Use mailbox to get hwrev

[cdsteinkuehler]

I ran into some trouble using this library on my system because (see below for details if interested).

Anyway, I was having issues with identifying the Raspberry Pi hardware platform. Since the code is already talking to the firmware mailbox register I just switched to directly asking the firmware for the hardware revision. I have no idea if this is a desired change or not, but to me it seems to make the code somewhat cleaner (as well as fixing my use case). I wonder if someone had intended to do something like this previously as there is a "dangling" definition for a get_version() function in mailbox.h that has no code behind it.

Details on my issue:
I'm using Buildroot + U-Boot + RAUC to provide a system that supports safe firmware updates and a fallback rescue partition (see: https://github.com/cdsteinkuehler/br2rauc). I'm using a 64-bit OS so I don't get the hardware details in /proc/cpuinfo. The /system device-tree entries the existing code in rpihw.c is looking for are actually populated by the RPi firmware. Since I load the device-tree from the selected root filesystem (allowing for kernel and device-tree updates over time) I don't have these entries in my device tree. I may see about having my U-Boot script copy over some of these RPi firmware populated device-tree nodes, but it was quicker in the short term to just update the hardware detection logic.

Thanks for the great project!

[Gadgetoid]

I'd take a wild guess that this would elevate the privilege level required for the library to say "your board is not supported, go away" (since IIRC mailbox requires root?) but I don't really see that as a problem.

This might take some significant regression testing, and potentially be obsolete once we figure out #183, but the code is much cleaner.

I have never been all that comfortable with the /proc/cpuinfo method of grabbing the revision, and your case is one I didn't consider in my argument against it.

I don't believe it's that you're using a 64bit OS, but rather that you're not including this patch (and whatever related patches make it show up in /proc/cpuinfo) - raspberrypi/linux@3e787f9

Looks like Revision ID in /proc/cpuinfo is- in fact- doomed to be the downstream hack I suspected it was.

[airtower-luna]

I ran into the same problem that when booting via U-Boot and having U-Boot load a device tree (in my case from a FIT image) the /system/* nodes aren't transferred to the new DT. The U-Boot devs are understandably reluctant to accept code to copy undocumented and non-standard nodes over (unlike e.g. /model, which is standard).

Which makes me wonder: Is checking the revision actually necessary? Looking through the definitions in rpihw.c, it seems all revisions of the same model share the same type, periph_base, and videocore_base values. The RPi documentation explicitly states that new revisions of a model "are always backwards-compatible", and recommends checking the /compatible device tree node as a more widely compatible approach where the exact revision isn't needed.

I'm thinking of an approach like:

1. Search the list in /proc/device-tree/compatible for a value starting with raspberrypi,. Using only the first value would be insufficient because vendors building devices based on RPi ones might prepend their own compatible values.
2. If found, use the remainder of the string to identify the model and load the correct set of values (like the revision is used now). Otherwise return an error (same).
3. Use /proc/device-tree/model to get a nicely readable identification (including the revision) if needed (e.g. to replace the current desc). This could also be used to identify the revision if contrary to the statement in the RPi docs any model should turn up in the future that needs per-revision quirks.

This would significantly simplify the code, and would not require mailbox access. That that might be acceptable, I can look at writing a patch. That would also solve #183.