| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
| |
This has not been converted to Generic Board, so should be removed.
(See doc/README.generic-board for details.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Larry Johnson <lrj@acm.org>
|
|
|
|
|
|
|
|
| |
This has not been converted to Generic Board, so should be removed.
(See doc/README.generic-board for details.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Eric Millbrandt <emillbrandt@dekaresearch.com>
|
|
|
|
|
|
|
|
| |
They have not been converted to Generic Board, so should be removed.
(See doc/README.generic-board for details.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Erik Theisen <etheisen@mindspring.com>
|
|
|
|
|
|
|
| |
They have not been converted to Generic Board, so should be removed.
(See doc/README.generic-board for details.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
|
|
|
|
|
|
| |
This has not been converted to Generic Board, so should be removed.
(See doc/README.generic-board for details.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Stephen Williams <steve@icarus.com>
|
|
|
|
|
|
|
| |
This has not been converted to Generic Board, so should be removed.
(See doc/README.generic-board for details.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
|
|
|
|
|
| |
We don't want that CONSOLE is redirected to LCD upon init, we rather prefer
that console is still on the serial line.
Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
|
|
|
|
|
|
|
|
|
|
| |
Commit f022d36e8a4517b2a9d25ff2d75bd2459d0c68b1 introduces
error register offset.
Change the "char reserved3[59]" to "char reserved3[56]".
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The build break was caused by one of my previous commit:
'odroid: defconfig: disable memset at malloc init'
It removes the dts from odroid defconfig - rebase mistake.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Minkyu Kang <mk7.kang@samsung.com>
|
|
|
|
|
| |
Signed-off-by: Hannes Petermaier <hannes.petermaier@br-automation.com>
Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Panasonic's System LSI products, UniPhier SoC family, have been
transferred to Socionext Inc.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
| |
| |
| |
| |
| |
| | |
I have transferred to Socionext Inc.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
| |
| |
| |
| |
| |
| | |
I have transferred to Socionext Inc.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit e02ee2548afe (kconfig: switch to single .config
configuration), the prefixes in defconfig files such as "+S:",
"+ST:", etc., are meaningless.
This commit was generated by the following command:
find configs -name '*_defconfig' | xargs sed -i 's/^+*S*T*://'
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the case of BUILD_NBUILDS > 1, MAKEALL would try to print the size
immediately after the u-boot binary is deleted by the call to:
make -s clean
Move the size print to before the clean
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <yamada.masahiro@socionext.com>
Cc: Tom Rini <trini@konsulko.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This should make it more clear why there appear to be C pre-processor
symbols in the file that contain mixed case. They're really error
messages.
Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When Beagle X15 is connected to Gigabit switch, it takes
more time to finish auto-negotiation than on a 10/100 switch.
The default 4 second limit times-out more often than not. This is
observed when testing with a D-Link DGS-1008A desktop switch.
Increase the auto-negotiation time-out for Beagle-X15 to handle
this case.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <vchengalvala@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <prao@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is in preperation of using generic cross OMAP code.
Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <nm@ti.com>
Tested-by: Matt Porter <mporter@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|/
|
|
|
|
|
|
| |
The purpose of this build target is to do SPL over USB RNDIS. We remove
YMODEM, MMC and NAND (and re-set ENV to be built-in) as when those are needed
we can use the other build targets. This brings us well under size limit again.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
README
Signed-off-by: Tom Rini <trini@konsulko.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to work with our downstream U-Boot environment and update
scripts add support for the following miscellaneous commands:
CONFIG_CMD_SETEXPR
CONFIG_FAT_WRITE
Increase the console I/O and print as well as argument buffer sizes:
CONFIG_SYS_CBSIZE
CONFIG_SYS_PBSIZE
CONFIG_SYS_BARGSIZE
Increase the maximum number of arguments allowed:
CONFIG_SYS_MAXARGS
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now with all the Tegra PCIe and Intel E1000 gigabit Ethernet driver
updates being merged actually make use of it.
While at it get rid of the USB networking support which now does not
make much sense any longer.
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the MMC/SD card detect GPIOs for Apalis T30 which got broken
by the following commit:
2b2b50bc8748 "dm: tegra: dts: Use TEGRA_GPIO() macro for all GPIOs"
While at it also re-add the comments describing which particular
Apalis/Colibri pins those GPIOs are on.
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All boards with a SPI interface have a suitable spi alias except Apalis
T30. Add these missing aliases just as the following commit did for the
others:
d2f60f93325a "dm: tegra: dts: Add aliases for spi on tegra30 boards"
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| | |
This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Tegra210 has a per-pin option named e_io_hv, which indicates that the
pin's input path should be configured to be 3.3v-tolerant. Add support
for this.
Note that this is very similar to previous chip's rcv_sel option.
However, since the Tegra TRM names this option differently for the
different chips, we support the new name so that the code exactly matches
the naming in the TRM, to avoid confusion.
This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Tegra210 starts its drive group registers at a different offset from the
APB MISC register block that other SoCs. Update the code to handle this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
T210 support HSM and Schmitt options in the pinmux register (previous
chips placed these options in the drive group register). Update the
code to handle this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Tegra210 moves some bits around in the pinmux registers. Update the code
to handle this.
This doesn't attempt to address the issues with the group-to-group varying
drive group register layout mentioned earlier. This patch handles the
SoC-to-SoC differences in the mux register layout.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On some future SoCs, some per-drive-group features became per-pin
features. Move all type definitions early in the header so they can
be enabled irrespective of the setting of TEGRA_PMX_SOC_HAS_DRVGRPS.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
On some future SoCs, some of the per-drive-group features no longer
exist. Add some ifdefs to support this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Future SoCs have a slightly different combination of pinmux options per
pin. This will be simpler to handle if we simply have one define per
option, rather than grouping various options together, in combinations
that don't align with future chips.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Tegra's drive group registers have a remarkably inconsistent layout. The
current U-Boot driver doesn't take this into account at all. Add a
comment to describe the issue, so at least anyone debugging the driver
will be aware of this. To solve this, we'd need to add a per-drive-group
data structure describing the layout for the individual register. Since
we don't set up too many drive groups in U-Boot at present, this
hopefully isn't causing too much practical issue. Still, we probably need
to fix this sometime.
Wth Tegra210, the register layout becomes almost entirely consistent, so
this problem partially solves itself over time.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Syseng has revamped the Jetson TK1 pinmux spreadsheet, basing the content
completely on correct configuration for the board/schematic, rather than
the previous version which was based on the bare minimum changes relative
to another reference board.
The new spreadsheet sets TRISTATE for any input-only pins. This only works
correctly if the global CLAMP bit is not set, so the Jetson TK1 board code
has been adjusted accordingly. Apparently syseng have changed their mind
since the previous advice that this needed to be set:-/
This content comes from Jetson_TK1_customer_pinmux.xlsm (v09) downloaded
from https://developer.nvidia.com/hardware-design-and-development.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is needed to correctly apply the new Jetson TK1 pinmux config.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All boards need CONFIG_BOARD_EARLY_INIT_F, and many actively need
CONFIG_BOARD_LATE_INIT. Move both of these into tegra-common.h so that
board config headers don't need to repeatedly define them.
Later commits will add new code in board_late_init() which applies to
all boards, so CONFIG_BOARD_LATE_INIT should be enabled for all Tegra
boards.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some systems have so much RAM that the end of RAM is beyond 4GB. An
example would be a Tegra124 system (where RAM starts at 2GB physical)
that has more than 2GB of RAM.
In this case, we want gd->ram_size to represent the actual RAM size, so
that the actual RAM size is passed to the OS. This is useful if the OS
implements LPAE, and can actually use the "extra" RAM.
However, we can't use get_ram_size() to verify the actual amount of RAM
present on such systems, since some of the RAM can't be accesses, which
confuses that function. Avoid calling get_ram_size() when the RAM size
is too large for it to work correctly. It's never actually needed anyway,
since there's no reason for the BCT to report the wrong RAM size.
In systems with >=4GB RAM, we still need to clip the reported RAM size
since U-Boot uses a 32-bit variable to represent the RAM size in bytes.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|