From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mx.groups.io with SMTP id smtpd.web11.11523.1602937166974009302 for ; Sat, 17 Oct 2020 05:19:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jEyrcDou; spf=pass (domain: gmail.com, ip: 209.85.208.181, mailfrom: crudo.daniele@gmail.com) Received: by mail-lj1-f181.google.com with SMTP id c21so5573428ljn.13 for ; Sat, 17 Oct 2020 05:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NEjgrQmn8uEmGaCLkvvY+qn/2xzJlAL1/Kz/YlLa7Uo=; b=jEyrcDouRmTr37KwUKaAfGd5oglvZSEHBhle3w6+YaVzjsFnmFr6vLcn1alkkiKruw FadCYh3hbrzHXOBhYAMpFkvEMGKe+CutDvrR6xdF3Lp19SJr01Sd4/94n4RnTLpsSUhC 5rfJxau1uXgnZa6OkBQ8ylc0yHmJkRJ/bLIDAK8PY9WxtiEqrEd8fK5HCoYA3xqmrkMI l/KFFWCfSq1R2XTD57l5DWRuuJp/h8gQIsvnHKQeFg3y4JNRmwMyRvb5PDFcldd/Y2eM Vdss16gJwIvN2xVtzVJl4xiKI0gfxm3tln8WmYOoRdGJUjOvoZhBNu5imdRUFlXxUAyF d42A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NEjgrQmn8uEmGaCLkvvY+qn/2xzJlAL1/Kz/YlLa7Uo=; b=fNW7QyWHIp7IxLQ1GB+ShrTXhfMrrFEZ7xKflLIxpI7s1368pf4lGbrqCL9nIlVvzd rDZbozUUHC39cF7Ck+/ZJqREYMTPDS6J/mAxPzR3R6RCAbM46XZuchzy6ebQeivnH4sM aQaopjkL9m79cFNrZUh+IFOm2wxp9dorBsZf/3Rnbu/Zh+9XQhHN999eUmPphMhMaafc sm7Z1X1DktmycHGNbj6DAS6mnMjdWcn5aOp2+Xtvr02x3kk280XNIorvz4nGRitdgEnU HIpOhU+N+KynMIaqvwwzPCgeK6LOCZAmtBiRMJdyo96fOsOZ3moP7z/9woSrXvLlxcaO 4xwA== X-Gm-Message-State: AOAM532mdzwYwdtWeQw5GWjPV1Lqr1kQfXlewY1JDyHwpZeg9TC+6qGh xtqBE3p9tpgkXbKBxmvu8ROEb86MtjfBLANU5MM= X-Google-Smtp-Source: ABdhPJwtpbXfZa72Gr0QyJ9XHphOTQR8dTWZov00+1eQregTwDtlEBlr5xvXdjyNC6OXOZXBqikCRT71Ab+yz3++L3o= X-Received: by 2002:a2e:50d:: with SMTP id 13mr3037433ljf.195.1602937165209; Sat, 17 Oct 2020 05:19:25 -0700 (PDT) MIME-Version: 1.0 References: <1D62256C-60B6-4453-AA33-1DCF7E125DD9@apple.com> In-Reply-To: From: "Daniele Crudo" Date: Sat, 17 Oct 2020 14:19:13 +0200 Message-ID: Subject: Re: [edk2-devel] Issues with edk2 compilation with xcode5 on mac OS - files compiled but strange behaviors To: Andrew Fish Cc: edk2-devel-groups-io Content-Type: multipart/alternative; boundary="0000000000005465a305b1dce482" --0000000000005465a305b1dce482 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Finally I found the culprit. I tested also different toolchains; here the details. On Big Sur beta 10: Xcode 12.0.1 Build version 12A7300 1- Toolchain 1: Apple clang version 12.0.0 (clang-1200.0.32.2) Target: x86_64-apple-darwin20.1.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolc= hain/usr/bin 2- Toolchain 2: clang version 9.0.0 (git://github.com/llvm/llvm-project.git 0399d5a9682b3cef71c653373e38890c63c4c365) Target: x86_64-apple-darwin20.1.0 Thread model: posix InstalledDir: /Users/daniele/Downloads/clang+llvm-9.0.0-x86_64-darwin-apple/bin On Catalina 10.15.7: Xcode 12.0.1 Build version 12A7300 1- Toolchain 1: Apple clang version 12.0.0 (clang-1200.0.32.2) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolc= hain/usr/bin 2- Toolchain 2: clang version 9.0.0 (git://github.com/llvm/llvm-project.git 0399d5a9682b3cef71c653373e38890c63c4c365) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Users/daniele/Downloads/clang+llvm-9.0.0-x86_64-darwin-apple/bin 3- Toolchain 3: Apple clang version 7.0.0 (based on LLVM 7.0.0) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Library/Developer/Toolchains/swift-latest.xctoolchain/usr/b= in --------------------------------------------------------------------------= ---- I noticed that the issue was with Catalina and Toolchain 3. Commands to compile the files with GPU issue (Toolchain 3): $ 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 These commands build files successfully, but OVMF_VARS.fd and OVMF_CODE.fd give the described issue (cannot boot if hdmi is not plugged in). Other toolchains (both on Big Sur and Catalina), with the same commands reported above, give an error if: $ make -C BaseTools/ is not run after: $ git submodule update --init --force All the other toolchains build files without the described issue (I can boot with only dvi attached). So, I thought, let's run: $ make -C BaseTools/ with toolchain 3 (clang 7, on Catalina) and boom, I'm able to boot with only dvi attached. I'm not sure where the problem is, because if you take a look at the first mac os log I attached (where I did not explicitly run $ make -C BaseTools/), BaseTools seem to have compiled: "Finished building BaseTools C Tools with HOST_ARCH=3DX64" Anyway, if I don't explicitly run: $ make -C BaseTools/ OVMF_CODE.fd and OVMF_VARS.fd don't work properly. Summary for tianocore logo (logo is shown: yes/no): Clang 12.0: NO Clang 9.0: YES Clang 7.0: YES Summary for building (can compile without errors, without explicitly run "make -C BaseTools/": yes/no): Clang 12.0: NO Clang 9.0: NO Clang 7.0: YES Best regards Il giorno ven 16 ott 2020 alle ore 22:05 Andrew Fish ha scritto: > > > On Oct 16, 2020, at 12:24 PM, Daniele Crudo > wrote: > > > Sorry I missed the edk2-devel in cc, resending. > > 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 c= an >> edit them in Conf/tools_def.txt >> > > ok, thanks for this, I was hoping in optimization issue but it seems it'= s > not the case (?) > > What logo are your talking about? I see the TianoCore logo failed in you= r >> macOS debug log as I would expect [1]d: >> "HII Image Package with logo not found in PE/COFF resource section=E2= =80=9D >> I don=E2=80=99t see that error message in the kali log, so that matches= what I >> would expect. >> > > Yes, I was referring to the tianocore logo; I was writing that in the ka= li > compiled log there are additional lines relating to tftpDynamicCommand.e= fi > and LinuxInitrdDynamicShellCommand.efi, which are not in the mac compile= d > log. > > 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=3D0x0007DDEFE36 Bootstrap.ef= i >> Loading driver at 0x0007DC77000 EntryPoint=3D0x0007DCED3A5 OpenCore.efi >> Loading driver at 0x0007DDDA000 EntryPoint=3D0x0007DDDA5C9 >> AE4C11C8-1D6C-F24E-A183-E1CA36D1A8A9.efi >> Loading driver at 0x0007F88E000 EntryPoint=3D0x0007F8920BD OpenRuntime.= efi >> Loading driver at 0x0007DD45000 EntryPoint=3D0x0007DD56C4B OpenCanopy.e= fi >> Loading driver at 0x0007DD66000 EntryPoint=3D0x0007DD6FC53 AudioDxe.efi >> Loading driver at 0x0007DDCE000 EntryPoint=3D0x0007DDD17C9 UsbMouseDxe.= efi >> Loading driver at 0x0007D054000 EntryPoint=3D0x0007D0A220C apfs.efi >> >> And this is the macOS booter (1st stage OS loader, the thing Mac EFI >> firmware loads directly) >> Loading driver at 0x0007CE48000 EntryPoint=3D0x0007CE51673 boot.efi >> > > Yes, I know and this is expected behavior, I was not referring to that > logo. > > There was some work on a CLANGPDB toolchain that worked on all platforms= . >> > > Thanks for this, I rapidly had a look at the github page; so these > commands: > $ wget > https://releases.llvm.org/9.0.0/clang+llvm-9.0.0-x86_64-darwin-apple.tar= .xz > $ tar -xvf clang+llvm-9.0.0-x86_64-darwin-apple.tar.xz > $ 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 checkout CLANGPDB > $ git submodule update --init --force > $ source edksetup.sh > $ export > CLANG_BIN=3D~/my/local/path/to/clang+llvm-9.0.0-x86_64-darwin-apple/bin/ > $ build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t CLANGPDB > > will let me install the clang 9.0 toolchain in my mac os and build edk2 > with that toolchain? > > So it sounds like you have some kind of graphics issue on a RELEASE buil= d? >> What happens if on a RELEASE XCODE build you just boot to the UEFI Shel= l? >> > > Maybe I misunderstood, but I cannot boot to a shell, as soon as I type > "virsh start mymv" the screen goes black (with hdmi unplugged). > > > I=E2=80=99m wondering what happens if you boot another guest OS. At leas= t on OVMF > if you don=E2=80=99t have a guest OS to boot then you drop into an UEFI = Shell (EFI > Application) that is built into the EFI ROM. > > Thanks, > > Andrew Fish > >=20 > > > --0000000000005465a305b1dce482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Finally I found the culprit.

I tested also differen= t toolchains; here the details.

On Big Sur beta 10:

Xcode 12.= 0.1
Build version 12A7300

1- Toolchain 1:
Apple clang version = 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin20.1.0
Thread m= odel: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Too= lchains/XcodeDefault.xctoolchain/usr/bin

2- Toolchain 2:
clang ve= rsion 9.0.0 (git://gith= ub.com/llvm/llvm-project.git 0399d5a9682b3cef71c653373e38890c63c4c365)<= br>Target: x86_64-apple-darwin20.1.0
Thread model: posix
InstalledDir= : /Users/daniele/Downloads/clang+llvm-9.0.0-x86_64-darwin-apple/bin

= On Catalina 10.15.7:

Xcode 12.0.1
Build version 12A7300

1-= Toolchain 1:
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: = x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applicat= ions/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/b= in

2- Toolchain 2:
clang version 9.0.0 (git://github.com/llvm/llvm-project.git 0399d= 5a9682b3cef71c653373e38890c63c4c365)
Target: x86_64-apple-darwin19.6.0Thread model: posix
InstalledDir: /Users/daniele/Downloads/clang+llvm-= 9.0.0-x86_64-darwin-apple/bin

3- Toolchain 3:
Apple clang version= 7.0.0 =C2=A0(based on LLVM 7.0.0)
Target: x86_64-apple-darwin19.6.0
= Thread model: posix
InstalledDir: /Library/Developer/Toolchains/swift-la= test.xctoolchain/usr/bin
-----------------------------------------------= -------------------------------

I noticed that the issue was with Ca= talina and Toolchain 3.
Commands to compile the files with GPU issue (To= olchain 3):

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

These commands build files successfully, but OVMF_VARS.= fd and OVMF_CODE.fd give the described issue (cannot boot if hdmi is not pl= ugged in).

Other toolchains (both on Big Sur and Catalina), with the= same commands reported above, give an error if:

$ make -C BaseTools= /

is not run after:

$ git submodule update --init --force
=
All the other toolchains build files without the described issue (I can= boot with only dvi attached).

So, I thought, let's run:

= $ make -C BaseTools/

with toolchain 3 (clang 7, on Catalina) and boo= m, I'm able to boot with only dvi attached.

I'm not sure whe= re the problem is, because if you take a look at the first mac os log I att= ached (where I did not explicitly run $ make -C BaseTools/), BaseTools seem= to have compiled:

"Finished building BaseTools C Tools with HO= ST_ARCH=3DX64"

Anyway, if I don't explicitly run:

$ = make -C BaseTools/

OVMF_CODE.fd and OVMF_VARS.fd don't work prop= erly.

Summary for tianocore logo (logo is shown: yes/no):
Clang 12.0: NO
Clang 9.0: YES
Clang 7.0: Y= ES

Summary for building (can compile without error= s, without explicitly run "make -C BaseTools/": yes/no):
Clang 12.0: NO
Clang 9.0: NO
Clang 7.0: YES

Best regards

Il giorno ven 16 ott 2020 alle= ore 22:05 Andrew Fish <afish@apple.c= om> ha scritto:


On Oct 16, 2020, at 12:24 PM, Daniele Crudo <crudo.daniele@gmail.= com> wrote:


Sorry I missed the edk2-devel in cc, resending.
<= div dir=3D"ltr">
OK so the DEBUG and RELEASE both buil= d with -Os. This is firmware things have to fit in the ROM. The big differe= nce between DEBUG and release is the DEBUG prints get stripped out, so that= usually means timing issues :(.=C2=A0

The com= piler flags live in=C2=A0=C2=A0BaseTools/Conf/tools_def.template and you ca= n edit them in Conf/tools_def.txt

ok, thanks for this, I was hoping in optimization issue but it seems it&= #39;s not the case (?)

What logo are your talking about? I see th= e 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=E2=80=9D
I don=E2=80=99t see that error message in the k= ali log, so that matches what I would expect.=C2=A0
=

Yes, I was referring to the tianocore logo= ; I was writing that in the kali compiled log there are additional lines re= lating to=C2=A0tftpDynamicCommand.efi and LinuxInitrdDynamicShellCommand.ef= i, which are not in the mac compiled log.

It soun= ds like you are talking about a logo coming from your Hackintosh EFI boot s= him? Or the macOS booter?
This is all the Hackintosh stuff that i= s loading.=C2=A0
[Bds] Expand PciRoot(0x0)/Pci(0x1F,0x2)/Sat= a(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=3D0x000= 7DDEFE36 Bootstrap.efi
Loading driver at 0x0007DC77000 EntryPoint= = =3D0x0007DCED3A5 OpenCore.efi
Loading driver at 0x0007DDDA000 En= tryPoint=3D0x0007DDDA5C9 AE4C11C8-1D6C-F24E-A183-E1CA36D1A8A9.efi
Loading driver at 0x0007F88E000 EntryPoint=3D0x0007F8920BD OpenRuntime.efi=
Loading driver at 0x0007DD45000 EntryPoint=3D0x0007DD56C4B OpenC= anopy.efi
Loading driver at 0x0007DD66000 EntryPoint=3D0x0007DD6F= C53 AudioDxe.efi
Loading driver at 0x0007DDCE000 EntryPoint=3D0x0= 007DDD17C9 UsbMouseDxe.efi
Loading driver at 0x0007D054000 EntryP= oint=3D0x0007D0A220C apfs.efi

And this= is the macOS booter (1st stage OS loader, the thing Mac EFI firmware loads= directly)=C2=A0
Loading driver at 0x0007CE48000 EntryPoint= =3D0x0007CE51673 boot.efi
=
=C2=A0
Yes, I know and this is expected behavior, I was not = referring to that logo.

There was some work on a CLANGPDB toolcha= in that worked on all platforms.=C2=A0
<= br>
Thanks for this, I rapidly had a look at the github page; so = these commands:
$ wget https://rel= eases.llvm.org/9.0.0/clang+llvm-9.0.0-x86_64-darwin-apple.tar.xz
$ t= ar -xvf clang+llvm-9.0.0-x86_64-darwin-apple.tar.xz
$=C2=A0git clone https://github.com/tianocore/edk2.git
$ cd edk= 2
$ git clean -ffdx
$ git reset --hard
$ git submodule dein= it --force --all
$ git checkout edk2-stable202008
$ git checkout CLAN= GPDB
$ git submodule update --init --force
$ source edksetup.s= h
$ export CLANG_BIN=3D~/my/local/path/to/clang+llvm-9.0.0-x86_64-darwin= -apple/bin/
$ build -a X64 -b RELEASE -p OvmfPkg/OvmfPkgX64.dsc -t CLANG= PDB

will let me install the clang 9.0 toolchai= n in my mac os and build edk2 with that toolchain?

So it sounds l= ike you have some kind of graphics issue on a RELEASE build? What happens i= f on a RELEASE XCODE build you just boot to the UEFI Shell?

Maybe I misunderstood, but I cannot boot= to a shell, as soon as I type "virsh start mymv" the screen goes= black (with hdmi unplugged).

<= /div>

I=E2=80=99m wondering what happens if= you boot another guest OS. At least on OVMF if you don=E2=80=99t have a gu= est OS to boot then you drop into an UEFI Shell (EFI Application) that is b= uilt into the EFI ROM.=C2=A0

Thanks,
Andrew Fish


--0000000000005465a305b1dce482--