<somlo>
I have a .dtb and fw_jump.bin for my LiteX setup, but wanted to set up a "reference" qemu machine before I deal with a bunch of *additional* moving parts :)
<davidlt[m]>
Ah
<davidlt[m]>
We aren't using jump anymore, even QEMU doesn't use it anymore by default
<davidlt[m]>
If you want to use it there is a description how to do it (I think) in the chat history.
<davidlt[m]>
I think I described how to do it to rwmjones a month ago or so.
<somlo>
well, that's why I wanted to set up qemu first, to poke around and see how I can adapt with the least amount of pain possible :)
<davidlt[m]>
Realistically we use U-Boot SPL which loads U-Boot ITB (DTB) which contains the config, OpenSBI FW_DYNAMIC and U-Boot binary.
<davidlt[m]>
SPL fills the structure about the next bootloader stage (aka U-Boot proper) and calls OpenSBI passing the struct.
<davidlt[m]>
OpenSBI does it thing and calls U-Boot.
<davidlt[m]>
U-Boot has a built in boot order for each device. It will scan in order (NVMe, USB, etc.) looking for the 1st partition and exlinux.conf (or not the 1st partition if partition has legacy boot flag set in GPT entry).
<davidlt[m]>
Once exlinux.conf is located it loads and jumps the kernel with DTB, initramfs information.
<davidlt[m]>
We still don't have GRUB2 stage (LoadFile2 and boot hard ID protocol continues to be not implemeted)
<somlo>
my current setup uses tftp to load opensbi, dtb, kernel, and initrd into RAM and jumps to opensbi which then boots the kernel :)
<somlo>
I can probably hack something together, then later adapt the "hardware" to the "standard" flow, but it'd be easier if I had something that already works to look at
<somlo>
but I understand if things are in flux on your end as well that it's probably not worth writing down before it "settles" :)
<davidlt[m]>
Well, it basically settled :) I just need for GRUB2 to land at some point upstream. Patches have been hanging for a year now.
<Guest51>
transferred properly to the SD card and that I have revision 3B0. What am I doing wrong?
<davidlt[m]>
This image doesn't incl. proper desktop support
<davidlt[m]>
This targets mainly console
<Guest51>
I usually go for the multi-user.target. Can this image handle that with systemd?
<davidlt[m]>
Isn't that a default?
<Guest51>
I don't know because it's never made it to the login prompt
<davidlt[m]>
With this image you should be able to use serial console or/and ssh to remotely manage it. By default there should be nothing on a display (most likely) if GPU and monitor is present.
<Guest51>
I suppose I could boot the factory image, mount the filesystems, and check.
<davidlt[m]>
Check serial console output.
<Guest51>
Gotcha.
<Guest51>
I'll try that.
<davidlt[m]>
Even if there is a corrupted bootloader or something there usually is some garbage printed in the serial.