[U-Boot-Users] [uboot] Walnut PPC405GP flash

[Stefan Roese]

On Monday 21 April 2008, 甜瓜 wrote:
>     I'm a beginner of embedded system. I'm working on a board of Walnut
> PPC405GP which use PPCBOOT 1.1.2.

Wow, that's ancient. I suggest to update to the current version.

Please find some comments below.

> One day I tried to write some data into unused area of the flash:
> >> fli
>
> Bank # 1: AMD AM29F040 (512 Kbit, uniform sector size)
>   Size: 512 KB in 8 Sectors
>   Sector Start Addresses:
>     FFF80000  RO  FFF90000  RO  FFFA0000  RO  FFFB0000      FFFC0000
>     FFFD0000      FFFE0000      FFFF0000
>
> I use the last sector:
> >> md ffff0000
>
> ffff0000: 00000000 00000000 00000000 00000000    ................
> ffff0010: 00000000 00000000 00000000 00000000    ................
> ffff0020: 00000000 00000000 00000000 00000000    ................
> ffff0030: 00000000 00000000 00000000 00000000    ................
> ffff0040: 00000000 00000000 00000000 00000000    ................
> ffff0050: 00000000 00000000 00000000 00000000    ................
> ffff0060: 00000000 00000000 00000000 00000000    ................
> ffff0070: 00000000 00000000 00000000 00000000    ................
> ffff0080: 00000000 00000000 00000000 00000000    ................
> ffff0090: 00000000 00000000 00000000 00000000    ................
> ffff00a0: 00000000 00000000 00000000 00000000    ................
> ffff00b0: 00000000 00000000 00000000 00000000    ................
> ffff00c0: 00000000 00000000 00000000 00000000    ................
> ffff00d0: 00000000 00000000 00000000 00000000    ................
> ffff00e0: 00000000 00000000 00000000 00000000    ................
> ffff00f0: 00000000 00000000 00000000 00000000    ................
>
> >> protected off ffff0000 ffffffff
>
> Un-Protected 1 sectors
>
> >> erase ffff0000 ffffffff
>
> Erase Flash from 0xffff0000 to 0xffffffff
> Erasing sector ffff0000
> . done
> Erased 1 sectors

You should not have erased this sector. It's part of the U-Boot (PPCBoot) 
image and erasing it (without reflashing) will lead to a non breaking system.

> !! Now I tried to copy a small file data to this area by using tftp.
>
> >> tftp ffff0000 data_file
>
> 405GP Eth Status:
>    data len error 0
>    rx frames 0
>    rx 0
>    rx_prot_err 0
>    int_err 0
>    tx_err_log:
>       [0] 0
>       [1] 0
>       [2] 0
>       [3] 0
>       [4] 0
>       [5] 0
>       [6] 0
>       [7] 0
>       [8] 0
>       [9] 0
>    rx_err_log:
>       [0] 0
>       [1] 0
>       [2] 0
>       [3] 0
>       [4] 0
>       [5] 0
>       [6] 0
>       [7] 0
>       [8] 0
>       [9] 0

I have never seen such a debug log.

> ENET Speed is 100 Mbps - FULL duplex connection
> *** ERROR: `ipaddr' not set
>
> Well, set the target addr first, then:
> >> dhcp
>
> 405GP Eth Status:
>    data len error 0
>    rx frames 0
>    rx 0
>    rx_prot_err 0
>    int_err 0
>    tx_err_log:
>       [0] 0
>       [1] 0
>       [2] 0
>       [3] 0
>       [4] 0
>       [5] 0
>       [6] 0
>       [7] 0
>       [8] 0
>       [9] 0
>    rx_err_log:
>       [0] 0
>       [1] 0
>       [2] 0
>       [3] 0
>       [4] 0
>       [5] 0
>       [6] 0
>       [7] 0
>       [8] 0
>       [9] 0
>
> ENET Speed is 100 Mbps - FULL duplex connection
> BOOTP broadcast 1
> DHCPHandler: got packet: (src=67, dst=68, len=548) state: 3
> Filtering pkt = 0
> DHCPHandler: got DHCP packet: (src=67, dst=68, len=548) state: 3
> DHCP: state=SELECTING bp_file: "uImage"
> TRANSITIONING TO REQUESTING STATE
> Bootfile: uImage
> DhcpSendRequestPkt: Sending DHCPREQUEST
> Transmitting DHCPREQUEST packet: len = 308
> DHCPHandler: got packet: (src=67, dst=68, len=548) state: 4
> Filtering pkt = 0
> DHCPHandler: got DHCP packet: (src=67, dst=68, len=548) state: 4
> DHCP State: REQUESTING
> Bootfile: uImage
> DHCP client bound to address 192.168.1.201
> ARP broadcast 1
> Got good ARP - start TFTP
> TFTP from server 192.168.1.200; our IP address is 192.168.1.201
> Filename 'uImage'.
> Load address: 0xffff0000
> Loading: *##############NIP: 00000200 XER: 00000000 LR: 67E12A71 REGS:
> 01faea48 TRAP: 0700 DAR: 00080000
> MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
>
> GPR00: 00000001 01FAEB38 40000000 01FAEB48 80000000 00000002 01FB016D
> 01C80764
> GPR08: 01FF5060 01FF5074 FFFFFFFF 01FF54B4 00000000 7C6BFE6C 01FF4400
> 02050000
> GPR16: E45EA284 DC212086 02CACA22 F3844306 00001000 01FAEB38 00000000
> 67E12A71
> GPR24: 76585F5E 00000001 00000000 01FAEF8C 00000004 00000000 01FF44CC
> 01FF52A4
> ** Illegal Instruction **
> Call backtrace:
> Program Check Exception
>
>  ========================
> You can see my mistake...>_< A big uImage file is copied to flash, rather
> than data_file.
> After that, the Walnut board cannot boot anymore... I wonder why. The data
> is simply copied to
> the unused sector, while other sectors are under protection. It should be
> safe even if I made mistakes.

No, it's not unused. The 4xx reset vector is at 0xfffffffc, so it definitely 
is needed. I'm afraid your FLASH image is corrupted now. The only way out is 
reflashing using a JTAG debugger like the BDI2000.

Best regards,
Stefan

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