Home Original page

[syslinux] Proposal for Chain-Loadable LDLINUX.SYS

Gert Hulselmans hulselmansgert at gmail.com
Mon Dec 31 13:02:07 PST 2012 
A LDLINUX.SYS that confirms to the (a) multiboot specification might
be a possibiltity to consider.
The multiboot entry point can be a different one than the normal entry
point (e.g doesn't need to load
the rest of LDLINUX.SYS from disk).

- Gert

2012/12/31 Shao Miller <sha0.miller at gmail.com>:
> 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
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
More information about the Syslinux mailing list