• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 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.

OMAPL-138 SOM revB: Boot Issue

michael clark
Intellectual 520 points
Other Parts Discussed in Thread: OMAP-L138, TPS65070

Hello,

I am working with a custom board that resembles the Zoom OMAP-L138 eXp kit. I am having a difficult time booting the Kernel when using OMAPL-138 SOM revB, but not revA. Actually, I can not boot the Kernel using revA after attempting to boot using revB. I have to first disconnect the battery pack and hold the reset button for several seconds, and then revA boots up.

The hardware under test does have several cuts & jumpers, which might be the cause of this issue. Previous board versions did not show this issue after we updated the Kernel's source file da850.c with variant ID 1.

I'm not able to view printk console messages over the serial port after uncompressing the Kernel, but I was able to get the messages from RAM as shown below:

<5>Linux version 2.6.32-ts-armv5l (mike@IAI183-l) (gcc version 44.5 (GCC) ) #14. PREEMPT Thu Oct27 12:37:02 EDT 2011.
<4>CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177.
<4>CPU: VIVT data cache, VIVT instruction cache.
<4>Machine: DaVinci DA850/OMAP-L138 EVM.
<4>Memory policy: ECC disabled, Data cache writeback.
<7>On node 0 totalpages: 16384.
<7>free_area_init_node: node 0, pgdat c04367d4, node_mem_map c0459000.
<7>DMA zone: 128 pages used for memmap.
<7>DMA zone: 0 pages reserved.
<7>DMA zone: 16256 pages, LIFO batch:3.
<6>DaVinci da850/omap-l138/am18x variant 0x1.
<4>Built 1 zonelists in Zone order, mobility grouping on.  Total pages:16256.
<5>Kernel command line: mem=64M console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait debug.
<6>PID hash table entries: 256 (order: -2, 1024 bytes).
<6>Dentry cache hash table entries: 8192 (order: 3, 32768 bytes).
<6>Inode-cache hash table entries: 4096 (order: 2, 16384 bytes).
<6>Memory: 64MB = 64MB total.
<5>Memory: 60456KB available (3952K code, 303K data, 156K init, 0K highmem).
<6>SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1.
<6>Hierarchical RCU implementation..
<6>NR_IRQS:245.
<4>Console: colour dummy device 80x30.
<6>Calibrating delay loop... 149.50 BogoMIPS (lpj=747520).
<4>Mount-cache hash table entries: 512.<6>CPU: Testing write buffer coherency:  ok.
<6>DaVinci:144 gpio irqs.
<6>regulator: core version 0.5.
<6>NET: Registered protocol family 16.
<4>bio: create slab <bio-0> at 0.
<5>SCSI subsystem initialized.
<7>libata version 3.00 loaded.
<6>usbcore: registered new interface driver usbfs.
<6>usbcore: registered new interface driver hub.
<6>usbcore: registered new device driver usb

I rebooted and captured the log messages many times, and the messages always stop at the same point. As a sanity check, I cleared this section of memory (__log_buf) before booting up each time. When the Kernel boots successfully the following messages are displayed next:

regulator: VDCDC1: 3200 <--> 3300 mV                                           
regulator: VDCDC2: 1750 <--> 3300 mV                                           
regulator: VDCDC3: 950 <--> 1300 mV                                            
regulator: LDO1: 1800 mV                                                       
regulator: LDO2: 1150 <--> 1300 mV

We are using a different power management system compared to the EVM (TPS65070), so this might be the cause of the hang. At this point I'm ready to start reviewing Kernel code, but I'm curious if anyone can provide additional information.

Thanks!

  • 0
    Intellectual 520 points

    Hello,

    I was able to make a bit more progress...

    It seems the Kernel is getting hung when calling "davinci_i2c_init_driver." I determined this by evaluating the initcall_t function pointers with the System.map file when executing "do_initcalls" from kernel_init->do_basic_setup. I'm still looking, but the issue seems to occur in "i2c_davinci_init."

    The OMAP-L138 SOM uses i2c bus 0 for power management ( TPS65070 ), so I verified the kernel configuration included I2C and TPS65070 power management drivers. Both drivers are built-in. Again, I am able to boot the Kernel when using SOM revA, but not revB.

    Any help would be appreciated

    Thanks!

     

  • 0 in reply to michael clark
    Intellectual 520 points

    This problem was resolved by providing a constant 3.3v power to the RTC battery pin on the module. After reviewing the OMAP-L138 spec, it was verified that this is required as the RTC voltage is not optional. Our custom board uses a coin battery for the RTC power, but due to high run-time current draw the battery life-time was only a few weeks. Once the battery voltage fell below a threshold, the kernel was consistently crashing, but UBL and u-boot ran successfully.