|
|
|
|
|
|
by jeroenhd
1400 days ago
|
|
|
I'm a bit confused by the whole bootloader situation. Locking down a bootloader on an open device seems quite bad, but what's the issue here exactly? The user can install any bootloader they want, can't they? I know the ARM bootloader system isn't anything like the PC bootloader system, but even if the bootloader is loaded from eMMC, in what way is the user impeded? I would guess all the user should need to do to use their own bootloader is to pacman -R manjaro-arm-uboot and pacman -S pmos-uboot to hand over control of the bootloader image if you buy a device flashed with Manjaro, or overwrite the eMMC bootloader with one that manually tries to boot from the SD card before resuming normal boot? It seems that the frustrations about Manjaro go further than just the bootloader but I don't really understand why a SPI flash chip would even be a necessity in the first place. |
|
|
The "bootloader" isn't just a bootloader, it's effectively a critical firmware component. If the "bootloader" is missing or garbled, the board is bricked and can only be recovered by removing the eMMC, which would be very difficult for most users. Such a thing should not be stored on a data partition and managed like any other distribution package. If they aren't going to ship a separate SPI chip, the eMMC should at least be repartitioned to include a separate "firmware" partition and the bootloader should be shipped there. Distributions should then boot via a chainload mechanism, just like on x86 hardware. (This mechanism can be UEFI based but need not be.)