On Thu, Jan 31, 2019 at 8:24 PM Tom Rini <tr...@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.goldschm...@gmail.com> wrote: > > > > > > On Thu, Jan 31, 2019 at 3:43 PM Tom Rini <tr...@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 <vigne...@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 <ja...@openedev.com> > > > > > Tested-by: Jagan Teki <ja...@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!
BAR change can be alter(even I change while applying) 16/20, has some code removed and same was added during 08/20, I commented to add that part of 08/20. even style changes can be fixed while applying. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
