From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: Problems booting exynos5420 with >1 CPU Date: Mon, 09 Jun 2014 13:27:51 -0700 Message-ID: <7hoay1rfp4.fsf@paris.lan> References: <539145B4.5000200@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from mail-pb0-f43.google.com ([209.85.160.43]:43511 "EHLO mail-pb0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753988AbaFIU1y (ORCPT ); Mon, 9 Jun 2014 16:27:54 -0400 Received: by mail-pb0-f43.google.com with SMTP id up15so5344467pbc.16 for ; Mon, 09 Jun 2014 13:27:54 -0700 (PDT) In-Reply-To: (Nicolas Pitre's message of "Sat, 7 Jun 2014 12:10:27 -0400 (EDT)") Sender: linux-samsung-soc-owner@vger.kernel.org List-Id: linux-samsung-soc@vger.kernel.org To: Nicolas Pitre Cc: Abhilash Kesavan , Doug Anderson , linux-samsung-soc , "Turquette, Mike" , Tushar Behera , Thomas Abraham , linux-arm-kernel , Olof Johansson , Sonny Rao , Javier Martinez Canillas , Arun Kumar Nicolas Pitre writes: > On Sat, 7 Jun 2014, Abhilash Kesavan wrote: > >> Hi Nicolas, >> >> The first man of the incoming cluster enables its snoops via the >> power_up_setup function. During secondary boot-up, this does not occur >> for the boot cluster. Hence, I enable the snoops for the boot cluster >> as a one-time setup from the u-boot prompt. After secondary boot-up >> there is no modification that I do. > > OK that's good. > >> Where should this be ideally done ? > > If I remember correctly, the CCI can be safely activated only when the > cache is disabled. So that means the CCI should ideally be turned on > for the boot cluster (and *only* for the boot CPU) by the bootloader. > > Now... If you _really_ prefer to do it from the kernel to avoid > difficulties with bootloader updates, then it should be possible to do > it from the kernel by temporarily turning the cache off. This is not a > small thing but the MCPM infrastructure can be leveraged. Here's what I > tried on a TC2 which might just work for you as well: FWIW, I dropped the u-boot hack I was using to enable CCI and tested this patch (with a cut/paste of the TC2 specific stuff into mach-exynos/mcpm-exynos.c) along with Doug's patch[1] and and confirm that all 8 cores boot up on the Chromebook2 using linux-next. Kevin [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262440.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@linaro.org (Kevin Hilman) Date: Mon, 09 Jun 2014 13:27:51 -0700 Subject: Problems booting exynos5420 with >1 CPU In-Reply-To: (Nicolas Pitre's message of "Sat, 7 Jun 2014 12:10:27 -0400 (EDT)") References: <539145B4.5000200@gmail.com> Message-ID: <7hoay1rfp4.fsf@paris.lan> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Nicolas Pitre writes: > On Sat, 7 Jun 2014, Abhilash Kesavan wrote: > >> Hi Nicolas, >> >> The first man of the incoming cluster enables its snoops via the >> power_up_setup function. During secondary boot-up, this does not occur >> for the boot cluster. Hence, I enable the snoops for the boot cluster >> as a one-time setup from the u-boot prompt. After secondary boot-up >> there is no modification that I do. > > OK that's good. > >> Where should this be ideally done ? > > If I remember correctly, the CCI can be safely activated only when the > cache is disabled. So that means the CCI should ideally be turned on > for the boot cluster (and *only* for the boot CPU) by the bootloader. > > Now... If you _really_ prefer to do it from the kernel to avoid > difficulties with bootloader updates, then it should be possible to do > it from the kernel by temporarily turning the cache off. This is not a > small thing but the MCPM infrastructure can be leveraged. Here's what I > tried on a TC2 which might just work for you as well: FWIW, I dropped the u-boot hack I was using to enable CCI and tested this patch (with a cut/paste of the TC2 specific stuff into mach-exynos/mcpm-exynos.c) along with Doug's patch[1] and and confirm that all 8 cores boot up on the Chromebook2 using linux-next. Kevin [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262440.html