[U-Boot] 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 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
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
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
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
On 2010/08/16 10:29 PM, Wolfgang Denk wrote:
Dear Rogan Dawes,
In message4C699C6E.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 CRCRamdisk 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
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 |= (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 */
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
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
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
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
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
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 CRCRamdisk 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
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 CRCRamdisk 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
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,
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
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,
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
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
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,
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
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
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
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
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
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:
From the vendor u-boot:
## Loading Ramdisk Image at ff9a0000 ... Image Name: Ramdisk Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5240600 Bytes = 5 MB Load Address: 00800000 Entry Point: 00800000 Verifying Checksum ... OK
And from mine:
DNS323B1> setenv verify no DNS323B1> run bootcmd ## 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 ## 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 Loading Kernel Image ... OK OK
0x800000 is well within the 64MB that the device has.
Regards,
Rogan
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
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 at 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
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
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
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
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
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@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
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
participants (4)
-
Albert ARIBAUD -
Gérald Kerma -
Rogan Dawes -
Wolfgang Denk