* 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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox