[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v2 2/2] hw/riscv: Add server platform reference machine
From: |
Marcin Juszkiewicz |
Subject: |
Re: [RFC v2 2/2] hw/riscv: Add server platform reference machine |
Date: |
Fri, 22 Mar 2024 10:20:34 +0100 |
User-agent: |
Mozilla Thunderbird |
W dniu 22.03.2024 o 09:50, Heinrich Schuchardt pisze:
>>> I see no mention of device trees in the spec, but I do see ACPI. Do we
>>> really expect a server platform to use DTs?
>>
>> This platform "kind of" follows sbsa-ref where we have very
>> minimalistic device tree sharing information qemu->firmware.
>>
>> libfdt is small, format is known and describes hardware. Firmware is
>> free to make use of it in any way it wants.
>>
>> On sbsa-ref we parse DT in TF-A (base firmware) and provide hardware
>> information to higher level (edk2) via SMC mechanism. Then EDK2
>> creates ACPI tables and provide them to the Operating System.
> We should ensure that only either an ACPI table or a device-tree
> description is passed to the OS and not both, e.g. when using
>
> qemu-system-riscv64 -kernel vmlinux -M sbsa-ref
>
> But that requirement is not machine specific.
I would not call "qemu-system-* -M machinename -k kernel_image" a proper
way to boot for several systems emulated by QEMU.
DeviceTree is in rvsp-ref and sbsa-ref because it is easy to process in
limited space 1st stage of firmware has.
And if we knew how people will mention 'sbsa-ref uses DT' we would use
something else instead. But that would require adding more code into
existing firmware projects (libfdt is usually already there).
I did not looked at DT generated for rvsp-ref. I know that sbsa-ref one
is too minimalistic for kernel use as we added only those fields/nodes
we need to provide data for firmware.
Re: [RFC v2 2/2] hw/riscv: Add server platform reference machine, Atish Kumar Patra, 2024/03/22