[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[James Bates]

Thanks everyone,


Loads of issues were pointed out there for me to solve (Thanks) but the main
one was to do with my console baud rate after all. When I changed my
terminal emulator to 9600 linux was there up and running all along. The
problem was that U-boot was configured to run at 115200 and linux at 9600.
The problem I have now is changing my u-boot baud rate to 9600 (which is
what the powers that be have decided). I tried changing CONFIG_BAUDRATE to
9600 but it has no effect, it just stays at 115200. Any ideas?

Thanks again,

James Bates

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.

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Wolfgang Denk]

In message <OJEPIMKHOKJAJIDJLJBNEEBPCAAA.jbates@paradise.co.uk> you wrote:
> 
> what the powers that be have decided). I tried changing CONFIG_BAUDRATE to
> 9600 but it has no effect, it just stays at 115200. Any ideas?

Did you try the obvious way:

	=> setenv baudrate 9600
	...
	=> saveenv

?

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
It is better to marry than to burn.
                                - Bible ``I Corinthians'' ch. 7, v. 9

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Detlev Zundel]

Hi James,

> Loads of issues were pointed out there for me to solve (Thanks) but the main
> one was to do with my console baud rate after all. When I changed my
> terminal emulator to 9600 linux was there up and running all along. The
> problem was that U-boot was configured to run at 115200 and linux at 9600.
> The problem I have now is changing my u-boot baud rate to 9600 (which is
> what the powers that be have decided). I tried changing CONFIG_BAUDRATE to
> 9600 but it has no effect, it just stays at 115200. Any ideas?

I can't think of a proper reason why changing CONFIG_BAUDRATE and a
make (after make clean) shouldn't help, but you can surely do the
following (in u-boot):

setenv baudrate 9600
[adjust terminal emulator and press enter]
saveenv

Cheers
  Detlev

-- 
In the topologic hell the beer is packed in Klein's bottles.

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Wolfgang Denk]

In message <871xunhyyo.fsf@deepthought.outer.space.org> you wrote:
> 
> > The problem I have now is changing my u-boot baud rate to 9600 (which is
> > what the powers that be have decided). I tried changing CONFIG_BAUDRATE to
> > 9600 but it has no effect, it just stays at 115200. Any ideas?
> 
> I can't think of a proper reason why changing CONFIG_BAUDRATE and a
> make (after make clean) shouldn't help, but you can surely do the
> following (in u-boot):

Well, a possible reason is that the environment is not embedded  with
the  U-Boot  image  (i.  e.  stored in a separate flash sector, on in
EEPROM or NVRAM etc.), so installing a  new  U-Boot  image  will  not
automatically overwrite the environment.

> setenv baudrate 9600
> [adjust terminal emulator and press enter]
> saveenv

Right. This should always work.

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
A committee is a life form with six or more legs and no brain.
                              -- Lazarus Long, "Time Enough For Love"

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Rune Torgersen]

> changing CONFIG_BAUDRATE to 9600 but it has no effect, it 
> just stays at 115200. Any ideas?

Note that that CONFIG parameter is ONLY used if there is no baudrate settin
on the environment in flash.
Change the environment variable, and it should work. (Same thing with
CONFIG_CLOCK_IN_MHZ....)

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Scott McNutt]

> 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.

If you're really using a Lynx KDI, this is not necessary. The KDI
should be self-contained.

> I have made sure that IMAP_ADDR is correct but I still get the same
> thing, just hangs after uncompression. I am totally stumped.

This is really, really, important ... double check this. The default Bluecat
hardcodes the IMMR ... it doesn't look for the u-boot parameters ... it just
creates its own bd info struct. So if u-boot and Bluecat are not in sync,
the behavior you describe is just what I would expect.

> vco         = 266.666 MHz
> sccfreq     = 66.666 MHz
> brgfreq     = 66.666 MHz
> intfreq     = 199.999 MHz
> cpmfreq     = 133.333 MHz
> busfreq     = 66.666 MHz
> baudrate    = 115200 bps

This is another area to check. The default Bluecat BSP for VADS has
many of these hardcoded. Although u-boot is smart in this area, Bluecat
is (unfortunately) is not. The Bluecat code may not be setting up the
uart BRG incorrectly -- check any code you borrowed from the VADS
BSP.

Regards,
--Scott

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[James Bates]

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.

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Detlev Zundel]

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

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Wolfgang Denk]

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_

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Yuli Barcohen]

>>>>> 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
========================================================================

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[tn]

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

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Wolfgang Denk]

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.

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Brian Waite]

-----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-----

[U-Boot-Users] Uncompressing kernel ..... OK (Hangs here)

[Wolfgang Denk]

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_