arm: omap: Unify get_device_type() function

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 platfor

arm: omap: Unify get_device_type() function

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>

show more ...

TI: Rework SRAM definitions and maximums

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 a

TI: Rework SRAM definitions and maximums

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>

show more ...

omap4: Reboot mode support

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 us

omap4: Reboot mode support

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>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot

omap4: omap_die_id support

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: Pa

omap4: omap_die_id support

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>

show more ...

omap-common: Common boot code OMAP3 support and cleanup

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_pa

omap-common: Common boot code OMAP3 support and cleanup

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>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-arm

Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'

ARM: omap4: add platform specific info for GPMC and ELM controllers

This patch moves platform specific information for GPMC and ELM controller
into separate header files, so that any derivative devi

ARM: omap4: add platform specific info for GPMC and ELM controllers

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>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-arm

Bringing in the MMC tree means that CONFIG_BOUNCE_BUFFER needed to be
added to include/configs/exynos5-dt.h now.

Conflicts:
include/configs/ex

Merge branch 'master' of git://git.denx.de/u-boot-arm

Bringing in the MMC tree means that CONFIG_BOUNCE_BUFFER needed to be
added to include/configs/exynos5-dt.h now.

Conflicts:
include/configs/exynos5250-dt.h

Signed-off-by: Tom Rini <trini@ti.com>

show more ...

ARM: OMAP4: Move TEXT_BASE down to non-HS limit

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

ARM: OMAP4: Move TEXT_BASE down to non-HS limit

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>

show more ...

ARM: omap4-panda: Add MAC address creation for panda

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

ARM: omap4-panda: Add MAC address creation for panda

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>

show more ...

Merge branch 'master' of git://git.denx.de/u-boot-arm

Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'

ARM: OMAP4470: Add OMAP4470 identification

Signed-off-by: Taras Kondratiuk <taras@ti.com>

Merge git://git.denx.de/u-boot-arm

Conflicts:
board/freescale/mx6qsabrelite/Makefile
board/freescale/mx6qsabrelite/mx6qsabrelite.c
include/configs/mx6qsabrelite.h

Signed-off-by: Stefano Babic <s

Merge git://git.denx.de/u-boot-arm

Conflicts:
board/freescale/mx6qsabrelite/Makefile
board/freescale/mx6qsabrelite/mx6qsabrelite.c
include/configs/mx6qsabrelite.h

Signed-off-by: Stefano Babic <sbabic@denx.de>

show more ...

Merge branch 'u-boot/master' into u-boot-arm/master

Add GPL-2.0+ SPDX-License-Identifier to source files

Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>

Merge branch 'master' of git://git.denx.de/u-boot-arm

Small conflict over DRA7XX updates and adding SRAM_SCRATCH_SPACE_ADDR

Conflicts:
arch/arm/include/asm/arch-omap5/omap.h

Signed-off-by: Tom Ri

Merge branch 'master' of git://git.denx.de/u-boot-arm

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>

show more ...

Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'

ARM: OMAP4+: Cleanup header files

After having the u-boot clean up series, there are
many definitions that are unused in header files.
Removing all those unused ones.
Signed-off-by: Lokesh Vutla <lo

ARM: OMAP4+: Cleanup header files

After having the u-boot clean up series, there are
many definitions that are unused in header files.
Removing all those unused ones.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

show more ...

OMAP3+: introduce generic ABB support

Adaptive Body Biasing (ABB) modulates transistor bias voltages
dynamically in order to optimize switching speed versus leakage.
Adaptive Body-Bias ldos are pres

OMAP3+: introduce generic ABB support

Adaptive Body Biasing (ABB) modulates transistor bias voltages
dynamically in order to optimize switching speed versus leakage.
Adaptive Body-Bias ldos are present for some voltage domains
starting with OMAP3630. There are three modes of operation:

* Bypass - the default, it just follows the vdd voltage
* Foward Body-Bias - applies voltage bias to increase transistor
performance at the cost of power. Used to operate safely at high
OPPs.
* Reverse Body-Bias - applies voltage bias to decrease leakage and
save power. Used to save power at lower OPPs.

Signed-off-by: Andrii Tseglytskyi <andrii.tseglytskyi@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>

show more ...

am33xx/omap4+: Move SRAM_SCRATCH_SPACE_ADDR to <asm/arch/omap.h>

The location of valid scratch space is dependent on SoC, so move that
there. On OMAP4+ we continue to use SRAM_SCRATCH_SPACE_ADDR.

am33xx/omap4+: Move SRAM_SCRATCH_SPACE_ADDR to <asm/arch/omap.h>

The location of valid scratch space is dependent on SoC, so move that
there. On OMAP4+ we continue to use SRAM_SCRATCH_SPACE_ADDR. On
am33xx/ti814x we want to use what the ROM defines as "public stack"
which is the area after our defined download image space. Correct the
comment about and location of CONFIG_SPL_TEXT_BASE.

Signed-off-by: Tom Rini <trini@ti.com>

show more ...

Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'

ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common

These defines are same across OMAP4/5. So move them to
omap_common.h. This is required for the patches that
follow.

Signed-off-by: Sricharan R

ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common

These defines are same across OMAP4/5. So move them to
omap_common.h. This is required for the patches that
follow.

Signed-off-by: Sricharan R <r.sricharan@ti.com>

show more ...