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

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

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?

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