etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Multiboot Information structure is not correct

[SONE T. <ts...@cm...>]

On Tue, Jul 01, 2003 at 05:15:29PM -0600, Eric W. Biederman wrote:
> No. Etherboot gets the size part correct.  It just only includes it
> once.

You are right.

> If you want to submit a patch to fix etherboot please go ahead.
> I would request that anything that fixes multiboot support also
> add the detection of the multiboot header so it can coexist with
> more sane loaders.  

OK, the patch is attached.
This code is confirmed to give the same memory map as GRUB.
If Multiboot header is not found, it switches to ELFboot.

--
Takeshi


Index: arch/i386/core/multiboot_loader.c
===================================================================
RCS file: /cvsroot/etherboot/etherboot/etherboot-5.1/src/arch/i386/core/multiboot_loader.c,v
retrieving revision 1.2
diff -u -u -r1.2 multiboot_loader.c
--- arch/i386/core/multiboot_loader.c	20 Dec 2002 07:40:58 -0000	1.2
+++ arch/i386/core/multiboot_loader.c	2 Jul 2003 11:55:07 -0000
@@ -1,3 +1,8 @@
+/* Multiboot support
+ *
+ * 2003-07-02 mmap fix and header probe by SONE Takeshi
+ */
+
 struct multiboot_mods {
 	unsigned mod_start;
 	unsigned mod_end;
@@ -5,6 +10,14 @@
 	unsigned reserved;
 };
 
+struct multiboot_mmap {
+	unsigned int size;
+	unsigned int base_addr_low;
+	unsigned int base_addr_high;
+	unsigned int length_low;
+	unsigned int length_high;
+	unsigned int type;
+};
 
 /* The structure of a Multiboot 0.6 parameter block.  */
 struct multiboot_info {
@@ -27,20 +40,52 @@
 	unsigned syms_addr;
 	unsigned syms_shndx;
 	unsigned mmap_length;
-	struct e820entry *mmap_addr;
+	unsigned  mmap_addr;
 	/* The structure actually ends here, so I might as well put
 	 * the ugly e820 parameters here...
 	 */
-	unsigned e820entry_size;
-	struct e820entry mmap[E820MAX];
+	struct multiboot_mmap mmap[E820MAX];
+};
+
+/* Multiboot image header (minimal part) */
+struct multiboot_header {
+	unsigned int magic;
+#define MULTIBOOT_HEADER_MAGIC 0x1BADB002
+	unsigned int flags;
+	unsigned int checksum;
 };
 
+static struct multiboot_header *mbheader;
+
 static struct multiboot_info mbinfo;
 
+static void multiboot_probe(unsigned char *data, int len)
+{
+    int offset;
+    struct multiboot_header *h;
+
+    /* Multiboot spec requires the header to be in first 8KB of the image */
+    if (len > 8192)
+	    len = 8192;
+
+    for (offset = 0; offset < len; offset += 4) {
+	    h = (struct multiboot_header *) (data + offset);
+	    if (h->magic == MULTIBOOT_HEADER_MAGIC
+			    && h->magic + h->flags + h->checksum == 0) {
+		    printf("/Multiboot");
+		    mbheader = h;
+		    return;
+	    }
+    }
+    mbheader = 0;
+}
+
 static inline void multiboot_boot(unsigned long entry)
 {
 	unsigned char cmdline[512], *c;
 	int i;
+	if (!mbheader)
+		return;
 	/* Etherboot limits the command line to the kernel name,
 	 * default parameters and user prompted parameters.  All of
 	 * them are shorter than 256 bytes.  As the kernel name and
@@ -68,11 +113,21 @@
 	mbinfo.memupper = meminfo.memsize;
 	mbinfo.bootdev = 0;	/* not booted from disk */
 	mbinfo.cmdline = virt_to_phys(cmdline);
-	mbinfo.e820entry_size = sizeof(struct e820entry);
-	mbinfo.mmap_length = 
-		mbinfo.e820entry_size * meminfo.map_count;
-	mbinfo.mmap_addr = mbinfo.mmap;
-	memcpy(mbinfo.mmap, meminfo.map, mbinfo.mmap_length);
+	for (i = 0; i < (int) meminfo.map_count; i++) {
+		mbinfo.mmap[i].size = sizeof(struct multiboot_mmap)
+		    - sizeof(unsigned int);
+		mbinfo.mmap[i].base_addr_low = 
+		    (unsigned int) meminfo.map[i].addr;
+		mbinfo.mmap[i].base_addr_high = 
+		    (unsigned int) (meminfo.map[i].addr >> 32);
+		mbinfo.mmap[i].length_low = 
+		    (unsigned int) meminfo.map[i].size;
+		mbinfo.mmap[i].length_high = 
+		    (unsigned int) (meminfo.map[i].size >> 32);
+		mbinfo.mmap[i].type = meminfo.map[i].type;
+	}
+	mbinfo.mmap_length = meminfo.map_count * sizeof(struct multiboot_mmap);
+	mbinfo.mmap_addr = virt_to_phys(mbinfo.mmap);
 	
 	/* The Multiboot 0.6 spec requires all segment registers to be
 	 * loaded with an unrestricted, writeable segment.
Index: core/elf_loader.c
===================================================================
RCS file: /cvsroot/etherboot/etherboot/etherboot-5.1/src/core/elf_loader.c,v
retrieving revision 1.3
diff -u -u -r1.3 elf_loader.c
--- core/elf_loader.c	21 Feb 2003 03:33:00 -0000	1.3
+++ core/elf_loader.c	2 Jul 2003 11:55:17 -0000
@@ -159,6 +159,7 @@
 	}
 	printf("(ELF");
 	elf_freebsd_probe();
+	multiboot_probe(data, len);
 	printf(")... ");
 	phdr_size = estate.e.elf32.e_phnum * estate.e.elf32.e_phentsize;
 	if (estate.e.elf32.e_phoff + phdr_size > len) {
Index: core/osloader.c
===================================================================
RCS file: /cvsroot/etherboot/etherboot/etherboot-5.1/src/core/osloader.c,v
retrieving revision 1.9
diff -u -u -r1.9 osloader.c
--- core/osloader.c	24 May 2003 14:13:30 -0000	1.9
+++ core/osloader.c	2 Jul 2003 11:55:17 -0000
@@ -68,6 +68,7 @@
 #ifdef	IMAGE_MULTIBOOT
 #include "../arch/i386/core/multiboot_loader.c"
 #else
+#define multiboot_probe(data, len) do {} while(0)
 #define multiboot_boot(entry) do {} while(0)
 #endif
 

Re: [Etherboot-developers] Multiboot Information structure is not correct

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

Anselm Martin Hoffmeister <an...@ho...> writes:

> Hello list,
> 
> > The Multiboot Specification may be ambiguous and misleading,
> > but the example code in the Specification and the implementation 
> > in GRUB are different from Etherboot.
> 
> > Eric's mkelfImage is based on Etherboot's implementation
> > so it should also be fixed.
> 
> As someone has to fiddle on this multiboot stuff at all...
> Eric mentioned one could implement the SECURE_BOOT (as it should be
> in 5.1 CVS for some month now) for ELF multiboot as well.

ELF but not ELF multiboot.  The multiboot specification is not extensible.
It based on the assumption you are using a.out.

> Requirements to the image would be to have 64 bytes available for
> usage data (the md5-hash of the whole image including this
> storage-region with all 64 bytes set to zero, then encrypted with the
> private key which public counterpart is compiled into etherboot...)
> For more information, please have look into the 5.1 contrib section,
> the "safeboot" directory. The code is (at least the non-rsaeuro code)
> fairly trivial.

> Just a pity I don't understand where to put 64 bytes inside multiboot
> images, but I didn't even dig deeply into the MultiBoot specs.
> If you give me a hint, I can implement it myself.

Just using a standard ELF not should be sufficient.

I have been busy lately so I haven't had a chance to really look at that
stuff yet.

Eric

Re: [Etherboot-developers] Multiboot Information structure is not correct

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

SONE Takeshi <ts...@cm...> writes:

> Hi,
> I think that Multiboot loader in Etherboot is not correctly
> implemented.

I am certain I looked at this before and seeing things
matching the etherboot behavior.  But looking now
there is a difference in behavior.

Quoting the appropriate piece of the multiboot specification.
>    If bit 6 in the multiboot_info.flags word is set, then the
>    'mmap_*' fields are valid, and indicate the address and length of
>    a buffer containing a memory map of the machine provided by the
>    BIOS. 'mmap_addr' is the address, and 'mmap_length' is the total
>    size of the buffer. The buffer consists of one or more of the
>    following size/structure pairs ('size' is really used for
>    skipping to the next pair):
> 
>         +-------------------+
> -4      | size              |
>         +-------------------+
> 0       | BaseAddrLow       |
> 4       | BaseAddrHigh      |
> 8       | LengthLow         |
> 12      | LengthHigh        |
> 16      | Type              |
>         +-------------------+
> 
>    where 'size' is the size of the associated structure in bytes,
>    which can be greater than the minimum of 20 bytes. 'BaseAddrLow'
>    is the lower 32 bits of the starting address, and 'BaseAddrHigh'
>    is the upper 32 bits, for a total of a 64-bit starting address.
>    'LengthLow' is the lower 32 bits of the size of the memory region
>    in bytes, and 'LengthHigh' is the upper 32 bits, for a total of a
>    64-bit length. 'Type' is the variety of address range
>    represented, where a value of 1 indicates available RAM, and all
>    other values currently indicated a reserved area. 
>    
>    The map provided is guaranteed to list all standard RAM that
>    should be available for normal use. 

The etherboot interpretation of this was that size only occurred
once and was at a negative offset from the beginning of the
buffer.

The oskit and grub interpretation seems to be that size is a
member of the structure that we have an array of.

      +-------------------+
 0    | size              |
      +-------------------+
 4    | BaseAddrLow       |
 8    | BaseAddrHigh      |
12    | LengthLow         |
16    | LengthHigh        |
24    | Type              |
      +-------------------+


SONE Takeshi <ts...@cm...> writes:
> The Specification says 'mmap_addr' points to 'size' of the
> first mmap entry, but Etherboot's structure points to 
> 'base_addr_low'.

The specification says that size occurs at offset -4...
Which is what etherboot implements.

> Also, the 'size' of a mmap entry should not include the size of itself,
> but Etherboot does. (That is, a Multiboot OS looks at every 'size+4' 
> bytes for mmap entries, but with Etherboot, the mmap entries are
> at every 'size' bytes.)

No. Etherboot gets the size part correct.  It just only includes it
once.

> The Multiboot Specification may be ambiguous and misleading,
> but the example code in the Specification and the implementation 
> in GRUB are different from Etherboot.

I agree here.  Things are ambiguous.
 
> Eric's mkelfImage is based on Etherboot's implementation
> so it should also be fixed.

It is based on the same interpretation of the standard so
it has the same problem..

If you want to submit a patch to fix etherboot please go ahead.
I would request that anything that fixes multiboot support also
add the detection of the multiboot header so it can coexist with
more sane loaders.  

If not I suggest we just delete that code.  Since it is incorrect,
and there are better mechanisms in etherboot currently.

Eric

Re: [Etherboot-developers] Multiboot Information structure is not correct

[Anselm M. H. <an...@ho...>]

Hello list,

> The Multiboot Specification may be ambiguous and misleading,
> but the example code in the Specification and the implementation 
> in GRUB are different from Etherboot.

> Eric's mkelfImage is based on Etherboot's implementation
> so it should also be fixed.

As someone has to fiddle on this multiboot stuff at all...
Eric mentioned one could implement the SECURE_BOOT (as it should be
in 5.1 CVS for some month now) for ELF multiboot as well.
Requirements to the image would be to have 64 bytes available for
usage data (the md5-hash of the whole image including this
storage-region with all 64 bytes set to zero, then encrypted with the
private key which public counterpart is compiled into etherboot...)
For more information, please have look into the 5.1 contrib section,
the "safeboot" directory. The code is (at least the non-rsaeuro code)
fairly trivial.
Just a pity I don't understand where to put 64 bytes inside multiboot
images, but I didn't even dig deeply into the MultiBoot specs.
If you give me a hint, I can implement it myself.

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

-- 
Merke: Nicht das OS macht dich zu einem interessanteren Gespraechs-
partner, sondern das, was du darueber weisst. Und die Toleranz macht
dich dann noch zu einem liebenswerten Gespraechspartner.
(Buelent Caliskan in de.org.ccc)

[Etherboot-developers] Multiboot Information structure is not correct

[SONE T. <ts...@cm...>]

Hi,
I think that Multiboot loader in Etherboot is not correctly
implemented.

The Specification says 'mmap_addr' points to 'size' of the
first mmap entry, but Etherboot's structure points to 
'base_addr_low'.

Also, the 'size' of a mmap entry should not include the size of itself,
but Etherboot does. (That is, a Multiboot OS looks at every 'size+4' 
bytes for mmap entries, but with Etherboot, the mmap entries are
at every 'size' bytes.)

The Multiboot Specification may be ambiguous and misleading,
but the example code in the Specification and the implementation 
in GRUB are different from Etherboot.

Eric's mkelfImage is based on Etherboot's implementation
so it should also be fixed.

--
Takeshi

Re: [Etherboot-developers] UNDI driver

[H. P. A. <hp...@zy...>]

Michael Brown wrote:
> 
> The only thing I can think of that could cause this is a corrupted 
> interrupt handler.  I've taken a look at pxeprefix.S.  It performs the PXE 
> API calls PXENV_UNDI_SHUTDOWN, PXENV_STOP_UNDI and PXENV_UNLOAD_STACK.  It 
> doesn't check the return status of any of these calls and it then proceeds 
> to forcibly free base memory, even if the API calls returned "No, you 
> can't free base memory because I've got an interrupt handler installed 
> that I can't unhook for some reason".
> 

Ouch!

I'd recommend looking at the unloading code in PXELINUX.  Getting 
unloading to work (semi-)reliably was the single hardest thing I had to 
deal with in PXELINUX, believe it or not.

PXELINUX is quite conservative; if it detects any errors it assumes 
memory is not freeable; Linux doesn't care anyway.

	-hpa

Re: [Etherboot-developers] [PATCH] ipconfig dhcp mtu option support

[Hans-Peter J. <hp...@ur...>]

Dear Ken,

On Sunday 22 June 2003 03:18, Ken Yap wrote:
> >BTW, anybody willing to apply and test this on 2.5?
>
> I have a feeling you will not get much sympathy for 2.[56] because
> there ipconfig in the kernel is deprecated in favour of userspace
> config from the initrd.

Well, I've red about it. Applied to 2.4 would better fit to my current 
needs ;-)

Which reminds me, that my problems, reported at tuesday, still persist.
Would you loose a sentence or two on my 2nd message, and shed some light
in this mystical side of contemporary netbooting from a user, who 
enjoy{s|ed} using dhcpd as a network bootmanager with eb 5.0 builtin 
menus [flashed on 3com, but the last revision :-] a lot :-)

I may ask Eric directly, if he {had found|can imagine} a way to get eb 
5.1 in such a device' flash.

Still-launch-that-*-thing-from-floppy-if-not-freezed-ly y'rs,
Pete

Re: [Etherboot-developers] [PATCH] ipconfig dhcp mtu option support

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

>BTW, anybody willing to apply and test this on 2.5?

I have a feeling you will not get much sympathy for 2.[56] because there
ipconfig in the kernel is deprecated in favour of userspace config from
the initrd.

[Etherboot-developers] [PATCH] ipconfig dhcp mtu option support

[Hans-Peter J. <hp...@ur...>]

Hi,

while experimenting with jumbo frames in a diskless setup, I came
across the problem to enable them properly on the client. This is 
due to missing support for the dhcp interface-mtu option in ipconfig.

It took me this patch to make them work. Note, that I ommited the
bootp_init_ext, so this one is limited to dhcp by now... While at
it, I've cleaned up the ifreq struct usage a bit.

If you're going to test this, please let me know, if it __works__ 
for you, too, since I plan to send it to Marcelo, when 'enough' 
positives arrived here.

BTW, anybody willing to apply and test this on 2.5?

Enjoy,
Pete

P.S.: I'm using e1000 (Intel Pro/1000 MT Desktop) GB NICs here.

--- linux-2.4.20/net/ipv4/ipconfig.c.orig	2003-06-21 17:24:21.000000000 +0200
+++ linux/net/ipv4/ipconfig.c	2003-06-22 01:50:53.000000000 +0200
@@ -27,10 +27,13 @@
  *  Merged changes from 2.2.19 into 2.4.3
  *              -- Eric Biederman <ebi...@ln...>, 22 April Aug 2001
  *
  *  Multipe Nameservers in /proc/net/pnp
  *              --  Josef Siemes <js...@we...>, Aug 2002
+ *
+ *  Support for MTU selection via DHCP
+ *              -- Hans-Peter Jansen <hp...@ur...>, June 2003
  */
 
 #include <linux/config.h>
 #include <linux/types.h>
 #include <linux/string.h>
@@ -144,10 +147,13 @@
  */
 
 /* Name of user-selected boot device */
 static char user_dev_name[IFNAMSIZ] __initdata = { 0, };
 
+/* MTU of device (if requested) */
+static int ic_dev_mtu __initdata = 0;
+
 /* Protocols supported by available interfaces */
 static int ic_proto_have_if __initdata = 0;
 
 #ifdef IPCONFIG_DYNAMIC
 static spinlock_t ic_recv_lock = SPIN_LOCK_UNLOCKED;
@@ -262,21 +268,32 @@
 	sin->sin_family = AF_INET;
 	sin->sin_addr.s_addr = addr;
 	sin->sin_port = port;
 }
 
-static int __init ic_dev_ioctl(unsigned int cmd, struct ifreq *arg)
+static int __init ic_devinet_ioctl(unsigned int cmd, struct ifreq *arg)
 {
 	int res;
 
 	mm_segment_t oldfs = get_fs();
 	set_fs(get_ds());
 	res = devinet_ioctl(cmd, arg);
 	set_fs(oldfs);
 	return res;
 }
 
+static int __init ic_dev_ioctl(unsigned int cmd, struct ifreq *arg)
+{
+	int res;
+
+	mm_segment_t oldfs = get_fs();
+	set_fs(get_ds());
+	res = dev_ioctl(cmd, arg);
+	set_fs(oldfs);
+	return res;
+}
+
 static int __init ic_route_ioctl(unsigned int cmd, struct rtentry *arg)
 {
 	int res;
 
 	mm_segment_t oldfs = get_fs();
@@ -291,30 +308,38 @@
  */
 
 static int __init ic_setup_if(void)
 {
 	struct ifreq ir;
-	struct sockaddr_in *sin = (void *) &ir.ifr_ifru.ifru_addr;
+	struct sockaddr_in *sin = (void *) &ir.ifr_addr;
 	int err;
 
 	memset(&ir, 0, sizeof(ir));
-	strcpy(ir.ifr_ifrn.ifrn_name, ic_dev->name);
+	strcpy(ir.ifr_name, ic_dev->name);
 	set_sockaddr(sin, ic_myaddr, 0);
-	if ((err = ic_dev_ioctl(SIOCSIFADDR, &ir)) < 0) {
+	if ((err = ic_devinet_ioctl(SIOCSIFADDR, &ir)) < 0) {
 		printk(KERN_ERR "IP-Config: Unable to set interface address (%d).\n", err);
 		return -1;
 	}
 	set_sockaddr(sin, ic_netmask, 0);
-	if ((err = ic_dev_ioctl(SIOCSIFNETMASK, &ir)) < 0) {
+	if ((err = ic_devinet_ioctl(SIOCSIFNETMASK, &ir)) < 0) {
 		printk(KERN_ERR "IP-Config: Unable to set interface netmask (%d).\n", err);
 		return -1;
 	}
 	set_sockaddr(sin, ic_myaddr | ~ic_netmask, 0);
-	if ((err = ic_dev_ioctl(SIOCSIFBRDADDR, &ir)) < 0) {
+	if ((err = ic_devinet_ioctl(SIOCSIFBRDADDR, &ir)) < 0) {
 		printk(KERN_ERR "IP-Config: Unable to set interface broadcast address (%d).\n", err);
 		return -1;
 	}
+	if (ic_dev_mtu) {
+		strcpy(ir.ifr_name, ic_dev->name);
+		ir.ifr_mtu = ic_dev_mtu;
+		if ((err = ic_dev_ioctl(SIOCSIFMTU, &ir))  < 0)
+			printk(KERN_ERR "IP-Config: Unable to set interface mtu to %d (%d).\n", 
+				ic_dev_mtu, err);
+			/* Don't error out because set mtu failure, just notice the operator */
+	}
 	return 0;
 }
 
 static int __init ic_setup_routes(void)
 {
@@ -576,10 +601,11 @@
 			3,	/* Default gateway */
 			6,	/* DNS server */
 			12,	/* Host name */
 			15,	/* Domain name */
 			17,	/* Boot path */
+			26,	/* MTU */
 			40,	/* NIS domain name */
 		};
 
 		*e++ = 55;	/* Parameter request list */
 		*e++ = sizeof(ic_req_params);
@@ -777,10 +803,13 @@
 			break;
 		case 17:	/* Root path */
 			if (!root_server_path[0])
 				ic_bootp_string(root_server_path, ext+1, *ext, sizeof(root_server_path));
 			break;
+		case 26:
+			ic_dev_mtu = ntohs(*(u16 *)(ext+1));
+			break;
 		case 40:	/* NIS Domain name (_not_ DNS) */
 			ic_bootp_string(system_utsname.domainname, ext+1, *ext, __NEW_UTS_LEN);
 			break;
 	}
 }
@@ -1294,10 +1323,12 @@
 	printk(",\n     host=%s, domain=%s, nis-domain=%s",
 	       system_utsname.nodename, ic_domain, system_utsname.domainname);
 	printk(",\n     bootserver=%u.%u.%u.%u", NIPQUAD(ic_servaddr));
 	printk(", rootserver=%u.%u.%u.%u", NIPQUAD(root_server_addr));
 	printk(", rootpath=%s", root_server_path);
+	if (ic_dev_mtu)
+		printk(", mtu=%d", ic_dev_mtu);
 	printk("\n");
 #endif /* !SILENT */
 
 	return 0;
 }

[Etherboot-developers] Re: [Etherboot-users] (no subject)

[Anselm M. H. <an...@ho...>]

Hello deng,

> Hi:
>    I have use mknbi-dos to make a image about 80M which include a mini=20
> windowd 98 se, It can boot windows 98 se ok, and all operater is ok, an=
d I=20
> can run 3 instance of iexplorer.exe, but when i run 4th instance of=20
> iexplorer.exe, the system is halt(the display is freezed, mouse & keybo=
ard=20
> is freezed too). when I reduce the size of image to less then 75M,=20
> everything is ok. Last I found when I increase the size of image to mor=
e=20
> than 75M, the system is halt when running 4th instance of IE, but less =
then=20
> 75M is ok!
>    I think whether when windows allocate memory the ramdisk is crashed =
by it
> =A3=BF
> Thanks very much!

Could you please verify this? You could e.g. post a "mem /c" output in
both situations (as short as possible before the crash) (mem /d and
mem /f could be useful, too...).
You could, in second situation, start some mem-consuming applications
(e.g. start several dozens of solitair :-)

Best regards,
 Anselm                            mailto:an...@ho...

[Etherboot-developers] (no subject)

[deng z. <dz...@ho...>]

Hi:
   I have use mknbi-dos to make a image about 80M which include a mini 
windowd 98 se, It can boot windows 98 se ok, and all operater is ok, and I 
can run 3 instance of iexplorer.exe, but when i run 4th instance of 
iexplorer.exe, the system is halt(the display is freezed, mouse & keyboard 
is freezed too). when I reduce the size of image to less then 75M, 
everything is ok. Last I found when I increase the size of image to more 
than 75M, the system is halt when running 4th instance of IE, but less then 
75M is ok!
   I think whether when windows allocate memory the ramdisk is crashed by it
？
Thanks very much!

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn  

Re: [Etherboot-developers] e1000 and etherboot menu

[Hans-Peter J. <hp...@ur...>]

Hi Anselm,

thanks for your quick answer.

On Tuesday 17 June 2003 18:56, Anselm Martin Hoffmeister wrote:
> Hello Hans-Peter,
>
> > [...]
> > only supported by the current development version, which
> > unfortunately has the menuing stuff removed.
> >
> > If I cannot flash etherboot on the NIC, I normally use a pxe target
> > to load etherboot (dhcp filename), which in turn presents the menu
> > and loads the default kernel.
> >
> > What is the prefered way to mimic this behaviour in the development
> > series?
>
> You can use some newer mknbi to create an external menu program which
> does exactly what you want. [man mknbi-menu] It seems to be with
> mknbi-1.2.6 and newer (though I did not use it myself). RTfineM...

Well, the manual is a bit sparse on that topic :-(.

Loading the e1000 driver from floppy and using menu.elf as the boot 
target restarts the system after printing
[E1000]Ethernet addr: xx:xx:xx:xx:xx:xx
(the last line printed is unpossible to read without a serial console)

Using menu.nbi gives the error message: not a valid image
Unable to load file and loops in the boot destination selection...

Never the less, even if I get the menu going, I have no idea, how to 
daisy chain it from the e1000.pxe image. Is it possible to combine 
those two images into one?

An additional side note: running e1000 from floppy stops in about 3 of 5 
times after loading the kernel image:

..........................done
[Freeze]

The kernel image was created with a command similar to:
mknbi-linux $kernelimg --format=elf --first32pm= --rootdir=$rootdir 
--ip=rom --append="$append > $netbootimg

> > Booting-from-floppy-is-really-uncool'ly y'rs
>
> Yup!
>
> > Pete
>
> Best regards,
>  Anselm Martin Hoffmeister
>  Stockholm Projekt Computer-Service
>  <an...@ho...>

Thanks again,
Pete

Re: [Etherboot-developers] e1000 and etherboot menu

[Anselm M. H. <an...@ho...>]

Hello Hans-Peter,

> [...]
> only supported by the current development version, which unfortunately
> has the menuing stuff removed. 

> If I cannot flash etherboot on the NIC, I normally use a pxe target to 
> load etherboot (dhcp filename), which in turn presents the menu and 
> loads the default kernel.

> What is the prefered way to mimic this behaviour in the development 
> series? 

You can use some newer mknbi to create an external menu program which does
exactly what you want. [man mknbi-menu] It seems to be with
mknbi-1.2.6 and newer (though I did not use it myself). RTfineM...

> Booting-from-floppy-is-really-uncool'ly y'rs

Yup!

> Pete

Best regards,
 Anselm Martin Hoffmeister
 Stockholm Projekt Computer-Service
 <an...@ho...>

-- 
Merke: Nicht das OS macht dich zu einem interessanteren Gespraechs-
partner, sondern das, was du darueber weisst. Und die Toleranz macht
dich dann noch zu einem liebenswerten Gespraechspartner.
(Buelent Caliskan in de.org.ccc)

[Etherboot-developers] e1000 and etherboot menu

[Hans-Peter J. <hp...@ur...>]

Hi,

today I finally got some PRO/1000 MT Desktop NICs, but now I'm in 
trouble. These NICs carry a 82540EM (PCI ID: 0x8086/0x100E) which is 
only supported by the current development version, which unfortunately 
has the menuing stuff removed. 

If I cannot flash etherboot on the NIC, I normally use a pxe target to 
load etherboot (dhcp filename), which in turn presents the menu and 
loads the default kernel.

What is the prefered way to mimic this behaviour in the development 
series? 

Booting-from-floppy-is-really-uncool'ly y'rs
Pete

[Etherboot-developers] Re: High-End Desktop Support

[YhLu <Yh...@ty...>]

Eric and Ron,

Thanks for the direction.

After I use zelf format, the NIC is OK and can download kernel from thr =
TFTP
server now.

Regards

Yinghai Lu

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: lin...@cl...
[mailto:lin...@cl...] =B4=FA=B1=ED Yinghai Lu
=B7=A2=CB=CD=CA=B1=BC=E4: 2003=C4=EA6=D4=C214=C8=D5 19:00
=CA=D5=BC=FE=C8=CB: 'Eric W. Biederman'
=B3=AD=CB=CD: 'ron minnich'; lin...@cl...; 'Etherboot =
Developers'
=D6=F7=CC=E2: Re: [Etherboot-developers] High-End Desktop Support

Eric,

But it works for 5.0.8 and 5.0.9. and I have tried it on RH 8 and RH 9.

1. strip e1000.elf : 92 bytes
2. strip -R comment e1000.elf : 92 bytes.
3. strip -R note e1000.elf : 92 bytes.
4. strip -R comment -R note e1000.elf : 92 bytes.

Anyway I will use zelf format.

Regards

Yinghai Lu

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: lin...@cl...
[mailto:lin...@cl...] =B4=FA=B1=ED Eric W. =
Biederman
=B7=A2=CB=CD=CA=B1=BC=E4: 2003=C4=EA6=D4=C214=C8=D5 18:17
=CA=D5=BC=FE=C8=CB: Yinghai Lu
=B3=AD=CB=CD: 'ron minnich'; lin...@cl...; 'Etherboot =
Developers'
=D6=F7=CC=E2: Re: [Etherboot-developers] g-e$: g-e$: g-e$: High-End =
Desktop
Support

"Yinghai Lu" <yh...@ty...> writes:

> Thanks, I will try again with zelf.
>=20
> I have used strip make ebi,=20
> # strip -R comment -R note e1000.elf
> The EBI file only 92 bytes ???

There should be nothing worth stripping by the time the etherboot
build gets that far, at least for 5.1.x.  It is desirable to
keep the notes we have placed there.

Beyond that it looks like by trying to strip etherboot you have
hit one of the many binutils bugs that crop up from time to time.

Eric

_______________________________________________
Linuxbios mailing list
Lin...@cl...
http://www.clustermatic.org/mailman/listinfo/linuxbios

_______________________________________________
Linuxbios mailing list
Lin...@cl...
http://www.clustermatic.org/mailman/listinfo/linuxbios

Re: [Etherboot-developers] High-End Desktop Support

[Yinghai L. <yh...@ty...>]

Eric,

But it works for 5.0.8 and 5.0.9. and I have tried it on RH 8 and RH 9.

1. strip e1000.elf : 92 bytes
2. strip -R comment e1000.elf : 92 bytes.
3. strip -R note e1000.elf : 92 bytes.
4. strip -R comment -R note e1000.elf : 92 bytes.

Anyway I will use zelf format.

Regards

Yinghai Lu

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: lin...@cl...
[mailto:lin...@cl...] =B4=FA=B1=ED Eric W. Biederman
=B7=A2=CB=CD=CA=B1=BC=E4: 2003=C4=EA6=D4=C214=C8=D5 18:17
=CA=D5=BC=FE=C8=CB: Yinghai Lu
=B3=AD=CB=CD: 'ron minnich'; lin...@cl...; 'Etherboot =
Developers'
=D6=F7=CC=E2: Re: [Etherboot-developers] g-e$: g-e$: g-e$: High-End =
Desktop
Support

"Yinghai Lu" <yh...@ty...> writes:

> Thanks, I will try again with zelf.
>=20
> I have used strip make ebi,=20
> # strip -R comment -R note e1000.elf
> The EBI file only 92 bytes ???

There should be nothing worth stripping by the time the etherboot
build gets that far, at least for 5.1.x.  It is desirable to
keep the notes we have placed there.

Beyond that it looks like by trying to strip etherboot you have
hit one of the many binutils bugs that crop up from time to time.

Eric

_______________________________________________
Linuxbios mailing list
Lin...@cl...
http://www.clustermatic.org/mailman/listinfo/linuxbios

Re: [Etherboot-developers] 答复: 答复: 答复: High-End Desktop Support

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

"Yinghai Lu" <yh...@ty...> writes:

> Thanks, I will try again with zelf.
> 
> I have used strip make ebi, 
> # strip -R comment -R note e1000.elf
> The EBI file only 92 bytes ???

There should be nothing worth stripping by the time the etherboot
build gets that far, at least for 5.1.x.  It is desirable to
keep the notes we have placed there.

Beyond that it looks like by trying to strip etherboot you have
hit one of the many binutils bugs that crop up from time to time.

Eric

[Etherboot-developers] =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTogSGlnaC1FbmQgRGVza3RvcCAgU3VwcA==?= =?utf-8?B?b3J0?=

[Yinghai L. <yh...@ty...>]

Thanks, I will try again with zelf.

I have used strip make ebi,=20
# strip -R comment -R note e1000.elf
The EBI file only 92 bytes ???

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Eric W. Biederman [mailto:er...@ln...] =
=E4=BB=A3=E8=A1=A8 Eric W. Biederman
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2003=E5=B9=B46=E6=9C=8814=E6=97=A5 =
14:24
=E6=94=B6=E4=BB=B6=E4=BA=BA: Yinghai Lu
=E6=8A=84=E9=80=81: 'ron minnich'; lin...@cl...; =
'Etherboot Developers'
=E4=B8=BB=E9=A2=98: Re: =C2=B4=C3=B0=C2=B8=C2=B4: =
=C2=B4=C3=B0=C2=B8=C2=B4: High-End Desktop Support

"Yinghai Lu" <yh...@ty...> writes:

> Eric,
>=20
> Thanks for the quick response.
> >> 3. If enable RELOCATION: got error: It can not calculate the file
> size, and
> >> keep print " 61:rom_read_bytes() - skipping block 16"
> >The only difference in the loader that looks relevant
> >is the second PT_LOAD segment now has a size.
> >You are not running mkelfImage on the etherboot file are you?
> >That is only need for the Linux kernel.
>=20
> Yes, I didn't mkelfImage, I only use that to transfer kernel and add
> some tags, at last the ELF files is put into the boot server's
> /tftpboot.

Hmm.  Then you have something corrupted.
=20
> In the Config, You said that 5.2 need all drivers to support =
RELOCATION.
> So Does the E1000 driver support RELOCATION yet?

Yes.
=20
> Your snippet is for RELOCATION or not?

RELOCATION but that should not matter this early in the startup
because you die before the code is relocated.

Seriously the ELF header information was very wrong.  Multiple
PT_LOAD segments.  And addresses and sizes that don't make
any sense at all.  I don't know where to start but it looks
very strongly like your ELF image is corrupted.

Eric

[Etherboot-developers] Re: =?gb2312?b?tPC4tA==?=: =?gb2312?b?tPC4tA==?=: High-End Desktop Support

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

"Yinghai Lu" <yh...@ty...> writes:

> Eric,
> 
> Thanks for the quick response.
> >> 3. If enable RELOCATION: got error: It can not calculate the file
> size, and
> >> keep print " 61:rom_read_bytes() - skipping block 16"
> >The only difference in the loader that looks relevant
> >is the second PT_LOAD segment now has a size.
> >You are not running mkelfImage on the etherboot file are you?
> >That is only need for the Linux kernel.
> 
> Yes, I didn't mkelfImage, I only use that to transfer kernel and add
> some tags, at last the ELF files is put into the boot server's
> /tftpboot.

Hmm.  Then you have something corrupted.
 
> In the Config, You said that 5.2 need all drivers to support RELOCATION.
> So Does the E1000 driver support RELOCATION yet?

Yes.
 
> Your snippet is for RELOCATION or not?

RELOCATION but that should not matter this early in the startup
because you die before the code is relocated.

Seriously the ELF header information was very wrong.  Multiple
PT_LOAD segments.  And addresses and sizes that don't make
any sense at all.  I don't know where to start but it looks
very strongly like your ELF image is corrupted.

Eric

[Etherboot-developers] =?gb2312?B?tPC4tDogtPC4tDogSGlnaC1FbmQgRGVza3RvcCBTdXBwb3J0?=

[Yinghai L. <yh...@ty...>]

Eric,

Thanks for the quick response.
>> 3. If enable RELOCATION: got error: It can not calculate the file
size, and
>> keep print " 61:rom_read_bytes() - skipping block 16"
>The only difference in the loader that looks relevant
>is the second PT_LOAD segment now has a size.
>You are not running mkelfImage on the etherboot file are you?
>That is only need for the Linux kernel.

Yes, I didn't mkelfImage, I only use that to transfer kernel and add
some tags, at last the ELF files is put into the boot server's
/tftpboot.

In the Config, You said that 5.2 need all drivers to support RELOCATION.
So Does the E1000 driver support RELOCATION yet?

Your snippet is for RELOCATION or not?

Regards

Yinghai Lu

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Eric W. Biederman [mailto:er...@ln...] =
=B4=FA=B1=ED Eric W. Biederman
=B7=A2=CB=CD=CA=B1=BC=E4: 2003=C4=EA6=D4=C214=C8=D5 9:23
=CA=D5=BC=FE=C8=CB: YhLu
=B3=AD=CB=CD: ron minnich; lin...@cl...; Etherboot =
Developers
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: High-End Desktop Support

YhLu <Yh...@ty...> writes:

> Eric and Ron,
>=20
> I can get into the Etherboot now.  But I meet problem again:
>=20
> Etherboot 5.0.10 (Last Product version) only support Intel 82544. Tyan
s2725
> uses Intel 82646EB. (DeviceID is ox1010).
> So It said" No Adapter found".=20
>=20
> Etherboot 5.1.8 seems support 82546, But I found
> 1. can not make EBI, have to use ELF. It is around 30KB.

Correct.  You can also make zelf if that helps.  There was
a naming cleanup in the extensions used by etherboot.

> 2. If disable RELOCATION : got error: NO HEAP FOUND.
Something is very wrong here even though etherboot got
loaded.  There are PT_LOAD segments.  Etherboot only has one.
Something looks corrupted.

> 3. If enable RELOCATION: got error: It can not calculate the file
size, and
> keep print " 61:rom_read_bytes() - skipping block 16"

The only difference in the loader that looks relevant
is the second PT_LOAD segment now has a size.


You are not running mkelfImage on the etherboot file are you?
That is only need for the Linux kernel.

> My Question is:
> 1. When do you plan to support 82546? In 5.0.11 or 5.2.0.
5.0.x never.  GigE drivers are to large, to easily support there.
Plus the LinuxBIOS support isn't half as good in 5.0.x. =20

As for 5.2.x whenever there is enough consensus among the developers
that we are there.  We are quite close but...

p.s. Someone remind me to put calculate the checksum on the
etherboot image in apply_elf_prefix...

> 2. Is there any easy way to modify 5.0.10 to make it work with Intel
82546?

No.


Here is a snippet of what the loader Loading etherboot should look like.
------------------------------

Found ELF candiate at offset 0
Loading Etherboot version: 5.1.8pre5
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x21aa2 offset 0xc0 filesize 0x61de
(cleaned up) New segment addr 0x20000 size 0x21aa2 offset 0xc0 filesize
0x61de
Loading Segment: addr: 0x0000000000020000 memsz: 0x0000000000021aa2
filesz: 0x00000000000061de
Clearing Segment: addr: 0x00000000000261de memsz: 0x000000000001b8c4
Jumping to boot code at 0x20000
ROM segment 0xdffe length 0xd050 reloc 0x00020000

>=20
> 222222222222222222222222222222222222222222222222222
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.
> Version 1.2
>=20
>     37:init_bytes() - zkernel_start:0xffff0000
zkernel_mask:0x0000ffff
> Found ELF candiate at offset 0
> Dropping non PT_LOAD segment
> New segment addr 0x20000 size 0x10e80c3 offset 0xb0 filesize 0x755c
> (cleaned up) New segment addr 0x20000 size 0x10e80c3 offset 0xb0
filesize
> 0x755c
>=20
> Loading Segment: addr: 0x000000003ffca7e8 memsz: 0x000000000000ec0c
filesz:
> 0x00
> 0000000000755c
> Clearing Segment: addr: 0x000000003ffd1d44 memsz: 0x00000000000076b0
> Loading Segment: addr: 0x000000000002ec0c memsz: 0x00000000010d94b7
filesz:
> 0x00
> 00000000000000
> Clearing Segment: addr: 0x000000000002ec0c memsz: 0x00000000010d94b7
> Jumping to boot code at 0x20000
> ROM segment 0x0000 length 0xfbf8 reloc 0x00020000
> CPU 1343 Mhz
> Etherboot 5.1.8 (GPL) Tagged ELF (Multiboot) for [E1000]
> init_heap: No heap found.
>=20
> 22222222222222222222222222222222222222222222222222222222222222222
>=20
>
333333333333333333333333333333333333333333333333333333333333333333333333
33
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.
> Version 1.2
>=20
>     37:init_bytes() - zkernel_start:0xffff0000
zkernel_mask:0x0000ffff
> Found ELF candiate at offset 0
> Dropping non PT_LOAD segment
> New segment addr 0x20000 size 0x1106000 offset 0xb0 filesize 0x76bcc3
> (cleaned up) New segment addr 0x20000 size 0x1106000 offset 0xb0
filesize
> 0x76bc
> c3
> Loading Segment: addr: 0x000000003ffca7e8 memsz: 0x000000000000ec0c
filesz:
> 0x00
> 0000000000ec0c
> Loading Segment: addr: 0x000000000002ec0c memsz: 0x00000000010f73f4
filesz:
> 0x00
> 0000000075d0b7
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>
333333333333333333333333333333333333333333333333333333333333333333333333
3333
> 3
>=20
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: YhLu=20
> =B7=A2=CB=CD=CA=B1=BC=E4: 2003=C4=EA6=D4=C213=C8=D5 0:27
> =CA=D5=BC=FE=C8=CB: ron minnich; ebi...@ln...
> =B3=AD=CB=CD: lin...@cl...
> =D6=F7=CC=E2: =B4=F0=B8=B4: High-End Desktop Support
>=20
> Eric,
>=20
> I am working on porting linuxbios to Tyan s2725. The southbridge is
ICH5.
>=20
> I have copied 82801ca to 82801er. And update pci_ids.h to add some
ICH5
> device id.
>=20
> I compare the Intel whitepaper, only need to comment out several line
in
> ich5_ioapi.c. because ICH5 has no operation to index 3 reg.
>=20
> I didn't initialize USB and Serial ATA.=20
>=20
> I used e1000.ebi from Etherboot 5.0.8.=20
>=20
> I only got the following result. The ebi size is 18164, so I set
> ROM_IMAGE_SIZE to 46*1024.=20
>=20
> I wonder why the size if not right: 0x4564 =3D 17764. But the EBI is
18164.
>=20
> Regards
>=20
> Yinghai Lu
>=20
> Console output:
>=20
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.
> Version 1.2
>=20
>     37:init_bytes() - zkernel_start:0xffff0000
zkernel_mask:0x0000ffff
> Found ELF candiate at offset 0
> New segment addr 0x94000 size 0x7168 offset 0x60 filesize 0x4564
> (cleaned up) New segment addr 0x94000 size 0x7168 offset 0x60 filesize
> 0x4564
> Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000007168
filesz:
> 0x00
> 00000000004564
> Clearing Segment: addr: 0x0000000000098564 memsz: 0x0000000000002c04
> Jumping to boot code at
> =
0x=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=
=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=
=80=80=80=80=80
>=20
>
=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=
=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=
=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80
=80=80=80=80
>=20

[Etherboot-developers] Re: =?gb2312?b?tPC4tA==?=: High-End Desktop Support

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

YhLu <Yh...@ty...> writes:

> Eric and Ron,
>=20
> I can get into the Etherboot now.  But I meet problem again:
>=20
> Etherboot 5.0.10 (Last Product version) only support Intel 82544. Tyan s2=
725
> uses Intel 82646EB. (DeviceID is ox1010).
> So It said" No Adapter found".=20
>=20
> Etherboot 5.1.8 seems support 82546, But I found
> 1. can not make EBI, have to use ELF. It is around 30KB.

Correct.  You can also make zelf if that helps.  There was
a naming cleanup in the extensions used by etherboot.

> 2. If disable RELOCATION : got error: NO HEAP FOUND.
Something is very wrong here even though etherboot got
loaded.  There are PT_LOAD segments.  Etherboot only has one.
Something looks corrupted.

> 3. If enable RELOCATION: got error: It can not calculate the file size, a=
nd
> keep print " 61:rom_read_bytes() - skipping block 16"

The only difference in the loader that looks relevant
is the second PT_LOAD segment now has a size.


You are not running mkelfImage on the etherboot file are you?
That is only need for the Linux kernel.

> My Question is:
> 1. When do you plan to support 82546? In 5.0.11 or 5.2.0.
5.0.x never.  GigE drivers are to large, to easily support there.
Plus the LinuxBIOS support isn't half as good in 5.0.x.=20=20

As for 5.2.x whenever there is enough consensus among the developers
that we are there.  We are quite close but...

p.s. Someone remind me to put calculate the checksum on the
etherboot image in apply_elf_prefix...

> 2. Is there any easy way to modify 5.0.10 to make it work with Intel 8254=
6?

No.


Here is a snippet of what the loader Loading etherboot should look like.
------------------------------

Found ELF candiate at offset 0
Loading Etherboot version: 5.1.8pre5
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x21aa2 offset 0xc0 filesize 0x61de
(cleaned up) New segment addr 0x20000 size 0x21aa2 offset 0xc0 filesize 0x6=
1de
Loading Segment: addr: 0x0000000000020000 memsz: 0x0000000000021aa2 filesz:=
 0x00000000000061de
Clearing Segment: addr: 0x00000000000261de memsz: 0x000000000001b8c4
Jumping to boot code at 0x20000
ROM segment 0xdffe length 0xd050 reloc 0x00020000

>=20
> 222222222222222222222222222222222222222222222222222
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.
> Version 1.2
>=20
>     37:init_bytes() - zkernel_start:0xffff0000  zkernel_mask:0x0000ffff
> Found ELF candiate at offset 0
> Dropping non PT_LOAD segment
> New segment addr 0x20000 size 0x10e80c3 offset 0xb0 filesize 0x755c
> (cleaned up) New segment addr 0x20000 size 0x10e80c3 offset 0xb0 filesize
> 0x755c
>=20
> Loading Segment: addr: 0x000000003ffca7e8 memsz: 0x000000000000ec0c files=
z:
> 0x00
> 0000000000755c
> Clearing Segment: addr: 0x000000003ffd1d44 memsz: 0x00000000000076b0
> Loading Segment: addr: 0x000000000002ec0c memsz: 0x00000000010d94b7 files=
z:
> 0x00
> 00000000000000
> Clearing Segment: addr: 0x000000000002ec0c memsz: 0x00000000010d94b7
> Jumping to boot code at 0x20000
> ROM segment 0x0000 length 0xfbf8 reloc 0x00020000
> CPU 1343 Mhz
> Etherboot 5.1.8 (GPL) Tagged ELF (Multiboot) for [E1000]
> init_heap: No heap found.
>=20
> 22222222222222222222222222222222222222222222222222222222222222222
>=20
> 33333333333333333333333333333333333333333333333333333333333333333333333333
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.
> Version 1.2
>=20
>     37:init_bytes() - zkernel_start:0xffff0000  zkernel_mask:0x0000ffff
> Found ELF candiate at offset 0
> Dropping non PT_LOAD segment
> New segment addr 0x20000 size 0x1106000 offset 0xb0 filesize 0x76bcc3
> (cleaned up) New segment addr 0x20000 size 0x1106000 offset 0xb0 filesize
> 0x76bc
> c3
> Loading Segment: addr: 0x000000003ffca7e8 memsz: 0x000000000000ec0c files=
z:
> 0x00
> 0000000000ec0c
> Loading Segment: addr: 0x000000000002ec0c memsz: 0x00000000010f73f4 files=
z:
> 0x00
> 0000000075d0b7
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
>     61:rom_read_bytes() - skipping block 16
> 3333333333333333333333333333333333333333333333333333333333333333333333333=
333
> 3
>=20
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: YhLu=20
> =B7=A2=CB=CD=CA=B1=BC=E4: 2003=C4=EA6=D4=C213=C8=D5 0:27
> =CA=D5=BC=FE=C8=CB: ron minnich; ebi...@ln...
> =B3=AD=CB=CD: lin...@cl...
> =D6=F7=CC=E2: =B4=F0=B8=B4: High-End Desktop Support
>=20
> Eric,
>=20
> I am working on porting linuxbios to Tyan s2725. The southbridge is ICH5.
>=20
> I have copied 82801ca to 82801er. And update pci_ids.h to add some ICH5
> device id.
>=20
> I compare the Intel whitepaper, only need to comment out several line in
> ich5_ioapi.c. because ICH5 has no operation to index 3 reg.
>=20
> I didn't initialize USB and Serial ATA.=20
>=20
> I used e1000.ebi from Etherboot 5.0.8.=20
>=20
> I only got the following result. The ebi size is 18164, so I set
> ROM_IMAGE_SIZE to 46*1024.=20
>=20
> I wonder why the size if not right: 0x4564 =3D 17764. But the EBI is 1816=
4.
>=20
> Regards
>=20
> Yinghai Lu
>=20
> Console output:
>=20
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.
> Version 1.2
>=20
>     37:init_bytes() - zkernel_start:0xffff0000  zkernel_mask:0x0000ffff
> Found ELF candiate at offset 0
> New segment addr 0x94000 size 0x7168 offset 0x60 filesize 0x4564
> (cleaned up) New segment addr 0x94000 size 0x7168 offset 0x60 filesize
> 0x4564
> Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000007168 files=
z:
> 0x00
> 00000000004564
> Clearing Segment: addr: 0x0000000000098564 memsz: 0x0000000000002c04
> Jumping to boot code at
> 0x=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=
=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=
=80=80=80=80=80=80
>=20
> =80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=
=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=
=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=80=
=80=80
>=20

Re: [Etherboot-developers] tcpdump Question

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

>I am reviewing a tcpdump file with ethereal for a driver I am working
>on.  I see the following:
>
>1: DHCP Discover 
>2: DHCP Discover
>3: DHCP Offer
>4: DHCP Request 
>5: DHCP Request
>...
>n: DHCP Request
>
>The DHCP Request is for the ip address that was offered.  From this I am
>making the assumption that the eb driver transmitted 2 packets and
>correctly received one packet.  Then it looks like it is not receiving
>anything else.
>
>Is this assumption correct?

Looks that way. A tip, dhcpdump can format the tcpdump output in a
readable fashion. E.g.

tcpdump -lenx -s 1500 -f tlan.dmp | dhcpdump

Looks like the receiver goes deaf after the first packet. Probably
the device isn't being set up for the next packet.

[Etherboot-developers] tcpdump Question

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

Hi

I am reviewing a tcpdump file with ethereal for a driver I am working
on.  I see the following:

1: DHCP Discover 
2: DHCP Discover
3: DHCP Offer
4: DHCP Request 
5: DHCP Request
...
n: DHCP Request

The DHCP Request is for the ip address that was offered.  From this I am
making the assumption that the eb driver transmitted 2 packets and
correctly received one packet.  Then it looks like it is not receiving
anything else.

Is this assumption correct?

I have attached the dump file.

Tim

Re: [Etherboot-developers] UNDI driver

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

Hi Michael,

I have run the tests you requested using EEPRO100 and 3C905C NICs. I am 
using CONSOLE_DUAL to capture output. I seem to lose a little output at 
the end with serial port echoing. If I use regular output I sometimes 
get a little more output. I suspect the Etherboot code size is a little 
bigger, and there is some output latency caused by the serial output 
routines waiting for the port.

> PXE chaining is working for me via all three routes, although I get the
> expected warning about a valid !PXE structure being found in free base
> memory with option (3).  (I haven't edited pxeprefix.S to delete the 
> !PXE
> signature yet).
> Michael

I have not been able to get chaining to work yet. I hope some other 
folks will give it a try so we can have more data points. Floppy load 
using UNDI works fine.

I hope this is helpful. Please let me know what to try next. And big 
thanks for debugging this!

Marty

On Thursday, June 12, 2003, at 10:47  AM, Michael Brown wrote:
> Could you retry this arrangement (PXE chaining) with DEBUG_BASEMEM 
> enabled
> in arch/i386/firmware/pcbios/basemem.c and three sets of configuration
> options in arch/i386/Config:
>
> 1.  CFLAGS+=-DPXELOADER_KEEP_ALL

[EEPRO100]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL) 
Tagged ELF for [UNDI]
Relocating _text from: [0000c300,0001bef0) to [07eb0410,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
Trying to allocate 1 kB of base memory, 574 kB free
Hunting for pixies...found !PXE at 0009dba0...ok
API 9db3:0106 St 8f80:0800 UD 98e0:4d30 UC 9db3:1e70 BD 9000:37c0 BC 
937c:563a
Resetting pixie...
UNDI API call 0x0070 failed with status 0x0001
API 9db3:0106 St 8f80:0800 UD 98e0:4d30 UC 9db3:1e70 BD 9000:37c0 BC 
937c:563a
UNDI API call 0x0000 failed with status 0x006a
UNDI API call 0x0076 failed with status 0x0001
UNDI API call 0x0070 failed with status 0x0001
Trying to free 7792 bytes base memory at 0x0009db30
WARNING: destructively expanding free block downwards to 0x0009d800
Trying to free 19760 bytes base memory at 0x00098e00
WARNING: destructively expanding free block downwards to 0x00098c00
Hunting for pixies...found !PXE at 0009d600...invalid checksum
...none found
Hunting for ROMs...found 55AA at 000c8000...PCI:8086:1229...ok
ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 8 kB of base memory, 573 kB free
Trying to allocate 20 kB of base memory, 565 kB free
Installing UNDI driver code to 8d40:0000, data at 8840:0000
UNDI driver created a pixie at 8d40:0070...ok
API 8d40:0106 St 8100:0800 UD 8840:4d30 UC 8d40:1e70 BD 0000:37c0 BC 
0000:563a
Initialized UNDI NIC with IO 0xdf00, IRQ 10, MAC 00:02:B3:25:45:56
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 545 kB free

(hangs)

[3C905C]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL) 
Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
Trying to allocate 1 kB of base memory, 639 kB free
Hunting for pixies...found !PXE at 0009d7a0...in free base memory!

WARNING: a valid !PXE structure was found in an area of memory marked 
as free!

API 9d74:00f6 St 0000:0000 UD 9a4b:3284 UC 9d74:24c0 BD 0000:0000 BC 
0000:0000

Ignoring and continuing, but this may cause problems later!

none found
Hunting for ROMs...found 55AA at 000c8000...PCI:10b7:9200...ok
ROM contains MBA UNDI by 3Com
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 10 kB of base memory, 638 kB free
Trying to allocate 13 kB of base memory, 628 kB free
Installing UNDI driver code to 9d00:0000, data at 99c0:0000
UNDI driver created a pixie at 9d00:0060...ok
API 9d00:00f6 St 0000:0000 UD 99c0:3284 UC 9d00:24c0 BD 0000:0000 BC 
0000:0000
Initialized UNDI NIC with IO 0xdc00, IRQ 10, MAC 00:01:02:59:03:D5
NDIS type DIX+802.3 interface at 10

(hangs)

> 2.  CFLAGS+=-DPXELOADER_KEEP_UNDI

[EEPRO100]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL) 
Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
Trying to allocate 1 kB of base memory, 611 kB free
Hunting for pixies...found !PXE at 0009dba0...ok
API 9db3:0106 St 0000:0000 UD 98e0:4d30 UC 9db3:1e70 BD 0000:0000 BC 
0000:0000
UNDI API call 0x0000 failed with status 0x006a
Trying to free 7792 bytes base memory at 0x0009db30
WARNING: destructively expanding free block downwards to 0x0009d800
Trying to free 19760 bytes base memory at 0x00098e00
WARNING: destructively expanding free block downwards to 0x00098c00
Hunting for pixies...none found
Hunting for ROMs...found 55AA at 000c8000...PCI:8086:1229...ok
ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 8 kB of base memory, 610 kB free
Trying to allocate 20 kB of base memory, 602 kB free
Installing UNDI driver code to 9680:0000, data at 9180:0000
UNDI driver created a pixie at 9680:0070...ok
API 9680:0106 St 8a40:0800 UD 9180:4d30 UC 9680:1e70 BD 0000:37c0 BC 
0000:563a
Initialized UNDI NIC with IO 0xdf00, IRQ 10, MAC 00:02:B3:25:45:56
ND

(hangs)

[3C905C]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL) 
Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
Trying to allocate 1 kB of base memory, 617 kB free
Hunting for pixies...found !PXE at 0009d7a0...ok
API 9d74:00f6 St 0000:0000 UD 9a4b:3284 UC 9d74:24c0 BD 0000:0000 BC 
0000:0000
Initialized UNDI NIC with IO 0xdc00, IRQ 10, MAC 00:01:02:59:03:D5
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 616 kB free
...Me: 192.168.2.137, Server: 192.168.2.37, Gateway 192.168.2.15
Loading 192.168.2.37:/ltsp-0x8000.nb .....

After the last "Trying to allocate 2 kB of base memory, 616 kB free" 
entry, things start moving very slowly. It takes about a minute for the 
DHCP information to get received, and then the Loading line moves 
glacially. It's been running for about 5 minutes, and so far I have:

Loading 192.168.2.37:/ltsp-0x8000.nb .......(NBI)......

normally this happens almost instantly. More memory contention? PXE 
interrupt handlers interfering with Etherboot polling drivers?

> 3.  (nothing)

[EEPRO100]
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
Trying to allocate 1 kB of base memory, 638 kB free
Hunting for pixies...found !PXE at 0009dba0...in free base memory!

WARNING: a valid !PXE structure was found in an area of memory marked 
as free!

API 9db3:0106 St 0000:0000 UD 98e0:4d30 UC 9db3:1e70 BD 0000:0000 BC 
0000:0000

Ignoring and continuing, but this may cause problems later!

none found
Hunting for ROMs...found 55AA at 000c8000...PCI:8086:1229...ok
ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 8 kB of base memory, 637 kB free
Trying to allocate 20 kB of base memory, 629 kB free
Installing UNDI driver code to 9d40:0000, data at 9840:0000
UNDI driver created a pixie at 9d40:0070...ok
API 9d40:0106 St 9100:0800 UD 9840:4d30 UC 9d40:1e70 BD 0000:37c0 BC 
0000:563a
Initialized UNDI NIC with IO 0xdf00, IRQ 10, MAC 00:02:B3:25:45:56
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 609 kB free

(hangs)

[3C905C]
ROM segment 0x0000 length 0x0000 reloc 0x00020000Etherboot 5.1.8 (GPL) 
Tagged ELF for [UNDI]
Relocating _text from: [0000c2d0,0001be80) to [07eb0450,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
Trying to allocate 1 kB of base memory, 639 kB free
Hunting for pixies...found !PXE at 0009d7a0...in free base memory!

WARNING: a valid !PXE structure was found in an area of memory marked 
as free!

API 9d74:00f6 St 0000:0000 UD 9a4b:3284 UC 9d74:24c0 BD 0000:0000 BC 
0000:0000

Ignoring and continuing, but this may cause problems later!

found !PXE at 0009c000...invalid checksum
...none found
Hunting for ROMs...found 55AA at 000c8000...PCI:10b7:9200...ok
ROM contains MBA UNDI by 3Com
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 10 kB of base memory, 638 kB free
Trying to allocate 13 kB of base memory, 628 kB free
Installing UNDI driver code to 9d00:0000, data at 99c0:0000
UNDI driver created a pixie at 9d00:0060...ok
API 9d00:00f6 St 0000:0000 UD 99c0:3284 UC 9d00:24c0 BD 0000:0000 BC 
0000:0000
Initialized UNDI NIC with IO 0xdc00, IRQ 10, MAC 00:01:02:59:03:D5
NDIS type DIX+802.3 interface at 10

(hangs)

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

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

Re: [Etherboot-developers] Alignment Question

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

On Thu, 12 Jun 2003, Timothy Legge wrote:
> I am looking at a doc that says:
> Align the list to the nearest octet (byte) boundary.
> I am assuming that octet is eight bits or one byte.  Is that correct?

Yes.

> If so, is any thing special necessary.  That is, do I need 
> __attribute__ ((aligned(1)))?

No; unless it's in the middle of a structure that involves bit fields then 
it will be byte aligned anyway.

Michael