2018-01-25 11:49 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:
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
When I use -kernel and -initrd instead of -bios in qemu command line, then the kernel boots successfully.
-- With best regards, Matwey V. Kornilov
-- 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