Re: [U-Boot] [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 home for holdoff releast. Thanks, Thank you for your patience. :) 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 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
Hello li.xi...@freescale.com, On Mon, 17 Nov 2014 02:16:11 +, li.xi...@freescale.com li.xi...@freescale.com wrote: 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. 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)? 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
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. 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, -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 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? 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
On 10/20/2014 02:00 AM, Xiubo Li wrote: Enable hypervisors utilizing the ARMv7 virtualization extension on the LS1021A-QDS/TWR boards with the A7 core tile, we add the required configuration variable. Also we define the board specific smp_set_cpu_boot_addr() function to set the start address for secondary cores in the LS1021A specific manner. Signed-off-by: Xiubo Li li.xi...@freescale.com --- Acked-by: York Sun york...@freescale.com ___ 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
Hello Xiubo, On Mon, 20 Oct 2014 17:00:48 +0800, Xiubo Li li.xi...@freescale.com wrote: Enable hypervisors utilizing the ARMv7 virtualization extension on the LS1021A-QDS/TWR boards with the A7 core tile, we add the required configuration variable. Also we define the board specific smp_set_cpu_boot_addr() function to set the start address for secondary cores in the LS1021A specific manner. Seems like there are two different logical changes here: - adding a secondary core boot address function; - changing a few targets' configurations. Please split this patch in two. Signed-off-by: Xiubo Li li.xi...@freescale.com --- arch/arm/cpu/armv7/ls102xa/cpu.c | 15 +++ arch/arm/include/asm/arch-ls102xa/config.h| 2 ++ arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 3 +++ include/configs/ls1021aqds.h | 7 +++ include/configs/ls1021atwr.h | 7 +++ 5 files changed, 34 insertions(+) diff --git a/arch/arm/cpu/armv7/ls102xa/cpu.c b/arch/arm/cpu/armv7/ls102xa/cpu.c index b7dde45..69d1801 100644 --- a/arch/arm/cpu/armv7/ls102xa/cpu.c +++ b/arch/arm/cpu/armv7/ls102xa/cpu.c @@ -101,3 +101,18 @@ int cpu_eth_init(bd_t *bis) return 0; } + +#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. 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? +#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_ADDR 0x1000 #define OCRAM_SIZE 0x0002 +#define OCRAM_BASE_S_ADDR0x1001 +#define OCRAM_S_SIZE 0x0001 #define CONFIG_SYS_IMMR 0x0100 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_OFFSET 0xe4 +#define CCSR_SCRATCHRW1_OFFSET 0x200 + #define RCWSR0_SYS_PLL_RAT_SHIFT 25 #define RCWSR0_SYS_PLL_RAT_MASK 0x1f #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_ADDR 0x01ee0200 +#define CONFIG_TIMER_CLK_FREQ1250 +#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_ADDR 0x01ee0200 +#define CONFIG_TIMER_CLK_FREQ1250 +#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
[U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
Enable hypervisors utilizing the ARMv7 virtualization extension on the LS1021A-QDS/TWR boards with the A7 core tile, we add the required configuration variable. Also we define the board specific smp_set_cpu_boot_addr() function to set the start address for secondary cores in the LS1021A specific manner. Signed-off-by: Xiubo Li li.xi...@freescale.com --- arch/arm/cpu/armv7/ls102xa/cpu.c | 15 +++ arch/arm/include/asm/arch-ls102xa/config.h| 2 ++ arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 3 +++ include/configs/ls1021aqds.h | 7 +++ include/configs/ls1021atwr.h | 7 +++ 5 files changed, 34 insertions(+) diff --git a/arch/arm/cpu/armv7/ls102xa/cpu.c b/arch/arm/cpu/armv7/ls102xa/cpu.c index b7dde45..69d1801 100644 --- a/arch/arm/cpu/armv7/ls102xa/cpu.c +++ b/arch/arm/cpu/armv7/ls102xa/cpu.c @@ -101,3 +101,18 @@ int cpu_eth_init(bd_t *bis) return 0; } + +#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); +} +#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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot