Steps for creating exactstep elf file from its component parts?

[ipacman]

Very interesting work, thank you!!

Would it be possible to add to README.md how the exactstep elf file is created from the Linux Kernel and busybox elf images (generated from perhaps your riscv32_linux_from_scratch repository), and how these are combined with an init fs containing the busybox executable? I was not familiar with the use of a single .elf file for booting Linux, usually there is a combination of images referenced in the Linux startup..

Its also not clear whether the dtb here is used only by exactstep or if it also gets passed into Linux. Maybe that is included in the exactstep elf file too?

It appears that opensbi is part of the answer but still not connecting all the dots.

--
One related question -- Using opensbi for exactstep simulation seems to diverge from your fpga platform use of the simplified riscv-linux-boot, so wondering why not use that (rather than opensbi) in exactstep?

[ipacman]

This side comment related to opensbi in https://github.com/ultraembedded/opensbi vs riscv32-unkown-elf-gcc generated from https://github.com/ultraembedded/riscv32_linux_from_scratch.

The 'latest generated' riscv32-unkown-elf-gcc (v10.1.0) does not successfully compile/link the opensbi in https://github.com/ultraembedded/opensbi.

Including a note here since opensbi appears to be used in the Linux example and was attempting to build it per my previous comment.

With 10.1.0 gcc, here is an inexplicable linker error about memset that I assumed was a problem with the 10.1.0 gcc since it compiled and linked ok with an older version I had laying about (and really, must be because I saw no such error).

But it turns out that 10.1.0 compiler does compile and link the latest opensbi from https://github.com/riscv/opensbi (with the same function it errored in unchanged).

Note in this updated opensbi, the qemu platform used here is now named 'generic'.

I notice that exactstep is able to handle compressed instructions (nice), but depending on use, it may be necessary to define PLATFORM_RISCV_ISA (either rv32ima or rv32imac) when compiling opensbi if trying to match an rtl implementation because otherwise the default for opensbi is rv32imafdc (!).

[ultraembedded]

Good comments!

You are right, I essentially support two SBI bootloaders - my lightweight fpga one, riscv-linux-boot, and OpenSBI.

The reason for riscv-linux-boot is that it has atomic instruction emulation which allows me to run kernel images built to use RV-A instructions on versions of my (hw) CPUs that don’t implement atomic instruction support.

OpenSBI does have this, and worse (for me), uses atomic instructions itself making it much more work to emulate RV-A.

Exactstep has support for RV-A instructions so it doesn’t matter which bootloader is used, but this is not the case for my FPGA systems.

I think I need to rebase my OpenSBI fork!