public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox