[U-Boot] u-boot 2018.07/2018.09 'data abort' kernel start failure with GCC 8.2.0 on sun8i (H3)

Sat Aug 25 20:02:00 UTC 2018

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/702d167134149f420ea3bcbc194d63a2653a0c27#diff-b1d17b73566e43abd1a12620ae7b0052

11:31 <https://irclog.whitequark.org/linux-sunxi/2018-08-25#22910361> <
jernej>
https://github.com/bminor/binutils-gdb/commit/702d167134149f420ea3bcbc194d63a2653a0c27

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