LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Marcel Ziswiler <marcel@ziswiler.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: "stefan@agner.ch" <stefan@agner.ch>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"jonathanh@nvidia.com" <jonathanh@nvidia.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"dev@lynxeye.de" <dev@lynxeye.de>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v2] ARM: dts: tegra: Add support for 256 MB Colibri-T20 (plus such board on Iris)
Date: Tue, 08 May 2018 15:03:02 +0200	[thread overview]
Message-ID: <1525784582.6999.27.camel@ziswiler.com> (raw)
In-Reply-To: <CAJKOXPetgqJgGHwdSzZeujM2KEDMWqffYMAJdBS3MXPd3Thb5w@mail.gmail.com>

On Tue, 2018-05-08 at 14:35 +0200, Krzysztof Kozlowski wrote:
> On Fri, May 4, 2018 at 12:14 PM, Marcel Ziswiler
> <marcel.ziswiler@toradex.com> 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 <stefan@agner.ch>
> > > 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.").

Argh, I guess that happens if you have stubborn IT departments which
still believe in M$. Sending via private email now.

> Therefore I did not include your comments
> and sent v3.

Yeah, I noticed that. It's forgiven, don't worry (;-p).

> > > 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.

Makes sense.

> > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > > 
> > > > > ---
> > > > > 
> > > > > 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.

Yeah, for a while I kept his patch set alive as well. I believe 4.4 was
still working fine passing all MTD tests. However, lately there were so
many changes it all fell apart. About a month ago I spend a couple
nights trying to get it running again but something is still not quite
right. Yet have to sync with Stefan in my team who is much more
knowledgeable about latest NAND development.

> Best regards,
> Krzysztof

Cheers

Marcel

  reply	other threads:[~2018-05-08 13:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03 15:08 Krzysztof Kozlowski
2018-05-04  9:19 ` Stefan Agner
2018-05-04  9:37   ` Marcel Ziswiler
2018-05-04 10:03   ` Krzysztof Kozlowski
2018-05-04 10:14     ` Marcel Ziswiler
2018-05-08 12:35       ` Krzysztof Kozlowski
2018-05-08 13:03         ` Marcel Ziswiler [this message]
2018-05-07 16:58 ` Rob Herring
2018-05-08  7:26   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1525784582.6999.27.camel@ziswiler.com \
    --to=marcel@ziswiler.com \
    --cc=dev@lynxeye.de \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=stefan@agner.ch \
    --cc=thierry.reding@gmail.com \
    --subject='Re: [PATCH v2] ARM: dts: tegra: Add support for 256 MB Colibri-T20 (plus such board on Iris)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).