Unable to simulate loader chain binaries (zsl.rom.elf, fw_payload.bin, linux.vcu128.gpt.bin)

[HepoH3]

Description

I'm exploring the Cheshire simulation environment and successfully ran the helloworld.spm.elf example. However, when I attempt to simulate any of the loader‐chain binaries (e.g. zsl.rom.elf, fw_payload.elf, fw_payload.bin, linux.vcu128.gpt.bin), the simulation fails with different errors.

I suspect I might be misconfiguring environment variables or misunderstanding the expected boot modes.

Environment

• Project version: v0.3.0 tag
• Simulator: QuestaSim (version 2024.1)
• Binaries under test:
  • zsl.rom.elf
  • fw_payload.elf / fw_payload.bin (OpenSBI + U‑Boot)
  • linux.vcu128.gpt.bin (full SD‑card image)

Steps to Reproduce

cd to target/sim/vsim folder
start vsim
# set BOOTMODE, PRELMODE, BINARY/IMAGE variables
source start.cheshire_soc.tcl
run -all

Variables values to simulate zsl.rom.elf via JTAG:

set BOOTMODE 0
set PRELMODE 0
set BINARY path/to/zsl.rom.elf

Variables values to simulate fw_payload.bin from SD‑card image:

set BOOTMODE 1
set IMAGE path/to/fw_payload.bin

Variables values to simulate fw_payload.elf via JTAG:

set BOOTMODE 0
set PRELMODE 0
set BINARY path/to/fw_payload.elf

Variables values to simulate Linux from SD‑card image:

set BOOTMODE 1
set IMAGE path/to/linux.vcu128.gpt.bin

Observed Behavior

• zsl.rom.elf:

  [ELF] INFO: Entrypoint at 0x10000000
  [ELF] WARNING: Section at 0x0 has 16 zero bytes not preloaded.
  # [TRACER] Output filename is: trace_hart_0.log
  # [JTAG] Initialization success
  # [JTAG] Wait for LLC configuration
  # [JTAG] Halted hart 0
  # [JTAG] Preloading ELF binary: ../../../sw/boot/zsl.rom.elf
  # [JTAG] Preloading section at 0x0000000000000000 (7328 bytes)
  # [JTAG] - 512/7328 bytes (6%)
  # ** Fatal: [JTAG] Abstract command error!
  

• fw_payload.bin & linux.vcu128.gpt.bin:

  ** Warning: Illegal character '' in data on line 1 of file .../fw_payload.bin / linux.vcu128.gpt.bin
  ...
  ** Fatal: Unsupported boot mode 1 (SD Card)!
  

• fw_payload.elf via JTAG:

  [ELF] INFO: Entrypoint at 0x80000000
  [ELF] WARNING: Section at 0x80000000 has 135216 zero bytes not preloaded.
  # [TRACER] Output filename is: trace_hart_0.log
  # [JTAG] Initialization success
  # [JTAG] Wait for LLC configuration
  # [JTAG] Halted hart 0
  # [JTAG] Preloading ELF binary: ../../../sw/boot/fw_payload.elf
  # [JTAG] Preloading section at 0x0000000080000000 (213928 bytes)
  # [JTAG] - 512/213928 bytes (0%)
  # ...
  # [JTAG] - 213504/213928 bytes (99%)
  # [JTAG] Preloading section at 0x0000000080200000 (415800 bytes)
  # [JTAG] - 512/415800 bytes (0%)
  # ...
  # [JTAG] - 415744/415800 bytes (99%)
  # [JTAG] Preload complete
  # [JTAG] Resumed hart 0 from 0x0000000080000000
  
  # ** Warning:           1[l1 dcache] reading invalid data on port 1: data=0000000000000000
  #    Time: 151418085 ns Started: 151418085 ns
  # Scope:
  # tb_cheshire_soc.fix.dut.gen_cva6_cores[0].i_core_cva6.gen_cache_wb.i_cache_subsystem.genblk1[1].a_invalid_read_data
  # File: cheshire/.bender/git/checkouts/cva6-20c9d7cbe0dd6995/core/cache_subsystem/std_cache_subsystem.sv Line: 318
  
  # ...
  
  # ** Warning: Got unknown value in one of the operands
  #    Time: 151418460 ns Started: 151418460 ns
  # Scope: tb_cheshire_soc.fix.dut.gen_cva6_cores[0].i_core_cva6.issue_stage_i.i_issue_read_operands
  # File: cheshire/.bender/git/checkouts/cva6-20c9d7cbe0dd6995/core/issue_read_operands.sv Line: 640
  

Expected Behavior

zsl.rom.elf should preload successfully without JTAG errors.

fw_payload.bin / linux.vcu128.gpt.bin should be accepted by the SD‑card loader (boot mode 1).

fw_payload.elf correct payload code should execute.

Questions & Next Steps

• Am I using the correct values for BOOTMODE and PRELMODE for each binary type?
• Are there additional simulator flags or scripts required to support SD‑card boot (mode 1)?
• Did I miss something in Simulation and Software Stack guidelines?

I appreciate any pointers or suggestions!

[paulsc96]

Hi,

First of all, thanks for the thorough issue.

You are running into a combination of unimplemented features and unclear documentation.

Booting from SD card

Sadly, this is not implemented in simulation (we test SD cards on FPGA boards). The reason is that could not yet find a publicly available SD card model people in charge are comfortable adding to our setup (license concerns).

If you still want to use the boot chain in simulation, you can use the SPI flash instead.

However, Since this may take a long time in Questasim, you may want to get an FPGA board or work toward a fast Verilator setup (see also #180 and #182).

Preloading zsl.rom.elf

The ROM-linked ELF files are not intended for preloading; they are an intermediary file used to create raw disk images (zsl.rom.bin). These raw images contain a single contiguous code section that should be copied to the SPM base before execution (usually done by the boot ROM).

As you can tell, if you do preload them, the load address is 0x0, since this is where they go in a disk image (right at the beginning). However, this will not work when preloading through JTAG, since that is not where the SPM is.

If you want to simulate ROMs, you can use a non-passive boot mode (e.g. 2 for SPI Flash) and pass an actual .rom.bin file to be preloaded into the external memory (Flash, EEPROM) models:

set BOOTMODE 2
set IMAGE path/to/zsl.rom.elf

Booting fw_payload.bin directly

This is the OpenSBI image with U-boot as its payload.

Since OpenSBI requires a a more advanced environment than directly bootable images (a preloaded device tree, DRAM access, and entry by all harts), the boot ROM cannot directly load it.

This is why we chain-load OpenSBI using the ZSL; see the ZSL's source for details.

A note on linux.vcu128.gpt.bin

While it is not very important at this stage, this image contains the device tree for the VCU128 FPGA board. In principle, there should also be one for use in simulation. However, in practice, we never boot Linux in simulation due to the prohibitive time it would take.

[paulsc96]

I actually just saw that I overlooked one case.

Preloading fw_payload.elf

This one can be made to work, but some legwork is required.

The simulation complains about uninitialized memory / state. This is because we didn't pass the arguments OpenSBI expects:

• a0: The hart ID (assuming a single core system, can be set to 0)
• a1: The address of the device tree blob in memory

Setting these (and, as a prerequisite, also loading the device tree into DRAM) is something the ZSL does for us when it chainloads OpenSBI.

You could take the scenic route and figure out how to set these registers through JTAG in simulation, but it is simpler to just load the ZSL. In fact, in boot mode 0, the ZSL skips any image loading from disk. Therefore, you can just:

• Preload OpenSBI (fw_payload.elf)
• Preload the device tree (no existing solution for this, probably easiest to convert it to a .memh file and use $readmemh)
• Preload and then execute the ZSL ( zsl.spm.elf)

That should launch OpenSBI and its payload (by default, U-boot). U-boot defaults on loading a linux image from Flash or SD card.

If you really want to boot Linux in simulation, I would reconfigure OpenSBI to chainload Linux. But then again, this is really not worth the time it takes to simulate unless you are chasing a horrifying bug that needs full introspection.

[HepoH3]

@paulsc96, thank you very much! I will definitely try to apply your advice soon!
Actually, my goal is not to boot Linux all the way through during the simulation. The thing is, I will need to test my own core as part of the Cheshire SoC in the future. This core has some peculiarities related to virtual memory, so problems may arise when trying to boot Linux.

At this stage, I'll be happy if I can at least boot into OpenSBI/U-Boot, and then attempt to load Linux. Even if I see just the first line of the Linux boot process — that will already be a big success, and from there I can start trying to boot on FPGA.

[paulsc96]

👍 Closing for now; feel free to reopen if needed.

[HepoH3]

For those who come after, here are the steps to simulate the Zero Stage Loader (ZSL).

First, you'll need a memory file that contains the code. Although it could be referred to as a "binary", you should not use .bin or .gpt binary files. Instead, you'll need a text file that can be used with the $readmemh call (or at least that's what worked for me during simulation).

To generate it, simply run make sw/boot/zsl.rom.memh from the CHS_ROOT directory. It will compile the zsl.rom.elf file and export code and data sections into zsl.rom.memh.

Then, as described in the Simulation manual, start the simulator, set:

• BOOTMODE to 2,
• IMAGE to the path of zsl.rom.memh,

and run the simulation.

The ZSL message should appear during the simulation, though it may take some time:

# [UART]  /\___/\       Boot mode:       2
# [UART] ( o   o )      Real-time clock: 32768 Hz
# [UART] (  =^=  )      System clock:    200033516 Hz
# [UART] (        )     Read global ptr: 0x02001abc
# [UART] (    P    )    Read pointer:    0x02000bdb
# [UART] (  U # L   )   Read argument:   0x1001ffb0
# [UART] (    P      )
# [UART] (           ))))))))))

I'm not sure whether this is expected behavior or not, but there are a lot of ASSERT FAILED messages and warnings in the unmodified repository between the lines:

# [UART] (    P      )

and

# [UART] (           ))))))))))

# ** Error: [ASSERT FAILED] [tb_cheshire_soc.fix.dut.gen_spi_host.i_spi_host.u_data_fifos.u_rx_fifo.Data
Known_A] DataKnown_A:  (cheshire/.bender/git/checkouts/opentitan_peripherals-b6ab
8aee295139a9/src/prim/rtl/prim_fifo_sync.sv:193)
#    Time: 51279250 ns Started: 51279250 ns  Scope: tb_cheshire_soc.fix.dut.gen_spi_host.i_spi_host.u_da
ta_fifos.u_rx_fifo.DataKnown_A File: cheshire/.bender/git/checkouts/opentitan_per
ipherals-b6ab8aee295139a9/src/prim/rtl/prim_fifo_sync.sv Line: 193
# ** Warning:           1[l1 dcache] writing invalid data: paddr=000000001001fd98, be=0f, data=xxxxxxxxx
xxxxxxx
#    Time: 51279575 ns Started: 51279575 ns  Scope: tb_cheshire_soc.fix.dut.gen_cva6_cores[0].i_core_cva
6.gen_cache_wb.i_cache_subsystem.a_invalid_write_data File: cheshire/.bender/git/
checkouts/cva6-412fee4648e8915c/core/cache_subsystem/std_cache_subsystem.sv Line: 303

---

@paulsc96, just a suggestion — have you considered committing the cheshire_bootrom.dump that corresponds to cheshire_bootrom.sv?

At the moment, it can be generated using the bootrom-all target, but that also recompiles and modifies cheshire_bootrom.sv, which (as I understand) isn't recommended unless necessary.

For anyone wanting to test changes in the processor and inspect the trace_log, having a disassembly is very helpful — but to use it properly, they'd need a matching bootrom disassembler, which currently requires regenerating cheshire_bootrom.sv.

[paulsc96]

Good to know you managed to simulate it 👍

Regarding the assertion failures: the way preloading works, any bytes not included in the .rom/.memh file will remain unknown ('x) in simulation. However, the ROM boot mode always loads a 48 KiB block, no matter how large the program is. Thus, 'x will be read by the SPI and caches in some places, causing them to complain. But since that data is never used, this should be benign.

As for the dump matching the upstream boot ROM, you can find it here:

cheshire_bootrom.dump.gz

The annoying part is that the full ELF path is contained, so dumps are not fully reproducible. But maybe I can add some scripting to remove the path and commit it that way.

[HepoH3]

I'm continuing to journaling my journey of using boot chain in simulation. At the moment, I'm trying to boot the fw_payload (OpenSBI + U-Boot) from the Zero Stage Loader (ZSL). To do this, I:

1. Compiled the DTB and exported it to a memh file. I'm not sure whether the DTB must be compiled for a specific platform (e.g., cheshire.vcu128.dts) or if it's sufficient to compile just cheshire.dtsi. Just in case, I tried both, but I believe using only the .dtsi is enough. The compilation is done with the following commands:

# Compile DTS to DTB:
dtc -I dts -O dtb -o cheshire.dtb cheshire.dtsi

# Convert DTB to memh with load address 0x80800000:
objcopy -I binary -O verilog --adjust-vma 0x80800000 cheshire.dtb cheshire_dtb.memh

The address 0x80800000 is taken from the macro __BOOT_ZSL_DTB in params.h.

2. Exported fw_payload to memh and appended the DTB to it:

objcopy -O verilog fw_payload.elf fw_payload.memh
cat cheshire_dtb.memh >> fw_payload.memh

Given the load address @80000000, the sections appear to be exported correctly.

Next, I had to initialize the main memory with this file. According to the simulation project hierarchy, the original repository uses axi_sim_mem instead of DRAMSys. To initialize this memory from the top-level module, one can add the following line at the beginning of the initial block:

$readmemh("fw_payload.memh", fix.vip.gen_no_dramsys.i_dram_sim_mem.mem);

After analyzing the ZSL code and simulation results, I decided to temporarily comment out the following section:

// If this is a GPT disk boot, load payload and device tree
if (read & 1) {
  rread = (gpt_read_t)(void *)(uintptr_t)(read & ~1);
  load_part_or_spin(priv, __BOOT_DTB_TYPE_GUID, __BOOT_ZSL_DTB, "device tree", 64);
  load_part_or_spin(priv, __BOOT_FW_TYPE_GUID, __BOOT_ZSL_FW, "firmware", 8192);
}

and recompile ZSL.

The reason I did this is that the read value (according to the ZSL code and simulation results) is 0x02000bdb, which has its least significant bit set to 1. This triggers the code block above, even though we are not supplying a GPT-formatted file to the simulator—we're initializing main memory directly via $readmemh. There might be a cleaner way to override this behavior (e.g., modifying the read value), but for now this seemed the most straightforward.

After this, I launched the simulation same way I did it to simulate ZSL:

set BOOTMODE 2
set IMAGE zsl.rom.memh

However, during simulation, several assertions are triggered repeatedly:

1. a_invalid_write_data and a_invalid_read_data in core/cache_subsystem/std_cache_subsystem.sv;
2. full_write in bus_err_unit_bare.sv.

To preserve UART output, I temporarily commented out these assertions.

According to PC addresses in trace_hart_0, the payload begins executing successfully, but the UART output appears to be corrupted or garbled binary data:

[TRACER] Output filename is: trace_hart_0.log
# [JTAG] Initialization success
# [UART]  /\___/\       Boot mode:       2
# [UART] ( o   o )      Real-time clock: 32768 Hz
# [UART] (  =^=  )      System clock:    199960418 Hz
# [UART] (        )     Read global ptr: 0x02001abc
# [UART] (    P    )    Read pointer:    0x02000bdb
# [UART] (  U # L   )   Read argument:   0x1001ffb0
# [UART] (    P      )
# [UART] (           ))))))))))
# [UART]
# [UART] [ZSL] Launch firmware at 80000000 with device tree at 80800000
# [UART] "ë     §☻]4♠♠♠♠]÷/ï-G$♠♠♠♠Gï▲7]=♥è↔^,÷^4â☼F▼<$¯÷àFNF7è°¯▲è/Fõ袮ÿ_p®öîoëíïh♥FN♠♠«É♫Ë ☼♠♠♠­ª
)/♫Ë ☼♠♠=¯ôG♂¶ ♥♠ª£
# [UART] £
# ♥♠j£¸☻¨ªW♥FVè¯À♠T9/£ú☼£
# Â☼Ȩ*∟j♥FNȨG☼FNȨ
# [UART] ë ÀNXê-♥♠♠♠♠♠NE 
# ♥♠♠
#ÉG$Ç/♠F♫H®ÊUh♥♠♠­/®Ê]Q♫♠♠®▬)♥♠♠     ½☼♠♠F▬♠♠↔¯▬♠♠↔☼VÈ£`¯ã♠♠♠♠♠♠♫♫À♠♠£W☼↔z♥♠♠♥♠♠À♠♠☺£W☼↔z♥♠♠♠
F♠♠♠£®▬§♠♠À♠♠♠F☼#l%W☼]☺♠♥♠♠♠♦ª♥Ëh♥F▬♠F♠F¹+▲£¨♥♠úW☼§-♥♠♠-§ª ♥♠♠Ø0¯♠♠♠?0♠♠♠▼☼ã§.¨   â♠♠-/£ê
/£ê/¨0+ìh♥FN?♂¶ì/Ø0+äÅÃN?♂ö¨♫♠ª"♫♠♠À♠♠♫‼☼Q®♠F▬♠♠ìþ"
# ↨zàÃ#
# ♥♠☼♥Fɹ♥Ãê++¨♂ª«>À^ø¨_¢=£ÿ+¨GU¯▬½«Â ♂ªú+¨G/Â♠F9♂▼zÊ♠♫¸Ëà++¨GN«A▬½«Â ♂ªú+¨Ç+▬¨§/
¢=«ª↔▼‼#▲ê ▬
# à+£=/£¢Q+▲U´A+£-☼ª↔☼Eþ+¨¢
# ♥£Ã¨+_¢=Õ/ãÃ'¢à£☼O+¨G+
# ☻♠G☼£_¢=«¢à£U®Â♠O+¨G/ªò¯â♫NF▲ê ▬
# à+£↨V¢à£G«_§☼À§+¨Ç«ã♠N▬¨§/¢=ÇN
# ▬
# ♥Âê♠▬=§àAò♫Wª¸♥♠ø§+¨G♠F
# ♥£Ã¨+_¢=¢☼ ½♠À
# §+¨Ç♠F
# ♥£Ã¨+_¢=G/­☼F▼ ☼À▼h¿z£§«▲C☼G/­☼♫W♥â♫♠ø§+¨♠F
# ♥£Ã¨+_¢=«¡¢☼ ½▼À§+¨G+Â'F▲ê ▬
# à+£-ÊO¢☼ ½_à♠ø+¨G☼ÂC«↓♥N▬¨§/¢=Õ/«O¢☼ ½▲ü¢?/$/ E« _☼é+¨G☼$♫ìÃ▲j¢²♂㧪(☻♠G☼£_¢=Õ☻♠ ☼
£-☼ÃW?☼ª↔♂♫WÂöì£Ãâ☼▲j♂À¨+♫W♥¼Gþ♫♠♦♫²☼ú♫ª∟ü☼♣*.♠­♠F;♥▼jÀ
# ☻▬­☻ä♫♠¢♂Ã▼ þ

@paulsc96, perhaps you have some ideas on what might be causing this behavior, or maybe you'll spot a flaw in my approach? Maybe I need to append fw_payload.memh with some additional sections?

[paulsc96]

Hi @HepoH3,

Your approach looks good overall; I have two suggestions:

• You link the .memh files against the DRAM base, meaning the preload addresses in the .memh file will start at 0x80000000; however, the actual testbench memory you preload directly is mapped at 0x80000000 in the system map. So the firmware needs to start at 0x0 and the device tree at 0x800000 in the .memh file to be accessible by the core from those addresses plus 0x80000000, respectively. This may fix your issue.
• The LSB of the read argument should only be set if the boot mode is a disk boot mode (we can freely use this bit as a legal code address must be two-byte-aligned). Setting the boot mode to 0 should prevent this, so you don't need to comment out any code.

[HepoH3]

• the firmware needs to start at 0x0 and the device tree at 0x800000 in the .memh file to be accessible by the core from those addresses plus 0x80000000, respectively.

Thank you, that's a really good idea — it's surprising I didn't think of it myself! Unfortunately, changing the load addresses in the final memh file only makes things worse — it results in exceptions about illegal instruction fetches starting at address 0x80000000 (which didn't happen before):

Warning: 1[l1 dcache] reading invalid instructions: vaddr=80000000, data=xxxxxxxx
Warning: 1[l1 dcache] reading invalid instructions: vaddr=80000008, data=xxxxxxxx
Warning: 1[l1 dcache] reading invalid instructions: vaddr=8000000c, data=xxxxxxxx

# [UART] [ZSL] Launch firmware at 80000000 with device tree at 80800000
# [UART]
# [UART] ==== [ZSL] trap encountered ====

Warning: 1[l1 dcache] reading invalid instructions: vaddr=80000004, data=xxxxxxxx
Warning: 1[l1 dcache] reading invalid instructions: vaddr=80000008, data=xxxxxxxx
Warning: 1[l1 dcache] reading invalid instructions: vaddr=8000000c, data=xxxxxxxx

# [UART]  mcause:     0x0000000000000002
# [UART]  mepc:       0x0000000080000000
# [UART]  mip:        0x0000000000000080
# [UART]  mie:        0x0000000000000008
# [UART]  mstatus:    0x0000000000005800

I checked out that this happened while memory has been initialized with correct instructions:

memory content

It looks like the original address (without stripping the upper 0x08) is being passed to axi_sim_mem. If that's the case, the lower 2GB of memory end up unused and the original load addresses in readmemh were the correct ones. It's kind of hard for me to check this through RTL.

[paulsc96]

Indeed, it seems I was wrong, as axi_sim_mem passes request addresses on exactly as they are without changes.

However, this seems to suggest the previous simulation was at least executing code. Then, this may be a baud rate mismatch. Perhaps you can measure the baud rate by looking at the UART TX wave in simulation. if one bit is not about 8.7 us long, something may have gone wrong with passing the device tree or setting up the UART.

[HepoH3]

if one bit is not about 8.7 us long

You're right — the duration of 1 bit in the ZSL messages is indeed 8.64us, which matches the expected value for a baud rate of 115200. However, in the payload, the bit duration drops to 2.16us — four times shorter.

I haven't yet figured out why this happens. I traced the logs down to the point where the UART is initialized, but I couldn't find anything unusual:

As you can see, uart8250_init is called, and it appears to use 50MHz (0x2faf080) and 115200 baud (0x1c200) as the UART parameters. So it looks like the DTB is built and loaded correctly.

[paulsc96]

However, in the payload, the bit duration drops to 2.16us — four times shorter.

That's it: Simulation runs at 200 MHz, but the FPGA device trees target 50MHz. Replacing the corresponding clocks in the device tree should resolve the issue.

EDIT: modifying the clock-frequency keys in the cpus, serial, and spi to 200000000 should do the trick.

[HepoH3]

Yup, now it's finally working!

# [UART] [ZSL] Launch firmware at 80000000 with device tree at 80800000
# [UART] 
# [UART] OpenSBI v0.9
# [UART]    ____                    _____ ____ _____
# [UART]   / __ \                  / ____|  _ \_   _|
# [UART]  | |  | |_ __   ___ _ __ | (___ | |_) || |
# [UART]  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
# [UART]  | |__| | |_) |  __/ | | |____) | |_) || |_
# [UART]   \____/| .__/ \___|_| |_|_____/|____/_____|
# [UART]         | |
# [UART]         |_|
# [UART]
# [UART] Platform Name             : CHESHIRE RISC-V
# [UART] Platform Features         : medeleg
# [UART] Platform HART Count       : 1
# [UART] Platform IPI Device       : aclint-mswi
# [UART] Platform Timer Device     : aclint-mtimer @ 1000000Hz
# [UART] Platform Console Device   : uart8250
# [UART] Platform HSM Device       : ---
# [UART] Platform Reboot Device    : ---
# [UART] Platform Shutdown Device  : ---
# [UART] Firmware Base             : 0x80000000
# [UART] Firmware Size             : 220 KB
# [UART] Runtime SBI Version       : 0.3
# [UART]
# [UART] Domain0 Name              : root
# [UART] Domain0 Boot HART         : 0
# [UART] Domain0 HARTs             : 0*
# [UART] Domain0 Region00          : 0x000000000204bff8-0x000000000204bfff (I)
# [UART] Domain0 Region01          : 0x0000000002044000-0x000000000204400f (I)
# [UART] Domain0 Region02          : 0x0000000002040000-0x0000000002043fff (I)
# [UART] Domain0 Region03          : 0x0000000080000000-0x000000008003ffff ()
# [UART] Domain0 Region04          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
# [UART] Domain0 Next Address      : 0x0000000080200000
# [UART] Domain0 Next Arg1         : 0x0000000080800000
# [UART] Domain0 Next Mode         : S-mode
# [UART] Domain0 SysReset          : yes
# [UART]
# [UART] Boot HART ID              : 0
# [UART] Boot HART Domain          : root
# [UART] Boot HART ISA             : rv64imafdcsuh
# [UART] Boot HART Features        : scounteren,mcounteren,mcountinhibit
# [UART] Boot HART PMP Count       : 0
# [UART] Boot HART PMP Granularity : 0
# [UART] Boot HART PMP Address Bits: 0
# [UART] Boot HART MHPM Count      : 6
# [UART] Boot HART MIDELEG         : 0x0000000000000666
# [UART] Boot HART MEDELEG         : 0x0000000000f0b509
# [UART]
# [UART]
# [UART] U-Boot 2021.07-rc4-gcb3f747f5e (Jul 08 2025 - 22:46:35 +0300)
# [UART]
# [UART] CPU:   rv64imafdc
# [UART] DRAM:  1 GiB
# [UART] bind node reserved-memory
# [UART] Device 'reserved-memory' has no compatible string
# [UART] bind node chosen
# [UART] Device 'chosen' has no compatible string
# [UART] bind node memory@80000000
# [UART] Device 'memory@80000000' has no compatible string
# [UART] bind node cpus
# [UART] Device 'cpus' has no compatible string
# [UART] bind node soc
# [UART]    - attempt to match compatible string 'eth,cheshire-bare-soc'
# [UART]    - attempt to match compatible string 'simple-bus'
# [UART]    - found match at 'simple_bus': 'simple-bus' matches 'simple-bus'
# [UART] bind node debug@0
# [UART]    - attempt to match compatible string 'riscv,debug-013'
# [UART] No match for node 'debug@0'
# [UART] bind node axi_llc@3001000
# [UART]    - attempt to match compatible string 'eth,axi-llc'
# [UART] No match for node 'axi_llc@3001000'
# [UART] bind node memory-controller@3006000
# [UART]    - attempt to match compatible string 'eth,ddr-link'
# [UART] No match for node 'memory-controller@3006000'
# [UART] bind node serial@3002000
# [UART]    - attempt to match compatible string 'ns16550a'
# [UART]    - found match at 'ns16550_serial': 'ns16550' matches 'ns16550a'
# [UART] Bound device serial@3002000 to soc
# [UART] bind node i2c@3003000
# [UART]    - attempt to match compatible string 'eth,i2c'
# [UART] No match for node 'i2c@3003000'
# [UART] bind node spi@3004000
# [UART]    - attempt to match compatible string 'opentitan,spi-host'
# [UART]    - found match at 'opentitan_qspi': 'opentitan,spi-host' matches 'opentitan,spi-host'
# [UART] Bound device spi@3004000 to soc
# [UART] bind node vga@3007000
# [UART]    - attempt to match compatible string 'eth,axi-vga'
# [UART] No match for node 'vga@3007000'
# [UART] bind node clint@2040000
# [UART]    - attempt to match compatible string 'riscv,clint0'
# [UART] No match for node 'clint@2040000'
# [UART] bind node interrupt-controller@4000000
# [UART]    - attempt to match compatible string 'riscv,plic0'
# [UART] No match for node 'interrupt-controller@4000000'
# [UART] Bound device soc to root_driver
# [UART] bind node cpu@0
# [UART]    - attempt to match compatible string 'eth,ariane'
# [UART]    - attempt to match compatible string 'riscv'
# [UART]    - found match at 'riscv_cpu': 'riscv' matches 'riscv'
# [UART] Bound device riscv_timer to cpu@0
# [UART] Bound device cpu@0 to cpus
# [UART] Bound device cpus to root_driver
# [UART] MMC:   0
# [UART]    - not found
# [UART] 
# [UART] Loading Environment from nowhere... OK
# [UART] In:    serial@3002000
# [UART] Out:   serial@3002000
# [UART] Err:   serial@3002000
# [UART] Net:   No ethernet found.

I still haven't reached the "Hit any key to stop autoboot" message — I'm not sure whether it's because I haven't provided a Linux kernel at this point, or if I just need to wait longer. Either way, the progress so far is very promising!

@paulsc96, you mentioned that you could reconfigure OpenSBI to chainload Linux. May I ask you to do that? I’d really appreciate it! If it would be helpful, I can document all the steps we made as an additional user guide afterward.

[paulsc96]

@paulsc96, you mentioned that you could reconfigure OpenSBI to chainload Linux. May I ask you to do that? I’d really appreciate it! If it would be helpful, I can document all the steps we made as an additional user guide afterward.

There is a target in cva6-sdk called spike_payload building a spike_fw_payload.elf. The name is misleading, but this just jumps to a payload preloaded to 0x80200000 instead of running a bundled one.

So if you load spike_fw_payload instead of fw_payload and additionally preload the raw Linux image (just called vmlinux) to 0x80200000, OpenSBI should load Linux directly.

NOTE: In that case, you may need to move the device tree out of the way of the linux image. Just pick a high address (linux will first make a copy, so don't worry about reclaiming that memory after boot) and replace __BOOT_ZSL_DTB with your chosen higher address in the ZSL.