On 24.01.18 20:29, Matwey V. Kornilov wrote: > 2018-01-24 22:05 GMT+03:00 Alexander Graf <[email protected]>: >> >> >> On 24.01.18 18:10, Matwey V. Kornilov wrote: >>> 2018-01-24 19:51 GMT+03:00 Alexander Graf <[email protected]>: >>>> >>>> >>>> On 24.01.18 17:43, Matwey V. Kornilov wrote: >>>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <[email protected]>: >>>>>> >>>>>> >>>>>> On 24.01.18 13:15, Matwey V. Kornilov wrote: >>>>>>> Hi, >>>>>>> >>>>>>> There is one more thing that is unclear to me now. As far as I >>>>>>> understand there is no other way except FDT to provide hardware layout >>>>>>> for armv7l kernel. Then, who is responsible for FDT loading? As far as >>>>>>> I understand it is grub2 task to load FDT from the table at >>>>>>> b1b621d5-f19c-41a5-.... And FDT is completely provided by UEFI >>>>>>> firmware. In case of u-boot, dtb file is loaded from the disk by means >>>>>>> of u-boot and placed into memory. What should happen here when OVMF is >>>>>>> used? In theory, it has to be configured to generate FDT from QEMU >>>>>>> config somehow, right? Or pass-through entire FDT from Qemu >>>>>>> hypervisor? >>>>>> >>>>>> It basically passes through the device tree that's generated by QEMU, >>>>>> yes. However, OVMF defaults changed a while back and it only exposes >>>>>> ACPI tables instead of DT in newer versions on AArch64 IIRC. >>>>>> >>>>>> Maybe something went wrong and they changed them for armv7 as well by >>>>>> accident? >>>>>> >>>>> >>>>> I use latest version of aarch32 OVMF firmware from openSUSE:Factory:ARM. >>>>> Well, then, I suppose, I have to see appropriate EFI driver >>>>> (FdtClientDxe ? ) in the driver list. >>>> >>>> I don't think the fact that the driver is loaded tells you anything. >>>> >>>> I assume you can't boot the VM properly? Does grub see the DT table? >>>> lsefi in grub should show you iirc. >>>> >>>> If it doesn't show it, but instead shows ACPI tables, can you try to >>>> pass -no-acpi to QEMU? >>>> >>> >>> There is nothing FDT-related at GRUB side. This is why I started to >>> search who is responsible for providing FDT. >>> -no-acpi also doesn't change anything. >>> >>> grub> lsefi >> >> Hm, that is the object list. Maybe it was lsefisystab? >> > > Ok, here FDT is present (b1b621d5-...). How can I dump it from grub console? > If I do it right, then It has correct magic header 0xd00dfeed.
Looks all green to me then. I guess you actually get into the kernel then with a working device tree, but just don't see output? Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
