From mboxrd@z Thu Jan 1 00:00:00 1970 From: Prabhakar Kushwaha Date: Sat, 2 Jun 2018 11:58:40 +0000 Subject: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode In-Reply-To: <517ac0ff-30cc-b88a-5cc1-c551fa3f7717@denx.de> References: <7ba7e1e2-fa0f-82bd-8aba-bd0b6088cf52@de.pepperl-fuchs.com> <72440169-ad4a-3ada-a16e-84d923fdfec2@de.pepperl-fuchs.com> <517ac0ff-30cc-b88a-5cc1-c551fa3f7717@denx.de> 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 > -----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 ; Jagan Teki > > 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 > >>> 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] > >>>>>>>>>>>> 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