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

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On 30 Aug 2002, Eric W. Biederman wrote:
> > > > >And then the big mystery.  NBI's appear to work for you, and not for
> > > > >others.  Why and where their first packet is getting corrupted is a
> > > > >mystery.
> > > > I think it's because I'm using mkelf-linux and they are using
> > > > mknbi-linux. If that's the case then I think the FreeDOS image will crash
> > > > the same way as theirs (DOS has to be a real mode entry image).
> > > OK, there's no corruption in the first packet.  I've added a little hex
> > > dump utility to misc.c - call as hex_dump(data,len) and it'll produce a
> > > nicely formatted hex dump of an area of memory, complete with a more-style
> > > pager.  It's #ifdeffed on DEBUG_UTILS, so no worries about code bloat.
> > > Hex dump of the 512-byte data block passed to tagged_probe() shows that it
> > > is identical to the first 512 bytes of the .nbi file, so the drivers are
> > > totally ruled out as a source of the problem.
> > Then the problem is in tagged_probe?  The final segment marker does not
> > appear, and it must be in that first segment.
> > Is it simply the algorithm for incrementing sh that is incorrect?
> > Does tagged probe generate incorrect code?
> > Is the memcpy bad?
> > Sorry I am quite mystified why this doesn't work.
> 
> OK - tracked down the problem but not sure yet how to solve it.
> 
> Problem occurs when sh=0x92254, with a segment that has
> loadaddress = 0x90200, imagelength = 0x1400, memlength = 0x9e00
> 
> After prep_segment() runs on this segment, the memory at sh has been
> zeroed, hence the rest of the segment list is missing and the routine
> aborts because sh->length == 0.
> 
> It looks as though the initial calculation of tctx.segaddr must be
> incorrect; a segment wants to be loaded at a point in virtual memory that
> is already allocated.  Should prep_segment() catch this and report an
> error?

Yes.  Thinking and justifications follow.

O.k. so we have an image with overlapping segments.  The tagged image
specification does not mention them.  As the order of processing
the segments is not clearly defined we have an undefined case in
the tagged image specification.

It is quite reasonable to forbid overlapping segments, in etherboot
because it makes no sense to put complicated logic into a network
bootloader, and it makes even less sense to rely on complicated
logic being present.  The ELF spec even forbids it for normal
executables.

Given that there are bad images out there, putting detection
of them into prep_segment sounds like the only reasonable option.
I only did not do it the first time because the logic seemed
complicated, and unneeded.  If the logic gets hary we can compile it
out. 

Also mknbi needs to be fixed to generate valid images.

A quick fix that we can use to verify that everything else
is working is to comment out the memset in prep_segment.

Eric