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
