2018-01-25 11:11 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:
2018-01-25 0:28 GMT+03:00 Alexander Graf <agraf@suse.de>:
On 24.01.18 20:29, Matwey V. Kornilov wrote:
2018-01-24 22:05 GMT+03:00 Alexander Graf <agraf@suse.de>:
On 24.01.18 18:10, Matwey V. Kornilov wrote:
2018-01-24 19:51 GMT+03:00 Alexander Graf <agraf@suse.de>:
On 24.01.18 17:43, Matwey V. Kornilov wrote: > 2018-01-24 16:38 GMT+03:00 Alexander Graf <agraf@suse.de>: >> >> >> 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?
Sure, I've managed to dump and decomile FDT. As far as I don't see any output, something is wrong either with serial port or interrupt controller?
Hm, with qemu debug and grub debug on, I see the following: Jumping to Linux... Taking exception 4 [Data Abort] ...from EL1 to EL1 ...with ESR 0x25/0x96000037 ...with DFSR 0x37 DFAR 0xfffdd000 -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org