* N25Q256A 13E40
@ 2013-10-07 16:24 Marek Vasut
2013-10-09 1:05 ` Brian Norris
0 siblings, 1 reply; 6+ messages in thread
From: Marek Vasut @ 2013-10-07 16:24 UTC (permalink / raw
To: linux-mtd@lists.infradead.org; +Cc: Artem Bityutskiy, Brian Norris
Hi guys!
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.
they are not supported on this part. Someone surely did some hard thinking
inventing such a crappy part. 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.
Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: N25Q256A 13E40
2013-10-07 16:24 N25Q256A 13E40 Marek Vasut
@ 2013-10-09 1:05 ` Brian Norris
2013-10-09 10:14 ` Marek Vasut
0 siblings, 1 reply; 6+ messages in thread
From: Brian Norris @ 2013-10-09 1:05 UTC (permalink / raw
To: Marek Vasut; +Cc: Artem Bityutskiy, linux-mtd@lists.infradead.org
On Mon, Oct 7, 2013 at 9:24 AM, Marek Vasut <marex@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?
> 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.)
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.
[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:
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.
Brian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: N25Q256A 13E40
2013-10-09 1:05 ` Brian Norris
@ 2013-10-09 10:14 ` Marek Vasut
2013-10-09 21:44 ` Brian Norris
0 siblings, 1 reply; 6+ messages in thread
From: Marek Vasut @ 2013-10-09 10:14 UTC (permalink / raw
To: Brian Norris; +Cc: Artem Bityutskiy, linux-mtd@lists.infradead.org
Hi Brian,
> On Mon, Oct 7, 2013 at 9:24 AM, Marek Vasut <marex@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: N25Q256A 13E40
2013-10-09 10:14 ` Marek Vasut
@ 2013-10-09 21:44 ` Brian Norris
2013-10-12 1:17 ` Marek Vasut
0 siblings, 1 reply; 6+ messages in thread
From: Brian Norris @ 2013-10-09 21:44 UTC (permalink / raw
To: Marek Vasut; +Cc: Artem Bityutskiy, linux-mtd@lists.infradead.org
Hi,
On Wed, Oct 09, 2013 at 12:14:02PM +0200, Marek Vasut wrote:
> > On Mon, Oct 7, 2013 at 9:24 AM, Marek Vasut <marex@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 ;-/
Well, the READ_4B consistency is (unintentionally?) helpful for my
systems, as we have begun implementing a jumper switch so that the boot
ROM will know whether to use FAST_READ or FAST_READ_4B. Since
essentially all large SPI flash at *least* support the READ_4B command
(as you noted), we can reliably boot from the flash, no matter what mode
it is left in. After booting, we can choose the appropriate mode for
programming/erasing.
> > [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).
Probably some series of acquisitions?
But you didn't quite answer my question. Are you having problems with
this Micron/ST/something-that's-not-AMD-or-Spansion flash using the
current mainline? Or did you only have trouble when you tried modifying
the code to use the dedicated 4-byte addressing commands?
> > if (JEDEC_MFR(info->jedec_id) == CFI_MFR_AMD) {
> > /* Dedicated 4-byte command set */
> > ...
Brian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: N25Q256A 13E40
2013-10-09 21:44 ` Brian Norris
@ 2013-10-12 1:17 ` Marek Vasut
2013-10-15 17:22 ` Brian Norris
0 siblings, 1 reply; 6+ messages in thread
From: Marek Vasut @ 2013-10-12 1:17 UTC (permalink / raw
To: Brian Norris; +Cc: Artem Bityutskiy, linux-mtd@lists.infradead.org
Hi Brian,
Sorry for the late reply :(
> Hi,
>
> On Wed, Oct 09, 2013 at 12:14:02PM +0200, Marek Vasut wrote:
> > > On Mon, Oct 7, 2013 at 9:24 AM, Marek Vasut <marex@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 ;-/
>
> Well, the READ_4B consistency is (unintentionally?) helpful for my
> systems, as we have begun implementing a jumper switch so that the boot
> ROM will know whether to use FAST_READ or FAST_READ_4B. Since
> essentially all large SPI flash at *least* support the READ_4B command
> (as you noted), we can reliably boot from the flash, no matter what mode
> it is left in. After booting, we can choose the appropriate mode for
> programming/erasing.
I wish I had such a bootrom. In my case (freescale imx28), the bootrom can just
do 3-byte operation and that's it. I believe the only way around here is to
power-cycle the spi flash before the bootrom starts using it.
> > > [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).
>
> Probably some series of acquisitions?
>
> But you didn't quite answer my question. Are you having problems with
> this Micron/ST/something-that's-not-AMD-or-Spansion flash using the
> current mainline? Or did you only have trouble when you tried modifying
> the code to use the dedicated 4-byte addressing commands?
Urgh, I just noticed I did exactly this. I modified the driver to enable this 4-
byte opcodes and then just forgot about it. Pardon my stupidity :(
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: N25Q256A 13E40
2013-10-12 1:17 ` Marek Vasut
@ 2013-10-15 17:22 ` Brian Norris
0 siblings, 0 replies; 6+ messages in thread
From: Brian Norris @ 2013-10-15 17:22 UTC (permalink / raw
To: Marek Vasut; +Cc: Artem Bityutskiy, linux-mtd@lists.infradead.org
Hi Marek,
On Fri, Oct 11, 2013 at 6:17 PM, Marek Vasut <marex@denx.de> wrote:
>> On Wed, Oct 09, 2013 at 12:14:02PM +0200, Marek Vasut wrote:
>> > > On Mon, Oct 7, 2013 at 9:24 AM, Marek Vasut <marex@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 ;-/
>>
>> Well, the READ_4B consistency is (unintentionally?) helpful for my
>> systems, as we have begun implementing a jumper switch so that the boot
>> ROM will know whether to use FAST_READ or FAST_READ_4B. Since
>> essentially all large SPI flash at *least* support the READ_4B command
>> (as you noted), we can reliably boot from the flash, no matter what mode
>> it is left in. After booting, we can choose the appropriate mode for
>> programming/erasing.
>
> I wish I had such a bootrom. In my case (freescale imx28), the bootrom can just
> do 3-byte operation and that's it. I believe the only way around here is to
> power-cycle the spi flash before the bootrom starts using it.
Well, such is life when dealing with these flash. Manufacturers
apparently didn't understand the impact that adding incompatible
mode-switches to such fundamental commands would have :(
>> > > [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).
>>
>> Probably some series of acquisitions?
>>
>> But you didn't quite answer my question. Are you having problems with
>> this Micron/ST/something-that's-not-AMD-or-Spansion flash using the
>> current mainline? Or did you only have trouble when you tried modifying
>> the code to use the dedicated 4-byte addressing commands?
>
> Urgh, I just noticed I did exactly this. I modified the driver to enable this 4-
> byte opcodes and then just forgot about it. Pardon my stupidity :(
No problem. The manufacturers haven't made this an easy problem.
Brian
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-10-15 17:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-07 16:24 N25Q256A 13E40 Marek Vasut
2013-10-09 1:05 ` Brian Norris
2013-10-09 10:14 ` Marek Vasut
2013-10-09 21:44 ` Brian Norris
2013-10-12 1:17 ` Marek Vasut
2013-10-15 17:22 ` Brian Norris
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.