Eddie Huang <eddie.huang@xxxxxxxxxxxx> writes: > On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote: >> Hi Eddie, >> >> Kevin Hilman <khilman@xxxxxxxxxx> writes: >> >> > Eddie Huang <eddie.huang@xxxxxxxxxxxx> writes: >> > >> >> On Tue, 2015-11-10 at 17:16 -0800, Kevin Hilman wrote: >> >>> Hi Eddie, >> >>> >> >>> [...] >> >>> >> >>> > I check the log [0], >> >>> >> >>> Thanks for checking into this boot failure. >> >>> >> >>> > it seems first time mt8135-evbp1 boot to kernel >> >>> > shell successfully, then boot again. In the second time, mt8135 stay in >> >>> > fastboot mode, waiting host send boot image, then timeout. >> >>> >> >>> Actually, it never gets to a shell the first time. If you look closely, >> >>> the target reboots as soon as userspace starts. Look for the PYBOOT >> >>> line which says "finished booting, starting userspace" >> >>> >> >>> Later on, pyboot thinks it finds a root shell due to finding '#' >> >>> characters, but clearly it never got to a shell. >> >>> >> >>> > I download zImage and dtb in [1], and kernel run to shell successfully >> >>> > on my platform. >> >>> >> >>> Are you can you try using a ramdisk as well? You can use the pre-built >> >>> one here: >> >>> http://storage.kernelci.org/images/rootfs/buildroot/armel/rootfs.cpio.gz >> >>> >> >> >> >> Yes, I tried this ramdisk, and I can reproduce fail issue. >> >> >> > >> > OK, good. Thanks for looking into it. >> > >> >>> Please check my boot logs to see how I'm generating the boot.img file >> >>> (search for mkbootimg) with a kernel/dtb/ramdisk. It may be possible >> >>> that the kernel image size with a ramdisk is breaking some of the >> >>> assumptions in the fastboot mode. I've seen problems like this on other >> >>> platforms due to hard-coded sizes/addresses in the boot firmware. >> >>> >> >> >> >> MT8135 allocate 10MB for BOOT partition, but the test boot.img is 11MB, >> >> thus cause user space fail. >> > >> > Aha, I was right! ;) >> >> Also notice in kernelci.org that the mt8173 board has also been failing >> to boot in mainline[1]. I wonder if this same limitation exists in the >> mt8173 boot firmware? >> > > MT8173 is another case, the failure is due to following commit: > 67e56c5 arm64: dts: mt8173: Add subsystem clock controller device nodes > > It is because this commit register MM subsystem clock, but kernel don't > use MM clock yet, then CCF disable it. (My internal platform kernel > command include clk_ignore_unused parameter, so don't have this > problem).I will do further checking and release solution later. Thanks > your testing. OK, thanks for looking into it. However, since the merge window is very close to closing, unless you can git a fix out soon (and one that doesn't introduce other bugs), probablly the right solution is to just revert the above patch so things are fixed for mainline ASAP. Kevin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
