mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Andreas Wilhelm <andreas.wilhelm@emlix.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: barebox-state setup
Date: Fri, 5 May 2017 15:52:22 +0200	[thread overview]
Message-ID: <9d5f2e1b-c065-8969-14fb-3cf309b580d9@emlix.com> (raw)
In-Reply-To: <20170503121324.qguy2tsch7gepob7@pengutronix.de>

On 05/03/2017 02:13 PM, Sascha Hauer wrote:
> On Tue, May 02, 2017 at 03:24:10PM +0200, Andreas Wilhelm wrote:
>> Hello,
>>
>> I am using barebox state to exchange data between barebox and linux. From barebox I can access and change the state without any problems. If I try to access the state using the barebox-state util included with dt-utils (v2017.03.0), I get the following error:
>>
>>> # barebox-state -g myvar
>>> of_get_devicepath: no 'label' property found in /soc/aips-bus@02000000/spba-bus@02000000/ecspi@02008000/m25p80@0
>>> Cannot find backend path in /state
>> This problem does not occur when using version 2016.08.0 of dt-utils. However, in this version I experienced an other problem. Even with backend-storage-type set to "circular" barebox attempted to storte data in "direct" mode:
>>
>>> WARNING, no stridesize given although we use a direct file
>>> write. Starting in degraded mode
>>> Failed to initialize desired amount of direct buckets, only 1 of 3
>>> succeeded
>> Furthermore changing the state from within barebox worked just fine, while changing it using dt-utils from within a booted linux didn't.
>>
>> The barebox state is stored in NOR-flash and configured in barebox as followed:
>>
>>> state: state {
>>>     magic = <0x27031977>;
>>>     compatible = "barebox,state";
>>>     backend-type = "raw";
>>>     backend = &flash, "partname:barebox-state";
> Please use "backend = &barebox_state;" with a partition like this:
>
> barebox_state: partition@0 {
> 	reg = <0x0 0x40000>;
> };
>
>> Within the linux kernel I use the following configuration
> Note that barebox will rewrite the state node in the device tree passed
> to Linux to make sure that both are consistent. You do not need to add a
> state node to the Linux device tree manually. Unfortunately the
> rewriting of the device node does not work correctly if you use the
> "partname:" binding above in barebox.
>
> Sascha
>
Thanks for your fast reply.

Removing the state definition from the linux device tree and changing the backend definition stopped barebox and dt-utils from complaining about a bad state backend. However, now I am facing a strange error.

I am able to read and change the barebox state from within barebox and changes are reflected when reading from within barebox and linux. When changing the state using dt-utils, the change is persistent between reboots, but cannot be seen from within barebox.

Example:

// State myvar initialized with A by default

state.myvar=B; state -s
=> Barebox: echo $state.myvar // myvar=B
=> Linux: barebox-state -g myvar // myvar=B

barebox-state -s myvar=C
=> Barebox: echo $state.myvar // myvar=B
=> Linux: barebox-state -g myvar // myvar=C

This looks to me like dt-utils reading and writing only one of the state copies, while the barebox internal code maintains all copies.

Ideas, opinions ?

Best regards
Andreas

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2017-05-05 13:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-02 13:24 Andreas Wilhelm
2017-05-03 12:13 ` Sascha Hauer
2017-05-05 13:52   ` Andreas Wilhelm [this message]
2017-05-08 12:18     ` Sascha Hauer
2017-05-09  8:26       ` Andreas Wilhelm
2017-05-22 12:47         ` Andreas Wilhelm
2017-05-23  8:01           ` Sascha Hauer

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=9d5f2e1b-c065-8969-14fb-3cf309b580d9@emlix.com \
    --to=andreas.wilhelm@emlix.com \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.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