[U-Boot-Users] Booting Linux stops at Starting Kernel, perhaps an endian problem
Hi all,
We're trying to make Linux run on our DBPXA based platform. U-boot works fine, we can communicate through serial line with it, using Minicom or HyperTerminal.
The kernel and file system image (u-boot multi image) is loaded into RAM with kermit at 0xa3100000. But, when we try to boot linux with the bootm command, it stops at "Starting Kernel" (We're working with Linux kernel 2.4.19 patched with -rmk7-pxa1 in eLinOS distribution).
In order to see if something went wrong, we've compared vmlinux.bin before compression and the kernel decompressed in RAM, in position Load_address. We've found that the information is the same but one is in big endian (in RAM) and the other one in little endian (vmlinux.bin). The platform works in little endian, so this is probably the problem. How can we solve it?? Is it a gunzip problem??
Thanks in advance
Best regards,
Sonia
On Thu, 4 Mar 2004, Sonia Martinez wrote:
The kernel and file system image (u-boot multi image) is loaded into RAM with kermit at 0xa3100000. But, when we try to boot linux with the bootm command, it stops at "Starting Kernel" (We're working with Linux kernel 2.4.19 patched with -rmk7-pxa1 in eLinOS distribution).
In order to see if something went wrong, we've compared vmlinux.bin before compression and the kernel decompressed in RAM, in position Load_address. We've found that the information is the same but one is in big endian (in RAM) and the other one in little endian (vmlinux.bin). The platform works in little endian, so this is probably the problem. How can we solve it?? Is it a gunzip problem??
It seems very unlikely to me that your u-boot has decompressed your kernel into a wrong endianess. Have double checked that you're really looking at what you're think you're looking at?
It is much more likely that your kernel might not be properly supporting your board in the early boot phase and just hangs there. Depending how far it got, you may try to check the contents of the kernel's log_buf array after resetting the hardware. All the early printk()s go there before the serial driver is started.
Regards, Marius
If your memory displaying programm reads word in memory, and then use some printf like function to display them, then it will appear as big endian, while the storage is little endian.
int foo; foo = 0x01020304; printf("0x%x\n",foo);
will display 0x01020304, but if you look at the memory address of foo, you will "see" 0x04030201
JP Francois *********** REPLY SEPARATOR ***********
On 04/03/2004 at 09:44 Marius Groeger wrote:
On Thu, 4 Mar 2004, Sonia Martinez wrote:
The kernel and file system image (u-boot multi image) is loaded into RAM with kermit at 0xa3100000. But, when we try to boot linux with the bootm command, it stops at "Starting Kernel" (We're working with Linux kernel 2.4.19 patched with -rmk7-pxa1 in eLinOS distribution).
In order to see if something went wrong, we've compared vmlinux.bin before compression and the kernel decompressed in RAM, in position Load_address. We've found that the information is the same but one is in big endian (in RAM) and the other one in little endian (vmlinux.bin). The platform works in little endian, so this is probably the problem. How can we solve it?? Is it a gunzip problem??
It seems very unlikely to me that your u-boot has decompressed your kernel into a wrong endianess. Have double checked that you're really looking at what you're think you're looking at?
It is much more likely that your kernel might not be properly supporting your board in the early boot phase and just hangs there. Depending how far it got, you may try to check the contents of the kernel's log_buf array after resetting the hardware. All the early printk()s go there before the serial driver is started.
Regards, Marius
-- Marius Groeger mgroeger@sysgo.com Project Manager
SYSGO Real-Time Solutions AG | Embedded and Real-Time Software Am Pfaffenstein 14 55270 Klein-Winternheim, Germany
Voice: +49-6136-9948-0 | FAX: +49-6136-9948-10 www.sysgo.com | www.elinos.com | www.osek.de
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message BAY15-DAV62qyFp4gpr000115c9@hotmail.com you wrote:
The kernel and file system image (u-boot multi image) is loaded into RAM with kermit at 0xa3100000. But, when we try to boot linux with the bootm command, it stops at "Starting Kernel" (We're working with Linux kernel 2.4.19 patched with -rmk7-pxa1 in eLinOS distribution).
In order to see if something went wrong, we've compared vmlinux.bin before compression and the kernel decompressed in RAM, in position Load_address. We've found that the information is the same but one is in big endian (in RAM) and the other one in little endian (vmlinux.bin). The platform works in little endian, so this is probably the problem. How can we solve it?? Is it a gunzip problem??
I cannot see how gunzip could perform a byte swapping.
Kermit binary protocol is byte oriented, so it definitely does not do any byte swapping either.
How did you compare the images?
Best regards,
Wolfgang Denk
participants (4)
-
Jean-Philippe Francois -
Marius Groeger -
Sonia Martinez -
Wolfgang Denk