Debugging why my kernel won't start
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 CRCRamdisk 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
Dear Rogan,
I've you set the uboot env machid to the correct value ? setenv machid <HexValue>
just replace HexValue with the correct MACH_TYPE.
You must then see something like :
Using machid 0xa76 from environment
after kernel loaded by uboot.
Best regards,
Le 16/08/2010 09:24, Rogan Dawes a ?crit :
Quoted 89 lines
Hi folks,
I'm trying to get mainline u-boot working on my DNS323 (Orion5x based). Until I am confident in the config, I'm using a chainloaded approach, wrapping my featureful u-boot in an image file:
$ mkimage -A arm -O u-boot -T kernel -C none -a 0x3000000 -e 0x3000000 -n "UBoot dns323" -d u-boot.bin uImage.binI 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 modifiedarch/arm/include/asm/mach-types.hto setMACH_TYPE_DNS323to 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 atff820000...Image Name: Linux-2.6.12.6-arm1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1490204 Bytes = 1.4 MiBLoad 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_wdnever completes, it seems.I added a debug statement at the top of
memmove_wd, and got:Moving memory from
ff820040to 00008000Is 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 atff820000...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 CRCRamdisk 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-e0x3000000Can anyone see what I am doing wrong?
Many thanks!
Rogan
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Signature · 1 line
G?rald
Quoted 6 lines · G?rald Kerma
Dear Rogan,
I've you set the uboot env machid to the correct value ? setenv machid<HexValue>
just replace HexValue with the correctMACH_TYPE.
Quoted 6 lines
You must then see something like :
Using machid0xa76from 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
Quoted 78 lines · Rogan Dawes
Hi folks,
I'm trying to get mainline u-boot working on my DNS323 (Orion5x based). Until I am confident in the config, I'm using a chainloaded approach, wrapping my featureful u-boot in an image file:
$ mkimage -A arm -O u-boot -T kernel -C none -a 0x3000000 -e 0x3000000 -n "UBoot dns323" -d u-boot.bin uImage.binI 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 modifiedarch/arm/include/asm/mach-types.hto setMACH_TYPE_DNS323to 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 atff820000...Image Name: Linux-2.6.12.6-arm1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1490204 Bytes = 1.4 MiBLoad 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_wdnever completes, it seems.I added a debug statement at the top of
memmove_wd, and got:Moving memory from
ff820040to 00008000Is 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 atff820000...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 CRCRamdisk image is corrupt or invalid
DNS323B1>My chainloaded u-boot is configured in an image to load at
0x3000000, and stay there (no relocation), if I have understood these parameters correctly:
Quoted 7 lines
-a
0x3000000-e0x3000000Can 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 400000df000: 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.000df00000df6f0: 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.000df00000df6f0: 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
Dear Rogan Dawes,
Quoted 11 lines · In message <[email protected]> you wrote:
Quoted 11 lines
DNS323B1> bootm FF820000
## Booting kernel from Legacy Image atff820000...Image Name: Linux-2.6.12.6-arm1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1490204 Bytes = 1.4 MiBLoad Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ...
Quoted 1 line
Quoted 1 line
and it hangs there.
Are you absolutely sure that you have RAM in your system at 0x8000? I doubt that your Load Address/Entry Point settings are correct.
Quoted 3 lines
Quoted 3 lines
Moving memory from
ff820040to 00008000Is that because the uImage header is 64 bytes?
The offset 0x40 is becaus eof the header, the 0x00008000 is because your Load Address setting.
Quoted 8 lines
Quoted 8 lines
## Loading init Ramdisk from Legacy Image at
ff9a0000...Image Name: Ramdisk Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5240600 Bytes = 5 MiB Load Address: 00800000 Entry Point: 00800000 Verifying Checksum ... Bad Data CRCRamdisk image is corrupt or invalid
Is there RAM at 0x00800000 ?
Quoted 1 line
So, I checked what was at that address:
Hm... instead of trying random things I recommend to apply common sense. Have a look at the memory map for your system - which memory types and register banks etc. are mapped to which address ragens? Where is your RAM and how big is it? I seriously doubt that you have RAM at these low addresses.
Quoted 8 lines
The first 1kB was not particularly interesting (to me). But the next chunk showed something interesting at
000df6e0:
000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 ....md.b.000df00000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 0.400...........
Quoted 8 lines
i.e. the command I had just executed.
So, it seems that for some reason, even though I tried to place my chain loaded u-boot out of harms way at
0x3000000, for some reason, it was still allocating memory at a lower address, precisely where the kernel is supposed to be copied to for execution.Can anyone explain why this happens? Or what I can do to fix it?
We don;t yuour hardware, we don't know your board configuration, we don't know your code...
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Was hei?t Windows auf Indianisch? - "Wei?er Mann, der auf Sanduhr wartet!"
Quoted 14 lines · Wolfgang Denk
Dear Rogan Dawes,
Quoted 11 lines · In message<[email protected]> you wrote:
Quoted 11 lines
DNS323B1> bootm FF820000
## Booting kernel from Legacy Image atff820000...Image Name: Linux-2.6.12.6-arm1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1490204 Bytes = 1.4 MiBLoad Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ...
Quoted 4 lines
Quoted 1 line
Quoted 1 line
and it hangs there.
Are you absolutely sure that you have RAM in your system at
0x8000? I doubt that your Load Address/Entry Point settings are correct.
Hi Wolfgang,
This is the default kernel that was shipped with the device, and so those are the settings that worked with the original u-boot.
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalidIs there RAM at
0x00800000?
Again, this is from the default vendor ramdisk that ships with the device.
Quoted 7 lines
Quoted 1 line
So, I checked what was at that address:
Hm... instead of trying random things I recommend to apply common sense. Have a look at the memory map for your system - which memory types and register banks etc. are mapped to which address ragens? Where is your RAM and how big is it? I seriously doubt that you have RAM at these low addresses.
I looked at the CPU datasheet, which shows that:
DDR SDRAM CS0 is by default 256 MB at 0000.0000?0FFF.FFFF
There doesn't appear to be any code in the orion5x setup that sets this to anything else:
$ git grep ORION5X_ATTR_DRAM_CS0 arch/arm/include/asm/arch-orion5x/cpu.h: ORION5X_ATTR_DRAM_CS0 = 0x0e, $
The device has 64MB RAM in two banks.
Quoted 15 lines
Quoted 15 lines
The first 1kB was not particularly interesting (to me). But the next chunk showed something interesting at
000df6e0:
000df6e0: ff ff ff ff 6d 64 2e 62 00 30 30 30 64 66 30 30 ....md.b.000df00000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 0.400...........i.e. the command I had just executed.
So, it seems that for some reason, even though I tried to place my chain loaded u-boot out of harms way at
0x3000000, for some reason, it was still allocating memory at a lower address, precisely where the kernel is supposed to be copied to for execution.
Quoted 4 lines
Quoted 1 line
Can anyone explain why this happens? Or what I can do to fix it?
We don;t yuour hardware, we don't know your board configuration, we don't know your code...
Patch to follow this mail.
Thanks for your help!
Rogan
PATCH 1/1 non-working dns323 config
From: Rogan Dawes <[email protected]>
--- arch/arm/include/asm/arch-orion5x/cpu.h | 2 +- board/D-Link/dns323_b1/Makefile | 53 +++++++++++++ board/D-Link/dns323_b1/config.mk | 27 +++++++ board/D-Link/dns323_b1/dns323_b1.c | 129 +++++++++++++++++++++++++++++++ board/D-Link/dns323_b1/dns323_b1.h | 41 ++++++++++ boards.cfg | 1 + include/configs/dns323_b1.h | 126 ++++++++++++++++++++++++++++++ 7 files changed, 378 insertions(+), 1 deletions(-) create mode 100644 board/D-Link/dns323_b1/Makefile create mode 100644 board/D-Link/dns323_b1/config.mk create mode 100644 board/D-Link/dns323_b1/dns323_b1.c create mode 100644 board/D-Link/dns323_b1/dns323_b1.h create mode 100644 include/configs/dns323_b1.h
arch/arm/include/asm/arch-orion5x/cpu.h +1 -1
@@ -76,7 +76,7 @@ enum orion5x_cpu_attrib {/* * Device Address MAP BAR values -/* +* * All addresses and sizes not defined by board code * will be given default values here. */
board/D-Link/dns323_b1/Makefile new file +53 -0
53 lines not on this page · raw message
board/D-Link/dns323_b1/config.mk new file +27 -0
@@ -0,0 +1,27 @@ +# +# Copyright (C) 2010 Albert ARIBAUD <[email protected]> +# +# (C) Copyright 2009 +# Marvell Semiconductor <www.marvell.com> +# Written-by: Prafulla Wadaskar <[email protected]> +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +TEXT_BASE = 0x00100000
board/D-Link/dns323_b1/dns323_b1.c new file +129 -0
129 lines not on this page · raw message
board/D-Link/dns323_b1/dns323_b1.h new file +41 -0
41 lines not on this page · raw message
boards.cfg +1 -0
@@ -253,6 +253,7 @@ sheevaplug arm arm926ejs - Marvell kirkwood imx27lite arm arm926ejs imx27lite logicpd mx27 magnesium arm arm926ejs imx27lite logicpd mx27 omap5912osk arm arm926ejs - ti omap +dns323_b1 arm arm926ejs - D-Link orion5x edminiv2 arm arm926ejs - LaCie orion5x omap3_overo arm armv7 overo - omap3 omap3_pandora arm armv7 pandora - omap3
include/configs/dns323_b1.h new file +126 -0
126 lines not on this page · raw message
Signature · 1 line
1.7.0.4
PATCH 1/1 non-working dns323 config
Dear Rogan Dawes,
Quoted 4 lines · In message <1281993065-19803-1-git-send-email-user@aphrodite> you wrote:
From: Rogan Dawes <[email protected]>
--- arch/arm/include/asm/arch-orion5x/cpu.h | 2 +-
This is a fix that is good... If there only was a SoB line...
Quoted 4 lines
board/D-Link/dns323_b1/Makefile | 53 +++++++++++++ board/D-Link/dns323_b1/config.mk | 27 +++++++ board/D-Link/dns323_b1/dns323_b1.c | 129 +++++++++++++++++++++++++++++++ board/D-Link/dns323_b1/dns323_b1.h | 41 ++++++++++
Quoted 8 lines
boards.cfg | 1 + include/configs/dns323_b1.h | 126 ++++++++++++++++++++++++++++++ 7 files changed, 378 insertions(+), 1 deletions(-) create mode 100644 board/D-Link/dns323_b1/Makefile create mode 100644 board/D-Link/dns323_b1/config.mk create mode 100644 board/D-Link/dns323_b1/dns323_b1.c create mode 100644 board/D-Link/dns323_b1/dns323_b1.h create mode 100644 include/configs/dns323_b1.h
But this is an attempt to sneak in an incomplete (no entries to MAKEALL or MAINTAINER, for example) board when no MW is open.
NAK for this part.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "I've finally learned what `upward compatible' means. It means we get to keep all our old mistakes." - Dennie van Tassel
PATCH 1/1 non-working dns323 config
Quoted 5 lines · Wolfgang Denk
But this is an attempt to sneak in an incomplete (no entries to MAKEALL or MAINTAINER, for example) board when no MW is open.
NAK for this part.
Hi Wolfgang,
The patch was simply to allow people to see my non-working config, in the hope of getting suggestions on how to improve it.
I didn't see much point in a SoB until it was ready to be submitted for real.
Thanks for taking a look at it, though.
Rogan
PATCH 1/1 non-working dns323 config
Dear Rogan Dawes,
Quoted 3 lines · In message <[email protected]> you wrote:
The patch was simply to allow people to see my non-working config, in the hope of getting suggestions on how to improve it.
Then please mark it as such in the subject - adding a "[RFC]" or similar tag would help.
Best regards,
Wolfgang Denk
Signature · 7 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Quote from the Boss after overriding the decision of a task force he created to find a solution: "I'm sorry if I ever gave you the impression your input would have any effect on my decision for the outcome of this project!"
PATCH 1/1 non-working dns323 config
Quoted 9 lines · Wolfgang Denk
Dear Rogan Dawes,
Quoted 3 lines · In message <[email protected]> you wrote:
The patch was simply to allow people to see my non-working config, in the hope of getting suggestions on how to improve it.
Then please mark it as such in the subject - adding a "[RFC]" or similar tag would help.
Sorry, git-send-email newbie here.
Will figure it out for the next time around.
Rogan
PATCH 1/1 non-working dns323 config
Dear Rogan Dawes,
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 3 lines
Then please mark it as such in the subject - adding a "[RFC]" or similar tag would help.
Sorry, git-send-email newbie here.
Will figure it out for the next time around.
You can manually edit the patch before handing it over to git-send-email, or you can use the "--subject-prefix" option with git-format-patch right when you create it.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The only way to get rid of a temptation is to yield to it.
- Oscar WildeDear Rogan Dawes,
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
Are you absolutely sure that you have RAM in your system at
0x8000? I doubt that your Load Address/Entry Point settings are correct.This is the default kernel that was shipped with the device, and so those are the settings that worked with the original u-boot.
Why do you not simply answer the question I asked?
Why do you not think about what I asked, and why?
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalidIs there RAM at
0x00800000?Again, this is from the default vendor ramdisk that ships with the device.
Why should I care about where this is coming from?
On such a base I cannot help you.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Steal five dollars and you were a petty thief. Steal thousands of
dollars and you are either a government or a hero.
- Terry Pratchett, _Going_Postal_Quoted 11 lines · Wolfgang Denk
Dear Rogan Dawes,
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
Are you absolutely sure that you have RAM in your system at
0x8000? I doubt that your Load Address/Entry Point settings are correct.This is the default kernel that was shipped with the device, and so those are the settings that worked with the original u-boot.
Why do you not simply answer the question I asked?
Because I don't know how to get the answer to your question.
My assumption is that, since this is the vendor kernel, and that this is the working configuration that they were using, that there MUST be memory at that location, otherwise the thousands of devices that they shipped would surely not have worked.
Clearly there is a different configuration somewhere between the vendor u-boot, and what mainline is using. All I am trying to do is figure out where that difference might be.
Quoted 1 line
Why do you not think about what I asked, and why?
I tried to find out by looking up the default CS0 value from the chipset, and seeing if there were any changes made to it in current u-boot. That's all I know how to do.
Quoted 10 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Verifying Checksum ... Bad Data CRC
Ramdisk image is corrupt or invalidIs 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
Le 16/08/2010 22:15, Rogan Dawes a ?crit :
Quoted 374 lines · Rogan Dawes
Quoted 78 lines
Hi folks,
I'm trying to get mainline u-boot working on my DNS323 (Orion5x based). Until I am confident in the config, I'm using a chainloaded approach, wrapping my featureful u-boot in an image file:
$ mkimage -A arm -O u-boot -T kernel -C none -a 0x3000000 -e 0x3000000 -n "UBoot dns323" -d u-boot.bin uImage.binI 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 modifiedarch/arm/include/asm/mach-types.hto setMACH_TYPE_DNS323to 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 atff820000...Image Name: Linux-2.6.12.6-arm1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1490204 Bytes = 1.4 MiBLoad 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_wdnever completes, it seems.I added a debug statement at the top of
memmove_wd, and got:Moving memory from
ff820040to 00008000Is 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 atff820000...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 CRCRamdisk image is corrupt or invalid
DNS323B1>My chainloaded u-boot is configured in an image to load at
0x3000000, and stay there (no relocation), if I have understood these parameters correctly:Quoted 7 lines
-a
0x3000000-e0x3000000Can anyone see what I am doing wrong?
Many thanks!
Rogan
So I changed
memmove_wdto 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
ff8f6840to000de800Moving 1024 of 610588 bytes fromff8f6c40to000dec00Moving 1024 of 609564 bytes fromff8f7040to000df000before it finally hung.
So, I checked what was at that address:
DNS323B1> md.b
000df000400000df000: 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.000df00000df6f0: 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.000df00000df6f0: 30 00 34 30 30 00 ff ff ff ff ff ff ff ff ff ff 0.400...........i.e. the command I had just executed.
So, it seems that for some reason, even though I tried to place my chain loaded u-boot out of harms way at
0x3000000, for some reason, it was still allocating memory at a lower address, precisely where the kernel is supposed to be copied to for execution.
Quoted 5 lines
Can anyone explain why this happens? Or what I can do to fix it?
Many thanks!
Rogan
(quick note to Wolfgang: yes, there is RAM at 0x00008000 on these machines. All orion5x based machines have RAM start at 0, and u-boot makes sure SDRAM is set up this way)
Rogan,
You cannot tell from your log output that memmove never completes. It could as well be the kernel not outputting to the console, or failing to start at all even though the move was ok.
The first thing you should do is make sure that you pass the right machine-id, but also that you pass ATAGs correctly to the kernel -- it seems that at least some LaCie custom u-boot implementations use an env variable ('mainlineKernel', IIRC) to differenciate between mainline and LaCie custom kernels. Maybe your HW was designed the same way. Best is you look up the u-boot source code provided by the manufacturer of your machine.
The second thing is to make sure your kernel uses the right console. Are you using netconsole? Maybe the manufacturer's kernel does not have netconsole. Do you use a serial (RS-232) console? Make sure the kernel has command line arguments to use it too.
Amicalement,
Signature · 1 line
Albert.
Quoted 9 lines · Albert ARIBAUD
(quick note to Wolfgang: yes, there is RAM at
0x00008000on these machines. All orion5x based machines have RAM start at 0, and u-boot makes sure SDRAM is set up this way)Rogan,
You cannot tell from your log output that memmove never completes. It could as well be the kernel not outputting to the console, or failing to start at all even though the move was ok.
Actually, I can tell that the memmove never completes (or if it does, it alters the code flow in the process):
Quoted 9 lines
Quoted 9 lines
So I changed
memmove_wdto 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
ff8f6840to000de800Moving 1024 of 610588 bytes fromff8f6c40to000dec00Moving 1024 of 609564 bytes fromff8f7040to000df000before it finally hung.
I had a debug statement in the loop, printing out the above at each iteration. Since it never completed the loop, copying/moving the entire kernel (609564 bytes remaining), I think it is safe to assume that it never got to the point of trying to boot the kernel.
Additionally, just doing a cp with the above parameters also hangs.
Quoted 8 lines
The first thing you should do is make sure that you pass the right machine-id, but also that you pass ATAGs correctly to the kernel -- it seems that at least some LaCie custom u-boot implementations use an env variable ('mainlineKernel', IIRC) to differenciate between mainline and LaCie custom kernels. Maybe your HW was designed the same way. Best is you look up the u-boot source code provided by the manufacturer of your machine.
Quoted 6 lines
The second thing is to make sure your kernel uses the right console. Are you using netconsole? Maybe the manufacturer's kernel does not have netconsole. Do you use a serial (RS-232) console? Make sure the kernel has command line arguments to use it too.
Amicalement,
I'll check those once I have got the copy working correctly :-)
FWIW, I'm using a serial console, not netconsole. And the bootargs include the console definition.
Based on what Wolfgang has said, perhaps the address space registers are set up differently in the vendor u-boot to what the current mainline is doing. I'll check that next, I think.
I'm just struggling to understand how the last command that I executed ended up in the memory where I was trying to copy the kernel to. That suggests that U-boot is actively using that memory for some reason, and copying the kernel image over the top of it seems like a very good way to cause u-boot to stop behaving consistently, and hang.
Thanks anyway.
Rogan
Le 17/08/2010 12:21, Rogan Dawes a ?crit :
Quoted 22 lines · Albert ARIBAUD
Quoted 9 lines
(quick note to Wolfgang: yes, there is RAM at
0x00008000on these machines. All orion5x based machines have RAM start at 0, and u-boot makes sure SDRAM is set up this way)Rogan,
You cannot tell from your log output that memmove never completes. It could as well be the kernel not outputting to the console, or failing to start at all even though the move was ok.
Actually, I can tell that the memmove never completes (or if it does, it alters the code flow in the process):
Quoted 8 lines
Quoted 8 lines
So I changed
memmove_wdto 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
ff8f6840to000de800Moving 1024 of 610588 bytes fromff8f6c40to000dec00Moving 1024 of 609564 bytes fromff8f7040to000df000
Quoted 6 lines
Quoted 1 line
Quoted 1 line
before it finally hung.
I had a debug statement in the loop, printing out the above at each iteration. Since it never completed the loop, copying/moving the entire kernel (609564 bytes remaining), I think it is safe to assume that it never got to the point of trying to boot the kernel.
Sorry, I'd missed that one.
Quoted 11 lines
Additionally, just doing a cp with the above parameters also hangs.
Based on what Wolfgang has said, perhaps the address space registers are set up differently in the vendor u-boot to what the current mainline is doing. I'll check that next, I think.
I'm just struggling to understand how the last command that I executed ended up in the memory where I was trying to copy the kernel to. That suggests that U-boot is actively using that memory for some reason, and copying the kernel image over the top of it seems like a very good way to cause u-boot to stop behaving consistently, and hang.
I do think you're overwriting u-boot with the kernel. What location does your u-boot load at? What location is the manufacturer's u-boot supposed to be loading at? See their TEXT_BASE in the board config file (or link file maybe).
FYI, in my u-boot edminiv2 support code, I had issues with big kernels, so I decided to move u-boot's final location as high in RAM as by board allows, so that it never will be overwritten by Linux (unless I load a 63+ MB kernel, that is :) )
Quoted 3 lines
Thanks anyway.
Rogan
You're welcome.
Amicalement,
Signature · 1 line
Albert.
Quoted 6 lines · Albert ARIBAUD
Quoted 4 lines
I had a debug statement in the loop, printing out the above at each iteration. Since it never completed the loop, copying/moving the entire kernel (609564 bytes remaining), I think it is safe to assume that it never got to the point of trying to boot the kernel.
Sorry, I'd missed that one.
No problem, there was a lot of data there.
Quoted 4 lines
I do think you're overwriting u-boot with the kernel. What location does your u-boot load at? What location is the manufacturer's u-boot supposed to be loading at? See their
TEXT_BASEin the board config file (or link file maybe).
My U-Boot is configured to load at 0x3000000 (48MB), as far out of the way as possible. That is, using the mkimage tool, which is how I get my rebuilt u-boot onto the machine. This is my command line:
$ make clean mrproper dns323_b1_config && make && \ mkimage -A arm -O u-boot -T kernel -C none \ -a 0x3000000 -e 0x3000000 -n "UBoot dns323" \ -d u-boot.bin uImage.bin
My TEXT_BASE is identical to yours: 0x100000
Does that make a difference, if the u-boot image is chain loaded from another one?
This is what I found in the vendor code:
./board/mv88fxx81/db88f5181/config_tiny.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config_prpmc.mk:TEXT_BASE = 0x02f10000 ./board/mv88fxx81/db88f5181/config_def.mk:TEXT_BASE = 0x00f10000 ./board/mv88fxx81/db88f5181/config_tiny_voip.mk:TEXT_BASE = 0x00f40000 ./board/mv88fxx81/db88f1181/config.mk:TEXT_BASE = 0x00f00000
I'm not sure which config has been used for the version of u-boot on my board, though.
At any rate, those are all substantially higher than I am currently using.
I'll try with a higher value, and see what happens.
Quoted 4 lines
FYI, in my u-boot edminiv2 support code, I had issues with big kernels, so I decided to move u-boot's final location as high in RAM as by board allows, so that it never will be overwritten by Linux (unless I load a 63+ MB kernel, that is :) )
That was my reasoning with the 48MB, too :-)
Rogan
Quoted 2 lines · Rogan Dawes
I'll try with a higher value, and see what happens.
So, I tried with TEXT_BASE=f10000, and I got a bit further:
DNS323B1> bootm FF820000
## Booting kernel from Legacy Image at ff820000 ...
Image Name: Linux-2.6.12.6-arm1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1490204 Bytes = 1.4 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Using machid 0x526 from environment
Starting kernel ...
Uncompressing Linux................................................................................................... done, booting the kernel.
So, that does appear to have been (at least part of) the problem.
Now to figure out why I'm not getting any further than this. (And why the vendor ramdisk is giving me CRC errors).
Rogan
Le 17/08/2010 13:42, Rogan Dawes a ?crit :
Quoted 18 lines · Rogan Dawes
Quoted 2 lines
I'll try with a higher value, and see what happens.
So, I tried with TEXT_BASE=f10000, and I got a bit further:
DNS323B1> bootm FF820000
## Booting kernel from Legacy Image atff820000...Image Name: Linux-2.6.12.6-arm1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1490204 Bytes = 1.4 MiBLoad Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Using machid0x526from environment
Quoted 7 lines
Starting kernel ...
Uncompressing Linux................................................................................................... done, booting the kernel.
So, that does appear to have been (at least part of) the problem.
Ok, so u-boot is now out of the way of the linux image load area.
Quoted 2 lines
Now to figure out why I'm not getting any further than this. (And why the vendor ramdisk is giving me CRC errors).
What is the actual command you use for booting your kernel? IIUC (and if I trust the few experiments I did on edminiv2 with ramdisks) you need to pass the ramdisk address to the bootm command, e.g. bootm ff820000 ff8xxxxx (where xxxxx is your ramdisk's location in flash (I'm assuming your ramdisk image is in flash as your kernel image is). You did an 'iminfo' on both images to verify their integrity, didn't you?
Amicalement,
Signature · 1 line
Albert.
Quoted 5 lines · Albert ARIBAUD
Ok, so u-boot is now out of the way of the linux image load area.
Quoted 2 lines
Now to figure out why I'm not getting any further than this. (And why the vendor ramdisk is giving me CRC errors).
Quoted 8 lines
What is the actual command you use for booting your kernel? IIUC (and if I trust the few experiments I did on edminiv2 with ramdisks) you need to pass the ramdisk address to the bootm command, e.g. bootm
ff820000ff8xxxxx (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
Quoted 6 lines · Rogan Dawes
Am I mistaken in expecting the machid environment variable trick to work?
Thanks
Rogan
No, but mistaken in thinking that the machid was in decimal, when it is really in hex.
Now to figure out why the CRC calculations are different, and I'll have a fully functioning u-boot!
Thanks so much to everyone who has helped me get this far!
Rogan
Dear Rogan Dawes,
Quoted 6 lines · In message <[email protected]> you wrote:
No, but mistaken in thinking that the machid was in decimal, when it is really in hex.
Now to figure out why the CRC calculations are different, and I'll have a fully functioning u-boot!
For a test you could as ell disable CRC checking:
=> setenv verify no => save
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de It is much easier to suggest solutions when you know nothing
Quoted 10 lines · Wolfgang Denk
Dear Rogan Dawes,
Quoted 6 lines · In message <[email protected]> you wrote:
No, but mistaken in thinking that the machid was in decimal, when it is really in hex.
Now to figure out why the CRC calculations are different, and I'll have a fully functioning u-boot!
Quoted 9 lines
For a test you could as ell disable CRC checking:
=> setenv verify no => saveBest regards,
Wolfgang Denk
Hi Wolfgang,
Yes, I found that while I was trying to see if the CRC calculation had changed, but it did not work.
For some reason, the kernel didn't seem to think it had been given the ramdisk parameter. At least, I get the following error message:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)
Hmmm! Diff of the boot logs shows (mainline vs vendor):
< initrd (0xff9a0040 - 0xffe9f758) extends beyond physical memory - disabling initrd
---
Quoted 1 line
Using UBoot passing parameters structure
Also potentially interesting is:
< Memory: 64MB = 64MB total
< Memory: 61696KB available (2599K code, 462K data, 112K init)
---
Quoted 2 lines
Memory: 64MB 0MB 0MB 0MB = 64MB total
Memory: 56576KB available (2599K code, 462K data, 112K init)
It seems that the amount of memory is being passed differently to the kernel (1 bank vs 4)?
Keeping in mind that this is the same kernel executing, just with a different setup code or parameters.
I'll keep investigating.
Rogan
Dear Rogan Dawes,
Quoted 3 lines · In message <[email protected]> you wrote:
For some reason, the kernel didn't seem to think it had been given the ramdisk parameter. At least, I get the following error message:
Where is the ramdisk located? Make sure it is loaded into RAM (not flash!).
Best regards,
Wolfgang Denk
Signature · 7 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Anyone who knows history, particularly the history of Europe, will, I think, recognize that the domination of education or of government by any one particular religious faith is never a happy arrangement for the people. - Eleanor Roosevelt
Quoted 7 lines · Wolfgang Denk
Dear Rogan Dawes,
Quoted 3 lines · In message <[email protected]> you wrote:
For some reason, the kernel didn't seem to think it had been given the ramdisk parameter. At least, I get the following error message:
Quoted 6 lines
Where is the ramdisk located? Make sure it is loaded into RAM (not flash!).
Best regards,
Wolfgang Denk
Hi Wolfgang,
The ramdisk is located at ff9a0000 (in flash). Its image header relocates it to 00800000:
Dear Rogan Dawes,
Quoted 3 lines · In message <[email protected]> you wrote:
The ramdisk is located at
ff9a0000(in flash). Its image header relocates it to 00800000:
Try to copy the ramdisk to RAM, and pass the Linux kernl an address in RAM.
Try it.
Best regards,
Wolfgang Denk
Signature · 8 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de I realize that command does have its fascination, even under circum- stances such as these, but I neither enjoy the idea of command nor am I frightened of it. It simply exists, and I will do whatever logi- cally needs to be done. -- Spock, "The Galileo Seven", stardate 2812.7
Quoted 7 lines · Wolfgang Denk
Dear Rogan Dawes,
Quoted 3 lines · In message <[email protected]> you wrote:
The ramdisk is located at
ff9a0000(in flash). Its image header relocates it to 00800000:
Quoted 9 lines
Try to copy the ramdisk to RAM, and pass the Linux kernl an address in RAM.
Try it.
Best regards,
Wolfgang Denk
Hi Wolfgang,
Thanks for the suggestion. It did make a slight difference in the boot logs. bootcmd uses the default (in flash) location for the ramdisk, while the second one has a copy of the ramdisk image at 1600000 (including the header). Both logs are using mainline u-boot, not the vendor one.
< DNS323B1> run bootcmd
Quoted 1 line
DNS323B1> bootm
ff8200001600000
< ## Loading init Ramdisk from Legacy Image@ff9a0000 ...
Quoted 1 line
## Loading init Ramdisk from Legacy Image at 01600000 ...
< initrd (0xff9a0040 - 0xffe9f758) extends beyond physical memory - disabling initrd
Quoted 1 line
checking if image is initramfs...it isn't (no cpio magic); looks like
an initrd
Quoted 4 lines
Freeing initrd memory: 5117K
RAMDISK: Compressed image found at block 0
invalid compressed format (err=1)
So it seems that the ramdisk is getting corrupted somehow. And yet, it is fine using the vendor u-boot. It must be something that I am doing wrong.
Rogan
Dear Rogan Dawes,
Quoted 3 lines · In message <[email protected]> you wrote:
Thanks for the suggestion. It did make a slight difference in the boot logs. bootcmd uses the default (in flash) location for the ramdisk,
Actually it's a pretty significant difference, as for the first time you actually see the kernel trying to access the ramdisk.
Quoted 5 lines
Quoted 2 lines
RAMDISK: Compressed image found at block 0
invalid compressed format (err=1)So it seems that the ramdisk is getting corrupted somehow. And yet, it is fine using the vendor u-boot. It must be something that I am doing wrong.
Try copying the raw ramdisk image (i. e. without the U-Boot header) to RAM, and try that one, i. e. something like
=> cp.b ff9a0040 01600000 ...size... ... => bootm ff820000 1600000
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de If in any problem you find yourself doing an immense amount of work, the answer can be obtained by simple inspection.
Quoted 9 lines · Wolfgang Denk
Dear Rogan Dawes,
Quoted 3 lines · In message <[email protected]> you wrote:
Thanks for the suggestion. It did make a slight difference in the boot logs. bootcmd uses the default (in flash) location for the ramdisk,
Actually it's a pretty significant difference, as for the first time you actually see the kernel trying to access the ramdisk.
Good point! :-)
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
RAMDISK: Compressed image found at block 0
invalid compressed format (err=1)So it seems that the ramdisk is getting corrupted somehow. And yet, it is fine using the vendor u-boot. It must be something that I am doing wrong.
Quoted 6 lines
Try copying the raw ramdisk image (i. e. without the U-Boot header) to RAM, and try that one, i. e. something like
=> cp.b ff9a0040 01600000 ...size... ... => bootm ff820000 1600000
Unfortunately, U-boot is expecting the second parameter to point to a uImage-wrapped ramdisk, not just raw bytes:
DNS323B1> cp.b ff9a0040 1600000 4ff718 DNS323B1> bootm ff820000 1600000
## Booting kernel from Legacy Image at ff820000 ...
Image Name: Linux-2.6.12.6-arm1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1490204 Bytes = 1.4 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
DNS323B1>
Why does it make a difference if it is in RAM vs in flash? I have 8MB of flash located at ff800000, so that reaches all the way to 0xffffffff. Surely that should be Ok? Besides, U-boot is supposed to copy the data in the image to the specified destination address, isn't it?
Rogan
Dear Rogan Dawes,
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 7 lines
Try copying the raw ramdisk image (i. e. without the U-Boot header) to RAM, and try that one, i. e. something like
=> cp.b ff9a0040 01600000 ...size... ... => bootm ff820000 1600000Unfortunately, U-boot is expecting the second parameter to point to a uImage-wrapped ramdisk, not just raw bytes:
Yes, I know. I was just trying out some things - I don't know in which way your U-Boot version might have been modified...
Quoted 1 line
Why does it make a difference if it is in RAM vs in flash? I have 8MB of
Your kernel may not be able to pick up a ramdisk image in flash.
Mainline ARM cannot do that, for example.
[Patches to support that have been submitted, but rejected.]
Quoted 2 lines
Surely that should be Ok? Besides, U-boot is supposed to copy the data in the image to the specified destination address, isn't it?
No, why should it copy the image? It just verifies that the checksum is OK, and then passes the address to the kernel. The kernel will have to copy it anyway when uncompressing it, so ther ei no use in U-Boot adding another copy operation.
Best regards,
Wolfgang Denk
Signature · 7 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Misquotation is, in fact, the pride and privilege of the learned. A
widely-read man never quotes accurately, for the rather obvious
reason that he has read too widely.
- Hesketh Pearson _Common Misquotations_ introductionQuoted 8 lines · Wolfgang Denk
Dear Rogan Dawes,
Your kernel may not be able to pick up a ramdisk image in flash.
Mainline ARM cannot do that, for example.
[Patches to support that have been submitted, but rejected.]
Quoted 7 lines
Quoted 2 lines
Surely that should be Ok? Besides, U-boot is supposed to copy the data in the image to the specified destination address, isn't it?
No, why should it copy the image? It just verifies that the checksum is OK, and then passes the address to the kernel. The kernel will have to copy it anyway when uncompressing it, so ther ei no use in U-Boot adding another copy operation.
Well, I thought that was the point of the "mkimage" header, with the Load Address and Entry Point fields. Although, of course, you'll never actually "enter" a ramdisk image. I had still thought that they would be copied, regardless. Otherwise, what is the point in specifying those fields? They might just as well be zero.
But yes, what you say makes sense.
This appears to be the answer, from Marvell's u-boot sources, in lib_arm/armlinux.c, inside the #ifdef RAMDISK block:
#ifdef DEBUG
if (!data) {
printf ("No initrd\n");
}#endif
if (data) {
#ifdef RAMDISK
initrd_start = ntohl(hdr->ih_load);
initrd_end = initrd_start + len;
memmove ((void *)initrd_start, (void *)data, len);
#else
initrd_start = data;
initrd_end = initrd_start + len;
#endif
} else {
initrd_start = 0;
initrd_end = 0;
}and then later:
#ifdef CONFIG_INITRD_TAG
if (initrd_start && initrd_end)
setup_initrd_tag (bd, initrd_start, initrd_end);#endif
So, clearly, the address that the kernel is expecting MUST be within RAM, and MUST exclude the header.
So, the question then is, what is current u-boot doing? And why does it not work when the ramdisk is copied over to memory?
It looks like U-Boot for ARM doesn't handle ramdisks at all? From common/cmd_bootm.c:
#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
case BOOTM_STATE_RAMDISK:
{
ulong rd_len = images.rd_end - images.rd_start;
char str[17];
ret = boot_ramdisk_high(&images.lmb,
images.rd_start,
rd_len, &images.initrd_start,
&images.initrd_end);
if (ret)
return ret;
sprintf(str, "%lx", images.initrd_start);
setenv("initrd_start", str);
sprintf(str, "%lx", images.initrd_end);
setenv("initrd_end", str);
}
break;#endif
But this is only enabled for PPC, M68K and SPARC.
Is this the missing functionality that I am looking for?
Rogan
Dear Rogan Dawes,
Quoted 3 lines · In message <[email protected]> you wrote:
Well, I thought that was the point of the "mkimage" header, with the Load Address and Entry Point fields. Although, of course, you'll never
These fields are only relevant for executable images, not for data like ramdisk images.
Quoted 3 lines
actually "enter" a ramdisk image. I had still thought that they would be copied, regardless. Otherwise, what is the point in specifying those fields? They might just as well be zero.
Indeed, and that's they usally are:
-> mkimage -l /opt/eldk-4.2/arm/images/uRamdisk Image Name: Simple Embedded Linux Framework Created: Sun Dec 7 18:27:20 2008 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 1659739 Bytes = 1620.84 kB = 1.58 MB Load Address: 00000000 Entry Point: 00000000
Copying the image is just a waste of boot time. I see no reeason why the kernel should not be able to read the image from RAM or from flash. On PowerPC this has always been possible, for well over a decade now. But in ARM land they reject patches that would add such support.
Quoted 1 line
So, the question then is, what is current u-boot doing? And why does it
In mainline code, it is supposed to verify the checksum and pass the start address of the data to the kernel.
Quoted 1 line
not work when the ramdisk is copied over to memory?
This I cannot answer.
Quoted 2 lines
It looks like U-Boot for ARM doesn't handle ramdisks at all? From
common/cmd_bootm.c:
It does.
Quoted 2 lines
#if
defined(CONFIG_PPC)||defined(CONFIG_M68K)||defined(CONFIG_SPARC)
caseBOOTM_STATE_RAMDISK:
This is actually the wrong place.
Quoted 1 line
Is this the missing functionality that I am looking for?
No.
For a test you might try to hook into this part of code, though:
"common/image.c":
952 #if defined(CONFIG_B2) || defined(CONFIG_EVB4510) || defined(CONFIG_ARMADILLO)
953 /*
954 * We need to copy the ramdisk to SRAM to let Linux boot
955 */
956 if (rd_data) {
957 memmove ((void *)rd_load, (uchar *)rd_data, rd_len);
958 rd_data = rd_load;
959 }
960 #endif /* CONFIG_B2 || CONFIG_EVB4510 || CONFIG_ARMADILLO */
This indeed performs a copy to the load address, as you expected.
Here is a log from a working example (QOng board, i. e. ARM11):
=> run flash_self
## Booting kernel from Legacy Image at a00a0000 ...
Image Name: Linux-2.6.34-rc1 Created: 2010-04-28 22:07:22 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1964848 Bytes = 1.9 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at a0300000 ...
Image Name: Simple Embedded Linux Framework Created: 2008-11-24 16:44:17 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 1659703 Bytes = 1.6 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34-rc1 (wd at sirius.denx.de) (gcc version 4.2.2) #3 Thu Apr 29 00:07:17 CEST 2010
CPU: ARMv6-compatible processor [4107b364] revision 4 (ARMv6TEJ), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Dave/DENX QongEVB-LITE
Memory policy: ECC disabled, Data cache writeback
INITRD: 0xa0300040+0x00195337 extends beyond physical memory - disabling initrd
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/ram rw ramdisk_size=8192 ip=192.168.20.12:192.168.1.1::255.255.0.0:qong:eth0:off panic=1 console=ttymxc0,115200 mtdparts=physmap-flash.0:384k(U-Boot),128k(env1),128k(env2),2432k(kernel),61m(rootfs),64m(user) ethaddr=00:50:c2:1e:af:e7 nohlt
...
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
...
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 140K
init started: BusyBox v1.7.1 (2008-11-24 17:40:49 MET)
starting pid 612, tty '': '/etc/rc.sh'
starting pid 617, tty '': '/bin/application'
### Application running ...
starting pid 618, tty '': '/bin/sh'
~ # eth0: link up (100/Full)
~ #
[Note: the Qong is running a kernel version that has the patch added which supports loading the ramdisk image from a flash address.]
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The years of peak mental activity are undoubtedly between the ages of four and eighteen. At four we know all the questions, at eighteen all the answers.
Dear Rogan Dawes,
Quoted 7 lines · In message <[email protected]> you wrote:
I'm not passing the second parameter at this stage, because the ramdisk is failing the CRC32 check for some reason. It may be that the CRC32 calculation has changed between 1.1.1 which was the base for the vendor u-boot, and mainline. e.g. rather than being calculated over the precise length of the data, it is calculated over the entire block. Just a guess, of course.
That's a wild guess actually, and I bet a beer or two that its a wrong one.
Quoted 7 lines
I had been led to believe that it was possible to override the compiled in mach type by setting a "machid" environment variable. This would give me the best of both worlds - a u-boot compiled according to mainline registered numbers, with the ability to boot vendor firmware by simply setting an environment variable.
Unfortunately, this did not work for me :-(
This feature was introduced by commit 3c234efa, dated 2008-01-30. Eventually your U-Bootimage predates this...
Quoted 1 line
Am I mistaken in expecting the machid environment variable trick to work?
It should work in reasonably recent versions of U-Boot.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de If you believe that feeling bad or worrying long enough will change a past or future event, then you are residing on another planet with a different reality system.