ComradeSlice wrote:
Thanks for responding. Those functions seem to rely on private structures.
And? That's just a bunch of local variables grouped together in a struct defined
here. You don't need to use that struct, you can pass the arguments to mtftp from other variables as well.
Quote:
To clarify, I do know how to initiate TFTP but I am unsure how an OS loader specifically is supposed to do it.
The example I linked does exatly that. It is an official OS loader example which uses TFTP to load the boot image.
Quote:
Documentation refers a lot to drivers and firmware developers. By the time firmware has passed control to the EFI image, DHCP has already been initiated, next-server has been read (if applicable), and a TFTP connection has been opened to the PXE server.
That should not concern you. You get the DHCP packet with an UEFI call, it really doesn't matter if it's queried right on the spot or the most recent packet served from a cache.
And there's no such thing, "opening a TFTP connection". TFTP uses state-less datagramms, there's no three-way-handshake or any TCP session involved, therefore you cannot "open" it.
Quote:
The PxeReply in EFI_PXE_BASE_CODE_MODE may be sufficient for getting the boot server IP address, but is this what an OS loader is meant to be doing?
Take a closer look on the example I've linked. PxeBcDhcp4BootInfo() function get's the last reply packet and copies the server's IP address out from that into the Private struct (line 494). It checks three different locations: boot server list, server address in header, option list entry 54 in order.
Quote:
What is the recommended way of determining *where* the EFI image was actually loaded from? When I boot from a disk volume (my EFI image supports booting from disk right now). The EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL always returns an ACPI device path for my EFI image. I need a push in the right direction for figuring out the best way to determine where the boot image was loaded from. Currently my logic is: if PXE is not started we must have booted from a volume. Then I search all volumes for certain files my OS contains. It would be ideal to simply know which volume the EFI image is located on.
I don't follow you here. You're implementing the OS loader, it's totally up to you, so you surely know. If you mean in the loaded EFI image, then the asnwer is again it's up to you how you pass variables to
your kernel from
your loader. In my loader I set up paging (because I'm using 64 bit kernel and long mode requires paging enabled), so I obviously map an info struct at an address where my kernel can find the info, and I don't care what the physical address is. If you don't use paging then you should figure out a way to pass a pointer as an argument when you transfer control to the kernel.
Cheers,
bzt