Thanks Eric and Ken for the responses so far. We are using a 3COM LAN
Modem. The ping times are using around 210ms. It is taking about 7
minutes to boot up (using the world's smallest 2.4 kernel!). Using the LAN
Modem is about the slowest possible way, we know -- but it does seem to be a
working solution. Of course "working" for some would not be using a 33.6
link. We will probably move to another form of connection, but at the
present time 33.6 is all we have available. We will look into
installing a disk drive in a workstation. I'm just glad we don't need to
run X over that 33.6 link.
Thanks,
James
----- Original Message -----
From: "Ken Yap" <ken_yap@...>
To: "Etherboot developers list" <etherboot-developers@...>
Sent: Thursday, May 30, 2002 9:20 AM
Subject: Re: [Etherboot-developers] TFTP speed
> >Hi. Not sure if this is the correct place of this post, forgive me if it
is
> >not. It seems that the TFTP speed downloading a kernel from an
Etherboot
> >workstation using a standard 33.6 modem is very slow. I know that
33.6kbps
> >is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink
>
> You're a brave man to do TFTP across a 33.6kb link. That's roughly 300
> times slower than 10 Mb. How far is the client from the server network
> wise, i.e. what sort of delay numbers do you get when you do a ping?
> TFTP was never intended for downloading across thin links, the UDP
> protocol is stop and wait. TCP gets its speed from buffering and
> streaming. You really should situate a server near the client.
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Etherboot-developers mailing list
> Etherboot-developers@...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

"James Newlin" <jnewlin@...> writes:
> Hi. Not sure if this is the correct place of this post, forgive me if it is
> not. It seems that the TFTP speed downloading a kernel from an Etherboot
> workstation using a standard 33.6 modem is very slow. I know that 33.6kbps
> is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink
> very slowing, which makes us think that maybe there is some sort of sleep
> state in place. The modems send/recv LEDs are on constantly after the
> kernel is loaded and booted up and the application is running. Is there
> some sort of built in sleeps or maybe timeouts with TFTP-SERVER.0.17-9.RPM?
> Server is RedHat 7.2. Would it be worth trying other TFTP servers?
>
Is the modem code in etherboot, or do you have a router in the middle
talking over the 33.6 link?
If the code is in etherboot I'd love to have a look at it. Being
able to boot over the serial port has a strange appeal in certain
weird circumstances.
Eric

"James Newlin" <jnewlin@...> writes:
> Hi. Not sure if this is the correct place of this post, forgive me if it is
> not. It seems that the TFTP speed downloading a kernel from an Etherboot
> workstation using a standard 33.6 modem is very slow. I know that 33.6kbps
> is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink
> very slowing, which makes us think that maybe there is some sort of sleep
> state in place. The modems send/recv LEDs are on constantly after the
> kernel is loaded and booted up and the application is running. Is there
> some sort of built in sleeps or maybe timeouts with TFTP-SERVER.0.17-9.RPM?
> Server is RedHat 7.2. Would it be worth trying other TFTP servers?
TFTP is painfully synchronous. In particular the greater your latency
between send and receive the slower TFTP will go.
The options worth investigating are the TFTP block size option, and upping
your interface MTU. It's a modem it has no natural MTU. Together you should
be able to handle large packets and at least saturate your link.
Over 100Mbit I can boot in less than a second.
At best for a 2M kernel you are looking at 8 minutes over a 33.6 link.
What kind of speed are you seeing?
Eric

>Hi. Not sure if this is the correct place of this post, forgive me if it is
>not. It seems that the TFTP speed downloading a kernel from an Etherboot
>workstation using a standard 33.6 modem is very slow. I know that 33.6kbps
>is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink
You're a brave man to do TFTP across a 33.6kb link. That's roughly 300
times slower than 10 Mb. How far is the client from the server network
wise, i.e. what sort of delay numbers do you get when you do a ping?
TFTP was never intended for downloading across thin links, the UDP
protocol is stop and wait. TCP gets its speed from buffering and
streaming. You really should situate a server near the client.

Hi. Not sure if this is the correct place of this post, forgive me if it is
not. It seems that the TFTP speed downloading a kernel from an Etherboot
workstation using a standard 33.6 modem is very slow. I know that 33.6kbps
is nothing like 10 or 100-base-T, but we can see the send/recv LEDs blink
very slowing, which makes us think that maybe there is some sort of sleep
state in place. The modems send/recv LEDs are on constantly after the
kernel is loaded and booted up and the application is running. Is there
some sort of built in sleeps or maybe timeouts with TFTP-SERVER.0.17-9.RPM?
Server is RedHat 7.2. Would it be worth trying other TFTP servers?
Thanks for any input,
James

>Explicitly specifying "unsigned char" fixes the problem. I've fixed the
>ones I've come across, but it seems to be common problem in many locations
>- it might be worth eliminating them all with a quick code review at some
>point.
Please fix away. Please do post a list of those files you've fixed so
that I can sync with the CVS archive.

I've noticed some strange things happening when DHCP options get longer
than 128 characters (which is easily possible if you use the
extensions-path mechanism to load an external options file via TFTP).
I've tracked it down to the lack of "unsigned" when defining character
types in places like:
char *motd[RFC1533_VENDOR_NUMOFMOTD];
which causes problems in bootmenu.c, at the point
int i,j,k = 0;
for (i = 0; i < RFC1533_VENDOR_NUMOFMOTD; i++) if (motd[i]) {
for (j = TAG_LEN(motd[i])
since if the DHCP option length is >=128, j will either be set to the
correct length or (correct length-256), at the discretion of the compiler.
Explicitly specifying "unsigned char" fixes the problem. I've fixed the
ones I've come across, but it seems to be common problem in many locations
- it might be worth eliminating them all with a quick code review at some
point.
Michael Brown
http://www.fensystems.co.uk

Christoph Plattner <christoph.plattner@...> writes:
> Hello !
>
> One word to:
> -DLOCALBOOT_DEINIT_NIC
>
> This option should no be an option. IMO it is very important to handle
> the full deactivation of all devices touched in the net booting stuff
> and in boot loaders.
>
> This is true for etherboot (also for GRUB). Before any system is booted,
> kernel is started or a local system is loaded, all devices used or
> touched should be clean deactivated. I also so the effect one day under
> Windows, that it explicitly cannot operate on the NIC.
>
> So a good design should include the activation (probing) and a clean
> "close" before jumping to the loaded kernel or to the chainloaded image.
Agreed.
Eric

>Is this not already possible via judicious use of the extensions-path
>option and the ANSI escape sequence "<esc>['filename'#"? Without filling
>up the DHCP packet, you can specify a menu file via the extensions-path
>option (or etherboot.extensions-path, if you've already upgraded to
>encapsulated options!) and the menu file can contain escape sequences to
>load icons, backdrops etc from further files.
But this still imposes the need for Etherboot to interpret the graphics,
which means bloat and also makes it harder to fix bugs and upgrade
because Etherboot code is often written in silicon. Also there's no
accounting for taste. One person will be happy with ANSI escapes,
another wants PCX graphics, yet another wants mouse interaction. All
those customisations can be done on the auxilliary program, not the core
of Etherboot. Menus could even be conditional on client info as returned
by DHCP. I would like to see all the menu stuff in Etherboot move into
an auxilliary program and Etherboot be just a loader.
>Very true. On my system, the only message that is actually visible is
>"Boot from Network or Local?": all the others vanish off the screen before
>you could even read enough to determine the language they were written in!
>
>Maybe it would be worth localizing this single message since it does
>prompt for user interaction?
There are basic defines for these at the top of etherboot.h. Possibly
they should be enclosed in #ifdefs or patch sets developed.

On Mon, 27 May 2002, Ken Yap wrote:
> >a/ Graphical boot logos
> I would very like to see this but by means of loading a menu program
> which does all the fancy things rather than the way it's done now by
> encoding the menu in the DHCP reply packet, which is becoming rather
> packed with features. I started some work on this but didn't take it
> beyond proof of concept, see mknbi-menu. My intention was next to take
> an interpreter like LUA (www.lua.org) to allow people to write menus as
> LUA scripts. LILO has some nice stuff you might be able to borrow from.
> Unfortunately I have only square tuits at the moment, no round ones (bad
> pun).
> If you pull this off, you will not need some of the additional features
> you proposed to introduce in your previous posting.
Is this not already possible via judicious use of the extensions-path
option and the ANSI escape sequence "<esc>['filename'#"? Without filling
up the DHCP packet, you can specify a menu file via the extensions-path
option (or etherboot.extensions-path, if you've already upgraded to
encapsulated options!) and the menu file can contain escape sequences to
load icons, backdrops etc from further files.
> >b/ Localized Etherboot version (text output in german, for example)
> Again, a user controllable graphics and menu capability might make this
> issue unimportant. Booting is normally so fast that before you know it,
> the kernel messages have appeared. If you could boot a menu, then before
> you know it, you have a graphics screen, and you just see the Probing,
> etc messages flash past.
Very true. On my system, the only message that is actually visible is
"Boot from Network or Local?": all the others vanish off the screen before
you could even read enough to determine the language they were written in!
Maybe it would be worth localizing this single message since it does
prompt for user interaction?
Michael Brown
http://www.fensystems.co.uk

Hello !
One word to:
-DLOCALBOOT_DEINIT_NIC
This option should no be an option. IMO it is very important to handle
the full deactivation of all devices touched in the net booting stuff
and in boot loaders.
This is true for etherboot (also for GRUB). Before any system is booted,
kernel is started or a local system is loaded, all devices used or
touched should be clean deactivated. I also so the effect one day under
Windows, that it explicitly cannot operate on the NIC.
So a good design should include the activation (probing) and a clean
"close" before jumping to the loaded kernel or to the chainloaded image.
With friendly regards
Christoph P.
Anselm Martin Hoffmeister wrote:
>
> Moin all around,
>
> I had some special requirements for etherboot functions, so I changed some
> lines in code. Perhaps it would be a good idea to introduce these changes
> into standard etherboot source tree.... That's what I would like to hear your
> opinion about.
>
> -DSILENT
> ========
> I added this additional switch which suppresses displaying the menu, password
> question and so on.... shortly said, every output between MOTD and [bootdisk]
> resp. [osloader] is suppressed, to the effect that a full-screen-Bootlogo can
> be shown, which in our case displays a penguin and a windumb flag offering
> the selection. We don't want text inside that.... And it's really nice.
> Alternatively, submitting the *keep*shut*up*-option via dhcp (more
> complicated) would allow the boot rom to be used this or that way - which we
> don't need at our site, so I took the way of least resistance.
>
> -DLAST_MOTD_AFTER_BOOTMENU
> ==========================
> The motd option is VERY useful for designing one's own face of etherboot, but
> supported by the load-file-option ^['filename'# we do not need eight lines of
> text, the first one only indeed. We would prefer to display a text string
> after user chose an operating system, which cleans away our graphical logo,
> brings the display back to text mode and says "Lade Betriebssystem:" (load
> operating system). This is done by modifying the [for]-loop in [show_motd] or
> whatever that function is called so it displays only seven motd-lines, and
> after menu selection displaying the 8th motd line, if defined.
>
> -DHARDDISK_FALLBACK
> ===================
> What happens when the server cannot be reached? At the school computer room
> where my ltsp project is in development, one time or another the linux server
> may be down, so that a fallback to boot Win3.11 is the best alternative (the
> best existing... Win is sooo slow). We don't want the floppy drive to be
> tried for a boot disk, because some of them are broken, and they are
> hardware-locked anyway. BIOS is too old (486/100). So booting from harddisk
> without any other delay would be best. This option inserts two lines of code
> at the location where server_not_reachable would occur. It just calls
> bootdisk(0x80,0) to load operating system from MBR instead of returning to
> BIOS boot.
>
> -DLOCALBOOT_DEINIT_NIC
> ======================
> I use to test etherboot at home, on my system with some M$-Operating System
> on it, which is loaded via a menu entry ::::/dev/hda2:::: so via calling the
> function [bootdisk]. Somehow Windumb didn't like being booted by etherboot
> (hanging at some time without further notice.... when trying to find network
> interfaces?), so I tried to investigate why. Entering this switch, which
> de-inits the NIC at the beginning of [bootdisk], made it work.
>
> -DNO_GFX_COLOUR_CORRECTION
> ==========================
> We really had a hard time finding out what happened to the colours of our
> boot-bitmap. We first tried 256-color-mode, but either bmptoppm or ppmtoansi
> didn't like that. After really frustrating hours of trying and always
> odd-colored logo, we changed to using 16-color images (converted by some
> windumb software to VGA-Color-palette), converting them with a small C
> proggie to ansi and - most important - disabling the colour correction inside
> the ansiesc.c where every colour <= 7 is looked up inside a table and
> replaced by another one. After all this, it went really great. I hope our
> users like it. Obviously, there is need for both measures (disabling colour
> correction AND not using ansitoppm) to work properly.
>
> That's quite a lot of topic for a single posting, isn't it? But two more
> things I want to mention - kind of request-for-comment. They will go to
> etherboot-users, too.
> a) Is there a need/want for a howto-graphical-boot-logo? We finally managed
> to get one, it was worth the pain. I could also post the program we now use
> to convert bitmap to ansi-graphics.
> b) Is there a need/want for a translated version of etherboot? Our system
> runs in the computer room of a secondary school, and it is kind of teacher's
> policy to prefer german user interfaces... This could be implemented by
> adding symbolic constants instead of strings which would have to be declared
> inside "i18n.h" where a "#ifdef LANGUAGE_GERMAN....." could be done...
>
> Have a nice day,
>
> Anselm M. Hoffmeister
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Etherboot-developers mailing list
> Etherboot-developers@...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
-----------------------------------------------------------------
private: christoph.plattner@...
company: christoph.plattner@...

>a/ Graphical boot logos
I would very like to see this but by means of loading a menu program
which does all the fancy things rather than the way it's done now by
encoding the menu in the DHCP reply packet, which is becoming rather
packed with features. I started some work on this but didn't take it
beyond proof of concept, see mknbi-menu. My intention was next to take
an interpreter like LUA (www.lua.org) to allow people to write menus as
LUA scripts. LILO has some nice stuff you might be able to borrow from.
Unfortunately I have only square tuits at the moment, no round ones (bad
pun).
If you pull this off, you will not need some of the additional features
you proposed to introduce in your previous posting.
>b/ Localized Etherboot version (text output in german, for example)
I understand the motivation for this. However my policy is that the
output text in the source stays in English. The reason is the same as
for the Linux kernel. To be able to report problems with the software,
diagnostic output must be readable by developers. This means, like it or
not, English. However I have no objections to (or any intention of
stopping) localisation patches. You are welcome to use the patch area at
the web site to post such patches. Perhaps you should register as a
developer.
Again, a user controllable graphics and menu capability might make this
issue unimportant. Booting is normally so fast that before you know it,
the kernel messages have appeared. If you could boot a menu, then before
you know it, you have a graphics screen, and you just see the Probing,
etc messages flash past.

Moin all around,
I had some special requirements for etherboot functions, so I changed some
lines in code. Perhaps it would be a good idea to introduce these changes
into standard etherboot source tree.... That's what I would like to hear your
opinion about.
-DSILENT
========
I added this additional switch which suppresses displaying the menu, password
question and so on.... shortly said, every output between MOTD and [bootdisk]
resp. [osloader] is suppressed, to the effect that a full-screen-Bootlogo can
be shown, which in our case displays a penguin and a windumb flag offering
the selection. We don't want text inside that.... And it's really nice.
Alternatively, submitting the *keep*shut*up*-option via dhcp (more
complicated) would allow the boot rom to be used this or that way - which we
don't need at our site, so I took the way of least resistance.
-DLAST_MOTD_AFTER_BOOTMENU
==========================
The motd option is VERY useful for designing one's own face of etherboot, but
supported by the load-file-option ^['filename'# we do not need eight lines of
text, the first one only indeed. We would prefer to display a text string
after user chose an operating system, which cleans away our graphical logo,
brings the display back to text mode and says "Lade Betriebssystem:" (load
operating system). This is done by modifying the [for]-loop in [show_motd] or
whatever that function is called so it displays only seven motd-lines, and
after menu selection displaying the 8th motd line, if defined.
-DHARDDISK_FALLBACK
===================
What happens when the server cannot be reached? At the school computer room
where my ltsp project is in development, one time or another the linux server
may be down, so that a fallback to boot Win3.11 is the best alternative (the
best existing... Win is sooo slow). We don't want the floppy drive to be
tried for a boot disk, because some of them are broken, and they are
hardware-locked anyway. BIOS is too old (486/100). So booting from harddisk
without any other delay would be best. This option inserts two lines of code
at the location where server_not_reachable would occur. It just calls
bootdisk(0x80,0) to load operating system from MBR instead of returning to
BIOS boot.
-DLOCALBOOT_DEINIT_NIC
======================
I use to test etherboot at home, on my system with some M$-Operating System
on it, which is loaded via a menu entry ::::/dev/hda2:::: so via calling the
function [bootdisk]. Somehow Windumb didn't like being booted by etherboot
(hanging at some time without further notice.... when trying to find network
interfaces?), so I tried to investigate why. Entering this switch, which
de-inits the NIC at the beginning of [bootdisk], made it work.
-DNO_GFX_COLOUR_CORRECTION
==========================
We really had a hard time finding out what happened to the colours of our
boot-bitmap. We first tried 256-color-mode, but either bmptoppm or ppmtoansi
didn't like that. After really frustrating hours of trying and always
odd-colored logo, we changed to using 16-color images (converted by some
windumb software to VGA-Color-palette), converting them with a small C
proggie to ansi and - most important - disabling the colour correction inside
the ansiesc.c where every colour <= 7 is looked up inside a table and
replaced by another one. After all this, it went really great. I hope our
users like it. Obviously, there is need for both measures (disabling colour
correction AND not using ansitoppm) to work properly.
That's quite a lot of topic for a single posting, isn't it? But two more
things I want to mention - kind of request-for-comment. They will go to
etherboot-users, too.
a) Is there a need/want for a howto-graphical-boot-logo? We finally managed
to get one, it was worth the pain. I could also post the program we now use
to convert bitmap to ansi-graphics.
b) Is there a need/want for a translated version of etherboot? Our system
runs in the computer room of a secondary school, and it is kind of teacher's
policy to prefer german user interfaces... This could be implemented by
adding symbolic constants instead of strings which would have to be declared
inside "i18n.h" where a "#ifdef LANGUAGE_GERMAN....." could be done...
Have a nice day,
Anselm M. Hoffmeister

Moin all around,
I had some special requirements for etherboot functions, so I changed some
lines in code. Perhaps it would be a good idea to introduce these changes
into standard etherboot source tree.... That's what I would like to hear your
opinion about.
-DSILENT
========
I added this additional switch which suppresses displaying the menu, password
question and so on.... shortly said, every output between MOTD and [bootdisk]
resp. [osloader] is suppressed, to the effect that a full-screen-Bootlogo can
be shown, which in our case displays a penguin and a windumb flag offering
the selection. We don't want text inside that.... And it's really nice.
Alternatively, submitting the *keep*shut*up*-option via dhcp (more
complicated) would allow the boot rom to be used this or that way - which we
don't need at our site, so I took the way of least resistance.
-DLAST_MOTD_AFTER_BOOTMENU
==========================
The motd option is VERY useful for designing one's own face of etherboot, but
supported by the load-file-option ^['filename'# we do not need eight lines of
text, the first one only indeed. We would prefer to display a text string
after user chose an operating system, which cleans away our graphical logo,
brings the display back to text mode and says "Lade Betriebssystem:" (load
operating system). This is done by modifying the [for]-loop in [show_motd] or
whatever that function is called so it displays only seven motd-lines, and
after menu selection displaying the 8th motd line, if defined.
-DHARDDISK_FALLBACK
===================
What happens when the server cannot be reached? At the school computer room
where my ltsp project is in development, one time or another the linux server
may be down, so that a fallback to boot Win3.11 is the best alternative (the
best existing... Win is sooo slow). We don't want the floppy drive to be
tried for a boot disk, because some of them are broken, and they are
hardware-locked anyway. BIOS is too old (486/100). So booting from harddisk
without any other delay would be best. This option inserts two lines of code
at the location where server_not_reachable would occur. It just calls
bootdisk(0x80,0) to load operating system from MBR instead of returning to
BIOS boot.
-DLOCALBOOT_DEINIT_NIC
======================
I use to test etherboot at home, on my system with some M$-Operating System
on it, which is loaded via a menu entry ::::/dev/hda2:::: so via calling the
function [bootdisk]. Somehow Windumb didn't like being booted by etherboot
(hanging at some time without further notice.... when trying to find network
interfaces?), so I tried to investigate why. Entering this switch, which
de-inits the NIC at the beginning of [bootdisk], made it work.
-DNO_GFX_COLOUR_CORRECTION
==========================
We really had a hard time finding out what happened to the colours of our
boot-bitmap. We first tried 256-color-mode, but either bmptoppm or ppmtoansi
didn't like that. After really frustrating hours of trying and always
odd-colored logo, we changed to using 16-color images (converted by some
windumb software to VGA-Color-palette), converting them with a small C
proggie to ansi and - most important - disabling the colour correction inside
the ansiesc.c where every colour <= 7 is looked up inside a table and
replaced by another one. After all this, it went really great. I hope our
users like it. Obviously, there is need for both measures (disabling colour
correction AND not using ansitoppm) to work properly.
That's quite a lot of topic for a single posting, isn't it? But two more
things I want to mention - kind of request-for-comment. They will go to
etherboot-users, too.
a) Is there a need/want for a howto-graphical-boot-logo? We finally managed
to get one, it was worth the pain. I could also post the program we now use
to convert bitmap to ansi-graphics.
b) Is there a need/want for a translated version of etherboot? Our system
runs in the computer room of a secondary school, and it is kind of teacher's
policy to prefer german user interfaces... This could be implemented by
adding symbolic constants instead of strings which would have to be declared
inside "i18n.h" where a "#ifdef LANGUAGE_GERMAN....." could be done...
Have a nice day,
Anselm M. Hoffmeister

I have just uploaded mkinitrd-net to etherboot-5.0/contribs/initrd. From
the README:
mkinitrd-net enables you to use your distribution's stock kernel for
diskless workstations, without having to compile in support for the
relevant network card(s). It creates an initial ramdisk image containing
the required network-card kernel modules and bootstrap scripts to load the
module, obtain an IP address via DHCP and mount the root filesystem via
NFS.
mkinitrd-net also generates a dhcpd.conf file fragment that can be used to
automate the process of mapping NBI files to clients, based on the PCI IDs
of their network cards. Etherboot will send the PCI ID of the network
card to the DHCP server in the etherboot-encapsulated-options field
(Etherboot 5.0.7 and newer) and the DHCP server can use this to identify
the correct NBI to point the client towards.
The end result is that:
a) You can avoid the hassle of compiling custom kernels for diskless
workstations.
b) Diskless workstations will automatically download the correct
kernel+initrd.
c) You have an easier life! :-)
Instructions are very simple: run "make". Has been tested on Mandrake 8.2
only; reports of problems with other distributions are very welcome.
Patches to make it work with other distributions even more so. :-)
Michael Brown
http://www.fensystems.co.uk

On 22 May 2002, Eric W. Biederman wrote:
> > > > OK, this I like. Is there any easy way to identify which rows in pcimap
> > > > correspond to network-card modules?
> > > Cross reference against kernel/drivers/net.
> > > Or look at the class to see if is 0200. Bu I don't think that is usually
> > > supplied.
> > Some degenerate network drivers can exist outside of kernel/drivers/net -
> > for example in Mandrake 8.2 the prism2 and e100/e1000 family of drivers
> > exist in kernel/3rdparty. :-(
> > Are there any symbols that all network modules export? Would this be a
> > viable method for testing?
> Try import and I think it is a viable method.
> I believe init_etherdev and it's cousing functions for initializing
> ethernet cards could be tested for.
I have something pretty close to working. I'm just running "nm" on all
the kernel modules referenced from modules.pcimap and grepping the output
for "ether" or "wlan". The automated script builds an initrd and then an
NBI for each network module, and generates a dhcpd.conf fragment that
matches against the encapsulated option etherboot.kmod. Works with the
only card I've tested it with so far :-)
I've hit one incredibly annoying problem: some modules include the PCI
vendor and device codes but neglect to include a MODULE_DEVICE_TABLE
macro, so their codes are never entered into modules.pcimap. Very
frustrating, and also explains why my Prism2.5 card didn't get
autodetected despite being perfectly well supported...
Michael Brown
http://www.fensystems.co.uk

>We could assign random arbitrary strings. But strings that make sense
>in some other context are probably better because someone can look at
>it and make sense of it. And also be able to predict with some degree
>of accuracy what other ISA chips will have.
It's not too bad. The number of ISA NICs supported by Etherboot is
finite and no new ISA NICs are being designed. We could use the
manufacturer's ID (if available) plus a device ID we invent, possibly
the ur-chip of the family. E.g.
3c509 VENDOR_3COM 509
3c515 VENDOR_3COM 515
NE2000 'NE' 2000
EEPRO10 VENDOR_INTEL 10
WD8013 VENDOR_SMC 8013
Lance VENDOR_AMD 7990
CS89x0 VENDOR_CRYSTAL 8900
DEPCA VENDOR_DIGITAL 100
It's a different namespace from PCI so clashes won't be a problem. A
couple of passes on this forum and we'll have the table.

Michael Brown <mbrown@...> writes:
>
> So is it something that would need to be individually coded into each ISA
> driver, or something that could be coded just once?
You could do it in one pass but you would have to add it to each driver.
There is no good way for software to identify ISA devices. And various
tricks are required.
> This is probably a
> stupid question, but I just don't know if the vendor name and part number
> are well-defined fields in the same way as the PCI vendor and device ID
> fields - I never really got into ISA hardware.
They are only well defined in that is what you order the part by. And
how you look up the parts documentation. For every bus that came after
ISA; PnPISA, MCA, PCI, USB, ... There are well defined fields you can use
But there is nothing on the software side for ISA.
We could assign random arbitrary strings. But strings that make sense
in some other context are probably better because someone can look at
it and make sense of it. And also be able to predict with some degree
of accuracy what other ISA chips will have.
Eric

On 22 May 2002, Eric W. Biederman wrote:
> > > > >BTW, where do I get the ID numbers from for ISA cards? For PCI, I am just
> > > > >using dev.vendor and dev.dev_id (in config.c), but I can't see an obvious
> > > > >equivalent for ISA.
> > > > There isn't any that I'm aware of at least for the non-PnP variety. We
> > > > may have to invent some. Possibly 4 distinct bytes from the common name,
> > > > or 2 from the same vendor table, plus 2 made up, might serve.
> > > The only kind of ID I can think of is the vendor name, and part number, of
> > > the ethernet chip.
> > > It might not be the smallest string but it would be something you
> > > could look up. And it is already distinct for manufacturing and
> > > tracking reasons.
> > Is this information already available somewhere within Etherboot?
> No so that it is trivial to get at. But basically to actually work
> on the driver that information is needed to look up the documentation.
So is it something that would need to be individually coded into each ISA
driver, or something that could be coded just once? This is probably a
stupid question, but I just don't know if the vendor name and part number
are well-defined fields in the same way as the PCI vendor and device ID
fields - I never really got into ISA hardware.
Michael Brown
http://www.fensystems.co.uk

Michael Brown <mbrown@...> writes:
> On 22 May 2002, Eric W. Biederman wrote:
> > > >BTW, where do I get the ID numbers from for ISA cards? For PCI, I am just
> > > >using dev.vendor and dev.dev_id (in config.c), but I can't see an obvious
> > > >equivalent for ISA.
> > > There isn't any that I'm aware of at least for the non-PnP variety. We
> > > may have to invent some. Possibly 4 distinct bytes from the common name,
> > > or 2 from the same vendor table, plus 2 made up, might serve.
> > The only kind of ID I can think of is the vendor name, and part number, of
> > the ethernet chip.
> > It might not be the smallest string but it would be something you
> > could look up. And it is already distinct for manufacturing and
> > tracking reasons.
>
> Is this information already available somewhere within Etherboot?
No so that it is trivial to get at. But basically to actually work
on the driver that information is needed to look up the documentation.
Eric

On 22 May 2002, Eric W. Biederman wrote:
> > >BTW, where do I get the ID numbers from for ISA cards? For PCI, I am just
> > >using dev.vendor and dev.dev_id (in config.c), but I can't see an obvious
> > >equivalent for ISA.
> > There isn't any that I'm aware of at least for the non-PnP variety. We
> > may have to invent some. Possibly 4 distinct bytes from the common name,
> > or 2 from the same vendor table, plus 2 made up, might serve.
> The only kind of ID I can think of is the vendor name, and part number, of
> the ethernet chip.
> It might not be the smallest string but it would be something you
> could look up. And it is already distinct for manufacturing and
> tracking reasons.
Is this information already available somewhere within Etherboot?
Michael Brown
http://www.fensystems.co.uk

Michael Brown <mbrown@...> writes:
> On 22 May 2002, Eric W. Biederman wrote:
> > > OK, this I like. Is there any easy way to identify which rows in pcimap
> > > correspond to network-card modules?
> > Cross reference against kernel/drivers/net.
> > Or look at the class to see if is 0200. Bu I don't think that is usually
> > supplied.
>
> Some degenerate network drivers can exist outside of kernel/drivers/net -
> for example in Mandrake 8.2 the prism2 and e100/e1000 family of drivers
> exist in kernel/3rdparty. :-(
>
> Are there any symbols that all network modules export? Would this be a
> viable method for testing?
Try import and I think it is a viable method.
I believe init_etherdev and it's cousing functions for initializing
ethernet cards could be tested for.
Eric

On 22 May 2002, Eric W. Biederman wrote:
> > In my opinion, ASCII text is always preferred. For DHCPD maintainence
> > binary data is not a good idea ! And the byte space is definitive not
> > critical in this point (3 or 8 bytes ....)
> Given that we have a maximum of 1500 bytes in the DHCP packet, size
> matters a lot.
Is it so critical in the DHCP request packet though? The DHCP request
packet is probably going to be tiny relative to the DHCP acknowledge
packet.
Michael Brown
http://www.fensystems.co.uk