3 ms·

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 stay

by stefan_ 7mo ago

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.

actionfromafar 7mo ago
Could these choices have anything to with the alleged focus on Compute Module and less focus on the "normal" Raspberry? Does anyone know?
- zokier 7mo ago
  not really, it has been like that since day1. it has more to do with the weird architecture of the bcm chips they use.
  - geerlingguy 7mo ago
    When your SoC is a GPU with CPU cores tacked on, it's a bit weird to boot things up.
jacquesm 7mo ago
[flagged]
- mlvljr 7mo ago
  [dead]
- stefan_ 7mo ago
  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.
  - jacquesm 7mo ago
    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.
    - ciupicri 7mo ago
      Apple doesn't pretend to be open.
      - jacquesm 7mo ago
        Apple can afford to spend as much as they want on this and they are in control, they're as vertically integrated as it gets. Heck, they could divert some of their developer toll to this. The Raspberry Pi foundation is emphatically not in control of Broadcom, and in spite of their success still has limited resources and needs to work with what they've got and to prioritize.
    - mschuster91 7mo ago
      > 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. Ooooh of course, I 'member the days right here when they announced they'd drop Intel. And I am fairly certain the echo across the tech blogosphere was what led them to, while not openly announcing they'd support a competing OS like they did with Bootcamp, they'd at least not lock down the bootloader like on iOS devices. > 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. Apple, to my knowledge, never explicitly said "you can't" - at least not on Mac devices, for iOS the situation is different. All they're saying is "we won't help you, but you may try your best". > Not having UEFI on ARM has never held me back. The thing is the lack of UEFI adoption in the ARM sphere is holding everyone back! An OS / distribution shouldn't have to manage devicetree overlays on its own, they should be provided by the BIOS/UEFI management layer as a finished component. RPi is the biggest toppest dog in the embedded world, at least when it comes to an ecosystem. They would have all the muscle needed to force everyone else's hand. > 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. What did you do to that thing? On any pre-ARM machine, the bare bootloader should always, even if the primary storage is gone, be able to bring up enough hardware to support a UI, an USB and networking stack to allow restoring it from the Internet. ARM machines I'm not sure, haven't had the misfortune of having to dig down that deep, but I think even they should be able to do that in case you somehow manage to fry your partition table. And even if you managed to fry that, any other Apple device should be able to do a DFU restore on its lowest level bootloader.
- 000ooo000 7mo ago
  Very sorry, but people are allowed to have opinions and to express them. If the opinions upset you, then don't read them - by your logic anyway.
morpheuskafka 7mo ago
> 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.
- westurner 7mo ago
  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 p-boot do after the signed grub shim is verified?
  - westurner 7mo ago
    mokutil and these commands don't work without UEFI: mokutil --sb-state mokutil --help mokutil --import key.der mokutil --list-new reboot efibootmgr efivar fwupd fwupdtool fwupdmgr get-updates && \ fwupdmgr update tree /sys/firmware/efi systemctl reboot --firmware-setup
    - my123 7mo ago
      Note that UEFI doesn't mean supporting most of those. UEFI without runtime UEFI variable writes is a thing, and that configuration is incompatible with mokutil.
      - westurner 7mo ago
        FWIU, There is no SecureBoot without UEFI. UEFI without SecureBoot does have advantages over legacy BIOS with DOS MBR. > UEFI without runtime UEFI variable writes is a thing Which vendors already support this? Do any BIOS - e.g. coreboot - support disabling online writes to EFI? (with e.g. efibootmgr or efivar or /sys/firmware/efi) One of the initial use cases for SecureBoot is preventing MBR malware. What there be security value to addding checksums or signatures as args to each boot entry in grub.cfg for each kernel image and initial ramdrive? Unless /boot is encrypted, it's possible for malware to overwrite grub.cfg to just omit signatures for example.
praseodym 7mo ago
This is exactly why I’ve to replaced my home server by a low-power x86 NUC instead. No custom build needed to run NixOS and idle power consumption turns out to be slightly lower than the Raspberry Pi 5.
- elnatro 7mo ago
  Allow me to ask you what’s the NUC computer you are using?
  - tomaskafka 7mo ago
    I am not the OP, but I got an $150 (at a time) fanless quad core Celeron box at Aliexpress about 5 years ago, and it just runs with zero problems with openmediavault and dockers. Attached is external HDD over USB 3, it’s still fast enough (and the HDD is the bottleneck, not the USB interface).
    - prox 7mo ago
      I wonder if I can run this on a 2 year old celeron laptop
      - gapan 7mo ago
        You can run this on a 10 year old celeron laptop.
    - rokweom 7mo ago
      Few months ago it was possible to get Intel N100 (i5-6400 performance at much lower power) based mini PC with 8GB RAM and 256GB SSD for 100-120 USD on sale. Unfortunately, 'rampocalypse' happened.
  - praseodym 7mo ago
    I’m using an ASUS NUC 14 Essential Kit N355. It’s a bit more expensive than the Pi 5, but also more powerful (8 cores and decent GPU). There is also a more affordable N150 model. And even lower budget are the N150 mini PCs from Chinese manufacturers, but they often mess up things like cooling in a hardware revision (compared to the favorable review that you’d read). And forgot to mention this before: Intel CPUs with built-in GPUs have very performant and energy efficient hardware video codecs, whereas the Raspberry Pi 5 is limited and lacks software support.

by stefan_ 7mo ago

actionfromafar 7mo ago

Could these choices have anything to with the alleged focus on Compute Module and less focus on the "normal" Raspberry? Does anyone know?

zokier 7mo ago
not really, it has been like that since day1. it has more to do with the weird architecture of the bcm chips they use.
- geerlingguy 7mo ago
  When your SoC is a GPU with CPU cores tacked on, it's a bit weird to boot things up.

jacquesm 7mo ago

[flagged]

mlvljr 7mo ago
[dead]
stefan_ 7mo ago
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.
- jacquesm 7mo ago
  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.
  - ciupicri 7mo ago
    Apple doesn't pretend to be open.
    - jacquesm 7mo ago
      Apple can afford to spend as much as they want on this and they are in control, they're as vertically integrated as it gets. Heck, they could divert some of their developer toll to this. The Raspberry Pi foundation is emphatically not in control of Broadcom, and in spite of their success still has limited resources and needs to work with what they've got and to prioritize.
  - mschuster91 7mo ago
    > 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. Ooooh of course, I 'member the days right here when they announced they'd drop Intel. And I am fairly certain the echo across the tech blogosphere was what led them to, while not openly announcing they'd support a competing OS like they did with Bootcamp, they'd at least not lock down the bootloader like on iOS devices. > 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. Apple, to my knowledge, never explicitly said "you can't" - at least not on Mac devices, for iOS the situation is different. All they're saying is "we won't help you, but you may try your best". > Not having UEFI on ARM has never held me back. The thing is the lack of UEFI adoption in the ARM sphere is holding everyone back! An OS / distribution shouldn't have to manage devicetree overlays on its own, they should be provided by the BIOS/UEFI management layer as a finished component. RPi is the biggest toppest dog in the embedded world, at least when it comes to an ecosystem. They would have all the muscle needed to force everyone else's hand. > 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. What did you do to that thing? On any pre-ARM machine, the bare bootloader should always, even if the primary storage is gone, be able to bring up enough hardware to support a UI, an USB and networking stack to allow restoring it from the Internet. ARM machines I'm not sure, haven't had the misfortune of having to dig down that deep, but I think even they should be able to do that in case you somehow manage to fry your partition table. And even if you managed to fry that, any other Apple device should be able to do a DFU restore on its lowest level bootloader.
000ooo000 7mo ago
Very sorry, but people are allowed to have opinions and to express them. If the opinions upset you, then don't read them - by your logic anyway.

morpheuskafka 7mo ago

> 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.

westurner 7mo ago
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 p-boot do after the signed grub shim is verified?
- westurner 7mo ago
  mokutil and these commands don't work without UEFI: mokutil --sb-state mokutil --help mokutil --import key.der mokutil --list-new reboot efibootmgr efivar fwupd fwupdtool fwupdmgr get-updates && \ fwupdmgr update tree /sys/firmware/efi systemctl reboot --firmware-setup
  - my123 7mo ago
    Note that UEFI doesn't mean supporting most of those. UEFI without runtime UEFI variable writes is a thing, and that configuration is incompatible with mokutil.
    - westurner 7mo ago
      FWIU, There is no SecureBoot without UEFI. UEFI without SecureBoot does have advantages over legacy BIOS with DOS MBR. > UEFI without runtime UEFI variable writes is a thing Which vendors already support this? Do any BIOS - e.g. coreboot - support disabling online writes to EFI? (with e.g. efibootmgr or efivar or /sys/firmware/efi) One of the initial use cases for SecureBoot is preventing MBR malware. What there be security value to addding checksums or signatures as args to each boot entry in grub.cfg for each kernel image and initial ramdrive? Unless /boot is encrypted, it's possible for malware to overwrite grub.cfg to just omit signatures for example.

praseodym 7mo ago

This is exactly why I’ve to replaced my home server by a low-power x86 NUC instead. No custom build needed to run NixOS and idle power consumption turns out to be slightly lower than the Raspberry Pi 5.

elnatro 7mo ago
Allow me to ask you what’s the NUC computer you are using?
- tomaskafka 7mo ago
  I am not the OP, but I got an $150 (at a time) fanless quad core Celeron box at Aliexpress about 5 years ago, and it just runs with zero problems with openmediavault and dockers. Attached is external HDD over USB 3, it’s still fast enough (and the HDD is the bottleneck, not the USB interface).
  - prox 7mo ago
    I wonder if I can run this on a 2 year old celeron laptop
    - gapan 7mo ago
      You can run this on a 10 year old celeron laptop.
  - rokweom 7mo ago
    Few months ago it was possible to get Intel N100 (i5-6400 performance at much lower power) based mini PC with 8GB RAM and 256GB SSD for 100-120 USD on sale. Unfortunately, 'rampocalypse' happened.
- praseodym 7mo ago
  I’m using an ASUS NUC 14 Essential Kit N355. It’s a bit more expensive than the Pi 5, but also more powerful (8 cores and decent GPU). There is also a more affordable N150 model. And even lower budget are the N150 mini PCs from Chinese manufacturers, but they often mess up things like cooling in a hardware revision (compared to the favorable review that you’d read). And forgot to mention this before: Intel CPUs with built-in GPUs have very performant and energy efficient hardware video codecs, whereas the Raspberry Pi 5 is limited and lacks software support.