etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] DHCP option 175

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

On Wed, 22 May 2002, Ken Yap wrote:
> >How about this standard for the NIC tag?
> >	"PCI" or "ISA" (3 bytes)
> >	Vendor ID (2 bytes network order)
> >	Device ID (2 bytes network order)
> >Length 8 bytes, including tag.
> Also I'd prefer that this tag be encapsulated inside one of the standard
> tags for this sort of client info, perhaps even the
> vendor-class-identifier tag to avoid using 175.

It could be wrapped up in vendor-encapsulated-options.  I chose 175 in
order to fit in with the current scheme which, AFAICT, uses the site-local
DHCP options (128-254) instead of encapsulation.

Michael

Re: [Etherboot-developers] DHCP option 175

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

>How about this standard for the NIC tag?
>
>	"PCI" or "ISA" (3 bytes)

Actually that's probably a waste of space, binary 1 = PCI, 2 = ISA,
others for later use should suffice.

>	Vendor ID (2 bytes network order)
>	Device ID (2 bytes network order)

6 bytes total.

As for any potential objection that it's unreadable binary, the rest of
the DHCP packet is unreadable binary anyway, space matters (the more
parsimonious you are with your options, the more space for other
options), and it makes the Etherboot shorter, just copy in the IDs, via
htons().

Re: [Etherboot-developers] DHCP option 175

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

On 21 May 2002, Eric W. Biederman wrote:
> > > Can we change this to return the PCI vendor id and device id's.  This
> > > makes changes in etherboot transparent to configurations.
> > > Something like:
> > > "PCI:8086:1229" for an Intel NIC
> > > "PCI:10b7:9805" for a 3COM NIC
> > > For PNPISA devices there is a similiar string we can use.  And for
> > > straight ISA we might want to just use the vendor and part number.
> > > Especially as there aren't 1-1 mappings between etherboot and foobar.
> > This change would make it significantly harder to maintain a DHCP server.
> > If Etherboot sends the driver name then the DHCP server configuration only
> > needs to know about the 36 Etherboot drivers.  If Etherboot sends the
> > vendor and device IDs then the DHCP server configuration needs to know
> > about the 112 different cards currently in the Etherboot database.
> > Additionally, new card definitions are likely to be added a lot more
> > frequently than new drivers(?)
> But the process could be fully automated by looking at the etherboot
> database, and the kernel module database (/lib/modules/xxx/pcimap).
> Both of which are list the vendor id, and device id of the card.   So
> once setup the worst you will have to do is rerun a script, that
> accomplishes the mapping.
> > If there is a better way to achieve this than sending the Etherboot driver
> > name, please let me know!
> So in summary I think the PCIID->kernel module mapping is much more
> of a constant setup situation than sending etherboot driver names.
> In particular you don't even have care about what etherboot will
> support you just have to worry about what you can support.

OK, this I like.  Is there any easy way to identify which rows in pcimap
correspond to network-card modules?

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

Re: [Etherboot-developers] DHCP option 175

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

>How about this standard for the NIC tag?
>
>	"PCI" or "ISA" (3 bytes)
>	Vendor ID (2 bytes network order)
>	Device ID (2 bytes network order)
>
>Length 8 bytes, including tag.

Also I'd prefer that this tag be encapsulated inside one of the standard
tags for this sort of client info, perhaps even the
vendor-class-identifier tag to avoid using 175.

Re: [Etherboot-developers] DHCP option 175

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

>So in summary I think the PCIID->kernel module mapping is much more
>of a constant setup situation than sending etherboot driver names.  
>In particular you don't even have care about what etherboot will
>support you just have to worry about what you can support.

I'm in favour of Eric's scheme. There are some NICs that are supported
by two drivers, e.g. the 3c900s are supported by the 595 driver and the
90x driver, in different modes. PCI IDs can also tell you something
about the media supported, e.g. the e1000 series. Late binding gives you
the flexibility to do something different on the server side. If you
decide on the driver ahead of time, you've lost that information. The
general princple is that code in *ROMs is harder to update than code in
servers.

How about this standard for the NIC tag?

	"PCI" or "ISA" (3 bytes)
	Vendor ID (2 bytes network order)
	Device ID (2 bytes network order)

Length 8 bytes, including tag.

Re: [Etherboot-developers] DHCP option 175

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

Michael Brown <mb...@fe...> writes:

> On 21 May 2002, Eric W. Biederman wrote:
> > > I have just committed some very small (8 lines total) changes to
> > > etherboot.h, nic.h, config.c, main.c.  Etherboot will now send the NIC
> > > driver name (e.g. "RTL8139") as vendor option 175 in the DHCPREQUEST
> > > packet.
> > > The idea behind this is that the DHCP server can use the contents of this
> > > option field to determine the value of the "filename" in the DHCPACK.  In
> > > this way, Etherboot can be directed to automatically download an
> > > appropriate kernel+initrd image.  The dhcpd.conf file could contain, for
> > > example:
> > > <snip>
> > Request.
> > Can we change this to return the PCI vendor id and device id's.  This
> > makes changes in etherboot transparent to configurations.
> > Something like:
> > "PCI:8086:1229" for an Intel NIC
> > "PCI:10b7:9805" for a 3COM NIC
> > For PNPISA devices there is a similiar string we can use.  And for
> > straight ISA we might want to just use the vendor and part number.
> > Especially as there aren't 1-1 mappings between etherboot and foobar.
> 
> This change would make it significantly harder to maintain a DHCP server.
> If Etherboot sends the driver name then the DHCP server configuration only
> needs to know about the 36 Etherboot drivers.  If Etherboot sends the
> vendor and device IDs then the DHCP server configuration needs to know
> about the 112 different cards currently in the Etherboot database.
> Additionally, new card definitions are likely to be added a lot more
> frequently than new drivers(?)

But the process could be fully automated by looking at the etherboot
database, and the kernel module database (/lib/modules/xxx/pcimap).
Both of which are list the vendor id, and device id of the card.   So
once setup the worst you will have to do is rerun a script, that
accomplishes the mapping.  

This has the advantage that it will work on across multiple versions
of etherboot.  Even when support for a card moves in and out of the
tulip driver.

It is completely independent of etherboot in the setup side.  You can
build configuration for every kernel supported network card, without
even looking at etherboot.

It doesn't export unimportant details from etherboot.  Making
etherboot easier to maintain.  You can change card support in a driver
without worring if it will mess up your dhcp configuration.

It should take a handle of fewer bytes to implement.

> If there is a better way to achieve this than sending the Etherboot driver
> name, please let me know!

So in summary I think the PCIID->kernel module mapping is much more
of a constant setup situation than sending etherboot driver names.  
In particular you don't even have care about what etherboot will
support you just have to worry about what you can support.

Eric

Re: [Etherboot-developers] DHCP option 175

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

On 21 May 2002, Eric W. Biederman wrote:
> > I have just committed some very small (8 lines total) changes to
> > etherboot.h, nic.h, config.c, main.c.  Etherboot will now send the NIC
> > driver name (e.g. "RTL8139") as vendor option 175 in the DHCPREQUEST
> > packet.
> > The idea behind this is that the DHCP server can use the contents of this
> > option field to determine the value of the "filename" in the DHCPACK.  In
> > this way, Etherboot can be directed to automatically download an
> > appropriate kernel+initrd image.  The dhcpd.conf file could contain, for
> > example:
> > <snip>
> Request.
> Can we change this to return the PCI vendor id and device id's.  This
> makes changes in etherboot transparent to configurations.
> Something like:
> "PCI:8086:1229" for an Intel NIC
> "PCI:10b7:9805" for a 3COM NIC
> For PNPISA devices there is a similiar string we can use.  And for
> straight ISA we might want to just use the vendor and part number.
> Especially as there aren't 1-1 mappings between etherboot and foobar.

This change would make it significantly harder to maintain a DHCP server.
If Etherboot sends the driver name then the DHCP server configuration only
needs to know about the 36 Etherboot drivers.  If Etherboot sends the
vendor and device IDs then the DHCP server configuration needs to know
about the 112 different cards currently in the Etherboot database.
Additionally, new card definitions are likely to be added a lot more
frequently than new drivers(?)

I am currently preparing to check mkinitrd-net into contribs.
mkinitrd-net will generate a NBI for any specified network card module,
using a stock (modularized) kernel and an initrd based around Busybox,
udhcpc and uClibc.  It will include a file that maps Etherboot driver
names to Linux kernel modules.  Using this file, it
a) automatically generates NBIs for all kernel modules that correspond to
   Etherboot drivers, and
b) generates a dhcpd.conf fragment that will automatically select the
   correct NBI based on the Etherboot driver name sent by Etherboot in
   option 175.

My aim is that a user should be able to install the mkinitrd-net RPM and
then immediately be able to boot from any Etherboot-supported NIC without
having to configure the "server" in any way (i.e. without having to touch
dhcpd.conf).  I like O(1) systems. :-)

If there is a better way to achieve this than sending the Etherboot driver
name, please let me know!

Michael

Re: [Etherboot-developers] DHCP option 175

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

Michael Brown <mb...@fe...> writes:

> I have just committed some very small (8 lines total) changes to
> etherboot.h, nic.h, config.c, main.c.  Etherboot will now send the NIC
> driver name (e.g. "RTL8139") as vendor option 175 in the DHCPREQUEST
> packet.
> 
> The idea behind this is that the DHCP server can use the contents of this
> option field to determine the value of the "filename" in the DHCPACK.  In
> this way, Etherboot can be directed to automatically download an
> appropriate kernel+initrd image.  The dhcpd.conf file could contain, for
> example:
> 
> option etherboot-driver code 175 = string;
> 
> if option etherboot-driver = "Prism2_PCI" {
>   filename "boot-prism2_pci.nbi";
> } elsif option etherboot-driver = "RLT8139" {
>   filename "boot-8139too.nbi";
> } elsif ... {
>   ...
> } else {
>   filename = concat ( "boot-", option etherboot-driver, ".nbi" );
> }
> 
> This is part of my efforts to automate some (all!) of the work in building
> initrds - watch for the addition of mkinitrd-net to contrib sometime soon.
> 
> I have updated vendortags.{sgml,html,txt} in doc/ to cover the new option.
> 
> Enjoy!  If my changes break anything, please let me know asap.

Request.
Can we change this to return the PCI vendor id and device id's.  This
makes changes in etherboot transparent to configurations.  

Something like:
"PCI:8086:1229" for an Intel NIC
"PCI:10b7:9805" for a 3COM NIC

For PNPISA devices there is a similiar string we can use.  And for
straight ISA we might want to just use the vendor and part number.
Especially as there aren't 1-1 mappings between etherboot and foobar.

Additionally we need one more piece of information to cross the wire.
The locations in RAM that are useable, for the loaded image.  So you
can check the location a ramdisk and kernel are loading before you
send a file across the wire.  The primary thing this would catch is if
an initrd or kernel is to big to fit in ram.

Eric

Re: [Etherboot-developers] Access Memory

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

Just use a pointer to access the location you want. Logical address =
physical address in Etherboot.

[Etherboot-developers] Access Memory

[Jaster C. <jas...@ho...>]

SG93IGNhbiBJIHJlYWQvd3JpdGUgc3BlY2lmaWVkIG1lbW9yeSBsb2NhdGlvbiBiZWxvdyAxTUIg
ZnJvbSBkcml2ZXI/IE9yIEkgc2hvdWxkIHNpbXBseSBjYWxsDQpyZWFkWCgpL3dyaXRlWCgpIGRl
ZmluZWQgaW4gbGludXgtYXNtLWlvLmg/DQoNCk1heWJlIHRoaXMgaXMgYSBzdHVwaWQgcXVlc3Rp
b24sIGJ1dCBJJ20gcmVhbGx5IGdvdCBtZXNzZWQgd2l0aCBpdC4NCg0KQW55IHN1Z2dlc3Rpb24g
aXMgYXBwcmVjaWF0ZWQhDQoNCkJlc3QgcmVnYXJkcyENCg0KKkphc3RlcioNCg==

Re: [Etherboot-developers] DHCP option 175

[Peter L. <P.L...@sy...>]

> The idea behind this is that the DHCP server can use the contents of this
> option field to determine the value of the "filename" in the DHCPACK

It would be good to have arbitrary user info in option 77 as per RFC
3004. This can encode multiple data which might select the image type,
ip address pool, or whatever indexed by nic type, processor type, amount
of memory or just site specific classification. I may get a rush of
blood to the head and submit something fairly soon.

And, at some point when I have breathing space, I want to propose a
reform of existing Etherboot specific DHCP options.

Re: [Etherboot-developers] Multi-driver ROMs (was: Prism II (wireless) drivers)

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

On Sun, 12 May 2002, Michael Brown wrote:
> I have modifed genrules.pl to produce pattern rules alongside the "normal"
> rules.  The upshot is that it is now possible to type
>   make bin32/PCI_NIC--ADDITIONAL_DRIVER.{rom,lzrom,etc.}
> for any combination of PCI_NIC and ADDITIONAL_DRIVER.  No multi-driver
> ROMs will be built by default (i.e. "make" will produce only single-driver
> ROMs).
> <snip>
> The current multi-driver solution is not particularly elegant in its
> implementation and has three known bugs:
> <snip>
> 2) It only works for dual-driver Roms - there is no way of even specifying
>    three or more drivers.  This is irritatingly inelegant but not likely
>    to cause practical problems; if you try to squeeze in three or more
>    drivers then Etherboot will die horribly through RAM starvation anyway.
>    It is probably possible to fix this using some of the more esoteric
>    features of make - patsubst, wildcard etc.

This problem, at least, is fixed.  You can now type, for example:

  make bin32/dfe538--prism2_pci--tulip.rom

and it will happily generate a ROM with three drivers (rtl8139, prism2_pci
and tulip) with the dfe538's PCI IDs.

> 3) The Roms makefile is too long and could probably be shortened
>    considerably by judicious use of pattern rules.

I'm less convinced of this now.  I managed to reduce the config-*.o rule
down to a single pattern rule (which handles both PCI and ISA, single- and
multi-driver), but the others are problematic.  The main issue is that
there doesn't seem to be any way to have the dependencies being a function
of the target (other than in the very simplistic pattern-rule style).  As
an example:

  rtl8139--%.img : bin32/rtl8139.o \
                   $(foreach driver,$(subst --, ,%),bin32/$(driver).o)

  make rtl8139--prism2_pci--tulip.img

does NOT evaluate to the expected

  rtl8139--prism2_pci--tulip.img : bin32/rtl8139.o \
                                   bin32/prism2_pci.o bin32/tulip.o

because the function evaluation happens *before* the pattern matching on
the %.  This means (I think) that any functions in the dependencies can
never know the contents of the "%".

As a workaround, I have made it so that building any multi-driver ROM is
dependent on all the *.o files (ugly).

If anyone knows a way to fix this, I'd really appreciate it.

Michael

[Etherboot-developers] Multi-driver ROMs (was: Prism II (wireless) drivers)

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

On Wed, 17 Apr 2002, Ken Yap wrote:
> >All now in CVS, including the multi-driver ROM stuff.  All builds fine on
> >my system, if anyone hits compile errors with my code please let me know.
> Sorry Michael, I've redesigned the format of the NIC spec file so your
> diffs have not been propagated because I haven't thought up of a
> replacement syntax for your multi-driver build specs. Suggest something.
> Maybe a section like:
> multi
> name=driver1,driver2,driver3	PCI-IDs	Comment
> You will find the revamped genrules.pl and NIC in CVS now.

OK, I finally got around to doing something about this.

I've taken a different approach: rather than having to list multi-driver
ROMs in the NIC file, I thought it would be more elegant if it were
possible to type, for example:

  make bin32/dfe538--prism2_pci.rom

to generate a BootROM for the dfe538 card (RTL8139-based) that would
include both the RTL8139 and Prism2_PCI drivers.

I have modifed genrules.pl to produce pattern rules alongside the "normal"
rules.  The upshot is that it is now possible to type

  make bin32/PCI_NIC--ADDITIONAL_DRIVER.{rom,lzrom,etc.}

for any combination of PCI_NIC and ADDITIONAL_DRIVER.  No multi-driver
ROMs will be built by default (i.e. "make" will produce only single-driver
ROMs).

I should probably document this somewhere - any suggestions for an
appropriate place?



For those interested: the build procedure for a multi-driver ROM is
identical to that of a single-driver ROM except that:

1) the config-*.o file must have -DINCLUDE_XXX defined for all the
   required drivers, and must also have -DTRY_ALL_DEVICES defined

2) when generating the .img, .tmp or .elf file, the additional driver must
   also be linked in


The current multi-driver solution is not particularly elegant in its
implementation and has three known bugs:

1) It only works with PCI Roms at the moment - I don't know enough about
   the ISA build process to be confident of modifying it.

2) It only works for dual-driver Roms - there is no way of even specifying
   three or more drivers.  This is irritatingly inelegant but not likely
   to cause practical problems; if you try to squeeze in three or more
   drivers then Etherboot will die horribly through RAM starvation anyway.

   It is probably possible to fix this using some of the more esoteric
   features of make - patsubst, wildcard etc.

3) The Roms makefile is too long and could probably be shortened
   considerably by judicious use of pattern rules.



This feature meshes nicely with the option-175 patch I put in yesterday:
the multi-driver NIC will send the currently-in-use driver as option 175
to the DHCP server and this means that the server can send back a
single-driver kernel - no need to maintain multi-driver kernels as well.

As always, if these changes break anything, please let me know.

Michael

[Etherboot-developers] DHCP option 175

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

I have just committed some very small (8 lines total) changes to
etherboot.h, nic.h, config.c, main.c.  Etherboot will now send the NIC
driver name (e.g. "RTL8139") as vendor option 175 in the DHCPREQUEST
packet.

The idea behind this is that the DHCP server can use the contents of this
option field to determine the value of the "filename" in the DHCPACK.  In
this way, Etherboot can be directed to automatically download an
appropriate kernel+initrd image.  The dhcpd.conf file could contain, for
example:

option etherboot-driver code 175 = string;

if option etherboot-driver = "Prism2_PCI" {
  filename "boot-prism2_pci.nbi";
} elsif option etherboot-driver = "RLT8139" {
  filename "boot-8139too.nbi";
} elsif ... {
  ...
} else {
  filename = concat ( "boot-", option etherboot-driver, ".nbi" );
}

This is part of my efforts to automate some (all!) of the work in building
initrds - watch for the addition of mkinitrd-net to contrib sometime soon.

I have updated vendortags.{sgml,html,txt} in doc/ to cover the new option.

Enjoy!  If my changes break anything, please let me know asap.

Michael

Re: [Etherboot-developers] Question about ioremap

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

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

> >I am working on the sundance driver.  It seems that the Linux driver is
> >written to use PCI memory space.  Does any one know whether it is possible
> >to use the ioaddr passed to the probe function?  
Please ignore it, and read the address from PCI configuration space.

> Do I need to do an ioremap?
No because etherboot does a 1-1 of physical to virtual addresses.
If etherboot goes cross platform we might need something like that but
we don't right now.

> >Is that even supported in the Etherboot code?  Any answers would help.
> 
> I think Eric Biederman fixed that aspect of Etherboot. Unless I'm
> mistaken, the address obtained from the PCI probe is just an address and
> doesn't necessarily mean I/O address anymore, despite the name. Ditto
> for membase. The e1000 driver also uses memory space I think.

Actually ioaddr is an io address, and membase is a memory address,
though if noone was using it membase may be totally removed.  No
changes have been made to their meaning except depricating them, which
is how I avoided breaking old drivers.   Feel free and encouraged to
ignore them.


Eric

Re: [Etherboot-developers] Question about ioremap

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

>I am working on the sundance driver.  It seems that the Linux driver is
>written to use PCI memory space.  Does any one know whether it is possible
>to use the ioaddr passed to the probe function?  Do I need to do an ioremap?
>Is that even supported in the Etherboot code?  Any answers would help.

I think Eric Biederman fixed that aspect of Etherboot. Unless I'm
mistaken, the address obtained from the PCI probe is just an address and
doesn't necessarily mean I/O address anymore, despite the name. Ditto
for membase. The e1000 driver also uses memory space I think.

[Etherboot-developers] Question about ioremap

[Timothy L. <tl...@ro...>]

Hi

I am working on the sundance driver.  It seems that the Linux driver is
written to use PCI memory space.  Does any one know whether it is possible
to use the ioaddr passed to the probe function?  Do I need to do an ioremap?
Is that even supported in the Etherboot code?  Any answers would help.

Regards

Tim

[Etherboot-developers] [±¤°í] ¾î¹öÀ̳¯ ½º½ÂÀdz¯ Ưº° ¼±¹°Àü ^.^

[giftset <gif...@ly...>]

<html>
<body bgcolor=white>
<p align=center><a href="http://www.softface.co.kr/gifthome.htm" target="_blank" onmouseover="window.status='선물모음전';return true" ><img src="http://www.dic4u.com/images2/giftad.gif"></a><br><br>&nbsp;</p>
<table border="0" align="center">
<tr>
<td>
<p style="LINE-HEIGHT: 120%"><span style="FONT-SIZE: 9pt">▷&nbsp;원치않은 정보였다면 정중히 사과 드리며, 수신 거부를 해주시면 다음부터는 메일이 발송되지 않을 것입니다.</p>
</td>
</tr>
<tr>
<td align="center"><FORM action=http://www.softface.co.kr/unsub.asp method=post><input type=hidden name=flag value=gift><input type=hidden name=email val...@li...><INPUT type=submit value='수신거부'></FORM></td>
</tr>
</table>
</body>
</html>

Re: [Etherboot-developers] SiS630ET

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

>Sorry. I was working on 5.1... :-p     This is not the current 
>development tree???

No, it's currently dormant. Always look at the release dates to see
which is more current. 5.1 isn't even in the download area at the
moment.

Re: [Etherboot-developers] SiS630ET

[Gustavo J. A. <al...@co...>]

Sorry. I was working on 5.1... :-p     This is not the current 
development tree???

I tried the 5.0 version and it was OK.

Ken Yap wrote:

>>Hi,
>>
>>This is the patch to support SiS630ET.
>>    
>>
>
>Against what version? You sure it's not already in there? I have this in
>the log file of 5.0.6:
>
>+ Chien-Yu Chen sent in patches to support the SiS630ET. Independently,
>Doug Ambrisko made the same changes. Marty Connor tidied the patches.
>
>_______________________________________________________________
>
>Have big pipes? SourceForge.net is looking for download mirrors. We supply
>the hardware. You get the recognition. Email Us: ban...@so...
>_______________________________________________
>Etherboot-developers mailing list
>Eth...@li...
>https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>  
>

Re: [Etherboot-developers] SiS630ET

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

>Hi,
>
>This is the patch to support SiS630ET.

Against what version? You sure it's not already in there? I have this in
the log file of 5.0.6:

+ Chien-Yu Chen sent in patches to support the SiS630ET. Independently,
Doug Ambrisko made the same changes. Marty Connor tidied the patches.

[Etherboot-developers] SiS630ET

[Gustavo J. A. <al...@co...>]

Hi,

This is the patch to support SiS630ET.

Gustavo Junior Alves
al...@co...

[Etherboot-developers] Re: =?gb2312?B?UmU6IFJlOiBbRXRoZXJib290LWRldmVsb3BlcnNdICJMaW51eEJJT1MgUk9NIEltYWdlICgu ZWJpKSBGT1IgRVhQRVJUUyBPTkxZIiB0eXBlIGNhbiBub3Qgd29yayEhIQ==?=

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

fs...@16... writes:

> > "fsswyjz" <fs...@16...> writes:
> > 
> > > In "http://rom-o-matic.net/5.0.6/",I use "LinuxBIOS ROM Image" type,Whene I
> 
> > > press "Get Rom" button,it post error such like this:
> > > 
> > > -----------------------------------------------------
> > > Build failed. Status = 2. 
> > > 
> > > Following is the output from make: 
> > > 
> > > 
> > > make: Entering directory `/tmp/ROMo6UhPR'
> > > make: *** No rule to make target `bin32/3c509.ebi'.  Stop.
> > > make: Leaving directory `/tmp/ROMo6UhPR'
> > > Please let us know that this happened. 
> > > ------------------------------------------------------
> > 
> > Currently the ISA NICS are not supportted.  And the 3c509 is an ISA
> > NIC.  Please feel free to fix that.  It was an oversight when
> > etherboot was initially modified to build LinuxBIOS images.
> > 
> > Other 3COM nics should work like the 3c590
> > 
> > Eric
> > 
>   But I use 3c590,It still post error such like below:why?

Because you are trying to build code that uses 16bit BIOS calls.  
LinuxBIOS doesn't do 16bit BIOS calls, so that code is incompatible,
you need a different set of options to make it work.

Failure at build time is preferable to failure at runtime.

Eric



> --------------------------------------------------------
> Build failed. Status = 2. 
> 
> Following is the output from make: 
> 
> 
> make: Entering directory `/tmp/ROMfZokeN'
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -DINCLUDE_3C595 -o bin32/3c595.o -c 3c595.c
> 
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -DINCLUDE_3C595 -o bin32/config-3c595.o -c config.c
> 
> config.c: In function `eth_probe':
> config.c:495: warning: passing arg 2 from incompatible pointer type
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/pci.o -c pci.c
> 
> /tmp/ccQSUu0z.s: Assembler messages:
> /tmp/ccQSUu0z.s:43: Warning: indirect lcall without `*'
> /tmp/ccQSUu0z.s:105: Warning: indirect lcall without `*'
> /tmp/ccQSUu0z.s:144: Warning: indirect lcall without `*'
> /tmp/ccQSUu0z.s:183: Warning: indirect lcall without `*'
> /tmp/ccQSUu0z.s:223: Warning: indirect lcall without `*'
> /tmp/ccQSUu0z.s:262: Warning: indirect lcall without `*'
> /tmp/ccQSUu0z.s:301: Warning: indirect lcall without `*'
> /tmp/ccQSUu0z.s:347: Warning: indirect lcall without `*'
> gcc -E -Wp,-Wall -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU
> -DCONGESTED -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 start32.S | as -o bin32/start32.o
> 
> {standard input}: Assembler messages:
> {standard input}:141: Warning: indirect ljmp without `*'
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/linuxbios.o -c linuxbios.c
> 
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/main.o -c main.c
> 
> main.c: In function `tftp':
> main.c:624: warning: `oport' might be used uninitialized in this function
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/osloader.o -c osloader.c
> 
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/nfs.o -c nfs.c
> 
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/misc.o -c misc.c
> 
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/ansiesc.o -c ansiesc.c
> 
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/bootmenu.o -c bootmenu.c
> 
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/md5.o -c md5.c
> 
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/floppy.o -c floppy.c
> 
> gcc -E -Wp,-Wall -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU
> -DCONGESTED -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 serial.S | as -o bin32/serial.o
> 
> kgcc -DASK_BOOT=3 -DANS_DEFAULT=ANS_NETWORK -DMOTD -DIMAGE_MENU -DCONGESTED
> -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -DTAGGED_IMAGE -DELF_IMAGE
> -DDOWNLOAD_PROTO_TFTP -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -DCOMPARM=0x03 -DPCBIOS
> -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -mcpu=i386
> -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -Wno-format
> -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -DVERSION=\"5.0.6\"
> -DRELOC=0x94000 -o bin32/timer.o -c timer.c
> 
> ar rv bin32/bootlib.a bin32/main.o bin32/osloader.o bin32/nfs.o bin32/misc.o
> bin32/ansiesc.o bin32/bootmenu.o bin32/md5.o bin32/floppy.o bin32/serial.o
> bin32/timer.o
> 
> a - bin32/main.o
> a - bin32/osloader.o
> a - bin32/nfs.o
> a - bin32/misc.o
> a - bin32/ansiesc.o
> a - bin32/bootmenu.o
> a - bin32/md5.o
> a - bin32/floppy.o
> a - bin32/serial.o
> a - bin32/timer.o
> ranlib bin32/bootlib.a
> ld -N -Ttext 0x94000 -e _start -o bin32/3c595.elf bin32/start32.o
> bin32/linuxbios.o bin32/config-3c595.o bin32/3c595.o bin32/pci.o bin32/bootlib.a
> 
> bin32/bootlib.a(main.o): In function `main':
> main.o(.text+0x7b): undefined reference to `currticks'
> main.o(.text+0x89): undefined reference to `currticks'
> bin32/bootlib.a(main.o): In function `bootp':
> main.o(.text+0x8b6): undefined reference to `currticks'
> main.o(.text+0xa2a): undefined reference to `currticks'
> bin32/bootlib.a(main.o): In function `await_reply':
> main.o(.text+0xab8): undefined reference to `currticks'
> bin32/bootlib.a(main.o)(.text+0xe1c): more undefined references to `currticks'
> follow
> 
> bin32/bootlib.a(misc.o): In function `gateA20_set':
> misc.o(.text+0x46e): undefined reference to `int15'
> bin32/bootlib.a(misc.o): In function `gateA20_unset':
> misc.o(.text+0x4a6): undefined reference to `int15'
> bin32/bootlib.a(misc.o): In function `putchar':
> misc.o(.text+0x4ee): undefined reference to `console_putc'
> bin32/bootlib.a(misc.o): In function `getchar':
> misc.o(.text+0x4ff): undefined reference to `console_ischar'
> misc.o(.text+0x508): undefined reference to `console_getc'
> bin32/bootlib.a(misc.o): In function `iskey':
> misc.o(.text+0x525): undefined reference to `console_ischar'
> bin32/bootlib.a(bootmenu.o): In function `selectImage':
> bootmenu.o(.text+0x264): undefined reference to `currticks'
> bootmenu.o(.text+0x2bf): undefined reference to `currticks'
> make: *** [bin32/3c595.elf] Error 1
> make: Leaving directory `/tmp/ROMfZokeN'
> Please let us know that this happened. 
> --------------------------------------------------

Re: [Etherboot-developers] "LinuxBIOS ROM Image (.ebi) FOR EXPERTS ONLY" type can not work!!!

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

"fsswyjz" <fs...@16...> writes:

>    In "http://rom-o-matic.net/5.0.6/",I use "LinuxBIOS ROM Image" type,Whene I
> press "Get Rom" button,it post error such like this:
> 
> -----------------------------------------------------
> Build failed. Status = 2. 
> 
> Following is the output from make: 
> 
> 
> make: Entering directory `/tmp/ROMo6UhPR'
> make: *** No rule to make target `bin32/3c509.ebi'.  Stop.
> make: Leaving directory `/tmp/ROMo6UhPR'
> Please let us know that this happened. 
> ------------------------------------------------------

Currently the ISA NICS are not supportted.  And the 3c509 is an ISA
NIC.  Please feel free to fix that.  It was an oversight when
etherboot was initially modified to build LinuxBIOS images.

Other 3COM nics should work like the 3c590

Eric

[Etherboot-developers] "LinuxBIOS ROM Image (.ebi) FOR EXPERTS ONLY" type can not work!!!

[fsswyjz <fs...@16...>]

ICAgSW4gImh0dHA6Ly9yb20tby1tYXRpYy5uZXQvNS4wLjYvIixJIHVzZSAiTGludXhCSU9TIFJP
TSBJbWFnZSIgdHlwZSxXaGVuZSBJIHByZXNzICJHZXQgUm9tIiBidXR0b24saXQgcG9zdCBlcnJv
ciBzdWNoIGxpa2UgdGhpczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQpCdWlsZCBmYWlsZWQuIFN0YXR1cyA9IDIuIA0KDQpGb2xsb3dpbmcg
aXMgdGhlIG91dHB1dCBmcm9tIG1ha2U6IA0KDQoNCm1ha2U6IEVudGVyaW5nIGRpcmVjdG9yeSBg
L3RtcC9ST01vNlVoUFInDQptYWtlOiAqKiogTm8gcnVsZSB0byBtYWtlIHRhcmdldCBgYmluMzIv
M2M1MDkuZWJpJy4gIFN0b3AuDQptYWtlOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3RtcC9ST01vNlVo
UFInDQpQbGVhc2UgbGV0IHVzIGtub3cgdGhhdCB0aGlzIGhhcHBlbmVkLiANCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K