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

[Michael B. <mb...@fe...>]

On 30 Aug 2002, Eric W. Biederman wrote:
> > > 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.

These are bad images that work with Etherboot 5.0.x, however.  I think it
would be best to try to ensure that any image that worked with Etherboot
5.0.x also works with 5.1.x.

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

Already tried this and it gets one stage further.  There's still one
(hopefully final) obstacle: although the image is now loaded correctly, it
never gets executed because tagged_download() never gets called after EOF.

Under 5.0.x, os_download() got called one final time after EOF.  Have
re-added this code to osloader.c and am in process of testing and checking
in...

Michael Brown
http://www.fensystems.co.uk