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

Simon Goldschmidt sgoldschmidt at de.pepperl-fuchs.com
Wed May 30 11:54:16 UTC 2018



On 30.05.2018 13:27, Marek Vasut wrote:
> On 05/30/2018 01:25 PM, 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?
>> what if u-boot operates in 4-bytes and trigger watchdog, should rom
>> boots from 4-byte addressing.
> 
> IMO his board needs a SPI NOR reset, otherwise he will always have
> reliability problems with booting. There will always be cornercases
> where the CPU reboots and SPI NOR is left in some crappy state and the
> machine will just hang. If you screw up the reset routing, your hardware
> is DOOMED and there's no fixing it in software.
> 
> That said, the 3byte addressing mode in U-Boot is crap too and should've
> been fixed since forever by importing the Linux SPI NOR stack.

So isn't that porting in progress? I haven't followed the ML for that 
long though, so I really can't tell what's going on here :-)

Simon


More information about the U-Boot mailing list