0

Could you help me understand the bootflow while using Qemu to load bins ? If we consider a simple program like writing ascii to VGA memory, where is bin loaded to when we call

qemu-system-i386 -drive 'file=my_image.bin,format=raw' -serial mon:stdio -smp 2

As per my understanding, the bios on finding a valid boot sector having the magic pattern 0xAA55, loads this sector to 0x7c00. Does Qemu actually copy the bin into this boot-sector of HDA?

I have seen in many tutorials that a linker script configured with 0x7c00 as the load address is used for generating the elf. However this elf is converted to a bin and passed to qemu. So, is the load address of 0x7c00 really needed ? Can it be any other value in the linker script ?

RohitMat
  • 145
  • 1
  • 14
  • 2
    It's not really copied, you specified your file as the content of hda. Yes, the load address is physical 0x7c00 which may be 0:0x7c00 or 0x7c0:0. You should ensure that your linker script and runtime addresses match. – Jester Jun 15 '20 at 19:02
  • Hi Jester, could you correct me if I'm wrong. The image that we pass onto qemu should not be having any relocation info right ? So is there really a concept of load address ? – RohitMat Jun 15 '20 at 19:07
  • Especially since it does not have relocations, any memory references in it should match where it is actually executing. – Jester Jun 15 '20 at 19:09
  • Wouldn't an elf generated by linker script with say load address 0x1000 and load address 0x7c00 generate the same bin via objcopy ? The relative offsets should be same right ? The assumption here is that we have the data and code everything as a single text section – RohitMat Jun 15 '20 at 19:16
  • 1
    @RohitMat Data references generally use absolute addressing, so relative addresses won't necessarily cut it. – fuz Jun 15 '20 at 19:20
  • Thanks @fuz. That makes sense – RohitMat Jun 15 '20 at 19:26
  • I think the branches which use absolute address would also get messed up. Now it makes total sense – RohitMat Jun 16 '20 at 17:52

0 Answers0