From: james.harris.1@gmail.com   
      
   On 30/11/2023 15:23, wolfgang kern wrote:   
   > On 30/11/2023 11:30, James Harris wrote:   
   > ...   
   >>>> a) Code at 1000, data at 1400   
   >>>> b) Code at 2000, data at 2400   
   >   
   >>> I cannot believe that it may randomly load to different locations.   
   >   
   >> Why not? A UEFI app (such as a bootloader) is just an app as far as   
   >> UEFI is concerned. Where it gets loaded is not specified as it was   
   >> with BIOS.   
   >   
   > Isn't the first thing it loads (or tries to) a file from the FAT32 root   
   > directory with a certain name like "efi.bin" ?   
      
   We were talking about /where/ UEFI loads the PE file. And you've kept   
   that prior discussion in. So the change to /what/ UEFI loads is unexpected.   
      
   But on the topic of what gets loaded ... all I can say is I don't know!   
   I presume each machine can be configured with a list of things to try.   
   Just like a BIOS can be configured to look for a floppy, an optical   
   drive, then the first hard disk, or similar, I believe a UEFI machine   
   can be configured to try a series of potentially bootable media and   
   files until it gets to one which works.   
      
   That said, there are some standard locations, most notably   
      
      /efi/boot/   
      
   Files in there called   
      
      bootARCH.efi   
      
   are meant to be bootable for the specified architecture. ARCH could be   
   such as ia32 or x64 (and yes, 3-char architecture names are OK).   
      
   I have been testing with qemu. No idea how to configure a boot list on   
   it but by default it will load either   
      
      /efi/boot/bootx64.efi   
      
   or   
      
      /startup.nsh   
      
   where the latter is a series of textual commands. startup.nsh is akin to   
   autoexec.bat.   
      
   >   
   >> There's no simple 0x7c00 any more! The actual location of one's   
   >> bootloader will likely depend on who wrote the firmware, what   
   >> /version/ of the firmware is being used, what drivers have been loaded   
   >> beforehand, what happened on the machine before it loaded our   
   >> bootloader, etc.   
   >   
   > Yes, there should be something like HW detection, GDT/IDT, USB and VESA   
   > stuff already mounted for the boot [ROM BIOS did that as well].   
      
   ...   
      
   >>>> 5) The choices are to write PIC code or use relocation but bear in   
   >>>> mind that UEFI firmware has to see your final PE file as something   
   >>>> it is willing to load and execute so it might expect some flags or   
   >>>> indicators to tell it that the file is PIC or, failing that, that it   
   >>>> comes with a relocation section.   
   >   
   > I think relocation requirement is found in the header of an PE,   
   > so if non is mentioned there UEFI should know how to act.   
      
   Note, though, that in the previously posted disassembly the PE file   
   appeared to do its own relocation.   
      
   I think the services UEFI might use to load PE files are   
      
   EFI_BOOT_SERVICES.LoadImage   
   EFI_BOOT_SERVICES.StartImage   
      
   but from a quick scan the standards don't seem to say what either of   
   them does about relocation. Probably nothing, would be my guess.   
      
   >   
   >>> you mean UEFI will disassemble my code before loading it ?   
   >> :-)   
   >> No, but remember that a bootloader has to be in PE format and such a   
   >> format has descriptive fields in its headers. The firmware will   
   >> naturally only load files if it likes what it sees in the headers.   
   >   
   > you mean UEFI insists to have relocation ? what for ?   
      
   I don't know what characteristics the OS loader (or any UEFI   
   Application) is expected to have. I tried removing some of the library   
   code you now have in the disassembly I posted before. I managed to get   
   rid of some of it but there came a point where the firmware would no   
   longer load the PE file.   
      
   It's something I've to get back to. All I can say just now is that the   
   PE file which the firmware wouldn't load had no reloc section.   
      
      
   >   
   > I have a copy from Herbert's shortest possible PE. I'll read it again.   
      
   Sounds good. Hope you'll feed back what you come up with.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)