Skip to content
Snippets Groups Projects
Select Git revision
  • v2020.01-ktn
  • caam_hab_mx8m
  • pmic_pca9450
  • feature_swupdate
  • wip_swupdate_env
  • master default protected
  • v2020.01-rc1
  • v2019.10
  • v2019.10-rc4
  • v2019.10-rc3
  • v2019.10-rc2
  • v2019.10-rc1
  • v2019.07
  • v2019.07-rc4
  • v2019.07-rc3
  • v2019.07-rc2
  • v2019.07-rc1
  • v2019.04
  • v2019.04-rc4
  • v2019.04-rc3
  • v2019.04-rc2
  • v2019.04-rc1
  • v2019.01
  • v2019.01-rc3
  • v2019.01-rc2
  • v2019.01-rc1
26 results
Search by author
  • Any Author
  • Florian Mayer Florian Mayer fmayer
1 author
  1. Aug 13, 2015
    • 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
  3. Jul 27, 2015
    • 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
  5. Jul 22, 2015
  7. Jul 20, 2015
  9. Jul 01, 2015
  11. Jun 29, 2015
    • Daniel Schwierzeck's avatar
      mtd, spi: Add MTD layer driver · 9fe6d871
      Daniel Schwierzeck authored 
      Add MTD layer driver for spi, original patch from:
http://git.denx.de/?p=u-boot/u-boot-mips.git;a=commitdiff;h=bb246819cdc90493dd7089eaa51b9e639765cced



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>
      9fe6d871
  13. Jun 26, 2015
  15. Jun 19, 2015
  17. Jun 08, 2015
  19. May 21, 2015
  21. May 19, 2015
    • 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
functionality.

Signed-off-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      92ac5208
    • 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
behavior.

Signed-off-by: default avatarJoe Hershberger <joe.hershberger@ni.com>
Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      bef1014b
    • 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>
      a8552c7c
  23. May 08, 2015
  25. Apr 30, 2015
  27. Apr 23, 2015
  29. Apr 18, 2015
  31. Apr 10, 2015
  33. Mar 31, 2015
  35. Mar 28, 2015
  37. Mar 13, 2015
  39. Mar 06, 2015
  41. Mar 04, 2015
    • Simon Glass's avatar
      arm: spl: Allow board_init_r() to run with a larger stack · db910353
      Simon Glass authored 
      
At present SPL uses a single stack, either CONFIG_SPL_STACK or
CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
environment) require a lot of stack, some boards set CONFIG_SPL_STACK to
point into SDRAM. They then set up SDRAM very early, before board_init_f(),
so that the larger stack can be used.

This is an abuse of lowlevel_init(). That function should only be used for
essential start-up code which cannot be delayed. An example of a valid use is
when only part of the SPL code is visible/executable, and the SoC must be set
up so that board_init_f() can be reached. It should not be used for SDRAM
init, console init, etc.

Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new
address before board_init_r() is called in SPL.

The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the README.

Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
For version 1:
Acked-by: default avatarAlbert ARIBAUD <albert.u.boot@aribaud.net>
Reviewed-by: default avatarStefan Roese <sr@denx.de>
Tested-by: default avatarBo Shen <voice.shen@atmel.com>
Acked-by: default avatarBo Shen <voice.shen@atmel.com>
Acked-by: default avatarHeiko Schocher <hs@denx.de>
Tested-by: default avatarHeiko Schocher <hs@denx.de>

Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      db910353
    • Stephen Warren's avatar
      ARM: tegra: support running in non-secure mode · 73c38934
      Stephen Warren authored 
      
When the CPU is in non-secure (NS) mode (when running U-Boot under a
secure monitor), certain actions cannot be taken, since they would need
to write to secure-only registers. One example is configuring the ARM
architectural timer's CNTFRQ register.

We could support this in one of two ways:
1) Compile twice, once for secure mode (in which case anything goes) and
   once for non-secure mode (in which case certain actions are disabled).
   This complicates things, since everyone needs to keep track of
   different U-Boot binaries for different situations.
2) Detect NS mode at run-time, and optionally skip any impossible actions.
   This has the advantage of a single U-Boot binary working in all cases.

(2) is not possible on ARM in general, since there's no architectural way
to detect secure-vs-non-secure. However, there is a Tegra-specific way to
detect this.

This patches uses that feature to detect secure vs. NS mode on Tegra, and
uses that to:

* Skip the ARM arch timer initialization.

* Set/clear an environment variable so that boot scripts can take
  different action depending on which mode the CPU is in. This might be
  something like:
  if CPU is secure:
    load secure monitor code into RAM.
    boot secure monitor.
    secure monitor will restart (a new copy of) U-Boot in NS mode.
  else:
    execute normal boot process

Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
Signed-off-by: default avatarTom Warren <twarren@nvidia.com>
      73c38934
  43. Feb 25, 2015
  45. Feb 24, 2015