4 ms·

Well, I love the promise of RISC-V but let's not delude ourselves. Some of the potential for RISC-V is to allow manufacturers to extend the ISAs with their own

Well, I love the promise of RISC-V but let's not delude ourselves. Some of the potential for RISC-V is to allow manufacturers to extend the ISAs with their own features. Some of those are bound to include undisclosed instruction sets. So it should come as no surprise that beyond that, SoC designers will likely be bound by their suppliers to keep some bits secret.

pjc50 8y ago
This doesn't seem to be about instruction sets so much as it's about the boot process; in particular, the first stage boot loader. Quote from linked email: "A high-level list of tasks that FSBL performs is in the manual[1]: • Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by configuring and running off the on-chip PLL • Configure DDR PLL, PHY, and controller • Set GEM GXL TX PLL to 125 MHz and reset it • If there is an external PHY, reset it • Download BBL from a partition with GUID type 2E54B353-1271-4842-806F-E436D6AF69851 • Scan the OTP for the chip serial number • Copy the embedded DTB to DDR, filling in FSBL version, memory size, and MAC address • Enable 15 of the 16 L2 ways (this removes almost all of the L2 LIM memory) • Jump to DDR memory (0x8000_0000) The manual can be found by googling for that GUID. https://static.dev.sifive.com/FU540-C000-v1.0.pdf https://static.dev.sifive.com/FU540-C000-v1.0.pdf I think the demand for "open source" hardware needs to accept that, because there are fundamental physical limitations on software freedoms 2 and 3 (https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html), the market for open hardware is going to behave differently. We can certainly keep asking for more openness, but perfect openness will probably not be acheivable.
- MaxBarraclough 8y ago
  I'm inclined to be more optimistic. Compared to how much Free/Open hardware progress has been made in the last couple years with RISC-V, getting a pure FOSS boot loader sounds like a cakewalk, no?
  - ac29 8y ago
    Its quite a bit more complicated than "bootloader" might make it sound. From the mailing list: "The original boot chain on the SiFive FU540 looks like this: MSEL (ROM0) -> ZSBL (ROM1) -> FSBL (SPI) -> bbl (SPI/SD) -> Linux Where the individual pieces mean this: MSEL: The "Mode select" ROM, consisting of a register that represents the state of four pins on the chip, and six instructions, which jump to the selected boot device or ZSBL. Fully documented (with an instruction listing) in the manual. ZSBL: The "Zeroth stage bootloader", several kilobytes of code in ROM, which parses a GPT header on SPI flash or an SD card and loads the next stage. Short, high-level documentation in the manual; I haven't seen the source code. FSBL: The "First stage bootloader", where interesting things like RAM init happen. High-level documentation in the manual; I haven't seen the source code. BBL: The "Berkeley bootloader". Its most important role, as far as I understand it, is to implement the SBI. The source code is public. See also chapter 6 (Boot process) of the FU540-C000 Manual[4]. With the unfinished coreboot port, I want it to look like this (although a lot of work has to be done on coreboot first, and I'm currently not actively working on that, for a few months): MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or MSEL (ROM0) -> coreboot (+bbl?) -> Linux ZSBL can be skipped, so you don't need to run closed source ROM code, at least as far as the hardware is concerned. (And note that this is just the situation on this particular SoC. Other SoCs from SiFive or other vendors may boot differently.)"

pjc50 8y ago

This doesn't seem to be about instruction sets so much as it's about the boot process; in particular, the first stage boot loader. Quote from linked email: "A high-level list of tasks that FSBL performs is in the manual[1]: • Switch core frequency to 1 GHz (or 500 MHz if TLCLKSEL =1) by configuring and running off the on-chip PLL • Configure DDR PLL, PHY, and controller • Set GEM GXL TX PLL to 125 MHz and reset it • If there is an external PHY, reset it • Download BBL from a partition with GUID type 2E54B353-1271-4842-806F-E436D6AF69851 • Scan the OTP for the chip serial number • Copy the embedded DTB to DDR, filling in FSBL version, memory size, and MAC address • Enable 15 of the 16 L2 ways (this removes almost all of the L2 LIM memory) • Jump to DDR memory (0x8000_0000) The manual can be found by googling for that GUID. https://static.dev.sifive.com/FU540-C000-v1.0.pdf https://static.dev.sifive.com/FU540-C000-v1.0.pdf I think the demand for "open source" hardware needs to accept that, because there are fundamental physical limitations on software freedoms 2 and 3 (https://www.gnu.org/philosophy/free-sw.en.html https://www.gnu.org/philosophy/free-sw.en.html), the market for open hardware is going to behave differently. We can certainly keep asking for more openness, but perfect openness will probably not be acheivable.

MaxBarraclough 8y ago
I'm inclined to be more optimistic. Compared to how much Free/Open hardware progress has been made in the last couple years with RISC-V, getting a pure FOSS boot loader sounds like a cakewalk, no?
- ac29 8y ago
  Its quite a bit more complicated than "bootloader" might make it sound. From the mailing list: "The original boot chain on the SiFive FU540 looks like this: MSEL (ROM0) -> ZSBL (ROM1) -> FSBL (SPI) -> bbl (SPI/SD) -> Linux Where the individual pieces mean this: MSEL: The "Mode select" ROM, consisting of a register that represents the state of four pins on the chip, and six instructions, which jump to the selected boot device or ZSBL. Fully documented (with an instruction listing) in the manual. ZSBL: The "Zeroth stage bootloader", several kilobytes of code in ROM, which parses a GPT header on SPI flash or an SD card and loads the next stage. Short, high-level documentation in the manual; I haven't seen the source code. FSBL: The "First stage bootloader", where interesting things like RAM init happen. High-level documentation in the manual; I haven't seen the source code. BBL: The "Berkeley bootloader". Its most important role, as far as I understand it, is to implement the SBI. The source code is public. See also chapter 6 (Boot process) of the FU540-C000 Manual[4]. With the unfinished coreboot port, I want it to look like this (although a lot of work has to be done on coreboot first, and I'm currently not actively working on that, for a few months): MSEL (ROM0) -> ZSBL (ROM1) -> coreboot (+bbl?) -> Linux, or MSEL (ROM0) -> coreboot (+bbl?) -> Linux ZSBL can be skipped, so you don't need to run closed source ROM code, at least as far as the hardware is concerned. (And note that this is just the situation on this particular SoC. Other SoCs from SiFive or other vendors may boot differently.)"