Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board
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.
Greetings, Jonathan Neuschäfer
[1]: https://www.sifive.com/documentation/chips/freedom-u540-c000-manual/
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.
On Fri, Jun 22, 2018 at 01:01:04PM +0200, Jonathan Neuschäfer wrote: [...]
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.
"While we’d love to provide you with this information, we believe we cannot. However, we can’t prevent anyone from disassembling the fsbl and copying the values sent to the blackbox DDR register map." (-- https://forums.sifive.com/t/ddr-controller-configuration-register-values-for...)
On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
"While we’d love to provide you with this information, we believe we cannot. However, we can’t prevent anyone from disassembling the fsbl and copying the values sent to the blackbox DDR register map."
and ... there ends my interest in the hifive. A shame.
ron
Hi,
Lets do some speculation that some off the shelf DDR memory controller is used.
Maybe it could be same as the RockChip aka Denali High-Speed DDR PHY IP from Cadence? It has also some "interrupt status" bits and such and "bstlen" which sounds same as the few regs named as the documentation.
Thanks Rudolf
On Sun, Jun 24, 2018 at 11:28:11PM +0200, Rudolf Marek wrote:
Hi,
Lets do some speculation that some off the shelf DDR memory controller is used.
Probably.
Maybe it could be same as the RockChip aka Denali High-Speed DDR PHY IP from Cadence? It has also some "interrupt status" bits and such and "bstlen" which sounds same as the few regs named as the documentation.
I haven't compared the register maps, and I'm not familiar with other controllers, this sounds like a good lead.
If this is the Denali DDR controller, do you think it would be possible to simply read the initial configuration out of the registers of a booted system? (In any case, that's probably worth trying.)
Jonathan Neuschäfer
Hi,
Dne 25.6.2018 v 09:01 Jonathan Neuschäfer napsal(a):
If this is the Denali DDR controller, do you think it would be possible to simply read the initial configuration out of the registers of a booted system? (In any case, that's probably worth trying.)
Perhaps it could work with the existing coreboot code. Basically it seems the PHY addresses are just black boxes and the configuration is mostly black box. Plus some logic is needed. See rockchip/rk3399/sdram.c Maybe some bits needs to be initially 0, and written later.
Another suspicious coincidence that it is denali is this:
/* * work around controller bug: * Do not program DRAM_CLASS until NO_PHY_IND_TRAIN_INT is programmed */ copy_to_reg(&denali_ctl[1], ¶ms_ctl[1], sizeof(struct rk3399_ddr_pctl_regs) - 4); write32(&denali_ctl[0], params_ctl[0]);
You see, it writes the first register last. As the DRAM_CLASS is defined to be first register in sifive manual in bits 11:8. The LPDDR3 seems to be 6 in coreboot sources, and the sifive manual says DDR3 is 6 and DDR4 is 0xa which matches and also bit position seems to match!
There is also some denali support in the u-boot it seems.
Plus this seems to be some old iteration:
http://www.fujitsu.com/downloads/MICRO/fme/displaycontrollers/rd-mb86r12-eme...
Seems to document some of it.
Search terms: "denali" "CASLAT_LIN" or "denali" "dram_class"
Thanks Rudolf
Hi,
Sifive did great job [1] [2] and everything is now opensource including mask rom loader.
"Today we’re finally able to rectify this issue by releasing the FU540-C000’s ZSBL and FSBL as an open source project, which can be found on GitHub like all of SiFive’s other open source projects."
And I guess someone could be interested in:
"A Challenge
Now that the bootloader code has been released it’s time for a little challenge. Since the ZSBL lives in a mask ROM on the FU540-C000 there is no way to replace it, but you can at least re-generate the contents of the ROM and then verify that it matches the contents of a real HiFive Unleashed. We’ve posted a copy of the contents of the mask ROM at https://github.com/sifive/freedom-u540-c000-bootloader, the first person to submit a pull request that can exactly reproduce that ROM will get a HiFive Unleashed board!"
Thanks Rudolf
[1] https://www.sifive.com/blog/2018/09/06/an-open-source-release-of-the-freedom... [2] https://github.com/sifive/freedom-u540-c000-bootloader
On 09/11/2018 08:16 AM, Rudolf Marek wrote:
Hi,
Sifive did great job [1] [2] and everything is now opensource including mask rom loader.
Nice!
Truly a win for freedom hardware
Lets hope they next add an IOMMU.
"Today we’re finally able to rectify this issue by releasing the FU540-C000’s ZSBL and FSBL as an open source project, which can be found on GitHub like all of SiFive’s other open source projects."
And I guess someone could be interested in:
"A Challenge
Now that the bootloader code has been released it’s time for a little challenge. Since the ZSBL lives in a mask ROM on the FU540-C000 there is no way to replace it, but you can at least re-generate the contents of the ROM and then verify that it matches the contents of a real HiFive Unleashed. We’ve posted a copy of the contents of the mask ROM at https://github.com/sifive/freedom-u540-c000-bootloader, the first person to submit a pull request that can exactly reproduce that ROM will get a HiFive Unleashed board!"
Sweet :D
I am trying that for sure!
https://github.com/sifive/freedom-u540-c000-bootloader/tree/challenge/u540-c...
Here is a linky to the actual mask rom for lazy people.
Thanks Rudolf
[1] https://www.sifive.com/blog/2018/09/06/an-open-source-release-of-the-freedom... [2] https://github.com/sifive/freedom-u540-c000-bootloader
It looks like someone already pulled it off :[
https://github.com/sifive/freedom-u540-c000-bootloader/pull/6
On Mon, Jun 25, 2018 at 2:46 AM, Jonathan Neuschäfer j.neuschaefer@gmx.net wrote:
On Fri, Jun 22, 2018 at 01:01:04PM +0200, Jonathan Neuschäfer wrote: [...]
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.
"While we’d love to provide you with this information, we believe we cannot. However, we can’t prevent anyone from disassembling the fsbl and copying the values sent to the blackbox DDR register map." (-- https://forums.sifive.com/t/ddr-controller-configuration-register-values-for...)
Thanks, seems our only option is to reversing.
-
Jonathan Neuschäfer -
ron minnich -
Rudolf Marek -
Shawn -
Taiidan＠gmx.com