Building Custom Boot-able Linux for Hifive Unleashed - U540

I’m trying to build a boot-able custom Linux for Sifive Hifive Unleashed.

Here is what I did:

Got riscv linux from
Got GNU tool chain from
Followed instruction in RISC-V GNU compiler Toolchain in riscv-gnu-toolchain and built GNU cross-compiler.
Built riscv linux on X86 amd64 Ubuntu 16.04 host machine using generated GNU cross-compiler.
Other than configuring the linux to include my driver as built in (not as module) which was some work, I was able to build the linux and have vmlinux and everything else.

I want to build boot-able image out of this linux and create file system so I can boot Hifive with SD card. I downloaded SiFive U Freedem SDK to get the boot loader builder and other tools that are needed to create bbl.bin.
If I follow the instruction on GitHub Sifive freedom-u-sdk it clones every thing including linux and configure it for busybox. So bbl.bin generated is not with the linux I have. I tried to replace the linux with my version, but make fails each time I tried.

My question is, how can I replace the linux in U Freedom SDK and build boot-able image off of my version of linux?

In you look in the toplevel Makefile, you will see a command like this

	cd $(pk_wrkdir) && $</configure \
                --host=$(target) \
	        --with-payload=$(vmlinux_stripped) \
                --enable-logo \
                --with-logo=$(abspath conf/sifive_logo.txt)

Replacing $(vmlinux_stripped) with your linux kernel binary, and rebuilding bbl should work. You can “rm -rf work/riscv-pk” to force it to rebuild.

You need to be careful with alternate kernels, because not all patches needed for the Unleashed board are upstream yet. It looks like the default riscv/riscv-linux branch is 4.19. If that is the same as the upstream 4.19, then it will boot on qemu, but not on the unleashed, because drivers are missing. You might need the riscv-all branch to get a kernel that boots on the unleashed.

1 Like

If that is the same as the upstream 4.19, then it will boot on qemu, but not on the unleashed

I wasn’t aware that is still the case, thought all the unleashed drivers were upstream.
Is there a site or issue keeping track of what drivers need to land in upstream before the SiFive Unleashed board can boot from it?

I’m not actively tracking linux kernel development, but I think they are shooting for 4.20 or 4.21 to get enough drivers to boot on the SiFive Unleashed hardware. You could try asking on the linux-riscv mailing list.

1 Like

Thanks for your reply.

I have change top level Makefile as follow:

$(bbl): $(pk_srcdir) $(vmlinux_stripped) <-- Changing this line seems doesn’t have affect
rm -rf $(pk_wrkdir)
mkdir -p $(pk_wrkdir)
cd $(pk_wrkdir) && $</configure
–with-payload=$(vmlinux) \ <— Changed this line
–with-logo=$(abspath conf/sifive_logo.txt)

I do not have vmlinux_stripped in my linux build.

make still gives error:

make -C /root/sifive/freedom-u-sdk/linux O=/root/sifive/freedom-u-sdk/work/linux
CONFIG_INITRAMFS_SOURCE="/root/sifive/freedom-u-sdk/conf/initramfs.txt /root/sifive/freedom-u-sdk/work/buildroot_initramfs_sysroot"
make[1]: Entering directory '/root/sifive/freedom-u-sdk/linux’
make[2]: Entering directory '/root/sifive/freedom-u-sdk/work/linux’
YACC scripts/kconfig/
/bin/sh: 1: -oscripts/kconfig/ not found
scripts/Makefile.lib:196: recipe for target ‘scripts/kconfig/’ failed
make[4]: *** [scripts/kconfig/] Error 127
/root/sifive/freedom-u-sdk/linux/Makefile:504: recipe for target ‘silentoldconfig’ failed
make[3]: *** [silentoldconfig] Error 2
make[2]: *** No rule to make target ‘include/config/auto.conf’, needed by ‘include/config/kernel.release’. Stop.
make[2]: Leaving directory '/root/sifive/freedom-u-sdk/work/linux’
Makefile:146: recipe for target ‘sub-make’ failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/root/sifive/freedom-u-sdk/linux’
Makefile:135: recipe for target ‘/root/sifive/freedom-u-sdk/work/linux/vmlinux’ failed
make: *** [/root/sifive/freedom-u-sdk/work/linux/vmlinux] Error 2 exist in : /root/sifive/freedom-u-sdk/work/linux/scripts/kconfig

/root/sifive/freedom-u-sdk/work/linux/scripts/kconfig# ls
conf* kconf_id.c nconf* qconf.h
conf.c list.h nconf.c*
confdata.c lkc.h symbol.c
conf.o lkc_proto.h nconf.gui.c tests/
expr.c lxdialog/ nconf.gui.o util.c
expr.h Makefile nconf.h zconf.l
gconf.c mconf.c nconf.o zconf.lex.c** preprocess.c menu.c
images.c** zconf.y

Please advise,

$(bbl): $(pk_srcdir) $(vmlinux_stripped) <-- Changing this line seems doesn’t have affect

This line lists dependencies. It means that vmlinux_stripped must be built before bbl can be built. Since you didn’t change it, that means we must build a linux kernel locally before we can build bbl. Your build will go faster if you change this line too, and if you use “make bbl” to just build bbl.

YACC scripts/kconfig/
/bin/sh: 1: -oscripts/kconfig/ not found

Despite the YACC reference, this should be trying to run bison. You can see the full build command that failed by using “make V=1”. Since you got a shell error, not a bison error, it looks like you might have an alias for bison, that maybe points to a broken shell script. What does the command “which bison” say?

Thanks Jim for reply.
Actually I was able to build bbl, but as you suspected it didn’t boot from SD card.
Any advise?

“didn’t boot” isn’t very descriptive. I’d need more info to say anything useful. If you did give me more info, I still might not be able to help, as I’m not a kernel expert. If you aren’t a RISC-V linux kernel hacker, then you should probably stick to kernels that are known to work for now, until everything is upstream.

Fedora incidentally is now using a 4.20 kernel. I don’t know if they have any extra patches added though, and I haven’t tried it yet. I don’t know know if they have tested it on the HiFive Unleashed, but it works in qemu. See for instance

Hi Jim,
There was nothing on the serial terminal output. Micro usb green light blinks couple times and stays green (the light next to micro usb connector on HiFive Unleashed).
I’m not consider myself a linux kernel hacker what so ever, I just simply want to be able to load kernel driver for my device which are upstream. They are by default in riscv linux defined as module and loadable module is not supported. That’s why I’m trying to build the kernel with my driver built-in.

Thank you for the Fedora link.
Do you know if kernel loadable module supported in Fedora for HiFive Unleashed? Meaning, can one load kernel drivers (modprobe, insmod and such commands work)?

I’m not a linux kernel hacker either. Nothing on the serial console means I have no idea what to do about that, except maybe wonder if it is a serial driver problem, and wonder if maybe you can ping the board and ssh in if the ethernet driver is working. I build my own kernels for gdb work, but I start with known working kernels, 4.15 based at the moment, and if something goes wrong I know it is my patch that is the problem.

I haven’t tried the latest Fedora image on hardware yet. I will try that this weekend. I have it running on qemu. I assume lsmod working implies that kernel loadable modules work. Otherwise I don’t know how to tell if kernel loadable modules are working.

[jimw@fedora-riscv ~]$ lsmod
Module Size Used by
ip6t_rpfilter 12100 1
ebtable_nat 5447 1
ip6table_security 5996 1
iptable_security 5903 1
ip_set 309643 0
nfnetlink 63216 1 ip_set
ebtable_filter 5467 1
ebtables 188406 2 ebtable_nat,ebtable_filter
[jimw@fedora-riscv ~]$ uname -a
Linux fedora-riscv 4.20.0-0.rc1.git1.1.1.riscv64.fc29.riscv64 #1 SMP Thu Nov 8 20:44:01 UTC 2018 riscv64 riscv64 riscv64 GNU/Linux
[jimw@fedora-riscv ~]$

Speaking of Fedora’s Linux-4.20, I haven’t been able to connect to

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox may only connect to it securely. As a result, it is not possible to add an exception for this certificate.

This doesn’t appear to have anything to do with the previous discussion. New threads for new problems please.

The Fedora guys are aware of the problem, but don’t know how to fix it. The hosting site added the HSTS header not the Fedora guys. They suggest using the IP address as a workaround, e.g.