etherboot-developers — Discussion of developer issues

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

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

Hi Eric

> I would start with memsizes.c
> The following patch should work around the immediate problem.

I applied both the pcbios patch and the the memsizes patch.  Now, I just
get:

Searching for server (DHCP)...
..Me:192.168.2.11, Server 192.168.2.6, Gateway 192.168.2.6
Loading 192.168.2.6:lts/vmlinuz-2.4.9-ltsp-5 ...(NBI)

It now freezes at this point, requiring a hard reboot.

Tim

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

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

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

> > The Roms file at least works for me. I just verified it.
> 
> Strange, I will try another update.
>  
> > 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
> 
> It seems that there is no comparison.  I am usin Mandrake kgcc
> 
> ld --version
> GNU ld 2.10.91
> Copyright 2000 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.
>   Supported emulations:
>    elf_i386
>    i386linux

This is probably o.k.  There is a bug fixed and I believe introduced
somewhere between 2.10 and 2.12.90.0.9 that puts junk at the end of
assembly files.   So be careful.  If you had earlier than 2.9 I might
worry but you are probably o.k.

> kgcc --version
> egcs-2.91.66

I would be surprised if the compiler version makes a difference.  
I use roughly the same compiler for compiling LinuxBIOS because
the later ones appear to introduce code bloat.

 
> > 2) Etherboot appears to be incorrectly deteceting your available memory.
> >    At line 360 of osloader.c could you change.
> 
> I receive 
> 
> Memory regions(32)

Ouch! The e820 map worked found 32 memory regions, none of them
with ram!

> I guess I should update my compiler etc.

Carefully.  At this point I think it is interesting information but
I wouldn't jump terribly fast.

I would start with memsizes.c
The following patch should work around the immediate problem.

A little more investigation is probably called for to see
what is actually in the returned e820 map.

void get_memsizes(void)
{
	int i;
+	int e820_ram;
	meminfo.basememsize = basememsize();
	meminfo.memsize = memsize();
	meminfo.map_count = meme820(meminfo.map, E820MAX);
+	e820_ram = 0;
+	for(i = 0; i < meminfo.map_count; i++) {
+		if (meminfo.map[i].type == E820_RAM) {
+			e820_ram = 1;
+			break;
+		} 
+	}
-	if (meminfo.map_count == 0) {
+	if (!e820_ram) {
		/* If we don't have an e820 memory map fake it */
		meminfo.map_count = 2;
		meminfo.map[0].addr = 0;
		meminfo.map[0].size = meminfo.basememsize << 10;
		meminfo.map[0].type = E820_RAM;
		meminfo.map[1].addr = 1024*1024;
		meminfo.map[1].size = meminfo.memsize << 10;
		meminfo.map[1].type = E820_RAM;
	}
	/* Allocate the real mode stack */
	real_mode_stack = (meminfo.basememsize << 10);
}

Eric

Re: [Etherboot-developers] eepro100 driver strange behaviour..

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

"atul srivastava" <atu...@re...> writes:

> since i amn't subscribed to list pls. cc any reply to me.

Once.  Are you running this on an embedded mips platform?
Normally traffic is kept on the list.

> I am trying to use etherboot for net booting using
> 82557 network card.
> 
> my driver is eepro100.c by R.E.wolff that is a scaled down version of donald
> becker one.
> this driver doesn't uses any interrupt and packet reception is polling driven.
> 
> resource assignment for pci base addreses are:
> 
> BAR0 - 0x60000000
> BAR1 - 0x18800001
> BAR2 - 0x62000000
> 
> these addresses are as per the mips idt manual.
> also virt_to_bus are confirmed to be o.k

Does your driver match the newest version in the development tree 5.1.2rc3?
Otherwise there is a missing virt_to_bus call.
 
> i am able to correctly read MAC address for card.
> 
> also packet reception is o.k , so the pci bus to memory trasaction is taking
> place.
> 
> my problem is in packet trasmission i should get txfd.status to become  nonzero
> for indicating packet trasfer has happened but it never happens and my driver
> hangs there for ever.
> 
> when debugged i saw from very begining status as 0090
> .
> 
> as per eepro manual status 0090 indicates "NO RESOURCE"
> 
> but i am unable to conclude what it means..
> 
> can any body help..?

Of the top of my head I would say it is the missing virt_to_bus call
in the stable version of the tree.

Eric

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

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

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

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

Tim





> -----Original Message-----
> From: eth...@li...
> [mailto:eth...@li...]On Behalf Of
> Eric W Biederman
> Sent: Tuesday, August 27, 2002 2:52 PM
> To: Etherboot Developers
> Cc: Timothy Legge
> Subject: Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.
>
>
> "Timothy Legge" <tl...@ro...> writes:
>
> > Hi
> >
> > > Which rom image did you build?
> >
> > I built both the 3c515 and  the 3c509.  This morning I verified
> that neither
> > the 3c515 or the 3c509 driver gets past:
> >
> > .000041.0000 done
> > R
>
> Compressed? or Uncompressed.
>
> That message does not seem at all familiar, so if you could give some
> more boot context.  Console dump from a serial port perhaps,
> it would really help.
>
> > on my old 486.  I will have to pull the 3c515 and toss it in
> the Pentium PC
> > (the one that reported the error:
> >
> > segment [00092800,00094000) does not fit in any memory region
>
> Again I don't have enough context to do anything with just that message.
> But it would have take a fairly large image to make that work.
>
> Eric
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

Re: [Etherboot-developers] multicast

[Ronald G M. <rmi...@la...>]

I basically agree with you, I like multicast ...

I think one reason was that myrinet does not do it well :-)

ron

Re: [Etherboot-developers] multicast

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

Ronald G Minnich <rmi...@la...> writes:

> FYI, Erik hendriks (here) just REMOVED multicast support from his beoboot
> code. There were just enough problems with switches etc. that in the end
> he decided it was a net loss performance-wise.
> 
> This may or may not affect what you want to do with multicast.

Hmm. I hadn't realized this was on the list.  A little more general
answer then.

For most drivers opening up the nic level filter to accept multicast
packets is about 2 or 3 lines of code.  So it is worth writing the code,
and setting the precedent even if multicast booting does not prove
a general purpose win.  Except for those 2 or 3 lines there is no overhead
for a multicast capable etherboot if you don't compile in the support.

As for how worthwhile the project is.  I coded the support after watching
the unicast traffic for booting several hundred computers simultaneously
be a human visble bottleneck.  Taking something like 15minutes and with atftp-0.3
showing up in top.

Beyond that we will be running a full scale test on MCR a 1000 node
cluster, in a couple of weeks, and I can give a report on how useful
it is.  So far all I have heard is, that it works and is boring.  I
don't plan to reevaluate that until 

To date I have not encoutered any fatal switch problems, and requesting
that switches that work on a large cluster where it is needed is not a
real problem.  When I use multicast I would be perfectly happy to use
broadcast,  the multicast is just a hint to the hardware to not send
the packets to everyone. 

Finally what was Erik doing that made multicast support less
performant than unicast?  Did he have a bad retransmission algorithm?
Even in the case the switch drops 50% of the packets, if you have 3
receivers for the same data you have gained performance.  Unless the
multicast traffic is jamming up your network between nodes doing other
things, in which case multicast is quite definitely not the tool for
the job.

Eric

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

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

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

> >O.k.  The BIOS based currticks is definitely bugging in the
> >presence of relocation.  The absolute BIOS addresses are not
> >fixed up, so if any amount of relocation is applied the will
> >read the wrong address.
> 
> Ok, that fix works, thanks. 

Welcome, then I will get that change committed.

> And the .lzrom version has no problem with loading to 0x20000. 

You might want to try the .nrv2brom variant as well.  I probably
should just totally switch so we don't have an excess of compressors,
something else to do before 5.2.

> The 3c509 is a nice card to start with as it only uses I/O instructions. 

O.k.  So the 3c509 is done. Cool.

> There is a small glitch though. After the second
> bootloader runs, sometimes it's unable to find the NIC the next time
> around and has to wait for a full reset.

Ouch.  I wonder what causes that.  I'm pretty certain the init path
didn't change.
 
> Slightly related, but in main.c there's a static int card_retries = 0
> which will not be reset by a longjmp. Probably needs to be made
> non-static and (re)set to 0 during initialisation.

Probably correct.  That piece hasn't changed since 5.0.  Basically
all it does is give an increasingly longer timeout every time it
is hit, so it shouldn't be a correctness problem.

Eric

Re: [Etherboot-developers] Multiple drivers

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

Michael Brown <mb...@fe...> writes:

> On Tue, 27 Aug 2002, Ken Yap wrote:
> > >Any way to get eb 5.07 to try multiple drivers?  I have a lab of crap
> > >computers, and it would be great to make a boot disk that had 5 or 6
> > >etherboot nic drivers that it could try to load.
> > Make a LILO floppy that will allow you to choose from a selection of
> > drivers.
> > Discussion redirected to users list where it belongs.
> 
> It is also possible with EB 5.0.7 to have multiple drivers in a single
> image.  For example:
> 
>   make bin32/rtl8139--prism2_pci.lzrom
> 
> will give you a ROM image that has rtl8139 and prism2_pci drivers, with
> the PCI IDs of an RTL8139 card.
> 
> Be warned that you are likely to run out of memory with >2 drivers.
> Symptoms will be seemingly random reboots.  Eric's memory allocation code
> in the 5.1.x branch fixes this problem, AFAIK.

To be clear it is the fact that 5.1.x isn't constrained to live in 64K
that fixes this problem.  The memory allocator is useful for those for those
cases where static allocation won't work.

Eric

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

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

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

> Hi
> 
> > Which rom image did you build?
> 
> I built both the 3c515 and  the 3c509.  This morning I verified that neither
> the 3c515 or the 3c509 driver gets past:
> 
> .000041.0000 done
> R

Compressed? or Uncompressed.

That message does not seem at all familiar, so if you could give some
more boot context.  Console dump from a serial port perhaps,
it would really help.
 
> on my old 486.  I will have to pull the 3c515 and toss it in the Pentium PC
> (the one that reported the error:
> 
> segment [00092800,00094000) does not fit in any memory region

Again I don't have enough context to do anything with just that message.
But it would have take a fairly large image to make that work.

Eric

[Etherboot-developers] Re: Possibly [PRISM] driver limitation?

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

On Tue, 27 Aug 2002, Boris Reisig wrote:
> Today I have been doing a bunch of tests. My test machine has 128mb of
> RAM and I was testing different size images and different network
> card/drivers to check for problems. Here are the results
> Realtek 8139 card with rtl8139 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb, 16.2mb, 15.2mb image files all booted OK.
> Realtek 8029 card with rtl8029 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb, 16.2mb, 15.2mb image files all booted OK also.
> Dlink DWL-520 with PRISM driver: 43mb failed, 20mb failed, 19.3mb ok, 19.1mb ok, 17.6mb,16.2mb ok, 15.2mb ok.
> It seems their seems to be a limitation in file size in the PRISM
> driver. Somewhere between 19.3mb-20mb's, the driver cannot allocate
> space or initialize the data from the image file. Hopefully we could
> fix this issue? [sooner the better..hehehe]

I'll help where I can, but I don't see this as an urgent problem - why
would you want to transfer images of 20MB and more anyway, particularly
over a slow wireless link?

Michael Brown
http://www.fensystems.co.uk

[Etherboot-developers] Possibly [PRISM] driver limitation?

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

Today I have been doing a bunch of tests. My test machine has 128mb of RAM and I was testing different size images and different network card/drivers to check for problems. Here are the results

Realtek 8139 card with rtl8139 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb, 16.2mb, 15.2mb image files all booted OK.
Realtek 8029 card with rtl8029 driver: 43mb,20mb, 19.3mb, 19.1mb, 17.6mb, 16.2mb, 15.2mb image files all booted OK also.
Dlink DWL-520 with PRISM driver: 43mb failed, 20mb failed, 19.3mb ok, 19.1mb ok, 17.6mb,16.2mb ok, 15.2mb ok.


It seems their seems to be a limitation in file size in the PRISM driver. Somewhere between 19.3mb-20mb's, the driver cannot allocate space or initialize the data from the image file. Hopefully we could fix this issue? [sooner the better..hehehe]

[Etherboot-developers] Re: multicast

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

Ronald G Minnich <rmi...@la...> writes:

> FYI, Erik hendriks (here) just REMOVED multicast support from his beoboot
> code. There were just enough problems with switches etc. that in the end
> he decided it was a net loss performance-wise.
> 
> This may or may not affect what you want to do with multicast.

We have to uses a full install, and booting.  For booting except
on a large system it isn't very significant as the files are generally
small.  For booting you start to notice a scalability limit somewhere
around 200+ nodes, at which point you need another server, patience or
multicast support.

For a full install multicast is very helpful.  For the MCR FSU (96
nodes) we can do a full install on all of the nodes in something like
twice the time it takes to do a full install on 1 node.  So about 10
minutes.   And I expect the numbers will hang in somewhere around
there for the whole cluster. 

Right now, getting work arounds for all of the hardware defects, and
LinuxBIOS bugs is the priority so we can reboot the FSU and have the
majority of the nodes come back up.

Eric

[Etherboot-developers] eepro100 and 5.0.7

[Ronald G M. <rmi...@la...>]

I have a digital logic smartcore p3 running linuxbios, and am having
troubles with the eepro100.

What happens: packets make it out just find, but the hardware status
doesn't seem to indicate that. Specifically, s1 and s2 at the end of
eepro100_transmit are always 0. So it seems that commands to the chip
mostly work (packets get out) but I/o status is wrong.

Any hints welcome ...

ron

Re: [Etherboot-developers] Multiple drivers

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

On Tue, 27 Aug 2002, Ken Yap wrote:
> >Any way to get eb 5.07 to try multiple drivers?  I have a lab of crap
> >computers, and it would be great to make a boot disk that had 5 or 6
> >etherboot nic drivers that it could try to load.
> Make a LILO floppy that will allow you to choose from a selection of
> drivers.
> Discussion redirected to users list where it belongs.

It is also possible with EB 5.0.7 to have multiple drivers in a single
image.  For example:

  make bin32/rtl8139--prism2_pci.lzrom

will give you a ROM image that has rtl8139 and prism2_pci drivers, with
the PCI IDs of an RTL8139 card.

Be warned that you are likely to run out of memory with >2 drivers.
Symptoms will be seemingly random reboots.  Eric's memory allocation code
in the 5.1.x branch fixes this problem, AFAIK.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] Wireless [D-LINK 520] problems

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

On Mon, 26 Aug 2002, Markus Gutschke wrote:
> > 2) It starts loading the image but it seems after about 20+mbs of
> > loading, The following errors occur and it wont recover. I have to hit
> > the ESCAPE key and then it trys reloading the image again but does the
> > same thing over and over but at different spots. Here are the errors.
> > Hfa384x: Tx FID allocate command failed: Aborting Transmit.
> > Hfa384x: Tx FID allocate command failed: Aborting Transmit.
> > Copy_form_bap(0x0282,0x003c,86) failed. Result=0x403c
> > Copy_form_bap(0x0282,0x003c,86) failed. Result=0x403c
> > Copy_form_bap(0x0282,0x003c,226) failed. Result=0x403c
> The image that we booted at LinuxExpo was considerably smaller than this
> (just a kernel and the LTSP initial ram disk). So, I am afraid I won't
> be able to be of much help.

Yes, it does sound as though the image may be too large.

I don't really know how the wireless drivers work in any great detail; I
reverse-engineered them from the Linux kernel drivers.  Basically, I
traced all the function calls within the drivers and used the trace to
reconstruct the sequence of operations necessary in order to initialise,
transmit, receive etc.  It's quite possible that I missed out freeing a
resource somewhere, in which case a large image could hit a resource
allocation limit that smaller images just don't trigger.

Michael Brown
http://www.fensystems.co.uk

[Etherboot-developers] eepro100 driver strange behaviour..

[atul s. <atu...@re...>]

since i amn't subscribed to list pls. cc any reply to me.

I am trying to use etherboot for net booting using
82557 network card.

my driver is eepro100.c by R.E.wolff that is a scaled down version 
of donald becker one.
this driver doesn't uses any interrupt and packet reception is 
polling driven.

resource assignment for pci base addreses are:

BAR0 - 0x60000000
BAR1 - 0x18800001
BAR2 - 0x62000000

these addresses are as per the mips idt manual.
also virt_to_bus are confirmed to be o.k

i am able to correctly read MAC address for card.

also packet reception is o.k , so the pci bus to memory trasaction 
is taking place.

my problem is in packet trasmission i should get txfd.status to 
become  nonzero for indicating packet trasfer has happened but it 
never happens and my driver hangs there for ever.

when debugged i saw from very begining status as 0090
.

as per eepro manual status 0090 indicates "NO RESOURCE"

but i am unable to conclude what it means..

can any body help..?

Best Regards,



__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/

[Etherboot-developers] eepro100 driver strange behaviour..

[atul s. <atu...@re...>]

I am trying to use etherboot for net booting using
82557 network card.

my driver is eepro100.c by R.E.wolff that is a scaled down version 
of donald becker one.
this driver doesn't uses any interrupt and packet reception is 
polling driven.

resource assignment for pci base addreses are:

BAR0 - 0x60000000
BAR1 - 0x18800001
BAR2 - 0x62000000

these addresses are as per the mips idt manual.
also virt_to_bus are confirmed to be o.k

i am able to correctly read MAC address for card.

also packet reception is o.k , so the pci bus to memory trasaction 
is taking place.

my problem is in packet trasmission i should get txfd.status to 
become  nonzero for indicating packet trasfer has happened but it 
never happens and my driver hangs there for ever.

when debugged i saw from very begining status as 0090
.

as per eepro manual status 0090 indicates "NO RESOURCE"

but i am unable to conclude what it means..

can any body help..?

Best Regards,



__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/

[Etherboot-developers] multicast

[Ronald G M. <rmi...@la...>]

FYI, Erik hendriks (here) just REMOVED multicast support from his beoboot
code. There were just enough problems with switches etc. that in the end
he decided it was a net loss performance-wise.

This may or may not affect what you want to do with multicast.

ron

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

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

>O.k.  The BIOS based currticks is definitely bugging in the
>presence of relocation.  The absolute BIOS addresses are not
>fixed up, so if any amount of relocation is applied the will
>read the wrong address.

Ok, that fix works, thanks. And the .lzrom version has no problem with
loading to 0x20000. The 3c509 is a nice card to start with as it only
uses I/O instructions. There is a small glitch though. After the second
bootloader runs, sometimes it's unable to find the NIC the next time
around and has to wait for a full reset.

Slightly related, but in main.c there's a static int card_retries = 0
which will not be reset by a longjmp. Probably needs to be made
non-static and (re)set to 0 during initialisation.

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

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

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

> >Was it a compressed rom image?
> 
> Yes.
> 
> >At the moment I would only expect non-compressed images which still
> >run at RELOCADDR to work reliably.  The compressed case relies on
> >being relocatable, and decompreses from RELOCADDR to a little further
> >down.   
> 
> Ok, a .rom image works, but unfortunately it can't load the NFL menu
> which uses 0x20000 also. Which would also be a problem for zImage
> kernels. I thought you were going to relocate Etherboot to the top of
> the 32-bit address space?

Right the code is there to do that but it takes a while to weed
out the dependencies on code that uses absolute addresses.  0x20000 is
just the initial load address. 

If you specify -DRELOCATE etherboot will relocate itself up to the top
of memory.  I have just left the default set so people can build
drivers and then see if there are relocation fixes that must be
handled.

Relocation fixes.  Mostly it is a matter of adding:
virt_to_bus, bus_to_virt, and ioremap in the drivers.
In some of the other code calling  phys_to_virt, and virt_to_phys
are appropriate.

For the most part the pointers just need to be fixed up and the code
will work.  Straight forward but work that needs to be done a small
piece at a time.

We should probably compile a list of drivers that have not
yet been converted to work when relocated.  Then walk through fixing
and testing them.  I'd like to add the ability to test multicast at
the same time so my next generic step will be to get the multicast
sever going.  Then I can convert as many drivers as possible, but I
don't have a lot of the hardware so there are a lot of cases I can't
test.

If you can think of a better way to handle it.  I am all ears.

Eric

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

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

>Was it a compressed rom image?

Yes.

>At the moment I would only expect non-compressed images which still
>run at RELOCADDR to work reliably.  The compressed case relies on
>being relocatable, and decompreses from RELOCADDR to a little further
>down.   

Ok, a .rom image works, but unfortunately it can't load the NFL menu
which uses 0x20000 also. Which would also be a problem for zImage
kernels. I thought you were going to relocate Etherboot to the top of
the 32-bit address space?

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

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

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

> ke...@us... (Ken Yap) writes:
> 
> > >I got a bit further than you. I'm using a 3c509.  I got my Etherboot ROM
> > >to load another ROM image and that worked, the 5.1.2rc3 image started
> > >executing, and prompted me for N or L. I chose N and it said Probing
> > >pci, no BIOS32\n Probing isa...[3c5x9] blah blah, and then froze after
> > >printing the MAC address.
> > 
> > Oh and the 3 second timeout didn't work so the PCBIOS timer is probably
> > not working. That may be the same reason for the freeze actually.
> 
> Hmm?  3 second timeout.

Eric the ASK_BOOT=3 timeout.   I usually set it to 1, and forgot
the default was 3.  So the BIOS based currticks is running at the
wrong speed, interesting.  Given that you chose N I assume it was
running slow? 

O.k.  A slow timer would certain give a freeze.

Sounds like I made a small bug in pcbios.S

Looking at the code....

O.k.  The BIOS based currticks is definitely bugging in the
presence of relocation.  The absolute BIOS addresses are not
fixed up, so if any amount of relocation is applied the will
read the wrong address.

Please, Please, Please when testing the new etherboot tell me if
what image you are testing.  And if you can test the non relocated
case.  I suspect there will be a bazillion little bugs when etherboot
is running relocated that is going to take a while to track down.

That is the big hunt before 5.2.

Anyway I believe the untested patch below should fix the timer
problem.

Eric


/**************************************************************************
CURRTICKS - Get Time
Use direct memory access to BIOS variables, longword 0040:006C (ticks
today) and byte 0040:0070 (midnight crossover flag) instead of calling
timeofday BIOS interrupt.
**************************************************************************/
	.globl	currticks
currticks:
	pushl	%ebp
	pushl	%ebx
	pushl	%esi
	pushl	%edi
#ifdef FREEBSD_PXEEMU
	cmpb	$0, pxeemu_nbp_active
	jne	currticks_postswitch
#endif

	pushl	$ 10f
	pushl	$ 20f - 10f
	call	_real_call
	.section ".text16"
10:	.code16
	ret
20:	.code32
	.previous

#ifdef FREEBSD_PXEEMU
currticks_postswitch:
#endif
-	movl	0x46C, %eax
-	movb	0x470, %bl
+       movl    virt_offset, %ebp
+       negl	%ebp			/* Physical address 0 */
+	movl    0x46C(%ebp), %eax
+	movb    0x470(%ebp), %bl
	cmpb	$0, %bl
	je	notmidnite
-	movb	$0, 0x470		/* clear the flag */
+	movb    $0, 0x470(%ebp)		/* clear the flag */
	addl	$0x1800b0,days		/* 0x1800b0 ticks per day */
notmidnite:
	addl	days,%eax
	popl	%edi
	popl	%esi
	popl	%ebx
	popl	%ebp
	ret

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

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

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

> >I got a bit further than you. I'm using a 3c509.  I got my Etherboot ROM
> >to load another ROM image and that worked, the 5.1.2rc3 image started
> >executing, and prompted me for N or L. I chose N and it said Probing
> >pci, no BIOS32\n Probing isa...[3c5x9] blah blah, and then froze after
> >printing the MAC address.
> 
> Oh and the 3 second timeout didn't work so the PCBIOS timer is probably
> not working. That may be the same reason for the freeze actually.

Hmm?  3 second timeout.

Was it a compressed rom image?

At the moment I would only expect non-compressed images which still
run at RELOCADDR to work reliably.  The compressed case relies on
being relocatable, and decompreses from RELOCADDR to a little further
down.   

Eric

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

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

>I got a bit further than you. I'm using a 3c509.  I got my Etherboot ROM
>to load another ROM image and that worked, the 5.1.2rc3 image started
>executing, and prompted me for N or L. I chose N and it said Probing
>pci, no BIOS32\n Probing isa...[3c5x9] blah blah, and then froze after
>printing the MAC address.

Oh and the 3 second timeout didn't work so the PCBIOS timer is probably
not working. That may be the same reason for the freeze actually.