1. 27 May, 2016 1 commit
  2. 20 May, 2016 1 commit
    • Nikita Kiryanov's avatar
      cmd: eeprom: add support for layout aware commands · aa9e6044
      Nikita Kiryanov authored
      Introduce the (optional) eeprom print and eeprom update commands.
      
      These commands are eeprom layout aware:
      * The eeprom print command prints the contents of the eeprom in a human
        readable way (eeprom layout fields, and data formatted to be fit for human
        consumption).
      * The eeprom update command allows user to update eeprom fields by specifying
        the field name, and providing the new data in a human readable format (same
        format as displayed by the eeprom print command).
      * Both commands can either auto detect the layout, or be told which layout to
        use.
      
      New CONFIG options:
      CONFIG_CMD_EEPROM_LAYOUT - enables commands.
      CONFIG_EEPROM_LAYOUT_HELP_STRING - tells user what layout names are supported
      
      Feature API:
      __weak int parse_layout_version(char *str)
      	- override to provide your own layout name parsing
      __weak void __eeprom_layout_assign(struct eeprom_layout *layout, int layout_version);
      	- override to setup the layout metadata based on the version
      __weak int eeprom_layout_detect(unsigned char *data)
      	- override to provide your own algorithm for detecting layout version
      eeprom_field.c
      	- contains various printing and updating functions for common types of
      	  eeprom fields. Can be used for defining custom layouts.
      
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Tom Rini <trini@konsulko.com>
      Signed-off-by: default avatarNikita Kiryanov <nikita@compulab.co.il>
      aa9e6044
  3. 17 May, 2016 2 commits
  4. 11 Apr, 2016 1 commit
  5. 01 Apr, 2016 1 commit
  6. 22 Mar, 2016 1 commit
  7. 14 Mar, 2016 1 commit
    • Simon Glass's avatar
      Kconfig: Move CONFIG_FIT and related options to Kconfig · 73223f0e
      Simon Glass authored
      There are already two FIT options in Kconfig but the CONFIG options are
      still in the header files. We need to do a proper move to fix this.
      
      Move these options to Kconfig and tidy up board configuration:
      
         CONFIG_FIT
         CONFIG_OF_BOARD_SETUP
         CONFIG_OF_SYSTEM_SETUP
         CONFIG_FIT_SIGNATURE
         CONFIG_FIT_BEST_MATCH
         CONFIG_FIT_VERBOSE
         CONFIG_OF_STDOUT_VIA_ALIAS
         CONFIG_RSA
      
      Unfortunately the first one is a little complicated. We need to make sure
      this option is not enabled in SPL by this change. Also this option is
      enabled automatically in the host builds by defining CONFIG_FIT in the
      image.h file. To solve this, add a new IMAGE_USE_FIT #define which can
      be used in files that are built on the host but must also build for U-Boot
      and SPL.
      
      Note: Masahiro's moveconfig.py script is amazing.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      [trini: Add microblaze change, various configs/ re-applies]
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      73223f0e
  8. 26 Feb, 2016 1 commit
    • Alexandre Messier's avatar
      net: bootp: Add environment variable for timeout period · 50768f5b
      Alexandre Messier authored
      There is currently one config option (CONFIG_NET_RETRY_COUNT) that
      is available to tune the retries of the network stack.
      Unfortunately, it is global to all protocols, and the value is
      interpreted differently in all of them.
      
      Add a new environment variable that directly sets the retry period for
      BOOTP timeouts. If this new value is not set, the period is still derived
      from the default number of retries, or from CONFIG_NET_RETRY_COUNT if
      defined. When both the new variable is set and CONFIG_NET_RETRY_COUNT
      is defined, the variable has precedence.
      Signed-off-by: default avatarAlexandre Messier <amessier@tycoint.com>
      50768f5b
  9. 08 Feb, 2016 2 commits
  10. 06 Feb, 2016 1 commit
  11. 29 Jan, 2016 2 commits
  12. 25 Jan, 2016 1 commit
  13. 19 Jan, 2016 1 commit
    • Tom Rini's avatar
      vsprintf.c: Always enable CONFIG_SYS_VSNPRINTF · 947c626d
      Tom Rini authored
      Enabling this function always removes some class of string saftey issues.
      The size change here in general is about 400 bytes and this seems a reasonable
      trade-off.
      
      Cc: Peng Fan <peng.fan@nxp.com>
      Cc: Peter Robinson <pbrobinson@gmail.com>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Adrian Alonso <aalonso@freescale.com>
      Cc: Stefano Babic <sbabic@denx.de>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      947c626d
  14. 14 Jan, 2016 1 commit
  15. 08 Jan, 2016 1 commit
  16. 15 Dec, 2015 3 commits
    • York Sun's avatar
      armv8: fsl-layerscale: Rewrite reserving memory for MC and debug server · c0492141
      York Sun authored
      MC and debug server are not board-specific. Move reserving memory to SoC
      file, using the new board_reserve_ram_top function. Reduce debug server
      memory by 2MB to make room for secure memory.
      
      In the system with MC and debug server, the top of u-boot memory
      is not the end of memory. PRAM is not used for this reservation.
      Signed-off-by: default avatarYork Sun <yorksun@freescale.com>
      c0492141
    • York Sun's avatar
      common: Rewrite hiding the end of memory · aabd7ddb
      York Sun authored
      As the name may be confusing, the CONFIG_SYS_MEM_TOP_HIDE reserves
      some memory from the end of ram, tracked by gd->ram_size. It is not
      always the top of u-boot visible memory. Rewrite the macro with a
      weak function to provide flexibility for complex calcuation. Legacy
      use of this macro is still supported.
      Signed-off-by: default avatarYork Sun <yorksun@freescale.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      aabd7ddb
    • York Sun's avatar
      Reserve secure memory · e8149522
      York Sun authored
      Secure memory is at the end of memory, separated and reserved
      from OS, tracked by gd->secure_ram. Secure memory can host
      MMU tables, security monitor, etc. This is different from PRAM
      used to reserve private memory. PRAM offers memory at the top
      of u-boot memory, not necessarily the real end of memory for
      systems with very large DDR. Using the end of memory simplifies
      MMU setup and avoid memory fragmentation.
      
      "bdinfo" command shows gd->secure_ram value if this memory is
      marked as secured.
      Signed-off-by: default avatarYork Sun <yorksun@freescale.com>
      e8149522
  17. 30 Nov, 2015 1 commit
  18. 22 Nov, 2015 1 commit
  19. 20 Nov, 2015 4 commits
  20. 13 Nov, 2015 1 commit
    • Fabio Estevam's avatar
      board_init: Change the logic to setup malloc_base · 9ac4fc82
      Fabio Estevam authored
      Prior to commit 5ba534d2 ("arm: Switch 32-bit ARM to using generic
      global_data setup") we used to have assembly code that configured the
      malloc_base address.
      
      Since this commit we use the board_init_f_mem() function in C to setup
      malloc_base address.
      
      In board_init_f_mem() there was a deliberate choice to support only
      early malloc() or full malloc() in SPL, but not both.
      
      Adapt this logic to allow both to be used, one after the other, in SPL.
      
      This issue has been observed in a Congatec board, where we need to
      retrieve the manufacturing information from the SPI NOR (the SPI API
      calls malloc) prior to configuring the DRAM. In this case as malloc_base
      was not configured we always see malloc to fail.
      
      With this change we are able to use malloc in SPL prior to DRAM gets
      initialized.
      
      Also update the CONFIG_SYS_SPL_MALLOC_START entry in the README file.
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      9ac4fc82
  21. 12 Nov, 2015 1 commit
  22. 28 Oct, 2015 1 commit
    • Albert ARIBAUD \(3ADEV\)'s avatar
      net: TFTP: variables cleanup and addition · f5fb7346
      Albert ARIBAUD \(3ADEV\) authored
      TFTP source and destination port variable names are
      'tftpsrcp' and 'tftpdstp' in the code, but 'tftpsrcport'
      and 'tftpdstport' in the README file. Fix the README.
      
      Add environment variable 'tftptimeoutcountmax'. As per the
      comments about the global variable tftp_timeout_count_max,
      make sure tftptimeoutcountmax is nonnegative.
      
      Introduce configuration option CONFIG_NET_TFTP_VARS,
      which controls whether environment variables tftpblocksize,
      tftptimeout, and tftptimoueoutcountmax are read by the TFTP
      client code. CONFIG_NET_TFTP_VARS defaults to y but can be
      set to n by targets with to tight size contraints.
      
      Make bf527-ezkit set CONFIG_NET_TFTP_VARS to n to keep the
      target size below limit.
      f5fb7346
  23. 26 Oct, 2015 1 commit
  24. 23 Oct, 2015 1 commit
  25. 21 Oct, 2015 1 commit
    • Bin Meng's avatar
      cmd: bootvx: Always get VxWorks bootline from env · 9e98b7e3
      Bin Meng authored
      So far VxWorks bootline can be contructed from various environment
      variables, but when these variables do not exist we get these from
      corresponding config macros. This is not helpful as it requires
      rebuilding U-Boot, and to make sure these config macros take effect
      we should not have these environment variables. This is a little
      bit complex and confusing.
      
      Now we change the logic to always contruct the bootline from
      environments (the only single source), by adding two new variables
      "bootdev" and "othbootargs", and adding some comments about network
      related settings mentioning they are optional. The doc about the
      bootline handling is also updated.
      Signed-off-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      Tested-by: default avatarHannes Schmelzer <oe5hpm@oevsv.at>
      9e98b7e3
  26. 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
      userspace.
      
      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
      segfaults.
      
      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>
      e392b923
  27. 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
      are.
      
      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_SYS_MXC_I2C4_SPEED) and slave (CONFIG_SYS_MXC_I2C4_SLAVE)
      config options.
      Signed-off-by: default avatarAlbert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
      03544c66
  28. 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:
      
      - CONFIG_PL011_SERIAL_RLCR
      - CONFIG_PL011_SERIAL_FLUSH_ON_INIT
      
      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
      code.
      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>
      68282f55
  29. 31 Aug, 2015 1 commit
  30. 21 Aug, 2015 1 commit
  31. 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
      configurations.
      
      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>
      a615d0be
  32. 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>
      f3f431a7