Re: [PATCH v2 1/1] BaseTools/tools_def: Add GCC49xASL Toolchain support

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 26 June 2018 at 20:42, Chris Co <Christopher.Co@microsoft.com> wrote:
>
>
>> -----Original Message-----
>> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Sent: Tuesday, June 26, 2018 1:22 AM
>> To: Gao, Liming <liming.gao@intel.com>
>> Cc: Chris Co <Christopher.Co@microsoft.com>; edk2-devel@lists.01.org; Leif
>> Lindholm <leif.lindholm@linaro.org>; Charles Garcia-Tobin <Charles.Garcia-
>> Tobin@arm.com>
>> Subject: Re: [edk2] [PATCH v2 1/1] BaseTools/tools_def: Add GCC49xASL
>> Toolchain support
>>
>> On 26 June 2018 at 06:40, Gao, Liming <liming.gao@intel.com> wrote:
>> > Chris:
>> >   Here is the example usage. You can add below [BuildOptions] in your
>> platform DSC. Then, it will use override ASL path and flag.
>> >
>> > [BuildOptions]
>> >   *_*_*_ASL_PATH                     == C:\Asl\asl.exe
>> >   *_*_*_ASL_FLAGS                    == /MsftInternal
>> >   *_*_*_ASL_OUTFLAGS                 == /Fo=
>> >
>>
>> I strongly prefer this over adding a new MS specific toolchain definition.
>>
>
> Thanks Liming!  I added these overrides and they works great.  Since we can do platform dsc overrides, I also used it to override the objcopy_path and symrename_path which was the other change we needed for building on Windows.
>   GCC:*_*_*_OBJCOPY_PATH = noop
>   GCC:*_*_*_SYMRENAME_PATH = noop
>
> Ard, I agree this is the better method.  We can drop this patch in favor of the platform dsc overrides.
>
> Leif, I tested GCC7.3 arm-eabi and ran into build errors.  Found out this was an issue encountered before: https://bugs.linaro.org/show_bug.cgi?id=2909
> I made a couple modifications to Trim.py to fix the errors and was able to successfully build and test.  Will submit the fix for review and update our toolchain to use GCC7.3 with GCC5 profile.
>

That is good news.

So I guess we're all set to start incorporating this platform.

Any clue whether there is also a device tree available for this
platform? I would prefer it if we could make the firmware OS agnostic,
rather than have Windows-only and Linux-only platforms in the
edk2-platforms tree.