public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Trouble "booting using board info"
Date: Thu, 25 Jun 2009 18:11:26 +0200	[thread overview]
Message-ID: <m21vp89tu9.fsf@ohwell.denx.de> (raw)
In-Reply-To: <4A439BC6.8070404@shoppertrak.com> (Mikhail Zaturenskiy's message of "Thu, 25 Jun 2009 10:46:14 -0500")

Hi Mikhail,

> You're right, I turned on CONFIG_OF_LIBFDT in include/configs/EP88x.h.

Wow, you _are_ quick ;)

> Here's where I'm at now:
>
> U-Boot 2009.03-svn8591 (Jun 25 2009 - 10:18:12)
>
> CPU:   MPC885ZPnn at 100 MHz [40.0...133.0 MHz]
>        8 kB I-Cache 8 kB D-Cache FEC present
> Board: EP88xC 1.1  CPLD revision 2
> DRAM:  64 MB
> FLASH: 32 MB
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC ETHERNET, FEC2 ETHERNET
> Hit any key to stop autoboot:  0
> Wrong Image Format for bootm command
> ERROR: can't get kernel image!
> => setenv ipaddr 10.0.54.150
> => setenv serverip 10.0.54.129
> => setenv bootargs root=/dev/ram0 rw
> => setenv ethaddr 00-e0-86-0c-84-fd
> => tftp 400000 ep88x_uimage2
> Using FEC ETHERNET device
> TFTP from server 10.0.54.129; our IP address is 10.0.54.150
> Filename 'ep88x_uimage2'.
> Load address: 0x400000
> Loading: #################################################################
>          ########
> done
> Bytes transferred = 1061544 (1032a8 hex)
> => tftp 550000 ep88x_ramdisk3
> Using FEC ETHERNET device
> TFTP from server 10.0.54.129; our IP address is 10.0.54.150
> Filename 'ep88x_ramdisk3'.
> Load address: 0x550000
> Loading: #################################################################
>          #############################################################
> done
> Bytes transferred = 1846099 (1c2b53 hex)
> => tftp 750000 ep88x_dtb
> Using FEC ETHERNET device
> TFTP from server 10.0.54.129; our IP address is 10.0.54.150
> Filename 'ep88x_dtb'.
> Load address: 0x750000
> Loading: #
> done
> Bytes transferred = 12288 (3000 hex)
> => bootm 400000 550000 750000
> ## Booting kernel from Legacy Image at 00400000 ...
>    Image Name:   Linux-2.6.30-rc2-01402-gd4e2f68-
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    1061480 Bytes =  1 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 00550000 ...
>    Image Name:   Simple Embedded Linux Framework
>    Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
>    Data Size:    1846035 Bytes =  1.8 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
> ## Flattened Device Tree blob at 00750000
>    Booting using the fdt blob at 0x750000
>    Uncompressing Kernel Image ... OK
>    Loading Ramdisk to 03daa000, end 03f6cb13 ... OK
>
> Now the usual hang, any more suggestions for what to do next?

If you are in the good position to own a JTAG debugger, now would be the
time to place it next to your board :)

If not, then try at least to be sure that "linux,stdout-path" is
sensible in your dts (compare to others).  Another option is to try the
postmortem debugging of the logbuffer described in our docs[1].

As I do not have much 8xx 2.6 exposure I don't know if this is supported
here, but you may try:

arch/powerpc/Kconfig.debug:128
 "Kernel hacking"
config PPC_EARLY_DEBUG
        bool "Early debugging (dangerous)"
        # PPC_EARLY_DEBUG on 440 leaves AS=1 mappings above the TLB high water
        # mark, which doesn't work with current 440 KVM.
        depends on !KVM
        help
          Say Y to enable some early debugging facilities that may be available
          for your processor/board combination. Those facilities are hacks
          intended to debug problems early during boot, this should not be
          enabled in a production kernel.
          Note that enabling this will also cause the kernel default log level
          to be pushed to max automatically very early during boot

If this all fails and as you are way past U-Boot, change the mailing
list to linuxppc-dev :)

Cheers
  Detlev

[1] http://www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis

-- 
You are God.  Remember?
      -- Timothy Leary
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

  reply	other threads:[~2009-06-25 16:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-24 17:23 [U-Boot] Trouble "booting using board info" Mikhail Zaturenskiy
2009-06-25 11:40 ` Detlev Zundel
2009-06-25 15:46   ` Mikhail Zaturenskiy
2009-06-25 16:11     ` Detlev Zundel [this message]
2009-06-25 17:00       ` Mikhail Zaturenskiy
2009-06-26 11:58         ` Detlev Zundel
2009-06-26 13:59           ` Mikhail Zaturenskiy
2009-06-29 18:37             ` Mikhail Zaturenskiy
2009-06-29 19:03               ` Jerry Van Baren
2009-06-29 20:19                 ` Mikhail Zaturenskiy
2009-06-30 18:30                   ` Mikhail Zaturenskiy
2009-06-30 18:38                     ` Mikhail Zaturenskiy
2009-06-30 18:51                       ` Jerry Van Baren
     [not found] ` <4A42FBC2.8050406@tataelxsi.co.in>
2009-06-25 14:23   ` [U-Boot] "Bad Data CRC" after ramdisk size increase Mikhail Zaturenskiy
2009-06-25 14:36     ` Detlev Zundel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m21vp89tu9.fsf@ohwell.denx.de \
    --to=dzu@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox