lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 11 Nov 2015 20:54:07 -0800 From: Kevin Hilman <khilman@...nel.org> To: Eddie Huang <eddie.huang@...iatek.com> Cc: Yingjoe Chen <yingjoe.chen@...iatek.com>, "devicetree\@vger.kernel.org" <devicetree@...r.kernel.org>, Russell King - ARM Linux <linux@....linux.org.uk>, <srv_heupstream@...iatek.com>, Arnd Bergmann <arnd@...db.de>, Tyler Baker <tyler.baker@...aro.org>, Stephen Boyd <sboyd@...eaurora.org>, lkml <linux-kernel@...r.kernel.org>, Olof Johansson <olof@...om.net>, Rob Herring <robh+dt@...nel.org>, <linux-mediatek@...ts.infradead.org>, Sascha Hauer <kernel@...gutronix.de>, Matthias Brugger <matthias.bgg@...il.com>, "linux-arm-kernel\@lists.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135 Hi Eddie, Kevin Hilman <khilman@...nel.org> writes: > Eddie Huang <eddie.huang@...iatek.com> 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? Kevin [1] http://kernelci.org/boot/mt8173-evb/job/mainline/kernel/v4.3-11553-g8d3de01cfa37/defconfig/defconfig/lab/lab-khilman/?_id=5643bc3959b5145c9e0918f4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists