Re: Re[2]: [Etherboot-developers] Q: does xstart work?

[Eric W B. <ebi...@ln...>]

Anselm Martin Hoffmeister <an...@ho...> writes:

> Hello Eric, list,
> 
> EWB> Probably the fun part is keeping track of which areas have been allocated
> EWB> to the partially loaded image.
>  
> >> I'm not so concerned about the text segment size of Etherboot when
> >> Etherboot is converted to run high. In the current version the main
> >> concern is the 48kB limitation. I think there are few machines that
> >> can't spare a couple of hundred kB from the top of memory during the
> >> image loading phase.  One is not supposed to load memory to brim anyway,
> >> Linux will need room to expand when it gains control.
> 
> EWB> Except when you have a ramdisk.  But a sane implemenation will load
> EWB> the ramdisk low, and then push it up higher if required.  Though I seem
> EWB> to like the insane varieties.
> 
> As I see it, Eric, you used the last room for just beyond land's end
> for SLAM downloaded data stuff. BTW, I copied that idea, so the last
> [image-block-num]*[image-block-size] bytes of memory are used for that
> purpose in TFTM too. No problem to spare the last say 300kB, but one
> must not forget!

Agreed.  That has been a FIXME in my code for a while.  Getting 
etherboot to relocate itself was the interesting part of this adventure.
When I get the code checked in there will be a lot of small little
fixes that need to propogate through etherboot to fix this.

Unless the multicast file has always loads into a fixed offset in ram
there is a tradeoff between scaleability and memory usage.  And I really 
don't see a practical way to fix that.  In the normal case of
increasing offsets going to increasingly higher addresses in ram the
the memory overhead actually becomes a constant.  This is because you
can overwrite memory that you have already loaded to it's final
location.

Eric