16 Mar, 2015

1 commit


15 Mar, 2015

1 commit


13 Mar, 2015

11 commits

  • RX51 has a secure logic which uses different parameters compared to
    traditional implementation. So, make the generic secure acr write
    over-ride-able by board file and refactor rx51 code to use this.

    While at it, enable the OMAP3 specific errata code for 454179, 430973,
    621766.

    Signed-off-by: Nishanth Menon
    Reviewed-by: Tom Rini

    Nishanth Menon
     
  • Enable the OMAP3 specific errata code for 454179, 430973, 621766
    and while at it, remove legacy non-revision checked errata logic.

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

    Nishanth Menon
     
  • Update to existing recommendation for L2ACTLR configuration to prevent
    system instability and optimize performance.

    These apply to both OMAP5 and DRA7.

    Reported-by: Vivek Chengalvala
    Signed-off-by: Nishanth Menon
    Reviewed-by: Tom Rini

    Nishanth Menon
     
  • This patch enables the workaround for ARM errata 798870 for OMAP5 /
    DRA7 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."

    An l2auxctlr accessor implementation for OMAP5 and DRA7 is introduced
    here as well.

    Signed-off-by: Praveen Rao
    Signed-off-by: Angela Stegmaier
    Signed-off-by: Nishanth Menon
    Tested-by: Matt Porter
    Reviewed-by: Tom Rini

    Praveen Rao
     
  • omap_smc1 is now generic enough to remove duplicate
    omap3_gp_romcode_call logic that omap3 introduced.

    As part of this change, move to using the generic lowlevel_init.S for
    omap3 as well.

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

    Nishanth Menon
     
  • This is in preperation of using generic cross OMAP code.

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

    Nishanth Menon
     
  • set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
    PL310 control register, however, that is something that is generic
    enough to be used for OMAP5 generation of processors as well. The only
    difference being the service being invoked for the function.

    So, convert the service to a macro and use a generic name (same as
    that used in Linux for some consistency). While at that, also add a
    data barrier which is necessary as per recommendation.

    While at this, smc #0 is maintained as handcoded assembly thanks to
    various gcc version eccentricities, discussion thread:
    http://marc.info/?t=142542166800001&r=1&w=2

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

    Nishanth Menon
     
  • 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


09 Mar, 2015

3 commits

  • While the Freescale ARMv8 board LS2085A will enter U-Boot both
    on a master and a secondary (slave) CPU, this is not the common
    behaviour on ARMv8 platforms. The norm is that U-Boot is entered
    from the master CPU only, while the other CPUs are kept in
    WFI (wait for interrupt) state.

    The code determining which CPU we are running on is using the
    MPIDR register, but the definition of that register varies with
    platform to some extent, and handling multi-cluster platforms
    (such as the Juno) will become cumbersome. It is better to only
    enable the multiple entry code on machines that actually need
    it and disable it by default.

    Make the single entry default and add a special
    ARMV8_MULTIENTRY KConfig option to be used by the
    platforms that need multientry and set it for the LS2085A.
    Delete all use of the CPU_RELEASE_ADDR from the Vexpress64
    boards as it is just totally unused and misleading, and
    make it conditional in the generic start.S code.

    This makes the Juno platform start U-Boot properly.

    Signed-off-by: Linus Walleij

    Linus Walleij
     
  • The way the PSCI DT update happens currently means we pull in
    everywhere, including on ARMv8 and that in turn brings in
    for some non-PSCI related things that header needs to deal
    with.

    To fix this, we rework the hook slightly. A good portion of
    arch/arm/cpu/armv7/virt-dt.c is common looking and I hope that when PSCI
    is needed on ARMv8 we can re-use this by and large. So rename the
    current hook to psci_update_dt(), move the prototype to and
    add an #ifdef that will make re-use later easier.

    Reported-by: York Sun
    Cc: Marc Zyngier
    Cc: York Sun
    Cc: Ian Campbell
    Cc: Hans de Goede
    Cc: Albert ARIBAUD
    Signed-off-by: Tom Rini
    Acked-by: York Sun

    Tom Rini
     
  • For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY,
    will highly increase the memset/memcpy performance. This is able
    thanks to the ARM multiple register instructions.

    Unfortunatelly the relocation is done without the cache enabled,
    so it takes some time, but zeroing the BSS memory takes much more
    longer, especially for the configs with big static buffers.

    A quick test confirms, that the boot time improvement after using
    the arch memcpy for relocation has no significant meaning.
    The same test confirms that enable the memset for zeroing BSS,
    reduces the boot time.

    So this patch enables the arch memset for zeroing the BSS after
    the relocation process. For ARM boards, this can be enabled
    in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'.

    This was tested on Trats2.
    A quick test with trace. Boot time from start to main_loop() entry:
    - ~1384ms - before this change
    - ~888ms - after this change

    Signed-off-by: Przemyslaw Marczak
    Reviewed-by: Simon Glass
    Cc: Albert Aribaud
    Cc: Tom Rini

    Przemyslaw Marczak
     

06 Mar, 2015

11 commits


05 Mar, 2015

12 commits

  • According to table 2-3 on page 87 of Marvell's latest PXA270
    Specification Update Rev. I from 2010.04.19 [1] there exists a breed of
    chips with a new CPU ID for PXA270M A1 stepping which our latest
    Colibri PXA270 V2.4A modules actually have assembled. This patch helps
    in correctly identifying those chips upon boot as well which then looks
    as follows:

    CPU: Marvell PXA27xM rev. A1

    [1] http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf

    Acked-by: Marek Vasut

    Marcel Ziswiler
     
  • Tom Rini
     
  • commit d9f43c8f5c1d7ed27c99a06be85a4bb64b2c73fb sets
    get_reset_cause() as static, but this conflicts with mx5
    where its prototype is in sys_proto.h.

    Drop it from sys_proto.h and drop print_cpuinfo from mx53_loco,
    factorizing the call for this board.

    Signed-off-by: Stefano Babic
    CC: Jason Liu

    Stefano Babic
     
  • Import DTS for Arria V development kit and enable support
    for DT. The DT is imported from Linux 3.19-rc1 as of commit
    97bf6af1f928216fd6c5a66e8a57bfa95a659672 .

    Signed-off-by: Marek Vasut
    Cc: Chin Liang See
    Cc: Dinh Nguyen
    Acked-by: Pavel Machek
    Reviewed-by: Stefan Roese
    Cc: Vince Bridgers

    Marek Vasut
     
  • Import DTS for Cyclone V development kit and enable support
    for DT. The DT is imported from Linux 3.19-rc1 as of commit
    97bf6af1f928216fd6c5a66e8a57bfa95a659672 .

    Signed-off-by: Marek Vasut
    Cc: Chin Liang See
    Cc: Dinh Nguyen
    Acked-by: Pavel Machek
    Reviewed-by: Stefan Roese
    Cc: Vince Bridgers

    Marek Vasut
     
  • Add support for the Altera Arria V development kit.

    Signed-off-by: Marek Vasut
    Cc: Chin Liang See
    Cc: Dinh Nguyen
    Cc: Pavel Machek
    Cc: Stefan Roese
    Cc: Vince Bridgers

    Marek Vasut
     
  • Currently in some cases SDRAM init requires global_data to be available
    and soon this will not be available prior to board_init_f(). Adjust the
    code paths in these cases to be correct. In some cases we had the SPL
    stack be in DDR as we might have large stacks (due to Falcon Mode +
    Environment). In these cases switch to CONFIG_SPL_STACK_R. In other
    cases we had simply been setting CONFIG_SPL_STACK into SRAM. In these
    cases we no longer need to (CONFIG_SYS_INIT_SP_ADDR is used and is also
    in SRAM) so drop those lines.

    Signed-off-by: Simon Glass
    Tested on Beagleboard, Beagleboard xM
    Tested-by: Matt Porter
    Tested on Beaglebone Black, AM43xx GP EVM, OMAP5 uEVM, OMAP4 Pandaboard
    Tested-by: Tom Rini
    Signed-off-by: Tom Rini
    Reviewed-by: Simon Glass

    Simon Glass
     
  • 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
     
  • Use the full driver model GPIO and serial drivers in SPL now that these are
    supported. Since device tree is not available they will use platform data.

    Remove the special SPL GPIO function as it is no longer needed.

    This is all in one commit to maintain bisectability.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • This is already set up in crt0.S. We don't need a new structure and don't
    really want one in the 'data' section of the image, since it will be empty
    and crt0.S's changes will be ignored.

    As an interim measure, remove it only if CONFIG_DM is not defined. This
    allows us to press ahead with driver model in SPL and allow the stragglers
    to catch up.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • This function has grown into something of a monster. Some boards are setting
    up a console and DRAM here in SPL. This requires global_data which should be
    set up in one place (crt0.S).

    There is no need for SPL to use s_init() for anything since board_init_f()
    is called immediately afterwards.

    Signed-off-by: Simon Glass

    Simon Glass
     
  • Modify CONFIG_USB_MAX_CONTROLLER_COUNT value to 1 on P1022DS.
    As ETSEC2 and USB2 are muxed; thus if ETSEC2 is enabled, the
    system bus hangs on USB2 if ETSEC2 is enabled but "usb start"
    command is issued. Hence making default controller count to 1
    to avoid system hang.

    Signed-off-by: Nikhil Badola
    Reviewed-by: Yusong Sun

    Ying Zhang