thefossguy/proposals
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

update proposal 1 with details about which boards can be supported with a generic image

Browse Source
This commit is contained in:
Pratham Patel 2023-05-08 09:32:19 +05:30
parent 1178546e5f
commit 6483177ccc
1 changed files with 12 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
01-riscv-visionfive2-disk-partition-layout.md
View File

@ -30,14 +30,23 @@ With a generic image, we can go with the conventional PC-style disk layout where
So now, two routes exist for us and I will lay out advantages and disadvantages for the generic route. You can assume the inverse to be true for the board-specific-image route.
## Advantages
## Types of boards
On a high level, there are two types of boards. This is categorized based on how much support for them is present in upstream. These categories are as follows:
1. **Zero or "barely working" support in upstream:** Any board that requires vendor kernel and/or vendor firmware to even boot will obviously need a board-specific image. (Supporting such boards will be a decision based on several aspects like 'community requests for supporting', 'any possible upstream effort', 'board provided to us (Rocky Linux) for supporting it', etc.)
2. **Full or "everything except GPU and other specialized hardware works" support in upstream:** Some boards, like the HiFive Unleashed, HiFive Unmatched and the StarFive VisionFive 2 can boot with unpatched upstream sources.
Since building a generic image for the first category of boards is by definition not possible, those are not considered for this proposal. This proposal is for generating images for the second category of boards, which enjoy full or nice upstream support.
### Advantages
1. Less storage + CDN cost.
2. Only one image to maintain, test and fix.
3. Less support headache.
4. Our image "should" work on SD, MMC and NVMe. (In theory, need to do more testing after uboot support is merged upstream.)
4. Our image boots off SD, MMC and NVMe. Maybe over PXE too! (MMC and NVMe support will obviously depend on board I/O and firmware support.)
## Disadvantages
### 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.)
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.