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

[Simon Goldschmidt]

Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <vigneshr at ti.com> geschrieben:

> On 14/12/18 3:43 PM, Jagan Teki wrote:
> > On Wed, Dec 12, 2018 at 11:02 PM Vignesh R <vigneshr at 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.
>

But if we do that, could we please have a config option so that I can
somehow ensure only 4 byte opcoses are used that don't change some state in
the chip?

BTW, should I re-read this series or is it equal to the RFC I tested?

Simon


> > 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.
>
> > 4) For non-dm code in spi-mem, no comments? (Tom is already commented,
> > may be Simon can comment)
> >
>
>
> --
> Regards
> Vignesh
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>