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

[Simon Goldschmidt]

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

>
>
> On 14-Dec-18 9:44 PM, Simon Goldschmidt wrote:
> >
> >
> > Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <vigneshr at ti.com
> > <mailto: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
> >     <mailto: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?
> >
>
> I am afraid BAR support would be the default as Jagan suggests not to
> change existing behavior. You would have to disable SPI_FLASH_BAR to use
> 4 Byte addressing opcodes.
>

Honestly, I don't like the idea of making BAR the default. Why can't we go
the Linux way and enable BAR (maybe then as default) for boards that need
it only?


> > BTW, should I re-read this series or is it equal to the RFC I tested?
> >
>
> Nope, its same as that branch you gave Tested-by to(sorry forgot to
> carry the tag here). But I may have to do one more revision if above
> change is needed.
>

Ok, thanks.

Regards,
Simon


> Regards
> Vignesh
>
> > 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 <mailto:U-Boot at lists.denx.de>
> >     https://lists.denx.de/listinfo/u-boot
> >
>