[U-Boot-Users] [uboot] Walnut PPC405GP flash
Howdy, I'm a beginner of embedded system. I'm working on a board of Walnut PPC405GP which use PPCBOOT 1.1.2. 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
!! 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
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.
Thank you very much. --- ShenLei
On Monday 21 April 2008, 甜瓜 wrote:
I'm a beginner of embedded system. I'm working on a board of WalnutPPC405GP 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@denx.de =====================================================================
Yep! The ppcboot is very ancient. hehe. Actually, my board is DHT-walnut: http://elinux.org/DHT-Walnut_U_Boot The web provides a pre-compiled bin uboot 1.1.4 for my board. The size is 256KB. I downloaded it, and burn this bin into flash. But the board is still not work. Well, you point out a very important thing that 4xx use 0xfffffffc as the reset vector. My flash is 512KB larger, therefore the bin only fills the first 256KB of the flash. The reset vector is not set correct. Am I correct? It seem that it depends on how CPU maps flash contents into address space. And how to set it? I don't know how to determine the real entry of a specific uboot-bin. :<
Thank you for your help. --- ShenLei
On Monday 21 April 2008, 甜瓜 wrote:
Yep! The ppcboot is very ancient. hehe. Actually, my board is DHT-walnut: http://elinux.org/DHT-Walnut_U_Boot
So, it's no "real" Walnut. Then the official Walnut U-Boot will probably not work for your board.
The web provides a pre-compiled bin uboot 1.1.4 for my board. The size is 256KB.
4xx U-Boot images need to get loaded at the "end" of flash. So a 256k image need to get loaded at 0xfffc0000.
I downloaded it, and burn this bin into flash. But the board is still not work. Well, you point out a very important thing that 4xx use 0xfffffffc as the reset vector. My flash is 512KB larger, therefore the bin only fills the first 256KB of the flash. The reset vector is not set correct. Am I correct? It seem that it depends on how CPU maps flash contents into address space. And how to set it? I don't know how to determine the real entry of a specific uboot-bin. :<
As mentioned above, you have to program a 256k image to 0xfffc0000.
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@denx.de =====================================================================
participants (2)
-
Stefan Roese -
甜瓜