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 >>> <sgoldschm...@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 >>>>> <sgoldschm...@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 >>>>>>>> <sgoldschm...@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 >>>>>>>>>> <sgoldschm...@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? >> >> 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 ;-) -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
