Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Pali Rohár]

On Wednesday 06 January 2016 10:55:51 Ivaylo Dimitrov wrote:
> 
> 
> On  6.01.2016 00:49, Tony Lindgren wrote:
> >
> >Suggested fix below, please test and reply with your Tested-by's if
> >it solves the problem so we may still be able to get this into v4.4.
> >
> >Regards,
> >
> >Tony
> >
> >8< ---
> >From: Tony Lindgren 
> >Date: Tue, 5 Jan 2016 12:04:20 -0800
> >Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
> >  corruption
> >
> >Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> >unified the GPMC debug for the SoCs with GPMC. The commit also left
> >out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> >for GPMC to be able to remap GPMC devices out of address 0.
> >
> >Unfortunately on 900, onenand now only partially works with the device
> >tree provided timings. It works enough to get detected but the clock
> >rate supported by the onenand chip gets misdetected. This in turn causes
> >the GPMC timings to be miscalculated and this leads into file system
> >corruption on n900.
> >
> >Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> >write. This is needed also for async timings when we write to onenand
> >with omap2_onenand_set_async_mode(). Without sync write bit set, the
> >async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> >
> >Let's exit with an error if onenand rate is not detected. And let's
> >remove the extra call to omap2_onenand_set_async_mode() as we only
> >need to do this once at the end of omap2_onenand_setup_async().
> >
> >Reported-by: Ivaylo Dimitrov 
> >Signed-off-by: Tony Lindgren 
> >
> >--- a/arch/arm/mach-omap2/gpmc-onenand.c
> >+++ b/arch/arm/mach-omap2/gpmc-onenand.c
> 
> Bellow is gpmc dmesg output with that fix. I also disabled
> CONFIG_OMAP_GPMC_DEBUG and am still able to boot to maemo with no obvious
> problems.
> 
> So, seems that fixes the problem, feel free to  add:
> 
> Tested-by: Ivaylo Dimitrov 

Great! Thank you for fixing and testing this problem!

> 
> Jan  6 10:34:15 Nokia-N900 kernel: [1.373229] omap-gpmc 6e00.gpmc:
> GPMC revision 5.0
> Jan  6 10:34:15 Nokia-N900 kernel: [1.379425] GPMC CS0: cs_on  :   0
> ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.387481] GPMC CS0: cs_rd_off  :
> 14 ticks,  84 ns (was  16 ticks)  84 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.395507] GPMC CS0: cs_wr_off  :
> 19 ticks, 114 ns (was  16 ticks) 114 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.403472] GPMC CS0: adv_on  :
> 0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.411407] GPMC CS0: adv_rd_off
> :   3 ticks,  18 ns (was   2 ticks)  18 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.419342] GPMC CS0: adv_wr_off
> :   3 ticks,  18 ns (was   2 ticks)  18 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.427276] GPMC CS0: oe_on  :   5
> ticks,  30 ns (was   2 ticks)  30 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.435211] GPMC CS0: oe_off  :
> 14 ticks,  84 ns (was  16 ticks)  84 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.443115] GPMC CS0: we_on  :   0
> ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.451110] GPMC CS0: we_off  :
> 14 ticks,  84 ns (was  16 ticks)  84 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.459045] GPMC CS0: rd_cycle  :
> 18 ticks, 108 ns (was  19 ticks) 108 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.467041] GPMC CS0: wr_cycle  :
> 17 ticks, 102 ns (was  19 ticks) 102 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.474975] GPMC CS0: access  :
> 13 ticks,  78 ns (was  15 ticks)  78 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.482879] GPMC CS0:
> page_burst_access:   0 ticks,   0 ns (was   2 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.490814] GPMC CS0: bus_turnaround
> :   0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.498748] GPMC CS0:
> cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.506683] GPMC CS0: wr_data_mux_bus
> :   5 ticks,  30 ns (was   5 ticks)  30 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.514617] GPMC CS0: wr_access  :
> 13 ticks,  78 ns (was  15 ticks)  78 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.522583] GPMC CS0: wait_monitoring
> :   0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.530548] GPMC CS0: clk_activation
> :   0 ticks,   0 ns (was   0 ticks)   0 ns
> Jan  6 10:34:15 Nokia-N900 kernel: [1.538543] GPMC CS0 CLK period is 6
> ns (div 1)
> Jan  6 10:34:15 Nokia-N900 kernel: [1.543334] gpmc cs0 after
> gpmc_cs_set_timings:
> Jan  6 10:34:15 Nokia-N900 kernel: [1.548126] cs0 GPMC_CS_CONFIG1:
> 0xd9001200
> Jan  6 10:34:15 Nokia-N900 kernel: [1.552581] cs0 GPMC_CS_CONFIG2:
> 0x00130e00
> 

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Ivaylo Dimitrov]

On  6.01.2016 00:49, Tony Lindgren wrote:


Suggested fix below, please test and reply with your Tested-by's if
it solves the problem so we may still be able to get this into v4.4.

Regards,

Tony

8< ---
From: Tony Lindgren 
Date: Tue, 5 Jan 2016 12:04:20 -0800
Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
  corruption

Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
unified the GPMC debug for the SoCs with GPMC. The commit also left
out the option for HWMOD_INIT_NO_RESET as we now require proper timings
for GPMC to be able to remap GPMC devices out of address 0.

Unfortunately on 900, onenand now only partially works with the device
tree provided timings. It works enough to get detected but the clock
rate supported by the onenand chip gets misdetected. This in turn causes
the GPMC timings to be miscalculated and this leads into file system
corruption on n900.

Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
write. This is needed also for async timings when we write to onenand
with omap2_onenand_set_async_mode(). Without sync write bit set, the
async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.

Let's exit with an error if onenand rate is not detected. And let's
remove the extra call to omap2_onenand_set_async_mode() as we only
need to do this once at the end of omap2_onenand_setup_async().

Reported-by: Ivaylo Dimitrov 
Signed-off-by: Tony Lindgren 

--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c


Bellow is gpmc dmesg output with that fix. I also disabled 
CONFIG_OMAP_GPMC_DEBUG and am still able to boot to maemo with no 
obvious problems.


So, seems that fixes the problem, feel free to  add:

Tested-by: Ivaylo Dimitrov 


Jan  6 10:34:15 Nokia-N900 kernel: [1.373229] omap-gpmc 
6e00.gpmc: GPMC revision 5.0
Jan  6 10:34:15 Nokia-N900 kernel: [1.379425] GPMC CS0: cs_on 
 :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.387481] GPMC CS0: cs_rd_off 
 :  14 ticks,  84 ns (was  16 ticks)  84 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.395507] GPMC CS0: cs_wr_off 
 :  19 ticks, 114 ns (was  16 ticks) 114 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.403472] GPMC CS0: adv_on 
 :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.411407] GPMC CS0: adv_rd_off 
 :   3 ticks,  18 ns (was   2 ticks)  18 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.419342] GPMC CS0: adv_wr_off 
 :   3 ticks,  18 ns (was   2 ticks)  18 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.427276] GPMC CS0: oe_on 
 :   5 ticks,  30 ns (was   2 ticks)  30 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.435211] GPMC CS0: oe_off 
 :  14 ticks,  84 ns (was  16 ticks)  84 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.443115] GPMC CS0: we_on 
 :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.451110] GPMC CS0: we_off 
 :  14 ticks,  84 ns (was  16 ticks)  84 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.459045] GPMC CS0: rd_cycle 
 :  18 ticks, 108 ns (was  19 ticks) 108 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.467041] GPMC CS0: wr_cycle 
 :  17 ticks, 102 ns (was  19 ticks) 102 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.474975] GPMC CS0: access 
 :  13 ticks,  78 ns (was  15 ticks)  78 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.482879] GPMC CS0: 
page_burst_access:   0 ticks,   0 ns (was   2 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.490814] GPMC CS0: 
bus_turnaround   :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.498748] GPMC CS0: 
cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.506683] GPMC CS0: 
wr_data_mux_bus  :   5 ticks,  30 ns (was   5 ticks)  30 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.514617] GPMC CS0: wr_access 
 :  13 ticks,  78 ns (was  15 ticks)  78 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.522583] GPMC CS0: 
wait_monitoring  :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.530548] GPMC CS0: 
clk_activation   :   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [1.538543] GPMC CS0 CLK period is 
6 ns (div 1)
Jan  6 10:34:15 Nokia-N900 kernel: [1.543334] gpmc cs0 after 
gpmc_cs_set_timings:
Jan  6 10:34:15 Nokia-N900 kernel: [1.548126] cs0 GPMC_CS_CONFIG1: 
0xd9001200
Jan  6 10:34:15 Nokia-N900 kernel: [1.552581] cs0 GPMC_CS_CONFIG2: 
0x00130e00
Jan  6 10:34:15 Nokia-N900 kernel: [1.558837] cs0 GPMC_CS_CONFIG3: 
0x00030300
Jan  6 10:34:15 Nokia-N900 kernel: [1.563323] cs0 GPMC_CS_CONFIG4: 
0x0e000e05
Jan  6 10:34:15 Nokia-N900 kernel: [1.567901] cs0 GPMC_CS_CONFIG5: 
0x000d1112
Jan  6 10:34:15 Nokia-N900 kernel: [1.572357] cs0 

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Sebastian Reichel]

Hi,

On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:
> Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> unified the GPMC debug for the SoCs with GPMC. The commit also left
> out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> for GPMC to be able to remap GPMC devices out of address 0.
> 
> Unfortunately on 900, onenand now only partially works with the device

You may want to change 900 to n900 (maybe even Nokia N900) before
actually committing this.

> tree provided timings. It works enough to get detected but the clock
> rate supported by the onenand chip gets misdetected. This in turn causes
> the GPMC timings to be miscalculated and this leads into file system
> corruption on n900.
> 
> Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> write. This is needed also for async timings when we write to onenand
> with omap2_onenand_set_async_mode(). Without sync write bit set, the
> async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> 
> Let's exit with an error if onenand rate is not detected. And let's
> remove the extra call to omap2_onenand_set_async_mode() as we only
> need to do this once at the end of omap2_onenand_setup_async().
> 
> Reported-by: Ivaylo Dimitrov 
> Signed-off-by: Tony Lindgren 

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Ivaylo Dimitrov]

On  6.01.2016 19:47, Tony Lindgren wrote:

* Sebastian Reichel  [160106 09:41]:

Hi,

On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:

Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
unified the GPMC debug for the SoCs with GPMC. The commit also left
out the option for HWMOD_INIT_NO_RESET as we now require proper timings
for GPMC to be able to remap GPMC devices out of address 0.

Unfortunately on 900, onenand now only partially works with the device


You may want to change 900 to n900 (maybe even Nokia N900) before
actually committing this.


Thanks will do.

Tony




Unfortunately, it seems there is more to be fixed. It booted several 
times to the userspace, but after a couple of shutdowns, rootfs became 
corrupted again. I flashed, installed linux 4.4, but the same happened 
after the first shutdown with 4.4:


<5>[8.159179] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
<3>[8.184631] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node 
type (255 but expected 9)
<3>[8.197937] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node 
at LEB 1934:6936, LEB mapping status 0

<3:[8.216522] Not a node, first 24 bytes:
<3>[8.220520] : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff  

<4>[8.247772] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.0-rc7+ #4
<4>[8.258911] Hardware name: Nokia RX-51 board
<4>[8.268096] [] (unwind_backtrace) from Y] 
(show_stack+0x10/0x14)
<4>[8.281097] [] (show_stack) from [] 
(ubifs_read_node+0x29c/0x2d4)
<4>[8.294097] [] (ubifs_read_node) from [] 
(dbg_old_index_check_init+0x60/0x9c)
<4>[8.308258] [] (dbg_old_index_check_init) from 
[] (ubifs_mount+0xd90/0x15f0)
<4>[8.322357] [] (ubifs_mount) from [] 
(mount_fs+0x70/0x148)
<4>[8.334747] [] (mount_fs) from [] 
(vfs_kern_mount+0x4c/0x110)
<4>[8.347412] [] (vfs_kern_mount) from [] 
(do_mount+0xadc/0xc34)
<4>[8.360168] [] (do_mount) from [] 
(SyS_mount+0x70/0x9c)
<4>[8.372253] [] (SyS_mount) from [] 
(mount_block_root+0xf0/0x28c)
<4>[8.385162] [] (mount_block_root) from [] 
(prepare_namespace+0x88/0x1bc)
<4>[8.398834] [] (prepare_namespace) from [] 
(kernel_init_freeable+0x178/0x1c4)
<4>[8.412963] [] (kernel_init_freeabme) from [] 
(kernel_init+0x8/0xe4)
<4>[8.426300] [] (kernel_init) from [] 
(ret_from_fork+0x14/0x3c)


P.S.
(Pali, sorry for not having time to read the kernel docs re e-mail 
clients :) )

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Sebastian Reichel  [160106 09:41]:
> Hi,
> 
> On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:
> > Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > unified the GPMC debug for the SoCs with GPMC. The commit also left
> > out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> > for GPMC to be able to remap GPMC devices out of address 0.
> > 
> > Unfortunately on 900, onenand now only partially works with the device
> 
> You may want to change 900 to n900 (maybe even Nokia N900) before
> actually committing this.

Thanks will do.

Tony


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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Ivaylo Dimitrov  [160106 10:01]:
> 
> Unfortunately, it seems there is more to be fixed. It booted several times
> to the userspace, but after a couple of shutdowns, rootfs became corrupted
> again. I flashed, installed linux 4.4, but the same happened after the first
> shutdown with 4.4:

Hmm. Care to verify that your onenand really gets detected at 83 MHz like
your earlier logs show? Below is a patch that should show it.

Also, do things now work reliably for you with CONFIG_OMAP_GPMC_DEBUG
enabled? Or does that also produce corruption after few reboots?

Regards,

Tony

8< --
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct 
omap_onenand_platform_data *cfg,
freq = 0;
}
 
+   pr_info("onenand rate detected: %i\n", freq);
+
return freq;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Ivaylo Dimitrov]

Hi,

On  6.01.2016 20:26, Tony Lindgren wrote:



Hmm. Care to verify that your onenand really gets detected at 83 MHz like
your earlier logs show? Below is a patch that should show it.


before the corruption appeared, I looked a couple of times in syslog and 
the freq there was 83MHz. Including after I disabled CONFIG_OMAP_GPMC_DEBUG.




Also, do things now work reliably for you with CONFIG_OMAP_GPMC_DEBUG
enabled? Or does that also produce corruption after few reboots?


CONFIG_OMAP_GPMC_DEBUG is disabled, shall I enable it?


--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct 
omap_onenand_platform_data *cfg,
freq = 0;
}

+   pr_info("onenand rate detected: %i\n", freq);
+
return freq;
  }



Where am I supposed to get the output from ^^^ if rootfs become 
corrupted? The problem appears after poweroff/restart when it is already 
too late to get the syslog.


BTW, did you compare all the GPMC registers with and without 
HWMOD_INIT_NO_RESET?


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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Pali Rohár  [160106 01:06]:
> On Wednesday 06 January 2016 10:55:51 Ivaylo Dimitrov wrote:
> > On  6.01.2016 00:49, Tony Lindgren wrote:
> > >
> > >Suggested fix below, please test and reply with your Tested-by's if
> > >it solves the problem so we may still be able to get this into v4.4.
> > >
> > >8< ---
> > >From: Tony Lindgren 
> > >Date: Tue, 5 Jan 2016 12:04:20 -0800
> > >Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid 
> > >filesystem
> > >  corruption
> > >
> > >Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > >unified the GPMC debug for the SoCs with GPMC. The commit also left
> > >out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> > >for GPMC to be able to remap GPMC devices out of address 0.
> > >
> > >Unfortunately on 900, onenand now only partially works with the device
> > >tree provided timings. It works enough to get detected but the clock
> > >rate supported by the onenand chip gets misdetected. This in turn causes
> > >the GPMC timings to be miscalculated and this leads into file system
> > >corruption on n900.
> > >
> > >Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> > >write. This is needed also for async timings when we write to onenand
> > >with omap2_onenand_set_async_mode(). Without sync write bit set, the
> > >async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> > >
> > >Let's exit with an error if onenand rate is not detected. And let's
> > >remove the extra call to omap2_onenand_set_async_mode() as we only
> > >need to do this once at the end of omap2_onenand_setup_async().
> > >
> > >Reported-by: Ivaylo Dimitrov 
> > >Signed-off-by: Tony Lindgren 
> > >
> > >--- a/arch/arm/mach-omap2/gpmc-onenand.c
> > >+++ b/arch/arm/mach-omap2/gpmc-onenand.c
> > 
> > Bellow is gpmc dmesg output with that fix. I also disabled
> > CONFIG_OMAP_GPMC_DEBUG and am still able to boot to maemo with no obvious
> > problems.
> > 
> > So, seems that fixes the problem, feel free to  add:
> > 
> > Tested-by: Ivaylo Dimitrov 
> 
> Great! Thank you for fixing and testing this problem!

Good to hear it fixes the issue. I'll wait to hear from Aaro before
committing.

Regards,

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Aaro Koskinen]

Hi,

On Tue, Jan 05, 2016 at 02:49:29PM -0800, Tony Lindgren wrote:
> From: Tony Lindgren 
> Date: Tue, 5 Jan 2016 12:04:20 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
>  corruption
> 
> Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> unified the GPMC debug for the SoCs with GPMC. The commit also left
> out the option for HWMOD_INIT_NO_RESET as we now require proper timings
> for GPMC to be able to remap GPMC devices out of address 0.
> 
> Unfortunately on 900, onenand now only partially works with the device
> tree provided timings. It works enough to get detected but the clock
> rate supported by the onenand chip gets misdetected. This in turn causes
> the GPMC timings to be miscalculated and this leads into file system
> corruption on n900.
> 
> Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
> write. This is needed also for async timings when we write to onenand
> with omap2_onenand_set_async_mode(). Without sync write bit set, the
> async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.
> 
> Let's exit with an error if onenand rate is not detected. And let's
> remove the extra call to omap2_onenand_set_async_mode() as we only
> need to do this once at the end of omap2_onenand_setup_async().
> 
> Reported-by: Ivaylo Dimitrov 
> Signed-off-by: Tony Lindgren 

This fixes also the detection issue on N950. Also tested the patch
with N810.

Tested-by: Aaro Koskinen 

A.

> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -149,8 +149,8 @@ static int omap2_onenand_get_freq(struct 
> omap_onenand_platform_data *cfg,
>   freq = 104;
>   break;
>   default:
> - freq = 54;
> - break;
> + pr_err("onenand rate not detected, bad GPMC async timings?\n");
> + freq = 0;
>   }
>  
>   return freq;
> @@ -271,6 +271,11 @@ static int omap2_onenand_setup_async(void __iomem 
> *onenand_base)
>   struct gpmc_timings t;
>   int ret;
>  
> + /*
> +  * Note that we need to keep sync_write set for the call to
> +  * omap2_onenand_set_async_mode() to work to detect the onenand
> +  * supported clock rate for the sync timings.
> +  */
>   if (gpmc_onenand_data->of_node) {
>   gpmc_read_settings_dt(gpmc_onenand_data->of_node,
> _async);
> @@ -281,12 +286,9 @@ static int omap2_onenand_setup_async(void __iomem 
> *onenand_base)
>   else
>   gpmc_onenand_data->flags |= ONENAND_SYNC_READ;
>   onenand_async.sync_read = false;
> - onenand_async.sync_write = false;
>   }
>   }
>  
> - omap2_onenand_set_async_mode(onenand_base);
> -
>   omap2_onenand_calc_async_timings();
>  
>   ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, _async);
> @@ -310,6 +312,8 @@ static int omap2_onenand_setup_sync(void __iomem 
> *onenand_base, int *freq_ptr)
>   if (!freq) {
>   /* Very first call freq is not known */
>   freq = omap2_onenand_get_freq(gpmc_onenand_data, onenand_base);
> + if (!freq)
> + return -ENODEV;
>   set_onenand_cfg(onenand_base);
>   }
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Pali Rohár]

On Monday 04 January 2016 20:13:56 Tony Lindgren wrote:
> * Ivaylo Dimitrov  [160104 10:59]:
> > Hi,
> > 
> > On  4.01.2016 19:40, Tony Lindgren wrote:
> > >>On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> >  >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> >  >dmesg output?
> > 
> > Here it is, including the pre-gpmc log, keep in mind this is with restored
> > HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get dmesg output
> > from the syslog. Don't know if it is helpful :). Also, this device has
> > Numonyx onenand (HW rev. 2204), unlike most of the others which have Samsung
> > onenand (HW rev. 2101 etc), no idea if it is relevant.
> 
> Thanks. I got the problem reproduced here too.
> 
> [1.915557] gpmc cs0 after gpmc_cs_set_timings:
> [1.920410] cs0 GPMC_CS_CONFIG1: 0xfb001201
> 
> Looks like in the failing case the clock rates are not properly
> calculated in GPMC and GPMCFCLKDIVIDER is set wrong in
> GPMC_CS_CONFIG1. Need to look at it more to figure out what's the
> best way to fix this.
> 
> Regards,
> 
> Tony

Hm... Maybe this problem is in U-Boot too?

-- 
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Pali Rohár  [160105 00:50]:
> On Monday 04 January 2016 20:13:56 Tony Lindgren wrote:
> > * Ivaylo Dimitrov  [160104 10:59]:
> > > Hi,
> > > 
> > > On  4.01.2016 19:40, Tony Lindgren wrote:
> > > >>On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> > >  >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> > >  >dmesg output?
> > > 
> > > Here it is, including the pre-gpmc log, keep in mind this is with restored
> > > HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get dmesg 
> > > output
> > > from the syslog. Don't know if it is helpful :). Also, this device has
> > > Numonyx onenand (HW rev. 2204), unlike most of the others which have 
> > > Samsung
> > > onenand (HW rev. 2101 etc), no idea if it is relevant.
> > 
> > Thanks. I got the problem reproduced here too.
> > 
> > [1.915557] gpmc cs0 after gpmc_cs_set_timings:
> > [1.920410] cs0 GPMC_CS_CONFIG1: 0xfb001201
> > 
> > Looks like in the failing case the clock rates are not properly
> > calculated in GPMC and GPMCFCLKDIVIDER is set wrong in
> > GPMC_CS_CONFIG1. Need to look at it more to figure out what's the
> > best way to fix this.
> > 
> > Regards,
> > 
> > Tony
> 
> Hm... Maybe this problem is in U-Boot too?

Yeah maybe. Looks like we need sync write bit set also for async
timings for omap2_onenand_set_async_mode() to work to detect the
onenand rate for sync mode :)

Suggested fix below, please test and reply with your Tested-by's if
it solves the problem so we may still be able to get this into v4.4.

Regards,

Tony

8< ---
From: Tony Lindgren 
Date: Tue, 5 Jan 2016 12:04:20 -0800
Subject: [PATCH] ARM: OMAP2+: Fix onenand rate detection to avoid filesystem
 corruption

Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
unified the GPMC debug for the SoCs with GPMC. The commit also left
out the option for HWMOD_INIT_NO_RESET as we now require proper timings
for GPMC to be able to remap GPMC devices out of address 0.

Unfortunately on 900, onenand now only partially works with the device
tree provided timings. It works enough to get detected but the clock
rate supported by the onenand chip gets misdetected. This in turn causes
the GPMC timings to be miscalculated and this leads into file system
corruption on n900.

Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
write. This is needed also for async timings when we write to onenand
with omap2_onenand_set_async_mode(). Without sync write bit set, the
async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.

Let's exit with an error if onenand rate is not detected. And let's
remove the extra call to omap2_onenand_set_async_mode() as we only
need to do this once at the end of omap2_onenand_setup_async().

Reported-by: Ivaylo Dimitrov 
Signed-off-by: Tony Lindgren 

--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -149,8 +149,8 @@ static int omap2_onenand_get_freq(struct 
omap_onenand_platform_data *cfg,
freq = 104;
break;
default:
-   freq = 54;
-   break;
+   pr_err("onenand rate not detected, bad GPMC async timings?\n");
+   freq = 0;
}
 
return freq;
@@ -271,6 +271,11 @@ static int omap2_onenand_setup_async(void __iomem 
*onenand_base)
struct gpmc_timings t;
int ret;
 
+   /*
+* Note that we need to keep sync_write set for the call to
+* omap2_onenand_set_async_mode() to work to detect the onenand
+* supported clock rate for the sync timings.
+*/
if (gpmc_onenand_data->of_node) {
gpmc_read_settings_dt(gpmc_onenand_data->of_node,
  _async);
@@ -281,12 +286,9 @@ static int omap2_onenand_setup_async(void __iomem 
*onenand_base)
else
gpmc_onenand_data->flags |= ONENAND_SYNC_READ;
onenand_async.sync_read = false;
-   onenand_async.sync_write = false;
}
}
 
-   omap2_onenand_set_async_mode(onenand_base);
-
omap2_onenand_calc_async_timings();
 
ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, _async);
@@ -310,6 +312,8 @@ static int omap2_onenand_setup_sync(void __iomem 
*onenand_base, int *freq_ptr)
if (!freq) {
/* Very first call freq is not known */
freq = omap2_onenand_get_freq(gpmc_onenand_data, onenand_base);
+   if (!freq)
+   return -ENODEV;
set_onenand_cfg(onenand_base);
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Ivaylo Dimitrov]

Hi,

On  4.01.2016 19:40, Tony Lindgren wrote:

On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:

> >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> >dmesg output?


Here it is, including the pre-gpmc log, keep in mind this is with 
restored HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get 
dmesg output from the syslog. Don't know if it is helpful :). Also, this 
device has Numonyx onenand (HW rev. 2204), unlike most of the others 
which have Samsung onenand (HW rev. 2101 etc), no idea if it is relevant.


Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Booting Linux on 
physical CPU 0x0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Initializing cgroup 
subsys cpu
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Linux version 
4.4.0-rc7+ (ivo@ivo-H81M-S2PV) (gcc version 4.7.2 20120701 (prerelease) 
(Linaro GCC 4.7-2012.07) ) #4 PREEMPT Mon Jan 4 20:30:31 EET 2016
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: ARMv7 Processor 
[411fc083] revision 3 (ARMv7), cr=10c5387d
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: PIPT / VIPT 
nonaliasing data cache, VIPT nonaliasing instruction cache

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Machine model: Nokia N900
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Memory policy: Data 
cache writeback
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] On node 0 totalpages: 
65280
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] free_area_init_node: 
node 0, pgdat c06776f8, node_mem_map cfcf9000
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 512 
pages used for memmap
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 0 pages 
reserved
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 65280 
pages, LIFO batch:15
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: All CPU(s) 
started in SVC mode.
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] OMAP3430/3530 ES3.1 
(l2cache iva sgx neon isp )
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pcpu-alloc: s0 r0 
d32768 u32768 alloc=1*32768

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pcpu-alloc: [0] 0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Built 1 zonelists in 
Zone order, mobility grouping on.  Total pages: 64768
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Kernel command line: 
init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs 
rootflags=bulk_read,no_chk_data_crc rw mtdoops.mtddev=log console=tty0 
console=ttyO2 omapfb_vram=7M omapfb.mode=lcd:848x480-16 nokia-modem.pm=0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] PID hash table 
entries: 1024 (order: 0, 4096 bytes)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Dentry cache hash 
table entries: 32768 (order: 5, 131072 bytes)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Inode-cache hash table 
entries: 16384 (order: 4, 65536 bytes)
Jan  4 20:42:50 Nokia-N900 cellular: csd[1026]: com.nokia.phone.SIM: 
csd-libsimpb::configure: args=<(null)>
Jan  4 20:42:50 Nokia-N900 cellular: csd[1026]: Succesfully loaded 
plugin 
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Memory: 
251588K/261120K available (4487K kernel code, 232K rwdata, 1624K rodata, 
244K init, 256K bss, 9532K reserved, 0K cma-reserved, 0K highmem)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Virtual kernel memory 
layout:
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] vector  : 
0x - 0x1000   (   4 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] fixmap  : 
0xffc0 - 0xfff0   (3072 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] vmalloc : 
0xd080 - 0xff80   ( 752 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] lowmem  : 
0xc000 - 0xd000   ( 256 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pkmap   : 
0xbfe0 - 0xc000   (   2 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] modules : 
0xbf00 - 0xbfe0   (  14 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .text : 
0xc0008000 - 0xc0600044   (6113 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .init : 
0xc0601000 - 0xc063e000   ( 244 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .data : 
0xc063e000 - 0xc0678240   ( 233 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00].bss : 
0xc0678240 - 0xc06b8628   ( 257 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] SLUB: HWalign=64, 
Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Preemptible 
hierarchical RCU implementation.
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] ^IBuild-time 
adjustment of leaf fanout to 32.

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] NR_IRQS:16 nr_irqs:16 16
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] IRQ: Found an INTC at 
0xfa20 (revision 4.0) with 96 interrupts
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Clocking rate 
(Crystal/Core/MPU): 19.2/332/500 MHz
Jan  4 20:42:50 Nokia-N900 

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Ivaylo Dimitrov  [160104 10:59]:
> Hi,
> 
> On  4.01.2016 19:40, Tony Lindgren wrote:
> >>On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
>  >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
>  >dmesg output?
> 
> Here it is, including the pre-gpmc log, keep in mind this is with restored
> HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get dmesg output
> from the syslog. Don't know if it is helpful :). Also, this device has
> Numonyx onenand (HW rev. 2204), unlike most of the others which have Samsung
> onenand (HW rev. 2101 etc), no idea if it is relevant.

Thanks. I got the problem reproduced here too.

[1.915557] gpmc cs0 after gpmc_cs_set_timings:
[1.920410] cs0 GPMC_CS_CONFIG1: 0xfb001201

Looks like in the failing case the clock rates are not properly
calculated in GPMC and GPMCFCLKDIVIDER is set wrong in
GPMC_CS_CONFIG1. Need to look at it more to figure out what's the
best way to fix this.

Regards,

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Pali Rohár  [160104 09:35]:
> On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> > Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> > dmesg output?
> 
> Hi Tony. We do not have serial console for N900 and so when kernel is 
> not fully bootable to userspace we cannot provide dmesg for you :-(

OK

> Maybe something with simple initramfs could work, but really if you have 
> serial console for N900 it should be for you lot of easier to get it.

Yeah OK will take a look ASAP. Is this happening with both legacy
booting and dts based booting?

For testing, CONFIG_INITRAMFS_SOURCE etc allow building initramfs
that's appended to the kernel.

Regards,

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Pali Rohár]

On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> dmesg output?

Hi Tony. We do not have serial console for N900 and so when kernel is 
not fully bootable to userspace we cannot provide dmesg for you :-(

Maybe something with simple initramfs could work, but really if you have 
serial console for N900 it should be for you lot of easier to get it.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Ivaylo Dimitrov  [160101 03:29]:
> Hi Tony,
> 
> On 21.05.2015 00:21, Tony Lindgren wrote:
> >We support decoding the bootloader values if DEBUG is defined.
> >But we also need to change the struct omap_hwmod flags to have
> >HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
> >boot. Otherwise just the default timings will be displayed
> >instead of the bootloader configured timings.
> >
> >This also allows us to clean up the various GPMC related
> >hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
> >and HWMOD_INIT_NO_IDLE is not needed.
> >
> >Cc: Brian Hutchinson 
> >Cc: Paul Walmsley 
> >Cc: Roger Quadros 
> >Signed-off-by: Tony Lindgren 
> >---
> >  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
> >  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
> >  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
> >  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
> >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
> >  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
> >  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
> >  drivers/memory/Kconfig  |  8 
> >  drivers/memory/omap-gpmc.c  |  6 +++---
> >  9 files changed, 29 insertions(+), 35 deletions(-)
> >
> 
> 1. Happy new year :)

Same to you :)

> 2. It was a while I tested upstream on N900 but I had some spare time during
> the holidays to play, so I tried to boot 4.4-rc6 with Maemo 5. To my
> surprise, after that try, Maemo 5 rootfs, which is located on onenand became
> irreversibly corrupted. I bisected the tree to the $subject commit and after
> restoring HWMOD_INIT_NO_RESET in omap3xxx_gpmc_hwmod flags, the problem was
> solved. It seems that GPMC is either incorrectly or incompletely setup by
> the kernel, leading to failed onenand reads/writes and whatnot.
> Unfortunately, what I have here is a release device, so I am unable to
> capture any logs through the serial port. BTW keep in mind that rootfs
> corruption happens as soon as a boot is attempted, even after a freshly
> flashed rootfs.

Oh crap, sorry to hear that :(

Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related dmesg
output? The dmesg timings with CONFIG_OMAP_GPMC_DEBUG enabled should be
compared against omap3-n900.dts gpmc timings. And if you don't see the whole
dmesg after booting, you may need to also increase CONFIG_LOG_BUF_SHIFT.
Meanwhile, I'll try to also produce it here.

Chances are we have bad or incomplete timings in the n900 :(

Regards,

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Ivaylo Dimitrov]

Hi Tony,

On 21.05.2015 00:21, Tony Lindgren wrote:

We support decoding the bootloader values if DEBUG is defined.
But we also need to change the struct omap_hwmod flags to have
HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
boot. Otherwise just the default timings will be displayed
instead of the bootloader configured timings.

This also allows us to clean up the various GPMC related
hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
and HWMOD_INIT_NO_IDLE is not needed.

Cc: Brian Hutchinson 
Cc: Paul Walmsley 
Cc: Roger Quadros 
Signed-off-by: Tony Lindgren 
---
  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
  drivers/memory/Kconfig  |  8 
  drivers/memory/omap-gpmc.c  |  6 +++---
  9 files changed, 29 insertions(+), 35 deletions(-)



1. Happy new year :)

2. It was a while I tested upstream on N900 but I had some spare time 
during the holidays to play, so I tried to boot 4.4-rc6 with Maemo 5. To 
my surprise, after that try, Maemo 5 rootfs, which is located on onenand 
became irreversibly corrupted. I bisected the tree to the $subject 
commit and after restoring HWMOD_INIT_NO_RESET in omap3xxx_gpmc_hwmod 
flags, the problem was solved. It seems that GPMC is either incorrectly 
or incompletely setup by the kernel, leading to failed onenand 
reads/writes and whatnot. Unfortunately, what I have here is a release 
device, so I am unable to capture any logs through the serial port. BTW 
keep in mind that rootfs corruption happens as soon as a boot is 
attempted, even after a freshly flashed rootfs.


Please advice on how to proceed.

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

Re: Antwort: Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Roger Quadros]

On 01/09/15 16:31, Hannes Schmelzer wrote:
>> Hi Hannes,
> Hi Roger,
> 
>>
>> On 27/08/15 08:52, Hannes Schmelzer wrote:
>>> Hi Tony,
>>>
>>> Did anyone test this changeset on some AM335x board?
>>>
>>> Today I ran into trouble with that because:
>>>
>>> The GPMC controller gets reseted on kernel boot due to the 
> missing/removed 
>> HWMOD_INIT_NO_RESET flag.
>>>
>>> Primary this should not be a big problem, but on my board (maybe on 
> all 
>> AM335x) the GPMC doesn't behave as described in TRM.
>>> Especially the GPMC_CONFIG register is not reset to 0h after reset, 
> instead 
>> it holds the value 0xa00 which is very strange because bit 10-31 are 
> reserved.
>>>
>>> Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly 
> this 
>> causes my system to stall on first access the connected NAND flash 
> because it 
>> never becomes ready due to the wrong wait pin polarity. Maybe others 
> dont't 
>> run into trouble because they may use WAIT0PIN, which one has it's old 
> polarity.
>>
>> So nand ready/busy pin is connected to waitpin1 through an inverter on 
> your board?
>>
>> On am335x-evm we use waitpin0. Nand ready/busy is directly connected to 
> waitpin0.
> 
> No there is no inverter between flash and AM335x, the READY_nBUSY line is 
> directly connected to waitpin1.
> But your sentence brings some good idea to me, i will try to solder some 
> inverter into the READY_nBUSY line on my board and see if the problem 
> appears again.

Please don't do that. We want to maintain the NAND ready/busy# logic as it is.

> If i'm right in my theory that the value 0xa00 in GPMC_CONFIG register is 
> the problem, the inverter would solve it.

You really need to disable read/write monitoring in gpmc-settings.

> 
> You're right am335x-evm uses waitpin0, which one is not affected from this 
> "bug".

Why is it not affected by this bug? The polarities are same for am335x-evm and
your board. Only the wait pin is different.

> I have to use waitpin1, because i also have a 2nd ethernet interface 
> connected, and there is waitpin0 uses for collission detect signal from 
> the phy (other pinmux).
> 
>> For NAND operation read/write wait monitoring must be disabled.
>> The nand driver uses the WAIT pin purely for Read/Busy signalling.
>> Unfortunately the existing driver cannot handle anything other than 
> waitpin 0 
>> for nand for DT boot.
> for sure ? have a look to omap-gpmc.c at line #90.
> Here i can see that either can be used.

Which tree are you referring to?

> 
>>
>> I've tried to address this issue here
>> http://thread.gmane.org/gmane.linux.drivers.devicetree/131076
> This is useful if the READY_nBUSY line cannot be connected to the GPMC 
> itself, instead it maybe connected to some other gpio.
> But it doesn't solve the problem.

It does. We are adding gpiolib and interrupt controller support for all
the wait pins.

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Roger Quadros]

Hi Hannes,

On 27/08/15 08:52, Hannes Schmelzer wrote:
> Hi Tony,
> 
> Did anyone test this changeset on some AM335x board?
> 
> Today I ran into trouble with that because:
> 
> The GPMC controller gets reseted on kernel boot due to the missing/removed 
> HWMOD_INIT_NO_RESET flag.
> 
> Primary this should not be a big problem, but on my board (maybe on all 
> AM335x) the GPMC doesn't behave as described in TRM.
> Especially the GPMC_CONFIG register is not reset to 0h after reset, instead 
> it holds the value 0xa00 which is very strange because bit 10-31 are reserved.
> 
> Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly this 
> causes my system to stall on first access the connected NAND flash because it 
> never becomes ready due to the wrong wait pin polarity. Maybe others dont't 
> run into trouble because they may use WAIT0PIN, which one has it's old 
> polarity.

So nand ready/busy pin is connected to waitpin1 through an inverter on your 
board?

On am335x-evm we use waitpin0. Nand ready/busy is directly connected to 
waitpin0.

For NAND operation read/write wait monitoring must be disabled.
The nand driver uses the WAIT pin purely for Read/Busy signalling.
Unfortunately the existing driver cannot handle anything other than waitpin 0 
for nand for DT boot.

I've tried to address this issue here
http://thread.gmane.org/gmane.linux.drivers.devicetree/131076

cheers,
-roger

> 
> First approach was simply to write 0x0 to the GPMC_CONFIG register during 
> gpmc_probe function.
> It solves the problem.
> 
> I also tried to issue some SYSRESET through GPMC registers without success, 
> same strange behavior.
> 
> What’s your thinking around that?
> 
> Best regards,
> Hannes
> 
> 
> linux-omap-ow...@vger.kernel.org schrieb am 20.05.2015 23:21:03:
> 
>> Von: Tony Lindgren 
>> An: linux-omap@vger.kernel.org
>> Kopie: linux-arm-ker...@lists.infradead.org, Brian Hutchinson
>> , Paul Walmsley , Roger Quadros 
>> 
>> Datum: 20.05.2015 23:37
>> Betreff: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
>> Gesendet von: linux-omap-ow...@vger.kernel.org
>>
>> We support decoding the bootloader values if DEBUG is defined.
>> But we also need to change the struct omap_hwmod flags to have
>> HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
>> boot. Otherwise just the default timings will be displayed
>> instead of the bootloader configured timings.
>>
>> This also allows us to clean up the various GPMC related
>> hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
>> and HWMOD_INIT_NO_IDLE is not needed.
>>
>> Cc: Brian Hutchinson 
>> Cc: Paul Walmsley 
>> Cc: Roger Quadros 
>> Signed-off-by: Tony Lindgren 
>> ---
>>  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
>>  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
>>  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
>>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
>>  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
>>  drivers/memory/Kconfig  |  8 
>>  drivers/memory/omap-gpmc.c  |  6 +++---
>>  9 files changed, 29 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.h 
>> b/arch/arm/mach-omap2/omap_hwmod.h
>> index 9611c91..b5d27ec 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.h
>> +++ b/arch/arm/mach-omap2/omap_hwmod.h
>> @@ -109,6 +109,12 @@ extern struct omap_hwmod_sysc_fields 
>> omap_hwmod_sysc_type3;
>>  
>>  #define DEBUG_OMAPUART_FLAGS   (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET)
>>  
>> +#ifdef CONFIG_OMAP_GPMC_DEBUG
>> +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS   HWMOD_INIT_NO_RESET
>> +#else
>> +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS   0
>> +#endif
>> +
>>  #if defined(CONFIG_DEBUG_OMAP2UART1)
>>  #undef DEBUG_OMAP2UART1_FLAGS
>>  #define DEBUG_OMAP2UART1_FLAGS DEBUG_OMAPUART_FLAGS
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/
>> mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> index 8821b9d..6dcfd03 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> @@ -762,16 +762,8 @@ struct omap_hwmod omap2xxx_gpmc_hwmod = {
>> .name  = "gpmc",
>> .class  = _gpmc_hwmod_class,
>> .main_clk   = "gpmc_fck",
>> -   /*
>> -* XXX HWMOD_INIT_NO_RESET should not be needed for this IP
>> -* block.  It is not being added due to any known bugs with
>> -* resetting the GPMC IP block, but rather because any timings
>> -* set by the bootloader are not being correctly programmed by
>> -* the kernel from the 

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Roger Quadros]

Hi Hannes,

On 27/08/15 08:52, Hannes Schmelzer wrote:
> Hi Tony,
> 
> Did anyone test this changeset on some AM335x board?
> 
> Today I ran into trouble with that because:
> 
> The GPMC controller gets reseted on kernel boot due to the missing/removed 
> HWMOD_INIT_NO_RESET flag.
> 
> Primary this should not be a big problem, but on my board (maybe on all 
> AM335x) the GPMC doesn't behave as described in TRM.
> Especially the GPMC_CONFIG register is not reset to 0h after reset, instead 
> it holds the value 0xa00 which is very strange because bit 10-31 are reserved.
> 
> Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly this 
> causes my system to stall on first access the connected NAND flash because it 
> never becomes ready due to the wrong wait pin polarity. Maybe others dont't 
> run into trouble because they may use WAIT0PIN, which one has it's old 
> polarity.

So nand ready/busy pin is connected to waitpin1 through an inverter on your 
board?

On am335x-evm we use waitpin0. Nand ready/busy is directly connected to 
waitpin0.

For NAND operation read/write wait monitoring must be disabled.
The nand driver uses the WAIT pin purely for Read/Busy signalling.
Unfortunately the existing driver cannot handle anything other than waitpin 0 
for nand for DT boot.

I've tried to address this issue here
http://thread.gmane.org/gmane.linux.drivers.devicetree/131076

cheers,
-roger

> 
> First approach was simply to write 0x0 to the GPMC_CONFIG register during 
> gpmc_probe function.
> It solves the problem.
> 
> I also tried to issue some SYSRESET through GPMC registers without success, 
> same strange behavior.
> 
> What’s your thinking around that?
> 
> Best regards,
> Hannes
> 
> 
> linux-omap-ow...@vger.kernel.org schrieb am 20.05.2015 23:21:03:
> 
>> Von: Tony Lindgren 
>> An: linux-omap@vger.kernel.org
>> Kopie: linux-arm-ker...@lists.infradead.org, Brian Hutchinson
>> , Paul Walmsley , Roger Quadros 
>> 
>> Datum: 20.05.2015 23:37
>> Betreff: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
>> Gesendet von: linux-omap-ow...@vger.kernel.org
>>
>> We support decoding the bootloader values if DEBUG is defined.
>> But we also need to change the struct omap_hwmod flags to have
>> HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
>> boot. Otherwise just the default timings will be displayed
>> instead of the bootloader configured timings.
>>
>> This also allows us to clean up the various GPMC related
>> hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
>> and HWMOD_INIT_NO_IDLE is not needed.
>>
>> Cc: Brian Hutchinson 
>> Cc: Paul Walmsley 
>> Cc: Roger Quadros 
>> Signed-off-by: Tony Lindgren 
>> ---
>>  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
>>  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
>>  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
>>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
>>  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
>>  drivers/memory/Kconfig  |  8 
>>  drivers/memory/omap-gpmc.c  |  6 +++---
>>  9 files changed, 29 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.h 
>> b/arch/arm/mach-omap2/omap_hwmod.h
>> index 9611c91..b5d27ec 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.h
>> +++ b/arch/arm/mach-omap2/omap_hwmod.h
>> @@ -109,6 +109,12 @@ extern struct omap_hwmod_sysc_fields 
>> omap_hwmod_sysc_type3;
>>  
>>  #define DEBUG_OMAPUART_FLAGS   (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET)
>>  
>> +#ifdef CONFIG_OMAP_GPMC_DEBUG
>> +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS   HWMOD_INIT_NO_RESET
>> +#else
>> +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS   0
>> +#endif
>> +
>>  #if defined(CONFIG_DEBUG_OMAP2UART1)
>>  #undef DEBUG_OMAP2UART1_FLAGS
>>  #define DEBUG_OMAP2UART1_FLAGS DEBUG_OMAPUART_FLAGS
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/
>> mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> index 8821b9d..6dcfd03 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
>> @@ -762,16 +762,8 @@ struct omap_hwmod omap2xxx_gpmc_hwmod = {
>> .name  = "gpmc",
>> .class  = _gpmc_hwmod_class,
>> .main_clk   = "gpmc_fck",
>> -   /*
>> -* XXX HWMOD_INIT_NO_RESET should not be needed for this IP
>> -* block.  It is not being added due to any known bugs with
>> -* resetting the GPMC IP block, but rather because any timings
>> -* set by the bootloader are not being correctly programmed by
>> -* the kernel from the 

Antwort: Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Hannes Schmelzer]

> Hi Hannes,
Hi Roger,

> 
> On 27/08/15 08:52, Hannes Schmelzer wrote:
> > Hi Tony,
> > 
> > Did anyone test this changeset on some AM335x board?
> > 
> > Today I ran into trouble with that because:
> > 
> > The GPMC controller gets reseted on kernel boot due to the 
missing/removed 
> HWMOD_INIT_NO_RESET flag.
> > 
> > Primary this should not be a big problem, but on my board (maybe on 
all 
> AM335x) the GPMC doesn't behave as described in TRM.
> > Especially the GPMC_CONFIG register is not reset to 0h after reset, 
instead 
> it holds the value 0xa00 which is very strange because bit 10-31 are 
reserved.
> > 
> > Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly 
this 
> causes my system to stall on first access the connected NAND flash 
because it 
> never becomes ready due to the wrong wait pin polarity. Maybe others 
dont't 
> run into trouble because they may use WAIT0PIN, which one has it's old 
polarity.
> 
> So nand ready/busy pin is connected to waitpin1 through an inverter on 
your board?
> 
> On am335x-evm we use waitpin0. Nand ready/busy is directly connected to 
waitpin0.

No there is no inverter between flash and AM335x, the READY_nBUSY line is 
directly connected to waitpin1.
But your sentence brings some good idea to me, i will try to solder some 
inverter into the READY_nBUSY line on my board and see if the problem 
appears again.
If i'm right in my theory that the value 0xa00 in GPMC_CONFIG register is 
the problem, the inverter would solve it.

You're right am335x-evm uses waitpin0, which one is not affected from this 
"bug".
I have to use waitpin1, because i also have a 2nd ethernet interface 
connected, and there is waitpin0 uses for collission detect signal from 
the phy (other pinmux).

> For NAND operation read/write wait monitoring must be disabled.
> The nand driver uses the WAIT pin purely for Read/Busy signalling.
> Unfortunately the existing driver cannot handle anything other than 
waitpin 0 
> for nand for DT boot.
for sure ? have a look to omap-gpmc.c at line #90.
Here i can see that either can be used.

> 
> I've tried to address this issue here
> http://thread.gmane.org/gmane.linux.drivers.devicetree/131076
This is useful if the READY_nBUSY line cannot be connected to the GPMC 
itself, instead it maybe connected to some other gpio.
But it doesn't solve the problem.

> 
> cheers,
> -roger
best regards,
Hannes



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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

Hi,

* Hannes Schmelzer hannes.schmel...@br-automation.com [150826 22:55]:
 Hi Tony,
 
 Did anyone test this changeset on some AM335x board?

Apparently not if it does not work or else you somehow have a different
configuration for GPMC.
 
 Today I ran into trouble with that because:
 
 The GPMC controller gets reseted on kernel boot due to the missing/removed 
 HWMOD_INIT_NO_RESET flag.

Oh so you mean it only works on am335x if CONFIG_OMAP_GPMC_DEBUG is set?
 
 Primary this should not be a big problem, but on my board (maybe on all 
 AM335x) the GPMC doesn't behave as described in TRM.
 Especially the GPMC_CONFIG register is not reset to 0h after reset, 
 instead it holds the value 0xa00 which is very strange because bit 10-31 
 are reserved.
 
 Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly this 
 causes my system to stall on first access the connected NAND flash because 
 it never becomes ready due to the wrong wait pin polarity. Maybe others 
 dont't run into trouble because they may use WAIT0PIN, which one has it's 
 old polarity.
 
 First approach was simply to write 0x0 to the GPMC_CONFIG register during 
 gpmc_probe function.
 It solves the problem.

OK
 
 I also tried to issue some SYSRESET through GPMC registers without 
 success, same strange behavior.

Interesting, never heard of that one before.
 
 What?s your thinking around that?

We could add a custom hwmod reset function that sets GPMC_CONFIG to 0.
Similar to omap_i2c_reset() is set up. Or we could set up a property for
the wait pin polarity. Roger, got any better ideas?

Regards,

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

Re: Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Hannes Schmelzer]

 
 Hi,
Hi,

 
 * Hannes Schmelzer hannes.schmel...@br-automation.com [150826 22:55]:
  Hi Tony,
  
  Did anyone test this changeset on some AM335x board?
 
 Apparently not if it does not work or else you somehow have a different
 configuration for GPMC.
 
  Today I ran into trouble with that because:
  
  The GPMC controller gets reseted on kernel boot due to the 
missing/removed 
  HWMOD_INIT_NO_RESET flag.
 
 Oh so you mean it only works on am335x if CONFIG_OMAP_GPMC_DEBUG is set?
Exactly.

 
  I also tried to issue some SYSRESET through GPMC registers without 
  success, same strange behavior.
 
 Interesting, never heard of that one before.

Unfortunately i only have my BR hardware to test,
maybe somebody else has an am335x board with NAND flash on it and can 
test.


  What?s your thinking around that?
 
 We could add a custom hwmod reset function that sets GPMC_CONFIG to 0.
 Similar to omap_i2c_reset() is set up. 
This would be possible, but we've to take care that such functions isn't 
called during the new introduced debug-case.


 Or we could set up a property for
 the wait pin polarity. Roger, got any better ideas?

In general, it would be a good idea to introduce a dt-property to control 
the polarity of the wait pins, since there is allready a property to 
select the wait pin - this would make the thing complete.

 
 Regards,
 Tony

best regards,
Hannes



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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Hannes Schmelzer]

Hi Tony,

Did anyone test this changeset on some AM335x board?

Today I ran into trouble with that because:

The GPMC controller gets reseted on kernel boot due to the missing/removed 
HWMOD_INIT_NO_RESET flag.

Primary this should not be a big problem, but on my board (maybe on all 
AM335x) the GPMC doesn't behave as described in TRM.
Especially the GPMC_CONFIG register is not reset to 0h after reset, 
instead it holds the value 0xa00 which is very strange because bit 10-31 
are reserved.

Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly this 
causes my system to stall on first access the connected NAND flash because 
it never becomes ready due to the wrong wait pin polarity. Maybe others 
dont't run into trouble because they may use WAIT0PIN, which one has it's 
old polarity.

First approach was simply to write 0x0 to the GPMC_CONFIG register during 
gpmc_probe function.
It solves the problem.

I also tried to issue some SYSRESET through GPMC registers without 
success, same strange behavior.

What?s your thinking around that?

Best regards,
Hannes

linux-omap-ow...@vger.kernel.org schrieb am 20.05.2015 23:21:03:

 Von: Tony Lindgren t...@atomide.com
 An: linux-omap@vger.kernel.org
 Kopie: linux-arm-ker...@lists.infradead.org, Brian Hutchinson 
 b.hutch...@gmail.com, Paul Walmsley p...@pwsan.com, Roger Quadros 
rog...@ti.com
 Datum: 20.05.2015 23:37
 Betreff: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
 Gesendet von: linux-omap-ow...@vger.kernel.org
 
 We support decoding the bootloader values if DEBUG is defined.
 But we also need to change the struct omap_hwmod flags to have
 HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
 boot. Otherwise just the default timings will be displayed
 instead of the bootloader configured timings.
 
 This also allows us to clean up the various GPMC related
 hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
 and HWMOD_INIT_NO_IDLE is not needed.
 
 Cc: Brian Hutchinson b.hutch...@gmail.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Roger Quadros rog...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 
++--
  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 
++--
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 
++-
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
  drivers/memory/Kconfig  |  8 
  drivers/memory/omap-gpmc.c  |  6 +++---
  9 files changed, 29 insertions(+), 35 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod.h 
b/arch/arm/mach-omap2/omap_hwmod.h
 index 9611c91..b5d27ec 100644
 --- a/arch/arm/mach-omap2/omap_hwmod.h
 +++ b/arch/arm/mach-omap2/omap_hwmod.h
 @@ -109,6 +109,12 @@ extern struct omap_hwmod_sysc_fields 
omap_hwmod_sysc_type3;
 
  #define DEBUG_OMAPUART_FLAGS   (HWMOD_INIT_NO_IDLE | 
HWMOD_INIT_NO_RESET)
 
 +#ifdef CONFIG_OMAP_GPMC_DEBUG
 +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS   HWMOD_INIT_NO_RESET
 +#else
 +#define DEBUG_OMAP_GPMC_HWMOD_FLAGS   0
 +#endif
 +
  #if defined(CONFIG_DEBUG_OMAP2UART1)
  #undef DEBUG_OMAP2UART1_FLAGS
  #define DEBUG_OMAP2UART1_FLAGS DEBUG_OMAPUART_FLAGS
 diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/
 mach-omap2/omap_hwmod_2xxx_ipblock_data.c
 index 8821b9d..6dcfd03 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
 @@ -762,16 +762,8 @@ struct omap_hwmod omap2xxx_gpmc_hwmod = {
 .name  = gpmc,
 .class  = omap2xxx_gpmc_hwmod_class,
 .main_clk   = gpmc_fck,
 -   /*
 -* XXX HWMOD_INIT_NO_RESET should not be needed for this IP
 -* block.  It is not being added due to any known bugs with
 -* resetting the GPMC IP block, but rather because any timings
 -* set by the bootloader are not being correctly programmed by
 -* the kernel from the board file or DT data.
 -* HWMOD_INIT_NO_RESET should be removed ASAP.
 -*/
 -   .flags  = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
 -HWMOD_NO_IDLEST),
 +   /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
 +   .flags  = HWMOD_NO_IDLEST | DEBUG_OMAP_GPMC_HWMOD_FLAGS,
 .prcm  = {
.omap2   = {
   .prcm_reg_id = 3,
 diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c 
b/arch/
 arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
 index cabc569..ae0cb67 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
 @@ -668,7 +668,8 @@ struct omap_hwmod am33xx_gpmc_hwmod = {
 .name  = gpmc,
 .class  = 

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [150520 15:52]:
 On Wed, 20 May 2015, Tony Lindgren wrote:
 
  We support decoding the bootloader values if DEBUG is defined.
  But we also need to change the struct omap_hwmod flags to have
  HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
  boot. Otherwise just the default timings will be displayed
  instead of the bootloader configured timings.
  
  This also allows us to clean up the various GPMC related
  hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
  and HWMOD_INIT_NO_IDLE is not needed.
  
  Cc: Brian Hutchinson b.hutch...@gmail.com
  Cc: Paul Walmsley p...@pwsan.com
  Cc: Roger Quadros rog...@ti.com
  Signed-off-by: Tony Lindgren t...@atomide.com
 
 Looks good to me, want me to queue it or do you want to?

Feel free to take it if it looks OK to you, I'll just queue
the first patch then. Roger may have other GPMC patches
coming up, but this should not conflict with them, there's
more of a hwmod conflict chance.

Regards,

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Paul Walmsley]

On Wed, 20 May 2015, Tony Lindgren wrote:

 We support decoding the bootloader values if DEBUG is defined.
 But we also need to change the struct omap_hwmod flags to have
 HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
 boot. Otherwise just the default timings will be displayed
 instead of the bootloader configured timings.
 
 This also allows us to clean up the various GPMC related
 hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
 and HWMOD_INIT_NO_IDLE is not needed.
 
 Cc: Brian Hutchinson b.hutch...@gmail.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Roger Quadros rog...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com

Looks good to me, want me to queue it or do you want to?


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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Paul Walmsley]

On Wed, 20 May 2015, Tony Lindgren wrote:

 * Paul Walmsley p...@pwsan.com [150520 15:52]:
  On Wed, 20 May 2015, Tony Lindgren wrote:
  
   We support decoding the bootloader values if DEBUG is defined.
   But we also need to change the struct omap_hwmod flags to have
   HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
   boot. Otherwise just the default timings will be displayed
   instead of the bootloader configured timings.
   
   This also allows us to clean up the various GPMC related
   hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
   and HWMOD_INIT_NO_IDLE is not needed.
   
   Cc: Brian Hutchinson b.hutch...@gmail.com
   Cc: Paul Walmsley p...@pwsan.com
   Cc: Roger Quadros rog...@ti.com
   Signed-off-by: Tony Lindgren t...@atomide.com
  
  Looks good to me, want me to queue it or do you want to?
 
 Feel free to take it if it looks OK to you, I'll just queue
 the first patch then. Roger may have other GPMC patches
 coming up, but this should not conflict with them, there's
 more of a hwmod conflict chance.

OK thanks queued for v4.2.

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