[PATCH] rtc-lib: drop unused rtc_ydays

[Antony Pavlov]

The patch fixes this compiler's warning:

drivers/rtc/rtc-lib.c:23:29: warning: ‘rtc_ydays’ defined but not used 
[-Wunused-const-variable=]
 static const unsigned short rtc_ydays[2][13] = {
 ^

Signed-off-by: Antony Pavlov 
---
 drivers/rtc/rtc-lib.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/rtc/rtc-lib.c b/drivers/rtc/rtc-lib.c
index 83d80455d..4a2d34fcf 100644
--- a/drivers/rtc/rtc-lib.c
+++ b/drivers/rtc/rtc-lib.c
@@ -20,13 +20,6 @@ static const unsigned char rtc_days_in_month[] = {
31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
 };
 
-static const unsigned short rtc_ydays[2][13] = {
-   /* Normal years */
-   { 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365 },
-   /* Leap years */
-   { 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 }
-};
-
 #define LEAPS_THRU_END_OF(y) ((y)/4 - (y)/100 + (y)/400)
 
 /*
-- 
2.11.0


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

[PATCH] state: Fix example in documentation

[Sascha Hauer]

The backend property must contain a phandle, so use a phandle
in the example.

Signed-off-by: Sascha Hauer 
---
 Documentation/devicetree/bindings/barebox/barebox,state.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/barebox/barebox,state.rst 
b/Documentation/devicetree/bindings/barebox/barebox,state.rst
index 06a0d100c8..40d7bc2e6f 100644
--- a/Documentation/devicetree/bindings/barebox/barebox,state.rst
+++ b/Documentation/devicetree/bindings/barebox/barebox,state.rst
@@ -84,7 +84,7 @@ Example::
magic = <0x27031977>;
compatible = "barebox,state";
backend-type = "raw";
-   backend = _part;
+   backend = <_part>;
 
foo {
reg = <0x00 0x4>;
-- 
2.11.0


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

Re: master breaks phytec-phycore-imx6ul

[Lucas Stach]

Am Dienstag, den 09.05.2017, 17:08 +0200 schrieb Stefan Riedmüller:
> Hi guys,
> 
> after applying the latest master patches barebox does not boot anymore on my 
> PHYTEC-phyCORE-i.MX6UL. It doesn't show any output. I was able to identify 
> the commit which seems to be responsible for this behavior.
> 
> It's 2c506afbadcd546dcc54a0e8599e454fd4aecfdc (ARM: i.MX50: Add support for 
> i.MX50 based Amazon Kindle e-book readers).
> 
> It is possible to make the board boot again by disabling System Type --> 
> CONFIG_MACH_KINDLE_MX50 (i.MX50 based Amazon Kindle 4 and 5) in the 
> menuconfig. This deactivates ARCH_IMX50. I also tested it on the 
> PHYTEC-phyCORE-i.MX6-Quad board and the Fresscale SabreSD board with i.MX6 
> Quad and found the same behavior. I could not find an explanation yet for 
> this so I hope you can help me.

The kindle initcalls are missing the compatibility checks, so they will
be executed on every machine on a multi-image build, which is wrong.

Regards,
Lucas


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

master breaks phytec-phycore-imx6ul

[Stefan Riedmüller]

Hi guys,

after applying the latest master patches barebox does not boot anymore on my 
PHYTEC-phyCORE-i.MX6UL. It doesn't show any output. I was able to identify the 
commit which seems to be responsible for this behavior.

It's 2c506afbadcd546dcc54a0e8599e454fd4aecfdc (ARM: i.MX50: Add support for 
i.MX50 based Amazon Kindle e-book readers).

It is possible to make the board boot again by disabling System Type --> 
CONFIG_MACH_KINDLE_MX50 (i.MX50 based Amazon Kindle 4 and 5) in the menuconfig. 
This deactivates ARCH_IMX50. I also tested it on the PHYTEC-phyCORE-i.MX6-Quad 
board and the Fresscale SabreSD board with i.MX6 Quad and found the same 
behavior. I could not find an explanation yet for this so I hope you can help 
me.

Mit freundlichen Grüßen,
Best regards,

Stefan Riedmüller


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

Re: Setting MAC address from nv variable broken in barebox 2017.05.0?

[Ian Abbott]

On 08/05/17 19:12, Sascha Hauer wrote:

On Mon, May 08, 2017 at 03:45:49PM +0100, Ian Abbott wrote:

On 08/05/17 14:39, Ian Abbott wrote:

Hi,

I'm not sure if this is a bug or whether I'm doing something wrong.  In
barebox 2017.04.0 and earlier, I stored the Ethernet MAC address in a
non-volatile ('nv') variable dev.eth0.macaddr=xx:xx:xx:xx:xx:xx and that
got propagated to 'global' and the eth0 device on boot:

barebox@:/ nv
  allow_color: true
  autoboot_timeout: 3
  dev.eth0.ethaddr: xx:xx:xx:xx:xx:xx
  user: none

[snip]

However, in 2017.05.0, my 'dev.eth0.ethaddr' variable is no longer being
propagated to global on boot, and as a consequence, is no longer
propagated to eth0 (note that 'dev.eth0.ethaddr' is the only nv variable
that I set manually when setting up a new board):

barebox@:/ devinfo eth0
Parameters:
  ethaddr: 00:00:00:00:00:00
  gateway: 0.0.0.0
  ipaddr: 0.0.0.0
  linux.bootargs:
  netmask: 0.0.0.0
  serverip: 0.0.0.0


[snip]

Is this the proper behaviour or a bug?  Could it be related to commit
35d8e858bea17ec4796069c9c27fd0b134125eaf ("nv: Do not create globalvars
from nvvars")?


As a related follow-up, this code in globalvar_add_simple() looks a bit
strange:

if (value)
dev_set_param(_device, name, value);

globalvar_nv_sync(name);


Ok, I think this should just be the other way round. Fixed in a patch I
just sent.


Yes, I thought that might be the case about it being the wrong way 
round.  I tested your patch and it works.


While on the subject, what is the desired behaviour when removing an nv 
variable?  Currently, removing an nv variable also deletes a global with 
the same name, even if the global has changed value in the meantime:


barebox@:/ global -r quux
barebox@:/ nv -r quux
barebox@:/ nv quux=foo
barebox@:/ global quux=bar
barebox@:/ nv -r quux
barebox@:/ global
  ... list of globals but 'quux' is missing ...

In 2017-04-0, the global variable remained, although its value was cleared.

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

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

Re: [PATCH v2 4/5] arm: boards: beaglebone: Delete default env

[Daniel Schultz]

Hi Sascha,

Am 08.05.2017 um 14:57 schrieb Sascha Hauer:

Hi Daniel,

On Fri, May 05, 2017 at 04:46:57PM +0200, Daniel Schultz wrote:

The Beaglebone environment should be set from outside with an application
specific environment.


I don't understand this. What are you trying to archieve and why?

I thought you prefer the bootloader spec way without a predefined 
environment, but maybe I just had misunderstood you. If so, I will only 
change the mount path of the boot partition.


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz


Sascha



Signed-off-by: Daniel Schultz 
---
 arch/arm/boards/beaglebone/Makefile | 1 -
 arch/arm/boards/beaglebone/board.c  | 2 --
 arch/arm/boards/beaglebone/defaultenv-beaglebone/boot/sd| 6 --
 .../arm/boards/beaglebone/defaultenv-beaglebone/init/usb-limit-1300 | 5 -
 4 files changed, 14 deletions(-)
 delete mode 100644 arch/arm/boards/beaglebone/defaultenv-beaglebone/boot/sd
 delete mode 100644 
arch/arm/boards/beaglebone/defaultenv-beaglebone/init/usb-limit-1300

diff --git a/arch/arm/boards/beaglebone/Makefile 
b/arch/arm/boards/beaglebone/Makefile
index 21a1a29..092c31d 100644
--- a/arch/arm/boards/beaglebone/Makefile
+++ b/arch/arm/boards/beaglebone/Makefile
@@ -1,3 +1,2 @@
 lwl-y += lowlevel.o
 obj-y += board.o
-bbenv-y += defaultenv-beaglebone
diff --git a/arch/arm/boards/beaglebone/board.c 
b/arch/arm/boards/beaglebone/board.c
index 5717c45..fc16aea 100644
--- a/arch/arm/boards/beaglebone/board.c
+++ b/arch/arm/boards/beaglebone/board.c
@@ -85,8 +85,6 @@ static int beaglebone_devices_init(void)

black = is_beaglebone_black();

-   defaultenv_append_directory(defaultenv_beaglebone);
-
globalvar_add_simple("board.variant", black ? "boneblack" : "bone");

printf("detected 'BeagleBone %s'\n", black ? "Black" : "White");
diff --git a/arch/arm/boards/beaglebone/defaultenv-beaglebone/boot/sd 
b/arch/arm/boards/beaglebone/defaultenv-beaglebone/boot/sd
deleted file mode 100644
index aa94b2f..000
--- a/arch/arm/boards/beaglebone/defaultenv-beaglebone/boot/sd
+++ /dev/null
@@ -1,6 +0,0 @@
-#!/bin/sh
-
-global.bootm.image=/boot/uImage
-global.bootm.oftree=/boot/oftree
-#global.bootm.initrd=
-global.linux.bootargs.dyn.root="root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
diff --git 
a/arch/arm/boards/beaglebone/defaultenv-beaglebone/init/usb-limit-1300 
b/arch/arm/boards/beaglebone/defaultenv-beaglebone/init/usb-limit-1300
deleted file mode 100644
index 56313bf..000
--- a/arch/arm/boards/beaglebone/defaultenv-beaglebone/init/usb-limit-1300
+++ /dev/null
@@ -1,5 +0,0 @@
-#!/bin/sh
-
-echo -n "changing USB current limit to 1300 mA... "
-i2c_write -b 0 -a 0x24 -r 0x01 0x3e
-echo "done"
--
1.9.1


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






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

Re: [PATCH] globalvar: Fix value of new globalvar when nvvar exists

[Ian Abbott]

On 08/05/17 19:10, Sascha Hauer wrote:

When a new globalvar with a value is created and the corresponding
nvvar exists, then the globalvar gets the value of the nvvar, not
from the newly assigned value as expected.

nv quux=foo; global quux=bar; echo ${global.quux}

Should give "bar", not "foo". Fix this.

Reported-by: Ian Abbott 
Signed-off-by: Sascha Hauer 
---
 common/globalvar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/globalvar.c b/common/globalvar.c
index c48e7df067..c528b24062 100644
--- a/common/globalvar.c
+++ b/common/globalvar.c
@@ -403,11 +403,11 @@ int globalvar_add_simple(const char *name, const char 
*value)
return PTR_ERR(param);
}

+   globalvar_nv_sync(name);
+
if (value)
dev_set_param(_device, name, value);

-   globalvar_nv_sync(name);
-
return 0;
 }


This seems to work.  Thanks.

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

___
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@0200/spba-bus@0200/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 = , "partname:barebox-state";
>>> Please use "backend = _state;" with a partition like this:
>>>
>>> barebox_state: partition@0 {
>>> reg = <0x0 0x4>;
>>> };
>>>
 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:

: 77 19 03 27 00 00 0c 00 6f c6 d5 7b 01 54 26 49w..'o..{.T
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 02 2d fa 14 28 00 00 00 77 19 03 27 00 00 0c 00.-..(...w..'
0030: 0a a1 69 c3 9f 54 8c 85 00 00 00 00 00 00 00 00..i..T..
0040: 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@0210/ethernet@02188000
adding DT alias:can0: stem=can id=0 node=/soc/aips-bus@0200/flexcan@0209
adding DT alias:can1: stem=can id=1 node=/soc/aips-bus@0200/flexcan@02094000
adding DT alias:gpio0: stem=gpio id=0 node=/soc/aips-bus@0200/gpio@0209c000
adding DT alias:gpio1: stem=gpio id=1 node=/soc/aips-bus@0200/gpio@020a
adding DT alias:gpio2: stem=gpio id=2 node=/soc/aips-bus@0200/gpio@020a4000
adding DT alias:gpio3: stem=gpio id=3 node=/soc/aips-bus@0200/gpio@020a8000
adding DT alias:gpio4: stem=gpio id=4 node=/soc/aips-bus@0200/gpio@020ac000
adding DT alias:gpio5: stem=gpio id=5 node=/soc/aips-bus@0200/gpio@020b
adding DT alias:gpio6: stem=gpio id=6 node=/soc/aips-bus@0200/gpio@020b4000
adding DT alias:i2c0: stem=i2c id=0 node=/soc/aips-bus@0210/i2c@021a
adding DT alias:i2c1: stem=i2c id=1 node=/soc/aips-bus@0210/i2c@021a4000
adding DT alias:i2c2: stem=i2c id=2 node=/soc/aips-bus@0210/i2c@021a8000
adding DT alias:mmc0: stem=mmc id=0 

Re: [PATCH] PPC: request a consistent memory layout

[Juergen Borleis]

Hi Sascha,

On Tuesday 09 May 2017 07:40:31 Sascha Hauer wrote:
> [...]
> This files doesn't exist in master. Could you rebase on a current tree?

Arghh, sorry. V2 sent.

jb

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

[PATCH v2] PPC: request a consistent memory layout

[Juergen Borleis]

Using the memory test command will crash barebox, because it tests the
area where the stack is located for the PPC architecture.

On PPC the stack is below the barebox binary. Below the stack the malloc
area is located. Until this change some routines used the macros
from 'memory_layout.h', some other calculated their values by their
own - which resulted into an unrequested and unprotected stack area.

Signed-off-by: Juergen Borleis 
---
 arch/ppc/mach-mpc5xxx/Kconfig |  1 -
 arch/ppc/mach-mpc5xxx/cpu.c   | 18 ++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/ppc/mach-mpc5xxx/Kconfig b/arch/ppc/mach-mpc5xxx/Kconfig
index 1ecce3a56..180aa32ad 100644
--- a/arch/ppc/mach-mpc5xxx/Kconfig
+++ b/arch/ppc/mach-mpc5xxx/Kconfig
@@ -32,7 +32,6 @@ config ARCH_MPC5200
 config MPC5xxx
bool
depends on MACH_PHYCORE_MPC5200B_TINY
-   select HAVE_CONFIGURABLE_MEMORY_LAYOUT
default y
 
 menu "Board specific settings"
diff --git a/arch/ppc/mach-mpc5xxx/cpu.c b/arch/ppc/mach-mpc5xxx/cpu.c
index 42ced9ac5..ab58967aa 100644
--- a/arch/ppc/mach-mpc5xxx/cpu.c
+++ b/arch/ppc/mach-mpc5xxx/cpu.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 int checkcpu (void)
 {
@@ -60,6 +62,22 @@ int checkcpu (void)
 
 /* - */
 
+static int mpc5xxx_reserve_region(void)
+{
+   struct resource *r;
+
+   /* keep this in sync with the assembler routines setting up the stack */
+   r = request_sdram_region("stack", _text_base - STACK_SIZE, STACK_SIZE);
+   if (r == NULL) {
+   pr_err("Failed to request stack region at: 0x%08lx/0x%08lx\n",
+   _text_base - STACK_SIZE, _text_base - 1);
+   return -EBUSY;
+   }
+
+   return 0;
+}
+coredevice_initcall(mpc5xxx_reserve_region);
+
 static void __noreturn mpc5xxx_restart_soc(struct restart_handler *rst)
 {
ulong msr;
-- 
2.11.0


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