[U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Simon Goldschmidt]

Am 05.12.2018 um 07:55 schrieb Simon Goldschmidt:
> On Wed, Dec 5, 2018 at 7:51 AM Vignesh R <vigneshr at ti.com> wrote:
>>
>> On 05/12/18 1:41 AM, Simon Goldschmidt wrote:
>>> Am 04.12.2018 um 13:55 schrieb Boris Brezillon:
>>>> On Tue, 4 Dec 2018 17:56:48 +0530
>>>> Vignesh R <vigneshr at ti.com> wrote:
>>>>
>>>>> U-Boot SPI NOR support (sf layer) is quite outdated as it does not
>>>>> support 4 byte addressing opcodes, SFDP table parsing and different types of
>>>>> quad mode enable sequences. Many newer flashes no longer support BANK
>>>>> registers used by sf layer to a access >16MB space.
>>>>> Also, many SPI controllers have special MMIO interfaces which provide
>>>>> accelerated read/write access but require knowledge of flash parameters
>>>>> to make use of it. Recent spi-mem layer provides a way to support such
>>>>> flashes but sf layer isn't using that.
>>>>> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
>>>>> spi-mem support on top.
>>>>> So, we gain 4byte addressing support and SFDP support. This makes
>>>>> migrating to U-Boot MTD framework easier.
>>>>
>>>> Glad to see that happen sooner than I had expected. Looks like the
>>>> patch series is in a good shape already, and I'm happy to see the
>>>> u-boot spi-nor layer being based on the Linux one.
>>
>>>>
>>>> Good job, and thanks again for working on that!
>>>
>>> Right, I do appreciate this!
>>>
>>
>> Thanks!
>>
>>> I did some compilation tests first and I'm happy to say that with the
>>> SPL_SPI_FLASH_TINY option enabled, my SPL is about 1900 byte smaller
>>> than before :-)
>>>
>>> However, my socfpga socrates board does not boot. I'll have to
>>> investigate why. I just applied this series and compiled for
>>> socfpga_socrates_defconfig. Is there anything else I should have changed
>>> to make it work?
>>>
>>
>> Oops, that's unfortunate.
>> Just to be sure, does SPL fail to come up or SPL fails to load U-Boot
>> from flash? Is this with SPL_SPI_FLASH_TINY enabled?
> 
> I tried both TINY and standard. Both are failing to load U-Boot (I get
> the standard error message that loading from SPI flash failed).
> 
>> Could you enable debug prints at the end of spi_mem_exec_op() in
>> drivers/spi/spi-mem.c to see what commands are sent and their responses?
> 
> OK, I'll do that.
> 
>> I have TI EVM with Cadence QSPI(like SoCFPGA) but with a Spansion flash
>> and that seems to work fine with both full and tiny stack.

OK, so I enabled some debugging and the first issue is that U-Boot has 
SNOR_MFR_MICRON and SNOR_MFR_ST while Linux only has SNOR_MFR_MICRON but 
defines it to CFI_MFR_ST (0x20, U-Boot ends up with 0x2c). While this 
might be correct, it leads to my n25q256a not being handled as 
"micron-like" and the code falls through to using Spansion-like opcode 
(0x17) that my chip does not understand.

However, after changing this (and using opcode 0xb7 to bring the chip 
into 4 byte mode, including 0x06 for write-enable), it still does not 
work as it uses the 'READ' opcode 0x03 instead of the 'FAST READ' opcode 
0x0b that U-Boot used until now. The problem here might be that 'READ' 
cannot do Quad-SPI (4-4-4) and I'm not sure the Cadence driver can 
handle Extended-SPI (1-1-1) that the 'READ' command is limited to...

Using SFDP would probably help, but that doesn't compile (as I wrote in 
the other thread).

On the other hand, enabling SFDP will increase the text/rodata size for 
SPL. We might need to remove the non-SFDP and write code as a counter 
measure to prevent increasing code size.

Regards,
Simon