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

Wed May 30 11:41:40 UTC 2018

On 30.05.2018 13:25, Jagan Teki wrote:
> On Wed, May 30, 2018 at 1:42 PM, Simon Goldschmidt
> <sgoldschmidt at de.pepperl-fuchs.com> wrote:
>>
>>
>> On 30.05.2018 07:10, Jagan Teki wrote:
>>>
>>> On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt
>>> <sgoldschmidt at de.pepperl-fuchs.com> wrote:
>>>>
>>>>
>>>> Hi Jagan,
>>>>
>>>>
>>>> On 21.05.2018 17:09, Jagan Teki wrote:
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>>
>>>> I understand your point. However, there *are* SPI chips without a reset
>>>> line. And if linux brings them into 4-byte address mode and then the system
>>>> gets a warm reset e.g. by the watchdog, where do you suggest to set the chip
>>>> back to 3-byte address mode?
>>>
>>>
>>> What are those chips?
>>
>>
>> For example the EPCQ256N mounted on the EBV Socrates board (Cyclone V SoC),
>> see this doc, pinout is in chapter 1.11.2:
>> https://www.altera.com/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf
>>
>>
>>> what if we have 4-byte addressing mode in
>>> U-Boot, we completely operate these into 3-byte mode by disabling
>>> 4-byte mode?
>>
>>
>> Ehrm, we don't have 4-byte addressing mode in U-Boot. That's the problem. If
>> we would, we would surely execute the opcode I have added and explicitly set
>> the device into 4-byte mode. That would solve the problem.
> 
> I'm not sure I understand this, how should 4-byte addressing solve the
> problem? you claimed in patch that bootrom would need 3-byte
> addressing during warm reset ie what the problem is all about right?

It's not the boot rom which needs 3-byte mode but it's SPL (and U-Boot).

Maybe I expressed myself unclear. Let me explain again:

1) Cold reset, qspi chip is in 3-byte addressing mode
2) Boot rom loads SPL from qspi (don't know in which mode that happens)
3) SPL & U-Boot use the chip in 3-byte mode
4) Linux 4.9 is booted, switches the chip into 4-byte mode
    (Note that newer versions seem to use 4-byte opcodes and don't
     touch the mode)
5) Soft reboot, qspi does not get a reset (I know this is not good but 
for now it's just like that.
6) SPL is not loaded from qspi again since the boot rom uses the version 
buffered in onchip SRAM (I think that's strange, too, but that's what 
happens)
7) SPL tries to use the chip in 3-byte mode without changing the mode, 
which, of course, fails.

Now I see three options here:
a) Wire qspi reset to be triggered on warm reset, too: can't do that on 
existing boards
b) Use 4-byte addressing mode or even better, 4-byte opcodes
c) Switch the chip into 3-byte mode

So would a patch to use 4-byte addressing be better accepted?

> what if u-boot operates in 4-bytes and trigger watchdog, should rom
> boots from 4-byte addressing.

As written above, I don't know what the boot rom needs since a reboot 
does not trigger loading from qspi again. Maybe Marek or someone at 
Intel knows more here...

Simon