[U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode

[Simon Goldschmidt]

On 14.05.2018 09:47, Simon Goldschmidt wrote:
> 
> 
> On 14.05.2018 09:22, Jagan Teki wrote:
>> On Mon, May 14, 2018 at 12:34 PM, Simon Goldschmidt
>> <sgoldschmidt at de.pepperl-fuchs.com> wrote:
>>> + Marek for the socfpga platform, see below
>>>
>>> On 07.12.2017 06:49, Jagan Teki wrote:
>>>>
>>>> On Tue, Dec 5, 2017 at 11:50 AM, Goldschmidt Simon
>>>> <sgoldschmidt at de.pepperl-fuchs.com> wrote:
>>>>>
>>>>> + Lukasz (as a reviewer of my patch[1])
>>>>>
>>>>> On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote:
>>>>>>
>>>>>> This is the patch[1] for 4-byte addressing, but I would wonder how 
>>>>>> can
>>>>>> proceed
>>>>>> operations with 4-byte if we disable during probe.
>>>>>>
>>>>>> [1] http://git.denx.de/?p=u-boot-
>>>>>> spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee17dca
>>>>>
>>>>>
>>>>> OK, so your patch does something different than what I did.
>>>>>
>>>>> I was trying to keep the change to U-Boot as small as possible, only
>>>>> fixing this issue I was seeing:
>>>>>
>>>>> After a soft-reboot where the SPI chip was not reset, it is left in
>>>>> 4-byte addressing mode (linux uses this mode, obviously). Remember
>>>>> that 4-byte mode is not a permanent setting, so we can enter and
>>>>> leave it any time we like by issuing a command.
>>>>>
>>>>> U-Boot uses the Bank Address Register (BAR) for spi flash chips with
>>>>> more than 16 MByte, so it impclitly assumes that the chip is in
>>>>> 3-byte address mode. As I see it, your patch is worth a discussion
>>>>> named "should we use 4-byte addressing mode on spi flash chips?".
>>>>> I do think this is a better alternative than writing BAR! But this
>>>>> change probably needs discussion and testing.
>>>>
>>>>
>>>> OK, will review your patch.
>>>
>>>
>>> Any update here? The last input on this is about five months old! 
>>> This is
>>> the last patch I need to run my socfpga board from qspi.
>>>
>>> I added Marek to the discussion as at least the SoCrates board does 
>>> not have
>>> a reset connected to the qspi chip and needs this as well. Note that the
>>> system boot rom does not have a problem with the chip being in 4-byte 
>>> mode
>>> but SPL fails to load U-Boot from qspi.
>>
>> Does Linux do this stuff? say my flash in 4-byte and flashed SPL and 
>> rebooted.
> 
> Yes. My code is inspired by 'drivers/mtd/spi-bor/spi-nor.c' function 
> 'set_4byte'. I'm using 4.9 where they don't have support for 4 byte 
> opcodes (which is why I'm seeing this bug after all). OK, this is not 
> the latest kernel, but it's LTS, so I think U-Boot should handle this 
> Kernel.
> 
> What happens in Linux (4.9) is that depending on the flash size, 4-byte 
> mode is *always* enabled. And it stays enabled after soft reboot. So 
> consequently, we have to *always* disable it in U-Boot.
> 
> In newer versions, they still use 4-byte mode if the flash chip does not 
> support 4-byte opcodes. I suppose that would fix it for me, too, but I'm 
> stuck with LTS for now.

Do you need any more information here? I'd really love to get this into 
2018.07, finally. As I said before, this is the last patch missing for 
socfpga cyclone5 running from qspi.


Thanks,
Simon