Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-05 12:45:42 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/mach-omap2/lowlevel_init.S

90 lines
1.8 KiB
ArmAsm
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style 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>
2018-05-06 21:58:06 +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
/*
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
*/
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
arm: omap-common: add secure smc entry Add an interface for calling secure ROM APIs across a range of OMAP and OMAP compatible high-security (HS) device variants. While at it, also perform minor cleanup/alignment without any change in functionality. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-06-27 14:19:17 +00:00
.arch_extension sec
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)
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: OMAP5+: Override switch_to_hypervisor function Override the switch_to_hypervisor function to switch cpu to hypervisor mode using the available ROM code hook early in the boot phase before the boot loader checks for HYP mode. Based on the work done by Jonathan Bergsagel jbergsagel@ti.com. Cc: beagleboard-x15@googlegroups.com Signed-off-by: Keerthy <j-keerthy@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-09-14 05:13:33 +00:00
#if !defined(CONFIG_TI_SECURE_DEVICE) && defined(CONFIG_ARMV7_LPAE)
ENTRY(switch_to_hypervisor)
/*
* Switch to hypervisor mode
*/
adr r0, save_sp
str sp, [r0]
adr r1, restore_from_hyp
ldr r0, =0x102
b omap_smc1
restore_from_hyp:
adr r0, save_sp
ldr sp, [r0]
MRC p15, 4, R0, c1, c0, 0
ldr r1, =0X1004 @Set cache enable bits for hypervisor mode
orr r0, r0, r1
MCR p15, 4, R0, c1, c0, 0
b switch_to_hypervisor_ret
save_sp:
.word 0x0
ENDPROC(switch_to_hypervisor)
#endif
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)
arm: omap-common: add secure smc entry Add an interface for calling secure ROM APIs across a range of OMAP and OMAP compatible high-security (HS) device variants. While at it, also perform minor cleanup/alignment without any change in functionality. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-06-27 14:19:17 +00:00
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-common: add secure smc entry Add an interface for calling secure ROM APIs across a range of OMAP and OMAP compatible high-security (HS) device variants. While at it, also perform minor cleanup/alignment without any change in functionality. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-06-27 14:19:17 +00:00
mov r12, r0 @ Service
mov r0, r1 @ Argument
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
arm: omap-common: add secure smc entry Add an interface for calling secure ROM APIs across a range of OMAP and OMAP compatible high-security (HS) device variants. While at it, also perform minor cleanup/alignment without any change in functionality. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-06-27 14:19:17 +00:00
dsb
dmb
smc 0 @ SMC #0 to enter monitor mode
@ call ROM Code API for the service requested
pop {r4-r12, pc}
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
ENDPROC(omap_smc1)
arm: omap-common: add secure smc entry Add an interface for calling secure ROM APIs across a range of OMAP and OMAP compatible high-security (HS) device variants. While at it, also perform minor cleanup/alignment without any change in functionality. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-06-27 14:19:17 +00:00
ENTRY(omap_smc_sec)
push {r4-r12, lr} @ save registers - ROM code may pollute
@ our registers
mov r6, #0xFF @ Indicate new Task call
mov r12, #0x00 @ Secure Service ID in R12
dsb
dmb
smc 0 @ SMC #0 to enter monitor mode
b omap_smc_sec_end @ exit at end of the service execution
nop
@ In case of IRQ happening in Secure, then ARM will branch here.
@ At that moment, IRQ will be pending and ARM will jump to Non Secure
@ IRQ handler
mov r12, #0xFE
dsb
dmb
smc 0 @ SMC #0 to enter monitor mode
omap_smc_sec_end:
pop {r4-r12, pc}
ENDPROC(omap_smc_sec)
Reference in a new issue Copy permalink