[U-Boot] U-boot -printk kernel crash dump using md on PDK

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi All,

I am using mx31 pdk and uImage generated by LTIB.
Basically, my problem is my kernel gets stuck after printing the
"Done...Booting the kernel". Please the responses below.

Upon inspecting the printk log by doing a memory dump of the _buf_log
symbol in System.map(i translated it to the physical address before
dumping it ). It seems before the console got initialized, the bootup
was successful to a certain extent, but i am unable to interpret
anything conclusive from the logs. ANy hints as to what might be
happening? I am guessing that unexpected RAM regions are getting
overwritten after uncompression  happens or the sdram hasn't been
initialized fully by U-boot.

I have attached the printk circular buffer log.

smc911x: initializing
smc911x: detected <NULL> controller
smc911x: phy initialized
smc911x: MAC 92:92:92:bb:bb:bb
TFTP from server 206.44.18.25; our IP address is 206.44.18.31
Filename 'zImage_spin2_23march'.
Load address: 0x81000000
Loading: * #################################################################
       #################################################
done
Bytes transferred = 1665000 (1967e8 hex)
=> go 0x81000000
## Starting application at 0x81000000 ...
Uncompressing Linux.............................................................
............................................... done, booting the kernel.

PRINTK log
==========
 md 80350f68 500\b\b0 \b\b50\b
80350f68: 4c3e353c 78756e69 72657620 6e6f6973    <5>Linux version
80350f78: 362e3220 2d34322e 2d303431 65383667     2.6.24-140-g68e
80350f88: 34623462 79742820 406f7561 656c7954    b4b4 (tyauo at Tyle
80350f98: 4c575372 694c6261 3278756e 2e4d412e    rSWLabLinux2.AM.
80350fa8: 50524f43 4952502e 28202956 20636367    CORP.PRIV) (gcc
80350fb8: 73726576 206e6f69 2e312e34 23202932    version 4.1.2) #
80350fc8: 52502033 504d4545 68542054 70412075    3 PREEMPT Thu Ap
80350fd8: 33322072 3a353120 323a3131 44432039    r 23 15:11:29 CD
80350fe8: 30322054 3c0a3930 50433e34 41203a55    T 2009.<4>CPU: A
80350ff8: 36764d52 6d6f632d 69746170 20656c62    RMv6-compatible
80351008: 636f7270 6f737365 345b2072 62373031    processor [4107b
80351018: 5d343633 76657220 6f697369 2034206e    364] revision 4
80351028: 4d524128 45543676 202c294a 303d7263    (ARMv6TEJ), cr=0
80351038: 33356530 0a663738 4d3e343c 69686361    0e5387f.<4>Machi
80351048: 203a656e 65657246 6c616373 584d2065    ne: Freescale MX
80351058: 4d2f3133 20323358 74532d33 206b6361    31/MX32 3-Stack
80351068: 72616f42 343c0a64 6d654d3e 2079726f    Board.<4>Memory
80351078: 696c6f70 203a7963 20434345 61736964    policy: ECC disa
80351088: 64656c62 6144202c 63206174 65686361    bled, Data cache
80351098: 69727720 61626574 3c0a6b63 6e4f3e37     writeback.<7>On
803510a8: 646f6e20 20302065 61746f74 6761706c     node 0 totalpag
803510b8: 203a7365 36373233 373c0a38 4420203e    es: 32768.<7>  D
803510c8: 7a20414d 3a656e6f 20383420 65676170    MA zone: 48 page
803510d8: 73752073 66206465 6d20726f 616d6d65    s used for memma
803510e8: 373c0a70 4420203e 7a20414d 3a656e6f    p.<7>  DMA zone:
803510f8: 70203020 73656761 73657220 65767265     0 pages reserve
80351108: 373c0a64 4420203e 7a20414d 3a656e6f    d.<7>  DMA zone:
80351118: 39303620 61702036 2c736567 46494c20     6096 pages, LIF
80351128: 6162204f 3a686374 373c0a30 4e20203e    O batch:0.<7>  N
80351138: 616d726f 6f7a206c 203a656e 20383032    ormal zone: 208
80351148: 65676170 73752073 66206465 6d20726f    pages used for m
80351158: 616d6d65 373c0a70 4e20203e 616d726f    emmap.<7>  Norma
80351168: 6f7a206c 203a656e 31343632 61702036    l zone: 26416 pa
80351178: 2c736567 46494c20 6162204f 3a686374    ges, LIFO batch:
80351188: 373c0a37 4d20203e 6261766f 7a20656c    7.<7>  Movable z
80351198: 3a656e6f 70203020 73656761 65737520    one: 0 pages use
803511a8: 6f662064 656d2072 70616d6d 3e343c0a    d for memmap.<4>
803511b8: 30555043 2044203a 54504956 69727720    CPU0: D VIPT wri
803511c8: 622d6574 206b6361 68636163 343c0a65    te-back cache.<4
803511d8: 5550433e 49203a30 63616320 203a6568    >CPU0: I cache:
803511e8: 38333631 79622034 2c736574 73736120    16384 bytes, ass
803511f8: 6169636f 69766974 34207974 3233202c    ociativity 4, 32
80351208: 74796220 696c2065 2c73656e 38323120     byte lines, 128
80351218: 74657320 343c0a73 5550433e 44203a30     sets.<4>CPU0: D
80351228: 63616320 203a6568 38333631 79622034     cache: 16384 by
80351238: 2c736574 73736120 6169636f 69766974    tes, associativi
80351248: 34207974 3233202c 74796220 696c2065    ty 4, 32 byte li
80351258: 2c73656e 38323120 74657320 343c0a73    nes, 128 sets.<4
80351268: 6975423e 3120746c 6e6f7a20 73696c65    >Built 1 zonelis
80351278: 69207374 6f5a206e 6f20656e 72656472    ts in Zone order
80351288: 6f6d202c 696c6962 67207974 70756f72    , mobility group
80351298: 20676e69 202e6e6f 746f5420 70206c61    ing on.  Total p
803512a8: 73656761 3233203a 0a323135 4b3e353c    ages: 32512.<5>K
803512b8: 656e7265 6f63206c 6e616d6d 696c2064    ernel command li
803512c8: 203a656e 6e696f6e 64727469 6e6f6320    ne: noinitrd con
803512d8: 656c6f73 7974743d 3063786d 3531312c    sole=ttymxc0,115
803512e8: 20303032 74696e69 696c2f3d 7278756e    200 init=/linuxr
803512f8: 6f722063 2f3d746f 2f766564 2073666e    c root=/dev/nfs
80351308: 7273666e 3d746f6f 2e363032 312e3434    nfsroot=206.44.1
80351318: 35322e38 66742f3a 6f627074 6c2f746f    8.25:/tftpboot/l
80351328: 2f626974 746f6f72 69207366 68643d70    tib/rootfs ip=dh
80351338: 3c0a7063 584d3e36 52492043 6e692051    cp.<6>MXC IRQ in
80351348: 61697469 657a696c 343c0a64 4449503e    itialized.<4>PID
80351358: 73616820 61742068 20656c62 72746e65     hash table entr
80351368: 3a736569 32313520 726f2820 3a726564    ies: 512 (order:
80351378: 202c3920 38343032 74796220 0a297365     9, 2048 bytes).
80351388: 4d3e363c 47204358 74205450 72656d69    <6>MXC GPT timer
80351398: 696e6920 6c616974 64657a69 6172202c     initialized, ra
803513a8: 3d206574 36363120 30303532 343c0a30    te = 16625000.<4
803513b8: 6e6f433e 656c6f73 6f63203a 72756f6c    >Console: colour
803513c8: 6d756420 6420796d 63697665 30382065     dummy device 80
803513d8: 0a303378 443e363c 72746e65 61632079    x30.<6>Dentry ca
803513e8: 20656863 68736168 62617420 6520656c    che hash table e
803513f8: 6972746e 203a7365 38333631 6f282034    ntries: 16384 (o
80351408: 72656472 2c34203a 35353620 62203633    rder: 4, 65536 b
80351418: 73657479 363c0a29 6f6e493e 632d6564    ytes).<6>Inode-c
80351428: 65686361 73616820 61742068 20656c62    ache hash table
80351438: 72746e65 3a736569 39313820 6f282032    entries: 8192 (o
80351448: 72656472 2c33203a 37323320 62203836    rder: 3, 32768 b
80351458: 73657479 363c0a29 6d654d3e 3a79726f    ytes).<6>Memory:
80351468: 38323120 3d20424d 38323120 7420424d     128MB = 128MB t
80351478: 6c61746f 3e353c0a 6f6d654d 203a7972    otal.<5>Memory:
80351488: 34363231 424b3631 61766120 62616c69    126416KB availab
80351498: 2820656c 30303133 6f63204b 202c6564    le (3100K code,
803514a8: 4b303832 74616420 31202c61 204b3830    280K data, 108K
803514b8: 74696e69 373c0a29 6c61433e 61726269    init).<7>Calibra
803514c8: 676e6974 6c656420 6c207961 2e706f6f    ting delay loop.
803514d8: 35202e2e 382e3033 6f422034 494d6f67    .. 530.84 BogoMI
803514e8: 28205350 3d6a706c 34353632 29383032    PS (lpj=2654208)
803514f8: 3e343c0a 6e756f4d 61632d74 20656863    .<4>Mount-cache
80351508: 68736168 62617420 6520656c 6972746e    hash table entri
80351518: 203a7365 0a323135 433e363c 203a5550    es: 512.<6>CPU:
80351528: 74736554 20676e69 74697277 75622065    Testing write bu
80351538: 72656666 686f6320 6e657265 203a7963    ffer coherency:
80351548: 3c0a6b6f 656e3e36 616e5f74 7073656d    ok.<6>net_namesp
80351558: 3a656361 20343620 65747962 363c0a73    ace: 64 bytes.<6
80351568: 54454e3e 6552203a 74736967 64657265    >NET: Registered
80351578: 6f727020 6f636f74 6166206c 796c696d     protocol family
80351588: 0a363120 4c3e363c 20305832 68636163     16.<6>L2X0 cach
80351598: 6f632065 6f72746e 72656c6c 616e6520    e controller ena
803515a8: 64656c62 3e363c0a 20555043 69207369    bled.<6>CPU is i
803515b8: 33584d2e 65522031 69736976 32206e6f    .MX31 Revision 2
803515c8: 3c0a302e 6c433e36 206b636f 75706e69    .0.<6>Clock inpu
803515d8: 6f732074 65637275 20736920 30303632    t source is 2600
803515e8: 30303030 3e363c0a 2043584d 4f495047    0000.<6>MXC GPIO
803515f8: 72616820 72617764 363c0a65 6973553e     hardware.<6>Usi
80351608: 5320676e 20414d44 50412e49 363c0a49    ng SDMA I.API.<6
80351618: 43584d3e 414d4420 49504120 696e6920    >MXC DMA API ini
80351628: 6c616974 64657a69 3e373c0a 69676552    tialized.<7>Regi
80351638: 72657473 20676e69 20656874 20495053    stering the SPI
80351648: 746e6f43 6c6c6f72 44207265 65766972    Controller Drive
80351658: 373c0a72 63786d3e 6970735f 63786d20    r.<7>mxc_spi mxc
80351668: 6970735f 203a302e 5f495053 20564552    _spi.0: SPI_REV
80351678: 0a342e30 633e363c 69666e6f 4c435f67    0.4.<6>config_CL
80351688: 635f4949 6b636f6c 7465533a 676e6974    II_clock:Setting
80351698: 20707520 49494c43 6f6c6320 0a2e6b63     up CLII clock..
803516a8: 633e363c 69666e6f 4c435f67 635f4949    <6>config_CLII_c
803516b8: 6b636f6c 7465533a 676e6974 20707520    lock:Setting up
803516c8: 5f43584d 5f4d5750 434d5750 78302852    MXC_PWM_PWMCR(0x
803516d8: 65326366 30303030 6f742029 30783020    fc2e0000) to 0x0
803516e8: 30326333 2e303030 3e363c0a 666e6f63    3c20000..<6>conf
803516f8: 435f6769 5f49494c 636f6c63 65533a6b    ig_CLII_clock:Se
80351708: 6e697474 70752067 43584d20 4d57505f    tting up MXC_PWM
80351718: 4d57505f 30285249 32636678 30303065    _PWMIR(0xfc2e000
80351728: 74202938 7830206f 30303030 30303030    8) to 0x00000000
80351738: 363c0a2e 6e6f633e 5f676966 49494c43    ..<6>config_CLII
80351748: 6f6c635f 533a6b63 69747465 7520676e    _clock:Setting u
80351758: 584d2070 57505f43 57505f4d 2852434d    p MXC_PWM_PWMCR(
80351768: 63667830 30306532 20296330 30206f74    0xfc2e000c) to 0
80351778: 30303078 31303030 3c0a2e30 6f633e36    x00000010..<6>co
80351788: 6769666e 494c435f 6c635f49 3a6b636f    nfig_CLII_clock:
80351798: 74746553 20676e69 4d207075 505f4358    Setting up MXC_P
803517a8: 505f4d57 52434d57 66783028 30653263    WM_PWMCR(0xfc2e0
803517b8: 29303130 206f7420 30307830 30303030    010) to 0x000000
803517c8: 0a2e3032 633e363c 69666e6f 4c435f67    20..<6>config_CL
803517d8: 635f4949 6b636f6c 7465533a 676e6974    II_clock:Setting
803517e8: 20707520 5f43584d 5f4d5750 434d5750     up MXC_PWM_PWMC
803517f8: 78302852 65326366 30303030 6f742029    R(0xfc2e0000) to
80351808: 30783020 30326333 2e313030 3e363c0a     0x03c20001..<6>
80351818: 666e6f63 435f6769 5f49494c 636f6c63    config_CLII_cloc
80351828: 65533a6b 6e697474 70752067 4d575020    k:Setting up PWM
80351838: 6170204f 65722064 74736967 0a2e7265    O pad register..
80351848: 6d3e373c 735f6378 6d206970 735f6378    <7>mxc_spi mxc_s
80351858: 302e6970 6572203a 74736967 64657265    pi.0: registered
80351868: 73616d20 20726574 31697073 3e373c0a     master spi1.<7>
80351878: 5f63786d 5f697073 75746573 6d203a70    mxc_spi_setup: m
80351888: 2065646f 38202c30 77706220 3035202c    ode 0, 8 bpw, 50
80351898: 30303030 7a682030 3e373c0a 5f63786d    00000 hz.<7>mxc_
803518a8: 20697073 5f63786d 2e697073 72203a30    spi mxc_spi.0: r
803518b8: 73696765 65726574 68632064 20646c69    egistered child
803518c8: 31697073 3c0a322e 786d3e37 70735f63    spi1.2.<7>mxc_sp
803518d8: 65735f69 3a707574 646f6d20 2c302065    i_setup: mode 0,
803518e8: 62203820 202c7770 30303035 68203030     8 bpw, 500000 h
803518f8: 373c0a7a 63786d3e 6970735f 63786d20    z.<7>mxc_spi mxc
80351908: 6970735f 203a302e 69676572 72657473    _spi.0: register
80351918: 63206465 646c6968 69707320 0a302e31    ed child spi1.0.
80351928: 433e363c 3a495053 63786d20 6970735f    <6>CSPI: mxc_spi
80351938: 7020302d 65626f72 373c0a64 63786d3e    -0 probed.<7>mxc
80351948: 6970735f 63786d20 6970735f 203a312e    _spi mxc_spi.1:
80351958: 5f495053 20564552 0a342e30 6d3e373c    SPI_REV 0.4.<7>m
80351968: 735f6378 6d206970 735f6378 312e6970    xc_spi mxc_spi.1
80351978: 6572203a 74736967 64657265 73616d20    : registered mas
80351988: 20726574 32697073 3e373c0a 5f63786d    ter spi2.<7>mxc_
80351998: 5f697073 75746573 6d203a70 2065646f    spi_setup: mode
803519a8: 38202c30 77706220 3034202c 30303030    0, 8 bpw, 400000
803519b8: 7a682030 3e373c0a 5f63786d 20697073    0 hz.<7>mxc_spi
803519c8: 5f63786d 2e697073 72203a31 73696765    mxc_spi.1: regis
803519d8: 65726574 68632064 20646c69 32697073    tered child spi2
803519e8: 3c0a322e 53433e36 203a4950 5f63786d    .2.<6>CSPI: mxc_
803519f8: 2d697073 72702031 6465626f 3e363c0a    spi-1 probed.<6>
80351a08: 2043584d 20433249 76697264 3c0a7265    MXC I2C driver.<
80351a18: 6c633e34 55203a6b 6c62616e 6f742065    4>clk: Unable to
80351a28: 74656720 71657220 74736575 63206465     get requested c
80351a38: 6b636f6c 6664203a 6c635f6d 373c0a6b    lock: dfm_clk.<7
80351a48: 63786d3e 6970735f 7465735f 203a7075    >mxc_spi_setup:
80351a58: 65646f6d 202c3620 62203233 202c7770    mode 6, 32 bpw,
80351a68: 30303034 20303030 3c0a7a68 636d3e36    4000000 hz.<6>mc
80351a78: 38373331 65522033 2e332076 69462035    13783 Rev 3.5 Fi
80351a88: 7265566e 64203420 63657465 0a646574    nVer 4 detected.
80351a98: 503e363c 2043494d 20435452 63637573    <6>PMIC RTC succ
80351aa8: 66737365 796c6c75 6f727020 0a646562    essfully probed.
80351ab8: 503e363c 2043494d 6867694c 75732074    <6>PMIC Light su
80351ac8: 73656363 6c756673 6c20796c 6564616f    ccessfully loade
80351ad8: 363c0a64 31434d3e 33383733 67657220    d.<6>MC13783 reg
80351ae8: 74616c75 7320726f 65636375 75667373    ulator successfu
80351af8: 20796c6c 626f7270 000a6465 00000000    lly probed......
80351b08: 00000000 00000000 00000000 00000000    ................
80351b18: 00000000 00000000 494d503e 6f502043    ........>PMIC Po
80351b28: 20726577 63637573 66737365 796c6c75    wer successfully
80351b38: 6f727020 0a646562 4e3e363c 203a5445     probed.<6>NET:
80351b48: 69676552 72657473 70206465 6f746f72    Registered proto
80351b58: 206c6f63 696d6166 3220796c 0000000a    col family 2....
80351b68: 00000000 00000000 00000000 00000000    ................
80351b78: 00000000 00000000 61682065 65622073    ........e has be
80351b88: 69206e65 6174736e 64656c6c 373c0a2e    en installed..<7
80351b98: 6977533e 65686374 6f742064 67696820    >Switched to hig
80351ba8: 65722068 756c6f73 6e6f6974 646f6d20    h resolution mod
80351bb8: 6e6f2065 55504320 3c0a3020 50493e36    e on CPU 0.<6>IP
80351bc8: 756f7220 63206574 65686361 73616820     route cache has
80351bd8: 61742068 20656c62 72746e65 3a736569    h table entries:
80351be8: 32303120 6f282034 72656472 2c30203a     1024 (order: 0,
80351bf8: 39303420 79622036 29736574 0000000a     4096 bytes)....
80351c08: 00000000 00000000 00000000 00000000    ................
80351c18: 00000000 00000000 6520656c 6972746e    ........le entri
80351c28: 203a7365 36393034 726f2820 3a726564    es: 4096 (order:
80351c38: 202c3320 36373233 79622038 29736574     3, 32768 bytes)
80351c48: 3e363c0a 20504354 646e6962 73616820    .<6>TCP bind has
80351c58: 61742068 20656c62 72746e65 3a736569    h table entries:
80351c68: 39303420 6f282036 72656472 2c32203a     4096 (order: 2,
80351c78: 33363120 62203438 73657479 363c0a29     16384 bytes).<6
80351c88: 5043543e 6148203a 74206873 656c6261    >TCP: Hash table
80351c98: 6f632073 6769666e 64657275 73652820    s configured (es
80351ca8: 6c626174 65687369 30342064 62203639    tablished 4096 b
80351cb8: 20646e69 36393034 363c0a29 5043543e    ind 4096).<6>TCP
80351cc8: 6e657220 6572206f 74736967 64657265     reno registered
80351cd8: 3e363c0a 2d776f4c 6576654c 4d50206c    .<6>Low-Level PM
80351ce8: 69724420 20726576 75646f6d 6c20656c     Driver module l
80351cf8: 6564616f 00000a64 696c633e 71726969    oaded...>cliiirq
80351d08: 6970203a 31313d6e 37373038 2c353632    : pin=118077265,
80351d18: 3d717269 672c3137 3d6f6970 6f702c37    irq=71,gpio=7,po
80351d28: 303d7472 6769732c 3d6f6e5f 00000a37    rt=0,sig_no=7...
80351d38: 00000000 00000000 00002043 00000000    ........C ......
80351d48: 00000000 00000000 00000000 00000000    ................
80351d58: 00000000 00000000 49494c43 43414d20    ........CLII MAC
80351d68: 6f6d3a3a 656c7564 74696e49 696c6169    ::moduleInitiali
80351d78: 6320657a 4d69696c 6f496361 6f6d654d    ze cliiMacIoMemo
80351d88: 203a7972 38637830 30343038 64203030    ry: 0xc8804000 d
80351d98: 0a656e6f 00000000 6e61686e 64656c64    one.....nhandled
80351da8: 75616620 203a746c 65747865 6c616e72     fault: external
80351db8: 6f626120 6f207472 6f6e206e 696c2d6e     abort on non-li
80351dc8: 6566656e 20686374 30783028 20293830    nefetch (0x008)
80351dd8: 30207461 38386378 30303430 00000a30    at 0xc8804000...
80351de8: 00000000 00000000 00000000 00000000    ................
80351df8: 00000000 00000000 5250205d 504d4545    ........] PREEMP
80351e08: 00000a54 00000000 00000000 00000000    T...............
80351e18: 00000000 00000000 433e343c 203a5550    ........<4>CPU:
80351e28: 20202030 746f4e20 69617420 6465746e    0    Not tainted
80351e38: 32282020 322e362e 34312d34 36672d30      (2.6.24-140-g6
80351e48: 34626538 23203462 000a2933 00000000    8eb4b4 #3)......
80351e58: 00000000 00000000 6c75646f 696e4965    ........oduleIni
80351e68: 6c616974 2b657a69 34377830 3178302f    tialize+0x74/0x1
80351e78: 000a3035 00000000 20736920 76207461    50...... is at v
80351e88: 6e697270 302b6b74 63373378 3478302f    printk+0x37c/0x4
80351e98: 000a3832 00000000 5b203a20 3030633c    28...... : [<c00
80351ea8: 35366330 205d3e30 6c202020 203a2072    0c650>]    lr :
80351eb8: 30633c5b 64353430 5d3e3835 20202020    [<c0045d58>]
80351ec8: 3a727370 30303420 31303030 343c0a33    psr: 40000013.<4
80351ed8: 2070733e 3763203a 66393163 20203037    >sp : c7c19f70
80351ee8: 3a207069 63376320 64653931 66202030    ip : c7c19ed0  f
80351ef8: 203a2070 31633763 63386639 0000000a    p : c7c19f8c....
80351f08: 00000000 00000000 00000000 00000000    ................
80351f18: 00000000 00000000 30303030 38722020    ........0000  r8
80351f28: 63203a20 38316337 0a303030 00000000     : c7c18000.....
80351f38: 00000000 00000000 30303030 36722020    ........0000  r6
80351f48: 63203a20 64313030 20386639 20357220     : c001d9f8  r5
80351f58: 3863203a 30343038 20203030 3a203472    : c8804000  r4 :
80351f68: 30303020 30303030 00000a30 00000000     00000000.......
80351f78: 00000000 00000000 20203030 3a203272    ........00  r2 :
80351f88: 63376320 30303831 72202030 203a2031     c7c18000  r1 :
80351f98: 30303030 31303030 30722020 30203a20    00000001  r0 : 0
80351fa8: 30303030 0a663330 00000000 00000000    000003f.........
80351fb8: 00000000 00000000 73515249 206e6f20    ........IRQs on
80351fc8: 51494620 6e6f2073 6f4d2020 53206564     FIQs on  Mode S
80351fd8: 335f4356 49202032 41204153 20204d52    VC_32  ISA ARM
80351fe8: 6d676553 20746e65 6e72656b 3c0a6c65    Segment kernel.<
80351ff8: 6f433e34 6f72746e 30203a6c 33356530    4>Control: 00e53
80352008: 20663738 62615420 203a656c 30303038    87f  Table: 8000
80352018: 30303034 41442020 30203a43 30303030    4000  DAC: 00000
80352028: 0a373130 00000000 00000000 00000000    017.............
80352038: 00000000 00000000 3a646970 202c3120    ........pid: 1,
80352048: 63617473 696c206b 2074696d 7830203d    stack limit = 0x
80352058: 31633763 30363238 00000a29 00000000    c7c18260).......
80352068: 00000000 00000000 00000000 00000000    ................
80352078: 00000000 00000000 30306131 000a2930    ........1a000)..
80352088: 00000000 00000000 00000000 00000000    ................
80352098: 00000000 00000000 00002020 00000000    ........  ......
803520a8: 00000000 00000000 00000000 00000000    ................
803520b8: 00000000 00000000 30303030 00002030    ........00000 ..
803520c8: 00000000 00000000 00000000 00000000    ................
803520d8: 00000000 00000000 0000203a 00000000    ........: ......
803520e8: 00000000 00000000 00000000 00000000    ................
803520f8: 00000000 00000000 65356330 00002038    ........0c5e8 ..
80352108: 00000000 00000000 00000000 00000000    ................
80352118: 00000000 00000000 00000020 00000000    ........ .......
80352128: 00000000 00000000 00000000 00000000    ................
80352138: 00000000 00000000 62663931 00002030    ........19fb0 ..
80352148: 00000000 00000000 00000000 00000000    ................
80352158: 00000000 00000000 00000020 00000000    ........ .......
80352168: 00000000 00000000 00000000 00000000    ................
80352178: 00000000 00000000 30636639 0000203a    ........9fc0: ..
80352188: 00000000 00000000 00000000 00000000    ................
80352198: 00000000 00000000 00000020 00000000    ........ .......
803521a8: 00000000 00000000 00000000 00000000    ................
803521b8: 00000000 00000000 30303030 30303020    ........0000 000
803521c8: 30303030 3c0a2030 66393e34 203a3065    00000 .<4>9fe0:
803521d8: 30303030 30303030 00000020 00000000    00000000 .......
803521e8: 00000000 00000000 00000000 00000000    ................
803521f8: 00000000 00000000 63373738 00000020    ........877c ...
80352208: 00000000 00000000 00000000 00000000    ................
80352218: 00000000 00000000 0000000a 00000000    ................
80352228: 00000000 00000000 00000000 00000000    ................
80352238: 00000000 00000000 646f6d28 49656c75    ........(moduleI
80352248: 6974696e 7a696c61 78302b65 78302f30    nitialize+0x0/0x
80352258: 29303531 00000020 3c5b206d 30303063    150) ...m [<c000
80352268: 38643738 00205d3e 00000000 00000000    87d8>] .........
80352278: 00000000 00000000 3278302f 0a296338    ......../0x28c).
80352288: 00000000 00000000 00000000 00000000    ................
80352298: 00000000 00000000 00386639 00000000    ........9f8.....
803522a8: 00000000 00000000 00000000 00000000    ................
803522b8: 00000000 00000000 3030633c 31373830    ........<c000871
803522c8: 205d3e30 00000000 00000000 00000000    0>] ............
803522d8: 00000000 00000000 20296338 00000000    ........8c) ....
803522e8: 00000000 00000000 00000000 00000000    ................
803522f8: 00000000 00000000 302f3078 30353778    ........x0/0x750
80352308: 00000a29 00000000 00000000 00000000    )...............
80352318: 00000000 00000000 65653565 00000020    ........e5ee ...
80352328: 00000000 00000000 00000000 00000000    ................
80352338: 00000000 00000000 00002029 00000000    ........) ......
80352348: 00000000 00000000 00000000 00000000    ................
80352358: 00000000 00000000 65316233 2d5d2033    ........3b1e3 ]-
80352368: 000a2d2d 00000000 00000000 00000000    --..............
80352378: 00000000 00000000 6e797320 676e6963    ........ syncing
80352388: 7441203a 706d6574 20646574 6b206f74    : Attempted to k
80352398: 206c6c69 74696e69 00000a21 00000000    ill init!.......
803523a8: 00000000 00000000 00000000 00000000    ................
803523b8: 00000000 00000000 00000000 00000000    ................
803523c8: 00000000 00000000 00000000 00000000    ................
803523d8: 00000000 00000000 00000000 00000000    ................
803523e8: 00000000 00000000 00000000 00000000    ................
803523f8: 00000000 00000000 00000000 00000000    ................
80352408: 00000000 00000000 00000000 00000000    ................
80352418: 00000000 00000000 00000000 00000000    ................
80352428: 00000000 00000000 00000000 00000000    ................
80352438: 00000000 00000000 00000000 00000000    ................
80352448: 00000000 00000000 00000000 00000000    ................
80352458: 00000000 00000000 00000000 00000000    ................
80352468: 00000000 00000000 00000000 00000000    ................
80352478: 00000000 00000000 00000000 00000000    ................
80352488: 00000000 00000000 00000000 00000000    ................
80352498: 00000000 00000000 00000000 00000000    ................

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Fabio Estevam]

Hi Alfred,

--- On Thu, 4/23/09, alfred steele <alfred.jaquez@gmail.com> wrote:

> I have attached the printk circular buffer log.
> 
> smc911x: initializing
> smc911x: detected <NULL> controller
> smc911x: phy initialized
> smc911x: MAC 92:92:92:bb:bb:bb
> TFTP from server 206.44.18.25; our IP address is
> 206.44.18.31
> Filename 'zImage_spin2_23march'.

Is this really an uImage? The name of the file starts with zImage, so it looks confusing. Can you confirm?

How are you generating the uImage? 

Assuming you are using MX31PDK Freescale BSP, you can do as follows:

cd rpm/BUILD/linux
make ARCH=arm uImage
(You need to have mkimage installed)

Which U-boot version are you using? 

Regards,

Fabio Estevam


      

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Fabio,
Are the load address and other params same for PDK and the ADS board.
I intend to do the same as what you intended to aith sucess.
I saw your post her :
http://www.nabble.com/Loading-a-kernel-on-MX31ADS-using-U-boot-td16642427.html


Please let me know how were able to sucessfully load the kernel. My
bootup sequence too hangs after "Uncompressing kernel...done booting
the kernel".

Thanks.


On Fri, Apr 24, 2009 at 1:23 PM, Fabio Estevam <fabioestevam@yahoo.com> wrote:
>
> Hi Alfred,
>
> --- On Thu, 4/23/09, alfred steele <alfred.jaquez@gmail.com> wrote:
>
>> I have attached the printk circular buffer log.
>>
>> smc911x: initializing
>> smc911x: detected <NULL> controller
>> smc911x: phy initialized
>> smc911x: MAC 92:92:92:bb:bb:bb
>> TFTP from server 206.44.18.25; our IP address is
>> 206.44.18.31
>> Filename 'zImage_spin2_23march'.
>
> Is this really an uImage? The name of the file starts with zImage, so it looks confusing. Can you confirm?
>
> How are you generating the uImage?
>
> Assuming you are using MX31PDK Freescale BSP, you can do as follows:
>
> cd rpm/BUILD/linux
> make ARCH=arm uImage
> (You need to have mkimage installed)
>
> Which U-boot version are you using?
>
> Regards,
>
> Fabio Estevam
>
>
>
>

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Wolfgang Denk]

Dear alfred steele,

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

(see http://www.netmeister.org/news/learn2quote.html)

In message <528f13590904262208s66b17bdekac218fba7994d177@mail.gmail.com> you wrote:
> Hi Fabio,
> Are the load address and other params same for PDK and the ADS board.
> I intend to do the same as what you intended to aith sucess.
> I saw your post her :
> http://www.nabble.com/Loading-a-kernel-on-MX31ADS-using-U-boot-td16642427.html
> 
> 
> Please let me know how were able to sucessfully load the kernel. My
> bootup sequence too hangs after "Uncompressing kernel...done booting
> the kernel".
...

[Full quote deleted.]

You top post.

You full quote.

And you post off topic stuff (Linux questions are off topic on the
U-Boot list).


Note that you cannot win any price for the maximum number of
netiquette violations in a single posting.


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 at denx.de
It is common sense to take a method and try it. If it fails, admit it
frankly and try another. But above all, try something.
                                              - Franklin D. Roosevelt

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Dear Wolfgang,

>You top post.
>You full quote.
Sincere Apologies. I better watch out before i hit the send button.

Best Regards.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Fabio Estevam]

Hi Alfred,

--- On Mon, 4/27/09, alfred steele <alfred.jaquez@gmail.com> wrote:

> Please let me know how were able to sucessfully load the
> kernel. My
> bootup sequence too hangs after "Uncompressing
> kernel...done booting
> the kernel".

Since MX31PDK is not in mainline U-boot yet, I am wondering which version are you using? Are you using the latest MX31PDK patches posted in this list by Magnus Lilja?

I think the first step would be to get MX31PDK into mainline U-boot. Are you willing to help on that?

Regards,

Fabio Estevam



      

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

> I think the first step would be to get MX31PDK into mainline U-boot. Are you willing to help on that?
Of course, as long as i have it up and running and tested on my
hardware. But in order to do that, i would need your help in answering
my earlier question.

Thanks for your help!

-Alfred.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/4/27 alfred steele <alfred.jaquez@gmail.com>:
>> I think the first step would be to get MX31PDK into mainline U-boot. Are you willing to help on that?
> Of course, as long as i have it up and running and tested on my
> hardware. But in order to do that, i would need your help in answering
> my earlier question.

And we need to know which U-boot patches you're using to boot the PDK
board. In your original post you use the "go" command to boot the
kernel, I use the "bootm" command.

Using my latest set of patches (posted here a couple of weeks ago) I
can boot Linux on the PDK using ethernet+tftp. The kernel (uImage) was
compiled using Linux v2.6.24 + Freescale's patches from one of their
BSPs (don't remember which actually, 1.3 or 1.4).

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Dear Magnus,

Thanks for the reply!
> And we need to know which U-boot patches you're using to boot the PDK
> board.
I am using the internal git tree code supplied to me by freescale. The
tarball is called "uboot-imx-imx_v2009.01.tar.gz". I can boot uboot
out of NAND successfully using that as the code base.  I had  started
using this even before Magnus had posted the patches and i had to
write a patch for the MMC/SD driver on top of that . To add to that ,
i tried downloading the mainline using GIT but it seems the corporate
firewall/proxy we have  blocks  it. Due to the shortage of time, i
continued to use the Freescale supplied code. It would be great if you
can supply me the code in a tarball(mainline git) with the patches you
posted if you want me to try it out.

>In your original post you use the "go" command to boot the
> kernel,
I use the "bootm" command now. My sole intention of using go was to
check whether or not zImage( instead of uImage) boots up as a generic
application. I tried verify  the bootags in  the U-boot environment. I
chacked on the machine id which gets registered with the kernel. They
all seemed to be the expected values.

Coming back to I am not sure about ,was when i tried dumping the
address(0x80000100) which supposedly stores the bootargs, i get the
following :
=> md 0x80000100
80000100: c0000100 c0000100 c0000108 c0000108    ................
80000110: c0000110 c0000110 c0000118 c0000118    ................
80000120: 92492492 24924924 00000149 736e6f63    .$I.$I.$I...cons
80000130: 3d656c6f 6d797474 2c306378 32353131    ole=ttymxc0,1152
80000140: c0000140 c0000140 c0000148 c0000148    @... at ...H...H...

It looks like the console is not set correctly to 115200, assuming its
in ASCII. Any clues as to what could be gone wrong?

Another quick question is do i have to supply the "mem=XX"  argument
if my CONFIG_SETUP_MEMORY_TAGS is set in include/configs/mx31_pdk.h

BTW, following is an extract from the uboot linker script -u-boot.lds
which i had edited. Please let me know if you think something's wrong
with it.

OUTPUT_ARCH(arm)
ENTRY(reset)
SECTIONS
{
        . = 0x00000000;

        . = ALIGN(4);
        .text      :
        {
          /* WARNING - the following is hand-optimized to fit within    */
          /* the sector layout of our flash chips!      XXX FIXME XXX   */

          * (.text.head)        /* arm reset handler */
          * (.text.init)        /* lowlevel initial */
          * (.text.load)        /* nand copy and load */
          * (.text.setup)
          board/freescale/mx31_3stack/libmx31_3stack.a  (.text)
          lib_arm/libarm.a              (.text)
          net/libnet.a                  (.text)
          drivers/mtd/libmtd.a          (.text)

          . = DEFINED(env_offset) ? env_offset : .;
          common/env_embedded.o(.text)

          *(.text)
        }

        . = ALIGN(4);

-Alfred.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/4/27 alfred steele <alfred.jaquez@gmail.com>:
> Dear Magnus,
>
> Thanks for the reply!
>> And we need to know which U-boot patches you're using to boot the PDK
>> board.
> I am using the internal git tree code supplied to me by freescale. The
> tarball is called "uboot-imx-imx_v2009.01.tar.gz". I can boot uboot
> out of NAND successfully using that as the code base. ?I had ?started
> using this even before Magnus had posted the patches and i had to
> write a patch for the MMC/SD driver on top of that . To add to that ,
> i tried downloading the mainline using GIT but it seems the corporate
> firewall/proxy we have ?blocks ?it. Due to the shortage of time, i
> continued to use the Freescale supplied code. It would be great if you
> can supply me the code in a tarball(mainline git) with the patches you
> posted if you want me to try it out.

There's a 'snapshot' function in git-web
(http://git.denx.de/?p=u-boot.git;a=tree) which will produce a tarball
of the current tree.

My patches are in the mailing list archives so you should be able to
download and apply them as well.

>
>>In your original post you use the "go" command to boot the
>> kernel,
> I use the "bootm" command now. My sole intention of using go was to
> check whether or not zImage( instead of uImage) boots up as a generic
> application. I tried verify ?the bootags in ?the U-boot environment. I
> chacked on the machine id which gets registered with the kernel. They
> all seemed to be the expected values.
>
> Coming back to I am not sure about ,was when i tried dumping the
> address(0x80000100) which supposedly stores the bootargs, i get the
> following :
> => md 0x80000100
> 80000100: c0000100 c0000100 c0000108 c0000108 ? ?................
> 80000110: c0000110 c0000110 c0000118 c0000118 ? ?................
> 80000120: 92492492 24924924 00000149 736e6f63 ? ?.$I.$I.$I...cons
> 80000130: 3d656c6f 6d797474 2c306378 32353131 ? ?ole=ttymxc0,1152
> 80000140: c0000140 c0000140 c0000148 c0000148 ? ?@... at ...H...H...
>
> It looks like the console is not set correctly to 115200, assuming its
> in ASCII. Any clues as to what could be gone wrong?

No idea.

Your printk dump from the first mail seems to indicate that the kernel
was able to boot, but for some reason it doesn't print on the serial
port. And I can't see any init of the serial port in that log either.
Seems like a problem with your kernel or its configuration.

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,

Thanks!
>Here's a 'snapshot' function in git-web
> (http://git.denx.de/?p=u-boot.git;a=tree) which will produce a tarball
> of the current tree.
Before that, i actually managed to "git clone" to a windows machine(at
my home) and export the u-boot tarball to my office linux host where
its destined to build. I got quite a few "HUNK" failures when i
applied your patch to that so I hand edited MAKEALL and Makefile and
some other  to restore parity.

But then on doing "make mx31_pdk_config", i got the following:

$ make mx31ads_config
: invalid option
make: *** [mx31ads_config] Error 1

So looks like somewhere out there , some file has some weird windows
inherited character/s e.g "CRLF" characters while doing a git cone
although i am not sure I am unable to identify the file. Any idea.

Thanks,
Alfred.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/4/28 alfred steele <alfred.jaquez@gmail.com>:
> Hi Magnus,
>
> Thanks!
> But then on doing "make mx31_pdk_config", i got the following:
>
> $ make mx31ads_config
> : invalid option
> make: *** [mx31ads_config] Error 1
>
> So looks like somewhere out there , some file has some weird windows
> inherited character/s e.g "CRLF" characters while doing a git cone
> although i am not sure I am unable to identify the file. Any idea.

No, but it seems that the problem is in the patched Makefile since it
says mx31ads_config instead of mx31_pdk_config.

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,

> No, but it seems that the problem is in the patched Makefile since it
> says mx31ads_config instead of mx31_pdk_config.
I tried this on all the RULES as i was getting the same results for
the rule "mx31_pdk_config". Apologize for for posting the wrong one.
This  problem got resolved when i useda tarball from the "snapshot"
feature of the GIT instead.

So , in order to boot out of NAND, all i need to do is use the image
generated out  "mx31pdk_nand_config" instead of the regular
"mx31_pdk_config". Right?

Thanks.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,

> So , in order to boot out of NAND, all i need to do is use the image
> generated out ?"mx31pdk_nand_config" instead of the regular
> "mx31_pdk_config". Right?
Another thing which confuses me is the file "nand_boot_mx31.c" . Is it
a symbolik link which points to the genric nand_boot.c or is it a file
by itself.

Thanks.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

> So , in order to boot out of NAND, all i need to do is use the image
> generated out ?"mx31pdk_nand_config" instead of the regular
> "mx31_pdk_config". Right?

Yes.

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/4/28 alfred steele <alfred.jaquez@gmail.com>:
> Hi Magnus,
>
>> So , in order to boot out of NAND, all i need to do is use the image
>> generated out ?"mx31pdk_nand_config" instead of the regular
>> "mx31_pdk_config". Right?
> Another thing which confuses me is the file "nand_boot_mx31.c" . Is it
> a symbolik link which points to the genric nand_boot.c or is it a file
> by itself.

The nand_spl/nand_boot_mx31.c is a regular file if that's the one you mean.

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,

Thanks again!
> The nand_spl/nand_boot_mx31.c is a regular file if that's the one you mean.
The reason i am asking is I am getting a build error  related to this
file after i apply your patches. When i do a ll(ls -l) on the file, i
get
$ll  u-boot-head/u-boot/nand_spl/board/freescale/mx31pdk/nand_boot_mx31.c
u-boot-head/u-boot/nand_spl/board/freescale/mx31pdk/nand_boot_mx31.c
-> u-boot-head/u-boot/nand_spl/board/freescale/mx31pdk/nand_boot_mx31.c

And there is NO real "nand_boot_mx31.c" from the patches i picked up
from the mail archives.  Perhaps i am looking at your older post.
Can you point me to the exact location for the basic support and the
"NAND spl" support.
As i am writing this email, . i found a new one
http://www.mail-archive.com/u-boot at lists.denx.de/msg11732.html. IS
that the correct one?

Thanks.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

2009/4/28 alfred steele <alfred.jaquez@gmail.com>:
> Hi Magnus,
>
> Thanks again!
>> The nand_spl/nand_boot_mx31.c is a regular file if that's the one you mean.
> The reason i am asking is I am getting a build error ?related to this
> file after i apply your patches. When i do a ll(ls -l) on the file, i
> get
> $ll ?u-boot-head/u-boot/nand_spl/board/freescale/mx31pdk/nand_boot_mx31.c
> u-boot-head/u-boot/nand_spl/board/freescale/mx31pdk/nand_boot_mx31.c
> -> u-boot-head/u-boot/nand_spl/board/freescale/mx31pdk/nand_boot_mx31.c

Hmm, I don't have my development machine up and running at the moment.
I'll check later.

> And there is NO real "nand_boot_mx31.c" from the patches i picked up
> from the mail archives. ?Perhaps i am looking at your older post.
> Can you point me to the exact location for the basic support and the
> "NAND spl" support.
> As i am writing this email, . i found a new one
> http://www.mail-archive.com/u-boot at lists.denx.de/msg11732.html. IS
> that the correct one?

Yes, that's the latest one I've posted (I've done minor updates
locally but haven't tested those yet).

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Dear Magnus,

> Yes, that's the latest one I've posted (I've done minor updates
> locally but haven't tested those yet).
I guess that's there are two patches for NAND_SPL, one which just adds
the SPL framework and the other which creates the mx31pdk_nand.c and
changes to start.S.
Please correct me if i am wrong.  Since the cpu/arm1136/start.S has
changed in a major way since April 02, since this is a generic file, i
am getting a BIG .rej file for the HUNKS which failed. I can hand edit
start.S as i have done for  the rest of the HUNK failures which were
minor. But is there a way i can get the snapshot as of April2, so that
i can apply this patch right away. This would greatly reduce the
effort. Or you suggest sticking to the latest and greatest mainline.

Thanks.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

>Or you suggest sticking to the latest and greatest mainline.
Alternatively, will use the .rej to generate the new lot of patches.
That seems the best route.

Thanks.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/4/28 alfred steele <alfred.jaquez@gmail.com>:
> Dear Magnus,
>
>> Yes, that's the latest one I've posted (I've done minor updates
>> locally but haven't tested those yet).
> I guess that's there are two patches for NAND_SPL, one which just adds
> the SPL framework and the other which creates the mx31pdk_nand.c and
> changes to start.S.

Something like that, in total there's four or five patches in that
series I think.

> Please correct me if i am wrong. ?Since the cpu/arm1136/start.S has
> changed in a major way since April 02, since this is a generic file, i
> am getting a BIG .rej file for the HUNKS which failed. I can hand edit
> start.S as i have done for ?the rest of the HUNK failures which were
> minor. But is there a way i can get the snapshot as of April2, so that
> i can apply this patch right away. This would greatly reduce the
> effort. Or you suggest sticking to the latest and greatest mainline.

If there are difficulties in applying the patches you could get a
snapshot of commit dfc91c33957c95da34e3888dc87912d5c15a7603 which is
the tree that I based my patches on. That's probably the quickest
solution.

I'll update the patches to the current u-boot tree, but I that can
take a couple of days.

Please put a question mark at the end of sentences that actually
contains a question!

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

> Please correct me if i am wrong. ?Since the cpu/arm1136/start.S has
> changed in a major way since April 02, since this is a generic file, i
> am getting a BIG .rej file for the HUNKS which failed. I can hand edit
> start.S as i have done for ?the rest of the HUNK failures which were
> minor. But is there a way i can get the snapshot as of April2, so that
> i can apply this patch right away. This would greatly reduce the
> effort. Or you suggest sticking to the latest and greatest mainline.

I just applied the patch series to the current u-boot tip and the only
problem was the top Makefile but that was easy to fix. No warnings
from start.S.

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,

> I just applied the patch series to the current u-boot tip and the only
> problem was the top Makefile but that was easy to fix. No warnings
> from start.S.
I was able to build successfully after hand editing some of the hunks
in start.S.   Even after using the commit snapshot you had referred
to.
I don't know where he disconnect is. Perhaps i am still not using  the
latest set of patches.

Towards  the end of my build , i get
cat nand_spl/u-boot-spl-aligned.bin u-boot.bin > u-boot-nand.bin
#cat nand_spl/u-boot-spl-16k.bin u-boot.bin > u-boot-nand.bin


But when i tried burning "u-boot-nand.bin" to the base address and
boot , i get only "one line"  printed on the console which is

U-Boot 2009.01 (Apr 28 2009 - 15:27:19)

 Looks like somethings messed up in the NAND detection in  the first
place.  I am using Redboot FIS to burn the  " u-boot-nand.bin" .  I
know it ignores bad blocks but i had used successfully to burn in the
past. I do not know the procedure for using u-boot to burn u-boot. Let
me know if you want me to try it.

Thanks.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/4/28 alfred steele <alfred.jaquez@gmail.com>:
> Hi Magnus,
> But when i tried burning "u-boot-nand.bin" to the base address and
> boot , i get only "one line" ?printed on the console which is
>
> U-Boot 2009.01 (Apr 28 2009 - 15:27:19)
>

If it comes that far it looks like a lot is working. Don't know why
the rest isn't though.

> ?Looks like somethings messed up in the NAND detection in ?the first
> place. ?I am using Redboot FIS to burn the ?" u-boot-nand.bin" . ?I
> know it ignores bad blocks but i had used successfully to burn in the
> past. I do not know the procedure for using u-boot to burn u-boot. Let
> me know if you want me to try it.

I suppose Redboot should be fine to use, haven't tried it much myself
though. I use a JTAG programmer for that.

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Fabio Estevam]

Hi Alfred,

--- On Tue, 4/28/09, alfred steele <alfred.jaquez@gmail.com> wrote:

> 
>  Looks like somethings messed up in the NAND detection in 
> the first
> place.  I am using Redboot FIS to burn the  "
> u-boot-nand.bin" .  I
> know it ignores bad blocks but i had used successfully to
> burn in the
> past. I do not know the procedure for using u-boot to burn
> u-boot. Let
> me know if you want me to try it.

I use ATK tool to flash Redboot and U-boot into the MX31PDK NAND.

You can get it from Freescale website.

Regards,

Fabio Estevam




      

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,

Thanks.

>>If it comes that far it looks like a lot is working. Don't know why
the rest isn't though.

At this point, it should be showing up the processor info.  I am using
a custom board with a different flash part. Samsung(KR series), and i
guess it is part of nand_id table as i have used that to get my other
version (patches form internal fresclae git) up and running. But i
believe the overall flash detection  happens automatically once you
have the id in place. Correct me if i am wrong.
Are there any specific files to look into from here. Another thing i
noticed  is that the config file in my build was somehow defining
CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT which should
not be the case. I put a #warning to identify that. What could be
wrong?

//#if defined(CONFIG_NAND_U_BOOT) && !defined(CONFIG_NAND_SPL)
//#warning "defined(CONFIG_NAND_U_BOOT) && !defined(CONFIG_NAND_SPL)"
//#define CONFIG_SKIP_LOWLEVEL_INIT
//#define CONFIG_SKIP_RELOCATE_UBOOT
//#endif

Thanks,
Alfred.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

> At this point, it should be showing up the processor info. ?I am using
> a custom board with a different flash part. Samsung(KR series), and i
> guess it is part of nand_id table as i have used that to get my other
> version (patches form internal fresclae git) up and running. But i
> believe the overall flash detection ?happens automatically once you
> have the id in place. Correct me if i am wrong.

A custom board with different flash and to me it's very confusing
which patches/version of u-boot you're and referring to in different
mails.

The mainline u-boot + my patches from early April does not contain any
driver for the i.MX31 NAND flash controller so that can't autodetect
any flash part at all.

> Are there any specific files to look into from here.

Follow the startup sequence in lib_arm/board.c:start_armboot and place
printf at strategic locations (unless you have a debugger which you
can single step in).

> Another thing i
> noticed ?is that the config file in my build was somehow defining
> CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT which should
> not be the case. I put a #warning to identify that. What could be
> wrong?
>
> //#if defined(CONFIG_NAND_U_BOOT) && !defined(CONFIG_NAND_SPL)
> //#warning "defined(CONFIG_NAND_U_BOOT) && !defined(CONFIG_NAND_SPL)"
> //#define CONFIG_SKIP_LOWLEVEL_INIT
> //#define CONFIG_SKIP_RELOCATE_UBOOT
> //#endif

CONFIG_NAND_SPL is defined in
nand_spl/board/freescale/mx31pdk/Makefile when it builds the second
phase loader.

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,


> The mainline u-boot + my patches from early April does not contain any
> driver for the i.MX31 NAND flash controller so that can't autodetect
> any flash part at all.
How does it boot out of NAND then? I am getting confused. By
detection, i meant the basic  init of the NFC and the NFCBUF and the
associated initiliazation to pool the SPL off the NAND which further
hand over to the uboot.

> Follow the startup sequence in lib_arm/board.c:start_armboot and place
> printf at strategic locations (unless you have a debugger which you
> can single step in).
How do i debug after u-boot relocates itself in RAM. I am getting this
on using u-boot as the ELF file with arm-elf-gdb. I remember when i
had the BDI3000 handy, i was getting a segfault when doing a "remote
target <IP>:2001>. Please suggest.

> CONFIG_NAND_SPL is defined in
> nand_spl/board/freescale/mx31pdk/Makefile when it builds the second
> phase loader.
CONFIG_NAND_SPL  is fine but  CONFIG_SKIP_LOWLEVEL_INIT and
CONFIG_SKIP_RELOCATE_UBOOT should not be defined in case we are
booting out of NAND, right?

Thanks.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/4/30 alfred steele <alfred.jaquez@gmail.com>:
> Hi Magnus,
>
>
>> The mainline u-boot + my patches from early April does not contain any
>> driver for the i.MX31 NAND flash controller so that can't autodetect
>> any flash part at all.
> How does it boot out of NAND then? I am getting confused. By
> detection, i meant the basic ?init of the NFC and the NFCBUF and the
> associated initiliazation to pool the SPL off the NAND which further
> hand over to the uboot.

I realize I wasn't clear. U-boot NAND booting is done in several
steps. For the i.MX31 the following steps are involved:
1. i.MX31 reads the first 2048 bytes from NAND. This is the SPL.
2. The SPL contains lowlevel-init and sets up the SDRAM (in
assembler). SPL is compiled without SKIP_LOWLEVEL_INIT and without
SKIP_RELOATE_UBOOT.
3. The SPL copies the rest of U-boot, a predefined number of blocks,
from NAND to SDRAM (nand_boot_mx31.c). This is currently done without
run-time detection of the NAND
type.CFG_NAND_CHIP_SIZE/CFG_NAND_PAGE_SIZE and others control this.
4. After copying, SPL jumps to U-boot
5. U-boot starts executing (cpu/arm1136/start.S)
6. SKIP_LOWLEVEL_INIT and SKIP_RELOCATE_UBOOT are defined when
compiling U-boot since the SDRAM has already been setup by SPL and SPL
has already placed U-boot at the correct address (i.e. no relocation
needed).
7. Eventually board/freescale/mx31pdk/mx31pdk.c:board_init is called.
8. U-boot main loop is entered.

(I hope I got the above right)

If U-boot had full NAND support for i.MX31, NAND would be detected
somewhere between steps 7 and 8.

Remember that there are two separate applications involved above, SPL
which is built in nand_spl, and U-boot. The two applications are
concatenated into one binary.
What's may be confusing is that the same config-file is used both when
compiling SPL and U-boot, but config.h is modified a bit.

>> CONFIG_NAND_SPL is defined in
>> nand_spl/board/freescale/mx31pdk/Makefile when it builds the second
>> phase loader.
> CONFIG_NAND_SPL ?is fine but ?CONFIG_SKIP_LOWLEVEL_INIT and
> CONFIG_SKIP_RELOCATE_UBOOT should not be defined in case we are
> booting out of NAND, right?

See my explanation above. CONFIG_SKIP* is defined when compiling
U-boot, but not when compiling SPL.

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,

> If U-boot had full NAND support for i.MX31, NAND would be detected
> somewhere between steps 7 and 8.
Thanks for the elaborate explanation. I did not find any detailed
documentation for the same in the u-boot readme's.


> See my explanation above. CONFIG_SKIP* is defined when compiling
> U-boot, but not when compiling SPL.
That explains why i swa the #warning spit out. So you mean the
CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT get toggled
during compile time only.
I am still struggling to get the NAND boot working.  I am not even
seeing U-boot spit out the first line on the console "U-boot <version
no> " when i power up subsequently.
This is what i did to build and run.
i) make mx31_pdk_nand_config
ii) make
Take U-boot-nand.bin and burn it at physical offset 0x0 of the NAND
using Redboot loaded via JTAG. When i reset, i see nothing on the
console.
I may be missing something which applying the patches then. Remote gdb
does not allow me to debug. If i put printfs in _start_armboot in
board.c, looks like its not ven entering that function.  Has the
standard output and the serial console dev been initiliazed before
this point i.e start_armboot?

Have you got a chance to post the patches to the mainline yet?
Thanks,
Alfred.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

> Have you got a chance to post the patches to the mainline yet?

No, but as I stated earlier the only merge problem I got was in the
top Makefile and that was easy to fix.

I need more time to post the patches since I'm taking care of some
comments that were posted to Maxim's patches (which I'm using as a
base).

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,

> I need more time to post the patches since I'm taking care of some
> comments that were posted to Maxim's patches (which I'm using as a
> base).
That's fine.
Which linker script gets actually used for the layout in in case of
nand_spl. Is it  u-boot-nand.lds or u-boot.lds.?

Thanks.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi
> That's fine.
> Which linker script gets actually used for the layout in in case of
> nand_spl. Is it ?u-boot-nand.lds or u-boot.lds.?

I am going back to the original intent of this thread, booting off the
linux kernel using TFTP.  Here's is a dump of my  U-boot  env.  Does
it look good enough for booting a  linux kernel.  WHat could be the
reason that the( md of the printk log does not show up the "console
=ttymxc0,115200" correctly.
It looks like its. just  "ttymxc0,1152" as evident from the memory
dump i had sent ealier in this thread.

=>printenv

baudrate=115200
netdev=eth0
uboot=u-boot.bin
nfsroot=/tools/rootfs/rootfs-2.6.24
bootargs_base=setenv bootargs console=ttymxc0,115200
bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serveri
p}:${nfsroot} rw
bootcmd=run bootcmd_net
bootcmd_net=run bootargs_base bootargs_nfs; tftpboot ${loadaddr} ${tftp_server}:
${kernel}; bootm
tftp_server=206.44.18.25
kernel=uImage_spin2
loadaddr=0x80008000
bootdelay=5
filesize=196828
fileaddr=81000000
ipaddr=206.44.18.31
serverip=206.44.18.25
loadaddr=0x80008000
bootargs=root=/dev/nfs rw
stdin=serial
stdout=serial
stderr=serial

Thanks.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/4/30 alfred steele <alfred.jaquez@gmail.com>:
> Hi
>> That's fine.
>> Which linker script gets actually used for the layout in in case of
>> nand_spl. Is it ?u-boot-nand.lds or u-boot.lds.?
>
> I am going back to the original intent of this thread, booting off the
> linux kernel using TFTP. ?Here's is a dump of my ?U-boot ?env. ?Does
> it look good enough for booting a ?linux kernel. ?WHat could be the
> reason that the( md of the printk log does not show up the "console
> =ttymxc0,115200" correctly.
> It looks like its. just ?"ttymxc0,1152" as evident from the memory
> dump i had sent ealier in this thread.
>
> =>printenv
>
> baudrate=115200
> netdev=eth0
> uboot=u-boot.bin
> nfsroot=/tools/rootfs/rootfs-2.6.24
> bootargs_base=setenv bootargs console=ttymxc0,115200
> bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serveri
> p}:${nfsroot} rw
> bootcmd=run bootcmd_net
> bootcmd_net=run bootargs_base bootargs_nfs; tftpboot ${loadaddr} ${tftp_server}:
> ${kernel}; bootm
> tftp_server=206.44.18.25
> kernel=uImage_spin2
> loadaddr=0x80008000
> bootdelay=5
> filesize=196828
> fileaddr=81000000
> ipaddr=206.44.18.31
> serverip=206.44.18.25
> loadaddr=0x80008000
> bootargs=root=/dev/nfs rw
> stdin=serial
> stdout=serial
> stderr=serial

I tend to load my kernels to 0x81000000 and not 0x80008000 but I don't
know if that really matters. Other than that I think 'run bootcmd_net'
should work.

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,


> I tend to load my kernels to 0x81000000 and not 0x80008000 but I don't
> know if that really matters. Other than that I think 'run bootcmd_net'
> should work.
Oops i realized i top posted:(  I am re-posting again.

i checked in the kernel code
rpm/BUILD/linux/arch/arm/mach-mx3/Makefile.boot. which probably
expects the uboot  load the kernel at address  0x80008000(zreladdr)
which is probably the kernel image relocated address

zreladdr-y   := 0x80008000
params_phys-y   := 0x80000100 (boot arg location which i verified
doing a md on u-boot).
initrd_phys-y   := 0x80800000

Are these the correct params or is there any other place you look at
for verifying if the u-boot and kernel match on  the values of
loadaddr, bootarg location ?

Thanks

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/5/1 alfred steele <alfred.jaquez@gmail.com>:
> Hi Magnus,
>
>
>> I tend to load my kernels to 0x81000000 and not 0x80008000 but I don't
>> know if that really matters. Other than that I think 'run bootcmd_net'
>> should work.
> Oops i realized i top posted:( ?I am re-posting again.
>
> i checked in the kernel code
> rpm/BUILD/linux/arch/arm/mach-mx3/Makefile.boot. which probably
> expects the uboot ?load the kernel at address ?0x80008000(zreladdr)
> which is probably the kernel image relocated address
>
> zreladdr-y ? := 0x80008000
> params_phys-y ? := 0x80000100 (boot arg location which i verified
> doing a md on u-boot).
> initrd_phys-y ? := 0x80800000
>
> Are these the correct params or is there any other place you look at
> for verifying if the u-boot and kernel match on ?the values of
> loadaddr, bootarg location ?

Yes, those values are correct. The boot_params address is also in
arch/arm/mach-mx3/mx31pdk.c (mx3_3stack.c if you use Freescale's BSP).

/Magnus

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

> Yes, those values are correct. The boot_params address is also in
> arch/arm/mach-mx3/mx31pdk.c (mx3_3stack.c if you use Freescale's BSP).
>
Where do i get the latest version of Freescale BSP? i know this is not
the correct forum...but still

Thanks,
Alfred

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Wolfgang Denk]

Dear alfred steele,

In message <528f13590905010838g1a1dc360gfd5fd4a64e84d466@mail.gmail.com> you wrote:
>
> Where do i get the latest version of Freescale BSP? i know this is not
> the correct forum...but still

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Fabio Estevam]

--- On Fri, 5/1/09, alfred steele <alfred.jaquez@gmail.com> wrote:

> Where do i get the latest version of Freescale BSP? i know
> this is not
> the correct forum...but still

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX31PDK&nodeId=0162468rH311432973ZrDR&fpsp=1&tab=Design_Tools_Tab

(Click on IMX31_PDK_14_LINUX_BSP_R14 )

Regards,

Fabio Estevam 


      

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Fabio Estevam]

--- On Fri, 5/1/09, alfred steele <alfred.jaquez@gmail.com> wrote:

> Where do i get the latest version of Freescale BSP? i know
> this is not
> the correct forum...but still

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX31PDK&nodeId=0162468rH311432973ZrDR&fpsp=1&tab=Design_Tools_Tab

(Click on IMX31_PDK_14_LINUX_BSP_R14 )

Regards,

Fabio Estevam 


      

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

> (Click on IMX31_PDK_14_LINUX_BSP_R14 )
Thanks Fabio. Do you know what the load address and entry point for
creating a uImage are for the mx31 pdk board and where to load the
uImage to. Itried "0x81000000" and "0x80008000" and i am still unable
to load the kernel off u-boot.?

Best Regards,
Alfred

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[alfred steele]

Hi Magnus,

> uImage to. Itried "0x81000000" and "0x80008000" and i am still unable
> to load the kernel off u-boot.?
Thanks  for all the help!  I have got  linux booting from u-boot. So
it had something to do with one of the device drivers
Doing a post mortem on the printk log buffer pointed me to the problem.

Thanks,
Alfred.

[U-Boot] U-boot -printk kernel crash dump using md on PDK

[Magnus Lilja]

Hi

2009/5/4 alfred steele <alfred.jaquez@gmail.com>:
> Hi Magnus,
>
>> uImage to. Itried "0x81000000" and "0x80008000" and i am still unable
>> to load the kernel off u-boot.?
> Thanks ?for all the help! ?I have got ?linux booting from u-boot. So
> it had something to do with one of the device drivers
> Doing a post mortem on the printk log buffer pointed me to the problem.

Excellent!

/Magnus