[U-Boot-Users] Flash boot issues with MPC8272ADS and PQ2FADS

We are using several PQ2FADS-VR and MPC8272ADS boards for a Linux project and are experiencing a high occurrence of boards that get into a state where they will not boot or behave erratically during boot.
The symptoms are usually that board continually resets in u-boot. See below for output examples. In other cases, the system will get to the point of attempting to load a kernel, but will claim the checksum is bad, or will start booting the kernel and crash shortly thereafter.
When folks bring me systems in this state, my "fix" has been to replace the 8MB flash SIMM. This usually gets them going again, but I honestly don't think the SIMM is the real problem. I have one PQ2FADS board that I have put four different SIMMs in and can not get it to boot. In most other cases, I can take the "bad" SIMM, put it in another board, reprogram it and it will work again (for a while).
In all of these cases, we are using known good u-boots (built from unmodified 1.1.2 source for either the PQ2FADS or MPC8272ADS) and known good, tested kernels. Typically, users will have been working for weeks without a problem until they run into this.
Here is the method I am using the program the flash using the BDI2000:
8275>unlock 0xff800000 0x40000 32
8275>erase 0xff800000 0x40000 32 Erasing flash at 0xff800000 Erasing flash at ... Erasing flash at 0xfffc0000 Erasing flash passed
8275>prog 0xfff00000 u-boot.bin.pq2fads bin Programming u-boot.bin.pq2fads , please wait .... Programming flash passed
8275>verify 0xfff00000 u-boot.bin.pq2fads bin Verifying u-boot.bin.pq2fads , please wait .... Verifying target memory passed
Is this incorrect?
Any insight or shared experience on this is greatly appreciated.
Thanks, Keath
Output such as this is typical (PQ2FADS output shown, MPC8272ADS output is similar):
---------------------------------------------------------------------------- --- U-Boot 1.1.2 (Aug 9 2005 - 12:58:57)
MPC8260 Reset Status: Check Stop, External Soft, External Hard
MPC8260 Clock Configuration - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300 - dfbrg 1, corecnf 0x0a, busdf 3, cpmdf 1, plldf 0, pllmf 3 - vco_out 264000000, scc_clk 66000000, brg_clk 16500000 - cpu_clk 264000000, cpm_clk 132000000, bus_clk 66000000 - pci_clk 44000000
CPU: MPC8260 (HiP7 Rev 11, Mask 0.0 0K49M) at 264 MHz Board: Motorola PQ2FADS-ZU DRAM: 32 MB FLASH: ---------------------------------------------------------------------------- --- <reboot happens here>
Sometimes, we will see garbage output to the serial port while this is happening. Occasionally, we will see some crash dump info, but not usually. Example: ---------------------------------------------------------------------------- --- U-Boot 1.1.2 (Aug 9 2005 - 12:58:57)
MPC8260 Reset Status: External Soft, External Hard
MPC8260 Clock Configuration - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq 25-75 , Core Freq 100-300 - dfbrg 1, corecnf 0x0a, busdf 3, cpmdf 1, plldf 0, pllmf 3 - vco_out 264000000, scc_clk 66000000, brg_clk 16500000 - cpu_clk 264000000, cpm_clk 132000000, bus_clk 66000000 - pci_clk 44000000
CPU: MPC8260 (HiP7 Rev 11, Mask 0.0 0K49M) at 264 MHz Board: Motorola PQ2FADS-ZU DRAM: 32 MB FLASH: 8 MB In: serial Out: serial Err: serial Bad trap at PC: 248, SR: 0, vector=800 4NIP: 00000248 XER: 00000000 LR: 01FE64F8 REGS: 01fefea1 TRAP: 0800 DAR: 01FFE04 MSR: 00000000 EE: 0 PR: 0 FP: 1fefea1 ME: 0 IR/DR: 1ffe0240
GPR00: 03FCD7C0 01B88AA0 FFFFFFFF 01B88B5D 01FEFCD3 00000010 FFFFFFFE 00000000 GPR08: 00000001 01FDDAEC 00000000 01FEFCD4 00000030 FFFFFFFF 01FFE000 020C9000 GPR16: FFFFFFFF EFFFFFFF FFFFFFFF FFEFFEFF 00000000 01B889A0 821CDAD8 01FCC098 GPR24: 01B88B50 00000000 00000008 00000000 01B88B62 01B88F6C 00001466 01B88B40 Call backtrace: 01FE64F8 00000010 FFFFFFFE 01B88858 00000041 00000010 00000000 01B889B0 01B889B0 01B889B0 01B889B0 Exception in kernel pc 248 signal 0 ---------------------------------------------------------------------------- --- <reboot>
As I mentioned above, these are just a couple of examples, output varies from board to board and boot-attempt to boot-attempt.

In message 95C7A54CCA1D3542A7721B03E7EE2F6B035181@AUSMAIL.austin.polycom.com you wrote:
In all of these cases, we are using known good u-boots (built from unmodified 1.1.2 source for either the PQ2FADS or MPC8272ADS) and known
"unmodified 1.1.2 source" and " known good u-boots" in one sentence is an oxymoron. Try using current code instead (like top of tree in CVS).
Best regards,
Wolfgang Denk

Keath Milligan writes:
Keath> We are using several PQ2FADS-VR and MPC8272ADS boards for a Keath> Linux project and are experiencing a high occurrence of Keath> boards that get into a state where they will not boot or Keath> behave erratically during boot.
Keath> The symptoms are usually that board continually resets in Keath> u-boot. See below for output examples. In other cases, the Keath> system will get to the point of attempting to load a kernel, Keath> but will claim the checksum is bad, or will start booting the Keath> kernel and crash shortly thereafter.
Keath> When folks bring me systems in this state, my "fix" has been Keath> to replace the 8MB flash SIMM. This usually gets them going Keath> again, but I honestly don't think the SIMM is the real Keath> problem. I have one PQ2FADS board that I have put four Keath> different SIMMs in and can not get it to boot. In most other Keath> cases, I can take the "bad" SIMM, put it in another board, Keath> reprogram it and it will work again (for a while).
Keath> In all of these cases, we are using known good u-boots (built Keath> from unmodified 1.1.2 source for either the PQ2FADS or Keath> MPC8272ADS) and known good, tested kernels. Typically, users Keath> will have been working for weeks without a problem until they Keath> run into this.
MPC8272ADS is very unstable. We had to change three boards until we got one which can work for some time without random reboots. Try to get the board replaced by Freescale. PQ2FADS is much better though not perfect as you noted:) We've got PQ2FADS-ZU (not VR) which can work for weeks without reboots. First of all, I'd suggest checking the clocks. The MPC8280 erratum regarding MF>=3.5 is in many cases the source of the instability. Try to use MF<=3.

Yuli Barcohen yuli@arabellasw.com wrote:
MPC8272ADS is very unstable. We had to change three boards until we got one which can work for some
I happen to have one on hand. I will check it to see my luck.
instability. Try to use MF<=3.
MF means CPM MF or CPU MF?
Thanks,
Sam
___________________________________________________________ 雅虎邮箱超强增值服务-2G超大空间、pop3收信、无限量邮件提醒 http://cn.mail.yahoo.com/mail_alert/promo1.html

Sam Song writes:
Yuli> MPC8272ADS is very unstable. We had to change three boards Yuli> until we got one which can work for some
Sam> I happen to have one on hand. I will check it to see my luck.
Yuli> instability. Try to use MF<=3.
Sam> MF means CPM MF or CPU MF?
MF is bus-to-core multiplication factor. It's erratum G9 for MPC8280 family. IMHO it does not apply to MPC8272 family.
participants (4)
-
Milligan, Keath
-
Sam Song
-
Wolfgang Denk
-
Yuli Barcohen