08 Jun, 2015

1 commit

  • These defines for a 2nd autoboot stop and delay string are nearly unused. Only
    sc3 defines CONFIG_AUTOBOOT_DELAY_STR2. And a patch to remove this most likely
    unmaintained board is also posted to the list.

    By removing these defines the code will become cleaner and moving the remaining
    compile options to Kconfig will get easier.

    Signed-off-by: Stefan Roese
    Reviewed-by: Tom Rini
    Reviewed-by: Simon Glass
    Cc: Wolfgang Denk
    Cc: Heiko Schocher

    Stefan Roese
     

21 May, 2015

2 commits


20 May, 2015

3 commits

  • 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: Joe Hershberger
    Reviewed-by: Simon Glass

    Joe Hershberger
     
  • 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: Joe Hershberger
    Reviewed-by: Simon Glass

    Joe Hershberger
     
  • 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: Hans de Goede
    Reviewed-by: Tom Rini

    Hans de Goede
     

09 May, 2015

1 commit


30 Apr, 2015

1 commit


28 Apr, 2015

1 commit


23 Apr, 2015

4 commits


20 Apr, 2015

1 commit


19 Apr, 2015

2 commits


18 Apr, 2015

1 commit

  • Sometimes, for example if the display is mounted in portrait mode or even if it
    is mounted landscape but rotated by 180 degrees, we need to rotate our content
    of the display respectively the framebuffer, so that user can read the messages
    which are printed out.

    For this we introduce the feature called "CONFIG_LCD_ROTATION", this may be
    defined in the board-configuration if needed. After this the lcd_console will
    be initialized with a given rotation from "vl_rot" out of "vidinfo_t" which is
    provided by the board specific code.

    If CONFIG_LCD_ROTATION is not defined, the console will be initialized with
    0 degrees rotation.

    Signed-off-by: Hannes Petermaier
    Signed-off-by: Hannes Petermaier
    Acked-by: Nikita Kiryanov
    [agust: fixed 'struct vidinfo' has no member named 'vl_rot' errors]
    Signed-off-by: Anatolij Gustschin

    Hannes Petermaier
     

10 Apr, 2015

1 commit


31 Mar, 2015

1 commit


28 Mar, 2015

1 commit


13 Mar, 2015

5 commits

  • The Driver Model description in README was removed by commit
    65eb659e56fa (README: remove description about driver model
    configuration options), and was revived by mistake by commit
    b79dadf846e5 when resolving the conflict.

    Signed-off-by: Masahiro Yamada
    Cc: Tom Rini
    Acked-by: Simon Glass

    Masahiro Yamada
     
  • 621766: Under a specific set of conditions, executing a sequence of
    NEON or vfp load instructions can cause processor deadlock
    Impacts: Every Cortex-A8 processors with revision lower than r2p1
    Work around: Set L1NEON to 1

    Based on ARM errata Document revision 20.0 (13 Nov 2010)

    Signed-off-by: Nishanth Menon
    Tested-by: Matt Porter
    Reviewed-by: Tom Rini

    Nishanth Menon
     
  • 430973: Stale prediction on replaced inter working branch causes
    Cortex-A8 to execute in the wrong ARM/Thumb state
    Impacts: Every Cortex-A8 processors with revision lower than r2p1
    Work around: Set IBE to 1

    Based on ARM errata Document revision 20.0 (13 Nov 2010)

    Signed-off-by: Nishanth Menon
    Tested-by: Matt Porter
    Reviewed-by: Tom Rini

    Nishanth Menon
     
  • 454179: Stale prediction may inhibit target address misprediction on
    next predicted taken branch
    Impacts: Every Cortex-A8 processors with revision lower than r2p1
    Work around: Set IBE and disable branch size mispredict to 1

    Also provide a hook for SoC specific handling to take place if needed.

    Based on ARM errata Document revision 20.0 (13 Nov 2010)

    Signed-off-by: Nishanth Menon
    Tested-by: Matt Porter
    Reviewed-by: Tom Rini

    Nishanth Menon
     
  • Add workaround for Cortex-A15 ARM erratum 798870 which says
    "If back-to-back speculative cache line fills (fill A and fill B) are
    issued from the L1 data cache of a CPU to the L2 cache, the second
    request (fill B) is then cancelled, and the second request would have
    detected a hazard against a recent write or eviction (write B) to the
    same cache line as fill B then the L2 logic might deadlock."

    Implementations for SoC families such as Exynos, OMAP5/DRA7 etc
    will be widely different.

    Every SoC has slightly different manner of setting up access to L2ACLR
    and similar registers since the Secure Monitor handling of Secure
    Monitor Call(smc) is diverse. Hence an weak function is introduced
    which may be overriden to implement SoC specific accessor implementation.

    Based on ARM errata Document revision 18.0 (22 Nov 2013)

    Signed-off-by: Nishanth Menon
    Tested-by: Matt Porter
    Reviewed-by: Tom Rini

    Nishanth Menon
     

11 Mar, 2015

1 commit


06 Mar, 2015

1 commit


05 Mar, 2015

3 commits

  • Tom Rini
     
  • 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: Simon Glass
    For version 1:
    Acked-by: Albert ARIBAUD
    Reviewed-by: Stefan Roese
    Tested-by: Bo Shen
    Acked-by: Bo Shen
    Acked-by: Heiko Schocher
    Tested-by: Heiko Schocher

    Signed-off-by: Tom Rini

    Simon Glass
     
  • 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: Stephen Warren
    Signed-off-by: Tom Warren

    Stephen Warren
     

02 Mar, 2015

1 commit


26 Feb, 2015

1 commit


25 Feb, 2015

1 commit


17 Feb, 2015

1 commit

  • A SoC like the i.MX6 supports more then one i2c bus. In oder to be
    able to use the eeprom command add a new define to specify the
    i2c bus to use. If CONFIG_SYS_I2C_EEPROM_BUS is not defined there
    is no functional change, else a call to i2c_set_bus_num(..) is
    done before calling i2c_read(..) and i2c_write(..).

    Signed-off-by: Christian Gmeiner
    Acked-by: Stefano Babic

    Christian Gmeiner
     

08 Feb, 2015

1 commit


30 Jan, 2015

3 commits


16 Jan, 2015

1 commit


06 Jan, 2015

1 commit