Tiny Core Linux
General TC => Tiny Core on Virtual Machines => Topic started by: mocore on September 18, 2024, 06:35:27 AM
-
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
-
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/