On 12/5/2012 19:38, Shao Miller wrote:> A proposal for changing the LDLINUX.SYS layout and flow:
>
> The current situation ("old style"):
>
> ldlinux.bin's physical layout:
> - VBR
> - 512 bytes of padding (never lands in memory)
> - ldlinux.sys, which is:
> - Sect1 code (494 bytes, leaving enough room for at least one
> extent, as planned)
> - Extent pointer patch space (1920 bytes)
> - The rest of the code
>
> ldlinux.bin's in-memory layout:
> - VBR @ 0:7C00 (or wherever else a crazy BIOS might put it)
> - ldlinux.sys @ 0:8000
> - Sect1 code @ 0:8000
> - Extent pointers @ 0:81EE
> - The rest of the code @ 0:896E
>
> Proposal for a future style:
>
> ldlinux.bin == ldlinux.sys
>
> ldlinux.sys' physical layout:
> - Sect1 code
> - Extent pointer patch space
> - The rest of the old-style ldlinux.sys code
> - 1024 bytes of Special Padding (you'll see why, later)
> - New Special Code
> - Padding to a 512-byte boundary
> - VBR
>
> ldlinux.sys' in-memory layout (unchanged from old style):
> - VBR @ 0:7C00 (or wherever else a crazy BIOS might put it)
> - ldlinux.sys @ 0:8000
> - Sect1 code @ 0:8000
> - Extent pointers @ 0:81EE
> - The rest of the code @ 0:896E
>
> The goals are:
>
> - That the installers wouldn't carry the VBR around as a separate
> blob, but could extract it from the end of the embedded ldlinux.sys,
> instead.
>
> - Sect1 could check to see where the instruction pointer is. If it
> is near 0:7C00, then some other boot-loader has loaded the whole
> ldlinux.sys there. Because the whole file is loaded, jump to New
> Special Code. If it is near 0:8000, then this is the usual load from
> the VBR; carry on as usual (no more discussion about the usual case).
>
> - New Special Code only runs when the whole ldlinux.sys has been
> loaded into memory. It shuffles down everything _before_ Special
> Padding from 0:7C00 (where some other boot-loader loaded all of
> ldlinux.sys) down to 0:8000 (where it's usually loaded by the VBR).
>
> - Now Special Padding has been obliterated and New Special Code
> immediately follows the rest of the old-style ldlinux.sys code (not that
> it really matters, as long as New Special Code is not overwritten)
>
> - New Special Code reads _the_actual_ disk VBR to 0:7C00, since
> everything's been shuffled down
>
> - New Special Code patches 0:7C00 with the ldlinux.sys VBR code,
> leaving the FS data intact. It then patches the VBR code to skip
> loading Sect1 from disk. It also patches Sect1 to skip loading the rest
> of ldlinux.sys from disk. (Sectors to load == 0)
>
> - New Special Code then jumps into the VBR code.
>
> - VBR code then does what it does except for loading Sect1, but still
> jumps to it.
>
> - Sect1 then does what it does except for loading the rest of
> ldlinux.sys from disk.
>
> - The rest of ldlinux.sys executes
>
> Does this make any sense as a possible way to chain-load ldlinux.sys
> from another boot-loader, without much risk of interfering with the
> current and common loaded-from-VBR flow?
>
> If my design makes sense, the only space needed from currently existing
> blobs would be for the new "check and possibly jump if we're at
0:7C00",
> in Sect1.
>
> The installers would obviously need to deal with a change in the layout
> of ldlinux.sys/ldlinux.bin
>
> I don't know if NASM allows for the VBR (which will live at 0:7C00) to
> come, in the binary file, physically after the usual ldlinux.sys code at
> 0:8000.
>
> I think a big win for this is that users don't need the installers for
> this... Wherever they happen to find an ldlinux.sys (with these
> changes), it should be transferable to anywhere else. Having a modified
> version means the two can be confused ("Well where did you get it
from?
> Did the installer make it? Or is it renamed from the special one?
...")
Alternatively, the following three features could result in a useful
chain-loadable Syslinux binary:
- Multiple FS support (called "multi-disk"?). This would remove
the
boot-from-FS limitation
- CPIO "FS" support
- Linux x86-format Syslinux binary
Then one could chain a "syslinux.lkrn" with a minimal
"initrd"
(CPIO/initramfs archive) containing some .c32s or whatever.
Maybe that'd work best? What needs to happen to get the
"multi-disk"
GSoC work into Syslinux? Some mailing-list review? Or is it (review,
merge, whatever) already assigned to a particular person's to-do list?
This e-mail prompted by reboot.pro forum members asking about
chain-loading Syslinux from GRUB4DOS, etc.
- Shao Miller