moving pyro to gcc 6.4 breaks u-boot-socfpga networking, etc

[fmhess]

Breaks due to change in default gcc optimizations, see

u-boot/u-boot@704f3ac

also linux can no longer boot due to being unable to find init in our ubifs root filesystem (we don't know why this happens yet, but it started happening after the update to gcc 6.4).

[koenkooi]

The gcc change was done in OE-core in what seems to be an reaction to spectre/meltdown, so I'm a bit hesitant to bring gcc 6.3 back. Can you try to move the OE-core revision back a bit to see if that is indeed causing the issues you are seeing?

[fmhess]

The breakage of u-boot networking was definitely caused by the compiler update, applying the patch I linked to in my original comment fixed that problem and we never needed that patch before. I've changed our openembbeded/angstrom revisions to the following (rolled back to end of 2017 basically):

name="Angstrom-distribution/meta-angstrom" revision="8e2f5bb1d814396b0487fe52e94d4ebd6a3634c5"

name="openembedded/openembedded-core" revision="ac2aad028daca6ea3aa0c0ccea8d528e896f8349"

name="openembedded/meta-openembedded" revision="dfbdd28d206a74bf264c2f7ee0f7b3e5af587796"

hopefully sometime later today these revisions will be tested and I'll let you know if they fix our linux boot problem.

[fmhess]

Ok, it was only u-boot-socfpga that was broken by gcc 6.4. Our linux init problems were due to bitbake breaking on doing a += with a machine override:

IMAGE_INSTALL_fluke-cda-vanquish +=

but it works fine with

IMAGE_INSTALL_append_fluke-cda-vanquish =

[koenkooi]

Right, += is destructive when used with overrides where _append isn't. They get applied at different times in the evaluation/expansion code, so it's not just the "one adds a leading space, the other doesn't" difference that the documentation implies.

Can you update your BSP to add that uboot patch?

[fmhess]

We are using a forked u-boot repo, so we just put the patch in our repo. To fix the problem for Angstrom generally, I guess you'd want to add a patch to the openembedded-core/recipes-bsp/u-boot layer.

[fmhess]

Hmm, rely on the u-boot from meta-altera/recipes-bsp/u-boot which I assumed inherited from the openembedded-core u-boot but doesn't seem to. Anyways, it seems like all the u-boots using u-boot versions that don't already have the patch would need it.