RE: [PATCH v1] mtd: spi-nor: Add gd55lb02gf chips
> Hi Takahiro, Hi Vincent, > > Le 11/05/26 10:28, [email protected] a écrit : > > > 0xc8671c is for GD55LB02GE and there is duplicate entry appears in the last > > part of GigaDevice entries. Besides SPI_NOR_HAS_TB flag is missing in the > > "gd55lb02g" entry... > > I deliberately did not copy SPI_NOR_HAS_TB. The GD55LB02GF > datasheet (Rev1.2) documents an SR layout that the uboot's current > SPI_NOR_HAS_TB handling cannot drive correctly from my understanding: > Thanks for pointing out. I just assumed GD55LB02GE flags were correct. > - datasheet table 4 (SR1): bits S6..S2 are BP4..BP0 > Bit S5 is BP3, not a TB bit. Now I understand this device has 4-bit BPs (BP3..BP0) + TB (BP4). BP3..BP0 select the size of locked area and BP4 selects the location of locked area, upper or lower. > - datasheet table 5 (SR2): bit S14 is CMP (Complement Protect). Default > value CMP = 0. > - datasheet tables 2 and 3: show that the BP4..BP0 region grows from the > bottom of the > array when CMP = 0, and from the top when CMP = 1. The TB-equivalent > direction > selection lives at SR2 bit S14 on this die. CMP inverts the locked and unlocked area, not equivalent to TB. > > currently, > - include/linux/mtd/spi-nor.h defines SR_TB = BIT(5). > - drivers/mtd/spi/spi-nor-core.c reads and writes that bit in SR1 when > SNOR_F_HAS_SR_TB is set. In Linux, HAS_4BIT_BP and HAS_SR_TB_BIT6 flags handle that, but not in u-boot yet. > - the same file spi-nor-core.c has the comment "CMP: complement > protect - only support CMP=0 (range is not complemented)", ie the > framework never reads SR2 for CMP. > In Linux, CMP support will be applied soon. > If SPI_NOR_HAS_TB is set on the GD55LB02GF entry, the framework will toggle > SR1 bit 5 on every direction change in sf protect which on this die is BP3 > not a direction selector. > > For the same reason, SPI_NOR_HAS_LOCK on this entry covers only a subset of > the chip's protection levels, > SR_BP0/BP1/BP2 (defined at include/linux/mtd/spi-nor.h) as BITs 2..4 > miss BP3 and BP4. > > A vendor hook handling the full 5-BP + SR2-CMP layout is out of scope for > this patch. > We need to sync u-boot to Linux. For now, let's drop SPI_NOR_HAS_LOCK flag. > > > SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)}, > > > + {INFO("gd55lb02gf", 0xc8601C, 0, 64 * 1024, 4096, SECT_4K | > > > + SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)}, > > > > Could you create a new entry just after "gd55lb02ge" with the same flags > > with > > it? GD55LB02G'F' should be a successor chip of GD55LB02G'E'. > > ok, I will move the entry next to gd55lb02ge in v2. > > Best regards, > Vincent Thanks, Takahiro
Re: [PATCH v1] mtd: spi-nor: Add gd55lb02gf chips
Hi Takahiro, Le 11/05/26 10:28, [email protected] a écrit : > 0xc8671c is for GD55LB02GE and there is duplicate entry appears in the last > part of GigaDevice entries. Besides SPI_NOR_HAS_TB flag is missing in the > "gd55lb02g" entry... I deliberately did not copy SPI_NOR_HAS_TB. The GD55LB02GF datasheet (Rev1.2) documents an SR layout that the uboot's current SPI_NOR_HAS_TB handling cannot drive correctly from my understanding: - datasheet table 4 (SR1): bits S6..S2 are BP4..BP0 Bit S5 is BP3, not a TB bit. - datasheet table 5 (SR2): bit S14 is CMP (Complement Protect). Default value CMP = 0. - datasheet tables 2 and 3: show that the BP4..BP0 region grows from the bottom of the array when CMP = 0, and from the top when CMP = 1. The TB-equivalent direction selection lives at SR2 bit S14 on this die. currently, - include/linux/mtd/spi-nor.h defines SR_TB = BIT(5). - drivers/mtd/spi/spi-nor-core.c reads and writes that bit in SR1 when SNOR_F_HAS_SR_TB is set. - the same file spi-nor-core.c has the comment "CMP: complement protect - only support CMP=0 (range is not complemented)", ie the framework never reads SR2 for CMP. If SPI_NOR_HAS_TB is set on the GD55LB02GF entry, the framework will toggle SR1 bit 5 on every direction change in sf protect which on this die is BP3 not a direction selector. For the same reason, SPI_NOR_HAS_LOCK on this entry covers only a subset of the chip's protection levels, SR_BP0/BP1/BP2 (defined at include/linux/mtd/spi-nor.h) as BITs 2..4 miss BP3 and BP4. A vendor hook handling the full 5-BP + SR2-CMP layout is out of scope for this patch. > > SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)}, > > + {INFO("gd55lb02gf", 0xc8601C, 0, 64 * 1024, 4096, SECT_4K | > > + SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)}, > > Could you create a new entry just after "gd55lb02ge" with the same flags with > it? GD55LB02G'F' should be a successor chip of GD55LB02G'E'. ok, I will move the entry next to gd55lb02ge in v2. Best regards, Vincent
RE: [PATCH v1] mtd: spi-nor: Add gd55lb02gf chips
Hi,
>
> Add GigaDevice GD55LB02GF (256 MiB, JEDEC 0xc8 0x60 0x1c) to the
> spi-nor ID table.
>
> Same die family as the existing gd55lb02g entry but a distinct memtype
> byte (0x60 versus 0x67), so the existing entry does not match.
>
0xc8671c is for GD55LB02GE and there is duplicate entry appears in the last
part of GigaDevice entries. Besides SPI_NOR_HAS_TB flag is missing in the
"gd55lb02g" entry...
> Signed-off-by: Vincent Jardin
>
> ---
>
> drivers/mtd/spi/spi-nor-ids.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index c0fa98424aa..50f6dd3e5c4 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -191,6 +191,8 @@ const struct flash_info spi_nor_ids[] = {
> SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
> {INFO("gd55lb02g", 0xc8671C, 0, 64 * 1024, 4096,SECT_4K |
> SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
> + {INFO("gd55lb02gf", 0xc8601C, 0, 64 * 1024, 4096, SECT_4K |
> + SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
Could you create a new entry just after "gd55lb02ge" with the same flags with
it? GD55LB02G'F' should be a successor chip of GD55LB02G'E'.
Thanks,
Takahiro
> {INFO("gd25lf80", 0xc86314, 0, 64 * 1024, 16, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
> {INFO("gd25lf16", 0xc86315, 0, 64 * 1024, 32, SECT_4K |
> --
> 2.43.0
>
> base-commit: bfe90a308a94caa9d855440683521ff04122ae2a
> branch: for-upstream/spi-nor-gd55lb02gf
[PATCH v1] mtd: spi-nor: Add gd55lb02gf chips
Add GigaDevice GD55LB02GF (256 MiB, JEDEC 0xc8 0x60 0x1c) to the
spi-nor ID table.
Same die family as the existing gd55lb02g entry but a distinct memtype
byte (0x60 versus 0x67), so the existing entry does not match.
Signed-off-by: Vincent Jardin
---
drivers/mtd/spi/spi-nor-ids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index c0fa98424aa..50f6dd3e5c4 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -191,6 +191,8 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd55lb02g", 0xc8671C, 0, 64 * 1024, 4096,SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
+ {INFO("gd55lb02gf", 0xc8601C, 0, 64 * 1024, 4096, SECT_4K |
+ SPI_NOR_HAS_LOCK | SPI_NOR_4B_OPCODES)},
{INFO("gd25lf80", 0xc86314, 0, 64 * 1024, 16, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK)},
{INFO("gd25lf16", 0xc86315, 0, 64 * 1024, 32, SECT_4K |
--
2.43.0
base-commit: bfe90a308a94caa9d855440683521ff04122ae2a
branch: for-upstream/spi-nor-gd55lb02gf
