Good reminder that the Raspberry Pis only have good software support if you stick to whatever the foundation is releasing. Because that same foundation has stayed obsessed with their weird custom ways of doing things, instead of furthering efforts like UEFI on ARM. Some of it is insultingly stupid - like for revD of the 5, you better now update the magic boot partition of your RPi with the device tree overlay for revD, because it will use the old device tree, but also expect the overlay to be there so it can actually work. To say the least, that is never what overlays were supposed to be for.
> custom ways of doing things, instead of furthering efforts like UEFI on ARM.
I thought uBoot was more or less the standard way of booting embedded Linux? Is it really worth bringing the entire UEFI environment, which is basically a mini OS, to such devices? Embedded devices are often designed to handle power loss or even be unplugged by users, so the boot up process is generally as lean as possible.
Besides that, if there is one constant about Raspberry Pi related articles then it is that there is always someone criticizing them no matter how hard they work and no matter how much they've tried to do within the rules as set by their corporate overlords.
Note that the Raspberry Pi is a lucky break and that every time you piss on the project, the founders, the contributors and the people who hold the purse strings you're doing us all no favors because there are some of us that use these things and that are praying that the peanut gallery (usually purists who would rather have nothing at all than something slightly flawed) doesn't one day cause the big boss to say it's all over.
If the Pi doesn't suit you, then don't use it. If you want something else vote with your dollars of show how it is done and if you manage to put something out with the same power, form factor, price point and not have it be controlled 100% by China I will probably become a regular buyer.
It is acutely on point. The only reason people have to put in work again and again to fix distributions like Fedora for Raspberry Pi models is because the foundation pulls stunts like that revD. Right now, you can take Buildroot at git master, build an RPi image and have it randomly not work on one of two what looks like identical RPi 5 boards. That's bad, and there is no reason for it.
Your comment only serves to illustrate exactly why big companies like BRCM are not seeing the case the way you do. Apple, if you want to start naming names puts out hardware that is far more closed than the Raspberry Pi foundation and yet you don't see the same level of aggression against Apple. What you do see is a couple of very talented hackers that won't take 'you can't' for an answer and that will RE stuff until they know enough to scratch their itch.
That's the way you solve these problems, not by writing take-downs.
Not having UEFI on ARM has never held me back. I do have a nice Apple laptop lying around here that is unusable because the network drivers need a functioning copy of Apple's OS on that machine to get bootstrapped. Rather than bitching at Apple about it I just stopped using and buying their products.
The first rule of bringup is thermal support.
Just another Raspberry Pi HAT ;)
Good reminder that the Raspberry Pis only have good software support if you stick to whatever the foundation is releasing. Because that same foundation has stayed obsessed with their weird custom ways of doing things, instead of furthering efforts like UEFI on ARM. Some of it is insultingly stupid - like for revD of the 5, you better now update the magic boot partition of your RPi with the device tree overlay for revD, because it will use the old device tree, but also expect the overlay to be there so it can actually work. To say the least, that is never what overlays were supposed to be for.
> custom ways of doing things, instead of furthering efforts like UEFI on ARM.
I thought uBoot was more or less the standard way of booting embedded Linux? Is it really worth bringing the entire UEFI environment, which is basically a mini OS, to such devices? Embedded devices are often designed to handle power loss or even be unplugged by users, so the boot up process is generally as lean as possible.
SecureBoot might be more useful than UEFI on SBC like Pi.
The grub EFI shim is signed, but does or doesn't verify kernel image and initrd and module (and IDK optionally drive and CPU and RAM hw) signatures?
mokutil does module signature key enrollment. Kernel modules must be signed with a key enrolled in the BIOS otherwise they won't be loaded.
To implement SecureBoot without UEFI would be to develop an alternate bootloader verification system.
But what does grub or uboot or pboot do after the signed grub shim is verified?
You are off-topic.
Besides that, if there is one constant about Raspberry Pi related articles then it is that there is always someone criticizing them no matter how hard they work and no matter how much they've tried to do within the rules as set by their corporate overlords.
Note that the Raspberry Pi is a lucky break and that every time you piss on the project, the founders, the contributors and the people who hold the purse strings you're doing us all no favors because there are some of us that use these things and that are praying that the peanut gallery (usually purists who would rather have nothing at all than something slightly flawed) doesn't one day cause the big boss to say it's all over.
If the Pi doesn't suit you, then don't use it. If you want something else vote with your dollars of show how it is done and if you manage to put something out with the same power, form factor, price point and not have it be controlled 100% by China I will probably become a regular buyer.
It is acutely on point. The only reason people have to put in work again and again to fix distributions like Fedora for Raspberry Pi models is because the foundation pulls stunts like that revD. Right now, you can take Buildroot at git master, build an RPi image and have it randomly not work on one of two what looks like identical RPi 5 boards. That's bad, and there is no reason for it.
And you would solve this how?
Your comment only serves to illustrate exactly why big companies like BRCM are not seeing the case the way you do. Apple, if you want to start naming names puts out hardware that is far more closed than the Raspberry Pi foundation and yet you don't see the same level of aggression against Apple. What you do see is a couple of very talented hackers that won't take 'you can't' for an answer and that will RE stuff until they know enough to scratch their itch.
That's the way you solve these problems, not by writing take-downs.
Not having UEFI on ARM has never held me back. I do have a nice Apple laptop lying around here that is unusable because the network drivers need a functioning copy of Apple's OS on that machine to get bootstrapped. Rather than bitching at Apple about it I just stopped using and buying their products.
Could these choices have anything to with the alleged focus on Compute Module and less focus on the "normal" Raspberry? Does anyone know?
not really, it has been like that since day1. it has more to do with the weird architecture of the bcm chips they use.