[U-Boot] spi and block bits

[U-Boot] spi and block bits

[Michael Walle]

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

[U-Boot] spi and block bits

[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.

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!
-- 
Jagan.

[U-Boot] spi and block bits

[Michael Walle]

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

[U-Boot] spi and block bits

[Jagan Teki]

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!
-- 
Jagan.