Messages in this thread | | | Date | Tue, 6 Oct 2020 17:10:24 +0530 | From | Pratyush Yadav <> | Subject | Re: [PATCH] mtd: spi-nor: Fix 3-or-4 address byte mode logic |
| |
On 06/10/20 11:19AM, Tudor.Ambarus@microchip.com wrote: > On 10/6/20 2:03 PM, Tudor Ambarus - M18064 wrote: > > On 10/1/20 9:34 AM, Pratyush Yadav wrote: > >> So using an address width of 4 here is not necessarily the right thing > >> to do. This change would break SMPT parsing for all flashes that use > >> 3-byte addressing by default because SMPT parsing can involve register > >> reads/writes. One such device is the Cypress S28HS flash. In fact, this > >> was what prompted me to write the patch [0]. > > > > Do you refer to spi_nor_get_map_in_use()? > > oh, I see. If addr width is set via the SMPT_CMD_ADDRESS_LEN_USE_CURRENT, > case, and if the flash comes in 4 byte address mode from a bootloader, > then setting addr_width to 3 in case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, > will break the reading of the map.
Yes it will but that is not the problem I was trying to solve. The problem is simply that nor->addr_width is 0 without the BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 case that I added, since BFPT parsing won't touch it at all. And so SMPT_CMD_ADDRESS_LEN_USE_CURRENT results in the command using an op.addr.nbytes == 0 for the register read even though op.addr.val is set correctly. This means the controller skips the address phase and the register read fails.
Defaulting to 3 for the BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 case means op.addr.nbytes is correctly set to 3 and register read works correctly and SMPT parsing correctly detects the current configuration.
If the address width is set to 4 by the bootloader then we have the same problem in some ways as the 8D boot problem where we have no way of easily detecting which mode is being used. I did not try to solve that problem with this change.
> If the Address Mode bit is volatile, maybe we can reset the flash to > its power on state immediately after identification. For the NV bits, > we have the same recurring problem.
Yes, the U-Boot xSPI series I sent does this somewhat. It issues a soft reset before handing control over to the kernel, so the kernel sees the flash in PoR state. This also helps when U-Boot uses the flash in 8D mode.
-- Regards, Pratyush Yadav Texas Instruments India
| |