Re: [Etherboot-developers] Porting question

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

Yannis Mitsos <gm...@te...> writes:

> Hi Eric,
> 
> Thank you for your answer.
> 
> >Etherboot needs to be stripped down?
> >
> It was a wrong phrase of mine. I mean that I am trying to comment-out everything
> related to x86.

As Ken has already pointed out this has already been done.
I admit there a few small bits left but those are all covered by config options,
and so they should be noops.

If you find something you need to change let us know.  For 5.1.x it should
be feasible to properly modify the core.

> >It should be possible to take the 5.1.x source and to do a real port.
> >
> Yes this is what I am doing...

Nice.  It will be a pleasure to see it.
 
> >The tricky bits I see are the self decompresser, which is a screen
> >Some support code like setjmp and longjmp.
> >
> For the time being I am commenting these out and I will figure out later what I
> will do with those

O.k. Sounds good.

> >And whatever you need for platform support.
> >Any big endian issues that may come with your RISC processor.
> >Any firmware/hardware interfacing issues you may have.
> >
> Actually the processor utilizes a big-endian scheme for its memories...

Which is what I meant x86 and ia64 are both little-endian.  So there
may be a bug or two.

May I ask which RISC processor you are using?

I am trying to think of a RISC processor that only has COFF support
in binutils.  I know linux won't build without ELF support.  So I
don't know which embedded OS the board is targeted for.

> >Etherboot is already running on the Itanium so 64bit issues, and
> >alignment issues are already sorted out.  Though not all of the
> >drivers have been tested.
> >
> I need only the well-konwn cs89x0 driver :-)

That makes it easy then.

> >I would recommend writing a mkelf for your platform that packages
> >kernels ramdisks and everything together, instead of adding a COFF
> >handler.  But it is your port...
> >

> This is not very clear to me. Initially I will try to add the COFF loader and if
> it is not possible I will come-back again.

Let me see if I can clarify this a bit.

In practice it usually happens that the kernel, a ramdisk and a command line
all need to be loaded into memory where the kernel can access them.

The etherboot recommended way is to create an external utility that combines
all of these into an ELF executable.  For linux on x86 normally
mkelf-linux is used to accomplish this task.  So the recommendation is
to write the companion utility mkelf-arch-os for your embedded
platform.  This is useful because this allows the same firmware to
load multiple OS's.  Which is the primary point keeping OS details
out of etherboot, as much as possible.

ELF was picked because it is stable cross platform file format, that
cleanly handles both 32bit and 64bit executables, and has enough
flexibility so OS peculiarities can be kept out of etherboot.  Instead
we have stub added by mkelf-linux and it's companions to handle the
weird stuff.

Eric