[U-Boot] mpc8313erdb: crash in image_print_type()

[U-Boot] mpc8313erdb: crash in image_print_type()

[Matthew L. Creech]

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 at 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!

-- 
Matthew L. Creech

[U-Boot] mpc8313erdb: crash in image_print_type()

[Matthew L. Creech]

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

[U-Boot] mpc8313erdb: crash in image_print_type()

[Scott Wood]

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

[U-Boot] mpc8313erdb: crash in image_print_type()

[Scott Wood]

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

[U-Boot] mpc8313erdb: crash in image_print_type()

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Conscious is when you are aware of something, and conscience is  when
you wish you weren't.

[U-Boot] mpc8313erdb: crash in image_print_type()

[Scott Wood]

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

[U-Boot] mpc8313erdb: crash in image_print_type()

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You can observe a lot just by watchin'.                  - Yogi Berra

[U-Boot] mpc8313erdb: crash in image_print_type()

[Scott Wood]

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