All this said, note that the HiFive is no more open, today, than your average ARM SOC; and it is much less open than, e.g., Power. I realize there was a lot of hope in the early days that RISC-V implied "openness" but as we can see that is not so. There's blobs in HiFive.
Open instruction sets do not necessarily result in open implementations. An open implementation of RISC-V will require a commitment on the part of a company to opening it up at all levels, not just the instruction set. On Fri, Jun 22, 2018 at 6:12 AM Shawn <[email protected]> wrote: > On Fri, Jun 22, 2018 at 7:01 PM, Jonathan Neuschäfer > <[email protected]> wrote: > > On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn wrote: > >> Hi Jonathan, > >> > >> On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer > > [...] > >> > 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. > >> > > >> Is ZSBL really can be skipped? I thought it was part of internal ROM > >> inside the chip. > > > > Yes. If you set the MSEL switches to 0001, the code in the MSEL ROM > > (aka. ROM0) jumps directly into the memory-mapped SPI flash, instead of > > into the big ROM1, where ZSBL is. > > > > Coreboot doesn't yet support this mode, but the hardware allows it. > > > >> > (And note that this is just the situation on this particular SoC. > Other > >> > SoCs from SiFive or other vendors may boot differently.) > >> > > >> Well, if FSBL is the place where coreboot comes into play, we might > >> only have two options: 1, Reversing the FSBL which is ~9k assembly LOC > >> 2, SiFive make the FSBL open source( I don't see any reason why they > >> don't do it if they intend to build an open eco-system for RISC-V). > > > > 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) > > > > Initializing the PLLs and reading the OTP ROM should be easy enough > > because both are documented in, I think, sufficient detail. > > > > Section 20.3 describes the initialization sequence for the DRAM > > controller, but leaves out the values for the register for "memory > > timing settings, PAD mode configuration, initialization, and training." > > It says: "Please contact SiFive directly to determine the complete > > register settings for your application." > > > > I will ask on the forum. > > > > Assuming that SiFive will tell us the values of the missing > > configuration registers, I don't think we need to reverse-engineer FSBL. > > > That's good to know and it's very helpful. We've been studying how to > make coreboot work on Hifve Unleashed. If the reversing is not > necessary, that'd be save a lot of time especially the decompiler for > RISC-V doesn't exist yet. Thanks for the info. > > > -- > GNU powered it... > GPL protect it... > God blessing it... > > regards > Shawn > > -- > coreboot mailing list: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
