Booting VxWorks from LinuxBios

[Eric W. Biederman]

Felix Radensky <felix at allot.com> writes:

> Eric W. Biederman wrote:
> 
> >Basically to load vxworks at 0x8000 you just need an ELF
> > header that says load me here.

> Is this going to work even if LinuxBios itself uses memory
> at 0x8000 ? 

Essentially yes, it will either work or refuse to load.
I do not think the LinuxBIOS tables extend that far up into
memory which is the only case it would refuse to load the image
for.  The LinuxBIOS code itself is copied to the top of memory
before the image is loaded, so it does not get in the way.

> In my current setup (without USE_ELF_BOOT)
> decompression of VxWorks boot loader fails at 0x8000 but
> succedes at 0x100000.
> 
> Can elfboot handle compressed images ?

Yes, you put a self decompresser in the image. 

>  I'll gladly provide a patch for mkelfimage, but I'll need
> some basic guidance, as I'm not familiar with internals
> of ELF format. Eric, can you please recommend some
> docs and code to look at, so I can get familiar with the format.

First there is nothing special about mkelfImage.  It is just
a repository for the code to convert various types of images
into a format the elf loader can handle.  For each different
image type there is a whole different set of code.

The easy reference to come by is /usr/include/elf.h

Basically there is an ELF header Elf32_Ehdr/Elf64_Ehdr followed by a
program header.  Elf32_Phdr/Elf64_Phdr.  Followed by the data to load
into memory.

The Ehdr reports what kind of elf image you have 32bit or 64bit,
little endian or big endian, which architecture the code is for
where the entry point is, and how many phdrs you have.

Each phdr describes a chunk of the image, and specifies where in
memory to load it.  

The ELF structures are a little verbose, but not prohibitively so,
and allow a clean way of specifying what to load and where.  The
elf loader is simply a mechanism where the LinuxBIOS can provide
a fixed interface, and the rest of the OS's can come to that one
interface with just a little bit of glue code.

> > And probably a bit
> >of adapter code that switches from 32bit protected mode
> >to 64bit protected mode.
> >
> >
> >
> This sounds a bit cryptic to me. Can you please elaborate on that.

Don't worry about it, I am working on Hammer stuff at the moment,
and parts of my brainstorming on how to handle the issues raised by
a 64bit port keep spilling out... 

Eric