* barebox-state setup @ 2017-05-02 13:24 Andreas Wilhelm 2017-05-03 12:13 ` Sascha Hauer 0 siblings, 1 reply; 7+ messages in thread From: Andreas Wilhelm @ 2017-05-02 13:24 UTC (permalink / raw) To: barebox 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: barebox-state setup 2017-05-02 13:24 barebox-state setup Andreas Wilhelm @ 2017-05-03 12:13 ` Sascha Hauer 2017-05-05 13:52 ` Andreas Wilhelm 0 siblings, 1 reply; 7+ messages in thread From: Sascha Hauer @ 2017-05-03 12:13 UTC (permalink / raw) To: Andreas Wilhelm; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: barebox-state setup 2017-05-03 12:13 ` Sascha Hauer @ 2017-05-05 13:52 ` Andreas Wilhelm 2017-05-08 12:18 ` Sascha Hauer 0 siblings, 1 reply; 7+ messages in thread From: Andreas Wilhelm @ 2017-05-05 13:52 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: barebox-state setup 2017-05-05 13:52 ` Andreas Wilhelm @ 2017-05-08 12:18 ` Sascha Hauer 2017-05-09 8:26 ` Andreas Wilhelm 0 siblings, 1 reply; 7+ messages in thread From: Sascha Hauer @ 2017-05-08 12:18 UTC (permalink / raw) To: Andreas Wilhelm; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: barebox-state setup 2017-05-08 12:18 ` Sascha Hauer @ 2017-05-09 8:26 ` Andreas Wilhelm 2017-05-22 12:47 ` Andreas Wilhelm 0 siblings, 1 reply; 7+ messages in thread From: Andreas Wilhelm @ 2017-05-09 8:26 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: barebox-state setup 2017-05-09 8:26 ` Andreas Wilhelm @ 2017-05-22 12:47 ` Andreas Wilhelm 2017-05-23 8:01 ` Sascha Hauer 0 siblings, 1 reply; 7+ messages in thread From: Andreas Wilhelm @ 2017-05-22 12:47 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: barebox-state setup 2017-05-22 12:47 ` Andreas Wilhelm @ 2017-05-23 8:01 ` Sascha Hauer 0 siblings, 0 replies; 7+ messages in thread From: Sascha Hauer @ 2017-05-23 8:01 UTC (permalink / raw) To: Andreas Wilhelm; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-05-23 8:02 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-05-02 13:24 barebox-state setup Andreas Wilhelm 2017-05-03 12:13 ` Sascha Hauer 2017-05-05 13:52 ` Andreas Wilhelm 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox