You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the firmware is built into a normal ELF binary, and then booted using Firecracker. However, it would be nice if were possible to build the firmware into a flat BIOS binary that can be directly executed by the processor on reset.
Specifically, the firmware would be loaded at Guest Physical Address 4 GiB - sizeof(binary) and then execution would begin at the standard x86 reset vector0xFFFFFFF0 in Real Mode. This is what SeaBIOS's bios.bin and EDK2's OVMF_CODE.fd/OVMF_VARS.fd builds do.
This would then allow for the binary to be used with any VMM that uses the normal BIOS loading process. This means automatic support for QEMU and XEN. Specifically, using QEMU would then be possible with:
I would be happy to start exploring this. My idea of the execution flow would be:
One instruction at the reset vector: jump to code in (2)
Assembly code that:
b) Deals with A20
c) Sets up stub IDT/GDT/Paging
d) Switches to long mode
e) Jump to _start (i.e. the normal ELF entry point)
Our normal Rust entry point: _start.
This could be done by having two similar target.json files, that only differed in refering to different layout.ld files. The layout.fd file for our flat BIOS build, would just have to make sure that the code for (1) was properly aligned and at the end of the file. This also means that our flat BIOS build would still be an ELF file, which has its advantages.
The text was updated successfully, but these errors were encountered:
Right now the firmware is built into a normal ELF binary, and then booted using Firecracker. However, it would be nice if were possible to build the firmware into a flat BIOS binary that can be directly executed by the processor on reset.
Specifically, the firmware would be loaded at Guest Physical Address
4 GiB - sizeof(binary)
and then execution would begin at the standard x86 reset vector0xFFFFFFF0
in Real Mode. This is what SeaBIOS'sbios.bin
and EDK2'sOVMF_CODE.fd
/OVMF_VARS.fd
builds do.This would then allow for the binary to be used with any VMM that uses the normal BIOS loading process. This means automatic support for QEMU and XEN. Specifically, using QEMU would then be possible with:
Design Ideas
I would be happy to start exploring this. My idea of the execution flow would be:
b) Deals with A20
c) Sets up stub IDT/GDT/Paging
d) Switches to long mode
e) Jump to
_start
(i.e. the normal ELF entry point)_start
.This could be done by having two similar
target.json
files, that only differed in refering to differentlayout.ld
files. Thelayout.fd
file for our flat BIOS build, would just have to make sure that the code for (1) was properly aligned and at the end of the file. This also means that our flat BIOS build would still be an ELF file, which has its advantages.The text was updated successfully, but these errors were encountered: