On 2012-09-09 21:49 +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
+ {
+ grub_relocator_chunk_t ch;
+ err = grub_relocator_alloc_chunk_addr (rel, &ch,
GRUB_FREEDOS_BPB_ADDR,
+ GRUB_DISK_SECTOR_SIZE);
I don't understand this. Shouldn't it be at 0x7c00 ?
This is intended to be at 0x27a00, not 0x7c00. GRUB_FREEDOS_BPB_ADDR
should evaluate to 0x27a00. I'll try to explain the reasoning for this -
if any of the following is unclear, please feel free to ask for
clarification. Sorry that it's so verbose; I suggest you read the summary
first if you prefer.
-
The FreeDOS kernel's original boot loader (boot/boot.asm in the kernel's
repo) first relocates itself to linear address 2_7A00h (formed as
segmented destination address 1FE0h:7C00h, the segmented source address
being 0000h:7C00h). This is an adjustment from other/earlier loaders that
left the (boot sector) loader at (linear) 0_7C00h and thus restricted the
next stage* to be loaded from disk to about 29 KiB, if it is to be loaded
into contiguous space starting at a lower address (used to be 0_0700h, now
0_0600h for current FreeDOS kernel releases). With this adjustment, the
limit is increased to about 157 KiB.
[* Earlier DOS-C (ie FreeDOS kernel) releases loaded a subsequent IPL
stage first, possibly motivated by this ca. 29 KiB limit as well. Current
FreeDOS kernel releases typically directly load the whole kernel.]
In principle, GRUB could of course write the BPB anywhere up to the top of
"conventional memory" (below A_0000h, or below an EBDA if present there)
and incidentally raise the file size limit. (Or potentially the kernel
could be loaded to eg 0_8000h with the BPB placed somewhere below that,
also raising the file size limit - however 0_0600h is clearly documented
as the canonical load address of the current protocol and the kernel might
rely on it.)
However, various programs might assume that the FreeDOS load protocol
places the BPB at exactly 2_7A00h (with ss:bp and ds:bp specifying
1FE0h:7C00h). I don't know whether the current kernel itself relies on
this. I'm aware that at least MetaBoot** does search at that particular
(linear) address, so placing the BPB/sector there is necessary (though not
sufficient) for it. (MetaBoot's only purpose is to reload a different
next-stage file, hence loading it from GRUB isn't important because GRUB
can instead directly load the desired next-stage file. I merely mentioned
MetaBoot for its assumption that this particular position is implied by
the load protocol.)
[** MetaBoot belongs to the MetaKern loader for FreeDOS, developed by
FreeDOS kernel maintainer Eric Auer. It is covered by the GPL 2 with an
additional loading exception/permission, and distributed as part of
FreeDOS.]
In addition, arguably there is little use in raising the file size limit
above what the original loader can work with. This differs from my
opinion, but might be a relevant view for GRUB to consider.
-
So, summing it all up, the resulting 2_7A00h address of the BPB is to most
closely mimic the original loader, which arrived there to partially raise
a limit caused by that loader's size constraints (from the original 29 KiB
limit to 157 KiB). That level of compatibility might be unnecessary (for
the kernel itself), but apart from reproducing the original's more recent
file size limit there is no harm in it.
Note that in GRUB's ntldr.c, the BPB is written at 0_7C00h and no
equivalent file size limit exists because the next stage (NTLDR) file is
loaded starting at a higher address, 2_0000h.
Do you plan to contribute more? If so I'd prefer to make you sign a
copyright assignment, otherwise this patch can go in, once it's clear
with addresses.
I could gladly sign an assignment, however I don't yet plan to contribute
more.
Regards,
Chris Masloch
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
