[U-Boot] [PATCH 2/2] arm64: add better spin-table support

[Chen-Yu Tsai]

Hi,

On Mon, Jun 27, 2016 at 6:47 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi Masahiro,
>
> On 25/06/16 05:08, Masahiro Yamada wrote:
>> Hi Andre,
>>
>>
>> 2016-06-19 19:33 GMT+09:00 André Przywara <andre.przywara at arm.com>:
>>> Hi,
>>>
>>> On 19/06/16 09:57, Masahiro Yamada wrote:
>>>> 2016-06-18 18:40 GMT+09:00 Linus Walleij <linus.walleij at linaro.org>:
>>>>> On Fri, Jun 17, 2016 at 2:51 PM, Masahiro Yamada
>>>>> <yamada.masahiro at socionext.com> wrote:
>>>>>
>>>>>> There are two enable methods supported by ARM64 Linux; psci and
>>>>>> spin-table.  The latter is simpler and easier to use for quick SoC
>>>>>> bring-up.
>>>>>>
>>>>>> So, I used the spin-table for my first ARMv8 SoC porting, but I
>>>>>> found its support in U-Boot was poor.  It is true there exists a
>>>>>> code fragment for the spin code in arch/arm/cpu/armv8/start.S,
>>>>>> but I see some problems:
>>>>>
>>>>> Is part of the motivation for this approach to boot an ARMv8 system
>>>>> without using the ARM Trusted Firmware?
>>>>>
>>>>> Yours,
>>>>> Linus Walleij
>>>>
>>>> Yes, exactly.
>>>>
>>>> It would be the best choice
>>>> to switch over to PSCI with ATF in a long run,
>>>> but, I decided to use spin-table for the initial SoC bring-up
>>>> because of tight schedule.
>>>
>>> So if you don't have an ATF port ready, why not use U-Boot's PSCI
>>> implementation meanwhile? I think there are efforts underway to make
>>> PSCI enablement for random new boards a walk in the park (by making the
>>> PSCI support as generic as possible, CCing Chen-Yu for this).
>>
>>
>> So, you mean U-Boot can serve PSCI for ARMv8 SoCs without ATF, right?
>> (and efforts underway for further improvement)
>
> Yes, if I am not mistaken then there are patches floating around to
> achieve this.

The first part of the PSCI rework is already in master.
The second part is here:

    http://lists.denx.de/pipermail/u-boot/2016-June/258484.html

Or a rebased version:

    https://github.com/wens/u-boot-sunxi/tree/psci-improve-part2

>> I know PSCI support is available for ARMv7
>> (arch/arm/cpu/armv7/psci.S),
>> but I could not find PSCI implementation
>> in arch/arm/cpu/armv8/ directory in the mainline U-Boot.
>
> I think that's work in progress (as in "on the ML").

My work is still focused on ARMv7. However, with a lot of the code
rewritten in C and modularized, I see no reason it could be moved
up to arch/arm and reused for ARMv8. Same probably goes for the
non-secure related stuff, but I haven't looked into those yet.

The remaining bits of assembly for PSCI are:

  - exception vector table
  - PSCI secure monitor entry
  - stack setup
  - CPU entry function
  - ARMv7(?) SMP toggling (can be done in C with inline assembly)
  - ARMv7 specific cache flush

My only ARMv8 board (Pine64) is still gathering dust, and Andre
is already working on an ATF port, so it's unlikely I will spend
time there. Also I'm very unfamiliar with ARMv8.

>> I checked Chen-Yu's patches on Patchwork,
>> but I think they are mostly for improvement of ARMv7 PSCI support.
>>
>> If I am missing something,
>> could you point me to the reference, please?
>
> I think you found this yourself already in that other mail of yours?
>
>>> IIRC the spin-table boot method was just introduced to cope with cores
>>> that don't have EL3 and thus cannot provide PSCI services the normal way
>>> (and that don't want to or cannot sacrifice EL2 for that).
>>> So I am a bit wary of proliferating this SMP method.
>>
>> Proliferating?
>>
>> Many of ARM 32bit SoCs have vendor-specific SMP methods.
>
> Yes, and this is a massive PITA, but hard to change now.

Get everyone on board with PSCI? :)

Regards
ChenYu

>> On the other hand, ARM64 only has two methods; psci and spin-table.
>
> For a reason: Actually we just wanted to have PSCI only, but it turns
> out that it's not easily possible on cores that don't implement EL3
> (which is architecturally allowed and also implemented).
> So spin-table support was added to provide a fall-back for those cases.
> But if you have the choice, then PSCI is your friend.
> Please note that any support for another SMP method is very unlikely to
> ever get merged into upstream Linux.
>
>> Is this a problem?
>
> As mentioned, if you have a proper PSCI framework (as we are about to
> get for U-Boot and which ATF already provides), adding SMP support is
> not more involved than implementing spin tables. After all it's about
> specifying the pen address and possibly providing per-core power hooks.
>
> Cheers,
> Andre.
>
>>> Wouldn't it be better to help making U-Boot's PSCI stack as easy to use
>>> as possible? I don't see technical reasons that adding PSCI support for
>>> a board should be harder or more involved than adding spin-table support
>>> - in the end you need to tell it about the SMP pen, maybe providing (or
>>> faking?) reset and shutdown for 0.2 compliance.
>>
>>
>> Right.
>>
>> My motivation is to bring up Linux quickly
>> before ATF becomes ready.
>>
>> From your statement, I felt
>> efforts for the ARMv8 PSCI implementation in U-Boot are underway.
>> If so, I am definitely interested in it.
>>
>>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot