[U-Boot] sf: proposed status register protect
George McCollister
george.mccollister at gmail.com
Thu Oct 6 17:51:48 CEST 2016
On Thu, Oct 6, 2016 at 10:27 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> On Thu, Oct 6, 2016 at 8:32 PM, George McCollister
> <george.mccollister at gmail.com> wrote:
>> I'm looking into adding a sub-command to sf to protect status
>> registers on Winbond SPI flash parts via the status register protect
>> bits SRP0, SRP1. I propose the sub-command be named sr-protect.
>>
>> My use case is simple, I want to make the SPI flash read-only when the
>> /WP pin is low. To do this I must do 'sf protect lock 0 $size' then
>> set SRP0 to 1 and hold the /WP pin low. Although my use case doesn't
>> require it, setting SRP1 to 1 allows either Power Supply Lock-Down or
>> One Time Program (if supported by hardware) and I would probably add
>> support for these as well.
>>
>> All of the current Winbond SPI NOR flash part datasheets that I've
>> looked at show that the parts support the same locking implemented in
>> stm_lock() even though SPI_FLASH_CFI_MFR_WINBOND is not in the list of
>> vendors which use the function. I'll change this to make
>> SPI_FLASH_CFI_MFR_WINBOND parts use stm_lock(), stm_unlock(),
>> stm_is_locked().
>
> Does stm_lock can't protect the Winbond? how different is in the
> process of doing when compared to stm?
stm_lock() does work with the Winbond parts. The issue is that you can
simply unlock from software (stm_unlock). To make it impossible to
write to the flash from software you must use stm_lock() then use the
status register protect bits to prevent an unlock.
>
>>
>> spi_flash_protect() (which ultimately calls either stm_lock() or
>> stm_unlock()) is not part of the driver model (dm_spi_flash_ops).
>> Is there any issue with adding another function (let's call it
>> spi_flash_sr_protect) that is not part of the driver model?
>
> Why spi_flash_sr_protect, why can't existing stm_lock?
Explained above.
>
> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.
More information about the U-Boot
mailing list