From patchwork Wed Jun 1 21:31:54 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nishanth Menon X-Patchwork-Id: 69076 Delivered-To: patch@linaro.org Received: by 10.140.23.41 with SMTP id 38csp18853qgo; Wed, 1 Jun 2016 14:32:44 -0700 (PDT) X-Received: by 10.98.32.140 with SMTP id m12mr12984418pfj.119.1464816764658; Wed, 01 Jun 2016 14:32:44 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id uy8si26204354pac.229.2016.06.01.14.32.44; Wed, 01 Jun 2016 14:32:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751485AbcFAVcl (ORCPT + 30 others); Wed, 1 Jun 2016 17:32:41 -0400 Received: from bear.ext.ti.com ([198.47.19.11]:49892 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751001AbcFAVck (ORCPT ); Wed, 1 Jun 2016 17:32:40 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id u51LW0R5011056; Wed, 1 Jun 2016 16:32:00 -0500 Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id u51LW0vK031660; Wed, 1 Jun 2016 16:32:00 -0500 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE73.ent.ti.com (128.247.5.110) with Microsoft SMTP Server id 14.3.294.0; Wed, 1 Jun 2016 16:32:00 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id u51LVxhV004216; Wed, 1 Jun 2016 16:31:59 -0500 From: Nishanth Menon To: Russell King , Santosh Shilimkar CC: , , Nishanth Menon , Bill Mills , Murali Karicheri , Grygorii Strashko , Tero Kristo , Lokesh Vutla Subject: [PATCH] ARM: Keystone: Introduce Kconfig option to compile in typical Keystone features Date: Wed, 1 Jun 2016 16:31:54 -0500 Message-ID: <1464816714-3900-1-git-send-email-nm@ti.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Introduce ARCH_KEYSTONE_TYPICAL which is common for all Keystone platforms. This is particularly useful when custom optimized defconfig builds are created for Keystone architecture platforms. An example of the same would be a sample fragment ks_only.cfg: http://pastebin.ubuntu.com/16904991/ - This prunes all arch other than keystone and any options the other architectures may enable. git clean -fdx && git reset --hard && \ ./scripts/kconfig/merge_config.sh -m \ ./arch/arm/configs/multi_v7_defconfig ~/tmp/ks_only.cfg &&\ make olddefconfig The above unfortunately will disable options necessary for KS2 boards to boot to the bare minimum initramfs. Hence the "KEYSTONE_TYPICAL" option is designed similar to commit 8d9166b519fd ("omap2/3/4: Add Kconfig option to compile in typical omap features") that can be enabled for most boards keystone platforms without needing to rediscover these in defconfig all over again - examples include multi_v7_defconfig base and optimizations done on top of them for keystone platform. NOTE: the alternative is to select the configurations under ARCH_KEYSTONE. However, that would fail multi_v7 builds on ARM variants that dont work with LPAE. Cc: Bill Mills Cc: Murali Karicheri Cc: Grygorii Strashko Cc: Tero Kristo Cc: Lokesh Vutla Signed-off-by: Nishanth Menon --- Based on: next-20160601 Tested for basic initramfs boot for K2HK/K2G platforms with the http://pastebin.ubuntu.com/16904991/ fragment + multi_v7_defconfig Side note on LPAE: For our current device tree and u-boot, LPAE is mandatory to bootup for current Keystone boards - but this is not a SoC requirement, booting without LPAE/HIGHMEM results in non-coherent DDR accesses. Currently: - U-Boot assumes that lpae is always enabled in kennel and updates the DT memory node with higher addresses. Because of which you are not detecting any memory without lpae and kernel crashed very early, hence no prints. So, make mem_lpae env setting as 0 in U-boot. - DT also assumes that lpae is always enabled, and always asks for dma-address translation for higher addresses to lower addresses. Just delete the "dma-ranges" property or create a one-on-one mapping like dma-ranges = <0x80000000 0x0 0x80000000 0x80000000> These are probably the reasons for the kernel not booting without LPAE enabled in .config. but then, the TI recommended operation for Keystone platforms is with LPAE and HIGHMEM enabled for coherent architecture behavior. arch/arm/mach-keystone/Kconfig | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) -- 2.8.0 diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig index ea955f6db8b7..a151f878143f 100644 --- a/arch/arm/mach-keystone/Kconfig +++ b/arch/arm/mach-keystone/Kconfig @@ -14,3 +14,22 @@ config ARCH_KEYSTONE help Support for boards based on the Texas Instruments Keystone family of SoCs. + +if ARCH_KEYSTONE + +menu "TI Keystone Specific Features" + +config ARCH_KEYSTONE_TYPICAL + bool "Typical Keystone configuration" + depends on ARM_LPAE + default y + select AEABI + select HIGHMEM + select NEON + select PM + select VFP + help + Compile a kernel suitable for booting most boards on Keystone + architecture to at least a simple initramfs +endmenu +endif