N25Q256A 13E40

[Marek Vasut]

Hi Brian,

> On Mon, Oct 7, 2013 at 9:24 AM, Marek Vasut <marex at denx.de> wrote:
> > Let's talk about our favourite chip :) I just got my hands on N25Q256A .
> > Since there was quite a flurry of patches for this and similar chips and
> > I got it working on a different chip with exactly the same IDs and type,
> > I'd would expect linux to work with this one too. Guess what ... ;-)
> > 
> > This particular incarnation of N25Q256A completely ignores the 4-byte
> > ERASE (0xdc) command. Apparently, if I look closely, it's N25Q256A 13E40
> > variant and seeing the Note #14 (datasheet page 30 / below Table 18.
> > Command set), quoting:
> > 
> > 14.This command is only for part numbers N25Q256A83ESF40x and
> > N25Q256A83E1240x.
> 
> This note also applies to PAGE_PROGRAM_4B (0x12) as well, right?

Yeah, both ERASE_4B and PP_4B or whatever they're called there. Interestingly 
enough, READ_4B works ;-/

> > they are not supported on this part. Someone surely did some hard
> > thinking inventing such a crappy part.
> 
> Yeah, we were already seeing this kind of inconsistency. I recall
> Micron saying that they tried to make the N25Q256A83xx... parts
> compatible with Macronix. Why they didn't just do that for the whole
> product line is anybody's guess...
> 
> > I can surely cook a patch, but I wonder what
> > direction we should take here. We can switch this chip into 4-byte mode
> > by 0xb7/0xe9 opcodes, which would in turn break BootROMs which depend on
> > the SPI NOR to be in 3-byte mode upon reboot. We can program the BAR
> > register before erase, which will do the same.
> > 
> > Sigh, if you have any idea, that'd be nice to hear.
> 
> Is there any way to differentiate the N25Q256Axx... flavors by ID or
> similar? (I believe I know the answer to this already, and it's not
> the answer I want.)

You can look at the top of the chip and read the label on top of it ;-/ But 
software-wise, no, there's no way to tell the crap ones from the not-crap ones.

> I don't think we want to start using the BAR. I think the 0xb7/0xe9
> opcodes are best (if we really have to...), since we already support
> them, and we never really *guarantee* that m25p80.c will leave the
> flash in 3-byte mode. It was just an added bonus that we are able to
> be mode-less on some flash.

Good point.

> [Now that I went back to look at some more code:] Wait, but we don't
> even try to use the 4-byte dedicated commands like 0xdc on Micron
> flash, so why are you having this problem? The code currently stands
> as:

The JEDEC_MFR for this flash Micron N25Q256A is CFI_MFR_ST (I wonder why).

>   if (JEDEC_MFR(info->jedec_id) == CFI_MFR_AMD) {
>           /* Dedicated 4-byte command set */
>           ...
> 
> They are only used on Spansion. IIRC, I wrote it this way specifically
> because Micron is so inconsistent, at least on their current
> generation (they're fixing that for the future, I think, but that
> doesn't help us of course). And I haven't had a chance to look at
> others too closely to judge them on this.

Spansion is good indeed, they always worked as they should have and were 
consistent.

Best regards,
Marek Vasut