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>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: U-Boot DM <u-boot-dm@lists.denx.de>
Cc: Tom Rini <trini@ti.com>
Acked-by: Tom Rini <trini@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
This fixes the breakage with SPL on most OMAP boards after the GPIO
driver was moved.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: U-Boot DM <u-boot-dm@lists.denx.de>
Cc: Tom Rini <trini@ti.com>
Acked-by: Tom Rini <trini@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Currently on OMAP4/5 platforms, many kernel drivers are dependent
upon the bootloaders for mux, dpll and clock configurations.
This should not be the case and bootloaders should set only the
minimum required for the uboot functionality and kernel boot.
Note that this is going to break the kernel drivers. But this
is the only way to get things fixed in the kernel.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Exactly one board has defined CONFIG_SYS_PROMPT_HUSH_PS2 to a value
different than "> " which is vision2. I have Cc'd the maintainer here
as I strongly suspect this is a bug rather than intentional behavior.
Cc: Stefano Babic <sbabic@denx.de>
Signed-off-by: Tom Rini <trini@ti.com>
Acked-by: Stefano Babic <sbabic@denx.de>
For OMAP4 boards, such as the panda-es, that have 1GB of memory the linux
kernel fails to locate the device tree blob on boot. The reason being is that
u-boot is copying the DT blob to the upper part of RAM when booting the kernel
and the kernel is unable to access the blob. By setting the fdt_high variable
to either 0xffffffff (to prevent the copy) or 0xac000000 (704MB boundary
of memory for OMAP4) the kernel is able to locate the DT blob and boot.
Based upon following patch by Dirk Behme set the fdt_high variable to allow
booting with device tree on OMAP4 boards.
"7e9603e i.mx6q: configs: Add fdt_high and initrd_high variables"
Cc: Sricharan R <r.sricharan@ti.com>
Cc: Sandeep Paulraj <s-paulraj@ti.com>
Cc: Tom Rini <trini@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Change the CONFIG_SYS_TEXT_BASE and the addresses of SDRAM
buffers used by SPL(heap and BSS) keeping in mind the
following requirements:
1. Make sure that SPL's heap and BSS doesn't come in the way
of Linux kernel, which is typically loaded at 0x80008000. This
will be important when SPL directly loads kernel.
2. Align the CONFIG_SYS_TEXT_BASE between TI internal
U-Boot and mainline U-Boot. This avoids a lot of confusion
and allows for the inter-operability of x-loader, SPL,
internal U-Boot, mainline U-Boot etc. The internal U-Boot's
address can not be changed to that of mainline U-Boot
as internal U-Boot doesn't have relocation and 0x80100000
used by mainline U-Boot will clash with kernel
3. Assume only a minimum amount of memory that may be available
on any practical OMAP4/5 board in future too. We are assuming
a minimum of 128 MB of memory
Signed-off-by: Aneesh V <aneesh@ti.com>
Configuration header(CH) is 512 byte header attached to an OMAP
boot image that will help ROM code to initialize clocks, SDRAM
etc and copy U-Boot directly into SDRAM. CH can help us in
by-passing SPL and directly boot U-boot, hence it's an alternative
for SPL. However, we intend to support both CH and SPL for OMAP4/5.
Initialization done through CH is limited and is not equivalent
to that done by SPL. So U-Boot has to distinguish between the
two cases and handle them accordingly. This patch takes care
of doing this.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
This patch adds the minimal support for OMAP5. The platform and machine
specific headers and sources updated for OMAP5430.
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP architecture.
It's a dual core SOC with GIC used for interrupt handling and SCU for cache
coherency.
Also moved some part of code from the basic platform support that can be made
common for OMAP4/5. Rest is kept out seperately. The same approach is followed
for clocks and emif support in the subsequent patches.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
FAT library now uses malloc() and free(). But SPL doesn't
have heap until now. Setup a heap in SDRAM to fix this issue.
However this increases SPL footprint beyond the available SRAM
budget. So, compile out some fancy features in the SDARM init
bring back footprint under control
CC: Sandeep Paulraj <s-paulraj@ti.com>
CC: Wolfgang Denk <wd@denx.de>
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
All ddr configurations(geometry/timings) are done automatically
by detecting the device connected at run time. Though this
is a useful feature, making this as a default setting increases
the code size by about 2K bytes. This is quite big, especially
in the case of SPL which runs from a smaller SRAM. So do not
use this feature as the default setting, instead use the
precalculated tables.
Signed-off-by: sricharan <r.sricharan@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Config VMMC voltage to 3V for MMC/SD card slot
and PBIAS settings needed for OMAP4
Fixes MMC/SD detection on boot from eMMC.
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
Factor out common parts from omap4_sdp4430.h and omap4_panda.h
into a new file omap4_common.h
Signed-off-by: Aneesh V <aneesh@ti.com>
Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
