On Tue, Sep 29, 2009 at 10:36:13AM -0700, Kevin Hilman wrote:
> "Thompson, Nick (GE EntSol,  Intelligent Platforms)" 
> <[email protected]> writes:
> 
> [...]
> 
> > After adding the printk hack to get better debug output I found:
> >
> > <5>Linux version 2.6.31-rc7-davinci1-06494-g6587756-dirty
> > (defa...@default-desktop) (gcc version 4.3.3 (Sourcery G++ Lite
> > 2009q1-203) ) #6 PREEMPT Tue Sep 29 16:21:36 BST 2009
> > CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
> > CPU: VIVT data cache, VIVT instruction cache
> > Machine: DaVinci DA830/OMAP L137 EVM
> > Memory policy: ECC disabled, Data cache writethrough
> > <7>On node 0 totalpages: 8192
> > <7>free_area_init_node: node 0, pgdat c02bec88, node_mem_map c02e9000
> > <7>  DMA zone: 64 pages used for memmap
> > <7>  DMA zone: 0 pages reserved
> > <7>  DMA zone: 8128 pages, LIFO batch:0
> > <3>davinci_common_init: SoC Initialization failed
> > Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
> > 8128
> > <5>Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p1
> > noinitrd rw ip=off mem=32M
> > PID hash table entries: 128 (order: 7, 512 bytes)
> > <6>Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> > <6>Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > <6>Memory: 32MB = 32MB total
> > <5>Memory: 29504KB available (2504K code, 270K data, 96K init, 0K
> > highmem)
> > <6>SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1,
> > Nodes=1
> > <6>NR_IRQS:245
> > <2>kernel BUG at arch/arm/mach-davinci/time.c:375!
> > <1>Unable to handle kernel NULL pointer dereference at virtual address
> > 00000000
> > <1>pgd = c0004000
> >
> > Note that the davinci SoC initilisation fails. This is where the clocks
> > are registered and the failure means there are no clocks, so clk_get
> > fails later.
> >
> > Why??? My OMAP-L137 is reporting a jtag part number of 0xb7df and a
> > variant number of 0x8. da830.c is expecting:
> >
> > static struct davinci_id da830_ids[] = {
> >     {
> >             .variant        = 0x0,
> >             .part_no        = 0xb7df,
> >             .manufacturer   = 0x017,        /* 0x02f >> 1 */
> >             .cpu_id         = DAVINCI_CPU_ID_DA830,
> >             .name           = "da830/omap l137",
> >     },
> > };
> >
> > I hacked the 0x0 to 0x08 and my target now boots. I guess the correct
> > fix is to add a second entry for the new (?) variant, but I'm not a
> > kernel expert.
> >
> > I hope that helps. Feel free to ask for more info.
> >
> 
> I've merged some patches for new silicon revs of dm646x and dm355 but
> haven't seen any patches for the da830.  Looks like one is needed.

Hmm, I missed the original post of this but I'll look for it in a
minute.  Yes, the correct solution for the "variant issue" would
be an additional entry in that table.  I'll research the new revs
to see what else has changed and make a patch(es).

Mark
--

_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to