From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933386AbbKLX4f (ORCPT ); Thu, 12 Nov 2015 18:56:35 -0500 Received: from mail-pa0-f49.google.com ([209.85.220.49]:34824 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754599AbbKLX43 (ORCPT ); Thu, 12 Nov 2015 18:56:29 -0500 From: Kevin Hilman To: Eddie Huang Cc: Yingjoe Chen , "devicetree\@vger.kernel.org" , Russell King - ARM Linux , , Arnd Bergmann , Tyler Baker , Stephen Boyd , lkml , Olof Johansson , Rob Herring , , Sascha Hauer , Matthias Brugger , "linux-arm-kernel\@lists.infradead.org" Subject: Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135 References: <1443799181-50409-1-git-send-email-yingjoe.chen@mediatek.com> <1443799181-50409-5-git-send-email-yingjoe.chen@mediatek.com> <1445843717.23888.1.camel@mtksdaap41> <1445859610.26723.4.camel@mtksdaap41> <1447135867.14454.9.camel@mtksdaap41> <7h1tbx1gjp.fsf@deeprootsystems.com> <1447228557.20886.10.camel@mtksdaap41> <7hpozgyu36.fsf@deeprootsystems.com> <7hwptnddhs.fsf@deeprootsystems.com> <1447332379.4156.5.camel@mtksdaap41> Date: Thu, 12 Nov 2015 15:56:26 -0800 In-Reply-To: <1447332379.4156.5.camel@mtksdaap41> (Eddie Huang's message of "Thu, 12 Nov 2015 20:46:19 +0800") Message-ID: <7hd1vedb6d.fsf@deeprootsystems.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Eddie Huang writes: > On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote: >> Hi Eddie, >> >> Kevin Hilman writes: >> >> > Eddie Huang 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135 Date: Thu, 12 Nov 2015 15:56:26 -0800 Message-ID: <7hd1vedb6d.fsf@deeprootsystems.com> References: <1443799181-50409-1-git-send-email-yingjoe.chen@mediatek.com> <1443799181-50409-5-git-send-email-yingjoe.chen@mediatek.com> <1445843717.23888.1.camel@mtksdaap41> <1445859610.26723.4.camel@mtksdaap41> <1447135867.14454.9.camel@mtksdaap41> <7h1tbx1gjp.fsf@deeprootsystems.com> <1447228557.20886.10.camel@mtksdaap41> <7hpozgyu36.fsf@deeprootsystems.com> <7hwptnddhs.fsf@deeprootsystems.com> <1447332379.4156.5.camel@mtksdaap41> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <1447332379.4156.5.camel@mtksdaap41> (Eddie Huang's message of "Thu, 12 Nov 2015 20:46:19 +0800") Sender: linux-kernel-owner@vger.kernel.org To: Eddie Huang Cc: Yingjoe Chen , "devicetree@vger.kernel.org" , Russell King - ARM Linux , srv_heupstream@mediatek.com, Arnd Bergmann , Tyler Baker , Stephen Boyd , lkml , Olof Johansson , Rob Herring , linux-mediatek@lists.infradead.org, Sascha Hauer , Matthias Brugger , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org Eddie Huang writes: > On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote: >> Hi Eddie, >> >> Kevin Hilman writes: >> >> > Eddie Huang 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@kernel.org (Kevin Hilman) Date: Thu, 12 Nov 2015 15:56:26 -0800 Subject: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135 In-Reply-To: <1447332379.4156.5.camel@mtksdaap41> (Eddie Huang's message of "Thu, 12 Nov 2015 20:46:19 +0800") References: <1443799181-50409-1-git-send-email-yingjoe.chen@mediatek.com> <1443799181-50409-5-git-send-email-yingjoe.chen@mediatek.com> <1445843717.23888.1.camel@mtksdaap41> <1445859610.26723.4.camel@mtksdaap41> <1447135867.14454.9.camel@mtksdaap41> <7h1tbx1gjp.fsf@deeprootsystems.com> <1447228557.20886.10.camel@mtksdaap41> <7hpozgyu36.fsf@deeprootsystems.com> <7hwptnddhs.fsf@deeprootsystems.com> <1447332379.4156.5.camel@mtksdaap41> Message-ID: <7hd1vedb6d.fsf@deeprootsystems.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Eddie Huang writes: > On Wed, 2015-11-11 at 20:54 -0800, Kevin Hilman wrote: >> Hi Eddie, >> >> Kevin Hilman writes: >> >> > Eddie Huang 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