Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[<ke...@us...>]

>In this case the first 512 bytes was being placed at 0x92200.  One segment
>of the NBI file had image from 0x90200 to 0x91600 and BSS from 91600 to
>9A000, so the BSS overlapped the 0x92200 region reserved for the
>directory.

I think I understand what happened.  There is a misapprehension here
that the difference between the image length and the memory length is
the BSS.  There is no preassigned meaning such as BSS to this gap or to
any area.  The loaded areas are just areas, not necessarily code, could
be data, disk images, ramdisk, whatever.  Etherboot is just a memory
loader + a start address, not a program loader like an OS. It's not even
a Linux specific loader.  Etherboot does not zero any areas.  If in the
rare case that a segment is to zeroed before use, it should be arranged
by running code.  Disk loaders don't zero memory before loading and
neither should Etherboot.

True, the declared memory areas in the NBI image overlap, but this is a
potential overlap, there is no actual overlap in loading. In the next
version of mknbi I shall restrict the memory length of the setup segment
to 8kB. The figure of 40 or so k comes from maximum allowed to setup.S
in the Linux kernel. There's also a "overlap" between the kernel and the
initrd because I arbitrarily assigned a memory length of 16MB to the
kernel, but the initrd is loaded right after it.

The memory length is used in exactly one place in 5.0.7's osloader.c, to
compute the start address where the segment is specified to follow the
previous one.  In practice, only absolute segments have been used in
mknbi and the other three types have not turned out to be of any use
yet. So only absolute segments were supported in ELF.

I think that osloader should do overlap checking only to protect
Etherboot itself. There may be legitimate reasons why someone may want
overlapping segments (real overlap, from the image length). Etherboot
should butt out and let the user hang himself if he wants to. It's also
good to exit with an error rather than loop on a truncated image but
beyond protecting itself, Etherboot should let the user do silly things
to memory if the user wishes to.

I know Jamie Honan personally and I am sure that he was not thinking of
BSS or anything like that when he wrote the NBI spec for the first
netboot (written in MASM and supporting only the WD8003). Most likely
had a vague notion that the memory length would serve to delimit areas
without having to load all of it from the wire.