On 08.11.17 21:17, Matwey V. Kornilov wrote:

On 08.11.2017 23:07, Alexander Graf wrote:

...

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...

Well, the last thing I see using linaro's DEBUG build is the following:

SetUefiImageMemoryAttributes - 0x00000000BBA48000 - 0x0000000000002000 (0x0000000000004000) Found Timer interrupts 29, 30, 27, 26 InstallProtocolInterface: 26BACCB3-6F42-11D4-BCE7-0080C73C8881 BBA48010 Loading driver E660EA85-058E-4B55-A54B-F02F83A24707 InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BAF790A8 add-symbol-file /home/buildslave/workspace/leg-virt-tianocore-edk2-upstream/edk2/Build/ArmVirtQemu-ARM/DEBUG_GCC5/ARM/MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe/DEBUG/DisplayEngine.dll 0xBBA26000 Loading driver at 0x000BBA25000 EntryPoint=0x000BBA26031 DisplayEngine.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BAF79990 ProtectUefiImageCommon - 0xBAF790A8 - 0x00000000BBA25000 - 0x000000000001C000 SetUefiImageMemoryAttributes - 0x00000000BBA25000 - 0x0000000000001000 (0x0000000000004000) SetUefiImageMemoryAttributes - 0x00000000BBA26000 - 0x0000000000017000 (0x0000000000020000) SetUefiImageMemoryAttributes - 0x00000000BBA3D000 - 0x0000000000004000 (0x0000000000004000)

Then happens nothing but 100% CPU load.

The file on the link I provided works just fine for me: $ qemu-system-arm -nographic -M virt -cpu cortex-a15 -bios QEMU_EFI.fd Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 08.11.17 21:24, Matwey V. Kornilov wrote:

On 08.11.2017 23:22, Alexander Graf wrote:

...

On 08.11.17 21:17, Matwey V. Kornilov wrote:

...

On 08.11.2017 23:07, Alexander Graf wrote:

...

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...

Well, the last thing I see using linaro's DEBUG build is the following:

SetUefiImageMemoryAttributes - 0x00000000BBA48000 - 0x0000000000002000 (0x0000000000004000) Found Timer interrupts 29, 30, 27, 26 InstallProtocolInterface: 26BACCB3-6F42-11D4-BCE7-0080C73C8881 BBA48010 Loading driver E660EA85-058E-4B55-A54B-F02F83A24707 InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BAF790A8 add-symbol-file /home/buildslave/workspace/leg-virt-tianocore-edk2-upstream/edk2/Build/ArmVirtQemu-ARM/DEBUG_GCC5/ARM/MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe/DEBUG/DisplayEngine.dll 0xBBA26000 Loading driver at 0x000BBA25000 EntryPoint=0x000BBA26031 DisplayEngine.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BAF79990 ProtectUefiImageCommon - 0xBAF790A8 - 0x00000000BBA25000 - 0x000000000001C000 SetUefiImageMemoryAttributes - 0x00000000BBA25000 - 0x0000000000001000 (0x0000000000004000) SetUefiImageMemoryAttributes - 0x00000000BBA26000 - 0x0000000000017000 (0x0000000000020000) SetUefiImageMemoryAttributes - 0x00000000BBA3D000 - 0x0000000000004000 (0x0000000000004000)

Then happens nothing but 100% CPU load.

The file on the link I provided works just fine for me:

$ qemu-system-arm -nographic -M virt -cpu cortex-a15 -bios QEMU_EFI.fd

What is your qemu version? Mine is

...

qemu-system-arm --version QEMU emulator version 2.9.1(openSUSE Leap 42.3)

$ qemu-system-arm --version QEMU emulator version 2.10.1(Virtualization / SLE_12) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 09.11.2017 10:25, Matwey V. Kornilov wrote:

2017-11-08 23:57 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 08.11.17 21:24, Matwey V. Kornilov wrote:

...

On 08.11.2017 23:22, Alexander Graf wrote:

...

On 08.11.17 21:17, Matwey V. Kornilov wrote:

...

On 08.11.2017 23:07, Alexander Graf wrote:

...

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...

Well, the last thing I see using linaro's DEBUG build is the following:

SetUefiImageMemoryAttributes - 0x00000000BBA48000 - 0x0000000000002000 (0x0000000000004000) Found Timer interrupts 29, 30, 27, 26 InstallProtocolInterface: 26BACCB3-6F42-11D4-BCE7-0080C73C8881 BBA48010 Loading driver E660EA85-058E-4B55-A54B-F02F83A24707 InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BAF790A8 add-symbol-file /home/buildslave/workspace/leg-virt-tianocore-edk2-upstream/edk2/Build/ArmVirtQemu-ARM/DEBUG_GCC5/ARM/MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe/DEBUG/DisplayEngine.dll 0xBBA26000 Loading driver at 0x000BBA25000 EntryPoint=0x000BBA26031 DisplayEngine.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BAF79990 ProtectUefiImageCommon - 0xBAF790A8 - 0x00000000BBA25000 - 0x000000000001C000 SetUefiImageMemoryAttributes - 0x00000000BBA25000 - 0x0000000000001000 (0x0000000000004000) SetUefiImageMemoryAttributes - 0x00000000BBA26000 - 0x0000000000017000 (0x0000000000020000) SetUefiImageMemoryAttributes - 0x00000000BBA3D000 - 0x0000000000004000 (0x0000000000004000)

Then happens nothing but 100% CPU load.

The file on the link I provided works just fine for me:

$ qemu-system-arm -nographic -M virt -cpu cortex-a15 -bios QEMU_EFI.fd

What is your qemu version? Mine is

...

qemu-system-arm --version QEMU emulator version 2.9.1(openSUSE Leap 42.3)

$ qemu-system-arm --version QEMU emulator version 2.10.1(Virtualization / SLE_12)

Alex

Thanks, now it almost works. I managed to run with 2.9.1 and Linaro's DEBUG UEFI image. However, I only Grub works well. The kernel seems to be not booted. I set loglevel=8 and console=ttyS0,115200 manually in grub config, but still don't see any info from the kernel.

Booting a command list

Loading linux.vmx... Loading initrd.vmx... PciBus: Disable Bus Master of all devices... Bus# Device# Function# NewCommand SetUefiImageMemoryAttributes - 0x00000000BBDBE000 - 0x0000000000009000 (0x0000000000000000) SetUefiImageMemoryAttributes - 0x00000000BBDB1000 - 0x000000000000D000 (0x0000000000000000) SetUefiImageMemoryAttributes - 0x00000000BBD36000 - 0x000000000007B000 (0x0000000000000000) SetUefiImageMemoryAttributes - 0x00000000BBD2D000 - 0x0000000000009000 (0x0000000000000000) SetUefiImageMemoryAttributes - 0x00000000BBD23000 - 0x000000000000A000 (0x0000000000000000) SetUefiImageMemoryAttributes - 0x00000000BBD1A000 - 0x0000000000009000 (0x0000000000000000) SetUefiImageMemoryAttributes - 0x00000000BBD11000 - 0x0000000000009000 (0x0000000000000000)

By the way. Does the OVMF generate FDT for the kernel? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 10.11.2017 14:38, Andreas Färber wrote:

Am 09.11.2017 um 08:25 schrieb Matwey V. Kornilov:

...

2017-11-08 23:57 GMT+03:00 Alexander Graf <agraf@suse.de>:

...

On 08.11.17 21:24, Matwey V. Kornilov wrote:

...

On 08.11.2017 23:22, Alexander Graf wrote:

...

On 08.11.17 21:17, Matwey V. Kornilov wrote:

...

On 08.11.2017 23:07, Alexander Graf wrote: > > > 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...

Well, the last thing I see using linaro's DEBUG build is the following:

SetUefiImageMemoryAttributes - 0x00000000BBA48000 - 0x0000000000002000 (0x0000000000004000) Found Timer interrupts 29, 30, 27, 26 InstallProtocolInterface: 26BACCB3-6F42-11D4-BCE7-0080C73C8881 BBA48010 Loading driver E660EA85-058E-4B55-A54B-F02F83A24707 InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BAF790A8 add-symbol-file /home/buildslave/workspace/leg-virt-tianocore-edk2-upstream/edk2/Build/ArmVirtQemu-ARM/DEBUG_GCC5/ARM/MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe/DEBUG/DisplayEngine.dll 0xBBA26000 Loading driver at 0x000BBA25000 EntryPoint=0x000BBA26031 DisplayEngine.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BAF79990 ProtectUefiImageCommon - 0xBAF790A8 - 0x00000000BBA25000 - 0x000000000001C000 SetUefiImageMemoryAttributes - 0x00000000BBA25000 - 0x0000000000001000 (0x0000000000004000) SetUefiImageMemoryAttributes - 0x00000000BBA26000 - 0x0000000000017000 (0x0000000000020000) SetUefiImageMemoryAttributes - 0x00000000BBA3D000 - 0x0000000000004000 (0x0000000000004000)

Then happens nothing but 100% CPU load.

The file on the link I provided works just fine for me:

$ qemu-system-arm -nographic -M virt -cpu cortex-a15 -bios QEMU_EFI.fd

What is your qemu version? Mine is

...

qemu-system-arm --version QEMU emulator version 2.9.1(openSUSE Leap 42.3)

$ qemu-system-arm --version QEMU emulator version 2.10.1(Virtualization / SLE_12)

Alex

Thanks, now it almost works. I managed to run with 2.9.1 and Linaro's DEBUG UEFI image. However, I only Grub works well. The kernel seems to be not booted. I set loglevel=8 and console=ttyS0,115200 manually in

Try ttyAMA0 instead.

Hm, no luck.

Regards, Andreas

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

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? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

2018-01-24 19:43 GMT+03:00 Matwey V. Kornilov <matwey.kornilov@gmail.com>:

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.

Shell> drivers T D D Y C I R P F A V VERSION E G G #D #C DRIVER NAME IMAGE NAME == ======== = = = == == =================================== ========== 6B 0000000A D - - 1 - Platform Console Management Driver ConPlatformDxe 6C 0000000A D - - 1 - Platform Console Management Driver ConPlatformDxe 6D 0000000A B - - 1 1 Console Splitter Driver ConSplitterDxe 6E 0000000A ? - - - - Console Splitter Driver ConSplitterDxe 6F 0000000A ? - - - - Console Splitter Driver ConSplitterDxe 70 0000000A B - - 1 1 Console Splitter Driver ConSplitterDxe 71 0000000A B - - 1 1 Console Splitter Driver ConSplitterDxe 75 0000000A ? - - - - Graphics Console Driver GraphicsConsoleDxe 76 0000000A B - - 1 1 Serial Terminal Driver TerminalDxe 77 0000000A D - - 1 - Generic Disk I/O Driver DiskIoDxe 78 0000000B ? - - - - Partition Driver(MBR/GPT/El Torito) PartitionDxe 79 0000000A ? - - - - FAT File System Driver Fat 7C 00000010 ? - - - - UDF File System Driver UdfDxe 7D 00000010 ? - - - - Virtio Block Driver VirtioBlkDxe 7E 00000010 B - - 1 1 Virtio Network Driver VirtioNetDxe 7F 00000010 ? - - - - Virtio SCSI Host Driver VirtioScsiDxe 80 00000010 ? - - - - Virtio Random Number Generator Driv VirtioRngDxe 81 0000000A B - - 1 1 ARP Network Service Driver ArpDxe 82 0000000A B - - 1 1 DHCP Protocol Driver Dhcp4Dxe 83 0000000A B - - 2 10 IP4 Network Service Driver Ip4Dxe 84 0000000A B - - 1 2 MNP Network Service Driver MnpDxe 85 0000000A B - - 1 1 VLAN Configuration Driver VlanConfigDxe 86 0000000A B - - 2 2 MTFTP4 Network Service Mtftp4Dxe 87 0000000A B - - 2 2 Tcp Network Service Driver Tcp4Dxe 88 0000000A B - - 6 10 UDP Network Service Driver Udp4Dxe 89 0000000A D - - 6 - UEFI PXE Base Code Driver UefiPxe4BcDxe 8A 0000000A D - - 1 - iSCSI Driver IScsi4Dxe 8C 0000000A ? - - - - SCSI Bus Driver ScsiBus 8D 0000000A ? - - - - Scsi Disk Driver ScsiDisk 8E 0000000A B - - 1 2 PCI Bus Driver PciBusDxe 90 00000010 D - - 1 - Virtio PCI Driver VirtioPciDeviceDxe 91 00000010 ? - - - - Virtio 1.0 PCI Driver Virtio10 92 00000010 ? - - - - Virtio GPU Driver VirtioGpuDxe 93 00000020 ? - - - - Usb Uhci Driver UhciDxe 94 00000030 ? - - - - Usb Ehci Driver EhciDxe 95 00000030 ? - - - - Usb Xhci Driver XhciDxe 96 0000000A ? - - - - Usb Bus Driver UsbBusDxe 97 0000000A ? - - - - Usb Keyboard Driver UsbKbDxe 98 00000011 ? - - - - Usb Mass Storage Driver UsbMassStorageDxe

Linaro's image has the same behavior. -- 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

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 Handle 0x7f260f90 loaded image Handle 0x7f260a90 decompress Handle 0x7f25a490 /MMap(b,1000,1fffff)/EndEntire 220e73b6-6bdb-4413-8405-b974b108619a device path 8f644fa9-e850-4db1-9ce2-0b44698e8da4 Handle 0x7f1e9f90 /UnknownMedia(7)/EndEntire 220e73b6-6bdb-4413-8405-b974b108619a device path 8f644fa9-e850-4db1-9ce2-0b44698e8da4 Handle 0x7f1e6790 fc1bcdb0-7d31-49aa-936a-a4600d9dd083 Handle 0x7ef05a10 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ef05590 fd0f4478-0efd-461d-ba2d-e58c45fd5f5e 5be40f57-fa68-4610-bbbf-e9c5fcdad365 13a3f0f6-264a-3ef0-f2e0-dec512342f34 11b34006-d85b-4d0a-a290-d5a571310ef7 Handle 0x7ef02890 e11faca0-4710-4c8e-a7a2-01baa2591b4c bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ef02510 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eefab90 26baccb1-6f42-11d4-bce7-0080c73c8881 Handle 0x7eeffc10 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eeff890 b7dfb4e1-052f-449f-87be-9818fc91b733 Handle 0x7eeff810 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eeff490 a46423e3-4617-49f1-b9ff-d1bfa9115839 94ab2f58-1438-4ef1-9152-18941a3a0e68 Handle 0x7eefcf10 15853d7c-3ddf-43e0-a1cb-ebf85b8f872c Handle 0x7eefc990 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eefc410 /HardwareVendor(f9b94ae2-8ba6-409b-9d56-b9b417f53cb3)[0: ]/EndEntire disk block device path Handle 0x7eefbe90 /HardwareVendor(8047db4b-7e9c-4c0c-8ebc-dfbbaacace8f)[0: ]/EndEntire disk 8f644fa9-e850-4db1-9ce2-0b44698e8da4 block device path Handle 0x7eefb910 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eefb390 6441f818-6362-4e44-b570-7dba31dd2453 1e5668e2-8481-11d4-bcf1-0080c73c8881 af23b340-97b4-4685-8d4f-a3f28169b21d cd3d0a05-9e24-437c-a891-1ee053db7638 Handle 0x7eef9a90 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eef9290 26baccb2-6f42-11d4-bce7-0080c73c8881 Handle 0x7eef9490 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eee6d90 1a1241e6-8f19-41a9-bc0e-e8ef39e06546 HII image 0a8badd5-03b8-4d19-b128-7b8f0edaa596 HII config routing HII database HII string HII font Handle 0x7eee6510 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eef3b90 /HardwareVendor(d3987d4b-971a-435f-8caf-4967eb627241)[0: ]/UART(38400,8,1,1) /EndEntire device path serial Handle 0x7eef3890 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eef3290 device path from text device path to text device path utilities Handle 0x7eef3490 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eef2b10 480f8ae9-0c46-4aa9-bc89-db9fba619806 Handle 0x7eef2a90 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eef2510 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 00 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef8f90 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 02 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef8d90 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 04 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef8a10 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 06 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef8890 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 08 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef8610 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 0a 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef8210 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 0c 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef7010 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 0e 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef7e90 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 10 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef7d10 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 12 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef7990 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 14 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef7710 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 16 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef7490 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 18 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef7310 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 1a 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef6b10 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 1c 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef6c10 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 1e 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef6a90 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 20 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef6910 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 22 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef6690 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 24 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef6410 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 26 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef5f10 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 28 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef5b90 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 2a 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef5090 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 2c 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef5810 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 2e 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef5590 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 30 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef5510 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 32 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef5390 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 34 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef4e10 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 36 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef4c90 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 38 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef4790 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 3a 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef4110 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 3c 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eef4190 /HardwareVendor(837dca9e-e874-4d82-b29a-23fe0e23d1e2)[8: 00 3e 00 0a 00 00 00 00 ]/EndEntire fa920010-6785-4941-b6ec-498c579f160a device path Handle 0x7eeeb010 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eeebd10 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eeeb590 3ebd9e82-2c78-4de6-9786-8d4bfcb7c881 Handle 0x7eeeb510 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eeeac90 9da34ae0-eaf9-4bbf-8ec3-fd60226c44be 27cfac88-46cc-11d4-9a38-0090273fc14d Handle 0x7eeea990 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eeea390 27cfac87-46cc-11d4-9a38-0090273fc14d Handle 0x7eef0f10 27cfac87-46cc-11d4-9a38-0090273fc14d Handle 0x7eef0e90 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eef0890 32898322-2da1-474a-baaa-f3f7cf569470 2890b3ea-053d-1643-ad0c-d64808da3ff1 Handle 0x7eeefd90 3c7200e9-005f-4ea4-87de-a3dfac8a27c3 6a1ee763-d47a-43b4-aabe-ef1de2ab56fc bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eeef410 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eeecc90 b9d4c360-bcfb-4f9b-9298-53c136982258 Handle 0x7eeeca10 1f73b18d-4630-43c1-a1de-6f80855d7da4 a770c357-b693-4e6d-a6cf-d21c728e550b Handle 0x7eeec710 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eee9b10 665e3ff6-46cc-11d4-9a38-0090273fc14d Handle 0x7eee9d10 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eee9110 03583ff6-cb36-4940-947e-b9b39f4afaf7 Handle 0x7eee9490 7ebb920d-1aaf-46d9-b2af-541e1dce148b bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ef02690 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eee8790 ad61f191-ae5f-4c0e-b9fa-e869d288c64f Handle 0x7eee8710 6a1ee763-d47a-43b4-aabe-ef1de2ab56fc bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eee7a10 53cd299f-2bc1-40c0-8c07-23f64fdb30e0 Handle 0x7eee7990 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eee7410 5053697e-2cbc-4819-90d9-0580deee5754 Handle 0x7eea1c90 f0e6a44f-7195-41c3-ac64-54f202cd0a21 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7eea1990 /HardwareVendor(f0e6a44f-7195-41c3-ac64-54f202cd0a21)[0: ]/EndEntire HII configuration access device path Handle 0x7ee9ff90 /HardwareVendor(5daf50a5-ea81-4de2-8f9b-cabda9cf5c14)[0: ]/EndEntire HII configuration access device path Handle 0x7ee9ef90 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee9e990 1da97072-bddc-4b30-99f1-72a0b56fff2a Handle 0x7ee9e710 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee9db10 26baccb3-6f42-11d4-bce7-0080c73c8881 Handle 0x7ee9da10 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee96a90 4311edc0-6054-46d4-9e40-893ea952fccc 9bbe29e9-fda1-41ec-ad52-452213742d2e Handle 0x7ee97490 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee94f90 /HardwareVendor(ebf8ed7c-0dd1-4787-84f1-f48d537dcacf)[0: ]/EndEntire HII configuration access device path Handle 0x7ee93490 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee93710 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee8a910 30cfe3e7-3de1-4586-be20-deaba1b3b793 cf8034be-6768-4d8b-b739-7cce683a9fbe Handle 0x7ee8a790 /ACPI(a0341d0,0)/EndEntire PCI root device path Handle 0x7ee89f10 /HardwareVendor(d9dcc5df-4007-435e-9098-8970935504b2)[0: ]/EndEntire HII configuration access device path bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee89810 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee91890 /HardwareVendor(28a03ff4-12b3-4305-a417-bb1a4f94081e)[0: ]/EndEntire HII configuration access device path Handle 0x7ee8ff90 /HardwareVendor(2a46715f-3581-4a55-8e73-2b769aaa30c5)[0: ]/EndEntire HII configuration access device path Handle 0x7ee8ed90 28a03ff4-12b3-4305-a417-bb1a4f94081e ab38a0df-6873-44a9-87e6-d4eb56148449 Handle 0x7ee90910 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee90210 665e3ff5-46cc-11d4-9a38-0090273fc14d Handle 0x7ee8e190 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee8e610 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding Handle 0x7ee8e390 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee8c990 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding Handle 0x7ee8c110 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding Handle 0x7ee8c690 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding Handle 0x7ee8c210 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding Handle 0x7ee8bb10 absolute pointer simple pointer dd9e7534-7762-4698-8c14-f58517a625aa simple text input Handle 0x7ee88e10 simple text output Handle 0x7ee88a10 simple text output Handle 0x7ee88a90 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee80790 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee87c90 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee87690 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee86c90 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee86690 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee85f10 a4c751fc-23ae-4c3e-92e9-4964cf63f349 unicode collation Handle 0x7ee85e10 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee85710 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee84d10 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee84710 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee81d10 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee81710 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee7fd10 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee7f710 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee7e110 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee7e390 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee75090 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee75310 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee7d090 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee7d310 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee7c090 59324945-ec44-4c0d-b1cd-9db139df070c component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee7c210 /HardwareVendor(6456ed61-3579-41c9-8a26-0a0bd62b78fc)[0: ]/EndEntire HII configuration access device path Handle 0x7ee7af10 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee7b910 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee79c90 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee79790 19cb87ab-2cb9-4665-8360-ddcf6054f79d Handle 0x7ee79490 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee78d10 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee78690 component name 2 EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee77e90 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee77210 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee76e90 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee76210 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee74e90 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee74210 component name 2 107a772c-d5e1-11d4-9a46-0090273fc14d EFI driver binding bc62157e-3e33-4fec-9920-2d3b36d750df loaded image Handle 0x7ee56c90 /ACPI(a0341d0,0)/PCI(0,0)/EndEntire PCI device path Handle 0x7ee55b10 /ACPI(a0341d0,0)/PCI(0,1)/EndEntire fa920010-6785-4941-b6ec-498c579f160a 4006c0c1-fcb3-403e-996d-4a6c8724e06d PCI device path Handle 0x7ee55d10 /ACPI(a0341d0,0)/PCI(0,2)/EndEntire disk block fa920010-6785-4941-b6ec-498c579f160a PCI device path Handle 0x7ee20190 /HardwareVendor(d3987d4b-971a-435f-8caf-4967eb627241)[0: ]/UART(38400,8,1,1) /MessagingVendor(dfa66065-b419-11d3-9a2d-0090273fc14d)[0: ]/EndEntire d3b36f2d-d551-11d4-9a46-0090273fc14d d3b36f2c-d551-11d4-9a46-0090273fc14d d3b36f2b-d551-11d4-9a46-0090273fc14d device path simple text output dd9e7534-7762-4698-8c14-f58517a625aa simple text input Handle 0x7de16b10 /ACPI(a0341d0,0)/PCI(0,1)/MacAddr(52:54:00:12:34:56,1)/EndEntire 4579b72d-7ec4-4dd4-8486-083c86b182a7 load file pxe 2fe800be-8f01-4aa6-946b-d71388e1833f 9d9a39d8-bd42-4a73-a4d5-8ee94be11380 83f01464-99bd-45e5-b383-af6305d8e9e6 00720665-67eb-4a99-baf7-d3c33a1c7cc9 e4f61863-fe2c-4b56-a8f4-08519bc439df 5b446ed1-e30b-4faa-871a-3654eca36080 c51711e7-b4bf-404a-bfb8-0a048ef1ffe4 f44c00ee-1f2c-4a00-aa09-1c9f3e0800a3 f36ff770-a7e1-42cf-9ed2-56f0f271f44c 9e23d768-d2f3-4366-9fc3-3a7aba864374 device path network Handle 0x7dd15c90 7ab33a91-ace5-4326-b572-e7ee33d39f16 Handle 0x7dcf3a90 7ab33a91-ace5-4326-b572-e7ee33d39f16 Handle 0x7dcf2990 /ACPI(a0341d0,0)/PCI(0,1)/MacAddr(52:54:00:12:34:56,1) /HardwareVendor(9fb1a1f3-3b71-4324-b39a-745cbb015fff)[0: ]/EndEntire HII configuration access device path Handle 0x7dcef510 /ACPI(a0341d0,0)/PCI(0,1)/MacAddr(52:54:00:12:34:56,1) /HardwareVendor(d79df6b0-ef44-43bd-9797-43e93bcf5fa8)[0: ]/EndEntire HII configuration access device path Handle 0x7dcee190 41d94cd2-35b6-455a-8258-d4e51334aadd Handle 0x7dceb710 41d94cd2-35b6-455a-8258-d4e51334aadd Handle 0x7dce8a90 41d94cd2-35b6-455a-8258-d4e51334aadd Handle 0x7dce8610 3ad9df29-4501-478d-b1f8-7f7fe70e50f3 Handle 0x7dce3710 41d94cd2-35b6-455a-8258-d4e51334aadd Handle 0x7dce2f90 3ad9df29-4501-478d-b1f8-7f7fe70e50f3 Handle 0x7dce2890 f4b427bb-ba21-4f16-bc4e-43e416ab619c Handle 0x7dce2490 8a219718-4ef5-4761-91c8-c0f04bda9e56 Handle 0x7dcd6010 41d94cd2-35b6-455a-8258-d4e51334aadd Handle 0x7dcd6a90 41d94cd2-35b6-455a-8258-d4e51334aadd Handle 0x7dcd6a10 3ad9df29-4501-478d-b1f8-7f7fe70e50f3 Handle 0x7dcd5010 78247c57-63db-4708-99c2-a8b4a9a61f6b Handle 0x7dcd5090 41d94cd2-35b6-455a-8258-d4e51334aadd Handle 0x7dcd5910 3ad9df29-4501-478d-b1f8-7f7fe70e50f3 Handle 0x7dcd5290 41d94cd2-35b6-455a-8258-d4e51334aadd Handle 0x7dcd4f10 3ad9df29-4501-478d-b1f8-7f7fe70e50f3 Handle 0x7dcd4a10 143b7632-b81b-4cb7-abd3-b625a5b9bffe Handle 0x7dcd4710 65530bc7-a359-410f-b010-5aadc7ec2b62 Handle 0x7dcd2f10 41d94cd2-35b6-455a-8258-d4e51334aadd Handle 0x7ee7a710 /ACPI(a0341d0,0)/PCI(0,2)/HD(1,800,64004,c30053f90c498e4a,2,2)/EndEntire simple FS disk c12a7328-f81f-11d2-ba4b-00a0c93ec93b 8cf2f62c-bc9b-4821-808d-ec9ec421a1a0 block device path Handle 0x7dcc1a90 /ACPI(a0341d0,0)/PCI(0,2)/HD(2,65000,8c804,6854a839332f1d42,2,2)/EndEntire disk 8cf2f62c-bc9b-4821-808d-ec9ec421a1a0 block device path Handle 0x7dcc1390 /ACPI(a0341d0,0)/PCI(0,2)/HD(3,f2000,437f81,e08fa6a941fcda4e,2,2)/EndEntire disk 8cf2f62c-bc9b-4821-808d-ec9ec421a1a0 block device path Handle 0x7dcc2590 bc62157e-3e33-4fec-9920-2d3b36d750df loaded image

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

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. grub> dump 0x7ffde000 100 d0 0d fe ed 00 01 10 00 00 00 00 40 00 00 1a 70 00 00 00 30 00 00 00 11 00 00

lsefisystab Address: 0x7fc24010 Signature: 5453595320494249 revision: 00020046 Vendor: EDK II, Version=10000 11 tables: 0x7f260a10 fc1bcdb0-7d31-49aa-936aa4600d9dd083 CRC32 GUIDED SECTION EXTRACTION 0x7fc57b58 05ad34ba-6f02-4214-952e4da0398e2bb9 DXE SERVICES 0x7f25e010 7739f24c-93d7-11d4-9a3a0090273fc14d HOB LIST 0x7fc577e8 4c19049f-4137-4dd3-9c108b97a83ffdfa MEMORY TYPE INFO 0x7fc58b28 49152e77-1ada-4764-b7a27afefed95e8b DEBUG IMAGE INFO 0x7fc24f90 a4ee0728-e5d7-4ac5-b21e658ed857e834 0x7ffde000 b1b621d5-f19c-41a5-830bd9152c69aae0 0x7fa86000 eb9d2d31-2d88-11d3-9a160090273fc14d SMBIOS 0x7fa84000 f2fd1544-9794-4a2c-992ee5bbcf20e394 0x7fa82f90 d719b2cb-3d3a-4596-a3bcdad00e67656f 0x7d773a90 dcfa911d-26eb-469f-a22038b7dc461220

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

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? /dts-v1/; / { interrupt-parent = <0x8001>; #size-cells = <0x2>; #address-cells = <0x2>; compatible = "linux,dummy-virt"; platform@c000000 { interrupt-parent = <0x8001>; ranges = <0x0 0x0 0xc000000 0x2000000>; #address-cells = <0x1>; #size-cells = <0x1>; compatible = "qemu,platform", "simple-bus"; }; fw-cfg@9020000 { dma-coherent; reg = <0x0 0x9020000 0x0 0x18>; compatible = "qemu,fw-cfg-mmio"; }; virtio_mmio@a000000 { dma-coherent; interrupts = <0x0 0x10 0x1>; reg = <0x0 0xa000000 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a000200 { dma-coherent; interrupts = <0x0 0x11 0x1>; reg = <0x0 0xa000200 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a000400 { dma-coherent; interrupts = <0x0 0x12 0x1>; reg = <0x0 0xa000400 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a000600 { dma-coherent; interrupts = <0x0 0x13 0x1>; reg = <0x0 0xa000600 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a000800 { dma-coherent; interrupts = <0x0 0x14 0x1>; reg = <0x0 0xa000800 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a000a00 { dma-coherent; interrupts = <0x0 0x15 0x1>; reg = <0x0 0xa000a00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a000c00 { dma-coherent; interrupts = <0x0 0x16 0x1>; reg = <0x0 0xa000c00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a000e00 { dma-coherent; interrupts = <0x0 0x17 0x1>; reg = <0x0 0xa000e00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a001000 { dma-coherent; interrupts = <0x0 0x18 0x1>; reg = <0x0 0xa001000 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a001200 { dma-coherent; interrupts = <0x0 0x19 0x1>; reg = <0x0 0xa001200 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a001400 { dma-coherent; interrupts = <0x0 0x1a 0x1>; reg = <0x0 0xa001400 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a001600 { dma-coherent; interrupts = <0x0 0x1b 0x1>; reg = <0x0 0xa001600 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a001800 { dma-coherent; interrupts = <0x0 0x1c 0x1>; reg = <0x0 0xa001800 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a001a00 { dma-coherent; interrupts = <0x0 0x1d 0x1>; reg = <0x0 0xa001a00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a001c00 { dma-coherent; interrupts = <0x0 0x1e 0x1>; reg = <0x0 0xa001c00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a001e00 { dma-coherent; interrupts = <0x0 0x1f 0x1>; reg = <0x0 0xa001e00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a002000 { dma-coherent; interrupts = <0x0 0x20 0x1>; reg = <0x0 0xa002000 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a002200 { dma-coherent; interrupts = <0x0 0x21 0x1>; reg = <0x0 0xa002200 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a002400 { dma-coherent; interrupts = <0x0 0x22 0x1>; reg = <0x0 0xa002400 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a002600 { dma-coherent; interrupts = <0x0 0x23 0x1>; reg = <0x0 0xa002600 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a002800 { dma-coherent; interrupts = <0x0 0x24 0x1>; reg = <0x0 0xa002800 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a002a00 { dma-coherent; interrupts = <0x0 0x25 0x1>; reg = <0x0 0xa002a00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a002c00 { dma-coherent; interrupts = <0x0 0x26 0x1>; reg = <0x0 0xa002c00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a002e00 { dma-coherent; interrupts = <0x0 0x27 0x1>; reg = <0x0 0xa002e00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a003000 { dma-coherent; interrupts = <0x0 0x28 0x1>; reg = <0x0 0xa003000 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a003200 { dma-coherent; interrupts = <0x0 0x29 0x1>; reg = <0x0 0xa003200 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a003400 { dma-coherent; interrupts = <0x0 0x2a 0x1>; reg = <0x0 0xa003400 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a003600 { dma-coherent; interrupts = <0x0 0x2b 0x1>; reg = <0x0 0xa003600 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a003800 { dma-coherent; interrupts = <0x0 0x2c 0x1>; reg = <0x0 0xa003800 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a003a00 { dma-coherent; interrupts = <0x0 0x2d 0x1>; reg = <0x0 0xa003a00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a003c00 { dma-coherent; interrupts = <0x0 0x2e 0x1>; reg = <0x0 0xa003c00 0x0 0x200>; compatible = "virtio,mmio"; }; virtio_mmio@a003e00 { dma-coherent; interrupts = <0x0 0x2f 0x1>; reg = <0x0 0xa003e00 0x0 0x200>; compatible = "virtio,mmio"; }; gpio-keys { #address-cells = <0x1>; #size-cells = <0x0>; compatible = "gpio-keys"; poweroff { gpios = <0x8003 0x3 0x0>; linux,code = <0x74>; label = "GPIO Key Poweroff"; }; }; pl061@9030000 { phandle = <0x8003>; clock-names = "apb_pclk"; clocks = <0x8000>; interrupts = <0x0 0x7 0x4>; gpio-controller; #gpio-cells = <0x2>; compatible = "arm,pl061", "arm,primecell"; reg = <0x0 0x9030000 0x0 0x1000>; }; pcie@10000000 { interrupt-map-mask = <0x1800 0x0 0x0 0x7>; interrupt-map = <0x0 0x0 0x0 0x1 0x8001 0x0 0x0 0x0 0x3 0x4 0x0 0x0 0x0 0x2 0x8001 0x0 0x0 0x0 0x4 0x4 0x0 0x0 0x0 0x3 0x8001 0x0 0x0 0x0 0x5 0x4 0x0 0x0 0x0 0x4 0x8001 0x0 0x0 0x0 0x6 0x4 0x800 0x0 0x0 0x1 0x8001 0x0 0x0 0x0 0x4 0x4 0x800 0x0 0x0 0x2 0x8001 0x0 0x0 0x0 0x5 0x4 0x800 0x0 0x0 0x3 0x8001 0x0 0x0 0x0 0x6 0x4 0x800 0x0 0x0 0x4 0x8001 0x0 0x0 0x0 0x3 0x4 0x1000 0x0 0x0 0x1 0x8001 0x0 0x0 0x0 0x5 0x4 0x1000 0x0 0x0 0x2 0x8001 0x0 0x0 0x0 0x6 0x4 0x1000 0x0 0x0 0x3 0x8001 0x0 0x0 0x0 0x3 0x4 0x1000 0x0 0x0 0x4 0x8001 0x0 0x0 0x0 0x4 0x4 0x1800 0x0 0x0 0x1 0x8001 0x0 0x0 0x0 0x6 0x4 0x1800 0x0 0x0 0x2 0x8001 0x0 0x0 0x0 0x3 0x4 0x1800 0x0 0x0 0x3 0x8001 0x0 0x0 0x0 0x4 0x4 0x1800 0x0 0x0 0x4 0x8001 0x0 0x0 0x0 0x5 0x4>; #interrupt-cells = <0x1>; ranges = <0x1000000 0x0 0x0 0x0 0x3eff0000 0x0 0x10000 0x2000000 0x0 0x10000000 0x0 0x10000000 0x0 0x2eff0000 0x3000000 0x80 0x0 0x80 0x0 0x80 0x0>; reg = <0x0 0x3f000000 0x0 0x1000000>; msi-parent = <0x8002>; dma-coherent; bus-range = <0x0 0xf>; #size-cells = <0x2>; #address-cells = <0x3>; device_type = "pci"; compatible = "pci-host-ecam-generic"; }; pl031@9010000 { status = "disabled"; clock-names = "apb_pclk"; clocks = <0x8000>; interrupts = <0x0 0x2 0x4>; reg = <0x0 0x9010000 0x0 0x1000>; compatible = "arm,pl031", "arm,primecell"; }; pl011@9000000 { clock-names = "uartclk", "apb_pclk"; clocks = <0x8000 0x8000>; interrupts = <0x0 0x1 0x4>; reg = <0x0 0x9000000 0x0 0x1000>; compatible = "arm,pl011", "arm,primecell"; }; intc { phandle = <0x8001>; reg = <0x0 0x8000000 0x0 0x10000 0x0 0x8010000 0x0 0x10000>; compatible = "arm,cortex-a15-gic"; ranges; #size-cells = <0x2>; #address-cells = <0x2>; interrupt-controller; #interrupt-cells = <0x3>; v2m { phandle = <0x8002>; reg = <0x0 0x8020000 0x0 0x1000>; msi-controller; compatible = "arm,gic-v2m-frame"; }; }; flash@0 { bank-width = <0x4>; reg = <0x0 0x0 0x0 0x4000000 0x0 0x4000000 0x0 0x4000000>; compatible = "cfi-flash"; }; psci { migrate = <0x84000005>; cpu_on = <0x84000003>; cpu_off = <0x84000002>; cpu_suspend = <0x84000001>; method = "hvc"; compatible = "arm,psci-0.2", "arm,psci"; }; cpus { #size-cells = <0x0>; #address-cells = <0x1>; cpu@0 { reg = <0x0>; compatible = "arm,cortex-a15"; device_type = "cpu"; }; }; timer { interrupts = <0x1 0xd 0x104 0x1 0xe 0x104 0x1 0xb 0x104 0x1 0xa 0x104>; always-on; compatible = "arm,armv7-timer"; }; apb-pclk { phandle = <0x8000>; clock-output-names = "clk24mhz"; clock-frequency = <0x16e3600>; #clock-cells = <0x0>; compatible = "fixed-clock"; }; memory { reg = <0x0 0x40000000 0x0 0x40000000>; device_type = "memory"; }; chosen { stdout-path = "/pl011@9000000"; }; };

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

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

Surprisingly it works. Thank you. However, with -m 1024 it stil doesn't work. 2018-02-17 0:41 GMT+03:00 Alexander Graf <agraf@suse.de>:

On 25.01.18 22:16, Matwey V. Kornilov wrote:

...

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.

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