Re: pxa3xx-nand failing to find device on linux-next

2017-05-26 Thread Boris Brezillon 
Le Thu, 25 May 2017 22:12:12 +,
Chris Packham  a écrit :

> On 25/05/17 18:19, Boris Brezillon wrote:
> > Le Wed, 24 May 2017 22:58:53 +,
> > Chris Packham  a écrit :
> >   
> >> On 25/05/17 10:36, Boris Brezillon wrote:  
> >>> Le Wed, 24 May 2017 22:03:52 +,
> >>> Chris Packham  a écrit :
> >>>  
>  On 24/05/17 23:25, Boris Brezillon wrote:  
> > On Wed, 24 May 2017 13:23:01 +0200
> > Boris Brezillon  wrote:
> > 
> >> Hi Chris,
> >>
> >> On Wed, 24 May 2017 09:36:56 +
> >> Chris Packham  wrote:
> >>
> >>> On 23/05/17 17:27, Chris Packham wrote:  
>  Hi,
> 
>  I'm doing some testing on linux-next and I'm finding that my nand 
>  flash
>  has disappeared.
> 
>  pxa3xx-nand f10d.flash: This platform can't do DMA on this device
>  pxa3xx-nand f10d.flash: non-supported command ef
>  pxa3xx-nand f10d.flash: non-supported command ee
>  pxa3xx-nand f10d.flash: non-supported command ef
>  pxa3xx-nand f10d.flash: non-supported command ee
>  On-die ECC forcefully enabled, not supported
>  nand: No NAND device found
>  pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> 
>  This was working around 4.11. I'll try to do some more digging 
>  tomorrow
>  to narrow down a failure point but I thought I'd send this out now 
>  just
>  in case it rings any bells.
> 
>  The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree 
>  but it
>  should be pretty close to the armada-388-db. I can make my dts 
>  available
>  if it's helpful.  
> >>>
> >>> Still works on 4.12-rc2. Fails on next-20170524.
> >>>
> >>> This appears to be due to commit b566d9c055de ("mtd: nand: add support
> >>> for Micron on-die ECC"). Which based on the description seems 
> >>> intentional.
> >>>
> >>> Since I have access to a hardware platform that has a micron flash 
> >>> with
> >>> ECC forcefully enabled how can I help to get this implemented.  
> >>
> >> Can you try with this patch applied [1]?  
> >
> > Sorry, wrong patch. Can you try this one [1] instead?
> >
> > [1]http://code.bulix.org/pkfhmi-135875
> > 
> 
>  With the patch above the chip is detected but ubifs is unhappy  
> >>>
> >>> Hm, weird. And if you revert my both Thomas patch and mine, what do you
> >>> get?  
> >>
> >> Seems to work just fine.  
> > 
> > Okay. Let's try with something simpler then. Can you test the following
> > patch?
> >   
> > --->8---  
> >  From 0a0eaa39ea9b19191ae0c31ff3625c224a8a55f2 Mon Sep 17 00:00:00 2001
> > From: Boris Brezillon 
> > Date: Thu, 25 May 2017 08:15:15 +0200
> > Subject: [PATCH] mtd: nand: pxa3xx: Implement failing  
> >   ->onfi_{set,get}_features() stubs  
> > 
> > Implement stubs returning -ENOTSUPP for ->onfi_{set,get}_features() so
> > that we don't let the core think we are supporting the GET/SET FEATURES
> > operation.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---  
> 
> Yep that seems to work.

Arrggg!! I hate this situation. Now I have to check all drivers
implementing their own ->cmdfunc() to make sure they support
NAND_CMD_SET/GET_FEATURES, and if they don't, do what I did for pxa3xx.

Anyway, thanks for testing. I'll try to re-arrange my nand/next branch
to avoid breaking bisectibility (put this patch before the on-die ECC
one).

Regards,

Boris

Re: pxa3xx-nand failing to find device on linux-next

2017-05-26 Thread Boris Brezillon 
Le Thu, 25 May 2017 22:12:12 +,
Chris Packham  a écrit :

> On 25/05/17 18:19, Boris Brezillon wrote:
> > Le Wed, 24 May 2017 22:58:53 +,
> > Chris Packham  a écrit :
> >   
> >> On 25/05/17 10:36, Boris Brezillon wrote:  
> >>> Le Wed, 24 May 2017 22:03:52 +,
> >>> Chris Packham  a écrit :
> >>>  
>  On 24/05/17 23:25, Boris Brezillon wrote:  
> > On Wed, 24 May 2017 13:23:01 +0200
> > Boris Brezillon  wrote:
> > 
> >> Hi Chris,
> >>
> >> On Wed, 24 May 2017 09:36:56 +
> >> Chris Packham  wrote:
> >>
> >>> On 23/05/17 17:27, Chris Packham wrote:  
>  Hi,
> 
>  I'm doing some testing on linux-next and I'm finding that my nand 
>  flash
>  has disappeared.
> 
>  pxa3xx-nand f10d.flash: This platform can't do DMA on this device
>  pxa3xx-nand f10d.flash: non-supported command ef
>  pxa3xx-nand f10d.flash: non-supported command ee
>  pxa3xx-nand f10d.flash: non-supported command ef
>  pxa3xx-nand f10d.flash: non-supported command ee
>  On-die ECC forcefully enabled, not supported
>  nand: No NAND device found
>  pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> 
>  This was working around 4.11. I'll try to do some more digging 
>  tomorrow
>  to narrow down a failure point but I thought I'd send this out now 
>  just
>  in case it rings any bells.
> 
>  The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree 
>  but it
>  should be pretty close to the armada-388-db. I can make my dts 
>  available
>  if it's helpful.  
> >>>
> >>> Still works on 4.12-rc2. Fails on next-20170524.
> >>>
> >>> This appears to be due to commit b566d9c055de ("mtd: nand: add support
> >>> for Micron on-die ECC"). Which based on the description seems 
> >>> intentional.
> >>>
> >>> Since I have access to a hardware platform that has a micron flash 
> >>> with
> >>> ECC forcefully enabled how can I help to get this implemented.  
> >>
> >> Can you try with this patch applied [1]?  
> >
> > Sorry, wrong patch. Can you try this one [1] instead?
> >
> > [1]http://code.bulix.org/pkfhmi-135875
> > 
> 
>  With the patch above the chip is detected but ubifs is unhappy  
> >>>
> >>> Hm, weird. And if you revert my both Thomas patch and mine, what do you
> >>> get?  
> >>
> >> Seems to work just fine.  
> > 
> > Okay. Let's try with something simpler then. Can you test the following
> > patch?
> >   
> > --->8---  
> >  From 0a0eaa39ea9b19191ae0c31ff3625c224a8a55f2 Mon Sep 17 00:00:00 2001
> > From: Boris Brezillon 
> > Date: Thu, 25 May 2017 08:15:15 +0200
> > Subject: [PATCH] mtd: nand: pxa3xx: Implement failing  
> >   ->onfi_{set,get}_features() stubs  
> > 
> > Implement stubs returning -ENOTSUPP for ->onfi_{set,get}_features() so
> > that we don't let the core think we are supporting the GET/SET FEATURES
> > operation.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---  
> 
> Yep that seems to work.

Arrggg!! I hate this situation. Now I have to check all drivers
implementing their own ->cmdfunc() to make sure they support
NAND_CMD_SET/GET_FEATURES, and if they don't, do what I did for pxa3xx.

Anyway, thanks for testing. I'll try to re-arrange my nand/next branch
to avoid breaking bisectibility (put this patch before the on-die ECC
one).

Regards,

Boris

Re: pxa3xx-nand failing to find device on linux-next

2017-05-25 Thread Chris Packham 
On 25/05/17 18:19, Boris Brezillon wrote:
> Le Wed, 24 May 2017 22:58:53 +,
> Chris Packham  a écrit :
> 
>> On 25/05/17 10:36, Boris Brezillon wrote:
>>> Le Wed, 24 May 2017 22:03:52 +,
>>> Chris Packham  a écrit :
>>>
 On 24/05/17 23:25, Boris Brezillon wrote:
> On Wed, 24 May 2017 13:23:01 +0200
> Boris Brezillon  wrote:
>   
>> Hi Chris,
>>
>> On Wed, 24 May 2017 09:36:56 +
>> Chris Packham  wrote:
>>  
>>> On 23/05/17 17:27, Chris Packham wrote:
 Hi,

 I'm doing some testing on linux-next and I'm finding that my nand flash
 has disappeared.

 pxa3xx-nand f10d.flash: This platform can't do DMA on this device
 pxa3xx-nand f10d.flash: non-supported command ef
 pxa3xx-nand f10d.flash: non-supported command ee
 pxa3xx-nand f10d.flash: non-supported command ef
 pxa3xx-nand f10d.flash: non-supported command ee
 On-die ECC forcefully enabled, not supported
 nand: No NAND device found
 pxa3xx-nand f10d.flash: failed to scan nand at cs 0

 This was working around 4.11. I'll try to do some more digging tomorrow
 to narrow down a failure point but I thought I'd send this out now just
 in case it rings any bells.

 The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but 
 it
 should be pretty close to the armada-388-db. I can make my dts 
 available
 if it's helpful.
>>>
>>> Still works on 4.12-rc2. Fails on next-20170524.
>>>
>>> This appears to be due to commit b566d9c055de ("mtd: nand: add support
>>> for Micron on-die ECC"). Which based on the description seems 
>>> intentional.
>>>
>>> Since I have access to a hardware platform that has a micron flash with
>>> ECC forcefully enabled how can I help to get this implemented.
>>
>> Can you try with this patch applied [1]?
>
> Sorry, wrong patch. Can you try this one [1] instead?
>
> [1]http://code.bulix.org/pkfhmi-135875
>   

 With the patch above the chip is detected but ubifs is unhappy
>>>
>>> Hm, weird. And if you revert my both Thomas patch and mine, what do you
>>> get?
>>
>> Seems to work just fine.
> 
> Okay. Let's try with something simpler then. Can you test the following
> patch?
> 
> --->8---
>  From 0a0eaa39ea9b19191ae0c31ff3625c224a8a55f2 Mon Sep 17 00:00:00 2001
> From: Boris Brezillon 
> Date: Thu, 25 May 2017 08:15:15 +0200
> Subject: [PATCH] mtd: nand: pxa3xx: Implement failing
>   ->onfi_{set,get}_features() stubs
> 
> Implement stubs returning -ENOTSUPP for ->onfi_{set,get}_features() so
> that we don't let the core think we are supporting the GET/SET FEATURES
> operation.
> 
> Signed-off-by: Boris Brezillon 
> ---

Yep that seems to work.

Re: pxa3xx-nand failing to find device on linux-next

2017-05-25 Thread Chris Packham 
On 25/05/17 18:19, Boris Brezillon wrote:
> Le Wed, 24 May 2017 22:58:53 +,
> Chris Packham  a écrit :
> 
>> On 25/05/17 10:36, Boris Brezillon wrote:
>>> Le Wed, 24 May 2017 22:03:52 +,
>>> Chris Packham  a écrit :
>>>
 On 24/05/17 23:25, Boris Brezillon wrote:
> On Wed, 24 May 2017 13:23:01 +0200
> Boris Brezillon  wrote:
>   
>> Hi Chris,
>>
>> On Wed, 24 May 2017 09:36:56 +
>> Chris Packham  wrote:
>>  
>>> On 23/05/17 17:27, Chris Packham wrote:
 Hi,

 I'm doing some testing on linux-next and I'm finding that my nand flash
 has disappeared.

 pxa3xx-nand f10d.flash: This platform can't do DMA on this device
 pxa3xx-nand f10d.flash: non-supported command ef
 pxa3xx-nand f10d.flash: non-supported command ee
 pxa3xx-nand f10d.flash: non-supported command ef
 pxa3xx-nand f10d.flash: non-supported command ee
 On-die ECC forcefully enabled, not supported
 nand: No NAND device found
 pxa3xx-nand f10d.flash: failed to scan nand at cs 0

 This was working around 4.11. I'll try to do some more digging tomorrow
 to narrow down a failure point but I thought I'd send this out now just
 in case it rings any bells.

 The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but 
 it
 should be pretty close to the armada-388-db. I can make my dts 
 available
 if it's helpful.
>>>
>>> Still works on 4.12-rc2. Fails on next-20170524.
>>>
>>> This appears to be due to commit b566d9c055de ("mtd: nand: add support
>>> for Micron on-die ECC"). Which based on the description seems 
>>> intentional.
>>>
>>> Since I have access to a hardware platform that has a micron flash with
>>> ECC forcefully enabled how can I help to get this implemented.
>>
>> Can you try with this patch applied [1]?
>
> Sorry, wrong patch. Can you try this one [1] instead?
>
> [1]http://code.bulix.org/pkfhmi-135875
>   

 With the patch above the chip is detected but ubifs is unhappy
>>>
>>> Hm, weird. And if you revert my both Thomas patch and mine, what do you
>>> get?
>>
>> Seems to work just fine.
> 
> Okay. Let's try with something simpler then. Can you test the following
> patch?
> 
> --->8---
>  From 0a0eaa39ea9b19191ae0c31ff3625c224a8a55f2 Mon Sep 17 00:00:00 2001
> From: Boris Brezillon 
> Date: Thu, 25 May 2017 08:15:15 +0200
> Subject: [PATCH] mtd: nand: pxa3xx: Implement failing
>   ->onfi_{set,get}_features() stubs
> 
> Implement stubs returning -ENOTSUPP for ->onfi_{set,get}_features() so
> that we don't let the core think we are supporting the GET/SET FEATURES
> operation.
> 
> Signed-off-by: Boris Brezillon 
> ---

Yep that seems to work.

Re: pxa3xx-nand failing to find device on linux-next

2017-05-25 Thread Boris Brezillon 
Le Wed, 24 May 2017 22:58:53 +,
Chris Packham  a écrit :

> On 25/05/17 10:36, Boris Brezillon wrote:
> > Le Wed, 24 May 2017 22:03:52 +,
> > Chris Packham  a écrit :
> >   
> >> On 24/05/17 23:25, Boris Brezillon wrote:  
> >>> On Wed, 24 May 2017 13:23:01 +0200
> >>> Boris Brezillon  wrote:
> >>>  
>  Hi Chris,
> 
>  On Wed, 24 May 2017 09:36:56 +
>  Chris Packham  wrote:
>  
> > On 23/05/17 17:27, Chris Packham wrote:  
> >> Hi,
> >>
> >> I'm doing some testing on linux-next and I'm finding that my nand flash
> >> has disappeared.
> >>
> >> pxa3xx-nand f10d.flash: This platform can't do DMA on this device
> >> pxa3xx-nand f10d.flash: non-supported command ef
> >> pxa3xx-nand f10d.flash: non-supported command ee
> >> pxa3xx-nand f10d.flash: non-supported command ef
> >> pxa3xx-nand f10d.flash: non-supported command ee
> >> On-die ECC forcefully enabled, not supported
> >> nand: No NAND device found
> >> pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> >>
> >> This was working around 4.11. I'll try to do some more digging tomorrow
> >> to narrow down a failure point but I thought I'd send this out now just
> >> in case it rings any bells.
> >>
> >> The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but 
> >> it
> >> should be pretty close to the armada-388-db. I can make my dts 
> >> available
> >> if it's helpful.  
> >
> > Still works on 4.12-rc2. Fails on next-20170524.
> >
> > This appears to be due to commit b566d9c055de ("mtd: nand: add support
> > for Micron on-die ECC"). Which based on the description seems 
> > intentional.
> >
> > Since I have access to a hardware platform that has a micron flash with
> > ECC forcefully enabled how can I help to get this implemented.  
> 
>  Can you try with this patch applied [1]?  
> >>>
> >>> Sorry, wrong patch. Can you try this one [1] instead?
> >>>
> >>> [1]http://code.bulix.org/pkfhmi-135875
> >>>  
> >>
> >> With the patch above the chip is detected but ubifs is unhappy  
> > 
> > Hm, weird. And if you revert my both Thomas patch and mine, what do you
> > get?  
> 
> Seems to work just fine.

Okay. Let's try with something simpler then. Can you test the following
patch?

--->8---
>From 0a0eaa39ea9b19191ae0c31ff3625c224a8a55f2 Mon Sep 17 00:00:00 2001
From: Boris Brezillon 
Date: Thu, 25 May 2017 08:15:15 +0200
Subject: [PATCH] mtd: nand: pxa3xx: Implement failing
 ->onfi_{set,get}_features() stubs

Implement stubs returning -ENOTSUPP for ->onfi_{set,get}_features() so
that we don't let the core think we are supporting the GET/SET FEATURES
operation.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/pxa3xx_nand.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 649ba8200832..341a229046f5 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -1649,6 +1649,13 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
return 0;
 }
 
+static int pxa3xx_nand_get_set_features(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   int feature_addr, u8 *subfeature_para)
+{
+   return -ENOTSUPP;
+}
+
 static int pxa3xx_nand_scan(struct mtd_info *mtd)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
@@ -1812,6 +1819,8 @@ static int alloc_nand_resource(struct platform_device 
*pdev)
chip->write_buf = pxa3xx_nand_write_buf;
chip->options   |= NAND_NO_SUBPAGE_WRITE;
chip->cmdfunc   = nand_cmdfunc;
+   chip->onfi_set_features = pxa3xx_nand_get_set_features;
+   chip->onfi_get_features = pxa3xx_nand_get_set_features;
}
 
nand_hw_control_init(chip->controller);
-- 
2.11.0

Re: pxa3xx-nand failing to find device on linux-next

2017-05-25 Thread Boris Brezillon 
Le Wed, 24 May 2017 22:58:53 +,
Chris Packham  a écrit :

> On 25/05/17 10:36, Boris Brezillon wrote:
> > Le Wed, 24 May 2017 22:03:52 +,
> > Chris Packham  a écrit :
> >   
> >> On 24/05/17 23:25, Boris Brezillon wrote:  
> >>> On Wed, 24 May 2017 13:23:01 +0200
> >>> Boris Brezillon  wrote:
> >>>  
>  Hi Chris,
> 
>  On Wed, 24 May 2017 09:36:56 +
>  Chris Packham  wrote:
>  
> > On 23/05/17 17:27, Chris Packham wrote:  
> >> Hi,
> >>
> >> I'm doing some testing on linux-next and I'm finding that my nand flash
> >> has disappeared.
> >>
> >> pxa3xx-nand f10d.flash: This platform can't do DMA on this device
> >> pxa3xx-nand f10d.flash: non-supported command ef
> >> pxa3xx-nand f10d.flash: non-supported command ee
> >> pxa3xx-nand f10d.flash: non-supported command ef
> >> pxa3xx-nand f10d.flash: non-supported command ee
> >> On-die ECC forcefully enabled, not supported
> >> nand: No NAND device found
> >> pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> >>
> >> This was working around 4.11. I'll try to do some more digging tomorrow
> >> to narrow down a failure point but I thought I'd send this out now just
> >> in case it rings any bells.
> >>
> >> The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but 
> >> it
> >> should be pretty close to the armada-388-db. I can make my dts 
> >> available
> >> if it's helpful.  
> >
> > Still works on 4.12-rc2. Fails on next-20170524.
> >
> > This appears to be due to commit b566d9c055de ("mtd: nand: add support
> > for Micron on-die ECC"). Which based on the description seems 
> > intentional.
> >
> > Since I have access to a hardware platform that has a micron flash with
> > ECC forcefully enabled how can I help to get this implemented.  
> 
>  Can you try with this patch applied [1]?  
> >>>
> >>> Sorry, wrong patch. Can you try this one [1] instead?
> >>>
> >>> [1]http://code.bulix.org/pkfhmi-135875
> >>>  
> >>
> >> With the patch above the chip is detected but ubifs is unhappy  
> > 
> > Hm, weird. And if you revert my both Thomas patch and mine, what do you
> > get?  
> 
> Seems to work just fine.

Okay. Let's try with something simpler then. Can you test the following
patch?

--->8---
>From 0a0eaa39ea9b19191ae0c31ff3625c224a8a55f2 Mon Sep 17 00:00:00 2001
From: Boris Brezillon 
Date: Thu, 25 May 2017 08:15:15 +0200
Subject: [PATCH] mtd: nand: pxa3xx: Implement failing
 ->onfi_{set,get}_features() stubs

Implement stubs returning -ENOTSUPP for ->onfi_{set,get}_features() so
that we don't let the core think we are supporting the GET/SET FEATURES
operation.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/pxa3xx_nand.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 649ba8200832..341a229046f5 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -1649,6 +1649,13 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
return 0;
 }
 
+static int pxa3xx_nand_get_set_features(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   int feature_addr, u8 *subfeature_para)
+{
+   return -ENOTSUPP;
+}
+
 static int pxa3xx_nand_scan(struct mtd_info *mtd)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
@@ -1812,6 +1819,8 @@ static int alloc_nand_resource(struct platform_device 
*pdev)
chip->write_buf = pxa3xx_nand_write_buf;
chip->options   |= NAND_NO_SUBPAGE_WRITE;
chip->cmdfunc   = nand_cmdfunc;
+   chip->onfi_set_features = pxa3xx_nand_get_set_features;
+   chip->onfi_get_features = pxa3xx_nand_get_set_features;
}
 
nand_hw_control_init(chip->controller);
-- 
2.11.0

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Chris Packham 
On 25/05/17 10:36, Boris Brezillon wrote:
> Le Wed, 24 May 2017 22:03:52 +,
> Chris Packham  a écrit :
> 
>> On 24/05/17 23:25, Boris Brezillon wrote:
>>> On Wed, 24 May 2017 13:23:01 +0200
>>> Boris Brezillon  wrote:
>>>
 Hi Chris,

 On Wed, 24 May 2017 09:36:56 +
 Chris Packham  wrote:
   
> On 23/05/17 17:27, Chris Packham wrote:
>> Hi,
>>
>> I'm doing some testing on linux-next and I'm finding that my nand flash
>> has disappeared.
>>
>> pxa3xx-nand f10d.flash: This platform can't do DMA on this device
>> pxa3xx-nand f10d.flash: non-supported command ef
>> pxa3xx-nand f10d.flash: non-supported command ee
>> pxa3xx-nand f10d.flash: non-supported command ef
>> pxa3xx-nand f10d.flash: non-supported command ee
>> On-die ECC forcefully enabled, not supported
>> nand: No NAND device found
>> pxa3xx-nand f10d.flash: failed to scan nand at cs 0
>>
>> This was working around 4.11. I'll try to do some more digging tomorrow
>> to narrow down a failure point but I thought I'd send this out now just
>> in case it rings any bells.
>>
>> The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
>> should be pretty close to the armada-388-db. I can make my dts available
>> if it's helpful.
>
> Still works on 4.12-rc2. Fails on next-20170524.
>
> This appears to be due to commit b566d9c055de ("mtd: nand: add support
> for Micron on-die ECC"). Which based on the description seems intentional.
>
> Since I have access to a hardware platform that has a micron flash with
> ECC forcefully enabled how can I help to get this implemented.

 Can you try with this patch applied [1]?
>>>
>>> Sorry, wrong patch. Can you try this one [1] instead?
>>>
>>> [1]http://code.bulix.org/pkfhmi-135875
>>>
>>
>> With the patch above the chip is detected but ubifs is unhappy
> 
> Hm, weird. And if you revert my both Thomas patch and mine, what do you
> get?

Seems to work just fine.

> BTW, can you paste the full boot logs, not only the failing part?

Sure. Full log from next-20170524 + http://code.bulix.org/pkfhmi-135875 
below.

[root@linuxbox /]# dmesg
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 455168
Kernel command line: console=ttyS0,115200 root=/dev/ram0 loglevel=8
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 1798628K/1835008K available (5120K kernel code, 173K rwdata, 
1364K rodata, 1024K init, 123K bss, 36380K reserved, 0K cma-rese
rved)
Virtual kernel memory layout:
 vector  : 0x - 0x1000   (   4 kB)
 fixmap  : 0xffc0 - 0xfff0   (3072 kB)
 vmalloc : 0xf080 - 0xff80   ( 240 MB)
 lowmem  : 0x8000 - 0xf000   (1792 MB)
 modules : 0x7f00 - 0x8000   (  16 MB)
   .text : 0x80008000 - 0x8060   (6112 kB)
   .init : 0x8080 - 0x8090   (1024 kB)
   .data : 0x8090 - 0x8092b600   ( 174 kB)
.bss : 0x80930688 - 0x8094f440   ( 124 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Preemptible hierarchical RCU implementation.
 RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 D prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 Coherent cache controller enabled, 16 ways, 1024 kB
L2C-310 Coherent: CACHE_ID 0x410054c9, AUX_CTRL 0x56070001
Switching to timer-based delay loop, resolution 50ns
sched_clock: 32 bits at 20MHz, resolution 50ns, wraps every 107374182375ns
clocksource: armada_370_xp_clocksource: mask: 0x max_cycles: 
0x, max_idle_ns: 95563022313 ns
Calibrating delay loop (skipped), value calculated using timer 
frequency.. 40.00 BogoMIPS (lpj=20)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 4096 (order: 2, 16384 bytes)
Mountpoint-cache hash table entries: 4096 (order: 2, 16384 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x10 - 0x100060
mvebu-soc-id: MVEBU SoC ID=0x6820, Rev=0x4
mvebu-pmsu: Initializing Power Management Service Unit
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
Booting CPU 1
CPU1: thread -1, cpu 1, socket 0, mpidr 8001
smp: Brought up 1 node, 2 CPUs
SMP: Total of 2 processors activated (80.00 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Chris Packham 
On 25/05/17 10:36, Boris Brezillon wrote:
> Le Wed, 24 May 2017 22:03:52 +,
> Chris Packham  a écrit :
> 
>> On 24/05/17 23:25, Boris Brezillon wrote:
>>> On Wed, 24 May 2017 13:23:01 +0200
>>> Boris Brezillon  wrote:
>>>
 Hi Chris,

 On Wed, 24 May 2017 09:36:56 +
 Chris Packham  wrote:
   
> On 23/05/17 17:27, Chris Packham wrote:
>> Hi,
>>
>> I'm doing some testing on linux-next and I'm finding that my nand flash
>> has disappeared.
>>
>> pxa3xx-nand f10d.flash: This platform can't do DMA on this device
>> pxa3xx-nand f10d.flash: non-supported command ef
>> pxa3xx-nand f10d.flash: non-supported command ee
>> pxa3xx-nand f10d.flash: non-supported command ef
>> pxa3xx-nand f10d.flash: non-supported command ee
>> On-die ECC forcefully enabled, not supported
>> nand: No NAND device found
>> pxa3xx-nand f10d.flash: failed to scan nand at cs 0
>>
>> This was working around 4.11. I'll try to do some more digging tomorrow
>> to narrow down a failure point but I thought I'd send this out now just
>> in case it rings any bells.
>>
>> The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
>> should be pretty close to the armada-388-db. I can make my dts available
>> if it's helpful.
>
> Still works on 4.12-rc2. Fails on next-20170524.
>
> This appears to be due to commit b566d9c055de ("mtd: nand: add support
> for Micron on-die ECC"). Which based on the description seems intentional.
>
> Since I have access to a hardware platform that has a micron flash with
> ECC forcefully enabled how can I help to get this implemented.

 Can you try with this patch applied [1]?
>>>
>>> Sorry, wrong patch. Can you try this one [1] instead?
>>>
>>> [1]http://code.bulix.org/pkfhmi-135875
>>>
>>
>> With the patch above the chip is detected but ubifs is unhappy
> 
> Hm, weird. And if you revert my both Thomas patch and mine, what do you
> get?

Seems to work just fine.

> BTW, can you paste the full boot logs, not only the failing part?

Sure. Full log from next-20170524 + http://code.bulix.org/pkfhmi-135875 
below.

[root@linuxbox /]# dmesg
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 455168
Kernel command line: console=ttyS0,115200 root=/dev/ram0 loglevel=8
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 1798628K/1835008K available (5120K kernel code, 173K rwdata, 
1364K rodata, 1024K init, 123K bss, 36380K reserved, 0K cma-rese
rved)
Virtual kernel memory layout:
 vector  : 0x - 0x1000   (   4 kB)
 fixmap  : 0xffc0 - 0xfff0   (3072 kB)
 vmalloc : 0xf080 - 0xff80   ( 240 MB)
 lowmem  : 0x8000 - 0xf000   (1792 MB)
 modules : 0x7f00 - 0x8000   (  16 MB)
   .text : 0x80008000 - 0x8060   (6112 kB)
   .init : 0x8080 - 0x8090   (1024 kB)
   .data : 0x8090 - 0x8092b600   ( 174 kB)
.bss : 0x80930688 - 0x8094f440   ( 124 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Preemptible hierarchical RCU implementation.
 RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 D prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 Coherent cache controller enabled, 16 ways, 1024 kB
L2C-310 Coherent: CACHE_ID 0x410054c9, AUX_CTRL 0x56070001
Switching to timer-based delay loop, resolution 50ns
sched_clock: 32 bits at 20MHz, resolution 50ns, wraps every 107374182375ns
clocksource: armada_370_xp_clocksource: mask: 0x max_cycles: 
0x, max_idle_ns: 95563022313 ns
Calibrating delay loop (skipped), value calculated using timer 
frequency.. 40.00 BogoMIPS (lpj=20)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 4096 (order: 2, 16384 bytes)
Mountpoint-cache hash table entries: 4096 (order: 2, 16384 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x10 - 0x100060
mvebu-soc-id: MVEBU SoC ID=0x6820, Rev=0x4
mvebu-pmsu: Initializing Power Management Service Unit
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
Booting CPU 1
CPU1: thread -1, cpu 1, socket 0, mpidr 8001
smp: Brought up 1 node, 2 CPUs
SMP: Total of 2 processors activated (80.00 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Boris Brezillon 
Le Wed, 24 May 2017 22:03:52 +,
Chris Packham  a écrit :

> On 24/05/17 23:25, Boris Brezillon wrote:
> > On Wed, 24 May 2017 13:23:01 +0200
> > Boris Brezillon  wrote:
> >   
> >> Hi Chris,
> >>
> >> On Wed, 24 May 2017 09:36:56 +
> >> Chris Packham  wrote:
> >>  
> >>> On 23/05/17 17:27, Chris Packham wrote:  
>  Hi,
> 
>  I'm doing some testing on linux-next and I'm finding that my nand flash
>  has disappeared.
> 
>  pxa3xx-nand f10d.flash: This platform can't do DMA on this device
>  pxa3xx-nand f10d.flash: non-supported command ef
>  pxa3xx-nand f10d.flash: non-supported command ee
>  pxa3xx-nand f10d.flash: non-supported command ef
>  pxa3xx-nand f10d.flash: non-supported command ee
>  On-die ECC forcefully enabled, not supported
>  nand: No NAND device found
>  pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> 
>  This was working around 4.11. I'll try to do some more digging tomorrow
>  to narrow down a failure point but I thought I'd send this out now just
>  in case it rings any bells.
> 
>  The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
>  should be pretty close to the armada-388-db. I can make my dts available
>  if it's helpful.  
> >>>
> >>> Still works on 4.12-rc2. Fails on next-20170524.
> >>>
> >>> This appears to be due to commit b566d9c055de ("mtd: nand: add support
> >>> for Micron on-die ECC"). Which based on the description seems intentional.
> >>>
> >>> Since I have access to a hardware platform that has a micron flash with
> >>> ECC forcefully enabled how can I help to get this implemented.  
> >>
> >> Can you try with this patch applied [1]?  
> > 
> > Sorry, wrong patch. Can you try this one [1] instead?
> > 
> > [1]http://code.bulix.org/pkfhmi-135875
> >   
> 
> With the patch above the chip is detected but ubifs is unhappy

Hm, weird. And if you revert my both Thomas patch and mine, what do you
get?

BTW, can you paste the full boot logs, not only the failing part?

Thanks,

Boris

> 
> ubi0: attaching mtd0
> random: fast init done
> random: crng init done
> ubi0: scanning is finished
> ubi0: attached mtd0 (name "pxa3xx_nand-0", size 1024 MiB)
> ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
> ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
> ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
> ubi0: good PEBs: 4088, bad PEBs: 8, corrupted PEBs: 0
> ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
> ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence 
> number: 1508037110
> ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for 
> bad PEB handling: 72
> ubi0: background thread "ubi_bgt0d" started, PID 597
> UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 601
> UBIFS (ubi0:0): recovery needed
> UBIFS (ubi0:0): recovery completed
> UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "user"
> UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB), min./max. I/O unit 
> sizes: 4096 bytes/4096 bytes
> UBIFS (ubi0:0): FS size: 1016315904 bytes (969 MiB, 4002 LEBs), journal 
> size 9404416 bytes (8 MiB, 38 LEBs)
> UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
> UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID 
> 9D7B5AAA-EFDC-41D4-875B-F9CDB457AE9D, small LPT model
> UBIFS error (ubi0:0 pid 599): ubifs_read_node: bad node type (160 but 
> expected 0)
> UBIFS error (ubi0:0 pid 599): ubifs_read_node: bad node at LEB 10:90344, 
> LEB mapping status 1
> Not a node, first 24 bytes:
> : 00 00 00 00 31 18 10 06 c3 f6 23 f6 3b 00 00 00 00 00 00 00 a0 
> 00 00 00  1.#.;...
> CPU: 1 PID: 599 Comm: mount Not tainted 4.12.0-rc2-next-20170524-at1+ #56
> Hardware name: Marvell Armada 380/385 (Device Tree)
> [<801102dc>] (unwind_backtrace) from [<8010b658>] (show_stack+0x10/0x14)
> [<8010b658>] (show_stack) from [<8031aa0c>] (dump_stack+0x88/0x9c)
> [<8031aa0c>] (dump_stack) from [<802aebb8>] (ubifs_read_node+0x130/0x284)
> [<802aebb8>] (ubifs_read_node) from [<802ca2a4>] 
> (ubifs_tnc_read_node+0x4c/0xd4)
> [<802ca2a4>] (ubifs_tnc_read_node) from [<802b1e60>] 
> (ubifs_tnc_locate+0x1c0/0x1c8)
> [<802b1e60>] (ubifs_tnc_locate) from [<802aa15c>] (ubifs_iget+0x78/0x554)
> [<802aa15c>] (ubifs_iget) from [<802aa90c>] (ubifs_mount+0x2d4/0x1524)
> [<802aa90c>] (ubifs_mount) from [<801dfab4>] (mount_fs+0x14/0xa4)
> [<801dfab4>] (mount_fs) from [<801fa6b4>] (vfs_kern_mount+0x4c/0xf4)
> [<801fa6b4>] (vfs_kern_mount) from [<801fd738>] (do_mount+0x154/0xb50)
> [<801fd738>] (do_mount) from [<801fe49c>] (SyS_mount+0x74/0x9c)
> [<801fe49c>] (SyS_mount) from [<801077a0>] (ret_fast_syscall+0x0/0x3c)
> UBIFS error (ubi0:0 pid 599): ubifs_iget: failed to read inode 1, error -22
> UBIFS (ubi0:0):

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Boris Brezillon 
Le Wed, 24 May 2017 22:03:52 +,
Chris Packham  a écrit :

> On 24/05/17 23:25, Boris Brezillon wrote:
> > On Wed, 24 May 2017 13:23:01 +0200
> > Boris Brezillon  wrote:
> >   
> >> Hi Chris,
> >>
> >> On Wed, 24 May 2017 09:36:56 +
> >> Chris Packham  wrote:
> >>  
> >>> On 23/05/17 17:27, Chris Packham wrote:  
>  Hi,
> 
>  I'm doing some testing on linux-next and I'm finding that my nand flash
>  has disappeared.
> 
>  pxa3xx-nand f10d.flash: This platform can't do DMA on this device
>  pxa3xx-nand f10d.flash: non-supported command ef
>  pxa3xx-nand f10d.flash: non-supported command ee
>  pxa3xx-nand f10d.flash: non-supported command ef
>  pxa3xx-nand f10d.flash: non-supported command ee
>  On-die ECC forcefully enabled, not supported
>  nand: No NAND device found
>  pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> 
>  This was working around 4.11. I'll try to do some more digging tomorrow
>  to narrow down a failure point but I thought I'd send this out now just
>  in case it rings any bells.
> 
>  The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
>  should be pretty close to the armada-388-db. I can make my dts available
>  if it's helpful.  
> >>>
> >>> Still works on 4.12-rc2. Fails on next-20170524.
> >>>
> >>> This appears to be due to commit b566d9c055de ("mtd: nand: add support
> >>> for Micron on-die ECC"). Which based on the description seems intentional.
> >>>
> >>> Since I have access to a hardware platform that has a micron flash with
> >>> ECC forcefully enabled how can I help to get this implemented.  
> >>
> >> Can you try with this patch applied [1]?  
> > 
> > Sorry, wrong patch. Can you try this one [1] instead?
> > 
> > [1]http://code.bulix.org/pkfhmi-135875
> >   
> 
> With the patch above the chip is detected but ubifs is unhappy

Hm, weird. And if you revert my both Thomas patch and mine, what do you
get?

BTW, can you paste the full boot logs, not only the failing part?

Thanks,

Boris

> 
> ubi0: attaching mtd0
> random: fast init done
> random: crng init done
> ubi0: scanning is finished
> ubi0: attached mtd0 (name "pxa3xx_nand-0", size 1024 MiB)
> ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
> ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
> ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
> ubi0: good PEBs: 4088, bad PEBs: 8, corrupted PEBs: 0
> ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
> ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence 
> number: 1508037110
> ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for 
> bad PEB handling: 72
> ubi0: background thread "ubi_bgt0d" started, PID 597
> UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 601
> UBIFS (ubi0:0): recovery needed
> UBIFS (ubi0:0): recovery completed
> UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "user"
> UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB), min./max. I/O unit 
> sizes: 4096 bytes/4096 bytes
> UBIFS (ubi0:0): FS size: 1016315904 bytes (969 MiB, 4002 LEBs), journal 
> size 9404416 bytes (8 MiB, 38 LEBs)
> UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
> UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID 
> 9D7B5AAA-EFDC-41D4-875B-F9CDB457AE9D, small LPT model
> UBIFS error (ubi0:0 pid 599): ubifs_read_node: bad node type (160 but 
> expected 0)
> UBIFS error (ubi0:0 pid 599): ubifs_read_node: bad node at LEB 10:90344, 
> LEB mapping status 1
> Not a node, first 24 bytes:
> : 00 00 00 00 31 18 10 06 c3 f6 23 f6 3b 00 00 00 00 00 00 00 a0 
> 00 00 00  1.#.;...
> CPU: 1 PID: 599 Comm: mount Not tainted 4.12.0-rc2-next-20170524-at1+ #56
> Hardware name: Marvell Armada 380/385 (Device Tree)
> [<801102dc>] (unwind_backtrace) from [<8010b658>] (show_stack+0x10/0x14)
> [<8010b658>] (show_stack) from [<8031aa0c>] (dump_stack+0x88/0x9c)
> [<8031aa0c>] (dump_stack) from [<802aebb8>] (ubifs_read_node+0x130/0x284)
> [<802aebb8>] (ubifs_read_node) from [<802ca2a4>] 
> (ubifs_tnc_read_node+0x4c/0xd4)
> [<802ca2a4>] (ubifs_tnc_read_node) from [<802b1e60>] 
> (ubifs_tnc_locate+0x1c0/0x1c8)
> [<802b1e60>] (ubifs_tnc_locate) from [<802aa15c>] (ubifs_iget+0x78/0x554)
> [<802aa15c>] (ubifs_iget) from [<802aa90c>] (ubifs_mount+0x2d4/0x1524)
> [<802aa90c>] (ubifs_mount) from [<801dfab4>] (mount_fs+0x14/0xa4)
> [<801dfab4>] (mount_fs) from [<801fa6b4>] (vfs_kern_mount+0x4c/0xf4)
> [<801fa6b4>] (vfs_kern_mount) from [<801fd738>] (do_mount+0x154/0xb50)
> [<801fd738>] (do_mount) from [<801fe49c>] (SyS_mount+0x74/0x9c)
> [<801fe49c>] (SyS_mount) from [<801077a0>] (ret_fast_syscall+0x0/0x3c)
> UBIFS error (ubi0:0 pid 599): ubifs_iget: failed to read inode 1, error -22
> UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
> ubi0: detaching mtd0
> ubi0: mtd0 is detached
> ubi0: attaching

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Chris Packham 
On 24/05/17 23:25, Boris Brezillon wrote:
> On Wed, 24 May 2017 13:23:01 +0200
> Boris Brezillon  wrote:
> 
>> Hi Chris,
>>
>> On Wed, 24 May 2017 09:36:56 +
>> Chris Packham  wrote:
>>
>>> On 23/05/17 17:27, Chris Packham wrote:
 Hi,

 I'm doing some testing on linux-next and I'm finding that my nand flash
 has disappeared.

 pxa3xx-nand f10d.flash: This platform can't do DMA on this device
 pxa3xx-nand f10d.flash: non-supported command ef
 pxa3xx-nand f10d.flash: non-supported command ee
 pxa3xx-nand f10d.flash: non-supported command ef
 pxa3xx-nand f10d.flash: non-supported command ee
 On-die ECC forcefully enabled, not supported
 nand: No NAND device found
 pxa3xx-nand f10d.flash: failed to scan nand at cs 0

 This was working around 4.11. I'll try to do some more digging tomorrow
 to narrow down a failure point but I thought I'd send this out now just
 in case it rings any bells.

 The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
 should be pretty close to the armada-388-db. I can make my dts available
 if it's helpful.
>>>
>>> Still works on 4.12-rc2. Fails on next-20170524.
>>>
>>> This appears to be due to commit b566d9c055de ("mtd: nand: add support
>>> for Micron on-die ECC"). Which based on the description seems intentional.
>>>
>>> Since I have access to a hardware platform that has a micron flash with
>>> ECC forcefully enabled how can I help to get this implemented.
>>
>> Can you try with this patch applied [1]?
> 
> Sorry, wrong patch. Can you try this one [1] instead?
> 
> [1]http://code.bulix.org/pkfhmi-135875
> 

With the patch above the chip is detected but ubifs is unhappy

ubi0: attaching mtd0
random: fast init done
random: crng init done
ubi0: scanning is finished
ubi0: attached mtd0 (name "pxa3xx_nand-0", size 1024 MiB)
ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
ubi0: good PEBs: 4088, bad PEBs: 8, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence 
number: 1508037110
ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for 
bad PEB handling: 72
ubi0: background thread "ubi_bgt0d" started, PID 597
UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 601
UBIFS (ubi0:0): recovery needed
UBIFS (ubi0:0): recovery completed
UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "user"
UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB), min./max. I/O unit 
sizes: 4096 bytes/4096 bytes
UBIFS (ubi0:0): FS size: 1016315904 bytes (969 MiB, 4002 LEBs), journal 
size 9404416 bytes (8 MiB, 38 LEBs)
UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID 
9D7B5AAA-EFDC-41D4-875B-F9CDB457AE9D, small LPT model
UBIFS error (ubi0:0 pid 599): ubifs_read_node: bad node type (160 but 
expected 0)
UBIFS error (ubi0:0 pid 599): ubifs_read_node: bad node at LEB 10:90344, 
LEB mapping status 1
Not a node, first 24 bytes:
: 00 00 00 00 31 18 10 06 c3 f6 23 f6 3b 00 00 00 00 00 00 00 a0 
00 00 00  1.#.;...
CPU: 1 PID: 599 Comm: mount Not tainted 4.12.0-rc2-next-20170524-at1+ #56
Hardware name: Marvell Armada 380/385 (Device Tree)
[<801102dc>] (unwind_backtrace) from [<8010b658>] (show_stack+0x10/0x14)
[<8010b658>] (show_stack) from [<8031aa0c>] (dump_stack+0x88/0x9c)
[<8031aa0c>] (dump_stack) from [<802aebb8>] (ubifs_read_node+0x130/0x284)
[<802aebb8>] (ubifs_read_node) from [<802ca2a4>] 
(ubifs_tnc_read_node+0x4c/0xd4)
[<802ca2a4>] (ubifs_tnc_read_node) from [<802b1e60>] 
(ubifs_tnc_locate+0x1c0/0x1c8)
[<802b1e60>] (ubifs_tnc_locate) from [<802aa15c>] (ubifs_iget+0x78/0x554)
[<802aa15c>] (ubifs_iget) from [<802aa90c>] (ubifs_mount+0x2d4/0x1524)
[<802aa90c>] (ubifs_mount) from [<801dfab4>] (mount_fs+0x14/0xa4)
[<801dfab4>] (mount_fs) from [<801fa6b4>] (vfs_kern_mount+0x4c/0xf4)
[<801fa6b4>] (vfs_kern_mount) from [<801fd738>] (do_mount+0x154/0xb50)
[<801fd738>] (do_mount) from [<801fe49c>] (SyS_mount+0x74/0x9c)
[<801fe49c>] (SyS_mount) from [<801077a0>] (ret_fast_syscall+0x0/0x3c)
UBIFS error (ubi0:0 pid 599): ubifs_iget: failed to read inode 1, error -22
UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
ubi0: detaching mtd0
ubi0: mtd0 is detached
ubi0: attaching mtd0
ubi0: scanning is finished
ubi0 error: ubi_read_volume_table: the layout volume was not found
ubi0 error: ubi_attach_mtd_dev: failed to attach mtd0, error -22

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Chris Packham 
On 24/05/17 23:25, Boris Brezillon wrote:
> On Wed, 24 May 2017 13:23:01 +0200
> Boris Brezillon  wrote:
> 
>> Hi Chris,
>>
>> On Wed, 24 May 2017 09:36:56 +
>> Chris Packham  wrote:
>>
>>> On 23/05/17 17:27, Chris Packham wrote:
 Hi,

 I'm doing some testing on linux-next and I'm finding that my nand flash
 has disappeared.

 pxa3xx-nand f10d.flash: This platform can't do DMA on this device
 pxa3xx-nand f10d.flash: non-supported command ef
 pxa3xx-nand f10d.flash: non-supported command ee
 pxa3xx-nand f10d.flash: non-supported command ef
 pxa3xx-nand f10d.flash: non-supported command ee
 On-die ECC forcefully enabled, not supported
 nand: No NAND device found
 pxa3xx-nand f10d.flash: failed to scan nand at cs 0

 This was working around 4.11. I'll try to do some more digging tomorrow
 to narrow down a failure point but I thought I'd send this out now just
 in case it rings any bells.

 The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
 should be pretty close to the armada-388-db. I can make my dts available
 if it's helpful.
>>>
>>> Still works on 4.12-rc2. Fails on next-20170524.
>>>
>>> This appears to be due to commit b566d9c055de ("mtd: nand: add support
>>> for Micron on-die ECC"). Which based on the description seems intentional.
>>>
>>> Since I have access to a hardware platform that has a micron flash with
>>> ECC forcefully enabled how can I help to get this implemented.
>>
>> Can you try with this patch applied [1]?
> 
> Sorry, wrong patch. Can you try this one [1] instead?
> 
> [1]http://code.bulix.org/pkfhmi-135875
> 

With the patch above the chip is detected but ubifs is unhappy

ubi0: attaching mtd0
random: fast init done
random: crng init done
ubi0: scanning is finished
ubi0: attached mtd0 (name "pxa3xx_nand-0", size 1024 MiB)
ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
ubi0: good PEBs: 4088, bad PEBs: 8, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence 
number: 1508037110
ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for 
bad PEB handling: 72
ubi0: background thread "ubi_bgt0d" started, PID 597
UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 601
UBIFS (ubi0:0): recovery needed
UBIFS (ubi0:0): recovery completed
UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "user"
UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB), min./max. I/O unit 
sizes: 4096 bytes/4096 bytes
UBIFS (ubi0:0): FS size: 1016315904 bytes (969 MiB, 4002 LEBs), journal 
size 9404416 bytes (8 MiB, 38 LEBs)
UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID 
9D7B5AAA-EFDC-41D4-875B-F9CDB457AE9D, small LPT model
UBIFS error (ubi0:0 pid 599): ubifs_read_node: bad node type (160 but 
expected 0)
UBIFS error (ubi0:0 pid 599): ubifs_read_node: bad node at LEB 10:90344, 
LEB mapping status 1
Not a node, first 24 bytes:
: 00 00 00 00 31 18 10 06 c3 f6 23 f6 3b 00 00 00 00 00 00 00 a0 
00 00 00  1.#.;...
CPU: 1 PID: 599 Comm: mount Not tainted 4.12.0-rc2-next-20170524-at1+ #56
Hardware name: Marvell Armada 380/385 (Device Tree)
[<801102dc>] (unwind_backtrace) from [<8010b658>] (show_stack+0x10/0x14)
[<8010b658>] (show_stack) from [<8031aa0c>] (dump_stack+0x88/0x9c)
[<8031aa0c>] (dump_stack) from [<802aebb8>] (ubifs_read_node+0x130/0x284)
[<802aebb8>] (ubifs_read_node) from [<802ca2a4>] 
(ubifs_tnc_read_node+0x4c/0xd4)
[<802ca2a4>] (ubifs_tnc_read_node) from [<802b1e60>] 
(ubifs_tnc_locate+0x1c0/0x1c8)
[<802b1e60>] (ubifs_tnc_locate) from [<802aa15c>] (ubifs_iget+0x78/0x554)
[<802aa15c>] (ubifs_iget) from [<802aa90c>] (ubifs_mount+0x2d4/0x1524)
[<802aa90c>] (ubifs_mount) from [<801dfab4>] (mount_fs+0x14/0xa4)
[<801dfab4>] (mount_fs) from [<801fa6b4>] (vfs_kern_mount+0x4c/0xf4)
[<801fa6b4>] (vfs_kern_mount) from [<801fd738>] (do_mount+0x154/0xb50)
[<801fd738>] (do_mount) from [<801fe49c>] (SyS_mount+0x74/0x9c)
[<801fe49c>] (SyS_mount) from [<801077a0>] (ret_fast_syscall+0x0/0x3c)
UBIFS error (ubi0:0 pid 599): ubifs_iget: failed to read inode 1, error -22
UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
ubi0: detaching mtd0
ubi0: mtd0 is detached
ubi0: attaching mtd0
ubi0: scanning is finished
ubi0 error: ubi_read_volume_table: the layout volume was not found
ubi0 error: ubi_attach_mtd_dev: failed to attach mtd0, error -22

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Boris Brezillon 
On Wed, 24 May 2017 13:23:01 +0200
Boris Brezillon  wrote:

> Hi Chris,
> 
> On Wed, 24 May 2017 09:36:56 +
> Chris Packham  wrote:
> 
> > On 23/05/17 17:27, Chris Packham wrote:  
> > > Hi,
> > >
> > > I'm doing some testing on linux-next and I'm finding that my nand flash
> > > has disappeared.
> > >
> > > pxa3xx-nand f10d.flash: This platform can't do DMA on this device
> > > pxa3xx-nand f10d.flash: non-supported command ef
> > > pxa3xx-nand f10d.flash: non-supported command ee
> > > pxa3xx-nand f10d.flash: non-supported command ef
> > > pxa3xx-nand f10d.flash: non-supported command ee
> > > On-die ECC forcefully enabled, not supported
> > > nand: No NAND device found
> > > pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> > >
> > > This was working around 4.11. I'll try to do some more digging tomorrow
> > > to narrow down a failure point but I thought I'd send this out now just
> > > in case it rings any bells.
> > >
> > > The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
> > > should be pretty close to the armada-388-db. I can make my dts available
> > > if it's helpful.
> > 
> > Still works on 4.12-rc2. Fails on next-20170524.
> > 
> > This appears to be due to commit b566d9c055de ("mtd: nand: add support 
> > for Micron on-die ECC"). Which based on the description seems intentional.
> > 
> > Since I have access to a hardware platform that has a micron flash with
> > ECC forcefully enabled how can I help to get this implemented.  
> 
> Can you try with this patch applied [1]?

Sorry, wrong patch. Can you try this one [1] instead?

[1]http://code.bulix.org/pkfhmi-135875

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Boris Brezillon 
On Wed, 24 May 2017 13:23:01 +0200
Boris Brezillon  wrote:

> Hi Chris,
> 
> On Wed, 24 May 2017 09:36:56 +
> Chris Packham  wrote:
> 
> > On 23/05/17 17:27, Chris Packham wrote:  
> > > Hi,
> > >
> > > I'm doing some testing on linux-next and I'm finding that my nand flash
> > > has disappeared.
> > >
> > > pxa3xx-nand f10d.flash: This platform can't do DMA on this device
> > > pxa3xx-nand f10d.flash: non-supported command ef
> > > pxa3xx-nand f10d.flash: non-supported command ee
> > > pxa3xx-nand f10d.flash: non-supported command ef
> > > pxa3xx-nand f10d.flash: non-supported command ee
> > > On-die ECC forcefully enabled, not supported
> > > nand: No NAND device found
> > > pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> > >
> > > This was working around 4.11. I'll try to do some more digging tomorrow
> > > to narrow down a failure point but I thought I'd send this out now just
> > > in case it rings any bells.
> > >
> > > The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
> > > should be pretty close to the armada-388-db. I can make my dts available
> > > if it's helpful.
> > 
> > Still works on 4.12-rc2. Fails on next-20170524.
> > 
> > This appears to be due to commit b566d9c055de ("mtd: nand: add support 
> > for Micron on-die ECC"). Which based on the description seems intentional.
> > 
> > Since I have access to a hardware platform that has a micron flash with
> > ECC forcefully enabled how can I help to get this implemented.  
> 
> Can you try with this patch applied [1]?

Sorry, wrong patch. Can you try this one [1] instead?

[1]http://code.bulix.org/pkfhmi-135875

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Boris Brezillon 
Hi Chris,

On Wed, 24 May 2017 09:36:56 +
Chris Packham  wrote:

> On 23/05/17 17:27, Chris Packham wrote:
> > Hi,
> >
> > I'm doing some testing on linux-next and I'm finding that my nand flash
> > has disappeared.
> >
> > pxa3xx-nand f10d.flash: This platform can't do DMA on this device
> > pxa3xx-nand f10d.flash: non-supported command ef
> > pxa3xx-nand f10d.flash: non-supported command ee
> > pxa3xx-nand f10d.flash: non-supported command ef
> > pxa3xx-nand f10d.flash: non-supported command ee
> > On-die ECC forcefully enabled, not supported
> > nand: No NAND device found
> > pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> >
> > This was working around 4.11. I'll try to do some more digging tomorrow
> > to narrow down a failure point but I thought I'd send this out now just
> > in case it rings any bells.
> >
> > The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
> > should be pretty close to the armada-388-db. I can make my dts available
> > if it's helpful.  
> 
> Still works on 4.12-rc2. Fails on next-20170524.
> 
> This appears to be due to commit b566d9c055de ("mtd: nand: add support 
> for Micron on-die ECC"). Which based on the description seems intentional.
> 
> Since I have access to a hardware platform that has a micron flash with
> ECC forcefully enabled how can I help to get this implemented.

Can you try with this patch applied [1]?

Thanks,

Boris

[1]http://code.bulix.org/eic5n9-135873

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Boris Brezillon 
Hi Chris,

On Wed, 24 May 2017 09:36:56 +
Chris Packham  wrote:

> On 23/05/17 17:27, Chris Packham wrote:
> > Hi,
> >
> > I'm doing some testing on linux-next and I'm finding that my nand flash
> > has disappeared.
> >
> > pxa3xx-nand f10d.flash: This platform can't do DMA on this device
> > pxa3xx-nand f10d.flash: non-supported command ef
> > pxa3xx-nand f10d.flash: non-supported command ee
> > pxa3xx-nand f10d.flash: non-supported command ef
> > pxa3xx-nand f10d.flash: non-supported command ee
> > On-die ECC forcefully enabled, not supported
> > nand: No NAND device found
> > pxa3xx-nand f10d.flash: failed to scan nand at cs 0
> >
> > This was working around 4.11. I'll try to do some more digging tomorrow
> > to narrow down a failure point but I thought I'd send this out now just
> > in case it rings any bells.
> >
> > The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
> > should be pretty close to the armada-388-db. I can make my dts available
> > if it's helpful.  
> 
> Still works on 4.12-rc2. Fails on next-20170524.
> 
> This appears to be due to commit b566d9c055de ("mtd: nand: add support 
> for Micron on-die ECC"). Which based on the description seems intentional.
> 
> Since I have access to a hardware platform that has a micron flash with
> ECC forcefully enabled how can I help to get this implemented.

Can you try with this patch applied [1]?

Thanks,

Boris

[1]http://code.bulix.org/eic5n9-135873

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Chris Packham 
On 23/05/17 17:27, Chris Packham wrote:
> Hi,
>
> I'm doing some testing on linux-next and I'm finding that my nand flash
> has disappeared.
>
> pxa3xx-nand f10d.flash: This platform can't do DMA on this device
> pxa3xx-nand f10d.flash: non-supported command ef
> pxa3xx-nand f10d.flash: non-supported command ee
> pxa3xx-nand f10d.flash: non-supported command ef
> pxa3xx-nand f10d.flash: non-supported command ee
> On-die ECC forcefully enabled, not supported
> nand: No NAND device found
> pxa3xx-nand f10d.flash: failed to scan nand at cs 0
>
> This was working around 4.11. I'll try to do some more digging tomorrow
> to narrow down a failure point but I thought I'd send this out now just
> in case it rings any bells.
>
> The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
> should be pretty close to the armada-388-db. I can make my dts available
> if it's helpful.

Still works on 4.12-rc2. Fails on next-20170524.

This appears to be due to commit b566d9c055de ("mtd: nand: add support 
for Micron on-die ECC"). Which based on the description seems intentional.

Since I have access to a hardware platform that has a micron flash with
ECC forcefully enabled how can I help to get this implemented.

Re: pxa3xx-nand failing to find device on linux-next

2017-05-24 Thread Chris Packham 
On 23/05/17 17:27, Chris Packham wrote:
> Hi,
>
> I'm doing some testing on linux-next and I'm finding that my nand flash
> has disappeared.
>
> pxa3xx-nand f10d.flash: This platform can't do DMA on this device
> pxa3xx-nand f10d.flash: non-supported command ef
> pxa3xx-nand f10d.flash: non-supported command ee
> pxa3xx-nand f10d.flash: non-supported command ef
> pxa3xx-nand f10d.flash: non-supported command ee
> On-die ECC forcefully enabled, not supported
> nand: No NAND device found
> pxa3xx-nand f10d.flash: failed to scan nand at cs 0
>
> This was working around 4.11. I'll try to do some more digging tomorrow
> to narrow down a failure point but I thought I'd send this out now just
> in case it rings any bells.
>
> The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
> should be pretty close to the armada-388-db. I can make my dts available
> if it's helpful.

Still works on 4.12-rc2. Fails on next-20170524.

This appears to be due to commit b566d9c055de ("mtd: nand: add support 
for Micron on-die ECC"). Which based on the description seems intentional.

Since I have access to a hardware platform that has a micron flash with
ECC forcefully enabled how can I help to get this implemented.