Re: [Etherboot-developers] Bugfixed PXE

[Marty C. <md...@th...>]

On 6/27/2001 4:25 PM Peter Lister P.L...@sy... wrote:
>OK, I found the magic numbers. :)

Give that man a prize!  Congrats!!
(I knew you'd figure it out :-)

>Had this just been affecting the ZLOADER, I would probably have left it,
>but I was getting weird hangs and crashes on our Supermicro boxes with
>Intel chips, even without ZLOADER, and I really have to get those going.

Necessity is a mother :-)

>Well, turns out that main.c uses the rom_info structure, BUT there are
>no obvious cues that rom_info in main.c and ROM_SEGMENT in loader.S are
>the same place. Just some absolute values - one in hex and the other in
>decimal - and different names (c.f. _start, used in both - but which
>really *is* different).

This is good information.  I am attempting to document parts of 
Etherboot, and I really appreciate your time on this.

>Vasil's original patch did actually allocate some space at the end of
>pxeloader.S for ROM_SEGMENT, but this broke when using ZLOADER, so I
>ifdef'd out the ROM_SEGMENT / ROM_LENGTH code, as it seemed to have no
>useful function, and we're not using a floppy, right? I was also worried
>by the fact that something was obviously being poked into somewhere I
>didn't understand.

Seems like a reasonable thing to do.

>So my fault for removing code without understanding the implications.
>BUT Etherboot didn't make it easy for me; this needs to be cleaned up
>and documented by someone who genuinely understands which way is up. It
>took me a *long* time to work out what was happening. Where *should*
>ROM_SEGMENT really be? Has Etherboot been poking into some random space
>and just been lucky until now?

I don't know if anyone at this moment understands this better, though I'm 
attempting to.  I suspect right now, each of us does what you just did.  
We spend a few long days and nights, figure things out, and post them.  
That's one reason Ken and I insist that people (as a general rule) 
respond to the lists rather than only sending us personal mail, so that 
stuff gets into the archives where we can search it, and so that others 
can contribute wisdom to the conversation.  (obviously sometimes private 
mail is required, but as the exception).

>I have reinstated the ROM_SEGMENT code, and the 2 data words just
>afterwards, conveniently before the ZLOADER code. I *believe* that I'm
>doing the right thing in properly allocating space, and so have NOT put
>the words in #ifdef PXELOADER/#endif. The assembler is happy, though it
>inflates the raw binary size a bit. Since we can now compress, I am not
>bothered.
>And - happy happy joy joy - I now get sensible numbers like
>(eepro100) ROM segment 0x07C0 length 0x3000 reloc 0x9400
>(3c90x)    ROM segment 0x07C0 length 0x5000 reloc 0x9400
>and ZLOADER is OK, once I fixed makerom to round UP the sizes.

Yes!  And this might also explain a problem I was having with LOADLIN.  
Each bit of knowledge added helps.

>The *correct* thing to do here, is - I believe - to stop using the 506
>offset unless we really and truly ARE providing floppyness to the
>outside world, and shove the data words just after the 3rd byte. This
>entails tweaking other code, however, and I do not claim to understand
>what is going on.

I will look at this.  As you've noticed there are so many interconnected 
parts and constraints with Etherboot that one must be careful in changing 
one part (especially low-level parts) without considering the 
ramifications to other parts.  The win is that since we all have the 
code, we can help each other and enlist the help of others when we get 
stuck.

>So - here's the new improved pxeloader, Makefile which now builds it
>with -DPXELOADER, and makerom which rounds up the size properly. The
>number of patch sections in pxeloader.S is now down to 4 PXE related and
>one for the ROM_SEGMENT; it should now be easy to retire pxeloader.S and
>merge back into loader.S. Patch relative to 5.0.2.
>Enjoy.

Excellent!  And I owe you and Vasil a beverage when we meet :-)

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/