riscv: add firmware partitions to GENERICSD.conf

[mhorne]

Summary

Create two partitions in the existing space at the beginning of the
image (8MB). These are intended to hold u-boot SPL and u-boot proper.

The partition types selected are compatible with SiFive boards, e.g. the
HiFive Unmatched. They can easily be overridden for a platform that uses
the same scheme but different partition types, e.g. the StarFive
VisionFive v2.

It is not as simple to create the firmware partitions after the fact,
e.g. with partition indices 3 and 4. It is a shortcoming of current day
u-boot that the SPL loader looks for a specific partition index, rather
than the partition type, meaning that we will fail to boot if partition
2 doesn't contain u-boot.

Thus, our GENERICSD images become more generically usable with current
RISC-V hardware/firmware platforms.

[jrtc27]

Doing this for the Unmatched doesn’t seem very useful when we can’t use the SD card for our rootfs due to driver limitations. I’ve generally taken the view that the “correct” way to treat all these dev boards so far is to treat firmware as distinct, whether that means using on-board flash (and a normally-partitioned drive in any form) or a dedicated firmware SD card (and a normally-partitioned drive that’s not the same SD card). The Arm world is a mess with all the special firmware you need, and we should be pushing for standard EFI boot flows where the firmware is part of the board rather than the OS (even if we ship updates to it for convenience).

[manu]

In D43849#1000334, @jrtc27 wrote:

Doing this for the Unmatched doesn’t seem very useful when we can’t use the SD card for our rootfs due to driver limitations.

Which driver ? ours ?

I’ve generally taken the view that the “correct” way to treat all these dev boards so far is to treat firmware as distinct, whether that means using on-board flash (and a normally-partitioned drive in any form) or a dedicated firmware SD card (and a normally-partitioned drive that’s not the same SD card). The Arm world is a mess with all the special firmware you need, and we should be pushing for standard EFI boot flows where the firmware is part of the board rather than the OS (even if we ship updates to it for convenience).

Cool, go work for all board maker and make this happen, for now we will deal with firmware ourselves.

[jrtc27]

In D43849#1000398, @manu wrote:

In D43849#1000334, @jrtc27 wrote:

Doing this for the Unmatched doesn’t seem very useful when we can’t use the SD card for our rootfs due to driver limitations.

Which driver ? ours ?

Yes. Unmatched has no SD controller, you have to send raw SPI yourself, which we don't support, and would need some additional functionality ("holding" a device across multiple SPI transfers) in order to do so, IIRC.

I’ve generally taken the view that the “correct” way to treat all these dev boards so far is to treat firmware as distinct, whether that means using on-board flash (and a normally-partitioned drive in any form) or a dedicated firmware SD card (and a normally-partitioned drive that’s not the same SD card). The Arm world is a mess with all the special firmware you need, and we should be pushing for standard EFI boot flows where the firmware is part of the board rather than the OS (even if we ship updates to it for convenience).

Cool, go work for all board maker and make this happen, for now we will deal with firmware ourselves.

FWIW that *is* supported by the Unleashed, Unmatched and VisionFive 2.

[mhorne]

In D43849#1000334, @jrtc27 wrote:

Doing this for the Unmatched doesn’t seem very useful when we can’t use the SD card for our rootfs due to driver limitations. I’ve generally taken the view that the “correct” way to treat all these dev boards so far is to treat firmware as distinct, whether that means using on-board flash (and a normally-partitioned drive in any form) or a dedicated firmware SD card (and a normally-partitioned drive that’s not the same SD card). The Arm world is a mess with all the special firmware you need, and we should be pushing for standard EFI boot flows where the firmware is part of the board rather than the OS (even if we ship updates to it for convenience).

I really don't have the Unmatched in mind here; on that board it is easiest to use the memstick installer on a USB, and that's what I recommended in the wiki instructions. In other words, driver issues notwithstanding, I still wouldn't recommend GENERICSD for that board.

The problem I am trying to solve here is more related to the VF2, and conceivably other smaller SBCs where root-and-firmware-on-SD is desirable/common. Even in this development stage, trying to prep an SD card for this board is non-trivial. If I dd the GENERICSD image, I then need to rewrite the partition table in order to insert the firmware partitions at the correct indices (gpart cannot modify a partition's index). So, reserving these partitions is a pragmatic choice aiming to reduce the number of user-required steps to install with GENERICSD.

Btw, the choice to use hifive-fsbl and hifive-bbl as the default types is somewhat arbitrary. gpart has these type aliases, and the Unleashed came first of all, so it seems a fine choice.

[jrtc27]

In D43849#1000411, @mhorne wrote:

In D43849#1000334, @jrtc27 wrote:

Doing this for the Unmatched doesn’t seem very useful when we can’t use the SD card for our rootfs due to driver limitations. I’ve generally taken the view that the “correct” way to treat all these dev boards so far is to treat firmware as distinct, whether that means using on-board flash (and a normally-partitioned drive in any form) or a dedicated firmware SD card (and a normally-partitioned drive that’s not the same SD card). The Arm world is a mess with all the special firmware you need, and we should be pushing for standard EFI boot flows where the firmware is part of the board rather than the OS (even if we ship updates to it for convenience).

I really don't have the Unmatched in mind here; on that board it is easiest to use the memstick installer on a USB, and that's what I recommended in the wiki instructions. In other words, driver issues notwithstanding, I still wouldn't recommend GENERICSD for that board.

The problem I am trying to solve here is more related to the VF2, and conceivably other smaller SBCs where root-and-firmware-on-SD is desirable/common. Even in this development stage, trying to prep an SD card for this board is non-trivial. If I dd the GENERICSD image, I then need to rewrite the partition table in order to insert the firmware partitions at the correct indices (gpart cannot modify a partition's index). So, reserving these partitions is a pragmatic choice aiming to reduce the number of user-required steps to install with GENERICSD.

Btw, the choice to use hifive-fsbl and hifive-bbl as the default types is somewhat arbitrary. gpart has these type aliases, and the Unleashed came first of all, so it seems a fine choice.

I just flashed the firmware to the VisionFive 2's on-board flash and then booted the existing GENERICSD without touching partitioning.

[mhorne]

In D43849#1000412, @jrtc27 wrote:

I just flashed the firmware to the VisionFive 2's on-board flash and then booted the existing GENERICSD without touching partitioning.

This is ideal. Yet, when we are talking about users, the steps to a bootable system need to be simpler (read: foolproof). Updating the flash will inevitably fail for someone who is not qualified to recover from it, and then it becomes our problem.

A simple procedure to create a bootable SD card is what I'm after.

[• karels]

Is the following summary accurate: This change is not required for all systems, but doesn't hurt; it makes it easier for some configurations. If that's true, then I don't have a problem with it.

[mhorne]

In D43849#1000490, @karels wrote:

Is the following summary accurate: This change is not required for all systems, but doesn't hurt; it makes it easier for some configurations. If that's true, then I don't have a problem with it.

That is accurate, it has no functional impact on the resulting images.

FYI, I intend to set an MFC of 1 month for these changes.

[imp]

I've wanted this for other boards in the past. Though they were flexible enought not to require slot 1 & 2.

We should also consider just starting what is now p3 at 16MB or 32MB to allow growth of bootware for future parts and to better align with physical NAND size in the coming years on SD and crappy usb drives.