From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Wed, 30 May 2018 13:54:16 +0200 Subject: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode In-Reply-To: References: <7ba7e1e2-fa0f-82bd-8aba-bd0b6088cf52@de.pepperl-fuchs.com> <31fe26f5-ca48-1b39-0f14-b06d2619e770@de.pepperl-fuchs.com> Message-ID: <857c6047-f355-b2da-52e4-7fec8c3035ca@de.pepperl-fuchs.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >> wrote: >>> >>> >>> On 30.05.2018 07:10, Jagan Teki wrote: >>>> >>>> On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt >>>> 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 >>>>>> 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 >>>>>>>>> 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 >>>>>>>>>>> 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