Re: [U-Boot] [PATCH v3] NET: add ENC28J60 driver using SPI framework
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
On Tuesday, September 21, 2010 01:21:46 Reinhard Meyer wrote:
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?
well, now i cant reproduce the issue, cold or warm booting :/. so i guess ignore this change until i can reproduce things and get a register dump.
although, earlier i was testing when the sun was out and shining on the board but now it's night, so maybe it's a cold-blooded part :x.
i looked at the linux driver again and i think i misread it. it isnt clearing ECON2 at reset, just when leaving low power mode. it clears ECON1 after doing a soft reset.
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).
the Blackfin timer is just fine thanks :P. it was pausing about 1 second between display of "enc0.18" and "CLKRDY timeout". it wasnt an instantaneous display of the two lines. -mike
Dear Mike Frysinger,
On Tuesday, September 21, 2010 01:21:46 Reinhard Meyer wrote: well, now i cant reproduce the issue, cold or warm booting :/. ... although, earlier i was testing when the sun was out and shining on the board but now it's night, so maybe it's a cold-blooded part :x.
Reminds me of the good old times with UV-Eraseable EPROMs, where a lab setup intermittently and mysteriously failed until I noticed it was the sun shining into the EPROM's windows. That did not erase them, just disturbed the reading.
Reinhard
Hi Mike,
On Mon, Sep 20, 2010 at 10:52 PM, Mike Frysinger vapier@gentoo.org wrote:
On Tuesday, September 21, 2010 01:21:46 Reinhard Meyer wrote:
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?
well, now i cant reproduce the issue, cold or warm booting :/. so i guess ignore this change until i can reproduce things and get a register dump.
although, earlier i was testing when the sun was out and shining on the board but now it's night, so maybe it's a cold-blooded part :x.
i looked at the linux driver again and i think i misread it. it isnt clearing ECON2 at reset, just when leaving low power mode. it clears ECON1 after doing a soft reset.
If you change your mind later, let me know and I'll squash this into the
earlier one.
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).
the Blackfin timer is just fine thanks :P. it was pausing about 1 second between display of "enc0.18" and "CLKRDY timeout". it wasnt an instantaneous display of the two lines. -mike
regards,
Ben
participants (3)
-
Ben Warren -
Mike Frysinger -
Reinhard Meyer