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

[Prabhakar Kushwaha]

> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Marek
> Vasut
> Sent: Wednesday, May 30, 2018 4:53 PM
> To: Simon Goldschmidt <sgoldschmidt at de.pepperl-fuchs.com>; Jagan Teki
> <jagannadh.teki at gmail.com>
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address
> mode
> 
> On 05/30/2018 01:18 PM, Simon Goldschmidt wrote:
> >
> >
> > On 30.05.2018 11:56, Marek Vasut wrote:
> >> On 05/30/2018 07:10 AM, 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]
> >>>>>>>>>>>> https://emea01.safelinks.protection.outlook.com/?url=http%3
> >>>>>>>>>>>> A%2F%2Fgit.denx.de%2F%3Fp%3Du-boot-
> &data=02%7C01%7Cprabhaka
> >>>>>>>>>>>>
> r.kushwaha%40nxp.com%7C339cc76ac69b4defecd508d5c6201e4d%7C6
> >>>>>>>>>>>>
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63663276362809106
> >>>>>>>>>>>>
> 7&sdata=WnAoQnIq48iDPtWamYqKhlaMYSQXm0QdOHp8qBsPxpc%3D&rese
> >>>>>>>>>>>> rved=0
> >>>>>>>>>>>>
> spi.git;a=commitdiff;h=fd0c22a90772379c4c11ba09347d36cc8ee1
> >>>>>>>>>>>> 7dca
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 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?
> >>
> >> Very select few actually have a reset line, which lures HW designers to
> >> believe reseting SPI NOR is optional, which in turn is BS.
> >>
> >>> what if we have 4-byte addressing mode in
> >>> U-Boot, we completely operate these into 3-byte mode by disabling
> >>> 4-byte mode?
> >>
> >> If you operate large chip in 3B addressing mode, you lose a lot of
> >> performance. This should be fixed in U-Boot too.
> >
> > Can you elaborate on the performance loss?
> >
> > Of course I'd also prefer using 4-byte addressing mode or even 4-byte
> > opcodes in U-Boot. However, I'm not sure I'll get the time to implement
> > this. Especially when knowing that there is a big patch to change all
> > this is in the queue... (whatever the status of this is)
> 
> Depends on the usecase really. If you keep switching the banks, it'll be
> a heavy hit. I'm not asking you to implement anything ;-)
> 

Why are we relying the bootROM/pre-loader will only be accessing 16MB of memory (using 3B) memory. 
As per system design, u-boot can be at any location of spi-flash.   

There can be such bootROM/pre-loader which transfer control beyond 16MB
Or
This scenario will never ever come and this is limitation from flash point of view.

--pk