* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot
@ 2015-03-25 18:03 ` Paul Walmsley
0 siblings, 0 replies; 33+ messages in thread
From: Paul Walmsley @ 2015-03-25 18:03 UTC (permalink / raw)
To: linux-arm-kernel
Hello Geert,
Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM:
multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20
multi_v7_defconfig boot.
Boot log before:
http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
Boot log after:
http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt
Any ideas? Stephen Warren thinks there might be an initcall that might
not check to see what kind of device it's running on.
- Paul
commit 4a3a6f86693922b29cf829c63f652b057f14619e
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Tue Feb 24 15:14:45 2015 +0100
ARM: multi_v7_defconfig: Enable shmobile platforms
Enable support for shmobile platforms that became multi-platform aware.
Several non-critical drivers and subsystems are built as modules, to keep
kernel size reasonable.
Tested on:
- r8a73a4/ape6evm:
- U-Boot fails with "Error: unrecognized/unsupported machine ID",
- kexec works.
- r8a7740/armadillo:
- Hermit boot loader fails (larger image, more memory corruption),
- kexec works.
- r8a7791/koelsch,
- sh73a0/kzm9g:
- zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n,
- kexec works.
- am335x/boneblack.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply [flat|nested] 33+ messages in thread* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 18:03 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-03-25 18:03 UTC (permalink / raw) To: linux-arm-kernel Hello Geert, Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 multi_v7_defconfig boot. Boot log before: http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt Boot log after: http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt Any ideas? Stephen Warren thinks there might be an initcall that might not check to see what kind of device it's running on. - Paul commit 4a3a6f86693922b29cf829c63f652b057f14619e Author: Geert Uytterhoeven <geert+renesas@glider.be> Date: Tue Feb 24 15:14:45 2015 +0100 ARM: multi_v7_defconfig: Enable shmobile platforms Enable support for shmobile platforms that became multi-platform aware. Several non-critical drivers and subsystems are built as modules, to keep kernel size reasonable. Tested on: - r8a73a4/ape6evm: - U-Boot fails with "Error: unrecognized/unsupported machine ID", - kexec works. - r8a7740/armadillo: - Hermit boot loader fails (larger image, more memory corruption), - kexec works. - r8a7791/koelsch, - sh73a0/kzm9g: - zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n, - kexec works. - am335x/boneblack. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de> ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 18:03 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-03-25 18:03 UTC (permalink / raw) To: geert+renesas Cc: swarren, pwalmsley, thierry.reding, horms+renesas, arnd, linux-arm-kernel, linux-tegra, linux-sh Hello Geert, Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 multi_v7_defconfig boot. Boot log before: http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt Boot log after: http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt Any ideas? Stephen Warren thinks there might be an initcall that might not check to see what kind of device it's running on. - Paul commit 4a3a6f86693922b29cf829c63f652b057f14619e Author: Geert Uytterhoeven <geert+renesas@glider.be> Date: Tue Feb 24 15:14:45 2015 +0100 ARM: multi_v7_defconfig: Enable shmobile platforms Enable support for shmobile platforms that became multi-platform aware. Several non-critical drivers and subsystems are built as modules, to keep kernel size reasonable. Tested on: - r8a73a4/ape6evm: - U-Boot fails with "Error: unrecognized/unsupported machine ID", - kexec works. - r8a7740/armadillo: - Hermit boot loader fails (larger image, more memory corruption), - kexec works. - r8a7791/koelsch, - sh73a0/kzm9g: - zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n, - kexec works. - am335x/boneblack. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Arnd Bergmann <arnd@arndb.de> ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 18:28 ` Tyler Baker 0 siblings, 0 replies; 33+ messages in thread From: Tyler Baker @ 2015-03-25 18:28 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: > > Hello Geert, > > Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: > multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 > multi_v7_defconfig boot. > > Boot log before: > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > Boot log after: > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > Any ideas? Stephen Warren thinks there might be an initcall that might > not check to see what kind of device it's running on. Can you try to shift your kernel load address around a bit? From experience with the boards from kernelci.org we find that as the multi v7 kernel size increases they can clobber memory when they get decompressed. > > > - Paul > > commit 4a3a6f86693922b29cf829c63f652b057f14619e > Author: Geert Uytterhoeven <geert+renesas@glider.be> > Date: Tue Feb 24 15:14:45 2015 +0100 > > ARM: multi_v7_defconfig: Enable shmobile platforms > > Enable support for shmobile platforms that became multi-platform aware. > Several non-critical drivers and subsystems are built as modules, to keep > kernel size reasonable. > > Tested on: > - r8a73a4/ape6evm: > - U-Boot fails with "Error: unrecognized/unsupported machine ID", > - kexec works. > - r8a7740/armadillo: > - Hermit boot loader fails (larger image, more memory corruption), > - kexec works. > - r8a7791/koelsch, > - sh73a0/kzm9g: > - zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n, > - kexec works. > - am335x/boneblack. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > Acked-by: Simon Horman <horms+renesas@verge.net.au> > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Cheers, Tyler ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 18:28 ` Tyler Baker 0 siblings, 0 replies; 33+ messages in thread From: Tyler Baker @ 2015-03-25 18:28 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: > > Hello Geert, > > Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: > multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 > multi_v7_defconfig boot. > > Boot log before: > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > Boot log after: > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > Any ideas? Stephen Warren thinks there might be an initcall that might > not check to see what kind of device it's running on. Can you try to shift your kernel load address around a bit? From experience with the boards from kernelci.org we find that as the multi v7 kernel size increases they can clobber memory when they get decompressed. > > > - Paul > > commit 4a3a6f86693922b29cf829c63f652b057f14619e > Author: Geert Uytterhoeven <geert+renesas@glider.be> > Date: Tue Feb 24 15:14:45 2015 +0100 > > ARM: multi_v7_defconfig: Enable shmobile platforms > > Enable support for shmobile platforms that became multi-platform aware. > Several non-critical drivers and subsystems are built as modules, to keep > kernel size reasonable. > > Tested on: > - r8a73a4/ape6evm: > - U-Boot fails with "Error: unrecognized/unsupported machine ID", > - kexec works. > - r8a7740/armadillo: > - Hermit boot loader fails (larger image, more memory corruption), > - kexec works. > - r8a7791/koelsch, > - sh73a0/kzm9g: > - zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n, > - kexec works. > - am335x/boneblack. > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> > Acked-by: Simon Horman <horms+renesas@verge.net.au> > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Cheers, Tyler ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 18:28 ` Tyler Baker 0 siblings, 0 replies; 33+ messages in thread From: Tyler Baker @ 2015-03-25 18:28 UTC (permalink / raw) To: Paul Walmsley Cc: geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, Arnd Bergmann, swarren-3lzwWm7+Weoh9ZMKESR00Q, linux-sh-u79uwXL29TY76Z2rM5mHXA, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, pwalmsley-DDmLM1+adcrQT0dZR+AlfA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ, linux-arm-kernel Hi Paul, On 25 March 2015 at 11:03, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote: > > Hello Geert, > > Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: > multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 > multi_v7_defconfig boot. > > Boot log before: > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > Boot log after: > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > Any ideas? Stephen Warren thinks there might be an initcall that might > not check to see what kind of device it's running on. Can you try to shift your kernel load address around a bit? From experience with the boards from kernelci.org we find that as the multi v7 kernel size increases they can clobber memory when they get decompressed. > > > - Paul > > commit 4a3a6f86693922b29cf829c63f652b057f14619e > Author: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> > Date: Tue Feb 24 15:14:45 2015 +0100 > > ARM: multi_v7_defconfig: Enable shmobile platforms > > Enable support for shmobile platforms that became multi-platform aware. > Several non-critical drivers and subsystems are built as modules, to keep > kernel size reasonable. > > Tested on: > - r8a73a4/ape6evm: > - U-Boot fails with "Error: unrecognized/unsupported machine ID", > - kexec works. > - r8a7740/armadillo: > - Hermit boot loader fails (larger image, more memory corruption), > - kexec works. > - r8a7791/koelsch, > - sh73a0/kzm9g: > - zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n, > - kexec works. > - am335x/boneblack. > > Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> > Acked-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> > Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Cheers, Tyler ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot 2015-03-25 18:28 ` Tyler Baker (?) @ 2015-03-25 18:46 ` Geert Uytterhoeven -1 siblings, 0 replies; 33+ messages in thread From: Geert Uytterhoeven @ 2015-03-25 18:46 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, Tyler, On Wed, Mar 25, 2015 at 7:28 PM, Tyler Baker <tyler.baker@linaro.org> wrote: > On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >> multi_v7_defconfig boot. >> >> Boot log before: >> >> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >> >> Boot log after: >> >> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt So it just hangs when booting the kernel. Do you have any early debugging support (earlycon, DEBUG_LL) for your kernel? >> Any ideas? Stephen Warren thinks there might be an initcall that might >> not check to see what kind of device it's running on. Always possible of course, but it didn't trigger on my boneblack. > Can you try to shift your kernel load address around a bit? From > experience with the boards from kernelci.org we find that as the multi > v7 kernel size increases they can clobber memory when they get > decompressed. Kernel size can indeed be an issue. I believe the failure to boot on ape6evm from U-Boot mentioned in the commit is caused by that, too. Note that the error message only shows up with DEBUG_LL enabled (and some manual editing of Kconfig.debug to make that work). I'll try changing the kernel load address on ape6evm, too. >> commit 4a3a6f86693922b29cf829c63f652b057f14619e >> Author: Geert Uytterhoeven <geert+renesas@glider.be> >> Date: Tue Feb 24 15:14:45 2015 +0100 >> >> ARM: multi_v7_defconfig: Enable shmobile platforms >> >> Enable support for shmobile platforms that became multi-platform aware. >> Several non-critical drivers and subsystems are built as modules, to keep >> kernel size reasonable. >> >> Tested on: >> - r8a73a4/ape6evm: >> - U-Boot fails with "Error: unrecognized/unsupported machine ID", >> - kexec works. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 18:46 ` Geert Uytterhoeven 0 siblings, 0 replies; 33+ messages in thread From: Geert Uytterhoeven @ 2015-03-25 18:46 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, Tyler, On Wed, Mar 25, 2015 at 7:28 PM, Tyler Baker <tyler.baker@linaro.org> wrote: > On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >> multi_v7_defconfig boot. >> >> Boot log before: >> >> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >> >> Boot log after: >> >> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt So it just hangs when booting the kernel. Do you have any early debugging support (earlycon, DEBUG_LL) for your kernel? >> Any ideas? Stephen Warren thinks there might be an initcall that might >> not check to see what kind of device it's running on. Always possible of course, but it didn't trigger on my boneblack. > Can you try to shift your kernel load address around a bit? From > experience with the boards from kernelci.org we find that as the multi > v7 kernel size increases they can clobber memory when they get > decompressed. Kernel size can indeed be an issue. I believe the failure to boot on ape6evm from U-Boot mentioned in the commit is caused by that, too. Note that the error message only shows up with DEBUG_LL enabled (and some manual editing of Kconfig.debug to make that work). I'll try changing the kernel load address on ape6evm, too. >> commit 4a3a6f86693922b29cf829c63f652b057f14619e >> Author: Geert Uytterhoeven <geert+renesas@glider.be> >> Date: Tue Feb 24 15:14:45 2015 +0100 >> >> ARM: multi_v7_defconfig: Enable shmobile platforms >> >> Enable support for shmobile platforms that became multi-platform aware. >> Several non-critical drivers and subsystems are built as modules, to keep >> kernel size reasonable. >> >> Tested on: >> - r8a73a4/ape6evm: >> - U-Boot fails with "Error: unrecognized/unsupported machine ID", >> - kexec works. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 18:46 ` Geert Uytterhoeven 0 siblings, 0 replies; 33+ messages in thread From: Geert Uytterhoeven @ 2015-03-25 18:46 UTC (permalink / raw) To: Paul Walmsley, Tyler Baker Cc: Geert Uytterhoeven, Arnd Bergmann, Stephen Warren, Linux-sh list, Thierry Reding, pwalmsley, linux-tegra, Simon Horman, linux-arm-kernel Hi Paul, Tyler, On Wed, Mar 25, 2015 at 7:28 PM, Tyler Baker <tyler.baker@linaro.org> wrote: > On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >> multi_v7_defconfig boot. >> >> Boot log before: >> >> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >> >> Boot log after: >> >> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt So it just hangs when booting the kernel. Do you have any early debugging support (earlycon, DEBUG_LL) for your kernel? >> Any ideas? Stephen Warren thinks there might be an initcall that might >> not check to see what kind of device it's running on. Always possible of course, but it didn't trigger on my boneblack. > Can you try to shift your kernel load address around a bit? From > experience with the boards from kernelci.org we find that as the multi > v7 kernel size increases they can clobber memory when they get > decompressed. Kernel size can indeed be an issue. I believe the failure to boot on ape6evm from U-Boot mentioned in the commit is caused by that, too. Note that the error message only shows up with DEBUG_LL enabled (and some manual editing of Kconfig.debug to make that work). I'll try changing the kernel load address on ape6evm, too. >> commit 4a3a6f86693922b29cf829c63f652b057f14619e >> Author: Geert Uytterhoeven <geert+renesas@glider.be> >> Date: Tue Feb 24 15:14:45 2015 +0100 >> >> ARM: multi_v7_defconfig: Enable shmobile platforms >> >> Enable support for shmobile platforms that became multi-platform aware. >> Several non-critical drivers and subsystems are built as modules, to keep >> kernel size reasonable. >> >> Tested on: >> - r8a73a4/ape6evm: >> - U-Boot fails with "Error: unrecognized/unsupported machine ID", >> - kexec works. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 22:00 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-03-25 22:00 UTC (permalink / raw) To: linux-arm-kernel Hi Tyler On Wed, 25 Mar 2015, Tyler Baker wrote: > On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: > > > Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: > > multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 > > multi_v7_defconfig boot. > > > > Boot log before: > > > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > > Boot log after: > > > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > > > > Any ideas? Stephen Warren thinks there might be an initcall that might > > not check to see what kind of device it's running on. > > Can you try to shift your kernel load address around a bit? From > experience with the boards from kernelci.org we find that as the multi > v7 kernel size increases they can clobber memory when they get > decompressed. Thanks, that was it: http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt Should have guessed when absolutely no debug output was emitted by the board... Sorry for the false alarm, Geert! - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 22:00 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-03-25 22:00 UTC (permalink / raw) To: linux-arm-kernel Hi Tyler On Wed, 25 Mar 2015, Tyler Baker wrote: > On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: > > > Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: > > multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 > > multi_v7_defconfig boot. > > > > Boot log before: > > > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > > Boot log after: > > > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > > > > Any ideas? Stephen Warren thinks there might be an initcall that might > > not check to see what kind of device it's running on. > > Can you try to shift your kernel load address around a bit? From > experience with the boards from kernelci.org we find that as the multi > v7 kernel size increases they can clobber memory when they get > decompressed. Thanks, that was it: http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt Should have guessed when absolutely no debug output was emitted by the board... Sorry for the false alarm, Geert! - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-25 22:00 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-03-25 22:00 UTC (permalink / raw) To: Tyler Baker Cc: geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, Arnd Bergmann, swarren-3lzwWm7+Weoh9ZMKESR00Q, linux-sh-u79uwXL29TY76Z2rM5mHXA, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, pwalmsley-DDmLM1+adcrQT0dZR+AlfA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ, linux-arm-kernel Hi Tyler On Wed, 25 Mar 2015, Tyler Baker wrote: > On 25 March 2015 at 11:03, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote: > > > Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: > > multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 > > multi_v7_defconfig boot. > > > > Boot log before: > > > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > > Boot log after: > > > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > > > > Any ideas? Stephen Warren thinks there might be an initcall that might > > not check to see what kind of device it's running on. > > Can you try to shift your kernel load address around a bit? From > experience with the boards from kernelci.org we find that as the multi > v7 kernel size increases they can clobber memory when they get > decompressed. Thanks, that was it: http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt Should have guessed when absolutely no debug output was emitted by the board... Sorry for the false alarm, Geert! - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-26 2:36 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-03-26 2:36 UTC (permalink / raw) To: linux-arm-kernel On 03/25/2015 04:00 PM, Paul Walmsley wrote: > Hi Tyler > > On Wed, 25 Mar 2015, Tyler Baker wrote: > >> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >> >>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>> multi_v7_defconfig boot. >>> >>> Boot log before: >>> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>> >>> Boot log after: >>> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>> >>> >>> Any ideas? Stephen Warren thinks there might be an initcall that might >>> not check to see what kind of device it's running on. >> >> Can you try to shift your kernel load address around a bit? From >> experience with the boards from kernelci.org we find that as the multi >> v7 kernel size increases they can clobber memory when they get >> decompressed. > > Thanks, that was it: > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > Should have guessed when absolutely no debug output was emitted by the > board... > > Sorry for the false alarm, Geert! Interesting. Do the values in U-Boot's default environment work correctly ("env default -f -a" will reset the environment to default, in case some old values are saved in flash); I put some effort into picking them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r}, ${ramdisk_addr_r}. ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-26 2:36 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-03-26 2:36 UTC (permalink / raw) To: linux-arm-kernel On 03/25/2015 04:00 PM, Paul Walmsley wrote: > Hi Tyler > > On Wed, 25 Mar 2015, Tyler Baker wrote: > >> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >> >>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>> multi_v7_defconfig boot. >>> >>> Boot log before: >>> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>> >>> Boot log after: >>> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>> >>> >>> Any ideas? Stephen Warren thinks there might be an initcall that might >>> not check to see what kind of device it's running on. >> >> Can you try to shift your kernel load address around a bit? From >> experience with the boards from kernelci.org we find that as the multi >> v7 kernel size increases they can clobber memory when they get >> decompressed. > > Thanks, that was it: > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > Should have guessed when absolutely no debug output was emitted by the > board... > > Sorry for the false alarm, Geert! Interesting. Do the values in U-Boot's default environment work correctly ("env default -f -a" will reset the environment to default, in case some old values are saved in flash); I put some effort into picking them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r}, ${ramdisk_addr_r}. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-26 2:36 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-03-26 2:36 UTC (permalink / raw) To: Paul Walmsley Cc: Tyler Baker, geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, Arnd Bergmann, linux-sh-u79uwXL29TY76Z2rM5mHXA, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, pwalmsley-DDmLM1+adcrQT0dZR+AlfA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ, linux-arm-kernel On 03/25/2015 04:00 PM, Paul Walmsley wrote: > Hi Tyler > > On Wed, 25 Mar 2015, Tyler Baker wrote: > >> On 25 March 2015 at 11:03, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote: >> >>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>> multi_v7_defconfig boot. >>> >>> Boot log before: >>> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>> >>> Boot log after: >>> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>> >>> >>> Any ideas? Stephen Warren thinks there might be an initcall that might >>> not check to see what kind of device it's running on. >> >> Can you try to shift your kernel load address around a bit? From >> experience with the boards from kernelci.org we find that as the multi >> v7 kernel size increases they can clobber memory when they get >> decompressed. > > Thanks, that was it: > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > Should have guessed when absolutely no debug output was emitted by the > board... > > Sorry for the false alarm, Geert! Interesting. Do the values in U-Boot's default environment work correctly ("env default -f -a" will reset the environment to default, in case some old values are saved in flash); I put some effort into picking them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r}, ${ramdisk_addr_r}. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot 2015-03-26 2:36 ` Stephen Warren (?) @ 2015-03-26 18:35 ` Paul Walmsley -1 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-03-26 18:35 UTC (permalink / raw) To: linux-arm-kernel On Wed, 25 Mar 2015, Stephen Warren wrote: > On 03/25/2015 04:00 PM, Paul Walmsley wrote: > > On Wed, 25 Mar 2015, Tyler Baker wrote: > >> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: > >>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: > >>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 > >>> multi_v7_defconfig boot. > >>> > >>> Boot log before: > >>> > >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > >>> > >>> Boot log after: > >>> > >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > >>> > >>> > >>> Any ideas? Stephen Warren thinks there might be an initcall that might > >>> not check to see what kind of device it's running on. > >> > >> Can you try to shift your kernel load address around a bit? From > >> experience with the boards from kernelci.org we find that as the multi > >> v7 kernel size increases they can clobber memory when they get > >> decompressed. > > > > Thanks, that was it: > > > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > > Should have guessed when absolutely no debug output was emitted by the > > board... > > > > Sorry for the false alarm, Geert! > > Interesting. Do the values in U-Boot's default environment work > correctly No idea, I haven't tried. (The load addresses I used are observable in the boot logs above.) > ("env default -f -a" will reset the environment to default, in > case some old values are saved in flash); I put some effort into picking > them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r}, > ${ramdisk_addr_r}. According to the tegra20-common.h file in the u-boot source here, kernel_addr_r is 0x01000000 and fdt_addr_r is 0x02000000. If one assumes the problem is that the kernel decompressor is overwriting the DTB, then I suspect they wouldn't work either, since the gap between the addresses is the same as what I used (0x01000000). - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-26 18:35 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-03-26 18:35 UTC (permalink / raw) To: linux-arm-kernel On Wed, 25 Mar 2015, Stephen Warren wrote: > On 03/25/2015 04:00 PM, Paul Walmsley wrote: > > On Wed, 25 Mar 2015, Tyler Baker wrote: > >> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: > >>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: > >>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 > >>> multi_v7_defconfig boot. > >>> > >>> Boot log before: > >>> > >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > >>> > >>> Boot log after: > >>> > >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > >>> > >>> > >>> Any ideas? Stephen Warren thinks there might be an initcall that might > >>> not check to see what kind of device it's running on. > >> > >> Can you try to shift your kernel load address around a bit? From > >> experience with the boards from kernelci.org we find that as the multi > >> v7 kernel size increases they can clobber memory when they get > >> decompressed. > > > > Thanks, that was it: > > > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > > Should have guessed when absolutely no debug output was emitted by the > > board... > > > > Sorry for the false alarm, Geert! > > Interesting. Do the values in U-Boot's default environment work > correctly No idea, I haven't tried. (The load addresses I used are observable in the boot logs above.) > ("env default -f -a" will reset the environment to default, in > case some old values are saved in flash); I put some effort into picking > them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r}, > ${ramdisk_addr_r}. According to the tegra20-common.h file in the u-boot source here, kernel_addr_r is 0x01000000 and fdt_addr_r is 0x02000000. If one assumes the problem is that the kernel decompressor is overwriting the DTB, then I suspect they wouldn't work either, since the gap between the addresses is the same as what I used (0x01000000). - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-26 18:35 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-03-26 18:35 UTC (permalink / raw) To: Stephen Warren Cc: Tyler Baker, geert+renesas, Arnd Bergmann, linux-sh, thierry.reding, pwalmsley, linux-tegra, horms+renesas, linux-arm-kernel On Wed, 25 Mar 2015, Stephen Warren wrote: > On 03/25/2015 04:00 PM, Paul Walmsley wrote: > > On Wed, 25 Mar 2015, Tyler Baker wrote: > >> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: > >>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: > >>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 > >>> multi_v7_defconfig boot. > >>> > >>> Boot log before: > >>> > >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > >>> > >>> Boot log after: > >>> > >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > >>> > >>> > >>> Any ideas? Stephen Warren thinks there might be an initcall that might > >>> not check to see what kind of device it's running on. > >> > >> Can you try to shift your kernel load address around a bit? From > >> experience with the boards from kernelci.org we find that as the multi > >> v7 kernel size increases they can clobber memory when they get > >> decompressed. > > > > Thanks, that was it: > > > > http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt > > > > Should have guessed when absolutely no debug output was emitted by the > > board... > > > > Sorry for the false alarm, Geert! > > Interesting. Do the values in U-Boot's default environment work > correctly No idea, I haven't tried. (The load addresses I used are observable in the boot logs above.) > ("env default -f -a" will reset the environment to default, in > case some old values are saved in flash); I put some effort into picking > them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r}, > ${ramdisk_addr_r}. According to the tegra20-common.h file in the u-boot source here, kernel_addr_r is 0x01000000 and fdt_addr_r is 0x02000000. If one assumes the problem is that the kernel decompressor is overwriting the DTB, then I suspect they wouldn't work either, since the gap between the addresses is the same as what I used (0x01000000). - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot 2015-03-26 18:35 ` Paul Walmsley (?) @ 2015-03-26 18:57 ` Stephen Warren -1 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-03-26 18:57 UTC (permalink / raw) To: linux-arm-kernel On 03/26/2015 12:35 PM, Paul Walmsley wrote: > On Wed, 25 Mar 2015, Stephen Warren wrote: > >> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>> multi_v7_defconfig boot. >>>>> >>>>> Boot log before: >>>>> >>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>> >>>>> Boot log after: >>>>> >>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>> >>>>> >>>>> Any ideas? Stephen Warren thinks there might be an initcall that might >>>>> not check to see what kind of device it's running on. >>>> >>>> Can you try to shift your kernel load address around a bit? From >>>> experience with the boards from kernelci.org we find that as the multi >>>> v7 kernel size increases they can clobber memory when they get >>>> decompressed. >>> >>> Thanks, that was it: >>> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>> >>> Should have guessed when absolutely no debug output was emitted by the >>> board... >>> >>> Sorry for the false alarm, Geert! >> >> Interesting. Do the values in U-Boot's default environment work >> correctly > > No idea, I haven't tried. (The load addresses I used are observable in > the boot logs above.) Sure. I was hoping you'd try it out since you already had the setup to repro the issue. It'd be good if your test-bed used the built-in U-Boot variables too, so we're testing them. >> ("env default -f -a" will reset the environment to default, in >> case some old values are saved in flash); I put some effort into picking >> them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r}, >> ${ramdisk_addr_r}. > > According to the tegra20-common.h file in the u-boot source here, > kernel_addr_r is 0x01000000 and fdt_addr_r is 0x02000000. If one assumes > the problem is that the kernel decompressor is overwriting the DTB, then > I suspect they wouldn't work either, since the gap between the addresses > is the same as what I used (0x01000000). I expect the issue is more how close the uncompressed kernel and/or DTB are to the start of RAM (where the decompressor writes to). IIRC, if the decompressor is going to overwrite the compressed kernel during decompression, it moves itself first. I can't remember where the destination of the move is, but perhaps the relocation can over-write the DTB. By pushing the location of the compressed kernel away from the start of RAM, this relocation won't happen. IIRC when the decompression happens, or relocation prior to decompression, there's no protection of the DTB being overwritten. ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-26 18:57 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-03-26 18:57 UTC (permalink / raw) To: linux-arm-kernel On 03/26/2015 12:35 PM, Paul Walmsley wrote: > On Wed, 25 Mar 2015, Stephen Warren wrote: > >> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>> multi_v7_defconfig boot. >>>>> >>>>> Boot log before: >>>>> >>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>> >>>>> Boot log after: >>>>> >>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>> >>>>> >>>>> Any ideas? Stephen Warren thinks there might be an initcall that might >>>>> not check to see what kind of device it's running on. >>>> >>>> Can you try to shift your kernel load address around a bit? From >>>> experience with the boards from kernelci.org we find that as the multi >>>> v7 kernel size increases they can clobber memory when they get >>>> decompressed. >>> >>> Thanks, that was it: >>> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>> >>> Should have guessed when absolutely no debug output was emitted by the >>> board... >>> >>> Sorry for the false alarm, Geert! >> >> Interesting. Do the values in U-Boot's default environment work >> correctly > > No idea, I haven't tried. (The load addresses I used are observable in > the boot logs above.) Sure. I was hoping you'd try it out since you already had the setup to repro the issue. It'd be good if your test-bed used the built-in U-Boot variables too, so we're testing them. >> ("env default -f -a" will reset the environment to default, in >> case some old values are saved in flash); I put some effort into picking >> them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r}, >> ${ramdisk_addr_r}. > > According to the tegra20-common.h file in the u-boot source here, > kernel_addr_r is 0x01000000 and fdt_addr_r is 0x02000000. If one assumes > the problem is that the kernel decompressor is overwriting the DTB, then > I suspect they wouldn't work either, since the gap between the addresses > is the same as what I used (0x01000000). I expect the issue is more how close the uncompressed kernel and/or DTB are to the start of RAM (where the decompressor writes to). IIRC, if the decompressor is going to overwrite the compressed kernel during decompression, it moves itself first. I can't remember where the destination of the move is, but perhaps the relocation can over-write the DTB. By pushing the location of the compressed kernel away from the start of RAM, this relocation won't happen. IIRC when the decompression happens, or relocation prior to decompression, there's no protection of the DTB being overwritten. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-03-26 18:57 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-03-26 18:57 UTC (permalink / raw) To: Paul Walmsley Cc: Tyler Baker, geert+renesas, Arnd Bergmann, linux-sh, thierry.reding, pwalmsley, linux-tegra, horms+renesas, linux-arm-kernel On 03/26/2015 12:35 PM, Paul Walmsley wrote: > On Wed, 25 Mar 2015, Stephen Warren wrote: > >> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>> multi_v7_defconfig boot. >>>>> >>>>> Boot log before: >>>>> >>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105514_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325105514/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>> >>>>> Boot log after: >>>>> >>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325105350_4a3a6f86693922b29cf829c63f652b057f14619e/20150325105350/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>> >>>>> >>>>> Any ideas? Stephen Warren thinks there might be an initcall that might >>>>> not check to see what kind of device it's running on. >>>> >>>> Can you try to shift your kernel load address around a bit? From >>>> experience with the boards from kernelci.org we find that as the multi >>>> v7 kernel size increases they can clobber memory when they get >>>> decompressed. >>> >>> Thanks, that was it: >>> >>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>> >>> Should have guessed when absolutely no debug output was emitted by the >>> board... >>> >>> Sorry for the false alarm, Geert! >> >> Interesting. Do the values in U-Boot's default environment work >> correctly > > No idea, I haven't tried. (The load addresses I used are observable in > the boot logs above.) Sure. I was hoping you'd try it out since you already had the setup to repro the issue. It'd be good if your test-bed used the built-in U-Boot variables too, so we're testing them. >> ("env default -f -a" will reset the environment to default, in >> case some old values are saved in flash); I put some effort into picking >> them so I really hope they work! ${kernel_addr_r}, ${fdt_addr_r}, >> ${ramdisk_addr_r}. > > According to the tegra20-common.h file in the u-boot source here, > kernel_addr_r is 0x01000000 and fdt_addr_r is 0x02000000. If one assumes > the problem is that the kernel decompressor is overwriting the DTB, then > I suspect they wouldn't work either, since the gap between the addresses > is the same as what I used (0x01000000). I expect the issue is more how close the uncompressed kernel and/or DTB are to the start of RAM (where the decompressor writes to). IIRC, if the decompressor is going to overwrite the compressed kernel during decompression, it moves itself first. I can't remember where the destination of the move is, but perhaps the relocation can over-write the DTB. By pushing the location of the compressed kernel away from the start of RAM, this relocation won't happen. IIRC when the decompression happens, or relocation prior to decompression, there's no protection of the DTB being overwritten. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-04-01 17:14 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-04-01 17:14 UTC (permalink / raw) To: linux-arm-kernel On 03/26/2015 12:57 PM, Stephen Warren wrote: > On 03/26/2015 12:35 PM, Paul Walmsley wrote: >> On Wed, 25 Mar 2015, Stephen Warren wrote: >> >>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>> multi_v7_defconfig boot. ... >>>>> Can you try to shift your kernel load address around a bit? From >>>>> experience with the boards from kernelci.org we find that as the multi >>>>> v7 kernel size increases they can clobber memory when they get >>>>> decompressed. >>>> >>>> Thanks, that was it: >>>> >>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt ... >>> Interesting. Do the values in U-Boot's default environment work >>> correctly >> >> No idea, I haven't tried. (The load addresses I used are observable in >> the boot logs above.) > > Sure. I was hoping you'd try it out since you already had the setup to > repro the issue. > > It'd be good if your test-bed used the built-in U-Boot variables too, so > we're testing them. I've reproduced the original problem, and then validated that using the addresses from U-Boot's default environment (at least with a ToT U-Boot that I just built) does indeed solve it. I'd like to re-iterate that the test bed should be using the values from U-Boot's environment rather than making up its own. That way: * The value the test bed uses for the kernel load address likely overlaps where the kernel decompressor writes to for even slightly large kernels. This means the decompressor must move itself before decompressing. IIUC, there's zero guarantee that moving the decompressor won't overwrite the DTB, since IIUC the decompressor uses zero knowledge of the DTB location. In other words, if the compressed kernel is loaded somewhere that's likely to require it to move itself, there's a real risk of the exact same problem cropping up again in the future if the kernel happens to overwrite the DTB during relocation. * The values are part of every Tegra U-Boot port (and hopefully for other SoCs too given any distro using boot.scr with config_distro_bootcmd.h will expect the variables to exist), so for future (Tegra) chips you won't have to adjust the test bed if RAM layout changes. * Those values get testing, so we'll find out if the ever don't work. We get more test coverage. ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-04-01 17:14 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-04-01 17:14 UTC (permalink / raw) To: linux-arm-kernel On 03/26/2015 12:57 PM, Stephen Warren wrote: > On 03/26/2015 12:35 PM, Paul Walmsley wrote: >> On Wed, 25 Mar 2015, Stephen Warren wrote: >> >>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>> multi_v7_defconfig boot. ... >>>>> Can you try to shift your kernel load address around a bit? From >>>>> experience with the boards from kernelci.org we find that as the multi >>>>> v7 kernel size increases they can clobber memory when they get >>>>> decompressed. >>>> >>>> Thanks, that was it: >>>> >>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt ... >>> Interesting. Do the values in U-Boot's default environment work >>> correctly >> >> No idea, I haven't tried. (The load addresses I used are observable in >> the boot logs above.) > > Sure. I was hoping you'd try it out since you already had the setup to > repro the issue. > > It'd be good if your test-bed used the built-in U-Boot variables too, so > we're testing them. I've reproduced the original problem, and then validated that using the addresses from U-Boot's default environment (at least with a ToT U-Boot that I just built) does indeed solve it. I'd like to re-iterate that the test bed should be using the values from U-Boot's environment rather than making up its own. That way: * The value the test bed uses for the kernel load address likely overlaps where the kernel decompressor writes to for even slightly large kernels. This means the decompressor must move itself before decompressing. IIUC, there's zero guarantee that moving the decompressor won't overwrite the DTB, since IIUC the decompressor uses zero knowledge of the DTB location. In other words, if the compressed kernel is loaded somewhere that's likely to require it to move itself, there's a real risk of the exact same problem cropping up again in the future if the kernel happens to overwrite the DTB during relocation. * The values are part of every Tegra U-Boot port (and hopefully for other SoCs too given any distro using boot.scr with config_distro_bootcmd.h will expect the variables to exist), so for future (Tegra) chips you won't have to adjust the test bed if RAM layout changes. * Those values get testing, so we'll find out if the ever don't work. We get more test coverage. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-04-01 17:14 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-04-01 17:14 UTC (permalink / raw) To: Paul Walmsley Cc: Tyler Baker, geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, Arnd Bergmann, linux-sh-u79uwXL29TY76Z2rM5mHXA, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, pwalmsley-DDmLM1+adcrQT0dZR+AlfA, linux-tegra-u79uwXL29TY76Z2rM5mHXA, horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ, linux-arm-kernel On 03/26/2015 12:57 PM, Stephen Warren wrote: > On 03/26/2015 12:35 PM, Paul Walmsley wrote: >> On Wed, 25 Mar 2015, Stephen Warren wrote: >> >>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote: >>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>> multi_v7_defconfig boot. ... >>>>> Can you try to shift your kernel load address around a bit? From >>>>> experience with the boards from kernelci.org we find that as the multi >>>>> v7 kernel size increases they can clobber memory when they get >>>>> decompressed. >>>> >>>> Thanks, that was it: >>>> >>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt ... >>> Interesting. Do the values in U-Boot's default environment work >>> correctly >> >> No idea, I haven't tried. (The load addresses I used are observable in >> the boot logs above.) > > Sure. I was hoping you'd try it out since you already had the setup to > repro the issue. > > It'd be good if your test-bed used the built-in U-Boot variables too, so > we're testing them. I've reproduced the original problem, and then validated that using the addresses from U-Boot's default environment (at least with a ToT U-Boot that I just built) does indeed solve it. I'd like to re-iterate that the test bed should be using the values from U-Boot's environment rather than making up its own. That way: * The value the test bed uses for the kernel load address likely overlaps where the kernel decompressor writes to for even slightly large kernels. This means the decompressor must move itself before decompressing. IIUC, there's zero guarantee that moving the decompressor won't overwrite the DTB, since IIUC the decompressor uses zero knowledge of the DTB location. In other words, if the compressed kernel is loaded somewhere that's likely to require it to move itself, there's a real risk of the exact same problem cropping up again in the future if the kernel happens to overwrite the DTB during relocation. * The values are part of every Tegra U-Boot port (and hopefully for other SoCs too given any distro using boot.scr with config_distro_bootcmd.h will expect the variables to exist), so for future (Tegra) chips you won't have to adjust the test bed if RAM layout changes. * Those values get testing, so we'll find out if the ever don't work. We get more test coverage. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot 2015-04-01 17:14 ` Stephen Warren (?) @ 2015-04-01 17:48 ` Paul Walmsley -1 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-04-01 17:48 UTC (permalink / raw) To: linux-arm-kernel On 04/01/2015 11:14 AM, Stephen Warren wrote: > On 03/26/2015 12:57 PM, Stephen Warren wrote: >> On 03/26/2015 12:35 PM, Paul Walmsley wrote: >>> On Wed, 25 Mar 2015, Stephen Warren wrote: >>> >>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>>> multi_v7_defconfig boot. > ... >>>>>> Can you try to shift your kernel load address around a bit? From >>>>>> experience with the boards from kernelci.org we find that as the >>>>>> multi >>>>>> v7 kernel size increases they can clobber memory when they get >>>>>> decompressed. >>>>> >>>>> Thanks, that was it: >>>>> >>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>> > ... >>>> Interesting. Do the values in U-Boot's default environment work >>>> correctly >>> >>> No idea, I haven't tried. (The load addresses I used are observable in >>> the boot logs above.) >> >> Sure. I was hoping you'd try it out since you already had the setup to >> repro the issue. >> >> It'd be good if your test-bed used the built-in U-Boot variables too, so >> we're testing them. > > I've reproduced the original problem, and then validated that using > the addresses from U-Boot's default environment (at least with a ToT > U-Boot that I just built) does indeed solve it. > > I'd like to re-iterate that the test bed should be using the values > from U-Boot's environment rather than making up its own. That way: > > * The value the test bed uses for the kernel load address likely > overlaps where the kernel decompressor writes to for even slightly > large kernels. This means the decompressor must move itself before > decompressing. IIUC, there's zero guarantee that moving the > decompressor won't overwrite the DTB, since IIUC the decompressor uses > zero knowledge of the DTB location. In other words, if the compressed > kernel is loaded somewhere that's likely to require it to move itself, > there's a real risk of the exact same problem cropping up again in the > future if the kernel happens to overwrite the DTB during relocation. > > * The values are part of every Tegra U-Boot port (and hopefully for > other SoCs too given any distro using boot.scr with > config_distro_bootcmd.h will expect the variables to exist), so for > future (Tegra) chips you won't have to adjust the test bed if RAM > layout changes. > > * Those values get testing, so we'll find out if the ever don't work. > We get more test coverage. Sounds reasonable, I'll try to get to this at some point soon. BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the value you define for kernel_addr_r. That would reinforce to folks who aren't using the U-boot scripts that they should use that address for loading their kernel. - Paul - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-04-01 17:48 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-04-01 17:48 UTC (permalink / raw) To: linux-arm-kernel On 04/01/2015 11:14 AM, Stephen Warren wrote: > On 03/26/2015 12:57 PM, Stephen Warren wrote: >> On 03/26/2015 12:35 PM, Paul Walmsley wrote: >>> On Wed, 25 Mar 2015, Stephen Warren wrote: >>> >>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>>> multi_v7_defconfig boot. > ... >>>>>> Can you try to shift your kernel load address around a bit? From >>>>>> experience with the boards from kernelci.org we find that as the >>>>>> multi >>>>>> v7 kernel size increases they can clobber memory when they get >>>>>> decompressed. >>>>> >>>>> Thanks, that was it: >>>>> >>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>> > ... >>>> Interesting. Do the values in U-Boot's default environment work >>>> correctly >>> >>> No idea, I haven't tried. (The load addresses I used are observable in >>> the boot logs above.) >> >> Sure. I was hoping you'd try it out since you already had the setup to >> repro the issue. >> >> It'd be good if your test-bed used the built-in U-Boot variables too, so >> we're testing them. > > I've reproduced the original problem, and then validated that using > the addresses from U-Boot's default environment (at least with a ToT > U-Boot that I just built) does indeed solve it. > > I'd like to re-iterate that the test bed should be using the values > from U-Boot's environment rather than making up its own. That way: > > * The value the test bed uses for the kernel load address likely > overlaps where the kernel decompressor writes to for even slightly > large kernels. This means the decompressor must move itself before > decompressing. IIUC, there's zero guarantee that moving the > decompressor won't overwrite the DTB, since IIUC the decompressor uses > zero knowledge of the DTB location. In other words, if the compressed > kernel is loaded somewhere that's likely to require it to move itself, > there's a real risk of the exact same problem cropping up again in the > future if the kernel happens to overwrite the DTB during relocation. > > * The values are part of every Tegra U-Boot port (and hopefully for > other SoCs too given any distro using boot.scr with > config_distro_bootcmd.h will expect the variables to exist), so for > future (Tegra) chips you won't have to adjust the test bed if RAM > layout changes. > > * Those values get testing, so we'll find out if the ever don't work. > We get more test coverage. Sounds reasonable, I'll try to get to this at some point soon. BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the value you define for kernel_addr_r. That would reinforce to folks who aren't using the U-boot scripts that they should use that address for loading their kernel. - Paul - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-04-01 17:48 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-04-01 17:48 UTC (permalink / raw) To: Stephen Warren, Paul Walmsley Cc: Tyler Baker, geert+renesas, Arnd Bergmann, linux-sh, thierry.reding, linux-tegra, horms+renesas, linux-arm-kernel On 04/01/2015 11:14 AM, Stephen Warren wrote: > On 03/26/2015 12:57 PM, Stephen Warren wrote: >> On 03/26/2015 12:35 PM, Paul Walmsley wrote: >>> On Wed, 25 Mar 2015, Stephen Warren wrote: >>> >>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>>> multi_v7_defconfig boot. > ... >>>>>> Can you try to shift your kernel load address around a bit? From >>>>>> experience with the boards from kernelci.org we find that as the >>>>>> multi >>>>>> v7 kernel size increases they can clobber memory when they get >>>>>> decompressed. >>>>> >>>>> Thanks, that was it: >>>>> >>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>> > ... >>>> Interesting. Do the values in U-Boot's default environment work >>>> correctly >>> >>> No idea, I haven't tried. (The load addresses I used are observable in >>> the boot logs above.) >> >> Sure. I was hoping you'd try it out since you already had the setup to >> repro the issue. >> >> It'd be good if your test-bed used the built-in U-Boot variables too, so >> we're testing them. > > I've reproduced the original problem, and then validated that using > the addresses from U-Boot's default environment (at least with a ToT > U-Boot that I just built) does indeed solve it. > > I'd like to re-iterate that the test bed should be using the values > from U-Boot's environment rather than making up its own. That way: > > * The value the test bed uses for the kernel load address likely > overlaps where the kernel decompressor writes to for even slightly > large kernels. This means the decompressor must move itself before > decompressing. IIUC, there's zero guarantee that moving the > decompressor won't overwrite the DTB, since IIUC the decompressor uses > zero knowledge of the DTB location. In other words, if the compressed > kernel is loaded somewhere that's likely to require it to move itself, > there's a real risk of the exact same problem cropping up again in the > future if the kernel happens to overwrite the DTB during relocation. > > * The values are part of every Tegra U-Boot port (and hopefully for > other SoCs too given any distro using boot.scr with > config_distro_bootcmd.h will expect the variables to exist), so for > future (Tegra) chips you won't have to adjust the test bed if RAM > layout changes. > > * Those values get testing, so we'll find out if the ever don't work. > We get more test coverage. Sounds reasonable, I'll try to get to this at some point soon. BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the value you define for kernel_addr_r. That would reinforce to folks who aren't using the U-boot scripts that they should use that address for loading their kernel. - Paul - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <551C2F7A.7040107-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot 2015-04-01 17:48 ` Paul Walmsley @ 2015-04-01 18:55 ` Stephen Warren -1 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-04-01 18:55 UTC (permalink / raw) To: Paul Walmsley Cc: Paul Walmsley, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, linux-tegra-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel (Dropping people likely not interested in Tegra U-Boot from explicit Cc) On 04/01/2015 11:48 AM, Paul Walmsley wrote: > On 04/01/2015 11:14 AM, Stephen Warren wrote: >> On 03/26/2015 12:57 PM, Stephen Warren wrote: >>> On 03/26/2015 12:35 PM, Paul Walmsley wrote: >>>> On Wed, 25 Mar 2015, Stephen Warren wrote: >>>> >>>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote: >>>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>>>> multi_v7_defconfig boot. >> ... >>>>>>> Can you try to shift your kernel load address around a bit? From >>>>>>> experience with the boards from kernelci.org we find that as the >>>>>>> multi >>>>>>> v7 kernel size increases they can clobber memory when they get >>>>>>> decompressed. >>>>>> >>>>>> Thanks, that was it: >>>>>> >>>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>>> >> ... >>>>> Interesting. Do the values in U-Boot's default environment work >>>>> correctly >>>> >>>> No idea, I haven't tried. (The load addresses I used are observable in >>>> the boot logs above.) >>> >>> Sure. I was hoping you'd try it out since you already had the setup to >>> repro the issue. >>> >>> It'd be good if your test-bed used the built-in U-Boot variables too, so >>> we're testing them. >> >> I've reproduced the original problem, and then validated that using >> the addresses from U-Boot's default environment (at least with a ToT >> U-Boot that I just built) does indeed solve it. >> >> I'd like to re-iterate that the test bed should be using the values >> from U-Boot's environment rather than making up its own. That way: >> >> * The value the test bed uses for the kernel load address likely >> overlaps where the kernel decompressor writes to for even slightly >> large kernels. This means the decompressor must move itself before >> decompressing. IIUC, there's zero guarantee that moving the >> decompressor won't overwrite the DTB, since IIUC the decompressor uses >> zero knowledge of the DTB location. In other words, if the compressed >> kernel is loaded somewhere that's likely to require it to move itself, >> there's a real risk of the exact same problem cropping up again in the >> future if the kernel happens to overwrite the DTB during relocation. >> >> * The values are part of every Tegra U-Boot port (and hopefully for >> other SoCs too given any distro using boot.scr with >> config_distro_bootcmd.h will expect the variables to exist), so for >> future (Tegra) chips you won't have to adjust the test bed if RAM >> layout changes. >> >> * Those values get testing, so we'll find out if the ever don't work. >> We get more test coverage. > > Sounds reasonable, I'll try to get to this at some point soon. > > BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the > value you define for kernel_addr_r. That would reinforce to folks who > aren't using the U-boot scripts that they should use that address for > loading their kernel. Hmm. Our values for CONFIG_LOADADDR and CONFIG_SYS_LOADADDR in U-Boot seem to be a mess. Essentially they are used for the same semantic purpose, it's just that different U-Boot features use one or the other. I propose we make them the same value. There are certainly many other boards that do (and many that don't, strangely). I'm not sure that pointing those at the same location as kernel_addr_r is best. I'd expect modern scripts to explicitly use one of the type-specific (kernel, DT, script, initrd, ...) variables and never rely on simple $loadaddr. How about we point these variables somewhere that doesn't overlap with any of the memory regions "reserved"/intended for a specific purpose? In other words, I'd suggest 0x90200000 as the value for Tegra30+; that's consistent with the default values of $scriptaddr and $pxefile_addr_r, i.e. 1MB beyond the latter, and well out of the way from anything else. Does all that sound reasonable? If so, I'll send a patch for U-Boot. ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-04-01 18:55 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-04-01 18:55 UTC (permalink / raw) To: linux-arm-kernel (Dropping people likely not interested in Tegra U-Boot from explicit Cc) On 04/01/2015 11:48 AM, Paul Walmsley wrote: > On 04/01/2015 11:14 AM, Stephen Warren wrote: >> On 03/26/2015 12:57 PM, Stephen Warren wrote: >>> On 03/26/2015 12:35 PM, Paul Walmsley wrote: >>>> On Wed, 25 Mar 2015, Stephen Warren wrote: >>>> >>>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>>>> multi_v7_defconfig boot. >> ... >>>>>>> Can you try to shift your kernel load address around a bit? From >>>>>>> experience with the boards from kernelci.org we find that as the >>>>>>> multi >>>>>>> v7 kernel size increases they can clobber memory when they get >>>>>>> decompressed. >>>>>> >>>>>> Thanks, that was it: >>>>>> >>>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>>> >> ... >>>>> Interesting. Do the values in U-Boot's default environment work >>>>> correctly >>>> >>>> No idea, I haven't tried. (The load addresses I used are observable in >>>> the boot logs above.) >>> >>> Sure. I was hoping you'd try it out since you already had the setup to >>> repro the issue. >>> >>> It'd be good if your test-bed used the built-in U-Boot variables too, so >>> we're testing them. >> >> I've reproduced the original problem, and then validated that using >> the addresses from U-Boot's default environment (at least with a ToT >> U-Boot that I just built) does indeed solve it. >> >> I'd like to re-iterate that the test bed should be using the values >> from U-Boot's environment rather than making up its own. That way: >> >> * The value the test bed uses for the kernel load address likely >> overlaps where the kernel decompressor writes to for even slightly >> large kernels. This means the decompressor must move itself before >> decompressing. IIUC, there's zero guarantee that moving the >> decompressor won't overwrite the DTB, since IIUC the decompressor uses >> zero knowledge of the DTB location. In other words, if the compressed >> kernel is loaded somewhere that's likely to require it to move itself, >> there's a real risk of the exact same problem cropping up again in the >> future if the kernel happens to overwrite the DTB during relocation. >> >> * The values are part of every Tegra U-Boot port (and hopefully for >> other SoCs too given any distro using boot.scr with >> config_distro_bootcmd.h will expect the variables to exist), so for >> future (Tegra) chips you won't have to adjust the test bed if RAM >> layout changes. >> >> * Those values get testing, so we'll find out if the ever don't work. >> We get more test coverage. > > Sounds reasonable, I'll try to get to this at some point soon. > > BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the > value you define for kernel_addr_r. That would reinforce to folks who > aren't using the U-boot scripts that they should use that address for > loading their kernel. Hmm. Our values for CONFIG_LOADADDR and CONFIG_SYS_LOADADDR in U-Boot seem to be a mess. Essentially they are used for the same semantic purpose, it's just that different U-Boot features use one or the other. I propose we make them the same value. There are certainly many other boards that do (and many that don't, strangely). I'm not sure that pointing those at the same location as kernel_addr_r is best. I'd expect modern scripts to explicitly use one of the type-specific (kernel, DT, script, initrd, ...) variables and never rely on simple $loadaddr. How about we point these variables somewhere that doesn't overlap with any of the memory regions "reserved"/intended for a specific purpose? In other words, I'd suggest 0x90200000 as the value for Tegra30+; that's consistent with the default values of $scriptaddr and $pxefile_addr_r, i.e. 1MB beyond the latter, and well out of the way from anything else. Does all that sound reasonable? If so, I'll send a patch for U-Boot. ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <551C3F25.40105-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot 2015-04-01 18:55 ` Stephen Warren @ 2015-04-01 19:17 ` Paul Walmsley -1 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-04-01 19:17 UTC (permalink / raw) To: Stephen Warren Cc: Paul Walmsley, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, linux-tegra-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel On 04/01/2015 12:55 PM, Stephen Warren wrote: > (Dropping people likely not interested in Tegra U-Boot from explicit Cc) > > On 04/01/2015 11:48 AM, Paul Walmsley wrote: >> On 04/01/2015 11:14 AM, Stephen Warren wrote: >>> On 03/26/2015 12:57 PM, Stephen Warren wrote: >>>> On 03/26/2015 12:35 PM, Paul Walmsley wrote: >>>>> On Wed, 25 Mar 2015, Stephen Warren wrote: >>>>> >>>>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>>>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote: >>>>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>>>>> multi_v7_defconfig boot. >>> ... >>>>>>>> Can you try to shift your kernel load address around a bit? From >>>>>>>> experience with the boards from kernelci.org we find that as the >>>>>>>> multi >>>>>>>> v7 kernel size increases they can clobber memory when they get >>>>>>>> decompressed. >>>>>>> >>>>>>> Thanks, that was it: >>>>>>> >>>>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>>>> >>>>>>> >>> ... >>>>>> Interesting. Do the values in U-Boot's default environment work >>>>>> correctly >>>>> >>>>> No idea, I haven't tried. (The load addresses I used are >>>>> observable in >>>>> the boot logs above.) >>>> >>>> Sure. I was hoping you'd try it out since you already had the setup to >>>> repro the issue. >>>> >>>> It'd be good if your test-bed used the built-in U-Boot variables >>>> too, so >>>> we're testing them. >>> >>> I've reproduced the original problem, and then validated that using >>> the addresses from U-Boot's default environment (at least with a ToT >>> U-Boot that I just built) does indeed solve it. >>> >>> I'd like to re-iterate that the test bed should be using the values >>> from U-Boot's environment rather than making up its own. That way: >>> >>> * The value the test bed uses for the kernel load address likely >>> overlaps where the kernel decompressor writes to for even slightly >>> large kernels. This means the decompressor must move itself before >>> decompressing. IIUC, there's zero guarantee that moving the >>> decompressor won't overwrite the DTB, since IIUC the decompressor uses >>> zero knowledge of the DTB location. In other words, if the compressed >>> kernel is loaded somewhere that's likely to require it to move itself, >>> there's a real risk of the exact same problem cropping up again in the >>> future if the kernel happens to overwrite the DTB during relocation. >>> >>> * The values are part of every Tegra U-Boot port (and hopefully for >>> other SoCs too given any distro using boot.scr with >>> config_distro_bootcmd.h will expect the variables to exist), so for >>> future (Tegra) chips you won't have to adjust the test bed if RAM >>> layout changes. >>> >>> * Those values get testing, so we'll find out if the ever don't work. >>> We get more test coverage. >> >> Sounds reasonable, I'll try to get to this at some point soon. >> >> BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the >> value you define for kernel_addr_r. That would reinforce to folks who >> aren't using the U-boot scripts that they should use that address for >> loading their kernel. > > Hmm. Our values for CONFIG_LOADADDR and CONFIG_SYS_LOADADDR in U-Boot > seem to be a mess. > > Essentially they are used for the same semantic purpose, it's just > that different U-Boot features use one or the other. I propose we make > them the same value. There are certainly many other boards that do > (and many that don't, strangely). That sounds fine to me. I got totally confused trying to figure out the difference between CONFIG_LOADADDR and CONFIG_SYS_LOAD_ADDR. > > I'm not sure that pointing those at the same location as kernel_addr_r > is best. I'd expect modern scripts to explicitly use one of the > type-specific (kernel, DT, script, initrd, ...) variables and never > rely on simple $loadaddr. How about we point these variables somewhere > that doesn't overlap with any of the memory regions > "reserved"/intended for a specific purpose? > > In other words, I'd suggest 0x90200000 as the value for Tegra30+; > that's consistent with the default values of $scriptaddr and > $pxefile_addr_r, i.e. 1MB beyond the latter, and well out of the way > from anything else. > > Does all that sound reasonable? If so, I'll send a patch for U-Boot. I always used to treat CONFIG_LOADADDR as the "recommended" load address for the kernel, as did my colleagues. But that was years ago in the days of uImages and things have changed a lot since then. So to be perfectly honest, I don't know what the right path forward is. I'd hate to add more work to your plate, but maybe we should ask on the U-boot mailing lists to see what folks there would recommend? If you're busy I'd be happy to send the initial query, just let me know. Otherwise, I think you probably know U-boot better than I, so ultimately I'm fine with your discretion. - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-04-01 19:17 ` Paul Walmsley 0 siblings, 0 replies; 33+ messages in thread From: Paul Walmsley @ 2015-04-01 19:17 UTC (permalink / raw) To: linux-arm-kernel On 04/01/2015 12:55 PM, Stephen Warren wrote: > (Dropping people likely not interested in Tegra U-Boot from explicit Cc) > > On 04/01/2015 11:48 AM, Paul Walmsley wrote: >> On 04/01/2015 11:14 AM, Stephen Warren wrote: >>> On 03/26/2015 12:57 PM, Stephen Warren wrote: >>>> On 03/26/2015 12:35 PM, Paul Walmsley wrote: >>>>> On Wed, 25 Mar 2015, Stephen Warren wrote: >>>>> >>>>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>>>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>>>>> multi_v7_defconfig boot. >>> ... >>>>>>>> Can you try to shift your kernel load address around a bit? From >>>>>>>> experience with the boards from kernelci.org we find that as the >>>>>>>> multi >>>>>>>> v7 kernel size increases they can clobber memory when they get >>>>>>>> decompressed. >>>>>>> >>>>>>> Thanks, that was it: >>>>>>> >>>>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>>>> >>>>>>> >>> ... >>>>>> Interesting. Do the values in U-Boot's default environment work >>>>>> correctly >>>>> >>>>> No idea, I haven't tried. (The load addresses I used are >>>>> observable in >>>>> the boot logs above.) >>>> >>>> Sure. I was hoping you'd try it out since you already had the setup to >>>> repro the issue. >>>> >>>> It'd be good if your test-bed used the built-in U-Boot variables >>>> too, so >>>> we're testing them. >>> >>> I've reproduced the original problem, and then validated that using >>> the addresses from U-Boot's default environment (at least with a ToT >>> U-Boot that I just built) does indeed solve it. >>> >>> I'd like to re-iterate that the test bed should be using the values >>> from U-Boot's environment rather than making up its own. That way: >>> >>> * The value the test bed uses for the kernel load address likely >>> overlaps where the kernel decompressor writes to for even slightly >>> large kernels. This means the decompressor must move itself before >>> decompressing. IIUC, there's zero guarantee that moving the >>> decompressor won't overwrite the DTB, since IIUC the decompressor uses >>> zero knowledge of the DTB location. In other words, if the compressed >>> kernel is loaded somewhere that's likely to require it to move itself, >>> there's a real risk of the exact same problem cropping up again in the >>> future if the kernel happens to overwrite the DTB during relocation. >>> >>> * The values are part of every Tegra U-Boot port (and hopefully for >>> other SoCs too given any distro using boot.scr with >>> config_distro_bootcmd.h will expect the variables to exist), so for >>> future (Tegra) chips you won't have to adjust the test bed if RAM >>> layout changes. >>> >>> * Those values get testing, so we'll find out if the ever don't work. >>> We get more test coverage. >> >> Sounds reasonable, I'll try to get to this at some point soon. >> >> BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the >> value you define for kernel_addr_r. That would reinforce to folks who >> aren't using the U-boot scripts that they should use that address for >> loading their kernel. > > Hmm. Our values for CONFIG_LOADADDR and CONFIG_SYS_LOADADDR in U-Boot > seem to be a mess. > > Essentially they are used for the same semantic purpose, it's just > that different U-Boot features use one or the other. I propose we make > them the same value. There are certainly many other boards that do > (and many that don't, strangely). That sounds fine to me. I got totally confused trying to figure out the difference between CONFIG_LOADADDR and CONFIG_SYS_LOAD_ADDR. > > I'm not sure that pointing those at the same location as kernel_addr_r > is best. I'd expect modern scripts to explicitly use one of the > type-specific (kernel, DT, script, initrd, ...) variables and never > rely on simple $loadaddr. How about we point these variables somewhere > that doesn't overlap with any of the memory regions > "reserved"/intended for a specific purpose? > > In other words, I'd suggest 0x90200000 as the value for Tegra30+; > that's consistent with the default values of $scriptaddr and > $pxefile_addr_r, i.e. 1MB beyond the latter, and well out of the way > from anything else. > > Does all that sound reasonable? If so, I'll send a patch for U-Boot. I always used to treat CONFIG_LOADADDR as the "recommended" load address for the kernel, as did my colleagues. But that was years ago in the days of uImages and things have changed a lot since then. So to be perfectly honest, I don't know what the right path forward is. I'd hate to add more work to your plate, but maybe we should ask on the U-boot mailing lists to see what folks there would recommend? If you're busy I'd be happy to send the initial query, just let me know. Otherwise, I think you probably know U-boot better than I, so ultimately I'm fine with your discretion. - Paul ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <551C445C.7040107-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot 2015-04-01 19:17 ` Paul Walmsley @ 2015-04-01 21:21 ` Stephen Warren -1 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-04-01 21:21 UTC (permalink / raw) To: Paul Walmsley Cc: Paul Walmsley, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, linux-tegra-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel On 04/01/2015 01:17 PM, Paul Walmsley wrote: > On 04/01/2015 12:55 PM, Stephen Warren wrote: >> (Dropping people likely not interested in Tegra U-Boot from explicit Cc) >> >> On 04/01/2015 11:48 AM, Paul Walmsley wrote: >>> On 04/01/2015 11:14 AM, Stephen Warren wrote: >>>> On 03/26/2015 12:57 PM, Stephen Warren wrote: >>>>> On 03/26/2015 12:35 PM, Paul Walmsley wrote: >>>>>> On Wed, 25 Mar 2015, Stephen Warren wrote: >>>>>> >>>>>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>>>>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org> wrote: >>>>>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>>>>>> multi_v7_defconfig boot. >>>> ... >>>>>>>>> Can you try to shift your kernel load address around a bit? From >>>>>>>>> experience with the boards from kernelci.org we find that as the >>>>>>>>> multi >>>>>>>>> v7 kernel size increases they can clobber memory when they get >>>>>>>>> decompressed. >>>>>>>> >>>>>>>> Thanks, that was it: >>>>>>>> >>>>>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>>>>> >>>>>>>> >>>> ... >>>>>>> Interesting. Do the values in U-Boot's default environment work >>>>>>> correctly >>>>>> >>>>>> No idea, I haven't tried. (The load addresses I used are >>>>>> observable in >>>>>> the boot logs above.) >>>>> >>>>> Sure. I was hoping you'd try it out since you already had the setup to >>>>> repro the issue. >>>>> >>>>> It'd be good if your test-bed used the built-in U-Boot variables >>>>> too, so >>>>> we're testing them. >>>> >>>> I've reproduced the original problem, and then validated that using >>>> the addresses from U-Boot's default environment (at least with a ToT >>>> U-Boot that I just built) does indeed solve it. >>>> >>>> I'd like to re-iterate that the test bed should be using the values >>>> from U-Boot's environment rather than making up its own. That way: >>>> >>>> * The value the test bed uses for the kernel load address likely >>>> overlaps where the kernel decompressor writes to for even slightly >>>> large kernels. This means the decompressor must move itself before >>>> decompressing. IIUC, there's zero guarantee that moving the >>>> decompressor won't overwrite the DTB, since IIUC the decompressor uses >>>> zero knowledge of the DTB location. In other words, if the compressed >>>> kernel is loaded somewhere that's likely to require it to move itself, >>>> there's a real risk of the exact same problem cropping up again in the >>>> future if the kernel happens to overwrite the DTB during relocation. >>>> >>>> * The values are part of every Tegra U-Boot port (and hopefully for >>>> other SoCs too given any distro using boot.scr with >>>> config_distro_bootcmd.h will expect the variables to exist), so for >>>> future (Tegra) chips you won't have to adjust the test bed if RAM >>>> layout changes. >>>> >>>> * Those values get testing, so we'll find out if the ever don't work. >>>> We get more test coverage. >>> >>> Sounds reasonable, I'll try to get to this at some point soon. >>> >>> BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the >>> value you define for kernel_addr_r. That would reinforce to folks who >>> aren't using the U-boot scripts that they should use that address for >>> loading their kernel. >> >> Hmm. Our values for CONFIG_LOADADDR and CONFIG_SYS_LOADADDR in U-Boot >> seem to be a mess. >> >> Essentially they are used for the same semantic purpose, it's just >> that different U-Boot features use one or the other. I propose we make >> them the same value. There are certainly many other boards that do >> (and many that don't, strangely). > > That sounds fine to me. I got totally confused trying to figure out the > difference between CONFIG_LOADADDR and CONFIG_SYS_LOAD_ADDR. > >> >> I'm not sure that pointing those at the same location as kernel_addr_r >> is best. I'd expect modern scripts to explicitly use one of the >> type-specific (kernel, DT, script, initrd, ...) variables and never >> rely on simple $loadaddr. How about we point these variables somewhere >> that doesn't overlap with any of the memory regions >> "reserved"/intended for a specific purpose? >> >> In other words, I'd suggest 0x90200000 as the value for Tegra30+; >> that's consistent with the default values of $scriptaddr and >> $pxefile_addr_r, i.e. 1MB beyond the latter, and well out of the way >> from anything else. >> >> Does all that sound reasonable? If so, I'll send a patch for U-Boot. > > I always used to treat CONFIG_LOADADDR as the "recommended" load address > for the kernel, as did my colleagues. But that was years ago in the > days of uImages and things have changed a lot since then. So to be > perfectly honest, I don't know what the right path forward is. I'd hate > to add more work to your plate, but maybe we should ask on the U-boot > mailing lists to see what folks there would recommend? If you're busy > I'd be happy to send the initial query, just let me know. > > Otherwise, I think you probably know U-boot better than I, so ultimately > I'm fine with your discretion. Thinking about this more, there's a case where setting CONFIG_LOADADDR to 0x90200000 won't work (raw zImage loaded at that address, with AUTO_ZRELADDR in use, booted using U-Boot's bootz command which IIRC never relocates the zImage). I would not expect scripts to mix "old" variables such as $loadaddr with "new" variables such as $kernel_addr_r, so sharing the same location for them should work out fine. I'll just do that. ^ permalink raw reply [flat|nested] 33+ messages in thread
* "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot @ 2015-04-01 21:21 ` Stephen Warren 0 siblings, 0 replies; 33+ messages in thread From: Stephen Warren @ 2015-04-01 21:21 UTC (permalink / raw) To: linux-arm-kernel On 04/01/2015 01:17 PM, Paul Walmsley wrote: > On 04/01/2015 12:55 PM, Stephen Warren wrote: >> (Dropping people likely not interested in Tegra U-Boot from explicit Cc) >> >> On 04/01/2015 11:48 AM, Paul Walmsley wrote: >>> On 04/01/2015 11:14 AM, Stephen Warren wrote: >>>> On 03/26/2015 12:57 PM, Stephen Warren wrote: >>>>> On 03/26/2015 12:35 PM, Paul Walmsley wrote: >>>>>> On Wed, 25 Mar 2015, Stephen Warren wrote: >>>>>> >>>>>>> On 03/25/2015 04:00 PM, Paul Walmsley wrote: >>>>>>>> On Wed, 25 Mar 2015, Tyler Baker wrote: >>>>>>>>> On 25 March 2015 at 11:03, Paul Walmsley <paul@pwsan.com> wrote: >>>>>>>>>> Looks like commit 4a3a6f86693922b29cf829c63f652b057f14619e ("ARM: >>>>>>>>>> multi_v7_defconfig: Enable shmobile platforms") breaks Tegra20 >>>>>>>>>> multi_v7_defconfig boot. >>>> ... >>>>>>>>> Can you try to shift your kernel load address around a bit? From >>>>>>>>> experience with the boards from kernelci.org we find that as the >>>>>>>>> multi >>>>>>>>> v7 kernel size increases they can clobber memory when they get >>>>>>>>> decompressed. >>>>>>>> >>>>>>>> Thanks, that was it: >>>>>>>> >>>>>>>> http://nvt.pwsan.com/pub/pwalmsley-tester/testlogs/test_20150325144058_6af714b069dc278d5d8e1b7afc13568f71d9aba8/20150325144058/boot/tegra20-trimslice/tegra20-trimslice/multi_v7_defconfig_log.txt >>>>>>>> >>>>>>>> >>>> ... >>>>>>> Interesting. Do the values in U-Boot's default environment work >>>>>>> correctly >>>>>> >>>>>> No idea, I haven't tried. (The load addresses I used are >>>>>> observable in >>>>>> the boot logs above.) >>>>> >>>>> Sure. I was hoping you'd try it out since you already had the setup to >>>>> repro the issue. >>>>> >>>>> It'd be good if your test-bed used the built-in U-Boot variables >>>>> too, so >>>>> we're testing them. >>>> >>>> I've reproduced the original problem, and then validated that using >>>> the addresses from U-Boot's default environment (at least with a ToT >>>> U-Boot that I just built) does indeed solve it. >>>> >>>> I'd like to re-iterate that the test bed should be using the values >>>> from U-Boot's environment rather than making up its own. That way: >>>> >>>> * The value the test bed uses for the kernel load address likely >>>> overlaps where the kernel decompressor writes to for even slightly >>>> large kernels. This means the decompressor must move itself before >>>> decompressing. IIUC, there's zero guarantee that moving the >>>> decompressor won't overwrite the DTB, since IIUC the decompressor uses >>>> zero knowledge of the DTB location. In other words, if the compressed >>>> kernel is loaded somewhere that's likely to require it to move itself, >>>> there's a real risk of the exact same problem cropping up again in the >>>> future if the kernel happens to overwrite the DTB during relocation. >>>> >>>> * The values are part of every Tegra U-Boot port (and hopefully for >>>> other SoCs too given any distro using boot.scr with >>>> config_distro_bootcmd.h will expect the variables to exist), so for >>>> future (Tegra) chips you won't have to adjust the test bed if RAM >>>> layout changes. >>>> >>>> * Those values get testing, so we'll find out if the ever don't work. >>>> We get more test coverage. >>> >>> Sounds reasonable, I'll try to get to this at some point soon. >>> >>> BTW, it might be worth changing U-boot CONFIG_LOADADDR to point to the >>> value you define for kernel_addr_r. That would reinforce to folks who >>> aren't using the U-boot scripts that they should use that address for >>> loading their kernel. >> >> Hmm. Our values for CONFIG_LOADADDR and CONFIG_SYS_LOADADDR in U-Boot >> seem to be a mess. >> >> Essentially they are used for the same semantic purpose, it's just >> that different U-Boot features use one or the other. I propose we make >> them the same value. There are certainly many other boards that do >> (and many that don't, strangely). > > That sounds fine to me. I got totally confused trying to figure out the > difference between CONFIG_LOADADDR and CONFIG_SYS_LOAD_ADDR. > >> >> I'm not sure that pointing those at the same location as kernel_addr_r >> is best. I'd expect modern scripts to explicitly use one of the >> type-specific (kernel, DT, script, initrd, ...) variables and never >> rely on simple $loadaddr. How about we point these variables somewhere >> that doesn't overlap with any of the memory regions >> "reserved"/intended for a specific purpose? >> >> In other words, I'd suggest 0x90200000 as the value for Tegra30+; >> that's consistent with the default values of $scriptaddr and >> $pxefile_addr_r, i.e. 1MB beyond the latter, and well out of the way >> from anything else. >> >> Does all that sound reasonable? If so, I'll send a patch for U-Boot. > > I always used to treat CONFIG_LOADADDR as the "recommended" load address > for the kernel, as did my colleagues. But that was years ago in the > days of uImages and things have changed a lot since then. So to be > perfectly honest, I don't know what the right path forward is. I'd hate > to add more work to your plate, but maybe we should ask on the U-boot > mailing lists to see what folks there would recommend? If you're busy > I'd be happy to send the initial query, just let me know. > > Otherwise, I think you probably know U-boot better than I, so ultimately > I'm fine with your discretion. Thinking about this more, there's a case where setting CONFIG_LOADADDR to 0x90200000 won't work (raw zImage loaded at that address, with AUTO_ZRELADDR in use, booted using U-Boot's bootz command which IIRC never relocates the zImage). I would not expect scripts to mix "old" variables such as $loadaddr with "new" variables such as $kernel_addr_r, so sharing the same location for them should work out fine. I'll just do that. ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2015-04-01 21:21 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-25 18:03 "ARM: multi_v7_defconfig: Enable shmobile platforms" breaks Tegra20 multi_v7_defconfig boot Paul Walmsley
2015-03-25 18:03 ` Paul Walmsley
2015-03-25 18:03 ` Paul Walmsley
2015-03-25 18:28 ` Tyler Baker
2015-03-25 18:28 ` Tyler Baker
2015-03-25 18:28 ` Tyler Baker
2015-03-25 18:46 ` Geert Uytterhoeven
2015-03-25 18:46 ` Geert Uytterhoeven
2015-03-25 18:46 ` Geert Uytterhoeven
2015-03-25 22:00 ` Paul Walmsley
2015-03-25 22:00 ` Paul Walmsley
2015-03-25 22:00 ` Paul Walmsley
2015-03-26 2:36 ` Stephen Warren
2015-03-26 2:36 ` Stephen Warren
2015-03-26 2:36 ` Stephen Warren
2015-03-26 18:35 ` Paul Walmsley
2015-03-26 18:35 ` Paul Walmsley
2015-03-26 18:35 ` Paul Walmsley
2015-03-26 18:57 ` Stephen Warren
2015-03-26 18:57 ` Stephen Warren
2015-03-26 18:57 ` Stephen Warren
2015-04-01 17:14 ` Stephen Warren
2015-04-01 17:14 ` Stephen Warren
2015-04-01 17:14 ` Stephen Warren
2015-04-01 17:48 ` Paul Walmsley
2015-04-01 17:48 ` Paul Walmsley
2015-04-01 17:48 ` Paul Walmsley
[not found] ` <551C2F7A.7040107-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-01 18:55 ` Stephen Warren
2015-04-01 18:55 ` Stephen Warren
[not found] ` <551C3F25.40105-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2015-04-01 19:17 ` Paul Walmsley
2015-04-01 19:17 ` Paul Walmsley
[not found] ` <551C445C.7040107-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-04-01 21:21 ` Stephen Warren
2015-04-01 21:21 ` Stephen Warren
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.