Raspberry Pi 4

Hello! Assuming RISC OS will need some tweaks to run on the newer Broadcom chip?

A quick check shows that the Cortex-A72 still runs AArch32, so a port to the Pi4 is at least theoretically possible. However, quite a lot has changed (USB3 etc.) so it may take a while even if there are no other roadblocks.

Anyway, I’ll be ordering a Pi4 just as soon as I finish writing this note…

Yes.

There’s a good chance that ROOL have already done some of this work, but we won’t know for sure until they make an announcement or make the code public.

Also there doesn’t appear to be a publicly released manual for the new chip yet, so if there are things that ROOL haven’t done, there might not be much we can do about it.

Watch this space!

There’s a good chance that ROOL have already done some of this work

Congratulations to Rick for deducing that. I may have acidentally published stuff ahead of the embargo being lifted, but only for about 30 seconds. I reckoned it was better to hide the one component until I’d cleared up the mess than to disable the whole site, but that apparently wasn’t enough :-)

Here is the current status – I’m afraid it’s not ready for general use yet.

Also there doesn’t appear to be a publicly released manual for the new chip yet

Tell me about it…

Might I suggest you consider hosting bcm2711-rpi-4-b.dtb just in case people don’t have a Raspian install.

The Pi firmware github repo has been updated now, so you can grab it from there.

https://github.com/raspberrypi/firmware/blob/master/boot/bcm2711-rpi-4-b.dtb

Just to throw a question “out there”, given how RISC OS handles memory allocations, are there likely to be any issues with a 4GiB model?

still runs AArch32

It may be that this is the end of the line for RISC OS the Pi models, but that’s not really a bad thing. We have the option of 1/2/4GiB memory, 1.5GHz quad core, USB3, proper Ethernet (not piggybacked on USB), onboard WiFi (dual band) and Bluetooth, dual display (4K, 60Hz, onboard HEVC decoding), finally USB C so one can pump a decent amount of juice into the thing…
Come on, with the exception of SATA (which might be a little faster than USB3 on an ARM board), this is probably the pinnacle of what RISC OS will run on, and if you ask me it’s more than adequate. Indeed, the thing is almost as highly specified as a two year old flagship phone, and it costs about fifty quid for the (already sold out!) top of the range model.

So don’t sweat it if the Pi 5 is 64 bit only. The Pi 4 is… bloody amazing.

The Pi 4 is… bloody amazing.

I’m going to give it a while (iron out the wrinkles, RISC OS support) and… Yeah… I’m tempted.

I’m not entirely sure why (my ARMv7 Pi2 is plenty adequate) but… I guess this is like the geek version of a bag of Maltesers. ;-)
(so glad I never bothered with the Pi3!)

Jeffery, please keep me up to date on your progress with getting other machines doing stuff over a network. I have older Pi hardware and, well, there’s an opportunity there. I’m wondering about taking the server off the desktop Pi and running it on a headless machine plugged into the mini hub. Then it can just sit and do what needs done.
Thing is, we (my mother and I) shut everything down fairly often this time of year (thunderstorms bite), I’ve got her trained to Ctrl-Sh-F12, and I have a little shutdown program that closes down ¹, I’d need to get it to talk on the network in order to shut down any other machines running.
Does Econet still work? Part of the network stuff is AUN, but I dimly recall it required weird network addresses. Is that still the case, or has it been updated to coexist with TCP/IP?

¹ I must make it smarter so that it can detect complaints about unsaved data and choose to discard the data (it’s usually an open TaskWindow). If the power is going off, data is going to be lost if unsaved, so it’s always better to get the machine into a state where it can be safely powered down.

are there likely to be any issues with a 4GiB model?

IIRC, the last time this question was asked the answer was that only the first 2GB are likely to be usable in any realistic timeframe. This was due to some functions still using the topmost bit of the address space as a flag of some sort. (EDIT: Found it )

I’ve ordered a 2GB Pi4 in the hope that I’ll be able to use all of the RAM for something, at least… :-)

Yeah… I’m tempted. […] I’m not entirely sure why (my ARMv7 Pi2 is plenty adequate)

Exactly.

(so glad I never bothered with the Pi3!)

I still find that Pi 2 is ample for RISC OS. But I have just ordered a 2GB Pi 4.

As this is a new Cortex implementation (and the latest ARMv8 we’ll likely ever get), it would be really useful (at least to me) to have an early version of RISC OS running on that machine, even if e.g. networking is not working yet. Just for software compatibility tests. I fear another CDVDBurn ARMv8 incident…

IIRC, the last time this question was asked the answer was that only the first 2GB are likely to be usable in any realistic timeframe. This was due to some functions still using the topmost bit of the address space as a flag of some sort. (EDIT: Found it )

That’s not exactly the problem.

RISC OS is currently limited to a 4GB physical address space. This is the main source of problems, because the typical way of producing machines with > 2GB of RAM is to place some of the memory above the 4GB boundary. E.g. with the 4GB version of the IGEPv5, there’s 2GB of RAM below the 4GB boundary, and 2GB above the boundary. This means that RISC OS is only able to use the lower 2GB of RAM (we’re also currently ignoring the last few MB of that, because of some address wrap-around bugs which are/were present). Removing the 4GB barrier is possible by implementing support for LPAE (“Large Physical Address Extension”) – which isn’t a massive amount of work (compared to e.g. some of the current bounties), but isn’t without a few headaches. So far nobody’s come up with a compelling reason to need that much RAM under RISC OS, so apart from occasionally nudging the code in the right direction, I haven’t devoted any time towards it.

For the Pi 4, I get the feeling that they’ve crammed all the memory into the existing 4GB ARM physical address space. So we shouldn’t need to implement LPAE in order to use the “full” 4GB, but in reality we won’t get to use 4GB anyway because ~32MB of it will be being used for accessing the other bits of hardware in the chip (similar to the 1GB Pi models, where 16MB of what should be RAM is actually used for peripheral access). But in reality this doesn’t affect things too much since the RAM which we can’t use gets used by the GPU for running its OS (the GPU and CPU have different physical memory maps, so even though we can’t see the missing memory, the GPU can).

There are problems with the way RISC OS manages its logical memory map (like the FileCore issue you linked to), but these will generally only become problems if there are lots of dynamic areas active, or if we decide to increase the maximum wimpslot size (since that will cause all the dynamic areas to get bumped up). IIRC there have been occasional requests for a larger wimpslot, so maybe that’ll come sooner rather than later. It can also easily be tied to a CMOS setting, so people who don’t need the extra space won’t have to worry about issues like FileCore storing flags in pointers. Although in the case of FileCore, I’d hope that the C rewrite that we’re getting as part of the partitions bounty will clean up those issues.

Historically there was also the problem that the free pool was mapped into logical address space (culminating in machines with 2GB of RAM often running out of logical address space when trying to create dynamic areas) – that would have definitely been a blocker to supporting more than 2GB.

Let’s ask a different question. Will RISC OS be able to work on a 4GiB Pi (even if it ignores half the memory), or should one prefer the 2GiB model?

Putting aside the missing documentation and subsequent lack of hardware support, there’s possibly going to be some instruction differences given the issues moving to Pi2 and Pi3. It’s not too different to the Pi3, so they’re probably going to be edge cases.

There’s possibly an errata to deal with, 859971 Speculative instruction prefetch to Execute-never (XN) memory could cause deadlock or data integrity – might come into play depending on the device memory map.

Speculative instruction prefetch to Execute-never (XN) memory could cause deadlock or data integrity

Hmm, I wonder if that’s related to the recent “issues” that somehow didn’t manage to flatten Intel?

I’m home now so I’ve been doing some research.

• Video is 4K/60Hz if only one display in use. It is supposed to be 4K/30Hz if two, but it’s “being worked on” apparently. Currently 1080p/60Hz max? Memory bandwidth issue?
• IIC clock stretching finally works. Maybe we can finally have a driver that doesn’t disable interrupts all the time. ;-)
• GPU is a VideoCore 6 (or VI in faux Latin). Still keeping with the proprietary there…
• Memory is LPDDR4 (and thus a fair bit nippier than previous models).
• The little handbook thingy that comes with the hardware mentions 8GiB on the front! A forthcoming option? FFS, that’d be more than most flagship phones (my S9 “only” has 4GiB onboard!).
• USB 2 might be a wiring up issue, because it appears from a photo that the USB chip is a VIA VL805, which is a PCIe to quad USB 3.0 host. Maybe a model B+ will offer all four ports as USB3? At any rate, they’re not on separate controllers, it’s an all or nothing deal.
• USB actually hangs off a PCIe bus. Yes, the new chip has PCIe. This could introduce some interesting options in the future.
• Might have milage as a NAS now, given USB3 support and gigabit Ethernet that is independent and not daisy chained to the overstressed USB. Okay, can it won’t be a good as a custom brick, but at less than a quarter of the price… Memory latency is a little slow, but the USB3 ought to manage around 3Gbit/sec.
• Which reminds me, the Ethernet driver is a BCM52413.
• Looks like the ARM is finally a first class citizen and not the GPUs bitch. As a side effect, second level boot code is now held in an SPI ROM – https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md
  If that’s ARM code and not ThreadX/GPU code, maybe some room for customising things like boot from LAN or USB?
• Fab is 28nm. Pi Foundation recommends running at 0-50C, and it’ll start to throttle to keep the temperature below 85C. Problem is, it’s been reported at running at over 65C out of the box and light loads. RISC OS might need rather more aggressive CPU speed management, and not sticking the thing at full tilt the moment the user presses F12.
• The SoCs own USB2 port is routed to the USB C connector. Future OTG capabilities?
• Vcore voltage is ridiculously tiny, a mere 0.85V. There was a time when TTL logic would consider that an “off” or zero input!
• There’s an internal high speed bus called “scb” that does DMA, Ethernet, USB, and some support for hardware video decoding. What’s the betting Broadcom copy-pasted that over from a set top box? ;-)
• PCIe will be okay for RISC OS, but with only 32 bit DMA support it’ll be interesting how that might work on an 8GiB model. It looks like there’s some brokenness with PCIe interrupts as well.
• Interrupt controller has changed to a standard GIC 400 – https://static.docs.arm.com/ddi0471/a/DDI0471A_gic400_r0p0_trm.pdf
• Preliminary data sheet : https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0_preliminary.pdf (doesn’t say anything we don’t already know)

I wonder if the GPU is still capable of scaling any arbitrary mode to fit a specific resolution? That’s one of the best things about the Pi – it has been told that my display is 1280×1024/60Hz and it outputs exactly that. Nothing more, nothing less. Whatever RISC OS tells it to use (320×240 to FHD), the result is always a reliable 1280×1024, with the mode in use being scaled to fit.

By comparison, my HDMI to VGA adaptor hates the Beagle. Getting anything at all out of it proved to be a challenge. My HDMI LCD fares better, but with 480×320 it’s a little cramped. ;-) https://heyrick.eu/blog/index.php?diary=20180406

As this is a new Cortex implementation (and the latest ARMv8 we’ll likely ever get), it would be really useful (at least to me) to have an early version of RISC OS running on that machine, even if e.g. networking is not working yet. Just for software compatibility tests. I fear another CDVDBurn ARMv8 incident…

ARMv8 attempts to define exactly what behaviour “unpredictable” instructions should exhibit, so I’d expect the A72 be be broadly the same as the A53 in terms of fussyness.

Let’s ask a different question. Will RISC OS be able to work on a 4GiB Pi (even if it ignores half the memory)

Almost certainly yes.

There’s possibly an errata to deal with, 859971 Speculative instruction prefetch to Execute-never (XN) memory could cause deadlock or data integrity – might come into play depending on the device memory map.

That should be OK – the errata relates to the logical mapping of the memory, not the physical arrangement. RISC OS keeps tight reigns on how IO memory is mapped, so it can easily add padding inbetween pages if necessary.

Yes, the new chip has PCIe. This could introduce some interesting options in the future.

Only if they release a board which exposes that PCIe bus. A good option for the compute module, but probably not going to appear on any regular Pi model.

Looks like the ARM is finally a first class citizen and not the GPUs bitch

Citation needed.

I wonder if the GPU is still capable of scaling any arbitrary mode to fit a specific resolution?

Almost certainly yes.

what behaviour “unpredictable” instructions should exhibit

Which would make them….. Predictable. :-)

in terms of fussyness.

Is there a reason for this, like a future plan to recycle bits as different meanings? I’m just wondering how much extra silicon is being used to spot dumb things and reject them. After all, isn’t the overwhelming majority of code these days emitted by compiler?

Almost certainly yes.

Great. If I was going to get a Pi4 (later!), then it’d make sense to get the most memory – Linux would appreciate it even if RISC OS would sit with about 3.8GiB unused.

Only if they release a board which exposes that PCIe bus

I was thinking more about other PCIe devices onboard. Imagine a Pi4+ with something like a Marvell 88SE14xx.

Citation needed.

It was something posted on CNX. Supposing that if the ARM booted itself from the SPI flash… but forgetting what got the machine to that state and provided the “recovery.bin” mechanism. :-)
Sadly I can’t find any recovery.bin file yet to see if it’s GPU code or ARM code. Given that firmware.bin is now ignored, I rather suspect it’s GPU code and not ARM.

Is there a reason for this, like a future plan to recycle bits as different meanings? I’m just wondering how much extra silicon is being used to spot dumb things and reject them. After all, isn’t the overwhelming majority of code these days emitted by compiler?

I’d imagine it’s mainly down to security. Knowing that none of your unpredictable/illegal instructions can be used for privilege escalation or can leak sensitive information is very useful.

Given that firmware.bin is now ignored, I rather suspect it’s GPU code and not ARM.

Yeah. Since it’s an evolution of the earlier GPU, and supports the same mailbox interface for communicating with the ARM, I’m almost certain that all they’ve done is shuffle around some bits of the boot code so that they’re stored in different locations/media. For the Pi 3 the hardwired boot ROM had to cope with SD, USB & ethernet booting, which proved to be troublesome when bugs were discovered. Moving most of that code to the SPI flash (so the hard boot ROM only has to deal with recovery.bin and the SPI flash) makes things much better.

I have just ordered a 2GB Pi 4.

What to do with it now? I look forward to something (anything?) which will at least attempt to start up.

which will at least attempt to start up

I have got as far as discovering the fixup4/dat and start4/elf are required but that only gets to the big rainbow square. All the firmware files from Raspbian did not get things any further forward.

I know this is nowhere near ready for use but I did think there might be signs of the RISC OS ROM attempting to start.

bcm2711-rpi-4-b.dtb is present and ROM is the latest beta which does have the RPi4 updates, AFAICS.

I know this is nowhere near ready for use but I did think there might be signs of the RISC OS ROM attempting to start.
bcm2711-rpi-4-b.dtb is present and ROM is the latest beta which does have the RPi4 updates, AFAICS.

The latest beta ROM wont help you. At the moment only the harmless/common changes for Pi 4 have been integrated (which are skipped or do nothing on Pi 3 and earlier) into the nightly builds, but the list of mods is also needed, and by extension also needs a custom ROM for the work-in-progress HAL changes.

I suggested to Ben hosting a suitable ROM somewhere (temporarily) so people can skip 4/5 of the steps.

I suggested to Ben hosting a suitable ROM somewhere (temporarily) so people can skip 4/5 of the steps.

There do seem to a number of keen experimenters who could form a nice alpha testing group for him.
Perhaps a heavier nudge?