All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] am335x_evm: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support
Date: Wed, 24 Oct 2012 13:56:55 -0700	[thread overview]
Message-ID: <50885617.1060609@ti.com> (raw)
In-Reply-To: <50883FB9.6050003@wwwdotorg.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/24/12 12:21, Stephen Warren wrote:
> On 10/24/2012 11:28 AM, Tom Rini wrote:
>> We add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, 
>> CONFIG_BOARD_LATE_INIT to set the variables and then fdtfile and
>>  findfdt to make us of this.  It is now possible to do 'run 
>> findfdt' to have fdtfile be set to the value of the dtb file to 
>> load for the board we are running on.
> 
>> diff --git a/arch/arm/cpu/armv7/am33xx/board.c 
>> b/arch/arm/cpu/armv7/am33xx/board.c
> 
>> +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG +	char 
>> safe_string[HDR_NAME_LEN + 1]; + +	/* Now set variables based on
>>  the header. */ +	strncpy(safe_string, (char *)header.name, 
>> sizeof(header.name)); +	safe_string[sizeof(header.name)] = 0; + 
>> setenv("board_name", safe_string); + +	strncpy(safe_string, (char
>> *)header.version, sizeof(header.version)); + 
>> safe_string[sizeof(header.version)] = 0; +	setenv("board_rev", 
>> safe_string); +#endif
> 
> By the way, is there any way to flag these variables as not being 
> saved in the environment by saveenv? With the code above, the 
> values will get over-written every time, so it's not such a big 
> deal; the only issue is that the value needlessly gets saved into 
> flash or uEnv.txt.
> 
> But what about a runtime-calculated variable that is only sometimes
> set? I suppose the answer there is to explicitly clear it if you
> aren't setting it.

Joe?  Am I thinking right that your env work leads us down the path of
being able to do this?

> Or what about if the environment gets saved to uEnv.txt on an SD 
> card which gets moved to a compatible but different board or board
>  revision, running an older U-Boot that doesn't have this patch; 
> then, the values stick around even though they're stale.

Yes, there's potential problems, but I think we can work around it or
live with it.  And FYI, uEnv.txt is (more or less) an un-mkimage'd
boot.scr file :)

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQiFYXAAoJENk4IS6UOR1WyIMP/iGYC6j001RpBgV3zn3AgAvG
5h+2f9C/LgSrEiuH2FarginkbOqyRR1fn/GYbwK/hK3+UMyPU7bY2m++VJ1RobQ8
j8A4HGHxBh/afrpkly/TtgXjJeK5NPxB7AH0mu0UBsBAFg7b64dVjVc1ZUuwkqBO
zddoFhLOvpUAuBOPiVZLBUREdgGs23pG7HO7yfyEbdUsZv6U09zlY/FQR06JgANu
2AjUZ932oH54448qmXdX2ePdX8zpWeXmsHwEDWX8kgJbGiUSe2oQbBc/u27/g1KS
LiJKfh9YaJV8EYkeF+i/CDwWNI81ykuHsSOem/AsXNhk3/r2Ua54WB3oUXHEZji1
h6J+3wxF1pS/9r5/FzHsKaeR5GCGXDDEDONlDuJb4PB0ZCuDfzGmsAOBxtA/0GiU
U6S3Cxwk7ajmXdtbVpZ+kzIemsqHbJd2wXKR2UDPa7fNqiTDa0XLfvWuwx6PdAmJ
aZoz344padFBdv/qVmF8657pUMaPW8A4YuTFmf1sj2QD3BtA5ATbMKD2Wu5RXbjY
feb/BxbZihfnCSA3RoyDCZC7Bh/OHz9v2lK6aSBQR1Jh+4ozmn6njla5iNVKcLuX
SbRyjJk1kmaAOUcdhDV6py9I+Fs8CmGFynBSCSkY+8nIiCzVl8587z8bcAOp6lHn
Fq0Kcoybbkp2lhyqAUG0
=sttt
-----END PGP SIGNATURE-----

  reply	other threads:[~2012-10-24 20:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-24 17:28 [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables Tom Rini
2012-10-24 17:28 ` [U-Boot] [PATCH 1/2] README: Document CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG Tom Rini
2012-10-24 17:28 ` [U-Boot] [PATCH 2/2] am335x_evm: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support Tom Rini
2012-10-24 19:21   ` Stephen Warren
2012-10-24 20:56     ` Tom Rini [this message]
2012-10-24 17:50 ` [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables Stephen Warren
2012-10-24 18:41   ` Tom Rini
2012-10-24 19:05     ` Stephen Warren
2012-10-24 19:32       ` Tom Rini
2012-10-24 22:24         ` Stephen Warren
2012-10-26  7:45         ` Joe Hershberger
2012-10-29 15:15           ` Stephen Warren
2012-10-29 18:13             ` Tom Rini
2012-10-30  0:14               ` Joe Hershberger
2012-10-26  2:41       ` Simon Glass
2012-11-04 18:29 ` 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=50885617.1060609@ti.com \
    --to=trini@ti.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.