sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
PATCH v3 1/1 sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Some SPI NOR chips only support 4-byte mode addressing. Here the default 3-byte mode does not work and leads to incorrect accesses. This patch now reads the 4-byte mode status bit (in this case in the CR register of the Macronix SPI NOR) and configures the SPI transfers accordingly.
This was noticed on the LinkIt Smart 7688 modul, which is equipped with an Macronix MX25L25635F device. But this device does *NOT* support switching to 3-byte mode via the EX4B command.
This should also work when the bootrom configures the SPI flash to 4-byte mode and runs U-Boot after this. U-Boot should dectect this mode (if the 4-byte mode detection is available for this chip) and use the correct OPs in this case.
---
v3:
- Rebased on latest version (merge conflict because of new patches from Simon Glass)
- Added Tested-by tag from Simon Goldschmidt
v2:
- Integrated STMICRO 4-byte detection from Simon
drivers/mtd/spi/sf_internal.h | 3 +- drivers/mtd/spi/spi_flash.c | 131 ++++++++++++++++++++++++++++------ include/spi_flash.h | 5 ++ 3 files changed, 118 insertions(+), 21 deletions(-)
drivers/mtd/spi/sf_internal.h +2 -1
@@ -26,7 +26,8 @@ enum spi_nor_option_flags { };#define SPI_FLASH_3B_ADDR_LEN 3 -#define SPI_FLASH_CMD_LEN (1 + SPI_FLASH_3B_ADDR_LEN) +#define SPI_FLASH_4B_ADDR_LEN 4 +#define SPI_FLASH_CMD_MAX_LEN (1 + SPI_FLASH_4B_ADDR_LEN)#define SPI_FLASH_16MB_BOUN 0x1000000/* CFI Manufacture ID's */
drivers/mtd/spi/spi_flash.c +111 -20
221 lines not on this page · raw message
include/spi_flash.h +5 -0
@@ -36,6 +36,8 @@ struct spi_slave;* @dual_flash: Indicates dual flash memories - dual stacked, parallel * @shift: Flash shift useful in dual parallel * @flags: Indication of spi flash flags +* @in_4byte_mode: True if flash is detected to be in 4-byte mode +* @cmdlen: CMD length (3-byte vs 4-byte mode) * @size: Total flash size * @page_size: Write (page) size * @sector_size: Sector size
@@ -69,6 +71,9 @@ struct spi_flash {u8 shift;u16 flags; +bool in_4byte_mode; +int cmdlen; +u32 size;u32 page_size;u32 sector_size;
Signature · 1 line
2.19.1
PATCH v3 1/1 sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Guys,
Let get back to the original thread. Since Rajat's first reply, the message id has been changed. All the comments were not captured by patchwork.
Quoted 5 lines · Stefan Roese
Some SPI NOR chips only support 4-byte mode addressing. Here the default 3-byte mode does not work and leads to incorrect accesses. This patch now reads the 4-byte mode status bit (in this case in the CR register of the Macronix SPI NOR) and configures the SPI transfers accordingly.
Quoted 8 lines
This was noticed on the LinkIt Smart 7688 modul, which is equipped with an Macronix MX25L25635F device. But this device does *NOT* support switching to 3-byte mode via the EX4B command.
This should also work when the bootrom configures the SPI flash to 4-byte mode and runs U-Boot after this. U-Boot should dectect this mode (if the 4-byte mode detection is available for this chip) and use the correct OPs in this case.
From what I read, Rajat's method is to extend the controller driver to support read SFDP and default to 4-byte mode if supported, or overwritten by user's flag. Stefan's method is to read 4-byte status bit and doesn't change controller driver.
Is the default value of this 4-byte status bit valid and correct for all cases?
Rajat, without your patch set, does Stefan's solution work for your board?
York
PATCH v3 1/1 sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Hi York,
Quoted 5 lines · York Sun
Guys,
Let get back to the original thread. Since Rajat's first reply, the message id has been changed. All the comments were not captured by patchwork.
I also wondered about this. Seems to have happened at some top-posting quite at the beginning of this thread.
Quoted 15 lines · Stefan Roese
Quoted 5 lines
Some SPI NOR chips only support 4-byte mode addressing. Here the default 3-byte mode does not work and leads to incorrect accesses. This patch now reads the 4-byte mode status bit (in this case in the CR register of the Macronix SPI NOR) and configures the SPI transfers accordingly.
Quoted 8 lines
This was noticed on the LinkIt Smart 7688 modul, which is equipped with an Macronix MX25L25635F device. But this device does *NOT* support switching to 3-byte mode via the EX4B command.
This should also work when the bootrom configures the SPI flash to 4-byte mode and runs U-Boot after this. U-Boot should dectect this mode (if the 4-byte mode detection is available for this chip) and use the correct OPs in this case.
Quoted 4 lines
From what I read, Rajat's method is to extend the controller driver to
support read SFDP and default to 4-byte mode if supported, or overwritten by user's flag. Stefan's method is to read 4-byte status bit and doesn't change controller driver.
Yes, the last sentence it correct.
Quoted 2 lines
Is the default value of this 4-byte status bit valid and correct for all cases?
This 4-byte address status bit implementation is SPI NOR chip specific (vendor specific?). With Simon's help we already support 2 vendors now. Extending for other vendors / chips is fairly easy.
Thanks,
Stefan
PATCH v3 1/1 sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Quoted 12 lines · Stefan Roese
Hi York,
Quoted 5 lines · York Sun
Guys,
Let get back to the original thread. Since Rajat's first reply, the message id has been changed. All the comments were not captured by patchwork.
I also wondered about this. Seems to have happened at some top-posting quite at the beginning of this thread.
I am having trouble recently with office365. It seems breaking all my email threads if senders use outlook.
Quoted 8 lines
Quoted 5 lines
From what I read, Rajat's method is to extend the controller driver to
support read SFDP and default to 4-byte mode if supported, or overwritten by user's flag. Stefan's method is to read 4-byte status bit and doesn't change controller driver.Yes, the last sentence it correct.
Quoted 7 lines
Quoted 2 lines
Is the default value of this 4-byte status bit valid and correct for all cases?
This 4-byte address status bit implementation is SPI NOR chip specific (vendor specific?). With Simon's help we already support 2 vendors now. Extending for other vendors / chips is fairly easy.
Let's wait for Rajat's comment. If this method doesn't work for his boards or his controllers, he still needs to extend controller's driver feature.
York
PATCH v3 1/1 sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
In reply to York SunQuoted 38 lines
-----Original Message-----
From: York Sun
Sent: Thursday, October 25, 2018 9:20 PM
To: Stefan Roese <[email protected]>
Cc: u-boot at lists.denx.de; Jagan Teki <[email protected]>; Rajat Srivastava <[email protected]>; simon.k.r.goldschmidt at gmail.com; Ashish Kumar <[email protected]>
Subject: Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)Guys,
Let get back to the original thread. Since Rajat's first reply, the message id has been changed. All the comments were not captured by patchwork.
Quoted 1 line · Stefan Roese
Some SPI NOR chips only support 4-byte mode addressing. Here the
default
Quoted 4 lines
3-byte mode does not work and leads to incorrect accesses. This patch now reads the 4-byte mode status bit (in this case in the CR register of the Macronix SPI NOR) and configures the SPI transfers accordingly.
Quoted 8 lines
This was noticed on the LinkIt Smart 7688 modul, which is equipped with an Macronix MX25L25635F device. But this device does *NOT* support switching to 3-byte mode via the EX4B command.
This should also work when the bootrom configures the SPI flash to 4-byte mode and runs U-Boot after this. U-Boot should dectect this mode (if the 4-byte mode detection is available for this chip) and use the correct OPs in this case.
From what I read, Rajat's method is to extend the controller driver to support read SFDP and default to 4-byte mode if supported, or overwritten by user's flag. Stefan's method is to read 4-byte status bit and doesn't change controller driver.
Quoted 6 lines
Is the default value of this 4-byte status bit valid and correct for all cases?
Rajat, without your patch set, does Stefan's solution work for your board?
York
No. Stefan's changes are specific to his boards and is not applicable on ours.
Stefan's patch is to support only certain flash that are factory strapped to work in 4-byte addressing modes only and will default to old method if such a flash is not found. The flashes on our boards (and also other vendor's board) will not work with Stefan's patch.
My patch can handle flashes with address widths of 3-byte, 4-byte or both. It also takes a more generic path (as opposed to supporting only specific flash models) by parsing SFDP standard parameters and then deciding what address width is to be used.
- Rajat
PATCH v3 1/1 sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Hi Rajat,
On 26.10.18 11:59, Rajat Srivastava wrote:
<snip>
Quoted 10 lines
Quoted 10 lines
From what I read, Rajat's method is to extend the controller driver to
support read SFDP and default to 4-byte mode if supported, or overwritten by user's flag. Stefan's method is to read 4-byte status bit and doesn't change controller driver.Is the default value of this 4-byte status bit valid and correct for all cases?
Rajat, without your patch set, does Stefan's solution work for your board?
Quoted 7 lines
Quoted 1 line
York
No. Stefan's changes are specific to his boards and is not applicable on ours.
Stefan's patch is to support only certain flash that are factory strapped to work in 4-byte addressing modes only and will default to old method if such a flash is not found.
That is not 100% correct. The flash does not need to be "factory strapped" to this 4-byte mode. It needs to be configured to this 4-byte mode. And this is also the case for example, when the ROM bootloader configures the flash this way or a soft-reboot (without hard flash chip reset) reboots into U-Boot after the flash was configured to 4-byte mode in Linux.
And it supports multiple vendors and can easily be extended to support more. The only thing needed is the detection of the 3-byte vs 4-byte address mode. But please note that it currently does not actively switch from 3-byte to 4-byte mode. This could be added though if needed / wanted.
Quoted 8 lines
The flashes on our
boards (and also other vendor's board) will not work with Stefan's patch.My patch can handle flashes with address widths of 3-byte, 4-byte or both. It also takes a more generic path (as opposed to supporting only specific flash models) by parsing SFDP standard parameters and then deciding what address width is to be used.
I still don't see why each and every SPI controller driver needs to be extended to support this SFDP parameter reading. Can't this be handled by some generic (read common) code part in the SPI flash infrastructure?
Thanks,
Stefan
PATCH v3 1/1 sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Hi Stefan
Quoted 40 lines
-----Original Message-----
From: Stefan Roese <[email protected]>
Sent: Friday, October 26, 2018 3:42 PM
To: Rajat Srivastava <[email protected]>; York Sun <[email protected]>; Jagan Teki <[email protected]>
Cc: u-boot at lists.denx.de; simon.k.r.goldschmidt at gmail.com; Ashish Kumar <[email protected]>
Subject: Re: [U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)Hi Rajat,
On 26.10.18 11:59, Rajat Srivastava wrote:
<snip>
Quoted 10 lines
Quoted 10 lines
From what I read, Rajat's method is to extend the controller driver
to support read SFDP and default to 4-byte mode if supported, or overwritten by user's flag. Stefan's method is to read 4-byte status bit and doesn't change controller driver.Is the default value of this 4-byte status bit valid and correct for all cases?
Rajat, without your patch set, does Stefan's solution work for your board?
Quoted 7 lines
Quoted 1 line
York
No. Stefan's changes are specific to his boards and is not applicable on ours.
Stefan's patch is to support only certain flash that are factory strapped to work in 4-byte addressing modes only and will default to old method if such a flash is not found.That is not 100% correct. The flash does not need to be "factory strapped" to this 4-byte mode. It needs to be configured to this 4-byte mode. And this is also the case for example, when the ROM bootloader configures the flash this way or a soft-reboot (without hard flash chip reset) reboots into U-Boot after the flash was configured to 4-byte mode in Linux.
Quoted 4 lines
And it supports multiple vendors and can easily be extended to support more. The only thing needed is the detection of the 3-byte vs 4-byte address mode. But please note that it currently does not actively switch from 3-byte to 4-byte mode. This could be added though if needed / wanted.
Spansion flashes (on our boards) support both 3-byte and 4-byte addressing modes which needs active switching. What could be added to your patch is already supported in SFDP method. SFDP also provides information about page size, flash density, read/write/erase commands, etc, in addition to getting information about address width supported by flash.
Quoted 5 lines
Quoted 5 lines
The flashes on our
boards (and also other vendor's board) will not work with Stefan's patch.
Quoted 8 lines
Quoted 4 lines
My patch can handle flashes with address widths of 3-byte, 4-byte or both. It also takes a more generic path (as opposed to supporting only specific flash models) by parsing SFDP standard parameters and then deciding what address width is to be used.
I still don't see why each and every SPI controller driver needs to be extended to support this SFDP parameter reading. Can't this be handled by some generic (read common) code part in the SPI flash infrastructure?
The generic (read common) code part in the SPI flash infrastructure also lands on respective SPI drivers which ultimately sends the commands to flash. Currently every SPI driver has support for basic read command (which is called after "generic read common code") but no driver has support for SFDP reading, which is what needs to be added. Also, only the drivers that want to make use of SFDP needs to extend support for SFDP parameter reading.
I am reiterating that this is how SFDP parsing has been implemented in Linux as well and this is the generic way. Driver support is absolutely required because SPI framework cannot directly send any command to any flash.
Thanks
Rajat
Quoted 3 lines
Thanks,
Stefan
PATCH v3 1/1 sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
On 10/26/18 03:36, Rajat Srivastava wrote:
<snip>
Quoted 12 lines
Spansion flashes (on our boards) support both 3-byte and 4-byte addressing modes which needs active switching. What could be added to your patch is already supported in SFDP method. SFDP also provides information about page size, flash density, read/write/erase commands, etc, in addition to getting information about address width supported by flash.
Quoted 10 lines
Quoted 9 lines
The flashes on our
boards (and also other vendor's board) will not work with Stefan's patch.My patch can handle flashes with address widths of 3-byte, 4-byte or both. It also takes a more generic path (as opposed to supporting only specific flash models) by parsing SFDP standard parameters and then deciding what address width is to be used.
Quoted 9 lines
Quoted 3 lines
I still don't see why each and every SPI controller driver needs to be extended to support this SFDP parameter reading. Can't this be handled by some generic (read common) code part in the SPI flash infrastructure?
The generic (read common) code part in the SPI flash infrastructure also lands on respective SPI drivers which ultimately sends the commands to flash. Currently every SPI driver has support for basic read command (which is called after "generic read common code") but no driver has support for SFDP reading, which is what needs to be added. Also, only the drivers that want to make use of SFDP needs to extend support for SFDP parameter reading.
I am reiterating that this is how SFDP parsing has been implemented in Linux as well and this is the generic way. Driver support is absolutely required because SPI framework cannot directly send any command to any flash.
It sounds like your difference is how to detect 4-byte addressing should be used.
Stefan's method is from the flash chip side, to check status register. The benefit is to preserve setting before U-Boot. I am not sure if it is necessary to preserve previous setting though.
Rajat's method is from the controller side, to read SFDP. It can support all flash chips I presume.
I guess Stefan's method will not determine Rajat's flash as 4-byte addressing because it indeed supports both 3- and 4-byte. To make Rajat's method work on Stefan's board, SFDP needs to be extended to the controller driver Stefan uses, is that right?
I also guess reading SFDP is controller-specific and cannot be done in a generic way. If the new feature is useful and can be gradually extended to other controllers, it sounds good to me. My guesses could wrong though.
York