Am Fr., 14. Dez. 2018, 17:28 hat Vignesh R vigneshr@ti.com geschrieben:
On 14-Dec-18 9:44 PM, Simon Goldschmidt wrote:
Am Fr., 14. Dez. 2018, 16:59 hat Vignesh R <vigneshr@ti.com mailto:vigneshr@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@ti.com <mailto: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 supportBANK
>> registers used by sf layer to a access >16MB space. >> Also, many SPI controllers have special MMIO interfaces whichprovide
>> 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 seemssimilar,
> repeat and never ended. I'm trying to summarize my comments here. > 1) You can sync or add new features by grabbing the code fromLinux,
> 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 seemslike 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 maintainingwhen
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 mainlineU-Boot*.
If support is needed in the future, we can accept patches on top ofnew
framework. > 4) For non-dm code in spi-mem, no comments? (Tom is alreadycommented,
> may be Simon can comment) > -- Regards Vignesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de <mailto:U-Boot@lists.denx.de> https://lists.denx.de/listinfo/u-boot