Dear Christopher Harvey,

In message 4E0B20D0.4070000@matrox.com you wrote:

I was under the impression that the second a working kernel got passed the "Uncompressing Linux... done, booting the kernel." point there was very little that could go wrong since it means the kernel was completely loaded into memory and the entry point was picked properly.

You are perfectly right and totally wrong.

Yes, you are right: when reaching this point there is not much left that can go wrong - in U-Boot, that is.

But of course there is a million things that can go wrong in Linux, and it appears you are running onto one of these.

The kernel is a very standard kernel, and uboot is a very minimal uboot build with no extra soc or board initializations besides memory size. eg: lowlevel_init is blank reset_cpu is an infinite loop timers aren't used

May I suggest to run a standard U-Boot version instead, which includes all the necessary initialization?

You don't mention a board name, so I guess all your code is not available in mainline?

Best regards,

Wolfgang Denk

On 06/29/11 08:55, Christopher Harvey wrote:

kernel version: 2.6.38 u-boot version: 2011.06

I've got an ARM (armv7) kernel that I can boot under QEMU without problems, but refuses to boot with a bootm command under u-boot.

All I see is "Uncompressing Linux... done, booting the kernel.", then nothing else.

I'm also hitting a bug very similar to the following with gdb, so I'm having a hard time figuring out exactly which lines are blocking the kernel. http://sourceware.org/ml/gdb-patches/2011-02/msg00048.html but that patch doesn't fix it in my case.

Basically I was hoping for some hints in case somebody here has already dealt with a similar problem and could provide some tips to help me figure out how to spend my debugging time.

I was under the impression that the second a working kernel got passed the "Uncompressing Linux... done, booting the kernel." point there was very little that could go wrong since it means the kernel was completely loaded into memory and the entry point was picked properly.

The kernel is a very standard kernel, and uboot is a very minimal uboot build with no extra soc or board initializations besides memory size. eg: lowlevel_init is blank reset_cpu is an infinite loop timers aren't used

any hints or ideas appreciated, Chris

Turns out I wasn't passing the machine ID or the initrd values to the r1 and r2 registers.

using a standard board_init function fixed it.

I've been learning and working on u-boot on and off for 2 weeks and solved it literally an hour or two after asking this question. It's amazing how often that happens.

U-Boot is working great now.

thanks, -C