Re: [U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hi Albert,
If there hasn't any other problem, I will send out the V4 series.
Thanks very much,
BRs
Xiubo
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Thursday, November 20, 2014 8:07 PM
To: Xiubo Li-B47053
Cc: Sun York-R58495; Jin Zhengxiong-R64188; u-boot@lists.denx.de
Subject: Re: [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hello li.xi...@freescale.com,
On Wed, 19 Nov 2014 07:21:26 +, li.xi...@freescale.com
li.xi...@freescale.com wrote:
Hi Albert,
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Tuesday, November 18, 2014 3:18 PM
To: Xiubo Li-B47053
Cc: Sun York-R58495; Jin Zhengxiong-R64188; u-boot@lists.denx.de
Subject: Re: [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa
boards
Hello li.xi...@freescale.com,
On Tue, 18 Nov 2014 02:01:02 +, li.xi...@freescale.com
li.xi...@freescale.com wrote:
Hi Albert,
+#if defined(CONFIG_ARMV7_NONSEC) ||
defined(CONFIG_ARMV7_VIRT)
+/* Setting the address at which secondary cores start
from.*/
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ struct ccsr_gur __iomem *gur = (void
*)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
+ out_be32(gur-scratchrw[0], addr);
+ out_be32(gur-brrl, 0x2);
+}
This function does not exactly [set] the address at which
secondary
cores start from; it sets *a* secondary core's boot address,
and
then
it *boots* it.
Okay, I will fix it later.
Why does this version of smp_set_core_boot_addr() need to boot
the
core
in addition to setting the address, whereas the existing ones
in
virt_v7, vexpress_common and arndale don't boot the cores?
Yes, they don't doing the release operation.
For Low Power Management requirement, maybe only one core will
be
used,
and
then
We also make sure that the secondary core must be in low power
and
deep
sleep
mode(using wfi). So I just release it here, to make sure that
the
wfi
instruction
will be executed as early as possible.
Right after smp_set_core_boot_addr() is called, kick_all_cpus()
isgoing
to be called. Wouldn't that boot your CPUs just as well?
Yes, it will.
But before that we must do the holdoff bit set operation as the
SoC's
requirement.
The BRR contains control bits for enabling boot for each core. On
exiting
HRESET or
PORESET, the RCW BOOT_HO field optionally allows for logical core 0
to
be
released
for booting or to remain in boot holdoff. All other cores remain in
boot
holdoff until their
corresponding bit is set.
Maybe the comment is not very clear and a bit confusing.
Before I'm lost entirely, do you mean that the comment:
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
Is actually wrong, and the instructions that follow it do not actually
boot the secondary core(s)?
The comment should be:
/*
* After setting the secondary core's start address,
* just release it from holdoff.
*/
From my tests, for most time the release instructions will boot the
secondary
core(s) without smp_kick_all_cpus(). One time has failed.
So I think the release can not make sure that it will boot the secondary
core(s).
Thanks for clarifying.
If a holdoff release is the right way to boot a secondary core for you,
then I think the right place to do it is not smp_set_core_boot_addr()
but smp_kick_all_cpus(), of which you could make a strong version which
would do the holdoff release instead of whatever the weak version does.
Yes, I do think a strong version will be okay.
In file arch/arm/cpu/armv7/ls102xa/cpu.c, add the strong version:
+/* Release the secondary core from holdoff state and boot it */
+void smp_kick_all_cpus(void)
+{
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ out_be32(gur-brrl, 0x2);
+}
+
Is this okay ?
Yes, thanks!
I have test the holdoff release in two boards(including the old one before
I used) for 37 times and all has passed. I have a check the before failed
logs,
It is another issue led to the failure. And also get confirmation that the
Holdoff release will do reset and then boot the secondary core.
Good -- this makes smp_kick_all_cpus() the right
Re: [U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hi Albert,
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Tuesday, November 18, 2014 3:18 PM
To: Xiubo Li-B47053
Cc: Sun York-R58495; Jin Zhengxiong-R64188; u-boot@lists.denx.de
Subject: Re: [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hello li.xi...@freescale.com,
On Tue, 18 Nov 2014 02:01:02 +, li.xi...@freescale.com
li.xi...@freescale.com wrote:
Hi Albert,
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+/* Setting the address at which secondary cores start from.*/
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ struct ccsr_gur __iomem *gur = (void
*)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
+ out_be32(gur-scratchrw[0], addr);
+ out_be32(gur-brrl, 0x2);
+}
This function does not exactly [set] the address at which
secondary
cores start from; it sets *a* secondary core's boot address, and
then
it *boots* it.
Okay, I will fix it later.
Why does this version of smp_set_core_boot_addr() need to boot the
core
in addition to setting the address, whereas the existing ones in
virt_v7, vexpress_common and arndale don't boot the cores?
Yes, they don't doing the release operation.
For Low Power Management requirement, maybe only one core will be
used,
and
then
We also make sure that the secondary core must be in low power and
deep
sleep
mode(using wfi). So I just release it here, to make sure that the
wfi
instruction
will be executed as early as possible.
Right after smp_set_core_boot_addr() is called, kick_all_cpus()
isgoing
to be called. Wouldn't that boot your CPUs just as well?
Yes, it will.
But before that we must do the holdoff bit set operation as the SoC's
requirement.
The BRR contains control bits for enabling boot for each core. On
exiting
HRESET or
PORESET, the RCW BOOT_HO field optionally allows for logical core 0 to
be
released
for booting or to remain in boot holdoff. All other cores remain in boot
holdoff until their
corresponding bit is set.
Maybe the comment is not very clear and a bit confusing.
Before I'm lost entirely, do you mean that the comment:
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
Is actually wrong, and the instructions that follow it do not actually
boot the secondary core(s)?
The comment should be:
/*
* After setting the secondary core's start address,
* just release it from holdoff.
*/
From my tests, for most time the release instructions will boot the
secondary
core(s) without smp_kick_all_cpus(). One time has failed.
So I think the release can not make sure that it will boot the secondary
core(s).
Thanks for clarifying.
If a holdoff release is the right way to boot a secondary core for you,
then I think the right place to do it is not smp_set_core_boot_addr()
but smp_kick_all_cpus(), of which you could make a strong version which
would do the holdoff release instead of whatever the weak version does.
Yes, I do think a strong version will be okay.
In file arch/arm/cpu/armv7/ls102xa/cpu.c, add the strong version:
+/* Release the secondary core from holdoff state and boot it */
+void smp_kick_all_cpus(void)
+{
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ out_be32(gur-brrl, 0x2);
+}
+
Is this okay ?
I have test the holdoff release in two boards(including the old one before
I used) for 37 times and all has passed. I have a check the before failed logs,
It is another issue led to the failure. And also get confirmation that the
Holdoff release will do reset and then boot the secondary core.
Thanks,
BRs
Xiubo
That is, unless you also need the weak version to run, in which case
I /still/ think you should find a way for all of this to happen at the
'kick stage (maybe with a .weakref in arch/arm/cpu/armv8/start.S, to
give the weak smp_kick_all_cpus symbol another name that could be
referred to by the strong version).
Thanks,
BRs
Xiubo
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hi Albert,
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+/* Setting the address at which secondary cores start from.*/
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ struct ccsr_gur __iomem *gur = (void
*)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
+ out_be32(gur-scratchrw[0], addr);
+ out_be32(gur-brrl, 0x2);
+}
This function does not exactly [set] the address at which secondary
cores start from; it sets *a* secondary core's boot address, and then
it *boots* it.
Okay, I will fix it later.
Why does this version of smp_set_core_boot_addr() need to boot the
core
in addition to setting the address, whereas the existing ones in
virt_v7, vexpress_common and arndale don't boot the cores?
Yes, they don't doing the release operation.
For Low Power Management requirement, maybe only one core will be used,
and
then
We also make sure that the secondary core must be in low power and deep
sleep
mode(using wfi). So I just release it here, to make sure that the wfi
instruction
will be executed as early as possible.
Right after smp_set_core_boot_addr() is called, kick_all_cpus() isgoing
to be called. Wouldn't that boot your CPUs just as well?
Yes, it will.
But before that we must do the holdoff bit set operation as the SoC's
requirement.
The BRR contains control bits for enabling boot for each core. On exiting
HRESET or
PORESET, the RCW BOOT_HO field optionally allows for logical core 0 to be
released
for booting or to remain in boot holdoff. All other cores remain in boot
holdoff until their
corresponding bit is set.
Maybe the comment is not very clear and a bit confusing.
Before I'm lost entirely, do you mean that the comment:
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
Is actually wrong, and the instructions that follow it do not actually
boot the secondary core(s)?
The comment should be:
/*
* After setting the secondary core's start address,
* just release it from holdoff.
*/
From my tests, for most time the release instructions will boot the secondary
core(s) without smp_kick_all_cpus(). One time has failed.
So I think the release can not make sure that it will boot the secondary
core(s).
Thanks,
BRs
Xiubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hi Albert,
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Friday, November 14, 2014 7:45 PM
To: Xiubo Li-B47053
Cc: Sun York-R58495; Jin Zhengxiong-R64188; u-boot@lists.denx.de
Subject: Re: [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hello li.xi...@freescale.com,
On Fri, 14 Nov 2014 09:06:13 +, li.xi...@freescale.com
li.xi...@freescale.com wrote:
Hi Albert,
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+/* Setting the address at which secondary cores start from.*/
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ struct ccsr_gur __iomem *gur = (void
*)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
+ out_be32(gur-scratchrw[0], addr);
+ out_be32(gur-brrl, 0x2);
+}
This function does not exactly [set] the address at which secondary
cores start from; it sets *a* secondary core's boot address, and then
it *boots* it.
Okay, I will fix it later.
Why does this version of smp_set_core_boot_addr() need to boot the core
in addition to setting the address, whereas the existing ones in
virt_v7, vexpress_common and arndale don't boot the cores?
Yes, they don't doing the release operation.
For Low Power Management requirement, maybe only one core will be used, and
then
We also make sure that the secondary core must be in low power and deep
sleep
mode(using wfi). So I just release it here, to make sure that the wfi
instruction
will be executed as early as possible.
Right after smp_set_core_boot_addr() is called, kick_all_cpus() isgoing
to be called. Wouldn't that boot your CPUs just as well?
Yes, it will.
But before that we must do the holdoff bit set operation as the SoC's
requirement.
The BRR contains control bits for enabling boot for each core. On exiting
HRESET or
PORESET, the RCW BOOT_HO field optionally allows for logical core 0 to be
released
for booting or to remain in boot holdoff. All other cores remain in boot
holdoff until their
corresponding bit is set.
Maybe the comment is not very clear and a bit confusing.
Thanks,
BRs
Xiubo
Thanks,
BRs,
Xiubo
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Hi Albert,
+#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
+/* Setting the address at which secondary cores start from.*/
+void smp_set_core_boot_addr(unsigned long addr, int corenr)
+{
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+
+ /*
+* After setting the secondary cores start address,
+* just release them to boot.
+*/
+ out_be32(gur-scratchrw[0], addr);
+ out_be32(gur-brrl, 0x2);
+}
This function does not exactly [set] the address at which secondary
cores start from; it sets *a* secondary core's boot address, and then
it *boots* it.
Okay, I will fix it later.
Why does this version of smp_set_core_boot_addr() need to boot the core
in addition to setting the address, whereas the existing ones in
virt_v7, vexpress_common and arndale don't boot the cores?
Yes, they don't doing the release operation.
For Low Power Management requirement, maybe only one core will be used, and then
We also make sure that the secondary core must be in low power and deep sleep
mode(using wfi). So I just release it here, to make sure that the wfi
instruction
will be executed as early as possible.
Thanks,
BRs,
Xiubo
+#endif
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index ed78c33..4856388 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -11,6 +11,8 @@
#define OCRAM_BASE_ADDR0x1000
#define OCRAM_SIZE 0x0002
+#define OCRAM_BASE_S_ADDR 0x1001
+#define OCRAM_S_SIZE 0x0001
#define CONFIG_SYS_IMMR0x0100
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..0bac353 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -17,6 +17,9 @@
#define SOC_VER_LS1021 0x11
#define SOC_VER_LS1022 0x12
+#define CCSR_BRR_OFFSET0xe4
+#define CCSR_SCRATCHRW1_OFFSET 0x200
+
#define RCWSR0_SYS_PLL_RAT_SHIFT 25
#define RCWSR0_SYS_PLL_RAT_MASK0x1f
#define RCWSR0_MEM_PLL_RAT_SHIFT 16
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 657e3b6..6976cfa 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -324,6 +324,13 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_CMDLINE_EDITING
#define CONFIG_CMD_IMLS
+#define CONFIG_ARMV7_NONSEC
+#define CONFIG_ARMV7_VIRT
+#define CONFIG_PEN_ADDR_BIG_ENDIAN
+#define CONFIG_SMP_PEN_ADDR0x01ee0200
+#define CONFIG_TIMER_CLK_FREQ 1250
+#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR
+
#define CONFIG_HWCONFIG
#define HWCONFIG_BUFFER_SIZE 128
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 45b2272..655b39a 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -227,6 +227,13 @@
#define CONFIG_CMDLINE_EDITING
#define CONFIG_CMD_IMLS
+#define CONFIG_ARMV7_NONSEC
+#define CONFIG_ARMV7_VIRT
+#define CONFIG_PEN_ADDR_BIG_ENDIAN
+#define CONFIG_SMP_PEN_ADDR0x01ee0200
+#define CONFIG_TIMER_CLK_FREQ 1250
+#define CONFIG_ARMV7_SECURE_BASE OCRAM_BASE_S_ADDR
+
#define CONFIG_HWCONFIG
#define HWCONFIG_BUFFER_SIZE 128
--
2.1.0.27.g96db324
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ls102xa: HYP/non-sec: for ls102xa.
Hi York, Albert Could you help me to review these patches ? Thanks very much, BRs Xiubo -Original Message- From: Xiubo Li [mailto:li.xi...@freescale.com] Sent: Tuesday, September 16, 2014 10:48 AM To: albert.u.b...@aribaud.net; Wang Huan-B18965; i...@hellion.org.uk; hdego...@redhat.com; Kushwaha Prabhakar-B32579; Wang Huan-B18965; andre.przyw...@linaro.org; marc.zyng...@arm.com; yamad...@jp.panasonic.com; Aggrwal Poonam-B10812; Leekha Shaveta-B20052; u-boot@lists.denx.de Cc: Xiubo Li-B47053 Subject: [PATCH 0/4] ls102xa: HYP/non-sec: for ls102xa. Xiubo Li (4): ARM: HYP/non-sec: add the pen address byte reverting support. ARM: HYP/non-sec: Fix the ARCH Timer frequency setting. ls102xa: HYP/non-sec: support for ls102xa boards ARM: ls102xa: allow all device accessable in non-secure state arch/arm/cpu/armv7/ls102xa/cpu.c | 15 +++ arch/arm/cpu/armv7/nonsec_virt.S | 7 +- arch/arm/include/asm/arch-ls102xa/config.h| 3 + arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 3 + arch/arm/include/asm/arch-ls102xa/ns_access.h | 117 ++ board/freescale/common/Makefile | 2 + board/freescale/common/ns_access.c| 32 ++ board/freescale/ls1021aqds/ls1021aqds.c | 88 board/freescale/ls1021atwr/ls1021atwr.c | 87 include/configs/ls1021aqds.h | 8 ++ include/configs/ls1021atwr.h | 8 ++ include/configs/sun7i.h | 1 + 12 files changed, 369 insertions(+), 2 deletions(-) create mode 100644 arch/arm/include/asm/arch-ls102xa/ns_access.h create mode 100644 board/freescale/common/ns_access.c -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] ls102xa: HYP/non-sec: for ls102xa.
Ping :) Thanks, BRs Xiubo -Original Message- From: Xiubo Li [mailto:li.xi...@freescale.com] Sent: Tuesday, September 16, 2014 10:48 AM To: albert.u.b...@aribaud.net; Wang Huan-B18965; i...@hellion.org.uk; hdego...@redhat.com; Kushwaha Prabhakar-B32579; Wang Huan-B18965; andre.przyw...@linaro.org; marc.zyng...@arm.com; yamad...@jp.panasonic.com; Aggrwal Poonam-B10812; Leekha Shaveta-B20052; u-boot@lists.denx.de Cc: Xiubo Li-B47053 Subject: [PATCH 0/4] ls102xa: HYP/non-sec: for ls102xa. Xiubo Li (4): ARM: HYP/non-sec: add the pen address byte reverting support. ARM: HYP/non-sec: Fix the ARCH Timer frequency setting. ls102xa: HYP/non-sec: support for ls102xa boards ARM: ls102xa: allow all device accessable in non-secure state arch/arm/cpu/armv7/ls102xa/cpu.c | 15 +++ arch/arm/cpu/armv7/nonsec_virt.S | 7 +- arch/arm/include/asm/arch-ls102xa/config.h| 3 + arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 3 + arch/arm/include/asm/arch-ls102xa/ns_access.h | 117 ++ board/freescale/common/Makefile | 2 + board/freescale/common/ns_access.c| 32 ++ board/freescale/ls1021aqds/ls1021aqds.c | 88 board/freescale/ls1021atwr/ls1021atwr.c | 87 include/configs/ls1021aqds.h | 8 ++ include/configs/ls1021atwr.h | 8 ++ include/configs/sun7i.h | 1 + 12 files changed, 369 insertions(+), 2 deletions(-) create mode 100644 arch/arm/include/asm/arch-ls102xa/ns_access.h create mode 100644 board/freescale/common/ns_access.c -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arch/arm: Add individual TLB size support.
Hi Albert, Subject: Re: [PATCH] arch/arm: Add individual TLB size support. Hi Xiubo, On Mon, 7 Jul 2014 13:19:11 +0800, Xiubo Li li.xi...@freescale.com wrote: This adds CONFIG_TLB_SIZE for individual board, whose TLB size maybe larger than PGTABLE_SIZE. Signed-off-by: Xiubo Li li.xi...@freescale.com --- arch/arm/lib/board.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index dc34190..b7327ce 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -353,7 +353,11 @@ void board_init_f(ulong bootflag) #if !(defined(CONFIG_SYS_ICACHE_OFF) defined(CONFIG_SYS_DCACHE_OFF)) /* reserve TLB table */ +#ifdef CONFIG_TLB_SIZE + gd-arch.tlb_size = CONFIG_TLB_SIZE; +#else gd-arch.tlb_size = PGTABLE_SIZE; +#endif addr -= gd-arch.tlb_size; /* round down to next 64 kB limit */ There is no code in current mainline which defines CONFIG_TLB_SIZE; that makes the patch a dead code addition. Yes, this will be used by our LS1 SoC first, and it is still doing The upstream. Besides, what's the point of this as opposed to, e.g., just defining the right PGTABLE_SIZE, or renaming PGTABLE_SIZE as CONFIG_TLB_SIZE? We'll add the LPAE support in uboot and need more space for tlb. Thanks very much, BRs Xiubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: non-sec: Add spin table reserved memory support
Subject: Re: [PATCH] ARM: non-sec: Add spin table reserved memory support
On 07/08/14 02:54, Xiubo Li wrote:
The memory where loaded the smp_waitloop code section probablly
be corrupted by Linux Kernel, then the secondary cores will be
running the random code, leading booting the secondary cores
failed.
There is now similar reservation code in virt-dt.c. Probably some form
of consolidation is in order.
Thanks,
M.
That's good, I will check that.
Thanks,
BRs
Xiubo
Signed-off-by: Xiubo Li li.xi...@freescale.com
---
arch/arm/cpu/armv7/nonsec_virt.S | 6 ++
arch/arm/include/asm/nonsecure.h | 14 ++
arch/arm/lib/Makefile| 4
arch/arm/lib/nonsecure.c | 34 ++
4 files changed, 58 insertions(+)
create mode 100644 arch/arm/include/asm/nonsecure.h
create mode 100644 arch/arm/lib/nonsecure.c
diff --git a/arch/arm/cpu/armv7/nonsec_virt.S
b/arch/arm/cpu/armv7/nonsec_virt.S
index c334a15..e3a62af 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -175,6 +175,9 @@ ENTRY(_nonsec_init)
bx lr
ENDPROC(_nonsec_init)
+.globl smp_waitloop_start
+smp_waitloop_start:
+ .word .
#ifdef CONFIG_SMP_PEN_ADDR
/* void __weak smp_waitloop(unsigned previous_address); */
ENTRY(smp_waitloop)
@@ -190,6 +193,9 @@ ENTRY(smp_waitloop)
ENDPROC(smp_waitloop)
.weak smp_waitloop
#endif
+.globl smp_waitloop_end
+smp_waitloop_end:
+ .word .
ENTRY(_switch_to_hyp)
mov r0, lr
diff --git a/arch/arm/include/asm/nonsecure.h
b/arch/arm/include/asm/nonsecure.h
new file mode 100644
index 000..31a4071
--- /dev/null
+++ b/arch/arm/include/asm/nonsecure.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (c) 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ARM_NONSECURE_H_
+#define _ARM_NONSECURE_H_
+
+extern ulong smp_waitloop_start; /* start of image for smp spin
table */
+extern ulong smp_waitloop_end; /* end of image for smp spin table
*/
+int fdt_add_smp_waitloop_mem_rsv(void *blob);
+
+#endif /* _ARM_NONSECURE_H_ */
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 321997c..fe707e9 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -55,6 +55,10 @@ ifndef CONFIG_ARM64
obj-y += cache-cp15.o
endif
+ifneq ($(CONFIG_ARMV7_NONSEC)$(CONFIG_ARMV7_VIRT),)
+obj-y += nonsecure.o
+endif
+
# For EABI conformant tool chains, provide eabi_compat()
ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS)))
extra-y+= eabi_compat.o
diff --git a/arch/arm/lib/nonsecure.c b/arch/arm/lib/nonsecure.c
new file mode 100644
index 000..2a83669
--- /dev/null
+++ b/arch/arm/lib/nonsecure.c
@@ -0,0 +1,34 @@
+/*
+ * Copyright (c) 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include common.h
+#include asm/nonsecure.h
+#include libfdt.h
+
+#define PG_4K_ALING ~((1 12) - 1)
+#define PG_4K (1 12)
+
+int fdt_add_smp_waitloop_mem_rsv(void *blob)
+{
+ unsigned long rsv_start = smp_waitloop_start PG_4K_ALING;
+ unsigned long rsv_end = smp_waitloop_end PG_4K_ALING;
+ unsigned long rsv_size;
+ int off;
+
+ if (smp_waitloop_end == smp_waitloop_start + 0x4)
+ return 0;
+
+ if (rsv_start != rsv_end)
+ rsv_size = 2 * PG_4K;
+ else
+ rsv_size = PG_4K;
+
+ off = fdt_add_mem_rsv(blob, rsv_start, (u64)rsv_size);
+ if (off 0)
+ printf(Failed to reserve memory for smp waitloop: %s\n,
+ fdt_strerror(off));
+
+ return off;
+}
--
Jazz is not dead. It just smells funny...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Add LS1021A-QDS/TWR Non-secure and HYP support.
[U-Boot,v4,03/10] ARM: non-sec: reset CNTVOFF to zero Before switching to non-secure, make sure that CNTVOFF is set to zero on all CPUs. Otherwise, kernel running in non-secure without HYP enabled (hence using virtual timers) may observe But we have HYP enabled. In this case why are the series dependent on this patch? Well, if the HYP is enabled, the host OS will use the Physical timer, and these CNTVOFFs could be cleared in kernel too. When and where to clear them is better ? In uboot or in kernel when needed? If HYP mode is available CNTVOFF is cleared in Linux. What I am trying to say is that it will work also without the patch you mentioned. Diana Yes, it will work, but the time won't be correct sometimes till the CNTVOFFs are cleared in Linux, which we can see from the Linux boot logs with the following is enabled: CONFIG_PRINTK_TIME=y This is because, if the HYP mode is available for Host OS, the Physical timers Will be used, but the ARCH ARM Timer will still use the Virtual timer's counter To count the xtime. Thanks, BRs Xiubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ARM: LS1021A: enable ARMv7 virt support for LS1021A A7
+#define CONFIG_ARMV7_NONSEC +#define CONFIG_ARMV7_VIRT +#define CONFIG_SOC_BIG_ENDIAN +#define CONFIG_DCFG_CCSR_SCRATCHRW1 0x01ee0200 +#define CONFIG_DCFG_CCSR_BRR 0x01ee00e4 Why are you hardcoding the register addresses in this file? I saw that all registers are defined in: arch/arm/include/asm/arch-ls102xa/config.h. Why are these special? No special, and I'll follow your advice. +#define CONFIG_SMP_PEN_ADDR CONFIG_DCFG_CCSR_SCRATCHRW1 +#define CONFIG_ARM_GIC_BASE_ADDRESS 0x0140 Why do you need the GIC base address? Can't this be read from CBAR? I'm not very sure, I have tried, but failed, I will do some research later. What is not working? Is the address returned by CBAR wrong? It works now using the CBAR... Thanks, BRs Xiubo Diana ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ARM: LS1021A: enable ARMv7 virt support for LS1021A A7
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index d639a6f..f090971 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -18,6 +18,15 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_ARCH_EARLY_INIT_R +#define CONFIG_ARMV7_NONSEC +#define CONFIG_ARMV7_VIRT +#define CONFIG_SOC_BIG_ENDIAN +#define CONFIG_DCFG_CCSR_SCRATCHRW10x01ee0200 +#define CONFIG_DCFG_CCSR_BRR 0x01ee00e4 Why are you hardcoding the register addresses in this file? I saw that all registers are defined in: arch/arm/include/asm/arch-ls102xa/config.h. Why are these special? No special, and I'll follow your advice. +#define CONFIG_SMP_PEN_ADDRCONFIG_DCFG_CCSR_SCRATCHRW1 +#define CONFIG_ARM_GIC_BASE_ADDRESS0x0140 Why do you need the GIC base address? Can't this be read from CBAR? I'm not very sure, I have tried, but failed, I will do some research later. Thanks, BRs Xiubo +#define CONFIG_TIMER_CLK_FREQ 12500 + #define CONFIG_HWCONFIG #define HWCONFIG_BUFFER_SIZE 128 diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index a8dc56e..235a862 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -18,6 +18,15 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_ARCH_EARLY_INIT_R +#define CONFIG_ARMV7_NONSEC +#define CONFIG_ARMV7_VIRT +#define CONFIG_SOC_BIG_ENDIAN +#define CONFIG_DCFG_CCSR_SCRATCHRW10x01ee0200 +#define CONFIG_DCFG_CCSR_BRR 0x01ee00e4 +#define CONFIG_SMP_PEN_ADDRCONFIG_DCFG_CCSR_SCRATCHRW1 +#define CONFIG_ARM_GIC_BASE_ADDRESS0x0140 +#define CONFIG_TIMER_CLK_FREQ 12500 + #define CONFIG_HWCONFIG #define HWCONFIG_BUFFER_SIZE 128 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Add LS1021A-QDS/TWR Non-secure and HYP support.
This patch series depends on the following patch: [U-Boot,v4,03/10] ARM: non-sec: reset CNTVOFF to zero Before switching to non-secure, make sure that CNTVOFF is set to zero on all CPUs. Otherwise, kernel running in non-secure without HYP enabled (hence using virtual timers) may observe But we have HYP enabled. In this case why are the series dependent on this patch? Well, if the HYP is enabled, the host OS will use the Physical timer, and these CNTVOFFs could be cleared in kernel too. When and where to clear them is better ? In uboot or in kernel when needed? Thanks, BRs Xiubo timers that are not synchronized, effectively seeing time going backward... Patch work: http://patchwork.ozlabs.org/patch/343084/ Xiubo Li (4): ARM: fix the ARCH Timer frequency setting. ARM: add the pen address byte reverting support. ARM: LS1021A: enable ARMv7 virt support for LS1021A A7 ARM: LS1021A: to allow non-secure R/W access for all devices' mapped region arch/arm/cpu/armv7/ls102xa/cpu.c | 12 +++ arch/arm/cpu/armv7/nonsec_virt.S | 7 +- arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 98 +- - board/freescale/ls1021aqds/ls1021aqds.c | 110 +++-- board/freescale/ls1021atwr/ls1021atwr.c | 111 -- include/configs/ls1021aqds.h | 9 ++ include/configs/ls1021atwr.h | 9 ++ 7 files changed, 333 insertions(+), 23 deletions(-) Diana ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: fix the ARCH Timer frequency setting.
Subject: Re: [PATCH 1/4] ARM: fix the ARCH Timer frequency setting. On 07/03/2014 12:51 PM, Xiubo Li wrote: For some SoCs, the CONFIG_SYS_CLK_FREQ maybe won't equal the ARCH Timer's frequency. Can you give an example? In LS1021A-QDS/TWR, the CONFIG_SYS_CLK_FREQ is 100Mhz and the ARCH timer's Frequency will be 12.5Mhz... Here using the CONFIG_TIMER_CLK_FREQ instead if the ARCH Timer's frequency need to config here. Signed-off-by: Xiubo Li li.xi...@freescale.com --- arch/arm/cpu/armv7/nonsec_virt.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index 6f90988..e9766c0 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -147,11 +147,11 @@ ENTRY(_nonsec_init) * we do this here instead. * But first check if we have the generic timer. */ -#ifdef CONFIG_SYS_CLK_FREQ +#ifdef CONFIG_TIMER_CLK_FREQ Aren't you breaking the boards which rely on CONFIG_SYS_CLK_FREQ ? I hadn't found any board is using this in the upstreamed tree, or may I miss something ? If there exist some, and I will redefined it for them here. In ARMv7, what could I find is that only vexpress_ca15_tc2 board has enabled the CONFIG_ARMV7_VIRT without defining it. Thanks, BRs Xiubo mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 and r0, r0, #CPUID_ARM_GENTIMER_MASK@ mask arch timer bits cmp r0, #(1 CPUID_ARM_GENTIMER_SHIFT) - ldreq r1, =CONFIG_SYS_CLK_FREQ + ldreq r1, =CONFIG_TIMER_CLK_FREQ mcreq p15, 0, r1, c14, c0, 0 @ write CNTFRQ #endif Diana ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: LS1021A: to allow non-secure R/W access for all devices' mapped region
- reg = in_be32(csu_csl2);
- out_be32(csu_csl2, reg | CSU_CSL2x_NS_SUP_READ_ACCESS |
- CSU_CSL2x_NS_USER_READ_ACCESS);
+void enable_devices_ns_access(void)
This function is identical for twr and qds? Can't be just one in a
common file?
Sure, I will follow your advice.
Thanks,
BRs
Xiubo
+{
+ uint32_t *csu_csl;
+ uint32_t reg;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(ns_dev); i++) {
+ csu_csl = CONFIG_SYS_FSL_CSU_ADDR + ns_dev[i].ind / 2 * 4;
+ reg = in_be32(csu_csl);
+ if (ns_dev[i].ind % 2 == 0)
+ reg |= ns_dev[i].val 16;
+ else
+ reg |= ns_dev[i].val;
+ out_be32(csu_csl, reg);
+ }
}
int board_late_init(void)
@@ -483,7 +580,7 @@ int board_late_init(void)
ahci_init(AHCI_BASE_ADDR);
scsi_scan(1);
- enable_ifc_ns_read_access();
+ enable_devices_ns_access();
return 0;
}
Diana Craciun
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
