[PATCH] mtd: spi-nor: fix options for mx66l51235f

[Alexander Amelkin]

27.08.2018 14:34, Marek Vasut wrote:
>
>>>> According to the datasheet for mx66l51235f, "The device default is in
>>>> 24-bit address mode" (section 9-10). Having option SPI_NOR_4B_OPCODES
>>>> makes the code act as if the device was already in 4B mode and didn't
>>>> need the EN4B command. That prevents this chip from functioning on
>>>> systems where the boot loader left the chip in 3B mode (e.g. if the
>>>> chip wasn't used during the boot process).
>>>>
>>>> Hence, this commit removes the SPI_NOR_4B_OPCODES option for
>>>> mx66l51235f (added previously by commit d342b6a973af).
>>> Could it be there are two variants of the chip, one which supports the
>>> 4B opcodes and one which does not ? Wouldn't be the first time I saw
>>> this. If this chip supports the SFDP tables, you can check those.
>> I was unable to find another variant of the chip. There is only one specified in the datasheet:
>> http://www.macronix.com/Lists/Datasheet/Attachments/7401/MX66L51235F,%203V,%20512Mb,%20v1.1.pdf
>> and it says that the device supports both 3B and 4B modes, but defaults to 3B (24-bit) mode.
> So keep the 4B part in. Linux will just not reconfigure the device to 4B
> mode using register write, but will instead issue the 4B opcode
> directly, without any stateful change.
Marek, thank you for asking all these questions. They made me conduct a deeper investigation than just finding the commit that broke it and reverting it. It appears that OpenPOWER P8's SBE code (the thing that P8 CPU runs first from its built-in memory) expects the PNOR flash chip to be in EN4B mode. It reads the rest of OpenPOWER Firmware using a usual READ (0x03) command with 4 bytes of address. Always. That's why, I believe, Roman's commit broke host booting for us.

Probably it would be best not to merge this patch into Linux kernel. I'll discuss it with colleagues from OpenPOWER community and we'll probably fix it on SBE side.

As for renaming the chip, I can provide a patch just for that. Or we can leave it as is.

Thanks.
Alexander.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180828/4983db74/attachment.sig>