Re: Early kernel hang with big DTB appended
On Tue, 15 Jan 2013, Tomasz Figa wrote: > Hi Nicolas, > > On Monday 14 of January 2013 17:13:09 Nicolas Pitre wrote: > > On Fri, 11 Jan 2013, Sascha Hauer wrote: > > > On Thu, Jan 03, 2013 at 04:55:00PM +0100, Tomasz Figa wrote: > > > > Hi, > > > > > > > > I'm observing strange behavior when booting 3.8-rc1 and -rc2 with > > > > appended DTB. The kernel hangs very early when the DTB is bigger > > > > than some threshold somewhere around 24 KiB. With fullest possible > > > > low level UART debugging (and printk patched to use printascii) I'm > > > > receiving following output: > > > > > > > > Uncompressing Linux... done, booting the kernel. > > > > Booting Linux on physical CPU 0xa00 > > > > Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc > > > > version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu > > > > Jan 3 > > > > 15:37:35 CET 2013 > > > > CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d > > > > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction > > > > cache > > > > > > > > I tested on two Exynos-based boards (exynos4210-trats and one > > > > internal > > > > exynos4412-based board) and same happens on both. > > > > > > > > Do you have any ideas? > > > > > > Another thing besides the things already mentioned is that the dtb may > > > not cross a 1MiB boundary. The Kernel uses a single 1Mib section > > > (aligned to 1Mib) to initially map the dtb. Once you cross that > > > boundary parts of the dtb won't be accessible for the Kernel anymore. > > > > Crap. You're right. This patch should fix this issue. > > > > @Tomasz: please could you confirm this fixes your initial problem? > > I just tested the patch and it fixes the problem indeed. The kernel > now boots successfully after applying the patch, while undoing it > makes the kernel fail to boot again. Thanks. > > Tested-by: Tomasz Figa Thanks. The patch is queued as 7628/1 in RMK's patch system. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Early kernel hang with big DTB appended
Hi Nicolas, On Monday 14 of January 2013 17:13:09 Nicolas Pitre wrote: > On Fri, 11 Jan 2013, Sascha Hauer wrote: > > On Thu, Jan 03, 2013 at 04:55:00PM +0100, Tomasz Figa wrote: > > > Hi, > > > > > > I'm observing strange behavior when booting 3.8-rc1 and -rc2 with > > > appended DTB. The kernel hangs very early when the DTB is bigger > > > than some threshold somewhere around 24 KiB. With fullest possible > > > low level UART debugging (and printk patched to use printascii) I'm > > > receiving following output: > > > > > > Uncompressing Linux... done, booting the kernel. > > > Booting Linux on physical CPU 0xa00 > > > Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc > > > version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu > > > Jan 3 > > > 15:37:35 CET 2013 > > > CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d > > > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction > > > cache > > > > > > I tested on two Exynos-based boards (exynos4210-trats and one > > > internal > > > exynos4412-based board) and same happens on both. > > > > > > Do you have any ideas? > > > > Another thing besides the things already mentioned is that the dtb may > > not cross a 1MiB boundary. The Kernel uses a single 1Mib section > > (aligned to 1Mib) to initially map the dtb. Once you cross that > > boundary parts of the dtb won't be accessible for the Kernel anymore. > > Crap. You're right. This patch should fix this issue. > > @Tomasz: please could you confirm this fixes your initial problem? I just tested the patch and it fixes the problem indeed. The kernel now boots successfully after applying the patch, while undoing it makes the kernel fail to boot again. Thanks. Tested-by: Tomasz Figa Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Early kernel hang with big DTB appended
On Mon, Jan 14, 2013 at 05:13:09PM -0500, Nicolas Pitre wrote: > On Fri, 11 Jan 2013, Sascha Hauer wrote: > > > On Thu, Jan 03, 2013 at 04:55:00PM +0100, Tomasz Figa wrote: > > > Hi, > > > > > > I'm observing strange behavior when booting 3.8-rc1 and -rc2 with > > > appended > > > DTB. The kernel hangs very early when the DTB is bigger than some > > > threshold somewhere around 24 KiB. With fullest possible low level UART > > > debugging (and printk patched to use printascii) I'm receiving following > > > output: > > > > > > Uncompressing Linux... done, booting the kernel. > > > Booting Linux on physical CPU 0xa00 > > > Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc > > > version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu Jan 3 > > > 15:37:35 CET 2013 > > > CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d > > > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > > > > > > I tested on two Exynos-based boards (exynos4210-trats and one internal > > > exynos4412-based board) and same happens on both. > > > > > > Do you have any ideas? > > > > Another thing besides the things already mentioned is that the dtb may > > not cross a 1MiB boundary. The Kernel uses a single 1Mib section > > (aligned to 1Mib) to initially map the dtb. Once you cross that boundary > > parts of the dtb won't be accessible for the Kernel anymore. > > Crap. You're right. This patch should fix this issue. Just successfully tested with a devicetree explicitly located just before a 1MiB boundary, so: Tested-by: Sascha Hauer Sascha > > @Tomasz: please could you confirm this fixes your initial problem? > > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S > index 4eee351f46..61fcb18c7e 100644 > --- a/arch/arm/kernel/head.S > +++ b/arch/arm/kernel/head.S > @@ -246,6 +246,7 @@ __create_page_tables: > > /* >* Then map boot params address in r2 if specified. > + * We map 2 sections in case the ATAGs/DTB crosses a section boundary. >*/ > mov r0, r2, lsr #SECTION_SHIFT > movsr0, r0, lsl #SECTION_SHIFT > @@ -253,6 +254,8 @@ __create_page_tables: > addne r3, r3, #PAGE_OFFSET > addne r3, r4, r3, lsr #(SECTION_SHIFT - PMD_ORDER) > orrne r6, r7, r0 > + strne r6, [r3], #1 << PMD_ORDER > + addne r6, r6, #1 << SECTION_SHIFT > strne r6, [r3] > > #ifdef CONFIG_DEBUG_LL > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Early kernel hang with big DTB appended
On Fri, 11 Jan 2013, Sascha Hauer wrote: > On Thu, Jan 03, 2013 at 04:55:00PM +0100, Tomasz Figa wrote: > > Hi, > > > > I'm observing strange behavior when booting 3.8-rc1 and -rc2 with appended > > DTB. The kernel hangs very early when the DTB is bigger than some > > threshold somewhere around 24 KiB. With fullest possible low level UART > > debugging (and printk patched to use printascii) I'm receiving following > > output: > > > > Uncompressing Linux... done, booting the kernel. > > Booting Linux on physical CPU 0xa00 > > Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc > > version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu Jan 3 > > 15:37:35 CET 2013 > > CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d > > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > > > > I tested on two Exynos-based boards (exynos4210-trats and one internal > > exynos4412-based board) and same happens on both. > > > > Do you have any ideas? > > Another thing besides the things already mentioned is that the dtb may > not cross a 1MiB boundary. The Kernel uses a single 1Mib section > (aligned to 1Mib) to initially map the dtb. Once you cross that boundary > parts of the dtb won't be accessible for the Kernel anymore. Crap. You're right. This patch should fix this issue. @Tomasz: please could you confirm this fixes your initial problem? diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 4eee351f46..61fcb18c7e 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -246,6 +246,7 @@ __create_page_tables: /* * Then map boot params address in r2 if specified. +* We map 2 sections in case the ATAGs/DTB crosses a section boundary. */ mov r0, r2, lsr #SECTION_SHIFT movsr0, r0, lsl #SECTION_SHIFT @@ -253,6 +254,8 @@ __create_page_tables: addne r3, r3, #PAGE_OFFSET addne r3, r4, r3, lsr #(SECTION_SHIFT - PMD_ORDER) orrne r6, r7, r0 + strne r6, [r3], #1 << PMD_ORDER + addne r6, r6, #1 << SECTION_SHIFT strne r6, [r3] #ifdef CONFIG_DEBUG_LL ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
$(make uImage) is stupid [Was: Re: Early kernel hang with big DTB appended]
Hello, unrelated to the original problem ... On Fri, Jan 04, 2013 at 11:18:56AM +0100, Tomasz Figa wrote: > We are using uImages built with same parameters as those used in simple > 'make uImage', just with a DTB appended to zImage before running mkimage > on it. note that the parameters used for $(make uImage) are not optimal, only safe. They use (letting the MMU aside) the link address of the final image as load address. That means as U-Boot probably didn't choose the right address when reading the image it has to move it to the link address and then jumps into it. Then the decompressor notices that the compressed image is located where the decompressed image should go to and so has to move the image again. So you could save quite some time during boot if you'd teach U-Boot that it can just use the image where it was loaded to. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Early kernel hang with big DTB appended
On Thu, Jan 03, 2013 at 04:55:00PM +0100, Tomasz Figa wrote: > Hi, > > I'm observing strange behavior when booting 3.8-rc1 and -rc2 with appended > DTB. The kernel hangs very early when the DTB is bigger than some > threshold somewhere around 24 KiB. With fullest possible low level UART > debugging (and printk patched to use printascii) I'm receiving following > output: > > Uncompressing Linux... done, booting the kernel. > Booting Linux on physical CPU 0xa00 > Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc > version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu Jan 3 > 15:37:35 CET 2013 > CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache > > I tested on two Exynos-based boards (exynos4210-trats and one internal > exynos4412-based board) and same happens on both. > > Do you have any ideas? Another thing besides the things already mentioned is that the dtb may not cross a 1MiB boundary. The Kernel uses a single 1Mib section (aligned to 1Mib) to initially map the dtb. Once you cross that boundary parts of the dtb won't be accessible for the Kernel anymore. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: Early kernel hang with big DTB appended
> -Original Message- > From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- > kernel-boun...@lists.infradead.org] On Behalf Of Tomasz Figa > Sent: Thursday, January 03, 2013 10:55 AM > To: devicetree-discuss@lists.ozlabs.org > Cc: linux-samsung-...@vger.kernel.org; li...@arm.linux.org.uk; > n...@linaro.org; kgene@samsung.com; thomas.abra...@linaro.org; > bo...@secretlab.ca; linux-arm-ker...@lists.infradead.org > Subject: Early kernel hang with big DTB appended > > Hi, > > I'm observing strange behavior when booting 3.8-rc1 and -rc2 with > appended DTB. The kernel hangs very early when the DTB is bigger than > some threshold somewhere around 24 KiB. With fullest possible low level > UART debugging (and printk patched to use printascii) I'm receiving > following > output: > > Uncompressing Linux... done, booting the kernel. > Booting Linux on physical CPU 0xa00 > Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc > version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu Jan 3 > 15:37:35 CET 2013 > CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction > cache > > I tested on two Exynos-based boards (exynos4210-trats and one internal > exynos4412-based board) and same happens on both. > > Do you have any ideas? Tomasz, Sounds to me like the DTB is not being fully written to memory or that it isn't being fully read from memory. I've had similar problems when I placed the DTB too close to the end of flash and not all of the DTB was written to flash. If you load a debug build of U-Boot, I believe there are a number of debug messages related to loading the device tree that U-Boot prints. Then you can at least verify that U-Boot is loading the entire device tree. Regards, Bryan > > Best regards, > -- > Tomasz Figa > Samsung Poland R&D Center > SW Solution Development, Linux Platform > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Early kernel hang with big DTB appended
Hi Bryan, Thanks for your reply. On Thursday 03 of January 2013 13:40:43 Bryan Evenson wrote: > > -Original Message- > > From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- > > kernel-boun...@lists.infradead.org] On Behalf Of Tomasz Figa > > Sent: Thursday, January 03, 2013 10:55 AM > > To: devicetree-discuss@lists.ozlabs.org > > Cc: linux-samsung-...@vger.kernel.org; li...@arm.linux.org.uk; > > n...@linaro.org; kgene@samsung.com; thomas.abra...@linaro.org; > > bo...@secretlab.ca; linux-arm-ker...@lists.infradead.org > > Subject: Early kernel hang with big DTB appended > > > > Hi, > > > > I'm observing strange behavior when booting 3.8-rc1 and -rc2 with > > appended DTB. The kernel hangs very early when the DTB is bigger than > > some threshold somewhere around 24 KiB. With fullest possible low > > level > > UART debugging (and printk patched to use printascii) I'm receiving > > following > > output: > > > > Uncompressing Linux... done, booting the kernel. > > Booting Linux on physical CPU 0xa00 > > Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc > > version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu Jan > > 3 > > 15:37:35 CET 2013 > > CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d > > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction > > cache > > > > I tested on two Exynos-based boards (exynos4210-trats and one internal > > exynos4412-based board) and same happens on both. > > > > Do you have any ideas? > > Tomasz, > > Sounds to me like the DTB is not being fully written to memory or that > it isn't being fully read from memory. I've had similar problems when > I placed the DTB too close to the end of flash and not all of the DTB > was written to flash. I'm using CONFIG_ARM_APPENDED_DTB, as it eases testing a bit, because DTB is built into the resulting uImage for u-boot (appended after zImage) and it does not require OF-aware versions of u-boot. Also the uImage is stored on an ext4 partition as a regular file, so I would exclude any storage issues. > > If you load a debug build of U-Boot, I believe there are a number of > debug messages related to loading the device tree that U-Boot prints. > Then you can at least verify that U-Boot is loading the entire device > tree. The u-boot I have is not OF-aware, so it just prints the standard messages about loading the uImage. P.S. With Nicolas' hint about image load address I managed to work around the issue and limit the scope of code where the bug might exist. Please see my reply to Nicolas' post. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Early kernel hang with big DTB appended
Hi Nicolas, Thanks for your reply. On Thursday 03 of January 2013 21:48:05 Nicolas Pitre wrote: > On Thu, 3 Jan 2013, Tomasz Figa wrote: > > Hi, > > > > I'm observing strange behavior when booting 3.8-rc1 and -rc2 with > > appended DTB. The kernel hangs very early when the DTB is bigger than > > some threshold somewhere around 24 KiB. > > What is the address where you load your zImage? We are using uImages built with same parameters as those used in simple 'make uImage', just with a DTB appended to zImage before running mkimage on it. By default the load address is set to 0x40008000, where 0x4000 is DRAM base. > What if you load it, say, at an offset of 16MB from the start of RAM? > Not that this is a fix, but at least that would help isolate the issue. Yes, it indeed helps. I tried with shifting the load address by 16 MiB to 0x41008000 (by adjusting mkimage parameters) and it now boots fine. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Early kernel hang with big DTB appended
On Thu, 3 Jan 2013, Tomasz Figa wrote: > Hi, > > I'm observing strange behavior when booting 3.8-rc1 and -rc2 with appended > DTB. The kernel hangs very early when the DTB is bigger than some > threshold somewhere around 24 KiB. What is the address where you load your zImage? What if you load it, say, at an offset of 16MB from the start of RAM? Not that this is a fix, but at least that would help isolate the issue. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
