[coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
rminnich at gmail.com
Sat Jun 23 18:52:33 CEST 2018
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 <citypw at gmail.com> wrote:
> On Fri, Jun 22, 2018 at 7:01 PM, Jonathan Neuschäfer
> <j.neuschaefer at gmx.net> 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
> >> > *a lot* of work has to be done on coreboot first, and I'm currently
> >> > 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,
> >> > 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.
> >> > 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:
> > • 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...
> coreboot mailing list: coreboot at coreboot.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot