Surprisingly it works. Thank you. However, with -m 1024 it stil doesn't work.
2018-02-17 0:41 GMT+03:00 Alexander Graf <ag...@suse.de>: > > > On 25.01.18 22:16, Matwey V. Kornilov wrote: >> 2018-01-25 11:49 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: >>> 2018-01-25 11:11 GMT+03:00 Matwey V. Kornilov <matwey.korni...@gmail.com>: >>>> 2018-01-25 0:28 GMT+03:00 Alexander Graf <ag...@suse.de>: >>>>> >>>>> >>>>> On 24.01.18 20:29, Matwey V. Kornilov wrote: >>>>>> 2018-01-24 22:05 GMT+03:00 Alexander Graf <ag...@suse.de>: >>>>>>> >>>>>>> >>>>>>> On 24.01.18 18:10, Matwey V. Kornilov wrote: >>>>>>>> 2018-01-24 19:51 GMT+03:00 Alexander Graf <ag...@suse.de>: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 24.01.18 17:43, Matwey V. Kornilov wrote: >>>>>>>>>> 2018-01-24 16:38 GMT+03:00 Alexander Graf <ag...@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. > > 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 -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
