Problem with cuImage on 83x

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.