Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-13 16:37:30 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arc/lib/start.S

114 lines
2.7 KiB
ArmAsm
Raw Normal View History

arc: add cpu files Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Francois Bedard <fbedard@synopsys.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Heiko Schocher <hs@denx.de>
2014-02-04 08:56:14 +00:00
/*
* Copyright (C) 2013-2014 Synopsys, Inc. All rights reserved.
*
* SPDX-License-Identifier: GPL-2.0+
*/
#include <asm-offsets.h>
#include <config.h>
arc: merge common start-up code between ARC and ARCv2 Even though ARCompact and ARCv2 are not binary compatible most of assembly instructions are used in both. With this change we'll get rid of duplicate code. Still IVTs are implemented differently so we're keeping them in separate files. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-02-19 15:40:58 +00:00
#include <linux/linkage.h>
arc: add cpu files Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Francois Bedard <fbedard@synopsys.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Heiko Schocher <hs@denx.de>
2014-02-04 08:56:14 +00:00
#include <asm/arcregs.h>
arc: merge common start-up code between ARC and ARCv2 Even though ARCompact and ARCv2 are not binary compatible most of assembly instructions are used in both. With this change we'll get rid of duplicate code. Still IVTs are implemented differently so we're keeping them in separate files. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-02-19 15:40:58 +00:00
ENTRY(_start)
arc: arcv1: Disable master/slave check ARCompact cores are not supposed to be used in SMP designs (this doesn't stop people from creation of heterogeneous chips, for an example keep reading) so there's no point in checking ARCNUM and halting somebody if we build for ARC700. Moreover on AXS101 board we have ARC770 in the ASIC together with other ARC cores and ARC770 happens to be the last node in JTAG chain with ARCNUM = 4. And existing check halts the one and only core we want keep running. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-04-11 15:24:25 +00:00
; ARCompact devices are not supposed to be SMP so master/slave check
; makes no sense.
#ifdef CONFIG_ISA_ARCV2
arcv2: Halt non-master cores Even though we expect only master core to execute U-Boot code let's make sure even if for some reason slave cores attempt to execute U-Boot in parallel with master they get halted very early. If platform wants it may kick-start slave cores before passing control to say Linux kernel or any other application that want to see all cores of SMP SoC up and running. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-03-30 14:50:45 +00:00
; Non-masters will be halted immediately, they might be kicked later
; by platform code right before passing control to the Linux kernel
; in bootm.c:boot_jump_linux().
lr r5, [identity]
lsr r5, r5, 8
bmsk r5, r5, 7
cmp r5, 0
mov.nz r0, r5
bz .Lmaster_proceed
flag 1
nop
nop
nop
.Lmaster_proceed:
arc: arcv1: Disable master/slave check ARCompact cores are not supposed to be used in SMP designs (this doesn't stop people from creation of heterogeneous chips, for an example keep reading) so there's no point in checking ARCNUM and halting somebody if we build for ARC700. Moreover on AXS101 board we have ARC770 in the ASIC together with other ARC cores and ARC770 happens to be the last node in JTAG chain with ARCNUM = 4. And existing check halts the one and only core we want keep running. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-04-11 15:24:25 +00:00
#endif
arcv2: Halt non-master cores Even though we expect only master core to execute U-Boot code let's make sure even if for some reason slave cores attempt to execute U-Boot in parallel with master they get halted very early. If platform wants it may kick-start slave cores before passing control to say Linux kernel or any other application that want to see all cores of SMP SoC up and running. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2017-03-30 14:50:45 +00:00
arc: introduce separate section for interrupt vector table Even though existing implementation works fine in preparation to submission of ARCv2 architecture we need this change. In case of ARCv2 interrupt vector table consists of just addresses of corresponding handlers. And if those addresses will be in .text section then assembler will encode them as everything in .text section as middle-endian and then on real execution CPU will read swapped addresses and will jump into the wild. Once introduced new section is situated so .text section remains the first which allows us to use common linker option for linking everything to a specified CONFIG_SYS_TEXT_BASE. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
2014-12-24 14:17:11 +00:00
/* Setup interrupt vector base that matches "__text_start" */
sr __ivt_start, [ARC_AUX_INTR_VEC_BASE]
arc: significant cache rework [1] Align cache management functions to those in Linux kernel. I.e.: a) Use the same functions for all cache ops (D$ Inv/Flush) b) Split cache ops in 3 sub-functions: "before", "lineloop" and "after". That way we may re-use "before" and "after" functions for region and full cache ops. [2] Implement full-functional L2 (SLC) management. Before SLC was simply disabled early on boot. It's also possible to enable or disable L2 cache from config utility. [3] Disable/enable corresponding caches early on boot. So if U-Boot is configured to use caches they will be used at all times (this is useful in partucular for speed-up of relocation). Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-05-18 13:56:26 +00:00
; Disable/enable I-cache according to configuration
lr r5, [ARC_BCR_IC_BUILD]
breq r5, 0, 1f ; I$ doesn't exist
lr r5, [ARC_AUX_IC_CTRL]
#ifndef CONFIG_SYS_ICACHE_OFF
bclr r5, r5, 0 ; 0 - Enable, 1 is Disable
#else
bset r5, r5, 0 ; I$ exists, but is not used
#endif
sr r5, [ARC_AUX_IC_CTRL]
1:
; Disable/enable D-cache according to configuration
lr r5, [ARC_BCR_DC_BUILD]
breq r5, 0, 1f ; D$ doesn't exist
lr r5, [ARC_AUX_DC_CTRL]
bclr r5, r5, 6 ; Invalidate (discard w/o wback)
#ifndef CONFIG_SYS_DCACHE_OFF
bclr r5, r5, 0 ; Enable (+Inv)
#else
bset r5, r5, 0 ; Disable (+Inv)
#endif
sr r5, [ARC_AUX_DC_CTRL]
arc: introduce separate section for interrupt vector table Even though existing implementation works fine in preparation to submission of ARCv2 architecture we need this change. In case of ARCv2 interrupt vector table consists of just addresses of corresponding handlers. And if those addresses will be in .text section then assembler will encode them as everything in .text section as middle-endian and then on real execution CPU will read swapped addresses and will jump into the wild. Once introduced new section is situated so .text section remains the first which allows us to use common linker option for linking everything to a specified CONFIG_SYS_TEXT_BASE. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
2014-12-24 14:17:11 +00:00
arc: significant cache rework [1] Align cache management functions to those in Linux kernel. I.e.: a) Use the same functions for all cache ops (D$ Inv/Flush) b) Split cache ops in 3 sub-functions: "before", "lineloop" and "after". That way we may re-use "before" and "after" functions for region and full cache ops. [2] Implement full-functional L2 (SLC) management. Before SLC was simply disabled early on boot. It's also possible to enable or disable L2 cache from config utility. [3] Disable/enable corresponding caches early on boot. So if U-Boot is configured to use caches they will be used at all times (this is useful in partucular for speed-up of relocation). Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-05-18 13:56:26 +00:00
1:
arc: add support for SLC (System Level Cache, AKA L2-cache) ARCv2 cores may have built-in SLC (System Level Cache, AKA L2-cache). This change adds functions required for controlling SLC: * slc_enable/disable * slc_flush/invalidate For now we just disable SLC to escape DMA coherency issues until either: * SLC flush/invalidate is supported in DMA APIin U-Boot * hardware DMA coherency is implemented (that might be board specific so probably we'll need to have a separate Kconfig option for controlling SLC explicitly) Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-03-30 10:36:04 +00:00
#ifdef CONFIG_ISA_ARCV2
arc: significant cache rework [1] Align cache management functions to those in Linux kernel. I.e.: a) Use the same functions for all cache ops (D$ Inv/Flush) b) Split cache ops in 3 sub-functions: "before", "lineloop" and "after". That way we may re-use "before" and "after" functions for region and full cache ops. [2] Implement full-functional L2 (SLC) management. Before SLC was simply disabled early on boot. It's also possible to enable or disable L2 cache from config utility. [3] Disable/enable corresponding caches early on boot. So if U-Boot is configured to use caches they will be used at all times (this is useful in partucular for speed-up of relocation). Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-05-18 13:56:26 +00:00
; Disable System-Level Cache (SLC)
lr r5, [ARC_BCR_SLC]
breq r5, 0, 1f ; SLC doesn't exist
lr r5, [ARC_AUX_SLC_CTRL]
bclr r5, r5, 6 ; Invalidate (discard w/o wback)
bclr r5, r5, 0 ; Enable (+Inv)
sr r5, [ARC_AUX_SLC_CTRL]
1:
arc: add support for SLC (System Level Cache, AKA L2-cache) ARCv2 cores may have built-in SLC (System Level Cache, AKA L2-cache). This change adds functions required for controlling SLC: * slc_enable/disable * slc_flush/invalidate For now we just disable SLC to escape DMA coherency issues until either: * SLC flush/invalidate is supported in DMA APIin U-Boot * hardware DMA coherency is implemented (that might be board specific so probably we'll need to have a separate Kconfig option for controlling SLC explicitly) Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-03-30 10:36:04 +00:00
#endif
arc: significant cache rework [1] Align cache management functions to those in Linux kernel. I.e.: a) Use the same functions for all cache ops (D$ Inv/Flush) b) Split cache ops in 3 sub-functions: "before", "lineloop" and "after". That way we may re-use "before" and "after" functions for region and full cache ops. [2] Implement full-functional L2 (SLC) management. Before SLC was simply disabled early on boot. It's also possible to enable or disable L2 cache from config utility. [3] Disable/enable corresponding caches early on boot. So if U-Boot is configured to use caches they will be used at all times (this is useful in partucular for speed-up of relocation). Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-05-18 13:56:26 +00:00
Fix board init code to respect the C runtime environment board_init_f_mem() alters the C runtime environment's stack it is actually already using. This is not a valid behaviour within a C runtime environment. Split board_init_f_mem into C functions which do not alter their own stack and always behave properly with respect to their C runtime environment. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Thomas Chou <thomas@wytron.com.tw>
2015-11-25 16:56:32 +00:00
/* Establish C runtime stack and frame */
arc: significant cache rework [1] Align cache management functions to those in Linux kernel. I.e.: a) Use the same functions for all cache ops (D$ Inv/Flush) b) Split cache ops in 3 sub-functions: "before", "lineloop" and "after". That way we may re-use "before" and "after" functions for region and full cache ops. [2] Implement full-functional L2 (SLC) management. Before SLC was simply disabled early on boot. It's also possible to enable or disable L2 cache from config utility. [3] Disable/enable corresponding caches early on boot. So if U-Boot is configured to use caches they will be used at all times (this is useful in partucular for speed-up of relocation). Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-05-18 13:56:26 +00:00
mov %sp, CONFIG_SYS_INIT_SP_ADDR
mov %fp, %sp
arc: introduce separate section for interrupt vector table Even though existing implementation works fine in preparation to submission of ARCv2 architecture we need this change. In case of ARCv2 interrupt vector table consists of just addresses of corresponding handlers. And if those addresses will be in .text section then assembler will encode them as everything in .text section as middle-endian and then on real execution CPU will read swapped addresses and will jump into the wild. Once introduced new section is situated so .text section remains the first which allows us to use common linker option for linking everything to a specified CONFIG_SYS_TEXT_BASE. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
2014-12-24 14:17:11 +00:00
Fix board init code to respect the C runtime environment board_init_f_mem() alters the C runtime environment's stack it is actually already using. This is not a valid behaviour within a C runtime environment. Split board_init_f_mem into C functions which do not alter their own stack and always behave properly with respect to their C runtime environment. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Thomas Chou <thomas@wytron.com.tw>
2015-11-25 16:56:32 +00:00
/* Allocate reserved area from current top of stack */
arc: get rid of CONFIG_SYS_GENERIC_GLOBAL_DATA As discussed on mailing list we're drifting away from CONFIG_SYS_GENERIC_GLOBAL_DATA in favour to use of board_init_f_mem() for global data. So do this for ARC architecture. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-02-25 15:10:18 +00:00
mov %r0, %sp
Fix board init code to respect the C runtime environment board_init_f_mem() alters the C runtime environment's stack it is actually already using. This is not a valid behaviour within a C runtime environment. Split board_init_f_mem into C functions which do not alter their own stack and always behave properly with respect to their C runtime environment. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Thomas Chou <thomas@wytron.com.tw>
2015-11-25 16:56:32 +00:00
bl board_init_f_alloc_reserve
/* Set stack below reserved area, adjust frame pointer accordingly */
arc: get rid of CONFIG_SYS_GENERIC_GLOBAL_DATA As discussed on mailing list we're drifting away from CONFIG_SYS_GENERIC_GLOBAL_DATA in favour to use of board_init_f_mem() for global data. So do this for ARC architecture. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-02-25 15:10:18 +00:00
mov %sp, %r0
mov %fp, %sp
Fix board init code to respect the C runtime environment board_init_f_mem() alters the C runtime environment's stack it is actually already using. This is not a valid behaviour within a C runtime environment. Split board_init_f_mem into C functions which do not alter their own stack and always behave properly with respect to their C runtime environment. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net> Acked-by: Thomas Chou <thomas@wytron.com.tw>
2015-11-25 16:56:32 +00:00
/* Initialize reserved area - note: r0 already contains address */
bl board_init_f_init_reserve
arc: introduce separate section for interrupt vector table Even though existing implementation works fine in preparation to submission of ARCv2 architecture we need this change. In case of ARCv2 interrupt vector table consists of just addresses of corresponding handlers. And if those addresses will be in .text section then assembler will encode them as everything in .text section as middle-endian and then on real execution CPU will read swapped addresses and will jump into the wild. Once introduced new section is situated so .text section remains the first which allows us to use common linker option for linking everything to a specified CONFIG_SYS_TEXT_BASE. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
2014-12-24 14:17:11 +00:00
/* Zero the one and only argument of "board_init_f" */
mov_s %r0, 0
j board_init_f
arc: merge common start-up code between ARC and ARCv2 Even though ARCompact and ARCv2 are not binary compatible most of assembly instructions are used in both. With this change we'll get rid of duplicate code. Still IVTs are implemented differently so we're keeping them in separate files. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-02-19 15:40:58 +00:00
ENDPROC(_start)
arc: introduce separate section for interrupt vector table Even though existing implementation works fine in preparation to submission of ARCv2 architecture we need this change. In case of ARCv2 interrupt vector table consists of just addresses of corresponding handlers. And if those addresses will be in .text section then assembler will encode them as everything in .text section as middle-endian and then on real execution CPU will read swapped addresses and will jump into the wild. Once introduced new section is situated so .text section remains the first which allows us to use common linker option for linking everything to a specified CONFIG_SYS_TEXT_BASE. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Igor Guryanov <guryanov@synopsys.com>
2014-12-24 14:17:11 +00:00
arc: add cpu files Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Francois Bedard <fbedard@synopsys.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Heiko Schocher <hs@denx.de>
2014-02-04 08:56:14 +00:00
/*
arc: clean-up init procedure Intention behind this work was elimination of as much assembly-written code as it is possible. In case of ARC we already have relocation fix-up implemented in C so why don't we use C for U-Boot copying, .bss zeroing etc. It turned out x86 uses pretty similar approach so we re-used parts of code in "board_f.c" initially implemented for x86. Now assembly usage during init is limited to stack- and frame-pointer setup before and after relocation. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Simon Glass <sjg@chromium.org>
2015-02-24 16:40:36 +00:00
* void board_init_f_r_trampoline(stack-pointer address)
arc: add cpu files Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Francois Bedard <fbedard@synopsys.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Heiko Schocher <hs@denx.de>
2014-02-04 08:56:14 +00:00
*
* This "function" does not return, instead it continues in RAM
* after relocating the monitor code.
*
arc: clean-up init procedure Intention behind this work was elimination of as much assembly-written code as it is possible. In case of ARC we already have relocation fix-up implemented in C so why don't we use C for U-Boot copying, .bss zeroing etc. It turned out x86 uses pretty similar approach so we re-used parts of code in "board_f.c" initially implemented for x86. Now assembly usage during init is limited to stack- and frame-pointer setup before and after relocation. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Simon Glass <sjg@chromium.org>
2015-02-24 16:40:36 +00:00
* r0 = new stack-pointer
arc: add cpu files Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Francois Bedard <fbedard@synopsys.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Heiko Schocher <hs@denx.de>
2014-02-04 08:56:14 +00:00
*/
arc: clean-up init procedure Intention behind this work was elimination of as much assembly-written code as it is possible. In case of ARC we already have relocation fix-up implemented in C so why don't we use C for U-Boot copying, .bss zeroing etc. It turned out x86 uses pretty similar approach so we re-used parts of code in "board_f.c" initially implemented for x86. Now assembly usage during init is limited to stack- and frame-pointer setup before and after relocation. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Simon Glass <sjg@chromium.org>
2015-02-24 16:40:36 +00:00
ENTRY(board_init_f_r_trampoline)
/* Set up the stack- and frame-pointers */
mov %sp, %r0
arc: add cpu files Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Francois Bedard <fbedard@synopsys.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Heiko Schocher <hs@denx.de>
2014-02-04 08:56:14 +00:00
mov %fp, %sp
arc: clean-up init procedure Intention behind this work was elimination of as much assembly-written code as it is possible. In case of ARC we already have relocation fix-up implemented in C so why don't we use C for U-Boot copying, .bss zeroing etc. It turned out x86 uses pretty similar approach so we re-used parts of code in "board_f.c" initially implemented for x86. Now assembly usage during init is limited to stack- and frame-pointer setup before and after relocation. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Simon Glass <sjg@chromium.org>
2015-02-24 16:40:36 +00:00
/* Update position of intterupt vector table */
lr %r0, [ARC_AUX_INTR_VEC_BASE]
ld %r1, [%r25, GD_RELOC_OFF]
add %r0, %r0, %r1
sr %r0, [ARC_AUX_INTR_VEC_BASE]
arc: add cpu files Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Francois Bedard <fbedard@synopsys.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Heiko Schocher <hs@denx.de>
2014-02-04 08:56:14 +00:00
arc: clean-up init procedure Intention behind this work was elimination of as much assembly-written code as it is possible. In case of ARC we already have relocation fix-up implemented in C so why don't we use C for U-Boot copying, .bss zeroing etc. It turned out x86 uses pretty similar approach so we re-used parts of code in "board_f.c" initially implemented for x86. Now assembly usage during init is limited to stack- and frame-pointer setup before and after relocation. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Simon Glass <sjg@chromium.org>
2015-02-24 16:40:36 +00:00
/* Re-enter U-Boot by calling board_init_f_r */
j board_init_f_r
ENDPROC(board_init_f_r_trampoline)
Reference in a new issue Copy permalink