Does Linux 5.1 need to be patched to boot on FU540?


(Dayeol Lee) #1

I am using modified bbl + Linux.
Bumped the Linux to 5.1, which worked well on the upstream QEMU 4.1.
However, when I try to boot in HiFive Unleashed board, it does not print out anything after the bbl.

SiFive FSBL:       2019-12- 8-bbfcc28
Using FSBL DTB
HiFive-U serial #: 000000e6
Loading boot payload................................

bbl loader

                SIFIVE, INC.

         5555555555555555555555555
        5555                   5555
       5555                     5555
      5555                       5555
     5555       5555555555555555555555
    5555       555555555555555555555555
   5555                             5555
  5555                               5555
 5555                                 5555
5555555555555555555555555555          55555
 55555           555555555           55555
   55555           55555           55555
     55555           5           55555
       55555                   55555
         55555               55555
           55555           55555
             55555       55555
               55555   55555
                 555555555
                   55555
                     5

           SiFive RISC-V Core IP

Does 5.1 need some patches to work on the board?


(Jim Wilson) #2

Getting all of the drivers necessary for the hifive unleashed board accepted upstream has been a long and slow process. I don’t think that 5.1 was complete, I think it was either 5.2 or 5.3 when we finally had all of the necessary drivers upstream.

The necessary drivers can be found in various places. github.com/riscv/meta-riscv is for OpenEmbedded and has a list of drivers needed to boot on the fu540. it is currently at 5.3, but if you go backwards a bit in the git tree you can find the list of patches for 5.1. Look in recipes-kernel/linux/files/freedom-u540


(Paul Walmsley) #3

v5.1 is pretty old in RISC-V terms. Consider using a newer kernel. v5.4 works pretty well on HiFive Unleashed.

You’re using BBL - you’ll need to use a different BBL branch for more recent versions of mainline Linux. BBL uses a DT data format that differs from what’s in upstream Linux. This might help:

https://lore.kernel.org/linux-riscv/alpine.DEB.2.21.9999.1905280105110.20842@viisi.sifive.com/


(Dayeol Lee) #4

Thanks for explaining!

Where can I find the defconfig for 5.3 or 5.4?

Also, as long as I’m using bbl, will DT format still be an issue on HiFive board even if it boots correctly on QEMU?


(Dayeol Lee) #5

I updated Linux to 5.3, and also used the branch of bbl that is mentioned in the link.
However, my upstream linux does not generate *.dtb.

How can I generate the file?


(Paul Walmsley) #6

Where can I find the defconfig for 5.3 or 5.4?

The v5.4 defconfig is here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/configs/defconfig?h=v5.4&id=219d54332a09e8d8741c1e1982f5eae56099de85

You may need to modify the configuration generated by defconfigs to meet your particular needs; defconfigs are oriented toward kernel developers.

Also, as long as I’m using bbl, will DT format still be an issue on HiFive board even if it boots correctly on QEMU?

Yes, it’s still an issue.


(Paul Walmsley) #7

Consider using v5.4 instead, unless you have a strong reason to use v5.3.

However, my upstream linux does not generate *.dtb. How can I generate the file?

Run “make dtbs” after generating your target kernel configuration.
You should see a build line such as:

DTC arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb


(Paul Walmsley) #8

Unless you’re an expert at working with the Linux kernel, you may be better served by our Freedom-U SDK, available here:


(Dayeol Lee) #9

Update: I was able to cherry-pick the changes in bbl (that passes bbl without parsing) to my riscv-pk,
and it now goes on up until printing out the bbl logo. (Linux v5.4 and dtb from that)

Thank you for the defconfig!
I’m still struggling with the DT.

We currently use a modified FSBL and some additional security extensions in bbl.
We also need to apply some patches to QEMU and Linux,
so we are unable to just download and use the upstream freedom-u-sdk because apparently freedom-u-sdk has been radically changed since our last fork.
It has changed the entire build system and replaced a bunch of components (e.g., bbl --> opensbi),
which is very hard to catch up.

The bbl at dev/paulw/configurable-machine-data-methods-v1 branch with --with-config-method, --enable-dtb, and --with-dtb-path flags make it hang in both QEMU and HiFive. --> it now only hangs on QEMU, but I think it makes sense since the dtb is invalid?

I could figure out it just hangs while parsing DT (query_mem()), failing at assert(mem_size > 0). Also, I got Linux 5.4 booted in QEMU without those DT flags in bbl. Thus, these clearly indicate it’s still a DT issue.

Why we can’t replace the dtb in the FSBL (https://github.com/sifive/freedom-u540-c000-bootloader)?


(Paul Walmsley) #10

Yes - it’s simply designed to be usable with the HiFive-U, not QEMU. The reason why is that the BBL branch doesn’t use DTBs to configure BBL any longer. You could create a similar C file inside riscv-pk for a particular QEMU configuration, similar to what was done for the HiFive-U. If you wish to do that, the code in the “configurable-machine-data” branch of sifive/riscv-pk is somewhat cleaner; it may be easier to use:

The reason that this branch removes DT parsing from BBL is simply because BBL looks for non-standard DT data using the same DT data that is passed to the kernel (which uses the upstream DT data format only in its in-tree DT data). This mismatch causes problems in BBL.

Usually what I do is that I keep around a “standard” BBL binary for my QEMU tests. Then as part of my test flow for the HiFive-U, I build the BBL from the configurable-machine-data branch for that use case, since I want to test with an unmodified upstream kernel DTS file.

Another approach would be to upstream DT bindings into the kernel tree for whatever BBL needs, then to upstream a combined set of DT data into the upstream Linux kernel tree.

And another option would be to switch to OpenSBI and U-Boot instead of using BBL.

Why we can’t replace the dtb in the FSBL (https://github.com/sifive/freedom-u540-c000-bootloader)?

Same problem as just mentioned: the Linux upstream DT format isn’t the same as what’s used in BBL.