On Mon, Jul 09, 2018 at 09:41:48AM -0600, Rob Herring wrote:
> Deferred probe will currently wait forever on dependent devices to probe,
> but sometimes a driver will never exist. It's also not always critical for
> a driver to exist. Platforms can rely on default configuration from the
> bootloade
On Wed, Aug 24, 2011 at 02:51:09PM +0100, Will Deacon wrote:
> I think it's important to separate the problems of secure boot with the
> problems of installing a hypervisor. Whatever happens in secure world, we can
> expect to be dropped at either HYP mode or non-secure SVC mode. Sure, on a dev
> b
On Tue, Aug 23, 2011 at 06:18:37PM +0100, Ian Jackson wrote:
> Yes. But in the future it will do, surely ? I mean, we're working on
> bootloader protocols and this part (to do with startup cpu states and
> ownership of the various privilege levels) is only part of it.
No - at least not yet, and
On Tue, Aug 23, 2011 at 06:17:04PM +0100, Catalin Marinas wrote:
> Maybe we could allow (b) if SoC vendors don't provide a different API
> to set the HVBAR. But it means that kernels not aware of this feature
> would fail.
Oh, does this mean that ARM Ltd are starting to see the light in having
a c
On Tue, Aug 23, 2011 at 05:50:10PM +0100, Ian Jackson wrote:
> Russell King - ARM Linux writes ("Re: ARM processor mode, kernel startup, Hyp
> / secure state"):
> > We already have kernels which boot in both secure and non-secure mode
> > CPUs. There's very littl
On Tue, Aug 23, 2011 at 03:52:25PM +0100, Ian Jackson wrote:
> We're looking into porting Xen to the ARM A15 architecture. In this
> context, it's necessary to arrange for the Xen hypervisor to be
> entered from the boot loader in an appropriate processor mode.
>
> KVM needs to deal with the same
