[U-Boot] building enc28j60 for omap3: undefined references

[U-Boot] building enc28j60 for omap3: undefined references

[jacopo mondi]

Hi all,
I'm trying enabling enc2j60 in order to use tftp with SPI-Ethernet
enc28j60 and beagleboard rev C3.
When building u-boot some functions referred by enc28j60.c remain
undefined.

drivers/net/libnet.o: In function `enc28j60_initialize':
u-boot/drivers/net/enc28j60.c:973:
undefined reference to `eth_register' drivers/net/libnet.o: In function
`enc_receive': u-boot/drivers/net/enc28j60.c:489:
undefined reference to `NetReceive' drivers/net/libnet.o: In function
`enc_recv': u-boot/drivers/net/enc28j60.c:868:
undefined reference to `NetRxPackets'

Driver gets compiled and linked without warnings nor errors:

arm-angstrom-linux-gnueabi-gcc  -g  -Os   -fno-common -ffixed-r8
-msoft-float   -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80008000
-Iu-boot/include -fno-builtin
-ffreestanding -nostdinc
-isystem cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/4.3.1/include
-pipe  -DCONFIG_ARM -D__ARM__ -marm  -mabi=aapcs-linux
-mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes
-fno-stack-protector   -o enc28j60.o enc28j60.c -c
arm-angstrom-linux-gnueabi-ld  -r -o libnet.o  enc28j60.o

I'm using last u-boot, cloned from master branch yesterday.
Is my toolchain broken?

thank you
	j

[U-Boot] building enc28j60 for omap3: undefined references

[Reinhard Meyer]

Dear jacopo mondi,
> Hi all,
> I'm trying enabling enc2j60 in order to use tftp with SPI-Ethernet
> enc28j60 and beagleboard rev C3.
> When building u-boot some functions referred by enc28j60.c remain
> undefined.
>
> drivers/net/libnet.o: In function `enc28j60_initialize':
> u-boot/drivers/net/enc28j60.c:973:
> undefined reference to `eth_register' drivers/net/libnet.o: In function
> `enc_receive': u-boot/drivers/net/enc28j60.c:489:
> undefined reference to `NetReceive' drivers/net/libnet.o: In function
> `enc_recv': u-boot/drivers/net/enc28j60.c:868:
> undefined reference to `NetRxPackets'
...
>
> I'm using last u-boot, cloned from master branch yesterday.
> Is my toolchain broken?

Not sure, the driver builds fine with ARM boards.
Maybe you need to have CONFIG_NET_MULTI set?

Best Regards,
Reinhard

[U-Boot] building enc28j60 for omap3: undefined references

[Mike Frysinger]

On Wednesday, February 16, 2011 12:31:23 Reinhard Meyer wrote:
> Dear jacopo mondi,
> > I'm using last u-boot, cloned from master branch yesterday.
> > Is my toolchain broken?
> 
> Not sure, the driver builds fine with ARM boards.

and Blackfin boards.  btw, not sure if i said this before, but good job with 
the updated enc2j60 net driver.  it rox teh sox.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110217/983b4de4/attachment.pgp 

[U-Boot] building enc28j60 for omap3: undefined references

[jacopo mondi]

On Wed, 16 Feb 2011 18:31:23 +0100
Reinhard Meyer <u-boot@emk-elektronik.de> wrote:
> 
> Not sure, the driver builds fine with ARM boards.
> Maybe you need to have CONFIG_NET_MULTI set?
> 
> Best Regards,
> Reinhard
Yes, I have CONFIG_NET_MULTI (mainly I've taken those entries from
top900 and lpc2292 configs).
That's how I enabled enc

/*ethernet*/
#define CONFIG_NET_MULTI
#define CONFIG_NET_RETRY_COUNT	20
/*network*/
#define CONFIG_ENC28J60
#define ENC_SPI_BUS		4
#define ENC_CS_NUM		0
#define ENC_SPI_CLOCK 25000000	
/*ip configuration*/
#define CONFIG_SERVERIP 192.168.5.5
#define CONFIG_IPADDR 192.168.5.1

libnet.o seems to be an architecture independent abstraction anyway,
but the problem is related to that...

Thank you
	j

[U-Boot] building enc28j60 for omap3: undefined references

[Stefano Babic]

On 02/16/2011 06:31 PM, Reinhard Meyer wrote:

>> I'm using last u-boot, cloned from master branch yesterday.
>> Is my toolchain broken?
> 
> Not sure, the driver builds fine with ARM boards.
> Maybe you need to have CONFIG_NET_MULTI set?

And the driver builds fine with beagleboard, too. Do you drop the

#undef CONFIG_CMD_NET

in the beagleboard configuration file ? If not, this generates exactly
the error you report.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] building enc28j60 for omap3: undefined references

[jacopo mondi]

On Thu, 17 Feb 2011 11:09:04 +0100
Stefano Babic <sbabic@denx.de> wrote:

> And the driver builds fine with beagleboard, too. Do you drop the
> 
> #undef CONFIG_CMD_NET
> 
> in the beagleboard configuration file ? If not, this generates exactly
> the error you report.
> 
> Best regards,
> Stefano Babic
> 

GOSH, I've exactly searched through the code for CONFIG_CMD_NET, but I
did not noticed was an undef statment instead of a define!
Everything's fine now. Thank you.

Just another question. I've studied the linux enc28j60 driver and
noticed it features an interrupt driven work flow.
No interrupt are used in u-boot version (for what I've seen). Is it
based on some sort of polling instead of interrupt? Isn't
that dangerous? I mean, if there are no data available everything is
going to freeze..

Thank you all
	jacopo

[U-Boot] building enc28j60 for omap3: undefined references

[Stefano Babic]

On 02/17/2011 11:48 AM, jacopo mondi wrote:
> GOSH, I've exactly searched through the code for CONFIG_CMD_NET, but I
> did not noticed was an undef statment instead of a define!
> Everything's fine now. Thank you.

Your're welcome.

> 
> Just another question. I've studied the linux enc28j60 driver and
> noticed it features an interrupt driven work flow.
> No interrupt are used in u-boot version (for what I've seen).

That is correct. As u-boot is a bootloader and no os, everything can be
done in a single task and polling is used when it is needed.

> Is it
> based on some sort of polling instead of interrupt? Isn't
> that dangerous? I mean, if there are no data available everything is
> going to freeze..

It seems to me that the driver goes out from receive function when no
data are available. pkn_cnt is read directly from HW, and if the
controller is not broken, it will not return any packets and the loop
ends up.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] building enc28j60 for omap3: undefined references

[jacopo mondi]

On Thu, 17 Feb 2011 13:37:27 +0100
Stefano Babic <sbabic@denx.de> wrote:
> It seems to me that the driver goes out from receive function when no
> data are available. pkn_cnt is read directly from HW, and if the
> controller is not broken, it will not return any packets and the loop
> ends up.
>
You are right..
 
> Best regards,
> Stefano Babic
> 
As said I'm trying to enable enc28j60 in beagle C4.
The device did not gets initialized because in eth.c, the
board_eth_init function is defined as __def_eth_init through an
__attribute__ weak statements (always return -1).

This is because in board/ti/beagle.c no board_eth_init function is
defined and libbeagle.o is not linked to libnet.o (where board_eth_init
gets called).
My question: have I to implement that function myself? Is it worth to
introduce a new #define statements in omap3_beagle.h that enables the
function in board specific file? I will be happy to do so, if it's
worth (I'm looking at top900 board specific file as an example).

Thank you

[U-Boot] building enc28j60 for omap3: SILICON ERRATA

[jacopo mondi]

On Wed, 16 Feb 2011 18:31:23 +0100
Reinhard Meyer <u-boot@emk-elektronik.de> wrote:
> 
> Not sure, the driver builds fine with ARM boards.
> Maybe you need to have CONFIG_NET_MULTI set?
> 
> Best Regards,
> Reinhard

I've continued working on enc28j60 in those days, trying to make it
finally work with my beagle.
Stefano confirmed it works 'out of the box' (if I understood
correctly), but I'm experiencing some problems.

The first one is related to an ENC28J60 silicon errata (revision B5,
issue number 1).
It happens that the driver hangs waiting for CLKRDY becoming ready
(enc_clock_wait function).
That test is not relevant, since after a soft reset CLKRDY
bit is not cleared. I can submit a patch, but is a question of simply
waiting for more than 1ms instead of polling on that bit (that's what
the errata says).

Second issue is related to enc identification.
The following code section:

	phid1 = phy_read(enc, PHY_REG_PHID1);
	phid2 = phy_read(enc, PHY_REG_PHID2) & ENC_PHID2_MASK;
	if (phid1 != ENC_PHID1_VALUE || phid2 != ENC_PHID2_VALUE) {
		printf("%s: failed to identify PHY. Found
		%04x:%04x\n",			enc->dev->name,
		phid1, phid2);
	 return -1;
	}

fails because phy_read instructions return 0 or random values (0xB0B0
or 0xB000).
Linux driver does not perform such tests, so I've tried removing them.
Anyway all read and write to enc fails.
Could that be related to omap3_spi implementation?

I can confirm that same same board I'm using for test works great
under Linux, so it is not an hardware issue.

Thank you
	jacopo

[U-Boot] building enc28j60 for omap3: SILICON ERRATA

[Anatolij Gustschin]

Hi,

On Tue, 22 Feb 2011 17:34:30 +0100
jacopo mondi <j.mondi@voltaelectronics.com> wrote:
...
> Second issue is related to enc identification.
> The following code section:
> 
> 	phid1 = phy_read(enc, PHY_REG_PHID1);
> 	phid2 = phy_read(enc, PHY_REG_PHID2) & ENC_PHID2_MASK;
> 	if (phid1 != ENC_PHID1_VALUE || phid2 != ENC_PHID2_VALUE) {
> 		printf("%s: failed to identify PHY. Found
> 		%04x:%04x\n",			enc->dev->name,
> 		phid1, phid2);
> 	 return -1;
> 	}
> 
> fails because phy_read instructions return 0 or random values (0xB0B0
> or 0xB000).
> Linux driver does not perform such tests, so I've tried removing them.

No, please do not remove them. Fix the register access
problem instead.

> Anyway all read and write to enc fails.
> Could that be related to omap3_spi implementation?

Yes. If you use the omap3_spi driver in current mainline tree,
then definitely the omap3_spi driver is the problem. enc28j60
register and buffer access can not work with this current driver
version.

We experienced problems with enc28j60 register access on a iMX31
based board as there were among other things some byte order issues
in the spi driver. When using spi clock above 2 MHz we also have
seen seemingly random data when reading the enc registers. Be aware
that there are two kinds of spi transfers for enc register access:
two bytes long transfers and three bytes long transfers with a dummy
byte. The spi chip select signal have to be active as long as
these tx/rx transfers didn't completed and may not be deactivated
in between. Also the spi transfer is full-duplex for enc28j60
register and buffers access. With a properly working spi driver
the enc28j60 driver in U-Boot works well.
 
> I can confirm that same same board I'm using for test works great
> under Linux, so it is not an hardware issue.

This is the omap3_spi driver issue. You can apply the attached
patch for enc28j60 driver to be able to start single register
accesses on the U-Boot command line. Then you can start fixing
the spi driver code. Implement fixes in the spi driver and test
the register access using the enc commands added by the path.

You will have to implement the Master Transmit-Receive Mode
(full-duplex) in the omap3_spi driver for proper enc28j60 register
and buffer access. Currently this driver is using Tx-Only Mode
for transmitting a Rx-Only Mode for receiving. But it shouldn't
be too hard to fix the spi driver. What is needed is a kind
of merge of omap3_spi_read/omap3_spi_write routines.

HTH
Anatolij
-------------- next part --------------
A non-text attachment was scrubbed...
Name: commands-for-ENC28J60-SPI-register-access-tests.patch
Type: text/x-patch
Size: 2008 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110223/cccdd98d/attachment.bin 

[U-Boot] building enc28j60 for omap3: SILICON ERRATA

[Wolfgang Denk]

Dear Anatolij Gustschin,

In message <20110223233201.09aee7e4@wker> you wrote:
>
> No, please do not remove them. Fix the register access
> problem instead.
> 
> > Anyway all read and write to enc fails.
> > Could that be related to omap3_spi implementation?
> 
> Yes. If you use the omap3_spi driver in current mainline tree,
> then definitely the omap3_spi driver is the problem. enc28j60
> register and buffer access can not work with this current driver
> version.

There might also be other issues.

The omap3_spi driver was one of those affected by the bug fixed in
commit 495df3b "ARM: fix write*() I/O accessors", see
http://patchwork.ozlabs.org/patch/82841/

This is fixed in mainline now, so it might be wise to update the code
base and just try again.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
On the subject of C program indentation: "In My Egotistical  Opinion,
most  people's  C  programs  should be indented six feet downward and
covered with dirt."                               - Blair P. Houghton

[U-Boot] building enc28j60 for omap3: SILICON ERRATA

[jacopo mondi]

On Wed, 23 Feb 2011 23:32:01 +0100
Anatolij Gustschin <agust@denx.de> wrote:

> You will have to implement the Master Transmit-Receive Mode
> (full-duplex) in the omap3_spi driver for proper enc28j60 register
> and buffer access. Currently this driver is using Tx-Only Mode
> for transmitting a Rx-Only Mode for receiving. But it shouldn't
> be too hard to fix the spi driver. What is needed is a kind
> of merge of omap3_spi_read/omap3_spi_write routines.
> 
> HTH
> Anatolij
Thank you Anatolij, I'm reading OMAP datasheet in these days...
Hope I'll provide something during next week.

[U-Boot] building enc28j60 for omap3: (omap3_spi rxtx)

[jacopo mondi]

On Wed, 23 Feb 2011 23:32:01 +0100
Anatolij Gustschin <agust@denx.de> wrote:

> Hi,
> 
> On Tue, 22 Feb 2011 17:34:30 +0100
> jacopo mondi <j.mondi@voltaelectronics.com> wrote:
> ...
> > Second issue is related to enc identification.
> > The following code section:
> > 
> > 	phid1 = phy_read(enc, PHY_REG_PHID1);
> > 	phid2 = phy_read(enc, PHY_REG_PHID2) & ENC_PHID2_MASK;
> > 	if (phid1 != ENC_PHID1_VALUE || phid2 != ENC_PHID2_VALUE) {
> > 		printf("%s: failed to identify PHY. Found
> > 		%04x:%04x\n",			enc->dev->name,
> > 		phid1, phid2);
> > 	 return -1;
> > 	}
> > 
> > fails because phy_read instructions return 0 or random values
> > (0xB0B0 or 0xB000).
> > Linux driver does not perform such tests, so I've tried removing
> > them.
> 
> No, please do not remove them. Fix the register access
> problem instead.
> 

Anatolj,
  how could the single register access work if all the spi setup and
startup is done in the spi_claim_bus function? (which is a bad design
in my opinion, since if I claim bus, it does not mean I want to start
the communication).

Anyway I've implemented the Transmit Receive mode, and verified it
works issuing a ping, that initialize enc and spi bus, and now I can
successfully read phy identifiers and the CLKRDY bit (which means that
read and write are now correct).

I'm still unable to ping because "`ethaddr' not set", maybe because
actually the transmit and receive mode is used only if txp and rxp are
not NULL (tx only or rx only methods are used either).
I can change that, but that means changing the omap_spi interface.

Also, the whole omap3_spi implementation has to be reworked, because
several things need to be added (turbo mode for 3 bytes transfers) and
some initialization work has to be moved from the claim_bus function to
the spi_xfer one...

I'll submit the receive-transmit mode patch only for now...
thank you
   j

[U-Boot] building enc28j60 for omap3: SILICON ERRATA

[Wolfgang Denk]

Hi,

I wrote:

> The omap3_spi driver was one of those affected by the bug fixed in
> commit 495df3b "ARM: fix write*() I/O accessors", see
> http://patchwork.ozlabs.org/patch/82841/

Sorry, I mixed this up.  That was the davinci_spi driver, not the
omap3_spi one.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Madness takes its toll. Please have exact change.