Set variable in redundant u-boot environment

[Robert Fritzsche]

Greetings,

It looks like that you have to call fw_setenv twice to set variables in the second, redundant, u-boot environment block. Somehow fw_setenv silently failed for me, and u-boot selects now the second environment.

Despite the fact that my memory has bad blocks. Would it make sense to call fw_setenv for every u-boot environment block in mender? I am not an u-boot expert. I just observed via strace that fw_setenv seeks to a different address on the second call. Please let me know if this makes sense to you.

Cheers,

Robert

--

Robert Fritzsche
Technical Lead
gridX GmbH
p:
+49 (0) 241 412 597 10
a:
gridX |  Noppiusstraße 12 | 52062 Aachen
w:
www.gridX.de  e: r.fri...@gridX.de
 
> Digitaler Ökostrom von gridX <

Sitz der Gesellschaft: Aachen | Registergericht: Amtsgericht Aachen | Registernummer: HRB 20494
Geschäftsführer: David Balensiefen | Andreas Booke
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

[Mirza Krak]

On 5 May 2018 at 17:35, Robert Fritzsche <r.fri...@gridx.de> wrote:

Greetings,

Greetings.

 

It looks like that you have to call fw_setenv twice to set variables in the second, redundant, u-boot environment block. Somehow fw_setenv silently failed for me, and u-boot selects now the second environment.

Despite the fact that my memory has bad blocks. Would it make sense to call fw_setenv for every u-boot environment block in mender? I am not an u-boot expert. I just observed via strace that fw_setenv seeks to a different address on the second call. Please let me know if this makes sense to you.

What you are describing, sounds like what is expected of fw_setenv. Will try and explain what it expected :).

fw_setenv has two copies of the environment (when redundant is enabled, which it is if you integrated with Mender). This layout is very similar to the A/B update strategy that Mender uses to do software updates.

This means that you always have one active U-boot environment, and one inactive. The environment is a "chunk" of data, which means that when you update ONE variable you re-write the whole environment containing your change.

So when you update a variable with fw_setenv you always update the inactive environment "chunk" (copies current active + your change), and that then becomes your active one. And keeps on going back and forth like this for every update. So it is not strange that "the second area" is you current environment.

This also means if you current active environment for some reason is corrupted it will go back using the previous one. 

Hope this cleared it up a bit :)

--

Med Vänliga Hälsningar / Best Regards

Mirza Krak

[Raghav Maheshwari]

Thank you for the help.
The theory helped me clear my concepts, but I am still unable to put it down to coding.
Could you please help what changes should I do to my code ?

Regards.
Raghav.

[Robert Fritzsche]

I see, thanks Mirza for the explanation.

Do you also know why fw_setenv succeeded and why I could use fw_printenv to display my changes to the environment block, but u-boot silently selected the other block? Is there a CRC to confirm from Linux that the environment block is OK?

@Raghav what implementation do you mean?

Cheers!

Robert

--
You received this message because you are subscribed to the Google Groups "Mender List mender.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mender+un...@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.
Visit this group at https://groups.google.com/a/lists.mender.io/group/mender/.

[Kristian Amlie]

On 07/05/18 08:24, Robert Fritzsche wrote:
> I see, thanks Mirza for the explanation.
>
> Do you also know why fw_setenv succeeded and why I could use fw_printenv
> to display my changes to the environment block, but u-boot silently
> selected the other block? Is there a CRC to confirm from Linux that the
> environment block is OK?

Are you sure that the environment is correctly detected by U-Boot at
all? This sounds more like the environment is not detected, and U-Boot
instead falls back to its read-only default copy. Does any change you
make get detected by U-Boot?

It should not be completely silent if what I described is happening,
there should be a message about the CRC being wrong.

--
Kristian

[Robert Fritzsche]

Hi Kristian,

yes if I call fw_setenv twice I can change the environment. Also if I do the changes from the u-boot command prompt.

I have seen the CRC environment warning in other setups before but not here, unfortunately. There are no warnings when u-boot starts-up.

Cheers!

Robert

[Kristian Amlie]

On 08/05/18 09:57, Robert Fritzsche wrote:
> Hi Kristian,
>
> yes if I call fw_setenv twice I can change the environment. Also if I do
> the changes from the u-boot command prompt.
>
> I have seen the CRC environment warning in other setups before but not
> here, unfortunately. There are no warnings when u-boot starts-up.

The only thing I can think of is that U-boot and the fw_setenv tool
disagree on whether the environment is redundant or not. For example,
this could result if U-Boot is not configured for a redundant
environment, and fw_setenv is. Then it makes sense that calling it twice
would fix the problem, because the first time around it edits the second
copy, which U-Boot doesn't know about, and the second time it edits the
copy they both share.

Make sure that the settings in /etc/fw_env.config are reflected in the
compile options for U-Boot, particularly the
CONFIG_SYS_REDUNDAND_ENVIRONMENT define (which should be on), and the
CONFIG_ENV_OFFSET_REDUND define (which should match the second address
in /etc/fw_env.config). Unfortunately there is no easy way to see this
AFAIK, so you will have to use the 'bitbake -c devshell u-boot' option
in Yocto to get a shell prompt, and then play with 'make
KBUILD_VERBOSE=1' and 'gcc -E' to see the defines that are active.

--
Kristian

>
> Kristian Amlie <kristia...@northern.tech> schrieb am Mo., 7. Mai
> 2018 um 08:36 Uhr:
>
> On 07/05/18 08:24, Robert Fritzsche wrote:
> > I see, thanks Mirza for the explanation.
> >
> > Do you also know why fw_setenv succeeded and why I could use
> fw_printenv
> > to display my changes to the environment block, but u-boot silently
> > selected the other block? Is there a CRC to confirm from Linux
> that the
> > environment block is OK?
>
> Are you sure that the environment is correctly detected by U-Boot at
> all? This sounds more like the environment is not detected, and U-Boot
> instead falls back to its read-only default copy. Does any change you
> make get detected by U-Boot?
>
> It should not be completely silent if what I described is happening,
> there should be a message about the CRC being wrong.
>
> --
> Kristian
>
> --
>
>

> Robert Fritzsche
> Technical Lead
> *gridX GmbH*

> p: +49 (0) 241 412 597 10
> a: gridX |  Noppiusstraße 12 | 52062 Aachen

> <https://maps.google.com/?q=Noppiusstra%C3%9Fe+12+%7C+52062+Aachen&entry=gmail&source=g>
> w: www.gridX.de <http://www.gridx.de/>  e: r.fri...@gridX.de
> <mailto:r.fri...@gridX.de>
>  
>> Digitaler Ökostrom von gridX < <https://gridx.de/tarifrechner>

>
>
> Sitz der Gesellschaft: Aachen | Registergericht: Amtsgericht Aachen |
> Registernummer: HRB 20494
> Geschäftsführer: David Balensiefen | Andreas Booke
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
> E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
> Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
> die unbefugte Weitergabe dieser Mail ist nicht gestattet.
> This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>

> --
> You received this message because you are subscribed to the Google
> Groups "Mender List mender.io" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mender+un...@lists.mender.io

> <mailto:mender+un...@lists.mender.io>.

> To post to this group, send email to men...@lists.mender.io

> <mailto:men...@lists.mender.io>.