Mailbox property interface missing tag

[svrsig]

There is a mailbox tag for revision code Get board revision
Tag: 0x00010002] but no tag for the extended revision code (which flags whether CM4 has eMMc and of WiFi). Doing a vcgencmd otp_dump will show both revision code (at word 30) and extd revision code (at word 33). For the CM4 bits 31 and 30 of word 33 indicate whether WiFi (bit 31) or eMMc (bit 30) are fitted (zero = fitted). A mailbox property tage would greatly simplify start up as the property interface is available at rom start up but the vcgcmd is not.

[peterharperuk]

Yes, you're right. We should probably fix that.

[svrsig]

Yes, you're right. We should probably fix that.

If you could do that, it would be extremely helpful.

[peterharperuk]

It might make more sense to add something like /proc/device-tree/chosen/rpi-board-attributes as that's what we're doing for board country and duid

[svrsig]

In message ***@***.***> Peter Harper ***@***.***> wrote:

It might make more sense to add something like /proc/device-tree/chosen/rpi-board-attributes as that's what we're doing for board country and duid

RISC OS needs to get the information in the early stages of running the kernel (the RISC OS rom image). The HAL can use the mailbox property interface at this stage but the extended revision code isn't one of those properties. The purpose is to decide whether the mmc storage is 'fixed' or 'removable' so that it can be given the right drive number internally in RISC OS - either SDFS::4 (fixed) or SDFS::0 (removable), which is then set as the boot drive depending on the contents of the file 'CMOS' which is loaded into memory at a known offset from the kernel (rom) - one parameter is the filing system number and drive number for the boot drive. Hope this helps.

…

-- Chris Hall ***@***.***>

[peterharperuk]

The information is in /proc/device-tree/chosen/rpi-boardrev-ext already. Can you use that?

[pelwell]

I'm sure somebody would love to write a minimal fdt parser in ARM assembler.

[peterharperuk]

\proc not available then? It's fairly easy to add a mailbox command but I'm not sure about getting that support into pre-Pi5 devices.

[pelwell]

@dp111 is more au-fait with the state of RiscOS development, but it used to be rather... spartan.

[popcornmix]

\proc not available then?

RISC OS is not based on linux, so no.

[rps102]

As others have commented, RISC OS is perhaps better thought of as a bare metal OS, it doesn't use a pre-kernel bootloader nor does it understand Linux device tree blobs, hence the interest in getting the extended revision flags word via a mailbox tag.

This would allow the very early boot to distinguish between a Lite (no eMMC) and normal CM4 with eMMC, which in turn sorts out the fixed disc versus removable drive paradox.

On original Acorn systems these sorts of low level/pre OS settings would be stored in an EEPROM (or battery backed real time clock). It's not spiritually that different to have them in OTP flags on a Pi today, we just need a legal way to read them.

[timg236]

N.B On Pi5 all new firmware / hardware configuration properties (e.g. USB-PD) are exposed via device-tree and where possible the vcmailbox interface to firmware drivers is being removed.

[rps102]

N.B On Pi5 all new firmware / hardware configuration properties (e.g. USB-PD) are exposed via device-tree and where possible the vcmailbox interface to firmware drivers is being removed.

For Pi 5 that shouldn't be an issue for RISC OS, because the kernel is currently written in AArch32 assembler and will need extensively rewriting (the Pi 5 can't run 32 bit privileged mode code) before it'd even run.

This request here for the extended flags via mailbox is only concerning the pre-Pi 5 (32 bit) family.

[popcornmix]

Latest start.elf firmware enhances the GET_BOARD_REVISION mailbox message.

pi@pi4:~ $ vcmailbox 0x00010002 4 4 0 0
0x00000020 0x80000000 0x00010002 0x00000004 0x80000004 <board rev> 0x00000000 0x00000000 
pi@pi4:~ $ vcmailbox 0x00010002 8 8 0 0
0x00000020 0x80000000 0x00010002 0x00000008 0x80000004 <board rev> <ext board rev> 0x00000000

[rps102]

Confirmed with a bit of BBC BASIC that this returns the extended revision word per the original post. Nice touch to extend the existing message tag 0x10002 - older firmware accepts the 8 byte request and returns 4 byte answer so it's also possible to distinguish old firmware from new that way.

@svrsig agree this ticket can be closed?

[svrsig]

In message ***@***.***> Robert Sprowson ***@***.***> wrote:

Confirmed with a bit of BBC BASIC that this returns the extended revision word per the original post. Nice touch to extend the existing message tag 0x10002 - older firmware accepts the 8 byte request and returns 4 byte answer so it's also possible to distinguish old firmware from new that way. @svrsig agree this ticket can be closed?

Yes, very pleased with the response. This has helped very much. Thanks.

…

-- Chris Hall ***@***.***>