Problem with cuImage on 83x

[Giuseppe Lippolis]

Dear All,
I'm trying, using buildroot, to generate an image for my iomega 150d
(mpc8347 based).
I'm prepared the device tree and configured the platform with:
CONFIG_PPC_83xx=y
CONFIG_MPC834x_MDS=y
CONFIG_MPC834x_ITX=y

The image I'm generating is cuImage.

I generated the image and the system crash after the wrapper call the
kernel.

## Booting image at 01000000 ...
   Image Name:   Linux-4.10.4
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    2988301 Bytes =  2.8 MB
   Load Address: 00600000
   Entry Point:  006001f4
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Memory <- <0x0 0x20000000> (512MB)
ethernet0: local-mac-address <- 00:d0:b8:01:d1:9f
ethernet1: local-mac-address <- 4b:ff:ff:60:72:6f
CPU clock-frequency <- 0x179a7b00 (396MHz)
CPU timebase-frequency <- 0x3ef1480 (66MHz)
CPU bus-frequency <- 0xfbc5200 (264MHz)

zImage starting: loaded at 0x00600000 (sp: 0x1ffb2cf8)
Decompression error: 'Not a gzip file'
No valid compressed data found, assume uncompressed data
Allocating 0x5f9250 bytes for kernel...
0x5bd520 bytes of uncompressed data copied

Linux/PowerPC load: root=/dev/mtdblock1 ro rootfstype=cramfs devfs=mount
console=ttySc
Finalizing device tree... flat tree at 0xbdb960


After some investigation I realize that the system crash very early on the
early_init call:

c000004c:       48 55 f8 71     bl      c055f8bc <early_init>

This call is linked in the .init.text section.
According to the readelf readout:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk
Inf Al
  [15] .init.text        PROGBITS        c055a000 56a000 025ae0 00  AX  0
0  4

And again according to the objdump/readelf readout:

c055a000 <__init_begin>:
c055a000:       ff ef b1 b0     .long 0xffefb1b0

c055a004 <dt_find_string>:
c055a004:       94 21 ff e0     stwu    r1,-32(r1)
c055a008:       7c 08 02 a6     mflr    r0
c055a00c:       42 9f 00 05     bcl     20,4*cr7+so,c055a010
<dt_find_string+0xc>

[...]

c055f8bc <early_init>:
c055f8bc:       94 21 ff f0     stwu    r1,-16(r1)
c055f8c0:       7c 08 02 a6     mflr    r0
c055f8c4:       bf c1 00 08     stmw    r30,8(r1)

Hex dump of section '.init.text':
  0xc055a000 ffefb1b0 9421ffe0 7c0802a6 429f0005 .....!..|...B...
  0xc055a010 bf61000c 7fc802a6 7c7b1b78 90010024 .a......|{.x...$


But If I execute a post-mortem dump on the target memory I get:

0055a000: afafd773 c13b262f 7be3b7ba ff3e75ef    ...s.;&/{....>u.
0055a010: 3e636df5 1d444cb1 9eeafdc9 bdb5eff4    >cm..DL.........

[..]

0055f8b0: ba7a7df9 9ca516fd 16faf9cd 11664eb4    .z}..........fN.
0055f8c0: 08addfb6 db7eae53 29ad963e db5a2fef    .....~.S)..>.Z/.


So It seems that the wrapper is making a mistake during the kernel copy.

I will proceed with the analysis, but before to proceed I would like to ask
if my analysis is correct or I'm wrong somewhere.

Thanks,
Bye.