[PATCH] pinctrl: mvebu: fix a comment about mv78460

It's pin mpp57 that has function vdd/cpu2-3-pd Signed-off-by: Uwe Kleine-König --- drivers/pinctrl/mvebu/armada-xp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/armada-xp.c b/drivers/pinctrl/mvebu/armada-xp.c index

Re: Loading kernel issues

ups... I think Ive broken everything... I just put at the end of the env/config file "boot nand" and now is looping and at some point it says "ERROR: out of memory". Another thing... I changed vivibootloader in NOR for the barebox, and even if I change to NOR it's looping again and again... What

[PATCH 2/2] mtd: nand: nand_mxs: Fix readtotal calculation

The calculation of readtotal must be bit alligend. If not the bch core finds bit flips in every page, because readtotal is too small. This bug was mostly introduced since commit "51061a9 mtd: nand: nand_mxs: Add subpage read support". Tested with: nand: NAND device: Manufacturer ID: 0x01, Chip

[PATCH 1/2] nand: imx6: Changed default NAND clock

From: Daniel Schultz The Barebox recognized false bad erase blocks while booting from a Spansion NAND (1). This error occurred due a to high clock. The Kernel sets the default NAND clock to 22Mhz. So, to fix this error and to be more identical with the Kernel, the Barebox

[PATCH] arm: Baltos: don't invoke baltos_read_eeprom in MLO

From: Yegor Yefremov EEPROM information is needed in barebox.bin in order to setup MACs and select appropriate DTB from kernel-fit.itb, so disable this initcall in MLO. Signed-off-by: Yegor Yefremov ---

Re: Loading kernel issues

Thank you very much maybe I just to put on /env/config a "boot nand" line... I'll try it. Regards 2016-10-20 11:13 GMT+02:00 Juergen Borleis : > Hi Javier, > > On Wednesday 19 October 2016 20:18:38 Javier Fileiv wrote: >> just in case...my /env/config as well >> [...] >

Re: Loading kernel issues

Hi Javier, On Wednesday 19 October 2016 20:18:38 Javier Fileiv wrote: > just in case...my /env/config as well > [...] Sorry, no idea. I do not even have the hardware anymore, so I cannot test it. Keep a look into the "env/bin/boot" script, what it tries to do with the configuration from your

[PATCH 1/3] state: pass error code instead of inventing new one

Both of_find_path() and of_find_path_by_node() return a meaningful error code, so forward it instead of inventing a new one. Do this especially for the -EPROBE_DEFER case which currently does not work. Signed-off-by: Sascha Hauer --- common/state/state.c | 7 --- 1

[PATCH 3/3] of_path: handle no driver for device

in __of_find_path it can happen that there is a device, but there is no driver for this device because it hasn't been probed yet. Return -ENODEV in this case to let the caller know that it has to try later again. Signed-off-by: Sascha Hauer --- drivers/of/of_path.c | 3

[PATCH 2/3] state: driver: handle EPROBE_DEFER

When state_new_from_node() returns -ENODEV that means that there is no device available for the node, so return -EPROBE_DEFER in this case and hope a device is there later. Signed-off-by: Sascha Hauer --- drivers/misc/state.c | 8 ++-- 1 file changed, 6