[U-Boot] mpc8313erdb: crash in image_print_type()
I'm building U-Boot 2009.01 for the MPC8313 ERDB. The issue I'm having is that when attempting to boot the kernel (or even when doing an "imi" command), I either get a bunch of garbage dumped to the screen or a machine check exception:
=> imi 100000
## Checking Image at 00100000 ... Legacy image found Image Name: Linux-2.6.28 Created: 2009-01-15 20:55:48 UTC Image Type: Machine check in kernel mode. Caused by (from msr): regs 07f2f7b8 Unknown values in msr NIP: 00001124 XER: 00000000 LR: 07FE318C REGS: 07f2f7b8 TRAP: 0200 DAR: 00000000 MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 07F2FD08 07F2F8A8 07F2FF54 572553E1 00000000 07F2F8E8 0013E043 FFFFFFFF GPR08: 00000003 572553E1 00000000 00000003 07FF2D86 00000000 07FFC000 00000000 GPR16: 00000000 07FF1930 07FFA238 07FF66D8 07FF2DD0 FFFFFF10 00000000 00000020 GPR24: 07F2F8F4 07FF1CBF 572553E1 FFFFFFFF 00000000 07F30122 07FFD49C 07F2F8E8 Call backtrace: Machine check in kernel mode. Caused by (from msr): regs 07f2f688 Unknown values in msr NIP: 07FB7940 XER: 00000000 LR: 07FB792C REGS: 07f2f688 TRAP: 0200 DAR: 00000000 MSR: 00003002 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 00 ...
The backtrace never actually gets printed (it seems to hit another exception instead), so I can't use the debugging instructions at http://www.denx.de/wiki/DULG/DecodingUBootCrashDumps . By adding some printf()s, it seems that it's getting into image_print_type(), but the last line:
printf ("%s %s %s (%s)\n", arch, os, type, comp);
is triggering the crash. Replacing with:
printf("%s\n", os);
still prints garbage, but I found that if I print the actual address that 'os' points to, and I do a "md" from the command-line, it correctly shows the uimage_os table entry:
=> md 13e61d 0013e61d: 4c696e75 78006e65 74627364 004e6574 Linux.netbsd.Net ...
So there seems to be something going on within printf() or some sub-function that's causing this issue. FYI, replacing with puts(os) didn't help, so the problem seems to be at a fairly low level (not within vsprintf() arg processing).
Build details:
- Toolchain is CodeSourcery 4.3-50 (CROSS_COMPILE is set to powerpc-linux-gnu-).
- This patch: http://www.mail-archive.com/u-boot@lists.denx.de/msg06883.html has been applied to get U-Boot to build properly.
- Otherwise, I'm doing a standard "make MPC8313ERDB_NAND_33_config; make".
Any ideas on how to debug this are appreciated, thanks!
On Thu, Jan 22, 2009 at 3:36 PM, Matthew L. Creech mlcreech@gmail.com wrote:
=> imi 100000
## Checking Image at 00100000 ...
...
=> md 13e61d 0013e61d: 4c696e75 78006e65 74627364 004e6574 Linux.netbsd.Net ...
Okay, upon re-reading this I saw where the problem lies. :) Apparently I'm overwriting the lookup table when I copy in the Linux image. Changing the destination address clears up the issue.
What is the region of memory reserved by U-boot that I shouldn't be touching? (From the MPC8313 config, I had thought that it relocates itself to 0x10000, and needs 512kB reserved for itself)
Matthew L. Creech wrote:
On Thu, Jan 22, 2009 at 3:36 PM, Matthew L. Creech mlcreech@gmail.com wrote:
=> imi 100000
## Checking Image at 00100000 ...
...
=> md 13e61d 0013e61d: 4c696e75 78006e65 74627364 004e6574 Linux.netbsd.Net ...
Okay, upon re-reading this I saw where the problem lies. :) Apparently I'm overwriting the lookup table when I copy in the Linux image. Changing the destination address clears up the issue.
What is the region of memory reserved by U-boot that I shouldn't be touching? (From the MPC8313 config, I had thought that it relocates itself to 0x10000, and needs 512kB reserved for itself)
0x10000 is where the NAND bootstrap goes, not the main u-boot image.
-scott
Matthew L. Creech wrote:
I'm building U-Boot 2009.01 for the MPC8313 ERDB. The issue I'm having is that when attempting to boot the kernel (or even when doing an "imi" command), I either get a bunch of garbage dumped to the screen or a machine check exception:
=> imi 100000
## Checking Image at 00100000 ...
When booting from NAND, u-boot is loaded at that address. It relocates to the end of memory, but the relocation process is incomplete and some things like strings still refer to the previous image. When booting from NOR, it's less of a problem because the strings are referenced in flash (though it could still go wrong if the flash is reprogrammed).
For now, use a different address to load your kernel.
-Scott
Dear Scott Wood,
In message 4978DCB3.1030200@freescale.com you wrote:
When booting from NAND, u-boot is loaded at that address. It relocates to the end of memory, but the relocation process is incomplete and some things like strings still refer to the previous image. When booting
But that's a serious bug that should be fixed.
Please at least point out where such problems are! Better even, fix them!
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Scott Wood,
In message 4978DCB3.1030200@freescale.com you wrote:
When booting from NAND, u-boot is loaded at that address. It relocates to the end of memory, but the relocation process is incomplete and some things like strings still refer to the previous image. When booting
But that's a serious bug that should be fixed.
Please at least point out where such problems are! Better even, fix them!
I thought it was known that relocation was imperfect, and that people tried fixing it, and ran into toolchain problems.
-Scott
Dear Scott Wood,
In message 4978E24B.5080802@freescale.com you wrote:
But that's a serious bug that should be fixed.
Please at least point out where such problems are! Better even, fix them!
I thought it was known that relocation was imperfect, and that people tried fixing it, and ran into toolchain problems.
So far the offical way is to manually relocate statically initialized pointers.
Thsi is independent of any toolchain (but becomes unnecessary once we get relocation working correctly).
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Scott Wood,
In message 4978E24B.5080802@freescale.com you wrote:
But that's a serious bug that should be fixed.
Please at least point out where such problems are! Better even, fix them!
I thought it was known that relocation was imperfect, and that people tried fixing it, and ran into toolchain problems.
So far the offical way is to manually relocate statically initialized pointers.
OK, well then the string tables in common/image.c are missing manual relocation.
-Scott
participants (3)
-
Matthew L. Creech -
Scott Wood -
Wolfgang Denk