On Monday, May 04, 2015 at 03:39:44 PM, Michal Suchanek wrote: > 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.
I'm glad to hear this got cleared up, thanks ! :) Best regards, Marek Vasut -- 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/
