On Wed, May 30, 2018 at 1:42 PM, Simon Goldschmidt <sgoldschm...@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 >> <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? > > > 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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot