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@xxxxxxxxxxxxxxxxxxx [mailto:linux-arm- > > kernel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Tomasz Figa > > Sent: Thursday, January 03, 2013 10:55 AM > > To: devicetree-discuss@xxxxxxxxxxxxxxxx > > Cc: linux-samsung-soc@xxxxxxxxxxxxxxx; linux@xxxxxxxxxxxxxxxx; > > nico@xxxxxxxxxx; kgene.kim@xxxxxxxxxxx; thomas.abraham@xxxxxxxxxx; > > bones@xxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |