[U-Boot] [PATCH v3] NET: add ENC28J60 driver using SPI framework

Reinhard Meyer u-boot at emk-elektronik.de
Tue Sep 21 07:21:46 CEST 2010


Dear Mike Frysinger,
> On Monday, September 20, 2010 17:44:38 Mike Frysinger wrote:
>> finally got around to testing this.  seems like the init needs some work.
>> if i power on the system (cold boot), boot Linux over the on-chip mac, and
>> let Linux program the enc part, it works fine under Linux.  then i do a
>> software reset back into u-boot, it can use the enc fine too.
>>
>> but if i cold boot u-boot and try to use the enc part, i get:
>> 	timeout waiting for CLKRDY
>> enabling DEBUG doesnt show any additional output though.
>
> comparing the linux and u-boot drivers leads me to this fix:
>
> --- a/drivers/net/enc28j60.c
> +++ b/drivers/net/enc28j60.c
> @@ -632,6 +632,8 @@ static int enc_clock_wait(enc_dev_t *enc)
>   {
>   	uint64_t etime;
>
> +	enc_bclr(enc, CTL_REG_ECON2, ENC_ECON2_PWRSV);
> +
>    	/* one second timeout */
>   	etime = get_ticks() + get_tbclk();

The Bit PWRSV is cleared (according to data sheet) on every Reset.
If that patch really helps in your case either the data sheet is wrong
(for your mask of the chip) OR there is another reason while the timeout
occurs in your case (I never had this timeout).

I don't mind explicitly clearing this bit, but I suspect that this just
covers another problem.

Could you read and print ECON2 in your case and see if PWRSV is really set?

Or, does the timeout really come to be 1 second - does get_tbclk()
really return the timer increments per second? On many architectures
get_tblck() simply returns CONFIG_SYS_HZ and not the number of timer
increments per second (which can be a different and much higher value).

Best Regards
Reinhard


More information about the U-Boot mailing list