On Oct 15, 2020, at 11:24 PM, Daniele Crudo <crudo.daniele@gmail.com> wrote:

Hi, thank you Andrew.
The debug version doesn't have any issue, so the issue is only with release.

OK so the DEBUG and RELEASE both build with -Os. This is firmware things have to fit in the ROM. The big difference between DEBUG and release is the DEBUG prints get stripped out, so that usually means timing issues :(.

The compiler flags live in BaseTools/Conf/tools_def.template and you can edit them in Conf/tools_def.txt

The mac version seems to skip tftpDynamicCommand.efi and LinuxInitrdDynamicShellCommand.efi (see attached debug logs), but it's not related to this and it's not related to the logo, because the debug version as I said it just works.

What logo are your talking about? I see the TianoCore logo failed in your macOS debug log as I would expect [1]d:

"HII Image Package with logo not found in PE/COFF resource section”

I don’t see that error message in the kali log, so that matches what I would expect.

It sounds like you are talking about a logo coming from your Hackintosh EFI boot shim? Or the macOS booter?

This is all the Hackintosh stuff that is loading.

[Bds] Expand PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0) -> PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0)/HD(1,GPT,58F0B968-76EA-4F98-BD18-44DC6D57AEBA,0x800,0x7F7DF)/\EFI\BOOT\BOOTX64.EFI

Loading driver at 0x0007DDEB000 EntryPoint=0x0007DDEFE36 Bootstrap.efi

Loading driver at 0x0007DC77000 EntryPoint=0x0007DCED3A5 OpenCore.efi

Loading driver at 0x0007DDDA000 EntryPoint=0x0007DDDA5C9 AE4C11C8-1D6C-F24E-A183-E1CA36D1A8A9.efi

Loading driver at 0x0007F88E000 EntryPoint=0x0007F8920BD OpenRuntime.efi

Loading driver at 0x0007DD45000 EntryPoint=0x0007DD56C4B OpenCanopy.efi

Loading driver at 0x0007DD66000 EntryPoint=0x0007DD6FC53 AudioDxe.efi

Loading driver at 0x0007DDCE000 EntryPoint=0x0007DDD17C9 UsbMouseDxe.efi

Loading driver at 0x0007D054000 EntryPoint=0x0007D0A220C apfs.efi

And this is the macOS booter (1st stage OS loader, the thing Mac EFI firmware loads directly)

Loading driver at 0x0007CE48000 EntryPoint=0x0007CE51673 boot.efi

I will try another toolchain, just to have some time to figure out how to setup the environment.

There was some work on a CLANGPDB toolchain that worked on all platforms.

So it sounds like you have some kind of graphics issue on a RELEASE build? What happens if on a RELEASE XCODE build you just boot to the UEFI Shell?

[1] https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Logo/Logo.c#L131

Thanks,

Andrew Fish

Thank you
Il giorno ven 16 ott 2020 alle ore 04:11 Andrew Fish <afish@apple.com> ha scritto:
Daniele,

The logo issue is due to the [Hii-Binary-Package.UEFI_HII] build rule not being supported by XCODE and RVCT those toolchains don’t contain resource compilers for PE/COFF files so they can’t inject HII into PE/COFF images. I submitted patches to fix this a while back and they got stuck and I got bogged down on my day job. This reminds me I need to get those patches moving again.

Due to the issue above the XCODE build skips some drivers/apps in OVMF [1] but I don’t think that is your issue?

I don’t think it is likely that your graphics issue is related to HII resources. Most of the times when I track down the “it does not work with clang (Xcode uses clang)” it ends up being the clang compiler optimizing away undefined behavior that the other compilers ignored. I’m not sure if there is a another clang toolchain you could try? That would be helpful to know if it is likely an undefined behavior difference.

Unfortunately the graphics issue is going to be hard to track down if we can’t reproduce it locally.

[1] Easiest way to find them is:
/Volumes/Case/edk2-github(master)>git grep '$(TOOL_CHAIN_TAG) == "XCODE5"'
OvmfPkg/OvmfPkgIa32.dsc:252:!if $(TOOL_CHAIN_TAG) == "XCODE5"
OvmfPkg/OvmfPkgIa32X64.dsc:256:!if $(TOOL_CHAIN_TAG) == "XCODE5"
OvmfPkg/OvmfPkgX64.dsc:256:!if $(TOOL_CHAIN_TAG) == "XCODE5"
OvmfPkg/OvmfXen.dsc:233:!if $(TOOL_CHAIN_TAG) == "XCODE5"
UefiCpuPkg/UefiCpuPkg.dsc:63:!if $(TOOL_CHAIN_TAG) == "XCODE5"

Thanks,

Andrew Fish
On Oct 15, 2020, at 8:22 AM, crudo.daniele@gmail.com wrote:
Good morning, I have an issue with compiled OVMF_CODE.fd and OVMF_VARS.fd with xcode5 on mac os - Catalina 10.15.7 (I tried v. 202005 and v. 202008 stable releases from github).
My commands for v. 202008, on mac OS:

git clone https://github.com/tianocore/edk2.git
cd edk2
git clean -ffdx
git reset --hard
git submodule deinit --force --all
git checkout edk2-stable202008
git submodule update --init --force
source edksetup.sh
nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)
build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t XCODE5

Files are compiled and saved (apparently correctly).
And I'm using OVMF_CODE.fd and OVMF_VARS.fd to boot a mac OS vm with QEMU/KVM.
I noticed that with that files I have no tianocore logo at boot and moreover, since I have gpu passthrough I cannot boot the vm if hdmi is not attached (2 monitors setup, hdmi<-->hdmi and dvi<-->dvi to vga adapter<-->vga).
If I have hdmi attached I can boot without any problem.

I tried to compile with the same commands edk2 on kali linux, except for the last line which became:
build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t GCC5

and the generated files work well (I have the tianocore logo and I can boot without hdmi attached, i.e. only one monitor).

What's going on?
Anybody can explain?
Is xcode5 incompatible, is there something wrong in the code or is it my fault?
At the beginning I thought about an edk2 bug, so I opened an issue into the bugtracker, full history here:
Bug 3006

I attach also the compilation log from mac OS.

Thanks

Daniele
<log-macOs.txt.zip>
<ovmf-kali-debug.log><ovmf-macos-debug.log>