From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Remove global variable env_t *env_ptr ?
Date: Tue, 4 Apr 2017 10:44:01 +0000 [thread overview]
Message-ID: <1491302640.30240.1.camel@infinera.com> (raw)
In-Reply-To: <20170404103137.68669120907@gemini.denx.de>
On Tue, 2017-04-04 at 12:31 +0200, Wolfgang Denk wrote:
> Dear Joakim,
>
> In message <1491301459.28343.1.camel@infinera.com> you wrote:
> >
> > Use case is when CONFIG_ENV_SECT_SIZE and/or CONFIG_ENV_ADDR are non constants.
>
> That is my exact question - when would this happen? Flash sectors
> do now wander around in memory or change size :-)
No, but they happens when you are forced to update you HW with new type of flashes
with different layout so you have to move where the environment is stored.
Sure, this can be fixed by having two different u-boot images but that will
in our case be just painful to carry around an extra u-boot img, then in field
devise a method to chose the right img. for what looks like the same HW but the flash.
What I have done is not that earth shattering, basically just move from:
static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;
to
int env_init(void)
{
...
env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;
This allows CONFIG_ENV_ADDR to be a function but it does not have to, you also
lose a relocation entry as a static variable is removed.
Jocke
next prev parent reply other threads:[~2017-04-04 10:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-03 12:19 [U-Boot] Remove global variable env_t *env_ptr ? Joakim Tjernlund
2017-04-03 20:17 ` Wolfgang Denk
2017-04-04 8:17 ` Joakim Tjernlund
2017-04-04 10:29 ` Wolfgang Denk
2017-04-04 8:55 ` Lukasz Majewski
2017-04-04 10:24 ` Joakim Tjernlund
2017-04-04 10:31 ` Wolfgang Denk
2017-04-04 10:44 ` Joakim Tjernlund [this message]
2017-04-04 11:27 ` Wolfgang Denk
2017-04-04 13:21 ` Joakim Tjernlund
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=1491302640.30240.1.camel@infinera.com \
--to=joakim.tjernlund@infinera.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