[U-Boot] spi and block bits
Hi there,
I stumbled across a situation where the SPI flash on my board was write protected and i could not unlock it in the bootloader. This is especially unfortunate because the recovery mechanism relies on the bootloader to be able to erase the environment.
So any ideas how to fix this? I didn't see any code which unlocks the sectors yet.
We could add a lock/unlock function to the spi system, then call unlock in the beginning of saveenv() and lock at the end of saveenv(). Eg.
lockbits = read_status() & LOCK_BITS spi_unlock_all() saveenv() spi_lock(lockbits)
Also this should be exposed to the CLI somehow. "sf lock/unlock"?
-michael
On 9 February 2015 at 04:57, Michael Walle michael@walle.cc wrote:
Hi there,
I stumbled across a situation where the SPI flash on my board was write protected and i could not unlock it in the bootloader. This is especially unfortunate because the recovery mechanism relies on the bootloader to be able to erase the environment.
Which flash vendor it is? seems like there is a hardware write protected mechanism in ST MICRON flashes.
Please refer that, may be this looks similar to that W#/Vpp CONFIG_SYS_SPI_ST_ENABLE_WP_PIN
So any ideas how to fix this? I didn't see any code which unlocks the sectors yet.
We could add a lock/unlock function to the spi system, then call unlock in the beginning of saveenv() and lock at the end of saveenv(). Eg.
lockbits = read_status() & LOCK_BITS spi_unlock_all() saveenv() spi_lock(lockbits)
Also this should be exposed to the CLI somehow. "sf lock/unlock"?
thanks!
Am 2015-04-16 20:32, schrieb Jagan Teki:
On 9 February 2015 at 04:57, Michael Walle michael@walle.cc wrote:
Hi there,
I stumbled across a situation where the SPI flash on my board was write protected and i could not unlock it in the bootloader. This is especially unfortunate because the recovery mechanism relies on the bootloader to be able to erase the environment.
Which flash vendor it is? seems like there is a hardware write protected mechanism in ST MICRON flashes.
it is a st micron. (see include/configs/lsxl.h)
Please refer that, may be this looks similar to that W#/Vpp CONFIG_SYS_SPI_ST_ENABLE_WP_PIN
But it isn't related to that.
My point was, if linux enables the lock bits, there is no way you can write to the flash in the bootloader anymore. Because it is not possible to clear these bits in u-boot. If you have a macronix or an ST flash the block protection bits are cleared on probe. see sf_probe.c:
/* Flash powers up read-only, so clear BP# bits */ #if defined(CONFIG_SPI_FLASH_ATMEL) || \ defined(CONFIG_SPI_FLASH_MACRONIX) || \ defined(CONFIG_SPI_FLASH_SST) spi_flash_cmd_write_status(flash, 0); #endif
Although as the comment says, it is because these chips power up in read-only state by default. In my case, linux would set these bits.
To be more precise, the fw_setenv will leave the flash write protected and i cannot modify the environment in the bootloader anymore.
-michael
On 17 April 2015 at 12:45, Michael Walle michael@walle.cc wrote:
Am 2015-04-16 20:32, schrieb Jagan Teki:
On 9 February 2015 at 04:57, Michael Walle michael@walle.cc wrote:
Hi there,
I stumbled across a situation where the SPI flash on my board was write protected and i could not unlock it in the bootloader. This is especially unfortunate because the recovery mechanism relies on the bootloader to be able to erase the environment.
Which flash vendor it is? seems like there is a hardware write protected mechanism in ST MICRON flashes.
it is a st micron. (see include/configs/lsxl.h)
Please refer that, may be this looks similar to that W#/Vpp CONFIG_SYS_SPI_ST_ENABLE_WP_PIN
But it isn't related to that.
My point was, if linux enables the lock bits, there is no way you can write to the flash in the bootloader anymore. Because it is not possible to clear these bits in u-boot. If you have a macronix or an ST flash the block protection bits are cleared on probe. see sf_probe.c:
/* Flash powers up read-only, so clear BP# bits */#if defined(CONFIG_SPI_FLASH_ATMEL) || \ defined(CONFIG_SPI_FLASH_MACRONIX) || \ defined(CONFIG_SPI_FLASH_SST) spi_flash_cmd_write_status(flash, 0); #endif
So are you saying clearing BP# bits should also required for Micron as you need to access it on bootloader?
Although as the comment says, it is because these chips power up in read-only state by default. In my case, linux would set these bits.
To be more precise, the fw_setenv will leave the flash write protected and i cannot modify the environment in the bootloader anymore.
I couldn't understand your point can you elaborate, if clearing BP# required for Micron how could it accessed in Linux?
thanks!
participants (2)
-
Jagan Teki -
Michael Walle