drv/uefi/devpath: new unit
This is getting good! Startup code in glue.fs now prints the "UEFI path" for
the first bound block I/O, which is the ATA drive.
drv/uefi: add "HandleProtocol"
For example, if you do, in QEMU+OVMF:
blkioguid LocateProtocol .
devpathguid swap absaddr q@ HandleProtocol .
You will have the "interface" variable hold a 64-bit pointer to a DevPath
interface targeting the first of the two BLKIO present.
I'm getting somewhere... I think...
lib/diag: don't depend on lib/fmt
It makes it harder to include on very tight systems, for no good reason.
uefi: use RSP as storage for all uefiexec args
Storing directly to register was faster, but the rules we had to follow to avoid
register clobbering was too restrictive and error prone. Let's make our lives
easier...
drv/uefi: add "LocateProtocol"
You can try it on QEMU+OVMF with "blkioguid LocateProtocol", which will yield
a 16b (2 elements) array.
uefi: change "uefiexec" semantics
This allows calls with more than 4 arguments.
uefi: Hello World! Hello World!
yay!
calling it twice to make sure the stack is OK...
deploy/uefi: it seems that compiling xcomp/boot is trivial!
deploy/uefi: organizing HERE
The UEFI executable now (apparently) has 1MB of HERE data to play with. It seems
to work. We can play.
ar/pe: tweak around
Added the "Contains uninitialized data" characteristics flag to the ".text"
section. Also, set the "total size" field. This is all a bit wobbly and the
result of trial and error on QEMU+OVMF. I don't really know what I'm doing.
It seems that someday, I'll have to devise a more solid PE generation mechanism.
io/stream: new "herestream" was broken...
fs/tar: fix long standing "cursor leak"
Cursor reuse would never work because the structure directly following the
new "files" link would be a secwin, not a file! The fix required a slight change
in fs/core inner semantics.
io/stream: add "spitclose"
io/stream: add "herestream"
deploy/uefi: begins interpreting payload!
deploy/uefi: can run on actual machines!