Seeming inefficiency in the MRB

[Blazing-Blast]

At the moment the MBR does the following:

1. Clear the segment registers.
2. Save the ID of the boot disk.
3. Move the Stack Pointer to 0x7b00.
4. Retrieve disk properties.
5. Calculate on how many sectors, and at what sector, Stage 2 lives.
6. Load Stage 2 from disk into 0x7e00.
7. Copy some Mover code to 0x7b00.
8. Jump to that Mover code and have it move Stage 2 from 0x7e00 to 0x7c00.
9. Jump into the relocated Stage 2.

Why not load Stage 2 into 0x7c00 the first time? Just skip steps 7 and 8.
I can speculate that the inc %eax at line 29, makes it so that too much is loaded from the disk, but in that case, wouldn't it be easier to zero out 0x7c00 + $BOOT_FILE_SIZE until 0x7c00 + dap_sectors * drive_params_bps?
Or is there another issue that I'm not seeing?

[Blazing-Blast]

I think I see why this was chosen, the MBR gets loaded to 0x7c00, but does Stage 2 really have to be as well? Can't it go somewhere else, to avoid this relocation?

[klange]

The caveat is there is no “stage 2”. The MBR loads the El Torito payload - which is also a first stage on its own. Both of those expect to be at 0x7c00. The El Torito payload could be built to be more flexible about where it is loaded, but that is relatively more complicated: The MBR being inefficient is of little concern; it is a quick hack to allow the CD images to be written to hard disks.

[Blazing-Blast]

That seems completely fair, although in the comments it is referred to as 'stage 2'.