building enc28j60 for omap3: undefined references

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

Dear jacopo mondi,

...

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

Best Regards,
Reinhard

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

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

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
=====================================================================

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

Your're welcome.

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.

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
=====================================================================

You are right..

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

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

Hi,

On Tue, 22 Feb 2011 17:34:30 +0100
jacopo mondi <[email protected]> wrote:
...

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

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.

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

Dear Anatolij Gustschin,

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

Thank you Anatolij, I'm reading OMAP datasheet in these days... Hope I'll provide something during next week.

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