[U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC

[Maxime Ripard <maxime.ripard@free-electrons.com>]

Hi,

On Sun, Jul 02, 2017 at 04:40:20PM +0100, André Przywara wrote:
> On 02/07/17 15:17, Maxime Ripard wrote:
> > On Wed, Jun 07, 2017 at 03:06:55PM +0100, Marc Zyngier wrote:
> >>> If that is so fundamentally broken that this is the only benefit, I
> >>> guess we might as well use some old-style SMP ops.
> >>
> >> Broken, for sure. Which is why I'm asking about the benefits of running
> >> non-secure on something that has evidently been very badly integrated,
> >> and for which non-secure is at best an afterthought.
> >>
> >> Now, if someone could try and run guests on this turd and report whether
> >> this works correctly or not, that'd be an interesting data point.
> >> Because in the absence of a TEE running on the secure side,
> >> virtualization is basically the only thing you gain from running on the
> >> non-secure side.
> > 
> > I just tried running Xen on it, with an adjustment similar to what
> > Chen-Yu made in the kernel.
> > 
> > It fails at boot, and stops with:
> > (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4
> > (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER8
> > (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER12
> > (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER16
> > (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER20
> > (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER24
> > (XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0
> 
> Those messages are normal and happen on every machine. The Xen VGIC
> implementation cannot clear the active flag [1] (for more complex
> reasons), and fortunately Linux and other OSes actually don't need it,
> so we get away with it. What the kernel does here is to make sure that
> no IRQ is active, which is basically a NOP on a pristine and just
> initialized (V)GIC.

Ok.

> But you said that it stopped at boot? Are you sure that your Xen setup
> works in the first place? Xen on A20 seems to be somewhat supported, by
> maybe there is some other A83T speciality that gets in the way?

It's basically stalled, yes, and didn't start dom0. I tested Xen in
the past on an A33, and it worked like a charm, but it might very well
be a PEBKAC.

> A more reliable and easier to debug test would be KVM, I guess.
> You can use kvmtool[2] instead of QEMU if that is too complex to setup:
> $ lkvm run -k zImage -p console=ttyS0
> gives you a shell in a guest, if you want to have a proper rootfs:
> $ lkvm run -k zImage -d somerootfs.img -p "console=ttyS0 root=/dev/vda"

I didn't know kvmtool, thanks for the tip.

Icenowy seems to had it running, so I guess we can just focus on KVM
for now.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170703/f2fd6daf/attachment.sig>