Syslinux - Jan 2016 - Embedding com32 modules and ldlinux.sys into one file

Good day, Tal.

Perhaps if you describe a little bit more about the rationale behind 
this single-file requirement, someone might be able to make an 
alternative suggestion that you haven't thought of.

The BIOS- and disk-based Syslinux bootstrapping actually often has a 
filesystem-specific piece of code that lives in the filesystem's 
meta-data, as well as the primary file and COMBOOT32 modules that you 
are thinking of.  Because of that first piece, it's not really possible 
to have this kind of Syslinux as a single file.

But if you were to share a few more details, perhaps you're thinking of 
a PXE environment or a CD environment or a new filesystem or...?  Are 
you able to describe the sequence of boot-up events that occur before 
the point you are thinking of?

Yes, you can print debug-output from custom builds.

-- 

Shao Miller
Synthetel Corporation
T: +1.9053927729
W: https://www.synthetel.com

On Mon, Jan 11, 2016 at 07:20:20PM -0500, Shao Miller via Syslinux
wrote:
> Good day, Tal.
> 
> Perhaps if you describe a little bit more about the rationale behind
> this single-file requirement, someone might be able to make an
> alternative suggestion that you haven't thought of.
> 
> The BIOS- and disk-based Syslinux bootstrapping actually often has a
> filesystem-specific piece of code that lives in the filesystem's
> meta-data, as well as the primary file and COMBOOT32 modules that
> you are thinking of.  Because of that first piece, it's not really
> possible to have this kind of Syslinux as a single file.
> 
> But if you were to share a few more details, perhaps you're thinking
> of a PXE environment or a CD environment or a new filesystem or...?
> Are you able to describe the sequence of boot-up events that occur
> before the point you are thinking of?
> 
> Yes, you can print debug-output from custom builds.
> 
Hi Shao

The requirement is for the bootloader to be stored on the BIOS flash chip
which will be read only.
The BIOS will be modified to load bootloader from this chip.
To simplify things and to avoid the need for a file system, I thought to
store the bootloader as a single file.
I don't reject the idea of using a very simple file-system to store the
different bootloader files and loading it into RAM.

Diving in I understand there are probably more difficulties I'll have to
face.
I'll be glad to get experts opinions and ideas about the difficulties
I'll
have to face and how to face it.

Regarding my other question (debugging). I know it is possible to use prints
for debugging.
I wonder if there is another way.

Regards,
Tal

On 01/12/16 13:21, Tal Lubko via Syslinux wrote:
> 
> Hi Shao
> 
> The requirement is for the bootloader to be stored on the BIOS flash chip
> which will be read only.
> The BIOS will be modified to load bootloader from this chip.
> To simplify things and to avoid the need for a file system, I thought to
> store the bootloader as a single file.
> I don't reject the idea of using a very simple file-system to store the
> different bootloader files and loading it into RAM.
> 
The "single file" you describe *is* a filesystem.  Currently the
simplest such filesystem we have support for is iso9660, but that is
very space-inefficient.  Thus, it might be a good idea to add support
for a very compact and maybe even compressed filesystem.

	-hpa

2016-01-12 22:21 UTC+01:00, Tal Lubko via Syslinux <syslinux at
zytor.com>:
> On Mon, Jan 11, 2016 at 07:20:20PM -0500, Shao Miller via Syslinux wrote:
>> Good day, Tal.
>>
>> Perhaps if you describe a little bit more about the rationale behind
>> this single-file requirement, someone might be able to make an
>> alternative suggestion that you haven't thought of.
>>
>> The BIOS- and disk-based Syslinux bootstrapping actually often has a
>> filesystem-specific piece of code that lives in the filesystem's
>> meta-data, as well as the primary file and COMBOOT32 modules that
>> you are thinking of.  Because of that first piece, it's not really
>> possible to have this kind of Syslinux as a single file.
>>
>> But if you were to share a few more details, perhaps you're
thinking
>> of a PXE environment or a CD environment or a new filesystem or...?
>> Are you able to describe the sequence of boot-up events that occur
>> before the point you are thinking of?
>>
>> Yes, you can print debug-output from custom builds.
>>
>
> Hi Shao
>
> The requirement is for the bootloader to be stored on the BIOS flash chip
> which will be read only.
> The BIOS will be modified to load bootloader from this chip.
> To simplify things and to avoid the need for a file system, I thought to
> store the bootloader as a single file.
> I don't reject the idea of using a very simple file-system to store the
> different bootloader files and loading it into RAM.
>
> Diving in I understand there are probably more difficulties I'll have
to
> face.
> I'll be glad to get experts opinions and ideas about the difficulties
I'll
> have to face and how to face it.
>
> Regarding my other question (debugging). I know it is possible to use
> prints
> for debugging.
> I wonder if there is another way.
In qemu it is possible to have source-level debugging, all you need to
know is the address at which the code is loaded to tell gdb where to
relocate the debugging symbols.

On real hardware, I think there's a support for serial port, but I've
never used it.

On Tue, 12 Jan 2016, Tal Lubko via Syslinux wrote:
> The requirement is for the bootloader to be stored on the BIOS flash chip
> which will be read only.
> The BIOS will be modified to load bootloader from this chip.
Have you looked at Coreboot.org and its payloads? It sounds similar to 
what that is aimed to do.

Regards,
BALATON Zoltan