Hi,
I am using an uImage generated by LTIB . I am not sure how the ideal uImage is generated for the PDK board. I try booting this uimage from RAM and then load it at 80008000.
It gets stuck after "done, booting the kernel." Please see the bootup messages below.
Any hints? I hope with, 0x80008000 as the load address on the MX31, you eliminate the cause of one probable failure, overlay memory with the existing code on RAM e.g. existing u-boot and the compressed kernel image
mc911x: MAC 92:92:92:bb:bb:bb TFTP from server 206.44.18.25; our IP address is 206.44.18.31 Filename 'uImage_spin2'. Load address: 0x80800000 Loading: ################################################################# ################################################# done Bytes transferred = 1665060 (196824 hex) ## Booting kernel from Legacy Image at 80800000 ... Image Name: Linux-2.6.24-140-g68eb4b4 Created: 2009-04-23 3:28:44 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1664996 Bytes = 1.6 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux............................................................. ............................................... done, booting the kernel.
<IT freezes here>
Thanks, Alfred.
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
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.
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.
On Thu, Apr 23, 2009 at 09:20:41AM -0500, alfred steele wrote:
Any hints? I hope with, 0x80008000 as the load address on the MX31, you eliminate the cause of one probable failure, overlay memory with the existing code on RAM e.g. existing u-boot and the compressed kernel image
mc911x: MAC 92:92:92:bb:bb:bb TFTP from server 206.44.18.25; our IP address is 206.44.18.31 Filename 'uImage_spin2'. Load address: 0x80800000 Loading: ################################################################# ################################################# done Bytes transferred = 1665060 (196824 hex) ## Booting kernel from Legacy Image at 80800000 ... Image Name: Linux-2.6.24-140-g68eb4b4 Created: 2009-04-23 3:28:44 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1664996 Bytes = 1.6 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
Uncompressing Linux............................................................. ............................................... done, booting the kernel.
See http://lists.arm.linux.org.uk/lurker/message/20081210.174754.29691349.en.htm...
participants (3)
-
alfred steele -
Daniel Mack -
Wolfgang Denk