On Fri, Mar 22, 2024 at 2:20 AM Marcin Juszkiewicz <marcin.juszkiew...@linaro.org> wrote: > > 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. >
OpenSBI also has DT support only. So a minimalistic DT generated by the machine for the firmware is required for RISC-V as well. > 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.
