boot multi initrd (on qemu)

[mocore]

as mentioned previously @ https://forum.tinycorelinux.net/index.php/topic,26118.msg170626.html#msg170626

https://bugs.launchpad.net/qemu/+bug/393569/comments/6

Looking through old bug tickets... If I've got that right, there is multiboot support in QEMU nowadays, and we also have the possibility to load multiple files with the "loader" device ... is that enough, or is still something to be done here?

some more details on specifics for this option use ( presumably gained from experience  )  @ https://stackoverflow.com/questions/58420670/qemu-bios-vs-kernel-vs-device-loader-file/58434837#58434837

-device loader is the "generic loader", which behaves the same on any architecture. It just loads an ELF image into guest RAM, and doesn't do anything to change the CPU reset behaviour. This is a good choice if you have a completely bare-metal image which includes the exception vector table and want to have it start in the same way the hardware would out of reset.

it appears this is the official qemu documentation for the 'loader' option  https://www.qemu.org/docs/master/system/guest-loader.html

this appears to cover more specifics https://qemu-project.gitlab.io/qemu/system/generic-loader.html

[mocore]

so afaik it appears to use qemu "loader" option with more than one inird(or initramfs as the case may be )

requires passing memory offset (afaik this is the size of each file) for each 'loader' option

and (out on a limb) apparently some background info of whatever architecture qemu is booting
( eg arm and x86 hw  have different hw init & defaults )

this appears to be a/the  relevant info for x86   arch
https://www.kernel.org/doc/html/v5.4/x86/boot.html#memory-layout

id guess from the name "initrd_addr_max (The maximum address that may be occupied by the initial ramdisk/ramfs contents.)"
 might perhaps also be relevant
 
 ...
https://binarydebt.wordpress.com/2017/10/22/paging-in-linux-on-x86-part-2/

Kernel typically divides virtual address space into 3GB from 0x00000000 to 0xbfffffff for user space and 0xc0000000 to 0xffffffff for kernel space. In kernel code, the macro PAGE_OFFSET contains virtual address at which kernel starts, i.e. 0xc0000000 on a typical x86 set up.

Early on during boot, kernel learns size of RAM by querying BIOS. Then it scans physcial addresses to find those addresses which are unavailable. They can be:

    addresses which are mapped with hardware devices’ I/O (memory-mapped I/O)
    addresses pointing to page frames containing BIOS data

Typically the kernel lodges itself at physical address 0x00100000, i.e. 2nd MB onwards.

https://0xax.gitbook.io/linux-insides/summary/booting/linux-bootstrap-1#bootloader

https://nickdesaulniers.github.io/blog/2018/10/24/booting-a-custom-linux-kernel-in-qemu-and-debugging-it-with-gdb/