[U-Boot] request for some debugging hints

[U-Boot] request for some debugging hints

[Christopher Harvey]

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

[U-Boot] request for some debugging hints

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The most difficult thing in the world is to know how to  do  a  thing
and to watch someone else doing it wrong, without commenting.
                                                        -- T.H. White

[U-Boot] request for some debugging hints

[Chander Kashyap]

Dear Christopher Harvey,
One thought.. Just check you are using correct serial port as console.


On 29 June 2011 18:25, Christopher Harvey <charvey@matrox.com> 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
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



-- 
with warm regards,
Chander Kashyap

[U-Boot] request for some debugging hints

[Christopher Harvey]

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