etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

[Doug A. <amb...@am...>]

Ken Yap writes:
| >Sorry to say this again, but I prefer using GRUB together with
| >`etherboot', and so nobody has to deal with `mknbi' in connection
| >with UNIX systems (for DOS mknbi is already needed so far).
| 
| There's no accounting for taste. :-)
| 
| GRUB suffers from the problem that it uses another copy of the network
| driver so you have to decide ahead of time which hardware you want to
| support when building GRUB. Ideally secondary loaders should be able to
| use the boot ROMs network driver. Hmm, sounds very much like PXE. I wish
| I had the time to rework Etherboot's architecture to allow callbacks so
| that secondary loaders can do network operations. Not necessarily PXE
| style, just having callbacks would be nice.

Heh, you just got patches to do some of that in the context of the
PXE patches to emulate PXE enough for the FreeBSD PXE boot loader to
work!  Maybe grub could be re-worked to access the hardware via PXE and
not just look like a PXE image.  Randoms thoughts are what if
Etherboot had a PXE network driver writen in terms the PXE stuff
that was sent in?  That would seem to get us most of the way there.
"pxegrub" could use the Etherboot "PXE network driver" to talk
to the Etherboot PXE emulation layer.

This sounds interesting to me.

Doug A.

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

Christoph Plattner <chr...@gm...> writes:

> Hello !
> 
> Sorry to say this again, but I prefer using GRUB together with
> `etherboot', and so nobody has to deal with `mknbi' in connection
> with UNIX systems (for DOS mknbi is already needed so far).

I agree that not necesarily needing mknbi is a good thing which
is why I am working on cleaning up the linux kernel build, so
it build ELF bootable kernels.

> GRUB can direclty load images and has currently the SAME network
> driver state as etherboot (full 5.0.5 driver compatible).

But the images still must be built. 
 
> I like really both, especially both in conjunction.
> Etherboot+GRUB is one of the best BIOS "Extensions" to get a feeling
> of a full boot monitor like on SUN or HP (even better !!!!).

And reply to me on this is definentily talking to the wrong crowd.
For the most part I figure todays BIOS's are way to complex to be
maintainable.  And I don't care how far you extend a pile of rubble
you just get more rubble. 

As for GRUB I see a lot of design issues with it, and it's whole
multiboot format.  I will agree for purposes of argument that
it may get experience right but that is about it.

Eric

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

>Sorry to say this again, but I prefer using GRUB together with
>`etherboot', and so nobody has to deal with `mknbi' in connection
>with UNIX systems (for DOS mknbi is already needed so far).

There's no accounting for taste. :-)

GRUB suffers from the problem that it uses another copy of the network
driver so you have to decide ahead of time which hardware you want to
support when building GRUB. Ideally secondary loaders should be able to
use the boot ROMs network driver. Hmm, sounds very much like PXE. I wish
I had the time to rework Etherboot's architecture to allow callbacks so
that secondary loaders can do network operations. Not necessarily PXE
style, just having callbacks would be nice.

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

[Christoph P. <chr...@gm...>]

Hello !

Sorry to say this again, but I prefer using GRUB together with
`etherboot', and so nobody has to deal with `mknbi' in connection
with UNIX systems (for DOS mknbi is already needed so far).

GRUB can direclty load images and has currently the SAME network
driver state as etherboot (full 5.0.5 driver compatible).

I like really both, especially both in conjunction.
Etherboot+GRUB is one of the best BIOS "Extensions" to get a feeling
of a full boot monitor like on SUN or HP (even better !!!!).

I want nothing to say against MKNBI !

Bye
Christoph Plattner


"Eric W. Biederman" wrote:
> 
> ke...@us... (Ken Yap) writes:
> 
> > >I have a smallish problem.  We can talk more about it but essentially
> > >mkelf-linux fails if it wasn't loaded with the etherboot ``generic''
> > >ELF loader.  It should be able to continue to work and just loose
> > >some features if it is loaded by an unrecognized ELF loader.
> >
> > Ok. There's probably some dependency I'll have to look into.
> 
> Cool.  I haven't checked the latest version so it might not be
> quite as bad in the mknbi-1.2 I was looking at.  A good test case is:
> -DELF -DIMAGE_MULTIBOOT.
> 
> > >My version of mkelfImage is getting close to the point where can
> > >looking at merging the code bases, or at least get some cooperation
> > >and code sharing going back and forth.
> >
> > Sounds good.
> 
> More later,
> 
> Eric
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

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

> >I have a smallish problem.  We can talk more about it but essentially 
> >mkelf-linux fails if it wasn't loaded with the etherboot ``generic''
> >ELF loader.  It should be able to continue to work and just loose
> >some features if it is loaded by an unrecognized ELF loader.
> 
> Ok. There's probably some dependency I'll have to look into.

Cool.  I haven't checked the latest version so it might not be
quite as bad in the mknbi-1.2 I was looking at.  A good test case is:
-DELF -DIMAGE_MULTIBOOT.

> >My version of mkelfImage is getting close to the point where can
> >looking at merging the code bases, or at least get some cooperation
> >and code sharing going back and forth.
> 
> Sounds good.

More later,

Eric

[Etherboot-developers] Multiboot BIOS and Etherboot ....

[Christoph P. <chr...@gm...>]

Hello Etherboot hackers !

For a special embedded board I have following problem:

We want to have a BIOS setup, which must never be changed during
operation and both should be possible: booting local and from net.

I configured a `etherboot' for default=local, timout=3sec and
the usage of serial console (in normal operation the board is
used haedless (=without screen and keyboard).

Now the problem: As the BIOS is multiboot compliant, the BIOS
sees etherboot as one "bootable device" (under normal circumstances
a very good thing ....). The etherboot is the first in the boot
order. After the timeout of 3 secs is over, the BIOS should boot
local, but loads again `etherboot' (so the BIOS tries to simple
boot always the normal order ....).

On other machines not having mulitboot BIOS, etherboot is simple
executed before the normal BIOS boots up with local disks.
How can I tell the BIOS to run etherboot before booting local
disk and not to have etherboot as one selectable device ?
Can this be done with the `-DNO_DELAYED_INT' to have etherboot
run before ... and then BIOS is trying to boot locally (of course
then etherboot has to be not the first in the boot order, if
etherboot is seen as boot device also).

Is there another way ? Again, the BIOS (boot order) must not (cannot)
be changed, as no screen/keyboard is present ....
The default should be a local boot, but pressing "N" while the
first 3 seconds (or whatever configured), the machine should also
boot from net.

By the way, the BIOS is a PhoenixBios customized to this embedded
board.

With friendly regards
Christoph Plattner


-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

>I have a smallish problem.  We can talk more about it but essentially 
>mkelf-linux fails if it wasn't loaded with the etherboot ``generic''
>ELF loader.  It should be able to continue to work and just loose
>some features if it is loaded by an unrecognized ELF loader.

Ok. There's probably some dependency I'll have to look into.

>My version of mkelfImage is getting close to the point where can
>looking at merging the code bases, or at least get some cooperation
>and code sharing going back and forth.

Sounds good.

Re: [Etherboot-developers] mknbi-1.2-7rc2 released

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

ke...@us... writes:

> I have placed mknbi-1.2-7rc2 at
> http://etherboot.sf.net/mknbi-1.2-7rc2.tar.gz
> 
> The only change from rc1 is that it now detects setup version 0x203
> (kernel 2.4.18 onwards) and uses the ramdisk_max variable as the default
> top of initrd.  This should help people with large amounts of RAM who
> currently have to set rdbase themselves. Please report problems to this
> list.

I have a smallish problem.  We can talk more about it but essentially 
mkelf-linux fails if it wasn't loaded with the etherboot ``generic''
ELF loader.  It should be able to continue to work and just loose
some features if it is loaded by an unrecognized ELF loader.

My version of mkelfImage is getting close to the point where can
looking at merging the code bases, or at least get some cooperation
and code sharing going back and forth.

Eric

[Etherboot-developers] mknbi-1.2-7rc2 released

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

I have placed mknbi-1.2-7rc2 at
http://etherboot.sf.net/mknbi-1.2-7rc2.tar.gz

The only change from rc1 is that it now detects setup version 0x203
(kernel 2.4.18 onwards) and uses the ramdisk_max variable as the default
top of initrd.  This should help people with large amounts of RAM who
currently have to set rdbase themselves. Please report problems to this
list.

[Etherboot-developers] [PATCH] kernel 2.4.17 - coredump sysctl

[Michael S. <ms...@wg...>]

coredump name format control via sysctl

Provides for a way to securely move where core files show up and to
set the name pattern for core files to include the UID, Program,
Hostname, and/or PID of the process that caused the core dump.
This is very handy for diskless clusters where all of the core
dumps go to the same disk and for production servers where core
dumps want to be segregated from the main production disks.

I figured that some of you may be interested in this patch.  It really
made our clusters better.   (And I hope I can get this into the official
Linux/Linus tree)

Anyway, the patch, while against 2.4.17, should apply easily to most
any version of the 2.4 and 2.5 kernel (the 2.5 kernel versions have
a different include list in the fs/exec.c file and the adding of the
extra include needed fails to patch)

FreeBSD has such a feature already (almost exactly like this one :-)
We use both FreeBSD and Linux in our large clusters (used to be FreeBSD
and we are migrating over to Linux)

-- Patch background and how it works --

What I did with this patch is provide a new sysctl that lets you
control the name of the core file.  The this name is actually a format
string such that certain values from the process can be included.
If the sysctl is not used to change the format string, the behavior
is exactly the same as the current kernel coredump behavior.  (The
default pattern is set to "core" which produces the same result
as the current kernels do - thus you can use the sysctl to even put
back the current behavior if you change it - the current behavior is
not a special case)

The sysctl is kernel.core_name_format and is a string up to 63 characters
(plus 1 for the null)

The following format options are available in that string:

	%P	The Process ID (current->pid)
	%U	The UID of the process (current->uid)
	%N	The command name of the process (current->comm)
	%H	The nodename of the system (system_utsname.nodename)
	%%	A "%"

For example, in my clusters, I have an NFS R/W mount at /coredumps
that all nodes have access to.  The format string I use is:

	sysctl -w "kernel.core_name_format=/coredumps/%H-%N-%P.core"

This then causes core dumps to be of the format:

	/coredumps/whale.sinz.org-badprogram-13917.core

Old behavior of appending the PID to the "core" name is still
supported with the added logic of only doing so if the PID is
not already part of the name format.  The default name format
is still just "core" to match old behavior.

The attached patch is for Linux 2.4.17 but should patch relatively
easily to other versions.  I tried to comment the code a bit
to explain the how and why.

Some notes on security:

This patch does add the ability of a system administrator to make
a core dump format string that could cause problems.  If the format
string is set to be a fixed file name of say, "/bin/sh" it would
be a "bad thing" to have a core dump happen :-)

There is always the problem of someone with root access making
a bad setting in the sysctl.  But then, if they have root, they don't
need to set some sysctl in order to cause damage.

However, I have also worked through the security and reliability of
the code assuming that the system administrator does not set a
blatantly bad pattern.  In addition to the standard prevention of
buffer over-runs and the like, I also make sure that any user
adjustable input gets filtered to remove "/" characters such that
directories can not be changed via a program name of, say "../foo/x"
(assuming that some program goes and changes its process name to that)

So it does not prevent someone from making a name format that
would be bad (such as "/bin/sh" or "/usr/bin/%N") but then "rm -rf" still
works too :-)

One thing that I do feel is very good about this is that you can now
segregate your core files to a different partition and thus prevent
the writing to and/or filling up of your important partitions.  For
the diskless cluster situation, it also provides a way to track who
caused the core dump and, in our cluster, a place to write it since
all of the other disks are read-only or /dev/tmpfs devices.

Michael Sinz -- ms...@wg... -- http://www.sinz.org
A master's secrets are only as good as
	the master's ability to explain them to others.

-------------------------------------------------------------------------------

diff -urP linux-2.4.17/fs/exec.c linux-2.4.17-patch/fs/exec.c
--- linux-2.4.17/fs/exec.c	Fri Dec 21 12:41:55 2001
+++ linux-2.4.17-patch/fs/exec.c	Wed Feb 20 09:49:20 2002
@@ -35,6 +35,7 @@
 #include <linux/highmem.h>
 #include <linux/spinlock.h>
 #include <linux/personality.h>
+#include <linux/utsname.h>
 #define __NO_VERSION__
 #include <linux/module.h>
 
@@ -48,6 +49,12 @@
 
 int core_uses_pid;
 
+/* The format string for the core file name...
+   We default to "core" such that past behavior
+   remains unchanged.  The 64 character limit is
+   arbitrary but must match the sysctl table. */
+char core_name_format[64] = {"core"};
+
 static struct linux_binfmt *formats;
 static rwlock_t binfmt_lock = RW_LOCK_UNLOCKED;
 
@@ -933,14 +940,37 @@
 		__MOD_DEC_USE_COUNT(old->module);
 }
 
+/* This is the maximum expanded core file name.  We use
+   a reasonable number here since we use the stack to
+   do the expansion.  However, the number should be big
+   enough to handle a reasonable command name plus PID
+   and/or UID in addition to the file name part that
+   is in the core_name_format string. */
+#define MAX_CORE_NAME (160)
+
 int do_coredump(long signr, struct pt_regs * regs)
 {
 	struct linux_binfmt * binfmt;
-	char corename[6+sizeof(current->comm)+10];
 	struct file * file;
 	struct inode * inode;
 	int retval = 0;
 
+	int fmt_i;
+	int name_n;
+	int addPID;
+	char *cname;
+
+	/* The +11 is here to simplify the code path.  What
+	   we do is always check that we are less than MAX
+	   but there are times when we also need to append
+	   a number (such as the PID or UID).  Rather than
+	   using another temporary buffer, we provide for
+	   enough extra space such that those numbers can
+	   be added in one gulp even if we are just under
+	   the MAX_CORE_NAME.  Reduction in complexity of
+	   the code path means a more reliable implementation. */
+	char corename[MAX_CORE_NAME + 1 + 11];
+
 	lock_kernel();
 	binfmt = current->binfmt;
 	if (!binfmt || !binfmt->core_dump)
@@ -951,10 +981,92 @@
 	if (current->rlim[RLIMIT_CORE].rlim_cur < binfmt->min_coredump)
 		goto fail;
 
-	memcpy(corename,"core.", 5);
-	corename[4] = '\0';
- 	if (core_uses_pid || atomic_read(&current->mm->mm_users) != 1)
- 		sprintf(&corename[4], ".%d", current->pid);
+	/* Set this to true if we are going to add the PID.  If the PID
+	   already is added in the format we will end up clearing this.
+	   The purpose is to provide for the old behavior of adding the
+	   PID to the core file name but to not add it if it already
+	   was included via the file name format pattern. */
+	addPID = (core_uses_pid || atomic_read(&current->mm->mm_users) != 1);
+
+	/* Build the core file name as needed from the format string */
+	for (fmt_i=0, name_n=0;
+	     name_n < MAX_CORE_NAME && core_name_format[fmt_i];
+	     fmt_i++)
+	{
+		switch (core_name_format[fmt_i])
+		{
+		case '%':	/* A format character */
+			fmt_i++;
+			switch (core_name_format[fmt_i])
+			{
+			case '%': /* The way we get this character */
+				corename[name_n++] = '%';
+				break;
+
+			case 'N': /* Process name */
+				cname=current->comm;
+
+				/* Only copy as much as will fit within the
+				   MAX_CORE_NAME */
+				while (*cname && (name_n < MAX_CORE_NAME))
+				{
+					if (*cname != '/')
+						corename[name_n++] = *cname;
+					cname++;
+				}
+				break;
+
+			case 'H': /* Node name */
+				cname=system_utsname.nodename;
+
+				/* Only copy as much as will fit within the
+				   MAX_CORE_NAME */
+				while (*cname && (name_n < MAX_CORE_NAME))
+				{
+					if (*cname != '/')
+						corename[name_n++] = *cname;
+					cname++;
+				}
+				break;
+
+			case 'P': /* Process PID */
+				/* Since we are adding it here, don't append */
+				addPID=0;
+
+				/* We don't need to pre-check that the number
+				   fits since we added a padding of 11
+				   characters to the end of the string buffer
+				   just so that we don't need to do an extra
+				   check */
+				name_n += sprintf(&corename[name_n],"%d",current->pid);
+				break;
+
+			case 'U': /* UID of the process */
+				/* We don't need to pre-check that the number
+				   fits since we added a padding of 11
+				   characters to the end of the string buffer
+				   just so that we don't need to do an extra
+				   check */
+				name_n += sprintf(&corename[name_n],"%d",current->uid);
+				break;
+			}
+			break;
+
+		default:	/* Anything else just pass along */
+			corename[name_n++] = core_name_format[fmt_i];
+		}
+	}
+
+	/* If we still want to append the PID and there is room, do so */
+	/* This is to preserve current behavior */
+	if (addPID && (name_n < MAX_CORE_NAME))
+	{
+		name_n += sprintf(&corename[name_n],".%d",current->pid);
+	}
+
+	/* And make sure to null terminate the string */
+	corename[name_n]='\0';
+
 	file = filp_open(corename, O_CREAT | 2 | O_NOFOLLOW, 0600);
 	if (IS_ERR(file))
 		goto fail;
diff -urP linux-2.4.17/include/linux/sysctl.h linux-2.4.17-patch/include/linux/sysctl.h
--- linux-2.4.17/include/linux/sysctl.h	Mon Nov 26 08:29:17 2001
+++ linux-2.4.17-patch/include/linux/sysctl.h	Wed Feb 20 09:49:20 2002
@@ -124,6 +124,7 @@
 	KERN_CORE_USES_PID=52,		/* int: use core or core.%pid */
 	KERN_TAINTED=53,	/* int: various kernel tainted flags */
 	KERN_CADPID=54,		/* int: PID of the process to notify on CAD */
+	KERN_CORE_NAME_FORMAT=55, /* string: core file name format string */
 };
 
 
diff -urP linux-2.4.17/kernel/sysctl.c linux-2.4.17-patch/kernel/sysctl.c
--- linux-2.4.17/kernel/sysctl.c	Fri Dec 21 12:42:04 2001
+++ linux-2.4.17-patch/kernel/sysctl.c	Wed Feb 20 09:49:20 2002
@@ -49,6 +49,7 @@
 extern int max_queued_signals;
 extern int sysrq_enabled;
 extern int core_uses_pid;
+extern char core_name_format[];
 extern int cad_pid;
 
 /* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */
@@ -171,6 +172,8 @@
 	 0644, NULL, &proc_dointvec},
 	{KERN_CORE_USES_PID, "core_uses_pid", &core_uses_pid, sizeof(int),
 	 0644, NULL, &proc_dointvec},
+	{KERN_CORE_NAME_FORMAT, "core_name_format", core_name_format, 64,
+	 0644, NULL, &proc_doutsstring, &sysctl_string},
 	{KERN_TAINTED, "tainted", &tainted, sizeof(int),
 	 0644, NULL, &proc_dointvec},
 	{KERN_CAP_BSET, "cap-bound", &cap_bset, sizeof(kernel_cap_t),

Re: [Etherboot-developers] Patch and a com speed preservation option

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

>This patch implements an option to disable most of etherboots
>initialization of the serial port so that the baud rate it will be
>preserved. 

Accepted.

Re: [Etherboot-developers] Etherboot modifications to achieve pxeboot based booting [PATCH]

[Doug A. <amb...@am...>]

Ken Yap writes:
| >	Attached herewith are patches to enable netbooting of FreeBSD via 
| >the pxeboot mechanism using etherboot-5.0.4 on all (etherboot-5.0.4) supporte
| >d
| >ethernet cards.
| >
| >	To enable, compile the utilities in /sys/boot/i386 with the enviorment
| >variable `ETHERBOOT_PXEEMU' set. Compile etherboot with `FREEBSD_PXEEMU'
| >defined in the Config file.
| 
| Thanks Rohit, that's very interesting. I looked through your changes and
| they are fully #ifdefed so I will probably have no objections to merging
| this change into the next version.
| 
| >Please note! This works only with FreeBSD pxeldr style btx clients.
| 
| Can anybody analyse on what it would take to modify the code to work
| with pxelinux?

I can't comment on pxelinux but I was able to boot pxegrub with it
(I know that isn't much of a test since pxegrub only uses the PXE
stuff to load the image into memory and grub deals with the NIC via
the Etherboot drivers).  To do this I made a change to the patches
so if the type was not identified then I assume it is a PXE type.
Doing a hexdump of some pxeloaders I didn't find anything in common
to identify the type easily.

Doug A.

Re: [Etherboot-developers] Etherboot modifications to achieve pxeboot based booting [PATCH]

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

>	Attached herewith are patches to enable netbooting of FreeBSD via 
>the pxeboot mechanism using etherboot-5.0.4 on all (etherboot-5.0.4) supporte
>d
>ethernet cards.
>
>	To enable, compile the utilities in /sys/boot/i386 with the enviorment
>variable `ETHERBOOT_PXEEMU' set. Compile etherboot with `FREEBSD_PXEEMU'
>defined in the Config file.

Thanks Rohit, that's very interesting. I looked through your changes and
they are fully #ifdefed so I will probably have no objections to merging
this change into the next version.

>Please note! This works only with FreeBSD pxeldr style btx clients.

Can anybody analyse on what it would take to modify the code to work
with pxelinux?

[Etherboot-developers] Etherboot modifications to achieve pxeboot based booting [PATCH]

[Rohit J. <ro...@pr...>]

Greetings,
	
	I have hacked the following files to provide limited PXE Emulation
support.

	Attached herewith are patches to enable netbooting of FreeBSD via 
the pxeboot mechanism using etherboot-5.0.4 on all (etherboot-5.0.4) supported
ethernet cards.

	To enable, compile the utilities in /sys/boot/i386 with the enviorment
variable `ETHERBOOT_PXEEMU' set. Compile etherboot with `FREEBSD_PXEEMU'
defined in the Config file.

	Also attached is a sample bootptab for your reference.

Files touched:
			etherboot-5.0.4/src/Config
			etherboot-5.0.4/src/main.c
			etherboot-5.0.4/src/misc.c
			etherboot-5.0.4/src/etherboot.h
			etherboot-5.0.4/src/linux-asm-string.h
			etherboot-5.0.4/src/osdep.h
			etherboot-5.0.4/src/start32.S

			/sys/boot/i386/btx/btx/Makefile
			/sys/boot/i386/btx/btx/btx.s
			/sys/boot/i386/btx/lib/Makefile
			/sys/boot/i386/btx/lib/btxsys.s
			/sys/boot/i386/btx/lib/btxv86.h
			/sys/boot/i386/libi386/Makefile
			/sys/boot/i386/libi386/pxe.c
			/sys/boot/i386/pxeldr/Makefile
			/sys/boot/i386/pxeldr/pxeldr.s
			
			
Please note! This works only with FreeBSD pxeldr style btx clients.

Regards,

rohit

Re: [Etherboot-developers] Intel D815EGEW mainboard and RTL8139 NIC

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

>will stay away from the 5.1.1 version.  We just wanted someone to know about
>the problems we are having with that Intel mainboard under 5.1.1, thinking
>that someday the 5.1.1 might become a production release with the problem
>still intact.

Thanks. We differ from the Linux kernel convention in that fixes made in
n+1 don't have to wait until n+2 but go back into n. Otherwise the cycle
would take too long for Etherboot.

Re: [Etherboot-developers] Intel D815EGEW mainboard and RTL8139 NIC

[James N. <jn...@me...>]

Thanks for the input.   We will continue to use the 5.0.5 release.    We
will stay away from the 5.1.1 version.  We just wanted someone to know about
the problems we are having with that Intel mainboard under 5.1.1, thinking
that someday the 5.1.1 might become a production release with the problem
still intact.

Thanks Ken and everyone else for the work on Etherboot.   It is a great
product.

----- Original Message -----
From: "Ken Yap" <ke...@us...>
To: "Etherboot developers list" <eth...@li...>
Sent: Tuesday, February 19, 2002 4:30 PM
Subject: Re: [Etherboot-developers] Intel D815EGEW mainboard and RTL8139 NIC


> >of Etherboot works.  So it appears to be mainboard specific.    Our
question
> >is why does 5.0.5 work and 5.1.1 / 4.7.22 not work?   Is there something
we
> >can do to help test Etherboot 5.1.1 version with this mainboard?
>
> Why do you want to use 5.1.1 anyway? The 5.1.1 series are for testing
> and are not guaranteed to work. The version number does not indicate
> which one is more recent. In fact 5.0.5 is more recent and has had all
> relevant fixes merged in. You have to look at the release dates. There
> have been no development releases for a while because there have been no
> controversial changes.
>
> Same convention as the Linux kernels. Even minor release number is
> production, odd is development. Stay away from the development series
> unless you are want to help debug.
>
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Intel D815EGEW mainboard and RTL8139 NIC

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

>of Etherboot works.  So it appears to be mainboard specific.    Our question
>is why does 5.0.5 work and 5.1.1 / 4.7.22 not work?   Is there something we
>can do to help test Etherboot 5.1.1 version with this mainboard?

Why do you want to use 5.1.1 anyway? The 5.1.1 series are for testing
and are not guaranteed to work. The version number does not indicate
which one is more recent. In fact 5.0.5 is more recent and has had all
relevant fixes merged in. You have to look at the release dates. There
have been no development releases for a while because there have been no
controversial changes.

Same convention as the Linux kernels. Even minor release number is
production, odd is development. Stay away from the development series
unless you are want to help debug.

[Etherboot-developers] Intel D815EGEW mainboard and RTL8139 NIC

[James N. <jn...@me...>]

Sorry if this has been discussed before, I'm a new member to the list so
bear with me.

We have compiled Etherboot 5.1.1 and 4.7.22 and production version 5.0.5
without problems.   At first we compiled them under RedHat 7.1 with GCC
2.96-98 -- big mistake.  Compiler worked but Etherboot did not.  It would
not send  or receive packets.  So we went back to an older version of GCC
like mentioned in the Etherboot docs.     We went back to GCC 2.95-2 and now
Etherboot is happy.

We have an Intel D815EGEW mainboard with a Dolphin (RTL8139C) NIC with boot
PROM socket.    The Etherboot 4.7.22 or 5.1.1 PROM image (rtl8139.rom) will
not boot in this system but the Etherboot 5.0.5 PROM image does?   (All
versions of Etherboot compiled from same RedHat system)   We have installed
this same NIC in other systems with different mainboards and every version
of Etherboot works.  So it appears to be mainboard specific.    Our question
is why does 5.0.5 work and 5.1.1 / 4.7.22 not work?   Is there something we
can do to help test Etherboot 5.1.1 version with this mainboard?

Thanks for your time,

James

Re: [Etherboot-developers] ADMTek Comet 683

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

>I successfully used etherboot with $subject, after:
>s/681/683/
>and replacing 681's pci id with:
>1113:1216 (which is the pci id of comet683).
>
>So it seems that you can add the 683 card to the source without any
>coding. It'll be an easy way to increment the supported cards in
>etherboot. ;)
>
>Thanks,
>Gergely
>
>PS: Oh, I didn't said that this is in tulip.c

Can you please confirm that these are the correct changes? Thanks.

diff -cr ../../etherboot-5.0.5/src/NIC ./NIC
*** ../../etherboot-5.0.5/src/NIC	Mon Dec 17 18:22:46 2001
--- ./NIC	Sat Feb 16 09:38:55 2002
***************
*** 108,113 ****
--- 108,115 ----
  mx98725		tulip		0x10d9,0x0531
  # Another Macronix clone?
  mxic-98715	tulip		0x1113,0x1217
+ # ADMTek Comet 683 (reported by RISKO Gergely)
+ an683		tulip		0x1113,0x1216
  # ADMtek Centaur-P, found on stmicro NIC by Ranjan Parthasarathy
  an981		tulip		0x1317,0x0981
  # ADMtek Centaur-P Tulip clones
diff -cr ../../etherboot-5.0.5/src/config.c ./config.c
*** ../../etherboot-5.0.5/src/config.c	Mon Dec 10 17:43:30 2001
--- ./config.c	Sat Feb 16 09:40:25 2002
***************
*** 150,155 ****
--- 152,159 ----
  		"Davicom 9102", 0, 0, 0, 0},
  	{ PCI_VENDOR_ID_DAVICOM, PCI_DEVICE_ID_DM9009,
  		"Davicom 9009", 0, 0, 0, 0},
+ 	{ PCI_VENDOR_ID_MACRONIX, 0x1216,
+ 		"ADMTek Comet 683", 0, 0, 0, 0},
  	{ PCI_VENDOR_ID_ADMTEK, PCI_DEVICE_ID_ADMTEK_0985,
  		"ADMtek Centaur-P", 0, 0, 0, 0},
  	{ PCI_VENDOR_ID_ADMTEK, 0x0981,
diff -cr ../../etherboot-5.0.5/src/tulip.c ./tulip.c
*** ../../etherboot-5.0.5/src/tulip.c	Sun Dec  2 16:48:27 2001
--- ./tulip.c	Sat Feb 16 09:43:15 2002
***************
*** 228,233 ****
--- 228,235 ----
        TULIP_IOTYPE, 0x80, DC21140 },
      { "Macronix mxic-98715 (EN1217)", { 0x12171113, 0xffffffff, 0, 0, 0, 0 },
        TULIP_IOTYPE, 256, MX98715 },
+     { "ADMTek Comet 683", { 0x12161113, 0xffffffff, 0, 0, 0, 0 },
+       TULIP_IOTYPE, 256, MX98715 },
      { 0, { 0, 0, 0, 0, 0, 0 }, 0, 0, 0 },
  };
  

Re: [Etherboot-developers] ADMTek Comet 683

[Christopher Li <ch...@gn...>]

I think we can just add 683's pci id in the pci info array then
we can support both 683 and 681.

BTW, I can't find 681 in tulip.c. Which version of etherboot you
are using right now?

Chris


On Fri, 15 Feb 2002, RISKO Gergely wrote:

> Hello!
> 
> I successfully used etherboot with $subject, after:
> s/681/683/
> and replacing 681's pci id with:
> 1113:1216 (which is the pci id of comet683).
> 
> So it seems that you can add the 683 card to the source without any
> coding. It'll be an easy way to increment the supported cards in
> etherboot. ;)
> 
> Thanks,
> Gergely
> 
> PS: Oh, I didn't said that this is in tulip.c
> 
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 

[Etherboot-developers] ADMTek Comet 683

[RISKO G. <ri...@at...>]

Hello!

I successfully used etherboot with $subject, after:
s/681/683/
and replacing 681's pci id with:
1113:1216 (which is the pci id of comet683).

So it seems that you can add the 683 card to the source without any
coding. It'll be an easy way to increment the supported cards in
etherboot. ;)

Thanks,
Gergely

PS: Oh, I didn't said that this is in tulip.c

Re: [Etherboot-developers] Eric's kernel patches in Kernel Traffic

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

ke...@us... writes:

> Read about your submission in Kernel Traffic, Eric.
> 
> Hope you get some good feedback from that and summarise to us in due
> course. I look forward to a cleanup of the 3-4 segment kernel image
> layout which just grew like topsy from the floppy boot requirement, and
> to the day when mknbi-linux is no longer needed.

So far so good.   People have a clue what I am trying for.  Right now
I just need to take a bunch of stuff and start writing the good versions
now that I know what I am doing.

But until I get my TODO list a little shorter I'm going to be running around
like a maniac.

Eric

[Etherboot-developers] Eric's kernel patches in Kernel Traffic

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

Read about your submission in Kernel Traffic, Eric.

Hope you get some good feedback from that and summarise to us in due
course. I look forward to a cleanup of the 3-4 segment kernel image
layout which just grew like topsy from the floppy boot requirement, and
to the day when mknbi-linux is no longer needed.

[Etherboot-developers] Re: 3Com 3C905B and fix

[Michael H. <m.h...@so...>]

Hello!

> I tried to use etherboot 5.0.5 with 3C905B (the one with buggy Lucent
> chipset).

I investigated a bit further in this topic. To see how 3com resp. Lanworks
deal with this bug I used a 3C905C-TXM with MBA Rom built in. Donald
Beckers vortex-diag.c (www.scyld.com) says in pcidev_tbl that this card
(PCI ID: 0x10b7/0x9200) has also the flash_bug.

Rom-Scan detects a 2k rom image. Inspecting the rom contents with
vortex-diag -B makes me believing 3com work around this bug by a loader
in the first 2k of the rom (checksum for 2k of rom!), which sets the
transceiver
type temporarily (not in eeprom like 3C90X_BOOTROM_FIX), then reads/
copies the whole rom content and then boots.

Maybe we could implement a similar loader to etherboot, eleminating those
nasty 3C90X_BOOTROM_FIX hack.
I hope then there are no more side effects like NT4 and DOS driver  (would
make me happy ;-) ) problems.

Michael Hertel
Sommer GmbH & Co. KG




*********************** Disclaim ******************************
*Diese E-Mail wurde auf Viren geprueft. Sofern Dateianhaenge  *
*eines unkomprimierten Formates vorhanden waren, wurden diese *
*automatisch in ein komprimiertes, selbstentpackendes Format  *
*umgewandelt. Bei Fragen oder Problemen wenden Sie sich an    *
*an den Support. Vielen Dank. pos...@so...        *
*                                                             *
***************************************************************
*                                                             *
*This E-Mail was checked for viruses. If uncompressed attach- *
*ments were available, these were converted automatically     *
*into a compressed, unpacking format. For questions or        *
*problems ask the support. Thank you. pos...@so...*
***************************************************************

[Etherboot-developers] 3Com 3C905B and fix

[Michael H. <m.h...@so...>]

Hello!

I tried to use etherboot 5.0.5 with 3C905B (the one with buggy Lucent
chipset).
From disk all went fine. Booting a tagged DOS disk with microsoft network
client worked.

After flashing to eeprom first no bootrom is seen. Rom-Scan detect those
weird rom-images (buggy multiplexing problem...).

After apply of bootrom-fix rom is seen and booting, but DOS fails during
netbind with error 36, hardware failure (booting from disk drive brings up
the same behaviour).

In 3c90x.txt is a mention of setting the romsize with 3c90xcfg.exe, but I
can´t find those option. Also writing romsize (128k, AT29C010) directly
to InternalConfig did not change anything.

Thank`s in advance

Michael Hertel
Sommer GmbH & Co. KG




*********************** Disclaim ******************************
*Diese E-Mail wurde auf Viren geprueft. Sofern Dateianhaenge  *
*eines unkomprimierten Formates vorhanden waren, wurden diese *
*automatisch in ein komprimiertes, selbstentpackendes Format  *
*umgewandelt. Bei Fragen oder Problemen wenden Sie sich an    *
*an den Support. Vielen Dank. pos...@so...        *
*                                                             *
***************************************************************
*                                                             *
*This E-Mail was checked for viruses. If uncompressed attach- *
*ments were available, these were converted automatically     *
*into a compressed, unpacking format. For questions or        *
*problems ask the support. Thank you. pos...@so...*
***************************************************************