etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Etherboot 4.7.16 (development) released

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

Ken Yap <ke...@nl...> writes:

> + Started on Elf support in mknbi.

I'm just wondering where you are going here.  I have done
some parellel work (documentation is still pending), and would like
to see how it compares.  In particular I created a variation on 
the multiboot stuff that allows an arbitrary number of parameters
to be defined instead of just that limited structure.

Eric

[Etherboot-developers] Etherboot 4.7.16 (development) released

[Ken Y. <ke...@nl...>]

Happy New Year!

I have released Etherboot 4.7.16 at http://etherboot.sourceforge.net

Changes in this release:

+ Duplicated 3c900 PCI IDs under 3c595 as some NICs apparently detect
and work with the 3c595 driver but not the 3c90x driver, according to a
report from Dirk Pfau. (The 3c90x series has two modes of operation,
programmed I/O mode descended from the 3c509, good only for 10 Mb
operation, and bus mastering mode, essential for 100 Mb operation. For
network booting, either mode is acceptable.)

+ Removed auto from kernel parameters; it's the default already.

+ Use hardware timer instead of loop counter for transmit timeout in
3c90x.c.

+ Define a jmpbuf type for setjmp and longjmp. Trim size to 7 longs,
that's all that's needed. Standardise the return values from longjmp:
-2: loader error, -1: timeout or ESC, 0: normal, 1..: return from
program.

+ Ansify function headers in bootmenu.c.

+ Make _int10 return ax | (bx << 16) as result so that these can be
accessed more efficiently in the following statements.

+ Make handleansi take unsigned int instead of unsigned char as
argument, otherwise extra code will be generated to handle this
according to ANSI rules.  (Quite significant saving of 55 bytes.) Rename
it ansi_putc for clarity.

+ Prefix getc, putc and ischar with console_ to make things clearer and
to avoid confusion with the Unix getc, putc.

+ Add menu as a target to mknbi. Started source code for menu extension.
Successfully transferred control to menu at 0x10000 and back. ANSI
colour controls work, at least. Return end needs more work.

+ Started on Elf support in mknbi.

MD5 sums:

0f5a1a16fd828c6ed74bf39027ae23ec  etherboot-4.7.16.tar.bz2
5c4c063301061ce943e045e9c56b1b3b  etherboot-4.7.16.tar.gz

[Etherboot-developers] help - unsubscribe

[Raghunandan N. <rag...@wi...>]

Re: [Etherboot-developers] NE2k probing

[Ken Y. <ke...@nl...>]

>Since ethX is brought up well before sound in this case, would it not make
>sense to probe there?  Even if there happens to be a sound card there, I
>dont think it would cause any trouble....  I might be wrong here though, I
>know absolutly nothing about C, let alone programming hardware stuff.

The list in Etherboot matches the one in the Linux kernel. Since you can
edit the address list yourself, you can decide for yourself if you want
to probe that address.

Re: [Etherboot-developers] NE2k probing

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

> Since ethX is brought up well before sound in this case, would it not make
> sense to probe there?  Even if there happens to be a sound card there, I
> dont think it would cause any trouble....  I might be wrong here though, I
> know absolutly nothing about C, let alone programming hardware stuff.

Legacy hardware (and most ISA bus hardware should be considered as
such) is really troublesome. You cannot reliably find out which
hardware is installed unless you start probing for it. Probing
involves writing (bad idea) or reading (only slight better) from
I/O addresses and ports where you might expect hardware to live. If
you see a pattern that you recognize, you assume that a particular
piece of hardware has been installed in the machine. The problem here
is that a) you might not always recognize a signature properly, and
b) even reading from ports and address can reconfigure hardware. The
latter can result in all kinds of unexpected behavior, from the
hardware just becoming unavailable to the entire machine crashing.
Thus, you must be extremely careful when probing and you should try
to touch as few addresses as possible. You might remember, that for
a very long time, Linux had problems with the initialization order of
device drivers, because there where rather tricky requirements as to
in which order autoprobing should be done. With the gradual
disappearance of ISA bus hardware this has now become better. ISA PnP
is some improvement (though still pretty ugly), PCI is a lot better,
and both PCMCIA and USB have enough meta information to properly
detect hardware and automatically load the right drivers.


Markus

-- 
Markus Gutschke                                Resonate, Inc.
3637 Fillmore Street #106                      385 Moffett Park Drive
San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
+1-415-567-8449                                +1-408-548-5528
ma...@gu...                            mgu...@re...

Re: [Etherboot-developers] NE2k probing

[bcrawford <bcr...@ho...>]

Ken Yap wrote:

> >Sorry if this is an FAQ.  I am trying to get etherboot to pick up my
> >ne2000 isa nic on 0x240..
> >Currently, it fails booting of a floppy saying:
> >Probing...[NE*000]No adapter found<sleep>
> >
> >most programs that I have used on this card fail to pick it up on this
> >port, so I normally have to force it.
> >
> >Could someone point me in the general direction of where/what I would
> >have to edit to get autoprobing to look on 0x240 for this card, or even
> >a way to hard code it onto this address?
>
> See in Makefile: NE_SCAN.
>
> Or adjust the card to one of the normal addresses. I think 0x240 was
> left out because it's often occupied by sound cards, etc.
>
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/mailman/listinfo/etherboot-developers

Thanks, I got it running and probing just fine now...

Since ethX is brought up well before sound in this case, would it not make
sense to probe there?  Even if there happens to be a sound card there, I
dont think it would cause any trouble....  I might be wrong here though, I
know absolutly nothing about C, let alone programming hardware stuff.
 brent

Re: [Etherboot-developers] NE2k probing

[Ken Y. <ke...@nl...>]

>Sorry if this is an FAQ.  I am trying to get etherboot to pick up my
>ne2000 isa nic on 0x240..
>Currently, it fails booting of a floppy saying:
>Probing...[NE*000]No adapter found<sleep>
>
>most programs that I have used on this card fail to pick it up on this
>port, so I normally have to force it.
>
>Could someone point me in the general direction of where/what I would
>have to edit to get autoprobing to look on 0x240 for this card, or even
>a way to hard code it onto this address?

See in Makefile: NE_SCAN.

Or adjust the card to one of the normal addresses. I think 0x240 was
left out because it's often occupied by sound cards, etc.

[Etherboot-developers] NE2k probing

[bcrawford <bcr...@ho...>]

Hello list,
Sorry if this is an FAQ.  I am trying to get etherboot to pick up my
ne2000 isa nic on 0x240..
Currently, it fails booting of a floppy saying:
Probing...[NE*000]No adapter found<sleep>

most programs that I have used on this card fail to pick it up on this
port, so I normally have to force it.

I have been grepping around the sources for something like a portlist
that it might use to scan for the card (like the way Donald Becker's
ne.c in the linux kernel does it)...  buy i couldnt find anything.

Could someone point me in the general direction of where/what I would
have to edit to get autoprobing to look on 0x240 for this card, or even
a way to hard code it onto this address?

thanks
-brent

[Etherboot-developers] Etherboot 4.7.15 (development) released

[Ken Y. <ke...@nl...>]

First of all, best wishes for the holiday season to all on these lists.
Have fun, I know I will.

I have released Etherboot 4.7.15 at http://etherboot.sourceforge.net

This is a development release leading to a new stable series. There will
be no further releases of 4.6. As it is a development release, EXPECT
BREAKAGE. But please help test it by reporting all problems.

Changes in 4.7.15:

+ Thanks to Mark VandeWettering for the start of HomePNA (networking
over phone lines) support for the AMD 79C978.

+ Bug fixed in first32.c handling of (ip|nfsroot)=X where X is not rom.

+ first32pm.linux works. No need to go into real mode to call first32pm
and then it goes back to protected mode. Paves the way for extension
routines to Etherboot.  Implement program returns to loader flag in
header field.  Added option to mknbi to specify this.

+ first32*.linux: Check tag 128 present and correct before appending tag
129. Also tag 129 should be appended to parameters before substitutions.

+ Merged cleanup_net into cleanup since they are always called together.

+ Floppy booting doesn't need to be passed BOOTP_DATA_ADDR.

+ Clean up variables associated with tagged image loading in osloader.c.

MD5 sums:

db1965db68d600ada71d0eb0e491eed7  etherboot-4.7.15.tar.bz2
70646cbd6cc7e2aad4d4b1f947c076b5  etherboot-4.7.15.tar.gz

[Etherboot-developers] Lance/HomePNA patches + problems.

[Mark V. <ma...@pi...>]

I started working on hacking support for HomePNA ethernet cards into
netboot, and uncovered a couple of problems.

For those of you who don't know what they are, the HomePNA ethernet
cards are 1Mbit network cards which use existing phoneline wiring to 
communicate.  I use them in my house to keep from stringing additional
ethernet cables throughout the four rooms that have computers in my
house, and use them to share cable modem access to everyone.   

The project I have in mind is to take a set-top box like the one that
SuperTek makes, and netboot it to run a small version of FreeBSD, and 
then use it to stream mp3s or the like from my main network server. 

In any case, these cards are based upon the AMD 79C978 chipset, which 
is a variant of their PC-net chipset, which is compatible with the old
lance drivers.

Well, for the most part.

The following patch is a start.  The primary modifications in the patch
below are to get the card recognized and probed properly, which it
seems to do.  The HomePNA cards also require a tiny bit of code to set
the media properly to use the phoneline transciever (some of them also
have regular 10Mbit ethernet transcievers).

While digging this, I also uncovered a bug in the reset code, where
chip_table[chip_version] is examined.  This should really be
chip_table[lance_version].  This patch fixes a couple of those problems.

Unfortunately, I still seem to be having trouble after enabling these
changes.  The system properly requests and receives DHCP messages, and
uses TFTP to download a MOTD.  I then tried to download a DRDOS
(version 7.02) netboot image I made with mknbi-dos, which hangs while
trying to load from the network.  When I recompiled the lancpci.fd0
module with debugging on, I notice that just before timing out, it
receives a packet which has CSR0 set to 4B3, which indicates

	bit 15 ERR
	bit 11 MERR memory error
	bit 9 TINT transmit interrupt
	bit 8 IDON initialization done
	bit 1 START
	bit 0 INIT

The normal value is apparently 33, which indicates Receive Interrupt, 
	Transmit Interrupt, and START and INIT.

I'm wondering if there is some problem with the error handling in 
lance_poll().  I've downloaded some of AMDs specs for the chipset, and 
it seems roughly allright, but I'm no device driver expert (haven't
written any in 15 years) and certainly no expert on the lance.

Anybody with any suggestions?  I'll keep hacking away on it, but I 
thought I'd let these patches out in hopes that someone else might
be able to help.

	Thanks!


diff -c /home/markv/etherboot-4.7.14/src/config.c ./config.c
*** /home/markv/etherboot-4.7.14/src/config.c	Thu Dec 14 04:10:36 2000
--- ./config.c	Mon Dec 18 22:11:34 2000
***************
*** 85,90 ****
--- 85,92 ----
  #ifdef	INCLUDE_LANCE
  	{ PCI_VENDOR_ID_AMD,		PCI_DEVICE_ID_AMD_LANCE,
  		"AMD Lance/PCI", 0, 0, 0, 0},
+ 	{ PCI_VENDOR_ID_AMD_HOMEPNA,	PCI_DEVICE_ID_AMD_HOMEPNA,
+ 		"AMD Lance/HomePNA", 0, 0, 0, 0},
  #endif
  #ifdef	INCLUDE_RTL8139
  	{ PCI_VENDOR_ID_REALTEK,	PCI_DEVICE_ID_REALTEK_8139,
diff -c /home/markv/etherboot-4.7.14/src/lance.c ./lance.c
*** /home/markv/etherboot-4.7.14/src/lance.c	Thu Dec 14 04:27:30 2000
--- ./lance.c	Mon Dec 18 22:05:14 2000
***************
*** 89,94 ****
--- 89,95 ----
  
  #define	LANCE_MUST_PAD		0x00000001
  #define	LANCE_ENABLE_AUTOSELECT	0x00000002
+ #define	LANCE_SELECT_PHONELINE	0x00000004
  #define	LANCE_MUST_UNRESET	0x00000008
  
  /* A mapping from the chip ID number to the part number and features.
***************
*** 114,119 ****
--- 115,122 ----
  		LANCE_ENABLE_AUTOSELECT},
          {0x2621, "PCnet/PCI-II 79C970A",        /* 79C970A PCInetPCI II. */
                  LANCE_ENABLE_AUTOSELECT},
+         {0x2626, "PCnet/HomePNA 79C978",        
+                 LANCE_ENABLE_AUTOSELECT|LANCE_SELECT_PHONELINE},
  	{0x0, "PCnet (unknown)",
  		LANCE_ENABLE_AUTOSELECT},
  };
***************
*** 123,128 ****
--- 126,132 ----
  #define	virt_to_bus(x)		((unsigned long)x)
  
  static int			chip_version;
+ static int			lance_version;
  static unsigned short		ioaddr;
  #ifndef	INCLUDE_LANCE
  static int			dma;
***************
*** 205,213 ****
  	/* Reset the LANCE */
  	(void)inw(ioaddr+LANCE_RESET);
  	/* Un-Reset the LANCE, needed only for the NE2100 */
! 	if (chip_table[chip_version].flags & LANCE_MUST_UNRESET)
  		outw(0, ioaddr+LANCE_RESET);
! 	if (chip_table[chip_version].flags & LANCE_ENABLE_AUTOSELECT)
  	{
  		/* This is 79C960 specific; Turn on auto-select of media
  		   (AUI, BNC). */
--- 209,217 ----
  	/* Reset the LANCE */
  	(void)inw(ioaddr+LANCE_RESET);
  	/* Un-Reset the LANCE, needed only for the NE2100 */
! 	if (chip_table[lance_version].flags & LANCE_MUST_UNRESET)
  		outw(0, ioaddr+LANCE_RESET);
! 	if (chip_table[lance_version].flags & LANCE_ENABLE_AUTOSELECT)
  	{
  		/* This is 79C960 specific; Turn on auto-select of media
  		   (AUI, BNC). */
***************
*** 215,220 ****
--- 219,253 ----
  		/* Don't touch 10base2 power bit. */
  		outw(inw(ioaddr+LANCE_BUS_IF) | 0x2, ioaddr+LANCE_BUS_IF);
  	}
+ 	/* HomePNA cards need to explicitly pick the phoneline interface.
+ 	 * Some of these cards have ethernet interfaces as well, this
+ 	 * code might require some modification for those.
+   	 */
+         if (chip_table[lance_version].flags & LANCE_SELECT_PHONELINE) {
+                 short media, check ;
+                 /* this is specific to HomePNA cards... */
+                 outw(49, ioaddr+0x12) ;
+                 media = inw(ioaddr+0x16) ;
+ #ifdef DEBUG
+                 printf("media was %d\n", media) ;
+ #endif
+                 media &= ~3 ;
+                 media |= 1 ;
+ #ifdef DEBUG
+                 printf("media changed to %d\n", media) ;
+ #endif
+                 media &= ~3 ;
+                 media |= 1 ;
+                 outw(49, ioaddr+0x12) ;
+                 outw(media, ioaddr+0x16) ;
+                 outw(49, ioaddr+0x12) ;
+                 check = inw(ioaddr+0x16) ;
+ #ifdef DEBUG
+                 printf("check %s, media was set properly\n", 
+ 			check ==  media ? "passed" : "FAILED" ) ; 
+ #endif
+ 	}
+  
  	/* Re-initialise the LANCE, and start it when done. */
  	/* Set station address */
  	for (i = 0; i < ETH_ALEN; ++i)
***************
*** 352,358 ****
  static int lance_probe1(struct nic *nic)
  #endif
  {
! 	int			reset_val, lance_version;
  	unsigned int		i;
  	Address			l;
  	short			dma_channels;
--- 385,391 ----
  static int lance_probe1(struct nic *nic)
  #endif
  {
! 	int			reset_val ;
  	unsigned int		i;
  	Address			l;
  	short			dma_channels;
diff -c /home/markv/etherboot-4.7.14/src/pci.h ./pci.h
*** /home/markv/etherboot-4.7.14/src/pci.h	Tue Dec 12 23:05:18 2000
--- ./pci.h	Mon Dec 18 22:10:51 2000
***************
*** 128,133 ****
--- 128,135 ----
  #define PCI_DEVICE_ID_INTEL_82562	0x2449
  #define PCI_VENDOR_ID_AMD		0x1022
  #define PCI_DEVICE_ID_AMD_LANCE		0x2000
+ #define PCI_VENDOR_ID_AMD_HOMEPNA	0x1022
+ #define PCI_DEVICE_ID_AMD_HOMEPNA	0x2001
  #define PCI_VENDOR_ID_SMC_1211          0x1113
  #define PCI_DEVICE_ID_SMC_1211          0x1211
  #define PCI_VENDOR_ID_DEC		0x1011


-- 
/* __  __  __   ___      __ */ float m,a,r,k,v;main(_){for(;r<4;r+=.1){for(a=0;
/*|  \/  | \ \ / \ \    / / */ a<4;a+=.06){k=v=0;for(_=99;--_&&k*k+v*v<4;)m=k*k
/*| |\/| |  \ V / \ \/\/ /  */ -v*v+a-2,v=2*k*v+r-2,k=m;putchar("X =."[_&3]);}
/*|_|  |_ark \_ande\_/\_ettering <ma...@te...> */ puts("");}}

[Etherboot-developers] Re: [Etherboot-users] ip=dhcp in 2.2.18 kernels

[Ken Y. <ke...@nl...>]

>Just a hint for people who wants to use this second dhcp request
>with kernel 2.2.18:
>Don't add the --ipaddrs, --rootdir options from mknbi, use instead:
>   mknbi-linux --output=/tmp/vmlinuz.tulip bzImage
>Then add some kernel parameters to the dhcpd.conf:
>   option option-129  "ip=dhcp root=/dev/nfs"
>
>2.2.18 doesn't start a dhcp request by itself, so you need ip=dhcp.

Ah, I found what the problem was. In 2.2.18, they turned off the default
of doing a IP autoconfig, you need to explicitly specify using ip=X
where X is one of the options off, none, on, all, bootp, dhcp, rarp, or
both (bootp and rarp, not bootp and dhcp). See the kernel source file
net/ipv4/ipconfig.c for the list.

So I have enhanced mknbi-1.1 to accept ip= (or ipaddrs=) followed by one
of those options. You can also use the tag 129 method of course but
since the tagged image is meant to be netbooted you might as well bundle
the option into the image instead of having to put it in the DHCP/BOOTP
config file. At the same time, this exposed a bug in first32.linux so
this was a useful exercise.

Here are the patches, until 4.7.15 is released:

diff -ur etherboot-4.7.14/mknbi-1.1/first32.c etherboot-4.7.15/mknbi-1.1/first32.c
--- etherboot-4.7.14/mknbi-1.1/first32.c	Mon Dec 18 12:59:14 2000
+++ etherboot-4.7.15/mknbi-1.1/first32.c	Wed Dec 20 22:38:33 2000
@@ -33,7 +33,6 @@
 
 */
 
-#define		DEBUG	1
 #define		PARAMSIZE	512
 
 extern void printf(const char *, ...);
@@ -323,7 +322,8 @@
 			*op++ = ':';
 		outtag(p);
 		discard_arg();
-	}
+	} else
+		copy_nonws();
 }
 
 static inline int skipws(void)
@@ -352,6 +352,11 @@
 static inline void process_params(void)
 {
 	int			i;
+	unsigned char		*p;
+	union {
+		unsigned long	l;
+		unsigned char	c[4];
+	} u;
 
 	while (skipws() != '\0') {
 		if ((i = copy_and_match()) >= 0)
@@ -360,7 +365,9 @@
 			copy_nonws();
 		*op++ = ' ';
 	}
-	outtag(gettag(BOOTP_RFC_CMDAD));	/* Append T129 */
+	p = gettag(BOOTP_RFC_VID);	/* check T128 present and correct */
+	if (*p == 6 && (memcpy(u.c, p + 1, 4), u.l == VEND_EB))
+		outtag(gettag(BOOTP_RFC_CMDAD));	/* Append T129 */
 	/* There may be a space after the last arg, probably does not matter
            but this is a reminder */
 	*op = '\0';
diff -ur etherboot-4.7.14/mknbi-1.1/first32.h etherboot-4.7.15/mknbi-1.1/first32.h
--- etherboot-4.7.14/mknbi-1.1/first32.h	Sun Dec 17 17:29:44 2000
+++ etherboot-4.7.15/mknbi-1.1/first32.h	Tue Dec 19 22:59:15 2000
@@ -10,6 +10,7 @@
 #define	RFC_1048	0x63538263
 #define	VEND_CMU	0x00554D43
 #define	VEND_STAN	0x4E415453
+#define	VEND_EB		0x687445E4	/* äEth */
 
 #define BOOTP_RFC_NOP	0		/* RFC vendor tag for NO-OP */
 #define BOOTP_RFC_MSK	1		/* RFC vendor tag for netmask */
diff -ur etherboot-4.7.14/mknbi-1.1/mknbi.pl etherboot-4.7.15/mknbi-1.1/mknbi.pl
--- etherboot-4.7.14/mknbi-1.1/mknbi.pl	Mon Dec 18 10:56:04 2000
+++ etherboot-4.7.15/mknbi-1.1/mknbi.pl	Wed Dec 20 22:49:35 2000
@@ -94,7 +94,7 @@
 	if (defined($ipaddrs)) {
 		if ($ipaddrs eq 'kernel') {
 			undef($ipaddrs);
-		} elsif ($ipaddrs ne 'rom') {
+		} elsif ($ipaddrs !~ /^(rom|off|none|on|any|dhcp|bootp|rarp|both)$/) {
 			$ipaddrs = &resolve_names($ipaddrs);
 		}
 	}
@@ -373,6 +373,7 @@
 	'param=s' => \$param,
 	'append=s' => \$append,
 	'rootdir=s' => \$rootdir,
+	'ip=s' => \$ipaddrs,
 	'ipaddrs=s' => \$ipaddrs,
 	'rdmode=s' => \$rdmode,
 	'harddisk!' => \$simhd,
@@ -472,13 +473,22 @@
 If the name given to the option starts with C</dev/>, the corresponding
 device is used as the root device, and no NFS directory will be mounted.
 
-B<--ipaddrs=>I<string> Define client and server IP addresses.
+B<--ip=>I<string> Define client and server IP addresses.
+B<--ipaddrs=>I<string> is a synonym for the same thing.
 
 In the absence of this option no IP addresses are defined, and the
 kernel should determine the IP addresses by itself, usually by using
 RARP, BOOTP or DHCP.  Note that the kernel's query is I<in addition to>
 the query made by the bootrom, and requires the IP: kernel level
 autoconfiguration (CONFIG_IP_PNP) feature to be included in the kernel.
+Note: In Linux kernels 2.2.x where x >= 18, it is B<necessary> to
+specify one of the enabling options in the next paragraph to cause the
+IP autoconfiguration to be activated. Unlike previous kernels in the 2.2
+series, IP autoconfiguration does not happen by default.
+
+If one of the following: C<off, none, on, any, dhcp, bootp, rarp, both>,
+is given, then the option will be passed unmodified to the kernel and
+cause that autoconfig option to be chosen.
 
 If C<rom> is given as the argument to this option, all necessary IP
 addresses for NFS root mounting will be inherited from the BOOTP/DHCP
@@ -488,7 +498,7 @@
 image. Then, all addresses must be seperated by a colon, and ordered in
 the following way:
 
-C<--ipaddrs=>I<client:server:gateway:netmask:hostname[:dev]>
+C<--ip=>I<client:server:gateway:netmask:hostname[:dev]>
 
 Using this option B<mknbi-linux> will automatically convert system names
 into decimal IP addresses for the first three entries in this string. The
@@ -535,7 +545,7 @@
 B<130> With this tag it is possible to the select the network adapter
 used for mounting root via NFS on a multihomed diskless client. The
 syntax for the I<string> value is the same as for the C<dev> entry used
-with the B<--ipaddrs=> option as described above. However note that the
+with the B<--ip=> option as described above. However note that the
 B<mknbi-linux> runtime loader does not check the syntax of the string.
 
 The same tags will work in DHCP with the appropriate syntax for your

Re: [Etherboot-developers] 4.6.13 patches

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

Ken Yap <ke...@nl...> writes:

> I've started work on 4.6.13. One thing I've put in is for the client to
> send an option 60 (vendor-class-identifier) of "Etherboot" in the
> DHCPDISCOVER message.  dhcp-3.0 can use this information in conditionals
> and presumably can be set to reply with a tag that says, yes I know
> Etherboot.  Then Etherboot can ignore offers from other DHCP servers on
> the same segment (a compile option).

> If anybody is happy to install ISC dhcp-3.0 and help test this, let me
> know.

I'll help test this I don't have a lot of time but I'll do what
I can do in my spare moments.

Eric

[Etherboot-developers] Re: Etherboot

[Ken Y. <ke...@nl...>]

>    I still use 8088's (yes, old pc's) They work fine. With a few simple
>mods to the Crynwar drivers, (I call it ne20008b), I boot them and then
>attach a DOS drive letter to one of our various Linux boxen. Most ne2000
>16 bit ISA cards also work fine in 8 bit mode! :) For networking I use
>XFS-186 which used to be around the net. There is a version of DOS XFS
>that is part of the SUSE distribution (not to be confused with X Font
>Services).
>
>    Alas (and this is the reason for my note), I can't use Etherboot. Why?
>Apparently Etherboot needs memory above 640k?

Unfortunately I feel that XTs and ATs have reached the end of the line
and I would rather spend effort on supporting newer hardware. The 32/16
bit split personality conditional compilation made the code rather ugly
and it was an effort to keep them in sync.  If you wish to hack
Etherboot please feel free, however I won't be incorporating 16 bit
support in future versions, so it would be best if you made a code fork.

Re: [Etherboot-developers] Etherboot 4.7.14 (development) released

[Ken Y. <ke...@nl...>]

>I have a small observation about frame sizes.  I am not sure how
>this might affect Etherboot, but VLANs add extra bytes into an
>ethernet packet.  It would be nice if Etherboot understood VLANs
>at some point, but for now it would be great if the design of
>Etherboot did not preclude using longer frames.  I haven't looked
>closely, but it sounds like it shouldn't be a problem.

Can you please explain how these larger frames would be reflected in
what the NIC sees? As I understand, in many cases the hardware discards
oversized frames anyway.

[Etherboot-developers] Etherboot 4.7.14 (development) released

[Ken Y. <ke...@nl...>]

I have released Etherboot 4.7.14 at http://etherboot.sourceforge.net

This is a development release leading to a new stable series. There will
be no further releases of 4.6. As it is a development release, EXPECT
BREAKAGE. But please help test it by reporting all problems.

Changes in 4.7.14:

+ Added more IDs for eepro100 variants taken from the Linux 2.2.18
source. Should handle the EEPROM properly now, a few defines were wrong
in 4.7.13.  Loop counter timeouts in eepro100.c replaced with hardware
timeouts.  Don't loop waiting for packet in _poll, return 0 immediately.

+ first32.linux works. Does kernel arguments and ramdisk but doesn't do
appended parameters from menu selections, which should be replaced by a
more elegant menu scheme anyway.  Needed gateA20 routines in
mknbi-1.1/first32.c otherwise cannot access extended memory.
first32.linux should be able to handle memory > 64 MB, which the old one
couldn't.  Support for first32pm call protocol added.

+ 3c595.c changed to use hardware timer for delays. Transmit routine
waits for a fixed period after transmitting. Changed to check
S_COMMAND_IN_PROGRESS bit. It also contains some of the same unused
variables as 3c509.c and mentions 3c509 in some comments. Cleaned up.

+ Hmm, how come this wasn't fixed long ago? Should discard BOOTP/DHCP
replies that are not to broadcast or own MAC address. I guess xid caught
practically of the non-matching packets.

+ Removed last vestiges of ETHERBOOT32 and ETHERBOOT16.

+ ETHER_ADDR_SIZE => ETH_ALEN, ETHER_HDR_SIZE => ETH_HLEN,
ETHER_MIN_PACKET => ETH_ZLEN, ETHER_MAX_PACKET => ETH_FRAME_LEN.  More
Linuxy and therefore more familiar to programmers.

+ Cleared up confusion with 60/64 and 1514/1518 for minimum and maximum
frame sizes. Practically always the right numbers are 60/1514, except
that some chips count the FCS in the receive length, then we have to use
64/1518.

+ Make __swap32 and __swap16 inline routines available globally as
swap32 and swap16. eepro.c can use swap16 instead of making up one.

+ Make aui field in nic.h an int since it will be padded to a longword
boundary anyway and call it flags so that other drivers can use it for
their own purposes. Currently only 3c503 uses it to indicate AUI xcvr.

+ Make sprintf return number of characters written instead of a pointer
to the last char written to be more consistent with standard C.

MD5 sums:

56ab552687b0ac72a9b18a07ebee0cd2  etherboot-4.7.14.tar.bz2
178e86a787357bd71c6c691a2a4287f3  etherboot-4.7.14.tar.gz

[Etherboot-developers] question mknbi?

[RAVELO R. <a19...@pu...>]

 How I apply el mknbi, i have a problem to build the image ??

				gino ravelo	 

[Etherboot-developers] Etherboot 4.7.13 (development) released

[Ken Y. <ke...@nl...>]

I have released Etherboot 4.7.13 at http://etherboot.sourceforge.net

This is the first of development releases leading to a new stable
series. There will be no further releases of 4.6. As it is a development
release, EXPECT BREAKAGE. But please help test it by reporting all
problems.

Changes in 4.7.13:

+ Jim McQuillan sent in a patch for first-linux.S where it was assuming
the argument in tag 129 (additional parameters) is a null terminated
string, when it's a length counted string. A new routine, addkarg was
created to handle this.

+ eepro100 should handle newer NICs with 256 byte EEPROMs now. This
includes the onboard NICs on some motherboards, see file NIC. Thanks to
Stephan Lauffer for helping with the fixes. WARNING: This code may have
a bug that causes the onboard EEPROM to be corrupted. We believe we have
found and removed the bug but please proceed with care.

+ DHCPDISCOVER was sending out one byte too many for PARAM_LIST.

+ In DHCPDISCOVER send "Etherboot" in VENDOR_CLASS_ID option (60).  Will
add code later to check for "Etherboot" in vendor encapsulated options.

+ Used µs timer routines in 3c509 for more accurate timing and hence
better hardware detection. Use COMMAND_IN_PROGRESS bit to detect
transmit complete instead of waiting for a fixed amount of time. Get rid
of eth_vendor and associated tests, it doesn't serve any useful purpose
since the driver was modularised long ago and the 3c509 detection status
is stored outside of the driver now. Got rid of some unused global
statics in 3c509.c, leftovers when the drivers were monolithic. Wait 2
seconds after enabling TP interface to give it time to come up. This
allows us to get rid of T509HACK in main.c.

+ Get rid of eth_vendor and associated tests in cs89x0.c, same reasons
as for 3c509.c.

+ Moved the rest of the VENDOR_ and FLAG_ defines into ns8390.h, as
ns8390.c is the only file that uses them now.

+ Use lower 32 bits of node address + current time for xid (network byte
order). More likely to be distinct from other clients than just the
current time, which is similar for all clients booted at about the same
time.

+ Support for 16-bit code has been removed.  XTs and ATs are pretty much
dead now and in fact many Etherboot/16 drivers have been broken for a
while but nobody noticed. This should make some of the code easier to
maintain.  If you really wanted 16 bit support, use an older version of
Etherboot, maybe 4.4 or something like that, not sure when things
started breaking for 16 bit mode.

+ Should not store IP and UDP headers at BOOTP_DATA_ADDRESS. Redefined
bootp_t without IP and UDP headers. Now requested size of bootp packet
matches storage available. Do not add sizeof(iphdr) + sizeof(udphdr) to
bootp pointer in start32.S:xstart now. start16.S:xstart was broken
because it did not do this addition but nobody noticed.

+ Removed array kernel_buf, saving 128 bytes and replaced with
KERNEL_BUF, a pointer into the bp_file of the bootp_reply structure at
BOOTP_DATA_ADDR. Note: this depends on the server not sending Option
Overload which would use the sname and file fields for options, but we
don't request this option so it shouldn't.  Removed char *kernel,
instead check KERNEL_BUF[0] just before booting and if null, use
fallback filename.  (This is needed for future extensions to booting
protocol.)

+ Define a shorter tftpreq_t type for making requests instead of using a
full sized tftp_t packet to reduce stack usage.

+ Defined macros for htonl/htons/ntohl/ntohs for cases where the operand
is a constant, saving a function call.

+ Started on first32.c, a protected mode 32-bit version of
first-linux.S, which should be far easier to read and maintain. Will
boot basic Linux kernels correctly but doesn't handle ramdisk or
kernel arguments yet.

+ Updated nfs-swap documentation in contrib/nfs-swap to point to
Claus-Justus Heine's new web page.

MD5 sums:

2b57c2eb33fa8d2addea6f56acd649ec  etherboot-4.7.13.tar.bz2
677674c1ec9d20c43ed08080716cbfc0  etherboot-4.7.13.tar.gz

[Etherboot-developers] Re: [Etherboot-users] start remoteboot from running dos

[Ken Y. <ke...@nl...>]

>The idea of making Etherboot only listen to certain servers might work
>in
>some situations, but what happens when you put a linux server in for
>that
>dhcp server, and all of a sudden all of the other clients on the network
>start getting IP addresses (or rejections) from that new server.  You've
>just broken a network that was working.

Mmmm, faulty base assumption. With vendor-client-identifier ISC DHCP 3.0
can not only accept selected clients, i.e. Etherboot, but also ignore
other clients, i.e. Windoze workstations. So you should be able add such
a server to a network and not affect existing clients.

Re: [Etherboot-developers] Re: [Etherboot-users] start remoteboot from running dos

[Marty C. <md...@th...>]

On 11/30/2000 10:42 PM Ken Yap ke...@nl... wrote:
>The problem is that .com files rely on a clean environment. Loadlin does
>the useful service of cleaning up all the junk that is loaded in a
>typical DOS or Windoze setup.

After a fair bit of effort I have been able to get LOADLIN to load an 
Etherboot image.  Unfortunately, it hangs just before running the kernel 
(after TFTP and the netboot loader copyright messages).  I suspect that 
LOADLIN is loading something in an unexpected (for Etherboot) location, 
and it can't find the kernel entry after it loads.  It's around here 
somewhere :-)
LOADLIN does some very twisted things to memory to try and deal with 
DOS/Windows, and there's only so much faking out we can do in Etherboot.

Perhaps having gotten this far, people more intimate with loaders and 
LOADLIN might have suggestions.  I'll debug it some more after resting.

>I'm not interested in hacks that bypass IP address management. Even
>disked Windoze uses DHCP. That should give you a hint of the ire you
>will get from sysadmins when they hit a rogue workstation that
>unilaterally takes an IP address and causes problems for other hosts on
>the network.
>What is it with DHCP? You'd have to setup a TFTP and NFS server anyway.
>If it's a problem working with existing DHCP servers, I'd rather pursue
>approaches that allow the boot ROM to pick the right DHCP server, which
>is what the vendor-class-identifier is about.

I understand your point.  I think there are environments where people 
need the flexibility of Etherbooting without having control of or access 
to a DHCP/BOOTP server.  TFTP and NFS are different from BOOTP/DHCP in 
that one doesn't have to do broadcasts to get to them, and there isn't 
all of this "Multiple DHCP Servers considered harmful" interference.  
Heck, one could tftp a kernel from almost anything, and then NFS mount 
from another machine.

I think the issue is worth thinking about, even if it's not likely to 
make it into the standard distribution.

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] Re: [Etherboot-users] start remoteboot from running dos

[Jim M. <ja...@Mc...>]

Marty and I were talking about this, because I have been approached
by many people lately who are looking for a way to boot a diskless
client without using bootp or dhcp.

I know the benefits of using bootp/dhcp, and I always try to convince
them that they really should use one of those methods.  But, they
insist that they can't, for whatever reason.  They MUST enter a static
address into a workstation and use that.

Two recent groups that have talked about this are the Fermi lab in
Illinois
and Lawrence Livermore labs in California.  Both are very large shops, 
(over 1000 workstations between the two of them ), and
both can't/won't use dhcp because they don't have full control over
their networks.  There are already dhcp servers and they can't get
access to them to add their own entries.

At this point, Fermi is looking at ThinkNics booting from a 
CDROM.  Each CDROM is customized to include the proper IP info.

So, i've been searching for a way to deal with this.

I've thought about hardcoding the IP info in each bootrom, but that
really sucks.

A couple of weeks ago, I was out at Comdex in Vegas and I ran into a
company
called Feiya, who makes tiny little flash ram ide devices that plug
right into the IDE header on a motherboard.  I think the smallest they
make is 4mb and the biggest is something like 384mb.
Sort of like a DiskOnChip, but this appears exactly like an IDE disk
to the rest of the system, rather than a special chip that needs special
(proprietary) drivers like the DOC.

The ThinkNic includes a 4mb Feiya IDE chip, so I have one to play with.
The Iopener also has a flash IDE disk, but I think it's soldered to the
motherboard.

This got me thinking that we could put Freedos on the flash-ide and load
Etherboot from dos.  

So now, i've been hacking my copy of Etherboot, trying to figure out
exactly
how to do it.  I've written a little dos program that will place the
parameters
in memory at 0xFE00, which is where the tx buffer will reside once
Etherboot
initializes the card. 

I'm purely in the discovery stages at this point, trying various things
to try
to get anything working.  

I've got it to the point where I can place the paramters using a dos
program
and Etherboot will pick them up.  It will then initialize the interface
with
those parameters and actually download the kernel.  The kernel then
fails
because it doesn't know it's own IP address.  I still have to get that
info
passed on to the kernel.  I'm looking now at filling in a bootp reply
structure
within Etherboot so that it will think it got it's parameters from bootp
and pass the parameters through the first-linux.S code that is prepended
onto
the kernel from mknbi.

Talking with Marty, he mentioned that I should bring this conversation
over to
the Etherboot discussion list to solicit ideas from you-all.

There are many issues that need to be addressed in a proper way, such as
where
in memory the parameters should be placed.  I chose 0xFE00 because it
seemed available
and after trying it, it worked.  There's probably a better place for it
though.


Anyway, it's really just a hack right now and needs lots of cleanup
before
it is ready for real production use.

I know that Ken is not terribly fond of the idea of static IP info
stored
on the workstation, but I'm not going to fight with potential users on
this
when I clearly can't win.

The idea of making Etherboot only listen to certain servers might work
in
some situations, but what happens when you put a linux server in for
that
dhcp server, and all of a sudden all of the other clients on the network
start getting IP addresses (or rejections) from that new server.  You've
just broken a network that was working.


Thanks,
Jim McQuillan
ja...@lt...
LTSP - Linux Terminal Server Project

Re: [Etherboot-developers] Re: [Etherboot-users] start remoteboot from running dos

[Ken Y. <ke...@nl...>]

>Now, it is likely that we could figure out which code is needed, take it 
>from a kernel, assemble it in, and off we go.  Of course, why not just 
>use a .COM file anyway, since it isn't the case that we can parse or use 
>most of the options being passed via LOADLIN anyway.

The problem is that .com files rely on a clean environment. Loadlin does
the useful service of cleaning up all the junk that is loaded in a
typical DOS or Windoze setup.

>FREEDOS, load a config, and let Etherboot load a kernel without any DHCP 
>server.  A win in some environments.  Once the kernel is loaded, we're on 
>the air.
>
>So, what do you think?  Does it have potential?  

I'm not interested in hacks that bypass IP address management. Even
disked Windoze uses DHCP. That should give you a hint of the ire you
will get from sysadmins when they hit a rogue workstation that
unilaterally takes an IP address and causes problems for other hosts on
the network.

What is it with DHCP? You'd have to setup a TFTP and NFS server anyway.
If it's a problem working with existing DHCP servers, I'd rather pursue
approaches that allow the boot ROM to pick the right DHCP server, which
is what the vendor-class-identifier is about.

[Etherboot-developers] Re: [Etherboot-users] start remoteboot from running dos

[Marty C. <md...@th...>]

On 11/30/2000 8:30 PM Ken Yap ke...@nl... wrote:
>>Etherboot lilo images do not work with LOADLIN, but if you're using DOS, 
>>you can generate a .COM file from Etherboot, and just run it (in DOS) to 
>>start the boot process. You can generate and download such a .COM file 
>>from rom-o-matic.net.

>Ah, I take you have tried it and it didn't work? Any idea what loadlin's
>beef is?

I haven't looked deeply into it, and we could probably figure out how to 
make it work, but here is what the author of the old "masq" contrib file 
had to say in his README file:

"Loadlin does not work, becauce it depends on the original linux setup
code (which is'nt present in netImage) for interrupt-vector handling."

Now, it is likely that we could figure out which code is needed, take it 
from a kernel, assemble it in, and off we go.  Of course, why not just 
use a .COM file anyway, since it isn't the case that we can parse or use 
most of the options being passed via LOADLIN anyway.

Which does however get me thinking -- it would be very nice if there was 
a way to pass arguments to Etherboot.  Something like:

    - stuff some parameters in a known memory loc and set a signature to
      indicate the block is real
    - load etherboot into memory
    - Etherboot starts, and if the flags are where we think they should be
      (and if a certain compile option is on) Etherboot processes the args
      and uses them instead of using BOOTP/DHCP.

This would allow a sequence of the form:

    A:> PASSARGS @ETHERBT.CFG 
    A:> TULIP.COM

Etherboot checks some known RAM region for config, which of course we 
store just before running Etherboot from, say FREEDOS.

If it finds the arg block it uses it for whatever it needs to.

Heck, you could even have a batch file that, based on user input selects 
the proper driver from a directory full of .COM files.  Thus people could 
decide at boot time what Etherboot config they want and what server they 
need.

Note that Etherboot only looks for and uses the state if it is 
specifically requested to do so, and the argument parser could be very 
simple, and completely under a conditional.  If the args aren't there, 
Etherboot could always use DHCP/BOOTP to continue.

LOL, I know this wasn't the question you were asking about, but I was 
talking to Jim McQuillan about this the other day, and it occurs to me 
that it would not be hard to add, and would allow people to boot in 
FREEDOS, load a config, and let Etherboot load a kernel without any DHCP 
server.  A win in some environments.  Once the kernel is loaded, we're on 
the air.

So, what do you think?  Does it have potential?  

Regards,

Marty

P.S. Even more deviously, one could make the .COM version of the 
Etherboot loader put the args in memory for us, and then jump to the ROM 
code, which checks for them based on some flag.  Not that I have anything 
agains DHCP or BOOTP servers, but sometimes it would be nice to get the 
kernel and go :-)


---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] Re: PXE Project?

[Marty C. <md...@th...>]

On 11/30/2000 4:58 PM Dave Stubbs ds...@nu... wrote:
>Is there a project out there to provide PXE boot ROMs for all network cards?

You might want to check out Nilo (www.nilo.org)  From that page:

NILO is the Network Interface Loader. NILO will boot Linux, FreeBSD, 
Windows 95/98/NT4 and support the Intel PXE standard, and is suitable for
burning into ROM. It is an evolution of the previous Etherboot and 
Netboot projects, and was authored by Ken Yap, until Rob Savoye took over
active development..

>I'd love to use etherboot but because of it's insistance on using 
>"next-server" it doesn't work with most of the environments I'm trying to 
>manage.  PXE is a much more desirable alternative because of this.

There are also commercial options for PXE ROMs.  There are links on the 
Etherboot (http://etherboot.sourceforge.net/) page.

You also might want to take a look at the GRUB project 
(www.gnu.org/software/grub/grub.html), and of course the PXELINUX project 
(http://people.redhat.com/alikins/ltsp/pxe/pxelinux/)

Hope this helps.  Please write back to let us know what you find, and how 
it works, that we might all benefit from your experience.

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] 4.6.13 patches

[Marty C. <md...@th...>]

On 11/30/2000 8:52 AM Ken Yap ke...@nl... wrote:
>If anybody is happy to install ISC dhcp-3.0 and help test this, let me
>know.

I'll be ready to help in a few days.  I am installing RedHat 7 on my 
laptop to use for DHCP and LTSP testing.  

This should also make it easier to debug the FA310TX bugs.  I note that 
NetGear is now doing FA311 and FA312 boards which use a completely 
different chip.  I also note that I cannot get the lite-on web site in 
Taiwan to respond, so I am starting to suspect that LC82C169s might just 
have been a passing fad.  I am still very interested in debugging them, 
however.

Anyway, thanks for all the hard work, Ken et al.  

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] 4.6.13 patches

[Ken Y. <ke...@nl...>]

I've started work on 4.6.13. One thing I've put in is for the client to
send an option 60 (vendor-class-identifier) of "Etherboot" in the
DHCPDISCOVER message.  dhcp-3.0 can use this information in conditionals
and presumably can be set to reply with a tag that says, yes I know
Etherboot.  Then Etherboot can ignore offers from other DHCP servers on
the same segment (a compile option).

If anybody is happy to install ISC dhcp-3.0 and help test this, let me
know.