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 <agraf@suse.de>:
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-upstre...
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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org