Hi,
On Mon, Jun 27, 2016 at 6:47 PM, Andre Przywara andre.przywara@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@arm.com:
Hi,
On 19/06/16 09:57, Masahiro Yamada wrote:
2016-06-18 18:40 GMT+09:00 Linus Walleij linus.walleij@linaro.org:
On Fri, Jun 17, 2016 at 2:51 PM, Masahiro Yamada yamada.masahiro@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot