[U-Boot] Intent of CONFIG_NAND_ENV_DST?

[U-Boot] Intent of CONFIG_NAND_ENV_DST?

[Tom Rini]

Hey all,

I'm attempting to use CONFIG_NAND_ENV_DST work, and I'm wondering it
what I see as the intent of the option is the real intent as it's not
working without patches, but perhaps I'm just using it wrong.  What
I'm trying to have done is that if the above is set, SPL will read the
environment from NAND into CONFIG_NAND_ENV_DST (nand_spl/ code does
this, today) and once U-Boot itself is fired up, env_init will see
we've been given a real environment and go.  But what happens now is
that there's no special case of env_relocate_spec that knows our
current pointer is fine and just needs to populate the table.

When I asked Wolfgang on IRC, he mentioned the embedded into the
U-Boot image trick, but I don't want to go down that path as it bloats
the image size (and in this case, U-Boot supports both a NAND-sporting
EVM and the NAND-less BeagleBone, and we don't want to add all that
padding and extra space to the Bone image).

Thanks!

-- 
Tom

[U-Boot] Intent of CONFIG_NAND_ENV_DST?

[Scott Wood]

On 12/19/2011 11:58 AM, Tom Rini wrote:
> Hey all,
> 
> I'm attempting to use CONFIG_NAND_ENV_DST work, and I'm wondering it
> what I see as the intent of the option is the real intent as it's not
> working without patches, but perhaps I'm just using it wrong.  What
> I'm trying to have done is that if the above is set, SPL will read the
> environment from NAND into CONFIG_NAND_ENV_DST (nand_spl/ code does
> this, today) and once U-Boot itself is fired up, env_init will see
> we've been given a real environment and go.  But what happens now is
> that there's no special case of env_relocate_spec that knows our
> current pointer is fine and just needs to populate the table.

Hmm... so it will unnecessarily reread the environment, discarding any
variables that have been modified before then.  That should be fixed (I
think we just need to add CONFIG_NAND_ENV_DST to the ENV_IS_EMBEDDED
ifdef in env_relocate_spec, as was done in env_init), though the primary
intent was simply to get early read access to variables such as serial
baud -- for that, it should already work, right?

-Scott

[U-Boot] Intent of CONFIG_NAND_ENV_DST?

[Tom Rini]

On Mon, Dec 19, 2011 at 11:57 AM, Scott Wood <scottwood@freescale.com> wrote:
> On 12/19/2011 11:58 AM, Tom Rini wrote:
>> Hey all,
>>
>> I'm attempting to use CONFIG_NAND_ENV_DST work, and I'm wondering it
>> what I see as the intent of the option is the real intent as it's not
>> working without patches, but perhaps I'm just using it wrong. ?What
>> I'm trying to have done is that if the above is set, SPL will read the
>> environment from NAND into CONFIG_NAND_ENV_DST (nand_spl/ code does
>> this, today) and once U-Boot itself is fired up, env_init will see
>> we've been given a real environment and go. ?But what happens now is
>> that there's no special case of env_relocate_spec that knows our
>> current pointer is fine and just needs to populate the table.
>
> Hmm... so it will unnecessarily reread the environment, discarding any
> variables that have been modified before then. ?That should be fixed (I
> think we just need to add CONFIG_NAND_ENV_DST to the ENV_IS_EMBEDDED
> ifdef in env_relocate_spec, as was done in env_init), though the primary
> intent was simply to get early read access to variables such as serial
> baud -- for that, it should already work, right?

It should be working for that use case, yes.  I'll give things a shot
with just or'ing in on the existing ENV_IS_EMBEDDED case and report
back.

-- 
Tom