Why did bootsect move itself to 0x90000 in linux(x86)?

Question

I'm studying the process of x86-system booting and Here is the booting flow:

1. BIOS load the bootsect from disk MBR to 0x7c00 memory address
2. boosect copy itself to 0x90000 memory address and jump to 0x90000.
3. boosect load setup from disk to 0x90200 memory address.
4. Get some system peripheral device parameters (video, root disk, keyboard,…,etc.) and jump to 0x90200.
5. Switch system into protected mode move kernel from 0x10000(64K) to 0x0000
6. Jump to 0x0000 and execute head.s for kernel boot

My question is that why we need to move bootsect itself to 0x90000 first?

Why can't we just move setup and system?

Thanks.

Answer 1

It was (and still is) a good practice to "shadow copy" your bootloader and jump to it. This practice began early when the typical boot loader was limited to the size of a single segment on an x86 processor and a single read sector from disk. Once interrogating the hardware a boot loader could do more advanced work, like install system files (calls, hooks, TSRs, etc), be taken over by viruses, or initialize protected mode and start performing hardware paging of applications, etc.

The origin of the "behavior" predates Linux, you should find that this behavior was common to x86 bootloaders. Possibly any computer based on the IBM PC.

The code presently in Linux was probably derived from this:

Fx. https://stuff.mit.edu/afs/sipb/user/warlord/C/memtest86/bootsect.s

In which case the choice to relocate to 0x90000 is likely arbitrary, the goal was to move the loader out of the default location into a location of its own choice where it wouldn't be tampered with by programs which might allocate from "low mem" (in effect: as a matter of practice.)

I would like to see a definite reason myself :) pretty sure it's really just a remnant of a time when the x86 platform was a DOS platform, and as the hardware evolved new tricks were employed to remain backward compatible with "unfriendly" lowmem code.

Answer 2

I believe that moving the boot sector out of the way was mostly a matter of convenience - there is no hard technical reason that it could not be done otherwise.

That said, 0x7c00 lies less than 32KiB from the start of the memory. 32KiB is often not enough for the setup stage of the kernel, let alone the kernel itself. 0x90000 is well under the area that is reserved by the PC BIOS, while also leaving enough space for the kernel.

In any case, the process you are referring to has not been used by the Linux kernel for several years. The addresses you mentioned are used by versions of the Linux Boot Protocol before v2.02, which was first used with linux-2.4.0. I think that the kernel itself stopped being directly bootable with linux-2.6.0 or so. The arch/i386/boot/bootsect.S file of that version would output a message to that effect when someone attempted to boot the kernel directly.

These days the kernel is usually loaded by a separate bootloader, which is free to use whatever approach it wishes as long as it complies with the boot protocol. The bootloader may have several stages and may even do kernel-y things, such as switching to protected mode itself.