[U-Boot] [PATCH v2] armv8/vexpress64: make multientry conditional

Linus Walleij linus.walleij at linaro.org
Fri Feb 6 11:56:42 CET 2015


On Wed, Feb 4, 2015 at 3:38 PM, FengHua <fenghua at 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


More information about the U-Boot mailing list