* [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
2003-09-10 15:35 ` [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here) James Bates
@ 2003-09-10 18:12 ` Detlev Zundel
2003-09-10 18:18 ` Wolfgang Denk
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Detlev Zundel @ 2003-09-10 18:12 UTC (permalink / raw)
To: u-boot
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
--
Once the implementation is up and running, it is still a trick to keep it
running. In a normal, closed implementation, this is not a problem; in a
system with metaobject protocols [..] there is the potential for spectacular
failure modes if certain situations are not properly anticipated.
-- The Art of the Metaobject Protocol
^ permalink raw reply [flat|nested] 9+ messages in thread* [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
2003-09-10 15:35 ` [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here) James Bates
2003-09-10 18:12 ` Detlev Zundel
@ 2003-09-10 18:18 ` Wolfgang Denk
2003-09-10 18:19 ` Yuli Barcohen
2003-09-10 20:54 ` [U-Boot-Users] " Brian Waite
3 siblings, 0 replies; 9+ messages in thread
From: Wolfgang Denk @ 2003-09-10 18:18 UTC (permalink / raw)
To: u-boot
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
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Gods don't like people not doing much work. People who aren't busy
all the time might start to _think_. - Terry Pratchett, _Small Gods_
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
2003-09-10 15:35 ` [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here) James Bates
2003-09-10 18:12 ` Detlev Zundel
2003-09-10 18:18 ` Wolfgang Denk
@ 2003-09-10 18:19 ` Yuli Barcohen
2003-09-11 13:40 ` tn
2003-09-10 20:54 ` [U-Boot-Users] " Brian Waite
3 siblings, 1 reply; 9+ messages in thread
From: Yuli Barcohen @ 2003-09-10 18:19 UTC (permalink / raw)
To: u-boot
>>>>> 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.
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli at arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
^ permalink raw reply [flat|nested] 9+ messages in thread* [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
2003-09-10 18:19 ` Yuli Barcohen
@ 2003-09-11 13:40 ` tn
2003-09-11 19:50 ` Wolfgang Denk
[not found] ` <44364.8242312067$1079416667@news.gmane.org>
0 siblings, 2 replies; 9+ messages in thread
From: tn @ 2003-09-11 13:40 UTC (permalink / raw)
To: u-boot
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.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.
>
> --
> ========================================================================
> Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
> yuli at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
^ permalink raw reply [flat|nested] 9+ messages in thread* [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
2003-09-11 13:40 ` tn
@ 2003-09-11 19:50 ` Wolfgang Denk
[not found] ` <44364.8242312067$1079416667@news.gmane.org>
1 sibling, 0 replies; 9+ messages in thread
From: Wolfgang Denk @ 2003-09-11 19:50 UTC (permalink / raw)
To: u-boot
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
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Writing a book is like washing an elephant: there's no good place to
begin or end, and it's hard to keep track of what you've already
covered.
^ permalink raw reply [flat|nested] 9+ messages in thread[parent not found: <44364.8242312067$1079416667@news.gmane.org>]
* [U-Boot] Uncompressing kernel ..... OK (Hangs here)
[not found] ` <44364.8242312067$1079416667@news.gmane.org>
@ 2011-06-16 12:14 ` Smitha
0 siblings, 0 replies; 9+ messages in thread
From: Smitha @ 2011-06-16 12:14 UTC (permalink / raw)
To: u-boot
Wolfgang Denk <wd <at> denx.de> writes:
>
> In message <001301c3786a$369162b0$321c10ac <at> 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
>
Hi ,
I am tryng to bring up the WRlinux kernel on a custom board based on mpc
8247 . When I boot my image using bootm command it hangs at (*kernel) (kbd,
initrd_start, initrd_end, cmd_start, cmd_end); in do_bootm_linux ( function..
please can you help
Regards,
Smitha
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
2003-09-10 15:35 ` [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here) James Bates
` (2 preceding siblings ...)
2003-09-10 18:19 ` Yuli Barcohen
@ 2003-09-10 20:54 ` Brian Waite
2003-09-10 21:20 ` Wolfgang Denk
3 siblings, 1 reply; 9+ messages in thread
From: Brian Waite @ 2003-09-10 20:54 UTC (permalink / raw)
To: u-boot
-----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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/X4+BmxLCz0u+Ko8RAgVQAKCW8ncg5xLYduxyozZFgfFMciUWGACdHbZP
ZRgfJkiZJOg5mLPNQY9/kDQ=
=CJB9
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 9+ messages in thread* [U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)
2003-09-10 20:54 ` [U-Boot-Users] " Brian Waite
@ 2003-09-10 21:20 ` Wolfgang Denk
0 siblings, 0 replies; 9+ messages in thread
From: Wolfgang Denk @ 2003-09-10 21:20 UTC (permalink / raw)
To: u-boot
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
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
You might not be as stupid as you look. This is not hard. Let's think
about this. I mean ... I'll think about this, and you can join in
when you know the words. - Terry Pratchett, _Men at Arms_
^ permalink raw reply [flat|nested] 9+ messages in thread