Commit graph

6 commits

Author SHA1 Message Date
Tom Rini
fa2f81b06f 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>
2016-09-06 13:41:42 -04:00
Paul Kocialkowski
90ca5dfec4 omap3: Use a define for reboot reason offset
This introduces a define for the offset to the reboot reason, rather than
hardcoding it.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-15 15:10:48 -04:00
Paul Kocialkowski
c5412b084b omap3: String-based reboot mode handling
This switches reboot mode handling to a string-based interface, that allows more
flexibility to set a common interface with the next generations of OMAP devices.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-03-15 15:10:47 -04:00
Paul Kocialkowski
a08af85f46 omap3: Reboot mode support
Reboot mode is written in scratchpad memory before reboot in the form of a
single char, that is the first letter of the reboot mode string as passed to the
reboot function.

This mechanism is supported on OMAP3 both my the upstream kernel and 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>
Reviewed-by: Tom Rini <trini@konsulko.com>
2015-08-12 20:47:36 -04:00
Paul Kocialkowski
60c7c30aa0 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>
2015-07-27 15:02:03 -04:00
Nishanth Menon
987ec5851c ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCs
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>
2015-03-13 09:28:57 -04:00
Renamed from arch/arm/include/asm/arch-omap3/omap3.h (Browse further)