[PATCH] nvmem: bsec: fix typo in function name (s/st32/stm32/)

2019-11-14 Thread Ahmad Fatoum
A m was missing. Reinstate it.

Signed-off-by: Ahmad Fatoum 
---
 drivers/nvmem/bsec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/nvmem/bsec.c b/drivers/nvmem/bsec.c
index 8235d468d16d..d772d0b7af92 100644
--- a/drivers/nvmem/bsec.c
+++ b/drivers/nvmem/bsec.c
@@ -57,7 +57,7 @@ static int bsec_smc(struct bsec_priv *priv, u8 op, enum 
bsec_field field,
return -ENXIO;
 }
 
-static int st32_bsec_read_shadow(void *ctx, unsigned reg, unsigned *val)
+static int stm32_bsec_read_shadow(void *ctx, unsigned reg, unsigned *val)
 {
return bsec_smc(ctx, BSEC_SMC_READ_SHADOW, reg, 0, val);
 }
@@ -69,7 +69,7 @@ static int stm32_bsec_reg_write_shadow(void *ctx, unsigned 
reg, unsigned val)
 
 static struct regmap_bus stm32_bsec_regmap_bus = {
.reg_write = stm32_bsec_reg_write_shadow,
-   .reg_read = st32_bsec_read_shadow,
+   .reg_read = stm32_bsec_read_shadow,
 };
 
 static int stm32_bsec_write(struct device_d *dev, int offset,
-- 
2.20.1


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


[PATCH 07/10] ARM: stm32mp: add helper for querying ram size

2019-11-12 Thread Ahmad Fatoum
The STM32MP DDR Controller has a very flexible way of mapping address
bits to columns/rows/banks. This is so far configured by the ARM TF-A
as part of the SDRAM setup, so we don't need to do this in barebox.

Nevertheless reading it out in barebox, allows us to determine unused
address bits and thus the total size of SDRAM configured.
Add a barebox_arm_entry wrapper that computes the SDRAM size internally,
so boards may drop their hard-coded RAM size specifications.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/mach-stm32mp/Makefile|   1 +
 arch/arm/mach-stm32mp/ddrctrl.c   | 121 ++
 arch/arm/mach-stm32mp/include/mach/ddr_regs.h | 368 ++
 arch/arm/mach-stm32mp/include/mach/entry.h|   8 +
 arch/arm/mach-stm32mp/include/mach/stm32.h|   2 +
 5 files changed, 500 insertions(+)
 create mode 100644 arch/arm/mach-stm32mp/ddrctrl.c
 create mode 100644 arch/arm/mach-stm32mp/include/mach/ddr_regs.h
 create mode 100644 arch/arm/mach-stm32mp/include/mach/entry.h

diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
index 6f495288923a..8e14b225359d 100644
--- a/arch/arm/mach-stm32mp/Makefile
+++ b/arch/arm/mach-stm32mp/Makefile
@@ -1,2 +1,3 @@
 obj-y := init.o
+obj-pbl-y := ddrctrl.o
 obj-$(CONFIG_BOOTM) += stm32image.o
diff --git a/arch/arm/mach-stm32mp/ddrctrl.c b/arch/arm/mach-stm32mp/ddrctrl.c
new file mode 100644
index ..90fb5e8956d0
--- /dev/null
+++ b/arch/arm/mach-stm32mp/ddrctrl.c
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Ahmad Fatoum 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADDRMAP1_BANK_B0   GENMASK( 5,  0)
+#define ADDRMAP1_BANK_B1   GENMASK(13,  8)
+#define ADDRMAP1_BANK_B2   GENMASK(21, 16)
+
+#define ADDRMAP2_COL_B2GENMASK( 3,  0)
+#define ADDRMAP2_COL_B3GENMASK(11,  8)
+#define ADDRMAP2_COL_B4GENMASK(19, 16)
+#define ADDRMAP2_COL_B5GENMASK(27, 24)
+
+#define ADDRMAP3_COL_B6GENMASK( 3,  0)
+#define ADDRMAP3_COL_B7GENMASK(12,  8)
+#define ADDRMAP3_COL_B8GENMASK(20, 16)
+#define ADDRMAP3_COL_B9GENMASK(28, 24)
+
+#define ADDRMAP4_COL_B10   GENMASK( 4,  0)
+#define ADDRMAP4_COL_B11   GENMASK(12,  8)
+
+#define ADDRMAP5_ROW_B0GENMASK( 3,  0)
+#define ADDRMAP5_ROW_B1GENMASK(11,  8)
+#define ADDRMAP5_ROW_B2_10 GENMASK(19, 16)
+#define ADDRMAP5_ROW_B11   GENMASK(27, 24)
+
+#define ADDRMAP6_ROW_B12   GENMASK( 3,  0)
+#define ADDRMAP6_ROW_B13   GENMASK(11,  8)
+#define ADDRMAP6_ROW_B14   GENMASK(19, 16)
+#define ADDRMAP6_ROW_B15   GENMASK(27, 24)
+
+#define ADDRMAP9_ROW_B2GENMASK( 3,  0)
+#define ADDRMAP9_ROW_B3GENMASK(11,  8)
+#define ADDRMAP9_ROW_B4GENMASK(19, 16)
+#define ADDRMAP9_ROW_B5GENMASK(27, 24)
+
+#define ADDRMAP10_ROW_B6   GENMASK( 3,  0)
+#define ADDRMAP10_ROW_B7   GENMASK(11,  8)
+#define ADDRMAP10_ROW_B8   GENMASK(19, 16)
+#define ADDRMAP10_ROW_B9   GENMASK(27, 24)
+
+#define ADDRMAP11_ROW_B10  GENMASK( 3, 0)
+
+#define LINE_UNUSED(reg, mask) (((reg) & (mask)) == (mask))
+
+enum ddrctrl_buswidth {
+   BUSWIDTH_FULL = 0,
+   BUSWIDTH_HALF = 1,
+   BUSWIDTH_QUARTER = 2
+};
+
+static unsigned long ddrctrl_addrmap_ramsize(struct stm32mp1_ddrctl __iomem *d,
+enum ddrctrl_buswidth buswidth)
+{
+   unsigned banks = 3, cols = 12, rows = 16;
+   u32 reg;
+
+   cols += buswidth;
+
+   reg = readl(>addrmap1);
+   if (LINE_UNUSED(reg, ADDRMAP1_BANK_B2)) banks--;
+   if (LINE_UNUSED(reg, ADDRMAP1_BANK_B1)) banks--;
+   if (LINE_UNUSED(reg, ADDRMAP1_BANK_B0)) banks--;
+
+   reg = readl(>addrmap2);
+   if (LINE_UNUSED(reg, ADDRMAP2_COL_B5)) cols--;
+   if (LINE_UNUSED(reg, ADDRMAP2_COL_B4)) cols--;
+   if (LINE_UNUSED(reg, ADDRMAP2_COL_B3)) cols--;
+   if (LINE_UNUSED(reg, ADDRMAP2_COL_B2)) cols--;
+
+   reg = readl(>addrmap3);
+   if (LINE_UNUSED(reg, ADDRMAP3_COL_B9)) cols--;
+   if (LINE_UNUSED(reg, ADDRMAP3_COL_B8)) cols--;
+   if (LINE_UNUSED(reg, ADDRMAP3_COL_B7)) cols--;
+   if (LINE_UNUSED(reg, ADDRMAP3_COL_B6)) cols--;
+
+   reg = readl(>addrmap4);
+   if (LINE_UNUSED(reg, ADDRMAP4_COL_B11)) cols--;
+   if (LINE_UNUSED(reg, ADDRMAP4_COL_B10)) cols--;
+
+   reg = readl(>addrmap5);
+   if (LINE_UNUSED(reg, ADDRMAP5_ROW_B11)) rows--;
+
+   reg = readl(>addrmap6);
+   if (LINE_UNUSED(reg, ADDRMAP6_ROW_B15)) rows--;
+   if (LINE_UNUSED(reg, ADDRMAP6_ROW_B14)) rows--;
+   if (LINE_UNUSED(reg, ADDRMAP6_ROW_B13)) rows--;
+   if (LINE_UNUSED(reg, ADDRMAP6_ROW_B12)) rows--;
+
+   return memory_sdram_size(cols, rows, BIT(banks), 4 / BIT(bu

[PATCH 04/10] watchdog: stm32_iwdg: return -ENOSYS on attempt to disable

2019-11-12 Thread Ahmad Fatoum
The stm32_iwdg watchdog can't be disabled. To have the wd commant report
this fact correctly to the user, the ->set_timeout needs to return -ENOSYS
which is interpreted as "Watchdog cannot be disabled" instead of -EINVAL
which means "Timeout value out of range".

Signed-off-by: Ahmad Fatoum 
---
 drivers/watchdog/stm32_iwdg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index 4d252e558c32..808d7c83720e 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -132,7 +132,7 @@ static int stm32_iwdg_set_timeout(struct watchdog *wdd, 
unsigned int timeout)
int ret;
 
if (!timeout)
-   return -EINVAL; /* can't disable */
+   return -ENOSYS; /* can't disable */
 
if (timeout > wdd->timeout_max)
return -EINVAL;
-- 
2.24.0.rc1


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


[PATCH 10/10] ARM: stm32mp: dk2: don't hard-code memory size

2019-11-12 Thread Ahmad Fatoum
There's new infrastructure for runtime determining RAM size. Use it so
we don't need to hard code it in PBL and board code.

Because this new infrastructure has some nested function calls, my
arm-v7a-linux-gnueabihf-gcc 9.2.1 (OSELAS.Toolchain-2019.09.0)
spills to the stack.  Add stm32mp_cpu_lowlevel_init, which also sets up
a stack after barebox end so this works.

Lastly, there's no upstream device tree node for the DDR controller.
Add one in the barebox device tree, so we don't have to hardcode the
DDRCTRL address into non-pbl code that's run everywhere.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/boards/stm32mp157c-dk2/board.c| 11 ---
 arch/arm/boards/stm32mp157c-dk2/lowlevel.c |  8 +++-
 arch/arm/dts/stm32mp157c.dtsi  |  7 +++
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boards/stm32mp157c-dk2/board.c 
b/arch/arm/boards/stm32mp157c-dk2/board.c
index f15ae0b4aff0..9cd5b4ee1ff4 100644
--- a/arch/arm/boards/stm32mp157c-dk2/board.c
+++ b/arch/arm/boards/stm32mp157c-dk2/board.c
@@ -6,17 +6,6 @@
 #include 
 #include 
 
-static int dk2_mem_init(void)
-{
-   if (!of_machine_is_compatible("st,stm32mp157c-dk2"))
-   return 0;
-
-   arm_add_mem_device("ram0", STM32_DDR_BASE, SZ_512M);
-
-   return 0;
-}
-mem_initcall(dk2_mem_init);
-
 static int dk2_postcore_init(void)
 {
if (!of_machine_is_compatible("st,stm32mp157c-dk2"))
diff --git a/arch/arm/boards/stm32mp157c-dk2/lowlevel.c 
b/arch/arm/boards/stm32mp157c-dk2/lowlevel.c
index 2106eaadc93a..7261d7a8bc58 100644
--- a/arch/arm/boards/stm32mp157c-dk2/lowlevel.c
+++ b/arch/arm/boards/stm32mp157c-dk2/lowlevel.c
@@ -1,8 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 #include 
-#include 
-#include 
-#include 
+#include 
 #include 
 
 extern char __dtb_z_stm32mp157c_dk2_start[];
@@ -17,12 +15,12 @@ ENTRY_FUNCTION(start_stm32mp157c_dk2, r0, r1, r2)
 {
void *fdt;
 
-   arm_cpu_lowlevel_init();
+   stm32mp_cpu_lowlevel_init();
 
if (IS_ENABLED(CONFIG_DEBUG_LL))
setup_uart();
 
fdt = __dtb_z_stm32mp157c_dk2_start + get_runtime_offset();
 
-   barebox_arm_entry(STM32_DDR_BASE, SZ_512M, fdt);
+   stm32mp1_barebox_entry(fdt);
 }
diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
index decb4ab6d5c4..bd2aabe6343a 100644
--- a/arch/arm/dts/stm32mp157c.dtsi
+++ b/arch/arm/dts/stm32mp157c.dtsi
@@ -24,6 +24,13 @@
psci {
compatible = "arm,psci-0.2";
};
+
+   soc {
+   memory-controller@5a003000 {
+   compatible = "st,stm32-ddrctrl";
+   reg = <0x5a003000 0x1000>;
+   };
+   };
 };
 
  {
-- 
2.24.0.rc1


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


[PATCH 03/10] mfd: stpmic1: use register define from header

2019-11-12 Thread Ahmad Fatoum
A previous commit has copied over the upstream 
header. Use it instead of replicating register definitions in the
MFD and watchdog cell driver. No functional change.

Signed-off-by: Ahmad Fatoum 
---
 drivers/mfd/stpmic1.c  |  3 +--
 drivers/watchdog/stpmic1_wdt.c | 28 
 2 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/drivers/mfd/stpmic1.c b/drivers/mfd/stpmic1.c
index eae6fe3a4e05..ab13ded0ecfe 100644
--- a/drivers/mfd/stpmic1.c
+++ b/drivers/mfd/stpmic1.c
@@ -12,8 +12,7 @@
 #include 
 #include 
 #include 
-
-#define VERSION_SR 0x6
+#include 
 
 struct stpmic1 {
struct device_d *dev;
diff --git a/drivers/watchdog/stpmic1_wdt.c b/drivers/watchdog/stpmic1_wdt.c
index 9b7a586387db..40273ffc4c85 100644
--- a/drivers/watchdog/stpmic1_wdt.c
+++ b/drivers/watchdog/stpmic1_wdt.c
@@ -14,22 +14,15 @@
 #include 
 #include 
 
-#define RESTART_SR 0x05
-#define MAIN_CR0x10
-#define WCHDG_CR   0x1B
-#define WCHDG_TIMER_CR 0x1C
+#include 
 
-/* Restart Status Register (RESTART_SR) */
+/* Restart Status Register (RREQ_STATE_SR) */
 #define R_RST  BIT(0)
 #define R_SWOFFBIT(1)
 #define R_WDG  BIT(2)
 #define R_PKEYLKP  BIT(3)
 #define R_VINOK_FA BIT(4)
 
-/* Main PMIC Control Register (MAIN_CR) */
-#define SWOFF   BIT(0)
-#define RREQ_EN BIT(1)
-
 /* Watchdog Control Register (WCHDG_CR) */
 #define WDT_START  BIT(0)
 #define WDT_PING   BIT(1)
@@ -106,8 +99,9 @@ static void __noreturn stpmic1_restart_handler(struct 
restart_handler *rst)
 {
struct stpmic1_wdt *wdt = container_of(rst, struct stpmic1_wdt, 
restart);
 
-   regmap_write_bits(wdt->regmap, MAIN_CR,
- SWOFF | RREQ_EN, SWOFF | RREQ_EN);
+   regmap_write_bits(wdt->regmap, SWOFF_PWRCTRL_CR,
+ SOFTWARE_SWITCH_OFF_ENABLED | RESTART_REQUEST_ENABLED,
+ SOFTWARE_SWITCH_OFF_ENABLED | 
RESTART_REQUEST_ENABLED);
 
mdelay(1000);
hang();
@@ -119,8 +113,9 @@ static void __noreturn stpmic1_poweroff(struct 
poweroff_handler *handler)
 
shutdown_barebox();
 
-   regmap_write_bits(wdt->regmap, MAIN_CR,
- SWOFF | RREQ_EN, SWOFF);
+   regmap_write_bits(wdt->regmap, SWOFF_PWRCTRL_CR,
+ SOFTWARE_SWITCH_OFF_ENABLED | RESTART_REQUEST_ENABLED,
+ SOFTWARE_SWITCH_OFF_ENABLED);
 
mdelay(1000);
hang();
@@ -142,7 +137,7 @@ static int stpmic1_set_reset_reason(struct regmap *map)
int ret;
int i, instance = 0;
 
-   ret = regmap_read(map, RESTART_SR, );
+   ret = regmap_read(map, RREQ_STATE_SR, );
if (ret)
return ret;
 
@@ -156,7 +151,7 @@ static int stpmic1_set_reset_reason(struct regmap *map)
 
reset_source_set_prinst(type, 400, instance);
 
-   pr_info("STPMIC1 reset reason %s (RESTART_SR: 0x%08x)\n",
+   pr_info("STPMIC1 reset reason %s (RREQ_STATE_SR: 0x%08x)\n",
reset_source_name(), reg);
 
return 0;
@@ -180,7 +175,8 @@ static int stpmic1_wdt_probe(struct device_d *dev)
wdd->timeout_max = PMIC_WDT_MAX_TIMEOUT;
 
/* have the watchdog reset, not power-off the system */
-   regmap_write_bits(wdt->regmap, MAIN_CR, RREQ_EN, RREQ_EN);
+   regmap_write_bits(wdt->regmap, SWOFF_PWRCTRL_CR,
+ RESTART_REQUEST_ENABLED, RESTART_REQUEST_ENABLED);
 
ret = watchdog_register(wdd);
if (ret) {
-- 
2.24.0.rc1


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


[PATCH 02/10] ARM: stm32mp157c-dk2: add optional DEBUG_LL print to entry point

2019-11-12 Thread Ahmad Fatoum
The TF-A sets up pin muxing and clocking for the UART4 which is the UART
suggested by ST for use as debug console.

Eventually, we might want to do this ourselves to be sure, but for now
lets just stick in a putc_ll('>'), so user selecting DEBUG_LL can see
that barebox started.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/boards/stm32mp157c-dk2/lowlevel.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boards/stm32mp157c-dk2/lowlevel.c 
b/arch/arm/boards/stm32mp157c-dk2/lowlevel.c
index 566ace79c956..2106eaadc93a 100644
--- a/arch/arm/boards/stm32mp157c-dk2/lowlevel.c
+++ b/arch/arm/boards/stm32mp157c-dk2/lowlevel.c
@@ -7,12 +7,21 @@
 
 extern char __dtb_z_stm32mp157c_dk2_start[];
 
+static void setup_uart(void)
+{
+   /* first stage has set up the UART, so nothing to do here */
+   putc_ll('>');
+}
+
 ENTRY_FUNCTION(start_stm32mp157c_dk2, r0, r1, r2)
 {
void *fdt;
 
arm_cpu_lowlevel_init();
 
+   if (IS_ENABLED(CONFIG_DEBUG_LL))
+   setup_uart();
+
fdt = __dtb_z_stm32mp157c_dk2_start + get_runtime_offset();
 
barebox_arm_entry(STM32_DDR_BASE, SZ_512M, fdt);
-- 
2.24.0.rc1


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


[PATCH 09/10] ARM: stm32mp: add stm32mp_cpu_lowlevel_init with stack set up

2019-11-12 Thread Ahmad Fatoum
When barebox is invoked out of the TF-A v2.1, it's started with
sp, r0, r1, r2 all equal to zero. To use the new RAM size calculating
stm32mp1_barebox_entry, we need to have a stack to handle spillage.

Add a stm32mp_cpu_lowlevel_init wrapper around arm_cpu_lowlevel_init,
which additionally configures a 64 byte stack after the end of the
barebox binary. This should be enough to help us through the RAM size
calculation. If not, compression will fail because of data corruption
and stack size can be increased as necessary.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/mach-stm32mp/include/mach/entry.h | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-stm32mp/include/mach/entry.h 
b/arch/arm/mach-stm32mp/include/mach/entry.h
index 703712a9eea7..92e15b5cf4e3 100644
--- a/arch/arm/mach-stm32mp/include/mach/entry.h
+++ b/arch/arm/mach-stm32mp/include/mach/entry.h
@@ -1,7 +1,18 @@
 #ifndef _STM32MP_MACH_ENTRY_H_
 #define _STM32MP_MACH_ENTRY_H_
 
-#include 
+#include 
+#include 
+
+static __always_inline void stm32mp_cpu_lowlevel_init(void)
+{
+   unsigned long stack_top;
+   arm_cpu_lowlevel_init();
+
+   stack_top = (unsigned long)__image_end + get_runtime_offset() + 64;
+   stack_top = ALIGN(stack_top, 16);
+   arm_setup_stack(stack_top);
+}
 
 void __noreturn stm32mp1_barebox_entry(void *boarddata);
 
-- 
2.24.0.rc1


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


[PATCH 01/10] ARM: dts: stm32mp: move alias to SoC device tree

2019-11-12 Thread Ahmad Fatoum
We'll want reliable ordering for other SD/MMC using boards as well, thus
move the alias out of the board device tree into the SoC's.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/dts/stm32mp157a-dk1.dtsi | 4 
 arch/arm/dts/stm32mp157c.dtsi | 1 +
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/dts/stm32mp157a-dk1.dtsi 
b/arch/arm/dts/stm32mp157a-dk1.dtsi
index e9e386a6649f..6be208f32ef2 100644
--- a/arch/arm/dts/stm32mp157a-dk1.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1.dtsi
@@ -8,10 +8,6 @@
 #include 
 
 / {
-   aliases {
-   mmc0 = 
-   };
-
chosen {
environment {
compatible = "barebox,environment";
diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
index 97c075a020f8..decb4ab6d5c4 100644
--- a/arch/arm/dts/stm32mp157c.dtsi
+++ b/arch/arm/dts/stm32mp157c.dtsi
@@ -18,6 +18,7 @@
gpio9 = 
gpio10 = 
gpio25 = 
+   mmc0 = 
};
 
psci {
-- 
2.24.0.rc1


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


[PATCH 06/10] Documentation: boards: stm32mp: document boot error LED

2019-11-12 Thread Ahmad Fatoum
The STM32MP Evaluation Kits place a LED on PA13 to display boot status.
Document its blinking patterns.

Signed-off-by: Ahmad Fatoum 
---
 Documentation/boards/stm32mp.rst | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/boards/stm32mp.rst b/Documentation/boards/stm32mp.rst
index f93ec04eb04d..6d97b0d6d4a2 100644
--- a/Documentation/boards/stm32mp.rst
+++ b/Documentation/boards/stm32mp.rst
@@ -81,3 +81,13 @@ pulled down and BOOT0 and BOOT2 are connected to a 2P DIP 
switch::
  BOOT2 | O --O |
  BOOT0 | N --O |  < DFU on UART and USB OTG
+---+
+
+Boot status indicator
+-
+
+The ROM code on the first Cortex-A7 core pulses the PA13 pad.
+An error LED on this pad can be used to indicate boot status:
+
+* **Boot Failure:** LED lights bright
+* **UART/USB Boot:** LED blinks fast
+* **Debug access:** LED lights weak
-- 
2.24.0.rc1


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


[PATCH 08/10] ARM: stm32mp: add basic DDR controller driver

2019-11-12 Thread Ahmad Fatoum
The STM32MP DDR Controller has a very flexible way of mapping address
bits to columns/rows/banks. This is so far configured by the ARM TF-A
as part of the SDRAM setup, so we don't need to do this in barebox.

Nevertheless reading it out in barebox, allows us to determine unused
address bits and thus the total size of SDRAM configured.

Add a simple driver that parses the ddrctrl node and adds an appropriate
memory bank. This can later be used to remove explicit calls to
arm_add_mem_device in board code.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/mach-stm32mp/ddrctrl.c | 34 +
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/mach-stm32mp/ddrctrl.c b/arch/arm/mach-stm32mp/ddrctrl.c
index 90fb5e8956d0..b959441455d5 100644
--- a/arch/arm/mach-stm32mp/ddrctrl.c
+++ b/arch/arm/mach-stm32mp/ddrctrl.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -119,3 +120,36 @@ void __noreturn stm32mp1_barebox_entry(void *boarddata)
 {
barebox_arm_entry(STM32_DDR_BASE, stm32mp1_ddrctrl_ramsize(), 
boarddata);
 }
+
+
+static int stm32_ddrctrl_probe(struct device_d *dev)
+{
+   struct resource *iores;
+   void __iomem *base;
+
+   iores = dev_request_mem_resource(dev, 0);
+   if (IS_ERR(iores))
+   return PTR_ERR(iores);
+   base = IOMEM(iores->start);
+
+   arm_add_mem_device("ram0", STM32_DDR_BASE, ddrctrl_ramsize(base));
+
+   return 0;
+}
+
+static __maybe_unused struct of_device_id stm32_ddrctrl_dt_ids[] = {
+   { .compatible = "st,stm32-ddrctrl" },
+   { /* sentinel */ }
+};
+
+static struct driver_d stm32_ddrctrl_driver = {
+   .name   = "stm32-ddrctrl",
+   .probe  = stm32_ddrctrl_probe,
+   .of_compatible = DRV_OF_COMPAT(stm32_ddrctrl_dt_ids),
+};
+
+static int stm32_ddrctrl_init(void)
+{
+   return platform_driver_register(_ddrctrl_driver);
+}
+mem_initcall(stm32_ddrctrl_init);
-- 
2.24.0.rc1


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


[PATCH 05/10] i2c: stm32: use device_reset_us helper instead of open-coding

2019-11-12 Thread Ahmad Fatoum
The exact sequence is already available in form of device_reset_us. Make
use of it.

Signed-off-by: Ahmad Fatoum 
---
 drivers/i2c/busses/i2c-stm32.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-stm32.c b/drivers/i2c/busses/i2c-stm32.c
index 6af55fb3ffda..9f34760e3fdf 100644
--- a/drivers/i2c/busses/i2c-stm32.c
+++ b/drivers/i2c/busses/i2c-stm32.c
@@ -785,7 +785,6 @@ static int __init stm32_i2c_probe(struct device_d *dev)
struct resource *iores;
struct stm32_i2c *stm32_i2c;
struct i2c_platform_data *pdata;
-   struct reset_control *rst;
const struct stm32_i2c_setup *setup;
struct i2c_timings *timings;
int ret;
@@ -799,13 +798,9 @@ static int __init stm32_i2c_probe(struct device_d *dev)
return PTR_ERR(stm32_i2c->clk);
clk_enable(stm32_i2c->clk);
 
-   rst = reset_control_get(dev, NULL);
-   if (IS_ERR(rst))
-   return PTR_ERR(rst);
-
-   reset_control_assert(rst);
-   udelay(2);
-   reset_control_deassert(rst);
+   ret = device_reset_us(dev, 2);
+   if (ret)
+   return ret;
 
ret = dev_get_drvdata(dev, (const void **));
if (ret)
-- 
2.24.0.rc1


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


[BUG] Padding inserted by linker breaks magicvar linker array

2019-11-03 Thread Ahmad Fatoum
Hi,

I run into a crash with barebox master[1] when running the magicvar command.
The culprit seems to be 8 bytes of padding inserted between
__barebox_magicvar_start and OPTARG, the first array element:

  0x00061918__barebox_magicvar_start = .
   *(SORT_BY_NAME(.barebox_magicvar*))
=> *fill* 0x000619180x8
   .barebox_magicvar_OPTARG
  0x00061920   0x10 common/built-in.o
  0x00061920__barebox_magicvar_OPTARG

The 8 byte *fill*er aligns the .barebox_magicvar_OPTARG section to 16 bytes.
Via addition and removal of dummy initcalls, we can shift the magicvars around
until we no longer straddle the 16 bit boundary:

 0x00061910__barebox_magicvar_start = .
   *(SORT_BY_NAME(.barebox_magicvar*))
   .barebox_magicvar_OPTARG
 0x00061910   0x10 common/built-in.o
 0x00061910__barebox_magicvar_OPTARG

Now running magicvar no longer crashes. We can achieve the alignment reliably by
adding . = ALIGN(16) at the start of the BAREBOX_MAGICVARS definition in
include/asm-generic/barebox.lds.h.

Does someone know what controls this 16 byte (or maybe 32 byte?) alignment?
Do we need to explicitly align the other linker array start symbols as well or
is there a better way?

Interestingly, the barebox_cmd array which I would've expected to behave the 
same
doesn't:

   0x00061638__barebox_cmd_start = .
*(SORT_BY_NAME(.barebox_cmd*))
.barebox_cmd_2048
   0x000616380x8 commands/built-in.o
   0x00061638barebox_cmd_2048

Here the 8 byte alignment is deemed ok by the linker...

Thoughts?

Cheers,
Ahmad



[1]: master at time of writing is 27ee6010 "console_simple: fix linking error 
when
 ARCH_HAS_CTRLC enabled". To reproduce the issue I've added a single dummy 
initcall.
 I can provide defconfig if requested.
-- 
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- |

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


Re: [PATCH v2 2/4] watchdog: implement generic support for .running device parameter

2019-11-05 Thread Ahmad Fatoum
On 11/5/19 11:46 AM, Ahmad Fatoum wrote:
> Hi,
> 
> On 11/5/19 11:40 AM, Sascha Hauer wrote:
>> When we just started the watchdog we actually know that it is running,
>> so we could support the parameter for all watchdogs once it's started.

I'll do this.

>> Casting p->value to (struct watchdog *) seems wrong. However, this
>> function shouldn't be needed, see below.

It's well-defined, but ye, it feels a bit wrong.

>>> +
>>>  static int watchdog_register_dev(struct watchdog *wd, const char *name, 
>>> int id)
>>>  {
>>> wd->dev.parent = wd->hwdev;
>>> @@ -162,6 +184,15 @@ int watchdog_register(struct watchdog *wd)
>>> if (ret)
>>> return ret;
>>>  
>>> +   if (test_bit(WDOG_HW_RUNNING_SUPPORTED, >status)) {
>>> +   p = dev_add_param(>dev, "running", NULL,
>>> + watchdog_get_running, PARAM_FLAG_RO);
>>> +   if (IS_ERR(p))
>>> +   return PTR_ERR(p);
>>> +
>>> +   p->value = (char *)wd;
>>> +   }
>>
>> How about adding this parameter unconditionally, with "unknown" as value
>> when WDOG_HW_RUNNING_SUPPORTED is not set. You can use
>> dev_add_param_enum() here.

Thinking about it, I'd rather not use dev_add_param_enum here. I would like
to leave the driver-side API not too different from Linux, i.e. status bits
that can be set. If I use dev_add_param_enum, I'll have to add a new struct
member for every new status bit. I can respin the patch with an unconditional
dev_add_param though.

> 
> Sounds good.
> 
>>
>> 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- |

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


Re: [PATCH v2 2/4] watchdog: implement generic support for .running device parameter

2019-11-05 Thread Ahmad Fatoum
Hi,

On 11/5/19 11:40 AM, Sascha Hauer wrote:
> Hi Ahmad,
> 
> On Mon, Nov 04, 2019 at 11:14:05PM +0100, Ahmad Fatoum wrote:
>> Linux watchdog have an optional WDOG_HW_RUNNING bit that is used in
>> conjunction with CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED to automatically
>> ping running watchdogs until userspace takes over.
>>
>> So far, when we ported Linux drivers, we dropped this detection, but it
>> would be useful to have this information in barebox as well:
>>
>> The American Megatrends BIOS I am using allows configuring the hardware
>> watchdog from the BIOS. barebox enables the WDT as well, so in normal
>> operation we would never notice if after a BIOS update, the watchdog is
>> no longer enabled. If we maintain a running parameter on watchdog
>> devices, board code can be written to check whether the watchdog device
>> is indeed running.
> 
> To write such code I would prefer to have a function which returns the
> running status rather than playing with getenv().

Ye, board code can use watchdog_hw_running added in this patch.
Hush scripts can use the device parameter. I'll amend the commit message.

> Additionally there is
> a function missing in the watchdog code which returns a watchdog by its
> name. This can be a future excercise, no need to do it in this patch.

Ok.

> 
>> @@ -45,7 +47,18 @@ int watchdog_set_timeout(struct watchdog *wd, unsigned 
>> timeout)
>>  
>>  pr_debug("setting timeout on %s to %ds\n", watchdog_name(wd), timeout);
>>  
>> -return wd->set_timeout(wd, timeout);
>> +ret = wd->set_timeout(wd, timeout);
>> +if (ret)
>> +return ret;
>> +
>> +if (test_bit(WDOG_HW_RUNNING_SUPPORTED, >status)) {
>> +if (timeout)
>> +set_bit(WDOG_HW_RUNNING, >status);
>> +else
>> +clear_bit(WDOG_HW_RUNNING, >status);
>> +}
> 
> When we just started the watchdog we actually know that it is running,
> so we could support the parameter for all watchdogs once it's started.
> 
>> +
>> +return 0;
>>  }
>>  EXPORT_SYMBOL(watchdog_set_timeout);
>>  
>> @@ -118,6 +131,15 @@ static int watchdog_register_poller(struct watchdog *wd)
>>  return PTR_ERR_OR_ZERO(p);
>>  }
>>  
>> +static const char *watchdog_get_running(struct device_d *dev, struct 
>> param_d *p)
>> +{
>> +/*
>> + * This won't ever fail, because the parameter is only registed when
>> + * test_bit(WDOG_HW_RUNNING_SUPPORTED, >status) is true
>> + */
>> +return watchdog_hw_running((struct watchdog *)p->value) ? "1" : "0";
>> +}
> 
> Casting p->value to (struct watchdog *) seems wrong. However, this
> function shouldn't be needed, see below.
> 
>> +
>>  static int watchdog_register_dev(struct watchdog *wd, const char *name, int 
>> id)
>>  {
>>  wd->dev.parent = wd->hwdev;
>> @@ -162,6 +184,15 @@ int watchdog_register(struct watchdog *wd)
>>  if (ret)
>>  return ret;
>>  
>> +if (test_bit(WDOG_HW_RUNNING_SUPPORTED, >status)) {
>> +p = dev_add_param(>dev, "running", NULL,
>> +  watchdog_get_running, PARAM_FLAG_RO);
>> +if (IS_ERR(p))
>> +return PTR_ERR(p);
>> +
>> +p->value = (char *)wd;
>> +}
> 
> How about adding this parameter unconditionally, with "unknown" as value
> when WDOG_HW_RUNNING_SUPPORTED is not set. You can use
> dev_add_param_enum() here.

Sounds good.

> 
> 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- |

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


[PATCH v3 4/4] watchdog: f71808e: support .running device parameter

2019-11-08 Thread Ahmad Fatoum
The American Megatrends BIOS I am using can be configured to start the
Fintek watchdog prior to the UEFI payloads. To avoid BIOS updates that reset
this functionality going unnoticed, implement support for WDOG_HW_RUNNING.

Signed-off-by: Ahmad Fatoum 
---
v2 -> v3:
  Use new enum wdog_hw_running
v1 -> v2:
  Use new WDOG_HW_RUNNING_SUPPORTED
---
 drivers/watchdog/f71808e_wdt.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/f71808e_wdt.c b/drivers/watchdog/f71808e_wdt.c
index 4f881a1d02bc..5307ab0b3ead 100644
--- a/drivers/watchdog/f71808e_wdt.c
+++ b/drivers/watchdog/f71808e_wdt.c
@@ -222,7 +222,7 @@ static int f71808e_wdt_init(struct f71808e_wdt *wd, struct 
device_d *dev)
 {
struct watchdog *wdd = >wdd;
const char * const *names = pulse_width_names;
-   int wdt_conf;
+   unsigned long wdt_conf;
int ret;
 
superio_enter(wd->sioaddr);
@@ -262,6 +262,11 @@ static int f71808e_wdt_init(struct f71808e_wdt *wd, struct 
device_d *dev)
 
dev_info(dev, "reset reason: %s\n", reset_source_name());
 
+   if (test_bit(F71808FG_FLAG_WD_EN, _conf))
+   wdd->running = WDOG_HW_RUNNING;
+   else
+   wdd->running = WDOG_HW_NOT_RUNNING;
+
ret = watchdog_register(wdd);
if (ret)
return ret;
-- 
2.24.0.rc1


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


[PATCH 1/2] ARM: i.MX6: Embedsky E9: remove inaccurate comment

2019-11-08 Thread Ahmad Fatoum
The board support is likely copied from the freescale-mx6-sabrelite,
which requires some GPIOs setup before Ethernet is usable. There is no
GPIOs used in this board's code, so remove the comment and along it the
 header.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/boards/embedsky-e9/board.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boards/embedsky-e9/board.c 
b/arch/arm/boards/embedsky-e9/board.c
index 0f47677bb06a..e5f92636fbc3 100644
--- a/arch/arm/boards/embedsky-e9/board.c
+++ b/arch/arm/boards/embedsky-e9/board.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -102,8 +101,4 @@ static int e9_coredevices_init(void)
 
return 0;
 }
-/*
- * Do this before the fec initializes but after our
- * gpios are available.
- */
 coredevice_initcall(e9_coredevices_init);
-- 
2.24.0.rc1


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


[PATCH 2/2] ARM: i.MX6: sabresd: remove inaccurate comment

2019-11-08 Thread Ahmad Fatoum
The board support is likely copied from the freescale-mx6-sabrelite,
which requires some GPIOs setup before Ethernet is usable. There is no
GPIOs used in this board's code, so remove the comment and along it the
 header.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/boards/freescale-mx6-sabresd/board.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boards/freescale-mx6-sabresd/board.c 
b/arch/arm/boards/freescale-mx6-sabresd/board.c
index 595b1eae0ba8..a5059835dfbc 100644
--- a/arch/arm/boards/freescale-mx6-sabresd/board.c
+++ b/arch/arm/boards/freescale-mx6-sabresd/board.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -84,8 +83,4 @@ static int sabresd_coredevices_init(void)
 
return 0;
 }
-/*
- * Do this before the fec initializes but after our
- * gpios are available.
- */
 coredevice_initcall(sabresd_coredevices_init);
-- 
2.24.0.rc1


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


Re: [PATCH v2 2/4] watchdog: implement generic support for .running device parameter

2019-11-08 Thread Ahmad Fatoum
On 11/5/19 12:18 PM, Sascha Hauer wrote:
> On Tue, Nov 05, 2019 at 12:10:51PM +0100, Ahmad Fatoum wrote:
>> On 11/5/19 11:46 AM, Ahmad Fatoum wrote:
>>> Hi,
>>>
>>> On 11/5/19 11:40 AM, Sascha Hauer wrote:
>>>> When we just started the watchdog we actually know that it is running,
>>>> so we could support the parameter for all watchdogs once it's started.
>>
>> I'll do this.
>>
>>>> Casting p->value to (struct watchdog *) seems wrong. However, this
>>>> function shouldn't be needed, see below.
>>
>> It's well-defined, but ye, it feels a bit wrong.
>>
>>>>> +
>>>>>  static int watchdog_register_dev(struct watchdog *wd, const char *name, 
>>>>> int id)
>>>>>  {
>>>>>   wd->dev.parent = wd->hwdev;
>>>>> @@ -162,6 +184,15 @@ int watchdog_register(struct watchdog *wd)
>>>>>   if (ret)
>>>>>   return ret;
>>>>>  
>>>>> + if (test_bit(WDOG_HW_RUNNING_SUPPORTED, >status)) {
>>>>> + p = dev_add_param(>dev, "running", NULL,
>>>>> +   watchdog_get_running, PARAM_FLAG_RO);
>>>>> + if (IS_ERR(p))
>>>>> + return PTR_ERR(p);
>>>>> +
>>>>> + p->value = (char *)wd;
>>>>> + }
>>>>
>>>> How about adding this parameter unconditionally, with "unknown" as value
>>>> when WDOG_HW_RUNNING_SUPPORTED is not set. You can use
>>>> dev_add_param_enum() here.
>>
>> Thinking about it, I'd rather not use dev_add_param_enum here. I would like
>> to leave the driver-side API not too different from Linux, i.e. status bits
>> that can be set. If I use dev_add_param_enum, I'll have to add a new struct
>> member for every new status bit.
> 
> Not for every bit, but for every flag you want to export as a parameter.
> But where's the problem with that?

Ok, sent v3 with your suggestions incorporated.

> 
> Sascha
> 


-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


[PATCH v3 2/4] watchdog: implement generic support for .running device parameter

2019-11-08 Thread Ahmad Fatoum
Linux watchdog have an optional WDOG_HW_RUNNING bit that is used in
conjunction with CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED to automatically
ping running watchdogs until userspace takes over.

So far, when we ported Linux drivers, we dropped this detection, but it
would be useful to have this information in barebox as well:

The American Megatrends BIOS I am using allows configuring the hardware
watchdog from the BIOS. barebox enables the WDT as well, so in normal
operation we would never notice if after a BIOS update, the watchdog is
no longer enabled. If we maintain a running parameter on watchdog
devices, board code can be written to check whether the watchdog device
is indeed running.

To achieve this, add the necessary bits to the watchdog API. How we go
about it differs from Linux a little:

- We use an enum instead of a single bit, so we can differentiate between
  watchdogs that are not running and watchdogs whose running status is
  unknown.
- Because we can check whether watchdog_hw_running is supported, it now
  can fail and return a negative value in that case
- We do the maintenance of the running parameter after barebox
  feeds/disables the watchdog in the core, so it doesn't need to
  be replicated across drivers. Drivers hould only initialize the
  running parameter once at probe time.

Signed-off-by: Ahmad Fatoum 
---
v2 -> v3:
  - replace bitmask for running status with enum
  - use dev_add_param_enum_ro helper
v1 -> v2:
  - WDOG_HW_RUNNING: add comment describing use
  - struct watchdog: drop status_supported member in favor of having a
single WDOG_HW_RUNNING_SUPPORTED bit
  - watchdog_set_timeout: return 0 instead of ret, when we now that ret
== 0
---
 drivers/watchdog/wd_core.c | 21 -
 include/watchdog.h | 17 +
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/wd_core.c b/drivers/watchdog/wd_core.c
index 39cac6f6c494..fcead1175558 100644
--- a/drivers/watchdog/wd_core.c
+++ b/drivers/watchdog/wd_core.c
@@ -37,6 +37,8 @@ static const char *watchdog_name(struct watchdog *wd)
  */
 int watchdog_set_timeout(struct watchdog *wd, unsigned timeout)
 {
+   int ret;
+
if (!wd)
return -ENODEV;
 
@@ -45,7 +47,13 @@ int watchdog_set_timeout(struct watchdog *wd, unsigned 
timeout)
 
pr_debug("setting timeout on %s to %ds\n", watchdog_name(wd), timeout);
 
-   return wd->set_timeout(wd, timeout);
+   ret = wd->set_timeout(wd, timeout);
+   if (ret)
+   return ret;
+
+   wd->running = timeout ? WDOG_HW_RUNNING : WDOG_HW_NOT_RUNNING;
+
+   return 0;
 }
 EXPORT_SYMBOL(watchdog_set_timeout);
 
@@ -144,6 +152,12 @@ static unsigned int dev_get_watchdog_priority(struct 
device_d *dev)
return priority;
 }
 
+const char *running_names[] = {
+   [WDOG_HW_RUNNING_UNSUPPORTED] = "unknown",
+   [WDOG_HW_RUNNING] = "1",
+   [WDOG_HW_NOT_RUNNING] = "0",
+};
+
 int watchdog_register(struct watchdog *wd)
 {
struct param_d *p;
@@ -162,6 +176,11 @@ int watchdog_register(struct watchdog *wd)
if (ret)
return ret;
 
+   p = dev_add_param_enum_ro(>dev, "running", >running,
+ running_names, ARRAY_SIZE(running_names));
+   if (IS_ERR(p))
+   return PTR_ERR(p);
+
if (!wd->priority)
wd->priority = dev_get_watchdog_priority(wd->hwdev);
 
diff --git a/include/watchdog.h b/include/watchdog.h
index 105b7ca81093..5790205a487b 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -16,6 +16,10 @@
 #include 
 #include 
 
+enum wdog_hw_runnning {
+WDOG_HW_RUNNING_UNSUPPORTED, WDOG_HW_RUNNING, WDOG_HW_NOT_RUNNING
+};
+
 struct watchdog {
int (*set_timeout)(struct watchdog *, unsigned);
const char *name;
@@ -27,8 +31,21 @@ struct watchdog {
unsigned int poller_enable;
struct poller_async poller;
struct list_head list;
+   int running; /* enum wdog_hw_running */
 };
 
+/*
+ * Use the following function to check whether or not the hardware watchdog
+ * is running
+ */
+static inline int watchdog_hw_running(struct watchdog *w)
+{
+   if (w->running == WDOG_HW_RUNNING_UNSUPPORTED)
+   return -ENOSYS;
+
+   return w->running == WDOG_HW_RUNNING;
+}
+
 #ifdef CONFIG_WATCHDOG
 int watchdog_register(struct watchdog *);
 int watchdog_deregister(struct watchdog *);
-- 
2.24.0.rc1


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


[PATCH v3 1/4] watchdog: always populate watchdog priority from device tree if possible

2019-11-08 Thread Ahmad Fatoum
So far, only the da9063 and da9053 have made use of the optional barebox
watchdog-priority binding. Move it into the core, so other device
drivers automatically have their watchdog-priority property parsed as
well. This patch doesn't introduce any functional changes for upstream
boards.

Signed-off-by: Ahmad Fatoum 
---
v1 -> v3:
 unchanged
---
 drivers/mfd/da9053.c   |  1 -
 drivers/mfd/da9063.c   |  1 -
 drivers/watchdog/wd_core.c | 34 ++
 include/watchdog.h |  7 ---
 4 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/drivers/mfd/da9053.c b/drivers/mfd/da9053.c
index 1faba813bee8..f4bfb68d0301 100644
--- a/drivers/mfd/da9053.c
+++ b/drivers/mfd/da9053.c
@@ -271,7 +271,6 @@ static int da9053_probe(struct device_d *dev)
da9053->dev = dev;
da9053->client = to_i2c_client(dev);
da9053->wd.set_timeout = da9053_set_timeout;
-   da9053->wd.priority = of_get_watchdog_priority(dev->device_node);
da9053->wd.hwdev = dev;
 
ret = da9053_enable_multiwrite(da9053);
diff --git a/drivers/mfd/da9063.c b/drivers/mfd/da9063.c
index e1343bac7618..0862a7e94c46 100644
--- a/drivers/mfd/da9063.c
+++ b/drivers/mfd/da9063.c
@@ -377,7 +377,6 @@ static int da9063_probe(struct device_d *dev)
dev_data = ret < 0 ? NULL : dev_data_tmp;
 
priv = xzalloc(sizeof(struct da9063));
-   priv->wd.priority = of_get_watchdog_priority(dev->device_node);
priv->wd.set_timeout = da9063_watchdog_set_timeout;
priv->wd.hwdev = dev;
priv->timeout = DA9063_INITIAL_TIMEOUT;
diff --git a/drivers/watchdog/wd_core.c b/drivers/watchdog/wd_core.c
index 8b13950238c9..39cac6f6c494 100644
--- a/drivers/watchdog/wd_core.c
+++ b/drivers/watchdog/wd_core.c
@@ -127,6 +127,23 @@ static int watchdog_register_dev(struct watchdog *wd, 
const char *name, int id)
return register_device(>dev);
 }
 
+/**
+ * dev_get_watchdog_priority() - get a device's desired watchdog priority
+ * @dev:   The device, which device_node to read the property from
+ *
+ * return: The priority
+ */
+static unsigned int dev_get_watchdog_priority(struct device_d *dev)
+{
+   unsigned int priority = WATCHDOG_DEFAULT_PRIORITY;
+
+   if (dev)
+   of_property_read_u32(dev->device_node, "watchdog-priority",
+);
+
+   return priority;
+}
+
 int watchdog_register(struct watchdog *wd)
 {
struct param_d *p;
@@ -146,7 +163,7 @@ int watchdog_register(struct watchdog *wd)
return ret;
 
if (!wd->priority)
-   wd->priority = WATCHDOG_DEFAULT_PRIORITY;
+   wd->priority = dev_get_watchdog_priority(wd->hwdev);
 
p = dev_add_param_uint32(>dev, "priority",
 watchdog_set_priority, NULL,
@@ -232,18 +249,3 @@ struct watchdog *watchdog_get_by_name(const char *name)
return NULL;
 }
 EXPORT_SYMBOL(watchdog_get_by_name);
-
-/**
- * of_get_watchdog_priority() - get the desired watchdog priority from device 
tree
- * @node:  The device_node to read the property from
- *
- * return: The priority
- */
-unsigned int of_get_watchdog_priority(struct device_node *node)
-{
-   unsigned int priority = WATCHDOG_DEFAULT_PRIORITY;
-
-   of_property_read_u32(node, "watchdog-priority", );
-
-   return priority;
-}
diff --git a/include/watchdog.h b/include/watchdog.h
index 184a218916f4..105b7ca81093 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -35,7 +35,6 @@ int watchdog_deregister(struct watchdog *);
 struct watchdog *watchdog_get_default(void);
 struct watchdog *watchdog_get_by_name(const char *name);
 int watchdog_set_timeout(struct watchdog*, unsigned);
-unsigned int of_get_watchdog_priority(struct device_node *node);
 #else
 static inline int watchdog_register(struct watchdog *w)
 {
@@ -61,12 +60,6 @@ static inline int watchdog_set_timeout(struct watchdog*w, 
unsigned t)
 {
return 0;
 }
-
-
-static inline unsigned int of_get_watchdog_priority(struct device_node *node)
-{
-   return 0;
-}
 #endif
 
 #define WATCHDOG_DEFAULT_PRIORITY 100
-- 
2.24.0.rc1


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


[PATCH v3 3/4] watchdog: imxwd: support .running device parameter on i.MX2+

2019-11-08 Thread Ahmad Fatoum
The i.MX can be fused to start the watchdog on power-on reset.
To give users an easy way to determine whether the watchdog is running,
implement support for WDOG_HW_RUNNING.

Signed-off-by: Ahmad Fatoum 
---
v2 -> v3:
  Use new enum wdog_hw_running
v1 -> v2:
  Use new WDOG_HW_RUNNING_SUPPORTED
---
 drivers/watchdog/imxwd.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/watchdog/imxwd.c b/drivers/watchdog/imxwd.c
index 77a3bd76cefa..b2cfd1cd3a31 100644
--- a/drivers/watchdog/imxwd.c
+++ b/drivers/watchdog/imxwd.c
@@ -28,6 +28,7 @@ struct imx_wd_ops {
int (*set_timeout)(struct imx_wd *, unsigned);
void (*soc_reset)(struct imx_wd *);
int (*init)(struct imx_wd *);
+   bool (*is_running)(struct imx_wd *);
unsigned int timeout_max;
 };
 
@@ -111,6 +112,11 @@ static void imx1_soc_reset(struct imx_wd *priv)
writew(IMX1_WDOG_WCR_WDE, priv->base + IMX1_WDOG_WCR);
 }
 
+static inline bool imx21_watchdog_is_running(struct imx_wd *priv)
+{
+   return imxwd_read(priv, IMX21_WDOG_WCR) & IMX21_WDOG_WCR_WDE;
+}
+
 static int imx21_watchdog_set_timeout(struct imx_wd *priv, unsigned timeout)
 {
u16 val;
@@ -243,6 +249,13 @@ static int imx_wd_probe(struct device_d *dev)
"fsl,ext-reset-output");
 
if (IS_ENABLED(CONFIG_WATCHDOG_IMX)) {
+   if (priv->ops->is_running) {
+   if (priv->ops->is_running(priv))
+   priv->wd.running = WDOG_HW_RUNNING;
+   else
+   priv->wd.running = WDOG_HW_NOT_RUNNING;
+   }
+
ret = watchdog_register(>wd);
if (ret)
goto on_error;
@@ -277,6 +290,7 @@ static const struct imx_wd_ops imx21_wd_ops = {
.set_timeout = imx21_watchdog_set_timeout,
.soc_reset = imx21_soc_reset,
.init = imx21_wd_init,
+   .is_running = imx21_watchdog_is_running,
.timeout_max = 128,
 };
 
-- 
2.24.0.rc1


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


[PATCH 3/3] remoteproc: add .stop device parameter for stopping remote processor

2019-11-21 Thread Ahmad Fatoum
Both the STM32 and i.MX7 remote proc drivers populate the .stop member
in the struct rproc, but it's not used anywhere. The firmware API is not
really fitting to 'unload' firmware. Add instead a device parameter to
stop a remote processor, e.g. remoteproc0.stop=1. This is similar to the
probe command used with MMCs.

Signed-off-by: Ahmad Fatoum 
---
 drivers/remoteproc/remoteproc_core.c | 30 +++-
 include/linux/remoteproc.h   |  2 ++
 2 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 8a28c1bafc1b..e031640bc7a0 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -101,6 +101,8 @@ static int rproc_firmware_finish(struct firmware_handler 
*fh)
fw.size = rproc->fw_buf_ofs;
 
ret = rproc_start(rproc, );
+   if (ret == 0)
+   rproc->stop = PARAM_TRISTATE_FALSE;
 
kfree(rproc->fw_buf);
 
@@ -120,6 +122,19 @@ static int rproc_register_dev(struct rproc *rproc, const 
char *alias)
return register_device(>dev);
 }
 
+static int rproc_set_stop(struct param_d *param, void *priv)
+{
+   struct rproc *rproc = priv;
+   int (*stop)(struct rproc *);
+
+   stop = rproc->ops->stop;
+
+   if (!stop)
+   return -ENOSYS;
+
+   return stop(rproc);
+}
+
 int rproc_add(struct rproc *rproc)
 {
struct device_d *dev = >dev;
@@ -142,12 +157,17 @@ int rproc_add(struct rproc *rproc)
fh->close = rproc_firmware_finish;
 
ret = firmwaremgr_register(fh);
-   if (ret)
-   dev_err(dev, "filed to register firmware handler %s\n", 
rproc->name);
-   else
-   dev_info(dev, "%s is available\n", rproc->name);
+   if (ret) {
+   dev_err(dev, "failed to register firmware handler %s\n", 
rproc->name);
+   return ret;
+   }
 
-   return ret;
+   rproc->stop = PARAM_TRISTATE_UNKNOWN;
+   dev_add_param_tristate(>dev, "stop", rproc_set_stop, NULL,
+  >stop, rproc);
+
+   dev_info(dev, "%s is available\n", rproc->name);
+   return 0;
 }
 
 struct rproc *rproc_alloc(struct device_d *dev, const char *name,
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index c6264d1c0a49..af35837fb39a 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -41,6 +41,8 @@ struct rproc {
 
void *fw_buf;
size_t fw_buf_ofs;
+
+   int stop;
 };
 
 struct rproc *rproc_alloc(struct device_d *dev, const char *name,
-- 
2.20.1


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


[PATCH 2/3] watchdog: core: use new dev_add_param_tristate helper for .running param

2019-11-21 Thread Ahmad Fatoum
Previous commit added a dev_add_param_tristate_ro that can be readily
used instead of the enum parameter here. Use it.
This also fixes the issue that running_names had external linkage.

Signed-off-by: Ahmad Fatoum 
---
 drivers/watchdog/wd_core.c | 9 +
 include/watchdog.h | 5 -
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/watchdog/wd_core.c b/drivers/watchdog/wd_core.c
index fcead1175558..b6e2a37b1f0c 100644
--- a/drivers/watchdog/wd_core.c
+++ b/drivers/watchdog/wd_core.c
@@ -152,12 +152,6 @@ static unsigned int dev_get_watchdog_priority(struct 
device_d *dev)
return priority;
 }
 
-const char *running_names[] = {
-   [WDOG_HW_RUNNING_UNSUPPORTED] = "unknown",
-   [WDOG_HW_RUNNING] = "1",
-   [WDOG_HW_NOT_RUNNING] = "0",
-};
-
 int watchdog_register(struct watchdog *wd)
 {
struct param_d *p;
@@ -176,8 +170,7 @@ int watchdog_register(struct watchdog *wd)
if (ret)
return ret;
 
-   p = dev_add_param_enum_ro(>dev, "running", >running,
- running_names, ARRAY_SIZE(running_names));
+   p = dev_add_param_tristate_ro(>dev, "running", >running);
if (IS_ERR(p))
return PTR_ERR(p);
 
diff --git a/include/watchdog.h b/include/watchdog.h
index 5790205a487b..9741570ce229 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -15,9 +15,12 @@
 
 #include 
 #include 
+#include 
 
 enum wdog_hw_runnning {
-WDOG_HW_RUNNING_UNSUPPORTED, WDOG_HW_RUNNING, WDOG_HW_NOT_RUNNING
+WDOG_HW_RUNNING_UNSUPPORTED = PARAM_TRISTATE_UNKNOWN,
+WDOG_HW_RUNNING = PARAM_TRISTATE_TRUE,
+WDOG_HW_NOT_RUNNING = PARAM_TRISTATE_FALSE
 };
 
 struct watchdog {
-- 
2.20.1


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


[PATCH 1/3] param: add dev_add_param_tristate(_ro) helpers

2019-11-21 Thread Ahmad Fatoum
This is can be considered an extension to the dev_add_param_bool
interfaces with a third value that's "unknown".
This can be used for cases, where barebox can flip a bit somewhere,
but it has no way of knowing what the initial state of the bit was,
e.g. turn on/off the watchdog, but no watchdog status.
Turn on/off a co-processor, but no co-processor online status.
And so on. Not providing a way to customize the "unknown" string
is a deliberate choice, so future device parameters follow the same
naming scheme.

Signed-off-by: Ahmad Fatoum 
---
 include/param.h | 24 
 lib/parameter.c | 22 ++
 2 files changed, 46 insertions(+)

diff --git a/include/param.h b/include/param.h
index 4ac502e726c0..d75f50ea3e60 100644
--- a/include/param.h
+++ b/include/param.h
@@ -63,6 +63,16 @@ struct param_d *dev_add_param_enum(struct device_d *dev, 
const char *name,
int (*get)(struct param_d *p, void *priv),
int *value, const char * const *names, int max, void *priv);
 
+enum param_tristate { PARAM_TRISTATE_UNKNOWN, PARAM_TRISTATE_TRUE, 
PARAM_TRISTATE_FALSE };
+
+struct param_d *dev_add_param_tristate(struct device_d *dev, const char *name,
+   int (*set)(struct param_d *p, void *priv),
+   int (*get)(struct param_d *p, void *priv),
+   int *value, void *priv);
+
+struct param_d *dev_add_param_tristate_ro(struct device_d *dev, const char 
*name,
+   int *value);
+
 struct param_d *dev_add_param_bitmask(struct device_d *dev, const char *name,
int (*set)(struct param_d *p, void *priv),
int (*get)(struct param_d *p, void *priv),
@@ -144,6 +154,20 @@ static inline struct param_d *dev_add_param_bitmask(struct 
device_d *dev, const
return ERR_PTR(-ENOSYS);
 }
 
+static inline struct param_d *dev_add_param_tristate(struct device_d *dev, 
const char *name,
+   int (*set)(struct param_d *p, void *priv),
+   int (*get)(struct param_d *p, void *priv),
+   int *value, void *priv)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
+static inline struct param_d *dev_add_param_tristate_ro(struct device_d *dev, 
const char *name,
+   int *value)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 static inline struct param_d *dev_add_param_ip(struct device_d *dev, const 
char *name,
int (*set)(struct param_d *p, void *priv),
int (*get)(struct param_d *p, void *priv),
diff --git a/lib/parameter.c b/lib/parameter.c
index fdbb2e71d15d..22695634e5f1 100644
--- a/lib/parameter.c
+++ b/lib/parameter.c
@@ -588,6 +588,28 @@ struct param_d *dev_add_param_enum(struct device_d *dev, 
const char *name,
return >param;
 }
 
+static const char *const tristate_names[] = {
+   [PARAM_TRISTATE_UNKNOWN] = "unknown",
+   [PARAM_TRISTATE_TRUE] = "1",
+   [PARAM_TRISTATE_FALSE] = "0",
+};
+
+struct param_d *dev_add_param_tristate(struct device_d *dev, const char *name,
+   int (*set)(struct param_d *p, void *priv),
+   int (*get)(struct param_d *p, void *priv),
+   int *value, void *priv)
+{
+   return dev_add_param_enum(dev, name, set, get, value, tristate_names,
+ ARRAY_SIZE(tristate_names), priv);
+}
+
+struct param_d *dev_add_param_tristate_ro(struct device_d *dev, const char 
*name,
+   int *value)
+{
+   return dev_add_param_enum_ro(dev, name, value, tristate_names,
+ARRAY_SIZE(tristate_names));
+}
+
 struct param_bitmask {
struct param_d param;
unsigned long *value;
-- 
2.20.1


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


[PATCH] watchdog: stm32_iwdg: explicitly set .running to UNSUPPORTED

2019-11-22 Thread Ahmad Fatoum
I've spent some time trying to get the ONF (Watchdog enable status)
bit in the IWDG_SR register to read as something other than zero.

It has since been confirmed to be non-functional[1]. To avoid someone
else spending time on this, document that running status is unsupported
on this hardware explicitly.
No functional change as UNSUPPORTED is already the default.

[1]: https://www.spinics.net/lists/arm-kernel/msg770527.html

Signed-off-by: Ahmad Fatoum 
---
 drivers/watchdog/stm32_iwdg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index 808d7c83720e..c7a5cb9caaf4 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -256,6 +256,7 @@ static int stm32_iwdg_probe(struct device_d *dev)
wdd->set_timeout = stm32_iwdg_set_timeout;
wdd->timeout_max = (RLR_MAX + 1) * data->max_prescaler * 1000;
wdd->timeout_max /= wd->rate * 1000;
+   wdd->running = WDOG_HW_RUNNING_UNSUPPORTED; /* ONF bit not present in 
IP */
 
ret = watchdog_register(wdd);
if (ret) {
-- 
2.24.0


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


Re: [PATCH 3/3] remoteproc: add .stop device parameter for stopping remote processor

2019-12-04 Thread Ahmad Fatoum
Hello Sascha,

On 11/25/19 9:28 AM, Sascha Hauer wrote:
> I would assume that when I can stop the remote processor with this
> parameter I should be able to start it here as well, no?

I've yet to think some more about this, but could you merge the first
two commits now?

Cheers
Ahmad


-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


[PATCH 9/9] serial: add support for PCI NS16550 UARTs

2019-12-04 Thread Ahmad Fatoum
This ports over the Linux v5.4 8250_pci driver. Unlike Linux, the
barebox ns16550 implementation provides less hooks for covering all the
quirky behavior of all the different 8250-"compatible" hardware blocks.

The barebox driver matches against all serial port the Linux driver does,
but for hardware with quirks that can't be expressed in the current barebox
n16550 API, the probe fails with -ENOSYS and an appropriate message
telling that the quirk handling is missing. This should make future
extension of the driver straight-forward.

Unlike the kernel variant of the driver, most ->exit quirk callbacks can
be dropped in barebox as they often disable IRQs, which we do in the
->init anyway.

This was tested with the EFI PCI driver on qemu with the options:

  -device pci-serial,chardev=cdev0 -chardev file,id=cdev0,path=COM

Signed-off-by: Ahmad Fatoum 
---
 drivers/serial/Kconfig  |8 +
 drivers/serial/Makefile |1 +
 drivers/serial/serial_ns16550_pci.c | 5311 +++
 3 files changed, 5320 insertions(+)
 create mode 100644 drivers/serial/serial_ns16550_pci.c

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 7a411d456e51..bd02fe2137c4 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -97,6 +97,14 @@ config DRIVER_SERIAL_NS16550_OMAP_EXTENSIONS
help
  Say Y here if you are using OMAP extensions to NS16550
 
+config DRIVER_SERIAL_NS16550_PCI
+   depends on DRIVER_SERIAL_NS16550
+   depends on PCI
+   default y
+   bool "NS16550 PCI serial driver"
+   help
+ Enable this to get support for NS16550 UARTs connected over PCI
+
 config DRIVER_SERIAL_PL010
depends on ARCH_EP93XX
default y
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 6f9e3b78350d..8a2abbbe45cf 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DRIVER_SERIAL_LINUX_CONSOLE)   += 
linux_console.o
 obj-$(CONFIG_DRIVER_SERIAL_MPC5XXX)+= serial_mpc5xxx.o
 obj-$(CONFIG_DRIVER_SERIAL_CLPS711X)   += serial_clps711x.o
 obj-$(CONFIG_DRIVER_SERIAL_NS16550)+= serial_ns16550.o
+obj-$(CONFIG_DRIVER_SERIAL_NS16550_PCI)+= serial_ns16550_pci.o
 obj-$(CONFIG_DRIVER_SERIAL_PL010)  += serial_pl010.o
 obj-$(CONFIG_DRIVER_SERIAL_S3C)+= serial_s3c.o
 obj-$(CONFIG_DRIVER_SERIAL_STM32)  += serial_stm32.o
diff --git a/drivers/serial/serial_ns16550_pci.c 
b/drivers/serial/serial_ns16550_pci.c
new file mode 100644
index ..d4b5bd8898b7
--- /dev/null
+++ b/drivers/serial/serial_ns16550_pci.c
@@ -0,0 +1,5311 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Probe module for 8250/16550-type PCI serial ports.
+ *
+ *  Based on Linux drivers/tty/serial/8250_pci.c
+ *  Itself based on Linux drivers/char/serial.c, by Linus Torvalds, Theodore 
Ts'o.
+ *
+ *  Copyright (C) 2001 Russell King, All Rights Reserved.
+ *  Copyright (C) 2019 Ahmad Fatoum, Pengutronix
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include "serial_ns16550.h"
+
+#define PCI_NUM_BAR_RESOURCES  6
+
+#define FL_BASE_MASK   0x0007
+#define FL_BASE0   0x
+#define FL_BASE1   0x0001
+#define FL_BASE2   0x0002
+#define FL_BASE3   0x0003
+#define FL_BASE4   0x0004
+#define FL_GET_BASE(x) (x & FL_BASE_MASK)
+
+/* Use successive BARs (PCI base address registers),
+   else use offset into some specified BAR */
+#define FL_BASE_BARS   0x0008
+
+/* do not assign an irq; no-op, we use no irqs */
+#define FL_NOIRQ   0x0080
+
+/* Use the Base address register size to cap number of ports */
+#define FL_REGION_SZ_CAP   0x0100
+
+
+struct uart_8250_port {
+   struct NS16550_plat *pdata;
+   struct resource resource;
+
+};
+
+struct pciserial_board {
+   unsigned int flags;
+   unsigned int num_ports;
+   unsigned int base_baud;
+   unsigned int uart_offset;
+   unsigned int reg_shift;
+   unsigned int first_offset;
+};
+
+struct serial_private;
+
+/*
+ * init function returns:
+ *  > 0 - number of ports
+ *  = 0 - use board->num_ports
+ *  < 0 - error
+ */
+struct pci_serial_quirk {
+   u32 vendor;
+   u32 device;
+   u32 subvendor;
+   u32 subdevice;
+   int (*probe)(struct pci_dev *dev);
+   int (*init)(struct pci_dev *dev);
+   int (*setup)(struct serial_private *,
+const struct pciserial_board *,
+struct uart_8250_port *, int);
+   void(*exit)(struct pci_dev *dev);
+};
+
+#define PCI_NUM_BAR_RESOURCES  6
+
+struct serial_private {
+   struct pci_dev  *dev;
+   unsigned intnr;
+   struct pci_serial_quirk *q

[PATCH 6/9] PCI: copy over some Linux PCI helpers

2019-12-04 Thread Ahmad Fatoum
Linux PCI drivers, like the incoming 8250_pci, make use of these
helpers. Port them over from Linux v5.4.

Signed-off-by: Ahmad Fatoum 
---
 drivers/pci/bus.c   | 26 ++
 include/linux/pci.h | 34 ++
 2 files changed, 60 insertions(+)

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index ac1562330788..251be4fffa6e 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -23,6 +23,32 @@ pci_match_one_device(const struct pci_device_id *id, const 
struct pci_dev *dev)
return NULL;
 }
 
+/**
+ * pci_match_id - See if a pci device matches a given pci_id table
+ * @ids: array of PCI device id structures to search in
+ * @dev: the PCI device structure to match against.
+ *
+ * Used by a driver to check whether a PCI device present in the
+ * system is in its list of supported devices.  Returns the matching
+ * pci_device_id structure or %NULL if there is no match.
+ *
+ * Deprecated, don't use this as it will not catch any dynamic ids
+ * that a driver might want to check for.
+ */
+const struct pci_device_id *pci_match_id(const struct pci_device_id *ids,
+struct pci_dev *dev)
+{
+   if (ids) {
+   while (ids->vendor || ids->subvendor || ids->class_mask) {
+   if (pci_match_one_device(ids, dev))
+   return ids;
+   ids++;
+   }
+   }
+   return NULL;
+}
+EXPORT_SYMBOL(pci_match_id);
+
 static int pci_match(struct device_d *dev, struct driver_d *drv)
 {
struct pci_dev *pdev = to_pci_dev(dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d92d70b6bd68..c742570e3684 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -115,6 +115,17 @@ struct pci_dev {
 };
 #defineto_pci_dev(d) container_of(d, struct pci_dev, dev)
 
+#define pci_resource_start(dev, bar)   ((dev)->resource[(bar)].start)
+#define pci_resource_end(dev, bar) ((dev)->resource[(bar)].end)
+#define pci_resource_flags(dev, bar)   ((dev)->resource[(bar)].flags)
+#define pci_resource_len(dev,bar) \
+   ((pci_resource_start((dev), (bar)) == 0 &&  \
+ pci_resource_end((dev), (bar)) == \
+ pci_resource_start((dev), (bar))) ? 0 :   \
+   \
+(pci_resource_end((dev), (bar)) -  \
+ pci_resource_start((dev), (bar)) + 1))
+
 enum {
PCI_BUS_RESOURCE_IO = 0,
PCI_BUS_RESOURCE_MEM = 1,
@@ -210,6 +221,20 @@ struct pci_driver {
.vendor = (vend), .device = (dev), \
.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID
 
+/**
+ * PCI_DEVICE_SUB - macro used to describe a specific PCI device with subsystem
+ * @vend: the 16 bit PCI Vendor ID
+ * @dev: the 16 bit PCI Device ID
+ * @subvend: the 16 bit PCI Subvendor ID
+ * @subdev: the 16 bit PCI Subdevice ID
+ *
+ * This macro is used to create a struct pci_device_id that matches a
+ * specific device with subsystem information.
+ */
+#define PCI_DEVICE_SUB(vend, dev, subvend, subdev) \
+   .vendor = (vend), .device = (dev), \
+   .subvendor = (subvend), .subdevice = (subdev)
+
 /**
  * PCI_DEVICE_CLASS - macro used to describe a specific pci device class
  * @dev_class: the class, subclass, prog-if triple for this device
@@ -350,4 +375,13 @@ enum pci_fixup_pass {
 
 void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
 
+#ifdef CONFIG_PCI
+const struct pci_device_id *pci_match_id(const struct pci_device_id *ids,
+struct pci_dev *dev);
+#else
+static inline const struct pci_device_id *pci_match_id(const struct 
pci_device_id *ids,
+struct pci_dev *dev)
+{ return NULL; }
+#endif
+
 #endif /* LINUX_PCI_H */
-- 
2.24.0


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


[PATCH 5/9] PCI: add driver_data member to struct pci_device_id

2019-12-04 Thread Ahmad Fatoum
Linux drivers have a driver data member in the struct to associate
variant specific driver data with each device id. Do likewise in
barebox.

Signed-off-by: Ahmad Fatoum 
---
 include/linux/mod_devicetable.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index d8125214a04a..1fbb3dc5c182 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -15,6 +15,7 @@ struct pci_device_id {
__u32 vendor, device;   /* Vendor and device ID or PCI_ANY_ID*/
__u32 subvendor, subdevice; /* Subsystem ID's or PCI_ANY_ID */
__u32 class, class_mask;/* (class,subclass,prog-if) triplet */
+   unsigned long driver_data;  /* Data private to the driver */
 };
 
 #define SPI_NAME_SIZE 32
-- 
2.24.0


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


[PATCH 1/9] efi: add and use new efi_device_has_guid helper

2019-12-04 Thread Ahmad Fatoum
We have at least two places where we check if a efidev has a particular
guid and a follow-up commit will introduce a third place.

So lets factor it out into a helper.

Signed-off-by: Ahmad Fatoum 
---
 drivers/block/efi-block-io.c | 11 ++-
 drivers/efi/efi-device.c | 11 ++-
 include/efi/efi-device.h | 12 
 3 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/block/efi-block-io.c b/drivers/block/efi-block-io.c
index 39dbfb0f7ada..30db486876a8 100644
--- a/drivers/block/efi-block-io.c
+++ b/drivers/block/efi-block-io.c
@@ -131,16 +131,9 @@ static void efi_bio_print_info(struct efi_bio_priv *priv)
media->optimal_transfer_length_granularity);
 }
 
-static int is_bio_usbdev(struct efi_device *efidev)
+static bool is_bio_usbdev(struct efi_device *efidev)
 {
-   int i;
-
-   for (i = 0; i < efidev->num_guids; i++) {
-   if (!efi_guidcmp(efidev->guids[i], EFI_USB_IO_PROTOCOL_GUID))
-   return 1;
-   }
-
-   return 0;
+   return efi_device_has_guid(efidev, EFI_USB_IO_PROTOCOL_GUID);
 }
 
 static int efi_bio_probe(struct efi_device *efidev)
diff --git a/drivers/efi/efi-device.c b/drivers/efi/efi-device.c
index a1aac2dd31be..ac035dcfacbb 100644
--- a/drivers/efi/efi-device.c
+++ b/drivers/efi/efi-device.c
@@ -386,16 +386,9 @@ static int efi_is_setup_mode(void)
return ret != 1;
 }
 
-static int is_bio_usbdev(struct efi_device *efidev)
+static bool is_bio_usbdev(struct efi_device *efidev)
 {
-   int i;
-
-   for (i = 0; i < efidev->num_guids; i++) {
-   if (!efi_guidcmp(efidev->guids[i], EFI_USB_IO_PROTOCOL_GUID))
-   return 1;
-   }
-
-   return 0;
+   return efi_device_has_guid(efidev, EFI_USB_IO_PROTOCOL_GUID);
 }
 
 static struct efi_device *bootdev;
diff --git a/include/efi/efi-device.h b/include/efi/efi-device.h
index 5eaf1f260d56..5ec59a8a2ddd 100644
--- a/include/efi/efi-device.h
+++ b/include/efi/efi-device.h
@@ -45,4 +45,16 @@ int efi_connect_all(void);
 void efi_register_devices(void);
 struct efi_device *efi_get_bootsource(void);
 
+static inline bool efi_device_has_guid(struct efi_device *efidev, efi_guid_t 
guid)
+{
+   int i;
+
+   for (i = 0; i < efidev->num_guids; i++) {
+   if (!efi_guidcmp(efidev->guids[i], guid))
+   return true;
+   }
+
+   return false;
+}
+
 #endif /* __EFI_EFI_DEVICE_H */
-- 
2.24.0


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


[PATCH 8/9] pci: add EFI PCI root bridge IO protocol driver

2019-12-04 Thread Ahmad Fatoum
UEFI 2.1D specifies two protocols for abstracting both the PCI host bus
controller and for PCI devices. The protocol for PCI devices provides
function pointers for accessing IO Port, Memory and PCI configuration
space, among others. The protocol for bus controllers provides the
ability to read the root bridge's PCI configuration space and to query
resources.

In barebox, we would want to reuse existing PCI drivers unmodified, so
we utilize the root bridge protocol, unlike most other EFI payloads.

We still utilize the PCI (device) IO protocol, but not for core
functionality: EFI has already enumerated the bus for us and allocated
the EFI handles. It thus makes sense to have the new pci device have the
EFI handle as parent and the controller as grand parent instead of
being sibling with the EFI handles. This is done with an early PCI fixup
that patches the device's parent pointer after consulting the PCI IO
GetLocation.

Signed-off-by: Ahmad Fatoum 
---
 drivers/efi/Kconfig   |   1 +
 drivers/pci/Kconfig   |   5 +
 drivers/pci/Makefile  |   1 +
 drivers/pci/pci-efi.c | 311 +++
 drivers/pci/pci-efi.h | 331 ++
 5 files changed, 649 insertions(+)
 create mode 100644 drivers/pci/pci-efi.c
 create mode 100644 drivers/pci/pci-efi.h

diff --git a/drivers/efi/Kconfig b/drivers/efi/Kconfig
index cca1a2e1d632..80d9e6f0c5eb 100644
--- a/drivers/efi/Kconfig
+++ b/drivers/efi/Kconfig
@@ -2,3 +2,4 @@ config EFI_BOOTUP
bool
select BLOCK
select PARTITION_DISK
+   select HW_HAS_PCI
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 025c418f2bcf..32153cda1809 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -54,6 +54,11 @@ config PCI_LAYERSCAPE
select OF_PCI
select PCI
 
+config PCI_EFI
+   bool "EFI PCI protocol"
+   depends on EFI_BOOTUP
+   select PCI
+
 endmenu
 
 endif
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 3ca6708657be..5843957b1925 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
 obj-$(CONFIG_PCIE_DW) += pcie-designware.o pcie-designware-host.o
 obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
 obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
+obj-$(CONFIG_PCI_EFI) += pci-efi.o
diff --git a/drivers/pci/pci-efi.c b/drivers/pci/pci-efi.c
new file mode 100644
index ..80d13d906fe9
--- /dev/null
+++ b/drivers/pci/pci-efi.c
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Ahmad Fatoum 
+ */
+#define pr_fmt(fmt) "pci-efi: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pci-efi.h"
+
+struct efi_pci_priv {
+   struct efi_pci_root_bridge_io_protocol *protocol;
+   struct device_d *dev;
+   struct pci_controller pci;
+   struct resource mem;
+   struct resource io;
+   struct list_head children;
+};
+
+struct pci_child_id {
+   size_t segmentno;
+   size_t busno;
+   size_t devno;
+   size_t funcno;
+};
+
+struct pci_child {
+   struct efi_pci_io_protocol *protocol;
+   struct device_d *dev;
+   struct list_head list;
+   struct pci_child_id id;
+};
+
+static inline bool pci_child_id_equal(struct pci_child_id *a, struct 
pci_child_id *b)
+{
+   return a->segmentno == b->segmentno
+   && a->busno == b->busno
+   && a->devno == b->devno
+   && a->funcno == b->funcno;
+}
+
+#define host_to_efi_pci(host) container_of(host, struct efi_pci_priv, pci)
+
+static inline u64 efi_pci_addr(struct pci_bus *bus, u32 devfn, int where)
+{
+   return EFI_PCI_ADDRESS(bus->number,
+  PCI_SLOT(devfn), PCI_FUNC(devfn),
+  where);
+}
+
+static int efi_pci_rd_conf(struct pci_bus *bus, u32 devfn, int where,
+  int size, u32 *val)
+{
+   struct efi_pci_priv *priv = host_to_efi_pci(bus->host);
+   efi_status_t efiret;
+   u32 value;
+   enum efi_pci_protocol_width width;
+
+   switch (size) {
+   case 4:
+   width = EFI_PCI_WIDTH_U32;
+   break;
+   case 2:
+   width = EFI_PCI_WIDTH_U16;
+   break;
+   case 1:
+   width = EFI_PCI_WIDTH_U8;
+   break;
+   default:
+   return PCIBIOS_BAD_REGISTER_NUMBER;
+   }
+
+   efiret = priv->protocol->pci.read(priv->protocol, width,
+   efi_pci_addr(bus, devfn, where),
+   1, );
+
+   *val = 0x;
+
+   if (EFI_ERROR(efiret))
+   return PCIBIOS_BAD_REGISTER_NUMBER;
+
+   *val = value;
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
+static int efi_pci_wr_conf(struct pci_bus *bus, u32 devfn, int where,
+

[PATCH 3/9] efi: fix off-by-one in mem_malloc_init(..., end)

2019-12-04 Thread Ahmad Fatoum
The second (end) parameter of mem_malloc_init() denotes the last address
in the malloc region, so we need to subtract one from the current value
to arrive at the correct end. So far this went not noticed, because iomem
doesn't yet display barebox malloc memory region.

Signed-off-by: Ahmad Fatoum 
---
 common/efi/efi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/efi/efi.c b/common/efi/efi.c
index 73cea3703695..ed8158355020 100644
--- a/common/efi/efi.c
+++ b/common/efi/efi.c
@@ -361,7 +361,7 @@ efi_status_t efi_main(efi_handle_t image, 
efi_system_table_t *sys_table)
if (EFI_ERROR(efiret))
panic("failed to allocate malloc pool: %s\n",
  efi_strerror(efiret));
-   mem_malloc_init((void *)mem, (void *)mem + memsize);
+   mem_malloc_init((void *)mem, (void *)mem + memsize - 1);
 
start_barebox();
 
-- 
2.24.0


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


[PATCH 4/9] x86: efi: lds: don't discard any relocation sections

2019-12-04 Thread Ahmad Fatoum
The incoming EFI PCI root bridge IO protocol driver will register
PCI fixups. Executing them will fail because the hook function's
relocation information is stripped from the final barebox.efi binary.

Instead of adding each section by name, just keep all .rela* sections
in the final binary.

This doesn't yet increase the size of the resulting barebox (yet).

Signed-off-by: Ahmad Fatoum 
---
 arch/x86/mach-efi/elf_x86_64_efi.lds.S | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/x86/mach-efi/elf_x86_64_efi.lds.S 
b/arch/x86/mach-efi/elf_x86_64_efi.lds.S
index 40a942503475..ed79118a3615 100644
--- a/arch/x86/mach-efi/elf_x86_64_efi.lds.S
+++ b/arch/x86/mach-efi/elf_x86_64_efi.lds.S
@@ -58,12 +58,7 @@ SECTIONS
. = ALIGN(4096);
 
.rela : {
-   *(.rela.data*)
-   *(.rela.barebox*)
-   *(.rela.initcall*)
-   *(.rela.exitcall*)
-   *(.rela.got)
-   *(.rela.stab)
+   *(.rela*)
}
 
. = ALIGN(4096);
-- 
2.24.0


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


[PATCH 1/2] bus: efi: add basic ACPI bus infrastructure

2019-12-04 Thread Ahmad Fatoum
It makes sense to support some ACPI tables like the WDAT (Watchdog
Action Table) in barebox. To facilitate this add a ACPI bus and
the necessary bits to integrate ACPI tables into the barebox
device/driver model as devices. These devices are identified by the
four byte signature, which drivers can then match against and the
system description table (SDT) of the device is then available as a
device memory resource.

Even without drivers, with this patch, devinfo and md can now be used
to view the ACPI system description tables, which can be useful
during UEFI payload development.

Support for the ACPI Machine Language and ACPI 5.1 _DSD (Device
Specific Data) is not implemented.

Signed-off-by: Ahmad Fatoum 
---
 drivers/bus/Kconfig  |   8 ++
 drivers/bus/Makefile |   1 +
 drivers/bus/acpi.c   | 255 +++
 include/acpi.h   |  73 +
 4 files changed, 337 insertions(+)
 create mode 100644 drivers/bus/acpi.c
 create mode 100644 include/acpi.h

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 219982d878a8..1a2ff9129e8e 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -25,4 +25,12 @@ config MVEBU_MBUS
  Driver needed for the MBus configuration on Marvell EBU SoCs
  (Kirkwood, Dove, Orion5x, MV78XX0 and Armada 370/XP).
 
+config ACPI
+   bool "Advanced Configuration and Power Interface (ACPI)"
+   default y
+   depends on EFI_BOOTUP
+   help
+ Driver needed for supporting drivers probed from ACPI tables.
+ The root SDT is found via UEFI.
+
 endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index ba5cee40636b..518689a1eabe 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_BUS_OMAP_GPMC) += omap-gpmc.o
 obj-$(CONFIG_IMX_WEIM) += imx-weim.o
 obj-$(CONFIG_MVEBU_MBUS)   += mvebu-mbus.o
 obj-$(CONFIG_TI_SYSC)  += ti-sysc.o
+obj-$(CONFIG_ACPI) += acpi.o
diff --git a/drivers/bus/acpi.c b/drivers/bus/acpi.c
new file mode 100644
index ..2515b6633b33
--- /dev/null
+++ b/drivers/bus/acpi.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Ahmad Fatoum
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct sig_desc {
+   const char sig[4];
+   const char *desc;
+} signatures[] = {
+   /* ACPI 6.3 Table 5-29, Defined DESCRIPTION_HEADER Signatures */
+   { "APIC", "Multiple APIC Description" },
+   { "BERT", "Boot Error Record" },
+   { "BGRT", "Boot Graphics Resource" },
+   { "CPEP", "Corrected Platform Error Polling" },
+   { "DSDT", "Differentiated System Description" },
+   { "ECDT", "Embedded Controller Boot Resource" },
+   { "EINJ", "Error Injection" },
+   { "ERST", "Error Record Serialization" },
+   { "FACP", "Fixed ACPI Description" },
+   { "FACS", "Firmware ACPI Control Structure" },
+   { "FPDT", "Firmware Performance Data" },
+   { "GTDT", "Generic Timer Description" },
+   { "HEST", "Hardware Error Source" },
+   { "MSCT", "Maximum System Characteristics" },
+   { "MPST", "Memory Power State" },
+   { "NFIT", "NVDIMM Firmware Interface" },
+   { "OEM\0", "OEM Specific Information" },
+   { "PCCT", "Platform Communications Channel" },
+   { "PMTT", "Platform Memory Topology" },
+   { "PSDT", "Persistent System Description" },
+   { "RASF", "ACPI RAS Feature" },
+   { "RSDT", "Root System Description" },
+   { "SBST", "Smart Battery Specification" },
+   { "SDEV", "Secure Devices" },
+   { "SLIT", "System Locality Distance Information" },
+   { "SRAT", "System Resource Affinity" },
+   { "SSDT", "Secondary System Description" },
+   { "XSDT", "Extended System Description" },
+
+   /* ACPI 6.3 Table 5-30, Reserved DESCRIPTION_HEADER Signatures */
+   { "BOOT", "Simple BOOT Flag" },
+   { "CSRT", "Core System Resource" },
+   { "DBG2", "Microsoft Debug Port 2" },
+   { "DBGP", "Debug Port" },
+   { "DMAR", "DMA Remapping" },
+   { "DPPT", "DMA Protection Policy" },
+   { "DRTM", "Dynamic Root of Trust for Measurement" },
+   { "ETDT", "(Obsolete) Event T

[PATCH 0/2] bus: efi: add basic ACPI bus infrastructure

2019-12-04 Thread Ahmad Fatoum
Microsoft specifies an ACPI Watchdog Action Table for its server
offerings that abstracts away hardware-specifics of watchdog devices.
This can be an alternative to implementing many different watchdog
driver in barebox for x86 H/W, as the driver is implemented in the
BIOS and barebox would only need to implement the H/W.

Unfortunately, I don't H/W handy that provides the WDAT table.
I've implemented the ACPI bus nevertheless, so here's the patch.

I haven't found anything else I'd like to do with ACPI, so I wrote a
sample driver to test the API. Not sure if it should go into the tree,
but I'd be in favor of adding it till there is a real user of the ACPI
bus (besides devinfo).

Cheers
Ahmad

Ahmad Fatoum (2):
  bus: efi: add basic ACPI bus infrastructure
  misc: add ACPI test driver

 drivers/bus/Kconfig  |   8 ++
 drivers/bus/Makefile |   1 +
 drivers/bus/acpi.c   | 255 +++
 drivers/misc/Kconfig |   6 +
 drivers/misc/Makefile|   1 +
 drivers/misc/acpi-test.c |  61 ++
 include/acpi.h   |  73 +++
 7 files changed, 405 insertions(+)
 create mode 100644 drivers/bus/acpi.c
 create mode 100644 drivers/misc/acpi-test.c
 create mode 100644 include/acpi.h

-- 
2.20.1


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


[PATCH 2/2] misc: add ACPI test driver

2019-12-04 Thread Ahmad Fatoum
We have a bus driver for ACPI, but no drivers yet. Add a simple (rather
useless) driver that exercises the API, which future drivers can be
based on. As soon as we have proper ACPI drivers, this driver could be
removed again.

Signed-off-by: Ahmad Fatoum 
---
 drivers/misc/Kconfig |  6 
 drivers/misc/Makefile|  1 +
 drivers/misc/acpi-test.c | 61 
 3 files changed, 68 insertions(+)
 create mode 100644 drivers/misc/acpi-test.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 0f736f8bded3..b76198b10af5 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -35,4 +35,10 @@ config UBOOTVAR
  While it can be used standalone, it is best when coupled
  with corresponding filesystem driver.
 
+config ACPI_TEST
+   bool "ACPI Test driver"
+   depends on ACPI
+   help
+ This is a simple Test driver to test the ACPI bus.
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index bc1c01ea4d67..4d92465a1e5e 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_SRAM)  += sram.o
 obj-$(CONFIG_STATE_DRV)+= state.o
 obj-$(CONFIG_DEV_MEM)  += mem.o
 obj-$(CONFIG_UBOOTVAR) += ubootvar.o
+obj-$(CONFIG_ACPI_TEST)+= acpi-test.o
diff --git a/drivers/misc/acpi-test.c b/drivers/misc/acpi-test.c
new file mode 100644
index ..970b435a0eec
--- /dev/null
+++ b/drivers/misc/acpi-test.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Ahmad Fatoum
+ */
+
+#include 
+#include 
+#include 
+
+static const char *profiles[] = {
+   "Unspecified",
+   "Desktop",
+   "Mobile",
+   "Workstation",
+   "Enterprise Server",
+   "SOHO Server",
+   "Applicance PC",
+   "Performance Server",
+   "Tablet",
+};
+
+static int acpi_test_probe(struct device_d *dev)
+{
+   const char *profile = "reserved";
+   u8 *sdt;
+   u8 profileno;
+
+   dev_dbg(dev, "driver initializing...\n");
+
+   sdt = (u8 __force *)dev_request_mem_region_by_name(dev, "SDT");
+   if (IS_ERR(sdt)) {
+   dev_err(dev, "no SDT resource available: %s\n", strerrorp(sdt));
+   return PTR_ERR(sdt);
+   }
+
+   dev_dbg(dev, "SDT is at 0x%p\n", sdt);
+
+   profileno = sdt[45];
+
+   if (profileno < ARRAY_SIZE(profiles))
+   profile = profiles[profileno];
+
+   dev_info(dev, "PM profile is for '%s'\n", profile);
+
+   return 0;
+}
+
+static void acpi_test_remove(struct device_d *dev)
+{
+   dev_info(dev, "FADT driver removed\n");
+}
+
+static struct acpi_driver acpi_test_driver = {
+   .signature = "FACP",
+   .driver = {
+   .name = "acpi-test",
+   .probe = acpi_test_probe,
+   .remove = acpi_test_remove,
+   }
+};
+device_acpi_driver(acpi_test_driver);
-- 
2.20.1


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


[PATCH 0/9] efi: add PCI controller driver

2019-12-04 Thread Ahmad Fatoum
This series adds support for reusing existing barebox PCI drivers under
EFI. This means implementation of the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID,
instead of EFI_PCI_IO_PROTOCOL_GUID, which abstracts the devices and
handles enumeration.

This was tested with the default QEMU x86_64 machine and OVMF (Tianocore)
as UEFI firmware and an emulated 8250_pci (driver included in this
series):

qemu-system-x86_64 -pflash OVMF.fd -device pci-serial,chardev=cdev0 \
-chardev file,id=cdev0,path=COM -nographic /dev/sdb

Driver is written against UEFI Specification 2.1D. This is my first
dabble with PCI controllers, so please take a more thorough look.

Thanks!
Ahmad


Ahmad Fatoum (9):
  efi: add and use new efi_device_has_guid helper
  driver: add missing parentheses around macro argument
  efi: fix off-by-one in mem_malloc_init(..., end)
  x86: efi: lds: don't discard any relocation sections
  PCI: add driver_data member to struct pci_device_id
  PCI: copy over some Linux PCI helpers
  efi: turn set of defines into enumerations
  pci: add EFI PCI root bridge IO protocol driver
  serial: add support for PCI NS16550 UARTs

 arch/x86/mach-efi/elf_x86_64_efi.lds.S |7 +-
 common/efi/efi.c   |2 +-
 drivers/block/efi-block-io.c   |   11 +-
 drivers/efi/Kconfig|1 +
 drivers/efi/efi-device.c   |   11 +-
 drivers/pci/Kconfig|5 +
 drivers/pci/Makefile   |1 +
 drivers/pci/bus.c  |   26 +
 drivers/pci/pci-efi.c  |  311 ++
 drivers/pci/pci-efi.h  |  331 ++
 drivers/serial/Kconfig |8 +
 drivers/serial/Makefile|1 +
 drivers/serial/serial_ns16550_pci.c| 5311 
 include/driver.h   |4 +-
 include/efi.h  |   42 +-
 include/efi/efi-device.h   |   12 +
 include/linux/mod_devicetable.h|1 +
 include/linux/pci.h|   34 +
 18 files changed, 6073 insertions(+), 46 deletions(-)
 create mode 100644 drivers/pci/pci-efi.c
 create mode 100644 drivers/pci/pci-efi.h
 create mode 100644 drivers/serial/serial_ns16550_pci.c

-- 
2.24.0


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


[PATCH 7/9] efi: turn set of defines into enumerations

2019-12-04 Thread Ahmad Fatoum
This allows us to use enum types instead of plain integers ttypes to
hold the values, which is done in a follow up commit.

Signed-off-by: Ahmad Fatoum 
---
 include/efi.h | 42 +++---
 1 file changed, 23 insertions(+), 19 deletions(-)

diff --git a/include/efi.h b/include/efi.h
index 166803a58f39..43c05939513d 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -91,21 +91,23 @@ typedef struct {
  */
 
 /* Memory types: */
-#define EFI_RESERVED_TYPE   0
-#define EFI_LOADER_CODE 1
-#define EFI_LOADER_DATA 2
-#define EFI_BOOT_SERVICES_CODE  3
-#define EFI_BOOT_SERVICES_DATA  4
-#define EFI_RUNTIME_SERVICES_CODE   5
-#define EFI_RUNTIME_SERVICES_DATA   6
-#define EFI_CONVENTIONAL_MEMORY 7
-#define EFI_UNUSABLE_MEMORY 8
-#define EFI_ACPI_RECLAIM_MEMORY 9
-#define EFI_ACPI_MEMORY_NVS10
-#define EFI_MEMORY_MAPPED_IO   11
-#define EFI_MEMORY_MAPPED_IO_PORT_SPACE12
-#define EFI_PAL_CODE   13
-#define EFI_MAX_MEMORY_TYPE14
+enum efi_memory_type {
+   EFI_RESERVED_TYPE,
+   EFI_LOADER_CODE,
+   EFI_LOADER_DATA,
+   EFI_BOOT_SERVICES_CODE,
+   EFI_BOOT_SERVICES_DATA,
+   EFI_RUNTIME_SERVICES_CODE,
+   EFI_RUNTIME_SERVICES_DATA,
+   EFI_CONVENTIONAL_MEMORY,
+   EFI_UNUSABLE_MEMORY,
+   EFI_ACPI_RECLAIM_MEMORY,
+   EFI_ACPI_MEMORY_NVS,
+   EFI_MEMORY_MAPPED_IO,
+   EFI_MEMORY_MAPPED_IO_PORT_SPACE,
+   EFI_PAL_CODE,
+   EFI_MAX_MEMORY_TYPE
+};
 
 /* Attribute values: */
 #define EFI_MEMORY_UC  ((u64)0x0001ULL)/* uncached */
@@ -124,10 +126,12 @@ typedef   struct {
 /*
  * Allocation types for calls to boottime->allocate_pages.
  */
-#define EFI_ALLOCATE_ANY_PAGES 0
-#define EFI_ALLOCATE_MAX_ADDRESS   1
-#define EFI_ALLOCATE_ADDRESS   2
-#define EFI_MAX_ALLOCATE_TYPE  3
+enum efi_allocate_type {
+   EFI_ALLOCATE_ANY_PAGES,
+   EFI_ALLOCATE_MAX_ADDRESS,
+   EFI_ALLOCATE_ADDRESS,
+   EFI_MAX_ALLOCATE_TYPE
+};
 
 typedef int (*efi_freemem_callback_t) (u64 start, u64 end, void *arg);
 
-- 
2.24.0


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


[PATCH 2/9] driver: add missing parentheses around macro argument

2019-12-04 Thread Ahmad Fatoum
Currently, the macro can't be used for more complex expressions
like _dev->dev. Fix this by adding the missing parentheses.

Signed-off-by: Ahmad Fatoum 
---
 include/driver.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/driver.h b/include/driver.h
index 300603fa3277..ad59ce90c3a3 100644
--- a/include/driver.h
+++ b/include/driver.h
@@ -155,12 +155,12 @@ int unregister_device(struct device_d *);
 /* Iterate over a devices children
  */
 #define device_for_each_child(dev, child) \
-   list_for_each_entry(child, >children, sibling)
+   list_for_each_entry(child, &(dev)->children, sibling)
 
 /* Iterate over a devices children - Safe against removal version
  */
 #define device_for_each_child_safe(dev, tmpdev, child) \
-   list_for_each_entry_safe(child, tmpdev, >children, sibling)
+   list_for_each_entry_safe(child, tmpdev, &(dev)->children, sibling)
 
 /* Iterate through the devices of a given type. if last is NULL, the
  * first device of this type is returned. Put this pointer in as
-- 
2.24.0


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


Re: [PATCH] net: designware: eqos: remove done TODO

2019-12-04 Thread Ahmad Fatoum
Hello Sascha,

On 11/15/19 2:33 PM, Sascha Hauer wrote:
> On Thu, Nov 14, 2019 at 02:28:08PM +0100, Ahmad Fatoum wrote:
>> The todo split comment is a left-over from refactoring. Remove it.
>>
>> Signed-off-by: Ahmad Fatoum 
>> ---
>>  drivers/net/designware_stm32.c | 1 -
>>  1 file changed, 1 deletion(-)
> 
> Applied, thanks

I can't find this commit in upstream/next and the string still exists.
Could you take a look?

Thanks,
Ahmad


-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


Re: [PATCH 0/2] bus: efi: add basic ACPI bus infrastructure

2019-12-04 Thread Ahmad Fatoum
On 12/4/19 3:07 PM, Ahmad Fatoum wrote:
> BIOS and barebox would only need to implement the H/W.

s{H/W}{interface}


-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


[PATCH 2/3] ARM: i.MX: introduce imx_image_rule variable for code deduplication

2019-12-04 Thread Ahmad Fatoum
The next patch will add the .imxcfg file as a rule prerequisite, so the
target is rebuilt if it changes. Instead of duplicating it in all rules,
factor out the common parts into a imx_image_rule variable.

No functional change.

Signed-off-by: Ahmad Fatoum 
---
 images/Makefile.imx | 32 +++-
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/images/Makefile.imx b/images/Makefile.imx
index 53d4ac8202c5..078b6b9d6a93 100644
--- a/images/Makefile.imx
+++ b/images/Makefile.imx
@@ -23,28 +23,18 @@ endef
 # %.imximg - convert into i.MX image
 # 
 
-$(obj)/%.imximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(@F)),)
-
-$(obj)/%.pimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.pimximg,%.imximg,$(@F))),\
-   -p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)))
-
-$(obj)/%.psimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.psimximg,%.imximg,$(@F))),\
-   -p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)) -s)
-
-$(obj)/%.simximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.simximg,%.imximg,$(@F))),-s)
-
-$(obj)/%.usimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.usimximg,%.imximg,$(@F))),-u -s)
-
-$(obj)/%.esimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-e -s)
+define imx_image_rule
+$$(obj)/%.$(strip $(1)): $$(obj)/% FORCE
+   $$(call if_changed,imx_image,$$(CFG_$$(patsubst %.$(strip 
$(1)),%.imximg,$$(@F))),$(strip $(2)))
+endef
 
-$(obj)/%.esimximg.dek: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-e -s)
+$(eval $(call imx_image_rule,imximg))
+$(eval $(call imx_image_rule,pimximg, -p $($(patsubst 
$(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<
+$(eval $(call imx_image_rule,psimximg, -p $($(patsubst 
$(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)) -s))
+$(eval $(call imx_image_rule,simximg, -s))
+$(eval $(call imx_image_rule,usimximg, -u -s))
+$(eval $(call imx_image_rule,esimximg, -e -s))
+$(eval $(call imx_image_rule,esimximg.dek, -e -s))
 
 .SECONDEXPANSION:
 $(obj)/%.img.dek: $(obj)/$$(FILE_$$(@F))
-- 
2.24.0


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


[PATCH 3/3] ARM: i.MX: rebuild .imximg if DCD table in .imxcfg changes

2019-12-04 Thread Ahmad Fatoum
So far changing the DCD table didn't trigger a rerun of the i.MX
image utility. To fix this, we need to have the DCD table as prerequisite
to the .imximg rule. The file name is contained in $(CFG_$(@F)), but
can't be used directly because $@ (and by extension @F) has no value
when first expanded in the read-in phase. If we expand a second time
during the target-update phase however, we would get the correct value.

GNU make provides .SECONDEXPANSION to expand all following prerequisites
a second time. Use it to have changes to the DCD table rebuild the
image.

Because we are now using imx_image_rule to generate the target, we must
escape each $ one more time to arrive at (CFG_(@F)).

In the final step, we replace (@F) with %.imximg, so we support the
rules not ending in .imximg as well.

Dependency file generation is still broken however and changed to headers
included in DCD tables won't be caught, but this functionality can be
fixed in a separate patch.

Signed-off-by: Ahmad Fatoum 
---
 images/Makefile.imx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/images/Makefile.imx b/images/Makefile.imx
index 078b6b9d6a93..c34d72eb1b59 100644
--- a/images/Makefile.imx
+++ b/images/Makefile.imx
@@ -23,8 +23,9 @@ endef
 # %.imximg - convert into i.MX image
 # 
 
+.SECONDEXPANSION:
 define imx_image_rule
-$$(obj)/%.$(strip $(1)): $$(obj)/% FORCE
+$$(obj)/%.$(strip $(1)): $$(obj)/% (CFG_%.imximg) FORCE
$$(call if_changed,imx_image,$$(CFG_$$(patsubst %.$(strip 
$(1)),%.imximg,$$(@F))),$(strip $(2)))
 endef
 
@@ -36,7 +37,6 @@ $(eval $(call imx_image_rule,usimximg, -u -s))
 $(eval $(call imx_image_rule,esimximg, -e -s))
 $(eval $(call imx_image_rule,esimximg.dek, -e -s))
 
-.SECONDEXPANSION:
 $(obj)/%.img.dek: $(obj)/$$(FILE_$$(@F))
$(Q)if [ -z $(FILE_$(@F)) ]; then echo "FILE_$(@F) empty!"; false; fi
$(call if_changed,shipped)
-- 
2.24.0


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


[PATCH 1/3] images: i.MX: rearrange image rules in preparation for boilerplate removal

2019-12-04 Thread Ahmad Fatoum
The following commit will introduce a variable define to remove the
duplication in the different [supe]*imximg rules.

Prepare for this by rearranging the command line flags to line up with
the letters in the extension (i.e. -e -s for esimximg instead of -s -e)
and by splitting off a multi-target rule into two.

The former improves readability when the define is introduced, as it is
then easy to see the correspondence between extension and arguments.

The latter is needed because we will call the variable for each target.

No functional change.

Signed-off-by: Ahmad Fatoum 
---
 images/Makefile.imx | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/images/Makefile.imx b/images/Makefile.imx
index 6572474e19c8..53d4ac8202c5 100644
--- a/images/Makefile.imx
+++ b/images/Makefile.imx
@@ -31,17 +31,20 @@ $(obj)/%.pimximg: $(obj)/% FORCE
-p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)))
 
 $(obj)/%.psimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.psimximg,%.imximg,$(@F))),-s \
-   -p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)))
+   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.psimximg,%.imximg,$(@F))),\
+   -p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)) -s)
 
 $(obj)/%.simximg: $(obj)/% FORCE
$(call if_changed,imx_image,$(CFG_$(patsubst 
%.simximg,%.imximg,$(@F))),-s)
 
 $(obj)/%.usimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.usimximg,%.imximg,$(@F))),-s -u)
+   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.usimximg,%.imximg,$(@F))),-u -s)
+
+$(obj)/%.esimximg: $(obj)/% FORCE
+   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-e -s)
 
-$(obj)/%.esimximg $(obj)/%.esimximg.dek: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-s -e)
+$(obj)/%.esimximg.dek: $(obj)/% FORCE
+   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-e -s)
 
 .SECONDEXPANSION:
 $(obj)/%.img.dek: $(obj)/$$(FILE_$$(@F))
-- 
2.24.0


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


Re: [PATCH 8/9] pci: add EFI PCI root bridge IO protocol driver

2019-12-09 Thread Ahmad Fatoum
On 12/4/19 1:56 PM, Ahmad Fatoum wrote:
> UEFI 2.1D specifies two protocols for abstracting both the PCI host bus
> controller and for PCI devices. The protocol for PCI devices provides
> function pointers for accessing IO Port, Memory and PCI configuration
> space, among others. The protocol for bus controllers provides the
> ability to read the root bridge's PCI configuration space and to query
> resources.
> 
> In barebox, we would want to reuse existing PCI drivers unmodified, so
> we utilize the root bridge protocol, unlike most other EFI payloads.

Please dismiss this patch for now. While it works on QEMU,
it doesn't handle address space descriptors of zero size (easily fixable)
and the PCI bridges on my laptop (not so easily fixable).

I'll resend when I had time to figure it out.

Cheers
Ahmad

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


[PATCH v2 3/3] ARM: i.MX: rebuild .imximg if DCD table in .imxcfg changes

2019-12-09 Thread Ahmad Fatoum
So far changing the DCD table didn't trigger a rerun of the i.MX
image utility. To fix this, we need to have the DCD table as prerequisite
to the .imximg rule. The file name is contained in $(CFG_$(@F)), but
can't be used directly because $@ (and by extension @F) has no value
when first expanded in the read-in phase. If we expand a second time
during the target-update phase however, we would get the correct value.

GNU make provides .SECONDEXPANSION to expand all following prerequisites
a second time. Use it to have changes to the DCD table rebuild the
image.

Because we are now using imx_image_rule to generate the target, we must
escape each $ one more time to arrive at (CFG_(@F)).

In the final step, we replace (@F) with %.imximg, so we support the
rules not ending in .imximg as well.

Dependency file generation is still broken however and changed to headers
included in DCD tables won't be caught, but this functionality can be
fixed in a separate patch.

Signed-off-by: Ahmad Fatoum 
---
No changes in v2.
---
 images/Makefile.imx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/images/Makefile.imx b/images/Makefile.imx
index 80e1acf941c5..c4b1bfb35e9f 100644
--- a/images/Makefile.imx
+++ b/images/Makefile.imx
@@ -5,9 +5,10 @@
 # %.imximg - convert into i.MX image
 # 
 
+.SECONDEXPANSION:
 define imx_image_rule
 $(eval
-$$(obj)/%.$(strip $(1)): $$(obj)/% FORCE
+$$(obj)/%.$(strip $(1)): $$(obj)/% (CFG_%.imximg) FORCE
$$(call if_changed,imx_image,$$(CFG_$$(patsubst %.$(strip 
$(1)),%.imximg,$$(@F))),$(strip $(2)))
 )
 endef
@@ -20,7 +21,6 @@ $(call imx_image_rule,usimximg, -u -s)
 $(call imx_image_rule,esimximg, -e -s)
 $(call imx_image_rule,esimximg.dek, -e -s)
 
-.SECONDEXPANSION:
 $(obj)/%.img.dek: $(obj)/$$(FILE_$$(@F))
$(Q)if [ -z $(FILE_$(@F)) ]; then echo "FILE_$(@F) empty!"; false; fi
$(call if_changed,shipped)
-- 
2.24.0


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


[PATCH v2 2/3] ARM: i.MX: introduce imx_image_rule variable for code deduplication

2019-12-09 Thread Ahmad Fatoum
The next patch will add the .imxcfg file as a rule prerequisite, so the
target is rebuilt if it changes. Instead of duplicating it in all rules,
factor out the common parts into a imx_image_rule variable.

As the arguments are now going through an eval, any use of $ must be
escaped with another $ to become $$.

No functional change.

Signed-off-by: Ahmad Fatoum 
---
v1 -> v2:
  * escaped PBL_MEMORY_SIZE dollars to fix imx_v8_defconfig pimximg build
  * moved eval into define, so it doesn't need replication for each
extension
---
 images/Makefile.imx | 36 ++--
 1 file changed, 14 insertions(+), 22 deletions(-)

diff --git a/images/Makefile.imx b/images/Makefile.imx
index daf0cf1fcfaa..80e1acf941c5 100644
--- a/images/Makefile.imx
+++ b/images/Makefile.imx
@@ -5,28 +5,20 @@
 # %.imximg - convert into i.MX image
 # 
 
-$(obj)/%.imximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(@F)),)
-
-$(obj)/%.pimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.pimximg,%.imximg,$(@F))),\
-   -p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)))
-
-$(obj)/%.psimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.psimximg,%.imximg,$(@F))),\
-   -p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)) -s)
-
-$(obj)/%.simximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.simximg,%.imximg,$(@F))),-s)
-
-$(obj)/%.usimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.usimximg,%.imximg,$(@F))),-u -s)
-
-$(obj)/%.esimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-e -s)
-
-$(obj)/%.esimximg.dek: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-e -s)
+define imx_image_rule
+$(eval
+$$(obj)/%.$(strip $(1)): $$(obj)/% FORCE
+   $$(call if_changed,imx_image,$$(CFG_$$(patsubst %.$(strip 
$(1)),%.imximg,$$(@F))),$(strip $(2)))
+)
+endef
+
+$(call imx_image_rule,imximg)
+$(call imx_image_rule,pimximg, -p $$($$(patsubst 
$$(obj)/%.pblb,PBL_MEMORY_SIZE_%,$$<)))
+$(call imx_image_rule,psimximg, -p $$($$(patsubst 
$$(obj)/%.pblb,PBL_MEMORY_SIZE_%,$$<)) -s)
+$(call imx_image_rule,simximg, -s)
+$(call imx_image_rule,usimximg, -u -s)
+$(call imx_image_rule,esimximg, -e -s)
+$(call imx_image_rule,esimximg.dek, -e -s)
 
 .SECONDEXPANSION:
 $(obj)/%.img.dek: $(obj)/$$(FILE_$$(@F))
-- 
2.24.0


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


Re: [PATCH 2/3] ARM: i.MX: introduce imx_image_rule variable for code deduplication

2019-12-09 Thread Ahmad Fatoum
On 12/9/19 2:31 PM, Sascha Hauer wrote:
> On Wed, Dec 04, 2019 at 05:01:59PM +0100, Ahmad Fatoum wrote:
>> The next patch will add the .imxcfg file as a rule prerequisite, so the
>> target is rebuilt if it changes. Instead of duplicating it in all rules,
>> factor out the common parts into a imx_image_rule variable.
>>
>> No functional change.

intended*. :-D

> 
> Famous last words...
> 
> This breaks imx_v8_defconfig build with:
> 
>   IMX-IMG images/start_nxp_imx8mq_evk.pblb.pimximg
>   image name not given

Will check.

Cheers,
Ahmad


-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


[PATCH v2 1/3] images: i.MX: rearrange image rules in preparation for boilerplate removal

2019-12-09 Thread Ahmad Fatoum
The following commit will introduce a variable define to remove the
duplication in the different [supe]*imximg rules.

Prepare for this by rearranging the command line flags to line up with
the letters in the extension (i.e. -e -s for esimximg instead of -s -e)
and by splitting off a multi-target rule into two.

The former improves readability when the define is introduced, as it is
then easy to see the correspondence between extension and arguments.

The latter is needed because we will call the variable for each target.

No functional change.

Signed-off-by: Ahmad Fatoum 
---
No changes in v2.
---
 images/Makefile.imx | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/images/Makefile.imx b/images/Makefile.imx
index a8f8a9b7d622..daf0cf1fcfaa 100644
--- a/images/Makefile.imx
+++ b/images/Makefile.imx
@@ -13,17 +13,20 @@ $(obj)/%.pimximg: $(obj)/% FORCE
-p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)))
 
 $(obj)/%.psimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.psimximg,%.imximg,$(@F))),-s \
-   -p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)))
+   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.psimximg,%.imximg,$(@F))),\
+   -p $($(patsubst $(obj)/%.pblb,PBL_MEMORY_SIZE_%,$<)) -s)
 
 $(obj)/%.simximg: $(obj)/% FORCE
$(call if_changed,imx_image,$(CFG_$(patsubst 
%.simximg,%.imximg,$(@F))),-s)
 
 $(obj)/%.usimximg: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.usimximg,%.imximg,$(@F))),-s -u)
+   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.usimximg,%.imximg,$(@F))),-u -s)
+
+$(obj)/%.esimximg: $(obj)/% FORCE
+   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-e -s)
 
-$(obj)/%.esimximg $(obj)/%.esimximg.dek: $(obj)/% FORCE
-   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-s -e)
+$(obj)/%.esimximg.dek: $(obj)/% FORCE
+   $(call if_changed,imx_image,$(CFG_$(patsubst 
%.esimximg,%.imximg,$(@F))),-e -s)
 
 .SECONDEXPANSION:
 $(obj)/%.img.dek: $(obj)/$$(FILE_$$(@F))
-- 
2.24.0


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


Re: [PATCH 1/2] ARM: omap: support for WAGO PFC200v3 750-821x

2019-12-13 Thread Ahmad Fatoum
Hello Roland,

On 12/11/19 9:02 PM, Roland Hieber wrote:
> diff --git a/arch/arm/boards/wago-pfc-am335x/ram-timings.h 
> b/arch/arm/boards/wago-pfc-am335x/ram-timings.h
> new file mode 100644
> index ..cc3d518f0c27
> --- /dev/null
> +++ b/arch/arm/boards/wago-pfc-am335x/ram-timings.h
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2015 Wadim Egorov, PHYTEC Messtechnik GmbH
> + *
> + * Copyright (C) 2018 WAGO Kontakttechnik GmbH & Co. KG 
> 
> + * Author: Oleg Karfich 
> + */
> +
> +#ifndef __RAM_TIMINGS_H
> +#define __RAM_TIMINGS_H
> +
> +#define DDR_IOCTRL   0x18B
> +
> +struct am335x_sdram_timings {
> + struct am33xx_emif_regs regs;
> + struct am33xx_ddr_data data;
> + struct am33xx_cmd_control cmd_ctrl;
> +};
> +
> +enum {
> + PFC_DDR3_256MB,
> + PFC_DDR3_512MB,
> +};
> +
> +struct am335x_sdram_timings pfc_timings[] = {

This should be static.

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


[PATCH] led: pca955x: remove ineffectual assignment

2019-12-12 Thread Ahmad Fatoum
the .num member of struct led is a 'private' member populated by
led_register. Populating it has no effect because it's always
overwritten. Remove the assignment.

Signed-off-by: Ahmad Fatoum 
---
 drivers/led/led-pca955x.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/led/led-pca955x.c b/drivers/led/led-pca955x.c
index 9c4f7967fb28..27fefce8d524 100644
--- a/drivers/led/led-pca955x.c
+++ b/drivers/led/led-pca955x.c
@@ -316,7 +316,6 @@ led_pca955x_pdata_of_init(struct device_node *np, struct 
pca955x *pca955x)
 
pca955x_led->led_cdev.name = pca955x_led->name;
pca955x_led->led_cdev.set = pca955x_led_set;
-   pca955x_led->led_cdev.num = pca955x_led->led_num;
pca955x_led->led_cdev.max_value = 255;
 
err = led_register(_led->led_cdev);
-- 
2.24.0


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


[PATCH] commands: led: print actual error code when led_set fails

2019-12-12 Thread Ahmad Fatoum
If led_set fails, the error code is the return value, not errno.
Fix this. While at replace the magic value in the command return code.

Signed-off-by: Ahmad Fatoum 
---
 commands/led.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/commands/led.c b/commands/led.c
index a53f0df6a200..b608fcfa2cdb 100644
--- a/commands/led.c
+++ b/commands/led.c
@@ -101,8 +101,8 @@ static int do_led(int argc, char *argv[])
 
ret = led_set(led, value);
if (ret < 0) {
-   perror("led");
-   return 1;
+   printf("led: %s\n", strerror(-ret));
+   return COMMAND_ERROR;
}
 
return 0;
-- 
2.24.0


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


Re: [PATCH] ARM: dts: imx6qdl: phycore: Remove emmc vmmc-supply

2019-12-05 Thread Ahmad Fatoum
Hi,

On 12/5/19 2:08 PM, Stefan Riedmüller wrote:
> What about regulators that are marked as regulator-always-on but need voltage 
> adjustments? Or isn't this a real use case for the bootloader?

If someone absolutely need the voltage adjustments, they'll have to implement
a proper regulator driver to realize it[1]. The [barebox,]regulator-always-on
handling I suggest, is only a fallback if there is no regulator found.


Cheers
Ahmad

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


Re: [PATCH] ARM: dts: imx6qdl: phycore: Remove emmc vmmc-supply

2019-12-05 Thread Ahmad Fatoum
Hello,

On 12/5/19 9:07 AM, Sascha Hauer wrote:
> On Tue, Dec 03, 2019 at 02:48:41PM +0100, Stefan Riedmueller wrote:
>> There is no driver for the eMMC's vmmc-supply regulator in the barebox.
>> Use a dummy regulator instead by simply deleting the vmmc-supply
>> property.
>>
>> Signed-off-by: Stefan Riedmueller 
>> ---
>>  arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi 
>> b/arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi
>> index 69f252b42382..974e271f453d 100644
>> --- a/arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi
>> +++ b/arch/arm/dts/imx6qdl-phytec-phycore-som.dtsi
>> @@ -112,6 +112,7 @@
>>  };
>>  
>>   {
>> +/delete-property/ vmmc-supply;
> 
> I don't like this approach very much. It's fine for barebox, but leads
> to problems once you start Linux with the barebox device tree. I'd
> rather go with the unmodified device trees (apart from the things
> barebox changes to the device trees in order to start Linux).

How about a barebox,regulator-always-on property? If the regulator is 
unnecessary,
it basically means you can assume it's always on when barebox runs.

If regulator_get is called with a property that points to such a node, a dummy
regulator is returned with which enable is a no-op. Additionally, do the same
for regulator-always-on, so the in-barebox device tree only needs to mark
non regulator-always-on that are expected to be always on when it runs due to
strapping/fuses as barebox,regulator-always-on.

Thoughts?
Ahmad

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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


Re: MFGTools from NXP

2019-10-15 Thread Ahmad Fatoum
Hello,

On 10/15/19 4:07 PM, Mihaita Ivascu wrote:
> Hello,
> 
>does anyone have experience with using imx_usb_loader to flash the
> barebox on a NAND(mtd partition)? If yes some reference scripts would
> be helpful for me. Or where should I look for an example?

Check out this thread:
https://www.spinics.net/lists/u-boot-v2/msg37199.html

TL;DR: imx_usb_loader to get barebox into SDRAM, then Android Fastboot for 
flashing

> 
> Thanks,
>   Mihaita Ivascu
> 
> 



-- 
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- |

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


[PATCH v2 3/8] pinctrl: stm32: parse pinctrl nodes without subnodes as well

2019-10-27 Thread Ahmad Fatoum
The bindings allow the pinmux node to occur directly in the node under
the pin controller as well. Check for this and support both types of
pinctrl specification.

Signed-off-by: Ahmad Fatoum 
---
 drivers/pinctrl/pinctrl-stm32.c | 180 ++--
 1 file changed, 99 insertions(+), 81 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-stm32.c b/drivers/pinctrl/pinctrl-stm32.c
index c199d74846e8..cdaed510c564 100644
--- a/drivers/pinctrl/pinctrl-stm32.c
+++ b/drivers/pinctrl/pinctrl-stm32.c
@@ -87,110 +87,128 @@ static inline u32 stm32_gpio_get_alt(u32 function)
return 0;
 }
 
-static int stm32_pinctrl_set_state(struct pinctrl_device *pdev, struct 
device_node *group)
+static int __stm32_pinctrl_set_state(struct device_d *dev, struct device_node 
*pins)
 {
-   struct stm32_pinctrl *pinctrl = to_stm32_pinctrl(pdev);
-   struct device_node *pins;
int ret;
 
-   ret = hwspinlock_lock_timeout(>hws, 10);
-   if (ret == -ETIMEDOUT) {
-   dev_err(pdev->dev, "hw spinlock timeout\n");
-   return ret;
+   int num_pins = 0, i;
+   u32 slew_rate;
+   bool adjust_slew_rate = false;
+   enum stm32_pin_bias bias = -1;
+   enum stm32_pin_out_type out_type = -1;
+   enum { PIN_INPUT, PIN_OUTPUT_LOW, PIN_OUTPUT_HIGH } dir = -1;
+
+   of_get_property(pins, "pinmux", _pins);
+   num_pins /= sizeof(__be32);
+   if (!num_pins) {
+   dev_err(dev, "Invalid pinmux property in %s\n",
+   pins->full_name);
+   return -EINVAL;
}
 
-   for_each_child_of_node(group, pins) {
-   int num_pins = 0, i;
-   u32 slew_rate;
-   bool adjust_slew_rate = false;
-   enum stm32_pin_bias bias = -1;
-   enum stm32_pin_out_type out_type = -1;
-   enum { PIN_INPUT, PIN_OUTPUT_LOW, PIN_OUTPUT_HIGH } dir = -1;
-
-   of_get_property(pins, "pinmux", _pins);
-   num_pins /= sizeof(__be32);
-   if (!num_pins) {
-   dev_err(pdev->dev, "Invalid pinmux property in %s\n",
-   pins->full_name);
-   return -EINVAL;
-   }
-
-   ret = of_property_read_u32(pins, "slew-rate", _rate);
-   if (!ret)
-   adjust_slew_rate = true;
-
-   if (of_get_property(pins, "bias-disable", NULL))
-   bias = STM32_PIN_NO_BIAS;
-   else if (of_get_property(pins, "bias-pull-up", NULL))
-   bias = STM32_PIN_PULL_UP;
-   else if (of_get_property(pins, "bias-pull-down", NULL))
-   bias = STM32_PIN_PULL_DOWN;
+   ret = of_property_read_u32(pins, "slew-rate", _rate);
+   if (!ret)
+   adjust_slew_rate = true;
+
+   if (of_get_property(pins, "bias-disable", NULL))
+   bias = STM32_PIN_NO_BIAS;
+   else if (of_get_property(pins, "bias-pull-up", NULL))
+   bias = STM32_PIN_PULL_UP;
+   else if (of_get_property(pins, "bias-pull-down", NULL))
+   bias = STM32_PIN_PULL_DOWN;
+
+   if (of_get_property(pins, "drive-push-pull", NULL))
+   out_type = STM32_PIN_OUT_PUSHPULL;
+   else if (of_get_property(pins, "drive-open-drain", NULL))
+   out_type = STM32_PIN_OUT_OPENDRAIN;
+
+   if (of_get_property(pins, "input-enable", NULL))
+   dir = PIN_INPUT;
+   else if (of_get_property(pins, "output-low", NULL))
+   dir = PIN_OUTPUT_LOW;
+   else if (of_get_property(pins, "output-high", NULL))
+   dir = PIN_OUTPUT_HIGH;
+
+   dev_dbg(dev, "%s: multiplexing %d pins\n", pins->full_name, num_pins);
+
+   for (i = 0; i < num_pins; i++) {
+   struct stm32_gpio_bank *bank = NULL;
+   u32 pinfunc, mode, alt;
+   unsigned func;
+   int offset;
+
+   ret = of_property_read_u32_index(pins, "pinmux",
+   i, );
+   if (ret)
+   return ret;
 
-   if (of_get_property(pins, "drive-push-pull", NULL))
-   out_type = STM32_PIN_OUT_PUSHPULL;
-   else if (of_get_property(pins, "drive-open-drain", NULL))
-   out_type = STM32_PIN_OUT_OPENDRAIN;
+   func = STM32_GET_PIN_FUNC(pinfunc);
+   offset = stm32_gpio_pin(STM32_GET_PIN_NO(pinfunc), );
+   if (offset < 0)
+   return -ENODEV;
 
-   if (of_get_property(pins, "input-enable", NULL))
-   dir = PIN_INPUT;
-   el

[PATCH v2 2/8] pinctrl: demote dev_info on successful probes to dev_dbg

2019-10-27 Thread Ahmad Fatoum
The SoC's pin controller is virtually always built and probed, so
there's is little information to gain from the fact it was successfully
probed. Have the success message show up as debug message to reduce probe
clutter like this:

NOTICE: stm32-pinctrl soc:pin-control...@50002000.of: pinctrl/gpio 
driver registered
NOTICE: stm32-pinctrl soc:pin-controlle...@54004000.of: pinctrl/gpio 
driver registered

Signed-off-by: Ahmad Fatoum 
---
 drivers/pinctrl/pinctrl-at91-pio4.c | 4 ++--
 drivers/pinctrl/pinctrl-bcm2835.c   | 2 +-
 drivers/pinctrl/pinctrl-stm32.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
b/drivers/pinctrl/pinctrl-at91-pio4.c
index 9bc259f84cca..b527114f1ba0 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -260,7 +260,7 @@ static int pinctrl_at91_pio4_gpiochip_add(struct device_d 
*dev,
return ret;
}
 
-   dev_info(dev, "gpio driver registered\n");
+   dev_dbg(dev, "gpio driver registered\n");
 
return 0;
 }
@@ -290,7 +290,7 @@ static int pinctrl_at91_pio4_probe(struct device_d *dev)
if (ret)
return ret;
 
-   dev_info(dev, "pinctrl driver registered\n");
+   dev_dbg(dev, "pinctrl driver registered\n");
 
if (of_get_property(np, "gpio-controller", NULL))
return pinctrl_at91_pio4_gpiochip_add(dev, pinctrl);
diff --git a/drivers/pinctrl/pinctrl-bcm2835.c 
b/drivers/pinctrl/pinctrl-bcm2835.c
index 5fd5740e8184..b8e9b60372e3 100644
--- a/drivers/pinctrl/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/pinctrl-bcm2835.c
@@ -171,7 +171,7 @@ static int bcm2835_gpio_probe(struct device_d *dev)
goto err;
}
 
-   dev_info(dev, "probed gpiochip%d with base %d\n", dev->id, 
bcmgpio->chip.base);
+   dev_dbg(dev, "probed gpiochip%d with base %d\n", dev->id, 
bcmgpio->chip.base);
 
if (IS_ENABLED(CONFIG_PINCTRL)) {
ret = pinctrl_register(>pctl);
diff --git a/drivers/pinctrl/pinctrl-stm32.c b/drivers/pinctrl/pinctrl-stm32.c
index ab121998a37f..c199d74846e8 100644
--- a/drivers/pinctrl/pinctrl-stm32.c
+++ b/drivers/pinctrl/pinctrl-stm32.c
@@ -401,7 +401,7 @@ static int stm32_pinctrl_probe(struct device_d *dev)
}
}
 
-   dev_info(dev, "pinctrl/gpio driver registered\n");
+   dev_dbg(dev, "pinctrl/gpio driver registered\n");
 
return 0;
 }
-- 
2.23.0


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


[PATCH v2 4/8] ARM: sm: document SMC/PSCI related options

2019-10-27 Thread Ahmad Fatoum
At least to me, the difference between these options were confusing at
first. Clear this up.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/Kconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 725ea12a8c57..d4947cef5c98 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -427,10 +427,14 @@ config ARM_SEMIHOSTING
 
 config ARM_SMCCC
bool
+   help
+ This option enables barebox to invoke ARM secure monitor calls.
 
 config ARM_SECURE_MONITOR
select ARM_SMCCC
bool
+   help
+ This option enables barebox to service ARM secure monitor calls.
 
 config ARM_PSCI_OF
bool
@@ -442,7 +446,7 @@ config ARM_PSCI
select ARM_PSCI_OF
help
  PSCI is used for controlling secondary CPU cores on some systems. Say
- yes here if you have one of these.
+ yes here if you want barebox to service PSCI calls on such systems.
 
 config ARM_PSCI_DEBUG
bool "Enable PSCI debugging"
-- 
2.23.0


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


[PATCH v2 7/8] ARM: stm32mp: dk2: add barebox SD-Card update handler

2019-10-27 Thread Ahmad Fatoum
Now with the SD/MMC controller supported, lets add a bbu handler, so we
can use it to update the second stage boot loader partition.

While doing this, I noticed that making use of the bus-width = <4>
property in the device tree now makes mmc usage fail when reading the
environment:

  ERROR: error SDMMC_STA_DCRCFAIL (0x81042) for cmd 18
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
  WARNING: stm32_sdmmc2_send_cmd: cmd 12 failed, retrying ...
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
  WARNING: stm32_sdmmc2_send_cmd: cmd 12 failed, retrying ...
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
  WARNING: stm32_sdmmc2_send_cmd: cmd 12 failed, retrying ...
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12

We'll want to fix this eventually, but for now force the bus width to 1
and print a notice to the console that we've done so. This is not
enough, however because it then fails at loading the kernel from MMC:

  ERROR: Time out on waiting for SDMMC_STA. cmd 18
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x804) for cmd 12
  WARNING: stm32_sdmmc2_send_cmd: cmd 18 failed, retrying ...

Fixing the max frequency at 208 MHz fixes this. So do that and print a
notice for it as well.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/boards/stm32mp157c-dk2/board.c  | 14 ++
 arch/arm/dts/stm32mp157a-dk1.dtsi|  4 
 arch/arm/mach-stm32mp/include/mach/bbu.h | 14 ++
 drivers/mci/stm32_sdmmc2.c   | 15 +--
 4 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/bbu.h

diff --git a/arch/arm/boards/stm32mp157c-dk2/board.c 
b/arch/arm/boards/stm32mp157c-dk2/board.c
index 9cb861af85d8..5bc88781c7ba 100644
--- a/arch/arm/boards/stm32mp157c-dk2/board.c
+++ b/arch/arm/boards/stm32mp157c-dk2/board.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int dk2_mem_init(void)
 {
@@ -15,3 +16,16 @@ static int dk2_mem_init(void)
return 0;
 }
 mem_initcall(dk2_mem_init);
+
+static int dk2_postcore_init(void)
+{
+   if (!of_machine_is_compatible("st,stm32mp157c-dk2"))
+   return 0;
+
+   stm32mp_bbu_mmc_register_handler("sd", "/dev/mmc0.ssbl",
+BBU_HANDLER_FLAG_DEFAULT);
+
+   return 0;
+}
+
+postcore_initcall(dk2_postcore_init);
diff --git a/arch/arm/dts/stm32mp157a-dk1.dtsi 
b/arch/arm/dts/stm32mp157a-dk1.dtsi
index 7f3b6fcf55ae..05a39d32e2fa 100644
--- a/arch/arm/dts/stm32mp157a-dk1.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1.dtsi
@@ -8,6 +8,10 @@
 #include 
 
 / {
+   aliases {
+   mmc0 = 
+   };
+
chosen {
environment {
compatible = "barebox,environment";
diff --git a/arch/arm/mach-stm32mp/include/mach/bbu.h 
b/arch/arm/mach-stm32mp/include/mach/bbu.h
new file mode 100644
index ..8b9504400e9e
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/bbu.h
@@ -0,0 +1,14 @@
+#ifndef MACH_STM32MP_BBU_H_
+#define MACH_STM32MP_BBU_H_
+
+#include 
+
+static inline int stm32mp_bbu_mmc_register_handler(const char *name,
+  const char *devicefile,
+  unsigned long flags)
+{
+   return bbu_register_std_file_update(name, flags, devicefile,
+   filetype_stm32_image_v1);
+}
+
+#endif /* MACH_STM32MP_BBU_H_ */
diff --git a/drivers/mci/stm32_sdmmc2.c b/drivers/mci/stm32_sdmmc2.c
index 7346c8a3f5d6..3f0fff1258c0 100644
--- a/drivers/mci/stm32_sdmmc2.c
+++ b/drivers/mci/stm32_sdmmc2.c
@@ -627,11 +627,22 @@ static int stm32_sdmmc2_probe(struct amba_device *adev,
if (IS_ERR(priv->reset_ctl))
priv->reset_ctl = NULL;
 
+   mci_of_parse(>mci);
+
mci->f_min = 40;
-   /* f_max is taken from kernel v5.3 variant_stm32_sdmmc */
-   mci->f_max = 20800;
mci->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
 
+   if (mci->f_max != 20800) {
+   /* f_max is taken from kernel v5.3 variant_stm32_sdmmc */
+   dev_notice(dev, "Fixing max-frequency to 208 MHz due to driver 
limitation\n");
+   mci->f_max = 20800;
+   }
+
+   if (mci->host_caps & (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
+   dev_notice(dev, "Fixing bus-width to 1 due to driver 
limitation\n");
+   mci->host_caps &= ~(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA);
+   }
+
return mci_register(>mci);
 
 priv_free:
-- 
2.23.0


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


[PATCH v2 8/8] ARM: stm32mp: implement SoC and boot source identification

2019-10-27 Thread Ahmad Fatoum
The BSEC OTP holds information about SoC type and package.
The Tamp registers hold information from the BootROM about boot
source. Add support for both.

Additionally, the tamp registers can also hold a request from the
operating system about what mode to enter after boot, e.g.
boot-into-recovery. A global function is exported for this, but
unused so far.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/mach-stm32mp/Makefile|   3 +-
 .../mach-stm32mp/include/mach/bootsource.h|  33 +++
 arch/arm/mach-stm32mp/include/mach/revision.h |  32 +++
 arch/arm/mach-stm32mp/init.c  | 260 ++
 4 files changed, 327 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/bootsource.h
 create mode 100644 arch/arm/mach-stm32mp/include/mach/revision.h
 create mode 100644 arch/arm/mach-stm32mp/init.c

diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
index 204cad608f56..6f495288923a 100644
--- a/arch/arm/mach-stm32mp/Makefile
+++ b/arch/arm/mach-stm32mp/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_BOOTM) := stm32image.o
+obj-y := init.o
+obj-$(CONFIG_BOOTM) += stm32image.o
diff --git a/arch/arm/mach-stm32mp/include/mach/bootsource.h 
b/arch/arm/mach-stm32mp/include/mach/bootsource.h
new file mode 100644
index ..1b6f562ac301
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/bootsource.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause */
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef __MACH_STM32_BOOTSOURCE_H__
+#define __MACH_STM32_BOOTSOURCE_H__
+
+enum stm32mp_boot_device {
+   STM32MP_BOOT_FLASH_SD   = 0x10, /* .. 0x13 */
+   STM32MP_BOOT_FLASH_EMMC = 0x20, /* .. 0x23 */
+   STM32MP_BOOT_FLASH_NAND = 0x30,
+   STM32MP_BOOT_FLASH_NAND_FMC = 0x31,
+   STM32MP_BOOT_FLASH_NOR  = 0x40,
+   STM32MP_BOOT_FLASH_NOR_QSPI = 0x41,
+   STM32MP_BOOT_SERIAL_UART= 0x50, /* .. 0x58 */
+   STM32MP_BOOT_SERIAL_USB = 0x60,
+   STM32MP_BOOT_SERIAL_USB_OTG = 0x62,
+};
+
+enum stm32mp_forced_boot_mode {
+   STM32MP_BOOT_NORMAL = 0x00,
+   STM32MP_BOOT_FASTBOOT   = 0x01,
+   STM32MP_BOOT_RECOVERY   = 0x02,
+   STM32MP_BOOT_STM32PROG  = 0x03,
+   STM32MP_BOOT_UMS_MMC0   = 0x10,
+   STM32MP_BOOT_UMS_MMC1   = 0x11,
+   STM32MP_BOOT_UMS_MMC2   = 0x12,
+};
+
+enum stm32mp_forced_boot_mode st32mp_get_forced_boot_mode(void);
+
+#endif
diff --git a/arch/arm/mach-stm32mp/include/mach/revision.h 
b/arch/arm/mach-stm32mp/include/mach/revision.h
new file mode 100644
index ..387201421de7
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/revision.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause */
+/*
+ * Copyright (C) 2015-2017, STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef __MACH_CPUTYPE_H__
+#define __MACH_CPUTYPE_H__
+
+/* ID = Device Version (bit31:16) + Device Part Number (RPN) (bit15:0)*/
+#define CPU_STM32MP157Cxx  0x0500
+#define CPU_STM32MP157Axx  0x0501
+#define CPU_STM32MP153Cxx  0x0524
+#define CPU_STM32MP153Axx  0x0525
+#define CPU_STM32MP151Cxx  0x052E
+#define CPU_STM32MP151Axx  0x052F
+
+/* silicon revisions */
+#define CPU_REV_A  0x1000
+#define CPU_REV_B  0x2000
+
+int stm32mp_silicon_revision(void);
+int stm32mp_cputype(void);
+int stm32mp_package(void);
+
+#define cpu_is_stm32mp157c() (stm32mp_cputype() == CPU_STM32MP157Cxx)
+#define cpu_is_stm32mp157a() (stm32mp_cputype() == CPU_STM32MP157Axx)
+#define cpu_is_stm32mp153c() (stm32mp_cputype() == CPU_STM32MP153Cxx)
+#define cpu_is_stm32mp153a() (stm32mp_cputype() == CPU_STM32MP153Axx)
+#define cpu_is_stm32mp151c() (stm32mp_cputype() == CPU_STM32MP151Cxx)
+#define cpu_is_stm32mp151a() (stm32mp_cputype() == CPU_STM32MP151Axx)
+
+#endif /* __MACH_CPUTYPE_H__ */
diff --git a/arch/arm/mach-stm32mp/init.c b/arch/arm/mach-stm32mp/init.c
new file mode 100644
index ..7bad989a609b
--- /dev/null
+++ b/arch/arm/mach-stm32mp/init.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Copyright (C) 2019 Ahmad Fatoum, Pengutronix
+ */
+
+#define pr_fmt(fmt) "stm32mp-init: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* DBGMCU register */
+#define DBGMCU_IDC (STM32_DBGMCU_BASE + 0x00)
+#define DBGMCU_APB4FZ1 (STM32_DBGMCU_BASE + 0x2C)
+#define DBGMCU_APB4FZ1_IWDG2   BIT(2)
+#define DBGMCU_IDC_DEV_ID_MASK GENMASK(11, 0)
+#define DBGMCU_IDC_DEV_ID_SHIFT0
+#define DBGMCU_IDC_REV_ID_MASK GENMASK(31, 16)
+#define DBGMCU_IDC_REV_ID_SHIFT16
+
+#define RCC_DBGCFGR(STM32_RCC_BASE + 0x080C)
+#define RCC_DBGCFGR_DBGCKENBIT(8)
+
+/* BSEC OTP index */
+#define BSEC_OTP_RPN   1
+#define BSEC_OTP_PKG   16
+
+/* D

[PATCH v2 6/8] nvmem: add read support for STM32MP1 bsec OTP

2019-10-27 Thread Ahmad Fatoum
The bsec on the STM32MP157C provides a 380 byte OTP. Add initial support
for reading and writing the shadow copy of the fuses. Direct fuse
access is not yet supported.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/dts/stm32mp157c.dtsi |   4 +
 arch/arm/mach-stm32mp/include/mach/bsec.h |  41 
 arch/arm/mach-stm32mp/include/mach/smc.h  |  28 +++
 drivers/nvmem/Kconfig |   8 +
 drivers/nvmem/Makefile|   5 +-
 drivers/nvmem/bsec.c  | 221 ++
 6 files changed, 306 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/bsec.h
 create mode 100644 arch/arm/mach-stm32mp/include/mach/smc.h
 create mode 100644 drivers/nvmem/bsec.c

diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
index 8d9c84a04785..771139c28af0 100644
--- a/arch/arm/dts/stm32mp157c.dtsi
+++ b/arch/arm/dts/stm32mp157c.dtsi
@@ -20,3 +20,7 @@
gpio25 = 
};
 };
+
+ {
+   barebox,provide-mac-address = < 0x39>;
+};
diff --git a/arch/arm/mach-stm32mp/include/mach/bsec.h 
b/arch/arm/mach-stm32mp/include/mach/bsec.h
new file mode 100644
index ..559faaa2bac3
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/bsec.h
@@ -0,0 +1,41 @@
+#ifndef __MACH_STM32_BSEC_H__
+#define __MACH_STM32_BSEC_H__
+
+#include 
+
+/* Return status */
+enum bsec_smc {
+   BSEC_SMC_OK = 0,
+   BSEC_SMC_ERROR  = -1,
+   BSEC_SMC_DISTURBED  = -2,
+   BSEC_SMC_INVALID_PARAM  = -3,
+   BSEC_SMC_PROG_FAIL  = -4,
+   BSEC_SMC_LOCK_FAIL  = -5,
+   BSEC_SMC_WRITE_FAIL = -6,
+   BSEC_SMC_SHADOW_FAIL= -7,
+   BSEC_SMC_TIMEOUT= -8,
+};
+
+/* Service for BSEC */
+enum bsec_field {
+   BSEC_SMC_READ_SHADOW= 1,
+   BSEC_SMC_PROG_OTP   = 2,
+   BSEC_SMC_WRITE_SHADOW   = 3,
+   BSEC_SMC_READ_OTP   = 4,
+   BSEC_SMC_READ_ALL   = 5,
+   BSEC_SMC_WRITE_ALL  = 6,
+};
+
+static inline enum bsec_smc bsec_read_field(enum bsec_field field, unsigned 
*val)
+{
+   return stm32mp_smc(STM32_SMC_BSEC, BSEC_SMC_READ_SHADOW,
+  field, 0, val);
+}
+
+static inline enum bsec_smc bsec_write_field(enum bsec_field field, unsigned 
val)
+{
+   return stm32mp_smc(STM32_SMC_BSEC, BSEC_SMC_WRITE_SHADOW,
+  field, val, NULL);
+}
+
+#endif
diff --git a/arch/arm/mach-stm32mp/include/mach/smc.h 
b/arch/arm/mach-stm32mp/include/mach/smc.h
new file mode 100644
index ..6b8e62bd5302
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/smc.h
@@ -0,0 +1,28 @@
+#ifndef __MACH_STM32_SMC_H__
+#define __MACH_STM32_SMC_H__
+
+#include 
+
+/* Secure Service access from Non-secure */
+#define STM32_SMC_RCC   0x82001000
+#define STM32_SMC_PWR   0x82001001
+#define STM32_SMC_RTC   0x82001002
+#define STM32_SMC_BSEC  0x82001003
+
+/* Register access service use for RCC/RTC/PWR */
+#define STM32_SMC_REG_WRITE 0x1
+#define STM32_SMC_REG_SET   0x2
+#define STM32_SMC_REG_CLEAR 0x3
+
+static inline int stm32mp_smc(u32 svc, u8 op, u32 data1, u32 data2, u32 *val)
+{
+struct arm_smccc_res res;
+
+arm_smccc_smc(svc, op, data1, data2, 0, 0, 0, 0, );
+if (val)
+*val = res.a1;
+
+return (int)res.a0;
+}
+
+#endif
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index c28a6d4e43c8..968342b281ad 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -51,4 +51,12 @@ config EEPROM_93XX46
  supports both read and write commands and also the command to
  erase the whole EEPROM.
 
+config STM32_BSEC
+   tristate "STM32 Boot and security and OTP control"
+   depends on ARCH_STM32MP
+   depends on OFDEVICE
+   help
+ This adds support for the STM32 OTP controller. Reads and writes
+ to will go to the shadow RAM, not the OTP fuses themselvers.
+
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index abf9dae429e2..7101c5aca44c 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -16,4 +16,7 @@ obj-$(CONFIG_RAVE_SP_EEPROM)  += nvmem-rave-sp-eeprom.o
 nvmem-rave-sp-eeprom-y := rave-sp-eeprom.o
 
 obj-$(CONFIG_EEPROM_93XX46)+= nvmem_eeprom_93xx46.o
-nvmem_eeprom_93xx46-y  := eeprom_93xx46.o
\ No newline at end of file
+nvmem_eeprom_93xx46-y  := eeprom_93xx46.o
+
+obj-$(CONFIG_STM32_BSEC)   += nvmem_bsec.o
+nvmem_bsec-y   := bsec.o
diff --git a/drivers/nvmem/bsec.c b/drivers/nvmem/bsec.c
new file mode 100644
index ..8235d468d16d
--- /dev/null
+++ b/drivers/nvmem/bsec.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Copyright (c) 2019 Ahmad Fatoum, Pengutronix
+ */
+
+#include 
+#in

[PATCH v2 1/8] pinctrl: stm32: fix debug print of uninitialized variable

2019-10-27 Thread Ahmad Fatoum
mode and alt are printed with the dev_dbg before they are initialized.
Remedy this by moving the dev_dbg after them.

Signed-off-by: Ahmad Fatoum 
---
 drivers/pinctrl/pinctrl-stm32.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-stm32.c b/drivers/pinctrl/pinctrl-stm32.c
index 7f04cea50b75..ab121998a37f 100644
--- a/drivers/pinctrl/pinctrl-stm32.c
+++ b/drivers/pinctrl/pinctrl-stm32.c
@@ -157,13 +157,13 @@ static int stm32_pinctrl_set_state(struct pinctrl_device 
*pdev, struct device_no
if (offset < 0)
return -ENODEV;
 
+   mode = stm32_gpio_get_mode(func);
+   alt = stm32_gpio_get_alt(func);
+
dev_dbg(pdev->dev, "configuring port %s pin %u 
with:\n\t"
"fn %u, mode %u, alt %u\n",
bank->name, offset, func, mode, alt);
 
-   mode = stm32_gpio_get_mode(func);
-   alt = stm32_gpio_get_alt(func);
-
clk_enable(bank->clk);
 
__stm32_pmx_set_mode(bank->base, offset, mode, alt);
-- 
2.23.0


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


[PATCH v2 5/8] ARM: stm32mp: select ARM_SMCCC always

2019-10-27 Thread Ahmad Fatoum
ARM_SMCCC compiles in the code for issuing ARM secure monitor calls.
We need those on the STM32MP, because barebox runs in non-secure mode
and does some operations like reading the BSEC OTP through SMCs.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d4947cef5c98..f82844a83a5e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -201,6 +201,7 @@ config ARCH_STM32MP
select GPIOLIB
select ARCH_HAS_RESET_CONTROLLER
select ARM_AMBA
+   select ARM_SMCCC
 
 config ARCH_VERSATILE
bool "ARM Versatile boards (ARM926EJ-S)"
-- 
2.23.0


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


[PATCH 5/8] ARM: stm32mp: select ARM_SMCCC always

2019-10-27 Thread Ahmad Fatoum
ARM_SMCCC compiles in the code for issuing ARM secure monitor calls.
We need those on the STM32MP, because barebox runs in non-secure mode
and does some operations like reading the BSEC OTP through SMCs.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d4947cef5c98..f82844a83a5e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -201,6 +201,7 @@ config ARCH_STM32MP
select GPIOLIB
select ARCH_HAS_RESET_CONTROLLER
select ARM_AMBA
+   select ARM_SMCCC
 
 config ARCH_VERSATILE
bool "ARM Versatile boards (ARM926EJ-S)"
-- 
2.23.0


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


[PATCH 7/8] ARM: stm32mp: dk2: add barebox SD-Card update handler

2019-10-27 Thread Ahmad Fatoum
Now with the SD/MMC controller supported, lets add a bbu handler, so we
can use it to update the second stage boot loader partition.

While doing this, I noticed that making use of the bus-width = <4>
property in the device tree now makes mmc usage fail when reading the
environment:

  ERROR: error SDMMC_STA_DCRCFAIL (0x81042) for cmd 18
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
  WARNING: stm32_sdmmc2_send_cmd: cmd 12 failed, retrying ...
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
  WARNING: stm32_sdmmc2_send_cmd: cmd 12 failed, retrying ...
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
  WARNING: stm32_sdmmc2_send_cmd: cmd 12 failed, retrying ...
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12

We'll want to fix this eventually, but for now force the bus width to 1
and print a notice to the console that we've done so. This is not
enough, however because it then fails at loading the kernel from MMC:

  ERROR: Time out on waiting for SDMMC_STA. cmd 18
  ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x804) for cmd 12
  WARNING: stm32_sdmmc2_send_cmd: cmd 18 failed, retrying ...

Fixing the max frequency at 208 MHz fixes this. So do that and print a
notice for it as well.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/boards/stm32mp157c-dk2/board.c  | 14 ++
 arch/arm/dts/stm32mp157a-dk1.dtsi|  4 
 arch/arm/mach-stm32mp/include/mach/bbu.h | 14 ++
 drivers/mci/stm32_sdmmc2.c   | 15 +--
 4 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/bbu.h

diff --git a/arch/arm/boards/stm32mp157c-dk2/board.c 
b/arch/arm/boards/stm32mp157c-dk2/board.c
index 9cb861af85d8..5bc88781c7ba 100644
--- a/arch/arm/boards/stm32mp157c-dk2/board.c
+++ b/arch/arm/boards/stm32mp157c-dk2/board.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int dk2_mem_init(void)
 {
@@ -15,3 +16,16 @@ static int dk2_mem_init(void)
return 0;
 }
 mem_initcall(dk2_mem_init);
+
+static int dk2_postcore_init(void)
+{
+   if (!of_machine_is_compatible("st,stm32mp157c-dk2"))
+   return 0;
+
+   stm32mp_bbu_mmc_register_handler("sd", "/dev/mmc0.ssbl",
+BBU_HANDLER_FLAG_DEFAULT);
+
+   return 0;
+}
+
+postcore_initcall(dk2_postcore_init);
diff --git a/arch/arm/dts/stm32mp157a-dk1.dtsi 
b/arch/arm/dts/stm32mp157a-dk1.dtsi
index 7f3b6fcf55ae..05a39d32e2fa 100644
--- a/arch/arm/dts/stm32mp157a-dk1.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1.dtsi
@@ -8,6 +8,10 @@
 #include 
 
 / {
+   aliases {
+   mmc0 = 
+   };
+
chosen {
environment {
compatible = "barebox,environment";
diff --git a/arch/arm/mach-stm32mp/include/mach/bbu.h 
b/arch/arm/mach-stm32mp/include/mach/bbu.h
new file mode 100644
index ..8b9504400e9e
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/bbu.h
@@ -0,0 +1,14 @@
+#ifndef MACH_STM32MP_BBU_H_
+#define MACH_STM32MP_BBU_H_
+
+#include 
+
+static inline int stm32mp_bbu_mmc_register_handler(const char *name,
+  const char *devicefile,
+  unsigned long flags)
+{
+   return bbu_register_std_file_update(name, flags, devicefile,
+   filetype_stm32_image_v1);
+}
+
+#endif /* MACH_STM32MP_BBU_H_ */
diff --git a/drivers/mci/stm32_sdmmc2.c b/drivers/mci/stm32_sdmmc2.c
index 7346c8a3f5d6..3f0fff1258c0 100644
--- a/drivers/mci/stm32_sdmmc2.c
+++ b/drivers/mci/stm32_sdmmc2.c
@@ -627,11 +627,22 @@ static int stm32_sdmmc2_probe(struct amba_device *adev,
if (IS_ERR(priv->reset_ctl))
priv->reset_ctl = NULL;
 
+   mci_of_parse(>mci);
+
mci->f_min = 40;
-   /* f_max is taken from kernel v5.3 variant_stm32_sdmmc */
-   mci->f_max = 20800;
mci->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
 
+   if (mci->f_max != 20800) {
+   /* f_max is taken from kernel v5.3 variant_stm32_sdmmc */
+   dev_notice(dev, "Fixing max-frequency to 208 MHz due to driver 
limitation\n");
+   mci->f_max = 20800;
+   }
+
+   if (mci->host_caps & (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
+   dev_notice(dev, "Fixing bus-width to 1 due to driver 
limitation\n");
+   mci->host_caps &= ~(MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA);
+   }
+
return mci_register(>mci);
 
 priv_free:
-- 
2.23.0


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


rom 3eed5e64521bacd6f8e84326aa98db7402ffc6fd Mon Sep 17 00:00:00 2001

2019-10-27 Thread Ahmad Fatoum
mode and alt are printed with the dev_dbg before they are initialized.
Remedy this by moving the dev_dbg after them.

Signed-off-by: Ahmad Fatoum 
---
 drivers/pinctrl/pinctrl-stm32.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-stm32.c b/drivers/pinctrl/pinctrl-stm32.c
index 7f04cea50b75..ab121998a37f 100644
--- a/drivers/pinctrl/pinctrl-stm32.c
+++ b/drivers/pinctrl/pinctrl-stm32.c
@@ -157,13 +157,13 @@ static int stm32_pinctrl_set_state(struct pinctrl_device 
*pdev, struct device_no
if (offset < 0)
return -ENODEV;
 
+   mode = stm32_gpio_get_mode(func);
+   alt = stm32_gpio_get_alt(func);
+
dev_dbg(pdev->dev, "configuring port %s pin %u 
with:\n\t"
"fn %u, mode %u, alt %u\n",
bank->name, offset, func, mode, alt);
 
-   mode = stm32_gpio_get_mode(func);
-   alt = stm32_gpio_get_alt(func);
-
clk_enable(bank->clk);
 
__stm32_pmx_set_mode(bank->base, offset, mode, alt);
-- 
2.23.0


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


[PATCH 6/8] nvmem: add read support for STM32MP1 bsec OTP

2019-10-27 Thread Ahmad Fatoum
The bsec on the STM32MP157C provides a 380 byte OTP. Add initial support
for reading and writing the shadow copy of the fuses. Direct fuse
access is not yet supported.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/dts/stm32mp157c.dtsi |   4 +
 arch/arm/mach-stm32mp/include/mach/bsec.h |  41 
 arch/arm/mach-stm32mp/include/mach/smc.h  |  28 +++
 drivers/nvmem/Kconfig |   8 +
 drivers/nvmem/Makefile|   5 +-
 drivers/nvmem/bsec.c  | 221 ++
 6 files changed, 306 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/bsec.h
 create mode 100644 arch/arm/mach-stm32mp/include/mach/smc.h
 create mode 100644 drivers/nvmem/bsec.c

diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
index 8d9c84a04785..771139c28af0 100644
--- a/arch/arm/dts/stm32mp157c.dtsi
+++ b/arch/arm/dts/stm32mp157c.dtsi
@@ -20,3 +20,7 @@
gpio25 = 
};
 };
+
+ {
+   barebox,provide-mac-address = < 0x39>;
+};
diff --git a/arch/arm/mach-stm32mp/include/mach/bsec.h 
b/arch/arm/mach-stm32mp/include/mach/bsec.h
new file mode 100644
index ..559faaa2bac3
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/bsec.h
@@ -0,0 +1,41 @@
+#ifndef __MACH_STM32_BSEC_H__
+#define __MACH_STM32_BSEC_H__
+
+#include 
+
+/* Return status */
+enum bsec_smc {
+   BSEC_SMC_OK = 0,
+   BSEC_SMC_ERROR  = -1,
+   BSEC_SMC_DISTURBED  = -2,
+   BSEC_SMC_INVALID_PARAM  = -3,
+   BSEC_SMC_PROG_FAIL  = -4,
+   BSEC_SMC_LOCK_FAIL  = -5,
+   BSEC_SMC_WRITE_FAIL = -6,
+   BSEC_SMC_SHADOW_FAIL= -7,
+   BSEC_SMC_TIMEOUT= -8,
+};
+
+/* Service for BSEC */
+enum bsec_field {
+   BSEC_SMC_READ_SHADOW= 1,
+   BSEC_SMC_PROG_OTP   = 2,
+   BSEC_SMC_WRITE_SHADOW   = 3,
+   BSEC_SMC_READ_OTP   = 4,
+   BSEC_SMC_READ_ALL   = 5,
+   BSEC_SMC_WRITE_ALL  = 6,
+};
+
+static inline enum bsec_smc bsec_read_field(enum bsec_field field, unsigned 
*val)
+{
+   return stm32mp_smc(STM32_SMC_BSEC, BSEC_SMC_READ_SHADOW,
+  field, 0, val);
+}
+
+static inline enum bsec_smc bsec_write_field(enum bsec_field field, unsigned 
val)
+{
+   return stm32mp_smc(STM32_SMC_BSEC, BSEC_SMC_WRITE_SHADOW,
+  field, val, NULL);
+}
+
+#endif
diff --git a/arch/arm/mach-stm32mp/include/mach/smc.h 
b/arch/arm/mach-stm32mp/include/mach/smc.h
new file mode 100644
index ..6b8e62bd5302
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/smc.h
@@ -0,0 +1,28 @@
+#ifndef __MACH_STM32_SMC_H__
+#define __MACH_STM32_SMC_H__
+
+#include 
+
+/* Secure Service access from Non-secure */
+#define STM32_SMC_RCC   0x82001000
+#define STM32_SMC_PWR   0x82001001
+#define STM32_SMC_RTC   0x82001002
+#define STM32_SMC_BSEC  0x82001003
+
+/* Register access service use for RCC/RTC/PWR */
+#define STM32_SMC_REG_WRITE 0x1
+#define STM32_SMC_REG_SET   0x2
+#define STM32_SMC_REG_CLEAR 0x3
+
+static inline int stm32mp_smc(u32 svc, u8 op, u32 data1, u32 data2, u32 *val)
+{
+struct arm_smccc_res res;
+
+arm_smccc_smc(svc, op, data1, data2, 0, 0, 0, 0, );
+if (val)
+*val = res.a1;
+
+return (int)res.a0;
+}
+
+#endif
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index c28a6d4e43c8..968342b281ad 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -51,4 +51,12 @@ config EEPROM_93XX46
  supports both read and write commands and also the command to
  erase the whole EEPROM.
 
+config STM32_BSEC
+   tristate "STM32 Boot and security and OTP control"
+   depends on ARCH_STM32MP
+   depends on OFDEVICE
+   help
+ This adds support for the STM32 OTP controller. Reads and writes
+ to will go to the shadow RAM, not the OTP fuses themselvers.
+
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index abf9dae429e2..7101c5aca44c 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -16,4 +16,7 @@ obj-$(CONFIG_RAVE_SP_EEPROM)  += nvmem-rave-sp-eeprom.o
 nvmem-rave-sp-eeprom-y := rave-sp-eeprom.o
 
 obj-$(CONFIG_EEPROM_93XX46)+= nvmem_eeprom_93xx46.o
-nvmem_eeprom_93xx46-y  := eeprom_93xx46.o
\ No newline at end of file
+nvmem_eeprom_93xx46-y  := eeprom_93xx46.o
+
+obj-$(CONFIG_STM32_BSEC)   += nvmem_bsec.o
+nvmem_bsec-y   := bsec.o
diff --git a/drivers/nvmem/bsec.c b/drivers/nvmem/bsec.c
new file mode 100644
index ..8235d468d16d
--- /dev/null
+++ b/drivers/nvmem/bsec.c
@@ -0,0 +1,221 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Copyright (c) 2019 Ahmad Fatoum, Pengutronix
+ */
+
+#include 
+#in

[PATCH 8/8] ARM: stm32mp: implement SoC and boot source identification

2019-10-27 Thread Ahmad Fatoum
The BSEC OTP holds information about SoC type and package.
The Tamp registers hold information from the BootROM about boot
source. Add support for both.

Additionally, the tamp registers can also hold a request from the
operating system about what mode to enter after boot, e.g.
boot-into-recovery. A global function is exported for this, but
unused so far.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/mach-stm32mp/Makefile|   3 +-
 .../mach-stm32mp/include/mach/bootsource.h|  33 +++
 arch/arm/mach-stm32mp/include/mach/revision.h |  32 +++
 arch/arm/mach-stm32mp/init.c  | 260 ++
 4 files changed, 327 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/bootsource.h
 create mode 100644 arch/arm/mach-stm32mp/include/mach/revision.h
 create mode 100644 arch/arm/mach-stm32mp/init.c

diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
index 204cad608f56..6f495288923a 100644
--- a/arch/arm/mach-stm32mp/Makefile
+++ b/arch/arm/mach-stm32mp/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_BOOTM) := stm32image.o
+obj-y := init.o
+obj-$(CONFIG_BOOTM) += stm32image.o
diff --git a/arch/arm/mach-stm32mp/include/mach/bootsource.h 
b/arch/arm/mach-stm32mp/include/mach/bootsource.h
new file mode 100644
index ..1b6f562ac301
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/bootsource.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause */
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef __MACH_STM32_BOOTSOURCE_H__
+#define __MACH_STM32_BOOTSOURCE_H__
+
+enum stm32mp_boot_device {
+   STM32MP_BOOT_FLASH_SD   = 0x10, /* .. 0x13 */
+   STM32MP_BOOT_FLASH_EMMC = 0x20, /* .. 0x23 */
+   STM32MP_BOOT_FLASH_NAND = 0x30,
+   STM32MP_BOOT_FLASH_NAND_FMC = 0x31,
+   STM32MP_BOOT_FLASH_NOR  = 0x40,
+   STM32MP_BOOT_FLASH_NOR_QSPI = 0x41,
+   STM32MP_BOOT_SERIAL_UART= 0x50, /* .. 0x58 */
+   STM32MP_BOOT_SERIAL_USB = 0x60,
+   STM32MP_BOOT_SERIAL_USB_OTG = 0x62,
+};
+
+enum stm32mp_forced_boot_mode {
+   STM32MP_BOOT_NORMAL = 0x00,
+   STM32MP_BOOT_FASTBOOT   = 0x01,
+   STM32MP_BOOT_RECOVERY   = 0x02,
+   STM32MP_BOOT_STM32PROG  = 0x03,
+   STM32MP_BOOT_UMS_MMC0   = 0x10,
+   STM32MP_BOOT_UMS_MMC1   = 0x11,
+   STM32MP_BOOT_UMS_MMC2   = 0x12,
+};
+
+enum stm32mp_forced_boot_mode st32mp_get_forced_boot_mode(void);
+
+#endif
diff --git a/arch/arm/mach-stm32mp/include/mach/revision.h 
b/arch/arm/mach-stm32mp/include/mach/revision.h
new file mode 100644
index ..387201421de7
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/revision.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause */
+/*
+ * Copyright (C) 2015-2017, STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef __MACH_CPUTYPE_H__
+#define __MACH_CPUTYPE_H__
+
+/* ID = Device Version (bit31:16) + Device Part Number (RPN) (bit15:0)*/
+#define CPU_STM32MP157Cxx  0x0500
+#define CPU_STM32MP157Axx  0x0501
+#define CPU_STM32MP153Cxx  0x0524
+#define CPU_STM32MP153Axx  0x0525
+#define CPU_STM32MP151Cxx  0x052E
+#define CPU_STM32MP151Axx  0x052F
+
+/* silicon revisions */
+#define CPU_REV_A  0x1000
+#define CPU_REV_B  0x2000
+
+int stm32mp_silicon_revision(void);
+int stm32mp_cputype(void);
+int stm32mp_package(void);
+
+#define cpu_is_stm32mp157c() (stm32mp_cputype() == CPU_STM32MP157Cxx)
+#define cpu_is_stm32mp157a() (stm32mp_cputype() == CPU_STM32MP157Axx)
+#define cpu_is_stm32mp153c() (stm32mp_cputype() == CPU_STM32MP153Cxx)
+#define cpu_is_stm32mp153a() (stm32mp_cputype() == CPU_STM32MP153Axx)
+#define cpu_is_stm32mp151c() (stm32mp_cputype() == CPU_STM32MP151Cxx)
+#define cpu_is_stm32mp151a() (stm32mp_cputype() == CPU_STM32MP151Axx)
+
+#endif /* __MACH_CPUTYPE_H__ */
diff --git a/arch/arm/mach-stm32mp/init.c b/arch/arm/mach-stm32mp/init.c
new file mode 100644
index ..7bad989a609b
--- /dev/null
+++ b/arch/arm/mach-stm32mp/init.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Copyright (C) 2019 Ahmad Fatoum, Pengutronix
+ */
+
+#define pr_fmt(fmt) "stm32mp-init: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* DBGMCU register */
+#define DBGMCU_IDC (STM32_DBGMCU_BASE + 0x00)
+#define DBGMCU_APB4FZ1 (STM32_DBGMCU_BASE + 0x2C)
+#define DBGMCU_APB4FZ1_IWDG2   BIT(2)
+#define DBGMCU_IDC_DEV_ID_MASK GENMASK(11, 0)
+#define DBGMCU_IDC_DEV_ID_SHIFT0
+#define DBGMCU_IDC_REV_ID_MASK GENMASK(31, 16)
+#define DBGMCU_IDC_REV_ID_SHIFT16
+
+#define RCC_DBGCFGR(STM32_RCC_BASE + 0x080C)
+#define RCC_DBGCFGR_DBGCKENBIT(8)
+
+/* BSEC OTP index */
+#define BSEC_OTP_RPN   1
+#define BSEC_OTP_PKG   16
+
+/* D

[PATCH 3/8] pinctrl: stm32: parse pinctrl nodes without subnodes as well

2019-10-27 Thread Ahmad Fatoum
The bindings allow the pinmux node to occur directly in the node under
the pin controller as well. Check for this and support both types of
pinctrl specification.

Signed-off-by: Ahmad Fatoum 
---
 drivers/pinctrl/pinctrl-stm32.c | 180 ++--
 1 file changed, 99 insertions(+), 81 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-stm32.c b/drivers/pinctrl/pinctrl-stm32.c
index c199d74846e8..cdaed510c564 100644
--- a/drivers/pinctrl/pinctrl-stm32.c
+++ b/drivers/pinctrl/pinctrl-stm32.c
@@ -87,110 +87,128 @@ static inline u32 stm32_gpio_get_alt(u32 function)
return 0;
 }
 
-static int stm32_pinctrl_set_state(struct pinctrl_device *pdev, struct 
device_node *group)
+static int __stm32_pinctrl_set_state(struct device_d *dev, struct device_node 
*pins)
 {
-   struct stm32_pinctrl *pinctrl = to_stm32_pinctrl(pdev);
-   struct device_node *pins;
int ret;
 
-   ret = hwspinlock_lock_timeout(>hws, 10);
-   if (ret == -ETIMEDOUT) {
-   dev_err(pdev->dev, "hw spinlock timeout\n");
-   return ret;
+   int num_pins = 0, i;
+   u32 slew_rate;
+   bool adjust_slew_rate = false;
+   enum stm32_pin_bias bias = -1;
+   enum stm32_pin_out_type out_type = -1;
+   enum { PIN_INPUT, PIN_OUTPUT_LOW, PIN_OUTPUT_HIGH } dir = -1;
+
+   of_get_property(pins, "pinmux", _pins);
+   num_pins /= sizeof(__be32);
+   if (!num_pins) {
+   dev_err(dev, "Invalid pinmux property in %s\n",
+   pins->full_name);
+   return -EINVAL;
}
 
-   for_each_child_of_node(group, pins) {
-   int num_pins = 0, i;
-   u32 slew_rate;
-   bool adjust_slew_rate = false;
-   enum stm32_pin_bias bias = -1;
-   enum stm32_pin_out_type out_type = -1;
-   enum { PIN_INPUT, PIN_OUTPUT_LOW, PIN_OUTPUT_HIGH } dir = -1;
-
-   of_get_property(pins, "pinmux", _pins);
-   num_pins /= sizeof(__be32);
-   if (!num_pins) {
-   dev_err(pdev->dev, "Invalid pinmux property in %s\n",
-   pins->full_name);
-   return -EINVAL;
-   }
-
-   ret = of_property_read_u32(pins, "slew-rate", _rate);
-   if (!ret)
-   adjust_slew_rate = true;
-
-   if (of_get_property(pins, "bias-disable", NULL))
-   bias = STM32_PIN_NO_BIAS;
-   else if (of_get_property(pins, "bias-pull-up", NULL))
-   bias = STM32_PIN_PULL_UP;
-   else if (of_get_property(pins, "bias-pull-down", NULL))
-   bias = STM32_PIN_PULL_DOWN;
+   ret = of_property_read_u32(pins, "slew-rate", _rate);
+   if (!ret)
+   adjust_slew_rate = true;
+
+   if (of_get_property(pins, "bias-disable", NULL))
+   bias = STM32_PIN_NO_BIAS;
+   else if (of_get_property(pins, "bias-pull-up", NULL))
+   bias = STM32_PIN_PULL_UP;
+   else if (of_get_property(pins, "bias-pull-down", NULL))
+   bias = STM32_PIN_PULL_DOWN;
+
+   if (of_get_property(pins, "drive-push-pull", NULL))
+   out_type = STM32_PIN_OUT_PUSHPULL;
+   else if (of_get_property(pins, "drive-open-drain", NULL))
+   out_type = STM32_PIN_OUT_OPENDRAIN;
+
+   if (of_get_property(pins, "input-enable", NULL))
+   dir = PIN_INPUT;
+   else if (of_get_property(pins, "output-low", NULL))
+   dir = PIN_OUTPUT_LOW;
+   else if (of_get_property(pins, "output-high", NULL))
+   dir = PIN_OUTPUT_HIGH;
+
+   dev_dbg(dev, "%s: multiplexing %d pins\n", pins->full_name, num_pins);
+
+   for (i = 0; i < num_pins; i++) {
+   struct stm32_gpio_bank *bank = NULL;
+   u32 pinfunc, mode, alt;
+   unsigned func;
+   int offset;
+
+   ret = of_property_read_u32_index(pins, "pinmux",
+   i, );
+   if (ret)
+   return ret;
 
-   if (of_get_property(pins, "drive-push-pull", NULL))
-   out_type = STM32_PIN_OUT_PUSHPULL;
-   else if (of_get_property(pins, "drive-open-drain", NULL))
-   out_type = STM32_PIN_OUT_OPENDRAIN;
+   func = STM32_GET_PIN_FUNC(pinfunc);
+   offset = stm32_gpio_pin(STM32_GET_PIN_NO(pinfunc), );
+   if (offset < 0)
+   return -ENODEV;
 
-   if (of_get_property(pins, "input-enable", NULL))
-   dir = PIN_INPUT;
-   el

[PATCH 4/8] ARM: sm: document SMC/PSCI related options

2019-10-27 Thread Ahmad Fatoum
At least to me, the difference between these options were confusing at
first. Clear this up.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/Kconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 725ea12a8c57..d4947cef5c98 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -427,10 +427,14 @@ config ARM_SEMIHOSTING
 
 config ARM_SMCCC
bool
+   help
+ This option enables barebox to invoke ARM secure monitor calls.
 
 config ARM_SECURE_MONITOR
select ARM_SMCCC
bool
+   help
+ This option enables barebox to service ARM secure monitor calls.
 
 config ARM_PSCI_OF
bool
@@ -442,7 +446,7 @@ config ARM_PSCI
select ARM_PSCI_OF
help
  PSCI is used for controlling secondary CPU cores on some systems. Say
- yes here if you have one of these.
+ yes here if you want barebox to service PSCI calls on such systems.
 
 config ARM_PSCI_DEBUG
bool "Enable PSCI debugging"
-- 
2.23.0


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


[PATCH 2/8] pinctrl: demote dev_info on successful probes to dev_dbg

2019-10-27 Thread Ahmad Fatoum
The SoC's pin controller is virtually always built and probed, so
there's is little information to gain from the fact it was successfully
probed. Have the success message show up as debug message to reduce probe
clutter like this:

NOTICE: stm32-pinctrl soc:pin-control...@50002000.of: pinctrl/gpio 
driver registered
NOTICE: stm32-pinctrl soc:pin-controlle...@54004000.of: pinctrl/gpio 
driver registered

Signed-off-by: Ahmad Fatoum 
---
 drivers/pinctrl/pinctrl-at91-pio4.c | 4 ++--
 drivers/pinctrl/pinctrl-bcm2835.c   | 2 +-
 drivers/pinctrl/pinctrl-stm32.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c 
b/drivers/pinctrl/pinctrl-at91-pio4.c
index 9bc259f84cca..b527114f1ba0 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -260,7 +260,7 @@ static int pinctrl_at91_pio4_gpiochip_add(struct device_d 
*dev,
return ret;
}
 
-   dev_info(dev, "gpio driver registered\n");
+   dev_dbg(dev, "gpio driver registered\n");
 
return 0;
 }
@@ -290,7 +290,7 @@ static int pinctrl_at91_pio4_probe(struct device_d *dev)
if (ret)
return ret;
 
-   dev_info(dev, "pinctrl driver registered\n");
+   dev_dbg(dev, "pinctrl driver registered\n");
 
if (of_get_property(np, "gpio-controller", NULL))
return pinctrl_at91_pio4_gpiochip_add(dev, pinctrl);
diff --git a/drivers/pinctrl/pinctrl-bcm2835.c 
b/drivers/pinctrl/pinctrl-bcm2835.c
index 5fd5740e8184..b8e9b60372e3 100644
--- a/drivers/pinctrl/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/pinctrl-bcm2835.c
@@ -171,7 +171,7 @@ static int bcm2835_gpio_probe(struct device_d *dev)
goto err;
}
 
-   dev_info(dev, "probed gpiochip%d with base %d\n", dev->id, 
bcmgpio->chip.base);
+   dev_dbg(dev, "probed gpiochip%d with base %d\n", dev->id, 
bcmgpio->chip.base);
 
if (IS_ENABLED(CONFIG_PINCTRL)) {
ret = pinctrl_register(>pctl);
diff --git a/drivers/pinctrl/pinctrl-stm32.c b/drivers/pinctrl/pinctrl-stm32.c
index ab121998a37f..c199d74846e8 100644
--- a/drivers/pinctrl/pinctrl-stm32.c
+++ b/drivers/pinctrl/pinctrl-stm32.c
@@ -401,7 +401,7 @@ static int stm32_pinctrl_probe(struct device_d *dev)
}
}
 
-   dev_info(dev, "pinctrl/gpio driver registered\n");
+   dev_dbg(dev, "pinctrl/gpio driver registered\n");
 
return 0;
 }
-- 
2.23.0


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


[PATCH] mfd: superio: use strerrorp helper instead of open-coding

2019-10-28 Thread Ahmad Fatoum
Apparently, we have a helper for strerror(-PTR_ERR(regmap)). Use it.

Signed-off-by: Ahmad Fatoum 
---
 drivers/mfd/superio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/superio.c b/drivers/mfd/superio.c
index 0f08d56cb357..12d74b40f6f8 100644
--- a/drivers/mfd/superio.c
+++ b/drivers/mfd/superio.c
@@ -88,7 +88,7 @@ void superio_chip_add(struct superio_chip *siochip)
 _regmap_config);
if (IS_ERR(regmap))
pr_warn("creating %s regmap failed: %s\n",
-   chipname, strerror(-PTR_ERR(regmap)));
+   chipname, strerrorp(regmap));
 
ret = regmap_register_cdev(regmap, chipname);
if (ret)
-- 
2.20.1


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


Re: [PATCH 1/3] watchdog: remove wrong uses of timeout_cur

2019-10-28 Thread Ahmad Fatoum
Hello Oleksij,

On 10/24/19 6:30 PM, Oleksij Rempel wrote:
> Hi,
> 
> How about using this variable to start watchdog(s) on kernel boot?

I originally thought that that is what the parameter is doing.
I think it'd be a good idea to add these semantic. Then it can
be made a generic parameter again.

Cheers

> 
> 
> Am 24.10.19 um 17:24 schrieb Ahmad Fatoum:
>> The barebox watchdog poller uses the struct watchdog.timeout_cur as
>> the timeout value to configure the watchdog with.
>>
>> There's no need for the device driver to set this. I didn't know that
>> when I wrote the drivers, but I do now, hence this commit.
>>
>> Signed-off-by: Ahmad Fatoum 
>> ---
>>  drivers/watchdog/stm32_iwdg.c  | 1 -
>>  drivers/watchdog/stpmic1_wdt.c | 1 -
>>  2 files changed, 2 deletions(-)
>>
>> diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
>> index 20536cb4ab2d..4d252e558c32 100644
>> --- a/drivers/watchdog/stm32_iwdg.c
>> +++ b/drivers/watchdog/stm32_iwdg.c
>> @@ -256,7 +256,6 @@ static int stm32_iwdg_probe(struct device_d *dev)
>>  wdd->set_timeout = stm32_iwdg_set_timeout;
>>  wdd->timeout_max = (RLR_MAX + 1) * data->max_prescaler * 1000;
>>  wdd->timeout_max /= wd->rate * 1000;
>> -wdd->timeout_cur = wdd->timeout_max;
>>
>>  ret = watchdog_register(wdd);
>>  if (ret) {
>> diff --git a/drivers/watchdog/stpmic1_wdt.c b/drivers/watchdog/stpmic1_wdt.c
>> index eb8c43f716a8..f79b7e8c2768 100644
>> --- a/drivers/watchdog/stpmic1_wdt.c
>> +++ b/drivers/watchdog/stpmic1_wdt.c
>> @@ -175,7 +175,6 @@ static int stpmic1_wdt_probe(struct device_d *dev)
>>  wdd->hwdev = dev;
>>  wdd->set_timeout = stpmic1_wdt_set_timeout;
>>  wdd->timeout_max = PMIC_WDT_MAX_TIMEOUT;
>> -wdd->timeout_cur = PMIC_WDT_DEFAULT_TIMEOUT;
>>
>>  /* have the watchdog reset, not power-off the system */
>>  regmap_write_bits(wdt->regmap, MAIN_CR, RREQ_EN, RREQ_EN);
>>
> 
> 
> --
> Regards,
> Oleksij
> 

-- 
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- |

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


Re: [PATCH v2 7/8] ARM: stm32mp: dk2: add barebox SD-Card update handler

2019-10-28 Thread Ahmad Fatoum



On 10/28/19 12:31 PM, Sascha Hauer wrote:
> On Mon, Oct 28, 2019 at 12:18:31AM +0100, Ahmad Fatoum wrote:
>> Now with the SD/MMC controller supported, lets add a bbu handler, so we
>> can use it to update the second stage boot loader partition.
>>
>> While doing this, I noticed that making use of the bus-width = <4>
>> property in the device tree now makes mmc usage fail when reading the
>> environment:
>>
>>   ERROR: error SDMMC_STA_DCRCFAIL (0x81042) for cmd 18
>>   ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
>>   WARNING: stm32_sdmmc2_send_cmd: cmd 12 failed, retrying ...
>>   ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
>>   WARNING: stm32_sdmmc2_send_cmd: cmd 12 failed, retrying ...
>>   ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
>>   WARNING: stm32_sdmmc2_send_cmd: cmd 12 failed, retrying ...
>>   ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x4) for cmd 12
> 
> Could you make this an extra patch?

Can do.

> 
>>
>> We'll want to fix this eventually, but for now force the bus width to 1
>> and print a notice to the console that we've done so. This is not
>> enough, however because it then fails at loading the kernel from MMC:
>>
>>   ERROR: Time out on waiting for SDMMC_STA. cmd 18
>>   ERROR: stm32_sdmmc2_end_cmd: error SDMMC_STA_CTIMEOUT (0x804) for cmd 12
>>   WARNING: stm32_sdmmc2_send_cmd: cmd 18 failed, retrying ...
>>
>> Fixing the max frequency at 208 MHz fixes this. So do that and print a
>> notice for it as well.
>>
>> @@ -627,11 +627,22 @@ static int stm32_sdmmc2_probe(struct amba_device *adev,
>>  if (IS_ERR(priv->reset_ctl))
>>  priv->reset_ctl = NULL;
>>  
>> +mci_of_parse(>mci);
>> +
>>  mci->f_min = 40;
>> -/* f_max is taken from kernel v5.3 variant_stm32_sdmmc */
>> -mci->f_max = 20800;
>>  mci->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
>>  
>> +if (mci->f_max != 20800) {
>> +/* f_max is taken from kernel v5.3 variant_stm32_sdmmc */
>> +dev_notice(dev, "Fixing max-frequency to 208 MHz due to driver 
>> limitation\n");
>> +mci->f_max = 20800;
>> +}
> 
> f_max previously was hardcoded to 208MHz. It still is now, so this can't
> fix anything.
> Looking at the device tree we have max-frequency = <12000>, so you
> probably mean that it doesn't work with the 120MHz specified here,
> right? If it doesn't work with a lower frequency it really looks fishy.

Exactly.

> 
> Could you have another look what is going on here?

I intend to, but not sure if it'll be before the cut-off for v2019.12.0.
I'd like for that release to have full STM32MP support.

I'll send a v2. 

> 
> 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- |

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


[PATCH 1/2] serial: efi-stdio: replace globals with handles in priv struct

2019-10-21 Thread Ahmad Fatoum
Despite assigning efi_sys_table->{con_in,con_out} to priv->{in,out},
some functions still use the global efi_sys_table->{con_in,con_out}.
Let's restrict globals access to the probe function and have the priv
struct completely describe input and output used in the callbacks.
No functional change.

Signed-off-by: Ahmad Fatoum 
---
 drivers/serial/efi-stdio.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/efi-stdio.c b/drivers/serial/efi-stdio.c
index 2ca89fa4f861..a8cc967b32a2 100644
--- a/drivers/serial/efi-stdio.c
+++ b/drivers/serial/efi-stdio.c
@@ -116,7 +116,7 @@ static int efi_read_key(struct efi_console_priv *priv, bool 
wait)
if (wait)
BS->wait_for_event(1, priv->in->wait_for_key, );
 
-efiret = priv->in->read_key_stroke(efi_sys_table->con_in, );
+efiret = priv->in->read_key_stroke(priv->in, );
 if (EFI_ERROR(efiret))
return -efi_errno(efiret);
 
@@ -133,7 +133,8 @@ static int efi_read_key(struct efi_console_priv *priv, bool 
wait)
 static void efi_console_putc(struct console_device *cdev, char c)
 {
uint16_t str[2] = {};
-   struct efi_simple_text_output_protocol *con_out = 
efi_sys_table->con_out;
+   struct efi_console_priv *priv = to_efi(cdev);
+   struct efi_simple_text_output_protocol *con_out = priv->out;
 
str[0] = c;
 
-- 
2.23.0


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


[PATCH 2/2] serial: efi-stdio: Add simple_text_input_ex_protocol backend

2019-10-21 Thread Ahmad Fatoum
EFI implementations differ in how simple_text_input_protocol treats
ctrl+alpha combinations. OVMF (used with QEMU) returns a Unicode control
character, the UEFI on the Dell Latitude 7490 on the other hand ignores
the ctrl completely and returns just the letter rendering utilities
like barebox edit unusable.

To fix this, the simple_text_input_ex_protocol can be leveraged as it
additionally provides the state of modifier keys. Extend efi-stdio to use
it where possible.

Cc: Michael Olbrich 
Signed-off-by: Ahmad Fatoum 
---
 drivers/serial/efi-stdio.c | 75 +-
 drivers/serial/efi-stdio.h | 58 +
 2 files changed, 123 insertions(+), 10 deletions(-)
 create mode 100644 drivers/serial/efi-stdio.h

diff --git a/drivers/serial/efi-stdio.c b/drivers/serial/efi-stdio.c
index a8cc967b32a2..9e825181e6f9 100644
--- a/drivers/serial/efi-stdio.c
+++ b/drivers/serial/efi-stdio.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include "efi-stdio.h"
 
 #define EFI_SHIFT_STATE_VALID   0x8000
 #define EFI_RIGHT_CONTROL_PRESSED   0x0004
@@ -71,6 +73,7 @@
 struct efi_console_priv {
struct efi_simple_text_output_protocol *out;
struct efi_simple_input_interface *in;
+   struct efi_simple_text_input_ex_protocol *inex;
struct console_device cdev;
int lastkey;
u16 efi_console_buffer[CONFIG_CBSIZE];
@@ -105,29 +108,65 @@ static struct efi_ctrlkey ctrlkeys[] = {
{ 0x17, 27 /* escape key */ },
 };
 
+static int xlate_keypress(struct efi_input_key *k)
+{
+   int i;
+
+   /* 32 bit modifier keys + 16 bit scan code + 16 bit unicode */
+   for (i = 0; i < ARRAY_SIZE(ctrlkeys); i++) {
+   if (ctrlkeys[i].scan_code == k->scan_code)
+   return ctrlkeys[i].bb_key;
+
+   }
+
+   return k->unicode_char & 0xff;
+}
+
 static int efi_read_key(struct efi_console_priv *priv, bool wait)
 {
unsigned long index;
efi_status_t efiret;
-   struct efi_input_key k;
-   int i;
+   struct efi_key_data kd;
 
/* wait until key is pressed */
if (wait)
BS->wait_for_event(1, priv->in->wait_for_key, );
 
-efiret = priv->in->read_key_stroke(priv->in, );
-if (EFI_ERROR(efiret))
-   return -efi_errno(efiret);
+   if (priv->inex) {
+   efiret = priv->inex->read_key_stroke_ex(priv->inex, );
 
-   /* 32 bit modifier keys + 16 bit scan code + 16 bit unicode */
-   for (i = 0; i < ARRAY_SIZE(ctrlkeys); i++) {
-   if (ctrlkeys[i].scan_code == k.scan_code)
-   return ctrlkeys[i].bb_key;
+   if (efiret == EFI_NOT_READY)
+   return -EAGAIN;
+
+   if (!EFI_ERROR(efiret)) {
+   if ((kd.state.shift_state & EFI_SHIFT_STATE_VALID) &&
+   (kd.state.shift_state & EFI_CONTROL_PRESSED)) {
+   int ch = tolower(kd.key.unicode_char & 0xff);
+
+   if (isalpha(ch))
+   return CHAR_CTRL(ch);
+   if (ch == '\0') /* ctrl is pressed on its own */
+   return -EAGAIN;
+   }
 
+   if (kd.key.unicode_char || kd.key.scan_code)
+   return xlate_keypress();
+
+   /* Some broken firmwares offer 
simple_text_input_ex_protocol,
+* but never handle any key. Treat those as if
+* read_key_stroke_ex failed and fall through
+* to the basic simple_text_input_protocol.
+*/
+   dev_dbg(priv->cdev.dev, "Falling back to 
simple_text_input_protocol\n");
+   }
}
 
-   return k.unicode_char & 0xff;
+   efiret = priv->in->read_key_stroke(priv->in, );
+
+   if (EFI_ERROR(efiret))
+   return -efi_errno(efiret);
+
+   return xlate_keypress();
 }
 
 static void efi_console_putc(struct console_device *cdev, char c)
@@ -332,8 +371,12 @@ static void efi_set_mode(struct efi_console_priv *priv)
 
 static int efi_console_probe(struct device_d *dev)
 {
+   efi_guid_t inex_guid = EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL_GUID;
+   struct efi_simple_text_input_ex_protocol *inex;
struct console_device *cdev;
struct efi_console_priv *priv;
+   efi_status_t efiret;
+
int i;
 
priv = xzalloc(sizeof(*priv));
@@ -341,6 +384,18 @@ static int efi_console_probe(struct device_d *dev)
priv->out = efi_sys_table->con_out;
priv->in = efi_sys_table->con_in;
 
+   efiret = BS->open_protocol((void *)efi_sys_table->con_in_handle,
+

Re: MFGTools from NXP

2019-10-18 Thread Ahmad Fatoum
Hello,

On 10/17/19 10:40 AM, Mihaita Ivascu wrote:
> Yes I have tried with 2019.01.0 barebox but no change. On linux I
> cannot even connect with PUTTY even though /dev/ttyACM0 is present. On
> Windows at least I can connect via PUTTY

There's A Linux PuTTY client? Have you tried with a more traditional client,
e.g. screen or microcom?

> On both OSes fastboot does not list any device. But the board is
> detected in device manager/dmesg.

:/
I don't know why it doesn't work for you. I've used so far at least barebox
v2018.12.0, v2019.03.0 and v2019.09.0 on my i.MX6UL board and all were correctly
detected by the fastboot installed on my system (1:7.0.+r33-1 in debian 9.11).

If you want to debug it, you should start by looking into why the ttyACM
doesn't work for you.

Cheers
Ahmad


> 
> Best regards,
>  Mihaita Ivascu
> 
> On Wed, Oct 16, 2019 at 2:46 PM Ahmad Fatoum  wrote:
>>
>> On 10/16/19 2:44 PM, Mihaita Ivascu wrote:
>>> 2018.04.0
>>
>> I've v2019.09.0 and did the same steps you described and it works for me.
>> Can you try with a newer version?
>>
>>>
>>> On Wed, Oct 16, 2019 at 2:41 PM Ahmad Fatoum  
>>> wrote:
>>>>
>>>> On 10/16/19 2:35 PM, Mihaita Ivascu wrote:
>>>>> No it does not. Still no devices listed.
>>>>
>>>> Strange. What barebox version?
>>>>
>>>>>
>>>>> Thanks,
>>>>>   Mihaita
>>>>>
>>>>> On Wed, Oct 16, 2019 at 1:36 PM Ahmad Fatoum  
>>>>> wrote:
>>>>>>
>>>>>> On 10/16/19 1:28 PM, Mihaita Ivascu wrote:
>>>>>>> On Wed, Oct 16, 2019 at 11:53 AM Ahmad Fatoum 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/16/19 11:48 AM, Mihaita Ivascu wrote:
>>>>>>>>> On Wed, Oct 16, 2019 at 11:26 AM Ahmad Fatoum 
>>>>>>>>> 
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 10/16/19 11:21 AM, Mihaita Ivascu wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>>Thanks for your answer. Yes i am able to connect via PUTTY to the
>>>>>>> target.
>>>>>>>>>>>Then I should use some adb commands in order to push the new
>>>>>>>>>>> barebox/firmware ? do you know where I could find some examples?
>>>>>>>>>>
>>>>>>>>>> fastboot device -l works normally on Linux. You need to check what 
>>>>>>>>>> you
>>>>>>> need
>>>>>>>>>> to do on Windows to do the same. You should only need the Fastboot
>>>>>>> utility
>>>>>>>>>> for this.
>>>>>>>>>>
>>>>>>>>> [mi] Yes I have both fastboot and adb installed on both Windows and
>>>>>>>>> Linux machines. In both cases it does not list any device.
>>>>>>>>>The board is detected as fastboot android is windows device
>>>>>>>>> manager. But the fastboot and adb does not list it. same for Linux.
>>>>>>>>> Please see attachment
>>>>>>>>
>>>>>>>> Let's focus on Linux. You don't see a device there?
>>>>>>>> What does barebox say? Does it say 'multi_bind: creating Fastboot
>>>>>>> function'?
>>>>>>>> What does you Linux host's dmesg say?
>>>>>>>>
>>>>>>>
>>>>>>> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ usbgadget -aA
>>>>>>> udc0: registering UDC driver [g_multi]
>>>>>>> multi_bind: creating Fastboot function
>>>>>>> multi_bind: creating ACM function
>>>>>>> g_multi usbgadget: Multifunction Composite Gadget
>>>>>>> g_multi usbgadget: userspace failed to provide iSerialNumber
>>>>>>> g_multi usbgadget: g_multi ready
>>>>>>> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ g_multi usbgadget: 
>>>>>>> high-speed
>>>>>>> config #1: Multifunction Composite Gadget
>>>>>>>
>>>>>>> dmesg:
>>>>>>>
>>>>>>> [   25.602275] usb 1-1.3: USB disconnect, device numb

[PATCH 1/2] hwrng: dev-random: always use /dev/urandom

2019-10-21 Thread Ahmad Fatoum
/dev/random can block long after boot time. It seems there's a consensus
that /dev/urandom is safe to use except for very early boot, which isn't
when barebox sandbox is usually run. To make the HWRNG more useful,
always use /dev/urandom.

Signed-off-by: Ahmad Fatoum 
---
 arch/sandbox/board/dev-random.c| 7 +--
 arch/sandbox/mach-sandbox/include/mach/linux.h | 1 -
 drivers/hw_random/Kconfig  | 6 +++---
 3 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/sandbox/board/dev-random.c b/arch/sandbox/board/dev-random.c
index f65e5ef6e5ed..60295e9fced2 100644
--- a/arch/sandbox/board/dev-random.c
+++ b/arch/sandbox/board/dev-random.c
@@ -4,10 +4,6 @@
 devrandom_t *devrandom_init(void) {
devrandom_t *fds = xzalloc(sizeof(*fds));
 
-   fds->randomfd = linux_open("/dev/random", false);
-   if (fds->randomfd < 0)
-   return ERR_PTR(-EPERM);
-
fds->urandomfd = linux_open("/dev/urandom", false);
if (fds->urandomfd < 0)
return ERR_PTR(-EPERM);
@@ -17,8 +13,7 @@ devrandom_t *devrandom_init(void) {
 
 int devrandom_read(devrandom_t *devrandom, void *buf, size_t len, int wait)
 {
-   if (wait)
-   return linux_read(devrandom->randomfd, buf, len);
+   (void)wait; /* /dev/urandom won't block */
 
return linux_read(devrandom->urandomfd, buf, len);
 }
diff --git a/arch/sandbox/mach-sandbox/include/mach/linux.h 
b/arch/sandbox/mach-sandbox/include/mach/linux.h
index 1e64d41c6a5e..9759a376ecb3 100644
--- a/arch/sandbox/mach-sandbox/include/mach/linux.h
+++ b/arch/sandbox/mach-sandbox/include/mach/linux.h
@@ -52,7 +52,6 @@ int barebox_libftdi1_update(struct ft2232_bitbang *ftbb);
 void barebox_libftdi1_close(void);
 
 typedef struct {
-   int randomfd;
int urandomfd;
 } devrandom_t;
 devrandom_t *devrandom_init(void);
diff --git a/drivers/hw_random/Kconfig b/drivers/hw_random/Kconfig
index c57928204d30..242a7ef27828 100644
--- a/drivers/hw_random/Kconfig
+++ b/drivers/hw_random/Kconfig
@@ -15,11 +15,11 @@ config HWRNG_MXC_RNGC
  Generator hardware found on some Freescale i.MX processors.
 
 config HWRNG_DEV_RANDOM
-   tristate "Linux /dev/random and /dev/urandom RNG"
+   tristate "Linux /dev/urandom RNG"
depends on SANDBOX
default y
help
- This driver allows use of the host provided /dev/random
- and /dev/urandom as barebox HWRNGs.
+ This driver allows use of the host provided /dev/urandom
+ as barebox HWRNGs.
 
 endif
-- 
2.23.0


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


[PATCH 2/2] fs: devfs-core: do a case-insensitive compare of partuuids

2019-10-21 Thread Ahmad Fatoum
partuuids are represented as hexadecimal strings, where case doesn't
matter. barebox formats them as lower case internally, forcing the
partuuid device tree property to be lower case too. Use strcasecmp to
be case-insensitive.

Signed-off-by: Ahmad Fatoum 
---
 fs/devfs-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/devfs-core.c b/fs/devfs-core.c
index 2b93a951f269..e2cefb6d4e21 100644
--- a/fs/devfs-core.c
+++ b/fs/devfs-core.c
@@ -104,7 +104,7 @@ struct cdev *cdev_by_partuuid(const char *partuuid)
return NULL;
 
list_for_each_entry(cdev, _list, list) {
-   if (!strcmp(cdev->partuuid, partuuid))
+   if (!strcasecmp(cdev->partuuid, partuuid))
return cdev;
}
return NULL;
-- 
2.23.0


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


[PATCH 1/2] partition: include partuuid string in debug string

2019-10-21 Thread Ahmad Fatoum
When debugging partitions detected by barebox, knowing the partuuid
can be useful. Include it in the dev_dbg output.

Signed-off-by: Ahmad Fatoum 
---
 common/partitions.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/partitions.c b/common/partitions.c
index 574b31fbbe9b..4162e86804db 100644
--- a/common/partitions.c
+++ b/common/partitions.c
@@ -54,8 +54,8 @@ static int register_one_partition(struct block_device *blk,
partition_name = basprintf("%s.%d", blk->cdev.name, no);
if (!partition_name)
return -ENOMEM;
-   dev_dbg(blk->dev, "Registering partition %s on drive %s\n",
-   partition_name, blk->cdev.name);
+   dev_dbg(blk->dev, "Registering partition %s on drive %s 
(partuuid=%s)\n",
+   partition_name, blk->cdev.name, part->partuuid);
cdev = devfs_add_partition(blk->cdev.name,
start, size, 0, partition_name);
if (IS_ERR(cdev)) {
-- 
2.23.0


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


Re: setup for a working framebuffer in qemu

2019-10-15 Thread Ahmad Fatoum
Hello Denis,

On 10/15/19 5:08 PM, Denis Roio wrote:
> 
> hi all! noob question here, hope you don't mind
> 
> is there a recommended, matching configuration to run barebox in qemu
> with a working /dev/fb0 ?

Easiest way is to use barebox sandbox. It has a SDL fb driver.

> 
> 
> I have made some tries already with no success:
> 
> - qemu emulated mips-malta boots, but no fb0
> - qemu emulated vexpress boots, but no fb0

Could be that they don't have driver support in barebox.
Check under drivers/fb.

> - qemu emulated sabrelite can't even get it to boot

There's a CONFIG_BOARD_ARM_GENERIC_DT option that yields a barebox image
that boots like Linux does and can be passed to qemu's -kernel
option. The commit introducing it has some extra info on how to use
it with QEMU + sabrelite.
https://www.spinics.net/lists/u-boot-v2/msg38795.html

> 
> I'm a bit out of ideas. Would really appreciate guidance, this is
> mostly for fun while poking around this wonderful project.
> 
> 
> Thanks!
> 
> 


-- 
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- |

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


Re: MFGTools from NXP

2019-10-15 Thread Ahmad Fatoum
On 10/15/19 4:41 PM, Mihaita Ivascu wrote:
> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ fastboot devices -l
That's what you run on your host system, not on the target.
-- 
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- |

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


[PATCH 5/5] efi: silence warning about un-prototyped assembly-called functions

2019-10-16 Thread Ahmad Fatoum
Both _relocate and efi_main are only called from assembly, but
-Wmissing-prototypes doesn't know that and warns about them.
Pre-declare prototypes to silence the warnings.

Signed-off-by: Ahmad Fatoum 
---
 arch/x86/mach-efi/reloc_x86_64.c | 3 +++
 common/efi/efi.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/arch/x86/mach-efi/reloc_x86_64.c b/arch/x86/mach-efi/reloc_x86_64.c
index 1db72f5dbc52..e83bacb302ca 100644
--- a/arch/x86/mach-efi/reloc_x86_64.c
+++ b/arch/x86/mach-efi/reloc_x86_64.c
@@ -35,11 +35,14 @@
 SUCH DAMAGE.
 */
 
+#include 
 #include 
 #include 
 
 #include 
 
+asmlinkage efi_status_t _relocate (long, Elf64_Dyn *, efi_handle_t, 
efi_system_table_t *);
+
 efi_status_t _relocate (long ldbase, Elf64_Dyn *dyn, efi_handle_t image, 
efi_system_table_t *systab)
 {
long relsz = 0, relent = 0;
diff --git a/common/efi/efi.c b/common/efi/efi.c
index a7b25cbbe251..73cea3703695 100644
--- a/common/efi/efi.c
+++ b/common/efi/efi.c
@@ -17,6 +17,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -318,6 +319,8 @@ static int efi_init(void)
 }
 device_initcall(efi_init);
 
+asmlinkage efi_status_t efi_main(efi_handle_t, efi_system_table_t *);
+
 /**
  * efi-main - Entry point for EFI images
  */
-- 
2.20.1


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


[PATCH 1/5] efi: Fix typo in description string

2019-10-16 Thread Ahmad Fatoum
s/Conosle/Console/

Signed-off-by: Ahmad Fatoum 
---
 common/efi-guid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/efi-guid.c b/common/efi-guid.c
index 1e45ccf4d238..2bf2395e8540 100644
--- a/common/efi-guid.c
+++ b/common/efi-guid.c
@@ -52,7 +52,7 @@ const char *efi_guid_string(efi_guid_t *g)
EFI_GUID_STRING(EFI_ISA_IO_PROTOCOL_GUID, "ISA IO Protocol", "ISA IO 
Protocol");
EFI_GUID_STRING(EFI_STANDARD_ERROR_DEVICE_GUID, "Standard Error Device 
Guid", "EFI Standard Error Device Guid");
EFI_GUID_STRING(EFI_CONSOLE_OUT_DEVICE_GUID, "Console Out Device Guid", 
"EFI Console Out Device Guid");
-   EFI_GUID_STRING(EFI_CONSOLE_IN_DEVICE_GUID, "Console In Device Guid", 
"EFI Conosle In Device Guid");
+   EFI_GUID_STRING(EFI_CONSOLE_IN_DEVICE_GUID, "Console In Device Guid", 
"EFI Console In Device Guid");
EFI_GUID_STRING(EFI_SIMPLE_TEXT_OUT_PROTOCOL_GUID, "Simple Text Out 
Protocol", "EFI 1.0 Simple Text Out Protocol");
EFI_GUID_STRING(EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL_GUID, "Simple Text 
Input Ex Protocol", "UEFI 2.1 Simple Text Input Ex Protocol");
EFI_GUID_STRING(EFI_SIMPLE_TEXT_IN_PROTOCOL_GUID, "Simple Text In 
Protocol", "EFI 1.0 Simple Text In Protocol");
-- 
2.20.1


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


[PATCH 4/5] x86: include: add asmlinkage 'storage class'

2019-10-16 Thread Ahmad Fatoum
We've a number of C functions with external linkage that are only called
from assembly. -Wmissing-prototypes warns about these unless they have
a prototype that goes unused. Let's standardize on using the asmlinkage
'storage class' to mark such declarations.

As  defines asmlinkage to naught unless 
does, it's sufficient to add an empty header to make this usable on x86
as well.

Signed-off-by: Ahmad Fatoum 
---
 arch/x86/include/asm/linkage.h | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 arch/x86/include/asm/linkage.h

diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
new file mode 100644
index ..a8d1bdb7de1f
--- /dev/null
+++ b/arch/x86/include/asm/linkage.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+/* referenced by  */
+
+#endif
-- 
2.20.1


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


[PATCH 2/5] efi: retire efi_compare_guid in favor of efi_guidcmp

2019-10-16 Thread Ahmad Fatoum
Both functions wrap the same memcmp except that one uses pointers to
GUIDs and the other passes the GUIDs by value.

The function is static inline, so it doesn't really matter which one we
keep. We'll drop efi_compare_guid because it's been used once only in the
code base so far.

Signed-off-by: Ahmad Fatoum 
---
 common/efi-devicepath.c | 2 +-
 include/efi.h   | 5 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/common/efi-devicepath.c b/common/efi-devicepath.c
index 24722284b4a7..3db2cea061ca 100644
--- a/common/efi-devicepath.c
+++ b/common/efi-devicepath.c
@@ -572,7 +572,7 @@ dev_path_vendor(struct string *str, void *dev_path)
}
 
cprintf(str, "Ven%s(%pU", type, >Guid);
-   if (efi_compare_guid(>Guid, _unknown_device_guid) == 0) {
+   if (efi_guidcmp(Vendor->Guid, efi_unknown_device_guid) == 0) {
/* GUID used by EFI to enumerate an EDD 1.1 device */
unknown_dev_path =
(struct unknown_device_vendor_device_path *) Vendor;
diff --git a/include/efi.h b/include/efi.h
index 218333f82426..166803a58f39 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -664,11 +664,6 @@ typedef union {
efi_ipv6_address v6;
 } efi_ip_address;
 
-static inline int efi_compare_guid(efi_guid_t *a, efi_guid_t *b)
-{
-   return memcmp(a, b, sizeof(efi_guid_t));
-}
-
 struct efi_device_path *device_path_from_handle(efi_handle_t Handle);
 char *device_path_to_str(struct efi_device_path *dev_path);
 u8 device_path_to_type(struct efi_device_path *dev_path);
-- 
2.20.1


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


[PATCH 3/5] efi: use efi_guidcmp helper where appropriate

2019-10-16 Thread Ahmad Fatoum
We have a helper for it. Let's use it.

Signed-off-by: Ahmad Fatoum 
---
 drivers/efi/efi-device.c | 2 +-
 fs/efivarfs.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/efi/efi-device.c b/drivers/efi/efi-device.c
index 305d337aabf5..68d81caf010b 100644
--- a/drivers/efi/efi-device.c
+++ b/drivers/efi/efi-device.c
@@ -311,7 +311,7 @@ static int efi_bus_match(struct device_d *dev, struct 
driver_d *drv)
int i;
 
for (i = 0; i < efidev->num_guids; i++) {
-   if (!memcmp(>guid, >guids[i], 
sizeof(efi_guid_t))) {
+   if (!efi_guidcmp(efidrv->guid, efidev->guids[i])) {
BS->handle_protocol(efidev->handle, >guids[i],
>protocol);
return 0;
diff --git a/fs/efivarfs.c b/fs/efivarfs.c
index 1e8049362168..9eadda41215c 100644
--- a/fs/efivarfs.c
+++ b/fs/efivarfs.c
@@ -145,7 +145,7 @@ static int efivars_create(struct device_d *dev, const char 
*pathname, mode_t mod
if (ret)
return -ENOENT;
 
-   if (memcmp(, _BAREBOX_VENDOR_GUID, sizeof(efi_guid_t)))
+   if (efi_guidcmp(vendor, EFI_BAREBOX_VENDOR_GUID))
return -EPERM;
 
inode = xzalloc(sizeof(*inode));
-- 
2.20.1


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


Re: MFGTools from NXP

2019-10-16 Thread Ahmad Fatoum
On 10/16/19 11:21 AM, Mihaita Ivascu wrote:
> Hello,
> 
>Thanks for your answer. Yes i am able to connect via PUTTY to the target.
>Then I should use some adb commands in order to push the new
> barebox/firmware ? do you know where I could find some examples?

fastboot device -l works normally on Linux. You need to check what you need
to do on Windows to do the same. You should only need the Fastboot utility
for this.

> 
>Also I have a question: purpose of this activity is for me to be
> able to flash some imx6ul boards that have no firmware: no barebox.
>So I know hardware config for the port is otg mode but as I have no
> barebox running them before I am wondering if I will be able to
> connect via PUTTY if I do not set the ACM gadget from barebox?

Check the Embest MarS board's environment in barebox master. It sets up
a fastboot gadget automatically on boot from imx-usb-loader.
You can adjust it to your liking.

Cheers
Ahmad

> 
> Thanks,
>   Mihaita
> 
> On Wed, Oct 16, 2019 at 10:51 AM Ahmad Fatoum  wrote:
>>
>> On 10/16/19 10:40 AM, Mihaita Ivascu wrote:
>>> Hello again,
>>>
>>>I have the target in otg peripheral mode, ADB and fastboot drivers
>>> installed but fastboot does not list any device. The board is detected
>>> in device manager
>>
>> Try enabling the ACM gadget in barebox and connect with PuTTY and see if
>> at least that works. It worked for me on Windows with another i.MX board
>> a month ago.
>>
>> As for fastboot, I don't know how to configure it on Windows, but surely
>> Android Modding boards will have you covered there.
>>
>>>Please see attachment. Any ideas how should I proceed? Thanks for
>>> the support.
>>
>> You can enable the ACM gadget in barebox and see if that works, I tested
>> it on Windows with an i.MX board a month ago
>>
>> Cheers
>> Ahmad
>>
>>>
>>> Thanks,
>>>   Mihaita
>>>
>>> On Wed, Oct 16, 2019 at 9:32 AM Mihaita Ivascu
>>>  wrote:
>>>>
>>>> Thanks. I have installed ADB and fastboot drivers for Win from
>>>> https://www.getdroidtips.com/how-to-install-adb-and-fastboot-on-windows/
>>>> I have installed according to the attachment.
>>>> But is not recognized in Windows. I did reboot the system after
>>>> installation but did not add any new env variable.
>>>>
>>>> H:\>fastboot devices -l
>>>> 'fastboot' is not recognized as an internal or external command,
>>>> operable program or batch file.
>>>>
>>>> Thanks,
>>>>   Mihaita
>>>>
>>>>
>>>> On Tue, Oct 15, 2019 at 4:44 PM Ahmad Fatoum  
>>>> wrote:
>>>>>
>>>>> On 10/15/19 4:41 PM, Mihaita Ivascu wrote:
>>>>>> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ fastboot devices -l
>>>>> That's what you run on your host system, not on the target.
>>>>> --
>>>>> 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- |
>>
>>
>> --
>> 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- |
> 


-- 
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- |

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


Re: MFGTools from NXP

2019-10-16 Thread Ahmad Fatoum
On 10/16/19 10:40 AM, Mihaita Ivascu wrote:
> Hello again,
> 
>I have the target in otg peripheral mode, ADB and fastboot drivers
> installed but fastboot does not list any device. The board is detected
> in device manager

Try enabling the ACM gadget in barebox and connect with PuTTY and see if
at least that works. It worked for me on Windows with another i.MX board
a month ago.

As for fastboot, I don't know how to configure it on Windows, but surely
Android Modding boards will have you covered there.

>Please see attachment. Any ideas how should I proceed? Thanks for
> the support.

You can enable the ACM gadget in barebox and see if that works, I tested
it on Windows with an i.MX board a month ago

Cheers
Ahmad

> 
> Thanks,
>   Mihaita
> 
> On Wed, Oct 16, 2019 at 9:32 AM Mihaita Ivascu
>  wrote:
>>
>> Thanks. I have installed ADB and fastboot drivers for Win from
>> https://www.getdroidtips.com/how-to-install-adb-and-fastboot-on-windows/
>> I have installed according to the attachment.
>> But is not recognized in Windows. I did reboot the system after
>> installation but did not add any new env variable.
>>
>> H:\>fastboot devices -l
>> 'fastboot' is not recognized as an internal or external command,
>> operable program or batch file.
>>
>> Thanks,
>>   Mihaita
>>
>>
>> On Tue, Oct 15, 2019 at 4:44 PM Ahmad Fatoum  wrote:
>>>
>>> On 10/15/19 4:41 PM, Mihaita Ivascu wrote:
>>>> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ fastboot devices -l
>>> That's what you run on your host system, not on the target.
>>> --
>>> 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- |


-- 
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- |

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


[PATCH] fixup! mci: add support for stm32mp sd/mmc controller

2019-10-16 Thread Ahmad Fatoum
We need reset controller support in the driver, depend on it.
---
 drivers/mci/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mci/Kconfig b/drivers/mci/Kconfig
index 5b560310136a..4a71a4609763 100644
--- a/drivers/mci/Kconfig
+++ b/drivers/mci/Kconfig
@@ -156,6 +156,7 @@ config MMC_SPI_CRC_ON
 config MCI_STM32_SDMMC2
bool "STMicroelectronics STM32H7 SD/MMC Host Controller support"
depends on ARM_AMBA
+   depends on RESET_CONTROLLER
help
  This selects support for the SD/MMC controller on STM32H7 SoCs.
  If you have a board based on such a SoC and with a SD/MMC slot,
-- 
2.23.0


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


Re: MFGTools from NXP

2019-10-16 Thread Ahmad Fatoum
On 10/16/19 1:28 PM, Mihaita Ivascu wrote:
> On Wed, Oct 16, 2019 at 11:53 AM Ahmad Fatoum 
> wrote:
>>
>>
>> On 10/16/19 11:48 AM, Mihaita Ivascu wrote:
>>> On Wed, Oct 16, 2019 at 11:26 AM Ahmad Fatoum 
> wrote:
>>>>
>>>> On 10/16/19 11:21 AM, Mihaita Ivascu wrote:
>>>>> Hello,
>>>>>
>>>>>Thanks for your answer. Yes i am able to connect via PUTTY to the
> target.
>>>>>Then I should use some adb commands in order to push the new
>>>>> barebox/firmware ? do you know where I could find some examples?
>>>>
>>>> fastboot device -l works normally on Linux. You need to check what you
> need
>>>> to do on Windows to do the same. You should only need the Fastboot
> utility
>>>> for this.
>>>>
>>> [mi] Yes I have both fastboot and adb installed on both Windows and
>>> Linux machines. In both cases it does not list any device.
>>>The board is detected as fastboot android is windows device
>>> manager. But the fastboot and adb does not list it. same for Linux.
>>> Please see attachment
>>
>> Let's focus on Linux. You don't see a device there?
>> What does barebox say? Does it say 'multi_bind: creating Fastboot
> function'?
>> What does you Linux host's dmesg say?
>>
> 
> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ usbgadget -aA
> udc0: registering UDC driver [g_multi]
> multi_bind: creating Fastboot function
> multi_bind: creating ACM function
> g_multi usbgadget: Multifunction Composite Gadget
> g_multi usbgadget: userspace failed to provide iSerialNumber
> g_multi usbgadget: g_multi ready
> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ g_multi usbgadget: high-speed
> config #1: Multifunction Composite Gadget
> 
> dmesg:
> 
> [   25.602275] usb 1-1.3: USB disconnect, device number 3
> [   28.359930] usb 1-1.3: new high-speed USB device number 5 using ehci-pci
> [   28.452971] usb 1-1.3: New USB device found, idVendor=1d6b,
> idProduct=0104
> [   28.452976] usb 1-1.3: New USB device strings: Mfr=0, Product=2,
> SerialNumber=0
> [   28.452980] usb 1-1.3: Product: Phytec phyCORE-i.MX6 Ultra Lite SOM
> [   28.457925] cdc_acm 1-1.3:1.1: ttyACM0: USB ACM device
> 
> 
> So I see the device on Linux. But fastboot does not list any device on
> Linux.

sudo doesn't change this?

> 
>>  >
>>>>>
>>>>>Also I have a question: purpose of this activity is for me to be
>>>>> able to flash some imx6ul boards that have no firmware: no barebox.
>>>>>So I know hardware config for the port is otg mode but as I have no
>>>>> barebox running them before I am wondering if I will be able to
>>>>> connect via PUTTY if I do not set the ACM gadget from barebox?
>>>>
>>>> Check the Embest MarS board's environment in barebox master. It sets up
>>>> a fastboot gadget automatically on boot from imx-usb-loader.
>>>> You can adjust it to your liking.
>>>
>>>   [mi] I was not able to find any docs about this board. I will keep
>>> searching/asking in the nxp community. If you have already ahve any
>>> files related to it would be helpful. Thanks
>>
>> It's in the barebox next branch (not master, sorry), see here:
>>
> https://github.com/saschahauer/barebox/blob/next/arch/arm/boards/embest-marsboard/defaultenv-mars/init/fastboot
>>
>> You can copy and adjust the environment setup for your board.
>>
>>>>
>>>> Cheers
>>>> Ahmad
>>>>
>>>>>
>>>>> Thanks,
>>>>>   Mihaita
>>>>>
>>>>> On Wed, Oct 16, 2019 at 10:51 AM Ahmad Fatoum 
> wrote:
>>>>>>
>>>>>> On 10/16/19 10:40 AM, Mihaita Ivascu wrote:
>>>>>>> Hello again,
>>>>>>>
>>>>>>>I have the target in otg peripheral mode, ADB and fastboot
> drivers
>>>>>>> installed but fastboot does not list any device. The board is
> detected
>>>>>>> in device manager
>>>>>>
>>>>>> Try enabling the ACM gadget in barebox and connect with PuTTY and
> see if
>>>>>> at least that works. It worked for me on Windows with another i.MX
> board
>>>>>> a month ago.
>>>>>>
>>>>>> As for fastboot, I don't know how to configure it on Windows, but
> surely
>>>>>> Android Modding boards will have you covered there.
>>>&g

[PATCH] ARM: stm32mp: select ARCH_HAS_RESET_CONTROLLER

2019-10-16 Thread Ahmad Fatoum
Many STM32 peripherals, including I2C, SPI, USB and SDMMC use the RCC
reset controller for reset. Enable ARCH_HAS_RESET_CONTROLLER, so drivers
depending on RESET_CONTROLLER become available for selection.

Signed-off-by: Ahmad Fatoum 
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b227bb78b64f..16bd82fe6b9f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -217,6 +217,7 @@ config ARCH_STM32MP
select HAS_DEBUG_LL
select HAVE_CLK
select GPIOLIB
+   select ARCH_HAS_RESET_CONTROLLER
 
 config ARCH_VERSATILE
bool "ARM Versatile boards (ARM926EJ-S)"
-- 
2.23.0


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


Re: MFGTools from NXP

2019-10-16 Thread Ahmad Fatoum


On 10/16/19 11:48 AM, Mihaita Ivascu wrote:
> On Wed, Oct 16, 2019 at 11:26 AM Ahmad Fatoum  wrote:
>>
>> On 10/16/19 11:21 AM, Mihaita Ivascu wrote:
>>> Hello,
>>>
>>>Thanks for your answer. Yes i am able to connect via PUTTY to the target.
>>>Then I should use some adb commands in order to push the new
>>> barebox/firmware ? do you know where I could find some examples?
>>
>> fastboot device -l works normally on Linux. You need to check what you need
>> to do on Windows to do the same. You should only need the Fastboot utility
>> for this.
>>
> [mi] Yes I have both fastboot and adb installed on both Windows and
> Linux machines. In both cases it does not list any device.
>The board is detected as fastboot android is windows device
> manager. But the fastboot and adb does not list it. same for Linux.
> Please see attachment

Let's focus on Linux. You don't see a device there?
What does barebox say? Does it say 'multi_bind: creating Fastboot function'?
What does you Linux host's dmesg say?

 > 
>>>
>>>Also I have a question: purpose of this activity is for me to be
>>> able to flash some imx6ul boards that have no firmware: no barebox.
>>>So I know hardware config for the port is otg mode but as I have no
>>> barebox running them before I am wondering if I will be able to
>>> connect via PUTTY if I do not set the ACM gadget from barebox?
>>
>> Check the Embest MarS board's environment in barebox master. It sets up
>> a fastboot gadget automatically on boot from imx-usb-loader.
>> You can adjust it to your liking.
> 
>   [mi] I was not able to find any docs about this board. I will keep
> searching/asking in the nxp community. If you have already ahve any
> files related to it would be helpful. Thanks

It's in the barebox next branch (not master, sorry), see here:
https://github.com/saschahauer/barebox/blob/next/arch/arm/boards/embest-marsboard/defaultenv-mars/init/fastboot

You can copy and adjust the environment setup for your board. 

>>
>> Cheers
>> Ahmad
>>
>>>
>>> Thanks,
>>>   Mihaita
>>>
>>> On Wed, Oct 16, 2019 at 10:51 AM Ahmad Fatoum  
>>> wrote:
>>>>
>>>> On 10/16/19 10:40 AM, Mihaita Ivascu wrote:
>>>>> Hello again,
>>>>>
>>>>>I have the target in otg peripheral mode, ADB and fastboot drivers
>>>>> installed but fastboot does not list any device. The board is detected
>>>>> in device manager
>>>>
>>>> Try enabling the ACM gadget in barebox and connect with PuTTY and see if
>>>> at least that works. It worked for me on Windows with another i.MX board
>>>> a month ago.
>>>>
>>>> As for fastboot, I don't know how to configure it on Windows, but surely
>>>> Android Modding boards will have you covered there.
>>>>
>>>>>Please see attachment. Any ideas how should I proceed? Thanks for
>>>>> the support.
>>>>
>>>> You can enable the ACM gadget in barebox and see if that works, I tested
>>>> it on Windows with an i.MX board a month ago
>>>>
>>>> Cheers
>>>> Ahmad
>>>>
>>>>>
>>>>> Thanks,
>>>>>   Mihaita
>>>>>
>>>>> On Wed, Oct 16, 2019 at 9:32 AM Mihaita Ivascu
>>>>>  wrote:
>>>>>>
>>>>>> Thanks. I have installed ADB and fastboot drivers for Win from
>>>>>> https://www.getdroidtips.com/how-to-install-adb-and-fastboot-on-windows/
>>>>>> I have installed according to the attachment.
>>>>>> But is not recognized in Windows. I did reboot the system after
>>>>>> installation but did not add any new env variable.
>>>>>>
>>>>>> H:\>fastboot devices -l
>>>>>> 'fastboot' is not recognized as an internal or external command,
>>>>>> operable program or batch file.
>>>>>>
>>>>>> Thanks,
>>>>>>   Mihaita
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 15, 2019 at 4:44 PM Ahmad Fatoum  
>>>>>> wrote:
>>>>>>>
>>>>>>> On 10/15/19 4:41 PM, Mihaita Ivascu wrote:
>>>>>>>> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ fastboot devices -l
>>>>>>> That's what you run on your host system, not on the ta

Re: [PATCH 4/5] ARM: stm32mp: dk2: add barebox SD-Card update handler

2019-10-15 Thread Ahmad Fatoum
On 10/15/19 9:59 AM, Sascha Hauer wrote:
> On Tue, Oct 15, 2019 at 08:58:23AM +0200, Ahmad Fatoum wrote:
>> Hello,
>>
>> On 10/14/19 2:51 PM, Sascha Hauer wrote:
>>> On Mon, Oct 14, 2019 at 08:39:21AM +0200, Ahmad Fatoum wrote:
>>>> Now with the SD/MMC controller supported, lets add a bbu handler, so we
>>>> can use it to update the second stage boot loader partition.
>>>>
>>>> Signed-off-by: Ahmad Fatoum 
>>>> ---
>>>>  arch/arm/boards/stm32mp157c-dk2/board.c  | 14 ++
>>>>  arch/arm/mach-stm32mp/include/mach/bbu.h | 14 ++
>>>>  2 files changed, 28 insertions(+)
>>>>  create mode 100644 arch/arm/mach-stm32mp/include/mach/bbu.h
>>>>
>>>> diff --git a/arch/arm/boards/stm32mp157c-dk2/board.c 
>>>> b/arch/arm/boards/stm32mp157c-dk2/board.c
>>>> index 9cb861af85d8..23eb6728b15a 100644
>>>> --- a/arch/arm/boards/stm32mp157c-dk2/board.c
>>>> +++ b/arch/arm/boards/stm32mp157c-dk2/board.c
>>>> @@ -4,6 +4,7 @@
>>>>  #include 
>>>>  #include 
>>>>  #include 
>>>> +#include 
>>>>  
>>>>  static int dk2_mem_init(void)
>>>>  {
>>>> @@ -15,3 +16,16 @@ static int dk2_mem_init(void)
>>>>return 0;
>>>>  }
>>>>  mem_initcall(dk2_mem_init);
>>>> +
>>>> +static int dk2_postcore_init(void)
>>>> +{
>>>> +  if (!of_machine_is_compatible("st,stm32mp157c-dk2"))
>>>> +  return 0;
>>>> +
>>>> +  stm32mp_bbu_mmc_register_handler("sd", "/dev/disk0.ssbl",
>>>> +   BBU_HANDLER_FLAG_DEFAULT);
>>>
>>> You should create an alias in dt for the sd device node (might exist
>>> already, don't know) and use mci_of_parse_node() in the SD driver. With
>>> this you get consistent names. "disk0" will be different devices
>>> depending on probe order.
>>
>> Ah, ok. I'll resend when Oleksij resends his.
>> The first patch would be useful to have for other boards as well.
>> Could you apply it seperately?
> 
> I applied all other patches except this one. Environment on SD cards
> doesn't obviously work as long as the driver is not there, but that
> should be a reason to not apply this series, right?

Great, thanks
Ahmad

> 
> 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- |

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


[PATCH] fixup! ARM: at91: build for all SoCs when AT91_MULTI_BOARDS is selected

2019-10-15 Thread Ahmad Fatoum
This reverts a hunk I missed after a rebase:
A previous commit restricts ARCH_BAREBOX_MAX_BARE_INIT to only
non-multi-image boards, so no need to touch it to be compatible
with the new multi-image changes.

---
 arch/arm/mach-at91/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index ef00e32e380d..5ad1f62c8d67 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -245,13 +245,13 @@ config ARCH_BAREBOX_MAX_BARE_INIT_SIZE
hex
default 0x1000 if ARCH_AT91SAM9260
default 0x27000 if ARCH_AT91SAM9261
+   default 0x12000 if ARCH_AT91SAM9263
default 0x4000 if ARCH_AT91SAM9G20
default 0x3000 if ARCH_AT91SAM9G10
default 0xF000 if ARCH_AT91SAM9G45
+   default 0x6000 if ARCH_AT91SAM9X5
default 0x6000 if ARCH_AT91SAM9N12
-   default 0x12000 if SOC_AT91SAM9263
-   default 0x6000 if SOC_AT91SAM9X5
-   default 0x6000 if SOC_SAMA5D3
+   default 0x6000 if ARCH_SAMA5D3
default 0x
 
 if ARCH_AT91RM9200
-- 
2.23.0


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


Re: [PATCH 4/5] ARM: stm32mp: dk2: add barebox SD-Card update handler

2019-10-15 Thread Ahmad Fatoum
Hello,

On 10/14/19 2:51 PM, Sascha Hauer wrote:
> On Mon, Oct 14, 2019 at 08:39:21AM +0200, Ahmad Fatoum wrote:
>> Now with the SD/MMC controller supported, lets add a bbu handler, so we
>> can use it to update the second stage boot loader partition.
>>
>> Signed-off-by: Ahmad Fatoum 
>> ---
>>  arch/arm/boards/stm32mp157c-dk2/board.c  | 14 ++
>>  arch/arm/mach-stm32mp/include/mach/bbu.h | 14 ++
>>  2 files changed, 28 insertions(+)
>>  create mode 100644 arch/arm/mach-stm32mp/include/mach/bbu.h
>>
>> diff --git a/arch/arm/boards/stm32mp157c-dk2/board.c 
>> b/arch/arm/boards/stm32mp157c-dk2/board.c
>> index 9cb861af85d8..23eb6728b15a 100644
>> --- a/arch/arm/boards/stm32mp157c-dk2/board.c
>> +++ b/arch/arm/boards/stm32mp157c-dk2/board.c
>> @@ -4,6 +4,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  static int dk2_mem_init(void)
>>  {
>> @@ -15,3 +16,16 @@ static int dk2_mem_init(void)
>>  return 0;
>>  }
>>  mem_initcall(dk2_mem_init);
>> +
>> +static int dk2_postcore_init(void)
>> +{
>> +if (!of_machine_is_compatible("st,stm32mp157c-dk2"))
>> +return 0;
>> +
>> +stm32mp_bbu_mmc_register_handler("sd", "/dev/disk0.ssbl",
>> + BBU_HANDLER_FLAG_DEFAULT);
> 
> You should create an alias in dt for the sd device node (might exist
> already, don't know) and use mci_of_parse_node() in the SD driver. With
> this you get consistent names. "disk0" will be different devices
> depending on probe order.

Ah, ok. I'll resend when Oleksij resends his.
The first patch would be useful to have for other boards as well.
Could you apply it seperately?

Thanks
Ahmad

> 
> 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- |

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


Re: MFGTools from NXP

2019-10-16 Thread Ahmad Fatoum
On 10/16/19 2:35 PM, Mihaita Ivascu wrote:
> No it does not. Still no devices listed.

Strange. What barebox version?

> 
> Thanks,
>   Mihaita
> 
> On Wed, Oct 16, 2019 at 1:36 PM Ahmad Fatoum  wrote:
>>
>> On 10/16/19 1:28 PM, Mihaita Ivascu wrote:
>>> On Wed, Oct 16, 2019 at 11:53 AM Ahmad Fatoum 
>>> wrote:
>>>>
>>>>
>>>> On 10/16/19 11:48 AM, Mihaita Ivascu wrote:
>>>>> On Wed, Oct 16, 2019 at 11:26 AM Ahmad Fatoum 
>>> wrote:
>>>>>>
>>>>>> On 10/16/19 11:21 AM, Mihaita Ivascu wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>>Thanks for your answer. Yes i am able to connect via PUTTY to the
>>> target.
>>>>>>>Then I should use some adb commands in order to push the new
>>>>>>> barebox/firmware ? do you know where I could find some examples?
>>>>>>
>>>>>> fastboot device -l works normally on Linux. You need to check what you
>>> need
>>>>>> to do on Windows to do the same. You should only need the Fastboot
>>> utility
>>>>>> for this.
>>>>>>
>>>>> [mi] Yes I have both fastboot and adb installed on both Windows and
>>>>> Linux machines. In both cases it does not list any device.
>>>>>The board is detected as fastboot android is windows device
>>>>> manager. But the fastboot and adb does not list it. same for Linux.
>>>>> Please see attachment
>>>>
>>>> Let's focus on Linux. You don't see a device there?
>>>> What does barebox say? Does it say 'multi_bind: creating Fastboot
>>> function'?
>>>> What does you Linux host's dmesg say?
>>>>
>>>
>>> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ usbgadget -aA
>>> udc0: registering UDC driver [g_multi]
>>> multi_bind: creating Fastboot function
>>> multi_bind: creating ACM function
>>> g_multi usbgadget: Multifunction Composite Gadget
>>> g_multi usbgadget: userspace failed to provide iSerialNumber
>>> g_multi usbgadget: g_multi ready
>>> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ g_multi usbgadget: high-speed
>>> config #1: Multifunction Composite Gadget
>>>
>>> dmesg:
>>>
>>> [   25.602275] usb 1-1.3: USB disconnect, device number 3
>>> [   28.359930] usb 1-1.3: new high-speed USB device number 5 using ehci-pci
>>> [   28.452971] usb 1-1.3: New USB device found, idVendor=1d6b,
>>> idProduct=0104
>>> [   28.452976] usb 1-1.3: New USB device strings: Mfr=0, Product=2,
>>> SerialNumber=0
>>> [   28.452980] usb 1-1.3: Product: Phytec phyCORE-i.MX6 Ultra Lite SOM
>>> [   28.457925] cdc_acm 1-1.3:1.1: ttyACM0: USB ACM device
>>>
>>>
>>> So I see the device on Linux. But fastboot does not list any device on
>>> Linux.
>>
>> sudo doesn't change this?
>>
>>>
>>>>  >
>>>>>>>
>>>>>>>Also I have a question: purpose of this activity is for me to be
>>>>>>> able to flash some imx6ul boards that have no firmware: no barebox.
>>>>>>>So I know hardware config for the port is otg mode but as I have no
>>>>>>> barebox running them before I am wondering if I will be able to
>>>>>>> connect via PUTTY if I do not set the ACM gadget from barebox?
>>>>>>
>>>>>> Check the Embest MarS board's environment in barebox master. It sets up
>>>>>> a fastboot gadget automatically on boot from imx-usb-loader.
>>>>>> You can adjust it to your liking.
>>>>>
>>>>>   [mi] I was not able to find any docs about this board. I will keep
>>>>> searching/asking in the nxp community. If you have already ahve any
>>>>> files related to it would be helpful. Thanks
>>>>
>>>> It's in the barebox next branch (not master, sorry), see here:
>>>>
>>> https://github.com/saschahauer/barebox/blob/next/arch/arm/boards/embest-marsboard/defaultenv-mars/init/fastboot
>>>>
>>>> You can copy and adjust the environment setup for your board.
>>>>
>>>>>>
>>>>>> Cheers
>>>>>> Ahmad
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>   Mihaita
>>>>>>&

Re: MFGTools from NXP

2019-10-16 Thread Ahmad Fatoum
On 10/16/19 2:44 PM, Mihaita Ivascu wrote:
> 2018.04.0

I've v2019.09.0 and did the same steps you described and it works for me.
Can you try with a newer version?

> 
> On Wed, Oct 16, 2019 at 2:41 PM Ahmad Fatoum  wrote:
>>
>> On 10/16/19 2:35 PM, Mihaita Ivascu wrote:
>>> No it does not. Still no devices listed.
>>
>> Strange. What barebox version?
>>
>>>
>>> Thanks,
>>>   Mihaita
>>>
>>> On Wed, Oct 16, 2019 at 1:36 PM Ahmad Fatoum  
>>> wrote:
>>>>
>>>> On 10/16/19 1:28 PM, Mihaita Ivascu wrote:
>>>>> On Wed, Oct 16, 2019 at 11:53 AM Ahmad Fatoum 
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 10/16/19 11:48 AM, Mihaita Ivascu wrote:
>>>>>>> On Wed, Oct 16, 2019 at 11:26 AM Ahmad Fatoum 
>>>>> wrote:
>>>>>>>>
>>>>>>>> On 10/16/19 11:21 AM, Mihaita Ivascu wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>>Thanks for your answer. Yes i am able to connect via PUTTY to the
>>>>> target.
>>>>>>>>>Then I should use some adb commands in order to push the new
>>>>>>>>> barebox/firmware ? do you know where I could find some examples?
>>>>>>>>
>>>>>>>> fastboot device -l works normally on Linux. You need to check what you
>>>>> need
>>>>>>>> to do on Windows to do the same. You should only need the Fastboot
>>>>> utility
>>>>>>>> for this.
>>>>>>>>
>>>>>>> [mi] Yes I have both fastboot and adb installed on both Windows and
>>>>>>> Linux machines. In both cases it does not list any device.
>>>>>>>The board is detected as fastboot android is windows device
>>>>>>> manager. But the fastboot and adb does not list it. same for Linux.
>>>>>>> Please see attachment
>>>>>>
>>>>>> Let's focus on Linux. You don't see a device there?
>>>>>> What does barebox say? Does it say 'multi_bind: creating Fastboot
>>>>> function'?
>>>>>> What does you Linux host's dmesg say?
>>>>>>
>>>>>
>>>>> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ usbgadget -aA
>>>>> udc0: registering UDC driver [g_multi]
>>>>> multi_bind: creating Fastboot function
>>>>> multi_bind: creating ACM function
>>>>> g_multi usbgadget: Multifunction Composite Gadget
>>>>> g_multi usbgadget: userspace failed to provide iSerialNumber
>>>>> g_multi usbgadget: g_multi ready
>>>>> barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ g_multi usbgadget: 
>>>>> high-speed
>>>>> config #1: Multifunction Composite Gadget
>>>>>
>>>>> dmesg:
>>>>>
>>>>> [   25.602275] usb 1-1.3: USB disconnect, device number 3
>>>>> [   28.359930] usb 1-1.3: new high-speed USB device number 5 using 
>>>>> ehci-pci
>>>>> [   28.452971] usb 1-1.3: New USB device found, idVendor=1d6b,
>>>>> idProduct=0104
>>>>> [   28.452976] usb 1-1.3: New USB device strings: Mfr=0, Product=2,
>>>>> SerialNumber=0
>>>>> [   28.452980] usb 1-1.3: Product: Phytec phyCORE-i.MX6 Ultra Lite SOM
>>>>> [   28.457925] cdc_acm 1-1.3:1.1: ttyACM0: USB ACM device
>>>>>
>>>>>
>>>>> So I see the device on Linux. But fastboot does not list any device on
>>>>> Linux.
>>>>
>>>> sudo doesn't change this?
>>>>
>>>>>
>>>>>>  >
>>>>>>>>>
>>>>>>>>>Also I have a question: purpose of this activity is for me to be
>>>>>>>>> able to flash some imx6ul boards that have no firmware: no barebox.
>>>>>>>>>So I know hardware config for the port is otg mode but as I have no
>>>>>>>>> barebox running them before I am wondering if I will be able to
>>>>>>>>> connect via PUTTY if I do not set the ACM gadget from barebox?
>>>>>>>>
>>>>>>>> Check the Embest MarS board's environment in barebox master. It sets up
>>>>>>>> a fastboot gadget automatically

Re: imx7d enable second core

2019-10-15 Thread Ahmad Fatoum
On 10/15/19 1:29 PM, Giorgio Dal Molin wrote:
> Hi,
> 
> can anyone please confirm that a recent barebox version (v2019.10 or v2019.09)
> is able to boot a linux kernel so that it can enable the second cpu core ?

If you #define DEBUG in arch/arm/cpu/psci.c, a smc command is enabled that can
be used to test ARM_PSCI_0_2_CPU_ON. This might aid you in your debug effort.

Cheers
Ahmad

> It actually used to work in the past but now I only get one core running:
> 
> Loading ARM Linux zImage '/mnt/boot/kernel.img'
> Loading devicetree from '/mnt/boot/devtree.dtb'
> commandline: console=ttymxc0,115200n8 
> ip=11.0.0.4::11.0.0.2:255.0.0.0:armgdm:eth0: 
> root=PARTUUID=abd2f9f6-88e5-4657-a5fb-aeb2cc6fde7e rootwait 
> video=HDMI-A-1:1024x768M@60 console=tty1
> Starting kernel in nonsecure mode
> [0.00] 000: Booting Linux on physical CPU 0x0
> [0.00] 000: Linux version 5.2.19-rt11-00268-g0308d71d8410-dirty 
> (giorgio@BVblfs) (gcc version 9.2.1 20190813 (OSELAS.Toolchain 9.2.1)) #1 SMP 
> PREEMPT RT Thu Oct 10 07:50:01 CEST 2019
> [0.00] 000: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
> cr=10c5387d
> [0.00] 000: CPU: div instructions available: patching division code
> [0.00] 000: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] 000: OF: fdt: Machine model: Freescale i.MX7 SabreSD Board
> [0.00] 000: Memory policy: Data cache writealloc
> [0.00] 000: cma: Reserved 64 MiB at 0xac00
> [0.00] 000: percpu: Embedded 10 pages/cpu s19296 r0 d21664 u40960
> [0.00] 000: Built 1 zonelists, mobility grouping on.  Total pages: 
> 260608
> [0.00] 000: Kernel command line: console=ttymxc0,115200n8 
> ip=11.0.0.4::11.0.0.2:255.0.0.0:armgdm:eth0: 
> root=PARTUUID=abd2f9f6-88e5-4657-a5fb-aeb2cc6fde7e rootwait 
> video=HDMI-A-1:1024x768M@60 console=tty1
> [0.00] 000: Dentry cache hash table entries: 131072 (order: 8, 
> 1048576 bytes)
> [0.00] 000: Inode-cache hash table entries: 65536 (order: 6, 262144 
> bytes)
> [0.00] 000: Memory: 958252K/1048576K available (9216K kernel code, 
> 403K rwdata, 2308K rodata, 1024K init, 719K bss, 24788K reserved, 65536K 
> cma-reserved, 261700K highmem)
> [0.00] 000: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [0.00] 000: rcu: Preemptible hierarchical RCU implementation.
> [0.00] 000: rcu:RCU priority boosting: priority 1 delay 500 
> ms.
> [0.00] 000: rcu:RCU_SOFTIRQ processing moved to rcuc kthreads.
> [0.00] 000: No expedited grace period (rcu_normal_after_boot).
> [0.00] 000: Tasks RCU enabled.
> [0.00] 000: rcu: RCU calculated value of scheduler-enlistment delay 
> is 10 jiffies.
> [0.00] 000: NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [0.00] 000: rcu:Offload RCU callbacks from CPUs: (none).
> [0.00] 000: arch_timer: cp15 timer(s) running at 8.00MHz (virt).
> [0.00] 000: clocksource: arch_sys_counter: mask: 0xff 
> max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
> [0.01] 000: sched_clock: 56 bits at 8MHz, resolution 125ns, wraps 
> every 2199023255500ns
> [0.12] 000: Switching to timer-based delay loop, resolution 125ns
> [0.000433] 000: Switching to timer-based delay loop, resolution 41ns
> [0.000445] 000: sched_clock: 32 bits at 24MHz, resolution 41ns, wraps 
> every 89478484971ns
> [0.000456] 000: clocksource: mxc_timer1: mask: 0x max_cycles: 
> 0x, max_idle_ns: 79635851949 ns
> [0.001625] 000: Console: colour dummy device 80x30
> [0.001638] 000: printk: console [tty1] enabled
> [0.001673] 000: Calibrating delay loop (skipped), value calculated using 
> timer frequency.. 48.00 BogoMIPS (lpj=24)
> [0.001680] 000: pid_max: default: 32768 minimum: 301
> [0.001816] 000: Mount-cache hash table entries: 2048 (order: 1, 8192 
> bytes)
> [0.001833] 000: Mountpoint-cache hash table entries: 2048 (order: 1, 8192 
> bytes)
> [0.002543] 000: CPU: Testing write buffer coherency: ok
> [0.002896] 000: CPU0: update cpu_capacity 1024
> [0.002908] 000: CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> [0.06] 000: Setting up static identity map for 0x8010 - 0x8010003c
> [0.079971] 000: rcu: Hierarchical SRCU implementation.
> [0.160105] 000: smp: Bringing up secondary CPUs ...
> [0.280352] 000: smp: Brought up 1 node, 1 CPU
> [0.280362] 000: SMP: Total of 1 processors activated (48.00 BogoMIPS).
> [0.280370] 000: CPU: All CPU(s) started in SVC mode.
> [0.281280] 000: devtmpfs: initialized
> 
> giorgio
> 
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions  

Re: [PATCH 2/5] scripts: Add rsatoc tool

2019-10-15 Thread Ahmad Fatoum
Hello Sascha,

On 10/15/19 9:55 AM, Sascha Hauer wrote:
> The rsatoc tool converts rsa public keys into C structs suitable to
> compile with barebox. Most of the openssl rsa related stuff has been
> taken from the U-Boot mkimage tool.

I don't have any FIT image or RSA options enabled, yet my build fails now with:

  RSAKEY  crypto/rsa-keys.h 

/bin/sh: 1: ./scripts/rsatoc: not found   
./crypto/Makefile:27: recipe for target 'crypto/rsa-keys.h' failed
make[2]: *** [crypto/rsa-keys.h] Error 127  

./Makefile:802: recipe for target 'crypto' failed 
make[1]: *** [crypto] Error 2   


Cheers
Ahmad

> 
> Signed-off-by: Sascha Hauer 
> ---
>  scripts/.gitignore |   1 +
>  scripts/Makefile   |   3 +
>  scripts/rsatoc.c   | 445 +
>  3 files changed, 449 insertions(+)
>  create mode 100644 scripts/rsatoc.c
> 
> diff --git a/scripts/.gitignore b/scripts/.gitignore
> index 45c81bf8f4..76ea271abb 100644
> --- a/scripts/.gitignore
> +++ b/scripts/.gitignore
> @@ -29,3 +29,4 @@ mxs-usb-loader
>  omap4_usbboot
>  omap3-usb-loader
>  mips-relocs
> +rsatoc
> diff --git a/scripts/Makefile b/scripts/Makefile
> index dffab53c73..81d1a501b0 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -10,6 +10,9 @@ hostprogs-y  += fix_size
>  hostprogs-y  += bareboxenv
>  hostprogs-y  += bareboxcrc32
>  hostprogs-y  += kernel-install
> +hostprogs-$(CONFIG_CRYPTO_RSA_BUILTIN_KEYS) += rsatoc
> +HOSTCFLAGS_rsatoc = `pkg-config --cflags openssl`
> +HOSTLDLIBS_rsatoc = `pkg-config --libs openssl`
>  hostprogs-$(CONFIG_IMD)  += bareboximd
>  hostprogs-$(CONFIG_KALLSYMS) += kallsyms
>  hostprogs-$(CONFIG_MIPS) += mips-relocs
> diff --git a/scripts/rsatoc.c b/scripts/rsatoc.c
> new file mode 100644
> index 00..f853691908
> --- /dev/null
> +++ b/scripts/rsatoc.c
> @@ -0,0 +1,445 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * rsatoc - utility to convert an RSA key to a C struct
> + *
> + * This tool converts an RSA key given as file or PKCS#11
> + * URI to a C struct suitable to compile with barebox.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int rsa_err(const char *msg)
> +{
> + unsigned long sslErr = ERR_get_error();
> +
> + fprintf(stderr, "%s", msg);
> + fprintf(stderr, ": %s\n",
> + ERR_error_string(sslErr, 0));
> +
> + return -1;
> +}
> +
> +/**
> + * rsa_pem_get_pub_key() - read a public key from a .crt file
> + *
> + * @keydir:  Directory containins the key
> + * @name Name of key file (will have a .crt extension)
> + * @rsap Returns RSA object, or NULL on failure
> + * @return 0 if ok, -ve on error (in which case *rsap will be set to NULL)
> + */
> +static int rsa_pem_get_pub_key(const char *path, RSA **rsap)
> +{
> + EVP_PKEY *key;
> + X509 *cert;
> + RSA *rsa;
> + FILE *f;
> + int ret;
> +
> + *rsap = NULL;
> + f = fopen(path, "r");
> + if (!f) {
> + fprintf(stderr, "Couldn't open RSA certificate: '%s': %s\n",
> + path, strerror(errno));
> + return -EACCES;
> + }
> +
> + /* Read the certificate */
> + cert = NULL;
> + if (!PEM_read_X509(f, , NULL, NULL)) {
> + rsa_err("Couldn't read certificate");
> + ret = -EINVAL;
> + goto err_cert;
> + }
> +
> + /* Get the public key from the certificate. */
> + key = X509_get_pubkey(cert);
> + if (!key) {
> + rsa_err("Couldn't read public key\n");
> + ret = -EINVAL;
> + goto err_pubkey;
> + }
> +
> + /* Convert to a RSA_style key. */
> + rsa = EVP_PKEY_get1_RSA(key);
> + if (!rsa) {
> + rsa_err("Couldn't convert to a RSA style key");
> + ret = -EINVAL;
> + goto err_rsa;
> + }
> + fclose(f);
> + EVP_PKEY_free(key);
> + X509_free(cert);
> + *rsap = rsa;
> +
> + return 0;
> +
> +err_rsa:
> + EVP_PKEY_free(key);
> +err_pubkey:
> + X509_free(cert);
> +err_cert:
> + fclose(f);
> + return ret;
> +}
> +
> +/**
> + * rsa_engine_get_pub_key() - read a public key from given engine
> + *
> + * @keydir:  Key prefix
> + * @name Name of key
> + * @engine   Engine to use
> + * @rsap Returns RSA object, or NULL on failure
> + * @return 0 if ok, -ve on error (in which case *rsap will be set to NULL)
> + */
> +static int rsa_engine_get_pub_key(const char *key_id,
> +   ENGINE *engine, RSA **rsap)
> +{
> + EVP_PKEY *key;
> + RSA 

<    1   2   3   4   5   6   7   8   9   10   >