[U-Boot-Users] trizeps2 SMC lan91c96

[U-Boot-Users] trizeps2 SMC lan91c96

[Hinko Kocevar]

Hi all,
I've successfully ported u-boot to trizeps2 cpu module from K&K that 
runs on pxa255 cpu, 32Mb FLASH and 64Mb SDRAM. Right no I get the 
command prompt.

Next I enabled CONFIG_DRIVER_LAN91C96 and set 'CONFIG_LAN91C96_BASE 
0x0C000300' - taken from linux kernel. After issuing tftp command I get 
following output:

U-Boot 1.1.3 (Mar  9 2005 - 16:32:01)

U-Boot code: A3080000 -> A30A9B40  BSS: -> A30AE1C4
RAM Configuration:
Bank #0: a0000000 64 MB
Flash: 32 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
$ tftp
LAN91C96:smc_close
LAN91C96:smc_shutdown
LAN91C96:smc_open
LAN91C96:smc_reset
LAN91C96:smc_enable

Warning: MAC addresses don't match:
         HW MAC address:  00:18:00:10:14:18
         "ethaddr" value: 00:50:C2:0E:C8:D9
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
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 ...
LAN91C96:smc_rcv
RCV: STATUS    0 LENGTH    0
  Reading 32766 words and 0 byte(s)

Now, in linux kernel I had to set bit LAN91C96_CR_INT_SEL1 in 
LAN91C96_CONFIG to select correct int, but in u-boot we do not use 
interrupts last time I checked and I have them disabled in my config 
also, so this should not be mandatory here.
 From the bdi debug session I managed to pinpoint the location where it 
all hangs - tftp.c, TftpSend():

             *((ushort *)pkt)++ = htons(TFTP_RRQ);

Has anyone any experience with lan91c96 under u-boot? Would I be better 
off using smc9111 driver instead?

Any comments are welcome,

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]

[U-Boot-Users] trizeps2 SMC lan91c96

[Matej Kupljen]

Hi

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

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

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

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

> Has anyone any experience with lan91c96 under u-boot? 

It works fine for us, in U-Boot and in Linux.

> Any comments are welcome,

It hard to say anything specific, because we do not have your
schematics to see how is the c91c97 connected to PXA.

BR,
Matej

[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@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]