If we wanted to point to an epoch-making moment for our community, we’d take you back to February 29th, 2012. It was that day on which a small outfit in Cambridge put on the market the first batch of their new product. That outfit was what would become the Raspberry Pi Foundation, and the product was a run of 10,000 Chinese made versions of their very first single board computer, the Raspberry Pi Model B. With its BCM2835 SoC and 512 megabytes of memory it might not have been the first board that could run a Linux distribution from an SD card, but it was certainly the first that did so for pocket money prices. On that morning back in 2012 the unforseen demand for the new board brought down the websites of both the electronics distributors putting it on sale, and a now-legendary product was born. We’re now on version 4 of the Model B with specs upgraded in almost every sense, and something closer to the original can still be bought in the form of its svelte stablemate, the Pi Zero.
How Do You Evolve Without Casualties?
The problem with having spawned such a successful product line is this: with so many competitors and copies snapping at your heels, how do you improve upon it? It’s fair to say that sometimes its competitors have produced more capable hardware than the Pi of the moment, but they do so without the board from Cambridge’s ace in the hole: its uniquely well-supported Linux distribution, Raspberry Pi OS. It’s that combination of a powerful board and an operating system with the minimum of shocks and surprises that still makes the Pi the one to go for after all these years.
But for all that, the Pi is still a Pi with largely the same interfaces and the same PCB as it had when the original Model B received its first upgrade to a 40-pin header and 4 USB ports. How do you improve on that without breaking compatibility with nearly a decades-worth of projects? We don’t have an inside line on the Pi folks’ R&D thinking on a future Pi 5, but we’d like to advance the theory that they’ve already done so, and with a Raspberry Pi. Not the extremely cute Raspberry Pi 400 all-in-one, but the Pi 4’s stripped down sibling, the Compute Module 4. Say hello to the new cutting edge of Raspberry Pi, it’s where we think the most interesting hardware developments currently lie for the platform.
There have been Raspberry Pi Compute Modules for sale since 2014 when the first one appeared as a BCM2835 on a SODIMM form factor. Since then we’ve seen a couple of versions with the Raspberry Pi 3’s multicore BCM2837 still on a SODIMM, but it’s fair to say that with a few very notable exceptions such as the StereoPi they’ve failed to set the world on fire for our community while the Compute Module 4 has in a short time spawned an interesting array of carrier boards.
We’d like to hazard a few guesses as to why this might be the case, among them that early Compute Module pricing wasn’t tailored towards individuals, that the Zero offered a much more affordable way to find a Pi on a smaller PCB, and that while capable the Compute Module perhaps didn’t offer enough extra that a regular Pi couldn’t do. It made sense for the volume manufacturers it was originally aimed at, but not so much for a hardware hacker when the Pi itself was so easily available. The Compute Module 4 in its daughter board format by contrast offers easy availability and some significantly tasty extra interfaces such as the PCI Express bus that make it a far more tempting target for the experimenter than a regular Pi. When you can spin your own Pi to your specifications, why look back? Here are a few examples, should you fail to have been convinced.
A Plethora Of Ways To Spin Your Own Pi
In a similar vein though not quite so simple in its construction is [Arturo182]’s smallest CM4 carrier board. It’s a truly minimalist design that sits on just one of the CM4’s connectors and only exposes a UART, I2C, and SPI. It requires the CM4 version with on-board mass storage, but even with this limited array of interfaces it still has plenty of potential.
Staying with minimalism, the CM4’s own form factor makes a handy template for [Kamil Lorenc]’s uCM4, a board the same size as the CM4 that’s designed as a tiny network powerhouse. It has an Ethernet port of course, and beyond that just micro USB for power and USB2, and a microSD slot for a boot disk. With USB-OTG support we could see it becoming a mini network too accessible from a portable device, for example.
While we’re on the subject of network peripherals it’s worth turning to the CM4-based NAS from [mebs]. Simple NAS devices have long been a Raspberry Pi staple, and this one takes the idea to the next level with a PCIe slot holding a SATA card. This is something that finally turns Pi-based NAS boxes into something that can compete with more conventional devices, as while the USB3 on the Pi 3 offers the speed it doesn’t so much offer the flexibility.
Finally in our quick round-up of CM4 projects is the StereoPi V2. We mentioned the original StereoPi earlier, and when we saw that first board we lauded it as a demonstration of how the earlier range of Compute Modules could be used to spin up a custom Raspberry Pi without the inconvenience of trying to source one of the Broadcom chips. Like the original it incorporates most of the interfaces that make a Pi a Pi, but it does so in its own compact form factor and sporting those two camera connectors that are it’s raison d’etre.
We hope that having had a chance to see all these CM4 boards in one place will have convinced you that there’s something in the idea of freeing yourself from the constraints of a mere Pi. We hope the Raspberry Pi folks will be watching the breadth of work done using their creation too, and will make future Compute Modules ever more accessible. Welcome to the new face of the Raspberry Pi!
Header image: SparkFun, CC BY 2.0.
“This is something that finally turns Pi-based NAS boxes into something that can compete with more conventional devices, as while the USB3 on the Pi 3 offers the speed it doesn’t so much offer the flexibility.”
Correction, it’s the Pi 4 that has USB3 onboard.
Also, as I recall, the Pi 4 has a much better implementation of the Ethernet port, compared to earlier Pi models.
Yeah, the Ethernet MAC is on the SoC itself on the Pi4, rather than a USB->Ethernet chip on the board. It can do a full 125 MB/s of gigabit, rather than having to fight with everything else connected to that is connected to the same USB bus.
As far as I remember, the first generation of the model B (and A) did only have 256MB memory – which was increased to 512 with the model B+
It was increased to 512MB with the second revision of the 1st gen Bs – which, I believe, coincided with a shift in production from China to the UK (Wales, iirc?), and the release of the model A with 256MB rather than the initially announced 128MB.
You are quite correct, I still have two of the ‘tiny’ memory versions, that I’m not sure I’ve used for much for a while – one of them was till recently… Wait a second is still running (the newer Pi I was going to migrate to is in the pile of stuff next to my desk) a small home server/nas – as when its effectively a network backup and music library you don’t need super high data throughput, while it works why hurry to change it.
Correct, it was the 256MB release model that made me hold off from being a first adopter, it just wasn’t enough. I quickly got in on the party when the 512MB revision landed.
Now I think “what the heck would I need 4GB or 8GB for?”. I know there are plenty of people taking advantage of it, but for me 2GB is plenty more then I need.
Shout out to Jeff Geerling who has been cataloging the ever-growing array of CM4 boards here: https://pipci.jeffgeerling.com/boards_cm
👍
👍
👍
👍
For me the biggest poblem with all Pi’s (or their SOCs) is that you can’t put it to sleep (RAM suspend) which practically eliminates it from battery powered devices. Some Allwinner SBCs has working suspend but not very reliable.
yeah it’s a big one. most mobile ARM devices, and even x86, can power down significantly without even suspending. they just draw much less power when idle. they have a HALT or other wait-for-interrupt instruction in the cpu idler process that causes it to draw basically no power even while it’s waking up at 100Hz to increment the jiffy counter and run the scheduler. you can tell it’s effective because your phone not only gets great battery life but isn’t even detectably warm when its UI is off, even though it really is waking up constantly to do various housekeeping tasks.
i’m not sure why not, but pi doesn’t offer even that. the CPU is putting out heat even when it’s idle. it’s a real puzzler for me because so many people do put them on batteries…sometimes they do the work to hack around it (such as using an extra controller to fully power it down), but mostly i think they simply don’t use the project. they hook up the battery, run their chosen hello world app, take a photo for their blog or clickbait, and then put it in a box and forget about it.
it’s sad to me because there is so much promise. i wish i knew the real limitations of the broadcom SoC, but the one thing i know confidently is that i’ll never know specs for the SoC.
it’s really disappointing because thanks to android and chromeos, there are a huge number of very cheap SoCs out there that — whether really open or not — do have proper idle and suspend support in linux. it seems like some of the non-raspi boards ought to use these chips, but i’m sure there are good reasons they don’t but that i don’t know about.
but the biggest disappointment is that the raspi community is such that barely anyone is talking about these real limitations from its closed pedigree, so it’s a huge effort just to find out if other boards from other vendors have similar drawbacks or not. somehow after hearing about raspi for years, i didn’t find out about this limitation until i’d bought one and banged on it for a while, and i don’t really care to proactively go through that process for a dozen knockoffs hoping one of them has either an open enough chipset or a hacked enough kernel to provide these basic functions.
This. Also the fact that the pi uses a linear regulator further reduces its suitability for portable applications. Disabling the usb controller (powered by the regulator) drastically increases the power efficiency, but then you don’t have usb peripherals anymore.
It’s really unfortunate especially considering the pi is otherwise the perfect platform for portable applications. Also the fact that the pi has been around for years, has released multiple versions, and gotten this large of a community without such simple design improvements is mind-boggling.
They’ve not used linear regulators for a long time now. Pi 2 changed to several standalone SMPS chips. Pi 3+ changed to a big PMIC.
Surely the fact we’ve not added this feature means its not actually as simple as you seem to think! Its also often brought up on github and the Pi forums, so tis not like we are hiding it. In fact there are specific reasons why it’s not possible on the current and previous SoC’s without greatly exceeding the price budget. i.e. there are features missing from the SoC to support this and changing SoC is not an option. Interesting that very few other SBC’s have decent working sleep implementations either.
The CM4 can be put into low power mode – as low as 15uA according to the data sheet. I’ve played with it some and it works, but I can’t really measure such low draw accuracy to know what it really does.
You also have to ask what battery powered device needs less than the idle draw AND the computing performance of a Pi – idling the Pi4 is something like 400mA, that is pretty damn low for a system read to jump up to full load immediately. If you really want less power draw than that while not working do you really need such high power SOC? I’d argue most of the time you really don’t.
400mA @ 5V = 2W?? that is not “pretty damn low.” i have an x86 laptop and an arm chromebook that both draw about 2.3W idle *with the backlight on*. android phones draw much less than that and for the most part they never “suspend”, they just run the idle task on a single core.
and that 15uA is if there’s an external circuit driving GLOBAL_EN low. software shutdown is 8mA, and once it’s in software shutdown it can’t ever wake up again unless an external circuit pulls GLOBAL_EN low. that is basically the same scenario available on previous raspi devices, you have to have an external circuit to access that shutdown mode usefully, it’s not really any more useful than having a physical power switch otherwise. there’s no sort of low power wake-on-interrupt / wake-on-timer mode. no suspend mode.
for some tasks, people really do build the external circuit to achieve full shutdown and then wake it up on a timer. but it’s not nearly as generally useful as is possible on the kind of chips they put into regular mobile consumer devices. in short, it doesn’t seem to be a mobile SoC.
You are kinda proving the point, low power efficient goal devices are rather similar in idle – and when you need Pi level compute power its going to be rather more of your power budget that one task cranking it up blows perhaps as much as 10x the power draw – for super long time idle setups you throw in the tiny micro that wakes its on demand, so what is the big deal? I believe in both shutdowns unless you choose to turn the GPIO off its wake on GPIO too, but I can’t quite recall.
Would it be nice if it didn’t have any external parts required to do every possible usecase under the sun, magic power management so it can work as low as your android device, sure but also completely impractical and changes the cost to produce – its easy to make a pi draw less than its default idle too, bit of under volt and lower min clock and it gets lower, but I don’t have great tools to measure how much lower, just have seen a dip in playing with it.
“I believe in both shutdowns unless you choose to turn the GPIO off its wake on GPIO too, but I can’t quite recall.”
this is an excellent example of specifically why pi is so infuriating. i don’t know if you’re right or wrong but i do happen to know that the datasheet says you are wrong, it says specifically that in the 8mA software-shutdown mode, it will not wake until you pull GLOBAL_EN low for at least 1ms, which rules out wake-on-GPIO. so, you’re probably wrong, and why is that a big deal? i really don’t mean this as an insult to you personally, because i think you’re thinking reasonably there. on everything smaller than the pi and on quite a few things much larger, these sorts of features are taken for granted. it is very reasonable when you don’t know to assume that there must be a good way to work it out, because, after all, the pi is very popular and very mature at this point. this feeling you expressed so clearly, “i don’t know, but it’s probably possible.” it’s exactly the feeling i had, and i think it is the defining feeling of someone who believes in the promise of pi.
but if you go to actually do it, you find out it isn’t possible. i mean, obviously, it’s not impossible to build a little IO-watching circuit that triggers GLOBAL_EN or whatever, there is a way to make it work, kind of, in a crappy way. but if you have the idea that the pi is useful for a large number of use cases and has the sorts of features we take for granted on both smaller and larger platforms, then you’ll be happy in that belief *until you try to do it*. and then you’ll be surprised and disappointed.
and that’s the entire problem with pi from my perspective. just in this one example, there are so many battery-powered pi projects, you assume it has some pittance of mobile features. but if you go to build one yourself you find out, it doesn’t, and all those battery-powered projects you saw had huge handicaps because of this. there’s so much smoke, and then to find out there’s no fire, it makes the smoke seem fraudulent. and that is precisely why i’m so repeatedly negative about pi on here.
and it’s not just power management, all of pi is like this.
From memory of reading the config details there was a config setting that puts it into the very very lowest power state that disables GPIO wake, but the default is its on – it is in the documentation somewhere, as I’ve read it – I just can’t exactly remember it, and as is often the case with more than just the Pi not all the documentation contains all the details (or links to them) it should, so finding it again… I have actually played with on and off and regretted my lack of sensitive enough meters to measure such paltry power draw and see how well it really works – was considering having a little cluster of CM4 ‘controlled’ by a FPGA running a RISKV core Linux install, so the FPGA does the SSH, VIM terminal type stuff and can be just generally played around with – and then activates, maybe provides the boot image for (so like Tails or a VM resettable every boot) and plays display and Keyboard switch to the CM4’s for more graphical or CPU intensive loads – small, embeddable with great performance at low price, fire up when you need it so was looking how much of a difference it makes – trying to decide how much effort its worth in the design to the potential gain in battery life. Not yet confident enough in my FPGA understanding to actually give it a go, and right now finding a FPGA I can afford with the scope I want and an open source toolchain..
For myself as there isn’t anything even remotely in the same budget and functionality as a Pi to my knowledge its nearly the only game in town – some nice boards out there by other folks, but all with flaws more annoying than the Pi’s…
And where power management is concerned nothing even remotely as powerful, small, hackable and cheap as a Pi does it better (to my knowledge) – so when you don’t have a better choice…
Like it or not its the best at the niche it fills, at least right now by quite some margin, which is why its one of the goto for industrial integration as well…
I still have my Model A from RS BNIB, one day it will be an antique!
The CM4 boards would be much more interesting if you could buy one.
CanaKit and Adafruit both have boards available.
Thanks but CanaKit price gouges and Adafruit only has the 1GB no wifi version in stock.
Ahhr, do you have a problem with waiting until May next year – lol.
Be happy that you do not need some 3B+ – estimated delivery October 2022, according to RS.
It seem ironical that the raspberrypi.com (for professionals!) is introduced at the same time there is nothing to deliver.
I’ve seen the entire range of CM4s listed on eBay for very reasonable prices.
According to Ebay there’s been two listings in the last 30 days. One in China and the other for 2.5 times the MSRP.
got 8gb one week ago, they still have it for the official recommended price + VAT
https://www.welectron.com/Raspberry-Pi-CM4108000-Compute-Module-Lite-8-GB-RAM-WLAN_1
they ship internationally, free shipping over 100 eur
” with so many competitors and copies snapping at your heels, how do you improve upon it?” That’s certainly “revised history”. There were many, many inefficiencies of the first, and even today’s Pi’s, and that was partly on purpose. It was meant for the higher education market, namely engineering students (why isn’t that part of the history described here?) The faults in design were perfectly acceptable for an SBC that was a teaching tool, and the OS was another educational freebie, not part of a well-thought-out plan. The original Pi’s lack of capabilities was actually a plus, because Intel or another SBC maker would have crushed the Raspberry Pi Foundation like a bug if they thought there was really any serious competition. Intel didn’t catch onto the potential, and they were too late when they tried the Galileo and Edison. Much like IBM didn’t take clone makers very seriously, then found other companies to be in control of the market they aimed to dominate. This was history repeating itself, stealth and patience overtaking technical and economic superiority and establishment branding.
I wish I could have got through the rest of the article, but I just got really aggravated that such fiction is presented as history. “How to improve upon it” is certainly not Raspberry Pi’s problem. That’s just patently ridiculous. The writer think he’s a Jedi mindtrickster “these are the SBC’s you are looking for!” The farce is strong with this one!
i think i agree with your main thrust, and i think the raspi presents a very interesting set of capabilities for such a very limited and inexpensive device. but i’m sad that it really is aimed at education when its biggest drawback is not in its specs but rather in its documentation. especially for students, meeting a wall of buggy closed source firmware is uniquely discouraging. when i was first learning, on DOS in the early 90s, it was so hard to get information…and now information is so much easier to share but we’re in an even worse position. the undocumented firmware is now so much more complex. i am sad thinking of all the young people who are going to accept this as normal.
The first Pi as superb, for what they are – affordable SBC to let people who don’t have big company budgets actually play with direct hardware access and electronic engineering! Other SBC did exist at the time, if you have more to spend than a high end desktop for massively less performance than a really old low spec one, and were from what I could see never really available to the normal folk at all!
There is a reason even the first revision Pi ended up in many commercial products – its cheap and really really functional – way better than its rivals, and it still is as despite Greg A’s complaints its about the most openly documented and accessible board you can get…
So how do you improve upon it is a very valid question – as part of what makes it is the price point, that is hard to build too, part of that is the degree and quality of freely available documentation – which limits you as you can’t then use any parts with NDA’s that stop you releasing important documentation, and part of that is performance, which within the other constraints isn’t trivial either…
Or in short there is a reason most things end up with a Pi inside, because its a neat very accessible and affordable package you can actually use almost no matter your computer experience – so they generally are the SBC you should be looking at! If you are master of EE enough to get other boards running, and master of kernel compiling enough to keep it running somewhere near upto date software when the maker can’t be arsed then maybe you can find a good alternative for you – there are some out there, but nothing comes close to the Pi yet for long term support and useablity.
“its about the most openly documented and accessible board you can get…”
and doesn’t that bum you out? i mean, it’s not entirely true…at lower specs, almost every board is much more documented. and at higher price, even your typical x86 laptop or android phone has a better mix of documentation, open source driver stack, and functional closed source components. but you’re right, at the specific goal of running linux on something that costs less than $100 and has exposed GPIO, it probably is the openest or close to it.
doesn’t that just make you mad? or sad? especially for education? it’s such a huge step backwards, justified by the juxtaposition of a low price point and a little inertia.
Can’t have everything, and the RPI foundation have been the first step in the right direction for making experiments and education with computers possible in decades – usefully powerful, really well documented for the most part, easy to use, long term support, really versatile and importantly really damn cheap..
So yeah being a lover of open source it would be nice if it was more open, but considering the state of computing when I was a kid – you needed weeks of your Dad/Mums wages to pay for a system of any sort and then because it was so expensive couldn’t really do anything risky with it – and when you know it can’t be replaced in practically forever you don’t want to either. Being before the internet really exists enough to give you any hope of fixing it (at least as the kid novice who doesn’t understand it all, Dad in my case might have had a hope, but hardware electronics hasn’t ever really been his thing)…
Well first step EE style computer hardware playing – if you only care about software you are in a much easier to fill place – though getting kids excited about it really means you need tangible goals, so having the GPIO is really useful still… Pure software where success is it compiled and printed “hello world” just won’t grab them till they have a taste of where that software dev skill could go.
you clearly haven’t hit the firmware wall. i would guess, you aren’t a developer, or at least, not a developer who looks at the kernel much? that’s fine. there are lots of people who will never even notice the pi’s limitations, and many more who will notice but won’t care. but when i think about education, i bring my own biases, i think about people who will learn my own skillset. and i do wonder how kids these days will ever learn any of these skills.
i hate the ‘learn to code’ fad with its blinking light demo projects. a blinking light is no more interesting than ‘hello world’. it doesn’t seem to be a promising pedagogical technique to me. i agree that we should work to remove the unnecessary barriers. but problem-solving and self-directed discovery skills should take the front seat rather than making a nicely paved no-inquiry-needed path to do something that is only at best vaguely related to programming.
for a lot of people, pi is the only exposure to linux. a cheap and low-risk way to have a linux box. that’s a mixed blessing, though, because it’s a uniquely handicapped linux box. especially for people who really want to learn anything about it, it might as well be an android phone. you almost can’t hack it, the only projects you can do are the “google it and see if anyone else has solved your problem” projects.
open source software has been eroding unnecessary barriers for 3 decades now. and the progress has really been remarkable! if you do want to go on a voyage of discovery, it’s not easy, it is intimidating, but the frontier is so much larger than it’s ever been! if you learn C, you can look in the kernel source, you can look in the libraries, you can look in the drivers. surprisingly often, you can even get datasheets for the chips involved. so many of the walls that i struggled with when i was young are obsolete, have been obsolete for 15 years now! it is amazing!
and then you go on pi and you start looking at the source to the library and you discover it’s nothing but a poorly-designed wrapper around another library, which is a poorly designed wrapper around a kernel interface, which is a poorly designed wrapper around a driver, which is a poorly designed internal interface to a firmware, Which. Is. A. Black. Box. and if you’re really determined to poke at the black box, you discover that it’s buggy and poorly designed and *A MOVING TARGET*. you went through all of that and didn’t have a satisfactory result. it is as bad as anything from my childhood and worse than any other linux experience i’ve had in the last decade.
for that kind of education, it’s a tremendous failure. it’s introducing kids to open source software in an environment where you hit a wall…it doesn’t live up to the potential. it’s great for superficial projects and it has some utilitarian value. but it doesn’t reward digging beneath the surface, and to me, that is the single defining value of an educational project. education should teach you specifically the skill of digging below the surface.
I know exactly what you mean Greg, but ultimately that is only one pretty narrow field of digging into how such things work – from the point of view of doing things with Linux, its pretty much the same as any Linux box, but cheap and with GPIO – its only if you really want to dig right down into how every driver works – which while interesting doesn’t really effect the function as the Pi is pretty much stable and effective so the difference between it having a blob of proprietary or some reverse engineered/open by design driver is rather close to nill.
JamesH said, “Of course, what you are trying to do is exactly what I said in a recent post, very esoteric. You are perhaps just one of a few people who are trying to do whatever you are trying to do. The rest of the 99.9999% never “hit the firmware” wall, because the vast majority of users never need to go anywhere near it. Because everything “just works”.”
what i’m trying to do is turn my TV on and off from the commandline using shell scripts. that’s hardly esoteric. i found cec-client and libcec to be quite unsatisfactory — slow, bloated, buggy. i am representing a common mentality among open source developers. one of us is crazy enough to write something new, and then people later can leverage what we did, and maybe it’ll be less work for them because i’ve been here already.
i had an x86 laptop, hardly a panacea. its headphone jack didn’t work under linux. the open source sound driver had enough clues that i was able to hack it to work even though the underlying chipset had no pretense of openness. i contributed it upstream and it was in the mainstream kernel for a while. then someone else came along and saw this pile of hacked drivers and unified them into one generic driver, breaking support for my soundcard. i waited a couple more years and a third person came along and added support for my soundcard back into the generic driver. 3 different people each independently tilted at this windmill, and now the mainstream kernel has had solid support for not just my laptop but every one that used a related chipset, for 8 years now (i still have the laptop).
this is open source. this is how it works. it’s true that only a minority of people chase a bug all the way down, but each act by one hacker then becomes part of the open source pedigree. we build on top of eachother and the result is that nearly every x86 laptop is very well-supported now. none of these problems are easy and we do benefit a lot from institutional support from vendors, but there is nothing like the huge amorphous mass of open source hackers occasionally fixing the problems we run into.
when you dismiss the hackers who actually contribute to open source support as ‘esoteric’ you are guaranteeing no one will ever benefit from my work. and it shows! you say everything “just works”, but it is not so! every problem i have run into, i have googled and found other people ran into the same problem. many times, you can find different threads, people ran into it 3 years ago, 5 years ago, 6 years ago. and at each epoch of pi, there is a different mix of people who found a partial solution, people who said that exact same solution doesn’t work for them, and another person pointing out the firmware version change between the guys who had success and the guys who had failure. we never make monotonic progress, every step forwards is just a stab into the dark of an undocumented firmware, and every step forwards is immediately undone.
it is an interesting product with interesting capabilities but it’s antagonistic to open source and that’s not just bad for philosophical reasons. people want to do the same things with it that i want to do with it and they are bashing their heads against the same walls for 6 years now without progress.
You are a bit out of date with your firmware barrier comment. We’ve spent years making the device more open, all the graphics for examples are now open source. Most of the camera as well. We also have a much more extensive datasheet. What limitations remain (and they are very few unless you want something VERY esoteric) are not preventing millions upon millions of industrial users from benefiting from a cheap but powerful device with a robust software landscape. Of course, they don’t need sleep.
I do agree myself, but still some areas to work on there though, and if you keep running into what isn’t documented its bound to be annoying.
lol I am out of date, am I? It’s improved so much since Feb 2021 when i embarked on this journey?
Can you show me any documentation or source for the HDMI CEC firmware? This is no idle request or gotcha. I ‘figured it out’ well enough using the sources to the vmcs_host library, but i still don’t understand how you’re *supposed* to do bus address discovery. I am setting the logical address to 0xE for address discovery, which is against the CEC standard but probably harmless, and works. You would expect to go into discovery with no address assigned, but that generates a bogus assignment to 0xE or 0xF at random, and then the polling would fail or succeed at random after that. libcec authors came to this same problem and came up with their own crappy solution:
// due to often (more than 20% test cases – CEC bus with 8 devices)
// irregularities on returned status, repeat until we get SAME
// result twice in a row
If I try to figure out how to power down unused cores or unused peripherals, will I hit a worse wall? if I try to figure out how to get HDMI into 24bpp mode, is there anything to look at other than a 5 year-old forum thread where people report undocumented settings from /boot/config.txt and superstitiously try to divine which firmware versions correspond with which hack? If I wanted to get to the bottom of it and read the HDMI driver source code, would that be possible? What if I wanted to work around the limitation that HDMI must be configured at boot-up? Is there any light entering that black box?
I’m not trying to be hostile, I’m honestly interested in the answers to these questions. I’m frustrated because I was astonished that the answers weren’t forthcoming…I’m astonished because instead of reading the source code for the HDMI CEC firmware and then writing something to interface with it, I had to read the source to an entire stack of wrapper libraries before I could understand *the location of the wall and how much of the problem was hidden behind it*. Just to understand how much was unknowable took a solid day’s labor. But if I’m wrong, if I made a mistake, and I could have simply found documentation for this, golly please let me know!
Not sure why you need to do what you are trying to do, but note that the KMS driver, which is fully OSS, drives the entire HDMI stack, including AIUI CEC, and doesn’t use the firmware at all. We still have to use the firmware for codecs for legal reasons, although using ARM side encode is getting more and more feasible.
Of course, what you are trying to do is exactly what I said in a recent post, very esoteric. You are perhaps just one of a few people who are trying to do whatever you are trying to do. The rest of the 99.9999% never “hit the firmware” wall, because the vast majority of users never need to go anywhere near it. Because everything “just works”. You have made the usual error of assuming everyone wants to do what you want to do. They don’t. They just want something that works. We cannot please everyone all the time, what we can do is please the vast majority. If you fall out of that category, then use a different board; we are perfectly pragmatic, and know the Pi is not a panacea, and fully accept we cannot be all things to all people.
ugh i replied on the thread above sorry for the sloppiness :)
He’t not alone. I wanted to do some work with CEC as well, so let’s not pretend that this is some “esoteric” pursuit.
Don’t forget you are literally one in a million. 7-8 million devices sold per year, number of people who are working at that level in CEC, about 7-8 (made up number, but you get the point). That said, the new KMS driver I think handles CEC entirely in OSS, so refer to that for information.
yes, JamesH, developers are a minority. but open source means leveraging that minority. raspberry pi frustrates the minority of users who bring the value. that value is called open source.
i am one person but just my incidental stupid hacks over the past 25 years have been used by at least tens of thousands of people. that’s not to aggrandize my own contributions — i’m the tiniest piece of the open source puzzle, and i’m eminently replacable. even the things that use my code, i’m usually the smallest part of that project! and many times, my contribution is just a stepping stone for someone else to make a better contribution. he sees the flaws in my work and makes it better. but my random “esoteric” efforts have been used by so many people! and on raspberry pi, i meet an as-yet-unsurmounted barrier of a closed firmware that changes too often for hacks to have any value.
and there are so many people who are like me, and they sometimes work on raspberry pi, and i can’t profit from their hacks either. i don’t see or fix the flaws in their work because i can’t see their work at all! they can’t help me because their hack stopped working 3 years ago with a firmware update. i suffer coming and going. the open source magic is stymied. it is the bad old days. it is raspi.
I’ve a developer too, and when combined with colleagues have made a lot of contributions to the Linux kernel through Raspberry Pi, so I am not sure what your point it. As for firmware changing and breaking “hacks”, are you sure? Our firmware is API backward compatible, i.e. except in rare cases code running on the ARMs do not need to worry about the firmware, and the majority of changes to it are bug fixes anyway. Not only that, we are actively reducing reliance on the firmware, as I said above. The graphics and display are now all oss (KMS), the camera is mostly there (libcamera), which combined are actually most of the reasons to have the firmware. Its really only needed now for some codec stuff and clock and power management.
Our attitude to open source is not “antagonistic”, it’s pragmatic. We do as much as we can to make things as open as possible, which still ensuring a good experience for our many users.
I would be quite interested to know what walls people are still bashing their heads against. CEC has been mentioned above, and I think that should be fixed by the KMS driver. The lack of hibernation/sleep is down to HW limitations (SoC, not PCB), so not a lot we can do about that.
I think the CM4 board makes a lot of sense for people (or companies) who can design there own base boards for a specific purpose in mind. The general purpose regular RPIs with hats and such seem much more versatile for the rest of us. That said, I still want to get a CM4 and a ‘general’ purpose base board ‘just because’ :) . May be my next purchase … if I can find one and a base board. Even the regular RPIs are out of stock at adafruit.
The CM4io boards are fairly cheap and well featured, they even have the PCIe slot.
What a shame you just can’t walk into a local jaycar and purchase the raspberry pi foundation hardware off the shelf.
Even then it’s not cheap either.
I personally have had a few projects in mind with the CM4.
Though, hopefully the next generation is backwards compatible and just brings in a third board to board connector for the new stuff. (hopefully a couple more PCIe lanes.)
Though, still waiting for someone to make a decent laptop case for the CM4….
+1 on a laptop case for the CM4.
Is there even any place to buy a pi – at a reasonable price – anymore? My son wants one for an Octopi, but it seems only scalpers are selling them now. What’s the scoop?
Adafruit has the 8GB one in stock again. A bit overkill for Octopi…. But available.
Isn’t Octopi fine on a Pi Zero still? If so any of the pi family you can get is good enough – so something should be findable in your budget, but without knowing where you are for a suggestion on where to look for stock….
Only if you don’t use WiFi. The driver for the Zero-W uses a ton of CPU and might not feed your printer properly when there is some network traffic. Gina hates it when people do that!
I just don’t get why go to all that work to make your own board for it + the cost. Just use a pi4. Biggest problem with raspberry pi is no RTC. Would they just put a clock in the thing please…
Personally I’ve designed heaps of my own boards for specific tasks – with the chip shortages won’t be making any of them any time soon though… Most of them doing things a Pi4 really can’t – at least anywhere near as easily, as the Pi4 doesn’t have PCIe available, or two camera and display channels, and the rest simply making it neater – getting all the IO of the Pi4 to appear where I need it to be! Won’t knock the pi4 though, its a good little machine, and if does what you need that is great.
CM4 IO board has an RTC….
The alleged Raspberry Pi 5 should definitely have M.2 and Sleep/Suspend management. These are two shortcomings which make it still unmature device. Even miniscule ESP32 has sleep/deep sleep/ with event wakeup (GPIO event).
It’s much MUCH easier to do sleep on a “tiny” device like the ESP32. If we could have implemented sleep on the Pi, we would have done.
I don’t believe that. Making Sleep e.g. on PC is hard because of too many manufacturers and many different board and various memory SIMMs wiring and timing. But accomplishing that on a single unified board should be much easier.
@Jenny List said: “…its competitors have produced more capable hardware than the Pi of the moment, but they do so without the board from Cambridge’s ace in the hole: its uniquely well-supported Linux distribution, Raspberry Pi OS.”
Respectfully, in my opinion what makes Raspberry Pi so successful these days is its “ace in the hole” Community, not so much their Raspberry Pi OS. There are plenty of other OSs to choose from for the Raspberry Pi, both specialized and general-purpose [1]. For example I use DietPi [2] and Kali [3] often on the Raspberry Pi.
One thing Raspberry Pi OS does have going for it is that it’s pretty easy to make the OS read-only so it doesn’t wear out the SD memory card [4]. Of course if you’re going to run the OS read-only you’re probably going to want to boot to the command prompt and run headless (no keyboard, video, or mouse) via SSH (the Secure Shell); see [5] on how to do that.
* References:
1. Top 21 Raspberry Pi OSs for Various Purposes [2020]
https://itsfoss.com/raspberry-pi-os/
2. DietPi OS
https://dietpi.com/
3. Kali Linux [The Most Advanced Penetration Testing Distribution]
https://www.kali.org/get-kali/
4. Read-Only Raspberry Pi – Never Corrupt your Micro-SD Card
https://core-electronics.com.au/tutorials/read-only-raspberry-pi.html
5. How to Boot to Command Line and SSH on Raspberry Pi
https://www.digikey.com/en/maker/blogs/2018/how-to-boot-to-command-line-and-ssh-on-raspberry-pi
I am using Alpine Linux a lot for RPi’s, and I can really recommend it.
It is small, fast, and runs completely out of RAM – one can remove the SD card once it is up and running.
And creating the SD card is a nobrainer, just make a boot-able fat partition, copy the approx 100-150MB files and directories to it, plug it in the RPi, and one is up and running.
But the big problem currently is the shortage, and the foresight that it is not possible to get hands on any kinds of RPi’s for at least the next six months – that really a show stopper.
To get around the SD card problem is boot from a USB 3.0 SSD. I like the Samsung T5 or T7, but also found the old internal SSDs I had stacked up gathering dust work well with a USB 3.0 to SATA cable.
The thing about PI OS is the GPIO access is built in, ready to go. Load and go. Very convenient. Of course the other OS’s work really well if there is no intention of using the GPIO, like a web server, or media center, general purpose, or whatever. I’ll stick with PI OS’s 32 and 64bit versions if I need to run Linux. I’ve learned over the years Linux is … still Linux no matter what distro is running… Looking at Altibo currently where I can get the the board’s resources dedicated to a single program…. no OS overhead. Fun!
@Chris Nobel said: “I am using Alpine Linux a lot for RPi’s, and I can really recommend it. It is small, fast, and runs completely out of RAM – one can remove the SD card once it is up and running.”
Hi Chris. I tried Alpine Linux on the RPi a long time ago specifically for its claimed run-from-RAM capability (kind-of like a Linux Live distro). Except for BusyBox, Alpine felt a lot like a full-up distro from the good old days when things in Linux actually made sense. (Pre-systemd. The System-V rc-init era.) The problem was, monitoring with dstat and atop showed Alpine was still writing to disk at seemingly random times, plus I could not dismount the SD card when the system was running.
There’s another small Debian-based Linux Live distro called SLAX [1] that works pretty well. But the sole SLAX developer comes and goes intermittently, sometimes with long gaps. I’m going to give Alpine Linux another try. I see that Alpine is now 16 years old yet it’s still actively maintained and developed [2]. (16-years. Whew, how time flies!) Thank you for posting Chris.
1. SLAX
https://www.slax.org/
2. Alpine Linux
https://en.wikipedia.org/wiki/Alpine_Linux