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.
--
Shannon
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
