Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Eric W B. <ebi...@ln...>]

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

> What I did:
> 
> cd etherboot-5.0/src
> make bin32/3c509.fd0
> make bin32/3c509.rom
> mknbi-linux bin32/3c509.rom > /tftpboot/lts/bootrom
> 
> reconfigured /etc/dhcpd.conf for the nic in question to grab the bootrom
> file
> 
> I booted with the 3c509.fd0 floppy from above and verified that version 5.0
> could load itself.  Then I reconfigured /etc/dhcpd.conf  while the bootrom
> was looping and booting itself and picked up the ltsp vmlinuz kernel and
> restarted dhcpd.  It worked, it transfered the kernel and boot as far as
> dhclient.
> 
> Then I:
> 
> cd etherboot-5.1.2rc3/src
> make bin32/3c509.fd0
> 
> when booting from the floppy I received the following:
> 
> blah..
> 
> Searching for server (DHCP)...
> ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
> Laoding 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI)
> segment [00092800,00094000) does not fit in an memory region
> error: not a valid image
> Unable to load file.
> <sleep>
> 
> I reconfigured /etc/dhcpd.conf to point to the bootrom file that worked with
> 5.0 and received the following:
> 
> Searching for server (DHCP)...
> ..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
> Laoding 192.168.2.6:/lts/bootrom ...(NBI)...............Unable to load file.
> <sleep>
> 
> I hope this helps.
> 
> BTW, the current cvs will not compile for me, it complains about a missing
> separator at Roms:370


The Roms file at least works for me. I just verified it.

O.k. Looking at bin32/3c509.tmp it lives from 0x20000 to 0x2d644.
So we do not have an overlap, of images.
I think tagged images worked for Ken, so it is probably not a tagged image, problem.
There are two problems
1) Etherboot doesn't think you have memory up to 0x940000
2) The bootrom image appears short, so load_kernel returns without doing anything.

I can think of two software possibilities.
1) I may be stressing your version of binutils and the compiler
   into compiling incorrect code.  If you could run
   ld --version and  gcc --version we can compare, I have:

   ld --version
   GNU ld version 2.12.90.0.9 20020526
   Copyright 2002 Free Software Foundation, Inc.
   This program is free software; you may redistribute it under the terms of
   the GNU General Public License.  This program has absolutely no warranty.
   
   gcc --version
   2.95.2

2) Etherboot appears to be incorrectly deteceting your available memory.
   At line 360 of osloader.c could you change.

	if (!fit) {
		printf("\nsegment [%X,%X) does not fit in any memory region\n",
			start, end);
-#if ELF_DEBUG
+#if 1
		printf("Memory regions(%d):\n", meminfo.map_count);
		for(i = 0; i < meminfo.map_count; i++) {
			unsigned long long r_start, r_end;
			if (meminfo.map[i].type != E820_RAM)
				continue;
			r_start = meminfo.map[i].addr;
			r_end = r_start + meminfo.map[i].size;
			printf("[%X%X, %X%X) type %d\n", 
				(unsigned long)(r_start >> 32),
				(unsigned long)r_start,
				(unsigned long)(r_end >> 32),
				(unsigned long)r_end,
				meminfo.map[i].type);
		}
#endif
		return 0;
	}

   This will report what memory etherboot thinks you do have available.  Which
   should at least explain why etherboot is complaining about using 0x92800 - 0x94000.

Eric