[coreboot] ARM Trusted Firmware build issue

[Martin Roth]

Ok, I tested updating the code from '.align x,0' to '.align x'.  This
updates the padding from 0x00 to nop instructions, and does work with
GAS 2.26.

I've submitted a pull request for the arm-trusted-firmware repo:
https://github.com/ARM-software/arm-trusted-firmware/pull/664

Martin

On Wed, Jul 13, 2016 at 9:14 AM, Paul Kocialkowski <contact at paulk.fr> wrote:
> Hi,
>
> Le mercredi 13 juillet 2016 à 08:57 -0600, Martin Roth a écrit :
>>   Thanks for posting about this.  I've spent some time looking into
>> this as well, but in my usual fashion, I didn't communicate what I
>> found in a responsible fashion.  Here's what I posted in a code
>> review:
>
> Looks like I didn't search long enough to find this ;)
>
>> > The current binutils (2.26) is failing to build the current arm-trusted-
>> > firmware.
>> > This wasn't caught because the jenkins builders haven't been updated to the
>> > latest build tools. I tested the new release of binutils (2.26.1) and the
>> > update
>> > didn't help my build. There's a patch that should fix the issue - See this
>> > thread for an explanation of the issue and the patch:
>> >
>> > https://www.mail-archive.com/linaro-toolchain%40lists.linaro.org/msg05685.ht
>> > ml
>> >
>> > Unfortunately, a different change went into 2.26.1 at that location, so this
>> > patch
>> > doesn't directly apply.
>>
>> For some reason, I didn't directly test that patch with 2.26 to see if
>> it actually worked - I tried adding it in to 2.26.1, which did not
>> help.  I'll test it with 2.26 today, and add the patch into the
>> toolchain build if it works.
>
> From what I understood, that patch only allows the build to work when removing
> the extra 0 to .align (so using ".align x" instead of ".align x, 0"). And it was
> indeed crafted for an older GAS version. For 2.26, it doesn't apply either and a
> similar fix was already included, so the workaround above does work.
>
> But again, we can't easily patch ATF…
>
>> We can't roll the entire toolchain back to binutils 2.25 because of
>> the RISC-V work.
>
> Indeed.
>
>> Is it reasonable to roll back to binutils 2.25 for just the ARM toolchain
>> builds?
>
> Someone should definitely try that, I have no idea whether it's a good idea off-
> hand. If anyone does, please speak up :)
>
> I'm running out of time these days, but if nobody else does it, I'll probably
> have a go at it this week-end.
>
>> And then I need to update the toolchains on the builders and figure
>> out how to keep them up-to-date so this doesn't happen again.
>
> That would be nice!
>
>> Sorry I didn't post this directly to the mailing list earlier.
>
> No problem, it was fun to dig into it. Also, since the affected devices are not
> public, I guess it doesn't really bother anyone. I just happened to look at it
> when submitting a crossgcc change, which comes out as unstable because of this
> issue, but that's about it.
>
> Cheers,
>
> Paul
>
>> On Wed, Jul 13, 2016 at 2:35 AM, Paul Kocialkowski <contact at paulk.fr> wrote:
>> > We spent some time yesterday evening on IRC investigating why the ARM
>> > Trusted
>> > Firmware (ATF) doesn't build with the current toolchain from coreboot's
>> > crossgcc.
>> >
>> > It turns out it is a complex issue on the assembler's side. I have opened a
>> > bug
>> > upstream about it, with all the details we could find:
>> > https://sourceware.org/bugzilla/show_bug.cgi?id=20364
>> >
>> > This regression was introduced with binutils 2.26. To get the build going in
>> > the
>> > short term, we could either downgrade binutils back to 2.25 (if it still
>> > meets
>> > all dependencies from other tools) or patch ATF to replace the ".align x, 0"
>> > directives to ".align x" in include/common/asm_macros.S (not sure this is a
>> > possibility).
>> >
>> > Cheers,
>> >
>> > -- Paul Kocialkowski, developer of low-level free software for embedded
>> > devices
>> >
>> > Website: https://www.paulk.fr/
>> > Coding blog: https://code.paulk.fr/
>> > Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
>> > --
>> > coreboot mailing list: coreboot at coreboot.org
>> > https://www.coreboot.org/mailman/listinfo/coreboot