configs/stm32f429: force usage of BINUTILS 2.28.x

Due to runtime issue with the usage of BINUTILS 2.29.x, we need to use the version 2.28.x

---
 configs/stm32f429_disco_defconfig | 1 +
 1 file changed, 1 insertion(+)

index 5237e9a..fc167d0 100644
@@ -2,6 +2,7 @@ BR2_arm=y
 BR2_cortex_m4=y
 BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32f429-disco/patches"
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_11=y
+BR2_BINUTILS_VERSION_2_28_X=y
 BR2_ROOTFS_POST_BUILD_SCRIPT="board/stmicroelectronics/stm32-post-build.sh"
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_VERSION=y

2.7.4

Due to runtime issue with the usage of BINUTILS 2.29.x, we need to use the version 2.28.x

---
 configs/stm32f469_disco_defconfig | 1 +
 1 file changed, 1 insertion(+)

index 8b77d8c..e5cacaf 100644
@@ -2,6 +2,7 @@ BR2_arm=y
 BR2_cortex_m4=y
 BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32f469-disco/patches"
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_11=y
+BR2_BINUTILS_VERSION_2_28_X=y
 BR2_ROOTFS_POST_BUILD_SCRIPT="board/stmicroelectronics/stm32-post-build.sh"
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_VERSION=y

2.7.4

Le 29/05/2018 ? 14:09, Christophe PRIOUZEAU a ?crit?:

Hi Christophe,

Le 29/05/2018 ? 14:09, Christophe PRIOUZEAU a ?crit?:

Thanks for the patch!

The defconfig stm32f469_disco is also affected by this issue. Binutils version must be updated as well.

Best regards,
Romain

Hi Romain,
I have pushed the 2 patches, it just take time to appear on patchwork.

When the both will be available on patchwork, I will update the bugzilla with the link of two patch.

patch1: http://patchwork.ozlabs.org/patch/922037/
patch 2: http://patchwork.ozlabs.org/patch/922049/

Regards
Christophe

On 05/29/2018 02:39 PM, Romain Naour wrote:

Hi Christophe,

Le 29/05/2018 ? 14:09, Christophe PRIOUZEAU a ?crit :

Due to runtime issue with the usage of BINUTILS 2.29.x, we need to use the version 2.28.x

---
 configs/stm32f429_disco_defconfig | 1 +

Thanks for the patch!

The defconfig stm32f469_disco is also affected by this issue. Binutils version must be updated as well.

Best regards,
Romain

 1 file changed, 1 insertion(+)

index 5237e9a..fc167d0 100644
@@ -2,6 +2,7 @@ BR2_arm=y
 BR2_cortex_m4=y
 BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32f429-disco/patches"
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_11=y
+BR2_BINUTILS_VERSION_2_28_X=y
 BR2_ROOTFS_POST_BUILD_SCRIPT="board/stmicroelectronics/stm32-post-build.sh"
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_VERSION=y

--

Best regards / Cordialement,

[cid:part1.D2E22D31.675807D7 at st.com] Christophe Priouzeau | TINA: 166 7320 | Tel: +33 244027320

STMicroelectronics
ST oneline: www.st.com<http://www.st.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180529/cae358a8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: st_mail.png
Type: image/png
Size: 9916 bytes
Desc: st_mail.png
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180529/cae358a8/attachment.png>

Sorry, I missed the second mail...

Le 29/05/2018 ? 14:39, Romain Naour a ?crit?:

Committed both after adding a reference to the bugtracker issue, thanks.

Bye, Peter Korsgaard

Hello Christophe,

I know those patches have been committed, but I'd like to say I'm not totally happy with them: to me, they don't implement the right approach.

Your patches only fix specifically the STM32 defconfigs. Any other Buildroot user doing Cortex-M4 stuff, for other platforms, will fall into the same binutils issue.

So in fact the proposal that was made back in April at
http://lists.busybox.net/pipermail/buildroot/2018-April/219223.html was in the end better.

I still don't like the fact that we are forced to use an old binutils version, because we are ultimately going to drop support for binutils 2.28 in the future, and if the issue isn't fixed in newer binutils versions, we are going to have a problem. But regardless of that, fixing the defconfigs is really not the correct solution here I believe.

Best regards,

Thomas

Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Similarly, one can argue that this patch impacts every software, whereas only linux kernel is not compatible with newer binutils.

Using this kernel patch may help to only fix what need to be fixed:

http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/565390.html

Laurent, All,

On 2018-05-30 14:12 +0200, Laurent GONZALEZ spake thusly:

That's not true, as other packages have been reportedly broken as well, namely libavcodec and openssl (at least):

    http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/543467.html

So, it's not just about the kernel; virtually any package that has some ARM/Thumb assembly is impacted.

But once those packages are fixed upstream, well eventually get an updated version in Buildroot, which fixes that issue, and in the end, only the kernel wil end up being impacted (because there are so many older kernels out there in the wild...).

Regards,
Yann E. MORIN.

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Hello Tomas,
I know that my patches are not a durable solution. My concern are to have a solution for stm32 and not keep
this state on which stm32 board doesn't boot.

For the long term solution, I have seen a patch on the kernel
to correct the issue around 'adr pseudo instruction'.
Patch: https://patchwork.kernel.org/patch/10072631/
"arm: ensure symbol is a thumb symbol in new binutils". This patch are not merged on the kernel, I have tested it on top of kernel 4.11(buildroot config) and kernel 4.17-rc5, the patch work correctly, we are able to perform a complete boot. I need to continue my test to see if this patch is sufficient.

Regards
Christophe Priouzeau

On 05/29/2018 11:32 PM, Thomas Petazzoni wrote:

Hello Christophe,

On Tue, 29 May 2018 12:09:27 +0000, Christophe PRIOUZEAU wrote:

Due to runtime issue with the usage of BINUTILS 2.29.x, we need to use the version 2.28.x

I know those patches have been committed, but I'd like to say I'm not totally happy with them: to me, they don't implement the right approach.

Your patches only fix specifically the STM32 defconfigs. Any other Buildroot user doing Cortex-M4 stuff, for other platforms, will fall into the same binutils issue.

So in fact the proposal that was made back in April at
http://lists.busybox.net/pipermail/buildroot/2018-April/219223.html was in the end better.

I still don't like the fact that we are forced to use an old binutils version, because we are ultimately going to drop support for binutils 2.28 in the future, and if the issue isn't fixed in newer binutils versions, we are going to have a problem. But regardless of that, fixing the defconfigs is really not the correct solution here I believe.

Best regards,

Thomas

--

Best regards / Cordialement,

[cid:part1.BC660A15.40BF3C41 at st.com] Christophe Priouzeau | TINA: 166 7320 | Tel: +33 244027320

STMicroelectronics
ST oneline: www.st.com<http://www.st.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180530/359799d7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: st_mail.png
Type: image/png
Size: 9916 bytes
Desc: st_mail.png
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180530/359799d7/attachment.png>

Hello,

Hence my proposal to generalize your change so that it covers all Cortex-M platforms and not just the STM32 defconfigs.

Your solution is not even generic enough for STM32: it only makes the STM32 defconfigs work. But if:

- Someone uses the defconfig and changes the binutils version to 2.29, it won't work anymore.

- Someone creates his own defconfig for another custom STM32 platform and uses binutils 2.29, it won't work.

So I repeat that the change of the defconfigs is the bad solution. If binutils 2.29 really doesn't work for Cortex-M platforms, the fix is to change the binutils package to exclude 2.29+ from being selected on Cortex-M platforms.

Thanks for working on this upstream with the kernel people.

However, we'll of course still have the "gap" that any kernel before the one having your fix will be broken with binutils 2.29+. I don't think there anything we can do about this though.

Best regards,

Thomas

Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Since we can assume that broken packages will eventually get patched (or that
we can patch them ourselves in Buildroot), the problem is just with the kernel, right? But the kernel may also have been patched. I really don't feel comfortable to make it impossible for the user to build the toolchain he wants when there is in fact no need to impose that limitation...

How about:

1. Applying http://patchwork.ozlabs.org/patch/898748/, so the default is still 2.28, but the user can choose another version.
2. Reverting these two patches (no longer needed).
3. Add a conditional warning to linux/Config.in that an unpatched kernel will fail to boot.
4. Eventually, add the patch that fixes the kernel to the stm32* defconfigs.

Regards,
Arnout

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Hello,

Sounds like a good plan to me.

Christophe, do you think you can provide the patches implementing this ?

Best regards,

Thomas

Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Hello,

Le 30/05/2018 ? 22:41, Thomas Petazzoni a ?crit?:

I've sent a mail to Nick Clifton about this issue on the Binutils mailing list.

https://sourceware.org/ml/binutils/2018-05/msg00348.html

Best regards,
Romain

Hello Thomas,
I'm ok to provide the patches.

For the warning, can you point to me an example or a documentation
to write a "conditional warning" on Kconfig.

Regards
Christophe

On 05/30/2018 10:41 PM, Thomas Petazzoni wrote:

Hello,

On Wed, 30 May 2018 22:35:50 +0200, Arnout Vandecappelle wrote:

How about:

1. Applying http://patchwork.ozlabs.org/patch/898748/, so the default is still 2.28, but the user can choose another version.
2. Reverting these two patches (no longer needed).
3. Add a conditional warning to linux/Config.in that an unpatched kernel will fail to boot.
4. Eventually, add the patch that fixes the kernel to the stm32* defconfigs.

Sounds like a good plan to me.

Christophe, do you think you can provide the patches implementing this ?

Best regards,

Thomas

--

Best regards / Cordialement,

[cid:part1.157DF46A.633AF376 at st.com] Christophe Priouzeau | TINA: 166 7320 | Tel: +33 244027320

STMicroelectronics
ST oneline: www.st.com<http://www.st.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180531/fbf4e813/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: st_mail.png
Type: image/png
Size: 9916 bytes
Desc: st_mail.png
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180531/fbf4e813/attachment.png>

comment "Unpatched Linux will not boot with binutils >= 2.29"

	depends on BR2_ARM_INSTRUCTIONS_THUMB2
	depends on BR2_BINUTILS_VERSION_2_29_X || BR2_BINUTILS_VERSION_2_30_X

Although, that would only show the warning for internal toolchains. So we
should probably introduce a BR2_TOOLCHAIN_HAS_BINUTILS_FIXED_BUG_21458 that is selected by internal and external toolchains which have that "fix". Custom external toolchains unfortunately still don't have that option...

Also I'm not sure about the THUMB2 condition - is the kernel automatically
built as thumb when we select THUMB2 on a Cortex-A? I think not, actually... So maybe it should be BR2_ARM_CPU_ARMV7M then.

Regards,
Arnout

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Hello Christophe,

It would be nice if you could avoid top-posting. It's the same best practice on the Linux kernel mailing lists.

Great!

comment "Linux kernel < v4.12 will not boot with the selected binutils version"

	depends on BR2_ARMV7M
	depends on !BR2_BINUTILS_2_28_X

or something like that (I haven't checked the exact option names, nor the kernel version, nor anything else, it's just an example).

Best regards,

Thomas

Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com