[U-Boot-Users] Linux kernel startup
Hi Harald,
The serial issues were solved. As u said, the problem was with the RTS/CTS. I disabled all the hardware control signals and some modifications with the relocation section in the start.S and it started working.
Now the issue is with the kernel CRC32 check. I compiled a kernel with the smdk2440 architecture and I do the following.
$ arm-linux-objcopy -O binary -R .note -R .comment -S vmlinux linux.bin $ gzip -9 linux.bin $../u-boot-1.3.2/tools/mkimage -A arm -O linux -T kernel -C gzip -a0x30008000 -e 0x30008000 -n "Linux kernel" -d linux.bin.gz uImage.bin
The size of vmlinux is around 25MB. When converted to linux.bin it is 3GB, when gziped it is around 4MB and when done an mkimage it remains almost the same..
The output is as follows:
U-Boot 1.3.2 (Apr 7 2008 - 12:14:29)
DRAM: 128 MB Flash: 32 MB Using default environment
In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 ## Booting image at 33000000 ... Image Name: Linux kernel Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 4271633 Bytes = 4.1 MB Load Address: 30008000 Entry Point: 30008000 Verifying Checksum ... Bad Data CRC
What ever kernel image I load it tells the same ie. "Verifying Checksum ... Bad Data CRC". I even tried the uImage.bin which was available on openmoko site and the same error occurs.
Is the error with the bootloader or the kernel image? If so what are the changes to be done?
Thanks in advance. Tiju
Messenger blocked? Want to chat? Go to http://in.messenger.yahoo.com/webmessengerpromo.php
On Mon, Apr 07, 2008 at 02:31:10PM +0530, Tiju wrote:
Hi Harald,
The serial issues were solved. As u said, the problem was with the RTS/CTS. I disabled all the hardware control signals and some modifications with the relocation section in the start.S and it started working.
great.
Now the issue is with the kernel CRC32 check. I compiled a kernel with the smdk2440 architecture and I do the following.
Please see my other e-mail response about this. I still believe there might be some wrong memory / bus / core clock timing and or voltage issues. please try to use u-boot's built-in memory verification code to veryify your memory before trying to boot a kernel on it.
What basically happens is that u-boot copies your kernel image from storage medium to SDRAM, and then tries to checksum it. If the original image is correct, and the copy in SDRAM isn't, this means that you somehow have memory corruption.
Is the hardware a prototype of a new board, or is it proven, verified hardware? If it's a new board, there can be dozens of different reasons why the PLL might run instable, the power lines have too much noise, etc.
Even if it's verified hardware, the particular PLL speed for memory or CPU clock used by your u-boot image might not be within whatever your hardware configuration supports.
So I would reconfigure all memory timings to their most conservative (slowest) setting, and run the bus at 25 or 50MHz, the CPU core at 100MHz and re-try. If the memory check and/or system boot works this way, you can try to increase the timings incrementally up to your desired configuration.
Tiju wrote:
Hi Harald,
The serial issues were solved. As u said, the problem was with the RTS/CTS. I disabled all the hardware control signals and some modifications with the relocation section in the start..S and it started working.
Now the issue is with the kernel CRC32 check. I compiled a kernel with the smdk2440 architecture and I do the following.
$ arm-linux-objcopy -O binary -R .note -R .comment -S vmlinux linux.bin $ gzip -9 linux.bin $ ../u-boot-1.3.2/tools/mkimage -A arm -O linux -T kernel -C gzip -a 0x30008000 -e 0x30008000 -n "Linux kernel" -d linux.bin.gz uImage.bin
The size of vmlinux is around 25MB. When converted to linux.bin it is 3GB, when gziped it is around 4MB and when done an mkimage it remains almost the same.
This is indicating you have major link / memory map / coding issue(s). vmlinux should be around 1MB, not 25MB! linux.bin should be around the same size as vmlinux. Having linux.bin grow to be 3GB indicates it has major holes in it that objdump is filling with "fill" values.
Loading a 3GB image (compressed to 4MB or not) is simply not going to work.
Use objdump to dump the section headers of the elf file (vmlinux) to see what addresses are being used and sizes of the sections. Figure out why it is producing pieces of code/data in widely varying address locations and possibly large sections of "bad" stuff. Until you fix your link, you aren't going to have any success loading it.
Good luck, gvb
participants (3)
-
Harald Welte -
Jerry Van Baren -
Tiju