On 4 May 2015 at 15:35, Marek Vasut <ma...@denx.de> wrote: > On Monday, May 04, 2015 at 03:18:56 PM, Michal Suchanek wrote: >> On 4 May 2015 at 14:12, Marek Vasut <ma...@denx.de> wrote: >> > On Monday, May 04, 2015 at 01:11:03 PM, Michal Suchanek wrote: >> >> >> >> It mentions both >> >> 32KB Block Erase (BE) (52H) >> >> and >> >> 64KB Block Erase (BE) (D8H) >> > >> > The SPI NOR framework will use 0xbe opcode, no problem. >> > >> >> So the chip probably tries its best to be compatible with any command >> >> set and this last patch is not needed. The memory organization table >> >> on page 7 is not all that reassuring, though. >> > >> > Which exact part do you refer to please ? >> >> Start of page 7 where it says sector size 32/64K in either datasheet. >> >> It can refer to both BE opcode variants being supported but it's quite >> unclear. > > My guess here would be that the internal organisation of the SPI NOR is > in 4k blocks, which is no surprise really. My understanding is that opcode > 0x52 erases 8x4k sector (ie. 32k of data) while 0xd8 erases 16x4k sector > (ie. 64k of data). I don't see any problem here -- there are two different > opcodes which do two different things and their behavior matches the one on > various other SPI NORs. > >> Write protection seems to be calculated in 4k sectors and not blocks >> so the block size does not seem very relevant. > > See above. Does it make sense now please ? >
Yes, makes sense. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
