We need to call the save_omap_boot_params function on am33xx/ti81xx and
other newer TI SoCs, so move the function to boot-common. Only OMAP4+
has the omap_hw_init_context function so add ifdefs to not call it on
am33xx/ti81xx. Call save_omap_boot_params from s_init on am33xx/ti81xx
boards.
Reviewed-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Prior to Sricharan's cleanup of the boot parameter saving code, we
did not make use of NON_SECURE_SRAM_START on am33xx, so it wasn't a
problem that the address was pointing to the middle of our running SPL.
Correct to point to the base location of the download image area.
Increase CONFIG_SPL_TEXT_BASE to account for this scratch area being
used. As part of correcting these tests, make use of the fact that
we've always been placing our stack outside of the download image area
(which is fine, once the downloaded image is run, ROM is gone) so
correct the max size test to be the ROM defined top of the download area
to where we link/load at.
Signed-off-by: Tom Rini <trini@ti.com>
---
Changes in v2:
- Fix typo noted by Peter Korsgaard
omap_boot_parameters is same and defined for each
soc. So move this to a common place to reuse it
across socs.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
The previous timings were done on the internal-only A1 board which has
different DDR part than all later revs. The timings need a slight
adjustment to be correct in all cases with later revs.
Signed-off-by: Tom Rini <trini@ti.com>
After further testing we can run DDR at 400MHz so update the timings
again.
Tested-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Tom Rini <trini@ti.com>
Given that on TI814x we have MMC1/2 swapped, we also need to swap them
in MMC_BOOT_DEVICES_START/END
Reported-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Tom Rini <trini@ti.com>
In the case of booting from certain peripherals, such as UART, we must
not see what the device descriptor says for RAW or FAT mode because in
addition to being nonsensical, it leads to a hang. This is why we have
a test currently for the boot mode being within range. The problem
however is that on some platforms we get MMC2_2 as the boot mode and not
the defined value for MMC2, and in others we get the value for MMC2_2.
This is required to fix eMMC booting on omap5_uevm.
Tested on am335x_evm (UART, NAND, SD), omap3_beagle (NAND, SD on
classic, SD only on xM rev C5) and omap5_uevm (SD, eMMC).
Signed-off-by: Tom Rini <trini@ti.com>
With uppcoming BCH support on OMAP devices we need to decide between differnt
algorithms when switching the ECC engine. Currently we support 1-bit hammign
and 8-bit BCH on HW backend.
In order to switch between differnet ECC algorithms we need to change the
interface of omap_nand_switch_ecc() also.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Cc: Thomas Weber <thomas.weber.linux@googlemail.com>
arch/arm/include/asm/arch-am33xx/omap_gpmc.h and
arch/arm/include/asm/arch-omap3/omap_gpmc.h are almost the same, consolidate
the common parts into a new header.
Introduce a new asm/omap_gpmc.h which defines the command part and pulls in
the architecture specific one.
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Tom Rini <trini@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
AM33XX and TI814X have a similar mux though the pinmux register
layout and address space differ. Add a separate ti814x mux include
to support the TI814X-specific differences.
Signed-off-by: Matt Porter <mporter@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
The AM33xx emif4/ddr support closely matches what is need to support
TI814x except that TI814x has two EMIF instances. Refactor all the
emif4 helper calls and the config_ddr() init function to use an
additional instance number argument.
Signed-off-by: Matt Porter <mporter@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Eliminate AM33xx specific names to prepare for TI814x support
within AM33xx-land.
Signed-off-by: Matt Porter <mporter@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
- In arch/arm/cpu/armv7/omap-common/timer.c,
drivers/mtd/nand/omap_gpmc.c and drivers/net/cpsw.c add #include files
that the driver needs but had been relying on <config.h> to bring in.
- In arch/arm/cpu/armv7/omap-common/lowlevel_init.S add <config.h>
- In am335x_evm.h and pcm051.h don't globally include
<asm/arch/hardware.h> and <asm/arch/cpu.h> but just <asm/arch/omap.h>
as that is the only include which defines things the config uses.
Cc: Lars Poeschel <poeschel@lemonage.de>
Signed-off-by: Tom Rini <trini@ti.com>
Enable DDR PHY dynamic power down bit, which enables
powering down the IO receiver when not performing read.
This also helps in reducing overall power consumption in
low power states (suspend/standby).
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Satyanarayana, Sandhya <sandhya.satyanarayana@ti.com>
Cc: Tom Rini <trini@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Allow AM335x MPU core clock speed to be specified in the board config file.
To use, add the following to the board's config file:-
#define CONFIG_SYS_MPUCLK <desired clock freq in MHz>
Signed-off-by: Mark Jackson <mpfj@newflow.co.uk>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects.
Changes in V4:
- Fix checkpatch errors (TAB -> space mangling)
Changes in V3:
- Fix line wrapping
Changes in V2:
- Indicate this is for AM33xx (not OMAP2)
Signed-off-by: Mark Jackson <mpfj@newflow.co.uk>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
The various mmc_host_def.h files are almost identical.
Reduce code duplication by moving the similar definitions to a common
header file.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
This patch adds BOOT_DEVICE define for USB booting and fixes
spl_board_init function to call arch_misc_init (this is the place there
musb is initialized).
Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
AM335x EVM 1.5A uses Micron MT41J512M8RH-125 SDRAM 4Gb (512Mx8) as the
DDR3 chip.
[Hebbar Gururaja <gururaja.hebbar@ti.com>]
- Resolve merge conflict while rebasing. File structure is
changed in the mainline. So re-arrange the code accordingly.
- Update commit message to reflect the DDR3 part number
Signed-off-by: Jeff Lance <j-lance1@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Signed-off-by: Hebbar Gururaja <gururaja.hebbar@ti.com>
The board is named pcm051 and has this hardware:
SOC: TI AM3359
DDR3-RAM: 2x MT41J256M8HX-15EIT:D 512MiB
ETH 1: LAN8710AI
SPI-Flash: W25Q64BVSSIG
RTC: RV-4162-C7
I2C-EEPROM: CAT32WC32
NAND: MT29F4G08_VFPGA63
PMIC: TPS65910A3
LCD
Supported:
UART 1
MMC/SD
ETH 1
USB
I2C
SPI
Not yet supported:
NAND
RTC
LCD
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
[trini: Add #define CONFIG_PHY_ADDR 0 to config]
Signed-off-by: Tom Rini <trini@ti.com>
AM33XX has Error Location Module (ELM) that can be used in conjuction
with GPMC controller to implement BCH codes fully in hardware.
This code is mostly taken from arago tree.
Signed-off-by: Mansoor Ahamed <mansoor.ahamed@ti.com>
Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
TI AM33XX has the same GPMC controller as OMAP3 so we could just use the
existing omap_gpmc driver. This patch adds adds required
definitions/intialization.
Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
AM33xx has support for dual port MUSB OTG controller. This patch
adds initialization for the controller using new MUSB gadget
driver and ether gadget.
Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
Move the hardcoded ddr2/ddr3 settings for the ti boards to board code,
so other boards can use different types/timings.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
[trini: Make apply with rtc32k_enable() in the file]
Signed-off-by: Tom Rini <trini@ti.com>
The i2c header is specific to ti(-derived) boards, and not generic for all
am335x boards.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
[trini: Make re-apply with rtc32k_enable() applied]
Signed-off-by: Tom Rini <trini@ti.com>
Add the required config.mk logic for this SoC as well as the BOOT_DEVICE
define. Finally, enable the options on the am335x_evm.
Signed-off-by: Tom Rini <trini@ti.com>
In order to support low power state, you must source kernel system
timers to persistent clock, available across suspend/resume. In case of
AM335x device, the only source we have is, RTC32K, available in
wakeup/always-on domain. Having said that, during validation it has
been observed that, RTC clock need couple of seconds delay to stabilize
the RTC OSC clock; and such a huge delay is not acceptable in kernel
especially during early init and also it will impact quick/fast boot
use-cases.
So, RTC32k OSC enable dependency has been shifted to
SPL/first-bootloader.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
U-boot should not ignore getting the bootmode passed on from the bootrom.
With this, U-boot SPL knows it was loaded from MMC1 and use this info to
read full U-boot from MMC1 as well.
Cc: pprakash@ti.com
Cc: trini@ti.com
Signed-off-by: Joel A Fernandes <joelagnel@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
This patch adds support for networking in SPL. Some devices are
capable of loading SPL via network so it makes sense to load the
main U-Boot binary via network too. This patch tries to use
existing network code as much as possible. Unfortunately, it depends
on environment which in turn depends on other code so SPL size
is increased significantly. No effort was done to decouple network
code and environment so far.
Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Tom Rini <trini@ti.com>
Move the SPL prototypes from <asm/omap_common.h> into <asm/spl.h> and
add <asm/arch/spl.h> for arch specific portions of CONFIG_SPL_FRAMEWORK.
Signed-off-by: Tom Rini <trini@ti.com>
This patch updates secure_emif_sdram_config with the
same value written to sdram_config during ddr3 initialization.
During suspend/resume, this value is copied into sdram_config.
With this, a write to sdram_config at the end of resume sequence
which triggers an init sequence can be avoided.
Without this register write in place, the DDR_RESET line goes
low for a few cycles during resume which is a violation of the
JEDEC spec.
Signed-off-by: Satyanarayana, Sandhya <sandhya.satyanarayana@ti.com>
Make the lowlevel_init function that these platforms have which just
sets up the stack and calls a C function available to all armv7
platforms. As part of this we change some of the macros that are used
to be more clear. Previously (except for am335x evm) we had been
setting CONFIG_SYS_INIT_SP_ADDR to a series of new defines that are
equivalent to simply referencing NON_SECURE_SRAM_END. On am335x evm we
should have been doing this initially and do now.
Cc: Sricharan R <r.sricharan@ti.com>
Tested-by: Allen Martin <amartin@nvidia.com>
Signed-off-by: Tom Rini <trini@ti.com>
- Correct the MMC1 base offset
- Remove MMC2 (that area is reserved and not MMC2).
- Add the real BOOT_DEVICE_MMC2 value
Signed-off-by: Tom Rini <trini@ti.com>
- Move definition of the EEPROM contents to <asm/arch/sys_proto.h>
- Make some defines a little less generic now.
- Pinmux must be done by done by SPL now.
- Create 3 pinmux functions, uart0, i2c0 and board.
- Add pinmux specific to Starter Kit EVM for MMC now.
Signed-off-by: Tom Rini <trini@ti.com>
- Board requires gpio0 #7 to be set to power DDR3.
- Board uses DDR3, add a way to determine which DDR type to call
config_ddr with.
- Both of the above require filling in the header structure early, move
it into the data section.
Signed-off-by: Tom Rini <trini@ti.com>
The ddr_regs struct was incorrectly offset after the dt0wiratio0 entry.
Correct this by documenting a missing register that will be used at some
point in the future (when write leveling is supported). Further, the
cmdNcs{force,delay} fields are undocumented and we have been setting
them to zero, remove. Next, setting of the
'DATAn_REG_PHY_USE_RANK0_DELAYS field belongs with the rest of the
ddr_data entries, so program it there. Finally, comment on how we are
configuring the DATA1 registers that correspond to the DATA0 (dt0)
registers defined in the struct.
Signed-off-by: Tom Rini <trini@ti.com>
The various ratio1 fields are not documented in any of the documentation
I can find. Removing these and testing has yielded success, so remove
the code that sets them and move their locations into the reserved
fields.
Signed-off-by: Tom Rini <trini@ti.com>
This function sets a number of related registers to the same value (the
registers in question all have the same field descriptions and are
related in operation). Rather than defining a struct and setting the
value repeatedly, just pass in the value.
Signed-off-by: Tom Rini <trini@ti.com>