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.stew...@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.stew...@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.g...@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 >>> > >>> > >>> >>> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
