[U-Boot] u-boot 2018.07/2018.09 'data abort' kernel start failure with GCC 8.2.0 on sun8i (H3)
Greetings,
As others have reported ( https://lists.denx.de/pipermail/u-boot/2018-July/334126.html), a 'data abort' occurs when attempting to load the kernel with recent u-boot compiled with recent GCC on Allwinner (Sunxi) H3 boards. I ran into this issue when performing a bootstrap of Shedbuilt GNU/Linux with upstream GCC 8.20, glibc 2.28 and binutils 2.31.1 on a Nano Pi Neo 512M board. I brought up this issue in IRC and did some debugging with xypron, who asked that I message the list.
Configurations I've personally tested: u-boot 2018.07 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.09-rc2 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.05 nanopi_neo_defconfig / GCC 7.3.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.03 nanopi_neo_defconfig / GCC 7.2.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.09-rc2 ARMv7 unaligned access patch ( https://lists.denx.de/pipermail/u-boot/2018-March/324202.html) / nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken
Error (captured on Nano Pi Neo 512M with 2018.09-rc2): (for complete log, see https://gist.github.com/austons/222c6f1fd304d0832bec9964a4f569f0) Starting kernel ...
data abort pc : [<5ff9f16c>] lr : [<5ff76ed7>] reloc pc : [<4a02916c>] lr : [<4a000ed7>] sp : 5bf50588 ip : 5bf568da fp : 40008000 r10: 5bf50698 r9 : 5bf55ee0 r8 : 00000400 r7 : 00000000 r6 : 40008000 r5 : 49ff8000 r4 : 00000000 r3 : 49ff8000 r2 : 49ff8000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode UK6_32 Code: e12fff1e e52de008 fa000001 e3a00000 (e49df008) Resetting CPU ...
I have access to a number of H3/sun8i test devices to assist in diagnosis. There is some speculation in the earlier thread that USB changes post-2018.07rc1 could be a cause, but the only confirmed workaround is reverting to earlier GCC. Thank you for your time. Please let me know if there are other details I can provide.
Auston Stewart Shedbuilt GNU/Linux http://shedbuilt.net
On 08/22/2018 01:05 AM, Auston Stewart wrote:
Greetings,
As others have reported (https://lists.denx.de/pipermail/u-boot/2018-July/334126.html), a 'data abort' occurs when attempting to load the kernel with recent u-boot compiled with recent GCC on Allwinner (Sunxi) H3 boards. I ran into this issue when performing a bootstrap of Shedbuilt GNU/Linux with upstream GCC 8.20, glibc 2.28 and binutils 2.31.1 on a Nano Pi Neo 512M board. I brought up this issue in IRC and did some debugging with xypron, who asked that I message the list.
Configurations I've personally tested: u-boot 2018.07 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.09-rc2 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.05 nanopi_neo_defconfig / GCC 7.3.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.03 nanopi_neo_defconfig / GCC 7.2.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.09-rc2 ARMv7 unaligned access patch (https://lists.denx.de/pipermail/u-boot/2018-March/324202.html) / nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken
Error (captured on Nano Pi Neo 512M with 2018.09-rc2): (for complete log, see https://gist.github.com/austons/222c6f1fd304d0832bec9964a4f569f0) Starting kernel ...
data abort pc : [<5ff9f16c>] lr : [<5ff76ed7>] reloc pc : [<4a02916c>] lr : [<4a000ed7>] sp : 5bf50588 ip : 5bf568da fp : 40008000 r10: 5bf50698 r9 : 5bf55ee0 r8 : 00000400 r7 : 00000000 r6 : 40008000 r5 : 49ff8000 r4 : 00000000 r3 : 49ff8000 r2 : 49ff8000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode UK6_32 Code: e12fff1e e52de008 fa000001 e3a00000 (e49df008) Resetting CPU ...
I have access to a number of H3/sun8i test devices to assist in diagnosis. There is some speculation in the earlier thread that USB changes post-2018.07rc1 could be a cause, but the only confirmed workaround is reverting to earlier GCC. Thank you for your time. Please let me know if there are other details I can provide.
Auston Stewart Shedbuilt GNU/Linux http://shedbuilt.net
Hi Auston,
I built Bananapi_defconfig with gcc 8.2 (Debian Buster) and had not problem to boot Linux.
Best regards
Heinrich
CC: ARM SUNXI maintainers
On 08/22/2018 01:31 AM, Heinrich Schuchardt wrote:
On 08/22/2018 01:05 AM, Auston Stewart wrote:
Greetings,
As others have reported (https://lists.denx.de/pipermail/u-boot/2018-July/334126.html), a 'data abort' occurs when attempting to load the kernel with recent u-boot compiled with recent GCC on Allwinner (Sunxi) H3 boards. I ran into this issue when performing a bootstrap of Shedbuilt GNU/Linux with upstream GCC 8.20, glibc 2.28 and binutils 2.31.1 on a Nano Pi Neo 512M board. I brought up this issue in IRC and did some debugging with xypron, who asked that I message the list.
Configurations I've personally tested: u-boot 2018.07 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.09-rc2 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.05 nanopi_neo_defconfig / GCC 7.3.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.03 nanopi_neo_defconfig / GCC 7.2.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.09-rc2 ARMv7 unaligned access patch (https://lists.denx.de/pipermail/u-boot/2018-March/324202.html) / nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken
Error (captured on Nano Pi Neo 512M with 2018.09-rc2): (for complete log, see https://gist.github.com/austons/222c6f1fd304d0832bec9964a4f569f0) Starting kernel ...
data abort pc : [<5ff9f16c>] lr : [<5ff76ed7>] reloc pc : [<4a02916c>] lr : [<4a000ed7>] sp : 5bf50588 ip : 5bf568da fp : 40008000 r10: 5bf50698 r9 : 5bf55ee0 r8 : 00000400 r7 : 00000000 r6 : 40008000 r5 : 49ff8000 r4 : 00000000 r3 : 49ff8000 r2 : 49ff8000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode UK6_32 Code: e12fff1e e52de008 fa000001 e3a00000 (e49df008) Resetting CPU ...
I have access to a number of H3/sun8i test devices to assist in diagnosis. There is some speculation in the earlier thread that USB changes post-2018.07rc1 could be a cause, but the only confirmed workaround is reverting to earlier GCC. Thank you for your time. Please let me know if there are other details I can provide.
Auston Stewart Shedbuilt GNU/Linux http://shedbuilt.net
Hi Auston,
I built Bananapi_defconfig with gcc 8.2 (Debian Buster) and had not problem to boot Linux.
Best regards
Heinrich
I tested another configuration to further isolate the issue:
u-boot 2018.05 / nanopi_neo_defconfig / GCC 8.2.0 + Linux 4.17.14 / GCC 8.2.0 = works
So something introduced between 2018.05 GA and 2018.07 GA associated with Sunxi H3 configs is rubbing GCC 8.2.0 the wrong way.
On Tue, Aug 21, 2018 at 1:41 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
CC: ARM SUNXI maintainers
On 08/22/2018 01:31 AM, Heinrich Schuchardt wrote:
On 08/22/2018 01:05 AM, Auston Stewart wrote:
Greetings,
As others have reported (https://lists.denx.de/pipermail/u-boot/2018-July/334126.html), a 'data abort' occurs when attempting to load the kernel with recent u-boot compiled with recent GCC on Allwinner (Sunxi) H3 boards. I ran into this issue when performing a bootstrap of Shedbuilt GNU/Linux with upstream GCC 8.20, glibc 2.28 and binutils 2.31.1 on a Nano Pi Neo 512M board. I brought up this issue in IRC and did some debugging with xypron, who asked that I message the list.
Configurations I've personally tested: u-boot 2018.07 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.09-rc2 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.05 nanopi_neo_defconfig / GCC 7.3.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.03 nanopi_neo_defconfig / GCC 7.2.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.09-rc2 ARMv7 unaligned access patch (https://lists.denx.de/pipermail/u-boot/2018-March/324202.html) / nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken
Error (captured on Nano Pi Neo 512M with 2018.09-rc2): (for complete log, see https://gist.github.com/austons/222c6f1fd304d0832bec9964a4f569f0) Starting kernel ...
data abort pc : [<5ff9f16c>] lr : [<5ff76ed7>] reloc pc : [<4a02916c>] lr : [<4a000ed7>] sp : 5bf50588 ip : 5bf568da fp : 40008000 r10: 5bf50698 r9 : 5bf55ee0 r8 : 00000400 r7 : 00000000 r6 : 40008000 r5 : 49ff8000 r4 : 00000000 r3 : 49ff8000 r2 : 49ff8000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode UK6_32 Code: e12fff1e e52de008 fa000001 e3a00000 (e49df008) Resetting CPU ...
I have access to a number of H3/sun8i test devices to assist in diagnosis. There is some speculation in the earlier thread that USB changes post-2018.07rc1 could be a cause, but the only confirmed workaround is reverting to earlier GCC. Thank you for your time. Please let me know if there are other details I can provide.
Auston Stewart Shedbuilt GNU/Linux http://shedbuilt.net
Hi Auston,
I built Bananapi_defconfig with gcc 8.2 (Debian Buster) and had not problem to boot Linux.
Best regards
Heinrich
Apologies! I just realized I had my SD cards mixed up. 2018.05 compiled with GCC 8.2.0 isn't working either, although I just see a 'resetting' message rather than the full dump. The 2018.05 installation I saw booting successfully was compiled using earlier GCC.
On Tue, Aug 21, 2018 at 3:17 PM Auston Stewart auston.stewart@gmail.com wrote:
I tested another configuration to further isolate the issue:
u-boot 2018.05 / nanopi_neo_defconfig / GCC 8.2.0 + Linux 4.17.14 / GCC 8.2.0 = works
So something introduced between 2018.05 GA and 2018.07 GA associated with Sunxi H3 configs is rubbing GCC 8.2.0 the wrong way.
On Tue, Aug 21, 2018 at 1:41 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
CC: ARM SUNXI maintainers
On 08/22/2018 01:31 AM, Heinrich Schuchardt wrote:
On 08/22/2018 01:05 AM, Auston Stewart wrote:
Greetings,
As others have reported (https://lists.denx.de/pipermail/u-boot/2018-July/334126.html), a
'data
abort' occurs when attempting to load the kernel with recent u-boot compiled with recent GCC on Allwinner (Sunxi) H3 boards. I ran into
this
issue when performing a bootstrap of Shedbuilt GNU/Linux with upstream GCC 8.20, glibc 2.28 and binutils 2.31.1 on a Nano Pi Neo 512M board. I brought up this issue in IRC and did some debugging with xypron,
who
asked that I message the list.
Configurations I've personally tested: u-boot 2018.07 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.09-rc2 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.05 nanopi_neo_defconfig / GCC 7.3.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.03 nanopi_neo_defconfig / GCC 7.2.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.09-rc2 ARMv7 unaligned access patch (https://lists.denx.de/pipermail/u-boot/2018-March/324202.html) / nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken
Error (captured on Nano Pi Neo 512M with 2018.09-rc2): (for complete log, see https://gist.github.com/austons/222c6f1fd304d0832bec9964a4f569f0) Starting kernel ...
data abort pc : [<5ff9f16c>] lr : [<5ff76ed7>] reloc pc : [<4a02916c>] lr : [<4a000ed7>] sp : 5bf50588 ip : 5bf568da fp : 40008000 r10: 5bf50698 r9 : 5bf55ee0 r8 : 00000400 r7 : 00000000 r6 : 40008000 r5 : 49ff8000 r4 : 00000000 r3 : 49ff8000 r2 : 49ff8000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode UK6_32 Code: e12fff1e e52de008 fa000001 e3a00000 (e49df008) Resetting CPU ...
I have access to a number of H3/sun8i test devices to assist in diagnosis. There is some speculation in the earlier thread that USB changes post-2018.07rc1 could be a cause, but the only confirmed workaround is reverting to earlier GCC. Thank you for your time. Please let me know if there are other
details
I can provide.
Auston Stewart Shedbuilt GNU/Linux http://shedbuilt.net
Hi Auston,
I built Bananapi_defconfig with gcc 8.2 (Debian Buster) and had not problem to boot Linux.
Best regards
Heinrich
I wanted to update the list with the latest findings from the Sunxi Linux community regarding the data abort when loading the kernel. Although early testing implicated recent GCC, more focused testing has identified binutils 2.31 as the culprit and a specific commit causing the u-boot regression. I apologize that I had not sufficiently isolated the various components of my toolchain in earlier testing. Details are below, with credit for in-depth analysis going to Jernek Skrabec and Chen-yu Tsai:
08:33 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22909764 < jernej> wens: this fixes PSCI U-Boot issue: http://sprunge.us/h0hK1k 08:33 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22909765 < jernej> why exactly, I don't know 08:34 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22909766 < jernej> I just noticed that ld from binutils-2.30 aligned secure section to 0x1000 08:34 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22909769 < jernej> but ld from binutils-2.31.1 does not (which seems to be correct behaviour) 08:34 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22909772 < jernej> so imo, it's U-Boot issue 08:35 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22909776 < jernej> wens: can you confirm that above patch solves the issue? 09:45 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22909984 < jernej> apritzel: you wrote U-Boot PSCI code, right? 09:46 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22909988 < jernej> I think code in some cases uses absolute addresses 09:46 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22909989 < jernej> which shouldn't right? 09:55 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910025 Gerwin_J_ is now known as Gerwin_J 11:14 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910294 < jernej> wens: it looks like if "CONSTANT(COMMONPAGESIZE)" in arch/arm/cpu/armv7/u-boot.lds is replaced with "0x1000" 11:14 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910295 < jernej> everything works 11:15 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910296 < jernej> so, maybe binutils bug nevertheless? 11:30 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910349 < jernej> wens: offending commit: https://github.com/bminor/binutils-gdb/commit/702d167134149f420ea3bcbc194d63...
11:31 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910361 < jernej> https://github.com/bminor/binutils-gdb/commit/702d167134149f420ea3bcbc194d63...
11:31 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910363 < jernej> if it is reverted, U-Boot works 12:54 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910672 < jernej> they changed a place where config.commonpagesize is set 12:54 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910674 < jernej> I think that is the issue 12:54 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910675 < jernej> I already filled a bug to binutils bugzilla 12:54 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910677 < jernej> let's see what they think 13:23 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910759 <wens> the result is __secure_start is completely not aligned (except for 4 byte alignment of course) 13:25 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910763 <wens> neither are the interrupt vectors for secure mode 13:25 https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910765 <wens> and there's also a gap between __secure_start and the interrupt vectors
On Tue, Aug 21, 2018 at 3:42 PM Auston Stewart auston.stewart@gmail.com wrote:
Apologies! I just realized I had my SD cards mixed up. 2018.05 compiled with GCC 8.2.0 isn't working either, although I just see a 'resetting' message rather than the full dump. The 2018.05 installation I saw booting successfully was compiled using earlier GCC.
On Tue, Aug 21, 2018 at 3:17 PM Auston Stewart auston.stewart@gmail.com wrote:
I tested another configuration to further isolate the issue:
u-boot 2018.05 / nanopi_neo_defconfig / GCC 8.2.0 + Linux 4.17.14 / GCC 8.2.0 = works
So something introduced between 2018.05 GA and 2018.07 GA associated with Sunxi H3 configs is rubbing GCC 8.2.0 the wrong way.
On Tue, Aug 21, 2018 at 1:41 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
CC: ARM SUNXI maintainers
On 08/22/2018 01:31 AM, Heinrich Schuchardt wrote:
On 08/22/2018 01:05 AM, Auston Stewart wrote:
Greetings,
As others have reported (https://lists.denx.de/pipermail/u-boot/2018-July/334126.html), a
'data
abort' occurs when attempting to load the kernel with recent u-boot compiled with recent GCC on Allwinner (Sunxi) H3 boards. I ran into
this
issue when performing a bootstrap of Shedbuilt GNU/Linux with upstream GCC 8.20, glibc 2.28 and binutils 2.31.1 on a Nano Pi Neo 512M board. I brought up this issue in IRC and did some debugging with xypron,
who
asked that I message the list.
Configurations I've personally tested: u-boot 2018.07 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.09-rc2 nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken u-boot 2018.05 nanopi_neo_defconfig / GCC 7.3.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.03 nanopi_neo_defconfig / GCC 7.2.0 + Kernel 4.17.14 / GCC 8.2.0 = works u-boot 2018.09-rc2 ARMv7 unaligned access patch (https://lists.denx.de/pipermail/u-boot/2018-March/324202.html) / nanopi_neo_defconfig / GCC 8.2.0 + Kernel 4.17.14 / GCC 8.2.0 = broken
Error (captured on Nano Pi Neo 512M with 2018.09-rc2): (for complete log, see https://gist.github.com/austons/222c6f1fd304d0832bec9964a4f569f0) Starting kernel ...
data abort pc : [<5ff9f16c>] lr : [<5ff76ed7>] reloc pc : [<4a02916c>] lr : [<4a000ed7>] sp : 5bf50588 ip : 5bf568da fp : 40008000 r10: 5bf50698 r9 : 5bf55ee0 r8 : 00000400 r7 : 00000000 r6 : 40008000 r5 : 49ff8000 r4 : 00000000 r3 : 49ff8000 r2 : 49ff8000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode UK6_32 Code: e12fff1e e52de008 fa000001 e3a00000 (e49df008) Resetting CPU ...
I have access to a number of H3/sun8i test devices to assist in diagnosis. There is some speculation in the earlier thread that USB changes post-2018.07rc1 could be a cause, but the only confirmed workaround is reverting to earlier GCC. Thank you for your time. Please let me know if there are other
details
I can provide.
Auston Stewart Shedbuilt GNU/Linux http://shedbuilt.net
Hi Auston,
I built Bananapi_defconfig with gcc 8.2 (Debian Buster) and had not problem to boot Linux.
Best regards
Heinrich
participants (2)
-
Auston Stewart -
Heinrich Schuchardt