public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] jetson-tk1: Set fdtfile environment variable
Date: Wed, 13 Apr 2016 20:17:31 +0200	[thread overview]
Message-ID: <570E8D3B.40601@suse.de> (raw)
In-Reply-To: <570E88BD.1050006@wwwdotorg.org>

Am 13.04.2016 um 19:58 schrieb Stephen Warren:
> On 04/13/2016 11:42 AM, Andreas F?rber wrote:
>> Am 13.04.2016 um 19:00 schrieb Stephen Warren:
>>> Anyway, nothing in your benefits-of-EFI statement implies that relying
>>> on $fdtfile being set is correct. That's a new requirement that didn't
>>> exist before. Either the requirement needs to be removed (e.g. using a
>>> default FDT filename such as "${soc}-${board}${boardver}.dts") or only
>>> enabling this functionality on boards that do set $fdtfile, since it
>>> relies on that.
>>
>> $fdtfile needs to be the Linux filename. It does not always follow the
>> same pattern as the U-Boot variables you suggest here.
>> CONFIG_DEFAULT_DEVICE_TREE ".dtb" might work better, and that was my
>> question to you.
> 
> That pattern is a good default that at least historically applied to all
> the systems where the distro bootcmds were enabled. Perhaps the set of
> systems using the distro bootcmds has increased now so the default isn't
> always applicable. Boards can set $fdtfile /if/ needed because of that,
> but I don't think should be forced to in all cases where the default
> makes sense.

I really don't care whether we set fdtfile and use $fdtfile or whether
we insert the filename string directly into the appropriate command
variable... My point is U-Boot via its jetson-tk1_defconfig / .config
knows this (or should know) better than any user. And it seemed to me
that variables were not exactly used sparingly in the distro mechanism
so far, so I don't see why not to populate that variable _if_ we know
what its value needs to be. Do you have any real reason for being
against populating fdtfile at whatever level turns out to be suitable?

I believe there is no argument that this patch will not be applied.
However I am strongly rejecting your attitude that everything is there
already with variables and that nothing new is needed. Something needs
to be done somewhere - and we need to figure out what exactly and where
for minimum impact to the release.

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

  reply	other threads:[~2016-04-13 18:17 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 12:48 [U-Boot] [PATCH] jetson-tk1: Set fdtfile environment variable Andreas Färber
2016-04-13 12:55 ` Andreas Färber
2016-04-13 15:31   ` Stephen Warren
2016-04-13 15:51     ` Alexander Graf
2016-04-13 17:00       ` Stephen Warren
2016-04-13 17:21         ` Alexander Graf
2016-04-13 17:31           ` Stephen Warren
2016-04-13 17:40             ` Alexander Graf
2016-04-13 22:17           ` Tom Rini
2016-04-13 22:38             ` Alexander Graf
2016-04-13 22:49               ` Tom Rini
2016-04-13 17:42         ` Andreas Färber
2016-04-13 17:58           ` Stephen Warren
2016-04-13 18:17             ` Andreas Färber [this message]
2016-04-13 18:51               ` Stephen Warren
2016-04-13 20:27                 ` Andreas Färber
2016-04-14  4:43                   ` Stephen Warren
2016-04-13 22:29           ` Tom Rini
2016-04-15 21:15             ` Alexander Graf
2016-04-13 17:22     ` Andreas Färber
2016-04-13 17:40       ` Stephen Warren
2016-04-13 17:50         ` Alexander Graf
2016-04-13 18:01           ` Stephen Warren
2016-04-13 18:02         ` Andreas Färber
2016-04-13 22:05           ` Tom Rini
2016-04-13 23:14             ` Andreas Färber
2016-04-13 21:59     ` Tom Rini

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=570E8D3B.40601@suse.de \
    --to=afaerber@suse.de \
    --cc=u-boot@lists.denx.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox