[U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode
Simon Goldschmidt
sgoldschmidt at de.pepperl-fuchs.com
Mon May 14 07:47:28 UTC 2018
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.
Simon
More information about the U-Boot
mailing list