RE: [U-Boot-Users] MPC8272ADS and uboot program check

-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Bastos Fernandez Alexandre Sent: Wednesday, September 15, 2004 8:48 AM To: 'u-boot-users@lists.sourceforge.net' Subject: [U-Boot-Users] MPC8272ADS and uboot program check
Hi to all,
After some days working ok with my MPC8272ADS board, now it keeps rebooting all the time with a Program Check report. It has arrived after a hang.
I have been checking the output as this is all the information i have at the moment. I have realized that clock reporting is incoherent (the true one is cpu_clk=400Mhz), so i wonder if it has any relation.
Any idea?
The output I get is:
U-Boot 1.0.0 (Jun 30 2004 - 20:20:47)
MPC8272 Reset Status: Check Stop, External Soft, External Hard
MPC8272 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 400000000, scc_clk 100000000, brg_clk 25000000
- cpu_clk 400000000, cpm_clk 200000000, bus_clk 100000000
CPU: MPC8272 (HiP7 Rev 13, Mask 0.1 0K50M) at 18.382000 MHz Board: Motorola MPC8272ADS I2C: ready DRAM: 64 MB
[garbage snipped]
8 MB *** Warning - bad CRC, using default environment
pci init start-----pci init end In: serial Out: serial Err: serial NIP: 03F968D8 XER: 20000000 LR: 03FB621C REGS: 03f3fdd8 TRAP: 0700 DAR: 03FB5374 MSR: 00083002 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 00
GPR00: CCC0E043 03F3FEC8 E7FFFFFF 00000001 00000000 00000010 000003A0 000003C4 GPR08: 00000264 B0FFFFFB 03FC86D0 001A6306 48002024 E7FFF3BF 03FC8000 058A0000 GPR16: FBFF9F7B FF7FFFED 00000000 FE729328 00003002 00000001 00000000 03FA3098 GPR24: 03FA390C 00000000 00000010 00000000 00000000 03F3FF64 00000020 F0010D40 Call backtrace: Program Check Exception
First of all, I would acknowleging that Wolfgang is probably right and you probably have a hardware problem. In case that is not true, my follow-up questions and observations are...
#1 question in debugging: what changed between when it last worked and now?
Looking at the above, what is the software trying to do when all the garbage is being spewed out (just before it prints "8MB"? What it is doing is likely related to the problem.
Did the board previously print the correct clock rate, or has it always been wrong? Why is it wrong?
#1 rule in debugging: always fix the known bugs before hunting for the unknown, known (but discounted and ignored) bugs tend to cause additional "unknown bugs" in strange and mysterious ways.
gvb
****************************************** The following messages are brought to you by the Lawyers' League of IdioSpeak:
****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************
participants (1)
-
VanBaren, Gerald (AGRE)