Patrick: In current tools_def.txt, iasl path is ENV(IASL_PREFIX)iasl. So, you can configure IASL_PREFIX env to point the your directory. In edk2, GCC5 is the tool chain configuration with LTO support, not specific to the compiler version. Since COREBOOT has the same configuration, it can reuse GCC5 tool chain. To let user correctly use GCC5 tool chain build CorebootPayloadPkg, you can add readme.md in CorebootPayloadPkg to introduce how to generate the cross compiler and how to configure GCC5_PREFIX and IASL_PREFIX env. In fact, even if COREBOOT tool chain is added, you also need to document these steps.
Thanks Liming >-----Original Message----- >From: edk2-devel [mailto:[email protected]] On Behalf Of >Patrick Georgi >Sent: Monday, July 10, 2017 11:06 PM >To: Gao, Liming <[email protected]> >Cc: [email protected] >Subject: Re: [edk2] [PATCH] BaseTools: Add COREBOOT tools definition > >Hi Liming, > >thank you for the review! > >2017-07-10 16:46 GMT+02:00 Gao, Liming <[email protected]>: > >> Patrick: >> Compared GCC5 and COREBOOT, the difference is that GCC5_IA32_PREFIX >and >> GCC5_X64_PREFIX. CoreBoot tool chain has the different style. So, it can't >> reuse GCC5 tool chain. If GCC5 is update to refer to ENV (GCC5_IA32_PREFIX) >> and ENV (GCC5_X64_PREFIX) like ENV(GCC5_ARM_PREFIX) in CC_PATH, >GCC5 can >> support COREBOOT usage. For the future, the different FLAG can be >appended >> in [BuildOptions] of platform.dsc. So, I suggest to reuse GCC5 tool chain >> for coreboot. >> >We also use our own make and iasl binaries. >*_COREBOOT_*_MAKE_PATH = DEF(COREBOOT_PREFIX)make >*_COREBOOT_*_ASL_PATH = DEF(COREBOOT_PREFIX)iasl > >The coreboot toolchain is gcc 6.3 based right now but will move to >something newer at some point. That the GCC5 configuration is sufficient >for now is a coincidence (although appreciated since it meant less work for >me). Unfortunately I likely won't be able to get away with that forever. >Asking people to adapt their Tianocore config because the toolchain was >updated is a bad user experience IMHO. > >The two main benefits of using a well-defined, maintained toolchain and >configuration are: >1. a portable toolchain: you get the same results no matter the OS you're on >2. reproducible builds: with a given source tree and configuratoin, we get >bit identical binaries, which is rather useful for trust/security >assessments. See >https://tests.reproducible-builds.org/coreboot/coreboot.html > >It might be useful to extend this effort to payloads such as >CorebootPayloadPkg. Dealing with random compilers (and their configs) is >something we at coreboot left behind ~10 years ago, and it was for the >better. (although I understand that the coreboot toolchain is just as >"random" to you as any other). >But if you feel this is too much extra stuff in your config files, I'll >have to see how to deal with the existing config sets instead. > > >Patrick >-- >Google Germany GmbH, ABC-Str. 19, 20354 Hamburg >Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: >Hamburg >Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle >_______________________________________________ >edk2-devel mailing list >[email protected] >https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
