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?
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.
On Thu, Apr 23, 2009 at 11:05 AM, Wolfgang Denk wd@denx.de wrote:
Dear alfred steele,
In message 528f13590904230720n14e87cchb87505c1de085be5@mail.gmail.com you wrote:
I am using an uImage generated by LTIB . I am not sure how the ideal uImage is generated for the PDK board.
...
Starting kernel ...
U-Boot's responsibility end's here.
Uncompressing Linux............................................................. ............................................... done, booting the kernel.
<IT freezes here>
Attach a BDI and debug where it's hanging. Eventually just your machine ID is wrong.
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@denx.de Make it right before you make it faster.