[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
Hi All,
I have now managed to get the image to be read in and kernel image uncompressed etc. I am getting the problem where it hangs after Uncompression though. My previous issue with Bad Magic Number errors was due to the compilation of the mkimage tool. It was producing images with the wrong endianness in the header. Not sure if this may still be my problem tho :)
I have tried both settings of clocks_in_mhz and have made sure that I copied u-boot.h from uboot to ppcboot.h in Linux. I have made sure that IMAP_ADDR is correct but I still get the same thing, just hangs after uncompression. I am totally stumped.
My board is an adaptation of the MPC8260ADS. I am using BlueCat 4.0 and u-boot 4.8 (tried 4.0 and 4.7) etc and have tried booting both the uImage and kdi files (after turning them into u-boot images with mkimgage).
Here is a print out with extra debug info when trying a kdi image called Q319.img: ---------------------------------------------------------------------------- --------------
=> tftpboot 100000 Q319.img Trying FCC2 ETHERNET TFTP from server 192.168.1.1; our IP address is 192.168.1.2 Filename 'Q319.img'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################################################# done Bytes transferred = 3637824 (378240 hex) => bootm common/cmd_bootm.c before attempting to boot an image ## Booting image at 00100000 ... common/cmd_bootm.c Image header has correct magic number common/cmd_bootm.c Image header has correct checksum Image Name: Linux Kernel Image Image Type: PowerPC LynxOS Kernel Image (uncompressed) Data Size: 3637760 Bytes = 3.5 MB Load Address: 00500000 Entry Point: 00507000 Verifying Checksum ... OK common/cmd_bootm.c Image data has correct checksum common/cmd_bootm.c Architecture check OK common/cmd_bootm.c Image Type check OK OK common/cmd_bootm.c Uncompression OK common/cmd_bootm.c Image Type check OK Booting Bluecat KDI ... loaded at: 00507000 005121DC zimage at: 0050D000 0057366C initrd at: 00575000 00878200 relocated to: 00576000 00879200 avail ram: 0087A000 04000000
Linux/PPC load: root=/dev/ram root=/dev/ram rw ramdisk_size=28472 hda=bswap hdb=bswap hdc=bswap hdd=bswap root=101 Uncompressing Linux...done. Now booting the kernel
(Hangs here)
---------------------------------------------------------------------------- ----------------
Another example which does not use a kdi image but simply takes a mkimaged zipped vmlinux file as follows.
=> tftpboot 100000 uImage Trying FCC2 ETHERNET TFTP from server 192.168.1.1; our IP address is 192.168.1.2 Filename 'uImage'. Load address: 0x100000 Loading: ################################################################# ################# done Bytes transferred = 419502 (666ae hex) => bootm common/cmd_bootm.c before attempting to boot an image ## Booting image at 00100000 ... common/cmd_bootm.c Image header has correct magic number common/cmd_bootm.c Image header has correct checksum Image Name: Linux Kernel Image Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 419438 Bytes = 409.6 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK common/cmd_bootm.c Image data has correct checksum common/cmd_bootm.c Architecture check OK common/cmd_bootm.c Image Type check OK Uncompressing Kernel Image ... OK common/cmd_bootm.c Uncompression OK common/cmd_bootm.c Image Type check OK ## Current stack ends at 0x03F6CBD8 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF10 bd address = 0x03F6CFB4 memstart = 0x00000000 memsize = 0x04000000 flashstart = 0xFE000000 flashsize = 0x7FCFFFF7 flashoffset = 0x0002E000 sramstart = 0x00000000 sramsize = 0x00000000 immr_base = 0xFA200000 bootflags = 0x00000001 vco = 266.666 MHz sccfreq = 66.666 MHz brgfreq = 66.666 MHz intfreq = 199.999 MHz cpmfreq = 133.333 MHz busfreq = 66.666 MHz ethaddr = 00:00:00:10:18:82 IP addr = 192.168.1.2 baudrate = 115200 bps common/cmd_bootm.c No initial ramdisk, no multifile, continue. No initrd ## Transferring control to Linux (at address 00000000) ... common/cmd_bootm.c All preparation done, transferring control to OS (hangs here)
Any ideas anyone? You help is much appreciated.
Regards,
James Bates
PS: Apologies for this signature at the bottom of my posts, it is attached by my employer out of my control.
This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error please return the message immediately to the sender and delete the message from your systems. Thank you.
Hi James,
I have tried both settings of clocks_in_mhz and have made sure that I copied u-boot.h from uboot to ppcboot.h in Linux. I have made sure that IMAP_ADDR is correct but I still get the same thing, just hangs after uncompression. I am totally stumped.
Are you really sure, the board hangs? Maybe the kernel runs but has no console to output its messages. Try appending "console=<whatever>" to bootargs.
Cheers Detlev
Dear James,
in message OJEPIMKHOKJAJIDJLJBNMEBMCAAA.jbates@paradise.co.uk you wrote:
I have now managed to get the image to be read in and kernel image uncompressed etc. I am getting the problem where it hangs after Uncompression though. My previous issue with Bad Magic Number errors was due to the compilation of the mkimage tool. It was producing images with the wrong endianness in the header. Not sure if this may still be my problem tho
Can you please explain how you managed to do that? Is there a chance that your toolchain is seriously broken (I think this is the most likely explanation).
I have tried both settings of clocks_in_mhz and have made sure that I copied
This sentence means that you probably tried thewrong thing. There are no two settings of clocks_in_mhz. Either the variable is set (no matter which value it has), or it is not set.
See also
u-boot.h from uboot to ppcboot.h in Linux. I have made sure that IMAP_ADDR is correct but I still get the same thing, just hangs after uncompression. I am totally stumped.
Then there is only one way: attach your BDI2000, and check what's going on.
My board is an adaptation of the MPC8260ADS. I am using BlueCat 4.0 and u-boot 4.8 (tried 4.0 and 4.7) etc and have tried booting both the uImage and kdi files (after turning them into u-boot images with mkimgage).
There is no such version of U-Boot as 4.x. We are still at 0.4.x.
Please note that U-Boot supports both LynxOS and BlueCat linux KDIs directly.
...
## Current stack ends at 0x03F6CBD8 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF10 bd address = 0x03F6CFB4 memstart = 0x00000000 memsize = 0x04000000 flashstart = 0xFE000000 flashsize = 0x7FCFFFF7
Your flashsize is seriously broken.
baudrate = 115200 bps
Are you sure your image will initialize the console for 115200 bps? I don't see you passing something like "console=ttyS0,115200" as boot argument.
Try:
- booting at a standard baudrate like 9600 bps - passing correct boot arguments - booting, and then test if the image is actually running even if you see no console output (try pinging it over the network, or telnet or whatever your image allows)
PS: Apologies for this signature at the bottom of my posts, it is attached by my employer out of my control.
You still have a couple of options: Change the mail service. Change the employer. etc.
Best regards,
Wolfgang Denk
James Bates writes:
James> Hi All,
James> I have now managed to get the image to be read in and kernel James> image uncompressed etc. I am getting the problem where it James> hangs after Uncompression though. My previous issue with Bad James> Magic Number errors was due to the compilation of the mkimage James> tool. It was producing images with the wrong endianness in James> the header. Not sure if this may still be my problem tho :)
James> I have tried both settings of clocks_in_mhz and have made James> sure that I copied u-boot.h from uboot to ppcboot.h in James> Linux. I have made sure that IMAP_ADDR is correct but I still James> get the same thing, just hangs after uncompression. I am James> totally stumped.
James> My board is an adaptation of the MPC8260ADS. I am using James> BlueCat 4.0 and u-boot 4.8 (tried 4.0 and 4.7) etc and have James> tried booting both the uImage and kdi files (after turning James> them into u-boot images with mkimgage).
James> Here is a print out with extra debug info when trying a kdi James> image called Q319.img:
[...kdi staff deleted...]
James> Another example which does not use a kdi image but simply James> takes a mkimaged zipped vmlinux file as follows.
You don't show the mkimage command but if you use gzipped vmlinux (i.e. ELF format) file it's exactly the problem. You have to convert ELF to raw binary using something like
powerpc-linux-objcopy -O binary vmlinux vmlinux.bin
Then you gzip vmlinux.bin and use it as input to mkimage, just as it's explained in the README.
[...Debug print deleted...]
James> Any ideas anyone? You help is much appreciated.
BTW, note that flash size looks incorrect. Also make sure that 66MHz is 66.666 as it appears in your log and not 66.000. It's not connected to the boot problem but may cause different problems.
Hi James,
Another thing you can do is go to u-boot/common/cmd_bootm.c in the function do_bootm_linux(..), at the end of it :
(*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);
change it to
(*kernel) (gd->bd, initrd_start, initrd_end, cmd_start, cmd_end); // kbd change to gd->bd
It should works.
I hope this help.
Tien
----- Original Message ----- From: "Yuli Barcohen" yuli@arabellasw.com To: "James Bates" jbates@paradise.co.uk Cc: u-boot-users@lists.sourceforge.net Sent: Wednesday, September 10, 2003 2:19 PM Subject: Re:[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
James Bates writes:
James> Hi All, James> I have now managed to get the image to be read in and kernel James> image uncompressed etc. I am getting the problem where it James> hangs after Uncompression though. My previous issue with Bad James> Magic Number errors was due to the compilation of the mkimage James> tool. It was producing images with the wrong endianness in James> the header. Not sure if this may still be my problem tho :) James> I have tried both settings of clocks_in_mhz and have made James> sure that I copied u-boot.h from uboot to ppcboot.h in James> Linux. I have made sure that IMAP_ADDR is correct but I still James> get the same thing, just hangs after uncompression. I am James> totally stumped. James> My board is an adaptation of the MPC8260ADS. I am using James> BlueCat 4.0 and u-boot 4.8 (tried 4.0 and 4.7) etc and have James> tried booting both the uImage and kdi files (after turning James> them into u-boot images with mkimgage). James> Here is a print out with extra debug info when trying a kdi James> image called Q319.img:[...kdi staff deleted...]
James> Another example which does not use a kdi image but simply James> takes a mkimaged zipped vmlinux file as follows.You don't show the mkimage command but if you use gzipped vmlinux (i.e. ELF format) file it's exactly the problem. You have to convert ELF to raw binary using something like
powerpc-linux-objcopy -O binary vmlinux vmlinux.binThen you gzip vmlinux.bin and use it as input to mkimage, just as it's explained in the README.
[...Debug print deleted...]
James> Any ideas anyone? You help is much appreciated.BTW, note that flash size looks incorrect. Also make sure that 66MHz is 66.666 as it appears in your log and not 66.000. It's not connected to the boot problem but may cause different problems.
--
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader yuli@arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel ========================================================================
This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 001301c3786a$369162b0$321c10ac@asradproto50 Tien wrote:
Another thing you can do is go to u-boot/common/cmd_bootm.c in the function do_bootm_linux(..), at the end of it :
(*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);change it to
(*kernel) (gd->bd, initrd_start, initrd_end, cmd_start, cmd_end); //kbd change to gd->bd
Do NOT do this.
It should works.
No, it is BROKEN. "gd" and "gd->bd" will go out of scope when Linux is booting. The contents of this memory will be undefined. You create ndefined behaviour. What do you think why we create a copy of this date (in "kbd") in the first place?
Best regards,
Wolfgang Denk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Another good idea is to look at the log_buf in memory. # grep log_buf System.map
in your JTAG debugger, start dumping from this address. You should see everything you ecpect to see on the console.
Thanks Brian On Wednesday 10 September 2003 11:35 am, James Bates wrote:
Hi All,
I have now managed to get the image to be read in and kernel image uncompressed etc. I am getting the problem where it hangs after Uncompression though. My previous issue with Bad Magic Number errors was due to the compilation of the mkimage tool. It was producing images with the wrong endianness in the header. Not sure if this may still be my problem tho
:)
I have tried both settings of clocks_in_mhz and have made sure that I copied u-boot.h from uboot to ppcboot.h in Linux. I have made sure that IMAP_ADDR is correct but I still get the same thing, just hangs after uncompression. I am totally stumped.
My board is an adaptation of the MPC8260ADS. I am using BlueCat 4.0 and u-boot 4.8 (tried 4.0 and 4.7) etc and have tried booting both the uImage and kdi files (after turning them into u-boot images with mkimgage).
Here is a print out with extra debug info when trying a kdi image called Q319.img:
=> tftpboot 100000 Q319.img Trying FCC2 ETHERNET TFTP from server 192.168.1.1; our IP address is 192.168.1.2 Filename 'Q319.img'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################################################# done Bytes transferred = 3637824 (378240 hex) => bootm common/cmd_bootm.c before attempting to boot an image ## Booting image at 00100000 ... common/cmd_bootm.c Image header has correct magic number common/cmd_bootm.c Image header has correct checksum Image Name: Linux Kernel Image Image Type: PowerPC LynxOS Kernel Image (uncompressed) Data Size: 3637760 Bytes = 3.5 MB Load Address: 00500000 Entry Point: 00507000 Verifying Checksum ... OK common/cmd_bootm.c Image data has correct checksum common/cmd_bootm.c Architecture check OK common/cmd_bootm.c Image Type check OK OK common/cmd_bootm.c Uncompression OK common/cmd_bootm.c Image Type check OK Booting Bluecat KDI ... loaded at: 00507000 005121DC zimage at: 0050D000 0057366C initrd at: 00575000 00878200 relocated to: 00576000 00879200 avail ram: 0087A000 04000000
Linux/PPC load: root=/dev/ram root=/dev/ram rw ramdisk_size=28472 hda=bswap hdb=bswap hdc=bswap hdd=bswap root=101 Uncompressing Linux...done. Now booting the kernel
(Hangs here)
Another example which does not use a kdi image but simply takes a mkimaged zipped vmlinux file as follows.
=> tftpboot 100000 uImage Trying FCC2 ETHERNET TFTP from server 192.168.1.1; our IP address is 192.168.1.2 Filename 'uImage'. Load address: 0x100000 Loading: ################################################################# ################# done Bytes transferred = 419502 (666ae hex) => bootm common/cmd_bootm.c before attempting to boot an image ## Booting image at 00100000 ... common/cmd_bootm.c Image header has correct magic number common/cmd_bootm.c Image header has correct checksum Image Name: Linux Kernel Image Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 419438 Bytes = 409.6 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK common/cmd_bootm.c Image data has correct checksum common/cmd_bootm.c Architecture check OK common/cmd_bootm.c Image Type check OK Uncompressing Kernel Image ... OK common/cmd_bootm.c Uncompression OK common/cmd_bootm.c Image Type check OK ## Current stack ends at 0x03F6CBD8 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF10 bd address = 0x03F6CFB4 memstart = 0x00000000 memsize = 0x04000000 flashstart = 0xFE000000 flashsize = 0x7FCFFFF7 flashoffset = 0x0002E000 sramstart = 0x00000000 sramsize = 0x00000000 immr_base = 0xFA200000 bootflags = 0x00000001 vco = 266.666 MHz sccfreq = 66.666 MHz brgfreq = 66.666 MHz intfreq = 199.999 MHz cpmfreq = 133.333 MHz busfreq = 66.666 MHz ethaddr = 00:00:00:10:18:82 IP addr = 192.168.1.2 baudrate = 115200 bps common/cmd_bootm.c No initial ramdisk, no multifile, continue. No initrd ## Transferring control to Linux (at address 00000000) ... common/cmd_bootm.c All preparation done, transferring control to OS (hangs here)
Any ideas anyone? You help is much appreciated.
Regards,
James Bates
PS: Apologies for this signature at the bottom of my posts, it is attached by my employer out of my control.
This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error please return the message immediately to the sender and delete the message from your systems. Thank you.
This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 200309101654.25917.waite@skycomputers.com you wrote:
Another good idea is to look at the log_buf in memory. # grep log_buf System.map
in your JTAG debugger, start dumping from this address. You should see everything you ecpect to see on the console.
You can also do a post-mortem dump in U-Boot after the reset.
Best regards,
Wolfgang Denk
participants (6)
-
Brian Waite -
Detlev Zundel -
James Bates -
tn -
Wolfgang Denk -
Yuli Barcohen