On Fri, 2002-06-21 at 13:19, Eric W. Biederman wrote:
> > I am also think about implementing a general purpose bootloader
> > from scratch. Unfortunately, I crashed my HD last week so I have
> > to redesign it all over again.
> 
> Ouch!
>  

Yea, I also lost my preliminary clock gen stuff.

> Actually that should work.  We might have to double check that we ignore
> unknown program segments but yes.
>  
> > I got this problem because our in-house etherboot is getting
> > bigger and bigger, and Linux/WinCE have different concept about
> > "reserved memory".
> 
> :)  
> The other solution is to get etherboot out of the way.  There has been
> some discussion about how to do that on the etherboot-developers list,
> but it hasn't been implemented yet.
> 

Does "get xxx out of the way" mean "dump it" or something else ??

> What kind of concept does WinCE have of reserved memory.  My gut
> impression is to just have etherboot move itself to the top of memory,
> but if it gets to big, that may be an issue. 
> 

Actually nobody knows for sure. It seems that both WinCe 3.x and 4.X
consider memory below 1 MB as reserved. From our experiments, WinCE 3.x
and 4.x have very different memory layout above 1MB. Memory below 1
MB is already used by LinuxBIOS which left little room for Etherboot. 
This makes it very difficult to build a etherboot image such that it
can be used for Linux and WinCE 3.x/4.x. So I was thinking if the .text
and .rodata section can be made XIP in flash, we only need a few KBs for
other sections in RAM.

> For the systems I work with I have issues like: how do I make the full
> 4GB of ram plugged into this machine available to the kernel.  So I
> really don't have a feel if consuming an extra 300k-400k at the top of
> memory would be a problem.
> 
> I currently have a solution in memtest86 that allows for arbitrary
> relocation, by making the application a shared library.  The problem
> is I can't remove the useless strings for all of the global variables,
> so it bloats this a little bit.  It is still better than having two
> copies of the application like memtest86 did. 
> 

I think putting etherboot at top of RAM is a good idea, the problem
is how can we do this kind of PIC/Dynamic Relocatable stuff ??

Ollie


Reply via email to