From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1TApCQ-0006Lu-PX for mharc-grub-devel@gnu.org; Sun, 09 Sep 2012 17:37:50 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TApCO-0006KZ-44 for grub-devel@gnu.org; Sun, 09 Sep 2012 17:37:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TApCM-00077x-KQ for grub-devel@gnu.org; Sun, 09 Sep 2012 17:37:48 -0400 Received: from mail.38.de ([81.209.249.38]:55108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TApCM-00077o-Al for grub-devel@gnu.org; Sun, 09 Sep 2012 17:37:46 -0400 Received: from dslb-084-062-006-140.pools.arcor-ip.net ([84.62.6.140] helo=isor) by mail.38.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TApCK-0005YP-2S for grub-devel@gnu.org; Sun, 09 Sep 2012 23:37:44 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "The development of GNU GRUB" Subject: Re: [PATCH] Improve FreeDOS direct loading support compatibility. References: <4FF82A25.9070504@gmail.com> <504CF2E4.7070705@gmail.com> Date: Sun, 09 Sep 2012 23:37:45 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "C. Masloch" Message-ID: In-Reply-To: <504CF2E4.7070705@gmail.com> User-Agent: Opera Mail/12.02 (Win32) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 81.209.249.38 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 21:37:49 -0000 On 2012-09-09 21:49 +0200, Vladimir '=CF=86-coder/phcoder' Serbinenko wr= ote: >> + { >> + grub_relocator_chunk_t ch; >> + err =3D 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 summar= y = 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 tha= t = left the (boot sector) loader at (linear) 0_7C00h and thus restricted th= e = next stage* to be loaded from disk to about 29 KiB, if it is to be loade= d = into contiguous space starting at a lower address (used to be 0_0700h, n= ow = 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. Curren= t = 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 mig= ht = 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 n= ot = 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 mentione= d = 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 mo= st = closely mimic the original loader, which arrived there to partially rais= e = a limit caused by that loader's size constraints (from the original 29 K= iB = limit to 157 KiB). That level of compatibility might be unnecessary (for= = the kernel itself), but apart from reproducing the original's more recen= t = 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 contribut= e = more. Regards, Chris Masloch