etherboot-developers — Discussion of developer issues

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

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

"Timothy Legge" <tl...@ro...> writes:

> > > However, from there, the PC reboots.  (That was using the 3c509 nic
> with
> > > the udelay replaced by DELAY.  Any thoughts on why udelay doe not
> work
> > > correctly on my 486 would be welcomed as well).
> > 
> > Does timer channel 2 not work on your 486?  Otherwise udelay
> > should work.
> 
> How would I know?

A quick test is to delay for a second and see time it:
A snippet of code like this.  Timer channel 2 is the underling
mechanism used for the delays.

printf("starting\n");
mdelay(1000);
printf("done\n");


Eric

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

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

[Sorry, if I said this before ]

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

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

[Anselm M. H. <ans...@gm...>]

> Hi all!
> 
> I think it could be VERY useful an universal, auto-probing driver, so we
> can have a single floppy for booting every pc...
> This universal driver could contain all existing drivers, or (if the
> size whould be a problem) only the most widespread (or there could be
> both version: one large universal driver and one smaller with only the
> most widespread...).
> 

AFAIK, never tried myself, you can generate such an image with
etherboot-5.1. That (development) version is not well (hardly at all) documented, but I
was told that
make etherboot.zdsk (or so)
outputs a multipurpose bootdisk image.
Ken will know :-)

However, the idea has been there for some time. As you say it, I think I'll
give it a run this afternoon.

Greetings,

Anselm M. Hoffmeister <ans...@ho...>

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

[Etherboot-developers] Universal auto-probing driver

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

Hi all!

I think it could be VERY useful an universal, auto-probing driver, so we
can have a single floppy for booting every pc...
This universal driver could contain all existing drivers, or (if the
size whould be a problem) only the most widespread (or there could be
both version: one large universal driver and one smaller with only the
most widespread...).

Bye!

Paolo

[Etherboot-developers] tg3 progress...

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

Someday I want to do a driver from scratch but I until then I get
to strip down linux drivers and see how small they can go.

On the broadcom gigabit driver the tg3 progress is being made.

I have done a quick conversion and the driver initialization code
appears to be working in etherboot.  I have yet to implement transmit
and receive functions, and there is still a lot of code to strip off
but progress is being made.

The history of the source appears to be:
>From a 10000 line broadcom driver to a 7000 line linux driver.
>From a 7000 line linux driver to a 3900 line etherboot driver.

And I haven't really started cutting yet.  I wonder how small it
will get tomorrow after I do some more serious cutting.

Eric

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

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

"Timothy Legge" <tl...@ro...> writes:

> > It looks like this bit of code in start32.S
> > 
> > 	/* Save the stack pointer */
> >         cs
> > 	movw	%sp, RADDR(real_sp)
> > 
> > Which when modified to say:
> > 
> > 	/* Reload %ds */
> > 	movw	%cs, %ax
> > 	movw	%ax, %ds
> > 
> > 	/* Save the stack pointer */
> > 	movw	%sp, RADDR(real_sp)
> > 
> > 
> > Works.  So it looks like I have found a 486 bug with respect to
> segment
> 
> I can confirm that a clean cvs with the above change will allow my 486
> to recognize the NIC and xfer a ltsp kernel.  Nice work Eric, I thought
> I was going to have to break down and learn assembly.  

I got lucky.  It was not an interrupt causing the problem.
 
> However, from there, the PC reboots.  (That was using the 3c509 nic with
> the udelay replaced by DELAY.  Any thoughts on why udelay doe not work
> correctly on my 486 would be welcomed as well).

Does timer channel 2 not work on your 486?  Otherwise udelay
should work.
 
> The reboot behavior was noted when I was working on the sundance driver.
> I thought it was related to that driver, but maybe not.

When I get a chance I will attempt to confirm ne.zdsk works properly.

But it just sitting there waiting for a DHCP reply everything worked
properly.

Eric

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

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

> It looks like this bit of code in start32.S
> 
> 	/* Save the stack pointer */
>         cs
> 	movw	%sp, RADDR(real_sp)
> 
> Which when modified to say:
> 
> 	/* Reload %ds */
> 	movw	%cs, %ax
> 	movw	%ax, %ds
> 
> 	/* Save the stack pointer */
> 	movw	%sp, RADDR(real_sp)
> 
> 
> Works.  So it looks like I have found a 486 bug with respect to
segment

I can confirm that a clean cvs with the above change will allow my 486
to recognize the NIC and xfer a ltsp kernel.  Nice work Eric, I thought
I was going to have to break down and learn assembly.  

However, from there, the PC reboots.  (That was using the 3c509 nic with
the udelay replaced by DELAY.  Any thoughts on why udelay doe not work
correctly on my 486 would be welcomed as well).

The reboot behavior was noted when I was working on the sundance driver.
I thought it was related to that driver, but maybe not.

Tim

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

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

"Timothy Legge" <tl...@ro...> writes:

> > Well I can reproduce the problem on my old 486 when attempting
> > to boot from a floppy.  Though I have to be careful to not
> > select CONFIG_TSC_CURRTICKS, which causes an entirely
> > different set of failures.
> > 
> Any thoughts on what may be causing the issue?

It looks like this bit of code in start32.S

	/* Save the stack pointer */
        cs
	movw	%sp, RADDR(real_sp)

Which when modified to say:

	/* Reload %ds */	
	movw	%cs, %ax
	movw	%ax, %ds

	/* Save the stack pointer */
	movw	%sp, RADDR(real_sp)
	

Works.  So it looks like I have found a 486 bug with respect to segment
prefixes.  I don't think the architecture was extended to be more liberal
after the 486.

Hopefully I can get the fix committed later today.  I have not setup a DHCP
server at home yet so I don't know if I can boot the 486 yet but:

ROM segment 0x0800 length 0x6600 reloc 0x00020000
Etherboot 5.1.6pre6 (GPL) Tagged ELF64 ELF for [NE*000]
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? 
Probing pci nic...
pci_init: no BIOS32 detected
Probing isa nic...
[NE*000]
NE2000 base 0x0300, addr 00:50:BA:A4:78:8F
Searching for server (DHCP)...
......


Eric

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

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

> Well I can reproduce the problem on my old 486 when attempting
> to boot from a floppy.  Though I have to be careful to not
> select CONFIG_TSC_CURRTICKS, which causes an entirely
> different set of failures.
> 
Any thoughts on what may be causing the issue?

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

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

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

> This is not your problem because 5.0.x would have failed under
> these conditions as well.  I do have a 486 at home (but it's power
> supply is failing) if I can get it to boot I will see if I can
> reproduce this problem there.

Well I can reproduce the problem on my old 486 when attempting
to boot from a floppy.  Though I have to be careful to not
select CONFIG_TSC_CURRTICKS, which causes an entirely
different set of failures.

Eric

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

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

ke...@us... writes:

> I have released Etherboot 5.1.6 at http://www.etherboot.org
> 
> This is a consolidation release to bring up to date various files which
> had fallen out of date. It also contains Eric's code for the AMD Hammer
> and a new PCI ID for via-rhines.
> 
> Eric, I know you are working on the new PCI ID scheme, but this is not
> user visible and we can release 5.1.7 whenever. I just want to get this
> out the door while I have a free moment.

Good call.  I will probably pushing the PCI ID changes about the
same time I push in a tg3/Broadcom gigabit driver.  If you thought
the e1000 was bad.  Even the cleaned up Linux driver by David Miller
and Jeff Garzik is over 7000 lines long.  But at least I have finally
gotten as far as being able to read the MAC address.  With broadcom
driver I could not even trace the code well enough to do that...

Though once that is done I will probably be leaving etherboot alone for
a while....

Eric

[Etherboot-developers] Etherboot 5.1.6 (development) released

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

I have released Etherboot 5.1.6 at http://www.etherboot.org

This is a consolidation release to bring up to date various files which
had fallen out of date. It also contains Eric's code for the AMD Hammer
and a new PCI ID for via-rhines.

Eric, I know you are working on the new PCI ID scheme, but this is not
user visible and we can release 5.1.7 whenever. I just want to get this
out the door while I have a free moment.

Re: [Etherboot-developers] PCI IDs in 5.1 drivers

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

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

> ke...@us... (Ken Yap) writes:
> 
> > >So the proposal goes:
> > >- Don't use pci_ids.h use hex numbers.  pci_ids.h doesn't seem to add any rea
> 
> > >l value.
> > >- Use macros (PCI_ROM, ISA_ROM) because they are easy to find.
> > >- Do the work in genrules.pl when we build the Rom file.
> > 
> > Agree fully.
> > 
> > >- For the weird cases, and for identifying the drivers keep the NIC file.
> > 
> > I think you could even dispense with a proto NIC file and have the NIC
> > template inside genrules.pl itself. Reasoning: there aren't likely to be
> > any new ISA drivers and new PCI families don't happen often either. When
> > that happens a new genrules.pl can be released.
> 
And there is one extra requirement.  That Marty be able to get a list
of all of the valid targets for rom-o-matic.

Eric

Re: [Etherboot-developers] Compile all drivers into one?

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

Gee...@xs... (Geert Stappers) writes:

> On Thu, Feb 13, 2003 at 04:31:33PM -0700, Eric W. Biederman wrote:
> > Boris <bo...@bo...> writes:
> > 
> > > What is the command to compile all network drivers into one file? I want to
> > > create a floppy disk that tries all the drivers. Thanks in advance.
> 
> interresting idea/question
> 
> > 
> > In 5.1.x
> > 
> > make bin/etherboot.???
> > 
> 
>  '???' can be 'rom' or 'fd0'

Yes, all of the usually suffixes apply.
.rom .dsk .zrom .elf ....

Eric

Re: [Etherboot-developers] Compile all drivers into one?

[<Gee...@xs...>]

On Fri, Feb 14, 2003 at 10:15:38AM +0100, Geert Stappers wrote:
> On Thu, Feb 13, 2003 at 04:31:33PM -0700, Eric W. Biederman wrote:
> > Boris <bo...@bo...> writes:
> > 
> > > What is the command to compile all network drivers into one file? I want to
> > > create a floppy disk that tries all the drivers. Thanks in advance.
> 
> interresting idea/question
> 
> > 
> > In 5.1.x
> > 
> > make bin/etherboot.???
> > 
> 
>  '???' can be 'rom' or 'fd0'
> 

Oops,  '???' does work with a valid NIC  ( I modified it my self )

Geert

Re: [Etherboot-developers] Compile all drivers into one?

[<Gee...@xs...>]

On Thu, Feb 13, 2003 at 04:31:33PM -0700, Eric W. Biederman wrote:
> Boris <bo...@bo...> writes:
> 
> > What is the command to compile all network drivers into one file? I want to
> > create a floppy disk that tries all the drivers. Thanks in advance.

interresting idea/question

> 
> In 5.1.x
> 
> make bin/etherboot.???
> 

 '???' can be 'rom' or 'fd0'


Geert

Re: [Etherboot-developers] PCI IDs in 5.1 drivers

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

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

> >So the proposal goes:
> >- Don't use pci_ids.h use hex numbers.  pci_ids.h doesn't seem to add any rea
> >l value.
> >- Use macros (PCI_ROM, ISA_ROM) because they are easy to find.
> >- Do the work in genrules.pl when we build the Rom file.
> 
> Agree fully.
> 
> >- For the weird cases, and for identifying the drivers keep the NIC file.
> 
> I think you could even dispense with a proto NIC file and have the NIC
> template inside genrules.pl itself. Reasoning: there aren't likely to be
> any new ISA drivers and new PCI families don't happen often either. When
> that happens a new genrules.pl can be released.

Probably, and even new ISA drivers can be handled.  But I will take
this one small step at a time.  I am certain I can get rid of most of
the NIC file.   There is danger in a misconversion though.

The most abnormal case I have is the ide driver.  As it supports
anything that is the right class of device.  And it does not have a
list of supported pci ids.  

Eric

Re: [Etherboot-developers] PCI IDs in 5.1 drivers

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

>So the proposal goes:
>- Don't use pci_ids.h use hex numbers.  pci_ids.h doesn't seem to add any rea
>l value.
>- Use macros (PCI_ROM, ISA_ROM) because they are easy to find.
>- Do the work in genrules.pl when we build the Rom file.

Agree fully.

>- For the weird cases, and for identifying the drivers keep the NIC file.

I think you could even dispense with a proto NIC file and have the NIC
template inside genrules.pl itself. Reasoning: there aren't likely to be
any new ISA drivers and new PCI families don't happen often either. When
that happens a new genrules.pl can be released.

Re: [Etherboot-developers] PCI IDs in 5.1 drivers

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

ke...@us... writes:

> Eric,
> 
> How about this scheme?
> 
> Define a macro with a distinctive name, say PCI_ID_ENTRY like this.
> 
> #define	PCI_ID_ENTRY(a,b,c)	{a,b,c}
> 
> Then use this macro in all the drivers like this:
> 
> PCI_ID_ENTRY(PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID,INTEL_82557,"Intel
> EtherExpressPro100"),
> 
> PCI_ID_ENTRY(...),
> ...
> 
> Or just use the bare numbers.  This allows grep or a perl script to
> extract all the IDs to create the file NIC. If the symbolic names are
> used, then preprocess the output against pci.h using cpp.


O.k. thinking about this some more I think I have a working proposal.
The guiding principles.
- Keep it simple.
- Allow driver code to be isolated to drivers.

So the proposal goes:
- Don't use pci_ids.h use hex numbers.  pci_ids.h doesn't seem to add any real value.
- Use macros (PCI_ROM, ISA_ROM) because they are easy to find.
- Do the work in genrules.pl when we build the Rom file.
- For the weird cases, and for identifying the drivers keep the NIC file.

Here is an initial implementation of the idea.

If no one objects I will commit this and start looking at other drivers
besides the eepro100.

Eric

diff -uNr --exclude=bin --exclude=CVS --exclude=*~ ../etherboot-checkin/etherboot/etherboot-5.1/src/NIC etherboot/src/NIC
--- ../etherboot-checkin/etherboot/etherboot-5.1/src/NIC	Tue Jan  7 19:54:12 2003
+++ etherboot/src/NIC	Thu Feb 13 18:03:35 2003
@@ -73,16 +73,8 @@
 3c9805		0x10b7,0x9805
 3csoho100-tx	0x10b7,0x7646
 
-family		drivers/net/eepro100
 # Intel Etherexpress Pro/100
-eepro100	0x8086,0x1229
-82559er		0x8086,0x1209
-id1029		0x8086,0x1029
-id1030		0x8086,0x1030
-82801cam	0x8086,0x1031	82801CAM (ICH3) Chipset Ethernet Controller
-id1038		0x8086,0x1038
-82562et		0x8086,0x1039
-82562em		0x8086,0x2449
+family		drivers/net/eepro100
 
 family		drivers/net/e1000
 #Intel Etherexpress Pro/1000
@@ -227,4 +219,3 @@
 ide_disk	0x0000,0x0000	Generic IDE disk support
 
 family		drivers/disk/pc_floppy
-pc_floppy	-		Generic PC floppy support
diff -uNr --exclude=bin --exclude=CVS --exclude=*~ ../etherboot-checkin/etherboot/etherboot-5.1/src/drivers/disk/pc_floppy.c etherboot/src/drivers/disk/pc_floppy.c
--- ../etherboot-checkin/etherboot/etherboot-5.1/src/drivers/disk/pc_floppy.c	Fri Jan 17 10:48:32 2003
+++ etherboot/src/drivers/disk/pc_floppy.c	Thu Feb 13 18:01:17 2003
@@ -1141,10 +1141,11 @@
 {
 	0x3F0, 0x370, 0
 };
+ISA_ROM("pc_floppy", "Generic PC Floppy support")
+
 static struct isa_driver floppy_isa_driver __isa_driver = {
 	.type    = FLOPPY_DRIVER,
 	.name    = "PC flopyy",
 	.probe   = floppy_probe,
 	.ioaddrs = floppy_ioaddrs,
-	
 };
diff -uNr --exclude=bin --exclude=CVS --exclude=*~ ../etherboot-checkin/etherboot/etherboot-5.1/src/drivers/net/eepro100.c etherboot/src/drivers/net/eepro100.c
--- ../etherboot-checkin/etherboot/etherboot-5.1/src/drivers/net/eepro100.c	Thu Jan  2 17:00:16 2003
+++ etherboot/src/drivers/net/eepro100.c	Thu Feb 13 18:01:10 2003
@@ -659,26 +659,15 @@
 #endif
 
 static struct pci_id eepro100_nics[] = {
-	{ PCI_VENDOR_ID_INTEL,		PCI_DEVICE_ID_INTEL_82557,
-		"Intel EtherExpressPro100" },
-	{ PCI_VENDOR_ID_INTEL,		PCI_DEVICE_ID_INTEL_82559ER,
-		"Intel EtherExpressPro100 82559ER" },
-	{ PCI_VENDOR_ID_INTEL,		PCI_DEVICE_ID_INTEL_ID1029,
-		"Intel EtherExpressPro100 ID1029" },
-	{ PCI_VENDOR_ID_INTEL,		PCI_DEVICE_ID_INTEL_ID1030,
-		"Intel Corporation 82559 InBusiness 10/100" },
-	{ PCI_VENDOR_ID_INTEL,		PCI_DEVICE_ID_INTEL_ID1031,
-		"Intel 82801CAM Chipset Ethernet Controller" },
-	{ PCI_VENDOR_ID_INTEL,		PCI_DEVICE_ID_INTEL_ID1039,
-		"Intel Corporation 82559 InBusiness 10/100" },
-	{ PCI_VENDOR_ID_INTEL,		PCI_DEVICE_ID_INTEL_ID103A,
-		"Intel Corporation 82559 InBusiness 10/100" },
-	{ PCI_VENDOR_ID_INTEL,		PCI_DEVICE_ID_INTEL_82562,
-		"Intel EtherExpressPro100 82562EM" },
-	{ PCI_VENDOR_ID_INTEL,		PCI_DEVICE_ID_INTEL_ID1038,
-		"Intel(R) PRO/100 VM Network Connection" },
-	{ PCI_VENDOR_ID_INTEL,		0x1039,
-		"Intel PRO100 VE 82562ET" },
+PCI_ROM(0x8086, 0x1229, "eepro100", "Intel EtherExpressPro100"),
+PCI_ROM(0x8086, 0x1209, "82559er",  "Intel EtherExpressPro100 82559ER"),
+PCI_ROM(0x8086, 0x1029, "id1029",   "Intel EtherExpressPro100 ID1029"),
+PCI_ROM(0x8086, 0x1030, "id1030",   "Intel EtherExpressPro100 ID1030"),
+PCI_ROM(0x8086, 0x1031, "82801cam", "Intel 82801CAM (ICH3) Chipset Ethernet Controller"),
+PCI_ROM(0x8086, 0x1038, "id1038",   "Intel(R) PRO/100 VM Network Connection"),
+PCI_ROM(0x8086, 0x1039, "82562et",  "Intel PRO100 VE 82562ET"),
+PCI_ROM(0x8086, 0x2449, "82562em",  "Intel EtherExpressPro100 82562EM"),
+PCI_ROM(0x8086, 0x103A, "id103a",   "Intel Corporation 82559 InBusiness 10/100"),
 };
 
 static struct pci_driver eepro100_driver __pci_driver = {
diff -uNr --exclude=bin --exclude=CVS --exclude=*~ ../etherboot-checkin/etherboot/etherboot-5.1/src/genrules.pl etherboot/src/genrules.pl
--- ../etherboot-checkin/etherboot/etherboot-5.1/src/genrules.pl	Thu Jan 16 09:12:16 2003
+++ etherboot/src/genrules.pl	Thu Feb 13 18:01:48 2003
@@ -59,6 +59,32 @@
 	return sort values %driver_dep
 }
 
+sub genroms($) {
+	my ($driver) = @_;
+	
+	# Automatically discover the ROMS this driver can produce.
+	unless (open(INFILE, "$driver")) {
+		print STDERR "$driver: %! (shouldn't happen)\n";
+		next;
+	};
+	while (<INFILE>) {
+		chomp($_);
+		if ($_ =~ m/^\s*PCI_ROM\(\s*0x([0-9A-Fa-f]*)\s*,\s*0x([0-9A-Fa-f]*)\s*,\s*"([^"]*)"\s*,\s*"([^"]*)"\)/) {
+
+			# We store a list of PCI IDs and comments for each PC target
+			my ($vendor_id, $device_id, $rom, $comment) = (hex($1), hex($2), $3, $4);
+			my $ids = sprintf("0x%04x,0x%04x", $vendor_id, $device_id);
+			push(@{$pcient{$curfam}}, [$rom, $ids, $comment]);
+		}
+		elsif($_ =~ m/^\s*ISA_ROM\(\s*"([^"]*)"\s*,\s*"([^"]*)"\)/) {
+			my ($rom, $comment) = ($1, $2);
+			# We store the base driver file for each ISA target
+			$isaent{$rom} = $curfam;
+			$buildent{$rom} = 1;
+		}
+	}
+}
+
 sub addfam ($) {
 	my ($family) = @_;
 
@@ -66,6 +92,7 @@
 	my @deps = &gendep("$family.c");
 	$drivers{$family} = join(' ', @deps);
 	$pcient{$family} = [];
+	genroms("$family.c");
 }
 
 sub addrom ($) {
diff -uNr --exclude=bin --exclude=CVS --exclude=*~ ../etherboot-checkin/etherboot/etherboot-5.1/src/include/isa.h etherboot/src/include/isa.h
--- ../etherboot-checkin/etherboot/etherboot-5.1/src/include/isa.h	Thu Dec 12 18:35:10 2002
+++ etherboot/src/include/isa.h	Thu Feb 13 17:59:06 2003
@@ -21,5 +21,7 @@
 extern const struct isa_driver isa_drivers[];
 extern const struct isa_driver isa_drivers_end[];
 
+#define ISA_ROM(IMAGE, DESCRIPTION)
+
 #endif /* ISA_H */
 
diff -uNr --exclude=bin --exclude=CVS --exclude=*~ ../etherboot-checkin/etherboot/etherboot-5.1/src/include/pci.h etherboot/src/include/pci.h
--- ../etherboot-checkin/etherboot/etherboot-5.1/src/include/pci.h	Thu Dec 12 18:35:53 2002
+++ etherboot/src/include/pci.h	Thu Feb 13 17:59:00 2003
@@ -231,5 +231,7 @@
 extern const struct pci_driver pci_drivers[];
 extern const struct pci_driver pci_drivers_end[];
 
+#define PCI_ROM(VENDOR_ID, DEVICE_ID, IMAGE, DESCRIPTION) \
+	{ VENDOR_ID, DEVICE_ID, IMAGE, }
 
 #endif	/* PCI_H */

Re: [Etherboot-developers] Compile all drivers into one?

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

Boris <bo...@bo...> writes:

> What is the command to compile all network drivers into one file? I want to
> create a floppy disk that tries all the drivers. Thanks in advance.

In 5.1.x

make bin/etherboot.???

Eric

[Etherboot-developers] Compile all drivers into one?

[Boris <bo...@bo...>]

What is the command to compile all network drivers into one file? I want to
create a floppy disk that tries all the drivers. Thanks in advance.

RE: [Etherboot-developers] sundance tcpdump

[Timothy L. <tim...@us...>]

> Hmm. You have a strange /etc/services file.  You have a service named
> wizard?
> 
> Taking this snippet, it looks odd.  You have 3 requests for the TFTP
> seesion,
> and compaq keeps arping for sundance.
> 
> So it feels like there someone is loosing UDP packets...
> 
> And after you have 3 tftp servers started all kinds of strange things
can
> happen.
> 
> 
> What were you looking for in the tcpdump output?
> 
> Eric

Weird indeed.  I should have posted another dump after my last check in.
It resolved some of the issues.

Tim

Re: [Etherboot-developers] sundance tcpdump

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

"Timothy Legge" <tl...@ro...> writes:

> Hi
> 
> Since I am not familiar with the output of tcpdump, I thought I would
> post a tcpdump file for review.  Please let me know if you see anything
> that might indicate the issue.
> 
> Tim

Hmm. You have a strange /etc/services file.  You have a service named wizard?

Taking this snippet, it looks odd.  You have 3 requests for the TFTP seesion,
and compaq keeps arping for sundance.  

So it feels like there someone is loosing UDP packets...

And after you have 3 tftp servers started all kinds of strange things can happen.


What were you looking for in the tcpdump output?

Eric


18:25:21.248764 arp who-has compaq.johnsonavenue.org tell sundance.johnsonavenue.org
18:25:21.249060 arp reply compaq.johnsonavenue.org is-at 0:a0:24:98:97:31
18:25:42.006224 sundance.johnsonavenue.org.wizard > compaq.johnsonavenue.org.tftp:  34 RRQ "lts/sundance"
18:25:42.459852 compaq.johnsonavenue.org.2063 > sundance.johnsonavenue.org.wizard: udp 15 (DF)
18:25:47.459694 arp who-has sundance.johnsonavenue.org tell compaq.johnsonavenue.org
18:25:47.460106 sundance.johnsonavenue.org.globe > compaq.johnsonavenue.org.tftp:  34 RRQ "lts/sundance"
18:25:47.464056 compaq.johnsonavenue.org.2063 > sundance.johnsonavenue.org.wizard: udp 15 (DF)
18:25:47.479933 compaq.johnsonavenue.org.2064 > sundance.johnsonavenue.org.globe: udp 15 (DF)
18:25:48.459693 arp who-has sundance.johnsonavenue.org tell compaq.johnsonavenue.org
18:25:48.460223 sundance.johnsonavenue.org.2003 > compaq.johnsonavenue.org.tftp:  34 RRQ "lts/sundance"
18:25:48.480814 compaq.johnsonavenue.org.dlsrpn > sundance.johnsonavenue.org.2003: udp 15 (DF)
18:25:48.481250 arp reply sundance.johnsonavenue.org is-at 0:5:5d:7:ea:32
18:

Re: [Etherboot-developers] VT6105 0x3106

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

>diff -u -r1.13 NIC
>- --- etherboot-5.1/src/NIC       8 Jan 2003 03:04:12 -0000       1.13
>+++ etherboot-5.1/src/NIC       9 Feb 2003 21:32:06 -0000
>@@ -155,6 +155,7 @@
> # Rhine-II
> via-rhine-old  0x1106,0x6100
> via-rhine      0x1106,0x3065
>+via-rhineVT6105	0x1106,0x3106
>
> family         drivers/net/w89c840
> winbond840     0x1050,0x0840   Winbond W89c840

Done. Actually made the same as the 5.0 entry for consistency.

>The 5.1.6pre5 release does a clean DCHP session on the VT6105.

Does it also do a TFTP ok? Or do you loosely call the whole DHCP/TFTP
process a "DHCP session"?

>IMHO does the LOG-file not have te been updated.

It has been now.

Re: [Etherboot-developers] VT6105 0x3106

[<Gee...@xs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Feb 07, 2003 at 02:06:01PM -0700, Eric W. Biederman wrote:
> Gee...@xs... (Geert Stappers) writes:
> 
> > Hello,
> > 
> > For the development release, 5.1.5, I made also 
> > a patch for supporting a VIA6105 chip with PCI ID 0x3106
> > 
> > It is not tested, because I was not able to build a testfloppy.
> > (the 5.0.8 is test due the better documation ;-)
> 
> make bin/???.fd0 should work...

For '???' I had to fill in 'via-rhineVT6105',
after this patch (against CVS): 

Index: etherboot-5.1/src/NIC
===================================================================
RCS file: /cvsroot/etherboot/etherboot/etherboot-5.1/src/NIC,v
retrieving revision 1.13
diff -u -r1.13 NIC
- --- etherboot-5.1/src/NIC       8 Jan 2003 03:04:12 -0000       1.13
+++ etherboot-5.1/src/NIC       9 Feb 2003 21:32:06 -0000
@@ -155,6 +155,7 @@
 # Rhine-II
 via-rhine-old  0x1106,0x6100
 via-rhine      0x1106,0x3065
+via-rhineVT6105	0x1106,0x3106

 family         drivers/net/w89c840
 winbond840     0x1050,0x0840   Winbond W89c840


The 5.1.6pre5 release does a clean DCHP session on the VT6105.

I still didn't read the small print on Sourceforge
 about getting a CVS account.
Could somebody else apply the patch?

IMHO does the LOG-file not have te been updated.


Geert Stappers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj5GzusACgkQ91HXn1UReY+TGACggeSgXmmGqbbgtRw2FFf22aBg
Pw4An0OkFro/XgFs5/VyIToB3JpUZEOk
=Yl5N
-----END PGP SIGNATURE-----