On Thu, 2021-04-15 at 07:25 +0200, Stefan Roese wrote: > On 11.04.21 20:47, Marek Vasut wrote: > > According to S26KL512S datasheet [1] and S29GL01GS datasheet [2], > > the procedure to read out PPB lock bits is to send the PPB Entry, > > PPB Read, Reset/ASO Exit. Currently, the code does send incorrect > > PPB Entry, PPB Read and Reset/ASO Exit is completely missing. > > > > The PPB Entry sent is implemented by sending flash_unlock_seq() > > and flash_write_cmd(..., FLASH_CMD_READ_ID). This translates to > > sequence 0x555:0xaa, 0x2aa:0x55, 0x555:0x90=FLASH_CMD_READ_ID. > > However, both [1] and [2] specify the last byte of PPB Entry as > > 0xc0=AMD_CMD_SET_PPB_ENTRY instead of 0x90=FLASH_CMD_READ_ID, > > that is 0x555:0xaa, 0x2aa:0x55, 0x555:0xc0=AMD_CMD_SET_PPB_ENTRY. > > Since this does make sense, this patch fixes it and thus also > > aligns the code in flash_get_size() with flash_real_protect(). > > > > The PPB Read returns 00h in case of Protected state and 01h in case > > of Unprotected state, according to [1] Note 83 and [2] Note 17, so > > invert the result. Moreover, align the arguments with similar code > > in flash_real_protect(). > >
Just saw the PPB lock words passing by and remembered the problems we had with u-boot using PPB to lock/unlock flash. This method is slow and persistent(unlike the Intel method) and this carries all the way to fw_setenv. PPB will write to internal flash bits(same bits every time) and this causes wear on said flash. We had disable flash lock/unlock here due to this wear. The DYB method is a much better fit for u-boot/linux flash locking needs. Jocke
