
On Wed, Feb 4, 2015 at 3:38 PM, FengHua fenghua@phytium.com.cn wrote:
config TARGET_LS2085A_SIMU bool "Support ls2085a_simu" select ARM64
select ARMV8_MULTIENTRY
VEXPRESS_AEMV8A and VEXPRESS_AEMV8A_SEMI are defaultly single entry?
Yes.
That means we always has ATF exist.
Not necessarily, just that something keeps the secondary cores in WFI. If that is ATF or something else (like the ROM, or just them being kept in power-on state) not doesn't matter.
But the more important question is: who is using this on vexpress64?
If I can reproduce the usecase with some sane setup, I'll be happy to handle the multientry case for the vexpress64's.
master_cpu:
/* On the master CPU */
+#endif /* CONFIG_ARMV8_MULTIENTRY */
bl _main
How about put the slave part of lowlevel_init in CONFIG_ARMV8_MULTIENTRY? although it still works with modified branch_if_master macro.
Yes it may save a few bytes, added some more #ifdefs.
.macro armv8_switch_to_el2_m, xreg1 diff --git a/board/armltd/vexpress64/vexpress64.c b/board/armltd/vexpress64/vexpress64.c index 58973185ecda..7ab000cca77b 100644 --- a/board/armltd/vexpress64/vexpress64.c +++ b/board/armltd/vexpress64/vexpress64.c @@ -22,12 +22,6 @@ int board_init(void)
int dram_init(void) {
/*
* Clear spin table so that secondary processors
* observe the correct value after waken up from wfe.
*/
*(unsigned long *)CPU_RELEASE_ADDR = 0;
Put them in CONFIG_ARMV8_MULTIENTRY instead of removing, so as to it works without ATF.
Do you have a system that uses this?
How can I reproduce a boot on one of the ARM vexpress64 simulators that will come up on multiple CPUs?
-/* SMP Spin Table Definitions */ -#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP -#define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f00000)
Are you sure Base FVP did not need MultiEntry?
Noone I know of uses it, if they exist the should speak up.
why is CPU_RELEASE_ADDR defined here with different value?
I think somebody just put it in there because the #define was needed to compile the U-boot. Noone has given any explanation to these magic numbers...
Yours, Linus Walleij