Re: [PATCH] Improve FreeDOS direct loading support compatibility.

["C. Masloch" <pushbx@38.de>]

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