Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-15 01:17:39 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/cpu/armv7/omap-common/lowlevel_init.S

40 lines
768 B
ArmAsm
Raw Normal View History

ARM Cortex A8: Move OMAP3 specific reset handler Because of the reset_cpu is soc specific, should be move to soc Cc: Dirk Behme <dirk.behme@googlemail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2009-07-20 02:40:01 +00:00
/*
ARMV7: Add basic support for TI OMAP4 This patch adds minimum support for OMAP4. Code which can be shared between OMAP3 and OMAP4 is placed in arch/arm/cpu/armv7/omap-common Signed-off-by: Aneesh V <aneesh@ti.com> Signed-off-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Sandeep Paulraj <s-paulraj@ti.com>
2010-06-08 20:07:46 +00:00
* Board specific setup info
*
* (C) Copyright 2010
* Texas Instruments, <www.ti.com>
*
* Author :
* Aneesh V <aneesh@ti.com>
ARM Cortex A8: Move OMAP3 specific reset handler Because of the reset_cpu is soc specific, should be move to soc Cc: Dirk Behme <dirk.behme@googlemail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2009-07-20 02:40:01 +00:00
*
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>
2013-07-08 07:37:19 +00:00
* SPDX-License-Identifier: GPL-2.0+
ARM Cortex A8: Move OMAP3 specific reset handler Because of the reset_cpu is soc specific, should be move to soc Cc: Dirk Behme <dirk.behme@googlemail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
2009-07-20 02:40:01 +00:00
*/
am33xx: Add required includes to some omap/am33xx code - 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>
2013-03-14 11:15:25 +00:00
#include <config.h>
omap5: Add minimal support for omap5430. 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>
2011-11-15 14:49:55 +00:00
#include <asm/arch/omap.h>
ARM: OMAP: Cleanup boot parameters usage The boot parameters are read from individual variables assigned for each of them. This been corrected and now they are stored as a part of the global data 'gd' structure. So read them from 'gd' instead. Signed-off-by: Sricharan R <r.sricharan@ti.com> [trini: Add igep0033 hunk] Signed-off-by: Tom Rini <trini@ti.com>
2013-04-24 00:41:24 +00:00
#include <asm/omap_common.h>
am33xx: Fix fetching of mmc1 bootmode from bootrom for AM33XX 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>
2012-09-18 04:30:51 +00:00
#include <asm/arch/spl.h>
armv7: add appropriate headers for assembly functions Use ENTRY and ENDPROC with assembly functions to ensure necessary assembler directives for all functions. Signed-off-by: Aneesh V <aneesh@ti.com> Acked-by: Mike Frysinger <vapier@gentoo.org>
2012-03-08 07:20:18 +00:00
#include <linux/linkage.h>
omap4/5: Add support for booting with CH. 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>
2011-11-15 14:50:03 +00:00
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-15 14:02:19 +00:00
#ifdef CONFIG_SPL
armv7: add appropriate headers for assembly functions Use ENTRY and ENDPROC with assembly functions to ensure necessary assembler directives for all functions. Signed-off-by: Aneesh V <aneesh@ti.com> Acked-by: Mike Frysinger <vapier@gentoo.org>
2012-03-08 07:20:18 +00:00
ENTRY(save_boot_params)
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-15 14:02:19 +00:00
ARM: OMAP: Cleanup boot parameters usage The boot parameters are read from individual variables assigned for each of them. This been corrected and now they are stored as a part of the global data 'gd' structure. So read them from 'gd' instead. Signed-off-by: Sricharan R <r.sricharan@ti.com> [trini: Add igep0033 hunk] Signed-off-by: Tom Rini <trini@ti.com>
2013-04-24 00:41:24 +00:00
ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
omap4/5: Add support for booting with CH. 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>
2011-11-15 14:50:03 +00:00
str r0, [r1]
arm: Allow lr to be saved by board code The link register value can be required on some boards (e.g. FEL mode on sunxi) so use a branch instruction to jump to save_boot_params() instead of a branch link. This requires a branch back to save_boot_params_ret so adjust the users to deal with this. For exynos just drop the function since it doesn't do anything. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-02-07 17:47:28 +00:00
b save_boot_params_ret
armv7: add appropriate headers for assembly functions Use ENTRY and ENDPROC with assembly functions to ensure necessary assembler directives for all functions. Signed-off-by: Aneesh V <aneesh@ti.com> Acked-by: Mike Frysinger <vapier@gentoo.org>
2012-03-08 07:20:18 +00:00
ENDPROC(save_boot_params)
ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with omap_smc1 omap_smc1 is now generic enough to remove duplicate omap3_gp_romcode_call logic that omap3 introduced. As part of this change, move to using the generic lowlevel_init.S for omap3 as well. Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-03-09 22:12:05 +00:00
#endif
omap4/5: Add support for booting with CH. 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>
2011-11-15 14:50:03 +00:00
ARM: OMAP: Change set_pl310_ctrl_reg to be generic 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>
2015-03-09 22:12:03 +00:00
ENTRY(omap_smc1)
PUSH {r4-r12, lr} @ save registers - ROM code may pollute
armv7: adapt omap4 to the new cache maintenance framework adapt omap4 to the new layered cache maintenance framework Signed-off-by: Aneesh V <aneesh@ti.com>
2011-06-16 23:30:52 +00:00
@ our registers
ARM: OMAP: Change set_pl310_ctrl_reg to be generic 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>
2015-03-09 22:12:03 +00:00
MOV r12, r0 @ Service
MOV r0, r1 @ Argument
DSB
DMB
.word 0xe1600070 @ SMC #0 - hand assembled for GCC versions
@ call ROM Code API for the service requested
POP {r4-r12, pc}
ENDPROC(omap_smc1)
Reference in a new issue Copy permalink