On 25.01.18 22:16, Matwey V. Kornilov wrote: > 2018-01-25 11:49 GMT+03:00 Matwey V. Kornilov <[email protected]>: >> 2018-01-25 11:11 GMT+03:00 Matwey V. Kornilov <[email protected]>: >>> 2018-01-25 0:28 GMT+03:00 Alexander Graf <[email protected]>: >>>> >>>> >>>> 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? >>>> >>> >>> 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.
I just ran across a very similar issue and it boiled down to the fact that grub puts the DT outside the linear memory map of Linux. Can you try to boot with -m 768 to ensure we always fit? That should make it work. Thanks, Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
