From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Date: Mon, 21 May 2018 20:39:42 +0530 Subject: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode In-Reply-To: References: Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. Jagan.