etherboot-developers — Discussion of developer issues

[Etherboot-developers] Award BIOS and int 18h problems

[Michael B. <mb...@fe...>]

I'm having major problems with Award Modular BIOS v6.00PG and the latest
Etherboot 5.0.8.  Booting from the network works fine; the problem is when
you choose "(L)ocal" and attempt to boot from the hard disk instead.  It
displays the message "PRESS A KEY TO REBOOT" and stops.

This occurs only when booting from a real EPROM (.lzrom).  Booting the
exact same code from a floppy (.lzfd0) has no problems.

I've been working back through the code, adding exit points at various
stages.  I'm now at the stage that loader.S executes an int 0x18 as soon
as the BIOS calls its Boot Execution Vector.  This was achieved with the
following modification to loader.S:

        .word 0x0000                    /* boot connection vector */
        .word 0x0000                    /* disconnect vector */
-       .word pnpentry
+/*     .word pnpentry */
+       .word pnpreturn
        .word 0x0000                    /* reserved */

i.e. the BEV points to pnpreturn instead of pnpentry.  pnpreturn contains
simply:

pnpreturn:
	int	$0x18			/* As per BIOS Boot Spec, next dev */


Even with this modification, the machine *STILL* fails with the "PRESS A
KEY TO REBOOT" message.

"Aha," I thought.  Maybe the implementation of int 0x18 is screwed in this
BIOS.  So I tried adding a second HDD.  Both HDDs have a standard DOS MBR
and DOS partition tables.  By deactivating the boot partition on one
drive, I can make the BIOS fall through and try the next drive.  This, as
far as I am aware without disassembling the MBR, involves the same int
0x18 mechanism.


As far as I can tell from reading around, there are no preconditions on
calling int 0x18 other than that "data areas such as the interrupt vector
table, the BDA, and the Extended BIOS Data Area must remain unchanged
[from when the BEV was called]".  Since by BEV is currently pointing
straight to an int 0x18 instruction, it's hard to see where I might be
violating this requirement.

The most annoying aspect of this is that the only to test code changes is
to burn them into silicon, and I don't have an EPROM eraser...

Any ideas are more than welcome.

Michael

Re: [Etherboot-developers] Porting question

[<ke...@us...>]

>>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.

Still the wrong idea. You shouldn't need to do that. Eric has done a
brilliant job separating out the non-architecture specific components
from the architecture specific ones. Ideally you should only need to
create a new branch in arch and new config files at the top level.  If
not tell us what needs to be fixed.

>>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.

Whatever loader format you choose, it has to have some kind of directory
at the beginning to indicate where the pieces go in memory. Etherboot
supports NBI and ELF. Instead of writing COFF support, try to see if you
can write an ELF generator, then you don't need to implement it in
Etherboot since it already has an ELF loader. You may need to write a
custom one anyway because of the need to load ramdisks.

Re: [Etherboot-developers] Porting question

[Yannis M. <gm...@te...>]

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

Re: [Etherboot-developers] Universal auto-probing driver

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

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

> >When built on my machine:
> >etherboot.o        is 231245 bytes
> >etherboot-pci.o    is 171370 bytes
> >etherboot.img      is 183444 bytes
> >etherboot.zimg     is  84581 bytes
> >etherboot-pci.img  is 140628 bytes
> >etherboot-pci.zimg is  75420 bytes
> >...
> >So I guess the next step is to look at the floppy loader and see
> >what can be done about this so mere mortals can load super etherboot
> >images.
> 
> Unless boot1a.s is made smarter, the limit it can load is 128 kB because
> it takes the number of 512 byte sectors to load from the length byte in
> the "ROM" image. It could be made smarter to look inside the PCI header
> which uses a short to hold the number of sectors. But that would
> probably require a second stage loader.

That is fine.  None of the compressed images exceed 128KB.
The problem I had was a read error at the end.  So either
I had a bad floppy, which read back o.k. before I tried it.
Or there was a checksum error.

Eric

Re: [Etherboot-developers] Universal auto-probing driver

[<ke...@us...>]

>When built on my machine:
>etherboot.o        is 231245 bytes
>etherboot-pci.o    is 171370 bytes
>etherboot.img      is 183444 bytes
>etherboot.zimg     is  84581 bytes
>etherboot-pci.img  is 140628 bytes
>etherboot-pci.zimg is  75420 bytes
>...
>So I guess the next step is to look at the floppy loader and see
>what can be done about this so mere mortals can load super etherboot
>images.

Unless boot1a.s is made smarter, the limit it can load is 128 kB because
it takes the number of 512 byte sectors to load from the length byte in
the "ROM" image. It could be made smarter to look inside the PCI header
which uses a short to hold the number of sectors. But that would
probably require a second stage loader.

Re: [Etherboot-developers] Wanted -the sis900 etherboot developer

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

stanimir <st...@fb...> writes:

> I noticed that etheboot driver recognise the sis900 PHYtransiver as VIA 6103,
> but the linux driver says - UNKNOWN PHYTRANSIVER and continues booting and
> working but with that terribly slow speed.
> I'm not C coder, but when I browsed sis900.c file in all linux modiles, which I
> managed to find in SIS web site and in kernel.org, I noticed that there is
> missing the code considering VIA 6103 PHYtransiver.
> Only the etherboot driver sis900.c has rows in the sorce code describing it.
> Can this be the answer of that network speed slowdown?

Perhaps.  I would suggest building a very large image say 30Megs, timing it.
Is etherboot faster than 1mbit a second?  Maybe it just prints the name.

I haven't a clue what the difference is.

Eric

Re: [Etherboot-developers] Universal auto-probing driver

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

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

> >it build a big etherboot.o file (140kb), but the etherboot.zdsk is 36
> >kb.... it semms too short!
> >
> >Booting, it write some number and then "err"....then it halts....
> 
> Ah, you've found a bug. The Makefile rule for .z?dsk pads the output to
> a full track on floppy, but assumes that no driver is > 36kB.  Obviously
> we weren't looking far ahead enough. Ditto for the .z?lilo rule.
> makerom.pl also has to be updated.
> 
> Fixed in the CVS.

We have progress.

But it appears there is still a bug in the dsk loader with
respect to large images.

I have just tested the silly case of make etherboot.elf etherboot
can successfully load the generated binary.

There was a strange bug in genrules.pl that did not add all of the
pci drivers to the list of drivers in etherboot.o and that is now
fixed.

In addition I have now added a rule for etherboot-pci.o which
is just the pci drivers.  It does not add a lot but it does mean
you don't get caught in the 3c509 drivers 4000 attempts to probe the
card, nor any other bad pci probe.

When built on my machine:
etherboot.o        is 231245 bytes
etherboot-pci.o    is 171370 bytes
etherboot.img      is 183444 bytes
etherboot.zimg     is  84581 bytes
etherboot-pci.img  is 140628 bytes
etherboot-pci.zimg is  75420 bytes

I have just updated the CHECKSIZE rule to make certain etherboot
loaded at RELOCADDR will be below 640K, including the bss segment.
Possibly this is a little too liberal but... We are so close
that etherboot.zelf does not load because it would uncompress
and exceed the 640K limit. 

So yay the code works.  Boo except loading etherboot from etherboot
it is useless at the moment.

So I guess the next step is to look at the floppy loader and see
what can be done about this so mere mortals can load super etherboot
images.

Anyway it is time for me to stop programming for the night, this was
a fun diversion but...

Eric

Re: [Etherboot-developers] tg3 progress...

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

ebi...@ln... (Eric W. Biederman) writes:

> Well I instead made the code work so I could be more certain
> of my cutting so I have a working driver in:
> 3726 lines of code.
> 
> Hopefully tomorrow I can find something to prune away.  It looks like I must
> trim it with a thousand cuts, so...

One little snip at a time.  I have done the basic analysis and know where
the big chunks of code are, and have just started the small snips to
make the driver smaller.  I have the code down to  3458 lines of
code and reduced in size by a 1/2 or so.

The only thing I can really do is change code that says:
if (x) bug_fix_y(); to bug_fix_y(); Though there are
a few other things.

In another week I might even have a small comprehensible driver.

Eric

[Etherboot-developers] [COMMIT] TG3 driver and Miscelanous bug fixes.

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

- A working tg3 driver
- Itanium bug fixes
- 486 booting bug fixes
- New driver method of specifying supported pci nics.
- misc bug fixes

So many things have collected in my tree I can barely keep track
but they are all pushed to the main etherboot cvs tree now.

Eric

Re: [Etherboot-developers] Universal auto-probing driver

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

Vasil Vasilev <vas...@sy...> writes:

> On Wed, 19 Feb 2003, Peter Lister wrote:
> 
> >
> > [Sorry, if I said this before ]
> >
> > PXE users are more likely to want a pre-built binary (e.g. pxelinux is
> > generally distributed prebuilt). An all-drivers image would be a useful
> > default for PXE users; Etherboot image is tftped, PXE users are not
> > significantly affected by image size.
> 
> PXE actually has a limit of 32K for the size of the first downloaded image
> (NBP as they call it).

On Itanium it is not quite so limited but the PXE stack also can't
handle loading anything large, so you always need a NBP.

Eric

Re: [Etherboot-developers] Wanted -the sis900 etherboot developer

[Michael B. <mb...@fe...>]

> >Please, I am not C coder, but I'm not too bad Delphi programer. If
> >somebody can add the VIA6103 into the linix sis900 module in 1 hour, and
> >it's working?  It will not be only me who will get the advantage of this
> >driver, but a lot of people as well. Thouse PCCHIPS MB are widely sold
> >in the UK.
> Well does someone want to do it for the glory of having their name in
> the kernel contributor list? I'm up to my neck here.

We can offer this as a commercial service.  Please contact me off-list if
you want to discuss it.

Incidentally, we can also supply BootROMs (with or without NICs) in the
UK.

Michael

Re: [Etherboot-developers] Universal auto-probing driver

[<ke...@us...>]

>it build a big etherboot.o file (140kb), but the etherboot.zdsk is 36
>kb.... it semms too short!
>
>Booting, it write some number and then "err"....then it halts....

Ah, you've found a bug. The Makefile rule for .z?dsk pads the output to
a full track on floppy, but assumes that no driver is > 36kB.  Obviously
we weren't looking far ahead enough. Ditto for the .z?lilo rule.
makerom.pl also has to be updated.

Fixed in the CVS.

Re: [Etherboot-developers] Wanted -the sis900 etherboot developer

[<ke...@us...>]

>Please, I am not C coder, but I'm not too bad Delphi programer. If 
>somebody can add the VIA6103 into the linix sis900 module in 1 hour, and 
>it's working?  It will not be only me who will get the advantage of this 
>driver, but a lot of people as well. Thouse PCCHIPS MB are widely sold 
>in the UK.

Well does someone want to do it for the glory of having their name in
the kernel contributor list? I'm up to my neck here.

Re: [Etherboot-developers] Wanted -the sis900 etherboot developer

[stanimir <st...@fb...>]

Ken Yap wrote:

>Hmm, the 6103 code was contributed by Andrew Ip according to the LOG. If
>it isn't in the Linux driver, it would be the first time I've heard that
>Etherboot code is ahead of the Linux code.
>
Apparently Etherboot project again proof its quality. :)

> But maybe you're not looking
>at the latest kernel sources?
>
Accordning kernel.otg the latest kernel is 2.5.62. I extracted the 
sis900 source and compiled with 2.4.20 kernel. Guest what - NOTHING.

> Also have you contacted SiS? They are a
>Linux-supporting company and may already have done the changes.
>  
>
The drivers in SIS official site are older the my grandmam.

>If not, I don't think it's difficult to add another PHY to the driver,
>but unless it hasn't already been done, you'd have problems getting the
>change accepted by the Linux kernel coders.
>  
>
I think so as well.

>  
>
>>I would rather pay for the development of Linux driver, then to buy 30 
>>new LAN cards.
>>Noble of you but sadly, no guesses which option is cheaper.
>>    
>>
Please, I am not C coder, but I'm not too bad Delphi programer. If 
somebody can add the VIA6103 into the linix sis900 module in 1 hour, and 
it's working?  It will not be only me who will get the advantage of this 
driver, but a lot of people as well. Thouse PCCHIPS MB are widely sold 
in the UK.

Re: [Etherboot-developers] Wanted -the sis900 etherboot developer

[Markus G. <ma...@gu...>]

RTL8139 based NIC cards can be had for less than $5 (search on 
www.froogle.com or www.pricewatch.com). For 30 cards, you can probably 
negotiate a price of less than $150 including shipping and tax.

These cards aren't the fastest, but they definitly can do better than 1 
Mbps.

Given this low price, it might be more cost-effective to just buy the cards.


Markus

stanimir wrote:
> Hi everybody,
> I'm an old etherboot user and a LTSP project fen.
> Recently we deployed 30 workstation - thin clients in an UK school.
> The MB are PCCHIPS M810 (no Linux support) - all-in-one, the integrated 
> LAN adapter is sis900,the etherboot 5.0.8 driver recognise it as sis900 
> with VIA 6103 PHYtransiver.After flashing the bios with the etherboot 
> image the system boots up perfectly. But the performance in linux is 
> terrible. I tryed everything, change the switch, test with crossover 
> cable directly to the server, change the server, change the linux 
> distro, test 5-6 different sis900 drivers, change the LTSP kernel, 
> recompile several times the LTSP kernel with different sis900 drivers, 
> change BIOS setings- NOTHING!
> I repeat NOTHING!!!
> The network performance is still teriblle - aldo the switch lights 
> indicate 100mMbits - full duplex, by my opinion the net speed is no more 
> then 1Mbits - half duplex.
> When turn off the onboard card and put any other 100mbits card - 
> everything is just fine.
> I noticed that etheboot driver recognise the sis900 PHYtransiver as VIA 
> 6103, but the linux driver says - UNKNOWN PHYTRANSIVER and continues 
> booting and working but with that terribly slow speed.
> I'm not C coder, but when I browsed sis900.c file in all linux modiles, 
> which I managed to find in SIS web site and in kernel.org, I noticed 
> that there is missing the code considering VIA 6103 PHYtransiver.
> Only the etherboot driver sis900.c has rows in the sorce code describing 
> it.
> Can this be the answer of that network speed slowdown?
> I read that etherboot driver are coded from normal linux drivers, but 
> apparently I can not find one with VIA6103 PHYtransiver support.
> 
> Please, if you can help, contact me as soon as possible.
> 
> I would rather pay for the development of Linux driver, then to buy 30 
> new LAN cards.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Wanted -the sis900 etherboot developer

[<ke...@us...>]

>I noticed that etheboot driver recognise the sis900 PHYtransiver as VIA 
>6103, but the linux driver says - UNKNOWN PHYTRANSIVER and continues 
>booting and working but with that terribly slow speed.
>I'm not C coder, but when I browsed sis900.c file in all linux modiles, 
>which I managed to find in SIS web site and in kernel.org, I noticed 
>that there is missing the code considering VIA 6103 PHYtransiver.
>Only the etherboot driver sis900.c has rows in the sorce code describing it.
>Can this be the answer of that network speed slowdown?
>I read that etherboot driver are coded from normal linux drivers, but 
>apparently I can not find one with VIA6103 PHYtransiver support.

Hmm, the 6103 code was contributed by Andrew Ip according to the LOG. If
it isn't in the Linux driver, it would be the first time I've heard that
Etherboot code is ahead of the Linux code. But maybe you're not looking
at the latest kernel sources? Also have you contacted SiS? They are a
Linux-supporting company and may already have done the changes.

If not, I don't think it's difficult to add another PHY to the driver,
but unless it hasn't already been done, you'd have problems getting the
change accepted by the Linux kernel coders.

>I would rather pay for the development of Linux driver, then to buy 30 
>new LAN cards.

Noble of you but sadly, no guesses which option is cheaper.

But please go back and check if it really isn't in the very latest
kernel sources. Try 2.5 sources if you have to.

Re: [Etherboot-developers] Universal auto-probing driver

[Alke <al...@io...>]

Mmmmm...

I've tried "make bin/etherboot.zdsk", nut it doesn't work....

it build a big etherboot.o file (140kb), but the etherboot.zdsk is 36
kb.... it semms too short!

Booting, it write some number and then "err"....then it halts....

...some helps?????


"Eric W. Biederman" ha scritto:
> 
> Peter Lister <P.L...@sy...> writes:
> 
> > [Sorry, if I said this before ]
> >
> > PXE users are more likely to want a pre-built binary (e.g. pxelinux is
> > generally distributed prebuilt). An all-drivers image would be a useful
> > default for PXE users; Etherboot image is tftped, PXE users are not
> > significantly affected by image size.
> 
> make etherboot.??? whatever should work.
> 
> Eric

[Etherboot-developers] Wanted -the sis900 etherboot developer

[stanimir <st...@fb...>]

Hi everybody,
I'm an old etherboot user and a LTSP project fen.
Recently we deployed 30 workstation - thin clients in an UK school.
The MB are PCCHIPS M810 (no Linux support) - all-in-one, the integrated 
LAN adapter is sis900,the etherboot 5.0.8 driver recognise it as sis900 
with VIA 6103 PHYtransiver.After flashing the bios with the etherboot 
image the system boots up perfectly. But the performance in linux is 
terrible. I tryed everything, change the switch, test with crossover 
cable directly to the server, change the server, change the linux 
distro, test 5-6 different sis900 drivers, change the LTSP kernel, 
recompile several times the LTSP kernel with different sis900 drivers, 
change BIOS setings- NOTHING!
I repeat NOTHING!!!
The network performance is still teriblle - aldo the switch lights 
indicate 100mMbits - full duplex, by my opinion the net speed is no more 
then 1Mbits - half duplex.
When turn off the onboard card and put any other 100mbits card - 
everything is just fine.
I noticed that etheboot driver recognise the sis900 PHYtransiver as VIA 
6103, but the linux driver says - UNKNOWN PHYTRANSIVER and continues 
booting and working but with that terribly slow speed.
I'm not C coder, but when I browsed sis900.c file in all linux modiles, 
which I managed to find in SIS web site and in kernel.org, I noticed 
that there is missing the code considering VIA 6103 PHYtransiver.
Only the etherboot driver sis900.c has rows in the sorce code describing it.
Can this be the answer of that network speed slowdown?
I read that etherboot driver are coded from normal linux drivers, but 
apparently I can not find one with VIA6103 PHYtransiver support.

Please, if you can help, contact me as soon as possible.

I would rather pay for the development of Linux driver, then to buy 30 
new LAN cards.

Re: [Etherboot-developers] Re: 5.1 will not boot on 486 was Serial Port Debugging

[Georg B. <Geo...@po...>]

Am Dienstag, 18. Februar 2003 22:50 schrieb Timothy Legge:
> I can confirm that a clean cvs with the above change will allow my 486
> to recognize the NIC and xfer a ltsp kernel.  Nice work Eric, I thought

You know that the LTSP kernels are tagged with mknbi 1.2-7 and 1.2-10 is 
required for Etherboot 5.1.x?


Georg

Re: [Etherboot-developers] Universal auto-probing driver

[Alke <al...@io...>]

"Eric W. Biederman" ha scritto:
> 
> Peter Lister <P.L...@sy...> writes:
> 
> > [Sorry, if I said this before ]
> >
> > PXE users are more likely to want a pre-built binary (e.g. pxelinux is
> > generally distributed prebuilt). An all-drivers image would be a useful
> > default for PXE users; Etherboot image is tftped, PXE users are not
> > significantly affected by image size.
> 
> make etherboot.??? whatever should work.

I'll try...

Only a little suggestion, if you want this option more widely tested:
add this option in the www.rom-o-matic.net site (I hope the manteiner is
reading this ml...)

Byw!

Re: [Etherboot-developers] Universal auto-probing driver

[Vasil V. <vas...@sy...>]

On Wed, 19 Feb 2003, Peter Lister wrote:

>
> [Sorry, if I said this before ]
>
> PXE users are more likely to want a pre-built binary (e.g. pxelinux is
> generally distributed prebuilt). An all-drivers image would be a useful
> default for PXE users; Etherboot image is tftped, PXE users are not
> significantly affected by image size.

PXE actually has a limit of 32K for the size of the first downloaded image
(NBP as they call it).

--
Vasil

Re: [Etherboot-developers] tg3 progress...

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

ebi...@ln... (Eric W. Biederman) writes:

> Someday I want to do a driver from scratch but I until then I get
> to strip down linux drivers and see how small they can go.
> 
> On the broadcom gigabit driver the tg3 progress is being made.
> 
> I have done a quick conversion and the driver initialization code
> appears to be working in etherboot.  I have yet to implement transmit
> and receive functions, and there is still a lot of code to strip off
> but progress is being made.
> 
> The history of the source appears to be:
> >From a 10000 line broadcom driver to a 7000 line linux driver.
> >From a 7000 line linux driver to a 3900 line etherboot driver.
> 
> And I haven't really started cutting yet.  I wonder how small it
> will get tomorrow after I do some more serious cutting.

Well I instead made the code work so I could be more certain
of my cutting so I have a working driver in:
3726 lines of code.

Hopefully tomorrow I can find something to prune away.  It looks like I must
trim it with a thousand cuts, so...


Eric

Re: [Etherboot-developers] Porting question

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

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

Re: [Etherboot-developers] Universal auto-probing driver

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

Peter Lister <P.L...@sy...> writes:

> [Sorry, if I said this before ]
> 
> PXE users are more likely to want a pre-built binary (e.g. pxelinux is
> generally distributed prebuilt). An all-drivers image would be a useful
> default for PXE users; Etherboot image is tftped, PXE users are not
> significantly affected by image size.

make etherboot.??? whatever should work.

Eric

[Etherboot-developers] Porting question

[Yannis M. <gm...@te...>]

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