Messages in this thread Patch in this message | | | From | SHUKLA Mamta Ramendra <> | Subject | Re: [PATCH v2] mtd: micron-st: enable lock/unlock for mt25qu512a | Date | Fri, 6 Oct 2023 10:30:36 +0000 |
| |
>>> On 10/5/23 10:21, SHUKLA Mamta Ramendra wrote: >>> >>> cut >>> >>>>> >>>>> and the second one will add just the BP support, something like: >>>>> diff --git a/drivers/mtd/spi-nor/micron-st.c >>>>> b/drivers/mtd/spi-nor/micron-st.c >>>>> index a8da1f18e335..fdafbfa0f936 100644 >>>>> --- a/drivers/mtd/spi-nor/micron-st.c >>>>> +++ b/drivers/mtd/spi-nor/micron-st.c >>>>> @@ -405,6 +405,8 @@ static const struct flash_info st_nor_parts[] = { >>>>> }, { >>>>> .id = SNOR_ID(0x20, 0xbb, 0x20, 0x10, 0x44, 0x00), >>>>> .name = "mt25qu512a", >>>>> + .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | >>>>> SPI_NOR_4BIT_BP | >>>>> + SPI_NOR_BP3_SR_BIT6, >>>>> .mfr_flags = USE_FSR, >>>>> }, { >>>>> .id = SNOR_ID(0x20, 0xbb, 0x20), >>>>> >>>>> Of course, I expect you to run again the mtd_debug tests and also verify >>>>> the locking. Thanks! >>>> >>>> I applied both changes as mentioned above i.e >>>> 1] Switch to SFDP and 2] Using BP Flags. >>>> >>>> Case 1: Use BP Flags and Switch to SFDP >>>> With both these changes, the lock/unlock doesn't work. >>>> >>>> ## x86-64-smarc-evk-uwd0j0007 # uname -r >>>> 6.6.0-rc2 >>>> >>>> # flash_lock -i /dev/mtd0 >>>> Device: /dev/mtd0 >>>> Start: 0 >>>> Len: 0x4000000 >>>> Lock status: unlocked >>>> Return code: 0 >>>> # flash_lock -l /dev/mtd0 >>>> flash_lock: error!: could not lock device: /dev/mtd0 >>>> >>>> error 5 (Input/output error) >>>> >>>> >>>> I suspected this is because of miscalculation of BP bits, like the >>>> possibility mentioned here: >>>> https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/commit/?h=spi-nor/next&id=3ea3f0ac242c86c0275d347ab8c92bf1eb854b49 >>>> >>>> >>>> But further checked size, it is correct: >>>> >>>> # mtd_debug info /dev/mtd0 >>>> mtd.type = MTD_NORFLASH >>>> mtd.flags = MTD_CAP_NORFLASH >>>> mtd.size = 67108864 (64M) >>>> mtd.erasesize = 4096 (4K) >>>> mtd.writesize = 1 >>>> mtd.oobsize = 0 >>>> regions = 0 >>>> >>>> And rest of read/write functions work as expected. >>>> >>>> Any suggestions about this? >>>> >>>> Case 2: Just added BP flags, rest of the size, mfr_flags, fixup flags >>>> kept as it is. >>> >>> would you please detail what exact definitions you used in case 2? Send >>> us the diff please. >> Case 2: Adding Flags for BP >> >> diff --git a/drivers/mtd/spi-nor/micron-st.c >> b/drivers/mtd/spi-nor/micron-st.c >> index 4afcfc57c896..6c8cabbead2e 100644 >> --- a/drivers/mtd/spi-nor/micron-st.c >> +++ b/drivers/mtd/spi-nor/micron-st.c >> @@ -405,6 +405,8 @@ static const struct flash_info st_nor_parts[] = { >> }, { >> .id = SNOR_ID(0x20, 0xbb, 0x20, 0x10, 0x44, 0x00), >> .name = "mt25qu512a", >> + .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | >> SPI_NOR_4BIT_BP | >> + SPI_NOR_BP3_SR_BIT6, >> .size = SZ_64M, >> .no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | >> SPI_NOR_QUAD_READ, >> .fixup_flags = SPI_NOR_4B_OPCODES, >> >> > > Thanks. Nothing obvious on a first look. I looked at the sfdp dump, it > looks like 4BAIT table is missing, so you'll probably need: > .fixup_flags = SPI_NOR_4B_OPCODES,
> I don't see how this could affect BP, but it is worth to test > incremental changes and find out what misses. > > After you test the above, I'd like you to extend the patch with: > .size = SZ_64M, > Check if it works and send us the output of mtd_debug info /dev/mtd0 here.
I started first with params and debug log for working and non-working cases:
1] Non-working case: BP Flags + Parsing SFDP(i.e remove size, fixup flag and no_sfdp flag)
## x86-64-smarc-evk-uwd0j0007 # flash_lock -l /dev/mtd0
[ 480.230232] spi-nor spi-PRP0001:00: SR: Read back test failed flash_lock: error!: could not lock device: /dev/mtd0
error 5 (Input/output error)
and params from debugfs look like:
## x86-64-smarc-evk-uwd0j0007 # cat /sys/kernel/debug/spi-nor/spi-PRP0001:00/params name mt25qu512a id 20 bb 20 10 44 00 size 64.0 MiB write size 1 page size 256 address nbytes 4 flags HAS_SR_TB | 4B_OPCODES | HAS_4BAIT | HAS_LOCK | HAS_16BIT_SR | HAS_4BIT_BP | HAS_SR_BP3_BIT6 | SOFT_RESET
Strange thing here is HAS_16BIT_SR. And it makes sense from debug log: [ 480.230232] spi-nor spi-PRP0001:00: SR: Read back test failed
which comes from spi_nor_write_16bit_sr_and_check () .
It is strange because in micron-st.c, in default init we have: static void micron_st_nor_default_init(struct spi_nor *nor) { nor->flags |= SNOR_F_HAS_LOCK; nor->flags &= ~SNOR_F_HAS_16BIT_SR; nor->params->quad_enable = NULL; }
2] Working case: Just BP flags and no parsing SFDP:
Params for flags look like
flags HAS_SR_TB | 4B_OPCODES | HAS_4BAIT | HAS_LOCK | HAS_4BIT_BP | HAS_SR_BP3_BIT6 | SOFT_RESET
3] Just adding .fixup_flags: @@ -407,6 +418,7 @@ static const struct flash_info st_nor_parts[] = { .name = "mt25qu512a", .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP | SPI_NOR_BP3_SR_BIT6, + .fixup_flags = SPI_NOR_4B_OPCODES, .mfr_flags = USE_FSR,
lock/unlock still doesn't work.
I also compared this with case when we just parse SFDP flag, we get 4Byte-AIT, so this flag is not required when parsing SFDP.
This is only required when we don't parse SFDP and use .size=SZ_64M
4] Adding .size flag i.e no SFDP parsing:
lock/unlock works as expected and params:
## x86-64-smarc-evk-uwd0j0007 # cat /sys/kernel/debug/spi-nor/spi-PRP0001:00/params name mt25qu512a id 20 bb 20 10 44 00 size 64.0 MiB write size 1 page size 256 address nbytes 4 flags HAS_SR_TB | 4B_OPCODES | HAS_LOCK | HAS_4BIT_BP | HAS_SR_BP3_BIT6
--------------------------------------------------------
IMO, HAS_16BIT_SR flag is causing lock/unlock failure, since BP bits are calculated wrong then.
I tested also for a case where I don't parse SFDP and reverted the condition in micron_st_nor_default_init() for 16BIT Status Register Flag. And lock/unlock fails with same log as Non-working case.
And this mt25qu512 has 8-BIT SR as typical micron-st flash.
> Also you could enable dev_dbg to see where you get -EIO. Probably when > reading the SR back. Also you can use debugfs to check what is set in > the working scenario and what params are different in the non-working > case. See drivers/mtd/spi-nor/debugfs.c > > Cheers, > ta > > >> ----------------------------------------------------------------- >> Case 1: BP Flags and removed size, and no_sfdp so by default expecting >> to read SFDP >> >> diff --git a/drivers/mtd/spi-nor/micron-st.c >> b/drivers/mtd/spi-nor/micron-st.c >> index 6c8cabbead2e..4feb03ee2d13 100644 >> --- a/drivers/mtd/spi-nor/micron-st.c >> +++ b/drivers/mtd/spi-nor/micron-st.c >> @@ -407,9 +407,6 @@ static const struct flash_info st_nor_parts[] = { >> .name = "mt25qu512a", >> .flags = SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB | >> SPI_NOR_4BIT_BP | >> SPI_NOR_BP3_SR_BIT6, >> - .size = SZ_64M, >> - .no_sfdp_flags = SECT_4K | SPI_NOR_DUAL_READ | >> SPI_NOR_QUAD_READ, >> - .fixup_flags = SPI_NOR_4B_OPCODES, >> .mfr_flags = USE_FSR, >> }, { >> >> >> >>> >>> Cheers, >>> ta >>> >>>> Lock/unlock works. >>>> >>>> ## x86-64-smarc-evk-uwd0j0007 # uname -r >>>> 6.6.0-rc2 >>>> >>>> # flash_lock -i /dev/mtd0 >>>> Start: 0 >>>> Len: 0x4000000 >>>> Lock status: unlocked >>>> Return code: 0 >>>> >>>> # flash_lock -l /dev/mtd0 >>>> # flash_lock -i /dev/mtd0 >>>> Device: /dev/mtd0 >>>> Start: 0 >>>> Len: 0x4000000 >>>> Lock status: locked >>>> Return code: 1 >>>> >>>> ## x86-64-smarc-evk-uwd0j0007 # mtd_debug erase /dev/mtd0 0 1048576 >>>> [ 413.472411] spi-nor spi-PRP0001:00: Erase operation failed. >>>> [ 413.478084] spi-nor spi-PRP0001:00: Attempted to modify a protected >>>> sector. >>>> MEMERASE: Input/output error >>>> >>>> # flash_lock -u /dev/mtd0 >>>> # flash_lock -i /dev/mtd0 >>>> Device: /dev/mtd0 >>>> Start: 0 >>>> Len: 0x4000000 >>>> Lock status: unlocked >>>> Return code: 0 >>>> >>>> ## x86-64-smarc-evk-uwd0j0007 # mtd_debug erase /dev/mtd0 0 1048576 >>>> Erased 1048576 bytes from address 0x00000000 in flash >>>> >>>> >>>> Further I tested on stable 6.5.5 Kernel with old way of Flash Info >>>> Format and which has forced PARSE_SFDP Flag, no issues with lock/unlock. >>>> >>>> >>
Thanks, Mamta
| |