1. 10 9月, 2016 1 次提交
  2. 07 9月, 2016 1 次提交
    • T
      TI: Rework SRAM definitions and maximums · fa2f81b0
      Tom Rini 提交于
      On all TI platforms the ROM defines a "downloaded image" area at or near
      the start of SRAM which is followed by a reserved area.  As it is at
      best bad form and at worst possibly harmful in corner cases to write in
      this reserved area, we stop doing that by adding in the define
      NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image
      area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this.
      At current we define the end of scratch space at 0x228 bytes past the
      start of scratch space this this gives us a lot of room to grow.  As
      these scratch uses are non-optional today, all targets are modified to
      respect this boundary.
      
      Tested on OMAP4 Pandaboard, OMAP3 Beagle xM
      
      Cc: Albert Aribaud <albert.u.boot@aribaud.net>
      Cc: Nagendra T S <nagendra@mistralsolutions.com>
      Cc: Vaibhav Hiremath <hvaibhav@ti.com>
      Cc: Lokesh Vutla <lokeshvutla@ti.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Nikita Kiryanov <nikita@compulab.co.il>
      Cc: Paul Kocialkowski <contact@paulk.fr>
      Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
      Cc: Adam Ford <aford173@gmail.com>
      Cc: Steve Sakoman <sakoman@gmail.com>
      Cc: Stefan Roese <sr@denx.de>
      Cc: Thomas Weber <weber@corscience.de>
      Cc: Hannes Schmelzer <oe5hpm@oevsv.at>
      Cc: Thomas Chou <thomas@wytron.com.tw>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Joe Hershberger <joe.hershberger@ni.com>
      Cc: Sam Protsenko <semen.protsenko@linaro.org>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Samuel Egli <samuel.egli@siemens.com>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
      Cc: Ben Whitten <ben.whitten@gmail.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Bin Meng <bmeng.cn@gmail.com>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Cc: Mugunthan V N <mugunthanvnm@ti.com>
      Cc: "B, Ravi" <ravibabu@ti.com>
      Cc: "Matwey V. Kornilov" <matwey.kornilov@gmail.com>
      Cc: Ladislav Michl <ladis@linux-mips.org>
      Cc: Ash Charles <ashcharles@gmail.com>
      Cc: "Kipisz, Steven" <s-kipisz2@ti.com>
      Cc: Daniel Allred <d-allred@ti.com>
      Signed-off-by: NTom Rini <trini@konsulko.com>
      Tested-by: NLokesh Vutla <lokeshvutla@ti.com>
      Acked-by: NLokesh Vutla <lokeshvutla@ti.com>
      Tested-by: NLadislav Michl <ladis@linux-mips.org>
      fa2f81b0
  3. 27 8月, 2016 1 次提交
    • T
      ARM: Move SYS_CACHELINE_SIZE over to Kconfig · 067716ba
      Tom Rini 提交于
      This series moves the CONFIG_SYS_CACHELINE_SIZE.  First, in nearly all
      cases we are mirroring the values used by the Linux Kernel here.  Also,
      so long as (and in this case, it is true) we implement flushes in hunks
      that are no larger than the smallest implementation (and given that we
      mirror the Linux Kernel, again we are fine) it is OK to align higher.
      The biggest changes here are that we always use 64 bytes for CPU_V7 even
      if for example the underlying core is only 32 bytes (this mirrors
      Linux).  Second, we say ARM64 uses 64 bytes not 128 (as found in the
      Linux Kernel) as we do not need multi-platform support (to this degree)
      and only the Cavium ThunderX 88xx series has a use for such large
      alignment.
      
      Cc: Albert Aribaud <albert.u.boot@aribaud.net>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Prafulla Wadaskar <prafulla@marvell.com>
      Cc: Luka Perkov <luka.perkov@sartura.hr>
      Cc: Stefan Roese <sr@denx.de>
      Cc: Nagendra T S <nagendra@mistralsolutions.com>
      Cc: Vaibhav Hiremath <hvaibhav@ti.com>
      Acked-by: NLokesh Vutla <lokeshvutla@ti.com>
      Cc: Steve Rae <steve.rae@raedomain.com>
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Nikita Kiryanov <nikita@compulab.co.il>
      Cc: Stefan Agner <stefan.agner@toradex.com>
      Acked-by: NHeiko Schocher <hs@denx.de>
      Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
      Cc: Peter Griffin <peter.griffin@linaro.org>
      Acked-by: NPaul Kocialkowski <contact@paulk.fr>
      Cc: Anatolij Gustschin <agust@denx.de>
      Acked-by: N"Pali Rohár" <pali.rohar@gmail.com>
      Cc: Adam Ford <aford173@gmail.com>
      Cc: Steve Sakoman <sakoman@gmail.com>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      Cc: Nishanth Menon <nm@ti.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Robert Baldyga <r.baldyga@samsung.com>
      Cc: Minkyu Kang <mk7.kang@samsung.com>
      Cc: Thomas Weber <weber@corscience.de>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: David Feng <fenghua@phytium.com.cn>
      Cc: Alison Wang <b18965@freescale.com>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: York Sun <york.sun@nxp.com>
      Cc: Shengzhou Liu <Shengzhou.Liu@nxp.com>
      Cc: Mingkai Hu <mingkai.hu@nxp.com>
      Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
      Cc: Aneesh Bansal <aneesh.bansal@freescale.com>
      Cc: Saksham Jain <saksham.jain@nxp.com>
      Cc: Qianyu Gong <qianyu.gong@nxp.com>
      Cc: Wang Dongsheng <dongsheng.wang@nxp.com>
      Cc: Alex Porosanu <alexandru.porosanu@freescale.com>
      Cc: Hongbo Zhang <hongbo.zhang@nxp.com>
      Cc: tang yuantian <Yuantian.Tang@freescale.com>
      Cc: Rajesh Bhagat <rajesh.bhagat@nxp.com>
      Cc: Josh Wu <josh.wu@atmel.com>
      Cc: Bo Shen <voice.shen@atmel.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Hannes Schmelzer <oe5hpm@oevsv.at>
      Cc: Thomas Chou <thomas@wytron.com.tw>
      Cc: Joe Hershberger <joe.hershberger@ni.com>
      Cc: Sam Protsenko <semen.protsenko@linaro.org>
      Cc: Bin Meng <bmeng.cn@gmail.com>
      Cc: Christophe Ricard <christophe-h.ricard@st.com>
      Cc: Anand Moon <linux.amoon@gmail.com>
      Cc: Beniamino Galvani <b.galvani@gmail.com>
      Cc: Carlo Caione <carlo@endlessm.com>
      Cc: huang lin <hl@rock-chips.com>
      Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
      Cc: Xu Ziyuan <xzy.xu@rock-chips.com>
      Cc: "jk.kernel@gmail.com" <jk.kernel@gmail.com>
      Cc: "Ariel D'Alessandro" <ariel@vanguardiasur.com.ar>
      Cc: Kever Yang <kever.yang@rock-chips.com>
      Cc: Samuel Egli <samuel.egli@siemens.com>
      Cc: Chin Liang See <clsee@altera.com>
      Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Ian Campbell <ijc@hellion.org.uk>
      Cc: Siarhei Siamashka <siarhei.siamashka@gmail.com>
      Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
      Cc: Andre Przywara <andre.przywara@arm.com>
      Cc: Bernhard Nortmann <bernhard.nortmann@web.de>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Ben Whitten <ben.whitten@gmail.com>
      Cc: Tom Warren <twarren@nvidia.com>
      Cc: Alexander Graf <agraf@suse.de>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Cc: Vitaly Andrianov <vitalya@ti.com>
      Cc: "Andrew F. Davis" <afd@ti.com>
      Cc: Murali Karicheri <m-karicheri2@ti.com>
      Cc: Carlos Hernandez <ceh@ti.com>
      Cc: Ladislav Michl <ladis@linux-mips.org>
      Cc: Ash Charles <ashcharles@gmail.com>
      Cc: Mugunthan V N <mugunthanvnm@ti.com>
      Cc: Daniel Allred <d-allred@ti.com>
      Cc: Gong Qianyu <Qianyu.Gong@freescale.com>
      Signed-off-by: NTom Rini <trini@konsulko.com>
      Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NChin Liang See <clsee@altera.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NPaul Kocialkowski <contact@paulk.fr>
      067716ba
  4. 06 8月, 2016 1 次提交
    • T
      omap3: Drop omap3_evm_quick_* targets · 584550d7
      Tom Rini 提交于
      These config targets were added well before the Kconfig migration began
      as a way to demonstrate how to make these platforms work with cut down
      features.  At this point in time they no longer serve a good purpose so
      remove them.
      Signed-off-by: NTom Rini <trini@konsulko.com>
      584550d7
  5. 10 6月, 2016 1 次提交
  6. 26 4月, 2016 3 次提交
  7. 06 2月, 2016 1 次提交
  8. 05 8月, 2015 1 次提交
  9. 26 6月, 2015 1 次提交
  10. 13 3月, 2015 1 次提交
  11. 05 12月, 2014 1 次提交
  12. 27 10月, 2014 1 次提交
  13. 22 11月, 2013 1 次提交
    • P
      mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-scheme · 3f719069
      pekon gupta 提交于
      This patch adds new CONFIG_NAND_OMAP_ECCSCHEME, replacing other distributed
      CONFIG_xx used for selecting NAND ecc-schemes.
      This patch aims at solving following issues.
      
      1) Currently ecc-scheme is tied to SoC platform, which prevents user to select
         other ecc-schemes also supported in hardware. like;
       - most of OMAP3 SoC platforms use only 1-bit Hamming ecc-scheme, inspite
         the fact that they can use higher ecc-schemes like 8-bit ecc-schemes with
         software based error detection (OMAP_ECC_BCH4_CODE_HW_DETECTION_SW).
       - most of AM33xx SoC plaforms use 8-bit BCH ecc-scheme for now, but hardware
         supports BCH16 ecc-scheme also.
      
      2) Different platforms use different CONFIG_xx to select ecc-schemes, which
         adds confusion for user while migrating platforms.
       - *CONFIG_NAND_OMAP_ELM* which enables ELM hardware engine, selects only
          8-bit BCH ecc-scheme with h/w based error-correction (OMAP_ECC_BCH8_CODE_HW)
          whereas ELM hardware engine supports other ecc-schemes also like; BCH4,
          and BCH16 (in future).
       - *CONFIG_NAND_OMAP_BCH8* selects 8-bit BCH ecc-scheme with s/w based error
          correction (OMAP_ECC_BCH8_CODE_HW_DETECTION_SW).
       - *CONFIG_SPL_NAND_SOFTECC* selects 1-bit Hamming ecc-scheme using s/w library
      
      Thus adding new *CONFIG_NAND_OMAP_ECCSCHEME* de-couples ecc-scheme dependency
      on SoC platform and NAND driver. And user can select ecc-scheme independently
      foreach board.
      However, selection some hardware based ecc-schemes (OMAP_ECC_BCHx_CODE_HW) still
      depends on presence of ELM hardware engine on SoC. (Refer doc/README.nand)
      Signed-off-by: NPekon Gupta <pekon@ti.com>
      3f719069
  14. 15 10月, 2013 1 次提交
  15. 24 7月, 2013 1 次提交
  16. 14 12月, 2012 1 次提交
  17. 27 11月, 2012 1 次提交
    • S
      spl/nand: introduce CONFIG_SPL_NAND_DRIVERS, _BASE, and _ECC. · 6f2f01b9
      Scott Wood 提交于
      Some small SPLs do not use nand_base.c, and a subset of those also
      require a special driver.  Some SPLs need software ECC but others can't
      fit it.
      
      All existing boards that specify CONFIG_SPL_NAND_SUPPORT have these
      symbols added to preserve existing behavior.
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      --
      v2: use positive logic for including bits of NAND, rather than
      a MINIMAL symbol that excludes things.
      6f2f01b9
  18. 23 10月, 2012 1 次提交
  19. 07 7月, 2012 2 次提交
  20. 27 1月, 2012 1 次提交
    • S
      nand_spl_simple: store ecc data on the stack · d3022c5f
      Stefano Babic 提交于
      Currently nand_spl_simple puts it's temp data at 0x10000 offset in SDRAM
      which is likely to contain already loaded data.
      The patch saves the oob data and the ecc on the stack replacing
      the fixed address in RAM.
      Signed-off-by: NStefano Babic <sbabic@denx.de>
      CC: Ilya Yanok <yanok@emcraft.com>
      CC: Scott Wood <scottwood@freescale.com>
      CC: Tom Rini <tom.rini@gmail.com>
      CC: Simon Schwarz <simonschwarzcor@googlemail.com>
      CC: Wolfgang Denk <wd@denx.de>
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      d3022c5f
  21. 07 12月, 2011 2 次提交
  22. 04 11月, 2011 3 次提交
  23. 22 10月, 2011 1 次提交
  24. 06 10月, 2011 1 次提交
  25. 01 10月, 2011 1 次提交
  26. 04 9月, 2011 2 次提交
  27. 04 8月, 2011 1 次提交
  28. 13 5月, 2011 1 次提交
  29. 28 4月, 2011 1 次提交
  30. 30 11月, 2010 1 次提交
  31. 20 11月, 2010 1 次提交
  32. 05 11月, 2010 2 次提交