Hi Wolfgang,
Thanks for the inputs. So what you are saying that we have eliminated all cases of the bootloader being at fault here except for the mach id mismatch.?? How do i verify the mach id mismatch. Is it the same id i see on a "bdinfo" dump on uboot. I looked at linux/include/asm/mach-types.h in linux . Is that the correct place to look at?
From the uboot code and the uboot config bdinfo structure,looks like machine
id is set correctly Bdinfo on uboot prompt gives me "5E7" which is 1511 i.e the machine id set in the kernel for the target -MX31 3stack board. What else could be wrong?
How do i debug this kind of an issue on the BDI since it may fall between the thin line of separation between MMU disabled and reenabled.
Can i put a breakpoint on a specific_thing like start_kernel ..or do you mean doing a backtrace from the point it hangs? I am using PDK which actually limits me to change boot switches for booting it from NAND or RAM.
Thanks.