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?
2017-11-08 23:07 GMT+03:00 Alexander Graf <[email protected]>: > > > On 08.11.17 21:00, Matwey V. Kornilov wrote: >> Hi, >> >> I am trying to run >> openSUSE-Tumbleweed-ARM-JeOS-efi.armv7l-2017.10.29-Build1.7.raw >> using qemu. >> >> When I use qemu-system-aarch64 with 64-bit UEFI code >> aavmf-aarch64-code.bin then the only I see is the EFI console: >> >> UEFI Interactive Shell v2.287477C2-69C7-11D2-8E39-00A0C969723B B8F1C820 >> >> EDK IIlProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA B8F1FF18 >> >> UEFI v2.60 (EDK II, 0x00010000)008-7F9B-4F30-87AC-60C9FEF5DA4E B8348710 >> >> Mapping table >> FS0: Alias(s):HD1a0b:;BLK2: >> >> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004) >> BLK5: Alias(s): >> VenHw(F9B94AE2-8BA6-409B-9D56-B9B417F53CB3) >> BLK0: Alias(s): >> VenHw(8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F) >> BLK1: Alias(s): >> >> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0) >> BLK3: Alias(s): >> >> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(2,GPT,3DF8DD35-94BC-4FF0-B74C-12853D4B1811,0x65000,0x83004) >> BLK4: Alias(s): >> >> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(3,GPT,38C4AA8C-4A7F-49C4-BCFD-6C2C755496BD,0xE8800,0x3DE781) >> >> Press ESC in 1 seconds to skip startup.nsh or any other key to continue. >> FSOpen: Open '\startup.nsh' Success >> FSOpen: Open '\startup.nsh' Success >> FSOpen: Open '\startup.nsh' Success >> Shell> bootarm >> FSOpen: Open '\efi\boot\bootarm.EFI' Success >> FSOpen: Open '\efi\boot\bootarm.EFI' Success >> FSOpen: Open '\efi\boot\bootarm.EFI' Success >> FSOpen: Open '\efi\boot\bootarm.EFI' Success >> [Security] 3rd party image[0] can be loaded after EndOfDxe: >> VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000)/Scsi(0x0,0x0)/HD(1,GPT,E30D92E4-F475-4D50-9D3D-DF05DA812008,0x800,0x64004)/\efi\boot\bootarm.EFI. >> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B8EDE440 >> Unloading driver at 0x00000000000 >> Shell> Error Status: Unsupported (line number 1) >> >> >> As far as I understand, 64-bit Qemu UEFI code doesn't expect to see and >> run 32-bit EFI executable. > > Correct, as far as UEFI is concerned, a 32bit ARM binary could as well > be a MIPS one ;). It's a different, unsupported platform for it. > >> When I try to use qemu-uefi-aarch32.bin as firmware, then I see the >> following: >> >> Initialization of device cfi.pflash01 failed: failed to read the initial >> flash content >> >> As far as I understand, qemu-uefi-aarch32.bin is in wrong format, but >> there are no other files in ovfm rpm package. > > Which ovmf package are you looking at? I'm not sure we properly package > OVMF for AArch32. But you can always try with the Linaro built ones :) > > http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-ARM/RELEASE_GCC5/ > >> What is the proper way to run JeOS-efi.armv7? Is it supposed to work in >> qemu? > > It should work, yes. It should also work on any platform that has distro > boot enabled and runs with recent U-Boot. > > > Alex -- With best regards, Matwey V. Kornilov -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
