RPi CM4 lite* NVMe build

Avalanche does use Null polls but should do only while it is processing a continuous stream of incoming network data. It should be switching back to poll_idle once incoming traffic drops. IIRC there is also a back off so it doesn’t Null poll for too long.

Avalanche is very asynchronous and internally has all sorts of things run from a fairly crude scheduler to try and keep things interactive. There are definitely bugs here and IIRC there is one task which keeps running even when all sessions are closed.

Those need fixing.

This same mechanism is also used for a few “do this thing as soon as possible but not now” type events. I can’t actually remember the details.

When I originally implemented this, I spent some time using Druck’s tools to check that it wasn’t putting much load on the system, while trying to get a good throughput.

While I accept that Avalanche needs fixing, I do question whether a few tens of Null poll events a second is symptomatic of a system under strain.

I can’t remember the name of it but there was a module to allow poll words to be used for reacting to network input. IIRC Avalanche will use this if present, which may reduce the Null polls, though I suspect you would still see a few a second so it would still be triggering the CPU speed manager.

I did make a start on this many months ago but other things got in the way as they inevitably do and I forgot about it.

The reason you don’t see much wimp time allocated to avalanche is that it doesn’t Null poll continuously very often

A few 10s of Null polls isn’t a problem, it’s when you see thousands per second when the system is idle.

It does seem to be a problem in that it is causing the CPU speed to be unnecessary raised.

I find the speed switcher is finely balanced and a few null polls can tip it into turbo mode.

With the 29th February Pi 4 firmware and the change that indentifies the different cm4 variants. The CM4 lite now recognises all my SD cards. The SD card icon is also the correct one.

I tried building a rom from the 11-Mar tarball (with and without the latest changes from Sprow) but it fell over with an error at the install phase. Trying again on another machine it built correctly.

I agree – the 13-Mar rom with Sprow’s changes identifies the SDFS eMMc as SDFS::4 with the latest (29 Feb) start4.elf and fixup4.dat. Excellent.

Hopefully when these changes work their way through, the status of the 530 port for the Pi should transition from Red to Amber.

@andrew k

Is it now possible to buy a RPi computer module 4 lite, IO board, and NVMe SSD and build our own RISC OS systems? If so has anyone done this and documented the process of setting everything up?

I’ve been working on something like this, and given you highlighted this:

https://www.waveshare.com/cm4-io-base-box-a.htm

I think I may have something for you, which also has the advantage of feeding in support to the development of the FreeNVMe driver. Drop me an email at info@…

Well the exciting news is that the bug fixes have worked their way through into the daily roms and the Raspberry Pi is now at the same state of readiness for 5.30 as when the stable build for 5.28 was released.

The three outstanding ‘desirable’ items are XHCI with a keyboard switch; gamma without ‘disable_gamma’ and bug #494 related to composite video output to older TVs).

All of these were flagged up in 2020 and accepted as intractable and ‘not a show stopper’ for 5.28 release (in 2022) so we should expect to see an RC5 candidate for the Raspberry Pi once the dust has settled.