[EXT] Re: [PATCH 2/2] mtd: rawnand: micron: Fix on-die ECC detection logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 12 Jul 2018 08:40:33 +0000
"Bean Huo (beanhuo)" <beanhuo at micron.com> wrote:

> Hi, Boris
> It is true. Bit7 of byte4 in READID changes after enable/disable internal ECC in case of  its default value is 0. 
> Also this bit value  is volatile. After power cyling, it resets to default value.

That's actually a good thing that ECC status get resets on PoR. I'd
wish that would be the case when issuing a SW reset (RESET command),
but unfortunately it's not.

> I don't know if
> this condition will be changed or kept since maybe it was a specific design request from customers.
> But GET Feature is still the preferred way to determine the state of ECC, we recommend using this way. 
> If internal ECC is default on, we don't do anything, and if default is off, then SET feature and GET feature.
> This always makes sense.

No, it doesn't work. When Linux acquires control on the NAND, we don't
know what was done before (maybe u-boot enabled ECC and didn't disable
it), so checking READID[4].bit7 only does not work. We need to first
disable the ECC through the SET_FEATURES(DIS_ECC) and then check the
READID bytes.

Also, using GET_FEATURES() does not work either, because Micron NANDs
with "forced on-die ECC" do not expose the ECC status in the 0x90
(Array Operation Mode) feature reg. So if we do that we report ECC as
always disabled which means "not supported"

> 
> I am still digging into why this doesn't depict in datasheet and whether this will be kept in coming design.
> As long I have new update, I will back to you.

Arrrggg! Please don't change that in future designs. We seem to have
something that works to detect whether on-die ECC is supported and if
it can be disabled.



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux