[U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework

From: Jagan Teki <jagan@amarulasolutions.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework
Date: Sat, 15 Dec 2018 19:24:57 +0530	[thread overview]
Message-ID: <CAMty3ZBdtC-PkT4UaqHF76iw4W4UogyAAJSYLcrHxQk4zz=47Q@mail.gmail.com> (raw)
In-Reply-To: <1cd66c4d-d37b-e48b-0a6a-6037e1d255f8@ti.com>

On Fri, Dec 14, 2018 at 9:23 PM Vignesh R <vigneshr@ti.com> wrote:
>
> On 14/12/18 3:43 PM, Jagan Teki wrote:
> > On Wed, Dec 12, 2018 at 11:02 PM Vignesh R <vigneshr@ti.com> wrote:
> >>
> >> U-Boot SPI NOR support (sf layer) is quite outdated as it does not
> >> support 4 byte addressing opcodes, SFDP table parsing and different types of
> >> quad mode enable sequences. Many newer flashes no longer support BANK
> >> registers used by sf layer to a access >16MB space.
> >> Also, many SPI controllers have special MMIO interfaces which provide
> >> accelerated read/write access but require knowledge of flash parameters
> >> to make use of it. Recent spi-mem layer provides a way to support such
> >> flashes but sf layer isn't using that.
> >> This patch series syncs SPI NOR framework from Linux v4.19. It also adds
> >> spi-mem support on top.
> >> So, we gain 4byte addressing support and SFDP support. This makes
> >> migrating to U-Boot MTD framework easier.
> >>
> >> Tested with few Spansion, micron and macronix flashes with TI's dra7xx,
> >> k2g, am43xx EVMs. I dont have access to flashes from other vendors. So,
> >> I would greatly appreciate testing on other platforms. Complete series
> >> with dependencies here[1]
> >>
> >> For clean build on some platforms, depends on CONFIG_SPI_FLASH migration
> >> to defconfigs [2]
> >>
> >> [1] https://github.com/r-vignesh/u-boot.git  branch: spi-nor-mig-patch-v1
> >> [2] https://patchwork.ozlabs.org/patch/1007485/
> >>
> >> Patch 12-15 are compile tested.
> >
> > Fist of all thanks for your time and work on this.
> >
> > Since most of the discussion on the individual patches seems similar,
> > repeat and never ended. I'm trying to summarize my comments here.
> > 1) You can sync or add new features by grabbing the code from Linux,
> > but I don't recommend __UBOOT macro or any Linux specific stuff  in
> > drivers/mtd/spi
>
> I am fine either way.
>
> > 2) For BAR support, lets place it as it is and support via spi-nor
>
> Problem is, it not desirable to use BAR as default because its not
> stateless and does not work with all flash parts. OTOH, it seems like 4
> byte addressing (stateless dedicated opcode or with enter/exit 4 byte
> mode) seems to be standard.
> Also, Linux doesn't support BAR and haven't seen any request for BAR
> support. Why support additional feature and burden of maintaining when
> it may not be needed.
>
> But if you insist, I just have to add BAR support back.

It's not about insistence, ie how we support since from long and
u-boot bootloader project does in general. bootloader can be some
certain boot difference functionalities unlike Linux, it's better not
to compare u-boot with Linux in all cases.

Example we have SPI_TX_BYTE which usually not supported in Linux.
Since it's ich controller specific and it require for bootloader to do
byte tx on that specific controller, so we supported. Same for the
case with the BAR, this specific controller(or supported boards) has
been in U-Boot since from long and they do upstream well. So we need
to support BAR in any case or we can find any alternative to work the
same functionalities. (we tried before but ended-up adding BAR)

>
> > 3) For dual flash, wait for Xilinx developers if they really want to support it?
>
> Sorry, this feature was never supported properly *in mainline U-Boot*.
> If support is needed in the future, we can accept patches on top of new
> framework.

Siva, Michael any time-line to work on this topic?