Received: by 10.192.165.148 with SMTP id m20csp4250928imm; Tue, 8 May 2018 05:37:31 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo6soitTEO7VS9r7Ti3Lgqkao1c7gVpqsNiOtMwMyFn8HwrInTR54xqe+moKSQqw5XOSDRZ X-Received: by 2002:a63:7d43:: with SMTP id m3-v6mr26352024pgn.117.1525783051444; Tue, 08 May 2018 05:37:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525783051; cv=none; d=google.com; s=arc-20160816; b=yM+ilFNW5t+WFw93H4+5a7OARLKsKlq+IYbJz6vuEBzXwpw0Pu6XZB5JRL55vgI1qT EN87xGgXUV6fhMDeWEBFmVLCtB4esTi52t0KOO3/fYQMwzKiD0/8wCGs/M5p+ZLl8WGg C72eZqsKKLCxJ5zh1zHOBOvTOZWVJk9wxQVuYimCNF+9hlsWegaW+RerNwrRIMxNwU0Y zPK+bKi1v/hvxxDqgllCB32BWCvKZnvyiEUNlR6MBnOY+1FyUTVc34wM+QHg9hwI5+lA Kj4uAr+v9/fpuuHAUM6F2b+5+aXVBKegV0yyiQFM47RrQOj69JRJZUTSmmg7pqMbMS3F RsGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=Bi3AFRX7d6hMg8V1JrV3wV9bTzGl/1SZxvdYFR7Vnk0=; b=iTa5PX/SPbqvXof49VPF2ZXb/ecsvO91OB6uWzd0UwWusBfrgR0nF9aghr174MYk3D HBkqrqRjp1V0fEJOskEklVm6yk7isakuCPtzPs4an2W79dqIaMQwqpy/TpyMHuF/8O4i YAlGEGxlAulc4KoBR1YJ87EuJ9vByT93UezPBeV9pfUXEXDkoWf/0kiTAKEAmOR3CU2t +TKjcZF+hl2DeM1L2dcvoTSoWz5vXv08/f/93TY5qFcQcKLLPzXoHi23j9saDj4b7Avs rHqYIAcWbPZ9vEsWMXU5kBVw/TueWyT2RbWhGy/W3vQlTANGgKSo0ylkSKkBDsEt7eMh MZSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=z99d1Evc; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h14-v6si25140740plk.535.2018.05.08.05.37.17; Tue, 08 May 2018 05:37:31 -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; dkim=pass header.i=@kernel.org header.s=default header.b=z99d1Evc; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754815AbeEHMfu (ORCPT + 99 others); Tue, 8 May 2018 08:35:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:34888 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752390AbeEHMfs (ORCPT ); Tue, 8 May 2018 08:35:48 -0400 Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DD03721837; Tue, 8 May 2018 12:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1525782948; bh=Y+M+DSCjJUvOY3fhhe4AlVWos4TKA27N7g/TG/JExoA=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=z99d1EvcEl7P0899jyVyy/sSxCPSOZFMN+7jYnpSs+aYcLyLHXn4M9aBQslkvyvnu o1+JK1wnCuCcZoUq2JV40bl7nMxb1A0i0JgJhUwnEImNuJeQU799UbtQh1enD2CBOC rdKH36NcA38pHf1ZRt9y4rVqCYus5tZKQqrOqkqA= Received: by mail-wm0-f50.google.com with SMTP id j4so18583530wme.1; Tue, 08 May 2018 05:35:47 -0700 (PDT) X-Gm-Message-State: ALKqPwfQaIbchClHM9y4yopzdihekt4QyjceYsSqKDBHZDe1SM9KPhQk Y8e4csxG09gP0GJ2w8c2YyAtDpoMP1Mq3iG77gM= X-Received: by 10.28.213.70 with SMTP id m67mr3544152wmg.117.1525782946311; Tue, 08 May 2018 05:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.199.70 with HTTP; Tue, 8 May 2018 05:35:45 -0700 (PDT) In-Reply-To: <1525428885.6296.18.camel@toradex.com> References: <1525360112-9893-1-git-send-email-krzk@kernel.org> <1525428885.6296.18.camel@toradex.com> From: Krzysztof Kozlowski Date: Tue, 8 May 2018 14:35:45 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] ARM: dts: tegra: Add support for 256 MB Colibri-T20 (plus such board on Iris) To: Marcel Ziswiler Cc: "stefan@agner.ch" , "linux-kernel@vger.kernel.org" , "robh+dt@kernel.org" , "jonathanh@nvidia.com" , "devicetree@vger.kernel.org" , "dev@lynxeye.de" , "thierry.reding@gmail.com" , "mark.rutland@arm.com" , "linux-tegra@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 4, 2018 at 12:14 PM, Marcel Ziswiler wrote: > Hi Krzysztof > > On Fri, 2018-05-04 at 12:03 +0200, Krzysztof Kozlowski wrote: >> On Fri, May 4, 2018 at 11:19 AM, Stefan Agner >> wrote: >> > On 03.05.2018 17:08, Krzysztof Kozlowski wrote: >> > > Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB >> > > RAM >> > > (with 1024 MB NAND) flavors. Add support for the 256 MB version >> > > on Iris >> > > evaluation board. >> > >> > To we really need to specify memory size these days? I think all >> > common >> > boot loaders fill the memory node anyway. >> > >> > arch/arm/boot/dts/imx6qdl-apalis.dtsi: >> > /* Will be filled by the bootloader */ >> > memory@10000000 { >> > reg = <0x10000000 0>; >> > }; >> > >> > >> > I think we should just rename tegra20-colibri-512.dtsi => >> > tegra20-colibri.dtsi and tegra20-iris-512.dts => tegra20-iris.dts >> > to >> > avoid confusion and add such an empty node. >> >> Having memory node is requirement of DeviceTree specification (at >> least one cpu and memory node). Of course if bootloader fills it, >> then >> we could assume that specification is satisfied... but what if some >> bootloader skips it? This creates quite specific dependency between >> kernel's DTS and bootloader. > > Yes, no system boots without any boot loader e.g. initialising the > memory and what not. So there are obviously quite specific > dependencies. Sorry for late reply, I missed your emails because unfortunately Google marks messages coming for Toradex as spam ("This message has a from address in toradex.com but has failed toradex.com's required tests for authentication."). Therefore I did not include your comments and sent v3. > >> One safe solution would be to specify 256 MB memory node for both >> boards and assume that bootloader will bump it to 512 MB for specific >> module. > > Like I mentioned this actually used to be how it was done however > lately it has been agreed that any boot loader anyway needs to do the > device tree dance (e.g. even just loading and passing it). Then the safest way is to provide /memory node with 256 MB. If some bootloader omits it (e.g. because it is too old or by any mistake) the FDT will be still usable with reduced memory in case of 512 board. >> > > Signed-off-by: Krzysztof Kozlowski >> > > >> > > --- >> > > >> > > Changes since v1: >> > > 1. Fix memory size in tegra20-colibri-256.dtsi (was working fine >> > > because >> > > my bootloader uses mem= argument). >> > >> > What boot loader are you using? You even can omit mem= if your boot >> > loader fills the memory node properly. >> >> I use the one provided by vendor - Toradex. By default it passes both >> mem= and few other mem-like arguments (for FB and video processor) to >> command line. I believe it does not adjust the DTB itself because >> Toradex prepared this bootloader for... 3.1 kernel without DTB. 7 >> years old kernel. :) > > Remember our regular BSP is still based on NVIDIA's downstream Linux > for Tegra aka L4T R16.5 based on Linux kernel 3.1.10 which does not > even use any device tree yet. Yes, I noticed. I am trying to bring it fully on new kernels but no huge successes so far... I'm stuck on NAND trying Lucas Stach's old patchset. Best regards, Krzysztof