Hi Michael, would it make sense to run SCT (using UnixHost and/or qemu) to verify the high level logic or do you think that would be too much to do for each PR? Also, do we want to run all these check

Thanks for linking that issue. I'd really like to see that getting solved. As for ninja: Yes it usually reduces build time a lot because unlike make it uses a very simple and fast to parse language an

Out of curiosity I took a closer look at how the build system works internall(especially the Makefile generation and parallel builds) and I got some questions which I hope you can answer: Why are we u

ElfConvert iterates over the section headers and handles the following section types: SHT_PROGBITS: Copy SHT_NOBITS: memset to 0 the default case looks like this: // // Ignore for unkown section type.

yes I'll do that next time. Thanks for the hint. Thanks Michael

Hi Ard, yes that fixes the problem too and looks much better, thx!

This was the warning(shown for __aeabi_memcpy, __aeabi_memcpy4 and __aeabi_memcpy8): ArmPkg/Library/CompilerIntrinsicsLib/memcpy.c:42:6: error: '__aeabi_memcpy8' alias between functions of incompatibl

CC the arm maintainers <sigmaepsilon92@...> wrote:

From: M1cha <sigmaepsilon92@...> GCC8 reported it with the following warning: ArmPkg/Library/ArmDisassemblerLib/ArmDisassembler.c: In function 'DisassembleArmInstruction': ArmPkg/Library/ArmDisa

I looked at ARMs TimerDxe and saw that mTimerNotifyFunction is called with TPL_HIGH_LEVEL but didn't realize that RestoreTPL would call all pending events. Thank you for your help. wrote: wrote: VFP V

But isn't that only necessary if you assume that interrupt-handlers use VFP registers? afaik on ARM <TPL_HIGH_LEVEL events are never called from the timer interrupt handler so basically if you're goin

So basically using them should be safe as long as you're in EfiGetCurrentTpl() < TPL_HIGH_LEVEL, right? Also, it'd probably be trivial to add VFP/NEON regs to EFI_SYSTEM_CONTEXT_ARM though that wouldn

For AArch32 the spec says in 2.3.5.3: extensions must not be used. For AArch64 the spec says in 2.3.6.4: So is there a reason why AArch32 is not allowed to use Floating point operations? I'd understan

Well since the fastboot implementation already is an application (and not a driver) all we need to do is to use WaitEvent instead of a notify callback. Once that's fixed I'd add ASSERTs on the current

Surprisingly no. I was just trying to understand the fastboot implementation before I use it on my platform and was surprised that this works at all. I can imagine that's because this is supposed to l

I feel like both of you misunderstood my intention. As I said in my initial mail, I'm not arguing the spec - I know that StartImage must be called from TPL_APPLICATION. I'm just discussing a bug insid

Are you sure? If you look at this file: https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/Application/AndroidFastboot/AndroidFastbootApp.c The DataReady Event is a TPL_CALLBACK event. From the

From looking at the code it seems to me that StartImage is called from TPL_CALLBACK. According to the Spec StartImage can only be called from <TPL_CALLBACK. If the current code actually works it means

This currently isn't needed by anything in the edk2 tree but it's useful for externally maintained platforms which have to set this register e.g. to disable alignment aborts. Contributed-under: TianoC

We're currently building everything except for this file. Since 'fdt_create_empty_tree' can be useful for some platforms, compile this one too. Contributed-under: TianoCore Contribution Agreement 1.1