[U-Boot-Users] trizeps2 SMC lan91c96

[Hinko Kocevar]

Matej Kupljen wrote:
>>Next I enabled CONFIG_DRIVER_LAN91C96 and set 'CONFIG_LAN91C96_BASE 
>>0x0C000300' - taken from linux kernel. 
> 
>     ^--- Are you sure about this?
> 
> We are using this chip on our custom board and have the 91c96 on
> CS3 and we define this as 0x0C000000

I'm using this setting in my linux kernel 2.6.9 and it works fine.

/*0x0c000000 + 0x300*/
#define TRIZEPS2_ETH_PHYS      (PXA_CS3_PHYS + 0x300)
#define TRIZEPS2_ETH_GPIO      19
#define TRIZEPS2_ETH_IRQ       (IRQ_GPIO(TRIZEPS2_ETH_GPIO))

...
smc91x.c: v1.0, mar 07 2003 by Nicolas Pitre <nico at cam.org>
eth0: SMC91C94 (rev 9) at 0xc4852300 IRQ 42 [nowait]
eth0: Ethernet addr: 00:50:c2:0e:c8:d9

-note the last 3 bytes in 0xc4852300-

>>Warning: MAC addresses don't match:
>>         HW MAC address:  00:18:00:10:14:18
>>         "ethaddr" value: 00:50:C2:0E:C8:D9
> 
> 
> Probably different values in EEPROM and in environment.

'ethaddr' value is copied from dev board sticker. It also the one in 
dhcp server.

>>Using MAC Address 00:50:C2:0E:C8:D9
>>TFTP from server 192.168.0.77; our IP address is 192.168.0.98
>>Filename 'trizeps2_kernel.img'.
>>Load address: 0xa3000000
> 
> 
> Hm, is this hardcoded or sent by your BOOTP server?

I have ipaddr, serverip and bootfile settings in my ENV, yes, if that is 
what you ask. I think there is no communicating between target and 
server, I checked with ethereal.

>>Loading: LAN91C96:smc_hardware_send_packet
>>LAN91C96: memory allocation, try 1 failed ...
>>LAN91C96: memory allocation, try 2 failed ...
>>LAN91C96: memory allocation, try 3 failed ...
>>LAN91C96: memory allocation, try 4 failed ...
>>LAN91C96: memory allocation, try 5 failed ...
> 
> 
> I remember we had some problems with this also, but we tracked this
> down to a compiler BUG (we use our own toolchain) because the macro
> SMC_outb(d,r) in drivers/lan91c96.h did not correctly set the address.
> When we updated the gcc everything worked fine.

I used crosstool for my toolchain and have successfully built several 
kernels, xorg, and other appz. I'm using gcc 3.4.1 with glibc 2.3.3 and 
binutils 2.15. I'm quite happy with it:) but will check the net to see 
if issues exist with my combination of tools.

Macros seem a little 'off' at first glance (amateur view) and I will 
check how linux stuff in smc91x looks like for comparison - for 
starters. Besides, that low level memory error stuff is way low... Need 
to visit the hardware and schematics, again.

>> From the bdi debug session I managed to pinpoint the location where it 
>>all hangs - tftp.c, TftpSend():
>>
>>             *((ushort *)pkt)++ = htons(TFTP_RRQ);
> 
> 
> I don't think this is the source of your problem.
> I'd look in lan91c96.c, especially where the values of the
> registers are written and read. Check the values you get in the code
> and check the values of the registers with the BDI.

I agree, that was just preliminary stab. I'm pretty sure now that high 
level net code has nothing to do with it.

I'm still in process of discovering the true power of BDI2000 and need 
some time to get used to this masterpiece.

Regards,
hk


-- 
hinko <dot> kocevar <at> iskramedical <dot> si
Hinko Kocevar, embedded systems developer
Iskra Medical d.o.o., Stegne 23, 1k LJ, SLO-EU

	"Aì rén"	|	[Analects XII:22]