On 2016/1/7 22:25, Laszlo Ersek wrote:
> On 01/07/16 10:31, Shannon Zhao wrote:
>> >
>> >
>> > On 2016/1/7 16:16, Ard Biesheuvel wrote:
>>> >> On 7 January 2016 at 03:47, Shannon Zhao <zhaoshengl...@huawei.com>
>>> >> wrote:
>>>>> >>>> Hi,
>>>>> >>>>
>>>>> >>>> I notice that when booting with DTS UEFI will disable RTC device
>>>>> >>>> PL031
>>>>> >>>> in the DTS by following codes. And it turns out that only rtc-efi
>>>>> >>>> shows
>>>>> >>>> up in guest.
>>>>> >>>>
>>>>> >>>> //
>>>>> >>>> // UEFI takes ownership of the RTC hardware, and exposes its
>>>>> >>>> functionality
>>>>> >>>> // through the UEFI Runtime Services GetTime, SetTime, etc. This
>>>>> >>>> means we
>>>>> >>>> // need to disable it in the device tree to prevent the OS from
>>>>> >>>> attaching its
>>>>> >>>> // device driver as well.
>>>>> >>>> //
>>>>> >>>> if ((RtcNode != -1) &&
>>>>> >>>> fdt_setprop_string (DeviceTreeBase, RtcNode, "status",
>>>>> >>>> "disabled") != 0) {
>>>>> >>>> DEBUG ((EFI_D_WARN, "Failed to set PL031 status to 'disabled'\n"));
>>>>> >>>> }
>>>>> >>>>
>>>>> >>>> But when booting with ACPI, there are two RTC devices, rtc-efi and
>>>>> >>>> PL031(PL031 shows up when kenrel PL031 driver adds support to probe
>>>>> >>>> it
>>>>> >>>> via ACPI). And I didn't see any codes in UEFI to handle the RTC node
>>>>> >>>> in
>>>>> >>>> ACPI table.
>>>>> >>>>
>>>>> >>>> I think it's hard to modify the DSDT table in UEFI since there is
>>>>> >>>> not a
>>>>> >>>> ACPI lib like libfdt. But for consistency, does it need to handle it
>>>>> >>>> too
>>>>> >>>> when booting with ACPI?
>>>>> >>>>
>>> >> Yes, it should. I didn't spot this before, or I would have said
>>> >> something.
>>> >>
>>> >> As long as the firmware is driving the RTC, the OS should not be able
>>> >> to attach its driver directly, ACPI or DT alike.
>> >
>> > Is there a way to parse DSDT in UEFI or other ways we could use to mask
>> > the RTC device? I think maybe we could use the STAO table or something
>> > like it which is added by ACPI 6.0.
> Let's see what ways there are for booting an ARM / AARCH64 guest
> ("virt") machine type:
>
> (1) QEMU's builtin (minimal) firmware, and nothing else. There is
> nothing to *consume* ACPI.
>
> (2) QEMU's builtin (minimal) firmware, and a directly booted kernel
> (-kernel option). The kernel gets only a DTB -- there is no
> architecturally defined way to expose ACPI to the kernel.
>
> (3) explicit firmware (-bios or -pflash option), and whatever gets
> booted by the firmware. Firmware here means UEFI, period. The guest OS
> gets both DTB and ACPI (unless disabled by -no-acpi).
>
> (4) explicit firmware (-bios or -pflash opton) plus an immediately
> booted fw_cfg kernel (i.e. -kernel option as well). Firmware again means
> UEFI, the guest OS gets again both DTB and ACPI (unless disabled by
> -no-acpi).
>
> So here's what I suggest:
>
> - modify QEMU to drop the RTC device specification from *both* the DTB
> and the ACPI generator *if* an explicit firmware is passed (with -bios
> or -pflash). Because this means UEFI, and UEFI will take control of the
> RTC. Cases (1) and (2) are unaffected, and cases (3) and (4) are handled
> correctly.
>
> - modify ArmVirtPkg to remove the above quoted disabling -- QEMU should
> handle it for the DTB as well.
>
> See QEMU commit 07abe45c4814, and the "arm_boot_info.firmware_loaded"
> field -- that could be used to control the DTB and ACPI generators.
I'm a bit worried that this way is a little UEFI specific. If there is
another firmware in the future which has a different way to handle RTC,
this will not work. Or I'm over worried?
Thanks,
--
Shannon
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
