Commit e29878f introduces an undesired dependency on CONFIG_SPL_LOAD_FIT
when building U-Boot for AM43xx high-security (HS) devices that causes the
build to break when that option is not active. Fix this issue by only
building the u-boot_HS.img target when building U-Boot into an actual
FIT image.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Modify the SPL build procedure for AM437x high-security (HS) device
variants to create a secure u-boot_HS.img FIT blob that contains U-Boot
and DTB artifacts signed (and optionally encrypted) with a TI-specific
process based on the CONFIG_TI_SECURE_DEVICE config option and the
externally-provided image signing tool.
Also populate the corresponding FIT image post processing call to be
performed during SPL runtime.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Enable Spread Spectrum for the MPU by calculating the required
values and setting the registers accordingly.
Signed-off-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
CONFIG_USB_XHCI_OMAP is enabled for host mode independent of CONFIG_USB_DWC3
which is meant for gadget mode only. We need enable/disbale_usb_clocks() for
host mode as well so provide for it.
Fixes: 09cc14f4bc ("ARM: AM43xx: Add functions to enable and disable USB clocks"
Signed-off-by: Roger Quadros <rogerq@ti.com>
The CDCE913 and CDCEL913 devices are modular PLL-based, low cost,
high performance , programmable clock synthesizers. They generate
upto 3 output clocks from a single input frequency. Each output can
be programmed for any clock-frequency.
Adding support for the same.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Modifies the config.mk to build secure images when building
the SPL for secure devices.
Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes. The same u-boot
binary file is processed slightly differently to produce a
different boot image, depending on whether the user wants to
boot off SPI, QSPI or other boot media.
Refer to README.ti-secure for more information.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adding support for AM43xx secure devices require the addition
of some SOC specific config options like the amount of memory
used by public ROM and the address of the entry point of u-boot
or SPL, as seen by the ROM code, for the image to be built
correctly.
This mandates the addition of am AM43xx CONFIG option and the
ARM Kconfig file has been modified to source this SOC Kconfig
file. Moving the TARGET_AM43XX_EVM config option to the SOC
KConfig and out of the arch/arm/Kconfig.
Updating defconfigs to add the CONFIG_AM43XX=y statement and
removing the #define CONFIG_AM43XX from the header file.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adds a new Kconfig file for AM33xx class devices. We
need a common place to define CONFIG parameters
for these SOCs, especially for adding support
for secure devices.
a) Adds a definition for ISW_ENTRY_ADDR. This is the
address to which the ROM branches when the SOC
ROM hands off execution to the boot loader.
CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
to this value for AM43xx devices.
b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
calculate CONFIG_SPL_MAX_SIZE. This value indicates the
amount of memory needed by the ROM to store data during
the boot process.
Currently, these CONFIG options are used only by AM43xx,
but in future other AM33xx class SOCs will also use them.
Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The current delays in the DDR initialization routines for am33xx
architectures are sometimes not running long enough leading to DDR
init errors. On am437x, this shows up as an L3 NOC error after the
kernel boots. This is due to the timer not being initialized
properly, but instead still containing the timer init values from
the boot ROM which cause timers to expire in 1/4th the time
required.
timer_init is typically not called until board_init_r, however on
am33xx/am43xx udelay is required in sdram_init which is called
from board_init_f, so a call to timer_init is required earlier.
Note that this issue introduced in v2015.01 by:
b352dde "am33xx: Drop timer_init call from s_init".
Although this could instead fixed by reverting said commit, it
would cause timer_init to be called twice in both SPL and non-SPL
cases. This gives a little more fine grained control and also
matches what is being done on omap-command and fsl-layerscape.
Signed-off-by: Russ Dill <russ.dill@ti.com>
A few boards still use ns16550_platdata structures, but assume the structure
is going to be in a specific order. By explicitly naming each entry,
this should also help 'future-proof' in the event the structure changes.
Tested on the Logic PD Torpedo + Wireless.
I only changed a handful of devices that used the same syntax as the Logic
board. Appologies if I missed one or stepped on toes. Thanks to Derald Woods
and Alexander Graf.
Signed-off-by: Adam Ford <aford173@gmail.com>
V6: Add fix to arch/arm/cpu/armv7/am33xx/board.c
V5: Add fix to arch/arm/cpu/arm926ejs/lpc32xx/devices.c
V4: Fix subject heading
V3: Remove reg_offset out in all the structs. It was reverted out, and and if
it did exist, it would get initialized to 0 by default.
V2: I hastily copy-pasted the boards without looking at the UART number.
This addresses 3 boards that use UART3 and not UART1.
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
On these platforms we have many cases of boards that enable device model
and GPIO support but do not enable OF_CONTROL and pass in a device tree
with the binary. We need to bring in the platform data here as well.
Tested on Beaglebone Black.
Reported-by: Robert Nelson <robertcnelson@gmail.com>
Reported-by: Francisco Aguerre <franciscoaguerre@gmail.com>
Reported-by: Jason Kridner <jkridner@beagleboard.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
This patch fixes the DDR3 initialization procedure in
order to comply with DDR3 standard. A 500 us delay is specified
between the DDR3 reset and clock enable signal. Until now,
this delay was not respected. Some DDR3 chips don't bother
but the bigger the RAM becomes the more likely it seems that
this delay is needed. We observed that DRAM > 256 MB from
the manufacturer Samsung have an issue when the specification
is not respected.
Changes:
1) Add a 1 ms wait for L3 timeout error trigger
2) Don't delay DDR3 initialization
Bit 31 of emif_sdram_ref_ctrl shouldn't be set because his
suppresses the initialization of DDR3
Signed-off-by: Samuel Egli <samuel.egli@siemens.com>
Reviewed-by: James Doublesin <doublesin@ti.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Roger Meier <r.meier@siemens.com>
Cc: Heiko Schocher <hs@denx.de>
We now want to make sure that we have the platform data for NS16550 when
we do not have OF_CONTROL set.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
serial_init() reads global_data, since global_data is not yet
initialized, this can cause unwanted behaviour leading to QSPI XIP boot
hang. Also, since serial_init() is anyways called later from
boar_init_f(), it does not make sense to do the same in s_init().
Tested on AM437x IDK EVM with QSPI XIP boot.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we have separate function to enable USB clocks, remove
enabling USB clocks from enable_basic_clocks(). Now board_usb_init()
should take care to invoke enable_usb_clocks() for enabling
USB clocks.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Added functions to enable and disable USB clocks which can be invoked
during USB init and USB exit respectively.
Cc: Roger Quadros <rogerq@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Adds functions to enable and disable edma3 clocks which can be invoked
by drivers using edma3 to control the clocks.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Add do_disable_clocks() to disable clock domains and module clocks.
These clocks are enabled using do_enable_clocks().
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
The "method" parameter was part of the original port of the driver from
the kernel. At some point this may have been added to allow for future
differentiation (as omap1 and omap2 have different GPIO IP blocks, so
this wasn't an unreasonable thing to do). At this point however it's
just extra overhead, so drop.
Signed-off-by: Tom Rini <trini@konsulko.com>
- Re-sync DT files for am33xx with Linux Kernel v4.1
- Include DT file now for the "AM335x GP EVM" and build target for it,
via device tree and DM.
- We only need to provide platform data for UART when OF_CONTROL isn't
also enabled really. We can just push GPIO to coming from DT
Signed-off-by: Tom Rini <trini@konsulko.com>
Add spi clock to the list of am43xx basic clocks to make the SPI
subsystem available on am43xx systems.
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Reviewed-by: Jagan Teki <jteki@openedev.com>
USB-related options are usually prefixed with CONFIG_USB and platform-specific
adaptation for the MUSB controller already have a CONFIG_USB_MUSB prefix, so
this switches all MUSB-related options to a CONFIG_USB_MUSB prefix, for
consistency.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
All am33xx device tree are using device-tree, so get_board_rev is never actually
called. Thus, we can get rid of it to make the code easier to maintain.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
The recent changes for hw leveling on am33xx were not intended for
DDR2 boards, only DDR3. Update emif_sdram_type to take a sdram_config
value to check against. This lets us pass in the value we would use to
configure, when we have not yet configured the board yet. In other cases
update the call to be as functional as before and check an already
programmed value in.
Tested-by: Yan Liu <yan-liu@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Enabled clocks for dwc3 controller and USB PHY present in AM43xx.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Back in fc46bae a "clean up" was introduced that intended to reconcile
some of the AM335x codepaths based on how AM43xx operates.
Unfortunately this introduced a regression on the DDR2 platforms. This
was un-noticed on DDR3 (everything except for Beaglebone White) as we
had already populated sdram_config correctly in sequence. This change
brings us back to the older behavior and is fine on all platforms.
Tested on Beaglebone White, Beaglebone Black and AM335x GP EVM
Reported-by: Matt Ranostay <mranostay@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <sjg@chromium.org>
Tested on Beagleboard, Beagleboard xM
Tested-by: Matt Porter <mporter@konsulko.com>
Tested on Beaglebone Black, AM43xx GP EVM, OMAP5 uEVM, OMAP4 Pandaboard
Tested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When EMAC is in the boot order, the boot ROM sets OPP50 and the
MAC clock is set to /2. SPL needs to change it to /5 for Ethernet
to generate the correct txclk. This patch sets it correctly.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Prior to this change we set the gd pointer early so that we can store
data in it. This becomes problematic for DM changes as well as being
odd in general. Re-work the code paths so that we don't need to set the
gd pointer so early and instead can rely upon the normal setting of it.
In order to do this we do need to move certain calls from s_init into
spl_board_init(), mainly preloader_console_init and
save_omap_boot_params.
Tested on: Beaglebone Black, AM43xx GP EVM, Beagleboard, Beagleboard xM,
OMAP5 uEVM, DRA7xx EVM
Signed-off-by: Tom Rini <trini@ti.com>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Switch to using hardware leveling for certain parameters on the EMIF
rather than using precalculated values. Doing this also means we have a
common place now between am437x and am335x for setting
emif_sdram_ref_ctrl with a value for the correct delay length.
Tested-by: Felipe Balbi <balbi@ti.com>
Tested-by: Tom Rini <trini@ti.com>
Signed-off-by: James Doublesin <doublesin@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In both SPL and non-SPL cases we will make a call to timer_init() early
on and do not need to call it again within s_init().
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Current get_board_rev() function returns a hard coded value which is
obviously incorrect for the majority of boards.
Allow boards to provide a correct implementation by making this
function weak.
In addition open code the trivial and useless BOARD_REV_ID define and
adjust the comment.
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Cc: Tom Rini <trini@ti.com>
Provide suitable platform data for am33xx boards, so that these boards can
use driver model for serial.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
Provide suitable platform data for am33xx boards, so that these boards can
use driver model for GPIO access.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
Commit 41623c9 'arm: move exception handling out of start.S files' missed some
linker scripts. Hence, some boards no longer had exception handling linked since
this commit. Restore the original behavior by adding the .vectors section to
these linker scripts.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
The code intends for the CM_DLL_READYST to be set, but
actually polls till any bit is set since the logical
AND is used instead of the bitwise one is used. Fix it.
cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Enable the cache for all devices, unless CONFIG_SYS_DCACHE_OFF is defined.
This speeds up the Beaglebone Black boot considerable.
(Tested only on Beaglebone Black with SD card boot)
Signed-off-by: Simon Glass <sjg@chromium.org>
Similar to OMAP4/5 we need to scale the voltage up prior to changing the
clock frequencies up higher. Add a similar hook to start with.
Signed-off-by: Tom Rini <trini@ti.com>
After enabling a module, SW has to wait on IDLEST bit
until it is Fully functional. This wait is missing for UART module
and there is a immediate access of UART registers after this. So there
is a chance of hang on this module( This can happen when we are running
from MPU SRAM). So waiting for IDLEST bit.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
With the changes to the i2c framework (and adopting the omap24xx_i2c
driver to them) we can no longer call i2c functions prior to gd having
been set and cleared. When SPL booting, this is handled by setting gd
to point to SRAM in s_init. However in the cases where we are loaded
directly by ROM (memory mapped NOR or QSPI) we need to make use of the
normal hooks to slightly delay these calls.
Signed-off-by: Tom Rini <trini@ti.com>
We have two contexts for booting these platforms. One is SPL which is
roughly: reset, cpu_init_crit, lowlevel_init, s_init, sdram_init, _main,
board_init_f from SPL, ... then U-Boot loads. The other is a
memory-mapped XIP case (NOR or QSPI) where we do not run an SPL. In
this case we go, roughly: reset, cpu_init_crit, lowlevel_init, s_init,
_main, regular board_init_f.
In the first case s_init will set a valid gd and then be able to call
sdram_init which in many cases will need i2c (which needs a valid gd for
gd->cur_i2c_bus). In this second case we must (and are able to and
should) defer sdram_init() into dram_init() called by board_init_f as gd
will have been set in _main and cleared in board_init_f.
Signed-off-by: Tom Rini <trini@ti.com>
The ePOS EVM and EVM SK have QSPI as an option to boot. Add a qspiboot
target that utilizes QSPI for env and so forth as an example of best
practices. As QSPI is booted from directly we need to chang
CONFIG_SYS_TEXT_BASE.
Note that on ePOS EVM the QSPI and NAND are mutually exclusive choices
we need to handle that elsewhere, once NAND support is also added.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
As revision code 1 is for silicon revision 2.0, it is easily confused with
silicon revision 1.0.
Device type report also reworked in same style.
Signed-off-by: Sergey Alyoshin <alyoshin.s@gmail.com>
GPMC controller on TI's OMAP SoC is general purpose controller to interface
with different types of external devices like;
- parallel NOR flash
- parallel NAND flash
- OneNand flash
- SDR RAM
- Ethernet Devices like LAN9220
Though GPMC configurations may be different for each platform depending on
clock-frequency and external device interfacing with controller. But
initialization sequence remains common across all platfoms.
Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c
files into single omap-common/mem-common.c
However, actual platforms specific register config values are still sourced
from corresponding platform specific headers like;
AM33xx: arch/arm/include/asm/arch-am33xx/mem.h
OMAP3: arch/arm/include/asm/arch-omap3/mem.h
OMAP4: arch/arm/include/asm/arch-omap4/mem.h
OMAP4: arch/arm/include/asm/arch-omap5/mem.h
Also, CONFIG_xx passed by board-profile decide config for which set of macros
need to be used for initialization
CONFIG_NAND: initialize GPMC for NAND device
CONFIG_NOR: initialize GPMC for NOR device
CONFIG_ONENAND: initialize GPMC for ONENAND device
Signed-off-by: Pekon Gupta <pekon@ti.com>
[trini: define GPMC_SIZE_256M for omap3]
Signed-off-by: Tom Rini <trini@ti.com>
In the case of SPL or NOR_BOOT (no SPL involved) we need to include
certain code in the build. Use !CONFIG_SKIP_LOWLEVEL_INIT rather than
CONFIG_SPL_BUILD || CONFIG_NOR_BOOT to make the code clearer, and to
make supporting XIP QSPI boot clearer in the code.
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Wolfgang Denk <wd@denx.de>
The s_init function is only called on SPL or XIP cases, so lets only
build it for them. This makes the #if logic within the function a bit
clearer as to when we are or are not calling things, and makes it easier
to see that for example preloader_console_init isn't ever called in the
non-XIP full U-Boot case.
Signed-off-by: Tom Rini <trini@ti.com>
The bit DDR3_RST_DEF_VAL inside CTRL_DDR_IO represents the default value
of the ddr reset value for DDR3 before the EMIF takes over. We must have
this bit set high so that on exit from DeepSleep0 within the kernel the
reset line has the proper value.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
