Re: [Etherboot-developers] Porting question

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

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

> Eric W. Biederman wrote:
> 
> >May I ask which RISC processor you are using?
> >
> Ok, the processor is Hyperstone's E132-XS (http://www.hyperstone.com).
> Actually we have a project to port Linux to the aforementioned
> processor. Currently, we have done almost everything done in the architecture
> dependent part of the kernel and we are working on the libc as well as on the
> executable file loader (the processor doesn't have an MMU so we are following
> the uClinux aaproach).
> 
> The problem that arises is that the kernel needs almost 3-4 minutes to download
> through the serial port which imposes us a significant delay. This is the reason
> why we started looking into the etherboot.

That makes sense.
> 
> >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.
> >
> You are not exactly right :-) When using the uClinux approach there is no need
> to have ELF capable tools. This is due to the fact that all the executables have
> to be converted to the "flat" file format before executing them. So even if you
> had ELF tools you still have to convert to the "flat" file format.

I guess I was thinking that multiple sections were needed for the kernel
to build correctly.  There are several tables in the kernel build that
are build as ELF sections, and gradually accumulated.

The "flat" file format makes sense.  Though there is no reason an ELF
loader would not work as well.  But it may not be the best fit for the
problem.  And I certainly seem to remember uClinux using a different 
methodology.

 
> >>>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.
> >
> Yes this is exactly what I thought, still the driver needs a little bit of
> hacking because there is no provision for implementations without an EPROM (most
> embedded systems do not include a ROM to store the onfiguration data like the
> standard NICs do).

That makes sense.  Still it should not be to difficult.
Probably a special build option that hard codes the result of
the eeprom probe would be a good fit.
 
> I will keep you inform on the progress of my work but most probably prior to
> this I will come back with more questions :-)

Questions we can answer. :)

Eric