On Fri, Jun 22, 2018 at 7:01 PM, Jonathan Neuschäfer
On Fri, Jun 22, 2018 at 03:04:06PM +0800, Shawn
On Thu, Jun 21, 2018 at 7:48 PM, Jonathan Neuschäfer
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.
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:
• 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
• 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
• 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...