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

[Vignesh R]

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.

> 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.

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
>