* Early kernel hang with big DTB appended @ 2013-01-03 15:55 ` Tomasz Figa 0 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2013-01-03 15:55 UTC (permalink / raw) To: devicetree-discuss Cc: linux-samsung-soc, linux-arm-kernel, nico, bones, linux, thomas.abraham, kgene.kim 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? Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ^ permalink raw reply [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-03 15:55 ` Tomasz Figa 0 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2013-01-03 15:55 UTC (permalink / raw) To: linux-arm-kernel 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 at 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? Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Early kernel hang with big DTB appended 2013-01-03 15:55 ` Tomasz Figa @ 2013-01-03 18:40 ` Bryan Evenson -1 siblings, 0 replies; 22+ messages in thread From: Bryan Evenson @ 2013-01-03 18:40 UTC (permalink / raw) To: Tomasz Figa, devicetree-discuss@lists.ozlabs.org Cc: kgene.kim@samsung.com, linux@arm.linux.org.uk, nico@linaro.org, linux-samsung-soc@vger.kernel.org, thomas.abraham@linaro.org, bones@secretlab.ca, linux-arm-kernel@lists.infradead.org > -----Original Message----- > From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm- > kernel-bounces@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-soc@vger.kernel.org; linux@arm.linux.org.uk; > nico@linaro.org; kgene.kim@samsung.com; thomas.abraham@linaro.org; > bones@secretlab.ca; linux-arm-kernel@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-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-03 18:40 ` Bryan Evenson 0 siblings, 0 replies; 22+ messages in thread From: Bryan Evenson @ 2013-01-03 18:40 UTC (permalink / raw) To: linux-arm-kernel > -----Original Message----- > From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm- > kernel-bounces at lists.infradead.org] On Behalf Of Tomasz Figa > Sent: Thursday, January 03, 2013 10:55 AM > To: devicetree-discuss at lists.ozlabs.org > Cc: linux-samsung-soc at vger.kernel.org; linux at arm.linux.org.uk; > nico at linaro.org; kgene.kim at samsung.com; thomas.abraham at linaro.org; > bones at secretlab.ca; linux-arm-kernel at 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 at 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-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Early kernel hang with big DTB appended 2013-01-03 18:40 ` Bryan Evenson @ 2013-01-04 10:26 ` Tomasz Figa -1 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2013-01-04 10:26 UTC (permalink / raw) To: Bryan Evenson Cc: devicetree-discuss@lists.ozlabs.org, linux-samsung-soc@vger.kernel.org, linux@arm.linux.org.uk, nico@linaro.org, kgene.kim@samsung.com, thomas.abraham@linaro.org, bones@secretlab.ca, linux-arm-kernel@lists.infradead.org Hi Bryan, Thanks for your reply. On Thursday 03 of January 2013 13:40:43 Bryan Evenson wrote: > > -----Original Message----- > > From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm- > > kernel-bounces@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-soc@vger.kernel.org; linux@arm.linux.org.uk; > > nico@linaro.org; kgene.kim@samsung.com; thomas.abraham@linaro.org; > > bones@secretlab.ca; linux-arm-kernel@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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-04 10:26 ` Tomasz Figa 0 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2013-01-04 10:26 UTC (permalink / raw) To: linux-arm-kernel Hi Bryan, Thanks for your reply. On Thursday 03 of January 2013 13:40:43 Bryan Evenson wrote: > > -----Original Message----- > > From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm- > > kernel-bounces at lists.infradead.org] On Behalf Of Tomasz Figa > > Sent: Thursday, January 03, 2013 10:55 AM > > To: devicetree-discuss at lists.ozlabs.org > > Cc: linux-samsung-soc at vger.kernel.org; linux at arm.linux.org.uk; > > nico at linaro.org; kgene.kim at samsung.com; thomas.abraham at linaro.org; > > bones at secretlab.ca; linux-arm-kernel at 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 at 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Early kernel hang with big DTB appended 2013-01-03 15:55 ` Tomasz Figa @ 2013-01-04 2:48 ` Nicolas Pitre -1 siblings, 0 replies; 22+ messages in thread From: Nicolas Pitre @ 2013-01-04 2:48 UTC (permalink / raw) To: Tomasz Figa Cc: devicetree-discuss, linux-samsung-soc, linux-arm-kernel, bones, linux, thomas.abraham, kgene.kim 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-04 2:48 ` Nicolas Pitre 0 siblings, 0 replies; 22+ messages in thread From: Nicolas Pitre @ 2013-01-04 2:48 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Early kernel hang with big DTB appended 2013-01-04 2:48 ` Nicolas Pitre @ 2013-01-04 10:18 ` Tomasz Figa -1 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2013-01-04 10:18 UTC (permalink / raw) To: Nicolas Pitre Cc: devicetree-discuss, linux-samsung-soc, linux-arm-kernel, bones, linux, thomas.abraham, kgene.kim 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 0x40000000 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-04 10:18 ` Tomasz Figa 0 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2013-01-04 10:18 UTC (permalink / raw) To: linux-arm-kernel 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 0x40000000 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* $(make uImage) is stupid [Was: Re: Early kernel hang with big DTB appended] 2013-01-04 10:18 ` Tomasz Figa @ 2013-01-14 8:45 ` Uwe Kleine-König -1 siblings, 0 replies; 22+ messages in thread From: Uwe Kleine-König @ 2013-01-14 8:45 UTC (permalink / raw) To: Tomasz Figa Cc: Nicolas Pitre, linux-samsung-soc, linux, devicetree-discuss, kgene.kim, thomas.abraham, bones, linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 22+ messages in thread
* $(make uImage) is stupid [Was: Re: Early kernel hang with big DTB appended] @ 2013-01-14 8:45 ` Uwe Kleine-König 0 siblings, 0 replies; 22+ messages in thread From: Uwe Kleine-König @ 2013-01-14 8:45 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Early kernel hang with big DTB appended 2013-01-03 15:55 ` Tomasz Figa @ 2013-01-11 16:45 ` Sascha Hauer -1 siblings, 0 replies; 22+ messages in thread From: Sascha Hauer @ 2013-01-11 16:45 UTC (permalink / raw) To: Tomasz Figa Cc: devicetree-discuss, linux-samsung-soc, linux, nico, kgene.kim, thomas.abraham, bones, linux-arm-kernel 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-5555 | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-11 16:45 ` Sascha Hauer 0 siblings, 0 replies; 22+ messages in thread From: Sascha Hauer @ 2013-01-11 16:45 UTC (permalink / raw) To: linux-arm-kernel 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 at 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-5555 | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Early kernel hang with big DTB appended 2013-01-11 16:45 ` Sascha Hauer @ 2013-01-14 22:13 ` Nicolas Pitre -1 siblings, 0 replies; 22+ messages in thread From: Nicolas Pitre @ 2013-01-14 22:13 UTC (permalink / raw) To: Sascha Hauer Cc: Tomasz Figa, devicetree-discuss, linux-samsung-soc, Russell King - ARM Linux, kgene.kim, thomas.abraham, bones, linux-arm-kernel 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 movs r0, 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-14 22:13 ` Nicolas Pitre 0 siblings, 0 replies; 22+ messages in thread From: Nicolas Pitre @ 2013-01-14 22:13 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 movs r0, 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: Early kernel hang with big DTB appended 2013-01-14 22:13 ` Nicolas Pitre @ 2013-01-15 10:53 ` Sascha Hauer -1 siblings, 0 replies; 22+ messages in thread From: Sascha Hauer @ 2013-01-15 10:53 UTC (permalink / raw) To: Nicolas Pitre Cc: Tomasz Figa, devicetree-discuss, linux-samsung-soc, Russell King - ARM Linux, kgene.kim, thomas.abraham, bones, linux-arm-kernel 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 <s.hauer@pengutronix.de> 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 > movs r0, 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-5555 | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-15 10:53 ` Sascha Hauer 0 siblings, 0 replies; 22+ messages in thread From: Sascha Hauer @ 2013-01-15 10:53 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 <s.hauer@pengutronix.de> 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 > movs r0, 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-5555 | ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Early kernel hang with big DTB appended 2013-01-14 22:13 ` Nicolas Pitre @ 2013-01-15 11:26 ` Tomasz Figa -1 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2013-01-15 11:26 UTC (permalink / raw) To: Nicolas Pitre Cc: Sascha Hauer, devicetree-discuss, linux-samsung-soc, Russell King - ARM Linux, kgene.kim, thomas.abraham, bones, linux-arm-kernel 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 <t.figa@samsung.com> Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ^ permalink raw reply [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-15 11:26 ` Tomasz Figa 0 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2013-01-15 11:26 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 <t.figa@samsung.com> Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Early kernel hang with big DTB appended 2013-01-15 11:26 ` Tomasz Figa @ 2013-01-15 18:12 ` Nicolas Pitre -1 siblings, 0 replies; 22+ messages in thread From: Nicolas Pitre @ 2013-01-15 18:12 UTC (permalink / raw) To: Tomasz Figa Cc: Sascha Hauer, devicetree-discuss, linux-samsung-soc, Russell King - ARM Linux, kgene.kim, thomas.abraham, bones, linux-arm-kernel 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 <t.figa@samsung.com> Thanks. The patch is queued as 7628/1 in RMK's patch system. Nicolas ^ permalink raw reply [flat|nested] 22+ messages in thread
* Early kernel hang with big DTB appended @ 2013-01-15 18:12 ` Nicolas Pitre 0 siblings, 0 replies; 22+ messages in thread From: Nicolas Pitre @ 2013-01-15 18:12 UTC (permalink / raw) To: linux-arm-kernel 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 at 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 <t.figa@samsung.com> Thanks. The patch is queued as 7628/1 in RMK's patch system. Nicolas ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2013-01-15 18:12 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-01-03 15:55 Early kernel hang with big DTB appended Tomasz Figa 2013-01-03 15:55 ` Tomasz Figa 2013-01-03 18:40 ` Bryan Evenson 2013-01-03 18:40 ` Bryan Evenson 2013-01-04 10:26 ` Tomasz Figa 2013-01-04 10:26 ` Tomasz Figa 2013-01-04 2:48 ` Nicolas Pitre 2013-01-04 2:48 ` Nicolas Pitre 2013-01-04 10:18 ` Tomasz Figa 2013-01-04 10:18 ` Tomasz Figa 2013-01-14 8:45 ` $(make uImage) is stupid [Was: Re: Early kernel hang with big DTB appended] Uwe Kleine-König 2013-01-14 8:45 ` Uwe Kleine-König 2013-01-11 16:45 ` Early kernel hang with big DTB appended Sascha Hauer 2013-01-11 16:45 ` Sascha Hauer 2013-01-14 22:13 ` Nicolas Pitre 2013-01-14 22:13 ` Nicolas Pitre 2013-01-15 10:53 ` Sascha Hauer 2013-01-15 10:53 ` Sascha Hauer 2013-01-15 11:26 ` Tomasz Figa 2013-01-15 11:26 ` Tomasz Figa 2013-01-15 18:12 ` Nicolas Pitre 2013-01-15 18:12 ` Nicolas Pitre
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.