• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 454 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM355 BOOT Starting kernel ... STOP

NINGMENG CHEN
Intellectual 895 points

We have produced more than 50 DM355 boards. The following case is the only one case.

The uImage, Uboot  and bootargs are all verified on the other boards.

But in one board, the kernel is stopped at "Starting kernel ...". I doubt the hardware have some problems.  Would you please give me some suggestions?

 

U-Boot 1.2.0 (Aug  8 2008 - 00:18:21)

DRAM:  128 MB
NAND:  NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)
Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
nand_read_bbt: Bad block at 0x010a0000
nand_read_bbt: Bad block at 0x02fc0000
nand_read_bbt: Bad block at 0x06940000
nand_read_bbt: Bad block at 0x0f600000
nand_read_bbt: Bad block at 0x1c600000
nand_read_bbt: Bad block at 0x1e3c0000
NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)
Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
nand_read_bbt: Bad block at 0x010a0000
nand_read_bbt: Bad block at 0x02fc0000
nand_read_bbt: Bad block at 0x06940000
nand_read_bbt: Bad block at 0x0f600000
nand_read_bbt: Bad block at 0x1c600000
nand_read_bbt: Bad block at 0x1e3c0000
1024 MiB
In:    serial
Out:   serial
Err:   serial
ARM Clock :- 216MHz
DDR Clock :- 171MHz
Hit any key to stop autoboot:  0
TFTP from server 192.168.1.55; our IP address is 192.168.1.46
Filename 'uImage-dm355'.
Load address: 0x80700000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##################################################
done
Bytes transferred = 1585304 (183098 hex)
## Booting image at 80700000 ...
   Image Name:   Linux-2.6.10_mvl401
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1585240 Bytes =  1.5 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

 

Lemon Chan
Beijing AVSolution Technology Co.,Ltd

  • 0
    TI__Mastermind 37340 points

    The log looks pretty normal (except maybe for the excessive 'Bad block' messages), up to the point you have posted above.  If the boards are all the same and the software is all the same, it may be a a loose component on the board.  I would probrably try reflashing u-boot and uImage again, since this is fairly easy, if this does not work, I would consider trouble-shooting NAND part on the board.  There are some board level test in Spectrum Digital site that may help serve as reference code for testing purposes.

    http://c6000.spectrumdigital.com/evmdm355/revd/

  • 0 in reply to Juan Gonzales
    Intellectual 895 points

    Juan Gonzales said:
    .  If the boards are all the same and the software is all the same, it may be a a loose component on the board.  I would probrably try reflashing u-boot and uImage again,

     

    With your guide, I do the above experiment and test the DDR, NAND FLASH(Upper and Lower), AIC33,VIDEO LOOPBACK. They are all OK.

    I doubt the the loose component is DM355? Is that possible?

     

  • 0 in reply to NINGMENG CHEN
    TI__Mastermind 41665 points

    NINGMENG CHEN said:
    I doubt the the loose component is DM355? Is that possible?

    It is possible but unlikely, in general if there was a problem with the DM355 itself the tests Juan suggested would probably be failing in other ways, but on the other hand the DM355 is probably the largest BGA device on your board making it most seceptable to manufacturing defects. The best I could suggest is to compare this failing board to the other known good boards in regards U-Boot arguments, UBL, U-Boot and uImage, reflashing everything from scratch the same way a known good board is booting as Juan suggested should work out any spurrious errors that may have caused this particular failure.