public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* DxeCore assert during initialization
@ 2017-02-23 17:16 Marcin Wojtas
  2017-02-23 17:17 ` Ard Biesheuvel
  0 siblings, 1 reply; 8+ messages in thread
From: Marcin Wojtas @ 2017-02-23 17:16 UTC (permalink / raw)
  To: edk2-devel-01
  Cc: Tian, Feng, Kinney, Michael D, Leif Lindholm, Ard Biesheuvel,
	semihalf-dabros-jan, Gao, Liming, yonghong.zhu

Hi,

I use Marvell Armada70x0 from mainline OpenPlatformPkg. After updating
baseline to newest tianocore master branch it turned out that the
platform fail to boot due to following assert:

/home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
0x1800
add-symbol-file
/home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
0x3F534800
Loading DxeCore at 0x003F534000 EntryPoint=0x003F534800

ASSERT_EFI_ERROR (Status = Invalid Parameter)
ASSERT [DxeCore]
/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c(523):
!EFI_ERROR (Status)

I bisected edk2 master branch and confirmed that the problem appeared
with commit dc4c770763d0 ("BaseTools: add error check for Macro usage
in the INF file").

There are no errors, nor warnings during BaseTool and platform builds.
Is it a known problem? Any idea about possible root cause?

Best regards,
Marcin


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: DxeCore assert during initialization
  2017-02-23 17:16 DxeCore assert during initialization Marcin Wojtas
@ 2017-02-23 17:17 ` Ard Biesheuvel
  2017-02-23 17:29   ` Laszlo Ersek
  2017-02-23 17:34   ` Marcin Wojtas
  0 siblings, 2 replies; 8+ messages in thread
From: Ard Biesheuvel @ 2017-02-23 17:17 UTC (permalink / raw)
  To: Marcin Wojtas
  Cc: edk2-devel-01, Tian, Feng, Kinney, Michael D, Leif Lindholm,
	semihalf-dabros-jan, Gao, Liming, Zhu, Yonghong

On 23 February 2017 at 17:16, Marcin Wojtas <mw@semihalf.com> wrote:
> Hi,
>
> I use Marvell Armada70x0 from mainline OpenPlatformPkg. After updating
> baseline to newest tianocore master branch it turned out that the
> platform fail to boot due to following assert:
>
> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
> 0x1800
> add-symbol-file
> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> 0x3F534800
> Loading DxeCore at 0x003F534000 EntryPoint=0x003F534800
>
> ASSERT_EFI_ERROR (Status = Invalid Parameter)
> ASSERT [DxeCore]
> /home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c(523):
> !EFI_ERROR (Status)
>
> I bisected edk2 master branch and confirmed that the problem appeared
> with commit dc4c770763d0 ("BaseTools: add error check for Macro usage
> in the INF file").
>
> There are no errors, nor warnings during BaseTool and platform builds.
> Is it a known problem? Any idea about possible root cause?
>

Already fixed in
1d8cebf91040 BaseTools: Fix the regression issue caused by commit dc4c77

Regards,
Ard.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: DxeCore assert during initialization
  2017-02-23 17:17 ` Ard Biesheuvel
@ 2017-02-23 17:29   ` Laszlo Ersek
  2017-02-23 17:33     ` Laszlo Ersek
  2017-02-23 17:34   ` Marcin Wojtas
  1 sibling, 1 reply; 8+ messages in thread
From: Laszlo Ersek @ 2017-02-23 17:29 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Marcin Wojtas, Tian, Feng, edk2-devel-01, Gao, Liming,
	Leif Lindholm, Kinney, Michael D

On 02/23/17 18:17, Ard Biesheuvel wrote:
> On 23 February 2017 at 17:16, Marcin Wojtas <mw@semihalf.com> wrote:
>> Hi,
>>
>> I use Marvell Armada70x0 from mainline OpenPlatformPkg. After updating
>> baseline to newest tianocore master branch it turned out that the
>> platform fail to boot due to following assert:
>>
>> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
>> 0x1800
>> add-symbol-file
>> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>> 0x3F534800
>> Loading DxeCore at 0x003F534000 EntryPoint=0x003F534800
>>
>> ASSERT_EFI_ERROR (Status = Invalid Parameter)
>> ASSERT [DxeCore]
>> /home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c(523):
>> !EFI_ERROR (Status)
>>
>> I bisected edk2 master branch and confirmed that the problem appeared
>> with commit dc4c770763d0 ("BaseTools: add error check for Macro usage
>> in the INF file").
>>
>> There are no errors, nor warnings during BaseTool and platform builds.
>> Is it a known problem? Any idea about possible root cause?
>>
> 
> Already fixed in
> 1d8cebf91040 BaseTools: Fix the regression issue caused by commit dc4c77

Yes, it is.

However, I'm seeing another problem (perhaps I should have started a separate thread with this):

> [Bds]=============Begin Load Options Dumping ...=============
>   Driver Options:
>   SysPrep Options:
>   Boot Options:
>     Boot0005: Red Hat Enterprise Linux 		 0x0001
>     Boot0001: UEFI QEMU QEMU CD-ROM  		 0x0001
>     Boot0000: UiApp 		 0x0109
>     Boot0002: UEFI Misc Device 		 0x0001
>     Boot0003: UEFI Misc Device 2 		 0x0001
>     Boot0006: EFI Internal Shell 		 0x0001
>   PlatformRecovery Options:
>     PlatformRecovery0000: Default PlatformRecovery 		 0x0001
> [Bds]=============End Load Options Dumping=============
> [Bds]BdsWait ...Zzzzzzzzzzzz...
> [Bds]BdsWait(5)..Zzzz...
> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD 139389420
> InstallProtocolInterface: 3AD9DF29-4501-478D-B1F8-7F7FE70E50F3 139389EB8
> InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C 139388030
> InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C 13939A2B0
> [Bds]BdsWait(4)..Zzzz...
> [Bds]BmHotkeyCallback: 0017:0000
> [Bds]Hotkey for Boot0000 pressed - Success
> [Bds]Exit the waiting!
> [Bds] Booting Boot Manager Menu.
> [Bds]Stop Hotkey Service!
> [Bds]UnregisterKeyNotify: 000C/0000 Success
> [Bds]UnregisterKeyNotify: 0017/0000 Success
> [Bds]UnregisterKeyNotify: 0000/000D Success
> Memory  Previous  Current    Next
>  Type    Pages     Pages     Pages
> ======  ========  ========  ========
>   09    00000000  00000080  000000A0
>   0A    00000000  00000020  00000028
>   00    00000000  00000004  00000005
>   06    00000258  00000410  00000514
>   05    00000190  000002C0  00000370
>   03    000005DC  0000056E  000005DC
>   04    00002EE0  00002CF1  00002EE0
>   01    00000014  00000000  00000014
>   02    00000000  00000000  00000000
> Memory Type Information settings change.
> [Bds]Booting UiApp
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 1393E05C0
> add-symbol-file .../Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll 0x13838D000
> Loading driver at 0x0013838C000 EntryPoint=0x0013838D000 UiApp.efi
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 138D1B498
> ProtectUefiImageCommon - 0x393E05C0
>   - 0x000000013838C000 - 0x0000000000044000
>   Image - .../Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
>   Section - '.text   '
>   VirtualSize          - 0x0003D000
>   VirtualAddress       - 0x00001000
>   SizeOfRawData        - 0x0003D000
>   PointerToRawData     - 0x00001000
>   PointerToRelocations - 0x00000000
>   PointerToLinenumbers - 0x00000000
>   NumberOfRelocations  - 0x00000000
>   NumberOfLinenumbers  - 0x00000000
>   Characteristics      - 0x60000020
> ImageCode: 0x000000013838D000 - 0x000000000003D000
>   Section - '.data   '
>   Section - '.reloc  '
> ImageCode SegmentCount - 0x1
> SetUefiImageMemoryAttributes - 0x000000013838C000 - 0x0000000000001000 (0x0000000000004008)
> SetUefiImageMemoryAttributes - 0x000000013838D000 - 0x000000000003D000 (0x0000000000020008)
> SetUefiImageMemoryAttributes - 0x00000001383CA000 - 0x0000000000006000 (0x0000000000004008)
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 13A690F98
> InstallProtocolInterface: 330D4706-F2A0-4E4F-A369-B66FA8D54385 1383CB150
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 1383CB300
> InstallProtocolInterface: 330D4706-F2A0-4E4F-A369-B66FA8D54385 1383CB2D0
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 1383CB498
> InstallProtocolInterface: 330D4706-F2A0-4E4F-A369-B66FA8D54385 1383CB4C8
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B 1383CB598
> InstallProtocolInterface: 330D4706-F2A0-4E4F-A369-B66FA8D54385 1383CB5E8
> ^[[2J^[[01;01H
> 
> Synchronous Exception at 0x000000013838F070
> PC 0x00013838F070 (0x00013838C000+0x00003070) [ 0] UiApp.dll
> PC 0x00013838EFF4 (0x00013838C000+0x00002FF4) [ 0] UiApp.dll
> PC 0x00013838F508 (0x00013838C000+0x00003508) [ 0] UiApp.dll
> PC 0x00013838D980 (0x00013838C000+0x00001980) [ 0] UiApp.dll
> PC 0x00013838D064 (0x00013838C000+0x00001064) [ 0] UiApp.dll
> PC 0x00013EC71E50 (0x00013EC6B000+0x00006E50) [ 1] DxeCore.dll
> PC 0x00013BA5D62C (0x00013BA4A000+0x0001362C) [ 2] BdsDxe.dll
> PC 0x00013BA62D5C (0x00013BA4A000+0x00018D5C) [ 2] BdsDxe.dll
> PC 0x00013BA4D580 (0x00013BA4A000+0x00003580) [ 2] BdsDxe.dll
> PC 0x00013EC6D768 (0x00013EC6B000+0x00002768) [ 3] DxeCore.dll
> PC 0x00013EC6C828 (0x00013EC6B000+0x00001828) [ 3] DxeCore.dll
> PC 0x00013EC6C024 (0x00013EC6B000+0x00001024) [ 3] DxeCore.dll
> 
> [ 0] .../Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.dll
> [ 1] .../Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> [ 2] .../Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll
> [ 3] .../Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> 
>   X0 0x00000001383C6E94   X1 0x0000000000000050   X2 0x0000000000000000   X3 0x000000013EC6AAA4
>   X4 0x0000000000000004   X5 0x0000000000000000   X6 0x0000000138396978   X7 0x00000003000001E0
>   X8 0x0000000000000000   X9 0x0000000000000000  X10 0x000001E000000280  X11 0x0000000000000003
>  X12 0x0000000000000000  X13 0x0000028000000000  X14 0x0052004100571400  X15 0x0047004E0049004E
>  X16 0x000000013EC6AC00  X17 0x0000000000000000  X18 0x0000000000000000  X19 0x0000000138D1B698
>  X20 0x000000013B632018  X21 0x0000000000000000  X22 0x0000000000000000  X23 0x0000000000000000
>  X24 0x0000000000000000  X25 0x0000000000000000  X26 0x0000000000000000  X27 0x0000000000000000
>  X28 0x0000000000000000   FP 0x000000013EC6AAD0   LR 0x000000013838EFF4
> 
>   V0 0xAFAFAFAFAFAFAFAF AFAFAFAFAFAFAFAF   V1 0x622D6963702F6666 6666666666666666
>   V2 0x632F304069736373 2F31406567646972   V3 0x0000000000000000 0000000000000000
>   V4 0x0000000000000000 0000000000000000   V5 0x4010040140100401 4010040140100401
>   V6 0x0000000000000000 0000000000000000   V7 0x0000000000000000 0000000000000000
>   V8 0x0000000000000000 0000000000000000   V9 0x0000000000000000 0000000000000000
>  V10 0x0000000000000000 0000000000000000  V11 0x0000000000000000 0000000000000000
>  V12 0x0000000000000000 0000000000000000  V13 0x0000000000000000 0000000000000000
>  V14 0x0000000000000000 0000000000000000  V15 0x0000000000000000 0000000000000000
>  V16 0x0000000000000000 0000000000000000  V17 0x0000000000000000 0000000000000000
>  V18 0x0000000000000000 0000000000000000  V19 0x0000000000000000 0000000000000000
>  V20 0x0000000000000000 0000000000000000  V21 0x0000000000000000 0000000000000000
>  V22 0x0000000000000000 0000000000000000  V23 0x0000000000000000 0000000000000000
>  V24 0x0000000000000000 0000000000000000  V25 0x0000000000000000 0000000000000000
>  V26 0x0000000000000000 0000000000000000  V27 0x0000000000000000 0000000000000000
>  V28 0x0000000000000000 0000000000000000  V29 0x0000000000000000 0000000000000000
>  V30 0x0000000000000000 0000000000000000  V31 0x0000000000000000 0000000000000000
> 
>   SP 0x000000013EC6AAD0  ELR 0x000000013838F070  SPSR 0x60000205  FPSR 0x00000000
>  ESR 0x9600004F          FAR 0x00000001383C6E94
> 
>  ESR : EC 0x25  IL 0x1  ISS 0x0000004F
> 
> Data abort: Permission fault, third level
> 
> Stack dump:
>   000013EC6A9D0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>   000013EC6A9F0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>   000013EC6AA10: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>   000013EC6AA30: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>   000013EC6AA50: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>   000013EC6AA70: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>   000013EC6AA90: 0000000000000000 0000000000000000 000000013838F070 0000000060000205
>   000013EC6AAB0: 0000000000000000 000000009600004F 00000001383C6E94 0000000000000004
> > 000013EC6AAD0: 000000013EC6AB60 000000013838F508 0000000000000000 0100000000000000
>   000013EC6AAF0: 4010040140100401 4010040140100401 0000000000000000 0000000000000000
>   000013EC6AB10: 000000013936D318 0000000000000024 000000013B94D1C0 000000013B94D250
>   000013EC6AB30: 0000000000000000 0000000000000000 0000001938396978 000001E000000050
>   000013EC6AB50: 0000000000000280 0000002500000003 000000013EC6ABB0 000000013838D980
>   000013EC6AB70: 000000013BFF0018 000000013A690B18 0000000000000019 0000000000000050
>   000013EC6AB90: 000000013B94D1C0 000000013B94D250 000000013937AC98 0000000000000000
>   000013EC6ABB0: 000000013EC6ABD0 000000013838D064 000000013BFF0018 000000013A690B18
> ASSERT [ArmCpuDxe] .../ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(265): ((BOOLEAN)(0==1))

This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU v2.8.0-1290-gc3618551719b, using TCG.

The compiler I used to build ArmVirtQemu is

aarch64-linux-gnu-gcc (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2)

Thanks
Laszlo


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: DxeCore assert during initialization
  2017-02-23 17:29   ` Laszlo Ersek
@ 2017-02-23 17:33     ` Laszlo Ersek
  2017-02-23 17:38       ` Ard Biesheuvel
  0 siblings, 1 reply; 8+ messages in thread
From: Laszlo Ersek @ 2017-02-23 17:33 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Tian, Feng, edk2-devel-01, Leif Lindholm, Gao, Liming,
	Kinney, Michael D

On 02/23/17 18:29, Laszlo Ersek wrote:

> This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU v2.8.0-1290-gc3618551719b, using TCG.

Hm, I have some patches in QEMU, so that hash will likely not resolve on
your side. The first upstream ancestor is e295a154c2a9.

Thanks
Laszlo


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: DxeCore assert during initialization
  2017-02-23 17:17 ` Ard Biesheuvel
  2017-02-23 17:29   ` Laszlo Ersek
@ 2017-02-23 17:34   ` Marcin Wojtas
  1 sibling, 0 replies; 8+ messages in thread
From: Marcin Wojtas @ 2017-02-23 17:34 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: edk2-devel-01, Tian, Feng, Kinney, Michael D, Leif Lindholm,
	semihalf-dabros-jan, Gao, Liming, Zhu, Yonghong

Hi Ard,

2017-02-23 18:17 GMT+01:00 Ard Biesheuvel <ard.biesheuvel@linaro.org>:
> On 23 February 2017 at 17:16, Marcin Wojtas <mw@semihalf.com> wrote:
>> Hi,
>>
>> I use Marvell Armada70x0 from mainline OpenPlatformPkg. After updating
>> baseline to newest tianocore master branch it turned out that the
>> platform fail to boot due to following assert:
>>
>> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
>> 0x1800
>> add-symbol-file
>> /home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>> 0x3F534800
>> Loading DxeCore at 0x003F534000 EntryPoint=0x003F534800
>>
>> ASSERT_EFI_ERROR (Status = Invalid Parameter)
>> ASSERT [DxeCore]
>> /home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c(523):
>> !EFI_ERROR (Status)
>>
>> I bisected edk2 master branch and confirmed that the problem appeared
>> with commit dc4c770763d0 ("BaseTools: add error check for Macro usage
>> in the INF file").
>>
>> There are no errors, nor warnings during BaseTool and platform builds.
>> Is it a known problem? Any idea about possible root cause?
>>
>
> Already fixed in
> 1d8cebf91040 BaseTools: Fix the regression issue caused by commit dc4c77

Thank you for very fast response. The fix indeed helps. Just for the
notice top of the master fails to build due to commit cfb0aba7934b
("MdeModulePkg: Add performance property configuration table").


/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c:
In function ‘DxeCorePerformanceLibConstructor’:
/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c:538:3:
error: passing argument 2 of ‘EfiGetSystemConfigurationTable’ from
incompatible pointer type [-Werror]
   Status = EfiGetSystemConfigurationTable (&gPerformanceProtocolGuid,
&PerformanceProperty);
   ^
In file included from
/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLibInternal.h:35:0,
                 from
/home/mw/git/edk2/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c:26:
/home/mw/git/edk2/MdePkg/Include/Library/UefiLib.h:135:1: note:
expected ‘void **’ but argument is of type ‘struct
PERFORMANCE_PROPERTY **’
 EfiGetSystemConfigurationTable (
 ^
cc1: all warnings being treated as errors
make: *** [/home/mw/git/edk2/Build/Armada70x0/DEBUG_GCC48/AARCH64/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib/OUTPUT/DxeCorePerformanceLib.obj]
Error 1

I'll stick to one revision and won't move from now on:)

Best regards,
Marcin


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: DxeCore assert during initialization
  2017-02-23 17:33     ` Laszlo Ersek
@ 2017-02-23 17:38       ` Ard Biesheuvel
  2017-02-23 17:51         ` Laszlo Ersek
  0 siblings, 1 reply; 8+ messages in thread
From: Ard Biesheuvel @ 2017-02-23 17:38 UTC (permalink / raw)
  To: Laszlo Ersek
  Cc: Tian, Feng, edk2-devel-01, Leif Lindholm, Gao, Liming,
	Kinney, Michael D

On 23 February 2017 at 17:33, Laszlo Ersek <lersek@redhat.com> wrote:
> On 02/23/17 18:29, Laszlo Ersek wrote:
>
>> This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU v2.8.0-1290-gc3618551719b, using TCG.
>
> Hm, I have some patches in QEMU, so that hash will likely not resolve on
> your side. The first upstream ancestor is e295a154c2a9.
>

Could you please double check?

$ git show e295a154c2a9
fatal: ambiguous argument 'e295a154c2a9': unknown revision or path not
in the working tree.

In any case, it faults on address 0x1383C6E94 with a data abort due to
permissions, which can only be caused by a store to read-only region.

This is at the end of the .text segment of UiApp.dll

Could you open the .dll in GDB (you may need to do 'set architecture
aarch64'), and paste the output of

disas *0x3070

?

Thanks


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: DxeCore assert during initialization
  2017-02-23 17:38       ` Ard Biesheuvel
@ 2017-02-23 17:51         ` Laszlo Ersek
  2017-02-23 17:55           ` Ard Biesheuvel
  0 siblings, 1 reply; 8+ messages in thread
From: Laszlo Ersek @ 2017-02-23 17:51 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Tian, Feng, edk2-devel-01, Leif Lindholm, Gao, Liming,
	Kinney, Michael D

On 02/23/17 18:38, Ard Biesheuvel wrote:
> On 23 February 2017 at 17:33, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 02/23/17 18:29, Laszlo Ersek wrote:
>>
>>> This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU v2.8.0-1290-gc3618551719b, using TCG.
>>
>> Hm, I have some patches in QEMU, so that hash will likely not resolve on
>> your side. The first upstream ancestor is e295a154c2a9.
>>
> 
> Could you please double check?
> 
> $ git show e295a154c2a9
> fatal: ambiguous argument 'e295a154c2a9': unknown revision or path not
> in the working tree.

That's the QEMU git hash:

e295a154c2a9 ("Merge remote-tracking branch 'remotes/dgilbert/tags/pull-hmp-20170221' into staging", 2017-02-21)

http://git.qemu-project.org/?p=qemu.git;a=commit;h=e295a154c2a9

> 
> In any case, it faults on address 0x1383C6E94 with a data abort due to
> permissions, which can only be caused by a store to read-only region.
> 
> This is at the end of the .text segment of UiApp.dll
> 
> Could you open the .dll in GDB (you may need to do 'set architecture
> aarch64'), and paste the output of
> 
> disas *0x3070

I don't have an aarch64 GDB on my laptop, but I have addr2line:

$ aarch64-linux-gnu-addr2line \
  -e Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.debug \
  0x3070
.../MdeModulePkg/Application/UiApp/FrontPage.c:834

This looks reasonable, because the crash hit after I pressed ESC on the splash screen, and was about to get in the menu.

   826    //
   827    // Set PCD to Inform GraphicsConsole to change video resolution.
   828    // Set PCD to Inform Consplitter to change text mode.
   829    //
   830    Status = PcdSet32S (PcdVideoHorizontalResolution, NewHorizontalResolution);
   831    ASSERT_EFI_ERROR (Status);
   832    Status = PcdSet32S (PcdVideoVerticalResolution, NewVerticalResolution);
   833    ASSERT_EFI_ERROR (Status);
   834    Status = PcdSet32S (PcdConOutColumn, NewColumns); <---------- here
   835    ASSERT_EFI_ERROR (Status);
   836    Status = PcdSet32S (PcdConOutRow, NewRows);
   837    ASSERT_EFI_ERROR (Status);

Disassembly with objdump:

  Status = PcdSet32S (PcdConOutColumn, NewColumns);
    3064:       f00001a0        adrp    x0, 3a000 <mHiiDefaultTypeToWidth+0x3968>
    3068:       913a5000        add     x0, x0, #0xe94
    306c:       b9407ba1        ldr     w1, [x29,#120]
    3070:       b9000001        str     w1, [x0]      <--------- here
    3074:       f90033bf        str     xzr, [x29,#96]

Does this help?

Thanks!
Laszlo


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: DxeCore assert during initialization
  2017-02-23 17:51         ` Laszlo Ersek
@ 2017-02-23 17:55           ` Ard Biesheuvel
  0 siblings, 0 replies; 8+ messages in thread
From: Ard Biesheuvel @ 2017-02-23 17:55 UTC (permalink / raw)
  To: Laszlo Ersek
  Cc: Tian, Feng, edk2-devel-01, Leif Lindholm, Gao, Liming,
	Kinney, Michael D

On 23 February 2017 at 17:51, Laszlo Ersek <lersek@redhat.com> wrote:
> On 02/23/17 18:38, Ard Biesheuvel wrote:
>> On 23 February 2017 at 17:33, Laszlo Ersek <lersek@redhat.com> wrote:
>>> On 02/23/17 18:29, Laszlo Ersek wrote:
>>>
>>>> This is with ArmVirtQemu @ c5c9e7e298ed, running on QEMU v2.8.0-1290-gc3618551719b, using TCG.
>>>
>>> Hm, I have some patches in QEMU, so that hash will likely not resolve on
>>> your side. The first upstream ancestor is e295a154c2a9.
>>>
>>
>> Could you please double check?
>>
>> $ git show e295a154c2a9
>> fatal: ambiguous argument 'e295a154c2a9': unknown revision or path not
>> in the working tree.
>
> That's the QEMU git hash:
>
> e295a154c2a9 ("Merge remote-tracking branch 'remotes/dgilbert/tags/pull-hmp-20170221' into staging", 2017-02-21)
>
> http://git.qemu-project.org/?p=qemu.git;a=commit;h=e295a154c2a9
>
>>
>> In any case, it faults on address 0x1383C6E94 with a data abort due to
>> permissions, which can only be caused by a store to read-only region.
>>
>> This is at the end of the .text segment of UiApp.dll
>>
>> Could you open the .dll in GDB (you may need to do 'set architecture
>> aarch64'), and paste the output of
>>
>> disas *0x3070
>
> I don't have an aarch64 GDB on my laptop, but I have addr2line:
>
> $ aarch64-linux-gnu-addr2line \
>   -e Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.debug \
>   0x3070
> .../MdeModulePkg/Application/UiApp/FrontPage.c:834
>
> This looks reasonable, because the crash hit after I pressed ESC on the splash screen, and was about to get in the menu.
>
>    826    //
>    827    // Set PCD to Inform GraphicsConsole to change video resolution.
>    828    // Set PCD to Inform Consplitter to change text mode.
>    829    //
>    830    Status = PcdSet32S (PcdVideoHorizontalResolution, NewHorizontalResolution);
>    831    ASSERT_EFI_ERROR (Status);
>    832    Status = PcdSet32S (PcdVideoVerticalResolution, NewVerticalResolution);
>    833    ASSERT_EFI_ERROR (Status);
>    834    Status = PcdSet32S (PcdConOutColumn, NewColumns); <---------- here
>    835    ASSERT_EFI_ERROR (Status);
>    836    Status = PcdSet32S (PcdConOutRow, NewRows);
>    837    ASSERT_EFI_ERROR (Status);
>
> Disassembly with objdump:
>
>   Status = PcdSet32S (PcdConOutColumn, NewColumns);
>     3064:       f00001a0        adrp    x0, 3a000 <mHiiDefaultTypeToWidth+0x3968>
>     3068:       913a5000        add     x0, x0, #0xe94
>     306c:       b9407ba1        ldr     w1, [x29,#120]
>     3070:       b9000001        str     w1, [x0]      <--------- here
>     3074:       f90033bf        str     xzr, [x29,#96]
>
> Does this help?
>

Yes, it does.

This bit, from BaseTools/Scripts/GccBase.lds

    /*
     * The contents of AutoGen.c files are constant from the POV of the program,
     * but most of its contents end up in .data or .bss by default since few of
     * the variable definitions that get emitted are declared as CONST.
     */
    *:AutoGen.obj(.data .data.* .bss .bss.*)

turns out to be inaccurate: AutoGen.c also contains (in this case),

.data._gPcd_BinaryPatch_PcdSetupConOutColumn

which is set by the PcdSet32S() call above.

Let me try if I can find a nice fix for this, but simply removing the
line should solve the issue for you.


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-02-23 17:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-23 17:16 DxeCore assert during initialization Marcin Wojtas
2017-02-23 17:17 ` Ard Biesheuvel
2017-02-23 17:29   ` Laszlo Ersek
2017-02-23 17:33     ` Laszlo Ersek
2017-02-23 17:38       ` Ard Biesheuvel
2017-02-23 17:51         ` Laszlo Ersek
2017-02-23 17:55           ` Ard Biesheuvel
2017-02-23 17:34   ` Marcin Wojtas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox