From: nowhere@never.at   
      
   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" ?   
      
   > 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].   
      
   ...   
   >>>    48 8d 15 e7 1f 00 00     lea    rdx,[rip+0x1fe7]   
   >> OK I see it, but it is limited to 64k distance (same as in 32bit).   
   > Are you sure it's not +/- 2G? (Those zeroes...!)   
      
   yeah got me :) I checked on my disassembler and it tells this four bytes   
   are signed relative to following instruction (same as jump near/short),   
      
   >> my one time self relocation used on start of several temporary dynamic   
   >> loaded modules (all static stuff is at fixed offsets as part of OS).   
      
   >> E8 0000_0000  CALL next   
   >> 5E            POP  ESI   
   >> ...           adjust with known offsets   
      
   > That's fine, too, especially if used only once and not in tight nested   
   > loops.   
      
   it should work almost equal in 64bit:   
         E8 0000_0000  CALL next ;sign-extended to 64 bit relative to L1   
   L1:  5E            POP RSI   ;get 64bit address of L1   
      
   >>> 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.   
      
   >> 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 have a copy from Herbert's shortest possible PE. I'll read it again.   
      
   >> we need to learn what exactly is required to make UEFI load and execute.   
      
   > That has to come from the spec because there are many implementations -   
   > both present and future.   
      
   >>> UEFI is a lot more fussy than BIOS as to what it will hand control to.   
   >> Oh yeah, that was the reason for I stopped all business with KESYS.   
      
   >> BTW, you have a working text test?   
   >> can you read out a few registers and print the values?   
   >> it would be interesting what we get on start, especially RSP.   
      
   > I have working text output but not number output in Asm. I could add it   
   > but it doesn't seem useful for this as the contents of registers which   
   > are not mentioned in the spec are unlikely to be consistent, AFIACS.   
      
   I remember back then when DOS once had similar issues, meanwhile start   
   conditions and reg-values are well documented and reliable (hugi comp).   
      
   I think UEFI will also either behave standardized or vanish soon.   
   what's missing on this matter is non C-styled detailed information.   
      
   OK so far I'll work on that after I assembled my new PC with parts   
   bought today [this may take a while].   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)