On Tue, Nov 10, 2015 at 04:09:52PM -0800, Simon Glass wrote:
Hi Fabio,
On 6 November 2015 at 04:24, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 05, 2015 at 12:43:42PM -0200, Fabio Estevam wrote:
Many SPI flashes have protection bits (BP2, BP1 and BP0) in the status register that can protect selected regions of the SPI NOR.
Take these bits into account when performing erase operations, making sure that the protected areas are skipped.
Tested on a mx6qsabresd:
=> sf probe SF: Detected M25P32 with page size 256 Bytes, erase size 64 KiB, total 4 MiB => sf protect lock 0x3f0000 0x10000 => sf erase 0x3f0000 0x10000 offset 0x3f0000 is protected and cannot be erased SF: 65536 bytes @ 0x3f0000 Erased: ERROR => sf protect unlock 0x3f0000 0x10000 => sf erase 0x3f0000 0x10000 SF: 65536 bytes @ 0x3f0000 Erased: OK
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com [re-worked to fit the lock common to dm and non-dm] Signed-off-by: Jagan Teki jteki@openedev.com Reviewed-by: Tom Rini trini@konsulko.com Reviewed-by: Heiko Schocher hs@denx.de Reviewed-by: Jagan Teki jteki@openedev.com
Applied to u-boot/master, thanks!
This patch breaks chromebook_link - I think because it adds a new operation which is not supported by all flash chips. Those that are not supported (i.e that don't have the 'flash_is_locked' method) should still work.
Also I don't like the way this adds new operations to struct spi_flash. These should go in struct dm_spi_flash_ops for driver model, and be compatible with the driver-model way of doing things.
Can you please take a look?
I think it's a bit more complex, I thought we had covered the not supported case. I wonder if it's the same chip family and thus thought to be, but not in this case, supported?