New CM3+ model info

[procount]

What is the new model compatibility information for the new CM3+?
Do we need to update any os.json files? Or is it compatible with the existing CM3 model?

[JamesH65]

It does have a new revision code, but need to check what it is tomorow so I can update the docs.

[procount]

The revision code is not so useful for NOOBS now (although it would still be good if you could provide it).
Nowadays it matches the model name from the DTB, e.g. "Pi Compute Module Rev" so this information is more useful.
Also for quick updating of all the OSes used in NOOBS/PINN, could I assume that any OS suitable for e.g. the 3B+ or 3A+ would also be suitable for the CM3+? Or does it require yet another firmware/kernel version?

[maxnet]

Also for quick updating of all the OSes uses in NOOBS/PINN, could I assume that any OS suitable for
e.g. the 3B+ or 3A+ would also be suitable for the CM3+?

Recall you also need a custom dt-blob.bin file specific for the carrier board used.
Or is that no longer the case?

[JamesH65]

Should be OK with any firmware/OS past about November last year (2018). Should be compatible with the old CM3.

Revision code docs have been updated (might take an hour to get moved from GH to website).

[procount]

Thanks James, Are you referring to the following document?https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md

Unfortunately, it does not contain the model names, just the revision codes. It would be good if an additional column could be added to the new Revision Code table to include the model name. It's not always easy to find out this information from the DTS files (sometimes you folks hide this information to prevent information leakage of new products!). Finding the right git branch and the correct part of the DTS hierarchy is not trivial either and I can't seem to find a bcm_xxxxx_cm3_plus.dts file.

Should I assume the model name is still "Raspberry Pi Compute Module 3" ?

[JamesH65]

Sorry, not sure what you specifically mean by model name. The table already cross references the revision code against the model, for example, 8 is a 3B, 10 is a CM3+.

[maxnet]

Sorry, not sure what you specifically mean by model name.

If you boot a CM3+ and do: cat /proc/device-tree/model
What does it give?

[JamesH65]

Don't have a CM3+, but tried with a 3B+, so that's the format of model name you want in the table? (excluding revision?) Some sort of device tree name?

[procount]

Exactly. NOOBS does a pattern match on that string to see if an OS is compatible with the board.
Have a look at http://downloads.raspberrypi.org/os_list_v3.json for the supported_models field and you will see some of the list of patterns that are used to match the OS to the model names of the boards.

(You will also see supported_hex_revisions but that is no longer used and is there for backward compatibility with older versions of NOOBS. - But I don't see the point in maintaining this, since the latest models need the latest NOOBS anyway, so old versions of NOOBS can no longer be used)

[JamesH65]

Those supported_models fields seem surprising inconsistent. Pi 3, Pi 3 Model B, Pi 3 Model B Rev all seem to refer to the same device.

[maxnet]

Those supported_models fields seem surprising inconsistent. Pi 3, Pi 3 Model B, Pi 3 Model B Rev all
seem to refer to the same device.

Are partial string matches.

E.g. "Pi 3" will catch both 3B, 3A+, 3B+
"Pi 3 Model B" will catch 3B, 3B+
"Pi 3 Model B Rev" only 3B

[procount]

--Deleted-- Ditto! (you beat me to it!)
I rely on @XECDesign for these, but if we had the full model names we can check them and create other pattern matching strings for other OSes.

[procount]

I made an attempt to document these on my wiki some time ago: https://github.com/procount/pinn/wiki/Model-Names but they need updating now. You could use that as a starting point if you want.

[XECDesign]

That's interesting - I rely on @procount, since I don't have the hardware either. NOOBS is mostly community maintained at this point.

[maxnet]

Question do is if "model" is enough for compute model to indicate compatibility with an OS.

I know that in the past one needed a custom dt-blob.bin -specific for the carrier board used- to get things to boot with Slice and the Western Digital CM carrier boards.
No idea if it does work out-of-the-box -without extra files- with the official CM3 dev kit.

[JamesH65]

So doing find *.dtb -exec strings {} \; | grep "Raspberry Pi" in /boot gives a list of model names- is that what you are looking for in the table? Or more details?

[JamesH65]

Cross referenced against the dtb blob names themselves?

[maxnet]

So doing find *.dtb -exec strings {} ; | grep "Raspberry Pi" in /boot

As indicated by procount before, there is no bcm2710-rpi-cm3-plus.dtb listed in github.
Makes us believe that you may have forgotten to check a file in, or that you have hidden some logic in your blackbox firmware files.

[JamesH65]

I think that is simply because it uses the CM3 dtb - there are no differences as its simply a packaging change and any other CM3+ specific stuff is indeed handled by the firmware, probably things like max ARM frequency. Which of course is not a DT thing anyway.

[XECDesign]

It is generated by the firmware, and it's not too difficult to figure out what the string is by looking at the source. However, if it hasn't been tested, it doesn't work. Aside from knowing what the string is, we'd also need to know which distros run on it. At the end of the day, updating os_list files without having the hardware to test on is just guesswork or involves extracting each tarball, extracting the firmware version string from start.elf and checking whether that firmware supports the new model (and that's not information distro maintainers know either).

[procount]

That's interesting - I rely on @procount, since I don't have the hardware either

Lol! Reciprocity! (Maybe that will change for me in the future...)

[JamesH65]

In the firmware the CM3+ is treated exactly the same as the CM3, so uses the same DTB.

The DTB blob filename is generated as:

"bcm%d-rpi-%s.dtb", upstream ? 2835 : 2708 + processor, model

where model is a, b,a-plus, b-plus, zero, zero-w, 2-b, 3-b, 3-b-plus, 3-a-plus, cm, cm3

Note, cm3 and cm3 plus are current defined to use the cm3 dtblob.

[XECDesign]

The .dtb isn't the issue. Look in board_info.c.

It's "Raspberry Pi %s Rev %s", type_string, rev_string, which I believe works out to "Raspberry Pi Compute Module 3 Plus Rev ?". So given that currently most distros either have "Compute Module" or "Compute Module 3", they should default to being supported.

[realizator]

@JamesH65

In the firmware the CM3+ is treated exactly the same as the CM3, so uses the same DTB.
...
Note, cm3 and cm3 plus are current defined to use the cm3 dtblob.

Our board supports CM1 and CM3, and we have sections "pins_cm {..." and "pins_cm3 {..." in our DTS file. Am I right understand you that we don't need to add something like "pins_cm3_plus {..." now and in the future?

[JamesH65]

I cannot predict the future, but at the moment, I believe that is correct. The CM3+ is pretty much exactly the same as the CM3, but the SoC is packaged differently.

[llks]

I think that is simply because it uses the CM3 dtb - there are no differences as its simply a packaging change and any other CM3+ specific stuff is indeed handled by the firmware, probably things like max ARM frequency. Which of course is not a DT thing anyway.

But isn't it both the CM3 and CM3 Plus processor speed at 1.2GHz? If use the cpuinfo (cat /proc/cpuinfo), and the firmware image cannot detect that the hardware is CM3+, then can the firmware still work properly in the new CM3+ hardware?

[realizator]

@JamesH65, @llks JFYI: I have tested our StereoPi carrier board with CM3+ module. First test was done with old kernel, and device was unable to boot. After kernel upgrade (rpi-update) device successfully booted and passed all tests. All tests was done with our original dt-blob.bin with cm3 settings, without any DTS modifications for CM3+.

[llks]

i have tested to use the latest firmware file "start.elf", "start_cd.elf", "start_db.elf", "start_x.elf", "fixup.dat", "fixup_cd.dat", "fixup_db.dat", and "fixup_x.dat" to replace my original design firmware files then everything work!