From: Russell King - ARM Linux admin <linux@armlinux.org.uk> To: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: Nick Desaulniers <ndesaulniers@google.com>, Nathan Chancellor <nathan@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, "kernelci-results@groups.io" <kernelci-results@groups.io>, Geert Uytterhoeven <geert+renesas@glider.be>, Nicolas Pitre <nico@fluxnic.net>, Linus Walleij <linus.walleij@linaro.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, clang-built-linux <clang-built-linux@googlegroups.com>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: next/master bisection: baseline.login on rk3288-rock2-square Date: Thu, 4 Feb 2021 21:50:33 +0000 [thread overview] Message-ID: <20210204215033.GD1463@shell.armlinux.org.uk> (raw) In-Reply-To: <253b2987-c8e9-fcb6-c1b9-81e765c0cc2a@collabora.com> On Thu, Feb 04, 2021 at 09:31:06PM +0000, Guillaume Tucker wrote: > On 04/02/2021 18:23, Nick Desaulniers wrote: > > You're right, I missed `LLVM=1`. Adding `LD=ld.bfd` I think should > > permit fallback to BFD. > > That was close, except we're cross-compiling with GCC for arm. > So I've now built a plain next-20210203 (without Ard's fix) using > this command line: > > make LD=arm-linux-gnueabihf-ld.bfd -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache clang" zImage > > I'm using a modified Docker image gtucker/kernelci-build-clang-11 > with the very latest LLVM 11 and gcc-8-arm-linux-gnueabihf > packages added to be able to use the GNU linker. BTW I guess we > should enable this kind of hybrid build setup on kernelci.org as > well. ... > And this booted fine, which confirms it's really down to how > ld.lld puts together the kernel image. Does it actually solve > the debate whether this is an issue to fix in the assembly code > or at link time? Well... as I mentioned previously, we don't really understand what is going on between the decompressor running with the caches on, turning the caches off, jumping into the decompressed kernel, and then getting to the v7 setup code. The results from various attempts at solving the problem which lead to Ard's original patch that caused your breakage were not making a whole lot of sense (I think I wrote that all up in a previous email thread, so won't repeat it here.) So, I was slightly nervous about merging Ard's fix - and your report suggested that there is indeed more going on here that we don't understand. When I was tracking down what was going on, I had this patch applied (I've had to recreate it, so may not be exactly what I had), with the DEBUG_LL stuff appropriately enabled. It may be worth applying this patch, enabling the DEBUG_LL stuff appropriately for one of your failing boards, and try booting it. You should get two strings of identical hex numbers that look something like: ffffffff480000000900040140003000000000004820071d40008090 If they're looking like instructions, for example: ee060f37e3a00080ee020f10ee020f30ee030f10e3a00903ee050f30 Then it's likely that you are seeing a very similar problem as I was without Ard's patch. If you do get instruction-like content, then you will likely find the sequence of instructions in the decompressor code. diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 28c9d32fa99a..19fa93ae282c 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -475,7 +475,39 @@ ENDPROC(cpu_pj4b_do_resume) ldr r12, [r0] add r12, r12, r0 @ the local stack stmia r12, {r1-r6, lr} @ v7_invalidate_l1 touches r0-r6 + ldr r0, [r12, #0] + bl printhex8 + ldr r0, [r12, #4] + bl printhex8 + ldr r0, [r12, #8] + bl printhex8 + ldr r0, [r12, #12] + bl printhex8 + ldr r0, [r12, #16] + bl printhex8 + ldr r0, [r12, #20] + bl printhex8 + ldr r0, [r12, #24] + bl printhex8 + mov r0, #'\n' + bl printch bl v7_invalidate_l1 + ldr r0, [r12, #0] + bl printhex8 + ldr r0, [r12, #4] + bl printhex8 + ldr r0, [r12, #8] + bl printhex8 + ldr r0, [r12, #12] + bl printhex8 + ldr r0, [r12, #16] + bl printhex8 + ldr r0, [r12, #20] + bl printhex8 + ldr r0, [r12, #24] + bl printhex8 + mov r0, #'\n' + bl printch ldmia r12, {r1-r6, lr} __v7_setup_cont: -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> To: Guillaume Tucker <guillaume.tucker@collabora.com> Cc: "kernelci-results@groups.io" <kernelci-results@groups.io>, Geert Uytterhoeven <geert+renesas@glider.be>, Nicolas Pitre <nico@fluxnic.net>, Linus Walleij <linus.walleij@linaro.org>, Nick Desaulniers <ndesaulniers@google.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Nathan Chancellor <nathan@kernel.org>, clang-built-linux <clang-built-linux@googlegroups.com>, Ard Biesheuvel <ardb@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: next/master bisection: baseline.login on rk3288-rock2-square Date: Thu, 4 Feb 2021 21:50:33 +0000 [thread overview] Message-ID: <20210204215033.GD1463@shell.armlinux.org.uk> (raw) In-Reply-To: <253b2987-c8e9-fcb6-c1b9-81e765c0cc2a@collabora.com> On Thu, Feb 04, 2021 at 09:31:06PM +0000, Guillaume Tucker wrote: > On 04/02/2021 18:23, Nick Desaulniers wrote: > > You're right, I missed `LLVM=1`. Adding `LD=ld.bfd` I think should > > permit fallback to BFD. > > That was close, except we're cross-compiling with GCC for arm. > So I've now built a plain next-20210203 (without Ard's fix) using > this command line: > > make LD=arm-linux-gnueabihf-ld.bfd -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache clang" zImage > > I'm using a modified Docker image gtucker/kernelci-build-clang-11 > with the very latest LLVM 11 and gcc-8-arm-linux-gnueabihf > packages added to be able to use the GNU linker. BTW I guess we > should enable this kind of hybrid build setup on kernelci.org as > well. ... > And this booted fine, which confirms it's really down to how > ld.lld puts together the kernel image. Does it actually solve > the debate whether this is an issue to fix in the assembly code > or at link time? Well... as I mentioned previously, we don't really understand what is going on between the decompressor running with the caches on, turning the caches off, jumping into the decompressed kernel, and then getting to the v7 setup code. The results from various attempts at solving the problem which lead to Ard's original patch that caused your breakage were not making a whole lot of sense (I think I wrote that all up in a previous email thread, so won't repeat it here.) So, I was slightly nervous about merging Ard's fix - and your report suggested that there is indeed more going on here that we don't understand. When I was tracking down what was going on, I had this patch applied (I've had to recreate it, so may not be exactly what I had), with the DEBUG_LL stuff appropriately enabled. It may be worth applying this patch, enabling the DEBUG_LL stuff appropriately for one of your failing boards, and try booting it. You should get two strings of identical hex numbers that look something like: ffffffff480000000900040140003000000000004820071d40008090 If they're looking like instructions, for example: ee060f37e3a00080ee020f10ee020f30ee030f10e3a00903ee050f30 Then it's likely that you are seeing a very similar problem as I was without Ard's patch. If you do get instruction-like content, then you will likely find the sequence of instructions in the decompressor code. diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 28c9d32fa99a..19fa93ae282c 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -475,7 +475,39 @@ ENDPROC(cpu_pj4b_do_resume) ldr r12, [r0] add r12, r12, r0 @ the local stack stmia r12, {r1-r6, lr} @ v7_invalidate_l1 touches r0-r6 + ldr r0, [r12, #0] + bl printhex8 + ldr r0, [r12, #4] + bl printhex8 + ldr r0, [r12, #8] + bl printhex8 + ldr r0, [r12, #12] + bl printhex8 + ldr r0, [r12, #16] + bl printhex8 + ldr r0, [r12, #20] + bl printhex8 + ldr r0, [r12, #24] + bl printhex8 + mov r0, #'\n' + bl printch bl v7_invalidate_l1 + ldr r0, [r12, #0] + bl printhex8 + ldr r0, [r12, #4] + bl printhex8 + ldr r0, [r12, #8] + bl printhex8 + ldr r0, [r12, #12] + bl printhex8 + ldr r0, [r12, #16] + bl printhex8 + ldr r0, [r12, #20] + bl printhex8 + ldr r0, [r12, #24] + bl printhex8 + mov r0, #'\n' + bl printch ldmia r12, {r1-r6, lr} __v7_setup_cont: -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-02-04 21:52 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <601b773a.1c69fb81.9f381.a32a@mx.google.com> 2021-02-04 8:43 ` next/master bisection: baseline.login on rk3288-rock2-square Guillaume Tucker 2021-02-04 8:43 ` Guillaume Tucker 2021-02-04 9:07 ` Ard Biesheuvel 2021-02-04 9:07 ` Ard Biesheuvel 2021-02-04 10:06 ` Russell King - ARM Linux admin 2021-02-04 10:06 ` Russell King - ARM Linux admin 2021-02-04 10:27 ` Ard Biesheuvel 2021-02-04 10:27 ` Ard Biesheuvel 2021-02-04 10:33 ` Guillaume Tucker 2021-02-04 10:33 ` Guillaume Tucker 2021-02-04 11:32 ` Guillaume Tucker 2021-02-04 11:32 ` Guillaume Tucker 2021-02-04 11:44 ` Russell King - ARM Linux admin 2021-02-04 11:44 ` Russell King - ARM Linux admin 2021-02-04 12:09 ` Ard Biesheuvel 2021-02-04 12:09 ` Ard Biesheuvel 2021-02-04 15:42 ` Ard Biesheuvel 2021-02-04 15:42 ` Ard Biesheuvel 2021-02-04 15:53 ` Guillaume Tucker 2021-02-04 15:53 ` Guillaume Tucker 2021-02-04 16:01 ` Ard Biesheuvel 2021-02-04 16:01 ` Ard Biesheuvel 2021-02-04 18:06 ` Nick Desaulniers 2021-02-04 18:06 ` Nick Desaulniers 2021-02-04 18:12 ` Nathan Chancellor 2021-02-04 18:12 ` Nathan Chancellor 2021-02-04 18:23 ` Nick Desaulniers 2021-02-04 18:23 ` Nick Desaulniers 2021-02-04 21:31 ` Guillaume Tucker 2021-02-04 21:31 ` Guillaume Tucker 2021-02-04 21:50 ` Russell King - ARM Linux admin [this message] 2021-02-04 21:50 ` Russell King - ARM Linux admin 2021-02-05 8:21 ` Ard Biesheuvel 2021-02-05 8:21 ` Ard Biesheuvel 2021-02-05 12:05 ` Ard Biesheuvel 2021-02-05 12:05 ` Ard Biesheuvel 2021-02-06 13:10 ` Guillaume Tucker 2021-02-06 13:10 ` Guillaume Tucker 2021-02-06 13:12 ` Ard Biesheuvel 2021-02-06 13:12 ` Ard Biesheuvel 2021-02-04 21:09 ` Guillaume Tucker 2021-02-04 21:09 ` Guillaume Tucker 2021-02-04 10:47 ` Russell King - ARM Linux admin 2021-02-04 10:47 ` Russell King - ARM Linux admin 2021-02-04 10:55 ` Ard Biesheuvel 2021-02-04 10:55 ` Ard Biesheuvel 2021-02-04 12:26 ` Marc Zyngier 2021-02-04 12:26 ` Marc Zyngier 2021-02-04 14:09 ` Russell King - ARM Linux admin 2021-02-04 14:09 ` Russell King - ARM Linux admin 2021-02-04 14:25 ` Ard Biesheuvel 2021-02-04 14:25 ` Ard Biesheuvel 2021-02-04 14:36 ` Russell King - ARM Linux admin 2021-02-04 14:36 ` Russell King - ARM Linux admin 2021-02-04 15:52 ` Ard Biesheuvel 2021-02-04 15:52 ` Ard Biesheuvel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210204215033.GD1463@shell.armlinux.org.uk \ --to=linux@armlinux.org.uk \ --cc=ardb@kernel.org \ --cc=clang-built-linux@googlegroups.com \ --cc=geert+renesas@glider.be \ --cc=guillaume.tucker@collabora.com \ --cc=kernelci-results@groups.io \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=nathan@kernel.org \ --cc=ndesaulniers@google.com \ --cc=nico@fluxnic.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.