[U-Boot] U-boot -printk kernel crash dump using md on PDK
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 5000 50 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@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 ................
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
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.ht...
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
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.ht...
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
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
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.
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
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 @...@...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.
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 @...@...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
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.
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
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.
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.
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
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@lists.denx.de/msg11732.html. IS that the correct one?
Thanks.
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@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
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.
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
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
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.
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
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.
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
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.
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
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.
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
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.
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.
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
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
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
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
From Freescale? Try www.freescale.com ...
Best regards,
Wolfgang Denk
--- 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&...
(Click on IMX31_PDK_14_LINUX_BSP_R14 )
Regards,
Fabio Estevam
(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
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.
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
--- 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&...
(Click on IMX31_PDK_14_LINUX_BSP_R14 )
Regards,
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
participants (4)
-
alfred steele -
Fabio Estevam -
Magnus Lilja -
Wolfgang Denk