This is always defined to 2, and referenced in two places. Move the
define to <asm/omap_common.h> and make sure the code that uses this
includes that file. Make <asm/arch-omap*/clock.h> not include that
file, as we don't need to be doing so.
Signed-off-by: Tom Rini <trini@konsulko.com>
It is bad practice to include common.h in other header files since it can
bring in any number of superfluous definitions. It implies that some C
files don't include it and thus may be missing CONFIG options that are set
up by that file. The C files should include these themselves.
Update some header files in arch/arm to drop this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move away from SoC specific headers to handle different register layout.
Instead use driver data to get appropriate register layouts like in the
kernel. While at it, perform some mostly cosmetic alignment/cleanup in
the functions being updated.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Align the base address defined in header files with the base address used
in the DTS. This will facilitate the introduction of the DMA support.
Of all HSMMC users, only omap3 doesn't have the 0x100 reserved region at
the top. This region will be used to determine if the controller supports
DMA transfers
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SYS_I2C_BUS_MAX
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
[trini: Fix AM43XX drop AM44XX]
Signed-off-by: Tom Rini <trini@konsulko.com>
For consistency with other platforms and in preparation of Kconfig
migration, let's change Several TI platforms that use I2C_BUS_MAX
to CONFIG_SYS_I2C_BUS_MAX
Signed-off-by: Adam Ford <aford173@gmail.com>
Refactor OMAP3/4/5 code so that we have only one get_device_type()
function for all platforms.
Details:
- Add ctrl variable for AM33xx and OMAP3 platforms (like it's done for
OMAP4/5), so we can obtain status register in common way
- For now ctrl structure for AM33xx/OMAP3 contains only status register
address
- Run hw_data_init() in order to assign ctrl to proper structure
- Remove DEVICE_MASK and DEVICE_GP definitions as they are not used
(DEVICE_TYPE_MASK and GP_DEVICE are used instead)
- Guard structs in omap_common.h with #ifdefs, because otherwise
including omap_common.h on non-omap4/5 board files breaks compilation
Buildman script was run for all OMAP boards. Result output:
arm: (for 38/616 boards)
all +352.5
bss -1.4
data +3.5
rodata +300.0
spl/u-boot-spl:all +284.7
spl/u-boot-spl:data +2.2
spl/u-boot-spl:rodata +252.0
spl/u-boot-spl:text +30.5
text +50.4
(no errors to report)
Tested on AM57x EVM and BeagleBoard xM.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
[trini: Rework the guards as to not break TI81xx]
Signed-off-by: Tom Rini <trini@konsulko.com>
On all TI platforms the ROM defines a "downloaded image" area at or near
the start of SRAM which is followed by a reserved area. As it is at
best bad form and at worst possibly harmful in corner cases to write in
this reserved area, we stop doing that by adding in the define
NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image
area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this.
At current we define the end of scratch space at 0x228 bytes past the
start of scratch space this this gives us a lot of room to grow. As
these scratch uses are non-optional today, all targets are modified to
respect this boundary.
Tested on OMAP4 Pandaboard, OMAP3 Beagle xM
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Nagendra T S <nagendra@mistralsolutions.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Paul Kocialkowski <contact@paulk.fr>
Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: Adam Ford <aford173@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Thomas Weber <weber@corscience.de>
Cc: Hannes Schmelzer <oe5hpm@oevsv.at>
Cc: Thomas Chou <thomas@wytron.com.tw>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Samuel Egli <samuel.egli@siemens.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Cc: Ben Whitten <ben.whitten@gmail.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: "B, Ravi" <ravibabu@ti.com>
Cc: "Matwey V. Kornilov" <matwey.kornilov@gmail.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Ash Charles <ashcharles@gmail.com>
Cc: "Kipisz, Steven" <s-kipisz2@ti.com>
Cc: Daniel Allred <d-allred@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Ladislav Michl <ladis@linux-mips.org>
The register offset of i2c_sysc offset is not correct as per
omap4 TRM [1], correct the offsets as per the documentation.
[1] - http://www.ti.com/lit/ug/swpu235ab/swpu235ab.pdf
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reboot mode is written to SAR memory before reboot in the form of a string.
This mechanism is supported on OMAP4 by various TI kernels.
It is up to each board to make use of this mechanism or not.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
This correctly enables the USB PHY clocks, by enabling CM_ALWON_USBPHY_CLKCTRL
and correctly setting CM_L3INIT_USBPHY_CLKCTRL's value.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
There is no distinction between essential and non-essential mux configuration,
so it doesn't make sense to have an "essential" prefix.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Individual boards might provide their own emif_get_device_timings function and
use the jedec timings in their own way, hence those have to be exported.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Individual boards might provide their own emif_get_device_timings function and
use the elpidia timings in their own way, hence those have to be exported.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Individual boards might provide their own emif_get_device_details function and
use elpidia device details in their own way, hence those have to be exported.
This also wraps existing definitions with the proper ifdef logic.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Many TI EVMs have capability to store relevant board information
such as DDR description in EEPROM. Further many pad configuration
variations can occur as part of revision changes in the platform.
In-order to support these at runtime, we for a board detection hook
which is available for override from board files that may desire to do
so.
NOTE: All TI EVMs are capable of detecting board information based on
early clocks that are configured. However, in case of additional needs
this can be achieved within the override logic from within the board
file.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Centralize gpi2c_init into omap_common from the sys_proto header so
that the information can be reused across SoCs.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Early clock initialization is currently done in two stages for OMAP4/5
SoCs. The first stage is the initialization of console clocks and
then we initialize basic clocks for functionality necessary for SoC
initialization and basic board functionality.
By splitting up prcm_init and centralizing this clock initialization,
we setup the code for follow on patches that can do board specific
initialization such as board detection which will depend on these
basic clocks.
As part of this change, since the early clock initialization
is centralized, we no longer need to expose the console clock
initialization.
NOTE: we change the sequence slightly by initializing console clocks
timer after the io settings are complete, but this is not expected
to have any functioanlity impact since we setup the basic IO drive
strength initialization as part of do_io_settings.
Signed-off-by: Steve Kipisz <s-kipisz2@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
In a number of places we had wordings of the GPL (or LGPL in a few
cases) license text that were split in such a way that it wasn't caught
previously. Convert all of these to the correct SPDX-License-Identifier
tag.
Signed-off-by: Tom Rini <trini@konsulko.com>
This introduces omap4 support for omap_die_id, which matches the common
omap_die_id definition. It replaces board-specific code to grab the die id bits.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
This cleans up the SPL boot devices for omap platforms and introduces support
for missing boot devices.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
This introduces OMAP3 support for the common omap boot code, as well as a
major cleanup of the common omap boot code.
First, the omap_boot_parameters structure becomes platform-specific, since its
definition differs a bit across omap platforms. The offsets are removed as well
since it is U-Boot's coding style to use structures for mapping such kind of
data (in the sense that it is similar to registers). It is correct to assume
that romcode structure encoding is the same as U-Boot, given the description
of these structures in the TRMs.
The original address provided by the bootrom is passed to the U-Boot binary
instead of a duplicate of the structure stored in global data. This allows to
have only the relevant (boot device and mode) information stored in global data.
It is also expected that the address where the bootrom stores that information
is not overridden by the U-Boot SPL or U-Boot.
The save_omap_boot_params is expected to handle all special cases where the data
provided by the bootrom cannot be used as-is, so that spl_boot_device and
spl_boot_mode only return the data from global data.
All of this is only relevant when the U-Boot SPL is used. In cases it is not,
save_boot_params should fallback to its weak (or board-specific) definition.
save_omap_boot_params should not be called in that context either.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
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>
Part of DMM logic is reuse from commit
47a4bea6af ("ARM: omap4: Update sdram
setting for panda rev A6") Which broke SDP4430 with ES2.3 (uses old
DDR).
So, to maintain support for newer DDR used in Panda ES rev B3, we
should, in addition to the commit
675cc77a3a ("ARM:OMAP4+: panda-es: Support
Rev B3 Elpida DDR2 RAM"), DDR timings, also do DMM configuration
specific to Panda.
Signed-off-by: Nishanth Menon <nm@ti.com>
The omap_hw_init_context function (and assorted helpers) is the same for
all OMAP-derived parts as when CHSETTINGS are used, that's the same and
our DDR base is also always the same. In order to make this common we
simply need to update the names of the define for DDR address space
which is also common.
Cc: Sricharan R. <r.sricharan@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
This patch moves platform specific information for GPMC and ELM controller
into separate header files, so that any derivative devices do not mess other
header files.
Platform specific information added into arch-xx/../hardware.h
- CPU related platform specific details like base-address of GPMC and ELM
Platform specific information added into arch-xx/../mem.h
- Generic configs for GPMC and ELM initialization.
- Hardware parameters or constrains specific to GPMC and ELM IP like;
number of max number of chip-selects available
Signed-off-by: Pekon Gupta <pekon@ti.com>
The only remaining user of the custom bit manipulation function sr32()
is arch/arm/cpu/armv7/omap3/clock.c, so make it a static function in
that file to prepare complete removal.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Fix the macros guarding the spl.h header for various platforms. Due to
a typo and a propagation of it, the macros went out-of-sync with their
ifdef check, so fix this.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@ti.com>
omap_gpmc.h is a generic header used by OMAP NAND driver for all TI platfoms.
Hence this file should be present in generic folder instead of architecture
specific include folder.
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: Pekon Gupta <pekon@ti.com>
Each SoC platform (AM33xx, OMAP3, OMAP4, OMAP5) has its own copy of GPMC related
defines and declarations scattered in SoC platform specific header files
like include/asm/arch-xx/cpu.h
However, GPMC hardware remains same across all platforms thus this patch merges
GPMC data scattered across different arch-xx specific header files into single
header file include/asm/arch/omap_gpmc.h
Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5
Signed-off-by: Pekon Gupta <pekon@ti.com>
The commit
f3f98bb0 : "ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls"
removed the config option aimed towards moving that stuff into kernel, which
renders some code unreachable. Remove that code.
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
With the current scenario SPL size is being overlapped with the public
stack and not allowing any OMAP4 device to boot. So the suggestion came
up was to move the TEXT_BASE down to non-HS limit. Fixing the same and
also moving the SRAM_SCRATCH_SPACE_ADDR up to the end of image
downloadable area.
Discussion on this can be seen here:
https://www.mail-archive.com/u-boot@lists.denx.de/msg127147.html
Tested on OMAP4460 PANDA.
Reported-by: Chao Xu <caesarxuchao@gmail.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Add a MAC address create based on the OMAP die ID registers.
Then poplulate the ethaddr enviroment variable so that the device
tree alias can be updated prior to boot.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
OMAP4470 reference design uses TWL6032 PMIC
with a following connection scheme:
VDD_CORE = TWL6032 SMPS2
VDD_MPU = TWL6032 SMPS1
VDD_IVA = TWL6032 SMPS5
Set voltage and frequency values according to
OMAP4470 Data Manual Operating Condition Addendum v0.7
Signed-off-by: Taras Kondratiuk <taras@ti.com>
Unlike the other patches in this series so far, this commit fixes a
ambiguity in the license terms for some OMAP files: the code was
originally derived from the Linux kernel sources, where it was clearly
marked as GPL-2.0 (i. e. without the "or later" part), but the U-Boot
version had a GPL-2.0+ file header added, apparently without
permission / relicensing from the original authors of the code.
Insert a GPL-2.0 SPDX-License-Identifier to fix this.
Signed-off-by: Wolfgang Denk <wd@denx.de>
cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Tom Rini <trini@ti.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Acked-by: Tom Rini <trini@ti.com>
Fix a trivial conflict in arch/arm/dts/exynos5250.dtsi about gpio and
serial.
Conflicts:
arch/arm/dts/exynos5250.dtsi
Signed-off-by: Tom Rini <trini@ti.com>
The omap_gpio driver is used by AM33XX, OMAP3/4, OMAP54XX and DRA7XX SoCs.
These SoCs have different gpio count but currently omap_gpio driver uses hard
coded 192 which is wrong.
This patch fixes this issue by:
1. Move define of OMAP_MAX_GPIO to all arch/arm/include/asm/arch-omap*/gpio.h.
2. Update gpio bank settings and enable GPIO modules 7 & 8 clocks for OMAP5.
Thanks for Lubomir Popov to provide valuable comments to fix this issue.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Tested-by: Lubomir Popov <lpopov@mm-sol.com>
Acked-by: Heiko Schocher <hs@denx.de>
Small conflict over DRA7XX updates and adding SRAM_SCRATCH_SPACE_ADDR
Conflicts:
arch/arm/include/asm/arch-omap5/omap.h
Signed-off-by: Tom Rini <trini@ti.com>
Update PLL values.
SYS_CLKSEL value for 20MHz is changed to 2. In other platforms
SYS_CLKSEL value 2 represents reserved. But in sys_clk array
ind 1 is used for 13Mhz. Since other platforms are not using
13Mhz, reusing index 1 for 20MHz.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
The sys_clk on the dra evm board is 20MHZ.
Changing the configuration for the same.
And also moving V_SCLK, V_OSCK defines to
arch/clock.h for OMAP4+ boards.
Signed-off-by: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
TPS659038 is the power IC used in DRA7XX boards.
Adding support for this and also adding pmic data
for DRA7XX boards.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Voltage scaling can be done in two ways:
-> Using SR I2C
-> Using GP I2C
In order to support both, have a function pointer in pmic_data
so that we can call as per our requirement.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
