diff mbox series

[1/2] configs/stm32f429: force usage of BINUTILS 2.28.x

Message ID 1527595765-23055-1-git-send-email-christophe.priouzeau@st.com
State Accepted
Commit cbe43fd417d77f846f1ca47cdacd51a73be1aaec
Headers show
Series [1/2] configs/stm32f429: force usage of BINUTILS 2.28.x | expand

Commit Message

Christophe PRIOUZEAU May 29, 2018, 12:09 p.m. UTC
Due to runtime issue with the usage of BINUTILS 2.29.x,
we need to use the version 2.28.x

Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com>
---
 configs/stm32f429_disco_defconfig | 1 +
 1 file changed, 1 insertion(+)

Comments

Romain Naour May 29, 2018, 12:39 p.m. UTC | #1
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
> 
> Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com>
> ---
>  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(+)
> 
> diff --git a/configs/stm32f429_disco_defconfig b/configs/stm32f429_disco_defconfig
> index 5237e9a..fc167d0 100644
> --- a/configs/stm32f429_disco_defconfig
> +++ b/configs/stm32f429_disco_defconfig
> @@ -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
>
Christophe PRIOUZEAU May 29, 2018, 12:47 p.m. UTC | #2
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

Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com><mailto:christophe.priouzeau@st.com>
---
 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(+)

diff --git a/configs/stm32f429_disco_defconfig b/configs/stm32f429_disco_defconfig
index 5237e9a..fc167d0 100644
--- a/configs/stm32f429_disco_defconfig
+++ b/configs/stm32f429_disco_defconfig
@@ -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@st.com]
Christophe Priouzeau | TINA: 166 7320 | Tel: +33 244027320

STMicroelectronics
ST oneline: www.st.com<http://www.st.com>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Romain,&nbsp; <br>
&nbsp; I have pushed the 2 patches, it just take time to appear on patchwork. <br>
<br>
&nbsp; When the both will be available on patchwork, I will update the bugzilla with the link of two patch.<br>
<br>
patch1: <a class="moz-txt-link-freetext" href="http://patchwork.ozlabs.org/patch/922037/">
http://patchwork.ozlabs.org/patch/922037/</a><br>
patch 2: <a class="moz-txt-link-freetext" href="http://patchwork.ozlabs.org/patch/922049/">
http://patchwork.ozlabs.org/patch/922049/</a><br>
<br>
Regards<br>
Christophe<br>
<br>
On 05/29/2018 02:39 PM, Romain Naour wrote:<br>
</div>
<blockquote type="cite" cite="mid:42437f2b-2d35-fa5c-c695-fb29031c8cc9@smile.fr">
<pre wrap="">Hi Christophe,

Le 29/05/2018 à 14:09, Christophe PRIOUZEAU a écrit&nbsp;:
</pre>
<blockquote type="cite">
<pre wrap="">Due to runtime issue with the usage of BINUTILS 2.29.x,
we need to use the version 2.28.x

Signed-off-by: Christophe Priouzeau <a class="moz-txt-link-rfc2396E" href="mailto:christophe.priouzeau@st.com">&lt;christophe.priouzeau@st.com&gt;</a>
---
 configs/stm32f429_disco_defconfig | 1 &#43;
</pre>
</blockquote>
<pre wrap="">
Thanks for the patch!

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

Best regards,
Romain

</pre>
<blockquote type="cite">
<pre wrap=""> 1 file changed, 1 insertion(&#43;)

diff --git a/configs/stm32f429_disco_defconfig b/configs/stm32f429_disco_defconfig
index 5237e9a..fc167d0 100644
--- a/configs/stm32f429_disco_defconfig
&#43;&#43;&#43; b/configs/stm32f429_disco_defconfig
@@ -2,6 &#43;2,7 @@ BR2_arm=y
 BR2_cortex_m4=y
 BR2_GLOBAL_PATCH_DIR=&quot;board/stmicroelectronics/stm32f429-disco/patches&quot;
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_11=y
&#43;BR2_BINUTILS_VERSION_2_28_X=y
 BR2_ROOTFS_POST_BUILD_SCRIPT=&quot;board/stmicroelectronics/stm32-post-build.sh&quot;
 BR2_LINUX_KERNEL=y
 BR2_LINUX_KERNEL_CUSTOM_VERSION=y

</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<title></title>
<br>
<div class="moz-signature">
<pre>Best regards / Cordialement,

<img alt="" src="cid:part1.D2E22D31.675807D7@st.com" height="54" width="202">
Christophe Priouzeau | TINA: 166 7320 | Tel: &#43;33 244027320

STMicroelectronics 
ST oneline: <a href="http://www.st.com">www.st.com</a> 
</pre>
<p class="MsoNormal"><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<pre><http: www.st.com="">
<http: twitter.com#!st_world="">

</http:></http:></pre>
</div>
</div>
</body>
</html>
Romain Naour May 29, 2018, 12:48 p.m. UTC | #3
Sorry, I missed the second mail...

Le 29/05/2018 à 14:39, Romain Naour a écrit :
> 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
>>
>> Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com>

Fixes: #11051

Acked-by: Romain Naour <romain.naour@smile.fr>

>> ---
>>  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(+)
>>
>> diff --git a/configs/stm32f429_disco_defconfig b/configs/stm32f429_disco_defconfig
>> index 5237e9a..fc167d0 100644
>> --- a/configs/stm32f429_disco_defconfig
>> +++ b/configs/stm32f429_disco_defconfig
>> @@ -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
>>
> 
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
Peter Korsgaard May 29, 2018, 3:51 p.m. UTC | #4
>>>>> "Christophe" == Christophe PRIOUZEAU <christophe.priouzeau@st.com> writes:

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

 > Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com>

Committed both after adding a reference to the bugtracker issue, thanks.
Thomas Petazzoni May 29, 2018, 9:32 p.m. UTC | #5
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
> 
> Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com>

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
Laurent GONZALEZ May 30, 2018, 12:12 p.m. UTC | #6
On 29/05/2018 23:32, 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
>>
>> Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com>
> 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.

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
Christophe PRIOUZEAU May 30, 2018, 3:24 p.m. UTC | #7
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

Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com><mailto:christophe.priouzeau@st.com>



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@st.com]
Christophe Priouzeau | TINA: 166 7320 | Tel: +33 244027320

STMicroelectronics
ST oneline: www.st.com<http://www.st.com>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hello Tomas, <br>
&nbsp; I know that my patches are not a durable solution. <br>
&nbsp; My concern are to have a solution for stm32&nbsp; and not keep <br>
this state on which stm32 board doesn't boot.<br>
<br>
&nbsp; For the long term solution, I have seen a patch on the kernel <br>
to correct the issue around 'adr pseudo instruction'. <br>
Patch: <a class="moz-txt-link-freetext" href="https://patchwork.kernel.org/patch/10072631/">
https://patchwork.kernel.org/patch/10072631/</a><br>
&quot;arm: ensure symbol is a thumb symbol in new binutils&quot;.<br>
This patch are not merged on the kernel, I have tested it on top <br>
of kernel 4.11(buildroot config) and kernel 4.17-rc5, the patch <br>
work correctly, we are able to perform a&nbsp; complete boot.<br>
I need to continue my test to see if this patch is sufficient.<br>
<br>
Regards<br>
Christophe Priouzeau<br>
&nbsp; <br>
<br>
<br>
On 05/29/2018 11:32 PM, Thomas Petazzoni wrote:<br>
</div>
<blockquote type="cite" cite="mid:20180529233219.0eca0f54@windsurf.home">
<pre wrap="">Hello Christophe,

On Tue, 29 May 2018 12:09:27 &#43;0000, Christophe PRIOUZEAU wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Due to runtime issue with the usage of BINUTILS 2.29.x,
we need to use the version 2.28.x

Signed-off-by: Christophe Priouzeau <a class="moz-txt-link-rfc2396E" href="mailto:christophe.priouzeau@st.com">&lt;christophe.priouzeau@st.com&gt;</a>
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-freetext" href="http://lists.busybox.net/pipermail/buildroot/2018-April/219223.html">http://lists.busybox.net/pipermail/buildroot/2018-April/219223.html</a> 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
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<title></title>
<br>
<div class="moz-signature">
<pre>Best regards / Cordialement,

<img alt="" src="cid:part1.BC660A15.40BF3C41@st.com" height="54" width="202">
Christophe Priouzeau | TINA: 166 7320 | Tel: &#43;33 244027320

STMicroelectronics 
ST oneline: <a href="http://www.st.com">www.st.com</a> 
</pre>
<p class="MsoNormal"><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<pre><http: www.st.com="">
<http: twitter.com#!st_world="">

</http:></http:></pre>
</div>
</div>
</body>
</html>
Thomas Petazzoni May 30, 2018, 3:42 p.m. UTC | #8
Hello,

On Wed, 30 May 2018 15:24:19 +0000, Christophe PRIOUZEAU wrote:

>   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.

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.

>   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.

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
Yann E. MORIN May 30, 2018, 4:24 p.m. UTC | #9
Laurent, All,

On 2018-05-30 14:12 +0200, Laurent GONZALEZ spake thusly:
> On 29/05/2018 23:32, Thomas Petazzoni wrote:
> > On Tue, 29 May 2018 12:09:27 +0000, Christophe PRIOUZEAU wrote:
> > 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.
> Similarly, one can argue that this patch impacts every software, whereas
> only linux kernel is not compatible with newer binutils.

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.

> 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
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Arnout Vandecappelle May 30, 2018, 8:35 p.m. UTC | #10
On 30-05-18 17:42, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 30 May 2018 15:24:19 +0000, Christophe PRIOUZEAU wrote:
> 
>>   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.
> 
> 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.

 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

>>   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.
> 
> 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 May 30, 2018, 8:41 p.m. UTC | #11
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
Romain Naour May 30, 2018, 8:46 p.m. UTC | #12
Hello,

Le 30/05/2018 à 22:41, Thomas Petazzoni a écrit :
> 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 ?

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
> 
> Best regards,
> 
> Thomas
>
Christophe PRIOUZEAU May 31, 2018, 8:34 a.m. UTC | #13
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@st.com]
Christophe Priouzeau | TINA: 166 7320 | Tel: +33 244027320

STMicroelectronics
ST oneline: www.st.com<http://www.st.com>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hello Thomas, <br>
&nbsp; I'm ok to provide the patches. <br>
<br>
&nbsp; For the warning, can you point to me an example or a documentation <br>
to write a &quot;conditional warning&quot; on Kconfig. <br>
<br>
Regards<br>
Christophe<br>
&nbsp; <br>
<br>
On 05/30/2018 10:41 PM, Thomas Petazzoni wrote:<br>
</div>
<blockquote type="cite" cite="mid:20180530224134.0b87b6ad@windsurf.home">
<pre wrap="">Hello,

On Wed, 30 May 2018 22:35:50 &#43;0200, Arnout Vandecappelle wrote:

</pre>
<blockquote type="cite">
<pre wrap=""> How about:

1. Applying <a class="moz-txt-link-freetext" href="http://patchwork.ozlabs.org/patch/898748/">http://patchwork.ozlabs.org/patch/898748/</a>, 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.
</pre>
</blockquote>
<pre wrap="">
Sounds like a good plan to me.

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

Best regards,

Thomas
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<title></title>
<br>
<div class="moz-signature">
<pre>Best regards / Cordialement,

<img alt="" src="cid:part1.157DF46A.633AF376@st.com" height="54" width="202">
Christophe Priouzeau | TINA: 166 7320 | Tel: &#43;33 244027320

STMicroelectronics 
ST oneline: <a href="http://www.st.com">www.st.com</a> 
</pre>
<p class="MsoNormal"><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<pre><http: www.st.com="">
<http: twitter.com#!st_world="">

</http:></http:></pre>
</div>
</div>
</body>
</html>
Arnout Vandecappelle May 31, 2018, 9:13 a.m. UTC | #14
On 31-05-18 10:34, Christophe PRIOUZEAU wrote:
> 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.

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

> 
> 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,
> 
> 
> Christophe Priouzeau | TINA: 166 7320 | Tel: +33 244027320
> 
> STMicroelectronics 
> ST oneline: www.st.com <http://www.st.com> 
> 
>  
>
Thomas Petazzoni May 31, 2018, 9:16 a.m. UTC | #15
Hello Christophe,

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

On Thu, 31 May 2018 08:34:08 +0000, Christophe PRIOUZEAU wrote:

>   I'm ok to provide the patches.

Great!

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

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
diff mbox series

Patch

diff --git a/configs/stm32f429_disco_defconfig b/configs/stm32f429_disco_defconfig
index 5237e9a..fc167d0 100644
--- a/configs/stm32f429_disco_defconfig
+++ b/configs/stm32f429_disco_defconfig
@@ -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