Forums

Amtel SAM9 "boot from NAND" is a myth?

Started by Grant Edwards September 15, 2010
We recently based a board on an Atmel AT91SAM9G20 part which the FAE
and rep said could boot from NAND flash.  The eval board can indeed be
configured to boot from NAND flash.  However, when it comes time to
spec parts for a real product, we find that's all smoke and mirrors.

The Atmel SAM9 parts require that block 0 be completely free of bit
errors since the ROM bootloader doesn't do ECC (despite the fact that
the part does have hardware ECC support).  So you have to use a NAND
flash that guarantees a good block 0 _without_using_ECC_.  It turns
out those sorts of NAND flash parts appear to be made of a combination
of Unicorn's horn and Unobtanium.  IOW, they don't exist.  At least
that's what the flash distributor and rep tell us.

What was Amtel thinking when they decided not to do ECC when reading
NAND flash?  I realize Atmel doesn't make NAND flash, but surely they
must have been aware that NAND flash parts aren't spec'ed to be
fault-free by the flash vendors.

My opinion?  It's a way for Atmel to suck you in and then after you
get the unpleasant surprise that you _can't_ boot from NAND, they try
to sell you a serial dataflash part you don't really want.

OTOH, TI did it right in their OMAP parts: not only does the
bootloader do ECC, it also will skip blocks that have uncorrectable
errors.

  Atmel:  Block 0 must be good without ECC

     TI:  _Any_ of blocks 0,1,2,3 must be good _with_ ECC

Which do you think is going to work better?
     
-- 
Grant Edwards               grant.b.edwards        Yow! It's a lot of fun
                                  at               being alive ... I wonder if
                              gmail.com            my bed is made?!?
On Wed, 15 Sep 2010 19:23:39 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>We recently based a board on an Atmel AT91SAM9G20 part which the FAE >and rep said could boot from NAND flash. The eval board can indeed be >configured to boot from NAND flash. However, when it comes time to >spec parts for a real product, we find that's all smoke and mirrors. > >The Atmel SAM9 parts require that block 0 be completely free of bit >errors since the ROM bootloader doesn't do ECC (despite the fact that >the part does have hardware ECC support). So you have to use a NAND >flash that guarantees a good block 0 _without_using_ECC_. It turns >out those sorts of NAND flash parts appear to be made of a combination >of Unicorn's horn and Unobtanium. IOW, they don't exist. At least >that's what the flash distributor and rep tell us. > >What was Amtel thinking when they decided not to do ECC when reading >NAND flash? I realize Atmel doesn't make NAND flash, but surely they >must have been aware that NAND flash parts aren't spec'ed to be >fault-free by the flash vendors. > >My opinion? It's a way for Atmel to suck you in and then after you >get the unpleasant surprise that you _can't_ boot from NAND, they try >to sell you a serial dataflash part you don't really want. > >OTOH, TI did it right in their OMAP parts: not only does the >bootloader do ECC, it also will skip blocks that have uncorrectable >errors. > > Atmel: Block 0 must be good without ECC > > TI: _Any_ of blocks 0,1,2,3 must be good _with_ ECC > >Which do you think is going to work better?
Cripes. Hopefully, Ulf will take a moment to provide a frank and complete response to your experiences here. Jon
On 09/15/2010 12:23 PM, Grant Edwards wrote:
> We recently based a board on an Atmel AT91SAM9G20 part which the FAE > and rep said could boot from NAND flash. The eval board can indeed be > configured to boot from NAND flash. However, when it comes time to > spec parts for a real product, we find that's all smoke and mirrors. > > The Atmel SAM9 parts require that block 0 be completely free of bit > errors since the ROM bootloader doesn't do ECC (despite the fact that > the part does have hardware ECC support). So you have to use a NAND > flash that guarantees a good block 0 _without_using_ECC_. It turns > out those sorts of NAND flash parts appear to be made of a combination > of Unicorn's horn and Unobtanium. IOW, they don't exist. At least > that's what the flash distributor and rep tell us. > > What was Amtel thinking when they decided not to do ECC when reading > NAND flash? I realize Atmel doesn't make NAND flash, but surely they > must have been aware that NAND flash parts aren't spec'ed to be > fault-free by the flash vendors. > > My opinion? It's a way for Atmel to suck you in and then after you > get the unpleasant surprise that you _can't_ boot from NAND, they try > to sell you a serial dataflash part you don't really want.
Product Marketing: "We need to boot from NAND flash" Engineering: "We're six months away from tape out, you can't add a new feature now" Product Marketing: "Men women and children will die if you don't make this work" Engineering: "Well, get the executive cadre to move tape out by nine months and we'll do the job right" Product Marketing: "We can't do that. Just make it work or you're all fired". Engineering: "OK..."
> OTOH, TI did it right in their OMAP parts: not only does the > bootloader do ECC, it also will skip blocks that have uncorrectable > errors. > > Atmel: Block 0 must be good without ECC > > TI: _Any_ of blocks 0,1,2,3 must be good _with_ ECC > > Which do you think is going to work better? >
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
On Sep 15, 4:10=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On 09/15/2010 12:23 PM, Grant Edwards wrote: > > > > > We recently based a board on an Atmel AT91SAM9G20 part which the FAE > > and rep said could boot from NAND flash. =A0The eval board can indeed b=
e
> > configured to boot from NAND flash. =A0However, when it comes time to > > spec parts for a real product, we find that's all smoke and mirrors. > > > The Atmel SAM9 parts require that block 0 be completely free of bit > > errors since the ROM bootloader doesn't do ECC (despite the fact that > > the part does have hardware ECC support). =A0So you have to use a NAND > > flash that guarantees a good block 0 _without_using_ECC_. =A0It turns > > out those sorts of NAND flash parts appear to be made of a combination > > of Unicorn's horn and Unobtanium. =A0IOW, they don't exist. =A0At least > > that's what the flash distributor and rep tell us. > > > What was Amtel thinking when they decided not to do ECC when reading > > NAND flash? =A0I realize Atmel doesn't make NAND flash, but surely they > > must have been aware that NAND flash parts aren't spec'ed to be > > fault-free by the flash vendors. > > > My opinion? =A0It's a way for Atmel to suck you in and then after you > > get the unpleasant surprise that you _can't_ boot from NAND, they try > > to sell you a serial dataflash part you don't really want. > > Product Marketing: > "We need to boot from NAND flash" > > Engineering: > "We're six months away from tape out, you can't add a new feature now" > > Product Marketing: > "Men women and children will die if you don't make this work" > > Engineering: > "Well, get the executive cadre to move tape out by nine months and we'll > do the job right" > > Product Marketing: > "We can't do that. =A0Just make it work or you're all fired". > > Engineering: > "OK..."
Which Dilbert book is this from? Only trouble is, marketing can't fire anyone in engineering... as much as they might like to. This sort of program uses all manner of concept, requirement and specification documents. But that is no replacement for thinking. This is just something that no one thought about at the time. Maybe I"m showing my ignorance, but I thought the ECC was ON the flash part and was hidden from the MCU. Is that being turned off or did I miss something in how NAND flash works? Rick
On 09/15/2010 03:19 PM, rickman wrote:
> On Sep 15, 4:10 pm, Tim Wescott<t...@seemywebsite.com> wrote: >> On 09/15/2010 12:23 PM, Grant Edwards wrote: >> >> >> >>> We recently based a board on an Atmel AT91SAM9G20 part which the FAE >>> and rep said could boot from NAND flash. The eval board can indeed be >>> configured to boot from NAND flash. However, when it comes time to >>> spec parts for a real product, we find that's all smoke and mirrors. >> >>> The Atmel SAM9 parts require that block 0 be completely free of bit >>> errors since the ROM bootloader doesn't do ECC (despite the fact that >>> the part does have hardware ECC support). So you have to use a NAND >>> flash that guarantees a good block 0 _without_using_ECC_. It turns >>> out those sorts of NAND flash parts appear to be made of a combination >>> of Unicorn's horn and Unobtanium. IOW, they don't exist. At least >>> that's what the flash distributor and rep tell us. >> >>> What was Amtel thinking when they decided not to do ECC when reading >>> NAND flash? I realize Atmel doesn't make NAND flash, but surely they >>> must have been aware that NAND flash parts aren't spec'ed to be >>> fault-free by the flash vendors. >> >>> My opinion? It's a way for Atmel to suck you in and then after you >>> get the unpleasant surprise that you _can't_ boot from NAND, they try >>> to sell you a serial dataflash part you don't really want. >> >> Product Marketing: >> "We need to boot from NAND flash" >> >> Engineering: >> "We're six months away from tape out, you can't add a new feature now" >> >> Product Marketing: >> "Men women and children will die if you don't make this work" >> >> Engineering: >> "Well, get the executive cadre to move tape out by nine months and we'll >> do the job right" >> >> Product Marketing: >> "We can't do that. Just make it work or you're all fired". >> >> Engineering: >> "OK..." > > Which Dilbert book is this from? Only trouble is, marketing can't > fire anyone in engineering... as much as they might like to. > > This sort of program uses all manner of concept, requirement and > specification documents. But that is no replacement for thinking. > This is just something that no one thought about at the time. > > Maybe I"m showing my ignorance, but I thought the ECC was ON the flash > part and was hidden from the MCU. Is that being turned off or did I > miss something in how NAND flash works?
The last time I looked at NAND flash the ECC part was just extra bits in each record -- it was your job to fill them in on writes and interpret them on reads. Of course, that was 5-10 years ago. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
On 2010-09-15, Tim Wescott <tim@seemywebsite.com> wrote:
> On 09/15/2010 03:19 PM, rickman wrote: >> On Sep 15, 4:10 pm, Tim Wescott<t...@seemywebsite.com> wrote: >>> On 09/15/2010 12:23 PM, Grant Edwards wrote:
>>>> What was Amtel thinking when they decided not to do ECC when reading >>>> NAND flash? I realize Atmel doesn't make NAND flash, but surely they >>>> must have been aware that NAND flash parts aren't spec'ed to be >>>> fault-free by the flash vendors. >>> >>>> My opinion? It's a way for Atmel to suck you in and then after you >>>> get the unpleasant surprise that you _can't_ boot from NAND, they try >>>> to sell you a serial dataflash part you don't really want.
>> This sort of program uses all manner of concept, requirement and >> specification documents. But that is no replacement for thinking. >> This is just something that no one thought about at the time.
Then somebody screwed up, becuase it was their job to think about that sort of thing.
>> Maybe I"m showing my ignorance, but I thought the ECC was ON the >> flash part and was hidden from the MCU.
Not in any of the NAND flash datasheets I've seen.
>> Is that being turned off or did I miss something in how NAND flash >> works? > > The last time I looked at NAND flash the ECC part was just extra bits > in each record -- it was your job to fill them in on writes and > interpret them on reads.
Yup. And the NAND controller in the SAM9 part _has_ hardware that generates the ECC bits when you do a write operation. All you hvae to do is write them into the "extra" bits in the flash after you've written the data. Reading is a bit more complex, since there's extra work required to correct an error when one is detected.
> Of course, that was 5-10 years ago.
It's still that way. There may be NAND parts that do ECC themselves, but I've never seen one. -- Grant
Grant Edwards wrote:
> The Atmel SAM9 parts require that block 0 be completely free of bit > errors since the ROM bootloader doesn't do ECC (despite the fact that > the part does have hardware ECC support). So you have to use a NAND > flash that guarantees a good block 0 _without_using_ECC_. It turns > out those sorts of NAND flash parts appear to be made of a combination > of Unicorn's horn and Unobtanium. IOW, they don't exist. At least > that's what the flash distributor and rep tell us.
For what it's worth, Micron MT29FxGxx has a guaranteed good block 0.
On Sep 15, 3:23=A0pm, Grant Edwards <inva...@invalid.invalid> wrote:

> The Atmel SAM9 parts require that block 0 be completely free of bit > errors since the ROM bootloader doesn't do ECC (despite the fact that
This is not unprecedented. In fact the original SSFDC specification, I believe, had the same requirement (it has been a VERY long time, but IIRC the first block had to contain the CIS, and it had to be 100% free of errors, both correctable and uncorrectable). We're shipping a product based on a micro with the same limitation. I believe bad block 0s are treated as a normal production yield issue (the parts are programmed in-circuit). I also think the i.MXxxxxxxxx family from Freescale has the same requirement. Anyway it's definitely not the first time I've heard it mentioned.
> My opinion? =A0It's a way for Atmel to suck you in and then after you > get the unpleasant surprise that you _can't_ boot from NAND, they try > to sell you a serial dataflash part you don't really want.
Never attribute to malice that which can adequately be explained by stupidity. And I doubt DataFlash is a major revenue generator for Atmel.
On Sep 15, 7:46=A0pm, Grant Edwards <inva...@invalid.invalid> wrote:

> It's still that way. =A0There may be NAND parts that do ECC themselves, > but I've never seen one.
The idea of NAND is cheap bulk storage, no on-chip smarts, move the cost into the main micro.
Grant Edwards <invalid@invalid.invalid> wrote:
> The Atmel SAM9 parts require that block 0 be completely free of bit > errors since the ROM bootloader doesn't do ECC (despite the fact that > the part does have hardware ECC support).
At least Samsung's S3C2440A has the same requirement. -a