From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Date: Mon, 3 Jul 2017 10:21:16 +0200 Subject: [U-Boot] [linux-sunxi] [RFC PATCH 8/8] sunxi: enable PSCI for A83T SoC In-Reply-To: <61ef9d70-8523-6735-5416-ffeeddd9e2cc@arm.com> References: <20170607065036.rlv5oif2majhxi7s@flea.lan> <40F87103-B0D5-47C0-BE60-59B84CC261F6@aosc.io> <9c72276f-5523-872d-9f69-22400ac51a11@arm.com> <20170607130427.kb6zhjqndegixquk@flea.lan> <20170702141733.6bhvzohn6fz3zs3a@flea> <61ef9d70-8523-6735-5416-ffeeddd9e2cc@arm.com> Message-ID: <20170703082116.usml2iubgvudkeoy@flea> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi, On Sun, Jul 02, 2017 at 04:40:20PM +0100, Andr=C3=A9 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 wheth= er > >> 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. > >=20 > > I just tried running Xen on it, with an adjustment similar to what > > Chen-Yu made in the kernel. > >=20 > > 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 >=20 > 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=3DttyS0 > gives you a shell in a guest, if you want to have a proper rootfs: > $ lkvm run -k zImage -d somerootfs.img -p "console=3DttyS0 root=3D/dev/vd= a" 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 --=20 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: