etherboot-developers

RE: [Etherboot-developers] Porting Linux 82547EI drivers to etherboot

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

> I get to:
> [E1000]The EEPROM Checksum Is Not Valid
> Probing isa nic...
> <sleep>
> 
> So, it looks like its failing during the probe.

Based on my experience with the 3c515 and a non ISAPNP Bios 486 (granted
a far cry from a gigabit card) I would try modifying the following code
in e1000_read_eeprom:

		while((!(eecd & E1000_EECD_GNT)) && (i < 100)) {
			i++;
-			udelay(5);
+			udelay(100);
			eecd = E1000_READ_REG(hw, EECD);
		}
Try incrementing the value till you hit 60000 or it works.  If you hit
60000 then try adding the DELAY function (see the beginning of the
3c515.c driver) and change the udelay to DELAY(1000) etc.

It may be a stupid idea, but as I found with the 3c515 lately, the eprom
was being read too fast and it produced incorrect data that caused the
checksum to fail

Tim

RE: [Etherboot-developers] Porting Linux 82547EI drivers to etherboot

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

> I think Tim has a strange clock problem.  That does not generally
affect
> the rest of us.  We need to get the delay routines fixed for Tim...

I think you are right Eric, Sorry for the wild ass guess Sam...

RE: [Etherboot-developers] Porting Linux 82547EI drivers to etherboot

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

> Based on my experience with the 3c515 and a non ISAPNP Bios 486
(granted
> a far cry from a gigabit card) I would try modifying the following
code
> in e1000_read_eeprom:
> 
> 		while((!(eecd & E1000_EECD_GNT)) && (i < 100)) {
> 			i++;
> -			udelay(5);
> +			udelay(100);
> 			eecd = E1000_READ_REG(hw, EECD);
> 		}
Actually the delay that might need to be adjusted could be in
e1000_shift_out_ee_bits.  Regardless, if it is a delay issue, try
increasing any of the udelays that are in the eprom reading code.  Bear
in mind, that this was the first five minutes I ever looked at the code!
;-)

Tim

RE: [Etherboot-developers] Porting Linux 82547EI drivers to etherboot

[Samuel C. <scl...@li...>]

>Actually the delay that might need to be adjusted could be in
>e1000_shift_out_ee_bits.  Regardless, if it is a delay issue, try
>increasing any of the udelays that are in the eprom reading code.  Bear
>in mind, that this was the first five minutes I ever looked at the code!
>;-)

Thanks for the input - I inserted the udelay increase, with the same 
results as before. I hunted for any other udelay that looked even remotely 
relevant to the EEPROM reading code and increased them too! I also added 
the DELAY (a la 3c515.c driver) and called it, with no difference in the 
end result (lots of pauses with the udelay increase(s) and lots of dots 
with the DELAY though...). Thinking its a problem at the checksum level, I 
changed it to:

if(checksum == checksum) (

thinking that would at least skip past it, I now get:
Ethernet addr: FF:FF:FF:FF:FF:FF
e1000: Hardware Initialization Failed

Don't know if that's even a bright thing to do, but there you have it.
   -Sam

Re: [Etherboot-developers] Porting Linux 82547EI drivers to etherboot

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

Samuel Clements <scl...@li...> writes:

> >Actually the delay that might need to be adjusted could be in
> >e1000_shift_out_ee_bits.  Regardless, if it is a delay issue, try
> >increasing any of the udelays that are in the eprom reading code.  Bear
> >in mind, that this was the first five minutes I ever looked at the code!
> >;-)
> 
> Thanks for the input - I inserted the udelay increase, with the same results as
> before. I hunted for any other udelay that looked even remotely relevant to the
> EEPROM reading code and increased them too! I also added the DELAY (a la 3c515.c
> 
> driver) and called it, with no difference in the end result (lots of pauses with
> 
> the udelay increase(s) and lots of dots with the DELAY though...). Thinking its
> a problem at the checksum level, I changed it to:

I think Tim has a strange clock problem.  That does not generally affect
the rest of us.  We need to get the delay routines fixed for Tim...
 
> if(checksum == checksum) (
> 
> thinking that would at least skip past it, I now get:
> Ethernet addr: FF:FF:FF:FF:FF:FF
> e1000: Hardware Initialization Failed
> 
> Don't know if that's even a bright thing to do, but there you have it.

Have you checked to see if what the latest linux driver does about reading
the serial eeprom?

The card initialization routines should be the same so should be able
to compare routing by routine to see what is going on.

Eric