Problems bringing up new PM 2.6.29 tree on Logic 35x LV SOM

Problems bringing up new PM 2.6.29 tree on Logic 35x LV SOM

[Peter Barada]

I pulled out Kevin's linux-omap PM tree this morning by:

git init
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
cd linux-omp-pm
git checkout -b pm origin/pm

1) Cloned arch/arm/mach-omap2/board-omap3beagle.c to
arch/arm/mach-omap2/board-omap3lv_som.c, and ifdef'd out all calls to
omap_cfg_reg and gpio calls (since the GPIO on my board is different
than beagle).

2) Added the following to arch/arm/mach-omap2/Makefile:

obj-$(CONFIG_MACH_OMAP3530_LV_SOM)	+= board-omap3lv_som.o \
					   mmc-twl4030.o \
					   twl4030-generic-scripts.o

3) Added the following to arch/arm/mach-omap2/Kconfig

config MACH_OMAP3530_LV_SOM
	bool "OMAP3 Logic 35x LV SOM board"
	depends on ARCH_OMAP3 && ARCH_OMAP34XX


4) Copied Kevin's beagle.pm.config to .config

5) Ran menuconfig, deselected "OMAP3 BEAGLE board" and selected "OMAP3
   Logic 35x LV SOM board", selected "Kernel low-level debugging
   function (DEBUG_LL)", changed "Low-level debug console UART" to
   UART1, turned on OMAP_MUX, OMAP_MUX_DEBUG, disabled USB and the
   OMAP host/otg USB controllers, and saved the results, built uImage.


When I first ran the kernel I got:

<5>Linux version 2.6.29-omap1 (peter@blackhole) (gcc version 4.1.2) #17
PREEMPT
Thu Mar 26 15:37:52 EDT 2009
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP OMAP3530LV_SOM board
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 32768
<7>free_area_init_node: node 0, pgdat c0396e74, node_mem_map c03c1000
<7>  Normal zone: 256 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 32512 pages, LIFO batch:7
<6>OMAP3430 ES2.1
<6>SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
32512
<5>Kernel command line: display=3 console=ttyS0,115200 root=/dev/nfs rw
nfsroot=192.168.3.5:/opt/nfs-exports/ltib-omap,wsize=1500,rsize=1500
ip=dhcp ignore_loglevel no_console_suspend initcall_debug
<6>debug: ignoring loglevel setting.
<6>Clocking rate (Crystal/DPLL/ARM core): 26.0/166/500 MHz
<6>Reprogramming SDRC
<6>GPMC revision 5.0
gpmc_mem_init: cs 0 base 0x30000000 size 0x8000000
<2>kernel BUG at arch/arm/mach-omap2/gpmc.c:438!
<1>Unable to handle kernel NULL pointer dereference at virtual address
00000000
<1>pgd = c0004000
<1>[00000000] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (2.6.29-rc8-omap1 â)
PC is at cache_init+0x608dca41/0x60b3392d
LR is at cache_init+0x6090515d/0x60b3392d
pc : [<c002e9a0>]    lr : [<c00570bc>]    psr: 400001d3
sp : c036df40  ip : c036de98  fp : c036df4c
r10: 00000000  r9 : 411fc082  r8 : c0398700
r7 : 00000000  r6 : c036c000  r5 : 30000000  r4 : fffffff0
r3 : 00000000  r2 : c036c000  r1 : 800001d3  r0 : 00000031
<1>Unable to handle kernel NULL pointer dereference at virtual address
00000013
<1>Unhandled fault: alignment exception (0x001) at 0xe1a040c2
Internal error: : 1 [#2] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (2.6.29-rc8-omap1 â)
PC is at cache_init+0x608df1b5/0x60b3392d
LR is at 0xe3e07002
pc : [<c0031114>]    lr : [<e3e07002>]    psr: 000001d3
sp : c0067ed0  ip : c0067f10  fp : c0067f0c
r10: 00000000  r9 : 400001d3  r8 : 159f00dc
r7 : c0067fd8  r6 : e1a04006  r5 : 00000560  r4 : ffffffff
r3 : c0066000  r2 : c0067fd8  r1 : 00000005  r0 : 159f00dc
<1>Unhandled fault: alignment exception (0x001) at 0xe1a040c2
Internal error: : 1 [#3] PREEMPT
Modules linked in:
CPU: 0    Not tainted  (2.6.29-rc8-omap1 â)
PC is at cache_init+0x608df1b5/0x60b3392d
LR is at 0xe3e07005
pc : [<c0031114>]    lr : [<e3e07005>]    psr: 000001d3
sp : c00679e0  ip : c0067a20  fp : c0067a1c
r10: c039e5d0  r9 : 400001d3  r8 : 00000013
r7 : c0067ae8  r6 : e1a04006  r5 : 00000000  r4 : ffffffff
r3 : c0066000  r2 : c0067ae8  r1 : 00000005  r0 : 00000013
<1>Unhandled fault: alignment exception (0x001) at 0xea000177
<1>Unhandled fault: alignment exception (0x001) at 0xea000177
<1>Unhandled fault: alignment exception (0x001) at 0xea000177

I changed the call to omap_init_common_hw to pass in four NULLs (as I
think the sdrc params for mt46h32m32lf6 (somehow?) don't match the
mt29c2g24maklajg-75 used on our board.  This lets the kernel go
farther, (though I do get "<3>dpll3_m2_clk rate change failed: -22"
before the "GPMC revision 5.0" message) but it hangs in rtc_hctosys,
and further printk debugging shows the hang is in twl4030_i2c_write_u8,
apparently no response comes back from the I2C controller.  Sometimes
it hangs in omap3_sr_init, again trying to write to the twl4030 to
turn on Smartreflex.  I checked the schematics, and both the beagle
board and Logic's LV SOM use the same pins for i2c1 to talk to the
twl4030.


1) Are the git commands I used the proper way to pull out Kevin's PM
   tree?
2) Does my approch of using Beagle as a starting point for a port
   to Logic's 35x LV SOM look sane (I already have 2.6.28-rc8 running
   on the LV som, started from LDP)?
3) Any suggestions on how to figure out why I2C communication with the
   TWL4030 fails?

Any help is appreciated!

-- 
Peter Barada <peterb@logicpd.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problems bringing up new PM 2.6.29 tree on Logic 35x LV SOM

[Kevin Hilman]

Peter Barada <peterb@logicpd.com> writes:

> I pulled out Kevin's linux-omap PM tree this morning by:
>
> git init
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
> cd linux-omp-pm
> git checkout -b pm origin/pm
>
> 1) Cloned arch/arm/mach-omap2/board-omap3beagle.c to
> arch/arm/mach-omap2/board-omap3lv_som.c, and ifdef'd out all calls to
> omap_cfg_reg and gpio calls (since the GPIO on my board is different
> than beagle).
>
> 2) Added the following to arch/arm/mach-omap2/Makefile:
>
> obj-$(CONFIG_MACH_OMAP3530_LV_SOM)	+= board-omap3lv_som.o \
> 					   mmc-twl4030.o \
> 					   twl4030-generic-scripts.o
>
> 3) Added the following to arch/arm/mach-omap2/Kconfig
>
> config MACH_OMAP3530_LV_SOM
> 	bool "OMAP3 Logic 35x LV SOM board"
> 	depends on ARCH_OMAP3 && ARCH_OMAP34XX
>
>
> 4) Copied Kevin's beagle.pm.config to .config
>
> 5) Ran menuconfig, deselected "OMAP3 BEAGLE board" and selected "OMAP3
>    Logic 35x LV SOM board", selected "Kernel low-level debugging
>    function (DEBUG_LL)", changed "Low-level debug console UART" to
>    UART1, turned on OMAP_MUX, OMAP_MUX_DEBUG, disabled USB and the
>    OMAP host/otg USB controllers, and saved the results, built uImage.
>
>
> When I first ran the kernel I got:
>
> <5>Linux version 2.6.29-omap1 (peter@blackhole) (gcc version 4.1.2) #17
> PREEMPT
> Thu Mar 26 15:37:52 EDT 2009
> CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f
> CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
> Machine: OMAP OMAP3530LV_SOM board
> Memory policy: ECC disabled, Data cache writeback
> <7>On node 0 totalpages: 32768
> <7>free_area_init_node: node 0, pgdat c0396e74, node_mem_map c03c1000
> <7>  Normal zone: 256 pages used for memmap
> <7>  Normal zone: 0 pages reserved
> <7>  Normal zone: 32512 pages, LIFO batch:7
> <6>OMAP3430 ES2.1
> <6>SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages:
> 32512
> <5>Kernel command line: display=3 console=ttyS0,115200 root=/dev/nfs rw
> nfsroot=192.168.3.5:/opt/nfs-exports/ltib-omap,wsize=1500,rsize=1500
> ip=dhcp ignore_loglevel no_console_suspend initcall_debug
> <6>debug: ignoring loglevel setting.
> <6>Clocking rate (Crystal/DPLL/ARM core): 26.0/166/500 MHz

The other big variable in early board bringup is the bootloader.  Which
determines the initial clock speeds during boot.

A quick glance at Beagle booting the same kernel at this point, and I
see:

   Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz

which shows the CORE_CLK on Beagle at 2x the frequency of on your
hardware.  That clock is the source for the interface and functional
clocks for most of the modules (including i2c.)

> <6>Reprogramming SDRC
> <6>GPMC revision 5.0
> gpmc_mem_init: cs 0 base 0x30000000 size 0x8000000
> <2>kernel BUG at arch/arm/mach-omap2/gpmc.c:438!
> <1>Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> <1>pgd = c0004000
> <1>[00000000] *pgd=00000000
> Internal error: Oops: 805 [#1] PREEMPT
> Modules linked in:
> CPU: 0    Not tainted  (2.6.29-rc8-omap1 â)
> PC is at cache_init+0x608dca41/0x60b3392d
> LR is at cache_init+0x6090515d/0x60b3392d
> pc : [<c002e9a0>]    lr : [<c00570bc>]    psr: 400001d3
> sp : c036df40  ip : c036de98  fp : c036df4c
> r10: 00000000  r9 : 411fc082  r8 : c0398700
> r7 : 00000000  r6 : c036c000  r5 : 30000000  r4 : fffffff0
> r3 : 00000000  r2 : c036c000  r1 : 800001d3  r0 : 00000031
> <1>Unable to handle kernel NULL pointer dereference at virtual address
> 00000013
> <1>Unhandled fault: alignment exception (0x001) at 0xe1a040c2
> Internal error: : 1 [#2] PREEMPT
> Modules linked in:
> CPU: 0    Not tainted  (2.6.29-rc8-omap1 â)
> PC is at cache_init+0x608df1b5/0x60b3392d
> LR is at 0xe3e07002
> pc : [<c0031114>]    lr : [<e3e07002>]    psr: 000001d3
> sp : c0067ed0  ip : c0067f10  fp : c0067f0c
> r10: 00000000  r9 : 400001d3  r8 : 159f00dc
> r7 : c0067fd8  r6 : e1a04006  r5 : 00000560  r4 : ffffffff
> r3 : c0066000  r2 : c0067fd8  r1 : 00000005  r0 : 159f00dc
> <1>Unhandled fault: alignment exception (0x001) at 0xe1a040c2
> Internal error: : 1 [#3] PREEMPT
> Modules linked in:
> CPU: 0    Not tainted  (2.6.29-rc8-omap1 â)
> PC is at cache_init+0x608df1b5/0x60b3392d
> LR is at 0xe3e07005
> pc : [<c0031114>]    lr : [<e3e07005>]    psr: 000001d3
> sp : c00679e0  ip : c0067a20  fp : c0067a1c
> r10: c039e5d0  r9 : 400001d3  r8 : 00000013
> r7 : c0067ae8  r6 : e1a04006  r5 : 00000000  r4 : ffffffff
> r3 : c0066000  r2 : c0067ae8  r1 : 00000005  r0 : 00000013
> <1>Unhandled fault: alignment exception (0x001) at 0xea000177
> <1>Unhandled fault: alignment exception (0x001) at 0xea000177
> <1>Unhandled fault: alignment exception (0x001) at 0xea000177
>
> I changed the call to omap_init_common_hw to pass in four NULLs (as I
> think the sdrc params for mt46h32m32lf6 (somehow?) don't match the
> mt29c2g24maklajg-75 used on our board.  This lets the kernel go
> farther, (though I do get "<3>dpll3_m2_clk rate change failed: -22"
> before the "GPMC revision 5.0" message) 

DPLL3 is what generates CORE_CLK, so this is another indicator that
something is awry in your early clock setup by the bootloader.

> but it hangs in rtc_hctosys,
> and further printk debugging shows the hang is in twl4030_i2c_write_u8,
> apparently no response comes back from the I2C controller.  Sometimes
> it hangs in omap3_sr_init, again trying to write to the twl4030 to
> turn on Smartreflex.  I checked the schematics, and both the beagle
> board and Logic's LV SOM use the same pins for i2c1 to talk to the
> twl4030.

Not sure I would really trust any results until you sort out the right
SDRC timings for your board.

> 1) Are the git commands I used the proper way to pull out Kevin's PM
>    tree?

Yes, although the 'git init' isn't needed.

> 2) Does my approch of using Beagle as a starting point for a port
>    to Logic's 35x LV SOM look sane (I already have 2.6.28-rc8 running
>    on the LV som, started from LDP)?
> 3) Any suggestions on how to figure out why I2C communication with the
>    TWL4030 fails?

Double check the setup of the clocks in your bootloader, DPLL3 in
particular.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problems bringing up new PM 2.6.29 tree on Logic 35x LV SOM

[Paul Walmsley]

On Thu, 26 Mar 2009, Peter Barada wrote:

> I changed the call to omap_init_common_hw to pass in four NULLs (as I
> think the sdrc params for mt46h32m32lf6 (somehow?) don't match the
> mt29c2g24maklajg-75 used on our board. 
                   ^^

This is why you can't use the MT46H32M32LF-6 parameters.  The -75 part is 
slower.  You'll need to plug in the -75 timings from the Micron datasheet 
1gb_ddr_mobile_sdram_t48m.pdf into calc-sdrc-params.c.  Using those 
values, create a new file, sdram-micron-mt46h32m32lf-75.h, for that part, 
and pass in the new SDRAM register structure via omap_init_common_hw() in 
your board-*.c file.


- Paul

Re: Problems bringing up new PM 2.6.29 tree on Logic 35x LV SOM

[Peter Barada]

On Thu, 2009-03-26 at 15:13 -0600, Paul Walmsley wrote:
> On Thu, 26 Mar 2009, Peter Barada wrote:
> 
> > I changed the call to omap_init_common_hw to pass in four NULLs (as I
> > think the sdrc params for mt46h32m32lf6 (somehow?) don't match the
> > mt29c2g24maklajg-75 used on our board. 
>                    ^^
> 
> This is why you can't use the MT46H32M32LF-6 parameters.  The -75 part is 
> slower.  You'll need to plug in the -75 timings from the Micron datasheet 
> 1gb_ddr_mobile_sdram_t48m.pdf into calc-sdrc-params.c.  Using those 
> values, create a new file, sdram-micron-mt46h32m32lf-75.h, for that part, 
> and pass in the new SDRAM register structure via omap_init_common_hw() in 
> your board-*.c file.

Ok, I've gone back and started over from scratch with Kevin's PM branch
(2.6.29).  First I ported u-boot 2009.03 from the beagle u-boot git tree
to my board(using beagle code as a starting point), and I have that
working, copmlete with ethernet, NAND, etc. I also took your sdrc timing
generator, and created a mt29c2g24maklajg-75.h for 2.6.29 that contains
the following structure:

static struct omap_sdrc_params mt29c2g24maklajg_75_sdrc_params[] = {
	[0] = {
		.rate	     = 166000000,
		.actim_ctrla = 0x9b6246c7,
		.actim_ctrlb = 0x00011217,
		.rfr_ctrl    = 0x0004dc01,
		.mr	     = 0x00000032,
	},
	[1] = {
		.rate	     = 165941176,
		.actim_ctrla = 0x9b6246c7,
		.actim_ctrlb = 0x00011217,
		.rfr_ctrl    = 0x0004dc01,
		.mr	     = 0x00000032,
	},
	[2] = {
		.rate	     = 133333333,
		.actim_ctrla = 0x7a99b485,
		.actim_ctrlb = 0x00011213,
		.rfr_ctrl    = 0x0003dd01,
		.mr	     = 0x00000032,
	},
	[3] = {
		.rate	     = 83000000,
		.actim_ctrla = 0x51d12484,
		.actim_ctrlb = 0x0001120c,
		.rfr_ctrl    = 0x00025501,
		.mr	     = 0x00000032,
	},
	[4] = {
		.rate	     = 82970588,
		.actim_ctrla = 0x51d12484,
		.actim_ctrlb = 0x0001120c,
		.rfr_ctrl    = 0x00025501,
		.mr	     = 0x00000032,
	},
	[5] = {
		.rate	     = 66666666,
		.actim_ctrla = 0x414d2243,
		.actim_ctrlb = 0x0001120a,
		.rfr_ctrl    = 0x0001d501,
		.mr	     = 0x00000032,
	},
	[6] = {
		.rate	     = 0
	},
};


And using this(and kernel code based on the beagle configuration), I can
boot up 2.6.29 until it wedges trying to program the twl40930 over I2C.
Using the new u-boot, I see from its output:

Clocking rate (Crystal/DPLL/ARM core): 26.0/332/1000 MHz

Which doesn't look right at all.  Before I go too far, I found in u-boot
that the I2C code in the tree made the assumption that the I2C clock was
based on 12Mhz, and blindly calculated the PSC and SCL values directly
from that instead of looking at I2C_IP_CLK (96Mhz).  I wonder if this is
what's (partially) biting me on the 2.6.29 startup.

Before I dig too deep,

1) Does u-boot, if loaded into ram and started up, setup the clocks from
scratch?  I'm asking since Logic has a primarly bootloader, LoLo, that
sets up the world, then I load/invoke u-boot, which then loads/boots the
kernel.  I can envision the clock setup in LoLo being incorrect, iff
u-boot does not program clocks that are already setup(i.e. if u-boot
reprograms all the clocks, then it shouldn't matter if LoLo set them up
incorrectly).

2) Any ideas why the kernel would think the core is running at 1000Mhz?
Dumping DPLL3


> 
> - Paul
-- 
Peter Barada <peterb@logicpd.com>