Those of us who have followed the Raspberry Pi over the years will be familiar with the various revisions of the little board, with their consequent new processors. What may be less obvious is that within the lifetime of any chip there will often be minor version changes, usually to fix bugs or to fine-tune production processes. They’re the same chip, but sometimes with a few extra capabilities. [Jeff Geerling] didn’t miss this when the Raspberry Pi 400 had a BCM2711 with a newer version number than that on the Pi 4, and now he’s notices the same chip on Pi 4 boards.
Why might they run two different revisions of the chip in parallel? It seems that the update changes the amount of memory addressable by the eMMC and the PCIe bus, the former could only see the first 1GB and the latter the first 3Gb. For the lower-spec Pi 4 boards this doesn’t present a problem, but for those with 8 gigabytes of memory it could clearly be an issue. Thus the Pi 400 and the top spec Pi 4 now have a newer BCM2711 version. This will almost certainly pass unnoticed for the average Raspberry Pi OS user, but the extra memory addressing space should be of interest for hardware experimenters wishing to expose that PCIe bus and talk to peripherals such as a GPU. That said, though he suggests the Compute Module 4 has the newer revision, his own experiments were unsuccessful.
[Editor’s Note: our own overclocking experiments show the C-version SOCs to run cooler/faster than their B counterparts, so it’s nice to have the better chips in the “normal” Pi form factor and not just the Pi 400 and compute modules.]
Yeah, I guess that they should have worded that as “and now he’s noticed the same chop on newer Pi 4 boards.” Since it wasn’t the chip in use previously.
It looks like he spend hours or days in scrubbing some information together and experimenting.
Isn’t there at least some document available from broadcom that describes all the differences, instead of painstakingly trying to reverse-engineer them one by one and never knowing what you missed?
Maybe such things were fun 15 years ago, but in these modern times there should be higher standards for documentation. One of the first things I did when I bought a few BBB’s was to download the datasheet of the Sittara chip on it. All 3000+ pages of it.
Just have a look at the sort of documenation that comes with it:
https://elinux.org/Beagleboard:BeagleBoneBlack#Hardware_Files
NDA’s due to licensed modules used by Broadcom probably prohibits that.
Also Broadcom were never famous for documenting things to make it easier for third-party developers to work with their things on their own.
I still remember how they were pretty much dicks in the Linux scene before the Raspberry-pi happened.
Open documentation creates a vulnerability to patent lawsuits. I believe that is the main reason why a lot of product doc requires an NDA.
Not really, Broadcom has many NDA’s in place and thats why even on an “Open” board, the firmware is still closed. It’s a shame Raspberry Pi foundation is utilizing a closed chip vs something that is open, but cost and reliability I assume still make this a great product. Also the “closed” nature of the CPU isn’t as bad as some other MCU vendors, but it is still limiting. Maybe one day, it will be RISC-V (or another open platform) based, with full documentation and sources, and no NDA’s … but that day is not today, yet.
RISC-V is just an ISA. It being documented and royalty free and extensible does NOT mean that its implementations are! Overwhelming majority if not ALL RISC-V SoC chips are proprietary!
Though there are few opensource implementations on that you can upload to you PROPRIETARY FPGA chip :)
Typos galore.
*Though there are a few opensource implementations on the internet that you can upload to your PROPRIETARY FPGA chip :)
On top of all the “open-ness” problems, there’s also the thing that a mere mortal can’t simply buy the broadcom chips and make his own boards.
“It looks like he spend hours or days in scrubbing some information together and experimenting.”
I consider Jeff an exemplar for hackers everywhere.
He tinkers with devices outside of their expected use case. He latest project is running PCIe video cards on Raspberry PIs. Neither of which are not particularly forthcoming with low level documentation.
He files tons of high quality bug reports.
He contributes many high quality patches.
That is pretty much the essence of hacker in my book.
Thanks for the compliment :)
Honestly, 90% of the hardware stuff posted to this site feels so far beyond me, so I’m glad to help eat at edge cases when I find them and have something to contribute.
The SGX530 might not be open though.
https://news.ycombinator.com/item?id=9021704
The goal of the Raspberry Pi was never to be an open source design. It was meant to built as cheaply as possible for students to use. Before the pi if you wanted a single board computer you were paying well over $100 for one.
Well so how much is for BBB now? did they made 4th generation with 64bit 2ghz cpu and 2GB ram for $35 too? Also is there opensource OpenGL and Vulkan driver for its GPU too?
btw pi is as open as you want and care for, there is gcc for videocore VPU for years and opensource rtos running on it https://github.com/librerpi/lk-overlay
raspi 400 is good design but i would like to put my motherboard, why not feather format? Orange Crab or some python stm
Today there are cheaper and better chip available but still without documentation. I should like to run an RealTime Operative System whatsoever to lower the batteri consumtion so it lives longer on battery but due to broodcom desition its impossible.
I have development board from different manufactors that solve my issue and make it not more expensive than RP pi whats so ever. Ok little more expensive but its solve my issues. Raspberry Pi whatsoever version does not.
the lost is actually Broodcom that still lives in a closed closet and refuse to open it. Its there lost.
I have sell several not closed closet solution to every one and thet get happier afterwards.
Still its the closed that is loosing. soo should raspberry pi also do… but most need a good performance and other need low power consume due to batteri need.
I still dont like SystemD and PulseAudio from the debian Linux Operative system. Its take much not needed space and consume alot of power. My solution is less than a 10 times lower than RPi whatsoever.
For most things the Pi is as open as it needs to be, and far better supported, generally with vastly greater performance than things more open…
So while I would like more open, as it stands the overlap between useable, well documented, open hardware’s capabilities and the well documented, fairly open and quite performant Pi family isn’t great – so when the Raspi family fits the bill its what I use – with all things its what is your use case and price range – and a Pi of some sort covers a wide range of those, while being pretty easy to use so is going to be the default choice for many for good reason.
Far as I can tell nobody must likes SystemD or PulseAudio, but they are (finally in pulseaudio’s case) a relatively functional system out the box with no challenging config for the user – so makes Linux Desktop use easier for novice Linux users/the less computer literate – makes sense most distro’s choose them for that reason alone (at least up till this new Pipewire stuff proves a better drop in replacement for PA – which I’d say it has now, but I don’t really have enough experience with the full range of sound systems to make that a statement of fact).
I do know I like working with the RPIs (main boards 1,2,3,4,400, zeros, A+, etc.) and now Picos (with C or Python) over the last few years. Just a lot of fun to tinker with using assembly (PI OS 64bit version), C, Python for apps. Now I recently found Ultibo (thanks to hackaday!) where I can write dedicated apps without overhead of an OS onboard. That excites me a bit as I like the Pascal language anyway and there is quite a few modules already built to handle the basic hardware on the RPIs. I wrote a lot of programs using Turbo Pascal through Delphi back when. So this is icing on the cake so to speak using Lazarus and freePascal. Interesting that it is come full circle.
The ‘proprietary’ nature of the CPU doesn’t seem to interfere with what I do and probably most users. Plenty of documentation to access the gpio and general programing for these boards. Anyway neat to see incremental improvements to the CPU.
rtthegergfeeswrtgfe, adafruit has a feather featuring the 2040 chip of the Pico :) .
What does this mean for a run-of-the-mill RasPi 4 / 8GB user? I got mine about a year ago and haven’t really dug into it yet. Will I be missing some functionality if I don’t have the latest revision?
I’m amazed that the 4 didn’t include a heatsink or at least directly plated on version with optional fan header location.
Should be simple to add this surely.
If ambient temperature gets too high or usage goes up the CPU ramps up fan speed.
Interesting note. I’ve heard that adversarial neural nets can be used to work around the restrictions for some applications.
Doesn’t technically count as reverse engineering either according to legal, but needs very sophisticated hardware ie an array of graphics cards and lots of time.
Other problem is you’d need to compile it for each and every model and some may work better than others.
Releasing a closed source blob but still mostly based on open source is perfectly fine and has been done before ie for TV set top boxes which often use silicon rejected for other applications due to things like excess power consumption.