[Buildroot] Searching for some advice

[Thomas De Schampheleire]

Hi Charles,

[this doesn't really have anything to do with buildroot, but anyway...]

On Tue, Aug 27, 2013 at 12:21 AM, Charles Krinke
<charles.krinke at gmail.com> wrote:
> Its my turn to be a noob today.
>
> I have a powerpc design using the mpc832x_rdb that is currently
> 2.6.35.12 and I am trying to test compile 2.6.39 and am hung up in a
> freeze right after the dtb is loaded.
>
> I am searching for an opinion or two on:
>
> a) What are the things most likely to cause a freeze after loading dtb
> between a 2.6.35.12 kernel and 2.6.39 where the dtb has not changed
> and

>From your explanation I take it that you compared the device trees in
the linux kernel source tree (arch/powerpc/boot/dts/mpc832x_rdb.dts)
between both kernel versions, correct?

When you say 'freeze' what exactly do you mean? Did you get any output
at all from the kernel? Any output afterwards? Are you sure the kernel
is actually frozen, or maybe there is just no serial output?
You could try to manipulate a LED (or other device) from some points
in the kernel, to get some proof whether the kernel actually stopped
completely or there is a serial output problem.

How are you booting? How is the device tree passed? Are you sure the
device tree is actually present from the location the kernel tries to
load it from?

Did you verify the kernel configuration? If you compare your original
config with the one from the new kernel: does everything look OK? Did
you effectively run 'make oldconfig' from the kernel sources to
migrate the config?
I recently also tried updating kernels, and noticed that if you just
give the new kernel to buildroot, it will do some automatic
application of the old config to the new kernel, without actually
launching oldconfig. I didn't double check this (my memory may be bad)
but the end result was anyway that some things were misconfigured.

>
> b) Is there any way to debug the kernel when it freezes after loading
> the dtb other then admire it when it freezes.

If you have access to a JTAG probe that would obviously help, because
you could then step through the kernel.
Alternatively, you could consider kdb or kgdb, but I haven't used them
before and I don't know how early they are setup during boot. Very
likely they are not yet available if the freeze is already during
device tree loading...

If there is any serial output before loading the device tree, you
could dig in the kernel and add printk statements to zoom in on the
problem.

Best regards,
Thomas