On 01/08/16 04:10, Shannon Zhao wrote:
>
>
> 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?
How long did it take ARM (the architecture) to grow *one* standardized
firmware? :)
Anyhow, I guess a -machine sub-option could be introduced (later) that
controls the generation of the RTC ACPI device directly. (For now, the
default should be as described above, I think.)
Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
