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

Thu Jan 31 15:08:17 UTC 2019

On Thu, Jan 31, 2019 at 4:02 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Jan 31, 2019 at 03:58:25PM +0100, Simon Goldschmidt wrote:
> > On Thu, Jan 31, 2019 at 3:54 PM Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Jan 31, 2019 at 08:21:29PM +0530, Jagan Teki wrote:
> > > > On Thu, Jan 31, 2019 at 8:18 PM Simon Goldschmidt
> > > > <simon.k.r.goldschmidt at gmail.com> wrote:
> > > > >
> > > > > On Thu, Jan 31, 2019 at 3:43 PM Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Jan 31, 2019 at 08:10:53PM +0530, Jagan Teki wrote:
> > > > > > > On Tue, Jan 29, 2019 at 11:19 AM Vignesh R <vigneshr at ti.com> wrote:
> > > > > > > >
> > > > > > > > Here is the v3 of SPI NOR migration(github branch at [1]). I have
> > > > > > > > retained Tested-by from v2 as this is just re split of patches and
> > > > > > > > minor fixups.
> > > > > > > >
> > > > > > > > Travis ci reports all green.
> > > > > > > >
> > > > > > > > Change log:
> > > > > > > > Since v2:
> > > > > > > > Split sync up patches into smaller versions so that its easier for review.
> > > > > > > > Address comments by Jagan and Simon Goldschmidt on v2.
> > > > > > > > Make SPI_FLASH_TINY(read only SF stack)  as default for SPL build to
> > > > > > > > offset against size increase due to new code.
> > > > > > > >
> > > > > > > > Since v1:
> > > > > > > > Remove #ifindef __UBOOT__
> > > > > > > > Add back BAR support, but dont enable as default for all platform (see
> > > > > > > > 10/11 for more details)
> > > > > > > > Enable SPI_FLASH_TINY on boards where there is SPL size constraint as
> > > > > > > > seen on travis ci builds.
> > > > > > > > Drop sf_mtd changes for now as it seems to cause issues.
> > > > > > > > v1: https://patchwork.ozlabs.org/cover/1012146/
> > > > > > > >
> > > > > > > > Since RFC v2:
> > > > > > > > Fix issues reported by Simon Goldschmidt wrt 4 use of byte addressing opcode
> > > > > > > > Fix issues in compiling SFDP code
> > > > > > > > Re organize file names and Makefile to simply spi-nor-tiny inclusion
> > > > > > > > Remove SPI_FLASH_BAR and SF_DUAL_FLASH as these are no longer used
> > > > > > > > RFC v2: https://patchwork.ozlabs.org/cover/1007589/
> > > > > > > >
> > > > > > > > Since RFC v1:
> > > > > > > > Add lightweight SPI flash stack for boards with SPL size constraints
> > > > > > > > Provide non DM version of spi-mem
> > > > > > > > Fix build issues on different platforms as reported by travis-ci on v1
> > > > > > > >
> > > > > > > > RFC v1: https://patchwork.ozlabs.org/cover/1004689/
> > > > > > > >
> > > > > > > > Background:
> > > > > > > >
> > > > > > > > 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-v3
> > > > > > > > [2] https://patchwork.ozlabs.org/patch/1007485/
> > > > > > > >
> > > > > > > > Vignesh R (20):
> > > > > > > >   configs: Move CONFIG_SPI_FLASH into defconfigs
> > > > > > > >   bitops: Fix GENMASK definition for Sandbox
> > > > > > > >   spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes
> > > > > > > >   spi: spi-mem: Extend spi_mem_adjust_op_size() to honor max xfer size
> > > > > > > >   spi: spi-mem: Claim SPI bus before spi mem access
> > > > > > > >   spi: Add non DM version of SPI_MEM
> > > > > > > >   sh: bitops: add hweight*() macros
> > > > > > > >   mtd: spi: Port SPI NOR framework from Linux
> > > > > > > >   mtd: spi: spi-nor-core: Add SPI MEM support
> > > > > > > >   mtd: spi: spi-nor-core: Add 4 Byte addressing support
> > > > > > > >   mtd: spi: spi-nor-core: Add SFDP support
> > > > > > > >   mtd: spi: spi-nor-core: Add back U-Boot specific features
> > > > > > > >   mtd: spi: sf_probe: Add "jedec,spi-nor" compatible string
> > > > > > > >   mtd: spi: Switch to new SPI NOR framework
> > > > > > > >   mtd: spi: Remove unused files
> > > > > > > >   mtd: spi: Add lightweight SPI flash stack for SPL
> > > > > > > >   spl: Kconfig: Enable SPI_FLASH_TINY by default for SPL
> > > > > > > >   configs: Remove SF_DUAL_FLASH
> > > > > > > >   configs: Don't use SPI_FLASH_BAR as default
> > > > > > > >   MAINTAINERS: Add an entry for SPI NOR
> > > > > > >
> > > > > > > Except 16/20 and 19/20, all look fine to me.
> > > > > > >
> > > > > > > Reviewed-by: Jagan Teki <jagan at openedev.com>
> > > > > > > Tested-by: Jagan Teki <jagan at amarulasolutions.com> #zynq-microzed
> > > > > >
> > > > > > And based on the Xilinx folks reply to 19/20, is 16/20 something we can
> > > > > > deal with as a follow-up?  Thanks!
> > > > >
> > > > > Going without 16/20 will increase the footprint in SPL. Given the limitation
> > > > > of size checks discussed recently, I don't think that would be a good idea.
> > > >
> > > > Please read the my comments again, I won't oppose the change.
> > >
> > > Ah, I think I have the numbers backwards then, I was thinking 19 was the
> > > one about BAR stuff and 16 was some style comments?  But I do want to
> > > stress again that I want to see this come in and the we deal with any
> > > further fall-out, this cycle.  Thanks!
> >
> > You were right about 19 (BAR). But 16 contains size-improvements for SPL.
> > The new framework as is lets SPL grow. Patch 16 introduces size improvements
> > for SPL that are a bit unrelated to this series but help making it acceptable
> > because it ensures this series as a whole does not grow SPL.
> >
> > Oh, you meant commit 16 as is and make style changes later?
>
> I mean, I think I should finish this cup of coffee before it gets cold
> and re-check the comments.  I swear I saw Jagan request some changes to
> one patch over importing various unused kernel code (EXPORT_SYMBOL_GPL,
> etc).  That seems like something to address after.  And with respect to
> the BAR changes, I really want to see the answer from the Xilinx folks.

OK, then I fully agree.

About the Xilinx BAR stuff: I took the time to dig into the TRM of
Zynq 7000 [1] as an
example. It says it can only access 16 MiB from one chip (unless using raw SPI
mode in which it only uses one data line). But then it also says:
"evice densities up to 128 Mb for I/O and linear mode. Densities
greater than 128 Mb
are supported in I/O mode".

So which is it now?

[1] https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

Regards,
Simon