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

[Jagan Teki]

Hi Simon,

On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt
<sgoldschmidt at de.pepperl-fuchs.com> wrote:
>
> 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.

The point I'm not clear is we don't have 4-byte addressing (we are
using Bank addressing for > 16MiB) so how come we disable 4-byte
addressing for the sake of other software blocks enabled it? It's like
a hack to me.

Jagan.