public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard)
@ 2012-02-29 12:12 Orjan Friberg
  2012-02-29 21:00 ` Scott Wood
  0 siblings, 1 reply; 6+ messages in thread
From: Orjan Friberg @ 2012-02-29 12:12 UTC (permalink / raw)
  To: u-boot

For the beagleboard, ecc.size is not explicitly set when doing 'nandecc 
sw'.  If it's not set for the NAND_ECC_SOFT case in nand_scan_tail, it's 
set to 256 bytes.

When doing 'nandecc hw', ecc.size is set to 512 bytes.  Hence, when 
changing back to 'nandecc sw' ecc.size remains at 512 bytes and suddenly 
the format has changed.


It seems the current nandecc command needs to set this explicitly, but 
also needs to be augmented to be able to select the newly added 4/8-bit 
BCH ECC.

But it also seems like nandecc selection should be more generic than for 
omap3 (currently it lives in arch/arm/cpu/armv7/omap3/board.c).


I have seen that TI did some work on this previously in the 
PSP04.02.00.07 release of u-boot and linux (2.6.37).

Is there ongoing work in this area?  I'd be happy to help out if I can.

(I noticed the nand dump.oob seems to have been fixed in the 
u-boot-nand-flash repo.)


Thanks,
Orjan

-- 
Orjan Friberg
FlatFrog Laboratories AB

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard)
  2012-02-29 12:12 [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard) Orjan Friberg
@ 2012-02-29 21:00 ` Scott Wood
  2012-03-01  9:17   ` Orjan Friberg
  2012-03-05 18:58   ` Tom Rini
  0 siblings, 2 replies; 6+ messages in thread
From: Scott Wood @ 2012-02-29 21:00 UTC (permalink / raw)
  To: u-boot

On 02/29/2012 06:12 AM, Orjan Friberg wrote:
> For the beagleboard, ecc.size is not explicitly set when doing 'nandecc
> sw'.  If it's not set for the NAND_ECC_SOFT case in nand_scan_tail, it's
> set to 256 bytes.
> 
> When doing 'nandecc hw', ecc.size is set to 512 bytes.  Hence, when
> changing back to 'nandecc sw' ecc.size remains at 512 bytes and suddenly
> the format has changed.
> 
> 
> It seems the current nandecc command needs to set this explicitly, but
> also needs to be augmented to be able to select the newly added 4/8-bit
> BCH ECC.

Yes, that looks like a bug in omap_nand_switch_ecc().

> But it also seems like nandecc selection should be more generic than for
> omap3 (currently it lives in arch/arm/cpu/armv7/omap3/board.c).

ECC mode is normally not something that you want to be runtime
switchable, as changing it usually changes the on-flash format.  It also
requires driver cooperation -- the actual implementation (as opposed to
the command-line wrapper) is in drivers/mtd/nand/omap_gpmc.c.

If we end up with multiple drivers that need to expose this sort of
functionality, maybe we can consider moving the command line wrapper to
common code.

-Scott

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard)
  2012-02-29 21:00 ` Scott Wood
@ 2012-03-01  9:17   ` Orjan Friberg
  2012-03-01 17:32     ` Scott Wood
  2012-03-05 18:58   ` Tom Rini
  1 sibling, 1 reply; 6+ messages in thread
From: Orjan Friberg @ 2012-03-01  9:17 UTC (permalink / raw)
  To: u-boot

On 02/29/2012 10:00 PM, Scott Wood wrote:
> ECC mode is normally not something that you want to be runtime
> switchable, as changing it usually changes the on-flash format.  It also
> requires driver cooperation -- the actual implementation (as opposed to
> the command-line wrapper) is in drivers/mtd/nand/omap_gpmc.c.

Are you saying that it shouldn't be switchable through a command line 
option (but rather based on information in the partition table or 
something similar), or are you saying that we shouldn't need different 
ECC modes for different parts of the flash (boot ROM vs. software 
implementations, whether block 0 has different ECC requirement etc)?


-- 
Orjan Friberg
FlatFrog Laboratories AB

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard)
  2012-03-01  9:17   ` Orjan Friberg
@ 2012-03-01 17:32     ` Scott Wood
  2012-03-02  8:39       ` Orjan Friberg
  0 siblings, 1 reply; 6+ messages in thread
From: Scott Wood @ 2012-03-01 17:32 UTC (permalink / raw)
  To: u-boot

On 03/01/2012 03:17 AM, Orjan Friberg wrote:
> On 02/29/2012 10:00 PM, Scott Wood wrote:
>> ECC mode is normally not something that you want to be runtime
>> switchable, as changing it usually changes the on-flash format.  It also
>> requires driver cooperation -- the actual implementation (as opposed to
>> the command-line wrapper) is in drivers/mtd/nand/omap_gpmc.c.
> 
> Are you saying that it shouldn't be switchable through a command line
> option (but rather based on information in the partition table or
> something similar), or are you saying that we shouldn't need different
> ECC modes for different parts of the flash (boot ROM vs. software
> implementations, whether block 0 has different ECC requirement etc)?

I'm saying that right now it's an OMAP-specific requirement and the
implementation of necessity involves the OMAP driver.  If another driver
grows this as a requirement, we can consider refactoring so the command
line frontend is common.

Different ECC modes for different parts of the flash is unfortunate, but
sometimes mandated by circumstance.  The NAND subsystem isn't really set
up to handle this, though changing it temporally is a hackish substitute.

-Scott

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard)
  2012-03-01 17:32     ` Scott Wood
@ 2012-03-02  8:39       ` Orjan Friberg
  0 siblings, 0 replies; 6+ messages in thread
From: Orjan Friberg @ 2012-03-02  8:39 UTC (permalink / raw)
  To: u-boot

On 03/01/2012 06:32 PM, Scott Wood wrote:
> I'm saying that right now it's an OMAP-specific requirement and the
> implementation of necessity involves the OMAP driver.  If another driver
> grows this as a requirement, we can consider refactoring so the command
> line frontend is common.
>
> Different ECC modes for different parts of the flash is unfortunate, but
> sometimes mandated by circumstance.  The NAND subsystem isn't really set
> up to handle this, though changing it temporally is a hackish substitute.

Ok, thanks for clarifying.

-- 
Orjan Friberg
FlatFrog Laboratories AB

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard)
  2012-02-29 21:00 ` Scott Wood
  2012-03-01  9:17   ` Orjan Friberg
@ 2012-03-05 18:58   ` Tom Rini
  1 sibling, 0 replies; 6+ messages in thread
From: Tom Rini @ 2012-03-05 18:58 UTC (permalink / raw)
  To: u-boot

On Wed, Feb 29, 2012 at 03:00:49PM -0600, Scott Wood wrote:
> On 02/29/2012 06:12 AM, Orjan Friberg wrote:
> > For the beagleboard, ecc.size is not explicitly set when doing 'nandecc
> > sw'.  If it's not set for the NAND_ECC_SOFT case in nand_scan_tail, it's
> > set to 256 bytes.
> > 
> > When doing 'nandecc hw', ecc.size is set to 512 bytes.  Hence, when
> > changing back to 'nandecc sw' ecc.size remains at 512 bytes and suddenly
> > the format has changed.
> > 
> > 
> > It seems the current nandecc command needs to set this explicitly, but
> > also needs to be augmented to be able to select the newly added 4/8-bit
> > BCH ECC.
> 
> Yes, that looks like a bug in omap_nand_switch_ecc().

Correct.  And wrt using the new 4/8/16-bit BCH library, that's what I
was starting on when I found the nand dump issue :)

> > But it also seems like nandecc selection should be more generic than for
> > omap3 (currently it lives in arch/arm/cpu/armv7/omap3/board.c).
> 
> ECC mode is normally not something that you want to be runtime
> switchable, as changing it usually changes the on-flash format.  It also
> requires driver cooperation -- the actual implementation (as opposed to
> the command-line wrapper) is in drivers/mtd/nand/omap_gpmc.c.

There is unfortunately a long-running saga here and what we have now is
what we have for a number of existing platforms.  Moving forward, things
are better and there's an argument at least for not making ECC mode
switching a run-time command.

-- 
Tom

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-03-05 18:58 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-29 12:12 [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard) Orjan Friberg
2012-02-29 21:00 ` Scott Wood
2012-03-01  9:17   ` Orjan Friberg
2012-03-01 17:32     ` Scott Wood
2012-03-02  8:39       ` Orjan Friberg
2012-03-05 18:58   ` Tom Rini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox