barebox-state setup

barebox-state setup

[Andreas Wilhelm]

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";
>     backend-storage-type = "circular";
>     status = "okay";
>
>     myvar {
>        reg = <0x00 0x4>;
>        type = "enum32";
>        names = "N", "Y";
>        default = <0>;
>     };
> };

> &ecspi1 {
>    status = "okay";
>
>    flash: m25p80@0 {
>        status = "okay";
>
>        ...
>
>        partition@0 {
>            label = "barebox-state";
>            reg = <0x0 0x40000>;
>        };
>
>       ...
>    };
> };

Within the linux kernel I use the following configuration:

> state: state {                                                         
>     magic = <0x27031977>;                                          
>     compatible = "barebox,state";                                  
>     backend-type = "raw";                                          
>     backend = <&statepart>;                                        
>     backend-storage-type = "circular";                             
>                                                                     
>     myvar {                                              
>         reg = <0x00 0x4>;                                      
>         type = "enum32";                                       
>         names = "N", "Y";                                      
>         default = <0>;                                         
>     };
> };
>
> &ecspi1 {                                                                      
>     ...                                                    
>                                                                     
>     flash: m25p80@0 {                                                      
>         ...                                                   
>         status = "okay";                                               
>
>         statepart: partition@0 {                                       
>             label = "barebox-state";                               
>             reg = <0x0 0x40000>;                                   
>         };                                                             
>
>         ...
>     };                                                          
> };

I am not sure why the call to "device_find_block_device" in dt-utils/src/libdt.c (function of_get_devicepath) does not return a valid mtd device, as it correctly setuip by the kernel.

> # dmesg  | grep -i spi
> [    2.265675] m25p80 spi0.0: found n25q128a13, expected m25p80
> [    2.271446] m25p80 spi0.0: n25q128a13 (16384 Kbytes)
> [    2.276593] 2 ofpart partitions found on MTD device spi0.0
> [    2.282113] Creating 2 MTD partitions on "spi0.0":
> [    2.312512] spi_imx 2008000.ecspi: probed

> # grep -r mtdblock6 /sys/devices/
> /sys/devices/soc0/soc/2000000.aips-bus/2000000.spba-bus/2008000.ecspi/spi_master/spi0/spi0.0/mtd/mtd6/mtdblock6/uevent:DEVNAME=mtdblock6

Ideas, opinions ?

Best regards
Andreas

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

Re: barebox-state setup

[Sascha Hauer]

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

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

Re: barebox-state setup

[Andreas Wilhelm]

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

Re: barebox-state setup

[Sascha Hauer]

On Fri, May 05, 2017 at 03:52:22PM +0200, Andreas Wilhelm wrote:
> 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.

First of all, what storage device are you using? Is it a real flash or
some EEPROM or NVRAM?

> 
> 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 like a circular/noncircular mixup somewhere. Could you
hexdump the state partition (using the md command in barebox) to see if
the data is stored in circular or noncircular format? In circular format
you should see two copies of the same data directly after each other.

Also the output of barebox-state with -v might contain some useful
information.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

Re: barebox-state setup

[Andreas Wilhelm]

On 05/08/2017 02:18 PM, Sascha Hauer wrote:
> On Fri, May 05, 2017 at 03:52:22PM +0200, Andreas Wilhelm wrote:
>> 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.
> First of all, what storage device are you using? Is it a real flash or
> some EEPROM or NVRAM?
>
>> 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 like a circular/noncircular mixup somewhere. Could you
> hexdump the state partition (using the md command in barebox) to see if
> the data is stored in circular or noncircular format? In circular format
> you should see two copies of the same data directly after each other.
It is stored in messed up circular-format:

00000000: 77 19 03 27 00 00 0c 00 6f c6 d5 7b 01 54 26 49    w..'....o..{.T&I
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
00000020: 02 2d fa 14 28 00 00 00 77 19 03 27 00 00 0c 00    .-..(...w..'....
00000030: 0a a1 69 c3 9f 54 8c 85 00 00 00 00 00 00 00 00    ..i..T..........
00000040: 01 00 00 00 00 00 00 00 02 2d fa 14 28 00 00 00    .........-..(...
>
> Also the output of barebox-state with -v might contain some useful
> information.
>
> Sascha
>
>

adding DT alias:ethernet0: stem=ethernet id=0 node=/soc/aips-bus@02100000/ethernet@02188000
adding DT alias:can0: stem=can id=0 node=/soc/aips-bus@02000000/flexcan@02090000
adding DT alias:can1: stem=can id=1 node=/soc/aips-bus@02000000/flexcan@02094000
adding DT alias:gpio0: stem=gpio id=0 node=/soc/aips-bus@02000000/gpio@0209c000
adding DT alias:gpio1: stem=gpio id=1 node=/soc/aips-bus@02000000/gpio@020a0000
adding DT alias:gpio2: stem=gpio id=2 node=/soc/aips-bus@02000000/gpio@020a4000
adding DT alias:gpio3: stem=gpio id=3 node=/soc/aips-bus@02000000/gpio@020a8000
adding DT alias:gpio4: stem=gpio id=4 node=/soc/aips-bus@02000000/gpio@020ac000
adding DT alias:gpio5: stem=gpio id=5 node=/soc/aips-bus@02000000/gpio@020b0000
adding DT alias:gpio6: stem=gpio id=6 node=/soc/aips-bus@02000000/gpio@020b4000
adding DT alias:i2c0: stem=i2c id=0 node=/soc/aips-bus@02100000/i2c@021a0000
adding DT alias:i2c1: stem=i2c id=1 node=/soc/aips-bus@02100000/i2c@021a4000
adding DT alias:i2c2: stem=i2c id=2 node=/soc/aips-bus@02100000/i2c@021a8000
adding DT alias:mmc0: stem=mmc id=0 node=/soc/aips-bus@02100000/usdhc@02190000
adding DT alias:mmc1: stem=mmc id=1 node=/soc/aips-bus@02100000/usdhc@02194000
adding DT alias:mmc2: stem=mmc id=2 node=/soc/aips-bus@02100000/usdhc@02198000
adding DT alias:mmc3: stem=mmc id=3 node=/soc/aips-bus@02100000/usdhc@0219c000
adding DT alias:serial0: stem=serial id=0 node=/soc/aips-bus@02000000/spba-bus@02000000/serial@02020000
adding DT alias:serial1: stem=serial id=1 node=/soc/aips-bus@02100000/serial@021e8000
adding DT alias:serial2: stem=serial id=2 node=/soc/aips-bus@02100000/serial@021ec000
adding DT alias:serial3: stem=serial id=3 node=/soc/aips-bus@02100000/serial@021f0000
adding DT alias:serial4: stem=serial id=4 node=/soc/aips-bus@02100000/serial@021f4000
adding DT alias:spi0: stem=spi id=0 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@02008000
adding DT alias:spi1: stem=spi id=1 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@0200c000
adding DT alias:spi2: stem=spi id=2 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@02010000
adding DT alias:spi3: stem=spi id=3 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@02014000
adding DT alias:usbphy0: stem=usbphy id=0 node=/soc/aips-bus@02000000/usbphy@020c9000
adding DT alias:usbphy1: stem=usbphy id=1 node=/soc/aips-bus@02000000/usbphy@020ca000
adding DT alias:spi4: stem=spi id=4 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@02018000
adding DT alias:ipu0: stem=ipu id=0 node=/soc/ipu@02400000
adding DT alias:rtc1: stem=rtc id=1 node=/soc/aips-bus@02100000/i2c@021a8000/da9062@58/rtc
adding DT alias:rtc2: stem=rtc id=2 node=/soc/aips-bus@02000000/snvs@020cc000/snvs-rtc-lp@34
adding DT alias:rtc0: stem=rtc id=0 node=/soc/aips-bus@02100000/i2c@021a0000/rtc@68
adding DT alias:ipu1: stem=ipu id=1 node=/soc/ipu@02800000
found state node /state:
state {
        magic = <0x27031977>;
        compatible = "barebox,state";
        backend-type = "raw";
        backend = <0x71>;
        backend-storage-type = "circular";
        #address-cells = <0x1>;
        #size-cells = <0x1>;
        myval1 {
                type = "enum32";
                reg = <0x0 0x4>;
                names = "N", "Y";
        };
        myval2 {
                type = "enum32";
                reg = <0x4 0x4>;
                names = "A", "B";
        };
        myval3 {
                type = "enum32";
                reg = <0x8 0x4>;
                names = "D", "T", "B";
        };
};
state: Read state from -1204245760 length 0
state: Read state from -1204245760 length 65536
state: Read state from -1204245760 length 131072
state: New state registered 'state'
state: Read state from PEB 0 global offset 40 length 0
state: Read state from -1204245760 length 40
state: Read state from PEB 1 global offset 40 length 0
state: Read state from -1204245760 length 65576
state: Read state from PEB 2 global offset 40 length 0
state: Read state from -1204245760 length 131112
state: Using bucket 0@0x00000000

Could this be caused by the definition of #address-cells and #size_cells?

Best regards
Andreas

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

Re: barebox-state setup

[Andreas Wilhelm]

On 05/09/2017 10:26 AM, Andreas Wilhelm wrote:
> On 05/08/2017 02:18 PM, Sascha Hauer wrote:
>> On Fri, May 05, 2017 at 03:52:22PM +0200, Andreas Wilhelm wrote:
>>> 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.
>> First of all, what storage device are you using? Is it a real flash or
>> some EEPROM or NVRAM?
>>
>>> 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 like a circular/noncircular mixup somewhere. Could you
>> hexdump the state partition (using the md command in barebox) to see if
>> the data is stored in circular or noncircular format? In circular format
>> you should see two copies of the same data directly after each other.
> It is stored in messed up circular-format:
>
> 00000000: 77 19 03 27 00 00 0c 00 6f c6 d5 7b 01 54 26 49    w..'....o..{.T&I
> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 00000020: 02 2d fa 14 28 00 00 00 77 19 03 27 00 00 0c 00    .-..(...w..'....
> 00000030: 0a a1 69 c3 9f 54 8c 85 00 00 00 00 00 00 00 00    ..i..T..........
> 00000040: 01 00 00 00 00 00 00 00 02 2d fa 14 28 00 00 00    .........-..(...
>> Also the output of barebox-state with -v might contain some useful
>> information.
>>
>> Sascha
>>
>>
> adding DT alias:ethernet0: stem=ethernet id=0 node=/soc/aips-bus@02100000/ethernet@02188000
> adding DT alias:can0: stem=can id=0 node=/soc/aips-bus@02000000/flexcan@02090000
> adding DT alias:can1: stem=can id=1 node=/soc/aips-bus@02000000/flexcan@02094000
> adding DT alias:gpio0: stem=gpio id=0 node=/soc/aips-bus@02000000/gpio@0209c000
> adding DT alias:gpio1: stem=gpio id=1 node=/soc/aips-bus@02000000/gpio@020a0000
> adding DT alias:gpio2: stem=gpio id=2 node=/soc/aips-bus@02000000/gpio@020a4000
> adding DT alias:gpio3: stem=gpio id=3 node=/soc/aips-bus@02000000/gpio@020a8000
> adding DT alias:gpio4: stem=gpio id=4 node=/soc/aips-bus@02000000/gpio@020ac000
> adding DT alias:gpio5: stem=gpio id=5 node=/soc/aips-bus@02000000/gpio@020b0000
> adding DT alias:gpio6: stem=gpio id=6 node=/soc/aips-bus@02000000/gpio@020b4000
> adding DT alias:i2c0: stem=i2c id=0 node=/soc/aips-bus@02100000/i2c@021a0000
> adding DT alias:i2c1: stem=i2c id=1 node=/soc/aips-bus@02100000/i2c@021a4000
> adding DT alias:i2c2: stem=i2c id=2 node=/soc/aips-bus@02100000/i2c@021a8000
> adding DT alias:mmc0: stem=mmc id=0 node=/soc/aips-bus@02100000/usdhc@02190000
> adding DT alias:mmc1: stem=mmc id=1 node=/soc/aips-bus@02100000/usdhc@02194000
> adding DT alias:mmc2: stem=mmc id=2 node=/soc/aips-bus@02100000/usdhc@02198000
> adding DT alias:mmc3: stem=mmc id=3 node=/soc/aips-bus@02100000/usdhc@0219c000
> adding DT alias:serial0: stem=serial id=0 node=/soc/aips-bus@02000000/spba-bus@02000000/serial@02020000
> adding DT alias:serial1: stem=serial id=1 node=/soc/aips-bus@02100000/serial@021e8000
> adding DT alias:serial2: stem=serial id=2 node=/soc/aips-bus@02100000/serial@021ec000
> adding DT alias:serial3: stem=serial id=3 node=/soc/aips-bus@02100000/serial@021f0000
> adding DT alias:serial4: stem=serial id=4 node=/soc/aips-bus@02100000/serial@021f4000
> adding DT alias:spi0: stem=spi id=0 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@02008000
> adding DT alias:spi1: stem=spi id=1 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@0200c000
> adding DT alias:spi2: stem=spi id=2 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@02010000
> adding DT alias:spi3: stem=spi id=3 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@02014000
> adding DT alias:usbphy0: stem=usbphy id=0 node=/soc/aips-bus@02000000/usbphy@020c9000
> adding DT alias:usbphy1: stem=usbphy id=1 node=/soc/aips-bus@02000000/usbphy@020ca000
> adding DT alias:spi4: stem=spi id=4 node=/soc/aips-bus@02000000/spba-bus@02000000/ecspi@02018000
> adding DT alias:ipu0: stem=ipu id=0 node=/soc/ipu@02400000
> adding DT alias:rtc1: stem=rtc id=1 node=/soc/aips-bus@02100000/i2c@021a8000/da9062@58/rtc
> adding DT alias:rtc2: stem=rtc id=2 node=/soc/aips-bus@02000000/snvs@020cc000/snvs-rtc-lp@34
> adding DT alias:rtc0: stem=rtc id=0 node=/soc/aips-bus@02100000/i2c@021a0000/rtc@68
> adding DT alias:ipu1: stem=ipu id=1 node=/soc/ipu@02800000
> found state node /state:
> state {
>         magic = <0x27031977>;
>         compatible = "barebox,state";
>         backend-type = "raw";
>         backend = <0x71>;
>         backend-storage-type = "circular";
>         #address-cells = <0x1>;
>         #size-cells = <0x1>;
>         myval1 {
>                 type = "enum32";
>                 reg = <0x0 0x4>;
>                 names = "N", "Y";
>         };
>         myval2 {
>                 type = "enum32";
>                 reg = <0x4 0x4>;
>                 names = "A", "B";
>         };
>         myval3 {
>                 type = "enum32";
>                 reg = <0x8 0x4>;
>                 names = "D", "T", "B";
>         };
> };
> state: Read state from -1204245760 length 0
> state: Read state from -1204245760 length 65536
> state: Read state from -1204245760 length 131072
> state: New state registered 'state'
> state: Read state from PEB 0 global offset 40 length 0
> state: Read state from -1204245760 length 40
> state: Read state from PEB 1 global offset 40 length 0
> state: Read state from -1204245760 length 65576
> state: Read state from PEB 2 global offset 40 length 0
> state: Read state from -1204245760 length 131112
> state: Using bucket 0@0x00000000
>
> Could this be caused by the definition of #address-cells and #size_cells?
>
> Best regards
> Andreas
Hi,

> First of all, what storage device are you using? Is it a real flash or
> some EEPROM or NVRAM?

we are using an SPI NOR flash Micron N25Q128A13ESE40F. Are there any known issues with this kind of chips? And what could cause such behavior as shown above?

Best regards
Andreas

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

Re: barebox-state setup

[Sascha Hauer]

Hi Andreas,

On Mon, May 22, 2017 at 02:47:18PM +0200, Andreas Wilhelm wrote:
> 
> > First of all, what storage device are you using? Is it a real flash or
> > some EEPROM or NVRAM?
> 
> we are using an SPI NOR flash Micron N25Q128A13ESE40F. Are there any
> known issues with this kind of chips? And what could cause such
> behavior as shown above?

No, there is no known issue. I just wanted to know because real flashes
use the circular backend while EEPROMs use the direct backend.

I just posted a state example dtsi file which works on a Phytec phyFLEX
i.MX6 board. This also contains a SPI NOR flash and I just verified this
works fine on current master with dt-utils 2017.03.0. Maybe you could
compare this with your current setup and see if you find any
differences.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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