[U-Boot] Debugging why my kernel won't start

[U-Boot] Debugging why my kernel won't start

[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:

-a 0x3000000 -e 0x3000000

Can anyone see what I am doing wrong?

Many thanks!

Rogan

[U-Boot] Debugging why my kernel won't start

[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.

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 :
> 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


-- 
G?rald

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/16 10:34 AM, G?rald Kerma wrote:
> 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,
>

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

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/16 9:24 AM, Rogan Dawes wrote:
> 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

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

[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C699C6E.2010706@dawes.za.net> you wrote:
>
> > 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.

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

> > 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.

> > ## 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 ?

> 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.

> 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?

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

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
Was hei?t Windows auf Indianisch? - "Wei?er  Mann,  der  auf  Sanduhr
wartet!"

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/16 10:29 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message<4C699C6E.2010706@dawes.za.net>  you wrote:
>>
>>> 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.
> 
> 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.

>>>       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.

>> 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.

>> 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?
> 
> 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

[U-Boot] [PATCH] non-working dns323 config

[Rogan Dawes]

From: Rogan Dawes <rogan@dawes.za.net>

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

diff --git a/arch/arm/include/asm/arch-orion5x/cpu.h b/arch/arm/include/asm/arch-orion5x/cpu.h
index 80717f8..6ce02a9 100644
--- a/arch/arm/include/asm/arch-orion5x/cpu.h
+++ b/arch/arm/include/asm/arch-orion5x/cpu.h
@@ -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.
  */
diff --git a/board/D-Link/dns323_b1/Makefile b/board/D-Link/dns323_b1/Makefile
new file mode 100644
index 0000000..fae0330
--- /dev/null
+++ b/board/D-Link/dns323_b1/Makefile
@@ -0,0 +1,53 @@
+#
+# Copyright (C) 2010 Albert ARIBAUD <albert.aribaud@free.fr>
+#
+# Based on original Kirkwood support which is
+# (C) Copyright 2009
+# Marvell Semiconductor <www.marvell.com>
+# Written-by: Prafulla Wadaskar <prafulla@marvell.com>
+#
+# 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
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).a
+
+COBJS	:= dns323_b1.o
+
+SRCS	:= $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+
+$(LIB):	$(obj).depend $(OBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+	rm -f $(OBJS)
+
+distclean:	clean
+	rm -f $(LIB) core *.bak .depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/D-Link/dns323_b1/config.mk b/board/D-Link/dns323_b1/config.mk
new file mode 100644
index 0000000..3dec1aa
--- /dev/null
+++ b/board/D-Link/dns323_b1/config.mk
@@ -0,0 +1,27 @@
+#
+# Copyright (C) 2010 Albert ARIBAUD <albert.aribaud@free.fr>
+#
+# (C) Copyright 2009
+# Marvell Semiconductor <www.marvell.com>
+# Written-by: Prafulla Wadaskar <prafulla@marvell.com>
+#
+# 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
diff --git a/board/D-Link/dns323_b1/dns323_b1.c b/board/D-Link/dns323_b1/dns323_b1.c
new file mode 100644
index 0000000..d05d63c
--- /dev/null
+++ b/board/D-Link/dns323_b1/dns323_b1.c
@@ -0,0 +1,129 @@
+/*
+ * Copyright (C) 2010 Albert ARIBAUD <albert.aribaud@free.fr>
+ *
+ * (C) Copyright 2009
+ * Marvell Semiconductor <www.marvell.com>
+ * Written-by: Prafulla Wadaskar <prafulla@marvell.com>
+ *
+ * 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
+ */
+
+#include <common.h>
+#include <miiphy.h>
+#include <asm/arch/orion5x.h>
+#include "dns323_b1.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * The Dlink DNS323 B1 is equipped with a Spansion S29GL064M90TFIR4 FLASH
+ * which CFI does not properly detect, hence the LEGACY config.
+ */
+#if defined(CONFIG_FLASH_CFI_LEGACY)
+#include <flash.h>
+ulong board_flash_get_legacy(ulong base, int banknum, flash_info_t *info)
+{
+        int sectsz[] = CONFIG_SYS_FLASH_SECTSZ;
+        int sect;
+
+        if (base != CONFIG_SYS_FLASH_BASE)
+                return 0;
+
+        info->size = 0;
+        info->sector_count = CONFIG_SYS_MAX_FLASH_SECT;
+        /* set each sector's start address and size based */
+        for (sect = 0; sect < CONFIG_SYS_MAX_FLASH_SECT; sect++) {
+                info->start[sect] = base+info->size;
+                info->size += sectsz[sect];
+        }
+        /* This flash must be accessed in 8-bits mode, no buffer. */
+        info->flash_id = FLASH_MAN_AMD;
+        info->portwidth = FLASH_CFI_8BIT;
+        info->chipwidth = FLASH_CFI_BY8;
+        info->buffer_size = 0;
+        /* timings are derived from the Spansion datasheet. */
+        info->erase_blk_tout = 4000;
+        info->write_tout = 10;
+        info->buffer_write_tout = 300;
+        /* Commands and addresses are for AMD mode 8-bit access. */
+        info->vendor = CFI_CMDSET_AMD_LEGACY;
+        info->cmd_reset = 0xF0;
+        info->interface = FLASH_CFI_X8;
+        info->legacy_unlock = 0;
+        info->ext_addr = 0;
+        info->addr_unlock1 = 0x00000aaa;
+        info->addr_unlock2 = 0x00000555;
+        /* Manufacturer Macronix, device MX29LV400CB, CFI 1.3. */
+        info->manufacturer_id = 0x01;
+        info->device_id = 0x7E;
+        info->device_id2 = 0x10;
+        info->cfi_version = 0x3133;
+        info->cfi_offset = 0x0000;
+        info->name = "S29GL064MR4";
+
+        return 1;
+}
+#endif                          /* CONFIG_SYS_FLASH_CFI */
+
+int board_init(void)
+{
+	/* arch number of board */
+	gd->bd->bi_arch_number = MACH_TYPE_DNS323;
+
+	/* boot parameter start at 256th byte of RAM base */
+	gd->bd->bi_boot_params = gd->bd->bi_dram[0].start + 0x100;
+
+	return 0;
+}
+
+#if defined(CONFIG_CMD_NET) && defined(CONFIG_RESET_PHY_R)
+/* Configure and enable MV88E1116 PHY */
+void reset_phy(void)
+{
+        u16 reg;
+        u16 devadr;
+        char *name = "egiga0";
+
+        if (miiphy_set_current_dev(name))
+                return;
+
+        /* command to read PHY dev address */
+        if (miiphy_read(name, 0xEE, 0xEE, (u16 *) &devadr)) {
+                printf("Err..%s could not read PHY dev address\n",
+                        __func__);
+                return;
+        }
+
+        /*
+         * Enable RGMII delay on Tx and Rx for CPU port
+         * Ref: sec 4.7.2 of chip datasheet
+         */
+        miiphy_write(name, devadr, MV88E1116_PGADR_REG, 2);
+        miiphy_read(name, devadr, MV88E1116_MAC_CTRL_REG, &reg);
+        reg |= (MV88E1116_RGMII_RXTM_CTRL | MV88E1116_RGMII_TXTM_CTRL);
+        miiphy_write(name, devadr, MV88E1116_MAC_CTRL_REG, reg);
+        miiphy_write(name, devadr, MV88E1116_PGADR_REG, 0);
+
+        /* reset the phy */
+        miiphy_reset(name, devadr);
+
+        printf("88E1116 Initialized on %s\n", name);
+}
+#endif /* CONFIG_RESET_PHY_R */
+
diff --git a/board/D-Link/dns323_b1/dns323_b1.h b/board/D-Link/dns323_b1/dns323_b1.h
new file mode 100644
index 0000000..5b3c4e6
--- /dev/null
+++ b/board/D-Link/dns323_b1/dns323_b1.h
@@ -0,0 +1,41 @@
+/*
+ * (C) Copyright 2009
+ * Net Insight <www.netinsight.net>
+ * Written-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
+ *
+ * Based on sheevaplug.h:
+ * (C) Copyright 2009
+ * Marvell Semiconductor <www.marvell.com>
+ * Written-by: Prafulla Wadaskar <prafulla@marvell.com>
+ *
+ * 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
+ */
+
+#ifndef __DNS323_BASE_H
+#define __DNS323_BASE_H
+
+/* PHY related */
+#define MV88E1116_LED_FCTRL_REG		10
+#define MV88E1116_CPRSP_CR3_REG		21
+#define MV88E1116_MAC_CTRL_REG		21
+#define MV88E1116_PGADR_REG		22
+#define MV88E1116_RGMII_TXTM_CTRL	(1 << 4)
+#define MV88E1116_RGMII_RXTM_CTRL	(1 << 5)
+
+#endif /* __DNS323_BASE_H */
diff --git a/boards.cfg b/boards.cfg
index 69c6897..37b980a 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -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
diff --git a/include/configs/dns323_b1.h b/include/configs/dns323_b1.h
new file mode 100644
index 0000000..1da4e92
--- /dev/null
+++ b/include/configs/dns323_b1.h
@@ -0,0 +1,126 @@
+/*
+ * Copyright (C) 2010 Albert ARIBAUD <albert.aribaud@free.fr>
+ *
+ * Based on original Kirkwood support which is
+ * (C) Copyright 2009
+ * Marvell Semiconductor <www.marvell.com>
+ * Written-by: Prafulla Wadaskar <prafulla@marvell.com>
+ *
+ * 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
+ */
+
+#ifndef _CONFIG_DNS323_B1_H
+#define _CONFIG_DNS323_B1_H
+
+/* Almost everything is the same, so include the edmini config */
+#include "edminiv2.h"
+
+/*
+ * Version number information
+ */
+#undef CONFIG_IDENT_STRING
+#define CONFIG_IDENT_STRING	" DNS323_B1"
+
+/*
+ * High Level Configuration Options (easy to change)
+ */
+
+#undef CONFIG_MACH_EDMINIV2
+#define CONFIG_MACH_DNS323	1	/* Machine type */
+
+/* Skip lowlevel init - 
+ * makes an image suitable for chaining from another u-boot loader 
+ */
+#define CONFIG_SKIP_LOWLEVEL_INIT	1
+
+#define CONFIG_BOOTARGS "console=ttyS0,115200"
+
+#define CONFIG_SYS_LONGHELP
+
+/*
+ * FLASH configuration
+ */
+
+#undef CONFIG_SYS_FLASH_BASE
+#define CONFIG_SYS_FLASH_BASE		0xff800000
+#define ORION5X_ADR_BOOTROM		CONFIG_SYS_FLASH_BASE
+#define ORION5X_SZ_BOOTROM		(8 * 1024 * 1024)
+
+/* #undef CONFIG_FLASH_CFI_LEGACY */
+
+#undef CONFIG_SYS_MAX_FLASH_SECT
+#undef CONFIG_SYS_FLASH_SECTSZ
+
+#define CONFIG_SYS_MAX_FLASH_SECT	135 
+#define CONFIG_SYS_FLASH_SECTSZ \
+        {8192, 8192, 8192, 8192, 8192, 8192, 8192, 8192, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+	 65536, 65536, 65536, 65536, 65536, 65536, 65536, 65536, \
+        }
+
+
+/* auto boot */
+#undef CONFIG_BOOTDELAY
+#define CONFIG_BOOTDELAY	-1	/* default disable autoboot */
+
+#undef CONFIG_SYS_PROMPT
+#define	CONFIG_SYS_PROMPT	"DNS323B1> "	/* Command Prompt */
+
+#ifdef CONFIG_CMD_NET
+#define CONFIG_CMD_DHCP
+#endif
+
+/*
+ * IDE overrides
+ */
+#undef CONFIG_SYS_ATA_IDE0_OFFSET
+#define CONFIG_SYS_ATA_IDE0_OFFSET      ORION5X_SATA_PORT0_OFFSET
+#define CONFIG_SYS_ATA_IDE1_OFFSET      ORION5X_SATA_PORT1_OFFSET
+
+#undef CONFIG_SYS_IDE_MAXBUS
+#undef CONFIG_SYS_IDE_MAXDEVICE
+#define CONFIG_SYS_IDE_MAXBUS		2
+#define CONFIG_SYS_IDE_MAXDEVICE	2
+
+/*
+ *  Environment variables configurations
+ */
+#undef CONFIG_ENV_OFFSET
+#define CONFIG_ENV_OFFSET		0x0000	/* env starts here */
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+	"bootargs=root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none\0" \
+	"bootcmd=bootm FF820000 FF9A0000\0" \
+	"machid=526\0"
+
+#endif /* _CONFIG_DNS323_B1_H */
-- 
1.7.0.4

[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C69A8DA.8020201@dawes.za.net> you wrote:
>
> > 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?

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

-- 
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_

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 12:03 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4C69A8DA.8020201@dawes.za.net> you wrote:
>>
>>> 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.

> 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.

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

[U-Boot] Debugging why my kernel won't start

[Albert ARIBAUD]

Le 16/08/2010 22:15, Rogan Dawes a ?crit :
> On 2010/08/16 9:24 AM, Rogan Dawes wrote:
>> 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
>
> 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

(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,
-- 
Albert.

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 12:10 PM, Albert ARIBAUD wrote:
> (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):

>> 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.

> 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,

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

[U-Boot] Debugging why my kernel won't start

[Albert ARIBAUD]

Le 17/08/2010 12:21, Rogan Dawes a ?crit :
> On 2010/08/17 12:10 PM, Albert ARIBAUD wrote:
>> (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):
>
>>> 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.

Sorry, I'd missed that one.

> 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 :) )

> Thanks anyway.
>
> Rogan

You're welcome.

Amicalement,
-- 
Albert.

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 12:41 PM, Albert ARIBAUD wrote:
>> 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.

> 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.

> 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

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 1:19 PM, Rogan Dawes wrote:
> 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

[U-Boot] Debugging why my kernel won't start

[Albert ARIBAUD]

Le 17/08/2010 13:42, Rogan Dawes a ?crit :
> On 2010/08/17 1:19 PM, Rogan Dawes wrote:
>> 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.

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

> 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,
-- 
Albert.

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 5:38 PM, Albert ARIBAUD wrote:

> Ok, so u-boot is now out of the way of the linux image load area.
> 
>> 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,

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

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 9:56 PM, Rogan Dawes wrote:
> 
> 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

[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C6AE955.1060708@dawes.za.net> 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.

> 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...

> 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

-- 
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.

[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C6AEC70.40801@dawes.za.net> 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

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

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/17 11:20 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4C6AEC70.40801@dawes.za.net> 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
> 

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
---
> Using UBoot passing parameters structure

Also potentially interesting is:

< Memory: 64MB = 64MB total
< Memory: 61696KB available (2599K code, 462K data, 112K init)
---
> 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

[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C6B051A.5050006@dawes.za.net> 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

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

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/18 12:04 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4C6B051A.5050006@dawes.za.net> 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

Hi Wolfgang,

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

[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C6B08F1.9000804@dawes.za.net> 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

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

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/18 7:51 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4C6B08F1.9000804@dawes.za.net> 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
> 

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
> DNS323B1> bootm ff820000 1600000

< ## Loading init Ramdisk from Legacy Image@ff9a0000 ...
> ## Loading init Ramdisk from Legacy Image at 01600000 ...

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

> checking if image is initramfs...it isn't (no cpio magic); looks like
an initrd
> 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

[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C6BAC5A.6060206@dawes.za.net> 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.

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

-- 
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.

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/18 12:54 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4C6BAC5A.6060206@dawes.za.net> 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! :-)

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

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

[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C6BF138.20107@dawes.za.net> you wrote:
>
> > 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...

> 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.]

> 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

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

[U-Boot] Debugging why my kernel won't start

[Rogan Dawes]

On 2010/08/18 5:33 PM, Wolfgang Denk wrote:
> 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.]
> 
>> 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

[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C6C0B33.8090703@dawes.za.net> 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.

> 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.

> 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.

> not work when the ramdisk is copied over to memory?

This I cannot answer.

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

It does.

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

This is actually the wrong place.

> 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

-- 
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.

[U-Boot] [PATCH] non-working dns323 config

[Wolfgang Denk]

Dear Rogan Dawes,

In message <1281993065-19803-1-git-send-email-user@aphrodite> you wrote:
> From: Rogan Dawes <rogan@dawes.za.net>
> 
> ---
>  arch/arm/include/asm/arch-orion5x/cpu.h |    2 +-

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

>  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

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

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

[U-Boot] [PATCH] non-working dns323 config

[Rogan Dawes]

On 2010/08/19 12:23 AM, Wolfgang Denk wrote:
> 
> 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

[U-Boot] [PATCH] non-working dns323 config

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C6CC059.4080806@dawes.za.net> 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

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

[U-Boot] [PATCH] non-working dns323 config

[Rogan Dawes]

On 2010/08/19 7:35 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
> 
> In message <4C6CC059.4080806@dawes.za.net> 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

[U-Boot] [PATCH] non-working dns323 config

[Wolfgang Denk]

Dear Rogan Dawes,

In message <4C6CD111.4070800@dawes.za.net> you wrote:
>
> > 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

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