New Revision b03115 of Raspberry Pi not identified correctly

In priciple this is the same issue as in #1270 that was fixed with #1376 again. I have a new revision that is not correctly detected as Rasperry Pi 4 and hence the same problem again.

Hint: I’ve posted the information below already as a comment at #1376, but @pgrawehr asked me to open a new issue here.

Details: When looking at /proc/cpuinfo I get the following output (cut down to the relevant part, important parts highlighted as bold text):

Hardware : BCM2711 Revision : b03115 Serial : 10000000aeb9cbea Model : Raspberry Pi 4 Model B Rev 1.5

This matches with the data that calling the pinout tool retrieves (again cut down):

Revision : b03115 SoC : BCM2711 RAM : 2GB

The “funny” part here is, that even the offical documentation does not list this board revision (but it states, that “this list is not exhaustive”…)

A quick fix for this issue could be to extend RaspberryBoardInfo.cs, line 166 0x3111 or 0x3112 or 0x3114 or 0x3115 => Model.RaspberryPi4,

But I’d like to question, if the approach to hardcode those regularly updated/supplemented numbers really is a good way? Shouldn’t there better be an alternative (read: extensible) way, that let’s one influence the board detection mechanism? Maybe some kind of delegate or by providing a kind of option pattern?

As @pgrawehr mentioned, the current way is the only reliable way to detect the board type, I want to clarify the concern I’ve written above: I do not question the mechanism in general. I rather question the implementation. Resolving the board’s revision number into the correct board type is basically a dictionary lookup. Currently this is a hard coded switch expression and I doubt this is a good way ragrding the “moving target” of revisions that are beeing released from time to time. Maybe there is no better way to do it at the moment, then I’m fine with it - but I wanted to set you thinking about it… In my eyes there should at least be some kind of extensibility mechanism for that.

[pgrawehr]

@W1zzardTPU

Also the code could be restructured so that people can actually force a specific hardware driver without having to fork the whole repo to make code changes (which is beyond most people’s abilities anyway).

That is possible. Just use .. = new GpioController(PinNumberingScheme.Logical, new RaspberryPi3Driver()).

[Mr-Bart-Simpson]

I can follow @joperezr’s point in general. Though, I had some trouble with injecting the driver by myself because it didn’t allow me to set some pins to INPUT_PULLUP - but maybe that was an issue on my side. I will probably re-check that…

On the actual topic, I have to admit, I didn’t have a detailed look into the documentation until now. But after doing so (especially at the structure of New-style Revision Codes), I agree with @W1zzardTPU’s proposal. When having a closer look at e.g. the revision number I get, it disassembles as follows:

0 0 0 000 0 0 1 011 0000 0011 00010001 0100

N O Q uuu W u F MMM CCCC PPPP TTTTTTTT RRRR

0 0 0   0 0 0 1   3    0    3     0x11    4
                            |        |    |
                            |        |    |-> Revision
                            |        |
                            |        |-> Type: 4B
                            |
                            |-> Processor: BCM2711

So maybe the current way to mask with & 0xFFFF is just not good here and the last four bits should be ignored, particularly because the information encoded there isn’t really used for retreiving the model . Hence masking with &0xFFF0 should do the job.

Edited for some clarification: “isn’t really used for retreiving the model” here of course is only related to new-style revision codes. It probably would be the best to distinguish between old- and new-style revision codes in the first place and doing the proposed masking only for the latter…