search

litex-hub / linux-on-litex-rocket

Run 64-bit Linux on LiteX + RocketChip
BSD 2-Clause "Simplified" License
178 stars 18 forks source link

Repo status #39

Closed trabucayre closed 1 week ago

trabucayre commented 4 months ago

Hi, I'm trying to build and to use this repo with an lambdaconcept ECPIX5 and observe some issues:

(I have to open a PR to fix these issue).

But once everything build and a boot.bin copied into /tftpboot the boot fails with:

[    6.216838] Warning: unable to open an initial console.
[    6.347518] Freeing unused kernel image (initmem) memory: 2940K
[    6.370316] Run /init as init process
[    6.372968]   with arguments:
[    6.375888]     /init
[    6.378132]   with environment:
[    6.381900]     HOME=/
[    6.383620]     TERM=linux
[   10.012638] irq 12: nobody cared (try booting with the "irqpoll" option)
[   10.018386] CPU: 0 PID: 52 Comm: init Not tainted 6.8.0-rc7-g7c43225d93f6 #2
[   10.025350] Hardware name: freechips,rocketchip-unknown (DT)
[   10.031004] Call Trace:
[   10.033436] [<ffffffff800063d2>] dump_backtrace+0x1c/0x24
[   10.038832] [<ffffffff8051911e>] show_stack+0x2c/0x38
[   10.043856] [<ffffffff80520f86>] dump_stack_lvl+0x3c/0x54
[   10.049244] [<ffffffff80520fb2>] dump_stack+0x14/0x1c
[   10.054282] [<ffffffff8051a066>] __report_bad_irq+0x3e/0xae
[   10.059832] [<ffffffff80060238>] note_interrupt+0x232/0x278
[   10.065392] [<ffffffff8005d126>] handle_irq_event+0xb4/0xc0
[   10.070954] [<ffffffff80061182>] handle_fasteoi_irq+0x9c/0x264
[   10.076774] [<ffffffff8005c000>] generic_handle_domain_irq+0x1c/0x2a
[   10.083110] [<ffffffff80333b70>] plic_handle_irq+0x7e/0xf6
[   10.088582] [<ffffffff8005c000>] generic_handle_domain_irq+0x1c/0x2a
[   10.094912] [<ffffffff80333834>] riscv_intc_irq+0x2c/0x44
[   10.100302] [<ffffffff80521004>] handle_riscv_irq+0x4a/0x74
[   10.105856] [<ffffffff805299e2>] call_on_irq_stack+0x32/0x40
[   10.111508] handlers:
[   10.113756] [<(____ptrval____)>] liteuart_interrupt
[   10.118626] Disabling IRQ #12

Any idea? Thanks.

gsomlo commented 4 months ago

Hi, I'm trying to build and to use this repo with an lambdaconcept ECPIX5 and observe some issues:

* litex: `linuxq` must be replaced by `linux`, `linux4` by `linux --cpu-num-cores 4`

* busybox: `CONFIG_USE_BB_CRYPT` and `CONFIG_USE_BB_CRYPT_SHA` must be set (fix issue [build busybox : fatal error:crypt.h No such file #38](https://github.com/litex-hub/linux-on-litex-rocket/issues/38))

* linux: indeed `CONFIG_RISCV_SBI_V01` must be set

* riscv_pk: with recent toolchain `rv64imac` must be replaced by `rv64i2p0_mac`

(I have to open a PR to fix these issue).

Yeah, that changed with https://github.com/enjoy-digital/litex/commit/c3e93620 and the corresponding https://github.com/litex-hub/pythondata-cpu-rocket/commit/ef6cf0a -- the variant naming scheme was getting a bit out of hand, and I felt I had to do something to get it back under control :)

But once everything build and a boot.bin copied into /tftpboot the boot fails with: ... Any idea? Thanks.

The *.dts files are likely also out of date, and so is everything related to using BBL.

Here's the current DTS files I'm using:

Once you've compiled them into dtb files (dtc -O dtb foo.dts -o foo.dtb), use them to build an opensbi firmware "blob":

git clone https://github.com/riscv-software-src/opensbi.git
cd opensbi
rm -rf build; make CROSS_COMPILE=riscv64-unknown-linux-gnu- PLATFORM=generic FW_FDT_PATH=/path/to/foo.dtb FW_JUMP_FDT_ADDR=0x82400000
cp build/platform/generic/firmware/fw_jump.bin /litex/boot/folder/

Note the FW_JUMP_FDT_ADDR which forces the DTB to be relocated in a way that doesn't have it stomp all over the kernel (learned that the hard way, see https://github.com/riscv-software-src/opensbi/commit/ee016a7)

My ECPIX5 build command is

litex-boards/litex_boards/targets/lambdaconcept_ecpix5.py --build \\
    --cpu-type rocket --cpu-variant linux --cpu-num-cores 1 --cpu-mem-width 2 --sys-clk-freq 50e6 \\
    --with-ethernet --with-sdcard --yosys-flow3 --nextpnr-timingstrict

The nexys-video command:

litex-boards/litex_boards/targets/digilent_nexys_video.py --build \\
    --cpu-type rocket --cpu-variant linux --cpu-num-cores 4 --cpu-mem-width 2 --sys-clk-freq 50e6 \\
    --with-ethernet --with-sdcard --with-sata --sata-gen 1

And, finally, my boot.json file (in /var/lib/tftpboot, but could be on the sdcard, or wherever you're booting from):

{
    "initrd_bb":   "0x82000000",
    "Image":       "0x80200000",
    "fw_jump.bin": "0x80000000"
}

HTH, and LMK if you need me to elaborate on any of the details :)

gsomlo commented 4 months ago

what we could really use is a programmatic way to "cut'n'paste" relevant cpu related bits and pieces from the elaborated rocket-chip sample .dts files in pythondata-cpu-rocket/generated-src into the output generated by litex_json2dts, and that would prevent this (linux-on-litex-rocket) repo from going stale in the first place... :)

Note that hard-coding rocket-cpu related properties in the litex json2dts generator is probably still suboptimal, as the cpu string (and other values) in dts change as the upstream rocket sources evolve, and we'd be back to having to "keep up" with something again...

trabucayre commented 4 months ago

Thanks for your answers! I will try it in this way. I observe with ecpix5 timings not met with pythondata-cpu-rocket HEAD, and a file is missing with the hash you mention. For dts: yes a compromise must be found between a wrong/partial dts and a too much hardcoded/hard to maintain solution.

gsomlo commented 4 months ago

I observe with ecpix5 timings not met with pythondata-cpu-rocket HEAD,

nextpnr is known to be a bit "pessimistic" with timing, so if you get $glbnet$sdrio_clk over 47MHz you "should" be OK :) If I want to be stubborn about it, I follow that up with:

cd build/lambdaconcept_ecpix5/gateware
while true; do
  nextpnr-ecp5 --json lambdaconcept_ecpix5.json --lpf lambdaconcept_ecpix5.lpf \
      --textcfg lambdaconcept_ecpix5.config --um5g-85k --package CABGA554 --speed 8 \
      --seed $RANDOM
  [ "$?" == "0" ] && break
done 2>&1 | grep 'Max frequency for clock'
ecppack --bootaddr 0 lambdaconcept_ecpix5.config --svf lambdaconcept_ecpix5.svf

and I end up with a fully timing compliant bitstream within a day or two (running in a VM on top of a 2012 era xeon server, FWIW) There's probably a "smarter" way to accomplish the same goal, but I haven't done a deep dive into studying nextpnr's fancier set of flags and options...

and a file is missing with the hash you mention.

Not sure what you mean by that, sorry. Can you please clarify, assuming there's something within my power to fix? :)

gsomlo commented 1 week ago

closing since last I remember this worked :) @trabucayre please re-open if somehow there's still something we need to do about this issue.