omap gpmc changes for parsing devices and working debug

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 <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Roger Quadros <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Quoted 10 lines · Tony Lindgren

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.

Quoted 4 lines

Cc Brian Hutchinson <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Roger Quadros <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

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

Quoted 17 lines · Paul Walmsley

Quoted 14 lines · Tony Lindgren

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 <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Roger Quadros <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Quoted 1 line

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.

Von: Tony Lindgren <[email protected]>
An: linux-omap at vger.kernel.org
Kopie: linux-arm-kernel at lists.infradead.org, Brian Hutchinson <[email protected]>, Paul Walmsley <[email protected]>, Roger Quadros

Datum: 20.05.2015 23:37
Betreff: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug Gesendet von: linux-omap-owner at 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 <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Roger Quadros <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 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 

drivers/memory/omap-gpmc.c +1 -1

              GPMC_CONFIG1_CLKACTIVATIONTIME_MAX,
              clk_activation, GPMC_CD_FCLK);
 
-#ifdef DEBUG
+#ifdef CONFIG_OMAP_GPMC_DEBUG
    pr_info("GPMC CS%d CLK period is %lu ns (div %d)\n",
          cs, (div * gpmc_get_fclk_period()) / 1000, div);
 #endif

Signature · 6 lines

2.1.4

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

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?

Hi,

Quoted 3 lines

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.

Quoted 3 lines

Today I ran into trouble with that because:

The GPMC controller gets reseted on kernel boot due to the

Quoted 1 line

HWMOD_INIT_NO_RESET flag.

Oh so you mean it only works on am335x if CONFIG_OMAP_GPMC_DEBUG is set?

Quoted 3 lines

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

Interesting, never heard of that one before.

Quoted 1 line

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

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-owner at vger.kernel.org schrieb am 20.05.2015 23:21:03:

Quoted 226 lines

Von: Tony Lindgren <[email protected]>
An: linux-omap at vger.kernel.org
Kopie: linux-arm-kernel at lists.infradead.org, Brian Hutchinson <[email protected]>, Paul Walmsley <[email protected]>, Roger Quadros <[email protected]>
Datum: 20.05.2015 23:37
Betreff: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug Gesendet von: linux-omap-owner at 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 <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Roger Quadros <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 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(-)

arch/arm/mach-omap2/omap_hwmod.h +6 -0

index 9611c91..b5d27ec 100644
@@ -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

arch/arm/ renamed from arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c +0 -0

mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 8821b9d..6dcfd03 100644

arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c +2 -10

@@ -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,

arch/ renamed from arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c +0 -0

arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c index cabc569..ae0cb67 100644

arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c +2 -1

@@ -668,7 +668,8 @@ struct omap_hwmod am33xx_gpmc_hwmod = {
    .name      = "gpmc",
    .class      = &am33xx_gpmc_hwmod_class,
    .clkdm_name   = "l3s_clkdm",
-   .flags      = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
+   .flags      = DEBUG_OMAP_GPMC_HWMOD_FLAGS,
    .main_clk   = "l3s_gclk",
    .prcm      = {
       .omap4   = {

arch/arm/mach-omap2/ renamed from arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +0 -0

omap_hwmod_3xxx_data.c
index 4e8e93c..0ca4d3f 100644

arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +2 -10

@@ -2169,16 +2169,8 @@ static struct omap_hwmod omap3xxx_gpmc_hwmod = {
    .clkdm_name   = "core_l3_clkdm",
    .mpu_irqs   = omap3xxx_gpmc_irqs,
    .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,
 };
 
 /*

arch/arm/mach-omap2/ renamed from arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0

omap_hwmod_44xx_data.c
index f5e68a7..43eebf2 100644

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +2 -9

@@ -1188,15 +1188,8 @@ static struct omap_hwmod omap44xx_gpmc_hwmod = {
    .name      = "gpmc",
    .class      = &omap44xx_gpmc_hwmod_class,
    .clkdm_name   = "l3_2_clkdm",
-   /*
-    * 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,
+   /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
+   .flags      = DEBUG_OMAP_GPMC_HWMOD_FLAGS,
    .prcm = {
       .omap4 = {
          .clkctrl_offs = OMAP4_CM_L3_2_GPMC_CLKCTRL_OFFSET,

arch/arm/mach-omap2/ renamed from arch/arm/mach-omap2/omap_hwmod_7xx_data.c +0 -0

omap_hwmod_7xx_data.c
index 0e64c2f..a0411f3 100644

arch/arm/mach-omap2/omap_hwmod_7xx_data.c +2 -2

@@ -819,8 +819,8 @@ static struct omap_hwmod dra7xx_gpmc_hwmod = {
    .name      = "gpmc",
    .class      = &dra7xx_gpmc_hwmod_class,
    .clkdm_name   = "l3main1_clkdm",
-   .flags      = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
-            HWMOD_SWSUP_SIDLE),
+   /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
+   .flags      = HWMOD_SWSUP_SIDLE | DEBUG_OMAP_GPMC_HWMOD_FLAGS,
    .main_clk   = "l3_iclk_div",
    .prcm = {
       .omap4 = {

arch/arm/mach-omap2/ renamed from arch/arm/mach-omap2/omap_hwmod_81xx_data.c +0 -0

omap_hwmod_81xx_data.c
index cab1eb6..c924137 100644

arch/arm/mach-omap2/omap_hwmod_81xx_data.c +2 -0

@@ -478,6 +478,8 @@ static struct omap_hwmod dm81xx_gpmc_hwmod = {
    .clkdm_name   = "alwon_l3s_clkdm",
    .class      = &dm81xx_gpmc_hwmod_class,
    .main_clk   = "sysclk6_ck",
+   /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
+   .flags      = DEBUG_OMAP_GPMC_HWMOD_FLAGS,
    .prcm = {
       .omap4 = {
          .clkctrl_offs = DM816X_CM_ALWON_GPMC_CLKCTRL,

drivers/memory/Kconfig +8 -0

index 868036f..8406c668 100644
@@ -49,6 +49,14 @@ config OMAP_GPMC
      interfacing to a variety of asynchronous as well as synchronous
      memory drives like NOR, NAND, OneNAND, SRAM.
 
+config OMAP_GPMC_DEBUG
+   bool
+   depends on OMAP_GPMC
+   help
+     Enables verbose debugging mostly to decode the bootloader provided
+     timings. Enable this during development to configure devices
+     connected to the GPMC bus.
+
 config MVEBU_DEVBUS
    bool "Marvell EBU Device Bus Controller"
    default y

drivers/memory/omap-gpmc.c +1 -1

index 0e524a1..3a27a84 100644
@@ -403,7 +403,7 @@ static void gpmc_cs_bool_timings(int cs, const struct
 gpmc_bool_timings *p)
             p->cycle2cyclediffcsen);
 }
 
-#ifdef DEBUG
+#ifdef CONFIG_OMAP_GPMC_DEBUG
 /**
  * get_gpmc_timing_reg - read a timing parameter and print DTS settings for it.

* @cs: Chip Select Region

drivers/memory/omap-gpmc.c +0 -0

@@ -612,7 +612,7 @@ static int set_gpmc_timing_reg(int cs, int reg, int

st_bit, int end_bit, int max

    }
 
    l = gpmc_cs_read_reg(cs, reg);

drivers/memory/omap-gpmc.c +2 -3

-#ifdef DEBUG
+#ifdef CONFIG_OMAP_GPMC_DEBUG
    pr_info(
       "GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n",
           cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks / 1000,

@@ -767,7 +767,7 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t,
              GPMC_CONFIG1_CLKACTIVATIONTIME_MAX,
              clk_activation, GPMC_CD_FCLK);
 
-#ifdef DEBUG
+#ifdef CONFIG_OMAP_GPMC_DEBUG
    pr_info("GPMC CS%d CLK period is %lu ns (div %d)\n",
          cs, (div * gpmc_get_fclk_period()) / 1000, div);
 #endif
--

2.1.4

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

Hi Hannes,

Quoted 7 lines

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

HWMOD_INIT_NO_RESET flag.

Quoted 2 lines

Primary this should not be a big problem, but on my board (maybe on

AM335x) the GPMC doesn't behave as described in TRM.

Quoted 1 line

Especially the GPMC_CONFIG register is not reset to 0h after reset,

it holds the value 0xa00 which is very strange because bit 10-31 are

Quoted 2 lines

Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly

causes my system to stall on first access the connected NAND flash

never becomes ready due to the wrong wait pin polarity. Maybe others

run into trouble because they may use WAIT0PIN, which one has it's old

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

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

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

for nand for DT boot.

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

cheers,
-roger

Quoted 1 line

Hi Hannes,

Hi Roger,

Quoted 9 lines · Hannes Schmelzer

Quoted 7 lines

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

Quoted 3 lines

HWMOD_INIT_NO_RESET flag.

Quoted 2 lines

Primary this should not be a big problem, but on my board (maybe on

all

Quoted 2 lines

AM335x) the GPMC doesn't behave as described in TRM.

Quoted 1 line

Especially the GPMC_CONFIG register is not reset to 0h after reset,

instead

Quoted 1 line

it holds the value 0xa00 which is very strange because bit 10-31 are

reserved.

Quoted 2 lines

Quoted 2 lines

Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly

this

Quoted 1 line

causes my system to stall on first access the connected NAND flash

because it

Quoted 1 line

never becomes ready due to the wrong wait pin polarity. Maybe others

dont't

Quoted 1 line

run into trouble because they may use WAIT0PIN, which one has it's old

polarity.

Quoted 2 lines

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

your board?

Quoted 1 line

Quoted 1 line

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).

Quoted 3 lines

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

Quoted 1 line

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.

Quoted 4 lines

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.

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-owner at vger.kernel.org schrieb am 20.05.2015 23:21:03:

Quoted 226 lines

Von: Tony Lindgren <[email protected]>
An: linux-omap at vger.kernel.org
Kopie: linux-arm-kernel at lists.infradead.org, Brian Hutchinson <[email protected]>, Paul Walmsley <[email protected]>, Roger Quadros <[email protected]>
Datum: 20.05.2015 23:37
Betreff: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug Gesendet von: linux-omap-owner at 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 <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Roger Quadros <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 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(-)

arch/arm/mach-omap2/omap_hwmod.h +6 -0

index 9611c91..b5d27ec 100644
@@ -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

arch/arm/ renamed from arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c +0 -0

mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 8821b9d..6dcfd03 100644

arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c +2 -10

@@ -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,

arch/ renamed from arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c +0 -0

arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c index cabc569..ae0cb67 100644

arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c +2 -1

@@ -668,7 +668,8 @@ struct omap_hwmod am33xx_gpmc_hwmod = {
    .name      = "gpmc",
    .class      = &am33xx_gpmc_hwmod_class,
    .clkdm_name   = "l3s_clkdm",
-   .flags      = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+   /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
+   .flags      = DEBUG_OMAP_GPMC_HWMOD_FLAGS,
    .main_clk   = "l3s_gclk",
    .prcm      = {
       .omap4   = {

arch/arm/mach-omap2/ renamed from arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +0 -0

omap_hwmod_3xxx_data.c
index 4e8e93c..0ca4d3f 100644

arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +2 -10

@@ -2169,16 +2169,8 @@ static struct omap_hwmod omap3xxx_gpmc_hwmod = {
    .clkdm_name   = "core_l3_clkdm",
    .mpu_irqs   = omap3xxx_gpmc_irqs,
    .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,
 };
 
 /*

arch/arm/mach-omap2/ renamed from arch/arm/mach-omap2/omap_hwmod_44xx_data.c +0 -0

omap_hwmod_44xx_data.c
index f5e68a7..43eebf2 100644

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +2 -9

@@ -1188,15 +1188,8 @@ static struct omap_hwmod omap44xx_gpmc_hwmod = {
    .name      = "gpmc",
    .class      = &omap44xx_gpmc_hwmod_class,
    .clkdm_name   = "l3_2_clkdm",
-   /*
-    * 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,
+   /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
+   .flags      = DEBUG_OMAP_GPMC_HWMOD_FLAGS,
    .prcm = {
       .omap4 = {
          .clkctrl_offs = OMAP4_CM_L3_2_GPMC_CLKCTRL_OFFSET,

arch/arm/mach-omap2/ renamed from arch/arm/mach-omap2/omap_hwmod_7xx_data.c +0 -0

omap_hwmod_7xx_data.c
index 0e64c2f..a0411f3 100644

arch/arm/mach-omap2/omap_hwmod_7xx_data.c +2 -2

@@ -819,8 +819,8 @@ static struct omap_hwmod dra7xx_gpmc_hwmod = {
    .name      = "gpmc",
    .class      = &dra7xx_gpmc_hwmod_class,
    .clkdm_name   = "l3main1_clkdm",
-   .flags      = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
-            HWMOD_SWSUP_SIDLE),
+   /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
+   .flags      = HWMOD_SWSUP_SIDLE | DEBUG_OMAP_GPMC_HWMOD_FLAGS,
    .main_clk   = "l3_iclk_div",
    .prcm = {
       .omap4 = {

arch/arm/mach-omap2/ renamed from arch/arm/mach-omap2/omap_hwmod_81xx_data.c +0 -0

omap_hwmod_81xx_data.c
index cab1eb6..c924137 100644

arch/arm/mach-omap2/omap_hwmod_81xx_data.c +2 -0

@@ -478,6 +478,8 @@ static struct omap_hwmod dm81xx_gpmc_hwmod = {
    .clkdm_name   = "alwon_l3s_clkdm",
    .class      = &dm81xx_gpmc_hwmod_class,
    .main_clk   = "sysclk6_ck",
+   /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
+   .flags      = DEBUG_OMAP_GPMC_HWMOD_FLAGS,
    .prcm = {
       .omap4 = {
          .clkctrl_offs = DM816X_CM_ALWON_GPMC_CLKCTRL,

drivers/memory/Kconfig +8 -0

index 868036f..8406c668 100644
@@ -49,6 +49,14 @@ config OMAP_GPMC
      interfacing to a variety of asynchronous as well as synchronous
      memory drives like NOR, NAND, OneNAND, SRAM.
 
+config OMAP_GPMC_DEBUG
+   bool
+   depends on OMAP_GPMC
+   help
+     Enables verbose debugging mostly to decode the bootloader provided
+     timings. Enable this during development to configure devices
+     connected to the GPMC bus.
+
 config MVEBU_DEVBUS
    bool "Marvell EBU Device Bus Controller"
    default y

drivers/memory/omap-gpmc.c +1 -1

index 0e524a1..3a27a84 100644
@@ -403,7 +403,7 @@ static void gpmc_cs_bool_timings(int cs, const struct
 gpmc_bool_timings *p)
             p->cycle2cyclediffcsen);
 }
 
-#ifdef DEBUG
+#ifdef CONFIG_OMAP_GPMC_DEBUG
 /**
  * get_gpmc_timing_reg - read a timing parameter and print DTS settings for it.

* @cs: Chip Select Region

drivers/memory/omap-gpmc.c +0 -0

@@ -612,7 +612,7 @@ static int set_gpmc_timing_reg(int cs, int reg, int

st_bit, int end_bit, int max

    }
 
    l = gpmc_cs_read_reg(cs, reg);

drivers/memory/omap-gpmc.c +2 -3

-#ifdef DEBUG
+#ifdef CONFIG_OMAP_GPMC_DEBUG
    pr_info(
       "GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n",
           cs, name, ticks, gpmc_get_clk_period(cs, cd) * ticks / 1000,

@@ -767,7 +767,7 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t,
              GPMC_CONFIG1_CLKACTIVATIONTIME_MAX,
              clk_activation, GPMC_CD_FCLK);
 
-#ifdef DEBUG
+#ifdef CONFIG_OMAP_GPMC_DEBUG
    pr_info("GPMC CS%d CLK period is %lu ns (div %d)\n",
          cs, (div * gpmc_get_fclk_period()) / 1000, div);
 #endif
--

2.1.4

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

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 <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Roger Quadros <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
  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(-)

Hi Tony,

Quoted 14 lines · Tony Lindgren

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 <[email protected]>

Cc Paul Walmsley <[email protected]>

Cc Roger Quadros <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Quoted 12 lines

---
 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.

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

Quoted 2 lines · 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.

Quoted 3 lines · On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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

Hi,

Quoted 1 line · Tony Lindgren

Quoted 1 line · On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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.

Quoted 4 lines · Ivaylo Dimitrov

Hi,

Quoted 1 line · Tony Lindgren

Quoted 1 line · On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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

Quoted 24 lines · On Monday 04 January 2016 20:13:56 Tony Lindgren wrote:

Quoted 4 lines · Ivaylo Dimitrov

Hi,

Quoted 1 line · Tony Lindgren

Quoted 1 line · On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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.

Quoted 3 lines

Regards,

Tony

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

arch/arm/mach-omap2/gpmc-onenand.c

Quoted 39 lines · Tony Lindgren

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 <[email protected]>
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 <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap2/gpmc-onenand.c +0 -0

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 <[email protected]>

Jan  6 10:34:15 Nokia-N900 kernel: [    1.373229] omap-gpmc 6e000000.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 GPMC_CS_CONFIG6:
0x8d050000
Jan  6 10:34:15 Nokia-N900 kernel: [    1.576812] gpmc cs0 access
configuration:
Jan  6 10:34:15 Nokia-N900 kernel: [    1.581146] gpmc,mux-add-data = <2>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.584899] gpmc,device-width = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.588592] gpmc,wait-pin = <0>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.591949] gpmc,burst-length = <16>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.595794] gpmc,sync-write = <1>
Jan  6 10:34:15 Nokia-N900 cellular: csd[1017]: Succesfully loaded plugin
<sms>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.599273] gpmc,burst-write = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.602905] gpmc,burst-read = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.606445] gpmc,burst-wrap = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.609954] gpmc cs0 timings
configuration:
Jan  6 10:34:15 Nokia-N900 kernel: [    1.614440] gpmc,cs-on-ns = <0> /* 0
ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.620269] gpmc,cs-rd-off-ns = <84>
/* 79 ns - 84 ns; 14 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.626861] gpmc,cs-wr-off-ns = <114>
/* 109 ns - 114 ns; 19 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.633728] gpmc,adv-on-ns = <0> /* 0
ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.639617] gpmc,adv-rd-off-ns = <18>
/* 13 ns - 18 ns; 3 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.646209] gpmc,adv-wr-off-ns = <18>
/* 13 ns - 18 ns; 3 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.652770] gpmc,oe-on-ns = <30> /* 25
ns - 30 ns; 5 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.658935] gpmc,oe-off-ns = <84> /*
79 ns - 84 ns; 14 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.665252] gpmc,we-on-ns = <0> /* 0
ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.671081] gpmc,we-off-ns = <84> /*
79 ns - 84 ns; 14 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.677398] gpmc,rd-cycle-ns = <108>
/* 103 ns - 108 ns; 18 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.684112] gpmc,wr-cycle-ns = <102>
/* 97 ns - 102 ns; 17 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.690765] gpmc,access-ns = <78> /*
73 ns - 78 ns; 13 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.697082] gpmc,page-burst-access-ns
= <0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.704010] gpmc,bus-turnaround-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.710662] gpmc,cycle2cycle-delay-ns
= <0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.717620] gpmc,wait-monitoring-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.724395] gpmc,clk-activation-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.731048] gpmc,wr-data-mux-bus-ns =
<30> /* 25 ns - 30 ns; 5 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.738098] gpmc,wr-access-ns = <78>
/* 73 ns - 78 ns; 13 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.744781] GPMC CS0: cs_on      :   0
ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.752685] GPMC CS0: cs_rd_off      :
16 ticks,  96 ns (was  14 ticks)  96 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.760681] GPMC CS0: cs_wr_off      :
16 ticks,  96 ns (was  19 ticks)  96 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.768646] GPMC CS0: adv_on      :
0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.776641] GPMC CS0: adv_rd_off
:   2 ticks,  12 ns (was   3 ticks)  12 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.784576] GPMC CS0: adv_wr_off
:   2 ticks,  12 ns (was   3 ticks)  12 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.792541] GPMC CS0: oe_on      :   3
ticks,  18 ns (was   5 ticks)  18 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.800476] GPMC CS0: oe_off      :
16 ticks,  96 ns (was  14 ticks)  96 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.808410] GPMC CS0: we_on      :   0
ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.816345] GPMC CS0: we_off      :
16 ticks,  96 ns (was  14 ticks)  96 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.824279] GPMC CS0: rd_cycle      :
19 ticks, 114 ns (was  18 ticks) 114 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.832183] GPMC CS0: wr_cycle      :
19 ticks, 114 ns (was  17 ticks) 114 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.840087] GPMC CS0: access      :
15 ticks,  90 ns (was  13 ticks)  90 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.848083] GPMC CS0:
page_burst_access:   2 ticks,  12 ns (was   0 ticks)  12 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.856018] GPMC CS0: bus_turnaround
:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.864013] GPMC CS0:
cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.871917] GPMC CS0: wr_data_mux_bus
:   5 ticks,  30 ns (was   5 ticks)  30 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.879821] GPMC CS0: wr_access      :
15 ticks,  90 ns (was  13 ticks)  90 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.887817] GPMC CS0: wait_monitoring
:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.895812] GPMC CS0: clk_activation
:   1 ticks,   6 ns (was   0 ticks)   6 ns
Jan  6 10:34:15 Nokia-N900 kernel: [    1.903747] GPMC CS0 CLK period is 12
ns (div 2)
Jan  6 10:34:15 Nokia-N900 kernel: [    1.908599] gpmc cs0 after
gpmc_cs_set_timings:
Jan  6 10:34:15 Nokia-N900 kernel: [    1.913421] cs0 GPMC_CS_CONFIG1:
0xfb001201
Jan  6 10:34:15 Nokia-N900 cellular: csd[1017]: Succesfully loaded plugin
<ss>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.917907] cs0 GPMC_CS_CONFIG2:
0x00101000
Jan  6 10:34:15 Nokia-N900 kernel: [    1.922332] cs0 GPMC_CS_CONFIG3:
0x00020200
Jan  6 10:34:15 Nokia-N900 kernel: [    1.926788] cs0 GPMC_CS_CONFIG4:
0x10001003
Jan  6 10:34:15 Nokia-N900 kernel: [    1.931243] cs0 GPMC_CS_CONFIG5:
0x020f1313
Jan  6 10:34:15 Nokia-N900 kernel: [    1.935729] cs0 GPMC_CS_CONFIG6:
0x8f050000
Jan  6 10:34:15 Nokia-N900 kernel: [    1.940124] gpmc cs0 access
configuration:
Jan  6 10:34:15 Nokia-N900 kernel: [    1.944519] gpmc,mux-add-data = <2>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.948211] gpmc,device-width = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.951934] gpmc,wait-pin = <0>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.955291] gpmc,burst-length = <16>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.959106] gpmc,sync-write = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.962646] gpmc,burst-write = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.966278] gpmc,gpmc,sync-read = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.970184] gpmc,burst-read = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.973724] gpmc,burst-wrap = <1>
Jan  6 10:34:15 Nokia-N900 kernel: [    1.977233] gpmc cs0 timings
configuration:
Jan  6 10:34:15 Nokia-N900 kernel: [    1.981658] gpmc,cs-on-ns = <0> /* 0
ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.987518] gpmc,cs-rd-off-ns = <96>
/* 91 ns - 96 ns; 16 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    1.994049] gpmc,cs-wr-off-ns = <96>
/* 91 ns - 96 ns; 16 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.000610] gpmc,adv-on-ns = <0> /* 0
ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.006591] gpmc,adv-rd-off-ns = <12>
/* 7 ns - 12 ns; 2 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.013000] gpmc,adv-wr-off-ns = <12>
/* 7 ns - 12 ns; 2 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.019500] gpmc,oe-on-ns = <18> /* 13
ns - 18 ns; 3 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.025634] gpmc,oe-off-ns = <96> /*
91 ns - 96 ns; 16 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.031921] gpmc,we-on-ns = <0> /* 0
ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.037780] gpmc,we-off-ns = <96> /*
91 ns - 96 ns; 16 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.044067] gpmc,rd-cycle-ns = <114>
/* 109 ns - 114 ns; 19 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.050811] gpmc,wr-cycle-ns = <114>
/* 109 ns - 114 ns; 19 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.057586] gpmc,access-ns = <90> /*
85 ns - 90 ns; 15 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.063903] gpmc,page-burst-access-ns
= <12> /* 7 ns - 12 ns; 2 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.071014] gpmc,bus-turnaround-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.077697] gpmc,cycle2cycle-delay-ns
= <0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.084625] gpmc,wait-monitoring-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.091339] gpmc,clk-activation-ns =
<6> /* 1 ns - 6 ns; 1 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.098022] gpmc,wr-data-mux-bus-ns =
<30> /* 25 ns - 30 ns; 5 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.105072] gpmc,wr-access-ns = <90>
/* 85 ns - 90 ns; 15 ticks */
Jan  6 10:34:15 Nokia-N900 kernel: [    2.111602] omap2-onenand
omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base
d0940000, freq 83 MHz
Jan  6 10:34:15 Nokia-N900 kernel: [    2.123016] OneNAND Manufacturer:
Numonyx (0x20)
Jan  6 10:34:15 Nokia-N900 gconfd (root-1080): starting (version 2.16.0),
pid 1080 user 'root'
Jan  6 10:34:16 Nokia-N900 kernel: [    2.123016] Muxed OneNAND 256MB 1.8V
16-bit (0x40)
Jan  6 10:34:16 Nokia-N900 waitx[1085]: trying to get X display
Jan  6 10:34:16 Nokia-N900 kernel: [    2.128112] OneNAND version = 0x0031
Jan  6 10:34:16 Nokia-N900 kernel: [    2.131896] Chip support all block
unlock
Jan  6 10:34:16 Nokia-N900 kernel: [    2.131896] Chip has 2 plane
Jan  6 10:34:16 Nokia-N900 kernel: [    2.133483] Scanning device for bad
blocks
Jan  6 10:34:16 Nokia-N900 kernel: [    2.232177] 6 ofpart partitions found
on MTD device (null)
Jan  6 10:34:16 Nokia-N900 kernel: [    2.238098] Creating 6 MTD partitions
on "(null)":
Jan  6 10:34:16 Nokia-N900 kernel: [    2.243164]
0x000000000000-0x000000020000 : "bootloader"
Jan  6 10:34:16 Nokia-N900 kernel: [    2.249725]
0x000000020000-0x000000080000 : "config"
Jan  6 10:34:16 Nokia-N900 kernel: [    2.255767]
0x000000080000-0x0000000c0000 : "log"
Jan  6 10:34:16 Nokia-N900 kernel: [    2.263793] mtdoops: ready 34,
959521136 (no erase)
Jan  6 10:34:16 Nokia-N900 kernel: [    2.263793] mtdoops: Attached to MTD
device 2
Jan  6 10:34:16 Nokia-N900 kernel: [    2.268432]
0x0000000c0000-0x0000002c0000 : "kernel"
Jan  6 10:34:16 Nokia-N900 kernel: [    2.274444]
0x0000002c0000-0x0000004c0000 : "initfs"
Jan  6 10:34:16 Nokia-N900 kernel: [    2.280364]
0x0000004c0000-0x000010000000 : "rootfs"
Jan  6 10:34:16 Nokia-N900 kernel: [    2.287963] gpmc cs1 before
gpmc_cs_program_settings:
Jan  6 10:34:16 Nokia-N900 kernel: [    2.293304] cs1 GPMC_CS_CONFIG1:
0x00001000
Jan  6 10:34:16 Nokia-N900 kernel: [    2.297790] cs1 GPMC_CS_CONFIG2:
0x00101001
Jan  6 10:34:16 Nokia-N900 kernel: [    2.302246] cs1 GPMC_CS_CONFIG3:
0x00020201
Jan  6 10:34:16 Nokia-N900 kernel: [    2.306732] cs1 GPMC_CS_CONFIG4:
0x10031003
Jan  6 10:34:16 Nokia-N900 kernel: [    2.311126] cs1 GPMC_CS_CONFIG5:
0x010f1111
Jan  6 10:34:16 Nokia-N900 kernel: [    2.315612] cs1 GPMC_CS_CONFIG6:
0x8f030000
Jan  6 10:34:16 Nokia-N900 kernel: [    2.320007] gpmc cs1 access
configuration:
Jan  6 10:34:16 Nokia-N900 kernel: [    2.324401] gpmc,mux-add-data = <0>
Jan  6 10:34:16 Nokia-N900 kernel: [    2.328124] gpmc,device-width = <1>
Jan  6 10:34:16 Nokia-N900 kernel: [    2.331817] gpmc,wait-pin = <0>
Jan  6 10:34:16 Nokia-N900 kernel: [    2.335205] gpmc,burst-length = <4>
Jan  6 10:34:16 Nokia-N900 kernel: [    2.338928] gpmc cs1 timings
configuration:
Jan  6 10:34:16 Nokia-N900 kernel: [    2.343353] gpmc,cs-on-ns = <6> /* 1
ns - 6 ns; 1 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.349212] gpmc,cs-rd-off-ns = <96>
/* 91 ns - 96 ns; 16 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.355773] gpmc,cs-wr-off-ns = <96>
/* 91 ns - 96 ns; 16 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.362274] gpmc,adv-on-ns = <6> /* 1
ns - 6 ns; 1 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.368225] gpmc,adv-rd-off-ns = <12>
/* 7 ns - 12 ns; 2 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.374664] gpmc,adv-wr-off-ns = <12>
/* 7 ns - 12 ns; 2 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.381103] gpmc,oe-on-ns = <18> /* 13
ns - 18 ns; 3 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.387237] gpmc,oe-off-ns = <96> /*
91 ns - 96 ns; 16 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.393463] gpmc,we-on-ns = <18> /* 13
ns - 18 ns; 3 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.399597] gpmc,we-off-ns = <96> /*
91 ns - 96 ns; 16 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.405914] gpmc,rd-cycle-ns = <102>
/* 97 ns - 102 ns; 17 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.412536] gpmc,wr-cycle-ns = <102>
/* 97 ns - 102 ns; 17 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.419219] gpmc,access-ns = <90> /*
85 ns - 90 ns; 15 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.425476] gpmc,page-burst-access-ns
= <6> /* 1 ns - 6 ns; 1 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.432403] gpmc,bus-turnaround-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.439086] gpmc,cycle2cycle-delay-ns
= <0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.446044] gpmc,wait-monitoring-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.452728] gpmc,clk-activation-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.459442] gpmc,wr-data-mux-bus-ns =
<18> /* 13 ns - 18 ns; 3 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.466491] gpmc,wr-access-ns = <90>
/* 85 ns - 90 ns; 15 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.473052] GPMC CS1: cs_on      :   0
ticks,   0 ns (was   1 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.481048] GPMC CS1: cs_rd_off      :
8 ticks,  48 ns (was  16 ticks)  48 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.489044] GPMC CS1: cs_wr_off      :
4 ticks,  24 ns (was  16 ticks)  24 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.496978] GPMC CS1: adv_on      :
0 ticks,   0 ns (was   1 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.504943] GPMC CS1: adv_rd_off
:   0 ticks,   0 ns (was   2 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.512878] GPMC CS1: adv_wr_off
:   0 ticks,   0 ns (was   2 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.520843] GPMC CS1: oe_on      :   2
ticks,  12 ns (was   3 ticks)  12 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.528839] GPMC CS1: oe_off      :
8 ticks,  48 ns (was  16 ticks)  48 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.536773] GPMC CS1: we_on      :   2
ticks,  12 ns (was   3 ticks)  12 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.544708] GPMC CS1: we_off      :
3 ticks,  18 ns (was  16 ticks)  18 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.552612] GPMC CS1: rd_cycle      :
30 ticks, 180 ns (was  17 ticks) 180 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.560607] GPMC CS1: wr_cycle      :
30 ticks, 180 ns (was  17 ticks) 180 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.568542] GPMC CS1: access      :
7 ticks,  42 ns (was  15 ticks)  42 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.576477] GPMC CS1:
page_burst_access:   0 ticks,   0 ns (was   1 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.584472] GPMC CS1: bus_turnaround
:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.592346] GPMC CS1:
cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.600341] GPMC CS1: wr_data_mux_bus
:   2 ticks,  12 ns (was   3 ticks)  12 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.608276] GPMC CS1: wr_access      :
0 ticks,   0 ns (was  15 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.616271] GPMC CS1: wait_monitoring
:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.624267] GPMC CS1: clk_activation
:   0 ticks,   0 ns (was   0 ticks)   0 ns
Jan  6 10:34:16 Nokia-N900 kernel: [    2.632171] GPMC CS1 CLK period is 6
ns (div 1)
Jan  6 10:34:16 Nokia-N900 kernel: [    2.637023] gpmc cs1 after
gpmc_cs_set_timings:
Jan  6 10:34:16 Nokia-N900 kernel: [    2.641815] cs1 GPMC_CS_CONFIG1:
0x00001000
Jan  6 10:34:16 Nokia-N900 kernel: [    2.646301] cs1 GPMC_CS_CONFIG2:
0x00040800
Jan  6 10:34:16 Nokia-N900 kernel: [    2.650726] cs1 GPMC_CS_CONFIG3:
0x00000000
Jan  6 10:34:16 Nokia-N900 kernel: [    2.655212] cs1 GPMC_CS_CONFIG4:
0x03020802
Jan  6 10:34:16 Nokia-N900 kernel: [    2.659606] cs1 GPMC_CS_CONFIG5:
0x00071e1e
Jan  6 10:34:16 Nokia-N900 kernel: [    2.664093] cs1 GPMC_CS_CONFIG6:
0x80020000
Jan  6 10:34:16 Nokia-N900 kernel: [    2.668548] gpmc cs1 access
configuration:
Jan  6 10:34:16 Nokia-N900 kernel: [    2.672882] gpmc,mux-add-data = <0>
Jan  6 10:34:16 Nokia-N900 kernel: [    2.676635] gpmc,device-width = <1>
Jan  6 10:34:16 Nokia-N900 kernel: [    2.680328] gpmc,wait-pin = <0>
Jan  6 10:34:16 Nokia-N900 kernel: [    2.683685] gpmc,burst-length = <4>
Jan  6 10:34:16 Nokia-N900 kernel: [    2.687408] gpmc cs1 timings
configuration:
Jan  6 10:34:16 Nokia-N900 kernel: [    2.691833] gpmc,cs-on-ns = <0> /* 0
ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.697692] gpmc,cs-rd-off-ns = <48>
/* 43 ns - 48 ns; 8 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.704132] gpmc,cs-wr-off-ns = <24>
/* 19 ns - 24 ns; 4 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.710601] gpmc,adv-on-ns = <0> /* 0
ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.716552] gpmc,adv-rd-off-ns = <0>
/* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.722808] gpmc,adv-wr-off-ns = <0>
/* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.729125] gpmc,oe-on-ns = <12> /* 7
ns - 12 ns; 2 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.735137] gpmc,oe-off-ns = <48> /*
43 ns - 48 ns; 8 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.741333] gpmc,we-on-ns = <12> /* 7
ns - 12 ns; 2 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.747375] gpmc,we-off-ns = <18> /*
13 ns - 18 ns; 3 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.753509] gpmc,rd-cycle-ns = <180>
/* 175 ns - 180 ns; 30 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.760284] gpmc,wr-cycle-ns = <180>
/* 175 ns - 180 ns; 30 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.767059] gpmc,access-ns = <42> /*
37 ns - 42 ns; 7 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.773254] gpmc,page-burst-access-ns
= <0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.780212] gpmc,bus-turnaround-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.786895] gpmc,cycle2cycle-delay-ns
= <0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.793853] gpmc,wait-monitoring-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.800628] gpmc,clk-activation-ns =
<0> /* 0 ns - 0 ns; 0 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.807312] gpmc,wr-data-mux-bus-ns =
<12> /* 7 ns - 12 ns; 2 ticks */
Jan  6 10:34:16 Nokia-N900 kernel: [    2.814270] gpmc,wr-access-ns = <0> /*

0 ns - 0 ns; 0 ticks */

Quoted 41 lines · On Wednesday 06 January 2016 10:55:51 Ivaylo Dimitrov wrote:

arch/arm/mach-omap2/gpmc-onenand.c

Quoted 35 lines · Tony Lindgren

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 <[email protected]>
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 <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap2/gpmc-onenand.c +0 -0

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.

Quoted 3 lines

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

Tested-by Ivaylo Dimitrov <[email protected]>

Great! Thank you for fixing and testing this problem!

From: Tony Lindgren <[email protected]>
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 <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

arch/arm/mach-omap2/gpmc-onenand.c +9 -5

@@ -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,
 				      &onenand_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(&t);
 
 	ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_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);
 	}
 

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 <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

Hi,

Quoted 5 lines · Tony Lindgren

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.

Quoted 1 line

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.

Quoted 8 lines · Sebastian Reichel

Hi,

Quoted 5 lines · Tony Lindgren

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.

Quoted 4 lines

Quoted 1 line

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:

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?

Hi,

Quoted 3 lines · Tony Lindgren

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.

Quoted 2 lines

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?

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?

OK well at least that part of the bug is fixed then.

Quoted 2 lines

Quoted 2 lines

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

Quoted 2 lines

CONFIG_OMAP_GPMC_DEBUG is disabled, shall I enable it?

Yes please.

Quoted 4 lines

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.

Hmm good point. Can you boot with root on MMC? So far no luck here reproducing the corruption here with my fix applied.

Quoted 3 lines

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

Well the timings now for me both with and without GPMC reset are:

cs0 GPMC_CS_CONFIG1: 0xfb001201
cs0 GPMC_CS_CONFIG2: 0x00101000
cs0 GPMC_CS_CONFIG3: 0x00020200
cs0 GPMC_CS_CONFIG4: 0x10001003
cs0 GPMC_CS_CONFIG5: 0x020f1313
cs0 GPMC_CS_CONFIG6: 0x8f050000

These timings also match the current mainline timings without the fix I posted when CONFIG_OMAP_GPMC_DEBUG is enabled.

The nolo set timings I have are:
cs0 GPMC_CS_CONFIG1: 0xfb001201
cs0 GPMC_CS_CONFIG2: 0x00101000
cs0 GPMC_CS_CONFIG3: 0x00020200
cs0 GPMC_CS_CONFIG4: 0x10001002 <- OEONTIME is still different in nolo cs0 GPMC_CS_CONFIG5: 0x020f1313
cs0 GPMC_CS_CONFIG6: 0x8f050000

So there seems to be OEONTIME difference. Once the legacy boot is gone, we can probably remove the OEONTIME calculations and rely on the dts provide values as it seems that currently the dts value is ignored in gpmc_calc_sync_read_timings().

To dump your nolo provided timings, you can add the following line to gpmc_probe_onenand_child() before gpmc_onenand_init:

	gpmc_cs_show_timings(gpmc_onenand_data->cs,
		"before gpmc_cs_program_settings");

Note that will show the wrong GPMC default values after reset unless you have CONFIG_OMAP_GPMC_DEBUG enabled.

Then below is a better debug patch to dump out the values after reset. Note that in that case the above "before" timings must be ignored.

Regards,

Tony

8< --------------------

arch/arm/mach-omap2/gpmc-onenand.c +2 -0

@@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct omap_onenand_platform_data *cfg,
  		freq = 0;
  	}
 
+	gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings");
+
  	return freq;
  }
 

arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +1 -2

@@ -2150,8 +2150,7 @@ static struct omap_hwmod omap3xxx_gpmc_hwmod = {
  	.clkdm_name	= "core_l3_clkdm",
  	.mpu_irqs	= omap3xxx_gpmc_irqs,
  	.main_clk	= "gpmc_fck",
-	/* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */
-	.flags		= HWMOD_NO_IDLEST | DEBUG_OMAP_GPMC_HWMOD_FLAGS,
+	.flags		= HWMOD_NO_IDLEST,
  };
 
  /*

Quoted 2 lines · Tony Lindgren

Quoted 2 lines

Quoted 2 lines

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

I'll make further experiments as I am a bit lost what and when happens. What is for sure is that corruptions occurs immediately after boot without your patch and with CONFIG_OMAP_GPMC_DEBUG disabled. So maybe there is another problem in ubfs or mtd driver.

Already did, every reflash and install of upstream kernel compatible SW takes me about 3 hours I'd rather spend on something else :). Though it seems that reboot issue happens no matter if CONFIG_OMAP_GPMC_DEBUG is enabled or not.

The problem is that between NOLO and kernel there is u-boot. And even if I am almost sure it doesn't touch onenand configs, I can't be absolutely sure. So those timings are not 100% reliable IMO, though close to that.

I'll play a bit more with printing the values with both CONFIG_OMAP_GPMC_DEBUG enabled and disabled and whatever I can think of, including dumping cs0 config from u-boot, nokia kernel and/or REing NOLO onenand init (already did that for N9 DDR timings, shouldn't be that hard for N900 GPMC). Will keep you informed on the progress. In the meanwhile I think your patch should make it as without it onenand is unusable.

Yes it seems there's some other issue too. Maybe you can run git bisect again and carry the fix along as an extra patch?

OK then it really seems like we do have another bug lurking around.

Maybe you can figure out an easier way to reproduce it?

Quoted 3 lines

The problem is that between NOLO and kernel there is u-boot. And even if I am almost sure it doesn't touch onenand configs, I can't be absolutely sure. So those timings are not 100% reliable IMO, though close to that.

Hmm yes I'm only booting with u-boot here as my device sits in my rack.

OK will push it out then.

And it looks like the problems happens sometimes on oops too.

Quoted 1 line · On Friday 08 January 2016 07:13:58 Ivaylo Dimitrov wrote:

And it looks like the problems happens sometimes on oops too.

In linux-n900 tree is enabled mtdoops driver which store oops to specified MTD device. So maybe this access cause it?

Hi,

Quoted 1 line · Pali Roh?r

On Friday 08 January 2016 07:13:58 Ivaylo Dimitrov wrote:

Quoted 5 lines

Quoted 1 line

And it looks like the problems happens sometimes on oops too.

In linux-n900 tree is enabled mtdoops driver which store oops to specified MTD device. So maybe this access cause it?

The key word here is "sometimes". i.e sometimes it hapens on normal reboot, sometimes it happens on oops.

Quoted 10 lines · On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote:

Hi,

Quoted 6 lines · Pali Roh?r

Quoted 1 line · On Friday 08 January 2016 07:13:58 Ivaylo Dimitrov wrote:

And it looks like the problems happens sometimes on oops too.

In linux-n900 tree is enabled mtdoops driver which store oops to specified MTD device. So maybe this access cause it?

Quoted 2 lines

The key word here is "sometimes". i.e sometimes it hapens on normal reboot, sometimes it happens on oops.

So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in different component? Do we know at least this?

Quoted 7 lines · Pali Roh?r

Quoted 2 lines · On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote:

The key word here is "sometimes". i.e sometimes it hapens on normal reboot, sometimes it happens on oops.

So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in different component? Do we know at least this?

I think I made some progress on the issue, it seems I have to have *both* e7b11dc7b77bfce0a351230a5feeadc1d0bba997 (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and* HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working onenand.

Tony, shall I hardcode GPMC_CS_CONFIG4 OEONTIME to be the same as NOLO's or it does not make sense?

Quoted 9 lines · Ivaylo Dimitrov

Quoted 7 lines · Pali Roh?r

Quoted 2 lines · On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote:

The key word here is "sometimes". i.e sometimes it hapens on normal reboot, sometimes it happens on oops.

So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in different component? Do we know at least this?

Quoted 5 lines

I think I made some progress on the issue, it seems I have to have *both* e7b11dc7b77bfce0a351230a5feeadc1d0bba997 (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and* HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working onenand.

That is strange. This is what I get with omap2plus_defconfig and omap-for-v4.5/fixes-rc1 after flashing the rootfs and booting kernel like you suggested on irc:

# dmesg | grep -i -e ubi -e onenand
[    2.502899] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base d0940000, freq 83 MHz
[    2.514373] OneNAND Manufacturer: Numonyx (0x20)
[    2.519287] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[    2.524444] OneNAND version = 0x0031
[    2.671966] 6 ofpart partitions found on MTD device omap2-onenand
[    2.678436] Creating 6 MTD partitions on "omap2-onenand":
[    3.414764] ubi0: attaching mtd5
[    3.668212] ubi0: scanning is finished
[    3.716552] ubi0: attached mtd5 (name "rootfs", size 251 MiB)
[    3.722839] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[    3.730194] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[    3.737304] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[    3.744537] ubi0: good PEBs: 2010, bad PEBs: 0, corrupted PEBs: 0
[    3.751037] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[    3.758697] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0
[    3.767578] ubi0: available PEBs: 0, total reserved PEBs: 2010, PEBs reserved for bad PEB handling: 40
[    3.923980] ubi0: background thread "ubi_bgt0d" started, PID 85
[    3.980529] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 87
[    3.996337] UBIFS (ubi0:0): recovery needed
[    4.079925] UBIFS (ubi0:0): recovery completed
[    4.085876] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[    4.093780] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    4.104339] UBIFS (ubi0:0): FS size: 252241920 bytes (240 MiB, 1955 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs)
[    4.115722] UBIFS (ubi0:0): reserved for root: 4190434 bytes (4092 KiB)
[    4.122772] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8F30A88A-F605-4291-9927-00CF3A2AE119, small LPT model
[    4.136077] VFS: Mounted root (ubifs filesystem) on device 0:15.

I copied over the modules to this rootfs too :) But in general onenand seems to behave for me.

Quoted 16 lines · Tony Lindgren

Quoted 14 lines · Ivaylo Dimitrov

Quoted 7 lines · Pali Roh?r

Quoted 2 lines · On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote:

The key word here is "sometimes". i.e sometimes it hapens on normal reboot, sometimes it happens on oops.

So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in different component? Do we know at least this?

I think I made some progress on the issue, it seems I have to have *both* e7b11dc7b77bfce0a351230a5feeadc1d0bba997 (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and* HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working onenand.

Quoted 3 lines

That is strange. This is what I get with omap2plus_defconfig and omap-for-v4.5/fixes-rc1 after flashing the rootfs and booting kernel like you suggested on irc:

Quoted 6 lines

# dmesg | grep -i -e ubi -e onenand
[    2.502899] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base d0940000, freq 83 MHz
[    2.514373] OneNAND Manufacturer: Numonyx (0x20)
[    2.519287] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[    2.524444] OneNAND version = 0x0031

Quoted 23 lines

[    2.671966] 6 ofpart partitions found on MTD device omap2-onenand
[    2.678436] Creating 6 MTD partitions on "omap2-onenand":
[    3.414764] ubi0: attaching mtd5
[    3.668212] ubi0: scanning is finished
[    3.716552] ubi0: attached mtd5 (name "rootfs", size 251 MiB)
[    3.722839] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[    3.730194] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[    3.737304] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[    3.744537] ubi0: good PEBs: 2010, bad PEBs: 0, corrupted PEBs: 0
[    3.751037] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[    3.758697] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0
[    3.767578] ubi0: available PEBs: 0, total reserved PEBs: 2010, PEBs reserved for bad PEB handling: 40
[    3.923980] ubi0: background thread "ubi_bgt0d" started, PID 85
[    3.980529] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 87
[    3.996337] UBIFS (ubi0:0): recovery needed
[    4.079925] UBIFS (ubi0:0): recovery completed
[    4.085876] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[    4.093780] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    4.104339] UBIFS (ubi0:0): FS size: 252241920 bytes (240 MiB, 1955 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs)
[    4.115722] UBIFS (ubi0:0): reserved for root: 4190434 bytes (4092 KiB)
[    4.122772] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8F30A88A-F605-4291-9927-00CF3A2AE119, small LPT model
[    4.136077] VFS: Mounted root (ubifs filesystem) on device 0:15.

Quoted 2 lines

I copied over the modules to this rootfs too :) But in general onenand seems to behave for me.

And ere are my GPCM timings when booted with GPMC_DEBUG in case they are different somehow for your device.

Regards,

Tony

omap-gpmc 6e000000.gpmc: GPMC revision 5.0
GPMC CS0: cs_on : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: cs_rd_off : 14 ticks, 84 ns (was 16 ticks) 84 ns
GPMC CS0: cs_wr_off : 19 ticks, 114 ns (was 16 ticks) 114 ns
GPMC CS0: adv_on : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: adv_rd_off : 3 ticks, 18 ns (was 2 ticks) 18 ns
GPMC CS0: adv_wr_off : 3 ticks, 18 ns (was 2 ticks) 18 ns
GPMC CS0: oe_on : 5 ticks, 30 ns (was 2 ticks) 30 ns
GPMC CS0: oe_off : 14 ticks, 84 ns (was 16 ticks) 84 ns
GPMC CS0: we_on : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: we_off : 14 ticks, 84 ns (was 16 ticks) 84 ns
GPMC CS0: rd_cycle : 18 ticks, 108 ns (was 19 ticks) 108 ns
GPMC CS0: wr_cycle : 17 ticks, 102 ns (was 19 ticks) 102 ns
GPMC CS0: access : 13 ticks, 78 ns (was 15 ticks) 78 ns
GPMC CS0: page_burst_access: 0 ticks, 0 ns (was 2 ticks) 0 ns
GPMC CS0: bus_turnaround : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: cycle2cycle_delay: 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: wr_data_mux_bus : 5 ticks, 30 ns (was 5 ticks) 30 ns
GPMC CS0: wr_access : 13 ticks, 78 ns (was 15 ticks) 78 ns
GPMC CS0: wait_monitoring : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: clk_activation : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0 CLK period is 6 ns (div 1)
gpmc cs0 after gpmc_cs_set_timings:
cs0 GPMC_CS_CONFIG1: 0xd9001200
cs0 GPMC_CS_CONFIG2: 0x00130e00
cs0 GPMC_CS_CONFIG3: 0x00030300
cs0 GPMC_CS_CONFIG4: 0x0e000e05
cs0 GPMC_CS_CONFIG5: 0x000d1112
cs0 GPMC_CS_CONFIG6: 0x8d050000
gpmc cs0 access configuration:
gpmc,mux-add-data = <2>
gpmc,device-width = <1>
gpmc,wait-pin = <0>
gpmc,burst-length = <16>
gpmc,sync-write = <1>
gpmc,burst-write = <1>
gpmc,burst-read = <1>
gpmc,burst-wrap = <1>
gpmc cs0 timings configuration:
gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,cs-rd-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */
gpmc,cs-wr-off-ns = <114> /* 109 ns - 114 ns; 19 ticks */
gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,adv-rd-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */
gpmc,adv-wr-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */
gpmc,oe-on-ns = <30> /* 25 ns - 30 ns; 5 ticks */
gpmc,oe-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */
gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,we-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */
gpmc,rd-cycle-ns = <108> /* 103 ns - 108 ns; 18 ticks */
gpmc,wr-cycle-ns = <102> /* 97 ns - 102 ns; 17 ticks */
gpmc,access-ns = <78> /* 73 ns - 78 ns; 13 ticks */
gpmc,page-burst-access-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,clk-activation-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */
gpmc,wr-access-ns = <78> /* 73 ns - 78 ns; 13 ticks */
GPMC CS0: cs_on : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: cs_rd_off : 16 ticks, 96 ns (was 14 ticks) 96 ns
GPMC CS0: cs_wr_off : 16 ticks, 96 ns (was 19 ticks) 96 ns
GPMC CS0: adv_on : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: adv_rd_off : 2 ticks, 12 ns (was 3 ticks) 12 ns
GPMC CS0: adv_wr_off : 2 ticks, 12 ns (was 3 ticks) 12 ns
GPMC CS0: oe_on : 3 ticks, 18 ns (was 5 ticks) 18 ns
GPMC CS0: oe_off : 16 ticks, 96 ns (was 14 ticks) 96 ns
GPMC CS0: we_on : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: we_off : 16 ticks, 96 ns (was 14 ticks) 96 ns
GPMC CS0: rd_cycle : 19 ticks, 114 ns (was 18 ticks) 114 ns
GPMC CS0: wr_cycle : 19 ticks, 114 ns (was 17 ticks) 114 ns
GPMC CS0: access : 15 ticks, 90 ns (was 13 ticks) 90 ns
GPMC CS0: page_burst_access: 2 ticks, 12 ns (was 0 ticks) 12 ns
GPMC CS0: bus_turnaround : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: cycle2cycle_delay: 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: wr_data_mux_bus : 5 ticks, 30 ns (was 5 ticks) 30 ns
GPMC CS0: wr_access : 15 ticks, 90 ns (was 13 ticks) 90 ns
GPMC CS0: wait_monitoring : 0 ticks, 0 ns (was 0 ticks) 0 ns
GPMC CS0: clk_activation : 1 ticks, 6 ns (was 0 ticks) 6 ns
GPMC CS0 CLK period is 12 ns (div 2)
gpmc cs0 after gpmc_cs_set_timings:
cs0 GPMC_CS_CONFIG1: 0xfb001201
cs0 GPMC_CS_CONFIG2: 0x00101000
cs0 GPMC_CS_CONFIG3: 0x00020200
cs0 GPMC_CS_CONFIG4: 0x10001003
cs0 GPMC_CS_CONFIG5: 0x020f1313
cs0 GPMC_CS_CONFIG6: 0x8f050000
gpmc cs0 access configuration:
gpmc,mux-add-data = <2>
gpmc,device-width = <1>
gpmc,wait-pin = <0>
gpmc,burst-length = <16>
gpmc,sync-write = <1>
gpmc,burst-write = <1>
gpmc,gpmc,sync-read = <1>
gpmc,burst-read = <1>
gpmc,burst-wrap = <1>
gpmc cs0 timings configuration:
gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,cs-rd-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
gpmc,cs-wr-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,adv-rd-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */
gpmc,adv-wr-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */
gpmc,oe-on-ns = <18> /* 13 ns - 18 ns; 3 ticks */
gpmc,oe-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,we-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
gpmc,rd-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */
gpmc,wr-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */
gpmc,access-ns = <90> /* 85 ns - 90 ns; 15 ticks */
gpmc,page-burst-access-ns = <12> /* 7 ns - 12 ns; 2 ticks */
gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,clk-activation-ns = <6> /* 1 ns - 6 ns; 1 ticks */
gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */
gpmc,wr-access-ns = <90> /* 85 ns - 90 ns; 15 ticks */
omap2-onenand omap2-onenand: initializing on CS0, phys base 0x04000000, virtual base d0940000, freq 83 MHz OneNAND Manufacturer: Numonyx (0x20)
Muxed OneNAND 256MB 1.8V 16-bit (0x40)
OneNAND version = 0x0031
Chip support all block unlock
Chip has 2 plane
Scanning device for bad blocks
6 ofpart partitions found on MTD device omap2-onenand
Creating 6 MTD partitions on "omap2-onenand":

0x000000000000-0x000000020000 : "bootloader"
0x000000020000-0x000000080000 : "config"
0x000000080000-0x0000000c0000 : "log"
mtdoops: ready 43, 6188 (no erase)
mtdoops: Attached to MTD device 2
0x0000000c0000-0x0000002c0000 : "kernel"
0x0000002c0000-0x0000004c0000 : "initfs"
0x0000004c0000-0x000010000000 : "rootfs"

I will play a bit more with omap2plus_defconfig here in attempt to make it boot, to see if I can recreate the issue.

- flashed maemo rootfs

sudo flasher-3.5 -f -F RX-51_2009SE_20.2010.36-2_PR_COMBINED_MR0_ARM.bin --flash-only=rootfs -R

- booted to maemo and powered the device off

sudo flasher-3.5 -k zImage -l -b"init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw mtdoops.mtddev=log omapfb_vram=7M omapfb.mode=lcd:848x480-16 nokia-modem.pm=0"

This seems to fix things here for legacy booting and booting the maemo zImage after dts image. Care to give it a try?

Basically onenand after reset is in wrong state, have not looked up the bits yet. Will post a better patch when I get a chance over next few days.

Regards,

Tony

Hi

Quoted 3 lines · Tony Lindgren

Yes it seems there's some other issue too. Maybe you can run git bisect again and carry the fix along as an extra patch?

No sane way to bisect, I don't really know what triggers the issue. Neither it is triggered regularly. It might happen on the first reboot or on the tenth, or ... And it looks like the problems happens sometimes on oops too. Not to say that it seems I should have fully booted userspace (so there is enough pressure on the ubi/mdt/nand subsystems), which is impossible with upstream without some n900 specific patches :(

Maybe we can get some ideas on what and where to look from ubifs people? Though I don't know whom to cc, feel free to help :)

My best bet aiui, is comparing what nokia omap1 kernel does vs upstream. Or looking at the commit log in ubi/mtd/onenand - who knows, I might get lucky once again the same way as with that phonet oops in __netif_receive_skb_core.

Quoted 1 line

OK then it really seems like we do have another bug lurking around.

:nod:

Quoted 3 lines

The problem is that between NOLO and kernel there is u-boot. And even if I am almost sure it doesn't touch onenand configs, I can't be absolutely sure. So those timings are not 100% reliable IMO, though close to that.

Hmm yes I'm only booting with u-boot here as my device sits in my rack.

Quoted 5 lines · On Thursday 07 January 2016 18:26:20 Tony Lindgren wrote:

Quoted 3 lines

The problem is that between NOLO and kernel there is u-boot. And even if I am almost sure it doesn't touch onenand configs, I can't be absolutely sure. So those timings are not 100% reliable IMO, though close to that.

Hmm yes I'm only booting with u-boot here as my device sits in my rack.

U-boot try to configure N900 device similar like (some older version of) linux kernel. So testing these bugs should be done also directly from NOLO without U-boot.

Btw, if you have usb connection to your device in your rack, you can use 0xFFFF tool (open source) which can send kernel image to NOLO which will boot it without flashing NAND.

https://github.com/pali/0xFFFF

Original Nokia flasher-3.5 could support also serial connection (not only usb), but do not know. I have never used serial connector on my N900, so I do not know and this is reason why also 0xFFFF has no serial support...