qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise ma


From: Leif Lindholm
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type
Date: Thu, 30 Aug 2018 09:31:18 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, Aug 30, 2018 at 03:07:29PM +0800, Hongbo Zhang wrote:
> >> Yes, I am working on the v3, with main changes:
> >>  - machine name "sbsa-ref" (good name?)
> >>  - a separate file sbsa-ref.c
> >>  - don't touch the acpi c file, acpi will be supplied by uefi
> >
> > I agree with the above three bullets.
> >
> >>  - only necessary dt node, no other peripheral dt nodes
> >
> > I'm not sure what DT nodes are necessary. After discussing the
> > ACPI tables, and that firmware would supply them, I thought we
> > also agreed firmware would supply the DTB.
>
> Yes, firmware supply ACPI to load OS.
> But for DT, It is said that UEFI still needs some DT nodes, at least
> for memory size. I am trying to figure out which DT nodes are
> mandatory too, it is better we don't have any DT nodes left.
> 
> @Ard, @Leif, is there any possibility to remove all the DT nodes?
> On real hardware, how does UEFI find the memory size and CPU number?

Usually by asking some form of SCP/PMU.
So until we have rock-solid multi-cpu-instance (making terms up here,
there may be a proper name already?) support upstream, we need to take
shortcuts.

Using DT in the same way as we do for mach-virt when booting the OS
with ACPI seems the most logical choice to me.

The best alternative I can think of would be extending fw_cfg, but
that would then be lost effort once (if) we get to the abovementioned
situation, whereas the DT route comes for free.

/
    Leif



reply via email to

[Prev in Thread] Current Thread [Next in Thread]