Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
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@gmail.com wrote:
On Fri, Jun 22, 2018 at 7:01 PM, Jonathan Neuschäfer j.neuschaefer@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
(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: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-
ron minnich