1. 11 Oct, 2015 1 commit
    • Ian Campbell's avatar
      arndale: Apply Cortex-A15 errata #773022 and #774769 · e392b923
      Ian Campbell authored
      We run 4 Arndale boards in our automated test framework, they have
      been running quite happily for quite some time using a Debian Wheezy
      However when upgrading to a Debian Jessie we started seeing frequent
      segmentation faults from gcc when building the kernel, to the extent
      that it is unable to successfully build the kernel twice in a row, and
      often fails on the first attempt.
      Searching around I found https://bugs.launchpad.net/arndale/+bug/1081417
      which pointed towards http://www.spinics.net/lists/kvm-arm/msg03723.html
      and CPU Errata 773022 and 774769.
      This errata needs to be applied to all processors in an SMP system,
      meaning that the usual strategy of applying them in
      arch/arm/cpu/armv7/start.S is not appropriate (since that applies to
      the boot processor only). Instead we apply these errata in the secure
      monitor which is code that is traversed by all processors as they are
      brought up.
      The net affect on Arndale is that ACTLR changes from 0x40 to
      0x2000042. I ran 17 kernel compile iterations overnight with no
      Runtime testing was done on our v2014.10 based branch and forward
      ported (with only minimal and trivial contextual conflicts) to current
      master, where it has been build tested only.
      I suppose in theory these errata apply to any Exynos5250 based boards,
      but Arndale is the only one I have access to and I have therefore
      chosen to be conservative and only apply it there.
      Also, reorder CONFIG_ARM_ERRATA_794072 in README to make the list
      numerically sorted.
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
  2. 02 Oct, 2015 1 commit
    • Albert ARIBAUD \\(3ADEV\\)'s avatar
      I2C: mxc_i2c: make I2C1 and I2C2 optional · 03544c66
      Albert ARIBAUD \\(3ADEV\\) authored
      The driver assumed that I2C1 and I2C2 were always enabled,
      and if they were not, then an asynchronous abort was (silently)
      raised, to be caught much later on in the Linux kernel.
      Fix this by making I2C1 and I2C2 optional just like I2C3 and I2C4
      To make the change binary-invariant, declare I2C1 and I2C2 in
      every include/configs/ file which defines CONFIG_SYS_I2C_MXC.
      Also, while updating README about CONFIG_SYS_I2C_MXC_I2C1 and
      CONFIG_SYS_I2C_MXC_I2C2, add missing descriptions for I2C4 speed
      config options.
      Signed-off-by: default avatarAlbert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
  3. 15 Sep, 2015 1 commit
    • Stefan Roese's avatar
      arm: Remove unused ST-Ericsson u8500 arch · 68282f55
      Stefan Roese authored
      This arch does not seem to be supported / used at all in the current
      U-Boot mainline source tree any more. So lets remove the core u8500 code
      and code that was only referenced by this platform.
      Please note that this patch also removes these config options:
      As they only seem to be referenced by u8500 based boards. Without any
      such board in the current code, these config option don't make sense
      any more. Lets remove them as well.
      If someone still wants to use this platform, then please send patches
      to re-enable support by adding at least one board that references this
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: John Rigby <john.rigby@linaro.org>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Tom Rini <trini@konsulko.com>
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Albert Aribaud <albert.u.boot@aribaud.net>
      Reviewed-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  4. 31 Aug, 2015 1 commit
  5. 21 Aug, 2015 1 commit
  6. 13 Aug, 2015 1 commit
    • Nishanth Menon's avatar
      ARM: Introduce erratum workaround for 801819 · a615d0be
      Nishanth Menon authored
      Add workaround for Cortex-A15 ARM erratum 801819 which says in summary
      that "A livelock can occur in the L2 cache arbitration that might
      prevent a snoop from completing. Under certain conditions this can
      cause the system to deadlock. "
      Recommended workaround is as follows:
      Do both of the following:
      1) Do not use the write-back no-allocate memory type.
      2) Do not issue write-back cacheable stores at any time when the cache
      is disabled (SCTLR.C=0) and the MMU is enabled (SCTLR.M=1). Because it
      is implementation defined whether cacheable stores update the cache when
      the cache is disabled it is not expected that any portable code will
      execute cacheable stores when the cache is disabled.
      For implementations of Cortex-A15 configured without the “L2 arbitration
      register slice” option (typically one or two core systems), you must
      also do the following:
      3) Disable write-streaming in each CPU by setting ACTLR[28:25] = 0b1111
      So, we provide an option to disable write streaming on OMAP5 and DRA7.
      It is a rare condition to occur and may be enabled selectively based
      on platform acceptance of risk.
      Applies to: A15 revisions r2p0, r2p1, r2p2, r2p3 or r2p4 and REVIDR[3]
      is set to 0.
      Note: certain unicore SoCs *might* not have REVIDR[3] not set, but
      might not meet the condition for the erratum to occur when they donot
      have ACP (Accelerator Coherency Port) hooked to ACE (AXI Coherency
      Extensions). Such SoCs will need the work around handled in the SoC
      specific manner, since there is no ARM generic manner to detect such
      Based on ARM errata Document revision 18.0 (22 Nov 2013)
      Suggested-by: default avatarRichard Woodruff <r-woodruff2@ti.com>
      Suggested-by: default avatarBrad Griffis <bgriffis@ti.com>
      Reviewed-by: default avatarBrad Griffis <bgriffis@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
  7. 27 Jul, 2015 1 commit
    • Paul Kocialkowski's avatar
      Reproducible U-Boot build support, using SOURCE_DATE_EPOCH · f3f431a7
      Paul Kocialkowski authored
      In order to achieve reproducible builds in U-Boot, timestamps that are defined
      at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH environment
      variable allows setting a fixed value for those timestamps.
      Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets can be
      built reproducibly. This is the case for e.g. sunxi devices.
      However, some other devices might need some more tweaks, especially regarding
      the image generation tools.
      Signed-off-by: default avatarPaul Kocialkowski <contact@paulk.fr>
  8. 22 Jul, 2015 3 commits
  9. 20 Jul, 2015 1 commit
  10. 01 Jul, 2015 4 commits
  11. 29 Jun, 2015 1 commit
    • Daniel Schwierzeck's avatar
      mtd, spi: Add MTD layer driver · 9fe6d871
      Daniel Schwierzeck authored
      Add MTD layer driver for spi, original patch from:
      Changes from Heiko Schocher against this patch:
      - Remove compile error if not defining CONFIG_SPI_FLASH_MTD:
        LD      drivers/mtd/spi/built-in.o
      drivers/mtd/spi/sf_probe.o: In function `spi_flash_mtd_unregister':
      /home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: multiple definition of `spi_flash_mtd_unregister'
      drivers/mtd/spi/sf_params.o:/home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: first defined here
      drivers/mtd/spi/sf_ops.o: In function `spi_flash_mtd_unregister':
      /home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: multiple definition of `spi_flash_mtd_unregister'
      drivers/mtd/spi/sf_params.o:/home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: first defined here
      make[1]: *** [drivers/mtd/spi/built-in.o] Fehler 1
      make: *** [drivers/mtd/spi] Fehler 2
      - Add a README entry.
      - Add correct writebufsize, to fit with Linux v3.14
        MTD, UBI/UBIFS sync.
      Note (From Jagan): For testing raw mtd parition erase/read/write operations
      using cmd_sf, sf_mtd should be required to register the spi flash device to
      MTD layer but the sf_mtd_info ops were not required until and unless if we
      use any flash filesystem layer say for example UBI. Due to this the foot-print
      got increased ~290bytes in non-UBI case here that should be acceptible.
      Signed-off-by: default avatarDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
      Signed-off-by: default avatarHeiko Schocher <hs@denx.de>
      Tested-by: default avatarJagannadh Teki <jteki@openedev.com>
      Reviewed-by: default avatarJagannadh Teki <jteki@openedev.com>
  12. 26 Jun, 2015 1 commit
  13. 19 Jun, 2015 1 commit
  14. 08 Jun, 2015 1 commit
  15. 21 May, 2015 1 commit
  16. 19 May, 2015 3 commits
    • Joe Hershberger's avatar
      net: Remove all references to CONFIG_ETHADDR and friends · 92ac5208
      Joe Hershberger authored
      We really don't want boards defining fixed MAC addresses in their config
      so we just remove the option to set it in a fixed way. If you must have
      a MAC address that was not provisioned, then use the random MAC address
      Signed-off-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    • Joe Hershberger's avatar
      net: Implement random ethaddr fallback in eth.c · bef1014b
      Joe Hershberger authored
      Implement the random ethaddr fallback in eth.c so it is in a common
      place and not reimplemented in each board or driver that wants this
      Signed-off-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
    • Hans de Goede's avatar
      console: Fix pre-console flushing via cfb_console being very slow · a8552c7c
      Hans de Goede authored
      On my A10 OlinuxIno Lime I noticed a huge (5+ seconds) delay coming from
      console_init_r. This turns out to be caused by the preconsole buffer flushing
      to the cfb_console. The Lime only has a 16 bit memory bus and that is already
      heavy used to scan out the 1920x1080 framebuffer.
      The problem is that print_pre_console_buffer() was printing the buffer once
      character at a time and the cfb_console code then ends up doing a cache-flush
      for touched display lines for each character.
      This commit fixes this by first building a 0 terminated buffer and then
      printing it in one puts() call, avoiding unnecessary cache flushes.
      This changes the time for the flush from 5+ seconds to not noticable.
      The downside of this approach is that the pre-console buffer needs to fit
      on the stack, this is not that much to ask since we are talking about plain
      text here. This commit also adjusts the sunxi CONFIG_PRE_CON_BUF_SZ to
      actually fit on the stack. Sunxi currently is the only user of the pre-console
      code so no other boards need to be adjusted.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
  17. 08 May, 2015 1 commit
  18. 30 Apr, 2015 1 commit
  19. 23 Apr, 2015 4 commits
  20. 18 Apr, 2015 3 commits
  21. 10 Apr, 2015 1 commit
  22. 31 Mar, 2015 1 commit
  23. 28 Mar, 2015 1 commit
  24. 13 Mar, 2015 5 commits