Raspberry Pi 4

Perhaps a heavier nudge?

How heavy were you thinking?

I was going to experiment but Farnell says new stock of the Pi 4 is not expected until 23 September so it seems I have missed the boat.

The 2GB boards are in stock at CPC: but not the 1 and 4 GB.

That makes sense; apparently they expected the 2 GB to be the most popular, so they made a lot of them.

I did a RPi 4 blog post mainly from a RISC OS standpoint (in German):

http://riscosblog.huber-net.de/2019/06/in-gespannter-erwartung-raspberry-pi-4-ante-portas/

I noticed while writing that I could not easily and quickly find info about cache sizes of the new BCM2711 Cortex-A72. Anyone happen to know that already?

GIYF – https://www.google.com/search?q=BCM2711+cache&ie=utf-8&oe=utf-8

tl;dr: 1MiB / 32KiB

OK, today I found a lot of info, too…the mighty Google indexer might have tidied things up over night. I guess we can assume a division into 16 KiB instruction and 16 KiB data cache?

RAM is said to be LPDDR4-2400 according to various sources (including the Foundation), but “3200” is sometimes also mentioned e.g. here: https://libreelec.tv/2019/06/libreelec-9-2-alpha1-rpi4b/ – maybe they already started their overclocking experiments…

Regarding the 1st Level Cache it seems for Cortex A72 it’s always 48 KiB I-Cache + 32 KiB D-Cache, so 80 KiB in total. Would be quite an improvement over Raspberry Pi3/Cortex A-53 with 16+16. Reference here

But I can’t find a direct reference to the BCM2711. Once Risc OS is running I can check the caches with my memory benchmark :-)

I would have expected to see the Cortex-A72 to have an “implementation defined” cache size note somewhere, but it seems not to be the case. The Foundation keeps quiet about caches, e.g. here https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/README.md

How’s that for a datasheet: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0_preliminary.pdf

A bit VERY light on the details…I moaned about the constantly lowering quality of datasheets before: http://itblog.huber-net.de/2018/04/die-zunehmende-nutzlosigkeit-von-datenblaettern/

Maybe the other sites just copy&pasted from the RPi 3 B+ specs.

I would have expected to see the Cortex-A72 to have an “implementation defined” cache size note somewhere, but it seems not to be the case

L2 cache size is implementation defined – ranging from 512KB to 4MB.

http://infocenter.arm.com/help/topic/com.arm.doc.100095_0003_06_en/way1381514591678.html

For the Pi 4, I get the feeling that they’ve crammed all the memory into the existing 4GB ARM physical address space.

This is correct. There’s a small (64MB) window at the top of the first 4GB of physical address space that by default has most of the peripherals mapped in instead of RAM. There’s enough space in the memory map to fit 16GB of RAM, so we should probably be planning on a future board (Pi 5?) to potentially have that much.

There is a big gotcha, though: the PCIe bus is only available in the top 8GB of the physical address map, and that’s where the XHCI (USB3) controller lives. Jeffrey, any feeling for how close we are to being able to use LPAE for IO regions, if not for RAM? I’m assuming that limits the APIs that would need extending to use >32-bit physical addresses.

The alternative is to do all accesses to PCIe via the new DMA controller that has access to the full 35-bit physical address map, which is possible but a bit icky.

Jeffrey, any feeling for how close we are to being able to use LPAE for IO regions, if not for RAM?

>4GB physical addresses for OS_Memory 13-style memory mapping should be trivial – look up “supersections” in the ARM ARM (16MB granular L1PT entries, with 40 bit physical address). It’s literally just a different L1PT entry format which we can use in our existing page tables. IIRC the only bits of the kernel source which would need modifying would be OS_Memory 13/RISCOS_MapInIO and RISCOS_LogToPhys. OS_Memory 0 doesn’t support log → phys mapping for IO memory, so that won’t need changing.

It’s only if we wanted to access RAM above 4GB (and have the OS treat it as RAM) that things would become tricky (migrating to the 8-bytes-per-entry “long descriptor” page table format, requiring a rewrite of all the page table handling code in the kernel)

that things would become tricky

Don’t forget, everybody, that this sort of thing has been done before. A RiscPC, running in 26 bit ARM mode, capable of addressing 64MiB, happily working on a machine with 128MiB fitted.
Same could be done for 35 bit addressing (why 35? is that the memory equivalent of “turning it up to eleven”?), it’s not as if anything on RISC OS is likely to say “I need an array that’s 4GiB in size”, so as long as everything looks the same in the system’s logical view of memory, nobody’s going to be asking what the MMU is actually doing. It could be fetching pages off the harddisc of a networked machine for all that it matters, as long as the right pages are in the right place…

Just got my Pi4 (1 GiB variant – seems to be the only one currently available – I heard that the foundation thought that the 2 GiB variant would initially be the most asked-for, but it turned out that everybody just wants the 4 GiB one), so if someone wants to offer a RISC OS version at least booting it…now would be the time :-)

Farnell says new stock of the Pi 4 is not expected until 23 September

.. so I ordered from CPC which said new stock on 7/6/2019 which I interpreted as 6 July (rather than 7th June) but which they interpreted as 29 July when I placed my order for a 4MB version (the 2GB variant was still in stock then).
It will be a race then to see whether RISC OS is up and running by the time my Pi 4 arrives.

I would have expected to see the Cortex-A72 to have an “implementation defined” cache size note somewhere, but it seems not to be the case

L2 cache size is implementation defined – ranging from 512KB to 4MB.

http://infocenter.arm.com/help/topic/com.arm.doc.100095_0003_06_en/way1381514591678.html

Thanks for reminding me of the ref, I seem to have extrapolated from Cortex-A53, which allows for different 1st level cache sizes.

Somehow I am lost in keeping track of all the core variants. I started a table comparing SoCs that are used on boards running RISC OS. Clock freq, architecture, cache sizes, VFP, NEON, and the speed and type of RAM. It’s a nightmare. But maybe somebody has already collected that info? Would be good to have it in ROOL Wiki perhaps?

when I placed my order for a 4MB version

Is that the “Archimedes retro experience” variant :-)

I started a table comparing SoCs that are used on boards running RISC OS

I don’t envy you. The A-core numbers don’t seem to necessarily follow a logical progression either.

But maybe somebody has already collected that info? Would be good to have it in ROOL Wiki perhaps?

Is it really necessary to know? We live with an OS that tries to go out of its way to not identify the platform, where most code is written to be transparently compatible with an ARM6 in 26 bit mode, and where the majority of boards have hardware FP but the standard compiler and libraries use an emulation of an ancient maths co-processor that few people ever actually owned. Crazy, but there you go…

That asides, the number of variations of the Pi family alone is getting pretty big.

…interesting read on temperature-issues and updated firmware found here

I also see that memory sometimes can be a problem…here ‘7Zip’ kind of crashed because of may be not enough memory and somewhere on the Raspberry Pi official forum I saw that ‘lame’ seemed to crash with the 4 GByte Pi.

I kind of guess it’s time to invest in heat sinks for that Pi ;-)

It will be a race then to see whether RISC OS is up and running by the time my Pi 4 arrives.

I now expect to receive my Pi 4 (4GB) on Monday 8th July so should be able to do some testing. I have a serial terminal (a Compaq 2114EA running Windows XP) and a GPIO to 9-way serial adapter.

I have a Pi 4 here, are there any prebuilt ROM images for it?
Just need to dig out a serial adapter.

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

I know about bootcode.bin (I can see that on the Raspbian SD card) but can’t find ‘start.elf’ (there is a ‘recovery.elf’). There is a ‘riscos-boot.bin’ (not sure what that’s for). Bot no sign of ‘fixup.dat’. Puzzled. Also what on earth is bcm2711-rpi-4-b.dtb?

Also what on earth is bcm2711-rpi-4-b.dtb?

That is no longer required to be present on the card.

I have done a build from git containing the latest firmware compatible BCMVideo 0.60 with the firmware as per the above link and on the RPi4 the start up still does not get further than the square rainbow. The same card is OK in the RPi3B+.

My Card.

CMOS         WR/
fixup4/dat   WR/
start4/elf   WR/
pi4/bin      WR/
riscos/img   WR/
BOOTCODE/BIN WR/
CMDLINE/TXT  WR/
CONFIG/TXT   WR/
FIXUP/DAT    WR/
START/ELF    WR/    

I can’t get any further than the square rainbow either.
Ben, any chance you can share a copy of the files you are using?

Many thanks, Ben. Just got to build the rom from the tarball now and to download the extra merge to add to it (and tweak a couple of flags).

Presumably I just need to add:
BCMVideo /s/BCMVideo
GenCmd /s/GenCmd
BCM2835ref /hdr/BCM2835reg
VersionASM /VersionASM
VersionNum /VersionNum
to the source tree (not sure why the links above don’t work – they should do). Git seems to be being a stupid git at the moment!
Edit to get linksright
Probably be Monday now before I can do it.