Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Wolfgang Denk]

Dear Aaron,

In message <5376617.97hUrJXovB@flash> you wrote:
>
> > Again you don't answer my question.  Why do you need a special new
> > API for such code?  Why do you not just link that code with the rest
> > of U-Boot?
>
> The code in question that is calling the API is not GPL and hence cannot be 
> linked with U-Boot though the phy code is GPL.

Ouch.  I was afraid to hear that.

Please be aware that your newly created API does NOT implement a GPL
license exception.  the only interface that allows for non-GPL code
to be run under control of U-Boot is the standalone program
interface, which is intentionally very restricted.

In other words: what you are doing here is a clear (and intentional,
which makes it even worse) GPL license violation.

> > It has been mentioned before, but just to be sure: this code which
> > uses your new API is licensed under a GPLv2 conforming lincense?
> > 
> There should be no need. None of the code is linked against U-Boot, either at 
> compile time nor at runtime. The application doesn't even know where it is 
> located except by looking for a named block of memory.

It does not have to be linked.  You access internal interfaces of
U-Boot that have not been exported for non-GPL use, so your code
still has to be licensed under GPLv2 or a compatible license.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"I've finally learned what `upward compatible' means. It means we get
to keep all our old mistakes." - Dennie van Tassel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Wolfgang Denk]

Dear Aaron,

In message <1838672.aZrPjDvGh8@flash> you wrote:
>
> To be blunt, the current U-Boot EFI driver does not provide the required 
> functionality. It would need to be extended in order to work. In addition, 
> spinlocks would be required in order to handle the case of reentrancy. Also, 
> how does the EFI loader deal with loading multiple applications across 
> multiple cores? The block support is the least important part of it. There 
> are 
> several other services not related to block devices or network calls.

Maybe you are just trying to squeeze too much of operating system
functionality into a mere boot loader?

Using tools for purposes they have not been designed for has never
been a good idea...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I think animal testing is a terrible idea; they get all  nervous  and
give the wrong answers.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] [PATCH v2 2/2] arm: ls1028a: use the new flexspi driver

[Michael Walle]

Hi Singh,

Am 2019-11-05 07:40, schrieb Kuldeep Singh:

Hi Michael,


-Original Message-
From: U-Boot  On Behalf Of Michael Walle
Sent: Saturday, November 2, 2019 11:56 PM
To: u-boot@lists.denx.de
Subject: [EXT] [U-Boot] [PATCH v2 2/2] arm: ls1028a: use the new 
flexspi

driver

Caution: EXT Email

Also align the fspi node with the kernel one. There is actually no 
driver which

would match "nxp,dn-fspi".

Signed-off-by: Michael Walle 
---
changes since v1:
 - none

 arch/arm/dts/fsl-ls1028a.dtsi | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi 
b/arch/arm/dts/fsl-ls1028a.dtsi index

43a154e8e7..774e477542 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -49,14 +49,16 @@
 <1 10 0x8>; /* Hypervisor PPI, active-low 
*/

};

-   fspi: flexspi@20C {
-   compatible = "nxp,dn-fspi";
+   fspi: flexspi@20c {
+   compatible = "nxp,lx2160a-fspi";
#address-cells = <1>;
#size-cells = <0>;
-   reg = <0x0 0x20C 0x0 0x1>,
-   <0x0 0x2000 0x0 0x1000>; /*64MB 
flash*/

-   reg-names = "FSPI", "FSPI-memory";
-   num-cs = <1>;
+   reg = <0x0 0x20c 0x0 0x1>,
+ <0x0 0x2000 0x0 0x1000>;
+   reg-names = "fspi_base", "fspi_mmap";
+   clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+   clock-names = "fspi_en", "fspi";
+   interrupts = <0 25 0x4>;


Please change the interrupts to "" as
it avoids magic numbers.


This is consistent with the other interrupt properties, which doesn't 
have these constants either. IMHO another commit where all these magic 
numbers are removed would be better.




Reviewed-by: Kuldeep Singh 

Thanks.

-michael
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] [PATCH v2 2/2] arm: ls1028a: use the new flexspi driver

[Kuldeep Singh]

Hi Michael,

> -Original Message-
> From: Michael Walle 
> Sent: Tuesday, November 5, 2019 3:07 PM
> To: Kuldeep Singh 
> Cc: u-boot@lists.denx.de
> Subject: Re: [EXT] [U-Boot] [PATCH v2 2/2] arm: ls1028a: use the new flexspi
> driver
> 
> Caution: EXT Email
> 
> Hi Singh,
> 
> Am 2019-11-05 07:40, schrieb Kuldeep Singh:
> > Hi Michael,
> >
> >> -Original Message-
> >> From: U-Boot  On Behalf Of Michael
> >> Walle
> >> Sent: Saturday, November 2, 2019 11:56 PM
> >> To: u-boot@lists.denx.de
> >> Subject: [EXT] [U-Boot] [PATCH v2 2/2] arm: ls1028a: use the new
> >> flexspi driver
> >>
> >> Caution: EXT Email
> >>
> >> Also align the fspi node with the kernel one. There is actually no
> >> driver which would match "nxp,dn-fspi".
> >>
> >> Signed-off-by: Michael Walle 
> >> ---
> >> changes since v1:
> >>  - none
> >>
> >>  arch/arm/dts/fsl-ls1028a.dtsi | 14 --
> >>  1 file changed, 8 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi
> >> b/arch/arm/dts/fsl-ls1028a.dtsi index
> >> 43a154e8e7..774e477542 100644
> >> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> >> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> >> @@ -49,14 +49,16 @@
> >>  <1 10 0x8>; /* Hypervisor PPI,
> >> active-low */
> >> };
> >>
> >> -   fspi: flexspi@20C {
> >> -   compatible = "nxp,dn-fspi";
> >> +   fspi: flexspi@20c {
> >> +   compatible = "nxp,lx2160a-fspi";
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> -   reg = <0x0 0x20C 0x0 0x1>,
> >> -   <0x0 0x2000 0x0 0x1000>; /*64MB
> >> flash*/
> >> -   reg-names = "FSPI", "FSPI-memory";
> >> -   num-cs = <1>;
> >> +   reg = <0x0 0x20c 0x0 0x1>,
> >> + <0x0 0x2000 0x0 0x1000>;
> >> +   reg-names = "fspi_base", "fspi_mmap";
> >> +   clocks = <&clockgen 4 3>, <&clockgen 4 3>;
> >> +   clock-names = "fspi_en", "fspi";
> >> +   interrupts = <0 25 0x4>;
> >
> > Please change the interrupts to "" as
> > it avoids magic numbers.
> 
> This is consistent with the other interrupt properties, which doesn't have 
> these
> constants either. IMHO another commit where all these magic numbers are
> removed would be better.
> 

I just checked and found no interrupt handler in spi/nxp_fspi.c driver. So, 
it's better to remove this line altogether. What do you think?

-Kuldeep
> 
> > Reviewed-by: Kuldeep Singh 
> Thanks.
> 
> -michael
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 0/4] RPi one binary for RPi3/4 and RPi1/2

[matthias . bgg]

From: Matthias Brugger 

In this series we prepare the RaspberryPi source code
to be able to build one binary for RPi[3,4] and one for RPi[1,2].
To achieve this we need to set the IO base address on runtime. Apart
from that, for arm64 we also need to set memory region correctly.

This patches fix this stuff. With this we could create one binary for
each armv7 and armv8 based RPis. There is still some work to do to
create a unified config, which will be done in a later patch series.

Changes in v2:
- push fw_dtb_pointer into the .data section
- fix register access in reset_cpu()
- rename BCM2838 to BCM2711 in the correct patch
- push rpi_bcm283x_base into the .data section
- Move mem_map out of assembly file
- push mem_map into the .data section
- update the members of mem_map inestead of the pointer

Matthias Brugger (4):
  rpi: push fw_dtb_pointer in the .data section
  ARM: bcm283x: Move BCM283x_BASE to a global variable
  ARM: bcm283x: Set rpi_bcm283x_base at run-time
  ARM: bcm283x: Set memory map at run-time

 arch/arm/mach-bcm283x/Kconfig  |   6 -
 arch/arm/mach-bcm283x/include/mach/base.h  |  11 ++
 arch/arm/mach-bcm283x/include/mach/mbox.h  |   4 +-
 arch/arm/mach-bcm283x/include/mach/sdhci.h |   5 +-
 arch/arm/mach-bcm283x/include/mach/timer.h |   7 +-
 arch/arm/mach-bcm283x/include/mach/wdog.h  |   5 +-
 arch/arm/mach-bcm283x/init.c   | 140 +
 arch/arm/mach-bcm283x/mbox.c   |   1 +
 arch/arm/mach-bcm283x/reset.c  |  20 ++-
 board/raspberrypi/rpi/lowlevel_init.S  |   9 --
 board/raspberrypi/rpi/rpi.c|  49 +---
 include/configs/rpi.h  |   4 +
 12 files changed, 190 insertions(+), 71 deletions(-)
 create mode 100644 arch/arm/mach-bcm283x/include/mach/base.h

-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/4] ARM: bcm283x: Move BCM283x_BASE to a global variable

[matthias . bgg]

From: Matthias Brugger 

We move the per SOC define BCM283x_BASE to a global variable.
This is a first step to provide a single binary for several bcm283x
SoCs.

Signed-off-by: Matthias Brugger 

---

Changes in v2:
- fix register access in reset_cpu()

 arch/arm/mach-bcm283x/include/mach/base.h  | 11 +++
 arch/arm/mach-bcm283x/include/mach/mbox.h  |  4 +++-
 arch/arm/mach-bcm283x/include/mach/sdhci.h |  5 -
 arch/arm/mach-bcm283x/include/mach/timer.h |  7 ++-
 arch/arm/mach-bcm283x/include/mach/wdog.h  |  5 -
 arch/arm/mach-bcm283x/init.c   |  8 
 arch/arm/mach-bcm283x/mbox.c   |  1 +
 arch/arm/mach-bcm283x/reset.c  | 20 +++-
 include/configs/rpi.h  |  4 
 9 files changed, 56 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/mach-bcm283x/include/mach/base.h

diff --git a/arch/arm/mach-bcm283x/include/mach/base.h 
b/arch/arm/mach-bcm283x/include/mach/base.h
new file mode 100644
index 00..c4ae39852f
--- /dev/null
+++ b/arch/arm/mach-bcm283x/include/mach/base.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * (C) Copyright 2019 Matthias Brugger
+ */
+
+#ifndef _BCM283x_BASE_H_
+#define _BCM283x_BASE_H_
+
+extern unsigned long rpi_bcm283x_base;
+
+#endif
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h 
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 0b6c2543d5..60e226ce1d 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -7,6 +7,7 @@
 #define _BCM2835_MBOX_H
 
 #include 
+#include 
 
 /*
  * The BCM2835 SoC contains (at least) two CPUs; the VideoCore (a/k/a "GPU")
@@ -37,7 +38,8 @@
 
 /* Raw mailbox HW */
 
-#define BCM2835_MBOX_PHYSADDR  (CONFIG_BCM283x_BASE + 0xb880)
+#define BCM2835_MBOX_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
+rpi_bcm283x_base + 0xb880; })
 
 struct bcm2835_mbox_regs {
u32 read;
diff --git a/arch/arm/mach-bcm283x/include/mach/sdhci.h 
b/arch/arm/mach-bcm283x/include/mach/sdhci.h
index b443c379d8..7323690687 100644
--- a/arch/arm/mach-bcm283x/include/mach/sdhci.h
+++ b/arch/arm/mach-bcm283x/include/mach/sdhci.h
@@ -6,7 +6,10 @@
 #ifndef _BCM2835_SDHCI_H_
 #define _BCM2835_SDHCI_H_
 
-#define BCM2835_SDHCI_BASE (CONFIG_BCM283x_BASE + 0x0030)
+#include 
+
+#define BCM2835_SDHCI_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
+ rpi_bcm283x_base + 0x0030; })
 
 int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq);
 
diff --git a/arch/arm/mach-bcm283x/include/mach/timer.h 
b/arch/arm/mach-bcm283x/include/mach/timer.h
index 014355e759..54f733a956 100644
--- a/arch/arm/mach-bcm283x/include/mach/timer.h
+++ b/arch/arm/mach-bcm283x/include/mach/timer.h
@@ -6,7 +6,12 @@
 #ifndef _BCM2835_TIMER_H
 #define _BCM2835_TIMER_H
 
-#define BCM2835_TIMER_PHYSADDR (CONFIG_BCM283x_BASE + 0x3000)
+#ifndef __ASSEMBLY__
+#include 
+#endif
+
+#define BCM2835_TIMER_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
+ rpi_bcm283x_base + 0x3000; })
 
 #define BCM2835_TIMER_CS_M3(1 << 3)
 #define BCM2835_TIMER_CS_M2(1 << 2)
diff --git a/arch/arm/mach-bcm283x/include/mach/wdog.h 
b/arch/arm/mach-bcm283x/include/mach/wdog.h
index 8292b3cf1f..9942666720 100644
--- a/arch/arm/mach-bcm283x/include/mach/wdog.h
+++ b/arch/arm/mach-bcm283x/include/mach/wdog.h
@@ -6,7 +6,10 @@
 #ifndef _BCM2835_WDOG_H
 #define _BCM2835_WDOG_H
 
-#define BCM2835_WDOG_PHYSADDR  (CONFIG_BCM283x_BASE + 0x0010)
+#include 
+
+#define BCM2835_WDOG_PHYSADDR ({ BUG_ON(!rpi_bcm283x_base); \
+rpi_bcm283x_base + 0x0010; })
 
 struct bcm2835_wdog_regs {
u32 unknown0[7];
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 97414415a6..d36017e823 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -8,6 +8,8 @@
 
 #include 
 
+unsigned long rpi_bcm283x_base;
+
 int arch_cpu_init(void)
 {
icache_enable();
@@ -15,6 +17,12 @@ int arch_cpu_init(void)
return 0;
 }
 
+int mach_cpu_init(void)
+{
+   rpi_bcm283x_base = CONFIG_BCM283x_BASE;
+
+   return 0;
+}
 #ifdef CONFIG_ARMV7_LPAE
 void enable_caches(void)
 {
diff --git a/arch/arm/mach-bcm283x/mbox.c b/arch/arm/mach-bcm283x/mbox.c
index 3c67f68c17..467d0d5fba 100644
--- a/arch/arm/mach-bcm283x/mbox.c
+++ b/arch/arm/mach-bcm283x/mbox.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/arch/arm/mach-bcm283x/reset.c b/arch/arm/mach-bcm283x/reset.c
index b3da0c7cd6..cd8138d702 100644
--- a/arch/arm/mach-bcm283x/reset.c
+++ b/arch/arm/mach-bcm283x/reset.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -25,10 +26,10 @@
 
 void hw_watchdog_disable(void) {}
 
-__efi_runtime_data struct bcm2835_wdog_regs *wdog_regs =
-   (struct bcm2835_wdog_regs *)BCM2835_WDOG_PHYSADDR;
+__efi_runtime_data struct bcm2835_wdog_reg

[U-Boot] [PATCH v2 1/4] rpi: push fw_dtb_pointer in the .data section

[matthias . bgg]

From: Matthias Brugger 

The fw_dtb_pointer was defined in the assembly code, which makes him
live in section .text_rest
Put that's not necessary, we can push the variable in the .data section.

This will prevent relocation errors like:
board/raspberrypi/rpi/rpi.c:317:(.text.board_get_usable_ram_top+0x8):
relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC against symbol
`fw_dtb_pointer' defined in .text section in board/raspberrypi/rpi/built-in.o

Signed-off-by: Matthias Brugger 

---

Changes in v2:
- push fw_dtb_pointer into the .data section

 board/raspberrypi/rpi/lowlevel_init.S | 9 -
 board/raspberrypi/rpi/rpi.c   | 4 ++--
 2 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/board/raspberrypi/rpi/lowlevel_init.S 
b/board/raspberrypi/rpi/lowlevel_init.S
index 435eed521f..2913143911 100644
--- a/board/raspberrypi/rpi/lowlevel_init.S
+++ b/board/raspberrypi/rpi/lowlevel_init.S
@@ -6,15 +6,6 @@
 
 #include 
 
-.align 8
-.global fw_dtb_pointer
-fw_dtb_pointer:
-#ifdef CONFIG_ARM64
-   .dword 0x0
-#else
-   .word 0x0
-#endif
-
 /*
  * Routine: save_boot_params (called after reset from start.S)
  * Description: save ATAG/FDT address provided by the firmware at boot time
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 9e0abdda31..0e05d59e1f 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -27,8 +27,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-/* From lowlevel_init.S */
-extern unsigned long fw_dtb_pointer;
+/* Assigned in lowlevel_init.S */
+unsigned long fw_dtb_pointer = 0x1;
 
 /* TODO(s...@chromium.org): Move these to the msg.c file */
 struct msg_get_arm_mem {
-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 3/4] ARM: bcm283x: Set rpi_bcm283x_base at run-time

[matthias . bgg]

From: Matthias Brugger 

As part of the effort to create one binary for several bcm83x SoCs
we use the SoC compatible to decide which IO base address we use.

Signed-off-by: Matthias Brugger 

---

Changes in v2:
- rename BCM2838 to BCM2711 in the correct patch
- push rpi_bcm283x_base into the .data section

 arch/arm/mach-bcm283x/Kconfig |  6 
 arch/arm/mach-bcm283x/init.c  | 62 +--
 2 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
index d9808609e2..00419bf254 100644
--- a/arch/arm/mach-bcm283x/Kconfig
+++ b/arch/arm/mach-bcm283x/Kconfig
@@ -209,10 +209,4 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "rpi"
 
-config BCM283x_BASE
-   hex
-   default "0x2000" if BCM2835
-   default "0x3f00" if BCM2836 || BCM2837
-   default "0xfe00" if BCM2711
-
 endmenu
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index d36017e823..d374fb60ba 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -7,8 +7,48 @@
  */
 
 #include 
+#include 
 
-unsigned long rpi_bcm283x_base;
+#define PDATA_BCM2835  0
+#define PDATA_BCM2836  1
+#define PDATA_BCM2837  2
+#define PDATA_BCM2711  3
+
+unsigned long rpi_bcm283x_base = 0x3f00;
+
+struct bcm283x_pdata {
+   unsigned long io_base;
+};
+
+struct bcm283x_pdata pdata_bcm283x[] = {
+   [PDATA_BCM2835] = {
+   .io_base = 0x2000,
+   },
+   [PDATA_BCM2836] = {
+   .io_base = 0x3f00,
+   },
+#ifdef CONFIG_ARM64
+   [PDATA_BCM2837] = {
+   .io_base = 0x3f00,
+   },
+   [PDATA_BCM2711] = {
+   .io_base = 0xfe00,
+   },
+#endif
+};
+
+/*
+ * I/O address space varies on different chip versions.
+ * We set the base address by inspecting the DTB.
+ */
+static const struct udevice_id board_ids[] = {
+   { .compatible = "brcm,bcm2835", .data = PDATA_BCM2835},
+   { .compatible = "brcm,bcm2836", .data = PDATA_BCM2836},
+   { .compatible = "brcm,bcm2837", .data = PDATA_BCM2837},
+   { .compatible = "brcm,bcm2838", .data = PDATA_BCM2711},
+   { .compatible = "brcm,bcm2711", .data = PDATA_BCM2711},
+   { },
+};
 
 int arch_cpu_init(void)
 {
@@ -19,10 +59,28 @@ int arch_cpu_init(void)
 
 int mach_cpu_init(void)
 {
-   rpi_bcm283x_base = CONFIG_BCM283x_BASE;
+   const struct udevice_id *of_match = board_ids;
+   int ret;
+
+   rpi_bcm283x_base = 0;
+
+   while (of_match->compatible) {
+   struct bcm283x_pdata pdat;
+
+   ret = fdt_node_check_compatible(gd->fdt_blob, 0,
+   of_match->compatible);
+   if (!ret) {
+   pdat = pdata_bcm283x[of_match->data];
+   rpi_bcm283x_base = pdat.io_base;
+   break;
+   }
+
+   of_match++;
+   }
 
return 0;
 }
+
 #ifdef CONFIG_ARMV7_LPAE
 void enable_caches(void)
 {
-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 4/4] ARM: bcm283x: Set memory map at run-time

[matthias . bgg]

From: Matthias Brugger 

For bcm283x based on arm64 we also have to change the mm_region.
Add assign this in mach_cpu_init() so we can create now one binary
for RPi3 and RPi4.

Signed-off-by: Matthias Brugger 

---

Changes in v2:
- Move mem_map out of assembly file
- push mem_map into the .data section
- update the members of mem_map inestead of the pointer

 arch/arm/mach-bcm283x/init.c | 74 
 board/raspberrypi/rpi/rpi.c  | 45 --
 2 files changed, 74 insertions(+), 45 deletions(-)

diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index d374fb60ba..639a5cf975 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -8,6 +8,9 @@
 
 #include 
 #include 
+#ifdef CONFIG_ARM64
+#include 
+#endif
 
 #define PDATA_BCM2835  0
 #define PDATA_BCM2836  1
@@ -16,23 +19,77 @@
 
 unsigned long rpi_bcm283x_base = 0x3f00;
 
+#ifdef CONFIG_ARM64
+static struct mm_region bcm283x_mem_map[] = {
+   {
+   .virt = 0xUL,
+   .phys = 0xUL,
+   .size = 0x3f00UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   .virt = 0x3f00UL,
+   .phys = 0x3f00UL,
+   .size = 0x0100UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   /* List terminator */
+   0,
+   }
+};
+
+static struct mm_region bcm2711_mem_map[] = {
+   {
+   .virt = 0xUL,
+   .phys = 0xUL,
+   .size = 0xfe00UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   .virt = 0xfe00UL,
+   .phys = 0xfe00UL,
+   .size = 0x0180UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   /* List terminator */
+   0,
+   }
+};
+
+struct mm_region *mem_map = bcm283x_mem_map;
+
+#else
+struct mm_region {
+   /* dummy struct */
+};
+#endif
+
 struct bcm283x_pdata {
unsigned long io_base;
+   struct mm_region *m_map;
 };
 
 struct bcm283x_pdata pdata_bcm283x[] = {
[PDATA_BCM2835] = {
.io_base = 0x2000,
+   .m_map = NULL,
},
[PDATA_BCM2836] = {
.io_base = 0x3f00,
+   .m_map = NULL,
},
 #ifdef CONFIG_ARM64
[PDATA_BCM2837] = {
.io_base = 0x3f00,
+   .m_map = bcm283x_mem_map,
},
[PDATA_BCM2711] = {
.io_base = 0xfe00,
+   .m_map = bcm2711_mem_map
},
 #endif
 };
@@ -57,6 +114,22 @@ int arch_cpu_init(void)
return 0;
 }
 
+#ifdef CONFIG_ARM64
+static void rpi_updated_mem_map(struct mm_region *pd)
+{
+   int i;
+
+   for (i = 0; i < 2; i++) {
+   mem_map[i].virt = pd[i].virt;
+   mem_map[i].phys = pd[i].phys;
+   mem_map[i].size = pd[i].size;
+   mem_map[i].attrs = pd[i].attrs;
+   }
+}
+#else
+static void rpi_updated_mem_map(struct mm_region *pd) {}
+#endif
+
 int mach_cpu_init(void)
 {
const struct udevice_id *of_match = board_ids;
@@ -72,6 +145,7 @@ int mach_cpu_init(void)
if (!ret) {
pdat = pdata_bcm283x[of_match->data];
rpi_bcm283x_base = pdat.io_base;
+   rpi_updated_mem_map(pdat.m_map);
break;
}
 
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 0e05d59e1f..248d04bfd2 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -248,51 +248,6 @@ static uint32_t rev_scheme;
 static uint32_t rev_type;
 static const struct rpi_model *model;
 
-#ifdef CONFIG_ARM64
-#ifndef CONFIG_BCM2711
-static struct mm_region bcm283x_mem_map[] = {
-   {
-   .virt = 0xUL,
-   .phys = 0xUL,
-   .size = 0x3f00UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   }, {
-   .virt = 0x3f00UL,
-   .phys = 0x3f00UL,
-   .size = 0x0100UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
-   }, {
-   /* List terminator */
-   0,
-   }
-};
-#else
-static struct mm_region bcm283x_mem_map[] = {
-   {
-   .virt = 0xUL,
-   .phys = 0xUL,
-   .size = 0

Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Aaron Williams]

Hi Wolfgang,

On Tuesday, November 5, 2019 12:37:26 AM PST Wolfgang Denk wrote:
> Dear Aaron,
> 
> In message <1838672.aZrPjDvGh8@flash> you wrote:
> > To be blunt, the current U-Boot EFI driver does not provide the required
> > functionality. It would need to be extended in order to work. In addition,
> > spinlocks would be required in order to handle the case of reentrancy.
> > Also, how does the EFI loader deal with loading multiple applications
> > across multiple cores? The block support is the least important part of
> > it. There are several other services not related to block devices or
> > network calls.
> Maybe you are just trying to squeeze too much of operating system
> functionality into a mere boot loader?
> 
> Using tools for purposes they have not been designed for has never
> been a good idea...
> 
> Best regards,
> 
> Wolfgang Denk

With the complexity of U-Boot, it certainly exceeds a number of operating 
systems I've used :)

U-Boot OS might be fun for people writing applications where they want bare 
metal (i.e. hard real-time), though that's already provided with the API and 
examples.

Our API is very much at arms length. It consists of a descriptor placed into a 
named block of memory that has the physical address of  a single entry point, 
version information and a magic number, similar to EFI. There has to be some 
way to hand the CPU over to U-Boot, after all. That single entry point is 
basically a syscall. It saves the context of the caller and performs a TLB 
context switch and sets up a new stack for U-Boot and the TLB mapping (we run 
U-Boot at 0xC000). There is also a spinlock so that no other core 
may enter U-Boot until the current request finishes. The C code then 
interprets the opcode and copies any data (using physical addresses) into 
buffers used by U-Boot then when done it copies the data back to the 
application's pointers (which are physical addresses). U-Boot code other than 
the API never sees outside pointers and all data is copied to a local buffer. 
It's not fast but it's been very reliable.  The external program doesn't need 
to know anything other than pass some parameters and call the address to hand 
the CPU context over to U-Boot. Neither side knows anything about the other. 
You can't get much more arms length than that except perhaps requiring U-Boot 
to use an interrupt. They are by just about any definition, completely 
separate binaries. I'm no lawyer, but reading the GPL FAQ I think we fall well 
within the arms length separation.

At least on MIPS, U-Boot doesn't seem to care which core it's running on as 
long as only one core is executing at a time. It's proven to be quite 
reliable. It's not meant to be a heavy-duty OS and by design it limits how 
much I/O can be performed. It's only meant to load and save configuration and 
a few other operations. Even functions like getc/putc are not supported (since 
the native application can do that). The main functions used are for changing 
the phy parameters and the MAC quad-lane-module parameters like amplitude and 
equalization which goes along with the phy code.

It also provides some very basic file I/O and block I/O and environment 
variable support like EFI. EFI would be nice to use, but it would require the 
proper lock support and a few other things to work in a multi-core 
environment.

It could be converted over to EFI, though EFI would need to be expanded in 
order to provide the spinlocks and a few other minor changes for the SoC. EFI 
would also need to be expanded to allow for platform-specific calls to be 
supported related to the phy and QLM.

Ideally we won't need this at all with some of the work we're doing on the 
Linux kernel.

Regards,

Aaron


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: fsl-layerscape: fix hwconfig and prefetching

[Priyanka Jain]

>-Original Message-
>From: U-Boot  On Behalf Of Michael Walle
>Sent: Tuesday, October 22, 2019 2:07 AM
>To: u-boot@lists.denx.de
>Cc: Tom Rini 
>Subject: [U-Boot] [PATCH] armv8: fsl-layerscape: fix hwconfig and prefetching
>
>If CONFIG_HWCONFIG is disabled, hwconfig_subarg_f() will return the empty
>string, ie. not NULL. Therefore, we have to check the returned argument
>length as well as the return value.
>
>Signed-off-by: Michael Walle 
>---
> arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>index a5d0b5370f..4bb73b524c 100644
>--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
>@@ -1073,7 +1073,7 @@ static void config_core_prefetch(void)
>   prefetch_arg = hwconfig_subarg_f("core_prefetch", "disable",
>&arglen, buf);
>
>-  if (prefetch_arg) {
>+  if (arglen && prefetch_arg) {
>   mask = simple_strtoul(prefetch_arg, NULL, 0) & 0xff;
>   if (mask & 0x1) {
>   printf("Core0 prefetch can't be disabled\n");
>--
>2.20.1
>
Please check similar patch at http://patchwork.ozlabs.org/patch/1187188/
Does this solve your issue?
--priyankajain
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Wolfgang Denk]

Dear Aaron,

In message <2609392.0ByMiX4J6F@flash> you wrote:
>
> U-Boot OS might be fun for people writing applications where they want bare 
> metal (i.e. hard real-time), though that's already provided with the API and 
> examples.

Urgh... no!!! U-Boot is definitely *not* suitable for any kind of
real-time tasks.  By design it implements strict single-tasking with
usally polling hardware access only.  No multi-tasking, no
interrupts, no locking, no timers, nothing...

> You can't get much more arms length than that except perhaps requiring U-Boot 
> to use an interrupt. They are by just about any definition, completely 
> separate binaries. I'm no lawyer, but reading the GPL FAQ I think we fall 
> well 
> within the arms length separation.

Definitely not.  You could not implement any of this without heavily
relyin on and deriving from internal interfaces of U-Boot which are
not exported for non-GPL use.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/4] regmap: Add devm_regmap_init()

[Jean-Jacques Hiblot]

Most of new linux drivers are using managed-API to allocate resources. To
ease porting drivers from linux to U-Boot, introduce devm_regmap_init() as
a managed API to get a regmap from the device tree.

Signed-off-by: Jean-Jacques Hiblot 
Reviewed-by: Simon Glass 

---

Changes in v2:
- Fix comment for devm_regmap_init()
- Fix spelling in commit log

 drivers/core/regmap.c | 26 ++
 include/regmap.h  | 18 ++
 2 files changed, 44 insertions(+)

diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index e9e55c9d16..f69ff6d12f 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -219,6 +219,32 @@ int regmap_init_mem(ofnode node, struct regmap **mapp)
 
return 0;
 }
+
+static void devm_regmap_release(struct udevice *dev, void *res)
+{
+   regmap_uninit(*(struct regmap **)res);
+}
+
+struct regmap *devm_regmap_init(struct udevice *dev,
+   const struct regmap_bus *bus,
+   void *bus_context,
+   const struct regmap_config *config)
+{
+   int rc;
+   struct regmap **mapp;
+
+   mapp = devres_alloc(devm_regmap_release, sizeof(struct regmap *),
+   __GFP_ZERO);
+   if (unlikely(!mapp))
+   return ERR_PTR(-ENOMEM);
+
+   rc = regmap_init_mem(dev_ofnode(dev), mapp);
+   if (rc)
+   return ERR_PTR(rc);
+
+   devres_add(dev, mapp);
+   return *mapp;
+}
 #endif
 
 void *regmap_get_range(struct regmap *map, unsigned int range_num)
diff --git a/include/regmap.h b/include/regmap.h
index 9ada1af5ef..624cdd8c98 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -73,6 +73,9 @@ struct regmap_range {
ulong size;
 };
 
+struct regmap_bus;
+struct regmap_config;
+
 /**
  * struct regmap - a way of accessing hardware/bus registers
  *
@@ -333,6 +336,21 @@ int regmap_init_mem_platdata(struct udevice *dev, 
fdt_val_t *reg, int count,
 
 int regmap_init_mem_index(ofnode node, struct regmap **mapp, int index);
 
+/**
+ * devm_regmap_init() - Initialise register map (device managed)
+ *
+ * @dev: Device that will be interacted with
+ * @bus: Bus-specific callbacks to use with device (IGNORED)
+ * @bus_context: Data passed to bus-specific callbacks (IGNORED)
+ * @config: Configuration for register map (IGNORED)
+ *
+ * @Return a valid pointer to a struct regmap or a ERR_PTR() on error.
+ * The structure is automatically freed when the device is unbound
+ */
+struct regmap *devm_regmap_init(struct udevice *dev,
+   const struct regmap_bus *bus,
+   void *bus_context,
+   const struct regmap_config *config);
 /**
  * regmap_get_range() - Obtain the base memory address of a regmap range
  *
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 4/4] test: dm: Add tests for regmap managed API and regmap fields

[Jean-Jacques Hiblot]

The tests rely on a dummy driver to allocate and initialize the regmap
and the regmap fields using the managed API.
The first test checks that the read/write callbacks are used.
The second test checks if regmap fields behave properly (mask and shift
are ok) by peeking into the regmap.

Signed-off-by: Jean-Jacques Hiblot 
Reviewed-by: Simon Glass 

---

Changes in v2: None

 arch/sandbox/dts/test.dts |  13 +++
 test/dm/regmap.c  | 189 ++
 2 files changed, 202 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index fdb08f2111..aa9eaec338 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -889,6 +889,19 @@
mdio: mdio-test {
compatible = "sandbox,mdio";
};
+
+   some_regmapped-bus {
+   #address-cells = <0x1>;
+   #size-cells = <0x1>;
+
+   ranges = <0x0 0x0 0x10>;
+   compatible = "simple-bus";
+
+   regmap-test_0 {
+   reg = <0 0x10>;
+   compatible = "sandbox,regmap_test";
+   };
+   };
 };
 
 #include "sandbox_pmic.dtsi"
diff --git a/test/dm/regmap.c b/test/dm/regmap.c
index 6fd1f20656..1a0dc78019 100644
--- a/test/dm/regmap.c
+++ b/test/dm/regmap.c
@@ -184,3 +184,192 @@ static int dm_test_regmap_poll(struct unit_test_state 
*uts)
 }
 
 DM_TEST(dm_test_regmap_poll, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+struct regmaptest_priv {
+   struct regmap *regmap;
+   struct regmap_field **fields;
+};
+
+#define REGMAP_TEST_BUF_SZ 12
+struct regmaptest_context {
+   unsigned short buffer[REGMAP_TEST_BUF_SZ];
+} ctx;
+
+static int regmaptest_write(void *context, unsigned int reg, unsigned int val)
+{
+   struct regmaptest_context *ctx = context;
+
+   if (reg < ARRAY_SIZE(ctx->buffer)) {
+   ctx->buffer[reg] = val;
+   return 0;
+   }
+   return -ERANGE;
+}
+
+static int regmaptest_read(void *context, unsigned int reg, unsigned int *val)
+{
+   struct regmaptest_context *ctx = context;
+
+   if (reg < ARRAY_SIZE(ctx->buffer)) {
+   *val = ctx->buffer[reg];
+   return 0;
+   }
+
+   return -ERANGE;
+}
+
+static struct regmap_config cfg = {
+   .reg_write = regmaptest_write,
+   .reg_read = regmaptest_read,
+};
+
+static const struct reg_field field_cfgs[] = {
+   {
+   .reg = 0,
+   .lsb = 0,
+   .msb = 6,
+   },
+   {
+   .reg = 1,
+   .lsb = 4,
+   .msb = 12,
+   },
+   {
+   .reg = 1,
+   .lsb = 12,
+   .msb = 15,
+   }
+};
+
+static int remaptest_probe(struct udevice *dev)
+{
+   struct regmaptest_priv *priv = dev_get_priv(dev);
+   struct regmap *regmap;
+   struct regmap_field *field;
+   int i;
+   static const int n = ARRAY_SIZE(field_cfgs);
+
+   regmap = devm_regmap_init(dev, NULL, &ctx, &cfg);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+   priv->regmap = regmap;
+
+   priv->fields = devm_kzalloc(dev, sizeof(struct regmap_field *) * n,
+   GFP_KERNEL);
+   if (!priv->fields)
+   return -ENOMEM;
+
+   for (i = 0 ; i < n; i++) {
+   field = devm_regmap_field_alloc(dev, regmap, field_cfgs[i]);
+   if (IS_ERR(field))
+   return PTR_ERR(field);
+   priv->fields[i] = field;
+   }
+   return 0;
+}
+
+static const struct udevice_id regmaptest_ids[] = {
+   { .compatible = "sandbox,regmap_test" },
+   { }
+};
+
+U_BOOT_DRIVER(regmap_test) = {
+   .name   = "regmaptest_drv",
+   .of_match   = regmaptest_ids,
+   .id = UCLASS_NOP,
+   .probe = remaptest_probe,
+   .priv_auto_alloc_size = sizeof(struct regmaptest_priv),
+};
+
+static int dm_test_devm_regmap(struct unit_test_state *uts)
+{
+   int i = 0;
+   u32 val;
+   u16 pattern[REGMAP_TEST_BUF_SZ];
+   struct udevice *dev;
+   struct regmaptest_priv *priv;
+
+   ut_assertok(uclass_get_device_by_name(UCLASS_NOP, "regmap-test_0",
+ &dev));
+
+   priv = dev_get_priv(dev);
+
+   srand(get_ticks() + rand());
+   for (i = REGMAP_TEST_BUF_SZ - 1; i >= 0; i--) {
+   pattern[i] = rand() & 0x;
+   ut_assertok(regmap_write(priv->regmap, i, pattern[i]));
+   }
+   for (i = 0; i < REGMAP_TEST_BUF_SZ; i++) {
+   ut_assertok(regmap_read(priv->regmap, i, &val));
+   ut_asserteq(val, ctx.buffer[i]);
+   ut_asserteq(val, pattern[i]);
+   }
+
+   ut_asserteq(-ERANGE, regmap_write(priv->regmap, REGMAP_TEST_BUF_SZ,
+ val));
+   ut_asserteq(-ERANGE, regmap_read(priv->regmap, REGMAP_TEST_BUF_SZ,
+   

[U-Boot] [PATCH v2 2/4] regmap: Allow providing read/write callbacks through struct regmap_config

[Jean-Jacques Hiblot]

Some linux drivers provide their own read/write functions to access data
from/of the regmap. Adding support for it.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v2:
- Only use custom accessors if {,SPL,TPL}_REGMAP_ACCESSORS is enabled

 drivers/core/Kconfig  | 25 +
 drivers/core/regmap.c | 22 --
 include/regmap.h  | 28 +---
 3 files changed, 70 insertions(+), 5 deletions(-)

diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index 3b95b5387b..3d836a63bf 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -129,6 +129,31 @@ config TPL_REGMAP
  support any bus type (I2C, SPI) but so far this only supports
  direct memory access.
 
+config REGMAP_ACCESSORS
+   bool
+   depends on REGMAP
+   default y
+
+config SPL_REGMAP_ACCESSORS
+   bool "Support custom regmap accessors in SPL"
+   depends on SPL_REGMAP
+   help
+ Allow to use a regmap with custom accessors. The acessors are the
+ low-level functions actually performing the read and write
+ operations.
+ This option can be used to access registers that are not
+ memory-mapped.
+
+config TPL_REGMAP_ACCESSORS
+   bool "Support custom regmap accessors in TPL"
+   depends on TPL_REGMAP
+   help
+ Allow to use a regmap with custom accessors. The acessors are the
+ low-level functions actually performing the read and write
+ operations.
+ This option can be used to access registers that are not
+ memory-mapped.
+
 config SYSCON
bool "Support system controllers"
depends on REGMAP
diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index f69ff6d12f..10ae9f918a 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -31,7 +31,11 @@ static struct regmap *regmap_alloc(int count)
if (!map)
return NULL;
map->range_count = count;
-
+#if CONFIG_IS_ENABLED(REGMAP_ACCESSORS)
+   map->bus_context = NULL;
+   map->reg_read = NULL;
+   map->reg_write = NULL;
+#endif
return map;
 }
 
@@ -241,7 +245,11 @@ struct regmap *devm_regmap_init(struct udevice *dev,
rc = regmap_init_mem(dev_ofnode(dev), mapp);
if (rc)
return ERR_PTR(rc);
-
+#if CONFIG_IS_ENABLED(REGMAP_ACCESSORS)
+   (*mapp)->reg_read = config->reg_read;
+   (*mapp)->reg_write = config->reg_write;
+   (*mapp)->bus_context = bus_context;
+#endif
devres_add(dev, mapp);
return *mapp;
 }
@@ -320,6 +328,11 @@ int regmap_raw_read_range(struct regmap *map, uint 
range_num, uint offset,
struct regmap_range *range;
void *ptr;
 
+#if CONFIG_IS_ENABLED(REGMAP_ACCESSORS)
+   if (map->reg_read)
+   return map->reg_read(map->bus_context, offset, valp);
+#endif
+
if (range_num >= map->range_count) {
debug("%s: range index %d larger than range count\n",
  __func__, range_num);
@@ -429,6 +442,11 @@ int regmap_raw_write_range(struct regmap *map, uint 
range_num, uint offset,
struct regmap_range *range;
void *ptr;
 
+#if CONFIG_IS_ENABLED(REGMAP_ACCESSORS)
+   if (map->reg_write)
+   return map->reg_write(map->bus_context, offset,
+ *(unsigned int *)val);
+#endif
if (range_num >= map->range_count) {
debug("%s: range index %d larger than range count\n",
  __func__, range_num);
diff --git a/include/regmap.h b/include/regmap.h
index 624cdd8c98..730e747d90 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -74,16 +74,38 @@ struct regmap_range {
 };
 
 struct regmap_bus;
-struct regmap_config;
+/**
+ * struct regmap_config - a way of accessing hardware/bus registers
+ *
+ * @reg_read:Optional callback that if filled will be used to perform
+ *   all the reads from the registers. Should only be provided for
+ *   devices whose read operation cannot be represented as a simple
+ *   read operation on a bus such as SPI, I2C, etc. Most of the
+ *   devices do not need this.
+ * @reg_write:   Same as above for writing.
+ */
+struct regmap_config {
+   int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
+   int (*reg_write)(void *context, unsigned int reg, unsigned int val);
+};
 
 /**
  * struct regmap - a way of accessing hardware/bus registers
  *
  * @range_count:   Number of ranges available within the map
  * @ranges:Array of ranges
+ * @bus_context:   Data passed to bus-specific callbacks
+ * @reg_read:  Optional callback that if filled will be used to perform
+ * all the reads from the registers.
+ * @reg_write: Same as above for writing.
  */
 struct regmap {
enum regmap_endianness_t endianness;
+#if CONFIG_IS_ENABLED(REGMAP_ACCESSORS)
+   voi

[U-Boot] [PATCH v2 0/4] regmap: Add a managed API, custom read/write callbacks and support for regmap fields

[Jean-Jacques Hiblot]

This is the first of a few series, the goal of which is to facilitate
porting drivers from the linux kernel. Most of the series will be about
adding managed API to existing infrastructure (GPIO, reset, phy,...)

This particular series is about regmaps. It adds the managed API, using
the same API as linux. It also adds support for regmap fields and for
custom read/write callbacks.

Changes in v2:
- Fix comment for devm_regmap_init()
- Fix spelling in commit log
- Only use custom accessors if {,SPL,TPL}_REGMAP_ACCESSORS is enabled

Jean-Jacques Hiblot (4):
  regmap: Add devm_regmap_init()
  regmap: Allow providing read/write callbacks through struct
regmap_config
  regmap: Add support for regmap fields
  test: dm: Add tests for regmap managed API and regmap fields

 arch/sandbox/dts/test.dts |  13 +++
 drivers/core/Kconfig  |  25 +
 drivers/core/regmap.c | 123 -
 include/regmap.h  | 148 +
 test/dm/regmap.c  | 189 ++
 5 files changed, 497 insertions(+), 1 deletion(-)

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 3/4] regmap: Add support for regmap fields

[Jean-Jacques Hiblot]

A regmap field is an abstraction available in Linux. It provides to access
bitfields in a regmap without having to worry about shifts and masks.

Signed-off-by: Jean-Jacques Hiblot 
Reviewed-by: Simon Glass 
---

Changes in v2: None

 drivers/core/regmap.c |  77 ++
 include/regmap.h  | 108 ++
 2 files changed, 185 insertions(+)

diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 10ae9f918a..905bc0b63d 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -15,6 +15,14 @@
 #include 
 #include 
 
+struct regmap_field {
+   struct regmap *regmap;
+   unsigned int mask;
+   /* lsb */
+   unsigned int shift;
+   unsigned int reg;
+};
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /**
@@ -508,3 +516,72 @@ int regmap_update_bits(struct regmap *map, uint offset, 
uint mask, uint val)
 
return regmap_write(map, offset, reg | (val & mask));
 }
+
+int regmap_field_read(struct regmap_field *field, unsigned int *val)
+{
+   int ret;
+   unsigned int reg_val;
+
+   ret = regmap_read(field->regmap, field->reg, ®_val);
+   if (ret != 0)
+   return ret;
+
+   reg_val &= field->mask;
+   reg_val >>= field->shift;
+   *val = reg_val;
+
+   return ret;
+}
+
+int regmap_field_write(struct regmap_field *field, unsigned int val)
+{
+   return regmap_update_bits(field->regmap, field->reg, field->mask,
+ val << field->shift);
+}
+
+static void regmap_field_init(struct regmap_field *rm_field,
+ struct regmap *regmap,
+ struct reg_field reg_field)
+{
+   rm_field->regmap = regmap;
+   rm_field->reg = reg_field.reg;
+   rm_field->shift = reg_field.lsb;
+   rm_field->mask = GENMASK(reg_field.msb, reg_field.lsb);
+}
+
+struct regmap_field *devm_regmap_field_alloc(struct udevice *dev,
+struct regmap *regmap,
+struct reg_field reg_field)
+{
+   struct regmap_field *rm_field = devm_kzalloc(dev, sizeof(*rm_field),
+GFP_KERNEL);
+   if (!rm_field)
+   return ERR_PTR(-ENOMEM);
+
+   regmap_field_init(rm_field, regmap, reg_field);
+
+   return rm_field;
+}
+
+void devm_regmap_field_free(struct udevice *dev, struct regmap_field *field)
+{
+   devm_kfree(dev, field);
+}
+
+struct regmap_field *regmap_field_alloc(struct regmap *regmap,
+   struct reg_field reg_field)
+{
+   struct regmap_field *rm_field = kzalloc(sizeof(*rm_field), GFP_KERNEL);
+
+   if (!rm_field)
+   return ERR_PTR(-ENOMEM);
+
+   regmap_field_init(rm_field, regmap, reg_field);
+
+   return rm_field;
+}
+
+void regmap_field_free(struct regmap_field *field)
+{
+   kfree(field);
+}
diff --git a/include/regmap.h b/include/regmap.h
index 730e747d90..8619566a95 100644
--- a/include/regmap.h
+++ b/include/regmap.h
@@ -314,6 +314,43 @@ int regmap_raw_read_range(struct regmap *map, uint 
range_num, uint offset,
regmap_read_poll_timeout_test(map, addr, val, cond, sleep_us, \
  timeout_ms, 0) \
 
+/**
+ * regmap_field_read_poll_timeout - Poll until a condition is met or a timeout
+ * occurs
+ *
+ * @field: Regmap field to read from
+ * @val:   Unsigned integer variable to read the value into
+ * @cond:  Break condition (usually involving @val)
+ * @sleep_us:  Maximum time to sleep between reads in us (0 tight-loops).
+ * @timeout_ms:Timeout in ms, 0 means never timeout
+ *
+ * Returns 0 on success and -ETIMEDOUT upon a timeout or the regmap_field_read
+ * error return value in case of a error read. In the two former cases,
+ * the last read value at @addr is stored in @val.
+ *
+ * This is modelled after the regmap_read_poll_timeout macros in linux but
+ * with millisecond timeout.
+ */
+#define regmap_field_read_poll_timeout(field, val, cond, sleep_us, timeout_ms) 
\
+({ \
+   unsigned long __start = get_timer(0); \
+   int __ret; \
+   for (;;) { \
+   __ret = regmap_field_read((field), &(val)); \
+   if (__ret) \
+   break; \
+   if (cond) \
+   break; \
+   if ((timeout_ms) && get_timer(__start) > (timeout_ms)) { \
+   __ret = regmap_field_read((field), &(val)); \
+   break; \
+   } \
+   if ((sleep_us)) \
+   udelay((sleep_us)); \
+   } \
+   __ret ?: ((cond) ? 0 : -ETIMEDOUT); \
+})
+
 /**
  * regmap_update_bits() - Perform a read/modify/write using a mask
  *
@@ -390,4 +427,75 @@ void *regmap_get_range(struct regmap *map, unsigned int 
range_num);
  */
 int regmap_uninit(struct regmap *map);
 
+/**
+ * str

[U-Boot] [PATCH v2 3/4] drivers: mux: mmio-based syscon mux controller

[Jean-Jacques Hiblot]

This adds a driver for mmio-based syscon multiplexers controlled by
bitfields in a syscon register range.
This is heavily based on the linux mmio-mux driver.

Signed-off-by: Jean-Jacques Hiblot 
---

Changes in v2: None

 drivers/mux/Kconfig  |  15 +
 drivers/mux/Makefile |   1 +
 drivers/mux/mmio.c   | 155 +++
 3 files changed, 171 insertions(+)
 create mode 100644 drivers/mux/mmio.c

diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index ad0199c058..bda6a2d9f5 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -4,4 +4,19 @@ config MULTIPLEXER
bool "Multiplexer Support"
depends on DM
 
+
+if MULTIPLEXER
+
+config MUX_MMIO
+   bool "MMIO register bitfield-controlled Multiplexer"
+   depends on MULTIPLEXER && SYSCON
+   help
+ MMIO register bitfield-controlled Multiplexer controller.
+
+ The driver builds multiplexer controllers for bitfields in a syscon
+ register. For N bit wide bitfields, there will be 2^N possible
+ multiplexer states.
+
+endif
+
 endmenu
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index 351e4363d3..78ebf04c7a 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -4,3 +4,4 @@
 # Jean-Jacques Hiblot 
 
 obj-$(CONFIG_$(SPL_)MULTIPLEXER) += mux-uclass.o
+obj-$(CONFIG_$(SPL_)MUX_MMIO) += mmio.o
diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c
new file mode 100644
index 00..a9faaeb9fd
--- /dev/null
+++ b/drivers/mux/mmio.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MMIO register bitfield-controlled multiplexer driver
+ * Based on the linux mmio multiplexer driver
+ *
+ * Copyright (C) 2017 Pengutronix, Philipp Zabel 
+ * Copyright (C) 2019 Texas Instrument, Jean-jacques Hiblot 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int mux_mmio_set(struct mux_control *mux, int state)
+{
+   struct regmap_field **fields = dev_get_priv(mux->dev);
+
+   return regmap_field_write(fields[mux_control_get_index(mux)], state);
+}
+
+static const struct mux_control_ops mux_mmio_ops = {
+   .set = mux_mmio_set,
+};
+
+static const struct udevice_id mmio_mux_of_match[] = {
+   { .compatible = "mmio-mux" },
+   { /* sentinel */ },
+};
+
+static int mmio_mux_probe(struct udevice *dev)
+{
+   struct regmap_field **fields;
+   struct mux_chip *mux_chip = dev_get_uclass_priv(dev);
+   struct regmap *regmap;
+   u32 *mux_reg_masks;
+   u32 *idle_states;
+   int num_fields;
+   int ret;
+   int i;
+
+   regmap = syscon_node_to_regmap(dev_ofnode(dev->parent));
+   if (IS_ERR(regmap)) {
+   ret = PTR_ERR(regmap);
+   dev_err(dev, "failed to get regmap: %d\n", ret);
+   return ret;
+   }
+
+   num_fields = dev_read_size(dev, "mux-reg-masks");
+   if (num_fields < 0) {
+   dev_err(dev, "mux-reg-masks property missing or invalid: %d\n",
+   num_fields);
+   return num_fields;
+   }
+   num_fields /= sizeof(u32);
+   if (num_fields == 0 || num_fields % 2)
+   ret = -EINVAL;
+   num_fields = num_fields / 2;
+
+   ret = mux_alloc_controllers(dev, num_fields);
+   if (ret < 0) {
+   dev_err(dev, "failed to allocate mux controllers: %d\n",
+   ret);
+   return ret;
+   }
+
+   fields = devm_kmalloc(dev, num_fields * sizeof(*fields), __GFP_ZERO);
+   if (!fields)
+   return -ENOMEM;
+   dev->priv = fields;
+
+   mux_reg_masks = devm_kmalloc(dev, num_fields * 2 * sizeof(u32),
+__GFP_ZERO);
+   if (!mux_reg_masks)
+   return -ENOMEM;
+
+   ret = dev_read_u32_array(dev, "mux-reg-masks", mux_reg_masks,
+num_fields * 2);
+   if (ret < 0) {
+   dev_err(dev, "failed to read mux-reg-masks property: %d\n",
+   ret);
+   return ret;
+   }
+
+   idle_states = devm_kmalloc(dev, num_fields * sizeof(u32), __GFP_ZERO);
+   if (!idle_states)
+   return -ENOMEM;
+
+   ret = dev_read_u32_array(dev, "idle-states", idle_states, num_fields);
+   if (ret < 0) {
+   dev_err(dev, "failed to read idle-states property: %d\n",
+   ret);
+   devm_kfree(dev, idle_states);
+   idle_states = NULL;
+   }
+
+   for (i = 0; i < num_fields; i++) {
+   struct mux_control *mux = &mux_chip->mux[i];
+   struct reg_field field;
+   u32 reg, mask;
+   int bits;
+
+   reg = mux_reg_masks[2 * i];
+   mask = mux_reg_masks[2 * i + 1];
+
+   field.reg = reg;
+   field.msb = fls(mask) - 1;
+   field.lsb = ffs(mask) - 1;
+
+   if (mask != GENM

[U-Boot] [PATCH v2 1/1] net: avoid address-of-packed-member error

[Heinrich Schuchardt]

sandbox_defconfig does not compile using GCC 9.2.1:

net/net.c: In function ‘net_process_received_packet’:
net/net.c:1288:23: error: taking address of packed member of ‘struct
ip_udp_hdr’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
 1288 |sumptr = (ushort *)&(ip->udp_src);
  |   ^~

Avoid the error by using a u8 pointer instead of an u16 pointer and
in-lining ntohs().

Simplify the checksumming of the last message byte.

Signed-off-by: Heinrich Schuchardt 
---
v2:
reword commit message
add a comment
simplify checksumming of last byte
---
 net/net.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/net/net.c b/net/net.c
index ded86e7456..bcb9d5f07e 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1274,7 +1274,7 @@ void net_process_received_packet(uchar *in_packet, int 
len)
 #ifdef CONFIG_UDP_CHECKSUM
if (ip->udp_xsum != 0) {
ulong   xsum;
-   ushort *sumptr;
+   u8 *sumptr;
ushort  sumlen;

xsum  = ip->ip_p;
@@ -1285,22 +1285,16 @@ void net_process_received_packet(uchar *in_packet, int 
len)
xsum += (ntohl(ip->ip_dst.s_addr) >>  0) & 0x;

sumlen = ntohs(ip->udp_len);
-   sumptr = (ushort *)&(ip->udp_src);
+   sumptr = (u8 *)&ip->udp_src;

while (sumlen > 1) {
-   ushort sumdata;
-
-   sumdata = *sumptr++;
-   xsum += ntohs(sumdata);
+   /* inlined ntohs() to avoid alignment errors */
+   xsum += (sumptr[0] << 8) + sumptr[1];
+   sumptr += 2;
sumlen -= 2;
}
-   if (sumlen > 0) {
-   ushort sumdata;
-
-   sumdata = *(unsigned char *)sumptr;
-   sumdata = (sumdata << 8) & 0xff00;
-   xsum += sumdata;
-   }
+   if (sumlen > 0)
+   xsum += (sumptr[0] << 8) + sumptr[0];
while ((xsum >> 16) != 0) {
xsum = (xsum & 0x) +
   ((xsum >> 16) & 0x);
--
2.24.0.rc1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 4/4] test: Add tests for the multiplexer framework

[Jean-Jacques Hiblot]

Provide tests to check the behavior of the multiplexer framework.
The test uses a mmio-based multiplexer.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v2:
- Call sandbox_set_enable_memio(true) before running the test

 arch/sandbox/dts/test.dts |  26 +++
 configs/sandbox_defconfig |   2 +
 test/dm/Makefile  |   1 +
 test/dm/mux-mmio.c| 147 ++
 4 files changed, 176 insertions(+)
 create mode 100644 test/dm/mux-mmio.c

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index aa9eaec338..3224a8389c 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1,3 +1,5 @@
+#include 
+
 /dts-v1/;
 
 / {
@@ -93,6 +95,11 @@
<&gpio_b 9 0xc 3 2 1>;
int-value = <1234>;
uint-value = <(-1234)>;
+
+   mux-controls = <&muxcontroller0 0>, <&muxcontroller0 1>,
+  <&muxcontroller0 2>, <&muxcontroller0 3>;
+   mux-control-names = "mux0", "mux1", "mux2", "mux3";
+   mux-syscon = <&syscon3>;
};
 
junk {
@@ -129,6 +136,9 @@
compatible = "denx,u-boot-fdt-test";
ping-expect = <3>;
ping-add = <3>;
+
+   mux-controls = <&muxcontroller0 0>;
+   mux-control-names = "mux0";
};
 
phy_provider0: gen_phy@0 {
@@ -665,6 +675,22 @@
0x58 8>;
};
 
+   syscon3: syscon@3 {
+   compatible = "simple-mfd", "syscon";
+   reg = <0x000100 0x10>;
+
+   muxcontroller0: a-mux-controller {
+   compatible = "mmio-mux";
+   #mux-control-cells = <1>;
+
+   mux-reg-masks = <0x0 0x30>, /* 0: reg 0x0, bits 5:4 */
+   <0x3 0x1E>, /* 1: reg 0x3, bits 4:1 */
+   <0x1 0xFF>; /* 2: reg 0x1, bits 7:0 */
+   idle-states = , <0x02>, <0x73>;
+   u-boot,mux-autoprobe;
+   };
+   };
+
timer {
compatible = "sandbox,timer";
clock-frequency = <100>;
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 20ebc68997..2822dd9c74 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -144,6 +144,8 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_MULTIPLEXER=y
+CONFIG_MUX_MMIO=y
 CONFIG_DM_ETH=y
 CONFIG_NVME=y
 CONFIG_PCI=y
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 0c2fd5cb5e..a3fc23e527 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_DM_SPI_FLASH) += sf.o
 obj-$(CONFIG_SMEM) += smem.o
 obj-$(CONFIG_DM_SPI) += spi.o
 obj-y += syscon.o
+obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
 obj-$(CONFIG_DM_USB) += usb.o
 obj-$(CONFIG_DM_PMIC) += pmic.o
 obj-$(CONFIG_DM_REGULATOR) += regulator.o
diff --git a/test/dm/mux-mmio.c b/test/dm/mux-mmio.c
new file mode 100644
index 00..a3dfd34120
--- /dev/null
+++ b/test/dm/mux-mmio.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Jean-Jacques Hiblot 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Test that mmio mux work correctly */
+static int dm_test_mux_mmio(struct unit_test_state *uts)
+{
+   struct udevice *dev, *dev_b;
+   struct regmap *map;
+   struct mux_control *ctl0_a, *ctl0_b;
+   struct mux_control *ctl1;
+   struct mux_control *ctl_err;
+   u32 val;
+   int i;
+
+   sandbox_set_enable_memio(true);
+
+   ut_assertok(uclass_get_device(UCLASS_TEST_FDT, 0, &dev));
+   ut_assertok(uclass_get_device(UCLASS_TEST_FDT, 1, &dev_b));
+   ut_asserteq_str("a-test", dev->name);
+   ut_asserteq_str("b-test", dev_b->name);
+   map = syscon_regmap_lookup_by_phandle(dev, "mux-syscon");
+   ut_assert(!IS_ERR(map));
+   ut_assert(map);
+
+   /* check default states */
+   ut_assertok(regmap_read(map, 3, &val));
+   ut_asserteq(0x02, (val & 0x1E) >> 1);
+   ut_assertok(regmap_read(map, 1, &val));
+   ut_asserteq(0x73, (val & 0xFF) >> 0);
+
+   ut_assertok(mux_control_get(dev, "mux0", &ctl0_a));
+   ut_assertok(mux_control_get(dev, "mux1", &ctl1));
+   ut_asserteq(-ERANGE, mux_control_get(dev, "mux3", &ctl_err));
+   ut_asserteq(-ENODATA, mux_control_get(dev, "dummy", &ctl_err));
+   ut_assertok(mux_control_get(dev_b, "mux0", &ctl0_b));
+
+   for (i = 0; i < mux_control_states(ctl0_a); i++) {
+   /* select a new state and verify the value in the regmap */
+   ut_assertok(mux_control_select(ctl0_a, i));
+   ut_assertok(regmap_read(map, 0, &val));
+   ut_asserteq

[U-Boot] [PATCH v2 2/4] dm: board: complete the initialization of the muxes in initr_dm()

[Jean-Jacques Hiblot]

This will probe the multiplexer devices that have a "u-boot,mux-autoprobe"
property. As a consequence they will be put in their idle state.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v2:
- insert the mux initialization in init_sequence_r[], just before the
console is initialized as its serial port may be muxed
- moved the definition of dm_mux_init() in this commit

 common/board_r.c | 16 
 drivers/mux/mux-uclass.c | 22 ++
 include/mux.h|  2 ++
 3 files changed, 40 insertions(+)

diff --git a/common/board_r.c b/common/board_r.c
index c1ecb06b74..3d410f3504 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -32,6 +32,7 @@
 #include 
 #endif
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -178,6 +179,18 @@ static int initr_serial(void)
return 0;
 }
 
+#if CONFIG_MULTIPLEXER
+static int initr_mux(void)
+{
+   /*
+* Initialize the multiplexer controls to their default state.
+* This must be done early as other drivers may unknowingly rely on it.
+*/
+   dm_mux_init();
+   return 0;
+}
+#endif
+
 #if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_MIPS)
 static int initr_trap(void)
 {
@@ -691,6 +704,9 @@ static init_fnc_t init_sequence_r[] = {
 #endif
 #ifdef CONFIG_EFI_LOADER
efi_memory_init,
+#endif
+#if CONFIG_MULTIPLEXER
+   initr_mux,
 #endif
stdio_init_tables,
initr_serial,
diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
index 6aaf4dc964..71392e9e50 100644
--- a/drivers/mux/mux-uclass.c
+++ b/drivers/mux/mux-uclass.c
@@ -262,6 +262,28 @@ int mux_uclass_post_probe(struct udevice *dev)
return 0;
 }
 
+void dm_mux_init(void)
+{
+   struct uclass *uc;
+   struct udevice *dev;
+   int ret;
+
+   ret = uclass_get(UCLASS_MUX, &uc);
+   if (ret < 0) {
+   debug("unable to get MUX uclass\n");
+   return;
+   }
+   uclass_foreach_dev(dev, uc) {
+   if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
+   ret = device_probe(dev);
+   if (ret)
+   debug("unable to probe device %s\n", dev->name);
+   } else {
+   printf("not found for dev %s\n", dev->name);
+   }
+   }
+}
+
 UCLASS_DRIVER(mux) = {
.id = UCLASS_MUX,
.name   = "mux",
diff --git a/include/mux.h b/include/mux.h
index 060f71a47c..2467723951 100644
--- a/include/mux.h
+++ b/include/mux.h
@@ -75,6 +75,8 @@ void mux_control_put(struct mux_control *mux);
 
 struct mux_control *devm_mux_control_get(struct udevice *dev,
 const char *mux_name);
+void dm_mux_init(void);
+
 #else
 unsigned int mux_control_states(struct mux_control *mux)
 {
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/4] drivers: Add a new framework for multiplexer devices

[Jean-Jacques Hiblot]

Add a new subsystem that handles multiplexer controllers. The API is the
same as in Linux.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v2:
- Fixed warning in mux_of_xlate_default()
- Improved documentation
- Fixed SPL build

 drivers/Kconfig   |   2 +
 drivers/Makefile  |   1 +
 drivers/mux/Kconfig   |   7 +
 drivers/mux/Makefile  |   6 +
 drivers/mux/mux-uclass.c  | 270 ++
 include/dm/uclass-id.h|   1 +
 include/dt-bindings/mux/mux.h |  17 +++
 include/mux-internal.h| 103 +
 include/mux.h | 113 ++
 9 files changed, 520 insertions(+)
 create mode 100644 drivers/mux/Kconfig
 create mode 100644 drivers/mux/Makefile
 create mode 100644 drivers/mux/mux-uclass.c
 create mode 100644 include/dt-bindings/mux/mux.h
 create mode 100644 include/mux-internal.h
 create mode 100644 include/mux.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9d99ce0226..450aa76e82 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -60,6 +60,8 @@ source "drivers/mmc/Kconfig"
 
 source "drivers/mtd/Kconfig"
 
+source "drivers/mux/Kconfig"
+
 source "drivers/net/Kconfig"
 
 source "drivers/nvme/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 0befeddfcb..9d64742580 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_TPL_)INPUT) += input/
 obj-$(CONFIG_$(SPL_TPL_)LED) += led/
 obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += mmc/
 obj-$(CONFIG_$(SPL_TPL_)NAND_SUPPORT) += mtd/nand/raw/
+obj-$(CONFIG_$(SPL_)MULTIPLEXER) += mux/
 obj-$(CONFIG_$(SPL_TPL_)PCH_SUPPORT) += pch/
 obj-$(CONFIG_$(SPL_TPL_)PCI) += pci/
 obj-$(CONFIG_$(SPL_TPL_)PHY) += phy/
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
new file mode 100644
index 00..ad0199c058
--- /dev/null
+++ b/drivers/mux/Kconfig
@@ -0,0 +1,7 @@
+menu "Multiplexer drivers"
+
+config MULTIPLEXER
+   bool "Multiplexer Support"
+   depends on DM
+
+endmenu
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
new file mode 100644
index 00..351e4363d3
--- /dev/null
+++ b/drivers/mux/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2019
+# Jean-Jacques Hiblot 
+
+obj-$(CONFIG_$(SPL_)MULTIPLEXER) += mux-uclass.o
diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
new file mode 100644
index 00..6aaf4dc964
--- /dev/null
+++ b/drivers/mux/mux-uclass.c
@@ -0,0 +1,270 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Multiplexer subsystem
+ *
+ * Based on the linux multiplexer framework
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ * Author: Peter Rosin 
+ *
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Jean-Jacques Hiblot 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The idle-as-is "state" is not an actual state that may be selected, it
+ * only implies that the state should not be changed. So, use that state
+ * as indication that the cached state of the multiplexer is unknown.
+ */
+#define MUX_CACHE_UNKNOWN MUX_IDLE_AS_IS
+
+static inline const struct mux_control_ops *mux_dev_ops(struct udevice *dev)
+{
+   return (const struct mux_control_ops *)dev->driver->ops;
+}
+
+static int mux_control_set(struct mux_control *mux, int state)
+{
+   int ret = mux_dev_ops(mux->dev)->set(mux, state);
+
+   mux->cached_state = ret < 0 ? MUX_CACHE_UNKNOWN : state;
+
+   return ret;
+}
+
+unsigned int mux_control_states(struct mux_control *mux)
+{
+   return mux->states;
+}
+
+static int __mux_control_select(struct mux_control *mux, int state)
+{
+   int ret;
+
+   if (WARN_ON(state < 0 || state >= mux->states))
+   return -EINVAL;
+
+   if (mux->cached_state == state)
+   return 0;
+
+   ret = mux_control_set(mux, state);
+   if (ret >= 0)
+   return 0;
+
+   /* The mux update failed, try to revert if appropriate... */
+   if (mux->idle_state != MUX_IDLE_AS_IS)
+   mux_control_set(mux, mux->idle_state);
+
+   return ret;
+}
+
+int mux_control_select(struct mux_control *mux, unsigned int state)
+{
+   int ret;
+
+   if (mux->in_use)
+   return -EBUSY;
+
+   ret = __mux_control_select(mux, state);
+
+   if (ret < 0)
+   return ret;
+
+   mux->in_use = true;
+
+   return 0;
+}
+
+int mux_control_deselect(struct mux_control *mux)
+{
+   int ret = 0;
+
+   if (mux->idle_state != MUX_IDLE_AS_IS &&
+   mux->idle_state != mux->cached_state)
+   ret = mux_control_set(mux, mux->idle_state);
+
+   mux->in_use = false;
+
+   return ret;
+}
+
+static int mux_of_xlate_default(struct mux_chip *mux_chip,
+   struct ofnode_phandle_args *args,
+   struct mux_control **muxp)
+{
+   struct mux_control *mux;
+   int id;
+
+   debug("%s(muxp=%p)\n

[U-Boot] [PATCH v2 0/4] drivers: Add a framework for MUX drivers

[Jean-Jacques Hiblot]

Add a new minimalistic subsystem that handles multiplexer controllers.
It provides the same API as Linux and mux drivers should be portable with
a minimum effort.
This series also includes a port of the Linux's mmio-mux driver.

This series relies on a series that extend the regmap [1].

[1] : https://patchwork.ozlabs.org/project/uboot/list/?series=140752

Changes in v2:
- Fixed warning in mux_of_xlate_default()
- Improved documentation
- Fixed SPL build
- insert the mux initialization in init_sequence_r[], just before the
console is initialized as its serial port may be muxed
- moved the definition of dm_mux_init() in this commit
- Call sandbox_set_enable_memio(true) before running the test

Jean-Jacques Hiblot (4):
  drivers: Add a new framework for multiplexer devices
  dm: board: complete the initialization of the muxes in initr_dm()
  drivers: mux: mmio-based syscon mux controller
  test: Add tests for the multiplexer framework

 arch/sandbox/dts/test.dts |  26 +++
 common/board_r.c  |  16 ++
 configs/sandbox_defconfig |   2 +
 drivers/Kconfig   |   2 +
 drivers/Makefile  |   1 +
 drivers/mux/Kconfig   |  22 +++
 drivers/mux/Makefile  |   7 +
 drivers/mux/mmio.c| 155 ++
 drivers/mux/mux-uclass.c  | 292 ++
 include/dm/uclass-id.h|   1 +
 include/dt-bindings/mux/mux.h |  17 ++
 include/mux-internal.h| 103 
 include/mux.h | 115 +
 test/dm/Makefile  |   1 +
 test/dm/mux-mmio.c| 147 +
 15 files changed, 907 insertions(+)
 create mode 100644 drivers/mux/Kconfig
 create mode 100644 drivers/mux/Makefile
 create mode 100644 drivers/mux/mmio.c
 create mode 100644 drivers/mux/mux-uclass.c
 create mode 100644 include/dt-bindings/mux/mux.h
 create mode 100644 include/mux-internal.h
 create mode 100644 include/mux.h
 create mode 100644 test/dm/mux-mmio.c

-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 15/17] dtoc: Convert fdt.py to Python 3

[sjg]

Drop the now-unused Python 2 code to keep code coverage at 100%.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/fdt.py | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 14/17] binman: Convert a few tests to Python 3

[sjg]

Some tests have crept in with Python 2 strings and constructs. Convert
then.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/binman/ftest.py | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 16/17] binman: Move to use Python 3

[sjg]

On Thu, Oct 31, 2019 at 10:12:04AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 31 Oct 2019 at 09:50, Tom Rini  wrote:
> >
> > On Thu, Oct 31, 2019 at 09:19:50AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 31 Oct 2019 at 07:55, Tom Rini  wrote:
> > > >
> > > > On Thu, Oct 31, 2019 at 07:43:05AM -0600, Simon Glass wrote:
> > > >
> > > > > Update this tool to use Python 3 to meet the 2020 deadline.
> > > > >
> > > > > Unfortunately this introduces a test failure due to a problem in 
> > > > > pylibfdt
> > > > > on Python 3. I will investigate.
> > > > >
> > > > > Signed-off-by: Simon Glass 
> > > > > ---
> > > > >
> > > > > Changes in v2:
> > > > > - Add a few more patches to correct remaining problems
> > > >
> > > > Is there still a failure or did you fix it?  If there still is, what
> > > > board(s) make use of that feature?  Thanks!
> > > >
> > >
> > > Everything works fine now, so far as I can tell. The pylibfdt fix was
> > > accepted upstream, too.
> >
> > OK, so a v3 to fix the commit message :)  Do you want to pull all of
> > this together in the end and give me a PR or do you want me to (and kick
> > Azure/Travis/GitLab as needed) ?
>
> Ooops, OK, will do.
>
> I am happy to do either.  I got a successful run. The latest one is
> going here, but only has commit-message changes:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1181

OK.  Can you please put together a fdt PR with those changes and then
I'll grab all of the rest of the Python stuff and make sure all the CIs
pass?  Thanks again!

-- 
Tom

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] fdt: Add INT32_MAX to kernel.h for libfdt

[sjg]

On Sun, Oct 27, 2019 at 09:47:39AM -0600, Simon Glass wrote:

> Unfortunately libfdt needs this value now, which is present in the
> stdint.h header. That file is just a placeholder in U-Boot and these sorts
> of constants appear in the linux/kernel.h header instead.
>
> To keep libfdt happy, add INT32_MAX too.
>
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 04/17] buildman: Convert to Python 3

[sjg]

Convert buildman to Python 3 and make it use that, to meet the 2020
deadline.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Use integer division for multiprocessing.cpu_count()
- Use integer division in SetupBuild() and GetActionSummary()
- Use HTTPMessage.getheader() instead of HTTPMessage.get()
- Use integer division in toolchain.Download()
- Use explicit utf-8 encoding in Boards.ReadBoards()

 tools/buildman/board.py |  9 +--
 tools/buildman/bsettings.py | 20 +++
 tools/buildman/builder.py   | 47 
 tools/buildman/builderthread.py | 24 
 tools/buildman/buildman.py  | 10 ++--
 tools/buildman/control.py   | 44 +++
 tools/buildman/func_test.py | 16 +++---
 tools/buildman/test.py  | 22 
 tools/buildman/toolchain.py | 99 +
 9 files changed, 146 insertions(+), 145 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/17] patman: Adjust 'command' to return strings instead of bytes

[sjg]

At present all the 'command' methods return bytes. Most of the time we
actually want strings, so change this. We still need to keep the internal
representation as bytes since otherwise unicode strings might break over
a read() boundary (e.g. 4KB), causing errors. But we can convert the end
result to strings.

Add a 'binary' parameter to cover the few cases where bytes are needed.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/binman/cbfs_util_test.py |  2 +-
 tools/binman/ftest.py  |  2 +-
 tools/patman/command.py| 31 +++
 tools/patman/tools.py  | 29 +
 4 files changed, 46 insertions(+), 18 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] fdt: Add Kconfig options to control code size

[sjg]

On Sun, Oct 27, 2019 at 09:47:40AM -0600, Simon Glass wrote:

> For better or worse libfdt recent grew a lot of code that checks the
> validity of the device tree in great detail. When using unsigned or
> unverified data this makes things safer, but it does add to code size.
>
> Add some controls to select the trade-off between safety and code size.
>
> Signed-off-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 12/17] pylibfdt: Correct the type for fdt_property_stub()

[sjg]

This function should use a void * type, not char *. This causes an error:

TypeError: in method 'fdt_property_stub', argument 3 of type 'char const *'

Fix it.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 scripts/dtc/pylibfdt/libfdt.i_shipped | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 02/17] patman: Use unicode for file I/O

[sjg]

At present patman test fail in some environments which don't use utf-8
as the default file encoding. Add this explicitly.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add new patch to explicitly use unicode for file I/O in patman

 tools/patman/func_test.py   | 8 
 tools/patman/patchstream.py | 4 ++--
 tools/patman/series.py  | 2 +-
 tools/patman/settings.py| 4 ++--
 tools/patman/test.py| 4 ++--
 5 files changed, 11 insertions(+), 11 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 05/17] test_fdt: Move to use Python 3

[sjg]

Update this test to use Python 3 to meet the 2020 deadline.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/test_fdt.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 03/17] patman: Move to use Python 3

[sjg]

Update this tool to use Python 3 to meet the 2020 deadline.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/patman/patman.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 07/17] microcode_tool: Convert to Python 3

[sjg]

Convert this tool to Python 3 and make it use that, to meet the 2020
deadline.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/microcode-tool.py | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 09/17] rkmux: Convert to Python 3

[sjg]

Convert this tool to Python 3 and make it use that, to meet the 2020
deadline.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/rkmux.py | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/17] test_dtoc: Move to use Python 3

[sjg]

Update this test to use Python 3 to meet the 2020 deadline.

Also make it executable while we are here.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/dtoc/dtoc.py  | 2 +-
 tools/dtoc/test_dtoc.py | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 tools/dtoc/test_dtoc.py

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 11/17] pylibfdt: Sync up with upstream

[sjg]

Sync up the libfdt Python bindings with upstream, commit:

430419c (tests: fix some python warnings)

Signed-off-by: Simon Glass 
---

Changes in v2: None

 scripts/dtc/pylibfdt/libfdt.i_shipped | 45 ---
 1 file changed, 33 insertions(+), 12 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] fdt: Sync up to the latest libfdt

[sjg]

Bring over the fdt from this commit:

430419c (origin/master) tests: fix some python warnings

adding in the 'assumptions' series designed to reduce code size.

Signed-off-by: Simon Glass 
---

 lib/libfdt/fdt_ro.c  | 420 ---
 scripts/dtc/libfdt/Makefile.libfdt   |   7 +
 scripts/dtc/libfdt/fdt.c | 182 
 scripts/dtc/libfdt/fdt.h |  47 +--
 scripts/dtc/libfdt/fdt_addresses.c   |  94 +++---
 scripts/dtc/libfdt/fdt_empty_tree.c  |  47 +--
 scripts/dtc/libfdt/fdt_overlay.c |  91 ++
 scripts/dtc/libfdt/fdt_ro.c  | 341 +++---
 scripts/dtc/libfdt/fdt_rw.c  | 119 
 scripts/dtc/libfdt/fdt_strerror.c|  47 +--
 scripts/dtc/libfdt/fdt_sw.c  | 241 ++-
 scripts/dtc/libfdt/fdt_wip.c |  47 +--
 scripts/dtc/libfdt/libfdt.h  | 268 +
 scripts/dtc/libfdt/libfdt_env.h  |  48 +--
 scripts/dtc/libfdt/libfdt_internal.h | 144 +
 tools/libfdt/fdt_rw.c|   3 +-
 16 files changed, 1275 insertions(+), 871 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] mx6: tbs2910: Minimise libfdt code size

[sjg]

This board appears to be very near its size limit and cannot accept the
new checking code in libfdt. Disable this code so this the board can
continue to build.

Signed-off-by: Simon Glass 
---

 configs/tbs2910_defconfig | 1 +
 1 file changed, 1 insertion(+)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 08/17] move_config: Convert to Python 3

[sjg]

Convert this tool to Python 3 and make it use that, to meet the 2020
deadline.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/moveconfig.py | 82 ++---
 1 file changed, 41 insertions(+), 41 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 10/17] pylibfdt: Convert to Python 3

[sjg]

Build this swig module with Python 3.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 scripts/dtc/pylibfdt/Makefile |  2 +-
 scripts/dtc/pylibfdt/libfdt.i_shipped |  2 +-
 scripts/dtc/pylibfdt/setup.py |  2 +-
 tools/binman/entry.py | 16 ++--
 tools/binman/entry_test.py| 15 ---
 tools/binman/etype/intel_fit.py   |  2 +-
 6 files changed, 6 insertions(+), 33 deletions(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 13/17] binman: Remember the pre-reset entry size

[sjg]

When preparing to possible expand or contract an entry we reset the size
to the original value from the binman device-tree definition, which is
often None.

This causes binman to forget the original size of the entry. Remember this
so that it can be used when needed.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/binman/entry.py | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

Applied to u-boot-fdt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] [PATCH v2 2/2] arm: ls1028a: use the new flexspi driver

[Michael Walle]

Am 2019-11-05 10:53, schrieb Kuldeep Singh:
Hi Kuldeep,



>> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi
>> b/arch/arm/dts/fsl-ls1028a.dtsi index
>> 43a154e8e7..774e477542 100644
>> --- a/arch/arm/dts/fsl-ls1028a.dtsi
>> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
>> @@ -49,14 +49,16 @@
>>  <1 10 0x8>; /* Hypervisor PPI,
>> active-low */
>> };
>>
>> -   fspi: flexspi@20C {
>> -   compatible = "nxp,dn-fspi";
>> +   fspi: flexspi@20c {
>> +   compatible = "nxp,lx2160a-fspi";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> -   reg = <0x0 0x20C 0x0 0x1>,
>> -   <0x0 0x2000 0x0 0x1000>; /*64MB
>> flash*/
>> -   reg-names = "FSPI", "FSPI-memory";
>> -   num-cs = <1>;
>> +   reg = <0x0 0x20c 0x0 0x1>,
>> + <0x0 0x2000 0x0 0x1000>;
>> +   reg-names = "fspi_base", "fspi_mmap";
>> +   clocks = <&clockgen 4 3>, <&clockgen 4 3>;
>> +   clock-names = "fspi_en", "fspi";
>> +   interrupts = <0 25 0x4>;
>
> Please change the interrupts to "" as
> it avoids magic numbers.

This is consistent with the other interrupt properties, which doesn't 
have these
constants either. IMHO another commit where all these magic numbers 
are

removed would be better.



I just checked and found no interrupt handler in spi/nxp_fspi.c
driver. So, it's better to remove this line altogether. What do you
think?


For the sake of consistency (with all other nodes and with the linux 
device tree) and if someone would like to sync the device tree with the 
linux one, I'd keep that. Like I said before, I'd do another patch were 
all interrupt magic numbers are replaced with the correct constants.


-michael
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Please pull u-boot-fdt

[Simon Glass]

Hi Tom,

Passing run here:

https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1210


The following changes since commit 73b6e6ad254b36763419cdd3fdf406c0094517b7:

  Merge tag 'u-boot-imx-20191104' of
https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2019-11-04
12:57:41 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-fdt.git tags/fdt-pull-5nov19

for you to fetch changes up to 388560134b99dc4cc752627d3a7e9f8c8c2a89a7:

  binman: Move to use Python 3 (2019-11-04 18:15:32 -0700)


Update to latest libfdt and pylibfdt, with added size control
Update binman, dtoc, patman, buildman to Python 3
Update move_config, rkmux, microcode_tool to Python 3


Simon Glass (20):
  fdt: Add INT32_MAX to kernel.h for libfdt
  fdt: Add Kconfig options to control code size
  mx6: tbs2910: Minimise libfdt code size
  fdt: Sync up to the latest libfdt
  patman: Adjust 'command' to return strings instead of bytes
  patman: Use unicode for file I/O
  patman: Move to use Python 3
  buildman: Convert to Python 3
  test_fdt: Move to use Python 3
  test_dtoc: Move to use Python 3
  microcode_tool: Convert to Python 3
  move_config: Convert to Python 3
  rkmux: Convert to Python 3
  pylibfdt: Convert to Python 3
  pylibfdt: Sync up with upstream
  pylibfdt: Correct the type for fdt_property_stub()
  binman: Remember the pre-reset entry size
  binman: Convert a few tests to Python 3
  dtoc: Convert fdt.py to Python 3
  binman: Move to use Python 3

 configs/tbs2910_defconfig |   1 +
 include/linux/kernel.h|   2 +
 include/linux/libfdt_env.h|   1 +
 lib/Kconfig   |  33 +++
 lib/libfdt/Makefile   |   3 +-
 lib/libfdt/fdt_ro.c   | 420 +-
 scripts/dtc/libfdt/Makefile.libfdt|   7 +
 scripts/dtc/libfdt/fdt.c  | 182 ++-
 scripts/dtc/libfdt/fdt.h  |  47 +---
 scripts/dtc/libfdt/fdt_addresses.c|  94 
 scripts/dtc/libfdt/fdt_empty_tree.c   |  47 +---
 scripts/dtc/libfdt/fdt_overlay.c  |  91 +++-
 scripts/dtc/libfdt/fdt_ro.c   | 341 ++-
 scripts/dtc/libfdt/fdt_rw.c   | 119 +-
 scripts/dtc/libfdt/fdt_strerror.c |  47 +---
 scripts/dtc/libfdt/fdt_sw.c   | 241 ---
 scripts/dtc/libfdt/fdt_wip.c  |  47 +---
 scripts/dtc/libfdt/libfdt.h   | 268 +-
 scripts/dtc/libfdt/libfdt_env.h   |  48 +---
 scripts/dtc/libfdt/libfdt_internal.h  | 144 +++-
 scripts/dtc/pylibfdt/Makefile |   2 +-
 scripts/dtc/pylibfdt/libfdt.i_shipped |  51 +++--
 scripts/dtc/pylibfdt/setup.py |   2 +-
 tools/binman/binman.py|   2 +-
 tools/binman/cbfs_util_test.py|   2 +-
 tools/binman/entry.py |  25 +-
 tools/binman/entry_test.py|  15 --
 tools/binman/etype/intel_fit.py   |   2 +-
 tools/binman/ftest.py |  16 +-
 tools/buildman/board.py   |   9 +-
 tools/buildman/bsettings.py   |  20 +-
 tools/buildman/builder.py |  47 ++--
 tools/buildman/builderthread.py   |  24 +-
 tools/buildman/buildman.py|  10 +-
 tools/buildman/control.py |  44 ++--
 tools/buildman/func_test.py   |  16 +-
 tools/buildman/test.py|  22 +-
 tools/buildman/toolchain.py   |  99 
 tools/dtoc/dtoc.py|   2 +-
 tools/dtoc/fdt.py |  17 +-
 tools/dtoc/test_dtoc.py   |   1 +
 tools/dtoc/test_fdt.py|   2 +-
 tools/libfdt/fdt_rw.c |   3 +-
 tools/microcode-tool.py   |  28 +--
 tools/moveconfig.py   |  82 +++
 tools/patman/command.py   |  31 ++-
 tools/patman/func_test.py |   8 +-
 tools/patman/patchstream.py   |   4 +-
 tools/patman/patman.py|   2 +-
 tools/patman/series.py|   2 +-
 tools/patman/settings.py  |   4 +-
 tools/patman/test.py  |   4 +-
 tools/patman/tools.py |  29 ++-
 tools/rkmux.py|  16 +-
 54 files changed, 1645 insertions(+), 1181 deletions(-)
 mode change 100644 => 100755 tools/dtoc/test_dtoc.py

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 1/6] mx7ulp: Print the LDO mode status

[Fabio Estevam]

As per the i.MX7ULP datasheet, it can boot in LDO enabled mode
or LDO bypass mode.

Print the LDO mode status in the U-Boot log for convenience.

Signed-off-by: Fabio Estevam 
---
Changes since v2:
- None

 arch/arm/mach-imx/mx7ulp/soc.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 127fcfeea1..b9a108a514 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -131,6 +131,21 @@ const char *get_imx_type(u32 imxtype)
return "7ULP";
 }
 
+#define PMC0_BASE_ADDR 0x410a1000
+#define PMC0_CTRL  0x28
+#define PMC0_CTRL_LDOENBIT(31)
+
+static bool ldo_mode_is_enabled(void)
+{
+   unsigned int reg;
+
+   reg = readl(PMC0_BASE_ADDR + PMC0_CTRL);
+   if (reg & PMC0_CTRL_LDOEN)
+   return true;
+   else
+   return false;
+}
+
 int print_cpuinfo(void)
 {
u32 cpurev;
@@ -159,6 +174,11 @@ int print_cpuinfo(void)
break;
}
 
+   if (ldo_mode_is_enabled())
+   printf("PMC1:  LDO enabled mode\n");
+   else
+   printf("PMC1:  LDO bypass mode\n");
+
return 0;
 }
 #endif
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 2/6] mx7ulp: Introduce the CONFIG_LDO_ENABLED_MODE option

[Fabio Estevam]

Introduce the CONFIG_LDO_ENABLED_MODE option so that i.MX7ULP boards
designed to operate with LDO enabled mode can work with 0.95V at LDO
output in RUN mode as per the datasheet.

Signed-off-by: Fabio Estevam 
---
Changes since v2:
- None

 arch/arm/mach-imx/mx7ulp/Kconfig |  5 +++
 arch/arm/mach-imx/mx7ulp/soc.c   | 58 
 2 files changed, 63 insertions(+)

diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig b/arch/arm/mach-imx/mx7ulp/Kconfig
index ed5f0aeb2d..138c58363f 100644
--- a/arch/arm/mach-imx/mx7ulp/Kconfig
+++ b/arch/arm/mach-imx/mx7ulp/Kconfig
@@ -3,6 +3,11 @@ if ARCH_MX7ULP
 config SYS_SOC
default "mx7ulp"
 
+config LDO_ENABLED_MODE
+   bool "i.MX7ULP LDO Enabled Mode"
+   help
+ Select this option to enable the PMC1 LDO.
+
 config MX7ULP
bool
 
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index b9a108a514..751575c95e 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -9,6 +9,22 @@
 #include 
 #include 
 
+#define PMC0_BASE_ADDR 0x410a1000
+#define PMC0_CTRL  0x28
+#define PMC0_CTRL_LDOENBIT(31)
+#define PMC0_CTRL_LDOOKDIS BIT(30)
+#define PMC0_CTRL_PMC1ON   BIT(24)
+#define PMC1_BASE_ADDR 0x4040
+#define PMC1_RUN   0x8
+#define PMC1_STOP  0x10
+#define PMC1_VLPS  0x14
+#define PMC1_RUN_LDOVL_SHIFT   16
+#define PMC1_RUN_LDOVL_MASK(0x3f << PMC1_RUN_LDOVL_SHIFT)
+#define PMC1_RUN_LDOVL_900 0x1e
+#define PMC1_RUN_LDOVL_950 0x23
+#define PMC1_STATUS0x20
+#define PMC1_STATUS_LDOVLF BIT(8)
+
 static char *get_reset_cause(char *);
 
 #if defined(CONFIG_IMX_HAB)
@@ -100,6 +116,44 @@ void init_wdog(void)
disable_wdog(WDG2_RBASE);
 }
 
+#if defined(CONFIG_LDO_ENABLED_MODE)
+static void init_ldo_mode(void)
+{
+   unsigned int reg;
+
+   /* Set LDOOKDIS */
+   setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
+
+   /* Set LDOVL to 0.95V in PMC1_RUN */
+   reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
+   reg &= ~PMC1_RUN_LDOVL_MASK;
+   reg |= (PMC1_RUN_LDOVL_950 << PMC1_RUN_LDOVL_SHIFT);
+   writel(PMC1_BASE_ADDR + PMC1_RUN, reg);
+
+   /* Wait for LDOVLF to be cleared */
+   reg = readl(PMC1_BASE_ADDR + PMC1_STATUS);
+   while (reg & PMC1_STATUS_LDOVLF)
+   ;
+
+   /* Set LDOVL to 0.95V in PMC1_STOP */
+   reg = readl(PMC1_BASE_ADDR + PMC1_STOP);
+   reg &= ~PMC1_RUN_LDOVL_MASK;
+   reg |= (PMC1_RUN_LDOVL_950 << PMC1_RUN_LDOVL_SHIFT);
+   writel(PMC1_BASE_ADDR + PMC1_STOP, reg);
+
+   /* Set LDOVL to 0.90V in PMC1_VLPS */
+   reg = readl(PMC1_BASE_ADDR + PMC1_VLPS);
+   reg &= ~PMC1_RUN_LDOVL_MASK;
+   reg |= (PMC1_RUN_LDOVL_900 << PMC1_RUN_LDOVL_SHIFT);
+   writel(PMC1_BASE_ADDR + PMC1_VLPS, reg);
+
+   /* Set LDOEN bit */
+   setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOEN);
+
+   /* Set the PMC1ON bit */
+   setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_PMC1ON);
+}
+#endif
 
 void s_init(void)
 {
@@ -113,6 +167,10 @@ void s_init(void)
/* enable dumb pmic */
writel((readl(SNVS_LP_LPCR) | SNVS_LPCR_DPEN), SNVS_LP_LPCR);
}
+
+#if defined(CONFIG_LDO_ENABLED_MODE)
+   init_ldo_mode();
+#endif
return;
 }
 
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 3/6] mx7ulp: Remove the _RUN notation from the PMC1 LDOVL definitions

[Fabio Estevam]

The LDOVL definitions is common to all the modes, not only RUN mode,
so in order to avoid confusion, remove the _RUN notation from the PMC1
LDOVL definitions.

Signed-off-by: Fabio Estevam 
---
Changes since v2:
- None

 arch/arm/mach-imx/mx7ulp/soc.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 751575c95e..4487fa61c0 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -18,10 +18,10 @@
 #define PMC1_RUN   0x8
 #define PMC1_STOP  0x10
 #define PMC1_VLPS  0x14
-#define PMC1_RUN_LDOVL_SHIFT   16
-#define PMC1_RUN_LDOVL_MASK(0x3f << PMC1_RUN_LDOVL_SHIFT)
-#define PMC1_RUN_LDOVL_900 0x1e
-#define PMC1_RUN_LDOVL_950 0x23
+#define PMC1_LDOVL_SHIFT   16
+#define PMC1_LDOVL_MASK(0x3f << PMC1_LDOVL_SHIFT)
+#define PMC1_LDOVL_900 0x1e
+#define PMC1_LDOVL_950 0x23
 #define PMC1_STATUS0x20
 #define PMC1_STATUS_LDOVLF BIT(8)
 
@@ -126,8 +126,8 @@ static void init_ldo_mode(void)
 
/* Set LDOVL to 0.95V in PMC1_RUN */
reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
-   reg &= ~PMC1_RUN_LDOVL_MASK;
-   reg |= (PMC1_RUN_LDOVL_950 << PMC1_RUN_LDOVL_SHIFT);
+   reg &= ~PMC1_LDOVL_MASK;
+   reg |= (PMC1_LDOVL_950 << PMC1_LDOVL_SHIFT);
writel(PMC1_BASE_ADDR + PMC1_RUN, reg);
 
/* Wait for LDOVLF to be cleared */
@@ -137,14 +137,14 @@ static void init_ldo_mode(void)
 
/* Set LDOVL to 0.95V in PMC1_STOP */
reg = readl(PMC1_BASE_ADDR + PMC1_STOP);
-   reg &= ~PMC1_RUN_LDOVL_MASK;
-   reg |= (PMC1_RUN_LDOVL_950 << PMC1_RUN_LDOVL_SHIFT);
+   reg &= ~PMC1_LDOVL_MASK;
+   reg |= (PMC1_LDOVL_950 << PMC1_LDOVL_SHIFT);
writel(PMC1_BASE_ADDR + PMC1_STOP, reg);
 
/* Set LDOVL to 0.90V in PMC1_VLPS */
reg = readl(PMC1_BASE_ADDR + PMC1_VLPS);
-   reg &= ~PMC1_RUN_LDOVL_MASK;
-   reg |= (PMC1_RUN_LDOVL_900 << PMC1_RUN_LDOVL_SHIFT);
+   reg &= ~PMC1_LDOVL_MASK;
+   reg |= (PMC1_LDOVL_900 << PMC1_LDOVL_SHIFT);
writel(PMC1_BASE_ADDR + PMC1_VLPS, reg);
 
/* Set LDOEN bit */
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 6/6] mx7ulp: Add support for Embedded Artists COM board

[Fabio Estevam]

The Embedded Artists COM board is based on NXP i.MX7ULP.

It has a BD70528 PMIC from Rohm with discrete DCDC powering option and
improved current observability (compared to the existing NXP i.MX7ULP EVK).

Add the initial support for the board.

Signed-off-by: Fabio Estevam 
---
Changes since v2:
- Add the imx7ulp-com.dts (Peng Fan)

 arch/arm/dts/Makefile|   3 +-
 arch/arm/dts/imx7ulp-com.dts |  90 ++
 arch/arm/mach-imx/mx7ulp/Kconfig |   6 ++
 board/ea/mx7ulp_com/Kconfig  |  12 +++
 board/ea/mx7ulp_com/MAINTAINERS  |   6 ++
 board/ea/mx7ulp_com/Makefile |   6 ++
 board/ea/mx7ulp_com/imximage.cfg | 128 +++
 board/ea/mx7ulp_com/mx7ulp_com.c |  48 
 configs/mx7ulp_com_defconfig |  59 ++
 include/configs/mx7ulp_com.h | 107 ++
 10 files changed, 464 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx7ulp-com.dts
 create mode 100644 board/ea/mx7ulp_com/Kconfig
 create mode 100644 board/ea/mx7ulp_com/MAINTAINERS
 create mode 100644 board/ea/mx7ulp_com/Makefile
 create mode 100644 board/ea/mx7ulp_com/imximage.cfg
 create mode 100644 board/ea/mx7ulp_com/mx7ulp_com.c
 create mode 100644 configs/mx7ulp_com_defconfig
 create mode 100644 include/configs/mx7ulp_com.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 251d32ca62..4ce0d813d4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -648,7 +648,8 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
imx7d-pico-hobbit.dtb
 
 
-dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
+dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-com.dtb \
+   imx7ulp-evk.dtb
 
 dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
diff --git a/arch/arm/dts/imx7ulp-com.dts b/arch/arm/dts/imx7ulp-com.dts
new file mode 100644
index 00..c01e03dd06
--- /dev/null
+++ b/arch/arm/dts/imx7ulp-com.dts
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright 2019 NXP
+// Author: Fabio Estevam 
+
+/dts-v1/;
+
+#include "imx7ulp.dtsi"
+
+/ {
+   model = "Embedded Artists i.MX7ULP COM";
+   compatible = "ea,imx7ulp-com", "fsl,imx7ulp";
+
+   chosen {
+   stdout-path = &lpuart4;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x6000 0x800>;
+   };
+};
+
+&lpuart4 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lpuart4>;
+   status = "okay";
+};
+
+&usbotg1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_usbotg1_id>;
+   srp-disable;
+   hnp-disable;
+   adp-disable;
+   status = "okay";
+};
+
+&usbphy1 {
+   fsl,tx-d-cal = <88>;
+};
+
+&usdhc0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_usdhc0>;
+   non-removable;
+   bus-width = <8>;
+   no-1-8-v;
+   status = "okay";
+};
+
+&iomuxc1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_hog_1>;
+
+   pinctrl_hog_1: hoggrp-1 {
+   fsl,pins = <
+   IMX7ULP_PAD_PTC1__PTC1  0x2
+   >;
+   };
+
+   pinctrl_lpuart4: lpuart4grp {
+   fsl,pins = <
+   IMX7ULP_PAD_PTC3__LPUART4_RX0x3
+   IMX7ULP_PAD_PTC2__LPUART4_TX0x3
+   >;
+   };
+
+   pinctrl_usdhc0: usdhc0grp {
+   fsl,pins = <
+   IMX7ULP_PAD_PTD1__SDHC0_CMD 0x43
+   IMX7ULP_PAD_PTD2__SDHC0_CLK 0x10042
+   IMX7ULP_PAD_PTD3__SDHC0_D7  0x43
+   IMX7ULP_PAD_PTD4__SDHC0_D6  0x43
+   IMX7ULP_PAD_PTD5__SDHC0_D5  0x43
+   IMX7ULP_PAD_PTD6__SDHC0_D4  0x43
+   IMX7ULP_PAD_PTD7__SDHC0_D3  0x43
+   IMX7ULP_PAD_PTD8__SDHC0_D2  0x43
+   IMX7ULP_PAD_PTD9__SDHC0_D1  0x43
+   IMX7ULP_PAD_PTD10__SDHC0_D0 0x43
+   IMX7ULP_PAD_PTD11__SDHC0_DQS0x42
+   >;
+   };
+
+   pinctrl_usbotg1_id: otg1idgrp {
+   fsl,pins = <
+   IMX7ULP_PAD_PTC13__USB0_ID  0x10003
+   >;
+   };
+};
diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig b/arch/arm/mach-imx/mx7ulp/Kconfig
index 138c58363f..6680f856c5 100644
--- a/arch/arm/mach-imx/mx7ulp/Kconfig
+++ b/arch/arm/mach-imx/mx7ulp/Kconfig
@@ -15,6 +15,11 @@ choice
prompt "MX7ULP board select"
optional
 
+config TARGET_MX7ULP_COM
+   bool "Support MX7ULP COM board"
+   select MX7ULP
+   select SYS_ARCH_TIMER
+
 config TARGET_MX7ULP_EVK
bool "Support mx7ulp EVK board"
select MX7ULP
@@ -22,6 +27,7 @@ config TARGET_MX7ULP_EVK
 
 endchoice
 
+source "board/ea/mx7ulp_com/Kconfig"
 source "board/freescale/mx7ulp_evk/Kconfig"
 
 endif
diff --git a/board/ea/mx7ulp_com/Kconfig b/board/ea/mx7ulp_com/Kcon

[U-Boot] [PATCH v3 4/6] mx7ulp: scg: Remove unnused scg_a7_apll_init()

[Fabio Estevam]

scg_a7_apll_init() is not called anywhere, so remove such dead code

Signed-off-by: Fabio Estevam 
---
Changes since v2:
- None

 arch/arm/include/asm/arch-mx7ulp/scg.h |  1 -
 arch/arm/mach-imx/mx7ulp/scg.c | 61 --
 2 files changed, 62 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx7ulp/scg.h 
b/arch/arm/include/asm/arch-mx7ulp/scg.h
index 531d8f3a95..b79bde338f 100644
--- a/arch/arm/include/asm/arch-mx7ulp/scg.h
+++ b/arch/arm/include/asm/arch-mx7ulp/scg.h
@@ -331,7 +331,6 @@ u32 decode_pll(enum pll_clocks pll);
 void scg_a7_rccr_init(void);
 void scg_a7_spll_init(void);
 void scg_a7_ddrclk_init(void);
-void scg_a7_apll_init(void);
 void scg_a7_firc_init(void);
 void scg_a7_nicclk_init(void);
 void scg_a7_sys_clk_sel(enum scg_sys_src clk);
diff --git a/arch/arm/mach-imx/mx7ulp/scg.c b/arch/arm/mach-imx/mx7ulp/scg.c
index 819c90af6c..c7bb7a1c66 100644
--- a/arch/arm/mach-imx/mx7ulp/scg.c
+++ b/arch/arm/mach-imx/mx7ulp/scg.c
@@ -949,67 +949,6 @@ void scg_a7_ddrclk_init(void)
 /* Clock source is System OSC <<0 */
 #define SCG1_APLL_CFG_CLKSRC_NUM((0x0) << SCG_PLL_CFG_CLKSRC_SHIFT)
 
-/*
- * A7 APLL = 24MHz / 1 * 22 / 1 / 1 = 528MHz,
- * system PLL is sourced from APLL,
- * APLL clock source is system OSC (24MHz)
- */
-#define SCG1_APLL_CFG_NUM_24M_OSC (SCG1_APLL_CFG_POSTDIV2_NUM |   \
-  SCG1_APLL_CFG_POSTDIV1_NUM |   \
-  (22 << SCG_PLL_CFG_MULT_SHIFT) |   \
-  SCG1_APLL_CFG_PFDSEL_NUM   |   \
-  SCG1_APLL_CFG_PREDIV_NUM   |   \
-  SCG1_APLL_CFG_BYPASS_NUM   |   \
-  SCG1_APLL_CFG_PLLSEL_NUM   |   \
-  SCG1_APLL_CFG_CLKSRC_NUM)
-
-/* PFD0 Freq = A7 APLL(528MHz) * 18 / 27 = 352MHz */
-#define SCG1_APLL_PFD0_FRAC_NUM (27)
-
-
-void scg_a7_apll_init(void)
-{
-   u32 val = 0;
-
-   /* Disable A7 Auxiliary PLL */
-   val = readl(&scg1_regs->apllcsr);
-   val &= ~SCG_APLL_CSR_APLLEN_MASK;
-   writel(val, &scg1_regs->apllcsr);
-
-   /* Gate off A7 APLL PFD0 ~ PDF4  */
-   val = readl(&scg1_regs->apllpfd);
-   val |= 0x80808080;
-   writel(val, &scg1_regs->apllpfd);
-
-   /*  A7 APLL Configuration Start == */
-   /* Configure A7 Auxiliary PLL */
-   writel(SCG1_APLL_CFG_NUM_24M_OSC, &scg1_regs->apllcfg);
-
-   /* Enable A7 Auxiliary PLL */
-   val = readl(&scg1_regs->apllcsr);
-   val |= SCG_APLL_CSR_APLLEN_MASK;
-   writel(val, &scg1_regs->apllcsr);
-
-   /* Wait for A7 APLL clock ready */
-   while (!(readl(&scg1_regs->apllcsr) & SCG_APLL_CSR_APLLVLD_MASK))
-   ;
-
-   /* Configure A7 APLL PFD0 */
-   val = readl(&scg1_regs->apllpfd);
-   val &= ~SCG_PLL_PFD0_FRAC_MASK;
-   val |= SCG1_APLL_PFD0_FRAC_NUM;
-   writel(val, &scg1_regs->apllpfd);
-
-   /* Un-gate A7 APLL PFD0 */
-   val = readl(&scg1_regs->apllpfd);
-   val &= ~SCG_PLL_PFD0_GATE_MASK;
-   writel(val, &scg1_regs->apllpfd);
-
-   /* Wait for A7 APLL PFD0 clock being valid */
-   while (!(readl(&scg1_regs->apllpfd) & SCG_PLL_PFD0_VALID_MASK))
-   ;
-}
-
 /* SCG1(A7) FIRC DIV configurations */
 /* Disable FIRC DIV3 */
 #define SCG1_FIRCDIV_DIV3_NUM   ((0x0) << SCG_FIRCDIV_DIV3_SHIFT)
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 6/6] mx7ulp: Add support for Embedded Artists COM board

[Fabio Estevam]

Hi Peng,

On Tue, Nov 5, 2019 at 2:57 AM Peng Fan  wrote:

> Hi Fabio,
>
> Seems you not add dts files. CI build fail
>arm:  +   mx7ulp_com
> +make[3]: *** No rule to make target 'arch/arm/dts/imx7ulp-com.dtb', needed 
> by 'dtbs'.  Stop.
> +make[2]: *** [arch-dtbs] Error 2
> +make[1]: *** [dts/dt.dtb] Error 2
> +make: *** [sub-make] Error 2

Ops, sorry. I have sent a v3 which adds the dtb.

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] mx6cuboxi: enable OF_CONTROL with DM_MMC and DM_USB

[Baruch Siach]

Make first step in DT/DM migration. Enable OF_CONTROL only for the main
U-Boot image for now.

Remove mmc_init_main() because board_mmc_init() is not called when
DM_MMC is enabled.

DM_MMC requires DM_GPIO for card-detect to work. That in turn makes gpio
request mandatory. Add code to request/free gpios in platform code.

MMC devices are now numbered according to DT. The SD card is 1, and eMMC
is 2. Account for that in board_mmc_get_env_dev(), BOOT_TARGET_DEVICES,
and has_emmc().

DM_MMC requires BLK. However, the (BLK && !DM_USB) combination disables
USB_STORAGE. Enable DM_USB to preserve USB functionality. Add also
DM_REGULATORS for the USB power controller. This allows us to drop
board_ehci_hcd_init() and setup_usb().

Runtime selection of DT is necessary because of the i.MX6QD vs i.MX6SDL
incompatibility. DT selection does not rely on GPIOs, since DM_GPIO
depends on DT. Instead, we take one "fully featured" DT of each variant.
That should be enough to boot from both SD card and eMMC.

Since we don't select the exact DT, override the generic
show_board_info() that shows the selected DT 'model' field.

Signed-off-by: Baruch Siach 
---
 board/solidrun/mx6cuboxi/mx6cuboxi.c | 119 ---
 configs/mx6cuboxi_defconfig  |  16 +++-
 include/configs/mx6cuboxi.h  |   6 +-
 3 files changed, 89 insertions(+), 52 deletions(-)

diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c 
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index f82fb0786a94..bb005aa28325 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -65,6 +65,8 @@ enum board_type {
UNKNOWN = 0x03,
 };
 
+static struct gpio_desc board_detect_desc[5];
+
 #define MEM_STRIDE 0x400
 static u32 get_ram_size_stride_test(u32 *base, u32 maxsize)
 {
@@ -154,10 +156,6 @@ static iomux_v3_cfg_t const som_rev_detect[] = {
IOMUX_PADS(PAD_CSI0_DAT18__GPIO6_IO04  | MUX_PAD_CTRL(UART_PAD_CTRL)),
 };
 
-static iomux_v3_cfg_t const usb_pads[] = {
-   IOMUX_PADS(PAD_GPIO_0__GPIO1_IO00 | MUX_PAD_CTRL(NO_PAD_CTRL)),
-};
-
 static void setup_iomux_uart(void)
 {
SETUP_IOMUX_PADS(uart1_pads);
@@ -175,7 +173,7 @@ static struct fsl_esdhc_cfg emmc_cfg = {
 
 int board_mmc_get_env_dev(int devno)
 {
-   return devno - 1;
+   return devno;
 }
 
 #define USDHC2_CD_GPIO  IMX_GPIO_NR(1, 4)
@@ -197,27 +195,6 @@ int board_mmc_getcd(struct mmc *mmc)
return ret;
 }
 
-static int mmc_init_main(bd_t *bis)
-{
-   int ret;
-
-   /*
-* Following map is done:
-* (U-Boot device node)(Physical Port)
-* mmc0Carrier board MicroSD
-* mmc1SOM eMMC
-*/
-   SETUP_IOMUX_PADS(usdhc2_pads);
-   usdhc_cfg.sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
-   ret = fsl_esdhc_initialize(bis, &usdhc_cfg);
-   if (ret)
-   return ret;
-
-   SETUP_IOMUX_PADS(usdhc3_pads);
-   emmc_cfg.sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
-   return fsl_esdhc_initialize(bis, &emmc_cfg);
-}
-
 static int mmc_init_spl(bd_t *bis)
 {
struct src *psrc = (struct src *)SRC_BASE_ADDR;
@@ -251,7 +228,7 @@ int board_mmc_init(bd_t *bis)
if (IS_ENABLED(CONFIG_SPL_BUILD))
return mmc_init_spl(bis);
 
-   return mmc_init_main(bis);
+   return 0;
 }
 
 static iomux_v3_cfg_t const enet_pads[] = {
@@ -283,12 +260,29 @@ static iomux_v3_cfg_t const enet_pads[] = {
 
 static void setup_iomux_enet(void)
 {
+   struct gpio_desc desc;
+   int ret;
+
SETUP_IOMUX_PADS(enet_pads);
 
+   ret = dm_gpio_lookup_name("GPIO4_15", &desc);
+   if (ret) {
+   printf("%s: phy reset lookup failed\n", __func__);
+   return;
+   }
+
+   ret = dm_gpio_request(&desc, "phy-reset");
+   if (ret) {
+   printf("%s: phy reset request failed\n", __func__);
+   return;
+   }
+
gpio_direction_output(ETH_PHY_RESET, 0);
mdelay(10);
gpio_set_value(ETH_PHY_RESET, 1);
udelay(100);
+
+   gpio_free_list_nodev(&desc, 1);
 }
 
 int board_phy_config(struct phy_device *phydev)
@@ -433,21 +427,6 @@ static int setup_display(void)
 }
 #endif /* CONFIG_VIDEO_IPUV3 */
 
-#ifdef CONFIG_USB_EHCI_MX6
-static void setup_usb(void)
-{
-   SETUP_IOMUX_PADS(usb_pads);
-}
-
-int board_ehci_hcd_init(int port)
-{
-   if (port == 1)
-   gpio_direction_output(USB_H1_VBUS, 1);
-
-   return 0;
-}
-#endif
-
 int board_early_init_f(void)
 {
setup_iomux_uart();
@@ -455,10 +434,6 @@ int board_early_init_f(void)
 #ifdef CONFIG_CMD_SATA
setup_sata();
 #endif
-
-#ifdef CONFIG_USB_EHCI_MX6
-   setup_usb();
-#endif
return 0;
 }
 
@@ -476,6 +451,29 @@ int board_init(void)
return ret;
 }
 
+static int request_detect_gpios(void)
+{
+   int node;
+   int ret;
+
+   node = fdt_node_offset_by_compatible(gd->fdt_blob, 0,
+   "solidrun,h

Re: [U-Boot] [PATCH v2 2/4] dm: board: complete the initialization of the muxes in initr_dm()

[Vignesh Raghavendra]

Hi JJ,

On 05/11/19 5:20 PM, Jean-Jacques Hiblot wrote:
> This will probe the multiplexer devices that have a "u-boot,mux-autoprobe"
> property. As a consequence they will be put in their idle state.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> 
> ---
[...]
> diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
> index 6aaf4dc964..71392e9e50 100644
> --- a/drivers/mux/mux-uclass.c
> +++ b/drivers/mux/mux-uclass.c
> @@ -262,6 +262,28 @@ int mux_uclass_post_probe(struct udevice *dev)
>   return 0;
>  }
>  
> +void dm_mux_init(void)
> +{
> + struct uclass *uc;
> + struct udevice *dev;
> + int ret;
> +
> + ret = uclass_get(UCLASS_MUX, &uc);
> + if (ret < 0) {
> + debug("unable to get MUX uclass\n");
> + return;
> + }
> + uclass_foreach_dev(dev, uc) {
> + if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
> + ret = device_probe(dev);
> + if (ret)
> + debug("unable to probe device %s\n", dev->name);
> + } else {
> + printf("not found for dev %s\n", dev->name);
> + }

Is "u-boot,mux-autoprobe" a required property? The fact that its in DT
makes me think its optional. If that's the case, above printf() should
be reduced to debug() to avoid confusion

> + }
> +}
> +
>  UCLASS_DRIVER(mux) = {
>   .id = UCLASS_MUX,
>   .name   = "mux",
> diff --git a/include/mux.h b/include/mux.h
> index 060f71a47c..2467723951 100644
> --- a/include/mux.h
> +++ b/include/mux.h
> @@ -75,6 +75,8 @@ void mux_control_put(struct mux_control *mux);
>  
>  struct mux_control *devm_mux_control_get(struct udevice *dev,
>const char *mux_name);
> +void dm_mux_init(void);
> +
>  #else
>  unsigned int mux_control_states(struct mux_control *mux)
>  {
> 

-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] net: avoid address-of-packed-member error

[Tom Rini]

On Tue, Nov 05, 2019 at 12:48:19PM +0100, Heinrich Schuchardt wrote:

> sandbox_defconfig does not compile using GCC 9.2.1:
> 
> net/net.c: In function ‘net_process_received_packet’:
> net/net.c:1288:23: error: taking address of packed member of ‘struct
> ip_udp_hdr’ may result in an unaligned pointer value
> [-Werror=address-of-packed-member]
>  1288 |sumptr = (ushort *)&(ip->udp_src);
>   |   ^~
> 
> Avoid the error by using a u8 pointer instead of an u16 pointer and
> in-lining ntohs().
> 
> Simplify the checksumming of the last message byte.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   reword commit message
>   add a comment
>   simplify checksumming of last byte

If I follow what Simon was saying yesterday, the whole message framing
is wrong.  The problem isn't that gcc 9.2 is showing a warning, the
problem is that gcc 9.2 is showing that we have a problem (in terms of
what can/can't happen in real life networking terms), which you're
correcting.  Simon, can you please suggest a commit message here if
you're still not quite happy, as you understand the underlying problem
well it seems.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] net: avoid address-of-packed-member error

[Simon Goldschmidt]

On Tue, Nov 5, 2019 at 2:52 PM Tom Rini  wrote:
>
> On Tue, Nov 05, 2019 at 12:48:19PM +0100, Heinrich Schuchardt wrote:
>
> > sandbox_defconfig does not compile using GCC 9.2.1:
> >
> > net/net.c: In function ‘net_process_received_packet’:
> > net/net.c:1288:23: error: taking address of packed member of ‘struct
> > ip_udp_hdr’ may result in an unaligned pointer value
> > [-Werror=address-of-packed-member]
> >  1288 |sumptr = (ushort *)&(ip->udp_src);
> >   |   ^~
> >
> > Avoid the error by using a u8 pointer instead of an u16 pointer and
> > in-lining ntohs().
> >
> > Simplify the checksumming of the last message byte.
> >
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> > v2:
> >   reword commit message
> >   add a comment
> >   simplify checksumming of last byte
>
> If I follow what Simon was saying yesterday, the whole message framing
> is wrong.  The problem isn't that gcc 9.2 is showing a warning, the
> problem is that gcc 9.2 is showing that we have a problem (in terms of
> what can/can't happen in real life networking terms), which you're
> correcting.  Simon, can you please suggest a commit message here if
> you're still not quite happy, as you understand the underlying problem
> well it seems.  Thanks!

Well, we do have an error and GCC 9.2 shows this. I don't know why other
versions don't issue this warning.

This new commit message might still concentrate too much on the GCC version,
but I think it's ok. I just wanted to prevent someone reading this in the
future and taking it as a hint that the attribute 'packed' can be removed
(which in turn might procude bugs on some platforms).

So:
Reviewed-by: Simon Goldschmidt 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Tom Rini]

On Tue, Nov 05, 2019 at 02:13:13AM +, Aaron Williams wrote:
> Hi Wolfgang,
> 
> On Monday, November 4, 2019 9:22:16 AM PST Tom Rini wrote:
> > On Thu, Oct 31, 2019 at 06:01:34PM +, Aaron Williams wrote:
> > > Hi Wolfgang,
> > > 
> > > On Thursday, October 31, 2019 3:40:27 AM PDT Wolfgang Denk wrote:
> > > > Dear Aaron,
> > > > 
> > > > In message <1889679.7FQr5zsBR1@flash> you wrote:
> > > > > Currently we are using 39MB under arch/mips. I think I can easily cut
> > > > > this
> > > > > down to 15MB or smaller, especially by moving some code here to the
> > > > > appropriate driver directories (i.e. DRAM,  pcie, watchdog, etc.)
> > > > > 
> > > > > It will still be a large SoC, though.
> > > > 
> > > > Have you already looked at formal requirements, like coding style
> > > > etc.?   Did you ever run your additions through checkpatch.pl, for
> > > > example?
> > > 
> > > We did follow the formal coding style. Everything will go through
> > > checkpatch. My biggest complaint about it is the 80 columns for debug and
> > > other print statements.
> > 
> > checkpatch doesn't complain about those when they use standard logging
> > functions, however.
> 
> It complains plenty about printf(), debug() and a number of other standard U-
> Boot logging calls.

Yes, but not about pr_debug, etc, which are what really should be used.
Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Tom Rini]

On Tue, Nov 05, 2019 at 02:08:54AM +, Aaron Williams wrote:
> On Monday, November 4, 2019 8:23:08 AM PST Tom Rini wrote:
> > On Mon, Nov 04, 2019 at 04:44:18PM +0100, Wolfgang Denk wrote:
> > > Dear Aaron,
> > > 
> > > In message <2710076.TiSPtmOvtb@flash> you wrote:
> > > > > What exactly do you need this for?  Why don't you just link your
> > > > > code with the rest of U-Boot?
> > > > 
> > > > We need it to obtain and modify the phy parameters. This is a custom 25G
> > > > gearbox that needs a lot of hand holding. This may end up being a low
> > > > priority (not the gearbox, but the API). It's only a few hundred lines
> > > > of code (the API).
> > > 
> > > Again you don't answer my question.  Why do you need a special new
> > > API for such code?  Why do you not just link that code with the rest
> > > of U-Boot?
> > > 
> > > It has been mentioned before, but just to be sure: this code which
> > > uses your new API is licensed under a GPLv2 conforming lincense?
> > 
> > And, to be blunt, if it is not, handling your non-GPLv2 applications
> > via an EFI binary is the way forward, not extending the U-Boot binary
> > ABI, in my opinion.
> 
> To be blunt, the current U-Boot EFI driver does not provide the required 
> functionality. It would need to be extended in order to work. In addition, 
> spinlocks would be required in order to handle the case of reentrancy. Also, 
> how does the EFI loader deal with loading multiple applications across 
> multiple cores? The block support is the least important part of it. There 
> are 
> several other services not related to block devices or network calls.

If there are parts of the EFI specification that we do not implement,
but could implement, it would be a much appreciated contribution to the
code.  If once you're up in the EFI world there are things you cannot do
that you need to do, that should be taken up with the UEFI consortium.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Tom Rini]

On Tue, Nov 05, 2019 at 09:33:35AM +0100, Wolfgang Denk wrote:
> Dear Aaron,
> 
> In message <5376617.97hUrJXovB@flash> you wrote:
> >
> > > Again you don't answer my question.  Why do you need a special new
> > > API for such code?  Why do you not just link that code with the rest
> > > of U-Boot?
> >
> > The code in question that is calling the API is not GPL and hence cannot be 
> > linked with U-Boot though the phy code is GPL.
> 
> Ouch.  I was afraid to hear that.
> 
> Please be aware that your newly created API does NOT implement a GPL
> license exception.  the only interface that allows for non-GPL code
> to be run under control of U-Boot is the standalone program
> interface, which is intentionally very restricted.
> 
> In other words: what you are doing here is a clear (and intentional,
> which makes it even worse) GPL license violation.
> 
> > > It has been mentioned before, but just to be sure: this code which
> > > uses your new API is licensed under a GPLv2 conforming lincense?
> > > 
> > There should be no need. None of the code is linked against U-Boot, either 
> > at 
> > compile time nor at runtime. The application doesn't even know where it is 
> > located except by looking for a named block of memory.
> 
> It does not have to be linked.  You access internal interfaces of
> U-Boot that have not been exported for non-GPL use, so your code
> still has to be licensed under GPLv2 or a compatible license.

I'm just following up to say that I agree with Wolfgang here.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC PATCH v1] imx: bootaux: PoC for elf firmware support

[Igor Opaniuk]

From: Igor Opaniuk 

Currently imx-specific bootaux command doesn't support ELF format
firmware for Cortex-M4 core.

This patches introduces a PoC implementation of handling elf firmware
(load_elf_image_phdr() was copy-pasted from elf.c just for PoC).

This has the advantage that the user does not need to know to which
address the binary has been linked to. However, in order to handle
and load the elf sections to the right address, we need to translate the
Cortex-M4 core memory addresses to primary/host CPU memory
addresses (Cortex A7/A9 cores).

This allows to boot firmwares from any location with just using
bootaux, e.g.:
tftp ${loadaddr} hello_world.elf && bootaux ${loadaddr}

Questions:
1. I really doubt that hardcoding the memory map for
Cortex-A7/Cortex-M4 is a good idea. Does it make sense to move this
table to -u-boot.dtsi instead?
2. How does similar "firmware loading" work is done on iMX8/iMX8M,
where U-boot is used only as non-secure bootloader.
I assume that this is responsibility of TF-A, who does all Cortex-M
initialization and firmware "deploying"?

Signed-off-by: Igor Opaniuk 
Signed-off-by: Stefan Agner 
---

 arch/arm/include/asm/mach-imx/sys_proto.h |  6 ++
 arch/arm/mach-imx/imx_bootaux.c   | 84 +--
 arch/arm/mach-imx/mx7/soc.c   | 26 +++
 3 files changed, 112 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 1e627c8fc3..fa05fda716 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -104,6 +104,12 @@ void gpr_init(void);
 
 #endif /* CONFIG_MX6 */
 
+struct memorymap {
+   unsigned long auxcore;
+   unsigned long host;
+   unsigned long size;
+};
+
 u32 get_nr_cpus(void);
 u32 get_cpu_rev(void);
 u32 get_cpu_speed_grade_hz(void);
diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c
index 3d9422d5a2..91d9272c51 100644
--- a/arch/arm/mach-imx/imx_bootaux.c
+++ b/arch/arm/mach-imx/imx_bootaux.c
@@ -7,18 +7,91 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-int arch_auxiliary_core_up(u32 core_id, ulong boot_private_data)
+const __weak struct memorymap hostmap[] = { };
+
+static const struct memorymap *get_host_mapping(unsigned long auxcore)
+{
+   const struct memorymap *mmap = hostmap;
+
+   while (mmap) {
+   if (mmap->auxcore <= auxcore &&
+   mmap->auxcore + mmap->size > auxcore)
+   return mmap;
+   mmap++;
+   }
+
+   return NULL;
+}
+
+/*
+ * A very simple elf loader, assumes the image is valid, returns the
+ * entry point address.
+ */
+static unsigned long load_elf_image_phdr(unsigned long addr)
+{
+   Elf32_Ehdr *ehdr; /* Elf header structure pointer */
+   Elf32_Phdr *phdr; /* Program header structure pointer */
+   int i;
+
+   ehdr = (Elf32_Ehdr *)addr;
+   phdr = (Elf32_Phdr *)(addr + ehdr->e_phoff);
+
+   /* Load each program header */
+   for (i = 0; i < ehdr->e_phnum; ++i, ++phdr) {
+   const struct memorymap *mmap = get_host_mapping(phdr->p_paddr);
+   void *dst, *src;
+
+   if (phdr->p_type != PT_LOAD)
+   continue;
+
+   if (!mmap) {
+   printf("Invalid aux core address: %08x",
+   phdr->p_paddr);
+   return 0;
+   }
+
+   dst = (void *)(phdr->p_paddr - mmap->auxcore) + mmap->host;
+   src = (void *)addr + phdr->p_offset;
+   debug("Loading phdr %i to 0x%p (%i bytes)\n",
+ i, dst, phdr->p_filesz);
+   if (phdr->p_filesz)
+   memcpy(dst, src, phdr->p_filesz);
+   if (phdr->p_filesz != phdr->p_memsz)
+   memset(dst + phdr->p_filesz, 0x00,
+  phdr->p_memsz - phdr->p_filesz);
+   flush_cache((unsigned long)dst & ~(CONFIG_SYS_CACHELINE_SIZE-1),
+   ALIGN(phdr->p_filesz, CONFIG_SYS_CACHELINE_SIZE));
+   }
+
+   return ehdr->e_entry;
+}
+
+int arch_auxiliary_core_up(u32 core_id, ulong addr)
 {
ulong stack, pc;
 
-   if (!boot_private_data)
+   if (!addr)
return -EINVAL;
 
-   stack = *(u32 *)boot_private_data;
-   pc = *(u32 *)(boot_private_data + 4);
+   if (valid_elf_image(addr)) {
+   stack = 0x0;
+   pc = load_elf_image_phdr(addr);
+   if (!pc)
+   return CMD_RET_FAILURE;
+
+   } else {
+   /*
+* Assume binary file with vector table at the beginning.
+* Cortex-M4 vector tables start with the stack pointer (SP)
+* and reset vector (initial PC).
+*/
+   stack = *(u32 *)addr;
+   pc = *(u32 *)(addr 

Re: [U-Boot] [PATCH] stm32mp1: configs: fix checking the presence of an environment

[Patrick DELAUNAY]

Hi Bartosz

> From: Bartosz Biłas 
> Sent: dimanche 3 novembre 2019 13:39
> 
> Hello Patrick,
> 
> On 11/3/19 11:15 AM, Bartosz Biłas wrote:
> > Hello Patrick,
> >
> > sorry for the late answer but I'll try to explain you my issue.
> >
> > On 10/29/19 9:38 AM, Patrick DELAUNAY wrote:
> >
> > Hi Bartosz,
> >
> > Please ad get maintainers or tools/patman to sent patch for stm32mp1 
> > platform.
> >
> > Ok, I'll remember about that.
> >
> >
> >
> >
> >
> > From: U-Boot
> >  On
> > Behalf Of Bartosz Bilas
> > Sent: dimanche 27 octobre 2019 15:46
> > To: u-boot@lists.denx.de
> > Subject: [U-Boot] [PATCH] stm32mp1: configs: fix checking the presence
> > of an environment
> >
> > Execute env check command within extra env settings section instead of
> > bootcmd whereby we are able to mount rootfs partition from sd card properly.
> >
> > Signed-off-by: Bartosz Bilas
> > 
> > ---
> >   include/configs/stm32mp1.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
> > index 988992b336..cadc0358fd 100644
> > --- a/include/configs/stm32mp1.h
> > +++ b/include/configs/stm32mp1.h
> > @@ -115,7 +115,6 @@
> >  "if test ${boot_device} = serial || test ${boot_device} = usb;" \
> >  "then stm32prog ${boot_device} ${boot_instance}; " \
> >  "else " \
> > -   "run env_check;" \
> >  "if test ${boot_device} = mmc;" \
> >  "then env set boot_targets \"mmc${boot_instance}\"; fi;" \
> >  "if test ${boot_device} = nand;" \ @@ -160,6 +159,7
> > @@
> >  "initrd_high=0x\0" \
> >  "altbootcmd=run bootcmd\0" \
> >  "env_default=1\0" \
> > +   "run env_check;" \
> >
> >
> >
> > It is not a correct place, this define CONFIG_EXTRA_ENV_SETTINGS only the
> default environment (only set env variable).
> > Only "bootcmd"  or "preboot" is really executed, this command will be never
> executed here.
> >
> >
> >
> >  "env_check=if test $env_default -eq 1;"\
> >  " then env set env_default 0;env save;fi\0" \
> >  STM32MP_BOOTCMD \
> > --
> >
> >
> >
> > Can you explain you issue and the board used.
> >
> > The problem which I've encountered is that I'm not able to boot my rootfs
> partition properly using the latest U-Boot version (2019.10) using 
> stm32mp157c-
> dk2 board (I've been getting kernel panic because it wasn't able to mount 
> partition).
> On the previous version (2019.07) there is no any problems with that. I've 
> used git
> bisect to check which commit causes the problem and it turned out that the
> problem is with commit 22bed7ee4988aadfaef0c0da9746bf8541549ed4.
> >
> >
> >
> > I think your patch only mask the issue, as environment is not saved, U-Boot
> never write in EXT4 file system.
> > You should have again the issue if you execute manually by the command "env
> save".
> >
> > Hmm, it makes sense.
> >
> >
> >
> > Today I have no issue on my side with environment in ext4 file system
> > (generated by donwstrean yocto); the requests done by U-Boot are acceptable 
> > if
> the ext4 file system is generated with only the features supported by U-Boot.
> >
> > I use buildroot and if you wanna you can build and check that image 
> > yourself.
> Here is a link to guide
> https://github.com/buildroot/buildroot/tree/master/board/stmicroelectronics/stm32m
> p157c-dk2 but remember to comment this line ->
> BR2_GLOBAL_PATCH_DIR="board/stmicroelectronics/stm32mp157c-
> dk2/patches" in stm32mp157c_dk2_defconfig file to disable my faulty patch.
> >
> >
> >
> > But we solved issue with latest ext4 tools; since e2fsprogs 1.43 at least, 
> > we have
> ascendance incompatibility as new enable features are enable by default =
> metadata_csum and dir_index.
> >
> > We remove them with the mkfs.ext4 option: -O ^metadata_csum,^dir_index
> >
> > Example : mkfs.ext4 -L rootfs -O ^metadata_csum,^dir_index /dev/sdb4
> >
> > I'll check that and let you know about the results.
> 
> I've prepared sd card with disabled those options and it works well. I think 
> we can
> reject that patch then.

Thanks for the feedback, 

Patch rejected :-)

> 
> 
> Best
> Bartek
> >
> >
> >
> > For details of restriction, see commit 10a7a1b8 : update with hash tree 
> > directory
> of EXT4 not support by U-Boot (EXT4_INDEX_FL)
> >
> > Thanks
> >
> >
> >

Regards 
Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCHv2 0/4] support remote system update on Intel Stratix10 SoC

[Richard Gong]

Hi Simon,

Thanks for your comments!

On 11/4/19 3:03 PM, Simon Goldschmidt wrote:

Am 30.10.2019 um 21:34 schrieb richard.g...@linux.intel.com:

From: Richard Gong 

This is 2nd submission of Intel Remote System Update patches.


Ok, so what has changed since v1? You'd normally add a changelog 
(ideally to both this cover-letter and to each patch). Have a look at 
patman in tools/patman, that allows you to create those changelogs more 
easily.

Sorry I missed that. I will add change details in the next submissions.


The Intel Remote System Update (RSU) provides a way for users to update
the QSPI configuration bitstream of a Intel Stratix10 SoC device with
significantly reduced risk of corrupting the bitstream storage and
bricking the system.

The patchset adds RSU support which allows user to perform a complete set
of RSU operations via provided console commands.

The patches have reviewed by other colleagues at Intel.

Richard Gong (4):
   arm: socfpga: stratix10: add RSU mailbox support
   drivers: firmware: add RSU support for Stratix10 SoC
   dirvers: firmware: add console commands for RSU support
   arm: socfpga: stratix10: add environment variables for RSU support

  arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   36 +-
  arch/arm/mach-socfpga/mailbox_s10.c  |   79 ++


Do you have plans to move this code to drivers/mailbox?


Yes, will do after RSU upstream.


  arch/arm/mach-socfpga/misc_s10.c |    9 +
  drivers/firmware/Kconfig |   11 +
  drivers/firmware/Makefile    |    1 +
  drivers/firmware/rsu.c   |  662 ++
  drivers/firmware/rsu_ll_qspi.c   | 1050 
++
  drivers/firmware/rsu_misc.c  |  817 
+
  drivers/firmware/rsu_s10.c   |  874 
++


Ok, so you started to add this "RSU" as a driver, that's probably fine 
(sorry I did not find the time to review that, yet).


However, I think you'd need a more specific name, probably including 
'intel' or something to make this more clear.


How about intel_rsu.c, intel_rsu_misc.c, intel_rsu_ll_qspi.c and 
intel_rsu_s10.c?



I'll hope to find the time to review the rest this week.

Regards,
Simon


  include/intel/rsu.h  |  291 ++
  include/intel/rsu_ll.h   |   72 ++
  include/intel/rsu_misc.h |   60 ++
  include/intel/rsu_s10.h  |   46 +
  13 files changed, 3998 insertions(+), 10 deletions(-)
  create mode 100644 drivers/firmware/rsu.c
  create mode 100644 drivers/firmware/rsu_ll_qspi.c
  create mode 100644 drivers/firmware/rsu_misc.c
  create mode 100644 drivers/firmware/rsu_s10.c
  create mode 100644 include/intel/rsu.h
  create mode 100644 include/intel/rsu_ll.h
  create mode 100644 include/intel/rsu_misc.h
  create mode 100644 include/intel/rsu_s10.h




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 0/2] Add board support for iMX8QXP AI_ML board

[Manivannan Sadhasivam]

Hi,

On Sun, Nov 03, 2019 at 04:29:49PM +0100, Stefano Babic wrote:
> On 21/10/19 13:00, Manivannan Sadhasivam wrote:
> > Hi,
> > 
> > On Thu, Aug 15, 2019 at 01:57:23PM +0530, Manivannan Sadhasivam wrote:
> >> Hello,
> >>
> >> This patchset adds initial board support for iMX8QXP AI_ML board
> >> from Einfochips. This board is one of the Consumer Edition and AI
> >> boards of the 96Boards family.
> >>
> >> This initial supports contains following peripherals which are tested and
> >> known to work:
> >>
> >> 1. Debug serial via UART2
> >> 2. SD card
> >> 3. Ethernet
> >>
> >> Below is the boot log from SPL to Linux kernel:
> >> ===
> >>
> >> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> >> Loading Environment from MMC... *** Warning - bad CRC, using default 
> >> environment
> >>
> >> In:serial@5a08
> >> Out:   serial@5a08
> >> Err:   serial@5a08
> >> Net:   
> >> Warning: ethernet@5b04 (eth0) using random MAC address - 
> >> d2:46:66:cf:f5:61
> >> eth0: ethernet@5b04
> >> Hit any key to stop autoboot:  0 
> >> switch to partitions #0, OK
> >> mmc1 is current device
> >> Scanning mmc 1:1...
> >> Found /extlinux/extlinux.conf
> >> Retrieving file: /extlinux/extlinux.conf
> >> 171 bytes read in 14 ms (11.7 KiB/s)
> >> 1:  ai_ml-kernel
> >> Retrieving file: /Image
> >> 24689152 bytes read in 1055 ms (22.3 MiB/s)
> >> append: earlycon console=ttyLP2,115200 rw root=/dev/mmcblk0p2 
> >> rootfstype=ext4 init=/sbin/t
> >> Retrieving file: /imx8qxp-ai_ml.dtb
> >> 12529 bytes read in 13 ms (940.4 KiB/s)
> >> ## Flattened Device Tree blob at 8300
> >>Booting using the fdt blob at 0x8300
> >>Using Device Tree in place at 8300, end 830060f0
> >>
> >> Starting kernel ...
> >>
> >> [0.00] Booting Linux on physical CPU 0x00 [0x410fd042]
> >> [0.00] Linux version 5.2.0-03138-gd75da80dce39 
> >> (mani@Mani-XPS-13-9360) (gcc versi9
> >> [0.00] Machine model: Einfochips i.MX8QXP AI_ML
> >> [0.00] efi: Getting EFI parameters from FDT:
> >> [0.00] efi: UEFI not found.
> >> [0.00] cma: Reserved 32 MiB at 0xfe00
> >> [0.00] earlycon: lpuart32 at MMIO 0x5a08 (options '')
> >> [0.00] printk: bootconsole [lpuart32] enabled
> >>
> >> Thanks,
> >> Mani
> >>
> > 
> > Any update on this patchset?
> 
> Sorry for delay. Anyway, I have applied the patch, but due to changes in
> other subsystems (environment, etc.) it is not built clean. Could you
> rebase and resend ? Thanks
> 

So you want me to just resend the board support patch? (Saw that you applied
DT patch)

Thanks,
Mani

> Best regards,
> Stefano
> 
> > 
> > Thanks,
> > Mani
> > 
> >> Note: This patchset depends on the below cleanup patches submitted:
> >> [U-Boot,1/2] arm: imx8: factor out uart init code
> >> [U-Boot,2/2] arm: imx8: don't duplicate build_info()
> >>
> >> Changes in v5:
> >>
> >> * Incorporated review comments from Lukasz.
> >>
> >> Changes in v4:
> >>
> >> * Incorporated review comments from Fabio.
> >>
> >> Changes in v3:
> >>
> >> * Incorporated review comments from Fabio. Major change is switching to
> >>   distro_boot.
> >> * Added Reviewed-by tag from Peng Fan.
> >>
> >> Changes in v2:
> >>
> >> * Rebased the patches on top of following patches:
> >>   [U-Boot,1/2] arm: imx8: factor out uart init code
> >>   [U-Boot,2/2] arm: imx8: don't duplicate build_info()
> >>
> >> Manivannan Sadhasivam (2):
> >>   arm: dts: Add devicetree support for iMXQXP AI_ML board
> >>   board: Add support for iMX8QXP AI_ML board
> >>
> >>  arch/arm/dts/Makefile |   1 +
> >>  arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi| 117 +++
> >>  arch/arm/dts/fsl-imx8qxp-ai_ml.dts| 181 ++
> >>  arch/arm/mach-imx/imx8/Kconfig|   6 +
> >>  board/einfochips/imx8qxp_ai_ml/Kconfig|  21 ++
> >>  board/einfochips/imx8qxp_ai_ml/MAINTAINERS|   6 +
> >>  board/einfochips/imx8qxp_ai_ml/Makefile   |   8 +
> >>  board/einfochips/imx8qxp_ai_ml/README |  49 +
> >>  .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c  |  79 
> >>  board/einfochips/imx8qxp_ai_ml/imximage.cfg   |  24 +++
> >>  board/einfochips/imx8qxp_ai_ml/spl.c  |  39 
> >>  configs/imx8qxp_ai_ml_defconfig   |  83 
> >>  include/configs/imx8qxp_ai_ml.h   |  95 +
> >>  13 files changed, 709 insertions(+)
> >>  create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
> >>  create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml.dts
> >>  create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig
> >>  create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS
> >>  create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile
> >>  create mode 100644 board/einfochips/imx8qxp_ai_ml/README
> >>  create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c
> >>  create mode 100644 board/einfochips/im

Re: [U-Boot] [PATCH v2 2/4] dm: board: complete the initialization of the muxes in initr_dm()

[Jean-Jacques Hiblot]

On 05/11/2019 14:05, Vignesh Raghavendra wrote:

Hi JJ,

On 05/11/19 5:20 PM, Jean-Jacques Hiblot wrote:

This will probe the multiplexer devices that have a "u-boot,mux-autoprobe"
property. As a consequence they will be put in their idle state.

Signed-off-by: Jean-Jacques Hiblot 

---

[...]

diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
index 6aaf4dc964..71392e9e50 100644
--- a/drivers/mux/mux-uclass.c
+++ b/drivers/mux/mux-uclass.c
@@ -262,6 +262,28 @@ int mux_uclass_post_probe(struct udevice *dev)
return 0;
  }
  
+void dm_mux_init(void)

+{
+   struct uclass *uc;
+   struct udevice *dev;
+   int ret;
+
+   ret = uclass_get(UCLASS_MUX, &uc);
+   if (ret < 0) {
+   debug("unable to get MUX uclass\n");
+   return;
+   }
+   uclass_foreach_dev(dev, uc) {
+   if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
+   ret = device_probe(dev);
+   if (ret)
+   debug("unable to probe device %s\n", dev->name);
+   } else {
+   printf("not found for dev %s\n", dev->name);
+   }

Is "u-boot,mux-autoprobe" a required property? The fact that its in DT
makes me think its optional. If that's the case, above printf() should
be reduced to debug() to avoid confusion


Thanks Vignesh. It was for debug and forgot to remove it.





+   }
+}
+
  UCLASS_DRIVER(mux) = {
.id = UCLASS_MUX,
.name   = "mux",
diff --git a/include/mux.h b/include/mux.h
index 060f71a47c..2467723951 100644
--- a/include/mux.h
+++ b/include/mux.h
@@ -75,6 +75,8 @@ void mux_control_put(struct mux_control *mux);
  
  struct mux_control *devm_mux_control_get(struct udevice *dev,

 const char *mux_name);
+void dm_mux_init(void);
+
  #else
  unsigned int mux_control_states(struct mux_control *mux)
  {


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] gpio: fix CONFIG_IS_ENABLED(DM_GPIO) for SPL

[Stefan Roese]

Hi Baruch,

On 03.11.19 10:52, Baruch Siach wrote:

There is currently no CONFIG_SPL_DM_GPIO, so CONFIG_IS_ENABLED(DM_GPIO)
is always false. As a result the sdhci driver can not use the DM gpio
API to read the card-detect signal in SPL. This breaks boot from SD card
on the SolidRun Clearfog platform since commit da18c62b6e ("mmc: sdhci:
Implement SDHCI card detect") that added sdhci_get_cd().

Add a blind CONFIG_SPL_DM_GPIO symbol that is enabled iff CONFIG_DM_GPIO
is. That makes CONFIG_IS_ENABLED(DM_GPIO) correct for SPL code.

Signed-off-by: Baruch Siach 
---
  drivers/gpio/Kconfig | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c1ad5d64a35c..9bac341c5ed5 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -14,6 +14,11 @@ config DM_GPIO
  particular GPIOs that they provide. The uclass interface
  is defined in include/asm-generic/gpio.h.
  
+config SPL_DM_GPIO

+   bool
+   depends on DM_GPIO
+   default y
+
  config GPIO_HOG
bool "Enable GPIO hog support"
depends on DM_GPIO



I think its preferred to disable such SPL configurations per default
to not increase the code size here - which is pretty crucial on some
boards. Better to enable this SPL_DM_GPIO on your target or if it
makes sense on your platform (MVEBU perhaps with a select or imply
via the MMC driver in Kconfig).

What do you think?

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] arm: mvebu: clearfog: fix boot from SD card

[Stefan Roese]

Hi Baruch,

On 03.11.19 10:52, Baruch Siach wrote:

Enable gpio0 in SPL to allow the sdhci driver read the SD card-detect
signal.

Signed-off-by: Baruch Siach 
---
  arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi 
b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
index cf6c08881b18..38e4f3d99ac9 100644
--- a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
+++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
@@ -12,6 +12,10 @@
u-boot,dm-spl;
  };
  
+&gpio0 {

+   u-boot,dm-spl;
+};
+
  &ahci0 {
u-boot,dm-spl;
  };



Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 0/2] Add board support for iMX8QXP AI_ML board

[Stefano Babic]

Hi,


On 05/11/19 16:12, Manivannan Sadhasivam wrote:
> Hi,
> 
> On Sun, Nov 03, 2019 at 04:29:49PM +0100, Stefano Babic wrote:
>> On 21/10/19 13:00, Manivannan Sadhasivam wrote:
>>> Hi,
>>>
>>> On Thu, Aug 15, 2019 at 01:57:23PM +0530, Manivannan Sadhasivam wrote:
 Hello,

 This patchset adds initial board support for iMX8QXP AI_ML board
 from Einfochips. This board is one of the Consumer Edition and AI
 boards of the 96Boards family.

 This initial supports contains following peripherals which are tested and
 known to work:

 1. Debug serial via UART2
 2. SD card
 3. Ethernet

 Below is the boot log from SPL to Linux kernel:
 ===

 MMC:   FSL_SDHC: 0, FSL_SDHC: 1
 Loading Environment from MMC... *** Warning - bad CRC, using default 
 environment

 In:serial@5a08
 Out:   serial@5a08
 Err:   serial@5a08
 Net:   
 Warning: ethernet@5b04 (eth0) using random MAC address - 
 d2:46:66:cf:f5:61
 eth0: ethernet@5b04
 Hit any key to stop autoboot:  0 
 switch to partitions #0, OK
 mmc1 is current device
 Scanning mmc 1:1...
 Found /extlinux/extlinux.conf
 Retrieving file: /extlinux/extlinux.conf
 171 bytes read in 14 ms (11.7 KiB/s)
 1:  ai_ml-kernel
 Retrieving file: /Image
 24689152 bytes read in 1055 ms (22.3 MiB/s)
 append: earlycon console=ttyLP2,115200 rw root=/dev/mmcblk0p2 
 rootfstype=ext4 init=/sbin/t
 Retrieving file: /imx8qxp-ai_ml.dtb
 12529 bytes read in 13 ms (940.4 KiB/s)
 ## Flattened Device Tree blob at 8300
Booting using the fdt blob at 0x8300
Using Device Tree in place at 8300, end 830060f0

 Starting kernel ...

 [0.00] Booting Linux on physical CPU 0x00 [0x410fd042]
 [0.00] Linux version 5.2.0-03138-gd75da80dce39 
 (mani@Mani-XPS-13-9360) (gcc versi9
 [0.00] Machine model: Einfochips i.MX8QXP AI_ML
 [0.00] efi: Getting EFI parameters from FDT:
 [0.00] efi: UEFI not found.
 [0.00] cma: Reserved 32 MiB at 0xfe00
 [0.00] earlycon: lpuart32 at MMIO 0x5a08 (options '')
 [0.00] printk: bootconsole [lpuart32] enabled

 Thanks,
 Mani

>>>
>>> Any update on this patchset?
>>
>> Sorry for delay. Anyway, I have applied the patch, but due to changes in
>> other subsystems (environment, etc.) it is not built clean. Could you
>> rebase and resend ? Thanks
>>
> 
> So you want me to just resend the board support patch? (Saw that you applied
> DT patch)

Yes.

Regards,
Stefano

> 
> Thanks,
> Mani
> 
>> Best regards,
>> Stefano
>>
>>>
>>> Thanks,
>>> Mani
>>>
 Note: This patchset depends on the below cleanup patches submitted:
 [U-Boot,1/2] arm: imx8: factor out uart init code
 [U-Boot,2/2] arm: imx8: don't duplicate build_info()

 Changes in v5:

 * Incorporated review comments from Lukasz.

 Changes in v4:

 * Incorporated review comments from Fabio.

 Changes in v3:

 * Incorporated review comments from Fabio. Major change is switching to
   distro_boot.
 * Added Reviewed-by tag from Peng Fan.

 Changes in v2:

 * Rebased the patches on top of following patches:
   [U-Boot,1/2] arm: imx8: factor out uart init code
   [U-Boot,2/2] arm: imx8: don't duplicate build_info()

 Manivannan Sadhasivam (2):
   arm: dts: Add devicetree support for iMXQXP AI_ML board
   board: Add support for iMX8QXP AI_ML board

  arch/arm/dts/Makefile |   1 +
  arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi| 117 +++
  arch/arm/dts/fsl-imx8qxp-ai_ml.dts| 181 ++
  arch/arm/mach-imx/imx8/Kconfig|   6 +
  board/einfochips/imx8qxp_ai_ml/Kconfig|  21 ++
  board/einfochips/imx8qxp_ai_ml/MAINTAINERS|   6 +
  board/einfochips/imx8qxp_ai_ml/Makefile   |   8 +
  board/einfochips/imx8qxp_ai_ml/README |  49 +
  .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c  |  79 
  board/einfochips/imx8qxp_ai_ml/imximage.cfg   |  24 +++
  board/einfochips/imx8qxp_ai_ml/spl.c  |  39 
  configs/imx8qxp_ai_ml_defconfig   |  83 
  include/configs/imx8qxp_ai_ml.h   |  95 +
  13 files changed, 709 insertions(+)
  create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi
  create mode 100644 arch/arm/dts/fsl-imx8qxp-ai_ml.dts
  create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig
  create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS
  create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile
  create mode 100644 board/einfochips/imx8qxp_ai_ml/README
  create mo

[U-Boot] [RFC PATCH] dm: core: Remove libfdt dependency when unnecessary

[Walter Lozano]

The support of libfdt should only be needed when OF_CONTROL
is enabled and OF_PLATDATA is not, as in other cases there is no
DT file to query.

This patch fixes this dependency allowing to save some space.

Signed-off-by: Walter Lozano 
---
 drivers/core/ofnode.c | 132 +--
 include/dm/read.h | 141 ++
 2 files changed, 267 insertions(+), 6 deletions(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 8f0eab2ca6..524d763379 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -23,11 +23,14 @@ int ofnode_read_u32(ofnode node, const char *propname, u32 
*outp)
if (ofnode_is_np(node)) {
return of_read_u32(ofnode_to_np(node), propname, outp);
} else {
-   const fdt32_t *cell;
+   const fdt32_t *cell = NULL;
int len;
 
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
cell = fdt_getprop(gd->fdt_blob, ofnode_to_offset(node),
   propname, &len);
+#endif
+
if (!cell || len < sizeof(int)) {
debug("(not found)\n");
return -EINVAL;
@@ -57,7 +60,7 @@ int ofnode_read_s32_default(ofnode node, const char 
*propname, s32 def)
 
 int ofnode_read_u64(ofnode node, const char *propname, u64 *outp)
 {
-   const unaligned_fdt64_t *cell;
+   const unaligned_fdt64_t *cell = NULL;
int len;
 
assert(ofnode_valid(node));
@@ -66,8 +69,10 @@ int ofnode_read_u64(ofnode node, const char *propname, u64 
*outp)
if (ofnode_is_np(node))
return of_read_u64(ofnode_to_np(node), propname, outp);
 
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
cell = fdt_getprop(gd->fdt_blob, ofnode_to_offset(node), propname,
   &len);
+#endif
if (!cell || len < sizeof(*cell)) {
debug("(not found)\n");
return -EINVAL;
@@ -118,8 +123,10 @@ const char *ofnode_read_string(ofnode node, const char 
*propname)
len = prop->length;
}
} else {
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
str = fdt_getprop(gd->fdt_blob, ofnode_to_offset(node),
  propname, &len);
+#endif
}
if (!str) {
debug("\n");
@@ -150,8 +157,11 @@ ofnode ofnode_find_subnode(ofnode node, const char 
*subnode_name)
}
subnode = np_to_ofnode(np);
} else {
-   int ooffset = fdt_subnode_offset(gd->fdt_blob,
+   int ooffset = -FDT_ERR_NOTFOUND;
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
+   ooffset = fdt_subnode_offset(gd->fdt_blob,
ofnode_to_offset(node), subnode_name);
+#endif
subnode = offset_to_ofnode(ooffset);
}
debug("%s\n", ofnode_valid(subnode) ?
@@ -170,9 +180,13 @@ int ofnode_read_u32_array(ofnode node, const char 
*propname,
return of_read_u32_array(ofnode_to_np(node), propname,
 out_values, sz);
} else {
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
return fdtdec_get_int_array(gd->fdt_blob,
ofnode_to_offset(node), propname,
out_values, sz);
+#else
+   return -FDT_ERR_NOTFOUND;
+#endif
}
 }
 
@@ -182,8 +196,12 @@ ofnode ofnode_first_subnode(ofnode node)
if (ofnode_is_np(node))
return np_to_ofnode(node.np->child);
 
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
return offset_to_ofnode(
fdt_first_subnode(gd->fdt_blob, ofnode_to_offset(node)));
+#else
+   return offset_to_ofnode(-FDT_ERR_NOTFOUND);
+#endif
 }
 
 ofnode ofnode_next_subnode(ofnode node)
@@ -192,8 +210,12 @@ ofnode ofnode_next_subnode(ofnode node)
if (ofnode_is_np(node))
return np_to_ofnode(node.np->sibling);
 
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
return offset_to_ofnode(
fdt_next_subnode(gd->fdt_blob, ofnode_to_offset(node)));
+#else
+   return offset_to_ofnode(-FDT_ERR_NOTFOUND);
+#endif
 }
 
 ofnode ofnode_get_parent(ofnode node)
@@ -204,9 +226,12 @@ ofnode ofnode_get_parent(ofnode node)
if (ofnode_is_np(node))
parent = np_to_ofnode(of_get_parent(ofnode_to_np(node)));
else
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
parent.of_offset = fdt_parent_offset(gd->fdt_blob,
 ofnode_to_offset(node));
-
+#else
+   parent.of_offset = -FDT_ERR_NOTFOUND;
+#endif
return parent;

[U-Boot] [PATCH] board: Add support for iMX8QXP AI_ML board

[Manivannan Sadhasivam]

This commit adds initial board support for iMX8QXP AI_ML board from
Einfochips. This board is one of the 96Boards Consumer Edition and AI
boards of the 96Boards family based on i.MX8QXP SoC from NXP/Freescale.

This initial supports contains following peripherals which are tested and
known to work:

1. Debug serial via UART2
2. SD card
3. Ethernet

More information about this board can be found in arrow website:
https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools

Signed-off-by: Manivannan Sadhasivam 
Reviewed-by: Peng Fan 
---
 arch/arm/mach-imx/imx8/Kconfig|  6 ++
 board/einfochips/imx8qxp_ai_ml/Kconfig| 21 
 board/einfochips/imx8qxp_ai_ml/MAINTAINERS|  6 ++
 board/einfochips/imx8qxp_ai_ml/Makefile   |  8 ++
 board/einfochips/imx8qxp_ai_ml/README | 49 ++
 .../einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c  | 78 +++
 board/einfochips/imx8qxp_ai_ml/imximage.cfg   | 24 +
 board/einfochips/imx8qxp_ai_ml/spl.c  | 39 
 configs/imx8qxp_ai_ml_defconfig   | 83 
 include/configs/imx8qxp_ai_ml.h   | 95 +++
 10 files changed, 409 insertions(+)
 create mode 100644 board/einfochips/imx8qxp_ai_ml/Kconfig
 create mode 100644 board/einfochips/imx8qxp_ai_ml/MAINTAINERS
 create mode 100644 board/einfochips/imx8qxp_ai_ml/Makefile
 create mode 100644 board/einfochips/imx8qxp_ai_ml/README
 create mode 100644 board/einfochips/imx8qxp_ai_ml/imx8qxp_ai_ml.c
 create mode 100644 board/einfochips/imx8qxp_ai_ml/imximage.cfg
 create mode 100644 board/einfochips/imx8qxp_ai_ml/spl.c
 create mode 100644 configs/imx8qxp_ai_ml_defconfig
 create mode 100644 include/configs/imx8qxp_ai_ml.h

diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index cdb78afacf..25fe4e2be0 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -55,6 +55,11 @@ config TARGET_COLIBRI_IMX8X
select BOARD_LATE_INIT
select IMX8QXP
 
+config TARGET_IMX8QXP_AI_ML
+   bool "Support i.MX8QXP AI_ML board"
+   select BOARD_EARLY_INIT_F
+   select IMX8QXP
+
 config TARGET_IMX8QM_MEK
bool "Support i.MX8QM MEK board"
select BOARD_LATE_INIT
@@ -73,6 +78,7 @@ config TARGET_IMX8QXP_MEK
 
 endchoice
 
+source "board/einfochips/imx8qxp_ai_ml/Kconfig"
 source "board/freescale/imx8qm_mek/Kconfig"
 source "board/freescale/imx8qxp_mek/Kconfig"
 source "board/advantech/imx8qm_rom7720_a1/Kconfig"
diff --git a/board/einfochips/imx8qxp_ai_ml/Kconfig 
b/board/einfochips/imx8qxp_ai_ml/Kconfig
new file mode 100644
index 00..b6806b8859
--- /dev/null
+++ b/board/einfochips/imx8qxp_ai_ml/Kconfig
@@ -0,0 +1,21 @@
+if TARGET_IMX8QXP_AI_ML
+
+config SYS_BOARD
+   default "imx8qxp_ai_ml"
+
+config SYS_VENDOR
+   default "einfochips"
+
+config SYS_CONFIG_NAME
+   default "imx8qxp_ai_ml"
+
+config SYS_MALLOC_LEN
+   default 0x240
+
+config ENV_SIZE
+   default 0x1000
+
+config ENV_OFFSET
+   default 0x40
+
+endif
diff --git a/board/einfochips/imx8qxp_ai_ml/MAINTAINERS 
b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS
new file mode 100644
index 00..add0bd9431
--- /dev/null
+++ b/board/einfochips/imx8qxp_ai_ml/MAINTAINERS
@@ -0,0 +1,6 @@
+i.MX8QXP AI_ML BOARD
+M: Manivannan Sadhasivam 
+S: Maintained
+F: board/einfochips/imx8qxp_ai_ml/
+F: include/configs/imx8qxp_ai_ml.h
+F: configs/imx8qxp_ai_ml_defconfig
diff --git a/board/einfochips/imx8qxp_ai_ml/Makefile 
b/board/einfochips/imx8qxp_ai_ml/Makefile
new file mode 100644
index 00..e08774dc6e
--- /dev/null
+++ b/board/einfochips/imx8qxp_ai_ml/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright 2019 Linaro Ltd.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += imx8qxp_ai_ml.o
+obj-$(CONFIG_SPL_BUILD) += spl.o
diff --git a/board/einfochips/imx8qxp_ai_ml/README 
b/board/einfochips/imx8qxp_ai_ml/README
new file mode 100644
index 00..488920580f
--- /dev/null
+++ b/board/einfochips/imx8qxp_ai_ml/README
@@ -0,0 +1,49 @@
+U-Boot for the Einfochips i.MX8QXP AI_ML board
+
+Quick Start
+===
+
+- Get and Build the ARM Trusted firmware
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Flash the binary into the SD card
+- Boot
+
+Get and Build the ARM Trusted firmware
+==
+
+$ git clone https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf/
+$ git checkout origin/imx_4.9.88_imx8qxp_beta2 -b imx_4.9.88_imx8qxp_beta2
+$ make PLAT=imx8qxp bl31
+
+Get scfw_tcm.bin and ahab-container.img
+===
+
+$ wget 
https://raw.githubusercontent.com/96boards-ai-ml/binaries/master/mx8qx-aiml-scfw-tcm.bin
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.1.bin
+$ chmod +x firmware-imx-8.1.bin
+$ ./firmware-imx-8.1.bin
+
+Copy the following binaries to U-Boot folder:
+
+$ cp imx-atf/build/imx8qxp/release/bl31.bin .
+$ cp firmware-imx-8.1/firmware/seco

Re: [U-Boot] [RFC/RFT U-Boot PATCH] image: Add Image.gz parsing support in booti.

[Atish Patra]

On Mon, 2019-11-04 at 17:35 -0500, Tom Rini wrote:
> On Mon, Nov 04, 2019 at 10:20:33PM +, Atish Patra wrote:
> > On Fri, 2019-11-01 at 09:29 -0400, Tom Rini wrote:
> > > On Thu, Oct 10, 2019 at 02:23:17PM -0700, Atish Patra wrote:
> > > 
> > > > Add gz parsing logic so that booti can parse both Image
> > > > and Image.gz to boot Linux. Currently, it is difficult to
> > > > calculate
> > > > a safe address for every board where the Image.gz can be
> > > > decompressed.
> > > > It is also not possible to figure out the size of the
> > > > compressed
> > > > file
> > > > as well. Thus, user need to set two additional environment
> > > > variables
> > > > kernel_gz_addr_r and kernel_gz_size to make Image.gz work.
> > > > 
> > > > Tested on HiFive Unleashed and Qemu for RISC-V.
> > > > 
> > > > Signed-off-by: Atish Patra 
> > > > ---
> > > > I could not test this patch on any ARM64 devices due to lack of
> > > > access to any ARM64 board. If anybody can test it on ARM64,
> > > > that
> > > > would be great.
> 
> Oh, I missed this part before.  You should be able to get fairly far
> with qemu :)
> 
I did verify with qemu. I was requesting some tested-by on ARM64
hardware. Sorry for the confusion. I will update the commit text in
next version.

> > > Can we do the compression check more generally?  I'd like to be
> > > able
> > > to
> > > see Image.xz/lz4/etc be able to be handled cleanly.
> > 
> > This patch is intended only handle Image.gz which is a compressed
> > version of kernel "Image" file. That's why relevant code is only
> > added
> > to booti command.
> 
> Right.  But the linux kernel will happily spit out a handful of other
> compressed Image files on arm64.  I see riscv is only .gz today, but
> I
> want to be able to handle whatever the compression is, so long as we
> have it available.
> 

Ahh I misunderstood that part. I could not find any existing code to
detect to different compression formats.

If I have not missed anything, I can add that code in common/image.c
and use that function in booti.c.

-- 
Regards,
Atish
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: sys_proto: Fixing function imx6_is_bmode_from_gpr9()

[Stefano Babic]

Hi Christoph,

On 14/10/19 14:27, Christoph Niedermaier wrote:
> A return type of u08 cuts the return value always to 0,
> because IMX6_SRC_GPR10_BMODE = bit 28 is above u08.
> Changing the return type to u32 gives
> the function the expected operation.
> 
> Fixes: cba586b400 ("imx6: Add imx6_src_get_boot_mode")
> Signed-off-by: Christoph Niedermaier 
> ---
>  arch/arm/include/asm/mach-imx/sys_proto.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
> b/arch/arm/include/asm/mach-imx/sys_proto.h
> index aa66fdc88f..5222f6957d 100644
> --- a/arch/arm/include/asm/mach-imx/sys_proto.h
> +++ b/arch/arm/include/asm/mach-imx/sys_proto.h
> @@ -99,7 +99,7 @@ enum imx6_bmode {
>   IMX6_BMODE_NAND_MAX = 0xf,
>  };
>  
> -static inline u8 imx6_is_bmode_from_gpr9(void)
> +static inline u32 imx6_is_bmode_from_gpr9(void)
>  {
>   return readl(&src_base->gpr10) & IMX6_SRC_GPR10_BMODE;
>  }
> 

This is correct but it rather conflicts with another patch I already
applied. Could you rebase and repost ? Thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] gpio: fix CONFIG_IS_ENABLED(DM_GPIO) for SPL

[Baruch Siach]

Hi Stefan,

On Tue, Nov 05, 2019 at 04:14:59PM +0100, Stefan Roese wrote:
> On 03.11.19 10:52, Baruch Siach wrote:
> > There is currently no CONFIG_SPL_DM_GPIO, so CONFIG_IS_ENABLED(DM_GPIO)
> > is always false. As a result the sdhci driver can not use the DM gpio
> > API to read the card-detect signal in SPL. This breaks boot from SD card
> > on the SolidRun Clearfog platform since commit da18c62b6e ("mmc: sdhci:
> > Implement SDHCI card detect") that added sdhci_get_cd().
> > 
> > Add a blind CONFIG_SPL_DM_GPIO symbol that is enabled iff CONFIG_DM_GPIO
> > is. That makes CONFIG_IS_ENABLED(DM_GPIO) correct for SPL code.
> > 
> > Signed-off-by: Baruch Siach 
> > ---
> >   drivers/gpio/Kconfig | 5 +
> >   1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index c1ad5d64a35c..9bac341c5ed5 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -14,6 +14,11 @@ config DM_GPIO
> >   particular GPIOs that they provide. The uclass interface
> >   is defined in include/asm-generic/gpio.h.
> > +config SPL_DM_GPIO
> > +   bool
> > +   depends on DM_GPIO
> > +   default y
> > +
> >   config GPIO_HOG
> > bool "Enable GPIO hog support"
> > depends on DM_GPIO
> 
> I think its preferred to disable such SPL configurations per default
> to not increase the code size here - which is pretty crucial on some
> boards. Better to enable this SPL_DM_GPIO on your target or if it
> makes sense on your platform (MVEBU perhaps with a select or imply
> via the MMC driver in Kconfig).
> 
> What do you think?

Makes sense to me.

Should SPL_DM_GPIO be a blind symbol, or user selectable?

Would it make sense to add

  select SPL_DM_GPIO if (SPL && DM_GPIO)

to CONFIG_MMC_SDHCI_MV?

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: sys_proto: Fixing function imx6_is_bmode_from_gpr9()

[Anatolij Gustschin]

Hi Stefano, Christoph,

On Tue, 5 Nov 2019 16:57:18 +0100
Stefano Babic sba...@denx.de wrote:
...
> > -static inline u8 imx6_is_bmode_from_gpr9(void)
> > +static inline u32 imx6_is_bmode_from_gpr9(void)
> >  {
> > return readl(&src_base->gpr10) & IMX6_SRC_GPR10_BMODE;
> >  }
> >   
> 
> This is correct but it rather conflicts with another patch I already
> applied. Could you rebase and repost ? Thanks !

This function was removed by Claudius (see commit ID e01c8cfe5769)
since there are no users any more. No need to rebase/repost.

--
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: [RFC PATCH 00/29] arm: Introduce Marvell/Cavium OcteonTX

[Tim Harvey]

On Mon, Nov 4, 2019 at 5:09 PM Aaron Williams  wrote:
>
> Hi Tim,
>
> On Thursday, October 31, 2019 12:12:34 PM PST Tim Harvey wrote:
> > On Wed, Oct 30, 2019 at 5:04 PM Aaron Williams 
> wrote:
> > > Hi Tim,
> > >
> > > I think I can answer some of your questions.
> > >
> > > On Wednesday, October 30, 2019 10:06:41 AM PDT Tim Harvey wrote:
> > > > External Email
> > > >
> > > > --
> > > >
> > > > On Tue, Oct 29, 2019 at 2:08 PM Suneel Garapati 
> > >
> > > wrote:
> > > > > This series will add support for OcteonTX and OcteonTX2 processsor
> > > > > based
> > > > > platforms. The Marvell/Cavium Octeon-TX 64-bit ARM based SoCs include
> > > > > the CN80XX, CN81XX and CN83XX while Octeon-TX2 64-bit ARM based SoCs
> > > > > include support for CN96XX and CN95XX.
> > > > > These SoC's have peripheral drivers based on PCI ECAM.
> > > > >
> > > > > Patches
> > > > > [1 -10] Add requied changes to PCI framework
> > > > >
> > > > >  - [6] Add support for multi-memory region range
> > > > >  - [7] EA in bridges
> > > > >  - [8] SR-IOV
> > > > >
> > > > > [12] Add driver model support for RTC DS1337 driver
> > > > > [15 - 17] AHCI changes
> > > > > [18 - 27] Add OcteonTX drivers
> > > > > [28 - 29] Add OcteonTX/TX2 board files and configurations
> > > >
> > > > Suneel,
> > > >
> > > > Thanks for submitting this series!
> > > >
> > > > I've applied and built this and am testing on the Gateworks Newport
> > > > boards with the CN802x/CN803x (octeontx_81xx) and this is what I've
> > > > found:
> > > > - I get hung in the smc_call from smc_dram_size which your calling
> > > > with the function id of 0xc2000301. The older U-Boot from the Cavium
> > > > OcteonTX SDK-6.2.0-p3 used 0x43000301 and this works for me. Is there
> > > > a difference in our ATF version?
> > >
> > > ATF has indeed changed significantly. The current U-Boot requires an
> > > up-to-
> > > date ATF. I recall this was one of the changes we made with regards to
> > > getting the size of memory.
> >
> > What ATF should I be using? Is Marvell merging patches to the ATF
> > required for OcteonTX?
> >
> > > > - configs/octeontx_81xx_defconfig - I have several changes I want to
> > > > make here, but perhaps some of these would warrant a custom config for
> > > > my boards
> > > >
> > > >   - you assume there is only a SPI NOR flash for env which we
> > > >
> > > > personally don't use. The env system supports multiple env types so we
> > > > could just enable MMC as well as SPI but then I find all the
> > > > hard-coded CONFIG_ENV_* defines restrictive. I wonder if anyone has
> > > > defined a way for these to come from device-tree?
> > >
> > > We have not tested loading the environment from eMMC. It would be nice if
> > > the environment location could come from the device tree.
> >
> > I tested it and it works fine.
> >
> > The mmc-env partition, offset, and offset-redundant can be set via dts
> > (doc/device-tree-bindings/config.txt and env/mmc.c) and I am setting
> > these in my dts. I'll look into expanding this if necessary so that
> > the defconfigs could just enable both SPI and MMC env and the dt will
> > be able to dictate the details.
> >
> > Does the 'Octeon' support your working on overlap with 'OcteonTX'?
>
> Some of the Octeon support will leverage OcteonTX since some of the drivers
> are mostly compatible, such as eMMC, SPI and I2C. There is also a lot in
> Octeon that in the case of OcteonTX is handled by ATF and our BDK bootloader.
> In these cases there is no overlap.
>

Aaron,

Thanks for the clarification. It sounds like you are working on SPL
for Octeon which I was hoping could perhaps also support OcteonTX at
some point. I had high hopes of adding SPL support for OcteonTX for
our boards but ended up not having the time to work through it and in
the end just used the BDK. This makes for an extremely long boot time
(about 10 seconds just to get to U-Boot unfortunately).

Regards,

Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Revert "binman: Correct symbol calculation with non-zero image base"

[Stephen Warren]

From: Stephen Warren 

This reverts commit 15c981cc8adc26501e3a19ca7fb35705870ef597.
"binman: Correct symbol calculation with non-zero image base". This
was previously reported to break initial boot on Jetson TK1, and Simon
dropped the patch from his branch. However, it seems to have shown up
again in a pull request somehow. Revert it until the problem is fixed.

Signed-off-by: Stephen Warren 
---
 tools/binman/elf.py  | 4 +++-
 tools/binman/test/u_boot_binman_syms.lds | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/binman/elf.py b/tools/binman/elf.py
index 0c1a5b44b669..7bc7cf61b5d8 100644
--- a/tools/binman/elf.py
+++ b/tools/binman/elf.py
@@ -135,7 +135,9 @@ def LookupAndWriteSymbols(elf_fname, entry, section):
 
 # Look up the symbol in our entry tables.
 value = section.LookupSymbol(name, sym.weak, msg)
-if value is None:
+if value is not None:
+value += base.address
+else:
 value = -1
 pack_string = pack_string.lower()
 value_bytes = struct.pack(pack_string, value)
diff --git a/tools/binman/test/u_boot_binman_syms.lds 
b/tools/binman/test/u_boot_binman_syms.lds
index 825fc3f649f7..926df873cb70 100644
--- a/tools/binman/test/u_boot_binman_syms.lds
+++ b/tools/binman/test/u_boot_binman_syms.lds
@@ -9,7 +9,7 @@ ENTRY(_start)
 
 SECTIONS
 {
-   . = 0x0010;
+   . = 0x;
_start = .;
 
. = ALIGN(4);
-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Revert "binman: Correct symbol calculation with non-zero image base"

[Simon Glass]

On Tue, 5 Nov 2019 at 09:21, Stephen Warren  wrote:
>
> From: Stephen Warren 
>
> This reverts commit 15c981cc8adc26501e3a19ca7fb35705870ef597.
> "binman: Correct symbol calculation with non-zero image base". This
> was previously reported to break initial boot on Jetson TK1, and Simon
> dropped the patch from his branch. However, it seems to have shown up
> again in a pull request somehow. Revert it until the problem is fixed.
>
> Signed-off-by: Stephen Warren 
> ---
>  tools/binman/elf.py  | 4 +++-
>  tools/binman/test/u_boot_binman_syms.lds | 2 +-
>  2 files changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: sys_proto: Fixing function imx6_is_bmode_from_gpr9()

[Stefano Babic]

On 05/11/19 17:05, Anatolij Gustschin wrote:
> Hi Stefano, Christoph,
> 
> On Tue, 5 Nov 2019 16:57:18 +0100
> Stefano Babic sba...@denx.de wrote:
> ...
>>> -static inline u8 imx6_is_bmode_from_gpr9(void)
>>> +static inline u32 imx6_is_bmode_from_gpr9(void)
>>>  {
>>> return readl(&src_base->gpr10) & IMX6_SRC_GPR10_BMODE;
>>>  }
>>>   
>>
>> This is correct but it rather conflicts with another patch I already
>> applied. Could you rebase and repost ? Thanks !
> 
> This function was removed by Claudius (see commit ID e01c8cfe5769)

Yes, but this check just one bit.

> since there are no users any more. 

Oh yes, you're right !

>No need to rebase/repost.

Regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT

[Simon Glass]

Hi Jean-Jacques,

On Mon, 4 Nov 2019 at 08:41, Jean-Jacques Hiblot  wrote:
>
>
> On 30/10/2019 02:48, Simon Glass wrote:
> > On Mon, 30 Sep 2019 at 10:15, Jean-Jacques Hiblot  wrote:
> >> Add managed functions to get a reset_ctl from the device-tree, based on a
> >> name or an index.
> >> Also add a managed functions to get a reset_ctl_bulk (array of reset_ctl)
> >> from the device-tree.
> >>
> >> When the device is unbound, the reset controllers are automatically
> >> released and the data structure is freed.
> >>
> >> Signed-off-by: Jean-Jacques Hiblot 
> >> ---
> >>
> >>   drivers/reset/reset-uclass.c | 116 +-
> >>   include/reset.h  | 135 ++-
> >>   2 files changed, 247 insertions(+), 4 deletions(-)
> > Reviewed-by: Simon Glass 
> >
> > I really don't like these ERR_PTR returns. I suppose they make the
> > code easier to port, and we can be sure that pointers will not be in
> > the last 4KB of address space?
>
> It seems rather unlikely because the returned pointer points to actual
> RAM allocated from the heap. On most platforms I've worked with, the top
> of the address space is not dedicated to memory.

Yes that's my comfort.

> If ever the need to fix
> this  arises it could done by tweaking the macros to use another unused
> address space.

Not easily without doing something platform-specific, as someone else
is currently pushing.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 26/34] binman: Correct symbol calculation with non-zero image base

[Simon Glass]

Hi Stephen,

On Mon, 4 Nov 2019 at 10:34, Stephen Warren  wrote:
>
> On 10/15/19 10:09 AM, Stephen Warren wrote:
> > On 10/15/19 8:07 AM, Simon Glass wrote:
> >> Hi Stephen,
> >>
> >> On Mon, 14 Oct 2019 at 09:49, Stephen Warren 
> >> wrote:
> >>>
> >>> On 9/26/19 6:38 PM, s...@google.com wrote:
>  At present binman adds the image base address to the symbol value
>  before
>  it writes it to the binary. This is not correct since the symbol value
>  itself (e.g. image position) has no relationship to the image base.
> 
>  Fix this and update the tests to cover this case.
> 
>  Signed-off-by: Simon Glass 
>  ---
> 
> tools/binman/elf.py  | 4 +---
> tools/binman/test/u_boot_binman_syms.lds | 2 +-
> 2 files changed, 2 insertions(+), 4 deletions(-)
> 
>  Applied to u-boot-dm, thanks!
> >>>
> >>> This seems to have only just been pushed. This patch breaks boot on
> >>> Jetson TK1; u-boot-dm.git master hangs in SPL or before the main U-Boot
> >>> prints anything, whereas after reverting this patch solves the issue.
> >>>
> >>> With this patch applied, all I get is:
> >>>
> >>> U-Boot SPL 2019.10-00490-g4f035abcde98 (Oct 14 2019 - 09:48:30 -0600)
> >>> Trying to boot from RAM
> >>
> >> Yes, just pushed as I had to wait for u-boot-dm/testing to pass, and
> >> it has some flaky runs and then I went on holiday.
> >>
> >> This is unfortunate. It looks like we were missing test coverage. I'll
> >> see if I can look at it later in the week, but for now I think I might
> >> drop this patch.
> >
> > Thanks. The latest push to u-boot-dm/master solves/removes this issue.
>
> This patch has now shown in in u-boot/master and u-boot-video/master, so
> Jetson TK1 testing is broken there now. Reverting this patch fixes the
> issue (I only tested that in u-boot/master).

Arggh OK I will sort this out this week.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT

[Simon Goldschmidt]

Am 05.11.2019 um 17:33 schrieb Simon Glass:

Hi Jean-Jacques,

On Mon, 4 Nov 2019 at 08:41, Jean-Jacques Hiblot  wrote:



On 30/10/2019 02:48, Simon Glass wrote:

On Mon, 30 Sep 2019 at 10:15, Jean-Jacques Hiblot  wrote:

Add managed functions to get a reset_ctl from the device-tree, based on a
name or an index.
Also add a managed functions to get a reset_ctl_bulk (array of reset_ctl)
from the device-tree.

When the device is unbound, the reset controllers are automatically
released and the data structure is freed.

Signed-off-by: Jean-Jacques Hiblot 
---

   drivers/reset/reset-uclass.c | 116 +-
   include/reset.h  | 135 ++-
   2 files changed, 247 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 

I really don't like these ERR_PTR returns. I suppose they make the
code easier to port, and we can be sure that pointers will not be in
the last 4KB of address space?


It seems rather unlikely because the returned pointer points to actual
RAM allocated from the heap. On most platforms I've worked with, the top
of the address space is not dedicated to memory.


Most != all: on socfpga, the internal SRAM is at the end of the address 
spcae. In SPL, this means the last 4K cannot be used.


However, that shouldn't keep us from porting ERR_PTR returns from Linux 
code.




Yes that's my comfort.


If ever the need to fix
this  arises it could done by tweaking the macros to use another unused
address space.


Not easily without doing something platform-specific, as someone else
is currently pushing.


That "someone else" would be me. Sadly, I did not get any response:

https://patchwork.ozlabs.org/project/uboot/list/?series=137880


Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC/RFT U-Boot PATCH] image: Add Image.gz parsing support in booti.

[Tom Rini]

On Tue, Nov 05, 2019 at 03:51:54PM +, Atish Patra wrote:
> On Mon, 2019-11-04 at 17:35 -0500, Tom Rini wrote:
> > On Mon, Nov 04, 2019 at 10:20:33PM +, Atish Patra wrote:
> > > On Fri, 2019-11-01 at 09:29 -0400, Tom Rini wrote:
> > > > On Thu, Oct 10, 2019 at 02:23:17PM -0700, Atish Patra wrote:
> > > > 
> > > > > Add gz parsing logic so that booti can parse both Image
> > > > > and Image.gz to boot Linux. Currently, it is difficult to
> > > > > calculate
> > > > > a safe address for every board where the Image.gz can be
> > > > > decompressed.
> > > > > It is also not possible to figure out the size of the
> > > > > compressed
> > > > > file
> > > > > as well. Thus, user need to set two additional environment
> > > > > variables
> > > > > kernel_gz_addr_r and kernel_gz_size to make Image.gz work.
> > > > > 
> > > > > Tested on HiFive Unleashed and Qemu for RISC-V.
> > > > > 
> > > > > Signed-off-by: Atish Patra 
> > > > > ---
> > > > > I could not test this patch on any ARM64 devices due to lack of
> > > > > access to any ARM64 board. If anybody can test it on ARM64,
> > > > > that
> > > > > would be great.
> > 
> > Oh, I missed this part before.  You should be able to get fairly far
> > with qemu :)
> 
> I did verify with qemu. I was requesting some tested-by on ARM64
> hardware. Sorry for the confusion. I will update the commit text in
> next version.

Ah, OK.

> > > > Can we do the compression check more generally?  I'd like to be
> > > > able
> > > > to
> > > > see Image.xz/lz4/etc be able to be handled cleanly.
> > > 
> > > This patch is intended only handle Image.gz which is a compressed
> > > version of kernel "Image" file. That's why relevant code is only
> > > added
> > > to booti command.
> > 
> > Right.  But the linux kernel will happily spit out a handful of other
> > compressed Image files on arm64.  I see riscv is only .gz today, but
> > I
> > want to be able to handle whatever the compression is, so long as we
> > have it available.
> > 
> 
> Ahh I misunderstood that part. I could not find any existing code to
> detect to different compression formats.
> 
> If I have not missed anything, I can add that code in common/image.c
> and use that function in booti.c.

Right, it's something we don't have today.  But I _think_ we have enough
of a general abstraction setup such that just like how we have "load"
and "ls" and such that will figure out the underlying filesystem we
could have "uncompress" (or perhaps something else, that might be an
alias for gunzip already) that will figure out what the compression is
based on the header and do the right thing.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] dm: core: Remove libfdt dependency when unnecessary

[Ezequiel Garcia]

Hello Walter,

Thanks for the patch.

On Tue, 5 Nov 2019 at 12:27, Walter Lozano  wrote:
>
> The support of libfdt should only be needed when OF_CONTROL
> is enabled and OF_PLATDATA is not, as in other cases there is no
> DT file to query.
>
> This patch fixes this dependency allowing to save some space.
>

Can you add some more information about the space saving?
The ./scripts/bloat-o-meter will help you get some info
on static footprint.

> Signed-off-by: Walter Lozano 
> ---
>  drivers/core/ofnode.c | 132 +--
>  include/dm/read.h | 141 ++
>  2 files changed, 267 insertions(+), 6 deletions(-)
>

You should try to avoid adding #ifdefery to the code. Normally,
the way to ifdef code is by having this in a header:

#ifdef CONFIG_FOO
int foo_feature_optional(struct foo *priv);
#else
static inline int foo_feature_optional(struct foo *priv)
{
return 0;
}
#endif

The user of foo_feature_optional shouldn't be bothered with
FOO being enabled or not. Pushing ifdefs away from .c to .h
is a common pattern, well described in a classic old article:

http://www.literateprogramming.com/ifdefs.pdf

Do you think you can try to rework the patch to reduce its impact
as much as possible?

Thanks,
Ezequiel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT

[Jean-Jacques Hiblot]

On 05/11/2019 17:42, Simon Goldschmidt wrote:

Am 05.11.2019 um 17:33 schrieb Simon Glass:

Hi Jean-Jacques,

On Mon, 4 Nov 2019 at 08:41, Jean-Jacques Hiblot  
wrote:



On 30/10/2019 02:48, Simon Glass wrote:
On Mon, 30 Sep 2019 at 10:15, Jean-Jacques Hiblot  
wrote:
Add managed functions to get a reset_ctl from the device-tree, 
based on a

name or an index.
Also add a managed functions to get a reset_ctl_bulk (array of 
reset_ctl)

from the device-tree.

When the device is unbound, the reset controllers are automatically
released and the data structure is freed.

Signed-off-by: Jean-Jacques Hiblot 
---

   drivers/reset/reset-uclass.c | 116 +-
   include/reset.h  | 135 
++-

   2 files changed, 247 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 

I really don't like these ERR_PTR returns. I suppose they make the
code easier to port, and we can be sure that pointers will not be in
the last 4KB of address space?


It seems rather unlikely because the returned pointer points to actual
RAM allocated from the heap. On most platforms I've worked with, the 
top

of the address space is not dedicated to memory.


Most != all: on socfpga, the internal SRAM is at the end of the 
address spcae. In SPL, this means the last 4K cannot be used.


However, that shouldn't keep us from porting ERR_PTR returns from 
Linux code.




Yes that's my comfort.


If ever the need to fix
this  arises it could done by tweaking the macros to use another unused
address space.


Not easily without doing something platform-specific, as someone else
is currently pushing.


That "someone else" would be me. Sadly, I did not get any response:

https://patchwork.ozlabs.org/project/uboot/list/?series=137880



Alternatively we could use BIT(0) to flag an error since allocations are 
always aligned on 4 or more (sizeof(ulong) or 2*sizeof(size_t))






Regards,
Simon


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] dm: core: Remove libfdt dependency when unnecessary

[Walter Lozano]

Hi Ezequiel,

On 5/11/19 13:56, Ezequiel Garcia wrote:

Hello Walter,

Thanks for the patch.

On Tue, 5 Nov 2019 at 12:27, Walter Lozano  wrote:

The support of libfdt should only be needed when OF_CONTROL
is enabled and OF_PLATDATA is not, as in other cases there is no
DT file to query.

This patch fixes this dependency allowing to save some space.


Can you add some more information about the space saving?



Sure, I will add some additional information about the static footprint. 
However according to my understanding the impact depends on how well 
different drivers supports features like OF_PLATDATA. For instance, in 
my current configuration it saves 2 KB.




The ./scripts/bloat-o-meter will help you get some info
on static footprint.



Thanks for your suggestion. I think you are pointing to a script found 
in the Linux kernel, right? I also think it could be useful to have a 
deep understanding on how the static footprint of some .o files changes, 
but it won't give us much information about the end result of the binary 
image, which is affected by the dependencies and compiler/linker 
optimizations. Is this correct?




Signed-off-by: Walter Lozano 
---
  drivers/core/ofnode.c | 132 +--
  include/dm/read.h | 141 ++
  2 files changed, 267 insertions(+), 6 deletions(-)


You should try to avoid adding #ifdefery to the code. Normally,
the way to ifdef code is by having this in a header:

#ifdef CONFIG_FOO
int foo_feature_optional(struct foo *priv);
#else
static inline int foo_feature_optional(struct foo *priv)
{
 return 0;
}
#endif

The user of foo_feature_optional shouldn't be bothered with
FOO being enabled or not. Pushing ifdefs away from .c to .h
is a common pattern, well described in a classic old article:

http://www.literateprogramming.com/ifdefs.pdf

Do you think you can try to rework the patch to reduce its impact
as much as possible?



Thanks for your review and your suggestions, I will be happy to rework 
this to improve it.



The intention of this RFC is to get some feedback about if this is 
something worth to be added and if this is the right approach. The use 
of OF_PLATDATA is quite limited as it needs drivers to support it, which 
will probably be a long process. Enabling it but having some drivers to 
query DT properties has no sense and requires additional dependencies, 
like libfdt.


Also I think it should be possible to remove some extra components but 
it will require extra work to avoid break some configurations.




Thanks,
Ezequiel



Thanks,

Walter

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] travis: Rework how we write the ~/.buildman file

[Tom Rini]

With python3 we're now tripping over a long-standing problem with how we
add to the buildman file with some toolchains.  We cannot have multiple
toolchain-alias sections as that leads to a parse error.

Signed-off-by: Tom Rini 
---
 .travis.yml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 2369da97f9e5..1e9837869508 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -47,7 +47,9 @@ install:
  # prepare buildman environment
  - echo -e "[toolchain]\nroot = /usr" > ~/.buildman
  - echo -e "arc = /tmp/arc_gnu_2018.09_prebuilt_uclibc_le_archs_linux_install" 
>> ~/.buildman
- - echo -e "\n[toolchain-alias]\nsh = sh2\n" >> ~/.buildman
+ - echo -e "\n[toolchain-alias]\nsh = sh2" >> ~/.buildman
+ - echo -e "x86 = i386" >> ~/.buildman;
+ - echo -e "riscv = riscv64" >> ~/.buildman;
  - cat ~/.buildman
  - grub-mkimage --prefix="" -o ~/grub_x86.efi -O i386-efi normal  echo 
lsefimmap lsefi lsefisystab efinet tftp minicmd
  - grub-mkimage --prefix="" -o ~/grub_x64.efi -O x86_64-efi normal  echo 
lsefimmap lsefi lsefisystab efinet tftp minicmd
@@ -74,7 +76,6 @@ before_script:
   - if [[ "${TOOLCHAIN}" == *sh* ]]; then ./tools/buildman/buildman 
--fetch-arch sh2 ; fi
   - if [[ "${TOOLCHAIN}" == *i386* ]]; then
   ./tools/buildman/buildman --fetch-arch i386;
-  echo -e "\n[toolchain-alias]\nx86 = i386" >> ~/.buildman;
 fi
   - if [[ "${TOOLCHAIN}" == arc ]]; then
wget 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2018.09-release/arc_gnu_2018.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
 &&
@@ -98,7 +99,6 @@ before_script:
   - if [[ "${TOOLCHAIN}" == "powerpc" ]]; then ./tools/buildman/buildman 
--fetch-arch powerpc; fi
   - if [[ "${TOOLCHAIN}" == "riscv" ]]; then
./tools/buildman/buildman --fetch-arch riscv64;
-   echo -e "\n[toolchain-alias]\nriscv = riscv64" >> ~/.buildman;
 fi
   - if [[ "${QEMU_TARGET}" != "" ]]; then
git clone git://git.qemu.org/qemu.git /tmp/qemu;
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: fsl-layerscape: fix hwconfig and prefetching

[Michael Walle]

Am 2019-11-05 11:23, schrieb Priyanka Jain:

-Original Message-
From: U-Boot  On Behalf Of Michael Walle
Sent: Tuesday, October 22, 2019 2:07 AM
To: u-boot@lists.denx.de
Cc: Tom Rini 
Subject: [U-Boot] [PATCH] armv8: fsl-layerscape: fix hwconfig and 
prefetching


If CONFIG_HWCONFIG is disabled, hwconfig_subarg_f() will return the 
empty
string, ie. not NULL. Therefore, we have to check the returned 
argument

length as well as the return value.

Signed-off-by: Michael Walle 
---
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index a5d0b5370f..4bb73b524c 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -1073,7 +1073,7 @@ static void config_core_prefetch(void)
prefetch_arg = hwconfig_subarg_f("core_prefetch", "disable",
 &arglen, buf);

-   if (prefetch_arg) {
+   if (arglen && prefetch_arg) {
mask = simple_strtoul(prefetch_arg, NULL, 0) & 0xff;
if (mask & 0x1) {
printf("Core0 prefetch can't be disabled\n");
--
2.20.1

Please check similar patch at 
http://patchwork.ozlabs.org/patch/1187188/

Does this solve your issue?


Yes that works, too. So my patch can be dropped.

Thanks,
-michael
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 3/3] arm: dts: ls1028a: fix interrupt properties

[Michael Walle]

Sync the interrupt properties with the ones from Linux. Also use the
constants provided by the dt-bindings header. Please note, that there
are actual changes/fixes in the irq flags. U-Boot won't use the
interrupt properties anyway. It's just to be consistent with the Linux
device tree.

Signed-off-by: Michael Walle 
---
changes since v1:
 - n/a
changes since v2:
 - new patch

 arch/arm/dts/fsl-ls1028a.dtsi | 55 ---
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 774e477542..5365bfb1a8 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -6,6 +6,8 @@
  *
  */
 
+#include 
+
 / {
compatible = "fsl,ls1028a";
interrupt-parent = <&gic>;
@@ -38,15 +40,20 @@
  <0x0 0x0604 0 0x4>;
#interrupt-cells = <3>;
interrupt-controller;
-   interrupts = <1 9 0x4>;
+   interrupts = ;
};
 
timer {
compatible = "arm,armv8-timer";
-   interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
-<1 14 0x8>, /* Physical Non-Secure PPI, active-low 
*/
-<1 11 0x8>, /* Virtual PPI, active-low */
-<1 10 0x8>; /* Hypervisor PPI, active-low */
+   interrupts = ,
+,
+,
+;
};
 
fspi: flexspi@20c {
@@ -58,7 +65,7 @@
reg-names = "fspi_base", "fspi_mmap";
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "fspi_en", "fspi";
-   interrupts = <0 25 0x4>;
+   interrupts = ;
status = "disabled";
};
 
@@ -66,7 +73,7 @@
device_type = "serial";
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
-   interrupts = <0 32 0x1>; /* edge triggered */
+   interrupts = ;
status = "disabled";
};
 
@@ -74,7 +81,7 @@
device_type = "serial";
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0600 0x0 0x100>;
-   interrupts = <0 32 0x1>; /* edge triggered */
+   interrupts = ;
status = "disabled";
};
 
@@ -150,7 +157,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x200 0x0 0x1>;
-   interrupts = <0 34 0x4>;
+   interrupts = ;
clock-names = "i2c";
clocks = <&clockgen 4 0>;
status = "disabled";
@@ -161,7 +168,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x201 0x0 0x1>;
-   interrupts = <0 34 0x4>;
+   interrupts = ;
clock-names = "i2c";
clocks = <&clockgen 4 0>;
status = "disabled";
@@ -172,7 +179,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x202 0x0 0x1>;
-   interrupts = <0 35 0x4>;
+   interrupts = ;
clock-names = "i2c";
clocks = <&clockgen 4 0>;
status = "disabled";
@@ -183,7 +190,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x203 0x0 0x1>;
-   interrupts = <0 35 0x4>;
+   interrupts = ;
clock-names = "i2c";
clocks = <&clockgen 4 0>;
status = "disabled";
@@ -194,7 +201,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x204 0x0 0x1>;
-   interrupts = <0 74 0x4>;
+   interrupts = ;
clock-names = "i2c";
clocks = <&clockgen 4 0>;
status = "disabled";
@@ -205,7 +212,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x205 0x0 0x1>;
-   interrupts = <0 74 0x4>;
+   interrupts = ;
clock-names = "i2c";
clocks = <&clockgen 4 0>;
status = "disabled";
@@ -216,7 +223,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x206 0x0 0x1>;
-   interrupts = <0 75 0x4>;
+   interrupts = ;
clock-names = "i2c";
clocks = <&clockgen 4 0>;
status = "disabled";
@@ -227,7 +234,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x207 0x0 0x1>;
-   interrupts = <0 75 0x4

[U-Boot] [PATCH v3 2/3] arm: ls1028a: use the new flexspi driver

[Michael Walle]

Also align the fspi node with the kernel one.

Signed-off-by: Michael Walle 
Reviewed-by: Kuldeep Singh 
---
changes since v1:
 - none
changes since v2:
 - none

 arch/arm/dts/fsl-ls1028a.dtsi | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 43a154e8e7..774e477542 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -49,14 +49,16 @@
 <1 10 0x8>; /* Hypervisor PPI, active-low */
};
 
-   fspi: flexspi@20C {
-   compatible = "nxp,dn-fspi";
+   fspi: flexspi@20c {
+   compatible = "nxp,lx2160a-fspi";
#address-cells = <1>;
#size-cells = <0>;
-   reg = <0x0 0x20C 0x0 0x1>,
-   <0x0 0x2000 0x0 0x1000>; /*64MB flash*/
-   reg-names = "FSPI", "FSPI-memory";
-   num-cs = <1>;
+   reg = <0x0 0x20c 0x0 0x1>,
+ <0x0 0x2000 0x0 0x1000>;
+   reg-names = "fspi_base", "fspi_mmap";
+   clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+   clock-names = "fspi_en", "fspi";
+   interrupts = <0 25 0x4>;
status = "disabled";
};
 
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 1/3] spi: nxp_fspi: new driver for the FlexSPI controller

[Michael Walle]

This is a port of the kernel's spi-nxp-fspi driver. It uses the new
spi-mem interface and does not expose the more generic spi-xfer
interface. The source was taken from the v5.3-rc3 tag.

The port was straightforward:
 - remove the interrupt handling and the completion by busy polling the
   controller
 - remove locks
 - move the setup of the memory windows into claim_bus()
 - move the setup of the speed into set_speed()
 - port the device tree bindings from the original fspi_probe() to
   ofdata_to_platdata()

There were only some style change fixes, no change in any logic. For
example, there are busy loops where the return code is not handled
correctly, eg. only prints a warning with WARN_ON(). This port
intentionally left most functions unchanged to ease future bugfixes.

This was tested on a custom LS1028A board. Because the LS1028A doesn't
have proper clock framework support, changing the clock speed was not
tested. This also means that it is not possible to change the SPI
speed on LS1028A for now (neither is it possible in the linux driver).

Signed-off-by: Michael Walle 
Reviewed-by: Jagan Teki 
---
changes since v1:
 - fixed typo, thanks Jagan
changes since v2:
 - none

 drivers/spi/Kconfig|   7 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/nxp_fspi.c | 997 +
 3 files changed, 1005 insertions(+)
 create mode 100644 drivers/spi/nxp_fspi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 7be867d5b6..ad20309df8 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -192,6 +192,13 @@ config MVEBU_A3700_SPI
  used to access the SPI NOR flash on platforms embedding this
  Marvell IP core.
 
+config NXP_FSPI
+   bool "NXP FlexSPI driver"
+   depends on SPI_MEM
+   help
+ Enable the NXP FlexSPI (FSPI) driver. This driver can be used to
+ access the SPI NOR flash on platforms embedding this NXP IP core.
+
 config PIC32_SPI
bool "Microchip PIC32 SPI driver"
depends on MACH_PIC32
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ae4f2958f8..52462e19a3 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o
 obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
 obj-$(CONFIG_MXC_SPI) += mxc_spi.o
 obj-$(CONFIG_MXS_SPI) += mxs_spi.o
+obj-$(CONFIG_NXP_FSPI) += nxp_fspi.o
 obj-$(CONFIG_ATCSPI200_SPI) += atcspi200_spi.o
 obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 obj-$(CONFIG_PIC32_SPI) += pic32_spi.o
diff --git a/drivers/spi/nxp_fspi.c b/drivers/spi/nxp_fspi.c
new file mode 100644
index 00..b808418eb6
--- /dev/null
+++ b/drivers/spi/nxp_fspi.c
@@ -0,0 +1,997 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * NXP FlexSPI(FSPI) controller driver.
+ *
+ * Copyright (c) 2019 Michael Walle 
+ *
+ * This driver was originally ported from the linux kernel v5.4-rc3, which had
+ * the following notes:
+ *
+ * Copyright 2019 NXP.
+ *
+ * FlexSPI is a flexsible SPI host controller which supports two SPI
+ * channels and up to 4 external devices. Each channel supports
+ * Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional
+ * data lines).
+ *
+ * FlexSPI controller is driven by the LUT(Look-up Table) registers
+ * LUT registers are a look-up-table for sequences of instructions.
+ * A valid sequence consists of four LUT registers.
+ * Maximum 32 LUT sequences can be programmed simultaneously.
+ *
+ * LUTs are being created at run-time based on the commands passed
+ * from the spi-mem framework, thus using single LUT index.
+ *
+ * Software triggered Flash read/write access by IP Bus.
+ *
+ * Memory mapped read access by AHB Bus.
+ *
+ * Based on SPI MEM interface and spi-fsl-qspi.c driver.
+ *
+ * Author:
+ * Yogesh Narayan Gaur 
+ * Boris Brezillon 
+ * Frieder Schrempf 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The driver only uses one single LUT entry, that is updated on
+ * each call of exec_op(). Index 0 is preset at boot with a basic
+ * read operation, so let's use the last entry (31).
+ */
+#defineSEQID_LUT   31
+
+/* Registers used by the driver */
+#define FSPI_MCR0  0x00
+#define FSPI_MCR0_AHB_TIMEOUT(x)   ((x) << 24)
+#define FSPI_MCR0_IP_TIMEOUT(x)((x) << 16)
+#define FSPI_MCR0_LEARN_EN BIT(15)
+#define FSPI_MCR0_SCRFRUN_EN   BIT(14)
+#define FSPI_MCR0_OCTCOMB_EN   BIT(13)
+#define FSPI_MCR0_DOZE_EN  BIT(12)
+#define FSPI_MCR0_HSEN BIT(11)
+#define FSPI_MCR0_SERCLKDIVBIT(8)
+#define FSPI_MCR0_ATDF_EN  BIT(7)
+#define FSPI_MCR0_ARDF_EN  BIT(6)
+#define FSPI_MCR0_RXCLKSRC(x)  ((x) << 4)
+#define FSPI_MCR0_END_CFG(x)   ((x) << 2)
+#define FSPI_MCR0_MDIS BIT(1)
+#define FSPI_MCR0_SWRST

Re: [U-Boot] [PATCH v2 1/1] net: avoid address-of-packed-member error

[Joe Hershberger]

On Tue, Nov 5, 2019 at 5:49 AM Heinrich Schuchardt  wrote:
>
> sandbox_defconfig does not compile using GCC 9.2.1:
>
> net/net.c: In function ‘net_process_received_packet’:
> net/net.c:1288:23: error: taking address of packed member of ‘struct
> ip_udp_hdr’ may result in an unaligned pointer value
> [-Werror=address-of-packed-member]
>  1288 |sumptr = (ushort *)&(ip->udp_src);
>   |   ^~
>
> Avoid the error by using a u8 pointer instead of an u16 pointer and
> in-lining ntohs().

Seems reasonable.

> Simplify the checksumming of the last message byte.
>
> Signed-off-by: Heinrich Schuchardt 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Aaron Williams]

From: Wolfgang Denk 
Sent: Tuesday, November 5, 2019 3:36 AM
To: Aaron Williams 
Cc: Tom Rini ; Daniel Schwierzeck 
; u-boot@lists.denx.de 
Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support

Hi Wolfgang,

I apologize in  advance for the lack of email formatting (blame our IT 
department for forcing Linux users to use the broken Outhouse web client).

Dear Aaron,

In message <2609392.0ByMiX4J6F@flash> you wrote:
>
> U-Boot OS might be fun for people writing applications where they want bare
> metal (i.e. hard real-time), though that's already provided with the API and
> examples.

Urgh... no!!! U-Boot is definitely *not* suitable for any kind of
real-time tasks.  By design it implements strict single-tasking with
usally polling hardware access only.  No multi-tasking, no
interrupts, no locking, no timers, nothing...

And I wouldn't ask U-Boot to do this. We don't do any multi-tasking with U-Boot 
with the exception of SoC specific code that deals with starting simple 
executive applications. Our API uses a single giant spinlock to prevent there 
being any multi-tasking within U-Boot.

Now there is other SoC specific code that does use locks and does support 
multiple cores simultaneously running code. This is needed when we start these 
Simple Executive applications. The code allows for multiple applications as 
well as the Linux kernel to be started simultaneously from within U-Boot. The 
code is executed by all cores in use and does things like set up memory and TLB 
mapping for the simple executive applications for each core. None of this code 
would be exposed outside of our SoC code and there is zero interaction with any 
of U-Boot's code. Each simple executive application has a core mask of cores 
assigned to it. Obviously in order to be able to do this there is locking 
within the SoC specific code. It does not involve any code outside of the SoC 
in order to do this.


> You can't get much more arms length than that except perhaps requiring U-Boot
> to use an interrupt. They are by just about any definition, completely
> separate binaries. I'm no lawyer, but reading the GPL FAQ I think we fall well
> within the arms length separation.

Definitely not.  You could not implement any of this without heavily
relyin on and deriving from internal interfaces of U-Boot which are
not exported for non-GPL use.

See 
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLInProprietarySystem

This behaves exactly in the manner that is permitted by the GPL. They are 
completely separate programs.

Best regards,

Wolfgang Denk

Regards,

Aaron Williams

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-fdt

[Tom Rini]

On Tue, Nov 05, 2019 at 05:23:51AM -0700, Simon Glass wrote:

> Hi Tom,
> 
> Passing run here:
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1210
> 
> 
> The following changes since commit 73b6e6ad254b36763419cdd3fdf406c0094517b7:
> 
>   Merge tag 'u-boot-imx-20191104' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2019-11-04
> 12:57:41 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-fdt.git tags/fdt-pull-5nov19
> 
> for you to fetch changes up to 388560134b99dc4cc752627d3a7e9f8c8c2a89a7:
> 
>   binman: Move to use Python 3 (2019-11-04 18:15:32 -0700)
> 

Now first,
Applied to u-boot/master, thanks!

And second, which is why I've included the board maintainers list and
custodian lists, this causes a bit of size growth everywhere just about
(tbs2910 being the exception) because by default upstream now has
various input validation routines.  It doesn't catch "tell the hardware
to overvolt something" but does catch "pass garbage in the property so
we can overwrite the stack and ..." type problems.  And it's
configurable.  If you turn off all of the validation stuff, which we do
in SPL/TPL by default (size concerns!), in the main U-Boot we go from a
size growth to a size shrink.  An arbitrary PowerPC board I picked to
confirm this on grows by 985 bytes now, but if I turned everything off
it would shrink by 1100 bytes.  There's an inbetween setting that would
probably result in neutral size change.

The default is all of the input validation we can do because I believe
it's important to validate inputs when we can validate them.  I also
firmly believe board maintainers know their requirements best and can
provide a different value for their board(s).

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] travis: Rework how we write the ~/.buildman file

[Tom Rini]

On Tue, Nov 05, 2019 at 03:56:29PM -0500, Tom Rini wrote:

> With python3 we're now tripping over a long-standing problem with how we
> add to the buildman file with some toolchains.  We cannot have multiple
> toolchain-alias sections as that leads to a parse error.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] dm: core: Remove libfdt dependency when unnecessary

[Ezequiel Garcia]

On Tue, 5 Nov 2019 at 15:12, Walter Lozano  wrote:
>
> Hi Ezequiel,
>
> On 5/11/19 13:56, Ezequiel Garcia wrote:
> > Hello Walter,
> >
> > Thanks for the patch.
> >
> > On Tue, 5 Nov 2019 at 12:27, Walter Lozano  
> > wrote:
> >> The support of libfdt should only be needed when OF_CONTROL
> >> is enabled and OF_PLATDATA is not, as in other cases there is no
> >> DT file to query.
> >>
> >> This patch fixes this dependency allowing to save some space.
> >>
> > Can you add some more information about the space saving?
>
>
> Sure, I will add some additional information about the static footprint.
> However according to my understanding the impact depends on how well
> different drivers supports features like OF_PLATDATA. For instance, in
> my current configuration it saves 2 KB.
>

Not sure I follow you. This patch adds a condition which adds/removes code
based on some conditions. So, it should depend on the arch, but otherwise
the reduction is an invariant as it just depend on the size of the
code that is being
added/removed. Or am I missing something?

>
> > The ./scripts/bloat-o-meter will help you get some info
> > on static footprint.
>
>
> Thanks for your suggestion. I think you are pointing to a script found
> in the Linux kernel, right?

Ah, yes. I have this script imported on my U-Boot repo, so I assumed
it was here as well.

> I also think it could be useful to have a
> deep understanding on how the static footprint of some .o files changes,
> but it won't give us much information about the end result of the binary
> image, which is affected by the dependencies and compiler/linker
> optimizations. Is this correct?
>

Normally, bloat-o-meter gives you a rough idea and allows you to
weigh code complexity vs. size reduction.

>
> >> Signed-off-by: Walter Lozano 
> >> ---
> >>   drivers/core/ofnode.c | 132 +--
> >>   include/dm/read.h | 141 ++
> >>   2 files changed, 267 insertions(+), 6 deletions(-)
> >>
> > You should try to avoid adding #ifdefery to the code. Normally,
> > the way to ifdef code is by having this in a header:
> >
> > #ifdef CONFIG_FOO
> > int foo_feature_optional(struct foo *priv);
> > #else
> > static inline int foo_feature_optional(struct foo *priv)
> > {
> >  return 0;
> > }
> > #endif
> >
> > The user of foo_feature_optional shouldn't be bothered with
> > FOO being enabled or not. Pushing ifdefs away from .c to .h
> > is a common pattern, well described in a classic old article:
> >
> > http://www.literateprogramming.com/ifdefs.pdf
> >
> > Do you think you can try to rework the patch to reduce its impact
> > as much as possible?
>
>
> Thanks for your review and your suggestions, I will be happy to rework
> this to improve it.
>
>
> The intention of this RFC is to get some feedback about if this is
> something worth to be added and if this is the right approach. The use
> of OF_PLATDATA is quite limited as it needs drivers to support it, which
> will probably be a long process. Enabling it but having some drivers to
> query DT properties has no sense and requires additional dependencies,
> like libfdt.
>
> Also I think it should be possible to remove some extra components but
> it will require extra work to avoid break some configurations.
>

It's always good to shave off bytes, specially in SPL -- not so much
in proper U-Boot, right?

BTW, what is the motivation of this patch: which platform are you
working on, and
how is it size constrained?

Thanks,
Ezequiel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Aaron Williams]

Hi Tom,


From: Tom Rini
Sent: Tuesday, November 5, 2019 6:16 AM
To: Wolfgang Denk
Cc: Aaron Williams; Daniel Schwierzeck; u-boot@lists.denx.de
Subject: Re: [EXT] Re: Cavium/Marvell Octeon Support

On Tue, Nov 05, 2019 at 09:33:35AM +0100, Wolfgang Denk wrote:
> Dear Aaron,
>
> In message <5376617.97hUrJXovB@flash> you wrote:
> >
> > > Again you don't answer my question.  Why do you need a special new
> > > API for such code?  Why do you not just link that code with the rest
> > > of U-Boot?
> >
> > The code in question that is calling the API is not GPL and hence cannot be
> > linked with U-Boot though the phy code is GPL.
>
> Ouch.  I was afraid to hear that.
>
> Please be aware that your newly created API does NOT implement a GPL
> license exception.  the only interface that allows for non-GPL code
> to be run under control of U-Boot is the standalone program
> interface, which is intentionally very restricted.
>
> In other words: what you are doing here is a clear (and intentional,
> which makes it even worse) GPL license violation.
>
> > > It has been mentioned before, but just to be sure: this code which
> > > uses your new API is licensed under a GPLv2 conforming lincense?
> > >
> > There should be no need. None of the code is linked against U-Boot, either 
> > at
> > compile time nor at runtime. The application doesn't even know where it is
> > located except by looking for a named block of memory.
>
> It does not have to be linked.  You access internal interfaces of
> U-Boot that have not been exported for non-GPL use, so your code
> still has to be licensed under GPLv2 or a compatible license.

I'm just following up to say that I agree with Wolfgang here.

Sorry for the broken formatting (our IT department forces the Outhouse web 
client).

I think there is some misunderstanding here. All of the code we include in 
U-Boot IS GPL or GPL compatible, including the API.

"Even though U-Boot in general is covered by the GPL-2.0/GPL-2.0+,
this does *not* cover the so-called "standalone" applications that
use U-Boot services by means of the jump table provided by U-Boot
exactly for this purpose - this is merely considered normal use of
U-Boot, and does *not* fall under the heading of "derived work"."

No part of U-Boot is included in these applications and no application code is 
included in U-Boot. We DO have SDK files used in U-Boot, but the SDK files are 
under a BSD-like license, basically do whatever you want with the code but 
don't hold us responsible. The SDK code is also used in stand-alone 
applications as well as the Linux kernel, where derivatives were upstreamed 
long-ago.

In any event, I think at this point we can remove this support. I don't think 
it's used any longer. It also looks like EFI does allow for vendor defined 
services. I hadn't looked at this code for a while but looking at it again it 
also appears the phy code has been removed. I think the remaining code for QLM 
configuration could be modified to just use a hook from some environment 
variables, removing this issue entirely.

--
Tom

Regards,

Aaron
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [BUG] display_options() fails on Raspberry Pi 3B+

[Heinrich Schuchardt]

Hello Matthias,

Tom reported:

Since patch
143256b353c4d2ad1cf5e5e63b38410188b35e49
fdt: update bcm283x device tree sources to Linux 5.1-rc6 state

the console no longer shows the initial message, e.g. "U-Boot
2020.01-rc1-00159-g73b6e6ad25-dirty". This leads to a failure in
automated testing.

To find out what is happening I applied the following code change:

diff --git a/drivers/serial/serial_bcm283x_mu.c
b/drivers/serial/serial_bcm283x_mu.c
index bd1d89ec83..395c49c60a 100644
--- a/drivers/serial/serial_bcm283x_mu.c
+++ b/drivers/serial/serial_bcm283x_mu.c
@@ -171,8 +171,11 @@ static int
bcm283x_mu_serial_ofdata_to_platdata(struct udevice *dev)
fdt_addr_t addr;

/* Don't spawn the device if it's not muxed */
-   if (!bcm283x_is_serial_muxed())
+   if (!bcm283x_is_serial_muxed()) {
+   sprintf((void *)0x0240, "muxed4 false\n");
return -ENODEV;
+   }
+   sprintf((void *)0x02400010, "muxed5 true");

addr = devfdt_get_addr(dev);
if (addr == FDT_ADDR_T_NONE)
diff --git a/lib/display_options.c b/lib/display_options.c
index ec16d75e0e..9d44f49731 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -45,6 +45,7 @@ int display_options(void)

display_options_get_banner(true, buf, sizeof(buf));
printf("%s", buf);
+   sprintf((void *)0x0249, "disp5options");

return 0;
 }


And see:

0240: 6d 75 78 65 64 34 20 66 61 64 69 73 70 35 6f 70muxed4
fadisp5op
02400010: 6d 75 78 65 64 35 20 74 72 75 65 00 05 07 06 01muxed5
true.

bcm283x_mu_serial_ofdata_to_platdata() is obviously called twice.

The first call is in serial_init(). At that time the GPIOs are not
correctly set up to use the serial port. So display_options() fails.
After relocation another call call occurs after the GPIOs are set up and
this call succeeds.

Do you have an idea how to proceed?

Best regards

Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] USB doesn't work on Rockpro64 in u-boot

[Vasily Khoruzhick]

Hi Akash, Jagan,

Looks like USB is not functional in u-boot on Rockpro64. u-boot is
from git, commit 680023c5fab6b1777c0c6f2e76e5d2effb7903a0.

I'm using u-boot SPL and mainline ATF
(19adcb415c313d656324d54e7608cdc7d7a5c414 is ATF commit)

'usb start' doesn't detect anything but hubs and looks like there's no
power on USB ports:

=> usb start
starting USB...
Bus usb@fe38: USB EHCI 1.00
Bus usb@fe3c: USB EHCI 1.00
Bus dwc3: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus dwc3: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe38 for devices... 1 USB Device(s) found
scanning bus usb@fe3c for devices... 1 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found

=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
 u-boot EHCI Host Controller

  1  Hub (480 Mb/s, 0mA)
 u-boot EHCI Host Controller

  1  Hub (5 Gb/s, 0mA)
 U-Boot XHCI Host Controller

  1  Hub (5 Gb/s, 0mA)
 U-Boot XHCI Host Controller

Regulators were probed correctly according to 'dm tree':

 regulator14  [ + ]   fixed regulator   |-- vcc12v-dcin
 regulator15  [ + ]   fixed regulator   |-- vcc1v8-s3
 regulator16  [ + ]   fixed regulator   |-- vcc3v3-pcie-regulator
 regulator17  [ + ]   fixed regulator   |-- vcc3v3-sys
 regulator18  [ + ]   fixed regulator   |-- vcc5v0-host-regulator
 regulator19  [ + ]   fixed regulator   |-- vcc5v0-typec-regulator
 regulator20  [ + ]   fixed regulator   |-- vcc5v0-sys
 regulator21  [ + ]   fixed regulator   |-- vcc5v0-usb
 regulator22  [ + ]   pwm_regulator `-- vdd-log

Any ideas what can be wrong? Have it worked before?

Regards,
Vasily
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] gpio: fix CONFIG_IS_ENABLED(DM_GPIO) for SPL

[Stefan Roese]

Hi Baruch,

On 05.11.19 17:01, Baruch Siach wrote:

Hi Stefan,

On Tue, Nov 05, 2019 at 04:14:59PM +0100, Stefan Roese wrote:

On 03.11.19 10:52, Baruch Siach wrote:

There is currently no CONFIG_SPL_DM_GPIO, so CONFIG_IS_ENABLED(DM_GPIO)
is always false. As a result the sdhci driver can not use the DM gpio
API to read the card-detect signal in SPL. This breaks boot from SD card
on the SolidRun Clearfog platform since commit da18c62b6e ("mmc: sdhci:
Implement SDHCI card detect") that added sdhci_get_cd().

Add a blind CONFIG_SPL_DM_GPIO symbol that is enabled iff CONFIG_DM_GPIO
is. That makes CONFIG_IS_ENABLED(DM_GPIO) correct for SPL code.

Signed-off-by: Baruch Siach 
---
   drivers/gpio/Kconfig | 5 +
   1 file changed, 5 insertions(+)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c1ad5d64a35c..9bac341c5ed5 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -14,6 +14,11 @@ config DM_GPIO
  particular GPIOs that they provide. The uclass interface
  is defined in include/asm-generic/gpio.h.
+config SPL_DM_GPIO
+   bool
+   depends on DM_GPIO
+   default y
+
   config GPIO_HOG
bool "Enable GPIO hog support"
depends on DM_GPIO


I think its preferred to disable such SPL configurations per default
to not increase the code size here - which is pretty crucial on some
boards. Better to enable this SPL_DM_GPIO on your target or if it
makes sense on your platform (MVEBU perhaps with a select or imply
via the MMC driver in Kconfig).

What do you think?


Makes sense to me.

Should SPL_DM_GPIO be a blind symbol, or user selectable?


What are the other comparable SPL_DM_foo symbols? My first guess is
that they are user selectable.
 

Would it make sense to add

   select SPL_DM_GPIO if (SPL && DM_GPIO)

to CONFIG_MMC_SDHCI_MV?


Yes, I had something like this on my mind. Please give it a try and
submit v2 if it fits.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] gpio: fix CONFIG_IS_ENABLED(DM_GPIO) for SPL

[Bin Meng]

Hi Baruch,

On Sun, Nov 3, 2019 at 5:53 PM Baruch Siach  wrote:
>
> There is currently no CONFIG_SPL_DM_GPIO, so CONFIG_IS_ENABLED(DM_GPIO)
> is always false. As a result the sdhci driver can not use the DM gpio
> API to read the card-detect signal in SPL. This breaks boot from SD card
> on the SolidRun Clearfog platform since commit da18c62b6e ("mmc: sdhci:
> Implement SDHCI card detect") that added sdhci_get_cd().
>
> Add a blind CONFIG_SPL_DM_GPIO symbol that is enabled iff CONFIG_DM_GPIO
> is. That makes CONFIG_IS_ENABLED(DM_GPIO) correct for SPL code.
>
> Signed-off-by: Baruch Siach 
> ---
>  drivers/gpio/Kconfig | 5 +
>  1 file changed, 5 insertions(+)
>

Simon has a patch already for this, see
http://patchwork.ozlabs.org/patch/1180459/

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] gpio: fix CONFIG_IS_ENABLED(DM_GPIO) for SPL

[Stefan Roese]

Hi Bin,

On 06.11.19 06:47, Bin Meng wrote:

Hi Baruch,

On Sun, Nov 3, 2019 at 5:53 PM Baruch Siach  wrote:


There is currently no CONFIG_SPL_DM_GPIO, so CONFIG_IS_ENABLED(DM_GPIO)
is always false. As a result the sdhci driver can not use the DM gpio
API to read the card-detect signal in SPL. This breaks boot from SD card
on the SolidRun Clearfog platform since commit da18c62b6e ("mmc: sdhci:
Implement SDHCI card detect") that added sdhci_get_cd().

Add a blind CONFIG_SPL_DM_GPIO symbol that is enabled iff CONFIG_DM_GPIO
is. That makes CONFIG_IS_ENABLED(DM_GPIO) correct for SPL code.

Signed-off-by: Baruch Siach 
---
  drivers/gpio/Kconfig | 5 +
  1 file changed, 5 insertions(+)



Simon has a patch already for this, see
http://patchwork.ozlabs.org/patch/1180459/


Thanks for the link.

IIUTC, then the patch from Simon, which also takes care of the TPL GPIO
symbol, has the same potential problem that Baruch's patch has. Enabling
SPL/TPL_DM_GPIO per default might increase the SPL/TPL image size too
much. So it should probably default to 'n' and users / drivers should
enable (imply or select via Kconfig) those symbols when required.

What do you think?

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PULL] u-boot-mmc mmc-2019-11-5

[Peng Fan]

Hi Tom,

Please pull u-boot-mmc mmc-2019-11-5

CI: https://travis-ci.org/MrVan/u-boot/builds/607453537

---
fsl_esdhc driver cleanup
fsl_esdhc_imx driver improvement and compatible string update
---

Thanks,
Peng.

The following changes since commit 73b6e6ad254b36763419cdd3fdf406c0094517b7:

  Merge tag 'u-boot-imx-20191104' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2019-11-04 12:57:41 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-mmc.git tags/mmc-2019-11-5

for you to fetch changes up to f65d08411d76f01ddfb5d44909c667b91b847ddf:

  mmc: fsl_esdhc_imx: Update compatible string for imx8m (2019-11-05 11:21:25 
+0800)


Peng Fan (2):
  mmc: fsl_esdhc_imx: drop redundant clock settings
  mmc: fsl_esdhc_imx: Update compatible string for imx8m

Yangbo Lu (7):
  mmc: fsl_esdhc: drop controller initialization in fsl_esdhc_init()
  mmc: fsl_esdhc: fix voltage validation
  mmc: fsl_esdhc: clean up bus width configuration code
  mmc: fsl_esdhc: convert to use fsl_esdhc_get_cfg_common()
  mmc: fsl_esdhc: drop redundant code for non-removable feature
  mmc: fsl_esdhc: always check write protect state
  mmc: fsl_esdhc: clean up DM and non-DM code

 drivers/mmc/fsl_esdhc.c | 370 

 drivers/mmc/fsl_esdhc_imx.c |  15 --
 include/fsl_esdhc.h |  14 +++---
 3 files changed, 139 insertions(+), 260 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot