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

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.

>>>
> Regarding my other question (debugging). I know it is possible to use
> prints
> for debugging.
> I wonder if there is another way.
...
On real hardware, I think there's a support for serial port, but I've
never used it.

<<<

I have used serial port debugging under VMware redirecting the VM COM to a pipe
and attaching a terminal emulator to it. 

Please consider using  serial port debugging (any kind of debugging) affects 

timing, then you could very well mask certain issues or even create some others
when testing time sensitive code (i.e. networking stuff).

Best,
Patrick

> -----Original Message-----
> From: Celelibi [mailto:celelibi at gmail.com]
> Sent: Wednesday, January 13, 2016 2:22 AM
> To: Tal Lubko
> Cc: Shao Miller; For discussion of Syslinux and tftp-hpa
> Subject: Re: [syslinux] Embedding com32 modules and ldlinux.sys into
> one file
> 
> 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.
OK. I'll try that.
Any thoughts regarding the requirement to store the bootloader inside the BIOS
chip?

On 01/13/16 00:13, Tal Lubko via Syslinux wrote:
> 
> OK. I'll try that.
> Any thoughts regarding the requirement to store the bootloader inside the
BIOS chip?
> 
That is fundamentally up to your BIOS.  The best is to expose the
bootloader in the BIOS as a (readonly) disk drive using standard BIOS or
EFI interfaces.

	-hpa