undefined reference to `__libc_detect_null'

[andreas-schwab]

The function __libc_detect_null is not defined anywhere.

gcc -I. -O2 -ggdb -march=rv64imafdc -mabi=lp64d -Wall -mcmodel=medany -mexplicit-relocs -nostdlib -nostartfiles -o fsbl.elf fsbl/start.o fsbl/main.o spi/spi.o uart/uart.o lib/version.o ememoryotp/ememoryotp.o fsbl/ux00boot.o clkutils/clkutils.o gpt/gpt.o fdt/fdt.o sd/sd.o lib/memcpy.o lib/memset.o lib/strcmp.o lib/strlen.o fsbl/dtb.o -Tux00_fsbl.lds
/usr/lib64/gcc/riscv64-suse-linux/8/../../../../riscv64-suse-linux/bin/ld: lib/strlen.o: in function strlen': /suse/schwab/src/riscv/sifive/freedom-u540-c000-bootloader/lib/strlen.c:38: undefined reference to __libc_detect_null'
collect2: error: ld returned 1 exit status

[jim-wilson]

You can find it in newlib/libc/machine/riscv/sys/string.h. So it appears that it will compile with an embedded elf compiler using newlib, but not a linux compiler. The files in the lib dir all appear remarkably similar to the ones in newlib/libc/machine/riscv, so either they were borrowed from newlib, or they have a common ancestor.

It looks like we could fix this by copying the missing function from newlib into freedom-u540-c000-bootloader, but we might have to rename it to avoid conflicts with a newlib based embedded elf compiler. Or maybe we could fix this by forcing use of newlib headers somehow.

I don't know if anyone is actively maintaining this tree. There are no commits since Sept 2018. Bootloader code probably doesn't need a lot of changes once it is working though.

[andreas-schwab]

How else can you fix the DTS? Kernel drivers are failing to work with the embedded device tree.

[jim-wilson]

I'm not a kernel hacker and don't know anything about kernel driver problems in general.

I do know that we have started using u-boot in house. I think this somehow allows one to specify an alternate DTS, perhaps by replacing the FSBL with u-boot. Using u-boot requires flipping one of the boot select switches to boot from the SDcard. With the red power switch on the left, the second switch from the bottom must be slid to the right. So maybe with u-boot working we don't need updates to the FSBL anymore?

The u-boot tree we are using is at
https://github.com/tmagik/HiFive_U-Boot
I haven't tried building this myself. We also have a freedom-u-sdk update in progress
sifive/freedom-u-sdk#88
but last I tried this it wasn't working because a compiler change meant that u-boot didn't fit in its sdcard partition anymore. This tree has never actually worked on hardware for me. And there is an alpha release at
https://github.com/tmagik/freedom-u-sdk/releases
but when I tried this it didn't work for me on hardware either. uboot ran, but the kernel didn't mount the root filesystem and dropped into busybox.

So unfortunately, we don't have anything in a releasable form at the moment, and I'm not a kernel hacker so I don't know exactly what is going on in this area.

There is one kernel driver problem I know about, and that applies only if you have the Microsemi expansion board for the HiFive Unleashed. The built-in FSBL doesn't have a DTS entry for the Microsemi PCIe support. I use the solution Atish Patra developed which modifies bbl to allow dynamically adding DTS entries. This can be found at
https://github.com/westerndigitalcorporation/RISC-V-Linux
but I think this is obsoleted by the u-boot stuff, which I haven't actually switched to yet.

[andreas-schwab]

The upstream U-Boot does not support replacing FSBL, it is started by BBL or openSBI.

[paul-walmsley-sifive]

If the reported issue here is the error message "undefined reference to `__libc_detect_null'", then as Jim wrote, that can be resolved by using the correct compiler. Please try using the compiler built with crosstool-ng with the "riscv64-unknown-elf" sample configuration:

https://github.com/crosstool-ng/crosstool-ng

Certainly, this is not appropriately documented. This is in keeping with the spirit of the rest of this repository ;-)

[jim-wilson]

We are discussing DTS problems now. Andreas wanted to build FSBL to fix the DTS, but I'm saying that u-boot provides its own DTS and hence a FSBL fix should not be necessary for that, and that we probably don't have any FSBL fixes for the DTS. But I don't know why the DTS is broken, other than for the microsemi expansion board.

[andreas-schwab]

U-Boot does not have its own DTS.

[paul-walmsley-sifive]

The comments on this issue are too confusing for me to figure out what the current problem is. If there is another problem with this repository beyond the compilation issue, could you guys open a separate issue?

[jim-wilson]

The u-boot I pointed at, the one we are using, has its own DTS.
https://github.com/tmagik/HiFive_U-Boot/blob/master/arch/riscv/dts/hifive_u540.dts

I think we are going in circles here. If you want a solution from SiFive, then you have to use our u-boot. If you don't want our u-boot, then you have to get a solution from someone else.

[paul-walmsley-sifive]

Some people at SiFive may be using that U-Boot & DTS file, but as far as I know, it's not a supported SiFive repository. It's probably mostly useful for older kernels. Mainline-oriented DTS files will be different.

[tmagik]

That U-boot and DTS file is what is going to get promoted to the next officially supported SiFive release. I would appreciate any pull requests for more mainline-oriented DTS files, along with working and tested kernel configs.

[tmagik]

@andreas-schwab https://github.com/tmagik/freedom-u-sdk/blob/dev/buildroot/conf/uEnv.txt allows you to specify an alternate device tree, and use either the one provided by U-boot, or the one in the FIT image, or you can modify the env and options to load a separate bbl, kernel, DTB, and initrd images either from a partition on the SDcard, or tftp/dhcp over the network.

[andreas-schwab]

I don't use buildroot, I'm using a real distribution.