flen is the FP register size. So gdb is telling you that the bbl binary was compiled for a target with 64-bit FP (e.g. lp64d), but the hardware target has no FP registers (e.g. rv64imac). Gdb can’t properly communicate with a target if gdb thinks the FP register size is different than the target FP register size. Also, gdb thinks that the code won’t run on the target.
If your target really doesn’t have FP registers, then try compiling bbl without FP instructions, e.g. using -mabi=lp64 instead of -mabi=lp64d. If your target does have FP registers, then there is something wrong on the target side. I don’t know how this stuff works when using an fpga board, unless perhaps you are using openocd, in which case you might have the wrong openocd configuration file.
Also check your gdb version. FSF gdb 8.3 released last weekend is the first FSF gdb release with proper RISC-V support, though the github.com riscv-gnu-toolchain has had working support since about November.
Although I can’t load symbols but I’ve tested bbl using UART. And I’ve found some issues.
One of those are related to toolchain.
When I use a FreedomStudio-4.7.2.2019-03/SiFive/toolchain/riscv64-unknown-elf-gcc-8.2.0-2019.02.0/bin/riscv64-unknown-elf-gcc, I can see sifive logo through minicom. However, when I use riscv64-buildroot-linux-gnu-gcc that is a result of buildroot, I can’t see any log from minicom.
The other is write_csr(mcounteren, -1) in mstatus_init(). As the code is executed, I got the following messages.
/home/cmlee/Workspace/SiFive/freedom-u-sdk/riscv-pk/machine/mtrap.c:21: machine mode: unhandlable trap 2 @ 0x0000000080001e34
Power off.
In summary, I found out why bbl didn’t work well. That was because uninitialized variables. (i.e. bss)
I think bss area should be clear but I can’t find it in riscv-pk.
I would expect that the code that loads bbl into memory would clear the bss as part of that operation. If you look at the program headers of the ELF file you will see
The difference between the filesz and the memsz is the bss. The loader is supposed to copy filesz bytes from the ELF file, and then zero the rest of the bytes up to memsz. You can use objdump or readelf to look at the program headers. I don’t know how booting works on an FPGA, so I don’t know the details here though.
Alternatively, if bss isn’t being cleared, then you can do it manually. There should be symbols _bss_start and _end in the program. You can add a loop at the beginning of the program to store zeroes from _bss_start to _end to clear bss. This needs to be done as early as possible. An embedded system with no boot loader would do this in _start before jumping to main, but you might be able to do it in main if _start doesn’t do much.
Since bbl is essentially a kernel, it might be clearing memory itself some other way. I’ve never looked at the details of how bbl works.
Thanks.
I’ve already done as you say. I did memset(&_bss_start, 0, &_bss_end - &_bss_start) as soon as entering init_first_hart(). I’m loading bbl using gdb over openocd.
In my case, uart global variable is not initialized to zero. (0xfffffffff) So it couldn’t pass below code.
To boot linux, bbl should be compiled with --with-payload ?
I’ve loaded dtb, vmlinux.bin to dram using openocd and then loading bbl using gdb.
So, I’ve hardcoded some variables; kernel_start, kernel_end, dtb location in bbl.
I’ve stuck in enter_supervisor_mode. I can’t go next step that is linux-kernel.
Kernel panic - not syncing: 4RISC-V system with no 'timebase-frequency' in DTS
There is something wrong. timebase-freqeuncy exists in bbl but after kernel booting, it disappears.
I’ve printed all fdt in kernel. I can’t find “timebase-freqeuncy”.
When I tested bbl and linux on qemu, it works well. “timebase-frequency” exists.
What is the “name = name” in kernel log ?
device tree dump in linux
[ 0.000000] [__of_find_property:211] name = next-level-cache
[ 0.000000] [__of_find_property:211] name = reg
[ 0.000000] [__of_find_property:211] name = riscv,isa
[ 0.000000] [__of_find_property:211] name = status
[ 0.000000] [__of_find_property:211] name = clock-frequency
[ 0.000000] [__of_find_property:211] name = compatible
[ 0.000000] [__of_find_property:211] name = d-cache-block-size
[ 0.000000] [__of_find_property:211] name = d-cache-sets
[ 0.000000] [__of_find_property:211] name = d-cache-size
[ 0.000000] [__of_find_property:211] name = d-tlb-sets
[ 0.000000] [__of_find_property:211] name = d-tlb-size
[ 0.000000] [__of_find_property:211] name = device_type
[ 0.000000] [__of_find_property:211] name = i-cache-block-size
[ 0.000000] [__of_find_property:211] name = i-cache-sets
[ 0.000000] [__of_find_property:211] name = i-cache-size
[ 0.000000] [__of_find_property:211] name = i-tlb-sets
[ 0.000000] [__of_find_property:211] name = i-tlb-size
[ 0.000000] [__of_find_property:211] name = mmu-type
[ 0.000000] [__of_find_property:211] name = next-level-cache
[ 0.000000] [__of_find_property:211] name = reg
[ 0.000000] [__of_find_property:211] name = riscv,isa
[ 0.000000] plic: mapped 1 interrupts to 1 (out of 2) handlers.
[ 0.000000] [time_init:28] cpu = (____ptrval____)
[ 0.000000] [__of_find_property:211] name = #address-cells
[ 0.000000] [__of_find_property:211] name = #size-cells
[ 0.000000] [__of_find_property:211] name = name
[ 0.000000] [time_init:31] ret = -22
[ 0.000000] Kernel panic - not syncing: 4RISC-V system with no 'timebase-frequency' in DTS
Consider rebuilding BBL with the --enable-print-device-tree flag provided to “configure”, and observing the DT printed during early boot. That might help determine what to do next.
time->timebase-freqeuncy is located in “cpu”, not its parent “cpus”
But I can see cpu = of_find_node_by_path("/cpus"); in arch/riscv/kerne/time.c.
Is this enough ?
Does it need a function to find child cpu such as for_each_available_child_of_node(parent, child) ?
[ 0.000000] [__of_find_property:213] cpu[18]->timebase-frequency
[ 0.000000] [__of_find_property:213] cpu[19]->tlb-split
[ 0.000000] [__of_find_property:213] cpu[20]->name
[ 0.000000] [__of_find_property:221] cpu->nr_prop = 21
[ 0.000000] plic: mapped 1 interrupts to 1 (out of 2) handlers.
[ 0.000000] [time_init:28] cpu = (____ptrval____)
[ 0.000000] [__of_find_property:211] cpus->properties = (____ptrval____)
[ 0.000000] [__of_find_property:213] cpus[0]->#address-cells
[ 0.000000] [__of_find_property:213] cpus[1]->#size-cells
[ 0.000000] [__of_find_property:213] cpus[2]->name
[ 0.000000] [__of_find_property:221] cpus->nr_prop = 3
[ 0.000000] [time_init:31] ret = -22
[ 0.000000] Kernel panic - not syncing: 4RISC-V system with no 'timebase-frequency' in DTS
[ 0.000000]
That is perhaps just a serial console issue, and the boot did succeed, you just don’t have a working serial console. If you have an ethernet device, trying pinging it. The “Console: colour dummy device 80x25” suggests that it might be trying to use a video device as the console. If you have pci, try plugging in a video card and attaching a monitor. Otherwise, try disabling video terminal stuff in the linux defconfig file. And check CONFIG_HVC_RISCV_SBI=y, try defining it if it isn’t defined, or undefining it if it is defined, as this one is known to be an issue for some hardware/simulators.
I’ve added “console=ttyS0” to cmd_line. After that, the message “bootconsole[early0] disable” retreated.
But no more progress.
I’ll try your suggestion; “CONFIG_HVC_RISCV_SBI=y”.
~ snip ~
[ 1.590000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 1.610000] 20000000.serial: ttySIF0 at MMIO 0x20000000 (irq = 1, base_baud = 0) is a sifive-serial
~ snip ~
[ 2.140000] Key type dns_resolver registered
[ 2.150000] bootconsole [early0] uses init memory and must be disabled even before the real one is ready
[ 2.160000] bootconsole [early0] disabled
I’m sorry there is no effect for HVC_RISCV_SBI in my case.
I just have a uart on my fpga. There are no any devices such as video, ethern and pci etc.
Not yet enabled correctly speaking. Very minimal h/w configuration.
Could you check my dts file and kernel log for uart?