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

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?

1 Like

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

2 Likes

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/

2 Likes

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?

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?

Where can I find the defconfig for 5.3 or 5.4?

The v5.4 defconfig is here: defconfig « configs « riscv « arch - kernel/git/torvalds/linux.git - Linux kernel source tree

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.

1 Like

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

2 Likes

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

1 Like

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)?

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 (GitHub - sifive/freedom-u540-c000-bootloader: Freedom U540-C000 Bootloader Code)?

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

1 Like

Anyone have a git repo with all of this in it? After following these instructions, I still can’t get it to boot the kernel. I want to essentially upgrade the buildroot-based SDK to a newer kernel (such as 5.4 or higher) in hopes of getting spidev access.

Hi Matthew,

You might consider trying our OpenEmbedded-based Freedom-U SDK. The master branch has new kernels, DT files, and an up-to-date userspace. We’re about to issue a new stable release, but in the meantime, try the following:

mkdir riscv-sifive && cd riscv-sifive
repo init -u git://github.com/sifive/meta-sifive -b master -m tools/manifests/sifive.xml
repo sync

More instructions are at the following URLs:


Thanks, I realized that I was using an older version of OpenEmbedded-based Freedom-U SDK (20because I was just following the docs from the freedom-u-sdk repo, which don’t include syncing from master, but an older version.

Now that I am on a newer kernel (5.5.7), I still don’t see any spidev devices in /dev

Is this something I need to include in the DTS file? in:
build/tmp-glibc/work-shared/freedom-u540/kernel-source/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts

or in:

build/tmp-glibc/work/x86_64-linux/u-boot-tools-native/1_2020.01-r0/git/arch/riscv/dts/fu540-c000.dtsi ?

Is this something I need to include in the DTS file? in:

Yes. You need to enable CONFIG_SPI_SPIDEV=y to get the user space devices, then assign them to that driver in the device tree.

For example set the following in the hifive-unleashed-a00.dts to assign qspi1:

&qspi1 {
        status = "okay";
        spidev1: spi@0 {
                compatible = "spidev";
                reg = <0>;
                spi-max-frequency = <50000000>;
        };
};

This gets you

crw------- 1 root root 153, 0 Dec 15 10:47 /dev/spidev1.0

Note that qspi0 and qspi2 are already in use for the SPI NOR and MMC respectively on the unleashed board.

Thank you! This worked great! I do see this in boot messages:
[ 1.738367] /soc/spi@10041000/spi@0: buggy DT: spidev listed directly in DT

but otherwise it seems to be working great!

Would I be able to pick any other GPIO pins to act as other CS pins (for connecting multiple devices to this bus)?