ollie lho <[EMAIL PROTECTED]> writes: > On Fri, 2002-06-21 at 13:19, Eric W. Biederman wrote:
> > 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 ?? I was thinking relocate it, or dumping at the last moment. One of those will work :) > > 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. Hmm. LinuxBIOS has been relocating itself to the top of memory for a fairly long while now just before calling the bootloader. The only exception is the LinuxBIOS table. > 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. That could be helpful. > > 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 ?? Check out memtest86-3.0. In particular reloc.c and the Makefile. It is very non-intrusive. Basically compile with -fPIC to reduce the number of relocations needed. Link with -Bsymbolic and -shared to build an object that can be relocated. Have your own relocator (see reloc.c) Do objdump -binary to dump the memory image. I'm about an inch from writing a special linker just for that case, because it is very handy functionality. Eric
