Skip to contentSkip to conversation

Debugging why my kernel won't start

U-Boot New Rogan Dawes 4 participants 34 messages Aug 16, 2010 – Aug 19, 2010 Arm (32-bit)

lore
Share & tools
lore
#0 lore raw

Hi folks,

I'm trying to get mainline u-boot working on my DNS323 (Orion5x based). Until I am confident in the config, I'm using a chainloaded approach, wrapping my featureful u-boot in an image file:

$ mkimage -A arm -O u-boot -T kernel -C none -a 0x3000000 -e 0x3000000 
-n "UBoot dns323" -d u-boot.bin uImage.bin

I am trying to boot the default kernel that is already flashed into the device first. The first problem is that the DNS323 uses an incorrect mach-type value of 526, while the registered value is 1542. See
<http://wiki.dns323.info/software:kernel>). I have modified arch/arm/include/asm/mach-types.h to set MACH_TYPE_DNS323 to the "correct" Dlink value, which should match what the default kernel is expecting.

Unfortunately, all I get is:

DNS323B1> bootm FF820000
## Booting kernel from Legacy Image at ff820000 ...

    Image Name:   Linux-2.6.12.6-arm1
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    1490204 Bytes = 1.4 MiB

Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ...

and it hangs there.

That appears to be this code from cmd_bootm:

         case IH_COMP_NONE:
                 if (load == blob_start) {
                         printf ("   XIP %s ... ", type_name);
                 } else {
                         printf ("   Loading %s ... ", type_name);
                         memmove_wd ((void *)load, (void *)image_start,
                                         image_len, CHUNKSZ);
                 }
                 *load_end = load + image_len;
                 puts("OK\n");
                 break;

So, the memmove_wd never completes, it seems.

I added a debug statement at the top of memmove_wd, and got:

Moving memory from ff820040 to 00008000

Is that because the uImage header is 64 bytes?

Also, the following suggests that there may be something wrong with the addresses that I am using:

DNS323B1> bootm FF820000 FF9A0000
## Booting kernel from Legacy Image at ff820000 ...

    Image Name:   Linux-2.6.12.6-arm1
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    1490204 Bytes = 1.4 MiB
    Load Address: 00008000
    Entry Point:  00008000
    Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at ff9a0000 ...
    Image Name:   Ramdisk
    Image Type:   ARM Linux RAMDisk Image (gzip compressed)
    Data Size:    5240600 Bytes = 5 MiB
    Load Address: 00800000
    Entry Point:  00800000
    Verifying Checksum ... Bad Data CRC

Ramdisk image is corrupt or invalid
DNS323B1>

My chainloaded u-boot is configured in an image to load at 0x3000000, and stay there (no relocation), if I have understood these parameters correctly:

-a 0x3000000 -e 0x3000000

Can anyone see what I am doing wrong?

Many thanks!

Rogan

#1 lore raw

Dear Rogan,

I've you set the uboot env machid to the correct value ? setenv machid <HexValue>
just replace HexValue with the correct MACH_TYPE.

You must then see something like :
Using machid 0xa76 from environment
after kernel loaded by uboot.

Best regards,

Le 16/08/2010 09:24, Rogan Dawes a ?crit :

Quoted 89 lines

Hi folks,

I'm trying to get mainline u-boot working on my DNS323 (Orion5x based). Until I am confident in the config, I'm using a chainloaded approach, wrapping my featureful u-boot in an image file:

$ mkimage -A arm -O u-boot -T kernel -C none -a 0x3000000 -e 0x3000000 
-n "UBoot dns323" -d u-boot.bin uImage.bin

I am trying to boot the default kernel that is already flashed into the device first. The first problem is that the DNS323 uses an incorrect mach-type value of 526, while the registered value is 1542. See
<http://wiki.dns323.info/software:kernel>). I have modified arch/arm/include/asm/mach-types.h to set MACH_TYPE_DNS323 to the "correct" Dlink value, which should match what the default kernel is expecting.

Unfortunately, all I get is:

DNS323B1> bootm FF820000
## Booting kernel from Legacy Image at ff820000 ...

    Image Name:   Linux-2.6.12.6-arm1
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    1490204 Bytes = 1.4 MiB

Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ...

and it hangs there.

That appears to be this code from cmd_bootm:

         case IH_COMP_NONE:
                 if (load == blob_start) {
                         printf ("   XIP %s ... ", type_name);
                 } else {
                         printf ("   Loading %s ... ", type_name);
                         memmove_wd ((void *)load, (void *)image_start,
                                         image_len, CHUNKSZ);
                 }
                 *load_end = load + image_len;
                 puts("OK\n");
                 break;

So, the memmove_wd never completes, it seems.

I added a debug statement at the top of memmove_wd, and got:

Moving memory from ff820040 to 00008000

Is that because the uImage header is 64 bytes?

Also, the following suggests that there may be something wrong with the addresses that I am using:

DNS323B1> bootm FF820000 FF9A0000
## Booting kernel from Legacy Image at ff820000 ...

    Image Name:   Linux-2.6.12.6-arm1
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    1490204 Bytes = 1.4 MiB
    Load Address: 00008000
    Entry Point:  00008000
    Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at ff9a0000 ...
    Image Name:   Ramdisk
    Image Type:   ARM Linux RAMDisk Image (gzip compressed)
    Data Size:    5240600 Bytes = 5 MiB
    Load Address: 00800000
    Entry Point:  00800000
    Verifying Checksum ... Bad Data CRC

Ramdisk image is corrupt or invalid
DNS323B1>

My chainloaded u-boot is configured in an image to load at 0x3000000, and stay there (no relocation), if I have understood these parameters correctly:

-a 0x3000000 -e 0x3000000

Can anyone see what I am doing wrong?

Many thanks!

Rogan
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Signature · 1 line
G?rald
#2 lore raw
Quoted 6 lines · G?rald Kerma

Dear Rogan,

I've you set the uboot env machid to the correct value ? setenv machid<HexValue>
just replace HexValue with the correct MACH_TYPE.

Quoted 6 lines

You must then see something like :
Using machid 0xa76 from environment
after kernel loaded by uboot.

Best regards,

Hi Gerald,

Thanks for the hint. That'll make it easier to handle the difference between the official and de facto machine ids.

Unfortunately, I don't even get to that point. It seems that my true problem is in the memmove function.

Rogan

#3 lore raw
In reply to Rogan Dawes
Quoted 78 lines · Rogan Dawes

Hi folks,

I'm trying to get mainline u-boot working on my DNS323 (Orion5x based). Until I am confident in the config, I'm using a chainloaded approach, wrapping my featureful u-boot in an image file:

$ mkimage -A arm -O u-boot -T kernel -C none -a 0x3000000 -e 0x3000000
-n "UBoot dns323" -d u-boot.bin uImage.bin

I am trying to boot the default kernel that is already flashed into the device first. The first problem is that the DNS323 uses an incorrect mach-type value of 526, while the registered value is 1542. See
<http://wiki.dns323.info/software:kernel>). I have modified arch/arm/include/asm/mach-types.h to set MACH_TYPE_DNS323 to the "correct" Dlink value, which should match what the default kernel is expecting.

Unfortunately, all I get is:

DNS323B1> bootm FF820000
## Booting kernel from Legacy Image at ff820000 ...

     Image Name:   Linux-2.6.12.6-arm1
     Image Type:   ARM Linux Kernel Image (uncompressed)
     Data Size:    1490204 Bytes = 1.4 MiB

Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ...

and it hangs there.

That appears to be this code from cmd_bootm:

          case IH_COMP_NONE:
                  if (load == blob_start) {
                          printf ("   XIP %s ... ", type_name);
                  } else {
                          printf ("   Loading %s ... ", type_name);
                          memmove_wd ((void *)load, (void *)image_start,
                                          image_len, CHUNKSZ);
                  }
                  *load_end = load + image_len;
                  puts("OK\n");
                  break;

So, the memmove_wd never completes, it seems.

I added a debug statement at the top of memmove_wd, and got:

Moving memory from ff820040 to 00008000

Is that because the uImage header is 64 bytes?

Also, the following suggests that there may be something wrong with the addresses that I am using:

DNS323B1> bootm FF820000 FF9A0000
## Booting kernel from Legacy Image at ff820000 ...

     Image Name:   Linux-2.6.12.6-arm1
     Image Type:   ARM Linux Kernel Image (uncompressed)
     Data Size:    1490204 Bytes = 1.4 MiB
     Load Address: 00008000
     Entry Point:  00008000
     Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at ff9a0000 ...
     Image Name:   Ramdisk
     Image Type:   ARM Linux RAMDisk Image (gzip compressed)
     Data Size:    5240600 Bytes = 5 MiB
     Load Address: 00800000
     Entry Point:  00800000
     Verifying Checksum ... Bad Data CRC

Ramdisk image is corrupt or invalid
DNS323B1>

My chainloaded u-boot is configured in an image to load at 0x3000000, and stay there (no relocation), if I have understood these parameters correctly:

Quoted 7 lines

-a 0x3000000 -e 0x3000000

Can anyone see what I am doing wrong?

Many thanks!

Rogan

So I changed memmove_wd to use the watchdog style of memmove'ing, in small chunks to try to track down where the problem arises. I used 1kB chunks, and got:

Moving 1024 of 611612 bytes from ff8f6840 to 000de800 Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00 Moving 1024 of 609564 bytes from ff8f7040 to 000df000

before it finally hung.

So, I checked what was at that address:

DNS323B1> md.b 000df000 400
000df000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df040: ff ff ff ff ff ff ff ff ff df ff ff ff ff ff ff
................
000df050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df070: ff ff ff ff bf ff ff ff ff ff ff ff ff f7 ff ff
................
000df080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df150: ff ff ff ff ff ff ff ff ff f7 ff ff ff ff ff ff
................
000df160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df180: ff df ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df200: ff ff ff ff ff 7f ff ff ff ff ff ff ff ff ff ff
................
000df210: ff ff ff ff 03 00 00 00 17 f2 0d 00 f8 1f 11 00
................
000df220: 01 ea 11 00 02 00 00 00 00 00 00 00 00 00 00 00
................
000df230: 30 f2 0d 00 02 00 00 00 ff ff ff ff 30 f2 0d 00 0...........0...
000df240: 2e 2e 2e 2e 2e 2e 2e 2e 30 2e 2e 2e 00 ff ff ff ........0.......
000df250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df280: 00 f0 0d 00 e4 fe 0d 00 01 00 00 00 00 04 00 00
................
000df290: 03 00 00 00 00 00 00 00 00 00 00 00 e0 bd 10 00
................
000df2a0: 10 00 00 00 d8 d0 10 00 ff ff ff ff 94 00 12 00
................
000df2b0: 03 00 00 00 ef 03 00 00 00 00 00 00 00 00 00 00
................
000df2c0: f5 f6 0d 00 b0 01 11 00 ff ff ff ff e4 f2 0d 00
................
000df2d0: e4 f6 0d 00 00 00 00 00 f5 fa 0d 00 01 00 00 00
................
000df2e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df2f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df370: ff df ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df3a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df3b0: ff ff ff ff ff ff ff ff ff ff ff ff ff fb ff ff
................
000df3c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df3d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df3e0: ff ff ff ff ff ff ef ff ff ff ff ff ff ff ff ff
................
000df3f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
DNS323B1>
000df400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df410: ff ff ff ff ff ff ff ff ff ff ff bf ff ff ff ff
................
000df420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df540: ff ff ff ff ff ff ff ff ff ff ff 7f ff ff ff ff
................
000df550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df5a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df5b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df5c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df5d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff fd
................
000df5e0: ff ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff
................
000df5f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 ....md.b.000df00
000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 0.400...........
000df700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df730: ff ff ff ff ff ff ff ff ff ff ff ff ff 7f ff ff
................
000df740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7a0: ff ff ff ff ff ff ff ff ff ff ff f7 ff ff ff ff
................
000df7b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7f0: ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff
................
DNS323B1>

The first 1kB was not particularly interesting (to me). But the next chunk showed something interesting at 000df6e0:

000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 ....md.b.000df00
000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 0.400...........

i.e. the command I had just executed.

So, it seems that for some reason, even though I tried to place my chain loaded u-boot out of harms way at 0x3000000, for some reason, it was still allocating memory at a lower address, precisely where the kernel is supposed to be copied to for execution.

Can anyone explain why this happens? Or what I can do to fix it?

Many thanks!

Rogan

#4 lore raw

Dear Rogan Dawes,

Quoted 11 lines · In message <[email protected]> you wrote:
Quoted 11 lines

DNS323B1> bootm FF820000
## Booting kernel from Legacy Image at ff820000 ...

     Image Name:   Linux-2.6.12.6-arm1
     Image Type:   ARM Linux Kernel Image (uncompressed)
     Data Size:    1490204 Bytes = 1.4 MiB

Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ...

Quoted 1 line
Quoted 1 line

and it hangs there.

Are you absolutely sure that you have RAM in your system at 0x8000? I doubt that your Load Address/Entry Point settings are correct.

Quoted 3 lines
Quoted 3 lines

Moving memory from ff820040 to 00008000

Is that because the uImage header is 64 bytes?

The offset 0x40 is becaus eof the header, the 0x00008000 is because your Load Address setting.

Quoted 8 lines
Quoted 8 lines

## Loading init Ramdisk from Legacy Image at ff9a0000 ...

     Image Name:   Ramdisk
     Image Type:   ARM Linux RAMDisk Image (gzip compressed)
     Data Size:    5240600 Bytes = 5 MiB
     Load Address: 00800000
     Entry Point:  00800000
     Verifying Checksum ... Bad Data CRC

Ramdisk image is corrupt or invalid

Is there RAM at 0x00800000 ?

Quoted 1 line

So, I checked what was at that address:

Hm... instead of trying random things I recommend to apply common sense. Have a look at the memory map for your system - which memory types and register banks etc. are mapped to which address ragens? Where is your RAM and how big is it? I seriously doubt that you have RAM at these low addresses.

Quoted 8 lines

The first 1kB was not particularly interesting (to me). But the next chunk showed something interesting at 000df6e0:

000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 ....md.b.000df00
000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 0.400...........

Quoted 8 lines

i.e. the command I had just executed.

So, it seems that for some reason, even though I tried to place my chain loaded u-boot out of harms way at 0x3000000, for some reason, it was still allocating memory at a lower address, precisely where the kernel is supposed to be copied to for execution.

Can anyone explain why this happens? Or what I can do to fix it?

We don;t yuour hardware, we don't know your board configuration, we don't know your code...

Best regards,

Wolfgang Denk

Signature · 5 lines
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
Was hei?t Windows auf Indianisch? - "Wei?er  Mann,  der  auf  Sanduhr
wartet!"
#5 lore raw
Quoted 14 lines · Wolfgang Denk

Dear Rogan Dawes,

Quoted 11 lines · In message<[email protected]> you wrote:
Quoted 11 lines

DNS323B1> bootm FF820000
## Booting kernel from Legacy Image at ff820000 ...

      Image Name:   Linux-2.6.12.6-arm1
      Image Type:   ARM Linux Kernel Image (uncompressed)
      Data Size:    1490204 Bytes = 1.4 MiB

Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ...

Quoted 4 lines
Quoted 1 line
Quoted 1 line

and it hangs there.

Are you absolutely sure that you have RAM in your system at 0x8000? I doubt that your Load Address/Entry Point settings are correct.

Hi Wolfgang,

This is the default kernel that was shipped with the device, and so those are the settings that worked with the original u-boot.

Quoted 4 lines
Quoted 2 lines
Quoted 2 lines

Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalid

Is there RAM at 0x00800000 ?

Again, this is from the default vendor ramdisk that ships with the device.

Quoted 7 lines
Quoted 1 line

So, I checked what was at that address:

Hm... instead of trying random things I recommend to apply common sense. Have a look at the memory map for your system - which memory types and register banks etc. are mapped to which address ragens? Where is your RAM and how big is it? I seriously doubt that you have RAM at these low addresses.

I looked at the CPU datasheet, which shows that:

DDR SDRAM CS0 is by default 256 MB at 0000.0000?0FFF.FFFF

There doesn't appear to be any code in the orion5x setup that sets this to anything else:

$ git grep ORION5X_ATTR_DRAM_CS0
arch/arm/include/asm/arch-orion5x/cpu.h:        ORION5X_ATTR_DRAM_CS0 =
0x0e,
$

The device has 64MB RAM in two banks.

Quoted 15 lines
Quoted 15 lines

The first 1kB was not particularly interesting (to me). But the next chunk showed something interesting at 000df6e0:

000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 ....md.b.000df00
000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 0.400...........

i.e. the command I had just executed.

So, it seems that for some reason, even though I tried to place my chain loaded u-boot out of harms way at 0x3000000, for some reason, it was still allocating memory at a lower address, precisely where the kernel is supposed to be copied to for execution.

Quoted 4 lines
Quoted 1 line

Can anyone explain why this happens? Or what I can do to fix it?

We don;t yuour hardware, we don't know your board configuration, we don't know your code...

Patch to follow this mail.

Thanks for your help!

Rogan

#6 lore raw

PATCH 1/1 non-working dns323 config

From: Rogan Dawes <[email protected]>

---
 arch/arm/include/asm/arch-orion5x/cpu.h |    2 +-
 board/D-Link/dns323_b1/Makefile         |   53 +++++++++++++
 board/D-Link/dns323_b1/config.mk        |   27 +++++++
 board/D-Link/dns323_b1/dns323_b1.c      |  129 +++++++++++++++++++++++++++++++
 board/D-Link/dns323_b1/dns323_b1.h      |   41 ++++++++++
 boards.cfg                              |    1 +
 include/configs/dns323_b1.h             |  126 ++++++++++++++++++++++++++++++
 7 files changed, 378 insertions(+), 1 deletions(-)
 create mode 100644 board/D-Link/dns323_b1/Makefile
 create mode 100644 board/D-Link/dns323_b1/config.mk
 create mode 100644 board/D-Link/dns323_b1/dns323_b1.c
 create mode 100644 board/D-Link/dns323_b1/dns323_b1.h
 create mode 100644 include/configs/dns323_b1.h
arch/arm/include/asm/arch-orion5x/cpu.h +1 -1
index 80717f8..6ce02a9 100644
@@ -76,7 +76,7 @@ enum orion5x_cpu_attrib {
 
 /*
  * Device Address MAP BAR values
-/*
+ *
  * All addresses and sizes not defined by board code
  * will be given default values here.
  */
board/D-Link/dns323_b1/Makefile new file +53 -0

53 lines not on this page · raw message

board/D-Link/dns323_b1/config.mk new file +27 -0
new file mode 100644
index 0000000..3dec1aa
@@ -0,0 +1,27 @@
+#
+# Copyright (C) 2010 Albert ARIBAUD <[email protected]>
+#
+# (C) Copyright 2009
+# Marvell Semiconductor <www.marvell.com>
+# Written-by: Prafulla Wadaskar <[email protected]>
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+TEXT_BASE = 0x00100000
board/D-Link/dns323_b1/dns323_b1.c new file +129 -0

129 lines not on this page · raw message

board/D-Link/dns323_b1/dns323_b1.h new file +41 -0

41 lines not on this page · raw message

boards.cfg +1 -0
index 69c6897..37b980a 100644
@@ -253,6 +253,7 @@ sheevaplug	arm	arm926ejs	-		Marvell		kirkwood
 imx27lite	arm	arm926ejs	imx27lite	logicpd		mx27
 magnesium	arm	arm926ejs	imx27lite	logicpd		mx27
 omap5912osk	arm	arm926ejs	-		ti		omap
+dns323_b1	arm	arm926ejs	-		D-Link		orion5x
 edminiv2	arm	arm926ejs	-		LaCie		orion5x
 omap3_overo	arm	armv7		overo		-		omap3
 omap3_pandora	arm	armv7		pandora		-		omap3
include/configs/dns323_b1.h new file +126 -0

126 lines not on this page · raw message

Signature · 1 line
1.7.0.4
#7 lore raw

PATCH 1/1 non-working dns323 config

Dear Rogan Dawes,

Quoted 4 lines · In message <1281993065-19803-1-git-send-email-user@aphrodite> you wrote:

From: Rogan Dawes <[email protected]>

---
 arch/arm/include/asm/arch-orion5x/cpu.h |    2 +-

This is a fix that is good... If there only was a SoB line...

Quoted 4 lines
 board/D-Link/dns323_b1/Makefile         |   53 +++++++++++++
 board/D-Link/dns323_b1/config.mk        |   27 +++++++
 board/D-Link/dns323_b1/dns323_b1.c      |  129 +++++++++++++++++++++++++++++++
 board/D-Link/dns323_b1/dns323_b1.h      |   41 ++++++++++
Quoted 8 lines
 boards.cfg                              |    1 +
 include/configs/dns323_b1.h             |  126 ++++++++++++++++++++++++++++++
 7 files changed, 378 insertions(+), 1 deletions(-)
 create mode 100644 board/D-Link/dns323_b1/Makefile
 create mode 100644 board/D-Link/dns323_b1/config.mk
 create mode 100644 board/D-Link/dns323_b1/dns323_b1.c
 create mode 100644 board/D-Link/dns323_b1/dns323_b1.h
 create mode 100644 include/configs/dns323_b1.h

But this is an attempt to sneak in an incomplete (no entries to MAKEALL or MAINTAINER, for example) board when no MW is open.

NAK for this part.

Best regards,

Wolfgang Denk

Signature · 5 lines
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
"I've finally learned what `upward compatible' means. It means we get
to keep all our old mistakes." - Dennie van Tassel
#8 lore raw

PATCH 1/1 non-working dns323 config

Quoted 5 lines · Wolfgang Denk

But this is an attempt to sneak in an incomplete (no entries to MAKEALL or MAINTAINER, for example) board when no MW is open.

NAK for this part.

Hi Wolfgang,

The patch was simply to allow people to see my non-working config, in the hope of getting suggestions on how to improve it.

I didn't see much point in a SoB until it was ready to be submitted for real.

Thanks for taking a look at it, though.

Rogan

#9 lore raw

PATCH 1/1 non-working dns323 config

Dear Rogan Dawes,

Quoted 3 lines · In message <[email protected]> you wrote:

The patch was simply to allow people to see my non-working config, in the hope of getting suggestions on how to improve it.

Then please mark it as such in the subject - adding a "[RFC]" or similar tag would help.

Best regards,

Wolfgang Denk

Signature · 7 lines
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
Quote from the Boss after overriding the decision of a task force  he
created  to  find  a  solution:  "I'm  sorry  if  I ever gave you the
impression your input would have any effect on my  decision  for  the
outcome of this project!"
#10 lore raw

PATCH 1/1 non-working dns323 config

Quoted 9 lines · Wolfgang Denk

Dear Rogan Dawes,

Quoted 3 lines · In message <[email protected]> you wrote:

The patch was simply to allow people to see my non-working config, in the hope of getting suggestions on how to improve it.

Then please mark it as such in the subject - adding a "[RFC]" or similar tag would help.

Sorry, git-send-email newbie here.

Will figure it out for the next time around.

Rogan

#11 lore raw

PATCH 1/1 non-working dns323 config

Dear Rogan Dawes,

Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 3 lines

Then please mark it as such in the subject - adding a "[RFC]" or similar tag would help.

Sorry, git-send-email newbie here.

Will figure it out for the next time around.

You can manually edit the patch before handing it over to git-send-email, or you can use the "--subject-prefix" option with git-format-patch right when you create it.

Best regards,

Wolfgang Denk

Signature · 5 lines
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
The only way to get rid of a temptation is to yield to it.
                                                        - Oscar Wilde
#12 lore raw
In reply to Rogan Dawes

Dear Rogan Dawes,

Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines

Are you absolutely sure that you have RAM in your system at 0x8000? I doubt that your Load Address/Entry Point settings are correct.

This is the default kernel that was shipped with the device, and so those are the settings that worked with the original u-boot.

Why do you not simply answer the question I asked?

Why do you not think about what I asked, and why?

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines

Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalid

Is there RAM at 0x00800000 ?

Again, this is from the default vendor ramdisk that ships with the device.

Why should I care about where this is coming from?

On such a base I cannot help you.

Best regards,

Wolfgang Denk

Signature · 6 lines
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
Steal five dollars and you were a petty  thief.  Steal  thousands  of
dollars and you are either a government or a hero.
                                   - Terry Pratchett, _Going_Postal_
#13 lore raw
Quoted 11 lines · Wolfgang Denk

Dear Rogan Dawes,

Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines

Are you absolutely sure that you have RAM in your system at 0x8000? I doubt that your Load Address/Entry Point settings are correct.

This is the default kernel that was shipped with the device, and so those are the settings that worked with the original u-boot.

Why do you not simply answer the question I asked?

Because I don't know how to get the answer to your question.

My assumption is that, since this is the vendor kernel, and that this is the working configuration that they were using, that there MUST be memory at that location, otherwise the thousands of devices that they shipped would surely not have worked.

Clearly there is a different configuration somewhere between the vendor u-boot, and what mainline is using. All I am trying to do is figure out where that difference might be.

Quoted 1 line

Why do you not think about what I asked, and why?

I tried to find out by looking up the default CS0 value from the chipset, and seeing if there were any changes made to it in current u-boot. That's all I know how to do.

Quoted 10 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines

Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalid

Is there RAM at 0x00800000 ?

Again, this is from the default vendor ramdisk that ships with the device.

Why should I care about where this is coming from?

On such a base I cannot help you.

Thanks for all the help you have given me so far. I'm sorry to have been such a pain.

Rogan

#14 lore raw
In reply to Rogan Dawes

Le 16/08/2010 22:15, Rogan Dawes a ?crit :

Quoted 374 lines · Rogan Dawes
Quoted 78 lines

Hi folks,

I'm trying to get mainline u-boot working on my DNS323 (Orion5x based). Until I am confident in the config, I'm using a chainloaded approach, wrapping my featureful u-boot in an image file:

$ mkimage -A arm -O u-boot -T kernel -C none -a 0x3000000 -e 0x3000000
-n "UBoot dns323" -d u-boot.bin uImage.bin

I am trying to boot the default kernel that is already flashed into the device first. The first problem is that the DNS323 uses an incorrect mach-type value of 526, while the registered value is 1542. See
<http://wiki.dns323.info/software:kernel>). I have modified arch/arm/include/asm/mach-types.h to set MACH_TYPE_DNS323 to the "correct" Dlink value, which should match what the default kernel is expecting.

Unfortunately, all I get is:

DNS323B1> bootm FF820000
## Booting kernel from Legacy Image at ff820000 ...

      Image Name:   Linux-2.6.12.6-arm1
      Image Type:   ARM Linux Kernel Image (uncompressed)
      Data Size:    1490204 Bytes = 1.4 MiB

Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ...

and it hangs there.

That appears to be this code from cmd_bootm:

           case IH_COMP_NONE:
                   if (load == blob_start) {
                           printf ("   XIP %s ... ", type_name);
                   } else {
                           printf ("   Loading %s ... ", type_name);
                           memmove_wd ((void *)load, (void *)image_start,
                                           image_len, CHUNKSZ);
                   }
                   *load_end = load + image_len;
                   puts("OK\n");
                   break;

So, the memmove_wd never completes, it seems.

I added a debug statement at the top of memmove_wd, and got:

Moving memory from ff820040 to 00008000

Is that because the uImage header is 64 bytes?

Also, the following suggests that there may be something wrong with the addresses that I am using:

DNS323B1> bootm FF820000 FF9A0000
## Booting kernel from Legacy Image at ff820000 ...

      Image Name:   Linux-2.6.12.6-arm1
      Image Type:   ARM Linux Kernel Image (uncompressed)
      Data Size:    1490204 Bytes = 1.4 MiB
      Load Address: 00008000
      Entry Point:  00008000
      Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at ff9a0000 ...
      Image Name:   Ramdisk
      Image Type:   ARM Linux RAMDisk Image (gzip compressed)
      Data Size:    5240600 Bytes = 5 MiB
      Load Address: 00800000
      Entry Point:  00800000
      Verifying Checksum ... Bad Data CRC

Ramdisk image is corrupt or invalid
DNS323B1>

My chainloaded u-boot is configured in an image to load at 0x3000000, and stay there (no relocation), if I have understood these parameters correctly:

Quoted 7 lines

-a 0x3000000 -e 0x3000000

Can anyone see what I am doing wrong?

Many thanks!

Rogan

So I changed memmove_wd to use the watchdog style of memmove'ing, in small chunks to try to track down where the problem arises. I used 1kB chunks, and got:

Moving 1024 of 611612 bytes from ff8f6840 to 000de800 Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00 Moving 1024 of 609564 bytes from ff8f7040 to 000df000

before it finally hung.

So, I checked what was at that address:

DNS323B1> md.b 000df000 400
000df000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df040: ff ff ff ff ff ff ff ff ff df ff ff ff ff ff ff
................
000df050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df070: ff ff ff ff bf ff ff ff ff ff ff ff ff f7 ff ff
................
000df080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df0f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df150: ff ff ff ff ff ff ff ff ff f7 ff ff ff ff ff ff
................
000df160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df180: ff df ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df1f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df200: ff ff ff ff ff 7f ff ff ff ff ff ff ff ff ff ff
................
000df210: ff ff ff ff 03 00 00 00 17 f2 0d 00 f8 1f 11 00
................
000df220: 01 ea 11 00 02 00 00 00 00 00 00 00 00 00 00 00
................
000df230: 30 f2 0d 00 02 00 00 00 ff ff ff ff 30 f2 0d 00 0...........0...
000df240: 2e 2e 2e 2e 2e 2e 2e 2e 30 2e 2e 2e 00 ff ff ff ........0.......
000df250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df280: 00 f0 0d 00 e4 fe 0d 00 01 00 00 00 00 04 00 00
................
000df290: 03 00 00 00 00 00 00 00 00 00 00 00 e0 bd 10 00
................
000df2a0: 10 00 00 00 d8 d0 10 00 ff ff ff ff 94 00 12 00
................
000df2b0: 03 00 00 00 ef 03 00 00 00 00 00 00 00 00 00 00
................
000df2c0: f5 f6 0d 00 b0 01 11 00 ff ff ff ff e4 f2 0d 00
................
000df2d0: e4 f6 0d 00 00 00 00 00 f5 fa 0d 00 01 00 00 00
................
000df2e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df2f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df370: ff df ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df3a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df3b0: ff ff ff ff ff ff ff ff ff ff ff ff ff fb ff ff
................
000df3c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df3d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df3e0: ff ff ff ff ff ff ef ff ff ff ff ff ff ff ff ff
................
000df3f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
DNS323B1>
000df400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df410: ff ff ff ff ff ff ff ff ff ff ff bf ff ff ff ff
................
000df420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df4f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df540: ff ff ff ff ff ff ff ff ff ff ff 7f ff ff ff ff
................
000df550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df5a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df5b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df5c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df5d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff fd
................
000df5e0: ff ff ff ff ff fe ff ff ff ff ff ff ff ff ff ff
................
000df5f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 ....md.b.000df00
000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 0.400...........
000df700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df730: ff ff ff ff ff ff ff ff ff ff ff ff ff 7f ff ff
................
000df740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7a0: ff ff ff ff ff ff ff ff ff ff ff f7 ff ff ff ff
................
000df7b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
000df7f0: ff ff ff fe ff ff ff ff ff ff ff ff ff ff ff ff
................
DNS323B1>

The first 1kB was not particularly interesting (to me). But the next chunk showed something interesting at 000df6e0:

000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 ....md.b.000df00
000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 0.400...........

i.e. the command I had just executed.

So, it seems that for some reason, even though I tried to place my chain loaded u-boot out of harms way at 0x3000000, for some reason, it was still allocating memory at a lower address, precisely where the kernel is supposed to be copied to for execution.

Quoted 5 lines

Can anyone explain why this happens? Or what I can do to fix it?

Many thanks!

Rogan

(quick note to Wolfgang: yes, there is RAM at 0x00008000 on these machines. All orion5x based machines have RAM start at 0, and u-boot makes sure SDRAM is set up this way)

Rogan,

You cannot tell from your log output that memmove never completes. It could as well be the kernel not outputting to the console, or failing to start at all even though the move was ok.

The first thing you should do is make sure that you pass the right machine-id, but also that you pass ATAGs correctly to the kernel -- it seems that at least some LaCie custom u-boot implementations use an env variable ('mainlineKernel', IIRC) to differenciate between mainline and LaCie custom kernels. Maybe your HW was designed the same way. Best is you look up the u-boot source code provided by the manufacturer of your machine.

The second thing is to make sure your kernel uses the right console. Are you using netconsole? Maybe the manufacturer's kernel does not have netconsole. Do you use a serial (RS-232) console? Make sure the kernel has command line arguments to use it too.

Amicalement,

Signature · 1 line
Albert.
#15 lore raw
Quoted 9 lines · Albert ARIBAUD

(quick note to Wolfgang: yes, there is RAM at 0x00008000 on these machines. All orion5x based machines have RAM start at 0, and u-boot makes sure SDRAM is set up this way)

Rogan,

You cannot tell from your log output that memmove never completes. It could as well be the kernel not outputting to the console, or failing to start at all even though the move was ok.

Actually, I can tell that the memmove never completes (or if it does, it alters the code flow in the process):

Quoted 9 lines
Quoted 9 lines

So I changed memmove_wd to use the watchdog style of memmove'ing, in small chunks to try to track down where the problem arises. I used 1kB chunks, and got:

Moving 1024 of 611612 bytes from ff8f6840 to 000de800 Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00 Moving 1024 of 609564 bytes from ff8f7040 to 000df000

before it finally hung.

I had a debug statement in the loop, printing out the above at each iteration. Since it never completed the loop, copying/moving the entire kernel (609564 bytes remaining), I think it is safe to assume that it never got to the point of trying to boot the kernel.

Additionally, just doing a cp with the above parameters also hangs.

Quoted 8 lines

The first thing you should do is make sure that you pass the right machine-id, but also that you pass ATAGs correctly to the kernel -- it seems that at least some LaCie custom u-boot implementations use an env variable ('mainlineKernel', IIRC) to differenciate between mainline and LaCie custom kernels. Maybe your HW was designed the same way. Best is you look up the u-boot source code provided by the manufacturer of your machine.

Quoted 6 lines

The second thing is to make sure your kernel uses the right console. Are you using netconsole? Maybe the manufacturer's kernel does not have netconsole. Do you use a serial (RS-232) console? Make sure the kernel has command line arguments to use it too.

Amicalement,

I'll check those once I have got the copy working correctly :-)

FWIW, I'm using a serial console, not netconsole. And the bootargs include the console definition.

Based on what Wolfgang has said, perhaps the address space registers are set up differently in the vendor u-boot to what the current mainline is doing. I'll check that next, I think.

I'm just struggling to understand how the last command that I executed ended up in the memory where I was trying to copy the kernel to. That suggests that U-boot is actively using that memory for some reason, and copying the kernel image over the top of it seems like a very good way to cause u-boot to stop behaving consistently, and hang.

Thanks anyway.

Rogan

#16 lore raw

Le 17/08/2010 12:21, Rogan Dawes a ?crit :

Quoted 22 lines · Albert ARIBAUD
Quoted 9 lines

(quick note to Wolfgang: yes, there is RAM at 0x00008000 on these machines. All orion5x based machines have RAM start at 0, and u-boot makes sure SDRAM is set up this way)

Rogan,

You cannot tell from your log output that memmove never completes. It could as well be the kernel not outputting to the console, or failing to start at all even though the move was ok.

Actually, I can tell that the memmove never completes (or if it does, it alters the code flow in the process):

Quoted 8 lines
Quoted 8 lines

So I changed memmove_wd to use the watchdog style of memmove'ing, in small chunks to try to track down where the problem arises. I used 1kB chunks, and got:

Moving 1024 of 611612 bytes from ff8f6840 to 000de800 Moving 1024 of 610588 bytes from ff8f6c40 to 000dec00 Moving 1024 of 609564 bytes from ff8f7040 to 000df000

Quoted 6 lines
Quoted 1 line
Quoted 1 line

before it finally hung.

I had a debug statement in the loop, printing out the above at each iteration. Since it never completed the loop, copying/moving the entire kernel (609564 bytes remaining), I think it is safe to assume that it never got to the point of trying to boot the kernel.

Sorry, I'd missed that one.

Quoted 11 lines

Additionally, just doing a cp with the above parameters also hangs.

Based on what Wolfgang has said, perhaps the address space registers are set up differently in the vendor u-boot to what the current mainline is doing. I'll check that next, I think.

I'm just struggling to understand how the last command that I executed ended up in the memory where I was trying to copy the kernel to. That suggests that U-boot is actively using that memory for some reason, and copying the kernel image over the top of it seems like a very good way to cause u-boot to stop behaving consistently, and hang.

I do think you're overwriting u-boot with the kernel. What location does your u-boot load at? What location is the manufacturer's u-boot supposed to be loading at? See their TEXT_BASE in the board config file (or link file maybe).

FYI, in my u-boot edminiv2 support code, I had issues with big kernels, so I decided to move u-boot's final location as high in RAM as by board allows, so that it never will be overwritten by Linux (unless I load a 63+ MB kernel, that is :) )

Quoted 3 lines

Thanks anyway.

Rogan

You're welcome.

Amicalement,

Signature · 1 line
Albert.
#17 lore raw
Quoted 6 lines · Albert ARIBAUD
Quoted 4 lines

I had a debug statement in the loop, printing out the above at each iteration. Since it never completed the loop, copying/moving the entire kernel (609564 bytes remaining), I think it is safe to assume that it never got to the point of trying to boot the kernel.

Sorry, I'd missed that one.

No problem, there was a lot of data there.

Quoted 4 lines

I do think you're overwriting u-boot with the kernel. What location does your u-boot load at? What location is the manufacturer's u-boot supposed to be loading at? See their TEXT_BASE in the board config file (or link file maybe).

My U-Boot is configured to load at 0x3000000 (48MB), as far out of the way as possible. That is, using the mkimage tool, which is how I get my rebuilt u-boot onto the machine. This is my command line:

$ make clean mrproper dns323_b1_config && make && \
mkimage -A arm -O u-boot -T kernel -C none \
-a 0x3000000 -e 0x3000000 -n "UBoot dns323" \
-d u-boot.bin uImage.bin

My TEXT_BASE is identical to yours: 0x100000

Does that make a difference, if the u-boot image is chain loaded from another one?

This is what I found in the vendor code:

./board/mv88fxx81/db88f5181/config_tiny.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config_prpmc.mk:TEXT_BASE = 0x02f10000 ./board/mv88fxx81/db88f5181/config_def.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config_tiny_voip.mk:TEXT_BASE = 0x00f40000 ./board/mv88fxx81/db88f1181/config.mk:TEXT_BASE = 0x00f00000

I'm not sure which config has been used for the version of u-boot on my board, though.

At any rate, those are all substantially higher than I am currently using.

I'll try with a higher value, and see what happens.

Quoted 4 lines

FYI, in my u-boot edminiv2 support code, I had issues with big kernels, so I decided to move u-boot's final location as high in RAM as by board allows, so that it never will be overwritten by Linux (unless I load a 63+ MB kernel, that is :) )

That was my reasoning with the 48MB, too :-)

Rogan

#18 lore raw
Quoted 2 lines · Rogan Dawes

I'll try with a higher value, and see what happens.

So, I tried with TEXT_BASE=f10000, and I got a bit further:

DNS323B1> bootm FF820000
## Booting kernel from Legacy Image at ff820000 ...

   Image Name:   Linux-2.6.12.6-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1490204 Bytes = 1.4 MiB

Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Using machid 0x526 from environment

Starting kernel ...

Uncompressing Linux................................................................................................... done, booting the kernel.

So, that does appear to have been (at least part of) the problem.

Now to figure out why I'm not getting any further than this. (And why the vendor ramdisk is giving me CRC errors).

Rogan

#19 lore raw

Le 17/08/2010 13:42, Rogan Dawes a ?crit :

Quoted 18 lines · Rogan Dawes
Quoted 2 lines

I'll try with a higher value, and see what happens.

So, I tried with TEXT_BASE=f10000, and I got a bit further:

DNS323B1> bootm FF820000
## Booting kernel from Legacy Image at ff820000 ...

    Image Name:   Linux-2.6.12.6-arm1
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    1490204 Bytes = 1.4 MiB

Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Using machid 0x526 from environment

Quoted 7 lines

Starting kernel ...

Uncompressing Linux................................................................................................... done, booting the kernel.

So, that does appear to have been (at least part of) the problem.

Ok, so u-boot is now out of the way of the linux image load area.

Quoted 2 lines

Now to figure out why I'm not getting any further than this. (And why the vendor ramdisk is giving me CRC errors).

What is the actual command you use for booting your kernel? IIUC (and if I trust the few experiments I did on edminiv2 with ramdisks) you need to pass the ramdisk address to the bootm command, e.g. bootm ff820000 ff8xxxxx (where xxxxx is your ramdisk's location in flash (I'm assuming your ramdisk image is in flash as your kernel image is). You did an 'iminfo' on both images to verify their integrity, didn't you?

Amicalement,

Signature · 1 line
Albert.
#20 lore raw
Quoted 5 lines · Albert ARIBAUD

Ok, so u-boot is now out of the way of the linux image load area.

Quoted 2 lines

Now to figure out why I'm not getting any further than this. (And why the vendor ramdisk is giving me CRC errors).

Quoted 8 lines

What is the actual command you use for booting your kernel? IIUC (and if I trust the few experiments I did on edminiv2 with ramdisks) you need to pass the ramdisk address to the bootm command, e.g. bootm ff820000 ff8xxxxx (where xxxxx is your ramdisk's location in flash (I'm assuming your ramdisk image is in flash as your kernel image is). You did an 'iminfo' on both images to verify their integrity, didn't you?

Amicalement,

Well, there are two approaches. The vendor u-boot uses two parameters to pass the address of the ramdisk to the kernel.

Without that parameter, the kernel should still boot, and show the initial messages, until it tries to mount its root filesystem, at which point it should panic.

I'm not passing the second parameter at this stage, because the ramdisk is failing the CRC32 check for some reason. It may be that the CRC32 calculation has changed between 1.1.1 which was the base for the vendor u-boot, and mainline. e.g. rather than being calculated over the precise length of the data, it is calculated over the entire block. Just a guess, of course.

But until I can get the standard firmware to boot from my replacement U-boot, I'll keep trying.

The hints I'm getting from googling for <u-boot "done, booting the kernel"> are suggesting that the problem is likely a machid mismatch.

And indeed, that WAS the problem.

I had been led to believe that it was possible to override the compiled in mach type by setting a "machid" environment variable. This would give me the best of both worlds - a u-boot compiled according to mainline registered numbers, with the ability to boot vendor firmware by simply setting an environment variable.

Unfortunately, this did not work for me :-(

-#define MACH_TYPE_DNS323 1542
+#define MACH_TYPE_DNS323 526

Making the above change results in a booting kernel, until the root fs can not be found.

Am I mistaken in expecting the machid environment variable trick to work?

Thanks

Rogan

#21 lore raw
Quoted 6 lines · Rogan Dawes

Am I mistaken in expecting the machid environment variable trick to work?

Thanks

Rogan

No, but mistaken in thinking that the machid was in decimal, when it is really in hex.

Now to figure out why the CRC calculations are different, and I'll have a fully functioning u-boot!

Thanks so much to everyone who has helped me get this far!

Rogan

#22 lore raw

Dear Rogan Dawes,

Quoted 6 lines · In message <[email protected]> you wrote:

No, but mistaken in thinking that the machid was in decimal, when it is really in hex.

Now to figure out why the CRC calculations are different, and I'll have a fully functioning u-boot!

For a test you could as ell disable CRC checking:

	=> setenv verify no
	=> save

Best regards,

Wolfgang Denk

Signature · 4 lines
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
It is much easier to suggest solutions when you know nothing
#23 lore raw
Quoted 10 lines · Wolfgang Denk

Dear Rogan Dawes,

Quoted 6 lines · In message <[email protected]> you wrote:

No, but mistaken in thinking that the machid was in decimal, when it is really in hex.

Now to figure out why the CRC calculations are different, and I'll have a fully functioning u-boot!

Quoted 9 lines

For a test you could as ell disable CRC checking:

	=> setenv verify no
	=> save

Best regards,

Wolfgang Denk

Hi Wolfgang,

Yes, I found that while I was trying to see if the CRC calculation had changed, but it did not work.

For some reason, the kernel didn't seem to think it had been given the ramdisk parameter. At least, I get the following error message:

Kernel panic - not syncing: VFS: Unable to mount root fs on

unknown-block(1,0)

Hmmm! Diff of the boot logs shows (mainline vs vendor):

< initrd (0xff9a0040 - 0xffe9f758) extends beyond physical memory - disabling initrd
---

Quoted 1 line

Using UBoot passing parameters structure

Also potentially interesting is:

< Memory: 64MB = 64MB total
< Memory: 61696KB available (2599K code, 462K data, 112K init)
---

Quoted 2 lines

Memory: 64MB 0MB 0MB 0MB = 64MB total
Memory: 56576KB available (2599K code, 462K data, 112K init)

It seems that the amount of memory is being passed differently to the kernel (1 bank vs 4)?

Keeping in mind that this is the same kernel executing, just with a different setup code or parameters.

I'll keep investigating.

Rogan

#24 lore raw

Dear Rogan Dawes,

Quoted 3 lines · In message <[email protected]> you wrote:

For some reason, the kernel didn't seem to think it had been given the ramdisk parameter. At least, I get the following error message:

Where is the ramdisk located? Make sure it is loaded into RAM (not flash!).

Best regards,

Wolfgang Denk

Signature · 7 lines
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
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy  arrangement  for
the people.                                       - Eleanor Roosevelt
#25 lore raw
Quoted 7 lines · Wolfgang Denk

Dear Rogan Dawes,

Quoted 3 lines · In message <[email protected]> you wrote:

For some reason, the kernel didn't seem to think it had been given the ramdisk parameter. At least, I get the following error message:

Quoted 6 lines

Where is the ramdisk located? Make sure it is loaded into RAM (not flash!).

Best regards,

Wolfgang Denk

Hi Wolfgang,

The ramdisk is located at ff9a0000 (in flash). Its image header relocates it to 00800000:

#26 lore raw

Dear Rogan Dawes,

Quoted 3 lines · In message <[email protected]> you wrote:

The ramdisk is located at ff9a0000 (in flash). Its image header relocates it to 00800000:

Try to copy the ramdisk to RAM, and pass the Linux kernl an address in RAM.

Try it.

Best regards,

Wolfgang Denk

Signature · 8 lines
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
I realize that command does have its fascination, even under  circum-
stances such as these, but I neither enjoy the idea of command nor am
I  frightened  of  it. It simply exists, and I will do whatever logi-
cally needs to be done.
	-- Spock, "The Galileo Seven", stardate 2812.7
#27 lore raw
Quoted 7 lines · Wolfgang Denk

Dear Rogan Dawes,

Quoted 3 lines · In message <[email protected]> you wrote:

The ramdisk is located at ff9a0000 (in flash). Its image header relocates it to 00800000:

Quoted 9 lines

Try to copy the ramdisk to RAM, and pass the Linux kernl an address in RAM.

Try it.

Best regards,

Wolfgang Denk

Hi Wolfgang,

Thanks for the suggestion. It did make a slight difference in the boot logs. bootcmd uses the default (in flash) location for the ramdisk, while the second one has a copy of the ramdisk image at 1600000 (including the header). Both logs are using mainline u-boot, not the vendor one.

< DNS323B1> run bootcmd

Quoted 1 line

DNS323B1> bootm ff820000 1600000

< ## Loading init Ramdisk from Legacy Image@ff9a0000 ...

Quoted 1 line

## Loading init Ramdisk from Legacy Image at 01600000 ...

< initrd (0xff9a0040 - 0xffe9f758) extends beyond physical memory - disabling initrd

Quoted 1 line

checking if image is initramfs...it isn't (no cpio magic); looks like

an initrd

Quoted 4 lines

Freeing initrd memory: 5117K

RAMDISK: Compressed image found at block 0
invalid compressed format (err=1)

So it seems that the ramdisk is getting corrupted somehow. And yet, it is fine using the vendor u-boot. It must be something that I am doing wrong.

Rogan

#28 lore raw

Dear Rogan Dawes,

Quoted 3 lines · In message <[email protected]> you wrote:

Thanks for the suggestion. It did make a slight difference in the boot logs. bootcmd uses the default (in flash) location for the ramdisk,

Actually it's a pretty significant difference, as for the first time you actually see the kernel trying to access the ramdisk.

Quoted 5 lines
Quoted 2 lines

RAMDISK: Compressed image found at block 0
invalid compressed format (err=1)

So it seems that the ramdisk is getting corrupted somehow. And yet, it is fine using the vendor u-boot. It must be something that I am doing wrong.

Try copying the raw ramdisk image (i. e. without the U-Boot header) to RAM, and try that one, i. e. something like

	=> cp.b ff9a0040 01600000 ...size...
	...
	=> bootm ff820000 1600000

Best regards,

Wolfgang Denk

Signature · 5 lines
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
If in any problem you find yourself doing an immense amount of  work,
the answer can be obtained by simple inspection.
#29 lore raw
Quoted 9 lines · Wolfgang Denk

Dear Rogan Dawes,

Quoted 3 lines · In message <[email protected]> you wrote:

Thanks for the suggestion. It did make a slight difference in the boot logs. bootcmd uses the default (in flash) location for the ramdisk,

Actually it's a pretty significant difference, as for the first time you actually see the kernel trying to access the ramdisk.

Good point! :-)

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines

RAMDISK: Compressed image found at block 0
invalid compressed format (err=1)

So it seems that the ramdisk is getting corrupted somehow. And yet, it is fine using the vendor u-boot. It must be something that I am doing wrong.

Quoted 6 lines

Try copying the raw ramdisk image (i. e. without the U-Boot header) to RAM, and try that one, i. e. something like

	=> cp.b ff9a0040 01600000 ...size...
	...
	=> bootm ff820000 1600000

Unfortunately, U-boot is expecting the second parameter to point to a uImage-wrapped ramdisk, not just raw bytes:

DNS323B1> cp.b ff9a0040 1600000 4ff718 DNS323B1> bootm ff820000 1600000
## Booting kernel from Legacy Image at ff820000 ...

   Image Name:   Linux-2.6.12.6-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1490204 Bytes = 1.4 MiB

Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
DNS323B1>

Why does it make a difference if it is in RAM vs in flash? I have 8MB of flash located at ff800000, so that reaches all the way to 0xffffffff. Surely that should be Ok? Besides, U-boot is supposed to copy the data in the image to the specified destination address, isn't it?

Rogan

#30 lore raw

Dear Rogan Dawes,

Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 7 lines

Try copying the raw ramdisk image (i. e. without the U-Boot header) to RAM, and try that one, i. e. something like

	=> cp.b ff9a0040 01600000 ...size...
	...
	=> bootm ff820000 1600000

Unfortunately, U-boot is expecting the second parameter to point to a uImage-wrapped ramdisk, not just raw bytes:

Yes, I know. I was just trying out some things - I don't know in which way your U-Boot version might have been modified...

Quoted 1 line

Why does it make a difference if it is in RAM vs in flash? I have 8MB of

Your kernel may not be able to pick up a ramdisk image in flash.

Mainline ARM cannot do that, for example.

[Patches to support that have been submitted, but rejected.]

Quoted 2 lines

Surely that should be Ok? Besides, U-boot is supposed to copy the data in the image to the specified destination address, isn't it?

No, why should it copy the image? It just verifies that the checksum is OK, and then passes the address to the kernel. The kernel will have to copy it anyway when uncompressing it, so ther ei no use in U-Boot adding another copy operation.

Best regards,

Wolfgang Denk

Signature · 7 lines
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
Misquotation is, in fact, the pride and privilege of the  learned.  A
widely-read  man  never  quotes  accurately,  for  the rather obvious
reason that he has read too widely.
                - Hesketh Pearson _Common Misquotations_ introduction
#31 lore raw
Quoted 8 lines · Wolfgang Denk

Dear Rogan Dawes,

Your kernel may not be able to pick up a ramdisk image in flash.

Mainline ARM cannot do that, for example.

[Patches to support that have been submitted, but rejected.]

Quoted 7 lines
Quoted 2 lines

Surely that should be Ok? Besides, U-boot is supposed to copy the data in the image to the specified destination address, isn't it?

No, why should it copy the image? It just verifies that the checksum is OK, and then passes the address to the kernel. The kernel will have to copy it anyway when uncompressing it, so ther ei no use in U-Boot adding another copy operation.

Well, I thought that was the point of the "mkimage" header, with the Load Address and Entry Point fields. Although, of course, you'll never actually "enter" a ramdisk image. I had still thought that they would be copied, regardless. Otherwise, what is the point in specifying those fields? They might just as well be zero.

But yes, what you say makes sense.

This appears to be the answer, from Marvell's u-boot sources, in lib_arm/armlinux.c, inside the #ifdef RAMDISK block:

#ifdef  DEBUG
        if (!data) {
                printf ("No initrd\n");
        }

#endif

        if (data) {
                #ifdef RAMDISK
                initrd_start = ntohl(hdr->ih_load);
                initrd_end = initrd_start + len;
                memmove ((void *)initrd_start, (void *)data, len);
                #else
                initrd_start = data;
                initrd_end = initrd_start + len;
                #endif
        } else {
                initrd_start = 0;
                initrd_end = 0;
        }

and then later:

#ifdef CONFIG_INITRD_TAG
        if (initrd_start && initrd_end)
                setup_initrd_tag (bd, initrd_start, initrd_end);

#endif

So, clearly, the address that the kernel is expecting MUST be within RAM, and MUST exclude the header.

So, the question then is, what is current u-boot doing? And why does it not work when the ramdisk is copied over to memory?

It looks like U-Boot for ARM doesn't handle ramdisks at all? From common/cmd_bootm.c:

#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
                case BOOTM_STATE_RAMDISK:
                {
                        ulong rd_len = images.rd_end - images.rd_start;
                        char str[17];

                        ret = boot_ramdisk_high(&images.lmb,
images.rd_start,
                                rd_len, &images.initrd_start,
&images.initrd_end);
                        if (ret)
                                return ret;

                        sprintf(str, "%lx", images.initrd_start);
                        setenv("initrd_start", str);
                        sprintf(str, "%lx", images.initrd_end);
                        setenv("initrd_end", str);
                }
                        break;

#endif

But this is only enabled for PPC, M68K and SPARC.

Is this the missing functionality that I am looking for?

Rogan

#32 lore raw

Dear Rogan Dawes,

Quoted 3 lines · In message <[email protected]> you wrote:

Well, I thought that was the point of the "mkimage" header, with the Load Address and Entry Point fields. Although, of course, you'll never

These fields are only relevant for executable images, not for data like ramdisk images.

Quoted 3 lines

actually "enter" a ramdisk image. I had still thought that they would be copied, regardless. Otherwise, what is the point in specifying those fields? They might just as well be zero.

Indeed, and that's they usally are:

	-> mkimage -l /opt/eldk-4.2/arm/images/uRamdisk
	Image Name:   Simple Embedded Linux Framework
	Created:      Sun Dec  7 18:27:20 2008
	Image Type:   ARM Linux RAMDisk Image (gzip compressed)
	Data Size:    1659739 Bytes = 1620.84 kB = 1.58 MB
	Load Address: 00000000
	Entry Point:  00000000

Copying the image is just a waste of boot time. I see no reeason why the kernel should not be able to read the image from RAM or from flash. On PowerPC this has always been possible, for well over a decade now. But in ARM land they reject patches that would add such support.

Quoted 1 line

So, the question then is, what is current u-boot doing? And why does it

In mainline code, it is supposed to verify the checksum and pass the start address of the data to the kernel.

Quoted 1 line

not work when the ramdisk is copied over to memory?

This I cannot answer.

Quoted 2 lines

It looks like U-Boot for ARM doesn't handle ramdisks at all? From common/cmd_bootm.c:

It does.

Quoted 2 lines

#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
case BOOTM_STATE_RAMDISK:

This is actually the wrong place.

Quoted 1 line

Is this the missing functionality that I am looking for?

No.

For a test you might try to hook into this part of code, though:

"common/image.c":

952 #if defined(CONFIG_B2) || defined(CONFIG_EVB4510) || defined(CONFIG_ARMADILLO)
953 /*
954 * We need to copy the ramdisk to SRAM to let Linux boot
955 */
956 if (rd_data) {
957 memmove ((void *)rd_load, (uchar *)rd_data, rd_len);
958 rd_data = rd_load;
959 }
960 #endif /* CONFIG_B2 || CONFIG_EVB4510 || CONFIG_ARMADILLO */

This indeed performs a copy to the load address, as you expected.

Here is a log from a working example (QOng board, i. e. ARM11):

=> run flash_self
## Booting kernel from Legacy Image at a00a0000 ...

   Image Name:   Linux-2.6.34-rc1
   Created:      2010-04-28  22:07:22 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1964848 Bytes = 1.9 MiB

Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at a0300000 ...

   Image Name:   Simple Embedded Linux Framework
   Created:      2008-11-24  16:44:17 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    1659703 Bytes = 1.6 MiB

Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34-rc1 (wd at sirius.denx.de) (gcc version 4.2.2) #3 Thu Apr 29 00:07:17 CEST 2010
CPU: ARMv6-compatible processor [4107b364] revision 4 (ARMv6TEJ), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Dave/DENX QongEVB-LITE
Memory policy: ECC disabled, Data cache writeback
INITRD: 0xa0300040+0x00195337 extends beyond physical memory - disabling initrd
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/ram rw ramdisk_size=8192 ip=192.168.20.12:192.168.1.1::255.255.0.0:qong:eth0:off panic=1 console=ttymxc0,115200 mtdparts=physmap-flash.0:384k(U-Boot),128k(env1),128k(env2),2432k(kernel),61m(rootfs),64m(user) ethaddr=00:50:c2:1e:af:e7 nohlt
...
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
...
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 140K
init started: BusyBox v1.7.1 (2008-11-24 17:40:49 MET)
starting pid 612, tty '': '/etc/rc.sh'
starting pid 617, tty '': '/bin/application'
### Application running ...
starting pid 618, tty '': '/bin/sh'
~ # eth0: link up (100/Full)
~ #

[Note: the Qong is running a kernel version that has the patch added which supports loading the ramdisk image from a flash address.]

Best regards,

Wolfgang Denk

Signature · 6 lines
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
The years of peak mental activity are undoubtedly between the ages of
four and eighteen. At four we know all the questions, at eighteen all
the answers.
#33 lore raw
In reply to Rogan Dawes

Dear Rogan Dawes,

Quoted 7 lines · In message <[email protected]> you wrote:

I'm not passing the second parameter at this stage, because the ramdisk is failing the CRC32 check for some reason. It may be that the CRC32 calculation has changed between 1.1.1 which was the base for the vendor u-boot, and mainline. e.g. rather than being calculated over the precise length of the data, it is calculated over the entire block. Just a guess, of course.

That's a wild guess actually, and I bet a beer or two that its a wrong one.

Quoted 7 lines

I had been led to believe that it was possible to override the compiled in mach type by setting a "machid" environment variable. This would give me the best of both worlds - a u-boot compiled according to mainline registered numbers, with the ability to boot vendor firmware by simply setting an environment variable.

Unfortunately, this did not work for me :-(

This feature was introduced by commit 3c234efa, dated 2008-01-30. Eventually your U-Bootimage predates this...

Quoted 1 line

Am I mistaken in expecting the machid environment variable trick to work?

It should work in reasonably recent versions of U-Boot.

Best regards,

Wolfgang Denk

Signature · 6 lines
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
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.