Re: [U-Boot] [PATCH v2 0/9] PSCI v0.2 framework for ARMv8
Hi Albert, -Original Message- From: Arnab Basu [mailto:arnab_b...@rocketmail.com] Apologies for the long delay, this is v2 of the series of patches that creates a generic PSCI v0.2 framework for ARMv8. The first 3 patches refactor existing code so that ARMv7 PSCI, ARMv8 spin-table and ARMv8 PSCI can coexist. The 4th patch modifies the spin table implementation for the ARMv8 foundation model to create per cpu release addresses The next 5 patches create a generic framework for PSCI v0.2 in ARMv8. The implementation is modelled on the pre-existing PSCI v0.1 support in ARMv7. PSCI support patches for the ARMv8 Foundation model that implement the mandatory PSCI functions and enable PCSI will follow very soon. It's been long since Arnab posted this series. This works fine for me on ARMv8 foundation model and also with minor modifications on Freescale's LS2085A platform. Can this be merged to the u-boot tree or are we waiting for a v3 to be spun-out by Arnab. Arnab Basu (9): ARM: PSCI: Update psci.h for psci v0.2 ARM: PSCI: Alow arch specific DT patching ARMv8/fsl-lsch3: Refactor spin-table code vexpress_aemv8a: Add spin table handling with per cpu release addresses ARMv8: PSCI: Add linker section to hold PSCI code ARMv8: PCSI: Add generic ARMv8 PSCI code ARMv8: PSCI: Fixup the device tree for PSCI v0.2 ARMv8: PSCI: Setup ARMv8 PSCI ARMv8: PSCI: Enable SMC arch/arm/config.mk | 2 +- arch/arm/cpu/armv7/virt-dt.c | 7 +- arch/arm/cpu/armv8/Makefile| 4 +- arch/arm/cpu/armv8/cpu-dt.c| 189 + arch/arm/cpu/armv8/cpu.c | 136 ++ arch/arm/cpu/armv8/fsl-lsch3/fdt.c | 48 -- arch/arm/cpu/armv8/psci.S | 168 + arch/arm/cpu/armv8/start.S | 141 --- arch/arm/cpu/armv8/u-boot.lds | 30 ++ arch/arm/include/asm/armv8/esr.h | 12 +++ arch/arm/include/asm/armv8/mp.h| 36 +++ arch/arm/include/asm/config.h | 1 + arch/arm/include/asm/macro.h | 5 + arch/arm/include/asm/psci.h| 42 - arch/arm/include/asm/system.h | 7 ++ arch/arm/lib/bootm-fdt.c | 11 ++- arch/arm/lib/bootm.c | 3 + include/configs/vexpress_aemv8a.h | 2 + 18 files changed, 772 insertions(+), 72 deletions(-) create mode 100644 arch/arm/cpu/armv8/cpu-dt.c create mode 100644 arch/arm/cpu/armv8/psci.S create mode 100644 arch/arm/include/asm/armv8/esr.h create mode 100644 arch/arm/include/asm/armv8/mp.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Vexpress64: Fix the compiling error when CONFIG_ARMV8_MULTIENTRY defined
-Original Message- From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of FengHua Sent: Wednesday, March 11, 2015 6:38 PM To: Linus Walleij Cc: U-Boot Mailing List Subject: Re: [U-Boot] [PATCH] Vexpress64: Fix the compiling error when CONFIG_ARMV8_MULTIENTRY defined -Original Messages- From: Linus Walleij linus.wall...@linaro.org Sent Time: 2015-03-10 18:08:03 (Tuesday) To: David Feng feng...@phytium.com.cn Cc: U-Boot Mailing List u-boot@lists.denx.de, Tom Rini tr...@ti.com, Albert ARIBAUD albert.u.b...@aribaud.net Subject: Re: [PATCH] Vexpress64: Fix the compiling error when CONFIG_ARMV8_MULTIENTRY defined On Tue, Mar 10, 2015 at 3:08 AM, feng...@phytium.com.cn wrote: From: David Feng feng...@phytium.com.cn CPU_RELEASE_ADDR should be defined when CONFIG_ARMV8_MULTIENTRY is used. Signed-off-by: David Feng feng...@phytium.com.cn As asked earlier: how can I test this with FVP or the base model? I usually use Foundation Model. I'm very interested in doing this as I guess it involves starting U-Boot at EL3 on bare metal and I really want to try this. +/* SMP Spin Table Definitions */ +#ifdef CONFIG_BASE_FVP +#define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f0) +#else +#define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0) +#endif Where are these address defines coming from? It's just hard coded and should be the same value with that in DTS. Do these spin tables exist in a standard ARM FVP or base model? I get the impression that a secondary operating system is being booted on the secondary CPU at one of these addresses, but why is it running at these addresses specifically, and is that something coming with these simulators, or is it some image that is loaded on the side, that the community does not have access to? PSCI is not implemented in uboot-armv8. If booting u-boot on bare-metal only spin table can be used. All we do is describing booting method(spin table) and cpu release address in DTS. Linux kernel get cpu release address from DTS also. Arnab's patches enable PSCI for amrv8 on u-boot: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/207882 We have tested the same on ARMv8 foundation model as well. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Errata/ARM57: Add basic constructs to handle and apply A57 specific erratas
Hi Mark, -Original Message- From: Mark Rutland [mailto:mark.rutl...@arm.com] Sent: Friday, January 16, 2015 12:35 AM To: Sharma Bhupesh-B45370 Cc: Sun York-R58495; u-boot@lists.denx.de; albert.u.b...@aribaud.net; Wood Scott-B07421; Yoder Stuart-B08248 Subject: Re: [U-Boot] [PATCH v2 1/2] Errata/ARM57: Add basic constructs to handle and apply A57 specific erratas On Thu, Jan 15, 2015 at 06:10:57AM +, bhupesh.sha...@freescale.com wrote: Hi York, -Original Message- From: Sun York-R58495 Sent: Wednesday, January 14, 2015 9:44 PM On 01/14/2015 05:46 AM, Bhupesh Sharma wrote: This patch adds basic constructs in the ARMv8 u-boot code to handle and apply Cortex-A57 specific erratas. As and example, the framework showcases how erratas 833069, 826974 and 828024 can be handled and applied. Later on this framework can be extended to include other erratas. Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com --- Changes from v1: - Addressed York's comment about x29 usage and calling the core errata fxup function before the lowlevel_init function is called. arch/arm/cpu/armv8/start.S | 51 ++ arch/arm/include/asm/macro.h | 20 + 2 files changed, 71 insertions(+) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 4b11aa4..df532f9 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -67,6 +67,9 @@ reset: msr cpacr_el1, x0 /* Enable FP/SIMD */ 0: + /* Apply ARM core specific erratas */ + bl apply_core_errata + /* * Cache/BPB/TLB Invalidate * i-cache is invalidated before enabled in icache_enable() @@ - 97,6 +100,54 @@ master_cpu: /* ---*/ +WEAK(apply_core_errata) + + /* For now, we support Cortex-A57 specific errata only */ + + /* Check if we are running on a Cortex-A57 core */ + branch_if_a57_core x0, 1f + b 2f +1: + bl apply_a57_core_errata + +2: + ret +ENDPROC(apply_core_errata) + Bhupesh, Have you tested the new code? I don't think it handles LR correctly. Your code will be stuck. Yes, I have tested this on both the LS2085A simulator and emulator platforms. On emulator I tried u-boot boot-to-prompt and on simulator I tried linux boot-to-prompt. Both seem to be working fine. Has the apply_a57_core_errata function definitely been called in your tests? If so the lr should point immediately after it (i.e. at the ret), and so the ret should branch to itself, repeatedly. Thanks for the pointers. Let me connect a debugger and see the step-by-step flow through the apply_a57_core_errata. I will revert with the findings soon. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Errata/ARM57: Add basic constructs to handle and apply A57 specific erratas
Hi York, -Original Message- From: Sun York-R58495 Sent: Wednesday, January 14, 2015 9:44 PM On 01/14/2015 05:46 AM, Bhupesh Sharma wrote: This patch adds basic constructs in the ARMv8 u-boot code to handle and apply Cortex-A57 specific erratas. As and example, the framework showcases how erratas 833069, 826974 and 828024 can be handled and applied. Later on this framework can be extended to include other erratas. Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com --- Changes from v1: - Addressed York's comment about x29 usage and calling the core errata fxup function before the lowlevel_init function is called. arch/arm/cpu/armv8/start.S | 51 ++ arch/arm/include/asm/macro.h | 20 + 2 files changed, 71 insertions(+) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 4b11aa4..df532f9 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -67,6 +67,9 @@ reset: msr cpacr_el1, x0 /* Enable FP/SIMD */ 0: + /* Apply ARM core specific erratas */ + bl apply_core_errata + /* * Cache/BPB/TLB Invalidate * i-cache is invalidated before enabled in icache_enable() @@ - 97,6 +100,54 @@ master_cpu: /* ---*/ +WEAK(apply_core_errata) + + /* For now, we support Cortex-A57 specific errata only */ + + /* Check if we are running on a Cortex-A57 core */ + branch_if_a57_core x0, 1f + b 2f +1: + bl apply_a57_core_errata + +2: + ret +ENDPROC(apply_core_errata) + Bhupesh, Have you tested the new code? I don't think it handles LR correctly. Your code will be stuck. Yes, I have tested this on both the LS2085A simulator and emulator platforms. On emulator I tried u-boot boot-to-prompt and on simulator I tried linux boot-to-prompt. Both seem to be working fine. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Errata/ARM57: Add basic constructs to handle and apply A57 specific erratas
Hi York, -Original Message- From: Sun York-R58495 Sent: Tuesday, January 13, 2015 10:01 PM On 01/13/2015 05:19 AM, Bhupesh Sharma wrote: This patch adds basic constructs in the ARMv8 u-boot code to handle and apply Cortex-A57 specific erratas. As and example, the framework showcases how erratas 826974 and 828024 can be handled and applied. Later on this framework can be extended to include other erratas. Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com --- arch/arm/cpu/armv8/start.S | 47 ++ arch/arm/include/asm/macro.h | 20 ++ 2 files changed, 67 insertions(+) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 4b11aa4..d5bcf12 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -100,6 +100,8 @@ master_cpu: WEAK(lowlevel_init) mov x29, lr /* Save LR */ + bl apply_core_errata + #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) branch_if_slave x0, 1f ldr x0, =GICD_BASE @@ -155,6 +157,51 @@ ENDPROC(smp_kick_all_cpus) /* ---*/ +WEAK(apply_core_errata) + mov x29, lr /* Save LR */ + + /* For now, we support Cortex-A57 specific errata only */ + + /* Check if we are running on a Cortex-A57 core */ + branch_if_a57_core x0, 1f + b 2f +1: + bl apply_a57_core_errata + +2: + mov lr, x29 /* Restore LR */ + ret +ENDPROC(apply_core_errata) + +/*--- +*/ + +WEAK(apply_a57_core_errata) + mov x29, lr /* Save LR */ + +#ifdef CONFIG_ARM_ERRATA_828024 + mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */ + /* Disable non-allocate hint of w-b-n-a memory type */ + mov x0, #0x1 49 + /* Disable write streaming no L1-allocate threshold */ + mov x0, #0x3 25 + /* Disable write streaming no-allocate threshold */ + mov x0, #0x3 27 + msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */ +#endif + +#ifdef CONFIG_ARM_ERRATA_826974 + mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */ + /* Disable speculative load execution ahead of a DMB */ + mov x0, #0x1 59 + msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */ +#endif + + mov lr, x29 /* Restore LR */ + ret +ENDPROC(apply_a57_core_errata) + Bhupesh, Have you tested your patch on simulator/emulator? It seems you use x29 recursively. x29 holds the return address for function lowlevel_init. You use it multiple times, so the program will not run correctly. Beside, you implement this framework in lowlevel_init function, which is a weak function. I guess you may have tested for LS2085A simulator, but we have a different lowlevel_init function implemented. You may want to add a new function call before bl lowlevel_init. Thanks for catching this. Seems like I unintentionally sent out the wrong version of the patches. I will send the correct set of patches soon. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: PSCI 0.1 vs 0.2
Hi, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jan Kiszka Sent: Monday, November 10, 2014 6:56 PM To: Marc Zyngier Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] ARM: PSCI 0.1 vs 0.2 On 2014-11-10 14:08, Marc Zyngier wrote: On 10/11/14 12:51, Jan Kiszka wrote: Hi Marc, what is the motivation to expose a PSCI 0.1 interface in U-boot, instead of 0.2? Support for preexisting users of 0.1? The kernel seems to be happy with both, and I'm now wondering if we should actually add the legacy version to Jailhouse as well (I hope we can avoid this). The initial rational was simple: at the time this code was written, the 0.2 spec still in review, and nobody was implementing it. Supporting 0.1 was the only viable use-case. Still studying the logic: Is it possible to provide both interfaces, and would it make sense? Supporting both is very easy. Just output the 0.2 function numbers that actually make sense for 0.1 and have both compatible strings. Ah, cool - parameters and return values of, say, CPU_ON/OFF are compatible across both versions? Jan -- We did send out some ARMv8 PSCI v0.2 u-boot patches, which can be seen here: http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/194210 Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 3/5] armv8/fsl-lsch3: Release secondary cores from boot hold off with Boot Page
Hi Mark,
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
On Behalf Of York Sun
Sent: Friday, August 22, 2014 12:03 AM
To: Mark Rutland; Basu Arnab-B45036
Cc: tr...@ti.com; u-boot@lists.denx.de; Wood Scott-B07421
Subject: Re: [U-Boot] [Patch v2 3/5] armv8/fsl-lsch3: Release secondary
cores from boot hold off with Boot Page
On 08/21/2014 06:47 AM, Mark Rutland wrote:
Hi York,
I have mostly minor comments this time; this is looking pretty good.
On Tue, Aug 19, 2014 at 09:28:00PM +0100, York Sun wrote:
Secondary cores need to be released from holdoff by boot release
registers. With GPP bootrom, they can boot from main memory directly.
Individual spin table is used for each core. If a single release
address is needed, defining macro CONFIG_FSL_SMP_RELEASE_ALL will use
the CPU_RELEASE_ADDR. Spin table and the boot page is reserved in
device tree so OS won't overwrite.
Signed-off-by: York Sun york...@freescale.com
Signed-off-by: Arnab Basu arnab.b...@freescale.com
---
v2: Removed copying boot page. Use u-boot image as is in memory.
Added dealing with different size of addr_cell in device tree.
Added dealing with big- and little-endian.
Added flushing spin table after cpu_release().
arch/arm/cpu/armv8/fsl-lsch3/Makefile |2 +
arch/arm/cpu/armv8/fsl-lsch3/cpu.c| 13 ++
arch/arm/cpu/armv8/fsl-lsch3/cpu.h|1 +
arch/arm/cpu/armv8/fsl-lsch3/fdt.c| 56 +++
arch/arm/cpu/armv8/fsl-lsch3/lowlevel.S | 128 -
--
arch/arm/cpu/armv8/fsl-lsch3/mp.c | 172
+
arch/arm/cpu/armv8/fsl-lsch3/mp.h | 36 +
arch/arm/cpu/armv8/transition.S | 63 +---
arch/arm/include/asm/arch-fsl-lsch3/config.h |3 +-
arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h | 35 +
arch/arm/include/asm/macro.h | 92 +++
arch/arm/lib/gic_64.S | 10 +-
common/board_f.c |2 +-
13 files changed, 525 insertions(+), 88 deletions(-) create mode
100644 arch/arm/cpu/armv8/fsl-lsch3/fdt.c
create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/mp.c create mode
100644 arch/arm/cpu/armv8/fsl-lsch3/mp.h
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/Makefile
b/arch/arm/cpu/armv8/fsl-lsch3/Makefile
index 9249537..f920eeb 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/Makefile
+++ b/arch/arm/cpu/armv8/fsl-lsch3/Makefile
@@ -7,3 +7,5 @@
obj-y += cpu.o
obj-y += lowlevel.o
obj-y += speed.o
+obj-$(CONFIG_MP) += mp.o
+obj-$(CONFIG_OF_LIBFDT) += fdt.o
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
index c129d03..47b947f 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/cpu.c
@@ -11,6 +11,7 @@
#include asm/io.h
#include asm/arch-fsl-lsch3/immap_lsch3.h
#include cpu.h
+#include mp.h
#include speed.h
#include fsl_mc.h
@@ -434,3 +435,15 @@ int cpu_eth_init(bd_t *bis) #endif
return error;
}
+
+
+int arch_early_init_r(void)
+{
+ int rv;
+ rv = fsl_lsch3_wake_seconday_cores();
+
+ if (rv)
+ printf(Did not wake secondary cores\n);
+
+ return 0;
+}
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/cpu.h
b/arch/arm/cpu/armv8/fsl-lsch3/cpu.h
index 28544d7..2e3312b 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/cpu.h
+++ b/arch/arm/cpu/armv8/fsl-lsch3/cpu.h
@@ -5,3 +5,4 @@
*/
int fsl_qoriq_core_to_cluster(unsigned int core);
+u32 cpu_mask(void);
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
b/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
new file mode 100644
index 000..2dbcdcb
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include libfdt.h
+#include fdt_support.h
+#include mp.h
+
+#ifdef CONFIG_MP
+void ft_fixup_cpu(void *blob)
+{
+ int off;
+ __maybe_unused u64 spin_tbl_addr = (u64)get_spin_tbl_addr();
+ fdt32_t *reg;
+ int addr_cells;
+ u64 val;
+ size_t *boot_code_size = (__secondary_boot_code_size);
+
+ off = fdt_node_offset_by_prop_value(blob, -1, device_type,
+ cpus, 4);
I didn't think /cpus had device_type = cpus. I can't see any
instances in any DTs I have to hand. Can we not find /cpus by path?
I will let Arnab to comment on this. He is coordinating with Linux device
tree.
Since I contribute to the DTS for FSL ARMv8 SoC, here is my rationale behind
the same.
I have used the standard ARM cpu device-tree binding documentation as a
reference (see [1])
which defined the device_type which
Re: [U-Boot] [PATCH v3] arm: Add support for semihosting for armv8 fastmodel targets.
Hi Darwin, -Original Message- From: Darwin Rambo [mailto:dra...@broadcom.com] Sent: Tuesday, March 25, 2014 12:46 AM To: u-boot@lists.denx.de Cc: Darwin Rambo; Albert Aribaud; Tom Rini; feng...@phytium.com.cn; Sharma Bhupesh-B45370 Subject: [PATCH v3] arm: Add support for semihosting for armv8 fastmodel targets. The reason for this change is to be able to use the ARM Trusted Firmware (ATF) to load the various ATF images, plus u-boot, which can then load the kernel/ramdisk/dtb with calls to an external host from a standard fastmodel armv8 board file using semihosting, and then launch the kernel without a bootwrapper. This gives us a more realistic boot sequence. There are two main ARM virtual Fixed Virtual Platform (FVP) models, Versatile Express (VE) FVP and BASE FVP (See http://www.arm.com/products/tools/models/fast-models/foundation- model.php) The initial vexpress64 u-boot board created here runs on the VE virtual platform using the license-free Foundation_v8 simulator. Fortunately, the Foundation_v8 simulator also supports the BASE_FVP model which companies can purchase licenses for and contain much more functionality. So we can, in u-boot, run either model by either using the VE FVP (default), or turning on CONFIG_BASE_FVP for the more full featured model. Rather than create a new armv8 board similar to armltd/vexpress64, add semihosting calls to the existing one, enabled with CONFIG_SEMIHOSTING and CONFIG_BASE_FVP both set. Also reuse the existing board config file vexpress_aemv8a.h but differentiate the two models by the presence or absence of CONFIG_BASE_FVP. This change is tested and works on both the Foundation and Base fastmodel simulators. Support for armv7 in fastmodel is less useful due to the wide range of available silicon and the lack of a free armv7 fastmodel, so this change contains an untested armv7 placeholder for the service trap opcode. The level of semihosting support is minimal, restricted to just what it takes to load images to memory. If more semihosting functionality is required, such as file seek, outputting strings, reading characters, etc, then it can be easily added later. Sorry for the late reply. We are using ARMv8 foundation model (the free version) to launch u-boot via the ARM Trusted Firmware (ATF). We are using a older u-boot version and cannot see the ATF launching the u-boot.bin. Please find the details of the ARMv8 foundation model command line and ATF, u-boot commit logs below (Host machine is a ubuntu-64 bit). ARMv8 foundation model Command Line used - $ ./Foundation_v8 --cores=1 --no-secure-memory --visualization --gicv3 --data=bl1.bin@0x --data=fip.bin@0x8000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Booting trusted firmware boot loader stage 1 Built : 12:58:21, May 22 2014 ERROR: Firmware Image Package header check failed. Booting trusted firmware boot loader stage 2 BL2 Built : 12:58:22, May 22 2014 ERROR: Firmware Image Package header check failed. ERROR: Firmware Image Package header check failed. Booting trusted firmware boot loader stage 3 BL31 Built : 12:58:23, May 22 2014 ATF latest commit - commit ca823d2c881d9d8c7db364de7e362d2e75ad55df Author: Achin Gupta achin.gu...@arm.com Date: Sun Feb 2 13:04:00 2014 + Increase coherent stack sizes This patch increases coherent stack size for both debug and release builds in order to accommodate stack-heavy printf() and extended EL3 functionality Change-Id: I30ef30530a01517a97e63d703873374828c09f20 u-boot commit - commit 22a240c32c1340183fce12867ae5f8736b92a638 Author: Alexey Brodkin alexey.brod...@synopsys.com Date: Fri Dec 13 10:35:11 2013 +0400 serial/serial_arc - add driver for ARC UART Driver for non-standard on-chip UART, instantiated in the ARC (Synopsys) FPGA Boards such as ARCAngel4/ML50x Signed-off-by: Alexey Brodkin abrod...@synopsys.com Regards, Bhupesh Signed-off-by: Darwin Rambo dra...@broadcom.com --- Changes in v3: - minor format fixup in board file Changes in v2: - use kernel_addr_r, fdt_addr_r, initrd_addr_r convention. - Use env variables for kernel/fdt/initrd file names. - Add CONFIG_BASE_FVP to differentiate VE and BASE FVP models. - CONFIG_SEMIHOSTING only refers to bringing in semihosting code now. - Remove unnecessary CONFIG_SYS_BAUDRATE_TABLE, CONFIG_SYS_PROMPT_HUSH_PS2 - Remove vexpress_aemv8a_semi.h and replace with CONFIG_BASE_FVP - Update boards.cfg with option SEMIHOSTING and BASE_FVP - Add doc/README.semihosting Changes in v1: - Initial code - Remove empty timer_init() function. arch/arm/include/asm/semihosting.h | 21 +++ arch/arm/lib/Makefile|1 + arch/arm/lib/semihosting.c | 235 ++ board/armltd/vexpress64/vexpress64.c | 101 ++-
Re: [U-Boot] how to get u-boot code with arm64: core support
Hi Inder, Could you please check the output of: $ echo $ARCH if it set to some values, unset it using: $ unset ARCH Regards, Bhupesh From: tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: Wednesday, February 12, 2014 1:44 PM To: inderpal.si...@linaro.org Cc: Sharma Bhupesh-B45370; dra...@broadcom.com; u-boot@lists.denx.de; tr...@ti.com Subject: Re: [U-Boot] how to get u-boot code with arm64: core support Hi, Inder: Could it be a toolchain issue? I used the linaro toochain gcc-linaro-aarch64-linux-gnu-4.8-2014.01_linux.tar.xzhttp://releases.linaro.org/latest/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.8-2014.01_linux.tar.xz at [1]. Maybe I use gcc-linaro-aarch64-linux-gnu-4.8-2013.07-1_linux.tar Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to get u-boot code with arm64: core support
Hi Tiger, -Original Message- From: tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: Thursday, January 23, 2014 1:25 PM To: Sharma Bhupesh-B45370; dra...@broadcom.com; u-boot@lists.denx.de Cc: tr...@ti.com Subject: Re: [U-Boot] how to get u-boot code with arm64: core support Hi, bhupesh and drambo: I think current uboot ARMv8's start.S could handle EL2/EL1 case. I have tested it on FVP model, let arm trusted firmware boot u- boot.bin. It seemed ok. The command I used is: ./Foundation_v8 --cores=4 --no-secure-memory --no-gicv3 --data=./bl1.bin@0x0 --nsdata=./u-boot.bin@0x0800 I changed CONFIG_SYS_TEXT_BASE = 0x0800 (because ARM trusted firmware will search non-secure firmware entry point at this addr). I tried the ATF method you mentioned above which the u-boot compiled for ARMv8 foundation model, but, I ran into some issues. Can you please elaborate the steps you use to compile the ATF for ARMv8 foundation model and the command line you use to launch the ATF BL1 and u-boot on the model. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to get u-boot code with arm64: core support
Hi Tiger, -Original Message- From: tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: Wednesday, February 12, 2014 7:38 AM To: Sharma Bhupesh-B45370; dra...@broadcom.com; u-boot@lists.denx.de Cc: tr...@ti.com Subject: Re: [U-Boot] how to get u-boot code with arm64: core support Hi, Bhupesh: I described my steps: 1. Compiled ATF Export CROSS_COMPILE=/home/lion/ gcc-linaro-aarch64/bin/aarch64-linux-gnu- make DEBUG=1 V=1 make DEBUG=1 PLAT=fvp all dump Note: I used linaro released aarch64 compiler, not official gcc 4.7 2. Compiled Uboot (1) revised CONFIG_SYS_TEXT_BASE in vexpress_aemv8a.h CONFIG_SYS_TEXT_BASE = 0x0800 (2) compiled Uboot export ARCH=aarch64 export CROSS_COMPILE=/home/lion/gcc-linaro-aarch64/bin/aarch64-linux-gnu- make vexpress_aemv8a Note: Please use u-boot.bin(about 207 KB) in below step 3. 3. Run ATF with FVP base model ./Foundation_v8 --cores=2 --no-gicv3 --data=./bl1.bin@0x0 --data=./u-boot.bin@0x0800 Note: I use Foundation_v8, a free armv8 foundation model, not a commercial licensed model. Thanks for the steps. Actually I was following the same but I get an error Failed to load boot loader stage 2 (BL2) firmware, although I have placed the 'bl2.bin' at the same directory level as the ARMv8 foundation model (v2 - Release 52rel06). The complete boot log is: Escape character is '^]'. Booting trusted firmware boot loader stage 1 Built : 16:09:23, Feb 11 2014 ERROR: Cannot access 'bl2.bin' file (-1). Failed to load boot loader stage 2 (BL2) firmware. Did you see some similar issues at your end? Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Commit 3865ceb7 breaks vexpress_aemv8a build with warnings
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Thursday, January 30, 2014 8:06 PM
To: U-Boot
Cc: Sharma Bhupesh-B45370; Tom Rini
Subject: Commit 3865ceb7 breaks vexpress_aemv8a build with warnings
Hello,
I have just noticed that vexpress_aemv8a seems broken with v2014.01,
using gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9).
The symptom is a lot of warnings like
smc9_eeprom.c: In function 'dump_reg':
/home/albert/src/u-boot-arm/include/../drivers/net/smc9.h:261:28:
warning: cast to pointer from integer of different size [-Wint-to-
pointer-cast] #define SMC_outw(a,d,r) (*((volatile word
*)((a)-iobase+(r))) = d)
^ /home/albert/src/u-boot-arm/include/../drivers/net/smc9.h:747:33:
note: in expansion of macro 'SMC_outw' #define SMC_SELECT_BANK(a,x) {
SMC_outw((a), (x), BANK_SELECT ); }
A rough search shows that the issue originates in commit 3865ceb7
(vexpress/armv8: Fix incorrect ethernet controller) submitted by
Bhupesh Sharma and committed by Tom Rini, both Cc:ed.
Bupesh, can you investigate?
I did post a reply to a mail on similar lines before:
http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/178502
I did not get much time to look into the same.
Let me try the same tomorrow.
Regards,
Bhupesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to get u-boot code with arm64: core support
-Original Message- From: Darwin Rambo [mailto:dra...@broadcom.com] Sent: Thursday, January 23, 2014 10:35 PM To: Detlev Zundel; Sharma Bhupesh-B45370 Cc: 'u-boot@lists.denx.de'; 'Tom Rini' Subject: Re: [U-Boot] how to get u-boot code with arm64: core support On 14-01-23 07:58 AM, Detlev Zundel wrote: Hi Bhupesh, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of drambo Sent: Thursday, January 23, 2014 12:32 AM To: u-boot@lists.denx.de Subject: Re: [U-Boot] how to get u-boot code with arm64: core support Hi Bhupesh, U-boot doesn't have ARM trusted firmware support as of now. U-boot for ARMv8 starts in EL3, whereas UEFI starts in EL2 as trusted firmware itself is working in EL3. Since the ATF software doesn't really care whether it is loading uefi or u-boot and since it wants to load non-secure images as EL2 or EL1 (https://github.com/ARM-software/arm-trusted- firmware/blob/master/docs/user-guide.md See section Normal World Software Execution), why would we want to assume u-boot starts in EL3 mode by default? If we want to support EL3 execution for convenience to those that don't have ATF setup, that might make sense, but then shouldn't initial EL3 execution and subsequent switching levels be debug CONFIG options? Thanks. In the past I remember using u-boot as the bare-metal s/w to debug a Silicon without any BootROM/firmware code running before the same on ARM 32-bit architectures. Many of our customers (in the embedded market) use U-Boot in such a way very successfully. armv8 and ATF bring in a new security model and with that, secure monitor/dispatch, secure OS support and secure power control. It may not be good to assume that we can work in a historical way here. I am not against ATF :) . Like I mentioned below, I personally favor using ATF to boot both u-boot and UEFI, but I have some reservations on the same. More on that below . The ATF is presently tested only for UEFI and UEFI comes up in EL2 while the ATF itself is running in EL3. I don't know what would be the popular vote on this, but personally I feel that the u-boot for ARMv8 should also be launched by the ATF (similar to UEFI) and should start execution in EL2 so that it can launch a hypervisor (running in EL2) or Linux (running in EL1). But this might hurt the popular premise that u-boot can be used as a bare-metal s/w to debug a silicon without additional firmware components. Perhaps u-boot experts can guide us on this ! I have to admit that I'm only reading up on the complexities of the security model of aarch64, but my gut response (cf. [1] is that real security stems from few code rather than adding layer over layer. With this in mind, I'd really like to see that U-Boot with its well known and tested code base can still be the root of trust in an embedded product (i.e. EL3 as far as I understand). EL3 is the highest level of trust, and the new armv8 security model treats uefi/u-boot as non-secure firmware. The ATF trusted firmware needs to run, initialize secure hardware, load trusted images, and ultimately launch the non-secure OS loader (uefi or u-boot). As such, I think that running uefi or u-boot at EL3 violates the current arm security model i.e. u-boot cannot be the root of trust in this architecture since it is non-secure. Having non-secure firmware run at the same level as the secure dispatcher and secure monitor will fail any secure audit in my opinion. However, if we set up u-boot so that it can wake up at any security level and migrate to non-secure EL1, that might be a nice compromise. But having specific EL3 startup assumptions and code that is always present in u-boot seems like the wrong approach to me. At the very least, we should wrap the EL3 code in a CONFIG option since this is not the planned entry state for final deployment. ... You seem to miss a critical detail here, security extensions were also part of the ARMv7 architecture (although optional) and were controlled by the ID_PFR1, Processor Feature Register 1, Security Extensions, bits[7:4]: Permitted values are: 0b Not implemented. 0b0001 Security Extensions implemented. So, there was a likelihood that some ARMv7 SoCs still didn't have security extensions enabled - I have used one and hence can vouch that a u-boot running as bare-metal s/w helped me in early SoC bringup. In ARMv8, we still have the AArch32 state which still has a ID_PFR1_EL1 register, with the same definition for security extension bits. I agree that for AArch64 state, it makes sense that the s/w to be launched at reset (usually a BootROM or ATF) executes in a Secure aware (i.e. is EL3 aware) and then provides control to a bootloader running in EL2 world (the case presently with UEFI). But that binds the bootloader, in this case u-boot, with an ATF being
Re: [U-Boot] how to get u-boot code with arm64: core support
Hi Darwin, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of drambo Sent: Thursday, January 23, 2014 12:32 AM To: u-boot@lists.denx.de Subject: Re: [U-Boot] how to get u-boot code with arm64: core support Hi Bhupesh, U-boot doesn't have ARM trusted firmware support as of now. U-boot for ARMv8 starts in EL3, whereas UEFI starts in EL2 as trusted firmware itself is working in EL3. Since the ATF software doesn't really care whether it is loading uefi or u-boot and since it wants to load non-secure images as EL2 or EL1 (https://github.com/ARM-software/arm-trusted- firmware/blob/master/docs/user-guide.md See section Normal World Software Execution), why would we want to assume u-boot starts in EL3 mode by default? If we want to support EL3 execution for convenience to those that don't have ATF setup, that might make sense, but then shouldn't initial EL3 execution and subsequent switching levels be debug CONFIG options? Thanks. In the past I remember using u-boot as the bare-metal s/w to debug a Silicon without any BootROM/firmware code running before the same on ARM 32-bit architectures. The ATF is presently tested only for UEFI and UEFI comes up in EL2 while the ATF itself is running in EL3. I don't know what would be the popular vote on this, but personally I feel that the u-boot for ARMv8 should also be launched by the ATF (similar to UEFI) and should start execution in EL2 so that it can launch a hypervisor (running in EL2) or Linux (running in EL1). But this might hurt the popular premise that u-boot can be used as a bare-metal s/w to debug a silicon without additional firmware components. Perhaps u-boot experts can guide us on this ! Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Warnings on arm64 build
Hi Mashiro,
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
On Behalf Of Masahiro Yamada
Sent: Thursday, January 23, 2014 12:38 PM
To: u-boot@lists.denx.de
Subject: [U-Boot] Warnings on arm64 build
Hello aarch64 experts,
Since commit 3865ceb (vexpress/armv7: Fix incorrect ethernet controller),
I have many warning messages when I compile vexpress board.
smc9.c: In function 'poll4int':
smc9.h:252:25: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast] #define SMC_inw(a,r) (*((volatile word
*)((a)-iobase+(r
^
smc9.c:242:18: note: in expansion of macro 'SMC_inw'
word old_bank = SMC_inw (dev, BSR_REG);
^
smc9.h:261:28: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast] #define SMC_outw(a,d,r) (*((volatile word
*)((a)-iobase+(r))) = d)
^
smc9.h:747:33: note: in expansion of macro 'SMC_outw'
#define SMC_SELECT_BANK(a,x) { SMC_outw((a), (x), BANK_SELECT ); }
These are issues with the SMSC91c111 driver highlighted when trying to compile
for ARM64.
I can try to fix the same, but will need some time to do the same, plus I don't
have additional
platforms to test the same.
Regards,
Bhupesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to get u-boot code with arm64: core support
-Original Message- From: tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: Monday, January 20, 2014 4:24 PM To: Wood Scott-B07421; Sharma Bhupesh-B45370 Cc: feng...@phytium.com.cn; tr...@ti.com; u-boot@lists.denx.de Subject: Re: Re: [U-Boot] how to get u-boot code with arm64: core support Hi, Scott: After changing to u-boot.elf, it could be run in FVP model. If I run ./Foundation_v8 --image ./u-boot.elf --cores=4 --no-secure- memory, Uboot could be run with FVP model. But no ARM trusted firmware boot info appeared. Such as: Booting trusted firmware boot loader stage 1 .. If I run ./Foundation_v8 --cores=4 --no-secure-memory --no-gicv3 --data=./bl1.bin@0x0 --nsdata=./u-boot.elf@0x8000, ARM trusted firmware boot info could appear, but failed to load and run u-boot.elf. So, if I want to use ARM trusted firmware to boot u-boot.elf, any ideas? U-boot doesn't have ARM trusted firmware support as of now. U-boot for ARMv8 starts in EL3, whereas UEFI starts in EL2 as trusted firmware itself is working in EL3. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64 patch: gicv3 support
Hi David, Thanks for the patch. Please see some comments inline: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of feng...@phytium.com.cn Sent: Wednesday, January 15, 2014 1:41 PM To: u-boot@lists.denx.de Cc: tr...@ti.com Subject: [U-Boot] [PATCH] arm64 patch: gicv3 support From: David Feng feng...@phytium.com.cn This patch add gicv3 support to uboot armv8 platform. Modifications cover 4 source files, as follows: gic.S: gicv3 initialization and sgi interrupt raising. goc.h: gicv3 register definitions. ^^^ Typo - gic.h vexpress_aemv8a.h: add CONFIG_GICV2/CONFIG_GICV3 switch. start.S: set SCR_EL3.NS bit to 1, gicv3 register of ICC_SRE_EL2 could be accessed only when SCR_EL3.NS=1. set SCR_EL3.IRQ|FIQ|EA bits, reroute all interrupts to el3 at all cores, slaves could be waken up by interrupt only when the interrupt is routed to it when running at el3. Hmmm. This seems a bit suspicious - if we reroute even IRQs and Aborts to the cores which work in EL3, they will not be visible to Linux or Hypervisor which work in EL2 or EL1. Have you tried to launch linux on the ARMv8 foundation model v2 with these changes? Note: please use the latest gcc 4.8 compiler from linaro which support gicv3 system register assembling. Two generic comments : - I see in the Foundation model README that the optional GICv3 is supported with memory-mapped CPU interface and distributor, but I see your patch accessing them via the sytem register interface (via msr and mrs). Is this a BUG in the README? Did you check this patch on the latest ARMv8 foundation model - v2? - Also how about sharing the GICv2 coding between ARMv7 and ARMv8 - some of the code may seems like a duplication from the ARMv7 GICv2 content. Signed-off-by: David Feng feng...@phytium.com.cn --- arch/arm/cpu/armv8/gic.S | 84 - arch/arm/cpu/armv8/start.S|5 ++- arch/arm/include/asm/gic.h| 56 + include/configs/vexpress_aemv8a.h |7 4 files changed, 150 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/gic.S b/arch/arm/cpu/armv8/gic.S index 599aa8f..a08939a 100644 --- a/arch/arm/cpu/armv8/gic.S +++ b/arch/arm/cpu/armv8/gic.S @@ -23,6 +23,74 @@ * * / WEAK(gic_init) +#if defined(CONFIG_GICV3) + branch_if_slave x0, 3f + + /* Initialize Distributor */ + ldr x1, =GICD_BASE + mov w0, #0x37 /* EnableGrp0 | EnableGrp1NS */ + /* EnableGrp1S | ARE_S | ARE_NS */ + str w0, [x1, GICD_CTLR] /* Secure GICD_CTLR */ + ldr w0, [x1, GICD_TYPER] + and w2, w0, #0x1f /* ITLinesNumber */ + cbz w2, 1f /* No SPIs */ + add x3, x1, (GICD_IGROUPRn + 4) + add x4, x1, (GICD_IGROUPMODRn + 4) + mov w5, #~0 +0: str w5, [x3], #0x4 + str wzr, [x4], #0x4 /* Config SPIs as Group1NS */ + sub w2, w2, #0x1 + cbnzw2, 0b + + /* Initialize All ReDistributors */ +1: ldr x1, =GICR_BASE +2: mov w0, #~0x2 + ldr w2, [x1, GICR_WAKER] + and w2, w2, w0 /* Clear ProcessorSleep */ + str w2, [x1, GICR_WAKER] + dsb st + isb +0: ldr w0, [x1, GICR_WAKER] + tbnzw0, #2, 0b /* Wait Children be Alive */ + + add x2, x1, #(1 16) /* SGI_Base */ + mov w5, #~0 + str w5, [x2, GICR_IGROUPRn] + str wzr, [x2, GICR_IGROUPMODRn] /* SGIs|PPIs Group1NS */ + mov w0, #0x1/* Enable SGI 0 */ + str w0, [x2, GICR_ISENABLERn] + + ldr w0, [x1, GICR_TYPER] + add x1, x1, #(2 16) + tbz w0, #4, 2b /* Next ReDistributor if Exist */ + + /* Initialize Cpu Interface */ +3: mrs x0, ICC_SRE_EL3 + orr x0, x0, #0xf/* SRE Disable IRQ/FIQ Bypass */ + /* Allow EL2 access to ICC_SRE_EL2 */ + msr ICC_SRE_EL3, x0 + isb + + mrs x0, ICC_SRE_EL2 + orr x0, x0, #0xf/* SRE Disable IRQ/FIQ Bypass */ + /* Allow EL1 access to ICC_SRE_EL1 */ + msr ICC_SRE_EL2, x0 + isb + + mov x0, #0x3/* EnableGrp1NS | EnableGrp1S */ + msr ICC_IGRPEN1_EL3, x0 + isb + + msr ICC_CTLR_EL3, xzr + isb + + msr ICC_CTLR_EL1, xzr /* NonSecure ICC_CTLR_EL1 */ + isb + + mov x0, #0x1 7 /* Non-Secure access to ICC_PMR_EL1 */ + msr ICC_PMR_EL1, x0 + isb +#elif defined(CONFIG_GICV2) branch_if_slave x0, 2f
Re: [U-Boot] [PATCH] arm64 patch: gicv3 support
-Original Message- From: FengHua [mailto:feng...@phytium.com.cn] Sent: Thursday, January 16, 2014 6:47 AM To: Sharma Bhupesh-B45370 Cc: u-boot@lists.denx.de; tr...@ti.com; Basu Arnab-B45036 Subject: Re: RE: [U-Boot] [PATCH] arm64 patch: gicv3 support hi bhupesh, -Original Messages- From: bhupesh.sha...@freescale.com bhupesh.sha...@freescale.com Sent Time: 2014-01-15 22:19:02 (Wednesday) To: 'feng...@phytium.com.cn' feng...@phytium.com.cn, u-boot@lists.denx.de u-boot@lists.denx.de Cc: tr...@ti.com tr...@ti.com, arnab.b...@freescale.com arnab.b...@freescale.com Subject: RE: [U-Boot] [PATCH] arm64 patch: gicv3 support Hi David, Thanks for the patch. Please see some comments inline: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of feng...@phytium.com.cn Sent: Wednesday, January 15, 2014 1:41 PM To: u-boot@lists.denx.de Cc: tr...@ti.com Subject: [U-Boot] [PATCH] arm64 patch: gicv3 support From: David Feng feng...@phytium.com.cn This patch add gicv3 support to uboot armv8 platform. Modifications cover 4 source files, as follows: gic.S: gicv3 initialization and sgi interrupt raising. goc.h: gicv3 register definitions. ^^^ Typo - gic.h vexpress_aemv8a.h: add CONFIG_GICV2/CONFIG_GICV3 switch. start.S: set SCR_EL3.NS bit to 1, gicv3 register of ICC_SRE_EL2 could be accessed only when SCR_EL3.NS=1. set SCR_EL3.IRQ|FIQ|EA bits, reroute all interrupts to el3 at all cores, slaves could be waken up by interrupt only when the interrupt is routed to it when running at el3. Hmmm. This seems a bit suspicious - if we reroute even IRQs and Aborts to the cores which work in EL3, they will not be visible to Linux or Hypervisor which work in EL2 or EL1. These bits will be cleared when jumping to el2. I seem to be missing this clear operation in your patch. Can you please point me to the same. Have you tried to launch linux on the ARMv8 foundation model v2 with these changes? Yes. But I thought we still don't have GICv3 driver in Linux. So did you boot linux with GICv2 or GICv3? Note: please use the latest gcc 4.8 compiler from linaro which support gicv3 system register assembling. Two generic comments : - I see in the Foundation model README that the optional GICv3 is supported with memory-mapped CPU interface and distributor, but I see your patch accessing them via the sytem register interface (via msr and mrs). Is this a BUG in the README? The document did not describe it clearly, but actually it support. So this seems to be a documentation BUG, did you provide a feedback to the ARM support folks regarding the same - they should probably fix the documentation. Did you check this patch on the latest ARMv8 foundation model - v2? Yes. - Also how about sharing the GICv2 coding between ARMv7 and ARMv8 - some of the code may seems like a duplication from the ARMv7 GICv2 content. Many codes could be shared between armv7 and armv8 such as cache maintenance and gic. These need be rearranged seriously. We'd better wait a period of time before the armv8 codes are more widely acquainted and get more feedback about this. I agree about the ARMv7/v8 code sharing, but with GICv3 there is an additional problem - it can be configured as GICv2 as well and for the same it would make sense to move common code b/w the CONFIG_GICV2/CONFIG_GICV3 code legs to a common leg. Signed-off-by: David Feng feng...@phytium.com.cn --- arch/arm/cpu/armv8/gic.S | 84 - arch/arm/cpu/armv8/start.S|5 ++- arch/arm/include/asm/gic.h| 56 + include/configs/vexpress_aemv8a.h |7 4 files changed, 150 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/gic.S b/arch/arm/cpu/armv8/gic.S index 599aa8f..a08939a 100644 --- a/arch/arm/cpu/armv8/gic.S +++ b/arch/arm/cpu/armv8/gic.S @@ -23,6 +23,74 @@ * * / WEAK(gic_init) +#if defined(CONFIG_GICV3) + branch_if_slave x0, 3f + + /* Initialize Distributor */ + ldr x1, =GICD_BASE + mov w0, #0x37 /* EnableGrp0 | EnableGrp1NS */ + /* EnableGrp1S | ARE_S | ARE_NS */ + str w0, [x1, GICD_CTLR] /* Secure GICD_CTLR */ + ldr w0, [x1, GICD_TYPER] + and w2, w0, #0x1f /* ITLinesNumber */ + cbz w2, 1f /* No SPIs */ + add x3, x1, (GICD_IGROUPRn + 4) + add x4, x1, (GICD_IGROUPMODRn + 4) + mov w5, #~0 +0: str w5, [x3], #0x4 + str wzr, [x4], #0x4 /* Config SPIs as Group1NS
Re: [U-Boot] how to get u-boot code with arm64: core support
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of tiger...@viatech.com.cn Sent: Tuesday, January 14, 2014 4:13 PM To: feng...@phytium.com.cn Cc: tr...@ti.com; u-boot@lists.denx.de; Wood Scott-B07421 Subject: Re: [U-Boot] how to get u-boot code with arm64: core support Hi, experts: I have tried to boot uefi bootloader with FVP model,it is ok! ./Foundation_v8 --cores=4 --no-secure-memory --visualization --gicv3 --data=./bl1.bin@0x0 --data=./uefi.fd@0x800 Which ARMv8 foundation model version you are using. I one I have doesn't support GiCv3. UEFI supports both GiCv3 and v2 whereas I believe uboot is only tested for GiCv2. BL1--BL2--...uefi.fd But booting uboot.bin, it still failed. Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to get u-boot code with arm64: core support
-Original Message- From: tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: Tuesday, January 14, 2014 4:40 PM To: Sharma Bhupesh-B45370; feng...@phytium.com.cn Cc: tr...@ti.com; u-boot@lists.denx.de; Wood Scott-B07421 Subject: Re: Re: [U-Boot] how to get u-boot code with arm64: core support Hi, sharma: ./Foundation_v8 --cores=4 --no-secure-memory --visualization --data=./bl1.bin@0x0 --data=./u-boot.bin@0x800 Is the TEXT_BASE right? Can you try this command: ./Foundation_v8 --image ./u-boot --cores=4 --no-secure-memory Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to get u-boot code with arm64: core support
Not the u-boot.bin, only u-boot: ./Foundation_v8 --image ./u-boot --cores=4 --no-secure-memory Regards, Bhupesh -Original Message- From: tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: Tuesday, January 14, 2014 4:52 PM To: Sharma Bhupesh-B45370; feng...@phytium.com.cn Cc: tr...@ti.com; u-boot@lists.denx.de; Wood Scott-B07421 Subject: Re: Re: [U-Boot] how to get u-boot code with arm64: core support Hi,Sharma: Can you try this command: ./Foundation_v8 --image ./u-boot --cores=4 --no-secure-memory Error: terminal_1: Listening for serial connection on port 5000 terminal_2: Listening for serial connection on port 5001 terminal_0: Listening for serial connection on port 5002 terminal_3: Listening for serial connection on port 5003 ERROR: an unexpected exception error has occurred inside the model terminate called after throwing an instance of 'ObjectLoaderError' what(): ./u-boot.bin: error while loading 'AXYS 'in'-file' file: fgets: Success ./run.sh: line 3: 25702 Aborted ./Foundation_v8 --image ./u-boot.bin --cores=4 --no-secure-memory So, maybe current FVP's version is newer! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v15 07/10] arm64: core support
Hi David,
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
On Behalf Of Bhupesh Sharma
Sent: Tuesday, December 03, 2013 3:33 PM
To: 'FengHua'
Cc: 'tr...@ti.com'; 'u-boot@lists.denx.de'; Wood Scott-B07421
Subject: Re: [U-Boot] [PATCH v15 07/10] arm64: core support
-Original Message-
From: FengHua [mailto:feng...@phytium.com.cn]
Sent: Sunday, December 01, 2013 7:48 PM
To: Sharma Bhupesh-B45370
Cc: 'Bhupesh SHARMA'; 'u-boot@lists.denx.de'; 'tr...@ti.com'; Wood
Scott-
B07421
Subject: Re: RE: Re: [U-Boot] [PATCH v15 07/10] arm64: core support
-Original Message-
From: FengHua [mailto:feng...@phytium.com.cn]
Sent: Friday, November 29, 2013 7:05 PM
To: Bhupesh SHARMA
Cc: u-boot@lists.denx.de; Sharma Bhupesh-B45370; tr...@ti.com;
Wood
Scott-B07421
Subject: Re: Re: [U-Boot] [PATCH v15 07/10] arm64: core support
hi Bhupesh,
Thank you for reviewing of the patch.
+/*
+ * Generic timer implementation of timer_read_counter() */
+unsigned long timer_read_counter(void) {
+ unsigned long cntpct;
+ isb();
+ asm volatile(mrs %0, cntpct_el0 : =r (cntpct));
+ return cntpct;
+}
diff --git a/arch/arm/cpu/armv8/gic.S
b/arch/arm/cpu/armv8/gic.S
The ARMv8 foundation model has support for GICv2 while GICv3 is
actually compatible to ARMv8. So although you mention in the
cover letter that this is currently GICv2 support, now while
trying to add
GICv3 support it will be difficult to envision GICv2 code in
'arch/arm/cpu/armv8/'
directory.
Infact GICv2 is compatible with ARMv7 and as secure and
non-secure copies of GIC registers are equally applicable to
ARMv7, would it make sense to keep the GICv2 code at a place
where both ARMv7 and
ARMv8 can use it?
Can we reuse something from [1] for GICv2:
[1]
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/non
se
c_vi
rt.S;h=24b4c18bd452fa155bcd5ed94c755aa05a33efe7;hb=HEAD#l88
Gicv2 only support maximum 8 cores, but still could be used with
armv8 processors if the processor contains less than 8 cores.
AMCC's
armv8 processor use Gicv2.
Yes, as you said it would be better to abstract a few common
routines of
Gicv2 and Gicv3 code and place them at a common place (such as
arm/lib) so that both ARMv7 and ARMv8 could use it.
+ /* Cache/BPB/TLB Invalidate */
+ bl __asm_flush_dcache_all /* dCache
cleaninvalidate */
+ bl __asm_invalidate_icache_all /* iCache invalidate */
+ bl __asm_invalidate_tlb_all/* invalidate TLBs */
+
+ /* Processor specific initialization */
+ bl lowlevel_init
Shouldn't this call be protected inside a '#ifndef
CONFIG_SKIP_LOWLEVEL_INIT'?
We could do so when it is actually needed.
+WEAK(lowlevel_init)
Ok, so this means that a specific SoC lowlevel_init
implementation can override this generic implementation. Because
I sure other secure/non-secure settings need to be put into
place for ARM IPs like SMMU-500.
+ENTRY(armv8_switch_to_el2)
Do we need a switch to Secure Monitor here? I am not able to
relate how this with the present ARMv7 code (see [2]):
[2]
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/non
se
c_vi
rt.S;h=24b4c18bd452fa155bcd5ed94c755aa05a33efe7;hb=HEAD#l29
Armv8 processor reset at el3(if it support security extension). So
we need to switch the processor to el2 or el1 before u-boot jump
to linux kernel due to linux-aarch64 only run at el2 or el1.
Hi David,
As per ARMv8 Arch Reference Manual (ARM), Monitor mode is provided
to support switching between Secure and Non-secure states. For
switching from secure to non secure state the usual mechanism is an
exception return. To return to Non-secure state (EL1/EL2), software
executing in
Monitor mode(EL3) sets SCR.NS to 1 and then performs the exception
return.
The implementation already in place for ARMv7 (see:
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/nonsec_
vi rt.S;h=24b4c18bd452fa155bcd5ed94c755aa05a33efe7;hb=HEAD#l29),
does this (sets up SMC handler and start.S calls smc #0 to switch to
non-secure state).
Something similar must be put into place for ARMv8 as well.
Sorry，I did not get your initially.
In my opinion, u-boot runs at monitor mode(EL3), it coulde set SCR.NS
to
1 directly.
Why we need to setup SMC handler and call SMC #0 to switch to
non-secure state?
I don't understand why armv7 did so. Did you have any understanding
about this?
Well, all ARM cores which support security extensions must support a
Re: [U-Boot] [U-boot] Uboot's plan for ARMv8
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of bhupesh.sha...@freescale.com Sent: Friday, January 10, 2014 12:59 PM To: 'tiger...@viatech.com.cn'; 'u-boot@lists.denx.de' Subject: Re: [U-Boot] [U-boot] Uboot's plan for ARMv8 -Original Message- From: tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: Friday, January 10, 2014 12:25 PM To: Sharma Bhupesh-B45370; u-boot@lists.denx.de Cc: feng...@phytium.com.cn Subject: Re: [U-boot] Uboot's plan for ARMv8 Hi, sharma: Thanks for your answer! How to get u-boot source code which includes arch/arm/cpu/armv8 dir? I used git clone git://www.denx.de/git/u-boot.git to download source code. But not find arm64 patch code in the downloaded source code. Hi Tiger, David's patches have still not made it into the DENX u-boot tree. If you are using a thunderbird email client to get email messages from DENX's u-boot list, go to MARC mailing list for u-boot (see [1]) and download all patches as '[Download message RAW]' and apply them over the top of your git-tree in correct patch order with 'git am -3' 1. http://marc.info/?l=u-bootm=138699294830148w=2 Sorry for the typo, I meant: a. If you are using a thunderbird email client to get email messages from DENX's u-boot list, you can directly download David's v16 ARM patches from there (as RAW patches), or b. Go to MARC mailing list for u-boot (see [1]) and download all patches as '[Download message RAW]' and apply them over the top of your git-tree in correct patch order with 'git am -3' 1. http://marc.info/?l=u-bootm=138699294830148w=2 Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] Uboot's plan for ARMv8
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of tiger...@viatech.com.cn Sent: Friday, January 10, 2014 8:33 AM To: u-boot@lists.denx.de Subject: [U-Boot] [U-boot] Uboot's plan for ARMv8 Hi, experts: Does U-boot have any plan to support ARMv8 SOC? Nvidia has decleared 64bit SOC plan. So, i think bootloader for ARMv8 SOC is urgent now. Although ARM Ltd recommended UEFI firmware as ARMv8's bootloader. But not a requirement. On Consumer Electronics market, Uboot has huge influence. So, Does U-boot have any plan to support ARMv8 SOC? I am sure you must have seen patches from David Feng (added in cc) for u-boot support for ARMv8 foundation model (see reference [1]). It compiles fine for me with the Linaro 'aarch64-linux-gcc' toolchain and is able to boot ARMv8 foundation model. With my SMSC ethernet related changes (already part of David's v16 patchset), I am able to TFTP standard vanilla Linux images onto the foundation model (along with a simple busybox RFS) and boot Linux on the same and test some simple applications like tftp on linux. This base code can be easily used to add support for a 'real' ARMv8 based SoC. Hope this helps. [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg127876.html Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] Uboot's plan for ARMv8
-Original Message- From: tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn] Sent: Friday, January 10, 2014 12:25 PM To: Sharma Bhupesh-B45370; u-boot@lists.denx.de Cc: feng...@phytium.com.cn Subject: Re: [U-boot] Uboot's plan for ARMv8 Hi, sharma: Thanks for your answer! How to get u-boot source code which includes arch/arm/cpu/armv8 dir? I used git clone git://www.denx.de/git/u-boot.git to download source code. But not find arm64 patch code in the downloaded source code. Hi Tiger, David's patches have still not made it into the DENX u-boot tree. If you are using a thunderbird email client to get email messages from DENX's u-boot list, go to MARC mailing list for u-boot (see [1]) and download all patches as '[Download message RAW]' and apply them over the top of your git-tree in correct patch order with 'git am -3' 1. http://marc.info/?l=u-bootm=138699294830148w=2 Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
