update proposal 1 with the firmware notice
This commit is contained in:
parent
87b15960a3
commit
1178546e5f
@ -42,3 +42,4 @@ So now, two routes exist for us and I will lay out advantages and disadvantages
|
|||||||
1. The firmware on the QSPI flash is not "prod ready". This obviously means that the user needs to be informed that their board firmware needs to be flashed. **IF DONE INCORRECTLY THE BOARD MAY BECOME A BRICK!** ("Prod ready" means any distro can depend on it to base their image off of.)
|
1. The firmware on the QSPI flash is not "prod ready". This obviously means that the user needs to be informed that their board firmware needs to be flashed. **IF DONE INCORRECTLY THE BOARD MAY BECOME A BRICK!** ("Prod ready" means any distro can depend on it to base their image off of.)
|
||||||
2. We need the user to have access to the Serial console to issue some uboot related commands that enable a boot order of 'sd emmc nvme pxe dhcp'. Not everyone has a USB-to-TTL cable though.
|
2. We need the user to have access to the Serial console to issue some uboot related commands that enable a boot order of 'sd emmc nvme pxe dhcp'. Not everyone has a USB-to-TTL cable though.
|
||||||
3. Adding features like GPU support (in the kernel), PCIe support (in u-boot), etc will be slower because, well, we are relying on upstream, not the vendor.
|
3. Adding features like GPU support (in the kernel), PCIe support (in u-boot), etc will be slower because, well, we are relying on upstream, not the vendor.
|
||||||
|
4. New firmware versions should be delivered somehow. If going the generic image route, it needs to be done, preferably, using the `fwupd` mechanism. If the SBC-specific route is taken, we need to `dd` partitions 1 and 2.
|
||||||
|
Loading…
Reference in New Issue
Block a user