PowerQUICC Processors中的主题 Re: U-Boot on MPC8360EA Reference Board.

U-Boot on MPC8360EA Reference Board.

clockwork — Tue, 11 Sep 2007 08:20:41 GMT

Hi,
I am trying to load customized linux kernel on MPC8360 reference board using U-Boot TFTP. I am not able to ping any outside address. I have tried connecting to TFTP server with a cross over cable. Still not able to ping the server. Am i missing something? Thanks and appreciate your help -

Re: U-Boot on MPC8360EA Reference Board.

abartky — Wed, 12 Sep 2007 01:28:31 GMT

clockwork,

When debugging u-boot networking and a new board for the first time, the real first step is KISS (keep it simple stupid) before you try more advanced networking, downloading etc. with it. u-boot has some quirks and also some of the setup is not 100% obvious if you are a u-boot newbie (as I was just 6 months ago)

First you should hook up your target board directly to your server using a straight through cable (as all the boards I've seen from Freescale have PHYs that have auto-crossover). Not all cross-over cables are created equal and some will not work at gigabit. The PHY on the board should take care of things OK.

Make sure that you see the carrier light on the port and also check the server side with an ifconfig (or similar command) to see that the port is up OK on the server as well. Also use a "known good" cable.

Assuming everything is OK at the physical level, you need to make sure u-boot is configured OK. Here is my config (for an MPC8313E-RDB board, but your config should be similar in the areas I will talk about):

=> print
flash_nfs=run nfsargs addip addtty;bootm ${kernel_addr}
flash_self=run ramargs addip addtty;bootm ${kernel_addr} ${ramdisk_addr}
net_nfs=tftp 200000 ${bootfile};run nfsargs addip addtty;bootm
load=tftp 100000 uboot_8313
update=protect off fe000000 fe04ffff; era fe000000 fe04ffff; cp.b 100000 fe00000
0 ${filesize}
upd=run load;run update
fdtaddr=400000
fdtfile=mpc8313erdb.dtb
vsc=cp.b fe050000 40000 12000;go 40004
bootcmd=protect on fe050000 fe07ffff;run vsc
ramargs=set bootargs root=/dev/ram rw ramdisk=128000
ethact=TSEC0
mtdids=nor0=nor,nand0=nand
rootpath=/tftpboot/192.168.2.192
filesize=119d
fileaddr=400000
gatewayip=192.168.2.1
netmask=255.255.255.0
ipaddr=192.168.2.192
serverip=192.168.2.129
bootargs=root=/dev/ram rw ramdisk=128000 console=ttyS0,115200
stdin=serial
stdout=serial
stderr=serial

Environment size: 1747/8188 bytes
=>

Here are the key ones to focus on:

Make sure the local ipaddr and netmask are OK and for initial debugging, make sure you used hard configured IP addresses on both the target and the server, here are mine:

ipaddr=192.168.2.192
netmask=255.255.255.0

Make sure the server IP address is set OK and if you are using a back to back cable you need to make sure the server and the target are on the same subnet:

serverip=192.168.2.129

I believe the 8360 device like the 8313 has multiple ETSECs, so you need to make sure that the correct ETSEC is set as default (i.e. the one connected to the port you are trying to run). In my case, I typically use ETSEC1 in the chip, but one thing that may bite you is the Freescale numbers ETSECs starting at 1 (ETSEC1, ETSEC2) whereas u-boot starts from 0 (TSEC0, TSEC1), so in my case I want to use ETSEC1 so I set ethact on u-boot to TSEC0. The active TSEC is set using the ethact environment variable (here is a print command showing mine):

=> print ethact
ethact=TSEC0
=>

Another thing that may bite you is sometimes when u-boot fails, it will automatically toggle between TSEC0 and TSEC1, so if ping isn't working, use the print ethact command to see if you are on the right port. If it is wrong, you can use the set command:

=> set ethact TSEC0

Another thing that may bite you is my board (and perhaps yours) also has an embedded Ethernet Switch. If your board has one, you need to make sure that it is loaded and running if you are trying to ping through that switch. The MPC8313E-RDB board has a Vitesse switch chip hooked up to TSEC1 (u-boot TSEC0) which must be running properly. In my case, I have my boot command setup to load the code automatically at startup (run vsc) as follows:

vsc=cp.b fe050000 40000 12000;go 40004
bootcmd=protect on fe050000 fe07ffff;run vsc

For my board when you "run vsc" you get the following output:

Protected 3 sectors
## Starting application at 0x00040004 ...
VSC7385 Version = 0x273850e9
Value in IRAM matches binary, total bytes 0x2000 loaded
## Application terminated, rc = 0x0

Also note that as the TSEC is directly connected on the boardto a port on the switch, it will always report the TSEC port as up even though nothing is connected to other switches on the port (this can cause confusion as well for a first time Freescale board user).

Another interesting bug (but shouldn't get you eventually get ping to work) is at least on my board and u-boot, the first time you try a ping, it gets an error, but then pings OK as follows:

=> ping 192.168.2.129
Speed: 1000, full duplex
Using TSEC0 device
Got error 4
host 192.168.2.129 is alive
=>

Subsequent pings then work OK:

=> ping 192.168.2.129
Speed: 1000, full duplex
Using TSEC0 device
host 192.168.2.129 is alive
=>

Notice that the ping command also tells you the speed, duplex setting and TSEC setting, make sure all those are OK (with the caution that if attached to an on-board switch chip that is running OK, it will always be at 1000, full duplex). If the TSEC device is the wrong one, use the set ethact command to change it. Also it is a good idea to save.

Another thing to remember while debugging u-boot networking is that u-boot can transmit ping requests and process the received ping replies, but u-boot does not support receiving ping requests and will silently discard them (so if you ping from the server to a u-boot target, you will not see a ping reply at the server side).

Last thing I can think of is I have seen cases where I've done a set ethact followed by a save and after a reboot, it doesn't "stick" and the other TSEC is the active one (not sure if this is a bug or a feature). Again either the print ethact or the ping command itself will tell which one is active (again remembering that u-boot numbers are one off from Freescale spec TSEC name).

Hope this helps :smileyhappy: Also after you get Ping to work OK, for other u-boot observations (such as running TFTP OK when running back to back, but sometimes failing on a network), you can check out my reply to another post at:

http://forums.freescale.com/freescale/board/message?board.id=MCUCOMM&thread.id=493

Cheers,

abartky

Re: U-Boot on MPC8360EA Reference Board.

clockwork — Wed, 12 Sep 2007 20:52:38 GMT

Thanks abartky. I did read your other post before posting my question. How to determine whether i got a vitesse switch on my board? I checked the board user manual. No mention of it. Let me go through the steps mentioned in your reply. Thanks for your help. -

Re: U-Boot on MPC8360EA Reference Board.

clockwork — Wed, 12 Sep 2007 22:46:04 GMT

Hi,
I followed all these step. I verified following environment variables ipaddr,ethaddr,ethact, gatewayip,serverip,netmask. Everything looks ok. I have connected the board directly to the server. It still makes no difference. I am certainly missing something. I got 2 board. Both of them behave the sameway. I got to be doing something wrong. Thanks -

Here is my u-boot environment
=> printenv
loada
bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:
rgs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;bootm $loadaddr $ram
diskaddr
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:
$serverip:$gatewayip:$netmask:$hostname:$netdevff console=$consoledev,$baudrat
e $othbootargs;tftp $loadaddr $bootfile;bootm $loadaddr
bootdelay=6
baudrate=115200
loads_echo=1
loadaddr=200000
netdev=eth0
consoledev=ttyS0
ramdiskaddr=400000
ramdiskfile=ramfs.83xx
ethact=FSL GETH0
ipaddr=10.0.20.95
serverip=10.0.20.245
gatewayip=10.0.20.1
stdin=serial
stdout=serial
stderr=serial
ethaddr=00:00:01:12:23:01

Environment size: 872/8188 bytes
=>

U-Boot 1.1.3 (Dec 8 2006 - 15:02:25) MPC83XX
SEC:

Clock configuration:
Coherent System Bus: 264 MHz MHz
Core:                 528 MHz MHz
QE:                   396 MHznumber.
Local Bus Controller: 264 MHzcpu revision!
SEC:                   88 MHz
I2C1:                  88 MHz
I2C2:                 264 MHz
CPU: Rev: Unknown, incompatible u-boot image.
Board: Freescale MPC8360EPB
I2C:   ready
DRAM:
   DDR DIMM: data bus width is 64 bit with ECC
   DDRC ECC mode: ON
   SDRAM on Local Bus: 64 MB
   DDR RAM: 256 MB
FLASH: 32 MB
In:    serial
Out:   serial
Err:   serial
Net:   FSL GETH0
Hit any key to stop autoboot: 0
=> ping 10.0.20.245
geth: PHY is Marvell 88E11x1 (1410cc2)
FSL GETH0: Full Duplex
FSL GETH0: Speed 1000BT
FSL GETH0: Link is up
Using FSL GETH0 device   ------> It stays here forever.

Message Edited by clockwork on 2007-09-12 04:48 PM

Re: U-Boot on MPC8360EA Reference Board.

abartky — Wed, 12 Sep 2007 23:57:13 GMT

clockwork,

I did a quick google search and found a "working" u-boot example for the 8360 where I searched for "FSL GETH0 printenv", the link I found is at:

http://www.mail-archive.com/linuxppc-embedded@ozlabs.org/msg20887.html

Here is an excerpt:

U-Boot 1.1.3 (ppc83xx-20050315-dev) (Dec 14 2005 - 09:37:59) MPC83XX

Clock configuration:
Coherent System Bus: 264 MHz
Core: 528 MHz
QE: 396 MHz
Local Bus Controller: 264 MHz
Local Bus: 66 MHz
DDR: 264 MHz
DDR Secondary: 264 MHz
I2C: 264 MHz
CPU: MPC83xx, Rev: 20 at 528 MHz
Board: Freescale MPC8360EPB
I2C: ready
DRAM:
SDRAM on Local Bus: 64 MB
DDR RAM: 256 MB
FLASH: 16 MB
In: serial
Out: serial
Err: serial
Net: FSL GETH0
Hit any key to stop autoboot: 0
=> printenv
bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrramboot=setenv
bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp
$ramdiskaddr $ramdiskfile;tftp $loarnfsboot=setenv bootargs root=/dev/nfs
rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrbootdelay=6
baudrate=115200
loads_echo=1
ethaddr=00:04:9f:11:22:33
eth1addr=00:E0:0C:00:7D:01
hostname=unknown
loadaddr=200000
netdev=eth0
consoledev=ttyS0
ramdiskaddr=400000
ramdiskfile=ramfs.83xx
ethact=FSL GETH0
filesize=2d030a
fileaddr=20000
gatewayip=192.168.3.1
netmask=255.255.255.0
serverip=192.168.3.81
bootfile=/tftpboot/vmlinux.gz
ipaddr=192.168.3.253
stdin=serial
stdout=serial
stderr=serial

Environment size: 1005/8188 bytes
=> setenv bootargs console=ttyS1 root=/dev/ram
=> tftp 200000 uImage_test
Auto negotiating done
switching to rgmii 100
duplexity: full
mac speed set to: 100
Using FSL GETH0 device
TFTP from server 192.168.3.81; our IP address is 192.168.3.253
Filename 'uImage_test'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
#######
done
Bytes transferred = 1033098 (fc38a hex)
=>

In your printenv, I did not see a netmask=255.255.255.0, so make sure that is set. Also I noticed the example working code also sets the eth1addr, so if you have a 2 port system, you may want to try that as well.

The other worrysome part are the startup messages from your trace saying "number", "CPU revision!" and "Rev: Unknown, incompatible u-boot image" and the fact that the ping command is hanging there, rather than timing out, do not bode well. Considering the fact the ping command is reporting the PHY status OK (full duplex Gigabit Ethernet), if adding the netmask and the eth1addr doesn't fix things, then you may have a u-boot software issue. Are you using the version of u-boot that came with the board's BSP?

Cheers,

abartky

Re: U-Boot on MPC8360EA Reference Board.

clockwork — Thu, 13 Sep 2007 01:08:53 GMT

Hi abartky,
I am using the one came with the board. I replaced using the one build from freescale linux BSP. Same revision 1.1.3 and made no difference. And finally, downloaded latest version 1.2 from net and build it for 8360. It did not boot at all. So reverted back to original revision came with the board. Thanks for your reply.

Re: U-Boot on MPC8360EA Reference Board.

LuckyS — Fri, 28 Sep 2007 14:06:18 GMT

Hi all,

We have almoast the same problem, we have took the freescale linux BSP (the last one: 3.0) install all the patches, create U-Boot and when PPC8360 Rev 2.0 starts running U-Boot some prints on console came up and then MPC8360 freezes. Has anyone had similar problems?

Thanks for your reply.

Re: U-Boot on MPC8360EA Reference Board.

LuckyS — Fri, 28 Sep 2007 16:40:23 GMT

Hi All,

We solved the problem, the problem was in MW compiler.

Thanks anyaway.