Thread: [Etherboot-developers] Porting question
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: Yannis M. <gm...@te...> - 2003-02-19 20:30:09
|
Hi all, I will try to strip-down the etherboot source code in order to make it work in an evaluation board of a RISC processor. The GNU tools that I have produce coff executable file format. From a first look inside the etherboot code I noticed that you support both ELF and a.out. Since you do not use the bfd library, do you have estimation how difficult would be to modify the bootloader accordingly? Regards Yannis |
|
From: <ebi...@ln...> - 2003-02-20 02:44:30
|
Yannis Mitsos <gm...@te...> writes: > Hi all, > > I will try to strip-down the etherboot source code in order to make it work in > an evaluation board of a RISC processor. Etherboot needs to be stripped down? It should be possible to take the 5.1.x source and to do a real port. The tricky bits I see are the self decompresser, which is a screen Some support code like setjmp and longjmp. 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. 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. > The GNU tools that I have produce coff > executable file format. From a first look inside the etherboot code I noticed > that you support both ELF and a.out. For building etherboot it should be pretty much of a non-issue. > Since you do not use the bfd library, do you have estimation how difficult would > be to modify the bootloader accordingly? It would not be hard. Maybe a days work including debugging. The challenge with COFF and a.out there are several variants and you would need to track down which variant you are using. For a format to loader over the network COFF bootloader format ELF is nicer as it is a stable format. 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... Eric |
|
From: Yannis M. <gm...@te...> - 2003-02-21 10:05:37
|
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. >It should be possible to take the 5.1.x source and to do a real port. > Yes this is what I am doing... >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 >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... > >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 :-) >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. Regards Yannis |
|
From: <ebi...@ln...> - 2003-02-21 19:59:59
|
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 |
|
From: Yannis M. <gm...@te...> - 2003-02-23 21:29:36
|
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. >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. >>>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). I will keep you inform on the progress of my work but most probably prior to this I will come back with more questions :-) Regards Yannis |
|
From: <ebi...@ln...> - 2003-02-24 00:41:36
|
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 |
