Re: [Etherboot-developers] [RFC] Relocation techniques...

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >For maximum flexibility the Virtual Address technique wins hands down
> >because it encompases most of the obvious effort needed to port
> >drivers to work on different cpu architectures.
> >
> >I'm still thinking about it.
> 
> With VM you could also do funky things like dynamically mapping in one
> out of a large set of drivers to reduce runtime footprint even when you
> have a lot of storage for the combined binary.
> 
> Question: what virtual address would you have Etherboot live at? Would
> it not preclude loading target code at that address range? I guess maybe
> not, you could have a different VM mapping for the target code and then
> switch it back on exiting Etherboot. Or maybe have Etherboot run in the
> highest available pages in VM and hopefully nobody ever wants to load
> target code there.

There are two possibilities, I have considered.
1) live at the end of memory.
2) If the image will overwrite etherboot, at some point stop the active
   driver relocate etherboot, and startup the everything again.

I would aim for the end of memory first, as it should be the least
contended location to work out of.

As for the virtual address it really doesn't matter, so long as the physical
one isn't a problem.  But except for a debugging build I doubt I would
use anything more than segment registers.
 
> >For me the low fruit is definitely solving the problem of compiling
> >in multiple drivers, and protocols and while still producing a working
> >binary.  For that the x86 bios calls definitely need to be clearly
> >seperated out.  (The ideal is to build a .com or .floppy image with
> >most of the drivers)
> 
> Yes, it's annoying that the BIOS calls are inline, limiting the total
> memory space of the 32-bit code to 64kB.

Definitely.  This is the first one to get.  Ideally we can leave
the BIOS code in the 16bit rom segment, and put the rest of etherboot elsewhere.

Eric