[PATCH v4 19/20] mips: mtmips: enable SPL for all boards

[Weijie Gao]

This patch enables SPL for all mtmips boards. And also remove defconfig
files which are intend to build ram bootable u-boot files.

SPL_DM and OF_CONTROL are enabled for both boards.

Reviewed-by: Stefan Roese 
Signed-off-by: Weijie Gao 
---
Changes since v3: none
---
 arch/mips/mach-mtmips/Kconfig | 26 ---
 board/gardena/smart-gateway-mt7688/board.c|  2 +
 ...gardena-smart-gateway-mt7688-ram_defconfig | 74 ---
 .../gardena-smart-gateway-mt7688_defconfig| 10 ++-
 configs/linkit-smart-7688-ram_defconfig   | 65 
 configs/linkit-smart-7688_defconfig   | 10 ++-
 .../configs/gardena-smart-gateway-mt7688.h| 20 -
 include/configs/linkit-smart-7688.h   | 21 +-
 8 files changed, 57 insertions(+), 171 deletions(-)
 delete mode 100644 configs/gardena-smart-gateway-mt7688-ram_defconfig
 delete mode 100644 configs/linkit-smart-7688-ram_defconfig

diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 493fe0b21d..2b8a848d18 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -61,7 +61,6 @@ config BOARD_GARDENA_SMART_GATEWAY_MT7688
bool "GARDENA smart Gateway"
depends on SOC_MT7628
select BOARD_LATE_INIT
-   select SUPPORTS_BOOT_RAM
help
  GARDENA smart Gateway boards have a MT7688 SoC with 128 MiB of RAM
  and 8 MiB of flash (SPI NOR) and additional SPI NAND storage.
@@ -69,7 +68,6 @@ config BOARD_GARDENA_SMART_GATEWAY_MT7688
 config BOARD_LINKIT_SMART_7688
bool "LinkIt Smart 7688"
depends on SOC_MT7628
-   select SUPPORTS_BOOT_RAM
help
  Seeed LinkIt Smart 7688 boards have a MT7688 SoC with 128 MiB of RAM
  and 32 MiB of flash (SPI).
@@ -79,30 +77,6 @@ config BOARD_LINKIT_SMART_7688
 
 endchoice
 
-choice
-   prompt "Boot mode"
-
-config BOOT_RAM
-   bool "RAM boot"
-   depends on SUPPORTS_BOOT_RAM
-   help
- This builds an image that is linked to a RAM address. It can be used
- for booting from CFE via TFTP using an ELF image, but it can also be
- booted from RAM by other bootloaders using a BIN image.
-
-config BOOT_ROM
-   bool "ROM boot"
-   depends on SUPPORTS_BOOT_RAM
-   help
- This builds an image that is linked to a ROM address. It can be
- used as main bootloader image which is programmed onto the onboard
- flash storage (SPI NOR).
-
-endchoice
-
-config SUPPORTS_BOOT_RAM
-   bool
-
 config SPL_UART2_SPIS_PINMUX
bool "Use alternative pinmux for UART2 in SPL stage"
depends on SPL_SERIAL_SUPPORT
diff --git a/board/gardena/smart-gateway-mt7688/board.c 
b/board/gardena/smart-gateway-mt7688/board.c
index 48cf3091e9..776afa43a6 100644
--- a/board/gardena/smart-gateway-mt7688/board.c
+++ b/board/gardena/smart-gateway-mt7688/board.c
@@ -295,8 +295,10 @@ err_free:
return ret;
 }
 
+#ifndef CONFIG_SPL_BUILD
 U_BOOT_CMD(
fd_write,   1,  0,  do_fd_write,
"Write test factory-data values to SPI NOR",
"\n"
 );
+#endif
diff --git a/configs/gardena-smart-gateway-mt7688-ram_defconfig 
b/configs/gardena-smart-gateway-mt7688-ram_defconfig
deleted file mode 100644
index 4b9559a46d..00
--- a/configs/gardena-smart-gateway-mt7688-ram_defconfig
+++ /dev/null
@@ -1,74 +0,0 @@
-CONFIG_MIPS=y
-CONFIG_SYS_TEXT_BASE=0x8001
-CONFIG_ENV_SIZE=0x1
-CONFIG_ENV_SECT_SIZE=0x1
-CONFIG_ENV_OFFSET=0xA
-CONFIG_SYS_BOOTCOUNT_ADDR=0xb06c
-CONFIG_NR_DRAM_BANKS=1
-CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
-CONFIG_ARCH_MTMIPS=y
-CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y
-# CONFIG_MIPS_BOOT_ENV_LEGACY is not set
-CONFIG_MIPS_BOOT_FDT=y
-CONFIG_ENV_VARS_UBOOT_CONFIG=y
-CONFIG_FIT=y
-CONFIG_FIT_SIGNATURE=y
-CONFIG_LEGACY_IMAGE_FORMAT=y
-CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="cp.b 8300 8400 1 && dhcp uEnv.txt && env 
import -t ${fileaddr} ${filesize} && run do_u_boot_init; reset"
-CONFIG_USE_PREBOOT=y
-CONFIG_SYS_CONSOLE_INFO_QUIET=y
-CONFIG_VERSION_VARIABLE=y
-CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_LICENSE=y
-# CONFIG_CMD_ELF is not set
-# CONFIG_CMD_XIMG is not set
-CONFIG_CMD_MEMINFO=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_GPIO=y
-# CONFIG_CMD_LOADS is not set
-CONFIG_CMD_MTD=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_WDT=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_BOOTCOUNT=y
-CONFIG_CMD_TIME=y
-CONFIG_CMD_UUID=y
-CONFIG_CMD_MTDPARTS=y
-CONFIG_MTDIDS_DEFAULT="spi-nand0=spi0.1,nor0=spi0.0"
-CONFIG_MTDPARTS_DEFAULT="spi0.0:640k(uboot),64k(uboot_env0),64k(uboot_env1),64k(factory),-(unused);spi0.1:-(nand)"
-CONFIG_CMD_UBI=y
-CONFIG_DEFAULT_DEVICE_TREE="gardena-smart-gateway-mt7688"
-CONFIG_ENV_IS_IN_SPI_FLASH=y
-CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
-CONFIG_ENV_OFFSET_REDUND=0xB
-CONFIG_SYS_RELOC_GD_ENV_ADDR=y
-CONFIG_NET_RANDOM_ETHADDR=y
-# CONFIG_DM_DEVICE_REMOVE is not 

[PATCH v4 16/20] tools: binman: add etype file for u-boot-lzma-img

[Weijie Gao]

This patch adds etype u-boot-lzma-img for binman. README.entries is also
updated.

Reviewed-by: Stefan Roese 
Signed-off-by: Weijie Gao 
---
Changes since v3: add a test to make sure 100% code coverage
---
 tools/binman/README.entries   | 15 
 tools/binman/etype/u_boot_lzma_img.py | 28 +++
 tools/binman/ftest.py |  7 ++
 tools/binman/test/156_u_boot_lzma_img.dts | 11 +
 4 files changed, 61 insertions(+)
 create mode 100644 tools/binman/etype/u_boot_lzma_img.py
 create mode 100644 tools/binman/test/156_u_boot_lzma_img.dts

diff --git a/tools/binman/README.entries b/tools/binman/README.entries
index 6a816bba6b..0aea9b8f6d 100644
--- a/tools/binman/README.entries
+++ b/tools/binman/README.entries
@@ -747,6 +747,21 @@ applications.
 
 
 
+Entry: u-boot-lzma-img: U-Boot legacy image with contents compressed by LZMA
+
+
+Properties / Entry arguments:
+- filename: Filename of u-boot-lzma.img (default 'u-boot-lzma.img')
+
+This is the U-Boot binary as a packaged image, in legacy format. It has a
+header which allows it to be loaded at the correct address for execution.
+Its contents are compressed by LZMA.
+
+You should use FIT (Flat Image Tree) instead of the legacy image for new
+applications.
+
+
+
 Entry: u-boot-nodtb: U-Boot flat binary without device tree appended
 
 
diff --git a/tools/binman/etype/u_boot_lzma_img.py 
b/tools/binman/etype/u_boot_lzma_img.py
new file mode 100644
index 00..966d6a46da
--- /dev/null
+++ b/tools/binman/etype/u_boot_lzma_img.py
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2020 MediaTek Inc. All Rights Reserved.
+# Author: Weijie Gao 
+#
+# Entry-type module for U-Boot legacy image with contents compressed by LZMA
+#
+
+from entry import Entry
+from blob import Entry_blob
+
+class Entry_u_boot_lzma_img(Entry_blob):
+"""U-Boot legacy image with contents compressed by LZMA
+
+Properties / Entry arguments:
+- filename: Filename of u-boot-lzma.img (default 'u-boot-lzma.img')
+
+This is the U-Boot binary as a packaged image, in legacy format. It has a
+header which allows it to be loaded at the correct address for execution.
+Its contents are compressed by LZMA.
+
+You should use FIT (Flat Image Tree) instead of the legacy image for new
+applications.
+"""
+def __init__(self, section, etype, node):
+Entry_blob.__init__(self, section, etype, node)
+
+def GetDefaultFilename(self):
+return 'u-boot-lzma.img'
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 872b855444..0ff7487b96 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -39,6 +39,7 @@ import tout
 # Contents of test files, corresponding to different entry types
 U_BOOT_DATA   = b'1234'
 U_BOOT_IMG_DATA   = b'img'
+U_BOOT_LZMA_IMG_DATA  = b'lzma-img'
 U_BOOT_SPL_DATA   = b'56780123456789abcdefghi'
 U_BOOT_TPL_DATA   = b'tpl9876543210fedcbazyw'
 BLOB_DATA = b'89'
@@ -115,6 +116,7 @@ class TestFunctional(unittest.TestCase):
 # Create some test files
 TestFunctional._MakeInputFile('u-boot.bin', U_BOOT_DATA)
 TestFunctional._MakeInputFile('u-boot.img', U_BOOT_IMG_DATA)
+TestFunctional._MakeInputFile('u-boot-lzma.img', U_BOOT_LZMA_IMG_DATA)
 TestFunctional._MakeInputFile('spl/u-boot-spl.bin', U_BOOT_SPL_DATA)
 TestFunctional._MakeInputFile('tpl/u-boot-tpl.bin', U_BOOT_TPL_DATA)
 TestFunctional._MakeInputFile('blobfile', BLOB_DATA)
@@ -1078,6 +1080,11 @@ class TestFunctional(unittest.TestCase):
 data = self._DoReadFile('036_u_boot_img.dts')
 self.assertEqual(U_BOOT_IMG_DATA, data)
 
+def testUBootLzmaImg(self):
+"""Test that u-boot-lzma.img can be put in a file"""
+data = self._DoReadFile('156_u_boot_lzma_img.dts')
+self.assertEqual(U_BOOT_LZMA_IMG_DATA, data)
+
 def testNoMicrocode(self):
 """Test that a missing microcode region is detected"""
 with self.assertRaises(ValueError) as e:
diff --git a/tools/binman/test/156_u_boot_lzma_img.dts 
b/tools/binman/test/156_u_boot_lzma_img.dts
new file mode 100644
index 00..f49d014216
--- /dev/null
+++ b/tools/binman/test/156_u_boot_lzma_img.dts
@@ -0,0 +1,11 @@
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   binman {
+   u-boot-lzma-img {
+   };
+   };
+};
-- 
2.17.1

[PATCH v4 15/20] Makefile: add support to generate LZMA compressed u-boot image

[Weijie Gao]

This patch adds support for generating LZMA compressed u-boot image.
The compressed image can be used for SPL to reduce the size of the u-boot
binary.

Reviewed-by: Stefan Roese 
Reviewed-by: Daniel Schwierzeck 
Reviewed-by: Simon Glass 
Signed-off-by: Weijie Gao 
---
Changes since v3: none
---
 Makefile | 13 +
 1 file changed, 13 insertions(+)

diff --git a/Makefile b/Makefile
index f899659a9a..8aed5bbca4 100644
--- a/Makefile
+++ b/Makefile
@@ -954,6 +954,9 @@ append = cat $(filter-out $< $(PHONY), $^) >> $@
 quiet_cmd_pad_cat = CAT $@
 cmd_pad_cat = $(cmd_objcopy) && $(append) || rm -f $@
 
+quiet_cmd_lzma = LZMA$@
+cmd_lzma = lzma -c -z -k -9 $< > $@
+
 cfg: u-boot.cfg
 
 quiet_cmd_cfgcheck = CFGCHK  $2
@@ -1336,6 +1339,16 @@ else
 UBOOT_BIN := u-boot.bin
 endif
 
+MKIMAGEFLAGS_u-boot-lzma.img = -A $(ARCH) -T standalone -C lzma -O u-boot \
+   -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
+   -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
+
+u-boot.bin.lzma: u-boot.bin FORCE
+   $(call if_changed,lzma)
+
+u-boot-lzma.img: u-boot.bin.lzma FORCE
+   $(call if_changed,mkimage)
+
 u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \
$(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \
$(if 
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE),dts/dt.dtb) \
-- 
2.17.1

[PATCH v4 17/20] spl: nor: add lzma decompression support for legacy image

[Weijie Gao]

This patch adds support for decompressing LZMA compressed u-boot payload in
legacy uImage format.

Using this patch together with u-boot-lzma.img is useful for NOR flashes as
they can reduce the size and load time of u-boot payload.

Reviewed-by: Stefan Roese 
Signed-off-by: Weijie Gao 
---
Changes since v3: none
---
 common/spl/spl_nor.c | 59 
 1 file changed, 54 insertions(+), 5 deletions(-)

diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
index b1e79b9ded..7c81fb28f6 100644
--- a/common/spl/spl_nor.c
+++ b/common/spl/spl_nor.c
@@ -4,8 +4,19 @@
  */
 
 #include 
+#include 
 #include 
 
+#if IS_ENABLED(CONFIG_SPL_LZMA)
+#include 
+#include 
+#include 
+#endif
+
+#ifndef CONFIG_SYS_BOOTM_LEN
+#define CONFIG_SYS_BOOTM_LEN   (8 << 20)
+#endif
+
 static ulong spl_nor_load_read(struct spl_load_info *load, ulong sector,
   ulong count, void *buf)
 {
@@ -27,6 +38,9 @@ static int spl_nor_load_image(struct spl_image_info 
*spl_image,
int ret;
__maybe_unused const struct image_header *header;
__maybe_unused struct spl_load_info load;
+   __maybe_unused SizeT lzma_len;
+   struct image_header hdr;
+   uintptr_t dataptr;
 
/*
 * Loading of the payload to SDRAM is done with skipping of
@@ -107,14 +121,49 @@ static int spl_nor_load_image(struct spl_image_info 
*spl_image,
  spl_nor_get_uboot_base());
}
 
-   ret = spl_parse_image_header(spl_image,
-   (const struct image_header *)spl_nor_get_uboot_base());
+   /* Payload image may not be aligned, so copy it for safety. */
+   memcpy(, (void *)spl_nor_get_uboot_base(), sizeof(hdr));
+   ret = spl_parse_image_header(spl_image, );
if (ret)
return ret;
 
-   memcpy((void *)(unsigned long)spl_image->load_addr,
-  (void *)(spl_nor_get_uboot_base() + sizeof(struct image_header)),
-  spl_image->size);
+   dataptr = spl_nor_get_uboot_base() + sizeof(struct image_header);
+
+   switch (image_get_comp()) {
+   case IH_COMP_NONE:
+   memmove((void *)(unsigned long)spl_image->load_addr,
+   (void *)dataptr, spl_image->size);
+   break;
+#if IS_ENABLED(CONFIG_SPL_LZMA)
+   case IH_COMP_LZMA:
+   lzma_len = CONFIG_SYS_BOOTM_LEN;
+
+   ret = lzmaBuffToBuffDecompress((void *)spl_image->load_addr,
+  _len, (void *)dataptr,
+  spl_image->size);
+
+   if (ret) {
+   printf("LZMA decompression error: %d\n", ret);
+   return ret;
+   }
+
+   spl_image->size = lzma_len;
+   break;
+#endif
+   default:
+   debug("Compression method %s is not supported\n",
+ genimg_get_comp_short_name(image_get_comp()));
+   return -EINVAL;
+   }
+
+   flush_cache((unsigned long)spl_image->load_addr, spl_image->size);
+
+   /*
+* If the image did not provide an entry point, assume the entry point
+* is the same as its load address.
+*/
+   if (!spl_image->entry_point)
+   spl_image->entry_point = spl_image->load_addr;
 
return 0;
 }
-- 
2.17.1

[PATCH v4 20/20] mips: mtmips: add support for mt7628-rfb

[Weijie Gao]

This patch adds support for mt7628 reference board. SPL_DM and DT are not
enabled for SPL to save about 17KiB for u-boot-spl.bin.

Reviewed-by: Stefan Roese 
Signed-off-by: Weijie Gao 
---
Changes since v3: none
---
 arch/mips/dts/Makefile|  1 +
 arch/mips/dts/mediatek,mt7628-rfb.dts | 67 +++
 arch/mips/mach-mtmips/Kconfig |  9 
 board/mediatek/mt7628/Kconfig | 12 +
 board/mediatek/mt7628/MAINTAINERS |  7 +++
 board/mediatek/mt7628/Makefile|  3 ++
 board/mediatek/mt7628/board.c |  8 
 configs/mt7628_rfb_defconfig  | 46 ++
 include/configs/mt7628.h  | 55 ++
 9 files changed, 208 insertions(+)
 create mode 100644 arch/mips/dts/mediatek,mt7628-rfb.dts
 create mode 100644 board/mediatek/mt7628/Kconfig
 create mode 100644 board/mediatek/mt7628/MAINTAINERS
 create mode 100644 board/mediatek/mt7628/Makefile
 create mode 100644 board/mediatek/mt7628/board.c
 create mode 100644 configs/mt7628_rfb_defconfig
 create mode 100644 include/configs/mt7628.h

diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index c9d75596f2..cbd0c8bc8b 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -17,6 +17,7 @@ dtb-$(CONFIG_BOARD_COMTREND_CT5361) += comtrend,ct-5361.dtb
 dtb-$(CONFIG_BOARD_COMTREND_VR3032U) += comtrend,vr-3032u.dtb
 dtb-$(CONFIG_BOARD_COMTREND_WAP5813N) += comtrend,wap-5813n.dtb
 dtb-$(CONFIG_BOARD_HUAWEI_HG556A) += huawei,hg556a.dtb
+dtb-$(CONFIG_BOARD_MT7628_RFB) += mediatek,mt7628-rfb.dtb
 dtb-$(CONFIG_BOARD_NETGEAR_CG3100D) += netgear,cg3100d.dtb
 dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += netgear,dgnd3700v2.dtb
 dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
diff --git a/arch/mips/dts/mediatek,mt7628-rfb.dts 
b/arch/mips/dts/mediatek,mt7628-rfb.dts
new file mode 100644
index 00..6ff36daa6e
--- /dev/null
+++ b/arch/mips/dts/mediatek,mt7628-rfb.dts
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ *
+ * Author: Weijie Gao 
+ */
+
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+
+/ {
+   compatible = "mediatek,mt7628-rfb", "ralink,mt7628a-soc";
+   model = "MediaTek MT7628 RFB";
+
+   aliases {
+   serial0 = 
+   spi0 = 
+   };
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   state_default: pin_state {
+   pleds {
+   groups = "p0led", "p1led", "p2led", "p3led", "p4led";
+   function = "led";
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   num-cs = <2>;
+
+   spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   spi-max-frequency = <2500>;
+   reg = <0>;
+   };
+};
+
+ {
+   mediatek,wan-port = <0>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_router_mode>;
+};
+
+ {
+   bus-width = <4>;
+   cap-sd-highspeed;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_router_mode>;
+
+   status = "okay";
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 2b8a848d18..bcd635f438 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -75,6 +75,14 @@ config BOARD_LINKIT_SMART_7688
  ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
  a MT7688 (PCIe).
 
+config BOARD_MT7628_RFB
+   bool "MediaTek MT7628 RFB"
+   depends on SOC_MT7628
+   help
+ The reference design of MT7628. The board has 128 MiB DDR2, 8 MiB
+ SPI-NOR flash, 1 built-in switch with 5 ports, 1 UART, 1 USB host,
+ 1 SDXC, 1 PCIe socket and JTAG pins.
+
 endchoice
 
 config SPL_UART2_SPIS_PINMUX
@@ -86,6 +94,7 @@ config SPL_UART2_SPIS_PINMUX
  (shared with SPIS) rather than the usual GPIO 20/21.
 
 source "board/gardena/smart-gateway-mt7688/Kconfig"
+source "board/mediatek/mt7628/Kconfig"
 source "board/seeed/linkit-smart-7688/Kconfig"
 
 endmenu
diff --git a/board/mediatek/mt7628/Kconfig b/board/mediatek/mt7628/Kconfig
new file mode 100644
index 00..d6b6f9d632
--- /dev/null
+++ b/board/mediatek/mt7628/Kconfig
@@ -0,0 +1,12 @@
+if BOARD_MT7628_RFB
+
+config SYS_BOARD
+   default "mt7628"
+
+config SYS_VENDOR
+   default "mediatek"
+
+config SYS_CONFIG_NAME
+   default "mt7628"
+
+endif
diff --git a/board/mediatek/mt7628/MAINTAINERS 
b/board/mediatek/mt7628/MAINTAINERS
new file mode 100644
index 00..032fd0e2f7
--- /dev/null
+++ b/board/mediatek/mt7628/MAINTAINERS
@@ -0,0 +1,7 @@
+MT7628_RFB BOARD
+M: Weijie Gao 
+S: Maintained
+F: board/mediatek/mt7628
+F: include/configs/mt7628.h
+F: configs/mt7628_rfb_defconfig
+F: arch/mips/dts/mediatek,mt7628-rfb.dts
diff --git a/board/mediatek/mt7628/Makefile 

[PATCH v4 18/20] mips: mtmips: add SPL support

[Weijie Gao]

This patch adds SPL support for mtmips platform. The lowlevel architecture
is split into SPL and the rest parts are built into a memory loadable
u-boot image. Optional SPL_DM and OF_CONTROL are also supported.

The increment of size is very small (< 10 KiB) if SPL_DM and OF_CONTROL are
not enabled and the memory bootable u-boot (u-boot.img) is generated
automatically so there is not need to add a separate config for it.

A lzma compressed payload (u-boot-lzma.img) is also generated and it will
be combined with u-boot-spl.bin to form the unified ROM bootable binary
u-boot-mtmips.bin.

A spl loader is added to support uncompress the payload.

Reviewed-by: Stefan Roese 
Signed-off-by: Weijie Gao 
---
Changes since v3: rename output file to u-boot-mips.bin
---
 Makefile|  9 
 arch/mips/Kconfig   |  3 ++
 arch/mips/dts/mt7628-u-boot.dtsi| 56 +
 arch/mips/dts/mt7628a.dtsi  |  2 +-
 arch/mips/mach-mtmips/Kconfig   | 23 +
 arch/mips/mach-mtmips/Makefile  |  1 +
 arch/mips/mach-mtmips/include/mach/serial.h | 13 +
 arch/mips/mach-mtmips/mt7628/Makefile   |  1 +
 arch/mips/mach-mtmips/mt7628/serial.c   | 34 +
 arch/mips/mach-mtmips/spl.c | 44 
 10 files changed, 185 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/dts/mt7628-u-boot.dtsi
 create mode 100644 arch/mips/mach-mtmips/include/mach/serial.h
 create mode 100644 arch/mips/mach-mtmips/mt7628/serial.c
 create mode 100644 arch/mips/mach-mtmips/spl.c

diff --git a/Makefile b/Makefile
index 8aed5bbca4..f80d4d27a5 100644
--- a/Makefile
+++ b/Makefile
@@ -897,6 +897,7 @@ ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
 endif
 
 ALL-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
+ALL-$(CONFIG_ARCH_MTMIPS) += u-boot-mips.bin
 
 # Add optional build target if defined in board/cpu/soc headers
 ifneq ($(CONFIG_BUILD_TARGET),)
@@ -1692,6 +1693,14 @@ u-boot-mtk.bin: u-boot.bin FORCE
$(call if_changed,mkimage)
 endif
 
+ifeq ($(CONFIG_SPL),y)
+u-boot-mips.bin: u-boot.dtb u-boot-lzma.img spl/u-boot-spl.bin FORCE
+   $(call if_changed,binman)
+else
+u-boot-mips.bin: u-boot.bin FORCE
+   $(call if_changed,copy)
+endif
+
 ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
 
 # Rule to link u-boot
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 7b9d0072eb..4c1eea1ccc 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -98,6 +98,9 @@ config ARCH_MTMIPS
select SUPPORTS_CPU_MIPS32_R2
select SUPPORTS_LITTLE_ENDIAN
select SYSRESET
+   select SUPPORT_SPL
+   select SPL_LZMA
+   select BINMAN
 
 config ARCH_JZ47XX
bool "Support Ingenic JZ47xx"
diff --git a/arch/mips/dts/mt7628-u-boot.dtsi b/arch/mips/dts/mt7628-u-boot.dtsi
new file mode 100644
index 00..9149187762
--- /dev/null
+++ b/arch/mips/dts/mt7628-u-boot.dtsi
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ *
+ * Author: Weijie Gao 
+ */
+
+/ {
+   binman {
+   filename = "u-boot-mips.bin";
+   pad-byte = <0xff>;
+
+#ifdef CONFIG_SPL
+   u-boot-spl {
+   };
+
+   u-boot-lzma-img {
+   };
+#else
+   u-boot {
+   };
+#endif
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 2200135a77..6baa63add3 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -33,7 +33,7 @@
#clock-cells = <0>;
};
 
-   palmbus@1000 {
+   palmbus: palmbus@1000 {
compatible = "palmbus", "simple-bus";
reg = <0x1000 0x20>;
ranges = <0x0 0x1000 0x1F>;
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 3f25de8b85..493fe0b21d 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -20,8 +20,15 @@ config SYS_ICACHE_LINE_SIZE
default 32
 
 config SYS_TEXT_BASE
+   default 0x9c00 if !SPL
+   default 0x8020 if SPL
+
+config SPL_TEXT_BASE
default 0x9c00
 
+config SPL_LOADER_SUPPORT
+   default y
+
 choice
prompt "MediaTek MIPS SoC select"
 
@@ -34,6 +41,14 @@ config SOC_MT7628
select PINCTRL_MT7628
select MTK_SERIAL
select SYSRESET_RESETCTL
+   select SPL_SEPARATE_BSS if SPL
+   select SPL_INIT_STACK_WITHOUT_MALLOC_F if SPL
+   select SPL_OF_CONTROL if SPL_DM
+   select SPL_SIMPLE_BUS if SPL_DM
+   select 

[PATCH v4 07/20] configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips boards

[Weijie Gao]

This patch enables CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips
boards.

Reviewed-by: Stefan Roese 
Reviewed-by: Daniel Schwierzeck 
Signed-off-by: Weijie Gao 
---
Changes since v3: none
---
 configs/gardena-smart-gateway-mt7688-ram_defconfig | 1 +
 configs/gardena-smart-gateway-mt7688_defconfig | 1 +
 configs/linkit-smart-7688-ram_defconfig| 1 +
 configs/linkit-smart-7688_defconfig| 1 +
 4 files changed, 4 insertions(+)

diff --git a/configs/gardena-smart-gateway-mt7688-ram_defconfig 
b/configs/gardena-smart-gateway-mt7688-ram_defconfig
index 2015eb2c07..4b9559a46d 100644
--- a/configs/gardena-smart-gateway-mt7688-ram_defconfig
+++ b/configs/gardena-smart-gateway-mt7688-ram_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_BOOTCOUNT_ADDR=0xb06c
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
 CONFIG_ARCH_MTMIPS=y
+CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y
 # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
 CONFIG_MIPS_BOOT_FDT=y
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
diff --git a/configs/gardena-smart-gateway-mt7688_defconfig 
b/configs/gardena-smart-gateway-mt7688_defconfig
index c816021c7c..9e3969e724 100644
--- a/configs/gardena-smart-gateway-mt7688_defconfig
+++ b/configs/gardena-smart-gateway-mt7688_defconfig
@@ -10,6 +10,7 @@ CONFIG_ARCH_MTMIPS=y
 CONFIG_BOOT_ROM=y
 CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y
 CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y
+CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y
 # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
 CONFIG_MIPS_BOOT_FDT=y
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
diff --git a/configs/linkit-smart-7688-ram_defconfig 
b/configs/linkit-smart-7688-ram_defconfig
index 7f29617ddc..1db94db41f 100644
--- a/configs/linkit-smart-7688-ram_defconfig
+++ b/configs/linkit-smart-7688-ram_defconfig
@@ -6,6 +6,7 @@ CONFIG_ENV_OFFSET=0x8
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_ARCH_MTMIPS=y
 CONFIG_BOARD_LINKIT_SMART_7688=y
+CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y
 # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
 CONFIG_MIPS_BOOT_FDT=y
 CONFIG_FIT=y
diff --git a/configs/linkit-smart-7688_defconfig 
b/configs/linkit-smart-7688_defconfig
index 484c338348..7993976443 100644
--- a/configs/linkit-smart-7688_defconfig
+++ b/configs/linkit-smart-7688_defconfig
@@ -9,6 +9,7 @@ CONFIG_BOARD_LINKIT_SMART_7688=y
 CONFIG_BOOT_ROM=y
 CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y
 CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y
+CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y
 # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
 CONFIG_MIPS_BOOT_FDT=y
 CONFIG_FIT=y
-- 
2.17.1

[PATCH v4 09/20] mips: add a option to support not reserving malloc space on initial stack

[Weijie Gao]

The initial stack on some platforms is too small to hold a large malloc
space. This patch adds a option to allow these platforms not reserving the
malloc space on initial stack. These platforms should set the malloc base
after DRAM is usable.

Reviewed-by: Stefan Roese 
Signed-off-by: Weijie Gao 
---
Changes since v3: none
---
 arch/mips/Kconfig | 18 ++
 arch/mips/cpu/start.S |  6 --
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index bf30a56101..5f82caf8be 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -317,6 +317,24 @@ config NEW_EXCEPTION_VECTOR_BASE
help
  The exception vector base to be restored before booting linux kernel
 
+config INIT_STACK_WITHOUT_MALLOC_F
+   bool "Do not reserve malloc space on initial stack"
+   default n
+   help
+ Enable this option if you don't want to reserve malloc space on
+ initial stack. This is useful if the initial stack can't hold large
+ malloc space. Platform should set the malloc_base later when DRAM is
+ ready to use.
+
+config SPL_INIT_STACK_WITHOUT_MALLOC_F
+   bool "Do not reserve malloc space on initial stack in SPL"
+   default n
+   help
+ Enable this option if you don't want to reserve malloc space on
+ initial stack. This is useful if the initial stack can't hold large
+ malloc space. Platform should set the malloc_base later when DRAM is
+ ready to use.
+
 endmenu
 
 menu "OS boot interface"
diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S
index dd93df9e4a..6de9a2f362 100644
--- a/arch/mips/cpu/start.S
+++ b/arch/mips/cpu/start.S
@@ -59,7 +59,8 @@
sp, sp, GD_SIZE # reserve space for gd
and sp, sp, t0  # force 16 byte alignment
movek0, sp  # save gd pointer
-#if CONFIG_VAL(SYS_MALLOC_F_LEN)
+#if CONFIG_VAL(SYS_MALLOC_F_LEN) && \
+!CONFIG_IS_ENABLED(INIT_STACK_WITHOUT_MALLOC_F)
li  t2, CONFIG_VAL(SYS_MALLOC_F_LEN)
PTR_SUBU \
sp, sp, t2  # reserve space for early malloc
@@ -75,7 +76,8 @@
blt t0, t1, 1b
 nop
 
-#if CONFIG_VAL(SYS_MALLOC_F_LEN)
+#if CONFIG_VAL(SYS_MALLOC_F_LEN) && \
+!CONFIG_IS_ENABLED(INIT_STACK_WITHOUT_MALLOC_F)
PTR_S   sp, GD_MALLOC_BASE(k0)  # gd->malloc_base offset
 #endif
.endm
-- 
2.17.1

[PATCH v4 14/20] lib: enable lzma decompression support for SPL build

[Weijie Gao]

This patch enables LZMA decompression support for SPL build

Reviewed-by: Stefan Roese 
Reviewed-by: Tom Rini 
Signed-off-by: Weijie Gao 
---
Changes since v3: none
---
 lib/Kconfig  | 5 +
 lib/Makefile | 1 +
 2 files changed, 6 insertions(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index ab6aff710d..5f52f14686 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -429,6 +429,11 @@ config SPL_LZ4
  fast compression and decompression speed. It belongs to the LZ77
  family of byte-oriented compression schemes.
 
+config SPL_LZMA
+   bool "Enable LZMA decompression support for SPL build"
+   help
+ This enables support for LZMA compression altorithm for SPL boot.
+
 config SPL_LZO
bool "Enable LZO decompression support in SPL"
help
diff --git a/lib/Makefile b/lib/Makefile
index 15259d0473..fa497a366d 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_$(SPL_)ZLIB) += zlib/
 obj-$(CONFIG_$(SPL_)ZSTD) += zstd/
 obj-$(CONFIG_$(SPL_)GZIP) += gunzip.o
 obj-$(CONFIG_$(SPL_)LZO) += lzo/
+obj-$(CONFIG_$(SPL_)LZMA) += lzma/
 obj-$(CONFIG_$(SPL_)LZ4) += lz4_wrapper.o
 
 obj-$(CONFIG_LIBAVB) += libavb/
-- 
2.17.1

[PATCH v4 00/20] Refactor the architecture parts of mt7628

[Weijie Gao]

This patch series are divided into two parts:

The main part is to rewrite the whole architecture code of mt7628:
* Lock parts of the d-cache for initial stack so the rest of the code can
  be reimplemented in C.
* Memory controller & DDR initialization have been fully written to support
  detecting DDR size automatically.
* DDR calibration has also been reimplemented with a clear logic.
* Implemented a new sysreset driver to take advantage of the reset
  controller so we can drop the use of syscon-based sysreset to reduce size.

The second part is to add SPL support for mt7628:
* With SPL enabled we can build the ROM-bootable and RAM-bootable binary
  simultaneously, and we can drop RAM boot related configs and defconfig
  files.
* Generate compressed u-boot.bin image for SPL to reduce size of final
  combined binary.
* Enable DM support for SPL for a more flexible device probing.
* Add a demo board (mt7628_rfb) aims at router application.

Changes since v2:
* Dropped a patch which removes unused parts of mt7628a.dtsi
* Move lzma decompression support to common spl_nor.c
* Move u-boot,dm-pre-reloc to u-boot-mt7628.dtsi

Changes since v3:
* Rebased on newest master branch
* Add a test for binman etype u-boot-lzma-img to make sure binman passes 100%
  code coverage
* Rename SPL-enabled output file name to u-boot-mips.bin

Weijie Gao (20):
  mips: add support to restore exception vector base before booting
linux
  mips: mtmips: add predefined i-cache/d-cache size and linesize
  mips: add an option to support initialize SRAM for initial stack
  mips: start.S: avoid overwriting outside gd when clearing global data
in stack
  sysreset: add reset controller based reboot driver
  mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
  configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips
boards
  mips: add a mtmips-specific field to architecture-specific global data
  mips: add a option to support not reserving malloc space on initial
stack
  mips: mtmips: rewrite lowlevel codes of mt7628
  dts: mtmips: add alternative pinmux node for uart2
  mips: enable support for appending dtb to spl binary
  mips: add an option to enable u_boot_list section for SPL loaders in
u-boot-spl.lds
  lib: enable lzma decompression support for SPL build
  Makefile: add support to generate LZMA compressed u-boot image
  tools: binman: add etype file for u-boot-lzma-img
  spl: nor: add lzma decompression support for legacy image
  mips: mtmips: add SPL support
  mips: mtmips: enable SPL for all boards
  mips: mtmips: add support for mt7628-rfb

 Makefile  |  22 ++
 arch/mips/Kconfig |  66 
 arch/mips/cpu/start.S |  16 +-
 arch/mips/cpu/u-boot-spl.lds  |   4 +-
 arch/mips/dts/Makefile|   1 +
 arch/mips/dts/mediatek,mt7628-rfb.dts |  67 
 arch/mips/dts/mt7628-u-boot.dtsi  |  56 +++
 arch/mips/dts/mt7628a.dtsi|  17 +-
 arch/mips/include/asm/global_data.h   |   3 +
 arch/mips/include/asm/u-boot-mips.h   |   2 +
 arch/mips/lib/bootm.c |   3 +
 arch/mips/lib/traps.c |  19 +
 arch/mips/mach-mtmips/Kconfig | 132 +++
 arch/mips/mach-mtmips/Makefile|   8 +-
 arch/mips/mach-mtmips/cpu.c   |  58 +---
 arch/mips/mach-mtmips/ddr_cal.c   | 211 +++
 arch/mips/mach-mtmips/ddr_calibrate.c | 309 -
 arch/mips/mach-mtmips/ddr_init.c  | 194 +++
 arch/mips/mach-mtmips/include/mach/ddr.h  |  52 +++
 arch/mips/mach-mtmips/include/mach/mc.h   | 180 ++
 arch/mips/mach-mtmips/include/mach/serial.h   |  13 +
 arch/mips/mach-mtmips/lowlevel_init.S | 328 --
 arch/mips/mach-mtmips/mt7628/Makefile |   6 +
 arch/mips/mach-mtmips/mt7628/ddr.c| 173 +
 arch/mips/mach-mtmips/mt7628/init.c   | 109 ++
 arch/mips/mach-mtmips/mt7628/lowlevel_init.S  | 161 +
 arch/mips/mach-mtmips/mt7628/mt7628.h | 104 ++
 arch/mips/mach-mtmips/mt7628/serial.c |  34 ++
 arch/mips/mach-mtmips/mt76xx.h|  32 --
 arch/mips/mach-mtmips/spl.c   |  44 +++
 board/gardena/smart-gateway-mt7688/board.c|   2 +
 board/mediatek/mt7628/Kconfig |  12 +
 board/mediatek/mt7628/MAINTAINERS |   7 +
 board/mediatek/mt7628/Makefile|   3 +
 board/mediatek/mt7628/board.c |   8 +
 common/spl/spl_nor.c  |  59 +++-
 ...gardena-smart-gateway-mt7688-ram_defconfig |  74 
 .../gardena-smart-gateway-mt7688_defconfig|  14 +-
 configs/linkit-smart-7688-ram_defconfig   |  65 
 configs/linkit-smart-7688_defconfig   |  14 +-
 configs/mt7628_rfb_defconfig  |  46 +++
 

[PATCH v4 01/20] mips: add support to restore exception vector base before booting linux

[Weijie Gao]

In U-Boot the exception vector base will be moved to top of memory, to be
used to display register dump when exception occurs.

But some old linux kernel does not honor the base set in CP0_EBASE. A
modified exception vector base will cause kernel crash.

This patch adds an option to enable reset exception vector base to its
previous value, or a user configured value before booting linux kernel.

Reviewed-by: Daniel Schwierzeck 
Signed-off-by: Weijie Gao 
---
Changes since v3: none
---
 arch/mips/Kconfig   | 30 +
 arch/mips/include/asm/u-boot-mips.h |  2 ++
 arch/mips/lib/bootm.c   |  3 +++
 arch/mips/lib/traps.c   | 19 ++
 4 files changed, 54 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index a3ae603044..5e20feeefb 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -287,6 +287,36 @@ config MIPS_RELOCATION_TABLE_SIZE
 
  If unsure, leave at the default value.
 
+config RESTORE_EXCEPTION_VECTOR_BASE
+   bool "Restore exception vector base before booting linux kernel"
+   default n
+   help
+ In U-Boot the exception vector base will be moved to top of memory,
+ to be used to display register dump when exception occurs.
+ But some old linux kernel does not honor the base set in CP0_EBASE.
+ A modified exception vector base will cause kernel crash.
+
+ This option will restore the exception vector base to its previous
+ value.
+
+ If unsure, say N.
+
+config OVERRIDE_EXCEPTION_VECTOR_BASE
+   bool "Override the exception vector base to be restored"
+   depends on RESTORE_EXCEPTION_VECTOR_BASE
+   default n
+   help
+ Enable this option if you want to use a different exception vector
+ base rather than the previously saved one.
+
+config NEW_EXCEPTION_VECTOR_BASE
+   hex "New exception vector base"
+   depends on OVERRIDE_EXCEPTION_VECTOR_BASE
+   range 0x8000 0xb000
+   default 0x8000
+   help
+ The exception vector base to be restored before booting linux kernel
+
 endmenu
 
 menu "OS boot interface"
diff --git a/arch/mips/include/asm/u-boot-mips.h 
b/arch/mips/include/asm/u-boot-mips.h
index 88438b9576..8b37cc4029 100644
--- a/arch/mips/include/asm/u-boot-mips.h
+++ b/arch/mips/include/asm/u-boot-mips.h
@@ -9,4 +9,6 @@ void except_vec_ejtag_debug(void);
 
 int arch_misc_init(void);
 
+void trap_restore(void);
+
 #endif /* _U_BOOT_MIPS_H_ */
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 8c0d7672f2..f1db6d23b8 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -294,6 +294,9 @@ static void boot_jump_linux(bootm_headers_t *images)
bootstage_report();
 #endif
 
+   if (CONFIG_IS_ENABLED(RESTORE_EXCEPTION_VECTOR_BASE))
+   trap_restore();
+
if (images->ft_len)
kernel(-2, (ulong)images->ft_addr, 0, 0);
else
diff --git a/arch/mips/lib/traps.c b/arch/mips/lib/traps.c
index b8568c00fe..8fff7541e3 100644
--- a/arch/mips/lib/traps.c
+++ b/arch/mips/lib/traps.c
@@ -20,6 +20,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+static unsigned long saved_ebase;
+
 static void show_regs(const struct pt_regs *regs)
 {
const int field = 2 * sizeof(unsigned long);
@@ -102,7 +104,24 @@ void trap_init(ulong reloc_addr)
set_handler(0x180, _vec3_generic, 0x80);
set_handler(0x280, _vec_ejtag_debug, 0x80);
 
+   saved_ebase = read_c0_ebase() & 0xf000;
+
write_c0_ebase(ebase);
clear_c0_status(ST0_BEV);
execution_hazard_barrier();
 }
+
+void trap_restore(void)
+{
+   set_c0_status(ST0_BEV);
+   execution_hazard_barrier();
+
+#ifdef CONFIG_OVERRIDE_EXCEPTION_VECTOR_BASE
+   write_c0_ebase(CONFIG_NEW_EXCEPTION_VECTOR_BASE & 0xf000);
+#else
+   write_c0_ebase(saved_ebase);
+#endif
+
+   clear_c0_status(ST0_BEV);
+   execution_hazard_barrier();
+}
-- 
2.17.1

[PATCH v4 06/20] mips: mtmips: make use of sysreset-resetctrl for mt7628 soc

[Weijie Gao]

This patch replaces sysreset-syscon with sysreset-resetctrl for mt7628 soc.

Reviewed-by: Stefan Roese 
Reviewed-by: Daniel Schwierzeck 
Signed-off-by: Weijie Gao 
---
Changes since v3: none
---
 arch/mips/dts/mt7628a.dtsi | 10 +-
 arch/mips/mach-mtmips/Kconfig  |  1 +
 configs/gardena-smart-gateway-mt7688-ram_defconfig |  1 -
 configs/gardena-smart-gateway-mt7688_defconfig |  1 -
 configs/linkit-smart-7688-ram_defconfig|  1 -
 configs/linkit-smart-7688_defconfig|  1 -
 6 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 76a80c8952..409695b5c7 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -46,11 +46,11 @@
reg = <0x0 0x100>;
};
 
-   syscon-reboot {
-   compatible = "syscon-reboot";
-   regmap = <>;
-   offset = <0x34>;
-   mask = <0x1>;
+   reboot: resetctl-reboot {
+   compatible = "resetctl-reboot";
+
+   resets = < MT7628_SYS_RST>;
+   reset-names = "sysreset";
};
 
clkctrl: clkctrl@0x2c {
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 8e10719b27..8cb76c4560 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -27,6 +27,7 @@ config SOC_MT7628
select MIPS_L1_CACHE_SHIFT_5
select PINCTRL_MT7628
select MTK_SERIAL
+   select SYSRESET_RESETCTL
help
  This supports MediaTek MT7628/MT7688.
 
diff --git a/configs/gardena-smart-gateway-mt7688-ram_defconfig 
b/configs/gardena-smart-gateway-mt7688-ram_defconfig
index 0704f70e05..2015eb2c07 100644
--- a/configs/gardena-smart-gateway-mt7688-ram_defconfig
+++ b/configs/gardena-smart-gateway-mt7688-ram_defconfig
@@ -68,7 +68,6 @@ CONFIG_MT7628_ETH=y
 CONFIG_PHY=y
 CONFIG_SPI=y
 CONFIG_MT7621_SPI=y
-CONFIG_SYSRESET_SYSCON=y
 CONFIG_WDT=y
 CONFIG_WDT_MT7621=y
 CONFIG_LZMA=y
diff --git a/configs/gardena-smart-gateway-mt7688_defconfig 
b/configs/gardena-smart-gateway-mt7688_defconfig
index 99389995a0..c816021c7c 100644
--- a/configs/gardena-smart-gateway-mt7688_defconfig
+++ b/configs/gardena-smart-gateway-mt7688_defconfig
@@ -71,7 +71,6 @@ CONFIG_MT7628_ETH=y
 CONFIG_PHY=y
 CONFIG_SPI=y
 CONFIG_MT7621_SPI=y
-CONFIG_SYSRESET_SYSCON=y
 CONFIG_WDT=y
 CONFIG_WDT_MT7621=y
 CONFIG_LZMA=y
diff --git a/configs/linkit-smart-7688-ram_defconfig 
b/configs/linkit-smart-7688-ram_defconfig
index d1691abfda..7f29617ddc 100644
--- a/configs/linkit-smart-7688-ram_defconfig
+++ b/configs/linkit-smart-7688-ram_defconfig
@@ -53,7 +53,6 @@ CONFIG_PHY=y
 CONFIG_MT76X8_USB_PHY=y
 CONFIG_SPI=y
 CONFIG_MT7621_SPI=y
-CONFIG_SYSRESET_SYSCON=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/linkit-smart-7688_defconfig 
b/configs/linkit-smart-7688_defconfig
index a567c0c507..484c338348 100644
--- a/configs/linkit-smart-7688_defconfig
+++ b/configs/linkit-smart-7688_defconfig
@@ -57,7 +57,6 @@ CONFIG_PHY=y
 CONFIG_MT76X8_USB_PHY=y
 CONFIG_SPI=y
 CONFIG_MT7621_SPI=y
-CONFIG_SYSRESET_SYSCON=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
-- 
2.17.1

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Ard Biesheuvel]

On Wed, 12 Feb 2020 at 06:49, Chang, Abner (HPS SW/FW Technologist)
 wrote:
>
>
>
> > -Original Message-
> > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > Sent: Wednesday, February 12, 2020 2:26 AM
> > To: Chang, Abner (HPS SW/FW Technologist) ;
> > Atish Patra ; Ard Biesheuvel
> > 
> > Cc: Alexander Graf ; U-Boot Mailing List  > b...@lists.denx.de>; Atish Patra ;
> > l...@nuviainc.com
> > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> >
> > On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Atish Patra [mailto:ati...@atishpatra.org]
> > >> Sent: Friday, February 7, 2020 6:56 AM
> > >> To: Ard Biesheuvel ; Chang, Abner (HPS
> > >> SW/FW
> > >> Technologist) 
> > >> Cc: Alexander Graf ; Heinrich Schuchardt
> > >> ; U-Boot Mailing List ;
> > >> Atish Patra ; l...@nuviainc.com
> > >> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI
> > >> setup
> > >>
> > >> On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel
> > >> 
> > >> wrote:
> > >>>
> > >>> On Thu, 6 Feb 2020 at 21:06, Atish Patra  wrote:
> > 
> >  On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf 
> > wrote:
> > >
> > >
> > > On 06.02.20 19:28, Atish Patra wrote:
> > >> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> > >>  wrote:
> > >>> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt
> > >>  wrote:
> >  RISC-V booting currently is based on a per boot stage lottery
> >  to determine the active CPU. The Hart State Management (HSM)
> >  SBI extension replaces this lottery by using a dedicated
> >  primary
> > >> CPU.
> > 
> >  Cf. Hart State Management Extension, Extension ID: 0x48534D
> >  (HSM)
> >  https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.a
> >  doc
> > 
> >  In this scenario the id of the active hart has to be passed
> >  from boot stage to boot stage. Using a UEFI variable would
> >  provide
> > >> an easy implementation.
> > 
> >  This patch provides a weak function that is called at the end
> >  of the setup of U-Boot's UEFI sub-system. By overriding this
> >  function architecture specific UEFI variables or configuration
> >  tables
> > >> can be created.
> > 
> >  Signed-off-by: Heinrich Schuchardt 
> >  Reviewed-by: Atish Patra 
> > >>> OK, so I have a couple of questions:
> > >>>
> > >>> - does RISC-V use device tree? if so, why are you not passing
> > >>> the active hart via a property in the /chosen node?
> > >> Yes. RISC-V uses device tree. Technically, we can pass the active
> > >> hart by a DT property but that means we have to modify the DT in
> > >> OpenSBI (RISC-V specific run time service provider).
> > >> We have been trying to avoid that if possible so that DT is not
> > >> bounced around. This also limits U-Boot to have its own device
> > >> tree.
> > >
> > >
> > > I don't understand how this is different from the UEFI variable
> > > scheme proposed here? If you want to create an SBI interface to
> > > propagate the active HART that U-Boot then uses to populate the
> > > /chosen property, that's probably fine as well.
> > >
> > 
> >  We don't want to create SBI interface to pass this information.
> > 
> > > We already have hooks that allow you to modify the DT right before
> > > it gets delivered to the payload. Just add it there?
> > >
> > 
> >  Hmm. I guess it is true if the DT is loaded from MMC or network as 
> >  well.
> >  How about EDK2 ? If we go DT route, it also has to modify the DT to
> >  pass the boot hart.
> > 
> >  As it requires DT modification in multiple projects, why not use
> >  efi configuration tables as suggested by Ard ?
> > 
> > >>>
> > >>> Configuration tables are preferred over variables, but putting it in
> > >>> the DT makes even more sense, since in that case, nothing that runs
> > >>> in the UEFI context has to care about any of this.
> > >>>
> > >>
> > >>
> > >>> I'd assume the EFI stub would not care at all about this
> > >>> information, and it would give you a Linux/RISC-V specific way
> > >>> to convey this information that is independent of EFI.
> > >> Yes. EFI stub doesn't care about this information. However, it
> > >> needs to save the information somewhere so that it can pass to
> > >> the real kernel after exiting boot time services.
> > >
> > >
> > > DT sounds like a pretty natural choice for that to me :).
> > >
> > >>>
> > >>> Indeed. DT has a /chosen node that is set aside for this purpose. It
> > >>> does depend on how early you need the value (i.e., before or after
> > >>> you can run C code), but since you are passing the DT address to the
> > >>> core kernel, it 

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Stefan]

Hi Mauro,
Hi Daniel,

On 11.02.20 19:05, Mauro Condarelli wrote:

Thanks Daniel.

On 2/11/20 5:49 PM, Daniel Schwierzeck wrote:

On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli  wrote:

===8<
Hit any key to stop autoboot:  0
=>

ok, booting from RAM works. But what I meant with bootable is, that
you can write the
the u-boot-mtmips.bin to SPI flash and do a cold boot. Only then we
can merge your patch.

It *does* work.
The U-Boot I have flashed is essentially the same as the one built
in the "master" directory, just a few days old (I changed essentially
my project-specific CONFIG_EXTRA_ENV_SETTINGS).

... which reminds me of something...

... it turns out that flashing *does* work:

=> setenv autoload no; dhcp; tftpboot 8500
192.168.7.101:u-boot-mtmips.bin; sf probe; sf update ${fileaddr} 0
${filesize}
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.7.110 (2953 ms)
Using eth@1011 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.110
Filename 'u-boot-mtmips.bin'.
Load address: 0x8500
Loading: #
      762.7 KiB/s
done
Bytes transferred = 244458 (3baea hex)
device 0 offset 0x0, size 0x3baea
240362 bytes written, 4096 bytes skipped in 2.232s, speed 111952 B/s
=> reset
resetting ...

U-Boot SPL 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)
Trying to boot from NOR


U-Boot 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: VoCore2
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@1013: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
Model: VoCore2
Net:
Warning: eth@1011 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93
eth0: eth@1011
Hit any key to stop autoboot:  0
=>

What *does NOT* work is loading RAM version or, to be more precise:
It works IF (and only if) you load the same code already running.
I *think* this is because current Weijie code unpacks to this same location
(8020) before relocating. If you are rewriting the same code in the
same location any cache inconsistencies are unimportant, otherwise
Bad Things happen.
I spoke with Stephan about this, but we never found a fix.

Now that I reflashed "u-boot-mips/testing" version I can run it also
"from RAM", while trying to load "master" hangs (I tried just now).

If this is considered "acceptable" (probably it has nothing to do with my
vocore2 port) I can clean-up my patches and resubmit.
I'm not a mips expert and I don't know how to debug this "RAM load"
misbehavior, but I'm available for testing, if useful.


I also noticed that "RAM loading" the U-Boot proper does not work all
the time on my MT7688 targets. It seems to depend on the image size
and some other factors (moon phase...). ;)

So there is very likely a bug somewhere hidden - perhaps in the
relocaton code. I will probably try to dig into this in sometime soon.
But I need a reproducable "bad" image for this. Right now, RAM loading
is working just fine.

BTW: I noticed that RAM loading does work even when loading into a
different address than TEXT_BASE. On the new MTMIPS targets TEXT_BASE is
0x8020 and loadind to e.g. 0x8100 does also work.

Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
independant?

Mauro, please try loading into a different address on your non-working
setup and report back if RAM loading works in this case.




===8<---

I *do* have a bootable patchset built on top of master + Nemirovsky
"reconfigurable cpu clocks" + Weijie v3.
Result is fully working, including net and mmc/SD.

This patchset applies cleanly to uboot-mips/testing and compile
apparently without errors, but resulting u-boot.bin does not work.
By "does not work" I mean it does not utter a single char on debug
serial.

I tried to do a complete diff between my working tree and this
non-working one and there are tons of differences, but I couldn't
spot anything that might be relevant.

I am unsure on how to proceed; please advise.

maybe you have a big diff because you are not on the latest master
branch. I currently
have ae347120eed8204b1fdf018ddf79131964e57016. The u-boot-mips/testing is based
on u-boot-mips/next and only contains Weijie's v3 patches from 14/20
to 20/20. For
u-boot-mips/next I intend to create a pull request soon. The existing
mtmips boards should
still work without SPL support. Maybe Stefan could give it a quick test.

Maybe I messed something up in u-boot-mips/testing. There were some
merge conflicts.

I don't think so.
As said problem is with RAM loading.


I also have this problem (sometimes). Please see above.


Could you build a new patch queue on top of u-boot-mips/next with the remaining
Weijie v3 patches and your VoCore2 patches?

I can do that if You think it's still 

Re: dm, serial: problem with using ns16550 driver before relocation on mpc83xx

[Heiko Schocher]

Hello Mario, Simon,

Am 10.02.2020 um 07:16 schrieb Mario Six:

Hi Heiko,

On Fri, Feb 7, 2020 at 6:53 AM Heiko Schocher  wrote:


Hi Simon,

removed Dirk from cc and added Mario Six

@Mario: Dirk is maintainer of the gazerbeam board:

https://gitlab.denx.de/u-boot/u-boot/blob/master/board/gdsys/mpc8308/MAINTAINERS#L2

but EMail get not delivered to his EMail address ... so I added
you to cc ... may you have a gazerbeam board? May you can try,
if current U-Boot mainline works (in special serial console) on it?


Dirk no longer works as gdsys (which is also the reason why I'm much less
active on the mailing list than I used to be).

I have a gazerbeam board. I'll try to get some time to test mainline on it some
time this week.


The problem is gone, no need for my fix. I made a cleanbuild after
I rebased with mainline this morning (without my "fix"), and all works
fine.

Sorry for the inconvenience!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

[PATCH] armV7R: K3: am654: Activate early console functionality

[Lokesh Vutla]

From: Andreas Dannenberg 

Activate early console functionality on AM65x devices to allow for
early diagnostic messages until the main console is ready
to get activated.

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/am6_init.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 8d107b870b..63cd7e0458 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -109,6 +109,16 @@ void board_init_f(ulong dummy)
/* Init DM early in-order to invoke system controller */
spl_early_init();
 
+#ifdef CONFIG_K3_EARLY_CONS
+   /*
+* Allow establishing an early console as required for example when
+* doing a UART-based boot. Note that this console may not "survive"
+* through a SYSFW PM-init step and will need a re-init in some way
+* due to changing module clock frequencies.
+*/
+   early_console_init();
+#endif
+
 #ifdef CONFIG_K3_LOAD_SYSFW
/*
 * Process pinctrl for the serial0 a.k.a. WKUP_UART0 module and continue
-- 
2.23.0

[PATCH] arm: K3: j721e: Fix boot parameter table index memory address

[Lokesh Vutla]

From: Andreas Dannenberg 

The boot parameter table index memory address for J721E was configured
to an incorrect value which prevented the use of this definition to
determine which boot parameter table is active which is needed to be
able to distinguish between primary and backup boot modes. Fix this
issue by updating the value to the correct one also in alignment with
the J721E Technical Reference Manual (TRM).

Signed-off-by: Andreas Dannenberg 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-k3/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 2e111bbf27..8f4272286c 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -50,7 +50,7 @@ config SYS_K3_MCU_SCRATCHPAD_SIZE
 config SYS_K3_BOOT_PARAM_TABLE_INDEX
hex
default 0x41c7fbfc if SOC_K3_AM6
-   default 0x41cffc00 if SOC_K3_J721E
+   default 0x41cffbfc if SOC_K3_J721E
help
  Address at which ROM stores the value which determines if SPL
  is booted up by primary boot media or secondary boot media.
-- 
2.23.0

Re: [PATCH] ARM: keystone2: enable initrd fixup for LPAE addressing

[Lokesh Vutla]

Hi Tom,

On 11/02/20 8:31 PM, Tom Rini wrote:
> On Tue, Feb 11, 2020 at 09:25:52AM +0530, Lokesh Vutla wrote:
> 
>> From: Tero Kristo 
>>
>> Keystone2 u-boot loads the initrd image into non-LPAE addressed memory
>> but linux kernel is running in LPAE. This causes a conflict as kernel
>> detects that non-memory address is passed and kernel ignores initrd.
>> There is an existing fixup logic to modify the address in the proper
>> configuration, but this is disabled at the moment. Enable the fixup
>> by setting the env variable for this so that initrd can be used
>> properly.
>>
>> Signed-off-by: Tero Kristo 
>> Signed-off-by: Lokesh Vutla 
>> ---
>> - This fixes boot on k2g platforms.
>>
>>  include/configs/ti_armv7_keystone2.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/configs/ti_armv7_keystone2.h 
>> b/include/configs/ti_armv7_keystone2.h
>> index ba12428dbe..1b014c1022 100644
>> --- a/include/configs/ti_armv7_keystone2.h
>> +++ b/include/configs/ti_armv7_keystone2.h
>> @@ -213,6 +213,7 @@
>>  "tftp_root=/\0" \
>>  "nfs_root=/export\0"\
>>  "mem_lpae=1\0"  \
>> +"uinitrd_fixup=1\0" \
>>  "addr_ubi=0x8200\0" \
>>  "addr_secdb_key=0xc00\0"\
>>  "name_kern=zImage\0"\
> 
> OK, hold up.  Why is any of this code needed and can't the normal
> bootm_size / bootm_low / etc as documented in the README enforce these
> constraints?  Thanks!
> 

K2 platforms has a special scenario. DDR view for U-Boot is starting from
0x8000_ - 0x_. Wheres as for kernel, the DDR view gets shifted to
0x8__ - 0x8_7FFF_. This is a hardware limitation to ensure coherency
among different master in the SoC. In kernel all the page tables are fixed up by
the Kconfig CONFIG_ARM_PV_FIXUP. But the expectation is to pass the right
information in DTB. U-Boot already fixes up the memory address nodes in
ft_board_setup() but missed updating the linux-initrd. This patch enables the
fixup for initrd.

Thanks and regards,
Lokesh

Re: [PATCH v3 01/12] clk: Always use the supplied struct clk

[Rick Chen]

Hi Lukasz

> From: Lukasz Majewski [mailto:lu...@denx.de]
> Sent: Friday, February 07, 2020 5:22 AM
> To: Sean Anderson
> Cc: U-Boot Mailing List; Rick Jian-Zhi Chen(陳建志); Lukas Auer
> Subject: Re: [PATCH v3 01/12] clk: Always use the supplied struct clk
>
> Hi Sean,
>
> > CCF clocks should always use the struct clock passed to their methods
> > for extracting the driver-specific clock information struct.
> > Previously, many functions would use the clk->dev->priv if the device
> > was bound. This could cause problems with composite clocks. The
> > individual clocks in a composite clock did not have the ->dev field
> > filled in. This was fine, because the device-specific clock
> > information would be used. However, since there was no ->dev, there
> > was no way to get the parent clock. This caused the recalc_rate method
> > of the CCF divider clock to fail. One option would be to use the
> > clk->priv field to get the composite clock and from there get the
> > appropriate parent device. However, this would tie the implementation
> > to the composite clock. In general, different devices should not rely
> > on the contents of ->priv from another device.
> >
> > The simple solution to this problem is to just always use the supplied
> > struct clock. The composite clock now fills in the ->dev pointer of
> > its child clocks. This allows child clocks to make calls like
> > clk_get_parent() without issue.
> >
> > imx avoided the above problem by using a custom get_rate function with
> > composite clocks.
> >
> > Signed-off-by: Sean Anderson 
>
> Thank you Sean for your CCF enhancement and updating the ccf.txt 
> documentation entry.
>
> Acked-by: Lukasz Majewski 
>
> I don't mind if RISC-V SoC maintainer pulls the whole series (including CCF 
> patches).

OK
Thanks for your review.

Regards,
Rick

>
> > ---
> >   Changes for v3:
> >   - Documented new assumptions in the CCF
> >   - Wrapped docs to 80 columns
> >
> >  doc/imx/clk/ccf.txt| 63
> > +- drivers/clk/clk-composite.c|
> > 8 + drivers/clk/clk-divider.c  |  6 ++--
> >  drivers/clk/clk-fixed-factor.c |  3 +-
> >  drivers/clk/clk-gate.c |  6 ++--
> >  drivers/clk/clk-mux.c  | 12 +++
> >  drivers/clk/imx/clk-gate2.c|  4 +--
> >  7 files changed, 51 insertions(+), 51 deletions(-)
> >
> > diff --git a/doc/imx/clk/ccf.txt b/doc/imx/clk/ccf.txt index
> > 36b60dc438..e40ac360e8 100644
> > --- a/doc/imx/clk/ccf.txt
> > +++ b/doc/imx/clk/ccf.txt
> > @@ -1,42 +1,37 @@
> >  Introduction:
> >  =
> >
> > -This documentation entry describes the Common Clock Framework [CCF]
> > -port from Linux kernel (v5.1.12) to U-Boot.
> > +This documentation entry describes the Common Clock Framework [CCF]
> > port from +Linux kernel (v5.1.12) to U-Boot.
> >
> > -This code is supposed to bring CCF to IMX based devices (imx6q, imx7
> > -imx8). Moreover, it also provides some common clock code, which would
> > -allow easy porting of CCF Linux code to other platforms.
> > +This code is supposed to bring CCF to IMX based devices (imx6q, imx7
> > imx8). +Moreover, it also provides some common clock code, which would
> > allow easy +porting of CCF Linux code to other platforms.
> >
> >  Design decisions:
> >  =
> >
> > -* U-Boot's driver model [DM] for clk differs from Linux CCF. The most
> > -  notably difference is the lack of support for hierarchical clocks
> > and
> > -  "clock as a manager driver" (single clock DTS node acts as a
> > starting
> > -  point for all other clocks).
> > +* U-Boot's driver model [DM] for clk differs from Linux CCF. The
> > most notably
> > +  difference is the lack of support for hierarchical clocks and
> > "clock as a
> > +  manager driver" (single clock DTS node acts as a starting point
> > for all other
> > +  clocks).
> >
> > -* The clk_get_rate() caches the previously read data if
> > CLK_GET_RATE_NOCACHE
> > -  is not set (no need for recursive access).
> > +* The clk_get_rate() caches the previously read data if
> > CLK_GET_RATE_NOCACHE is
> > +  not set (no need for recursive access).
> >
> > -* On purpose the "manager" clk driver (clk-imx6q.c) is not using
> > large
> > -  table to store pointers to clocks - e.g.
> > clk[IMX6QDL_CLK_USDHC2_SEL] = 
> > -  Instead we use udevice's linked list for the same class
> > (UCLASS_CLK). +* On purpose the "manager" clk driver (clk-imx6q.c) is
> > not using large table to
> > +  store pointers to clocks - e.g. clk[IMX6QDL_CLK_USDHC2_SEL] = 
> > Instead we
> > +  use udevice's linked list for the same class (UCLASS_CLK).
> >
> >Rationale:
> >--
> > -When porting the code as is from Linux, one would need ~1KiB of
> > RAM to
> > -store it. This is way too much if we do plan to use this driver
> > in SPL.
> > +When porting the code as is from Linux, one would need ~1KiB of
> > RAM to store
> > +it. This is way too much if we do plan to use this driver in SPL.
> >
> > 

Re: FYI: Please pull u-boot-dm

[Stephen Warren]

On 2/11/20 3:06 PM, Tom Rini wrote:

On Tue, Feb 11, 2020 at 03:02:12PM -0700, Stephen Warren wrote:

On 2/11/20 11:27 AM, Tom Rini wrote:

On Tue, Feb 11, 2020 at 11:20:36AM -0700, Simon Glass wrote:

Hi Tom,

On Sat, 8 Feb 2020 at 07:51, Simon Glass  wrote:


Hi Stephen,

On Thu, 6 Feb 2020 at 15:38, Simon Glass  wrote:


Hi Stephen,

On Thu, 6 Feb 2020 at 15:32, Stephen Warren  wrote:


On 2/6/20 2:55 PM, Simon Glass wrote:

Hi Tom,

This cannot be pulled yet since we need to update gitlab's docker
image to include SDL2. But gitlab seems to be having various problems
this week and today i won't work at all: ...


I see the following build error in u-boot-dm/master via Jenkins:


drivers/misc/p2sb_emul.c: In function ‘sandbox_p2sb_emul_map_physmem’:
drivers/misc/p2sb_emul.c:237:6: warning: ‘child’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
ret = axi_read(child, offset, priv->regs, AXI_SIZE_32);
^
CC  common


Hmmm that's odd. I don't see that, but there are so many device-tree
and libfdt warnings at present I may have missed it. Will take a look.


That doesn't happen with my gcc 7.3 toolchain. I'll send a patch to
set child to NULL at the start, but a look at the code shows that it
is correct.

Also this is in master and was not introduced by this series.


A fix for this is going in via the x86 tree.

Tom, is there anything else you need from me for this pull request?


Testing it now, thanks.


Now that this has been merged, the build break has come along with it. Is
there any chance of picking up the fix from the x86 tree quickly?


I thought we agreed that it seemed like a compiler problem for throwing
up a false-positive?  But are you unable to move up to something a bit
newer?  Thanks!


It might be possible to upgrade the compiler yet again. I'd rather not 
keep changing compilers all the time, which entails extra disk space 
etc. It's trivial to solve this issue (a patch has already been posted). 
I don't think forcing everyone to change compilers just because some 
easily-fixable warning appears is a good idea.


The code structure in question legitimately warns; it's only by analysis 
of additional possibly-inlined functions that happen to be in the same 
source file that the compiler could tell if the warning is false. If 
those called functions just happened to be implemented in a different 
source file, the same warning would be 100% legitimately emitted and 
probably is even with newer compilers, and the same fix would need to be 
applied. I'm not sure I'd go so far as to call this a compiler bug.

Re: FYI: Please pull u-boot-dm

[Tom Rini]

On Tue, Feb 11, 2020 at 05:15:39PM -0700, Stephen Warren wrote:
> On 2/11/20 3:06 PM, Tom Rini wrote:
> > On Tue, Feb 11, 2020 at 03:02:12PM -0700, Stephen Warren wrote:
> > > On 2/11/20 11:27 AM, Tom Rini wrote:
> > > > On Tue, Feb 11, 2020 at 11:20:36AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > > 
> > > > > On Sat, 8 Feb 2020 at 07:51, Simon Glass  wrote:
> > > > > > 
> > > > > > Hi Stephen,
> > > > > > 
> > > > > > On Thu, 6 Feb 2020 at 15:38, Simon Glass  wrote:
> > > > > > > 
> > > > > > > Hi Stephen,
> > > > > > > 
> > > > > > > On Thu, 6 Feb 2020 at 15:32, Stephen Warren 
> > > > > > >  wrote:
> > > > > > > > 
> > > > > > > > On 2/6/20 2:55 PM, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > > 
> > > > > > > > > This cannot be pulled yet since we need to update gitlab's 
> > > > > > > > > docker
> > > > > > > > > image to include SDL2. But gitlab seems to be having various 
> > > > > > > > > problems
> > > > > > > > > this week and today i won't work at all: ...
> > > > > > > > 
> > > > > > > > I see the following build error in u-boot-dm/master via Jenkins:
> > > > > > > > 
> > > > > > > > > drivers/misc/p2sb_emul.c: In function 
> > > > > > > > > ‘sandbox_p2sb_emul_map_physmem’:
> > > > > > > > > drivers/misc/p2sb_emul.c:237:6: warning: ‘child’ may be used 
> > > > > > > > > uninitialized in this function [-Wmaybe-uninitialized]
> > > > > > > > > ret = axi_read(child, offset, priv->regs, AXI_SIZE_32);
> > > > > > > > > ^
> > > > > > > > > CC  common
> > > > > > > 
> > > > > > > Hmmm that's odd. I don't see that, but there are so many 
> > > > > > > device-tree
> > > > > > > and libfdt warnings at present I may have missed it. Will take a 
> > > > > > > look.
> > > > > > 
> > > > > > That doesn't happen with my gcc 7.3 toolchain. I'll send a patch to
> > > > > > set child to NULL at the start, but a look at the code shows that it
> > > > > > is correct.
> > > > > > 
> > > > > > Also this is in master and was not introduced by this series.
> > > > > 
> > > > > A fix for this is going in via the x86 tree.
> > > > > 
> > > > > Tom, is there anything else you need from me for this pull request?
> > > > 
> > > > Testing it now, thanks.
> > > 
> > > Now that this has been merged, the build break has come along with it. Is
> > > there any chance of picking up the fix from the x86 tree quickly?
> > 
> > I thought we agreed that it seemed like a compiler problem for throwing
> > up a false-positive?  But are you unable to move up to something a bit
> > newer?  Thanks!
> 
> It might be possible to upgrade the compiler yet again. I'd rather not keep
> changing compilers all the time, which entails extra disk space etc. It's
> trivial to solve this issue (a patch has already been posted). I don't think
> forcing everyone to change compilers just because some easily-fixable
> warning appears is a good idea.
> 
> The code structure in question legitimately warns; it's only by analysis of
> additional possibly-inlined functions that happen to be in the same source
> file that the compiler could tell if the warning is false. If those called
> functions just happened to be implemented in a different source file, the
> same warning would be 100% legitimately emitted and probably is even with
> newer compilers, and the same fix would need to be applied. I'm not sure I'd
> go so far as to call this a compiler bug.

So, we enforce using gcc-6.0 or newer (in reality 6.1, there is no 6.0
release).  That's 4 years old this April.  In CI, we use gcc 7.3 (which
is 2 years old now) and have accepted that if you aren't using at least
that version some platforms may not optimize-for-size sufficiently.  The
flip side of all of this is the problems we keep getting reported and
fixes for using gcc-9.x which we can't easily globally switch to,
unfortunately.

For a one compiler to use everywhere I would suggest the 7.3 that
buildman fetches from kernel.org and has for a long while.

That said, since Bin is the one who was unhappy with the warning-fix to
start with but has since taken a patch for it, I'm not going to overrule
him.  I expect a PR shortly.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] Revert "gitlab: Disable SDL when building sandbox"

[Simon Glass]

This is not needed now that we have SDL2 in the docker image. It causes
test failures for tests which need video to work.

This reverts commit af800722eb718bec51c5943cfb69231acf15178f.

Signed-off-by: Simon Glass 
---

 .gitlab-ci.yml | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 1f8a4c93cf..e20a789ac1 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -31,8 +31,7 @@ stages:
 # use clang only do one configuration.
 - if [[ "${BUILDMAN}" != "" ]]; then
 ret=0;
-NO_SDL=1 tools/buildman/buildman -o /tmp -P -E ${BUILDMAN}
-  ${OVERRIDE}|| ret=$?;
+tools/buildman/buildman -o /tmp -P -E ${BUILDMAN} ${OVERRIDE}|| ret=$?;
 if [[ $ret -ne 0 && $ret -ne 129 ]]; then
   tools/buildman/buildman -o /tmp -sdeP ${BUILDMAN};
   exit $ret;
@@ -164,7 +163,7 @@ Run binman, buildman, dtoc and patman testsuites:
   export UBOOT_TRAVIS_BUILD_DIR=/tmp/.bm-work/sandbox_spl;
   export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt";
   export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}";
-  NO_SDL=1 ./tools/buildman/buildman -o /tmp -P sandbox_spl;
+  ./tools/buildman/buildman -o /tmp -P sandbox_spl;
   ./tools/binman/binman --toolpath ${UBOOT_TRAVIS_BUILD_DIR}/tools test;
   ./tools/buildman/buildman -t;
   ./tools/dtoc/dtoc -t;
-- 
2.25.0.225.g125e21ebc7-goog

Re: FYI: Please pull u-boot-dm

[Tom Rini]

On Wed, Feb 12, 2020 at 12:10:41AM +0100, Anatolij Gustschin wrote:
> Hi Simon,
> 
> On Tue, 11 Feb 2020 16:03:14 -0700
> Simon Glass s...@google.com wrote:
> 
> > Hi Tom,
> > 
> > On Tue, 11 Feb 2020 at 14:30, Tom Rini  wrote:
> > >
> > > On Tue, Feb 11, 2020 at 03:26:10PM -0500, Tom Rini wrote:  
> > > > On Thu, Feb 06, 2020 at 02:55:49PM -0700, Simon Glass wrote:
> > > >  
> > > > > Hi Tom,
> > > > >
> > > > > This cannot be pulled yet since we need to update gitlab's docker
> > > > > image to include SDL2. But gitlab seems to be having various problems
> > > > > this week and today i won't work at all:
> > > > >
> > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/2108
> > > > >
> > > > > Travis is happy.
> > > > >
> > > > > So I am sending this just FYI for now. Once things settle down I can
> > > > > do a new version if needed.
> > > > >
> > > > >
> > > > > The following changes since commit 
> > > > > f5cc89a82a9990ba9805ff5800c0872b891533ce:
> > > > >
> > > > >   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq
> > > > > (2020-02-05 07:19:52 -0500)
> > > > >
> > > > > are available in the Git repository at:
> > > > >
> > > > >   https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git 
> > > > > tags/dm-pull-6feb20
> > > > >
> > > > > for you to fetch changes up to 
> > > > > 21d651fb29cf268b1a5f64d080e3d352ee32c87f:
> > > > >
> > > > >   sandbox: Complete migration away from os_malloc() (2020-02-05 
> > > > > 21:48:23 -0700)  
> > > >
> > > > Applied to u-boot/master, thanks!  
> > >
> > > So I've pushed this but I think it was premature:
> > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/57084 is a kind of failure
> > > I'm seeing reliably.  I'm going to bisect down to which commit does
> > > this, but I suspect it's the whole of the SDL2 switch.  
> > 
> > Oh dear, I will take a look. But at least gitlab it builds with SDL2 now.
> 
> Reverting commit af800722eb71 ("gitlab: Disable SDL when building sandbox")
> fixes this, it seems.

Quicker than me, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: FYI: Please pull u-boot-dm

[Anatolij Gustschin]

Hi Simon,

On Tue, 11 Feb 2020 16:03:14 -0700
Simon Glass s...@google.com wrote:

> Hi Tom,
> 
> On Tue, 11 Feb 2020 at 14:30, Tom Rini  wrote:
> >
> > On Tue, Feb 11, 2020 at 03:26:10PM -0500, Tom Rini wrote:  
> > > On Thu, Feb 06, 2020 at 02:55:49PM -0700, Simon Glass wrote:
> > >  
> > > > Hi Tom,
> > > >
> > > > This cannot be pulled yet since we need to update gitlab's docker
> > > > image to include SDL2. But gitlab seems to be having various problems
> > > > this week and today i won't work at all:
> > > >
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/2108
> > > >
> > > > Travis is happy.
> > > >
> > > > So I am sending this just FYI for now. Once things settle down I can
> > > > do a new version if needed.
> > > >
> > > >
> > > > The following changes since commit 
> > > > f5cc89a82a9990ba9805ff5800c0872b891533ce:
> > > >
> > > >   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq
> > > > (2020-02-05 07:19:52 -0500)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >   https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git 
> > > > tags/dm-pull-6feb20
> > > >
> > > > for you to fetch changes up to 21d651fb29cf268b1a5f64d080e3d352ee32c87f:
> > > >
> > > >   sandbox: Complete migration away from os_malloc() (2020-02-05 
> > > > 21:48:23 -0700)  
> > >
> > > Applied to u-boot/master, thanks!  
> >
> > So I've pushed this but I think it was premature:
> > https://gitlab.denx.de/u-boot/u-boot/-/jobs/57084 is a kind of failure
> > I'm seeing reliably.  I'm going to bisect down to which commit does
> > this, but I suspect it's the whole of the SDL2 switch.  
> 
> Oh dear, I will take a look. But at least gitlab it builds with SDL2 now.

Reverting commit af800722eb71 ("gitlab: Disable SDL when building sandbox")
fixes this, it seems.

--
Anatolij

Re: [PATCH 1/1] log: correct CONFIG_LOG_TEST prerequisites

[Simon Glass]

On Sat, 8 Feb 2020 at 15:17, Heinrich Schuchardt  wrote:
>
> An error
>
> undefined reference to `do_log_test'
>
> occurs for CONFIG_CMD_LOG=y, CONFIG_LOG_TEST=y, CONGIG_UNIT_TEST=n
>
> Make CONFIG_UNIT_TEST a prerequisite.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Re: FYI: Please pull u-boot-dm

[Simon Glass]

Hi Tom,

On Tue, 11 Feb 2020 at 14:30, Tom Rini  wrote:
>
> On Tue, Feb 11, 2020 at 03:26:10PM -0500, Tom Rini wrote:
> > On Thu, Feb 06, 2020 at 02:55:49PM -0700, Simon Glass wrote:
> >
> > > Hi Tom,
> > >
> > > This cannot be pulled yet since we need to update gitlab's docker
> > > image to include SDL2. But gitlab seems to be having various problems
> > > this week and today i won't work at all:
> > >
> > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/2108
> > >
> > > Travis is happy.
> > >
> > > So I am sending this just FYI for now. Once things settle down I can
> > > do a new version if needed.
> > >
> > >
> > > The following changes since commit 
> > > f5cc89a82a9990ba9805ff5800c0872b891533ce:
> > >
> > >   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq
> > > (2020-02-05 07:19:52 -0500)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git 
> > > tags/dm-pull-6feb20
> > >
> > > for you to fetch changes up to 21d651fb29cf268b1a5f64d080e3d352ee32c87f:
> > >
> > >   sandbox: Complete migration away from os_malloc() (2020-02-05 21:48:23 
> > > -0700)
> >
> > Applied to u-boot/master, thanks!
>
> So I've pushed this but I think it was premature:
> https://gitlab.denx.de/u-boot/u-boot/-/jobs/57084 is a kind of failure
> I'm seeing reliably.  I'm going to bisect down to which commit does
> this, but I suspect it's the whole of the SDL2 switch.

Oh dear, I will take a look. But at least gitlab it builds with SDL2 now.

Regards,
SImon

Re: [BUG] binman: Add a library to access binman entries

[Simon Glass]

Hi Frank,

On Fri, 24 Jan 2020 at 11:15, Frank Wunderlich  wrote:
>
> Hi,
>
> a bit more info about this...

Sorry for the delay. Stephen hit this also.

>
> this line [1] (in my case) breaks the init-chain:
>
> return log_msg_ret("binman node", -EINVAL);
>
> the binman_init [2] is added to init_sequence_r[] which is executed by 
> initcall_run_list
>
> ./common/board_r.c:897: if (initcall_run_list(init_sequence_r))
>
> exiting the binman-function [3] with error-code (return <> 0) exits the full 
> chain (./include/initcall.h) [4] with message
>
> initcall sequence %p failed at call %p
>
> how to deal with this?
>
> - do not select binman as default=y in Kconfig

Where is it selected by default?

bpi-r64 uses binman to build its image so I think BINMAN is on.

> - adding the binman-node [1] to all dts

Yes, but in fact it should already be there. I see in the Makefile
that 64-bit sunxi uses 'cat' instead of 'binman'. It should use
binman.

> - do not exit with error-code (only print/log message)

Not keen on that

> - do not exit the init-sequence on binman-error [3]

or that

> - more ideas?

Let's convert bpi-64 as above.

>
> in our case we disabled option CONFIG_BINMAN_FDT [5]
>
> regards Frank
>
> [1] https://gitlab.denx.de/u-boot/u-boot/blob/master/lib/binman.c#L45
> [2] https://gitlab.denx.de/u-boot/u-boot/blob/master/common/board_r.c#L722
> [3] https://gitlab.denx.de/u-boot/u-boot/blob/master/common/board_r.c#L369
> [4] https://gitlab.denx.de/u-boot/u-boot/blob/master/include/initcall.h#L42
>
> [5] http://forum.banana-pi.org/t/bpi-r64-current-u-boot-support/10077/69
>

Regards,
Simon

Re: FYI: Please pull u-boot-dm

[Tom Rini]

On Tue, Feb 11, 2020 at 03:02:12PM -0700, Stephen Warren wrote:
> On 2/11/20 11:27 AM, Tom Rini wrote:
> > On Tue, Feb 11, 2020 at 11:20:36AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > > 
> > > On Sat, 8 Feb 2020 at 07:51, Simon Glass  wrote:
> > > > 
> > > > Hi Stephen,
> > > > 
> > > > On Thu, 6 Feb 2020 at 15:38, Simon Glass  wrote:
> > > > > 
> > > > > Hi Stephen,
> > > > > 
> > > > > On Thu, 6 Feb 2020 at 15:32, Stephen Warren  
> > > > > wrote:
> > > > > > 
> > > > > > On 2/6/20 2:55 PM, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > > 
> > > > > > > This cannot be pulled yet since we need to update gitlab's docker
> > > > > > > image to include SDL2. But gitlab seems to be having various 
> > > > > > > problems
> > > > > > > this week and today i won't work at all: ...
> > > > > > 
> > > > > > I see the following build error in u-boot-dm/master via Jenkins:
> > > > > > 
> > > > > > > drivers/misc/p2sb_emul.c: In function 
> > > > > > > ‘sandbox_p2sb_emul_map_physmem’:
> > > > > > > drivers/misc/p2sb_emul.c:237:6: warning: ‘child’ may be used 
> > > > > > > uninitialized in this function [-Wmaybe-uninitialized]
> > > > > > >ret = axi_read(child, offset, priv->regs, AXI_SIZE_32);
> > > > > > >^
> > > > > > >CC  common
> > > > > 
> > > > > Hmmm that's odd. I don't see that, but there are so many device-tree
> > > > > and libfdt warnings at present I may have missed it. Will take a look.
> > > > 
> > > > That doesn't happen with my gcc 7.3 toolchain. I'll send a patch to
> > > > set child to NULL at the start, but a look at the code shows that it
> > > > is correct.
> > > > 
> > > > Also this is in master and was not introduced by this series.
> > > 
> > > A fix for this is going in via the x86 tree.
> > > 
> > > Tom, is there anything else you need from me for this pull request?
> > 
> > Testing it now, thanks.
> 
> Now that this has been merged, the build break has come along with it. Is
> there any chance of picking up the fix from the x86 tree quickly?

I thought we agreed that it seemed like a compiler problem for throwing
up a false-positive?  But are you unable to move up to something a bit
newer?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: FYI: Please pull u-boot-dm

[Stephen Warren]

On 2/11/20 11:27 AM, Tom Rini wrote:

On Tue, Feb 11, 2020 at 11:20:36AM -0700, Simon Glass wrote:

Hi Tom,

On Sat, 8 Feb 2020 at 07:51, Simon Glass  wrote:


Hi Stephen,

On Thu, 6 Feb 2020 at 15:38, Simon Glass  wrote:


Hi Stephen,

On Thu, 6 Feb 2020 at 15:32, Stephen Warren  wrote:


On 2/6/20 2:55 PM, Simon Glass wrote:

Hi Tom,

This cannot be pulled yet since we need to update gitlab's docker
image to include SDL2. But gitlab seems to be having various problems
this week and today i won't work at all: ...


I see the following build error in u-boot-dm/master via Jenkins:


drivers/misc/p2sb_emul.c: In function ‘sandbox_p2sb_emul_map_physmem’:
drivers/misc/p2sb_emul.c:237:6: warning: ‘child’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
   ret = axi_read(child, offset, priv->regs, AXI_SIZE_32);
   ^
   CC  common


Hmmm that's odd. I don't see that, but there are so many device-tree
and libfdt warnings at present I may have missed it. Will take a look.


That doesn't happen with my gcc 7.3 toolchain. I'll send a patch to
set child to NULL at the start, but a look at the code shows that it
is correct.

Also this is in master and was not introduced by this series.


A fix for this is going in via the x86 tree.

Tom, is there anything else you need from me for this pull request?


Testing it now, thanks.


Now that this has been merged, the build break has come along with it. 
Is there any chance of picking up the fix from the x86 tree quickly?

Re: [PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"

[Rasmus Villemoes]

On 11/02/2020 22.20, Rasmus Villemoes wrote:
> On 11/02/2020 17.30, Wolfgang Denk wrote:

>>> This forces some scripts to needlessly duplicate logic and hardcode
>>> assumptions. For example, in an A/B scheme with three variables
>>>
>>> BOOT_ORDER # Either "A B" or "B A" depending on which slot was last updated
>>> BOOT_A_LEFT # 0..3
>>> BOOT_B_LEFT # 0..3
>>>
>>> when one needs to determine the slot to boot from, one does something
>>> like
>>
>> Well, there _are_ other ways...
> 
> Please do tell. How can I avoid code duplication and access a variable
> whose name I generate by string concatenation/variable interpolation?

Btw., I also considered implementing this as a separate subcommand "env
get  ", then I could do "env get result
BOOT_${slot}_LEFT". That wouldn't be quite as powerful as "env set -E",
but I think sufficient for my use case(s).

Rasmus

Re: [PATCH v3 1/5] doc: board: colibri_imx7: add readme.rst

[Heinrich Schuchardt]

On 2/11/20 8:56 PM, Igor Opaniuk wrote:

Heinrich,

On Tue, Feb 11, 2020 at 9:37 PM Igor Opaniuk  wrote:


Hi Heinrich,

On Tue, Feb 11, 2020 at 7:04 PM Heinrich Schuchardt  wrote:


On 2/11/20 4:19 PM, Igor Opaniuk wrote:

From: Igor Opaniuk 

- add initial index for toradex boards reST documentation
- add initial readme.rst file which provides all needed information
for obtaining a workable image ready for flashing
for both eMMC/NAND versions of Colibri iMX7.


Please, run checkpatch on your patch set:


I did, and this is strange, because in my case it didn't report anything.
I do use patman, so checkpatch is forced everytime,
so I would definitely catch these issues.

In my case it was just 4 warnings:
Interesting thing is that it does report also 4 warnings and that's it
for this 5 patches:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
checkpatch.pl found 0 error(s), 4 warning(s), 0 checks(s)

Magic?


u-boot-imx.git$ ./scripts/checkpatch.pl --no-tree -f doc/board/toradex/*
-
doc/board/toradex/apalix-imx8.rst
-
total: 0 errors, 0 warnings, 0 checks, 83 lines checked

doc/board/toradex/apalix-imx8.rst has no obvious style problems and is
ready for submission.
--
doc/board/toradex/colibri_imx7.rst
--
total: 0 errors, 0 warnings, 0 checks, 128 lines checked

doc/board/toradex/colibri_imx7.rst has no obvious style problems and
is ready for submission.
---
doc/board/toradex/colibri-imx8x.rst
---
total: 0 errors, 0 warnings, 0 checks, 82 lines checked

doc/board/toradex/colibri-imx8x.rst has no obvious style problems and
is ready for submission.
---
doc/board/toradex/index.rst
---
total: 0 errors, 0 warnings, 0 checks, 12 lines checked

doc/board/toradex/index.rst has no obvious style problems and is ready
for submission.
---
doc/board/toradex/verdin-imx8mm.rst
---
total: 0 errors, 0 warnings, 0 checks, 112 lines checked

doc/board/toradex/verdin-imx8mm.rst has no obvious style problems and
is ready for submission.

NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE
PREFER_ETHER_ADDR_COPY USLEEP_RANGE




ERROR: trailing whitespace
#196: FILE: doc/board/toradex/colibri_imx7.rst:66:
+* ``877ff400`` - IVT self address^M$

ERROR: DOS line endings
#273: FILE: doc/board/toradex/index.rst:9:
+   colibri_imx7^M$

Best regards

Heinrich



Signed-off-by: Igor Opaniuk 
---

   doc/board/index.rst|   1 +
   doc/board/toradex/colibri_imx7.rst | 128 +
   doc/board/toradex/index.rst|   9 ++
   3 files changed, 138 insertions(+)
   create mode 100644 doc/board/toradex/colibri_imx7.rst
   create mode 100644 doc/board/toradex/index.rst

diff --git a/doc/board/index.rst b/doc/board/index.rst
index 00e72f57cd..f2f5907b8c 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -15,4 +15,5 @@ Board-specific doc
  intel/index
  renesas/index
  sifive/index
+   toradex/index
  xilinx/index
diff --git a/doc/board/toradex/colibri_imx7.rst 
b/doc/board/toradex/colibri_imx7.rst
new file mode 100644
index 00..9d770251af
--- /dev/null
+++ b/doc/board/toradex/colibri_imx7.rst
@@ -0,0 +1,128 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Colibri iMX7
+===
+
+Quick Start
+---
+
+- Build U-Boot
+- NAND IMX image adjustments before flashing
+- Flashing manually U-Boot to eMMC
+- Flashing manually U-Boot to NAND
+- Using ``update_uboot`` script
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+$ export CROSS_COMPILE=arm-linux-gnueabi-
+$ export ARCH=arm
+$ make colibri_imx7_emmc_defconfig # For NAND: colibri_imx7_defconfig
+$ make
+
+After build succeeds, you will obtain final ``u-boot-dtb.imx`` IMX specific
+image, ready for flashing (but check next section for additional
+adjustments).
+
+Final IMX program image includes (section ``6.6.7`` from `IMX7DRM
+`_):
+
+* **Image vector table** (IVT) for BootROM
+* **Boot data** -indicates the program image location, program image size
+  in bytes, and the plugin flag.
+* **Device configuration data**
+* **User image**: U-Boot image (``u-boot-dtb.bin``)
+
+
+IMX image adjustments prior to flashing
+
+
+1. U-Boot for both Colibri iMX7 NAND and eMMC versions
+is built with HABv4 support (`AN4581.pdf

Re: FYI: Please pull u-boot-dm

[Tom Rini]

On Tue, Feb 11, 2020 at 03:26:10PM -0500, Tom Rini wrote:
> On Thu, Feb 06, 2020 at 02:55:49PM -0700, Simon Glass wrote:
> 
> > Hi Tom,
> > 
> > This cannot be pulled yet since we need to update gitlab's docker
> > image to include SDL2. But gitlab seems to be having various problems
> > this week and today i won't work at all:
> > 
> > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/2108
> > 
> > Travis is happy.
> > 
> > So I am sending this just FYI for now. Once things settle down I can
> > do a new version if needed.
> > 
> > 
> > The following changes since commit f5cc89a82a9990ba9805ff5800c0872b891533ce:
> > 
> >   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq
> > (2020-02-05 07:19:52 -0500)
> > 
> > are available in the Git repository at:
> > 
> >   https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git tags/dm-pull-6feb20
> > 
> > for you to fetch changes up to 21d651fb29cf268b1a5f64d080e3d352ee32c87f:
> > 
> >   sandbox: Complete migration away from os_malloc() (2020-02-05 21:48:23 
> > -0700)
> 
> Applied to u-boot/master, thanks!

So I've pushed this but I think it was premature:
https://gitlab.denx.de/u-boot/u-boot/-/jobs/57084 is a kind of failure
I'm seeing reliably.  I'm going to bisect down to which commit does
this, but I suspect it's the whole of the SDL2 switch.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"

[Rasmus Villemoes]

On 11/02/2020 17.30, Wolfgang Denk wrote:
> Dear Rasmus Villemoes,
> 
> In message <20200205010812.20373-1-rasmus.villem...@prevas.dk> you wrote:
>> Currently, there's no way to fetch the value of an environment
>> variable whose name is stored in some other variable, or generated from
>> such - in non-working pseudo-code,
>>
>>   ${${varname}}
>>   ${array${index}}
> 
> HUSH does not support arrays anyway...

Of course not, but they can be emulated by having variables foo0, foo1,
foo2 and programmatically accessing the variable foo$index, if only
there's a way to do that... In a sense, my BOOT_A_LEFT/BOOT_B_LEFT is
also just an array with keys "A" and "B".

>> This forces some scripts to needlessly duplicate logic and hardcode
>> assumptions. For example, in an A/B scheme with three variables
>>
>> BOOT_ORDER # Either "A B" or "B A" depending on which slot was last updated
>> BOOT_A_LEFT # 0..3
>> BOOT_B_LEFT # 0..3
>>
>> when one needs to determine the slot to boot from, one does something
>> like
> 
> Well, there _are_ other ways...

Please do tell. How can I avoid code duplication and access a variable
whose name I generate by string concatenation/variable interpolation?
I.e., I don't want anything like "if test $slot = "A" ; then setenv
result BOOT_A_LEFT ; elif test $slot = "B" ; then setenv result
BOOT_B_LEFT ; fi", because that doesn't scale.

>> This has been lightly tested in the sandbox. I'll add some proper unit
>> tests, update the help texts and try to handle the Kconfig issue if
>> this is something that might be accepted.
> 
> I'm pretty sure this will blow up in your face in real life, because
> if side effects on existing shell scripts even if you don't
> expect this. 

How so? The behaviour is completely opt-in per "env set", so nothing at
all changes for existing scripts, and it's only supposed to be used
where one would otherwise use some eval-like construct in a "normal"
shell. So

  env set -E result "\${BOOT_${x}_LEFT}"

corresponds to

  eval "result=\${BOOT_${x}_LEFT}"

And just as "eval" is used sparingly in shell scripts, I expect "env set
-E" to be used only when necessary.

> This needs _lots_ of testing with existing code /
> scripts.

I'm not proposing changing semantics of existing scripts at all.

Thanks,
Rasmus

Re: FYI: Please pull u-boot-dm

[Tom Rini]

On Thu, Feb 06, 2020 at 02:55:49PM -0700, Simon Glass wrote:

> Hi Tom,
> 
> This cannot be pulled yet since we need to update gitlab's docker
> image to include SDL2. But gitlab seems to be having various problems
> this week and today i won't work at all:
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/2108
> 
> Travis is happy.
> 
> So I am sending this just FYI for now. Once things settle down I can
> do a new version if needed.
> 
> 
> The following changes since commit f5cc89a82a9990ba9805ff5800c0872b891533ce:
> 
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq
> (2020-02-05 07:19:52 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git tags/dm-pull-6feb20
> 
> for you to fetch changes up to 21d651fb29cf268b1a5f64d080e3d352ee32c87f:
> 
>   sandbox: Complete migration away from os_malloc() (2020-02-05 21:48:23 
> -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 10/11] arm: fdt: omap: update dts panel node

[dariobin]

> Il 11 febbraio 2020 alle 5.11 Lokesh Vutla  ha scritto:
> 
> 
> 
> 
> On 11/02/20 1:49 AM, dario...@libero.it wrote:
> > Hi Lokesh
> > 
> >> Il 10 febbraio 2020 alle 5.22 Lokesh Vutla  ha scritto:
> >>
> >>
> >>
> >>
> >> On 10/02/20 12:17 AM, Dario Binacchi wrote:
> >>> Add the "u-boot,dm-pre-reloc" property to the "ti,tilcdc,panel"
> >>> compatible node. In this way the video-uclass module can allocate the
> >>> amount of memory needed to be assigned to the frame buffer.
> >>
> >> hmm..why do you need to add pre-reloc for allocating the memory? pre-reloc 
> >> flag
> >> is needed only when probing before relocation.
> >>
> > u-boot told me with an error message. 
> > Following the message I arrived at the video-uclass.c:
> > 
> > /* Device tree node may need the 'u-boot,dm-pre-reloc' or
> >  * 'u-boot,dm-pre-proper' tag
> >  */
> > printf("Video device '%s' cannot allocate frame buffer memory 
> > -ensure the device is set up before relocation\n",
> >dev->name);
> > return -ENOSPC;
> 
> When does your driver gets probed?
The driver is probed in 
int board_late_init(void)
{
ret = uclass_get_device(UCLASS_VIDEO, 0, );
if (ret)
printf("Unable to get VIDEO device (%d)\n", ret);

ret = uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, );
if (ret)
printf("Unable to get VIDEO CONSOLE device (%d)\n", ret);

snprintf(buf, sizeof(buf), "%s\n%s\n", U_BOOT_VERSION, corp);
vidconsole_position_cursor(con, 0, 0);
for (s = buf; *s; s++)
vidconsole_put_char(con, *s);

}

but, without the "u-boot,dm-pre-reloc" property, the error occurs early, during 
the video device post_binding.
I enabled debug messages in :
- drivers/core/device.c
- drivers/core/uclass.c
- drivers/video/video-uclass.c
and this is what is displayed by u-boot console:
U-Boot SPL 2018.11-rc2 (Feb 11 2020 - 17:34:58 +0100)
Trying to boot from NAND
## Checking hash(es) for Image uboot ... sha1+ OK
## Checking hash(es) for Image fdt ... sha1+ OK


U-Boot 2018.11-rc2 (Feb 11 2020 - 17:34:58 +0100)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x
DRAM:  Video frame buffers from 8fff to 8fff
256 MiB
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1 'root_driver'
   - not found
Bound device mod_exp_sw to root_driver
Bound device scm@21 to l4_wkup@44c0
Bound device l4_wkup@44c0 to ocp
Bound device gpio@44e07000 to ocp
Bound device gpio@4804c000 to ocp
Bound device gpio@481ac000 to ocp
Bound device gpio@481ae000 to ocp
Bound device serial@44e09000 to ocp
Bound device serial@48022000 to ocp
Bound device serial@48024000 to ocp
Bound device serial@481a6000 to ocp
Bound device i2c@44e0b000 to ocp
Bound device i2c@4802a000 to ocp
Bound device mmc@4806 to ocp
Bound device timer@4804 to ocp
Bound device timer@48042000 to ocp
Bound device timer@48044000 to ocp
Bound device timer@48046000 to ocp
Bound device timer@48048000 to ocp
Bound device timer@4804a000 to ocp
Bound device usb@47401000 to usb@4740
Bound device usb@47401800 to usb@4740
Bound device usb@4740 to ocp
Bound device ethernet@4a10 to ocp
Bound device ocp to root_driver
Video device 'panel' cannot allocate frame buffer memory -ensure the device is 
set up before relocation
Error binding driver 'am335x_fb': -28
Some drivers failed to bind
initcall sequence 8ffca898 failed at call 8080f71f (err=-28)
### ERROR ### Please RESET the board ###  

Thanks
Best Regards
Dario 
> 
> Thanks and regards,
> Lokesh
> 
> >>>
> >>> Signed-off-by: Dario Binacchi 
> >>
> >> $subject should be : arm: dts: am335x:
> > Ok. I will change it.
> > 
> >>
> >>> ---
> >>>
> >>>  arch/arm/dts/am335x-brppt1-mmc.dts  | 2 ++
> >>>  arch/arm/dts/am335x-brppt1-nand.dts | 2 ++
> >>>  arch/arm/dts/am335x-brppt1-spi.dts  | 2 ++
> >>>  arch/arm/dts/am335x-brsmarc1.dts| 1 +
> >>>  arch/arm/dts/am335x-brxre1.dts  | 2 ++
> >>>  arch/arm/dts/am335x-evm.dts | 1 +
> >>>  arch/arm/dts/am335x-evmsk.dts   | 1 +
> >>>  arch/arm/dts/am335x-guardian.dts| 1 +
> >>>  arch/arm/dts/am335x-pdu001.dts  | 1 +
> >>>  arch/arm/dts/am335x-pxm50.dts   | 1 +
> >>>  arch/arm/dts/am335x-rut.dts | 1 +
> >>>  arch/arm/dts/da850-evm.dts  | 1 +
> >>>  12 files changed, 16 insertions(+)
> >>>
> >>> diff --git a/arch/arm/dts/am335x-brppt1-mmc.dts 
> >>> b/arch/arm/dts/am335x-brppt1-mmc.dts
> >>> index 9be34d9da0..6f919711f0 100644
> >>> --- a/arch/arm/dts/am335x-brppt1-mmc.dts
> >>> +++ b/arch/arm/dts/am335x-brppt1-mmc.dts
> >>> @@ -53,6 +53,8 @@
> >>>   bkl-pwm = <>;
> >>>   bkl-tps = <_bl>;
> >>>  
> >>> + u-boot,dm-pre-reloc;
> >>
> >> This is u-boot specific dt flag. Please use it under *-u-boot.dtsi file.
> > Ok. I will fix it.
> > 
> > ---
> > Dario
> >>
> >> Thanks and regards,
> >> Lokesh

Re: [PATCH v3 1/5] doc: board: colibri_imx7: add readme.rst

[Igor Opaniuk]

Heinrich,

On Tue, Feb 11, 2020 at 9:37 PM Igor Opaniuk  wrote:
>
> Hi Heinrich,
>
> On Tue, Feb 11, 2020 at 7:04 PM Heinrich Schuchardt  
> wrote:
> >
> > On 2/11/20 4:19 PM, Igor Opaniuk wrote:
> > > From: Igor Opaniuk 
> > >
> > > - add initial index for toradex boards reST documentation
> > > - add initial readme.rst file which provides all needed information
> > > for obtaining a workable image ready for flashing
> > > for both eMMC/NAND versions of Colibri iMX7.
> >
> > Please, run checkpatch on your patch set:
> >
> I did, and this is strange, because in my case it didn't report anything.
> I do use patman, so checkpatch is forced everytime,
> so I would definitely catch these issues.
>
> In my case it was just 4 warnings:
> Interesting thing is that it does report also 4 warnings and that's it
> for this 5 patches:
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> checkpatch.pl found 0 error(s), 4 warning(s), 0 checks(s)
>
> Magic?

u-boot-imx.git$ ./scripts/checkpatch.pl --no-tree -f doc/board/toradex/*
-
doc/board/toradex/apalix-imx8.rst
-
total: 0 errors, 0 warnings, 0 checks, 83 lines checked

doc/board/toradex/apalix-imx8.rst has no obvious style problems and is
ready for submission.
--
doc/board/toradex/colibri_imx7.rst
--
total: 0 errors, 0 warnings, 0 checks, 128 lines checked

doc/board/toradex/colibri_imx7.rst has no obvious style problems and
is ready for submission.
---
doc/board/toradex/colibri-imx8x.rst
---
total: 0 errors, 0 warnings, 0 checks, 82 lines checked

doc/board/toradex/colibri-imx8x.rst has no obvious style problems and
is ready for submission.
---
doc/board/toradex/index.rst
---
total: 0 errors, 0 warnings, 0 checks, 12 lines checked

doc/board/toradex/index.rst has no obvious style problems and is ready
for submission.
---
doc/board/toradex/verdin-imx8mm.rst
---
total: 0 errors, 0 warnings, 0 checks, 112 lines checked

doc/board/toradex/verdin-imx8mm.rst has no obvious style problems and
is ready for submission.

NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE
PREFER_ETHER_ADDR_COPY USLEEP_RANGE

>
> > ERROR: trailing whitespace
> > #196: FILE: doc/board/toradex/colibri_imx7.rst:66:
> > +* ``877ff400`` - IVT self address^M$
> >
> > ERROR: DOS line endings
> > #273: FILE: doc/board/toradex/index.rst:9:
> > +   colibri_imx7^M$
> >
> > Best regards
> >
> > Heinrich
> >
> > >
> > > Signed-off-by: Igor Opaniuk 
> > > ---
> > >
> > >   doc/board/index.rst|   1 +
> > >   doc/board/toradex/colibri_imx7.rst | 128 +
> > >   doc/board/toradex/index.rst|   9 ++
> > >   3 files changed, 138 insertions(+)
> > >   create mode 100644 doc/board/toradex/colibri_imx7.rst
> > >   create mode 100644 doc/board/toradex/index.rst
> > >
> > > diff --git a/doc/board/index.rst b/doc/board/index.rst
> > > index 00e72f57cd..f2f5907b8c 100644
> > > --- a/doc/board/index.rst
> > > +++ b/doc/board/index.rst
> > > @@ -15,4 +15,5 @@ Board-specific doc
> > >  intel/index
> > >  renesas/index
> > >  sifive/index
> > > +   toradex/index
> > >  xilinx/index
> > > diff --git a/doc/board/toradex/colibri_imx7.rst 
> > > b/doc/board/toradex/colibri_imx7.rst
> > > new file mode 100644
> > > index 00..9d770251af
> > > --- /dev/null
> > > +++ b/doc/board/toradex/colibri_imx7.rst
> > > @@ -0,0 +1,128 @@
> > > +.. SPDX-License-Identifier: GPL-2.0+
> > > +
> > > +Colibri iMX7
> > > +===
> > > +
> > > +Quick Start
> > > +---
> > > +
> > > +- Build U-Boot
> > > +- NAND IMX image adjustments before flashing
> > > +- Flashing manually U-Boot to eMMC
> > > +- Flashing manually U-Boot to NAND
> > > +- Using ``update_uboot`` script
> > > +
> > > +Build U-Boot
> > > +
> > > +
> > > +.. code-block:: bash
> > > +
> > > +$ export CROSS_COMPILE=arm-linux-gnueabi-
> > > +$ export ARCH=arm
> > > +$ make colibri_imx7_emmc_defconfig # For NAND: colibri_imx7_defconfig
> > > +$ make
> > > +
> > > +After build succeeds, you will obtain final ``u-boot-dtb.imx`` IMX 
> > > specific
> > > +image, ready for flashing (but check next section for additional
> > > +adjustments).
> > > +
> > > +Final IMX program image includes (section ``6.6.7`` from `IMX7DRM
> > > +`_):
> > > +
> > > +* **Image vector table** (IVT) for BootROM
> > 

Re: [PATCH v3 1/5] doc: board: colibri_imx7: add readme.rst

[Igor Opaniuk]

Hi Heinrich,

On Tue, Feb 11, 2020 at 7:04 PM Heinrich Schuchardt  wrote:
>
> On 2/11/20 4:19 PM, Igor Opaniuk wrote:
> > From: Igor Opaniuk 
> >
> > - add initial index for toradex boards reST documentation
> > - add initial readme.rst file which provides all needed information
> > for obtaining a workable image ready for flashing
> > for both eMMC/NAND versions of Colibri iMX7.
>
> Please, run checkpatch on your patch set:
>
I did, and this is strange, because in my case it didn't report anything.
I do use patman, so checkpatch is forced everytime,
so I would definitely catch these issues.

In my case it was just 4 warnings:
Interesting thing is that it does report also 4 warnings and that's it
for this 5 patches:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
checkpatch.pl found 0 error(s), 4 warning(s), 0 checks(s)

Magic?

> ERROR: trailing whitespace
> #196: FILE: doc/board/toradex/colibri_imx7.rst:66:
> +* ``877ff400`` - IVT self address^M$
>
> ERROR: DOS line endings
> #273: FILE: doc/board/toradex/index.rst:9:
> +   colibri_imx7^M$
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Igor Opaniuk 
> > ---
> >
> >   doc/board/index.rst|   1 +
> >   doc/board/toradex/colibri_imx7.rst | 128 +
> >   doc/board/toradex/index.rst|   9 ++
> >   3 files changed, 138 insertions(+)
> >   create mode 100644 doc/board/toradex/colibri_imx7.rst
> >   create mode 100644 doc/board/toradex/index.rst
> >
> > diff --git a/doc/board/index.rst b/doc/board/index.rst
> > index 00e72f57cd..f2f5907b8c 100644
> > --- a/doc/board/index.rst
> > +++ b/doc/board/index.rst
> > @@ -15,4 +15,5 @@ Board-specific doc
> >  intel/index
> >  renesas/index
> >  sifive/index
> > +   toradex/index
> >  xilinx/index
> > diff --git a/doc/board/toradex/colibri_imx7.rst 
> > b/doc/board/toradex/colibri_imx7.rst
> > new file mode 100644
> > index 00..9d770251af
> > --- /dev/null
> > +++ b/doc/board/toradex/colibri_imx7.rst
> > @@ -0,0 +1,128 @@
> > +.. SPDX-License-Identifier: GPL-2.0+
> > +
> > +Colibri iMX7
> > +===
> > +
> > +Quick Start
> > +---
> > +
> > +- Build U-Boot
> > +- NAND IMX image adjustments before flashing
> > +- Flashing manually U-Boot to eMMC
> > +- Flashing manually U-Boot to NAND
> > +- Using ``update_uboot`` script
> > +
> > +Build U-Boot
> > +
> > +
> > +.. code-block:: bash
> > +
> > +$ export CROSS_COMPILE=arm-linux-gnueabi-
> > +$ export ARCH=arm
> > +$ make colibri_imx7_emmc_defconfig # For NAND: colibri_imx7_defconfig
> > +$ make
> > +
> > +After build succeeds, you will obtain final ``u-boot-dtb.imx`` IMX specific
> > +image, ready for flashing (but check next section for additional
> > +adjustments).
> > +
> > +Final IMX program image includes (section ``6.6.7`` from `IMX7DRM
> > +`_):
> > +
> > +* **Image vector table** (IVT) for BootROM
> > +* **Boot data** -indicates the program image location, program image size
> > +  in bytes, and the plugin flag.
> > +* **Device configuration data**
> > +* **User image**: U-Boot image (``u-boot-dtb.bin``)
> > +
> > +
> > +IMX image adjustments prior to flashing
> > +
> > +
> > +1. U-Boot for both Colibri iMX7 NAND and eMMC versions
> > +is built with HABv4 support (`AN4581.pdf
> > +`_)
> > +enabled by default, which requires to generate a proper
> > +Command Sequence File (CSF) by srktool from NXP (not included in the
> > +U-Boot tree, check additional details in introduction_habv4.txt)
> > +and concatenate it to the final ``u-boot-dtb.imx``.
> > +
> > +2. In case if you don't want to generate a proper ``CSF`` (for any reason),
> > +you still need to pad the IMX image so i has the same size as specified in
> > +in **Boot Data** section of IMX image.
> > +To obtain this value, run:
> > +
> > +.. code-block:: bash
> > +
> > +$ od -X -N 0x30 u-boot-dtb.imx
> > +000402000d1 8780  877ff42c
> > +020877ff420 877ff400 878a5000 
> > +
> > +040877ff000 000a8060  40b401d2
> > +    
> > +
> > +Where:
> > +
> > +* ``877ff400`` - IVT self address
> > +* ``877ff000`` - Program image address
> > +* ``000a8060`` - Program image size
> > +
> > +To calculate the padding:
> > +
> > +* IVT offset = ``0x877ff400`` - ``0x877ff000`` = ``0x400``
> > +* Program image size = ``0xa8060`` - ``0x400`` = ``0xa7c60``
> > +
> > +and then pad the image:
> > +
> > +.. code-block:: bash
> > +
> > +$ objcopy -I binary -O binary --pad-to 0xa7c60 

Re: FYI: Please pull u-boot-dm

[Tom Rini]

On Tue, Feb 11, 2020 at 11:20:36AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 8 Feb 2020 at 07:51, Simon Glass  wrote:
> >
> > Hi Stephen,
> >
> > On Thu, 6 Feb 2020 at 15:38, Simon Glass  wrote:
> > >
> > > Hi Stephen,
> > >
> > > On Thu, 6 Feb 2020 at 15:32, Stephen Warren  wrote:
> > > >
> > > > On 2/6/20 2:55 PM, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > This cannot be pulled yet since we need to update gitlab's docker
> > > > > image to include SDL2. But gitlab seems to be having various problems
> > > > > this week and today i won't work at all: ...
> > > >
> > > > I see the following build error in u-boot-dm/master via Jenkins:
> > > >
> > > > > drivers/misc/p2sb_emul.c: In function ‘sandbox_p2sb_emul_map_physmem’:
> > > > > drivers/misc/p2sb_emul.c:237:6: warning: ‘child’ may be used 
> > > > > uninitialized in this function [-Wmaybe-uninitialized]
> > > > >   ret = axi_read(child, offset, priv->regs, AXI_SIZE_32);
> > > > >   ^
> > > > >   CC  common
> > >
> > > Hmmm that's odd. I don't see that, but there are so many device-tree
> > > and libfdt warnings at present I may have missed it. Will take a look.
> >
> > That doesn't happen with my gcc 7.3 toolchain. I'll send a patch to
> > set child to NULL at the start, but a look at the code shows that it
> > is correct.
> >
> > Also this is in master and was not introduced by this series.
> 
> A fix for this is going in via the x86 tree.
> 
> Tom, is there anything else you need from me for this pull request?

Testing it now, thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Heinrich Schuchardt]

On 2/7/20 4:13 AM, Chang, Abner (HPS SW/FW Technologist) wrote:




-Original Message-
From: Atish Patra [mailto:ati...@atishpatra.org]
Sent: Friday, February 7, 2020 6:56 AM
To: Ard Biesheuvel ; Chang, Abner (HPS SW/FW
Technologist) 
Cc: Alexander Graf ; Heinrich Schuchardt
; U-Boot Mailing List ; Atish
Patra ; l...@nuviainc.com
Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel 
wrote:


On Thu, 6 Feb 2020 at 21:06, Atish Patra  wrote:


On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf  wrote:



On 06.02.20 19:28, Atish Patra wrote:

On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
 wrote:

On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt

 wrote:

RISC-V booting currently is based on a per boot stage lottery
to determine the active CPU. The Hart State Management (HSM)
SBI extension replaces this lottery by using a dedicated primary

CPU.


Cf. Hart State Management Extension, Extension ID: 0x48534D
(HSM)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.a
doc

In this scenario the id of the active hart has to be passed
from boot stage to boot stage. Using a UEFI variable would provide

an easy implementation.


This patch provides a weak function that is called at the end
of the setup of U-Boot's UEFI sub-system. By overriding this
function architecture specific UEFI variables or configuration tables

can be created.


Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Atish Patra 

OK, so I have a couple of questions:

- does RISC-V use device tree? if so, why are you not passing
the active hart via a property in the /chosen node?

Yes. RISC-V uses device tree. Technically, we can pass the
active hart by a DT property but that means we have to modify
the DT in OpenSBI (RISC-V specific run time service provider).
We have been trying to avoid that if possible so that DT is not
bounced around. This also limits U-Boot to have its own device
tree.



I don't understand how this is different from the UEFI variable
scheme proposed here? If you want to create an SBI interface to
propagate the active HART that U-Boot then uses to populate the
/chosen property, that's probably fine as well.



We don't want to create SBI interface to pass this information.


We already have hooks that allow you to modify the DT right before
it gets delivered to the payload. Just add it there?



Hmm. I guess it is true if the DT is loaded from MMC or network as well.
How about EDK2 ? If we go DT route, it also has to modify the DT to
pass the boot hart.

As it requires DT modification in multiple projects, why not use efi
configuration tables as suggested by Ard ?



Configuration tables are preferred over variables, but putting it in
the DT makes even more sense, since in that case, nothing that runs in
the UEFI context has to care about any of this.





I'd assume the EFI stub would not care at all about this
information, and it would give you a Linux/RISC-V specific way
to convey this information that is independent of EFI.

Yes. EFI stub doesn't care about this information. However, it
needs to save the information somewhere so that it can pass to
the real kernel after exiting boot time services.



DT sounds like a pretty natural choice for that to me :).



Indeed. DT has a /chosen node that is set aside for this purpose. It
does depend on how early you need the value (i.e., before or after you
can run C code), but since you are passing the DT address to the core
kernel, it makes way more sense to drop any additional information
that you need to pass in there.


We don't need boot hart id until real kernel boots and parse DT. So that
should be okay.
I just looked at the efi stub code once more and realized that it is already
parsing the DT to setup uefi memory maps from /chosen node. Adding boot
hart id to the chosen node does seem much cleaner to me :). Thanks for all
the explanations.

I have not looked at EDK2 code. But I am assuming modifying the DT just
before jumping to the payload won't be too hard for EDK2 as well.

We don’t use DT in edk2 RISC-V port and we pass boot HART ID in SMBIOS type 44h 
as it is spec out in below link,
https://github.com/riscv/riscv-smbios/blob/master/RISCV-SMBIOS.md


Thanks for the link.

For 'RISC-V SMBIOS Type 44 Processor Additional Information' I find
entry 0x13h 1: This is boot hart to boot system .

But is '44' a hexadecimal number? The document does not indicate this.

Best regards

Heinrich



Abner



Added Leif and Abner for the opinion.



--
Regards,
Atish

Re: FYI: Please pull u-boot-dm

[Simon Glass]

Hi Tom,

On Sat, 8 Feb 2020 at 07:51, Simon Glass  wrote:
>
> Hi Stephen,
>
> On Thu, 6 Feb 2020 at 15:38, Simon Glass  wrote:
> >
> > Hi Stephen,
> >
> > On Thu, 6 Feb 2020 at 15:32, Stephen Warren  wrote:
> > >
> > > On 2/6/20 2:55 PM, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > This cannot be pulled yet since we need to update gitlab's docker
> > > > image to include SDL2. But gitlab seems to be having various problems
> > > > this week and today i won't work at all: ...
> > >
> > > I see the following build error in u-boot-dm/master via Jenkins:
> > >
> > > > drivers/misc/p2sb_emul.c: In function ‘sandbox_p2sb_emul_map_physmem’:
> > > > drivers/misc/p2sb_emul.c:237:6: warning: ‘child’ may be used 
> > > > uninitialized in this function [-Wmaybe-uninitialized]
> > > >   ret = axi_read(child, offset, priv->regs, AXI_SIZE_32);
> > > >   ^
> > > >   CC  common
> >
> > Hmmm that's odd. I don't see that, but there are so many device-tree
> > and libfdt warnings at present I may have missed it. Will take a look.
>
> That doesn't happen with my gcc 7.3 toolchain. I'll send a patch to
> set child to NULL at the start, but a look at the code shows that it
> is correct.
>
> Also this is in master and was not introduced by this series.

A fix for this is going in via the x86 tree.

Tom, is there anything else you need from me for this pull request?

Regards,
Simon

Re: [PATCH 1/1] test: log functions with CONFIG_LOG=n

[Heinrich Schuchardt]

On 2/11/20 6:14 PM, Simon Glass wrote:

Hi Heinrich,

On Mon, 10 Feb 2020 at 22:36, Heinrich Schuchardt  wrote:


If CONFIG_LOG=n, we still expect output for log_err(), log_warning(),
log_notice(), log_info() and in case of DEBUG=1 also for log_debug().

Provide unit tests verifying this.

The tests depend on:

 CONFIG_CONSOLE_RECORD=y
 CONFIG_LOG=n

It may be necessary to increase the value of CONFIG_SYS_MALLOC_F_LEN to
accommodate CONFIG_CONSOLE_RECORD=y.

Signed-off-by: Heinrich Schuchardt 
---
  MAINTAINERS   |   2 +-
  include/test/suites.h |   1 +
  test/Makefile |   2 +-
  test/cmd_ut.c |   6 ++
  test/log/Makefile |   4 ++
  test/log/nolog_test.c | 147 ++
  6 files changed, 160 insertions(+), 2 deletions(-)
  create mode 100644 test/log/nolog_test.c



Looks good - but can you please look at u-boot-dm/master, e.g. this one:

400175b0a7 test: Add a way to check each line of console output

as we don't want to call membuff directory.


I found your patch in WIP/11Feb2020. Thanks for the hint.

Best regards

Heinrich

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Daniel Kiper]

On Wed, Feb 05, 2020 at 12:37:03PM +0100, Heinrich Schuchardt wrote:
> Hello Daniel, hello Leif,
>
> what is the GRUB view on this discussion?

Alex, could you chime in on this as a GRUB RISC-V maintainer?

Daniel

> Best regards
>
> Heinrich
>
> On 2/5/20 12:32 PM, Heinrich Schuchardt wrote:
> > On 2/5/20 8:43 AM, Ard Biesheuvel wrote:
> > > On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt 
> > > wrote:
> > > >
> > > > RISC-V booting currently is based on a per boot stage lottery to
> > > > determine
> > > > the active CPU. The Hart State Management (HSM) SBI extension replaces
> > > > this lottery by using a dedicated primary CPU.
> > > >
> > > > Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
> > > > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
> > > >
> > > > In this scenario the id of the active hart has to be passed from boot
> > > > stage
> > > > to boot stage. Using a UEFI variable would provide an easy
> > > > implementation.
> > > >
> > > > This patch provides a weak function that is called at the end of the
> > > > setup
> > > > of U-Boot's UEFI sub-system. By overriding this function architecture
> > > > specific UEFI variables or configuration tables can be created.
> > > >
> > > > Signed-off-by: Heinrich Schuchardt 
> > > > Reviewed-by: Atish Patra 
> > >
> > > OK, so I have a couple of questions:
> > >
> > > - does RISC-V use device tree? if so, why are you not passing the
> >
> > In the Linux kernel tree you can find the SiFive HiFive Unleashed device
> > tree: arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
> >
> > Some of the QEMU emulated RISC-V boards provide device trees, cf.
> > https://github.com/riscv/riscv-qemu/wiki#machines
> >
> > > active hart via a property in the /chosen node? I'd assume the EFI
> >
> > There is a hart (core) that calls the entry point of the next
> > boot-stage. Could this define the active hart?
> >
> > Best regards
> >
> > Heinrich
> >
> > > stub would not care at all about this information, and it would give
> > > you a Linux/RISC-V specific way to convey this information that is
> > > independent of EFI.
> > > - using variables to pass information from firmware to OS only is
> > > overkill, and config tables are preferred, given that they only
> > > require access to the system table. If required, a RISC-V specific
> > > data structure containing boot parameters could be installed as a
> > > configuration table, and the address passed to the startup code in the
> > > kernel proper [rather than just a hart id], allowing you to put any
> > > piece of information you like in there.
> > >
> > > Config tables work fine with kexec, btw. It is up to the first OS to
> > > memblock_reserve() the table to guarantee that it is still there at
> > > kexec time, but this applies equally to all other data structures
> > > passed as config tables. Alternatively, in this case, you can
> > > stipulate that it is passed as AcpiReclaim [ignore the 'Acpi' in the
> > > name] which is intended for firmware tables (and we never reclaim it
> > > in linux)
> > >
> > > I'd also recommend that RISC-V adopt the same principle as ARM does
> > > when it comes to EFI: call SetVirtualAddressMap in the stub, so that
> > > the kernel proper always sees the same handover state, regardless of
> > > kexec. Additionally, you shouldn't ever modify the EFI memory map
> > > provided by the firmware, so that the kexec kernel sees the exact same
> > > version.
> > >
> > >
> > >
> > >
> > > > ---
> > > > v2:
> > > >  reference the Hart State Management Extension in the commit
> > > > message
> > > > ---
> > > >   include/efi_loader.h   |  3 +++
> > > >   lib/efi_loader/efi_setup.c | 16 
> > > >   2 files changed, 19 insertions(+)
> > > >
> > > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > > index d4c59b54c4..d87de85e83 100644
> > > > --- a/include/efi_loader.h
> > > > +++ b/include/efi_loader.h
> > > > @@ -116,6 +116,9 @@ extern efi_uintn_t efi_memory_map_key;
> > > >   extern struct efi_runtime_services efi_runtime_services;
> > > >   extern struct efi_system_table systab;
> > > >
> > > > +/* Architecture specific initialization of the UEFI system */
> > > > +efi_status_t efi_setup_arch_specific(void);
> > > > +
> > > >   extern struct efi_simple_text_output_protocol efi_con_out;
> > > >   extern struct efi_simple_text_input_protocol efi_con_in;
> > > >   extern struct efi_console_control_protocol efi_console_control;
> > > > diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> > > > index de7b616c6d..8469f0f43c 100644
> > > > --- a/lib/efi_loader/efi_setup.c
> > > > +++ b/lib/efi_loader/efi_setup.c
> > > > @@ -22,6 +22,17 @@ void __weak allow_unaligned(void)
> > > >   {
> > > >   }
> > > >
> > > > +/**
> > > > + * efi_setup_arch_specific() - architecture specific UEFI setup
> > > > + *
> > > > + * This routine can be used to define architecture specific variables
> > > > + * or 

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Mauro Condarelli]

Thanks Daniel.

On 2/11/20 5:49 PM, Daniel Schwierzeck wrote:
> On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli  wrote:
>> ===8<
>> Hit any key to stop autoboot:  0
>> =>
> ok, booting from RAM works. But what I meant with bootable is, that
> you can write the
> the u-boot-mtmips.bin to SPI flash and do a cold boot. Only then we
> can merge your patch.
It *does* work.
The U-Boot I have flashed is essentially the same as the one built
in the "master" directory, just a few days old (I changed essentially
my project-specific CONFIG_EXTRA_ENV_SETTINGS).

... which reminds me of something...

... it turns out that flashing *does* work:

=> setenv autoload no; dhcp; tftpboot 8500
192.168.7.101:u-boot-mtmips.bin; sf probe; sf update ${fileaddr} 0
${filesize}
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.7.110 (2953 ms)
Using eth@1011 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.110
Filename 'u-boot-mtmips.bin'.
Load address: 0x8500
Loading: #
     762.7 KiB/s
done
Bytes transferred = 244458 (3baea hex)
device 0 offset 0x0, size 0x3baea
240362 bytes written, 4096 bytes skipped in 2.232s, speed 111952 B/s
=> reset
resetting ...

U-Boot SPL 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)
Trying to boot from NOR


U-Boot 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: VoCore2
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@1013: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
Model: VoCore2
Net:  
Warning: eth@1011 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93
eth0: eth@1011
Hit any key to stop autoboot:  0
=>

What *does NOT* work is loading RAM version or, to be more precise:
It works IF (and only if) you load the same code already running.
I *think* this is because current Weijie code unpacks to this same location
(8020) before relocating. If you are rewriting the same code in the
same location any cache inconsistencies are unimportant, otherwise
Bad Things happen.
I spoke with Stephan about this, but we never found a fix.

Now that I reflashed "u-boot-mips/testing" version I can run it also
"from RAM", while trying to load "master" hangs (I tried just now).

If this is considered "acceptable" (probably it has nothing to do with my
vocore2 port) I can clean-up my patches and resubmit.
I'm not a mips expert and I don't know how to debug this "RAM load"
misbehavior, but I'm available for testing, if useful.


>> ===8<---
 I *do* have a bootable patchset built on top of master + Nemirovsky
 "reconfigurable cpu clocks" + Weijie v3.
 Result is fully working, including net and mmc/SD.

 This patchset applies cleanly to uboot-mips/testing and compile
 apparently without errors, but resulting u-boot.bin does not work.
 By "does not work" I mean it does not utter a single char on debug
 serial.

 I tried to do a complete diff between my working tree and this
 non-working one and there are tons of differences, but I couldn't
 spot anything that might be relevant.

 I am unsure on how to proceed; please advise.
> maybe you have a big diff because you are not on the latest master
> branch. I currently
> have ae347120eed8204b1fdf018ddf79131964e57016. The u-boot-mips/testing is 
> based
> on u-boot-mips/next and only contains Weijie's v3 patches from 14/20
> to 20/20. For
> u-boot-mips/next I intend to create a pull request soon. The existing
> mtmips boards should
> still work without SPL support. Maybe Stefan could give it a quick test.
>
> Maybe I messed something up in u-boot-mips/testing. There were some
> merge conflicts.
I don't think so.
As said problem is with RAM loading.

> Could you build a new patch queue on top of u-boot-mips/next with the 
> remaining
> Weijie v3 patches and your VoCore2 patches?
I can do that if You think it's still useful, otherwise we can
just use testing.

> As long as all u-boot-mips changes aren't merged to mainline, your
> patches must work with
> the latest u-boot-mips/next branch. There could always be new and
> incompatible changes
Understood.

> in mainline or in other MIPS patches which you have to figure out then.
I don't think  there'll be problems.
My patches are quite basic and board-only.

I plan to clean my patch expunging all project-specific stuff,
rebase from the (current) tip of uboot-mips-mips/testing and
resubmit (unless You tell me to do something different,
of course).

For the Ram-lading problem I do not currently plan any
action, but I'm available.

Best Regards (and pardon me for the noise, please)
Mauro Condarelli

[PATCH] travis/gitlab/azure: Ensure we use python3 always

[Tom Rini]

When running our tests there are some cases where as part of the Python
2.7 to Python 3.6 migration we didn't force Python 3.6 to be used as
everything wasn't yet migrated.  Now that everything is, make sure to
tell virtualenv to use python3.  In the case of Travis this is best done
by making the tools test happen after the main tests so that it will
already have been run in all cases, TEST_PY_TOOLS is a subset of
TEST_PY_BD.

Signed-off-by: Tom Rini 
---
 .azure-pipelines.yml |  2 +-
 .gitlab-ci.yml   |  4 ++--
 .travis.yml  | 18 --
 3 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 052c3aa278b5..c22095830c0c 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -123,7 +123,7 @@ jobs:
   git config --global user.name "Azure Pipelines"
   git config --global user.email bmeng...@gmail.com
   export USER=azure
-  virtualenv /tmp/venv
+  virtualenv -p /usr/bin/python3 /tmp/venv
   . /tmp/venv/bin/activate
   pip install pyelftools
   export UBOOT_TRAVIS_BUILD_DIR=/tmp/.bm-work/sandbox_spl
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index e20a789ac150..d486e72042fb 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -72,7 +72,7 @@ build all 64bit ARM platforms:
   tags: [ 'all' ]
   stage: world build
   script:
-- virtualenv /tmp/venv
+- virtualenv -p /usr/bin/python3 /tmp/venv
 - . /tmp/venv/bin/activate
 - pip install pyelftools
 - ret=0;
@@ -157,7 +157,7 @@ Run binman, buildman, dtoc and patman testsuites:
 - git config --global user.name "GitLab CI Runner";
   git config --global user.email tr...@konsulko.com;
   export USER=gitlab;
-  virtualenv /tmp/venv;
+  virtualenv -p /usr/bin/python3 /tmp/venv;
   . /tmp/venv/bin/activate;
   pip install pyelftools;
   export UBOOT_TRAVIS_BUILD_DIR=/tmp/.bm-work/sandbox_spl;
diff --git a/.travis.yml b/.travis.yml
index 3991eb7716fb..23c181e8d377 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -133,16 +133,6 @@ script:
cp ~/grub_x64.efi $UBOOT_TRAVIS_BUILD_DIR/;
cp ~/grub2-arm/usr/lib/grub2/arm-efi/grub.efi 
$UBOOT_TRAVIS_BUILD_DIR/grub_arm.efi;
cp ~/grub2-arm64/usr/lib/grub2/arm64-efi/grub.efi 
$UBOOT_TRAVIS_BUILD_DIR/grub_arm64.efi;
-   if [[ -n "${TEST_PY_TOOLS}" ]]; then
- PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt"
- PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}"
- ./tools/binman/binman --toolpath ${UBOOT_TRAVIS_BUILD_DIR}/tools test &&
- ./tools/patman/patman --test &&
- ./tools/buildman/buildman -t &&
- PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt"
- PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}"
- ./tools/dtoc/dtoc -t;
-   fi;
if [[ "${TEST_PY_BD}" != "" ]]; then
  virtualenv -p /usr/bin/python3 /tmp/venv;
  . /tmp/venv/bin/activate;
@@ -154,6 +144,14 @@ script:
  if [[ $ret -ne 0 ]]; then
exit $ret;
  fi;
+ if [[ -n "${TEST_PY_TOOLS}" ]]; then
+   export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt";
+   export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}";
+   ./tools/binman/binman --toolpath ${UBOOT_TRAVIS_BUILD_DIR}/tools test &&
+   ./tools/patman/patman --test &&
+   ./tools/buildman/buildman -t &&
+   ./tools/dtoc/dtoc -t;
+ fi;
fi
 
 matrix:
-- 
2.17.1

[PATCH] sandbox: Update PCI nodes in dts files

[Tom Rini]

The way the PCI nodes are written today causes a number of warnings if
we stop disabling some of the warnings we pass to DTC.  As these
warnings aren't disabled in current Linux Kernel builds, we should aim
to not disable them here either, so rewrite these slightly.  Update the
driver model doc as well.

Cc: Simon Glass 
Signed-off-by: Tom Rini 
---
 arch/sandbox/dts/sandbox.dts   |  5 +++--
 arch/sandbox/dts/sandbox.dtsi  |  2 +-
 arch/sandbox/dts/sandbox64.dts |  5 +++--
 arch/sandbox/dts/test.dts  |  9 ++---
 doc/driver-model/pci-info.rst  | 10 +-
 5 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index 4dd82f6a32fd..2d7db0249ebe 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -10,7 +10,7 @@
 
aliases {
i2c0 = _0;
-   pci0 = 
+   pci0 = 
rtc0 = _0;
axi0 = 
spi0 = 
@@ -52,9 +52,10 @@
pinctrl-0 = <_i2c0>;
};
 
-   pci: pci-controller {
+   pcic: pci@0 {
compatible = "sandbox,pci";
device_type = "pci";
+   bus-range = <0x00 0xff>;
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x0200 0 0x1000 0x1000 0 0x2000
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 7bf144f53265..f7f3de784292 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -99,7 +99,7 @@
};
};
 
-   pci-controller {
+   pci@0 {
pci@1e,0 {
compatible = "sandbox,pmc";
reg = <0xf000 0 0 0 0>;
diff --git a/arch/sandbox/dts/sandbox64.dts b/arch/sandbox/dts/sandbox64.dts
index 5c95cee9d7a9..97e33f110eef 100644
--- a/arch/sandbox/dts/sandbox64.dts
+++ b/arch/sandbox/dts/sandbox64.dts
@@ -10,7 +10,7 @@
 
aliases {
i2c0 = _0;
-   pci0 = 
+   pci0 = 
rtc0 = _0;
axi0 = 
spi0 = 
@@ -47,9 +47,10 @@
pinctrl-0 = <_i2c0>;
};
 
-   pci: pci-controller {
+   pcic: pci@0 {
compatible = "sandbox,pci";
device_type = "pci";
+   bus-range = <0x00 0xff>;
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x0200 0 0x1000 0 0x1000 0 0x2000
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index c22844743143..4d3c42077858 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -463,9 +463,10 @@
compatible = "sandbox,pch";
};
 
-   pci0: pci-controller0 {
+   pci0: pci@0 {
compatible = "sandbox,pci";
device_type = "pci";
+   bus-range = <0x00 0xff>;
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x0200 0 0x1000 0x1000 0 0x200
@@ -531,9 +532,10 @@
};
};
 
-   pci1: pci-controller1 {
+   pci1: pci@1 {
compatible = "sandbox,pci";
device_type = "pci";
+   bus-range = <0x00 0xff>;
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x0200 0 0x3000 0x3000 0 0x2000
@@ -546,9 +548,10 @@
};
};
 
-   pci2: pci-controller2 {
+   pci2: pci@2 {
compatible = "sandbox,pci";
device_type = "pci";
+   bus-range = <0x00 0xff>;
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x0200 0 0x5000 0x5000 0 0x2000
diff --git a/doc/driver-model/pci-info.rst b/doc/driver-model/pci-info.rst
index 3c1b1adf077e..8b9faa106638 100644
--- a/doc/driver-model/pci-info.rst
+++ b/doc/driver-model/pci-info.rst
@@ -12,10 +12,10 @@ Bus number 0 will need to be requested first, and the alias 
in the device
 tree file will point to the correct device::
 
aliases {
-   pci0 = 
+   pci0 = 
};
 
-   pci: pci-controller {
+   pcic: pci@0 {
compatible = "sandbox,pci";
...
};
@@ -138,7 +138,7 @@ be scanned as a PCI device, causing confusion.
 
 When this bus is scanned we will end up with something like this::
 
-   `- * pci-controller @ 05c660c8, 0
+   `- * pci@0 @ 05c660c8, 0
 `-   pci@1f,0 @ 05c661c8, 63488
`-   emul@1f,0 @ 05c662c8
 
@@ -152,7 +152,7 @@ host controller node for this functionality to work.
 
 .. code-block:: none
 
-   pci1: pci-controller1 {
+   pci1: pci@1 {
compatible = "sandbox,pci";
...
sandbox,dev-info = <0x08 0x00 0x1234 0x5678
@@ -166,6 +166,6 @@ fourth cells are PCI 

Re: [PATCH v4 05/17] dm: Add support for simple-pm-bus

[Sean Anderson]

Hi Simon,

On 2/11/20 12:14 PM, Simon Glass wrote:
> Hi Sean,
> 
> On Mon, 10 Feb 2020 at 23:05, Sean Anderson  wrote:
>>
>> This type of bus is used in Linux to designate busses which have power
> 
> buses
> 
>> domains and/or clocks which need to be enabled before their child devices
>> can be used.  Because power domains are automatically enabled before
>> probing in u-boot, we just need to enable any clocks present.
> 
> U-Boot
> 
>>
>> Signed-off-by: Sean Anderson 
>> ---
> 
> With the above and below fixed:
> 
> Reviewed-by: Simon Glass 
> 

Will do, thanks.

>> diff --git a/drivers/core/simple-pm-bus.c b/drivers/core/simple-pm-bus.c
>> new file mode 100644
>> index 00..3ee54531d1
>> --- /dev/null
>> +++ b/drivers/core/simple-pm-bus.c
>> @@ -0,0 +1,55 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2020 Sean Anderson 
>> + */
>> +
> 
> common.h
> 
>> +#include 
>> +#include 
> 
> clk.h above dm.h
> 
>> diff --git a/test/dm/simple-pm-bus.c b/test/dm/simple-pm-bus.c
>> new file mode 100644
>> index 00..1b42415ccd
>> --- /dev/null
>> +++ b/test/dm/simple-pm-bus.c
>> @@ -0,0 +1,44 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2020 Sean Anderson 
>> + */
>> +
> 
> Please fix include ordering
> 
> https://www.denx.de/wiki/U-Boot/CodingStyle

Ah, I wasn't aware that there was a specific ordering; I had been doing
it alphabetically.

--Sean

Re: [PATCH 1/9] dma-mapping: fix the prototype of dma_map_single()

[Simon Glass]

On Tue, 11 Feb 2020 at 08:19, Masahiro Yamada  wrote:
>
> Hi Simon,
>
> On Wed, Feb 5, 2020 at 9:17 AM Simon Glass  wrote:
> >
> > On Tue, 4 Feb 2020 at 04:09, Masahiro Yamada
> >  wrote:
> > >
> > > Make dma_map_single() return the dma address, and remove the
> > > pointless volatile.
> > >
> > > Signed-off-by: Masahiro Yamada 
> > > ---
> > >
> > >  arch/arm/include/asm/dma-mapping.h   | 5 +++--
> > >  arch/nds32/include/asm/dma-mapping.h | 5 +++--
> > >  arch/riscv/include/asm/dma-mapping.h | 5 +++--
> > >  arch/x86/include/asm/dma-mapping.h   | 5 +++--
> > >  4 files changed, 12 insertions(+), 8 deletions(-)
> >
> > Reviewed-by: Simon Glass 
> >
> > But please can you add a full function comment in the header files?
>
>
> I can comment them, but it is tedious to duplicate
> exactly the same description to all of these architectures.
>
> So, my next plan is to merge them into
> include/asm-generic/dma-mapping.h,
> then make it a single point of comments.
>
> Each arch's  can simply wraps
> 
>
> It would be beyond the scope of this series
> (since my main motivation is fix the mmc/sdhci bug).
>
> So, I want to just let this series go in.
>
> After it lands, I can factoring them out,
> and add some comments.

OK sounds good.

BTW while I agree that duplicating comments is annoying, it's better
than not having comments.

Regards,
Simon

Re: [PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"

[Simon Glass]

Hi Rasmus,

On Tue, 11 Feb 2020 at 08:38, Rasmus Villemoes
 wrote:
>
> On 05/02/2020 18.59, Simon Glass wrote:
> > Hi Rasmus,
> >
>
> >> This has been lightly tested in the sandbox. I'll add some proper unit
> >> tests, update the help texts and try to handle the Kconfig issue if
> >> this is something that might be accepted.
> >>
> >> Signed-off-by: Rasmus Villemoes 
> >> ---
> >>  cmd/nvedit.c | 17 -
> >>  1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > Seems OK to me.
>
> Thanks. I'll go ahead and write some tests.
>
> > I suppose we don't want to implement bash's nested
> > expansion? ${var${suffix}}
>
> It's not that easy to implement inside-out expansion, one needs to
> juggle a lot of temporary buffers. So I went with the rather simple
> one-extra-pass, which can mostly achieve the same things (although
> perhaps the script needs to do a few extra steps).
>
> Out of curiosity, what bash version supports the above?
>
> $ echo $BASH_VERSION
> 4.4.20(1)-release
> $ foo_a=3
> $ foo_b=7
> $ x=a
> $ echo ${foo_${x}}
> bash: ${foo_${x}}: bad substitution
>
> however, this variant is supported:
>
> $ var=foo_$x
> $ echo ${var}
> foo_a
> $ echo ${!var}
> 3

Er, yes, sorry I was thinking of Makefiles.

Regards,
Simon

Re: [PATCH 1/3] test_vboot.py: remove extraneous -k option to fit_check_sign

[Simon Glass]

Hi Rasmus,

On Tue, 11 Feb 2020 at 02:49, Rasmus Villemoes
 wrote:
>

Please add a commit message with motivation and effect.

> Signed-off-by: Rasmus Villemoes 
> ---
>  test/py/tests/test_vboot.py | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>

Regards,
Simon

Re: [PATCH v4 04/17] reset: Add generic reset driver

[Simon Glass]

On Mon, 10 Feb 2020 at 23:05, Sean Anderson  wrote:
>
> This patch adds a generic reset driver. It is designed to be useful when
> one has a register in a regmap which contains bits that reset other
> devices. I thought this seemed like a very generic use, so here is a
> generic driver. The overall structure has been modeled on the syscon-reboot
> driver.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v4:
> - Added basic test
> - Fix incorrect usage of regmap_update_bits
>
> Changes in v3:
> - New
>
>  arch/sandbox/dts/test.dts | 15 
>  configs/sandbox_defconfig |  1 +
>  .../reset/syscon-reset.txt| 36 +
>  drivers/reset/Kconfig |  5 ++
>  drivers/reset/Makefile|  1 +
>  drivers/reset/reset-syscon.c  | 79 +++
>  test/dm/Makefile  |  1 +
>  test/dm/syscon-reset.c| 58 ++
>  8 files changed, 196 insertions(+)
>  create mode 100644 doc/device-tree-bindings/reset/syscon-reset.txt
>  create mode 100644 drivers/reset/reset-syscon.c
>  create mode 100644 test/dm/syscon-reset.c

Please fix the include-file ordering fixed in the two .c files in this
patch. Then:

Reviewed-by: Simon Glass 

Re: dm: core: Board failing to boot since commit 82de42fa1468 (parent data/probe)

[Simon Glass]

+Bin

Hi Wolfgang,

On Tue, 11 Feb 2020 at 06:59, Wolfgang Wallner
 wrote:
>
> Hello Simon,
>
> Since commit 82de42fa1468 ("dm: core: Allocate parent data separate from
> probing parent") I have trouble booting my board (a custom Apollo Lake design
> booted via Coreboot + U-Boot).
>
> I think this is because the function ns16550_serial_ofdata_to_platdata() of
> the UART driver noew tries to access the PCI bus before it is probed.
> I'm aware of the comment which you have added to pci-uclass.c [1].
>
> So the correct way to fix this would be to adapt the uart driver in ns16550.c?

Why is the UART being used so early? Also, if you are booting from
coreboot you really shouldn't need to auto-config PCI at all, so
perhaps just disable CONFIG_PCI_PNP? But I understand that that
changes the build.

The way I fixed it is to allow the UART to stay at a fixed PCI address:

9e11293319 dm: pci: Allow disabling auto-config for a device

That's in u-boot-dm/coral-working

>
> regards, Wolfgang
>
> Detail information:
>
> As far as I understand the situation the following things happen:
>  * My debug UART is probed
>  * This triggers a call to ns16550_serial_ofdata_to_platdata()
>  * This function tries to read BAR0 from the PCI devices
>  * Reading BAR0 returns 0x, as the PCI bus has not been probed yet
>  * The serial driver tries to read from a non-existing register based on this
>invalid BAR0 value and hangs indefinitely.
>
> This is confirmed by the warning which you have introduced a few commits 
> ealier
> in commit 4886287ee4f9 ("pci: Print a warning if the bus is accessed before
> probing"):
>
>   "dm_pci_get_bdf() PCI: Device 'uart@18,2' on unprobed bus 'pci'"
>
> [1] "A common cause of this problem is that this function is called in the
> ofdata_to_platdata() method of @dev. Accessing the PCI bus in that
> method is not allowed, since it has not yet been probed. To fix this,
> move that access to the probe() method of @dev instead."

Regards,
Simon

Re: [PATCH v4 06/17] spi: dw: Add device tree properties for fields in CTRL1

[Simon Glass]

On Mon, 10 Feb 2020 at 23:05, Sean Anderson  wrote:
>
> Some devices have different layouts for the fields in CTRL1 (e.g. the
> Kendryte K210). Allow this layout to be configurable from the device tree.
> The documentation has been taken from Linux.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v4:
> - New
>
>  .../spi/snps,dw-apb-ssi.txt   | 43 +++
>  drivers/spi/designware_spi.c  | 40 ++---
>  2 files changed, 68 insertions(+), 15 deletions(-)
>  create mode 100644 doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt
>

Reviewed-by: Simon Glass 

Re: [PATCH 2/3] tools: add fdt_add_pubkey

[Simon Glass]

Hi Rasmus,

On Tue, 11 Feb 2020 at 02:49, Rasmus Villemoes
 wrote:
>
> Having to use the -K option to mkimage to populate U-Boot's .dtb with the
> public key while signing the kernel FIT image is often a little
> awkward. In particular, when using a meta-build system such as
> bitbake/Yocto, having the tasks of the kernel and U-Boot recipes
> intertwined, modifying deployed artifacts and rebuilding U-Boot with
> an updated .dtb is quite cumbersome. Also, in some scenarios one may
> wish to build U-Boot complete with the public key(s) embedded in the
> .dtb without the corresponding private keys being present on the same
> build host.
>
> So this adds a simple tool that allows one to disentangle the kernel
> and U-Boot builds, by simply copy-pasting just enough of the mkimage
> code to allow one to add a public key to a .dtb. When using mkimage,
> some of the information is taken from the .its used to build the
> kernel (algorithm and key name), so that of course needs to be
> supplied on the command line.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  tools/.gitignore   |  1 +
>  tools/Makefile |  3 ++
>  tools/fdt_add_pubkey.c | 96 ++
>  3 files changed, 100 insertions(+)
>  create mode 100644 tools/fdt_add_pubkey.c

Would it be possible to modify mkimage instead, with another flag?

Regards,
Simon

Re: [PATCH 1/1] log: output for CONFIG_LOG=n

[Simon Glass]

Hi Heinrich,

On Mon, 10 Feb 2020 at 21:17, Heinrich Schuchardt  wrote:
>
>
>
> On 2/11/20 12:13 AM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Sun, 9 Feb 2020 at 15:33, Heinrich Schuchardt  wrote:
> >>
> >> On 2/9/20 11:21 PM, Sean Anderson wrote:
> >>> On 2/9/20 4:59 PM, Heinrich Schuchardt wrote:
>  If CONFIG_LOG=n, we should still output errors, warnings, notices, infos,
>  and for DEBUG=1 also debug messages.
> 
>  Signed-off-by: Heinrich Schuchardt 
> >>>
> >>> Why not just change the default for CONFIG_LOG to y? This is effectively
> >>> the same, except it still allows users to completely disable logging
> >>> altogether.
> >>>
> >>> --Sean
> >>>
> >>
> >
> > Reviewed-by: Simon Glass 
> >
> >> I have tested your suggestion for qemu_arm64_defconfig:
> >>
> >> Without my patch and CONFIG_LOG=n:
> >>
> >> u-boot.bin 664200 bytes
> >>
> >> With my patch and CONFIG_LOG=n:
> >>
> >> u-boot.bin 664432 bytes
> >>
> >> Without my patch but with CONFIG_LOG=y and CONFIG_CONSOLE=y:
> >
> > What is CONFIG_CONSOLE?
>
> This is a typo. It should be CONFIG_LOG_CONSOLE.
>
> Thanks for reviewing.
>
> >
> >>
> >> u-boot.bin 48 bytes
> >>
> >> So your suggestion consumes 2216 additional bytes to produce the
> >> essentially the same console output.
> >
> > OK. That is a lot more than I thought.
> >
> > I'm not sure if it is possible to update the log test to cover your new 
> > case?
>
> The current log test case in not a close fit, as filtering will be
> irrelevant.
>
> It should be possible to create a test using console recording
> (CONFIG_CONSOLE_RECORD=y).
>
> Looking at test/dm/test-main.c it seems that you once wanted to use
> console recording in a test but I could not identify any test actually
> using it up to now.

There is a pending pull request in dm/master which has this.

One challenge might be that you need a test that only runs if
CONFIG_LOG is not enabled. Perhaps you could use sandbox_spl for that?

Regards,
Simon

Re: [PATCH 1/1] common/console.c: discard volatile

[Simon Glass]

On Tue, 11 Feb 2020 at 05:05, Heinrich Schuchardt  wrote:
>
> Avoid errors of like
>
> common/console.c: In function ‘console_record_reset’:
> common/console.c:615:16: error: passing argument 1 of ‘membuff_purge’
> discards ‘volatile’ qualifier from pointer target type
> [-Werror=discarded-qualifiers]
>   615 |  membuff_purge(>console_out);
>   |^~~~
>
> by casting to non-volatile.
>
> The volatile property stems from declarations like
>
> arch/arm/include/asm/global_data.h:114:
>
> But there is no need to treat gd->console_out and gd->console_in as
> volatile in the context of common/console.c.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/console.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 1/1] test: log functions with CONFIG_LOG=n

[Simon Glass]

Hi Heinrich,

On Mon, 10 Feb 2020 at 22:36, Heinrich Schuchardt  wrote:
>
> If CONFIG_LOG=n, we still expect output for log_err(), log_warning(),
> log_notice(), log_info() and in case of DEBUG=1 also for log_debug().
>
> Provide unit tests verifying this.
>
> The tests depend on:
>
> CONFIG_CONSOLE_RECORD=y
> CONFIG_LOG=n
>
> It may be necessary to increase the value of CONFIG_SYS_MALLOC_F_LEN to
> accommodate CONFIG_CONSOLE_RECORD=y.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  MAINTAINERS   |   2 +-
>  include/test/suites.h |   1 +
>  test/Makefile |   2 +-
>  test/cmd_ut.c |   6 ++
>  test/log/Makefile |   4 ++
>  test/log/nolog_test.c | 147 ++
>  6 files changed, 160 insertions(+), 2 deletions(-)
>  create mode 100644 test/log/nolog_test.c
>

Looks good - but can you please look at u-boot-dm/master, e.g. this one:

400175b0a7 test: Add a way to check each line of console output

as we don't want to call membuff directory.

Regards,
Simon

Re: [PATCH v4 05/17] dm: Add support for simple-pm-bus

[Simon Glass]

Hi Sean,

On Mon, 10 Feb 2020 at 23:05, Sean Anderson  wrote:
>
> This type of bus is used in Linux to designate busses which have power

buses

> domains and/or clocks which need to be enabled before their child devices
> can be used.  Because power domains are automatically enabled before
> probing in u-boot, we just need to enable any clocks present.

U-Boot

>
> Signed-off-by: Sean Anderson 
> ---

With the above and below fixed:

Reviewed-by: Simon Glass 

>
> Changes in v4:
> - Split the bus off into its own driver
> - Add test
> - Fix line spacing in Kconfig
> - Lint
>
> Changes in v3:
> - New
>
>  arch/sandbox/dts/test.dts |  6 ++
>  arch/sandbox/include/asm/clk.h|  1 +
>  configs/sandbox_defconfig |  1 +
>  .../bus/simple-pm-bus.txt | 44 +++
>  drivers/core/Kconfig  |  7 +++
>  drivers/core/Makefile |  1 +
>  drivers/core/simple-pm-bus.c  | 55 +++
>  test/dm/Makefile  |  1 +
>  test/dm/simple-pm-bus.c   | 44 +++
>  9 files changed, 160 insertions(+)
>  create mode 100644 doc/device-tree-bindings/bus/simple-pm-bus.txt
>  create mode 100644 drivers/core/simple-pm-bus.c
>  create mode 100644 test/dm/simple-pm-bus.c
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 23f2aefd43..648f21239a 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -929,6 +929,12 @@
> compatible = "sandbox,mdio";
> };
>
> +   pm-bus-test {
> +   compatible = "simple-pm-bus";
> +   clocks = <_sandbox 4>;
> +   power-domains = < 1>;
> +   };
> +
> resetc2: syscon-reset {
> compatible = "syscon-reset";
> #reset-cells = <1>;
> diff --git a/arch/sandbox/include/asm/clk.h b/arch/sandbox/include/asm/clk.h
> index 1573e4a134..c184c4bffc 100644
> --- a/arch/sandbox/include/asm/clk.h
> +++ b/arch/sandbox/include/asm/clk.h
> @@ -21,6 +21,7 @@ enum sandbox_clk_id {
> SANDBOX_CLK_ID_I2C,
> SANDBOX_CLK_ID_UART1,
> SANDBOX_CLK_ID_UART2,
> +   SANDBOX_CLK_ID_BUS,
>
> SANDBOX_CLK_ID_COUNT,
>  };
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index 19970f1db5..c637b39b96 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -89,6 +89,7 @@ CONFIG_REGMAP=y
>  CONFIG_SYSCON=y
>  CONFIG_DEVRES=y
>  CONFIG_DEBUG_DEVRES=y
> +CONFIG_SIMPLE_PM_BUS=y
>  CONFIG_ADC=y
>  CONFIG_ADC_SANDBOX=y
>  CONFIG_AXI=y
> diff --git a/doc/device-tree-bindings/bus/simple-pm-bus.txt 
> b/doc/device-tree-bindings/bus/simple-pm-bus.txt
> new file mode 100644
> index 00..6f15037131
> --- /dev/null
> +++ b/doc/device-tree-bindings/bus/simple-pm-bus.txt
> @@ -0,0 +1,44 @@
> +Simple Power-Managed Bus
> +
> +
> +A Simple Power-Managed Bus is a transparent bus that doesn't need a real
> +driver, as it's typically initialized by the boot loader.
> +
> +However, its bus controller is part of a PM domain, or under the control of a
> +functional clock.  Hence, the bus controller's PM domain and/or clock must be
> +enabled for child devices connected to the bus (either on-SoC or externally)
> +to function.
> +
> +While "simple-pm-bus" follows the "simple-bus" set of properties, as 
> specified
> +in the Devicetree Specification, it is not an extension of "simple-bus".
> +
> +
> +Required properties:
> +  - compatible: Must contain at least "simple-pm-bus".
> +   Must not contain "simple-bus".
> +   It's recommended to let this be preceded by one or more
> +   vendor-specific compatible values.
> +  - #address-cells, #size-cells, ranges: Must describe the mapping between
> +   parent address and child address spaces.
> +
> +Optional platform-specific properties for clock or PM domain control (at 
> least
> +one of them is required):
> +  - clocks: Must contain a reference to the functional clock(s),
> +  - power-domains: Must contain a reference to the PM domain.
> +Please refer to the binding documentation for the clock and/or PM domain
> +providers for more details.
> +
> +
> +Example:
> +
> +   bsc: bus@fec1 {
> +   compatible = "renesas,bsc-sh73a0", "renesas,bsc",
> +"simple-pm-bus";
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges = <0 0 0x2000>;
> +   reg = <0xfec1 0x400>;
> +   interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
> +   clocks = <_clk>;
> +   power-domains = <_a4s>;
> +   };
> diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
> index 3b95b5387b..0cd687526e 100644
> --- a/drivers/core/Kconfig
> +++ b/drivers/core/Kconfig
> @@ -195,6 +195,13 @@ config 

Re: [PATCH v3 5/5] doc: board: add rockchip subfolder

[Heinrich Schuchardt]

On 2/11/20 5:48 PM, Heinrich Schuchardt wrote:

On 2/11/20 4:19 PM, Igor Opaniuk wrote:

From: Igor Opaniuk 

This fixes a warning when invoking make htmldocs:
checking consistency...
doc/board/rockchip/index.rst: WARNING: document isn't included in any
toctree

Signed-off-by: Igor Opaniuk 


I stumbled over the same issue:
https://lists.denx.de/pipermail/u-boot/2020-February/399494.html

Reviewed-by: Heinrich Schuchardt 


ERROR: DOS line endings
#121: FILE: doc/board/index.rst:17:
+   rockchip/index^M$

Best regards

Heinrich Schuchardt

Re: [PATCH v3 4/5] doc: board: colibri-imx8x: convert readme to reST

[Heinrich Schuchardt]

On 2/11/20 4:19 PM, Igor Opaniuk wrote:

From: Igor Opaniuk 

Convert README to reStructuredText format.


ERROR: DOS line endings
#276: FILE: doc/board/toradex/colibri-imx8x.rst:82:
+mmc write ${loadaddr} 0x0 ${blkcnt}^M$

ERROR: DOS line endings
#285: FILE: doc/board/toradex/index.rst:11:
+   colibri-imx8x^M$

Best regards

Heinrich Schuchardt



Signed-off-by: Igor Opaniuk 
---

  board/toradex/colibri-imx8x/README  | 66 ---
  doc/board/toradex/colibri-imx8x.rst | 82 +
  doc/board/toradex/index.rst |  1 +
  3 files changed, 83 insertions(+), 66 deletions(-)
  delete mode 100644 board/toradex/colibri-imx8x/README
  create mode 100644 doc/board/toradex/colibri-imx8x.rst

diff --git a/board/toradex/colibri-imx8x/README 
b/board/toradex/colibri-imx8x/README
deleted file mode 100644
index 708bb3e51c..00
--- a/board/toradex/colibri-imx8x/README
+++ /dev/null
@@ -1,66 +0,0 @@
-U-Boot for the Toradex Colibri iMX8QXP V1.0B Module
-
-Quick Start
-===
-
-- Build the ARM trusted firmware binary
-- Get scfw_tcm.bin and ahab-container.img
-- Build U-Boot
-- Load U-Boot binary using uuu
-- Flash U-Boot binary into the eMMC
-- Boot
-
-Get and Build the ARM Trusted Firmware
-==
-
-$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf/
-$ make PLAT=imx8qxp bl31
-
-Get scfw_tcm.bin and ahab-container.img
-===
-
-$ wget 
https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-bsp/imx-sc-firmware/files/mx8qx-colibri-scfw-tcm.bin?raw=true
-$ mv mx8qx-colibri-scfw-tcm.bin\?raw\=true mx8qx-colibri-scfw-tcm.bin
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
-$ chmod +x firmware-imx-8.0.bin
-$ ./firmware-imx-8.0.bin
-
-Copy the following binaries to the U-Boot folder:
-
-$ cp imx-atf/build/imx8qxp/release/bl31.bin .
-$ cp u-boot/u-boot.bin .
-
-Copy the following firmware to the U-Boot folder:
-
-$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
-
-Build U-Boot
-
-
-$ make colibri-imx8qxp_defconfig
-$ make u-boot-dtb.imx
-
-Load the U-Boot Binary Using UUU
-
-
-Get the latest version of the universal update utility (uuu) aka mfgtools 3.0:
-
-https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
-
-Put the module into USB recovery aka serial downloader mode, connect USB device
-to your host and execute uuu:
-
-sudo ./uuu u-boot/u-boot-dtb.imx
-
-Flash the U-Boot Binary into the eMMC
-=
-
-Burn the u-boot-dtb.imx binary to the primary eMMC hardware boot area 
partition:
-
-load mmc 1:1 $loadaddr u-boot-dtb.imx
-setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
-mmc dev 0 1
-mmc write ${loadaddr} 0x0 ${blkcnt}
-
-Boot
diff --git a/doc/board/toradex/colibri-imx8x.rst 
b/doc/board/toradex/colibri-imx8x.rst
new file mode 100644
index 00..ce9195af73
--- /dev/null
+++ b/doc/board/toradex/colibri-imx8x.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Colibri iMX8QXP V1.0B Module
+===
+
+Quick Start
+---
+
+- Build the ARM trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Load U-Boot binary using uuu
+- Flash U-Boot binary into the eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware
+--
+
+.. code-block:: bash
+
+$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf/
+$ make PLAT=imx8qxp bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---
+.. code-block:: bash
+
+$ wget https://github.com/toradex/meta-fsl-bsp-release/blob/
+   toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-
+   bsp/imx-sc-firmware/files/mx8qx-colibri-scfw-tcm.bin?raw=true
+$ mv mx8qx-colibri-scfw-tcm.bin\?raw\=true mx8qx-colibri-scfw-tcm.bin
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+$ chmod +x firmware-imx-8.0.bin
+$ ./firmware-imx-8.0.bin
+
+Copy the following binaries to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp imx-atf/build/imx8qxp/release/bl31.bin .
+$ cp u-boot/u-boot.bin .
+
+Copy the following firmware to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+   $ make colibri-imx8qxp_defconfig
+   $ make u-boot-dtb.imx
+
+Load the U-Boot Binary Using UUU
+
+
+Get the latest version of the universal update utility (uuu) aka ``mfgtools 
3.0``:
+
+https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
+
+Put 

Re: [PATCH v3 2/5] doc: board: verdin-imx8mm: convert readme to reST

[Heinrich Schuchardt]

On 2/11/20 4:19 PM, Igor Opaniuk wrote:

From: Igor Opaniuk 

Convert README to reStructuredText format.


Please, run checkpatch on your patch set:

ERROR: DOS line endings
#334: FILE: doc/board/toradex/verdin-imx8mm.rst:111:
+Hit any key to stop autoboot:  0^M$

ERROR: DOS line endings
#335: FILE: doc/board/toradex/verdin-imx8mm.rst:112:
+Verdin iMX8MM #^M$

Best regards

Heinrich



Signed-off-by: Igor Opaniuk 
---

  board/toradex/verdin-imx8mm/README  |  88 --
  doc/board/toradex/index.rst |   1 +
  doc/board/toradex/verdin-imx8mm.rst | 112 
  3 files changed, 113 insertions(+), 88 deletions(-)
  delete mode 100644 board/toradex/verdin-imx8mm/README
  create mode 100644 doc/board/toradex/verdin-imx8mm.rst

diff --git a/board/toradex/verdin-imx8mm/README 
b/board/toradex/verdin-imx8mm/README
deleted file mode 100644
index 1dac969476..00
--- a/board/toradex/verdin-imx8mm/README
+++ /dev/null
@@ -1,88 +0,0 @@
-U-Boot for the Toradex Verdin iMX8M Mini Module
-
-Quick Start
-===
-
-- Build the ARM trusted firmware binary
-- Get the DDR firmware
-- Build U-Boot
-- Flash to eMMC
-- Boot
-
-Get and Build the ARM Trusted Firmware (Trusted Firmware A)
-===
-
-$ echo "Downloading and building TF-A..."
-$ git clone -b imx_4.14.98_2.3.0 
https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf
-
-Please edit `plat/imx/imx8mm/include/platform_def.h` so it contains proper
-values for UART configuration and BL31 base address (correct values listed
-below):
-#define BL31_BASE  0x91
-#define IMX_BOOT_UART_BASE 0x3086
-#define DEBUG_CONSOLE  1
-
-Then build ATF (TF-A):
-$ make PLAT=imx8mm bl31
-
-Get the DDR Firmware
-
-
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.4.1.bin
-$ chmod +x firmware-imx-8.4.1.bin
-$ ./firmware-imx-8.4.1.bin
-$ cp firmware-imx-8.4.1/firmware/ddr/synopsys/lpddr4*.bin ./
-
-Build U-Boot
-
-
-$ export CROSS_COMPILE=aarch64-linux-gnu-
-$ make verdin-imx8mm_defconfig
-$ make flash.bin
-
-Flash to eMMC
-=
-
-> tftpboot ${loadaddr} flash.bin
-> setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
-> mmc dev 0 1 && mmc write ${loadaddr} 0x2 ${blkcnt}
-
-As a convenience, instead of the last two commands one may also use the update
-U-Boot wrapper:
-> run update_uboot
-
-Boot
-
-
-ATF, U-boot proper and u-boot.dtb images are packed into FIT image,
-which is loaded and parsed by SPL.
-
-Boot sequence is:
-SPL ---> ATF (TF-A) ---> U-boot proper
-
-Output:
-U-Boot SPL 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
-Normal Boot
-Trying to boot from MMC1
-NOTICE:  Configuring TZASC380
-NOTICE:  RDC off
-NOTICE:  BL31: v2.0(release):rel_imx_4.14.98_2.3.0-0-g09c5cc994-dirty
-NOTICE:  BL31: Built : 01:11:41, Jan 25 2020
-NOTICE:  sip svc init
-
-
-U-Boot 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
-
-CPU:   Freescale i.MX8MMQ rev1.0 at 0 MHz
-Reset cause: POR
-DRAM:  2 GiB
-MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
-Loading Environment from MMC... OK
-In:serial
-Out:   serial
-Err:   serial
-Model: Toradex Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT V1.0A, Serial# 06535149
-Net:   eth0: ethernet@30be
-Hit any key to stop autoboot:  0
-Verdin iMX8MM #
diff --git a/doc/board/toradex/index.rst b/doc/board/toradex/index.rst
index aa418d6bad..6cd2ade9f4 100644
--- a/doc/board/toradex/index.rst
+++ b/doc/board/toradex/index.rst
@@ -7,3 +7,4 @@ Toradex
 :maxdepth: 2

 colibri_imx7
+   verdin-imx8mm
diff --git a/doc/board/toradex/verdin-imx8mm.rst 
b/doc/board/toradex/verdin-imx8mm.rst
new file mode 100644
index 00..5363251dee
--- /dev/null
+++ b/doc/board/toradex/verdin-imx8mm.rst
@@ -0,0 +1,112 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Verdin iMX8M Mini Module
+===
+
+Quick Start
+---
+
+- Build the ARM trusted firmware binary
+- Get the DDR firmware
+- Build U-Boot
+- Flash to eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware (Trusted Firmware A)
+---
+
+.. code-block:: bash
+
+$ echo "Downloading and building TF-A..."
+$ git clone -b imx_4.14.98_2.3.0 \
+  https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf
+
+Please edit ``plat/imx/imx8mm/include/platform_def.h`` so it contains proper
+values for UART configuration and BL31 base address (correct values listed
+below):
+
+.. code-block:: bash
+
+#define BL31_BASE   0x91
+#define IMX_BOOT_UART_BASE  0x3086
+#define DEBUG_CONSOLE   1
+
+Then build ATF (TF-A):
+
+.. code-block:: bash
+
+$ make PLAT=imx8mm bl31
+
+Get the DDR Firmware
+
+
+.. code-block:: bash
+
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.4.1.bin
+

Re: [PATCH v3 3/5] doc: board: apalis-imx8: convert readme to reST

[Heinrich Schuchardt]

On 2/11/20 4:19 PM, Igor Opaniuk wrote:

From: Igor Opaniuk 

Convert README to reStructuredText format.


ERROR: DOS line endings
#277: FILE: doc/board/toradex/apalix-imx8.rst:83:
+^M$

ERROR: DOS line endings
#286: FILE: doc/board/toradex/index.rst:9:
+   apalix-imx8^M$

Best regards

Heinrich



Signed-off-by: Igor Opaniuk 
---

  board/toradex/apalis-imx8/README  | 66 
  doc/board/toradex/apalix-imx8.rst | 83 +++
  doc/board/toradex/index.rst   |  1 +
  3 files changed, 84 insertions(+), 66 deletions(-)
  delete mode 100644 board/toradex/apalis-imx8/README
  create mode 100644 doc/board/toradex/apalix-imx8.rst

diff --git a/board/toradex/apalis-imx8/README b/board/toradex/apalis-imx8/README
deleted file mode 100644
index e6e3dcb367..00
--- a/board/toradex/apalis-imx8/README
+++ /dev/null
@@ -1,66 +0,0 @@
-U-Boot for the Toradex Apalis iMX8QM V1.0B Module
-
-Quick Start
-===
-
-- Build the ARM trusted firmware binary
-- Get scfw_tcm.bin and ahab-container.img
-- Build U-Boot
-- Load U-Boot binary using uuu
-- Flash U-Boot binary into the eMMC
-- Boot
-
-Get and Build the ARM Trusted Firmware
-==
-
-$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf/
-$ make PLAT=imx8qm bl31
-
-Get scfw_tcm.bin and ahab-container.img
-===
-
-$ wget 
https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-bsp/imx-sc-firmware/files/mx8qm-apalis-scfw-tcm.bin?raw=true
-$ mv mx8qm-apalis-scfw-tcm.bin\?raw\=true mx8qm-apalis-scfw-tcm.bin
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
-$ chmod +x firmware-imx-8.0.bin
-$ ./firmware-imx-8.0.bin
-
-Copy the following binaries to the U-Boot folder:
-
-$ cp imx-atf/build/imx8qm/release/bl31.bin .
-$ cp u-boot/u-boot.bin .
-
-Copy the following firmware to the U-Boot folder:
-
-$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
-
-Build U-Boot
-
-
-$ make apalis-imx8qm_defconfig
-$ make u-boot-dtb.imx
-
-Load the U-Boot Binary Using UUU
-
-
-Get the latest version of the universal update utility (uuu) aka mfgtools 3.0:
-
-https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
-
-Put the module into USB recovery aka serial downloader mode, connect USB device
-to your host and execute uuu:
-
-sudo ./uuu u-boot/u-boot-dtb.imx
-
-Flash the U-Boot Binary into the eMMC
-=
-
-Burn the u-boot-dtb.imx binary to the primary eMMC hardware boot area 
partition:
-
-load mmc 1:1 $loadaddr u-boot-dtb.imx
-setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
-mmc dev 0 1
-mmc write ${loadaddr} 0x0 ${blkcnt}
-
-Boot
diff --git a/doc/board/toradex/apalix-imx8.rst 
b/doc/board/toradex/apalix-imx8.rst
new file mode 100644
index 00..e0c2929032
--- /dev/null
+++ b/doc/board/toradex/apalix-imx8.rst
@@ -0,0 +1,83 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Apalis iMX8QM V1.0B Module
+=
+
+Quick Start
+---
+
+- Build the ARM trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Load U-Boot binary using uuu
+- Flash U-Boot binary into the eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware
+--
+
+.. code-block:: bash
+
+$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf/
+$ make PLAT=imx8qm bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---
+
+.. code-block:: bash
+
+$ wget 
https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-
+  bsp/imx-sc-firmware/files/mx8qm-apalis-scfw-tcm.bin?raw=true
+$ mv mx8qm-apalis-scfw-tcm.bin\?raw\=true mx8qm-apalis-scfw-tcm.bin
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+$ chmod +x firmware-imx-8.0.bin
+$ ./firmware-imx-8.0.bin
+
+Copy the following binaries to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp imx-atf/build/imx8qm/release/bl31.bin .
+$ cp u-boot/u-boot.bin .
+
+Copy the following firmware to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
+
+Build U-Boot
+
+.. code-block:: bash
+
+$ make apalis-imx8qm_defconfig
+$ make u-boot-dtb.imx
+
+Load the U-Boot Binary Using UUU
+
+
+Get the latest version of the universal update utility (uuu) aka ``mfgtools 
3.0``:
+
+https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
+
+Put the module into USB recovery aka serial downloader mode, connect USB device
+to your host and execute uuu:
+

Re: [PATCH v3 1/5] doc: board: colibri_imx7: add readme.rst

[Heinrich Schuchardt]

On 2/11/20 4:19 PM, Igor Opaniuk wrote:

From: Igor Opaniuk 

- add initial index for toradex boards reST documentation
- add initial readme.rst file which provides all needed information
for obtaining a workable image ready for flashing
for both eMMC/NAND versions of Colibri iMX7.


Please, run checkpatch on your patch set:

ERROR: trailing whitespace
#196: FILE: doc/board/toradex/colibri_imx7.rst:66:
+* ``877ff400`` - IVT self address^M$

ERROR: DOS line endings
#273: FILE: doc/board/toradex/index.rst:9:
+   colibri_imx7^M$

Best regards

Heinrich



Signed-off-by: Igor Opaniuk 
---

  doc/board/index.rst|   1 +
  doc/board/toradex/colibri_imx7.rst | 128 +
  doc/board/toradex/index.rst|   9 ++
  3 files changed, 138 insertions(+)
  create mode 100644 doc/board/toradex/colibri_imx7.rst
  create mode 100644 doc/board/toradex/index.rst

diff --git a/doc/board/index.rst b/doc/board/index.rst
index 00e72f57cd..f2f5907b8c 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -15,4 +15,5 @@ Board-specific doc
 intel/index
 renesas/index
 sifive/index
+   toradex/index
 xilinx/index
diff --git a/doc/board/toradex/colibri_imx7.rst 
b/doc/board/toradex/colibri_imx7.rst
new file mode 100644
index 00..9d770251af
--- /dev/null
+++ b/doc/board/toradex/colibri_imx7.rst
@@ -0,0 +1,128 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Colibri iMX7
+===
+
+Quick Start
+---
+
+- Build U-Boot
+- NAND IMX image adjustments before flashing
+- Flashing manually U-Boot to eMMC
+- Flashing manually U-Boot to NAND
+- Using ``update_uboot`` script
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+$ export CROSS_COMPILE=arm-linux-gnueabi-
+$ export ARCH=arm
+$ make colibri_imx7_emmc_defconfig # For NAND: colibri_imx7_defconfig
+$ make
+
+After build succeeds, you will obtain final ``u-boot-dtb.imx`` IMX specific
+image, ready for flashing (but check next section for additional
+adjustments).
+
+Final IMX program image includes (section ``6.6.7`` from `IMX7DRM
+`_):
+
+* **Image vector table** (IVT) for BootROM
+* **Boot data** -indicates the program image location, program image size
+  in bytes, and the plugin flag.
+* **Device configuration data**
+* **User image**: U-Boot image (``u-boot-dtb.bin``)
+
+
+IMX image adjustments prior to flashing
+
+
+1. U-Boot for both Colibri iMX7 NAND and eMMC versions
+is built with HABv4 support (`AN4581.pdf
+`_)
+enabled by default, which requires to generate a proper
+Command Sequence File (CSF) by srktool from NXP (not included in the
+U-Boot tree, check additional details in introduction_habv4.txt)
+and concatenate it to the final ``u-boot-dtb.imx``.
+
+2. In case if you don't want to generate a proper ``CSF`` (for any reason),
+you still need to pad the IMX image so i has the same size as specified in
+in **Boot Data** section of IMX image.
+To obtain this value, run:
+
+.. code-block:: bash
+
+$ od -X -N 0x30 u-boot-dtb.imx
+000402000d1 8780  877ff42c
+020877ff420 877ff400 878a5000 
+
+040877ff000 000a8060  40b401d2
+    
+
+Where:
+
+* ``877ff400`` - IVT self address
+* ``877ff000`` - Program image address
+* ``000a8060`` - Program image size
+
+To calculate the padding:
+
+* IVT offset = ``0x877ff400`` - ``0x877ff000`` = ``0x400``
+* Program image size = ``0xa8060`` - ``0x400`` = ``0xa7c60``
+
+and then pad the image:
+
+.. code-block:: bash
+
+$ objcopy -I binary -O binary --pad-to 0xa7c60 --gap-fill=0x00 \
+u-boot-dtb.imx u-boot-dtb.imx.zero-padded
+
+3. Also, according to requirement from ``6.6.7.1``, the final image
+should have ``0x400`` offset for initial IVT table.
+
+For eMMC setup we handle this by flashing it to ``0x400``, howewer
+for NAND setup we adjust the image prior to flashing, adding padding in the
+beginning of the image.
+
+.. code-block:: bash
+
+$ dd if=u-boot-dtb.imx.zero-padded of=u-boot-dtb.imx.ready bs=1024 seek=1
+
+Flash U-Boot IMX image to eMMC
+--
+
+Flash the ``u-boot-dtb.imx.zero-padded`` binary to the primary eMMC hardware
+boot area partition:
+
+.. code-block:: bash
+
+
+=> load mmc 1:1 $loadaddr u-boot-dtb.imx.zero-padded
+=> setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+=> mmc dev 0 1
+=> mmc write ${loadaddr} 0x2 ${blkcnt}
+
+Flash U-Boot IMX image to NAND
+--
+
+.. code-block:: bash
+
+=> load mmc 1:1 $loadaddr u-boot-dtb.imx.ready
+=> nand erase.part u-boot1
+=> nand write ${loadaddr} u-boot1 ${filesize}
+=> nand erase.part u-boot2
+=> nand write ${loadaddr} u-boot2 ${filesize}
+
+Using update_uboot script

Re: [PATCH 1/1] net: designware: speed should be in a debug message

[Heinrich Schuchardt]

On 2/10/20 3:41 AM, Bin Meng wrote:

Hi Heinrich,

On Sun, Feb 9, 2020 at 11:58 AM Heinrich Schuchardt  wrote:


On 2/9/20 3:59 AM, Bin Meng wrote:

On Sun, Feb 9, 2020 at 8:38 AM Heinrich Schuchardt  wrote:


The network connection speed is a debug information. So we should use
debug() and not printf().

Signed-off-by: Heinrich Schuchardt 
---
   drivers/net/designware.c | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 19fc34f771..a89f4bedf1 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -255,9 +255,9 @@ static int dw_adjust_link(struct dw_eth_dev *priv, struct 
eth_mac_regs *mac_p,

  writel(conf, _p->conf);

-   printf("Speed: %d, %s duplex%s\n", phydev->speed,
-  (phydev->duplex) ? "full" : "half",
-  (phydev->port == PORT_FIBRE) ? ", fiber mode" : "");
+   debug("Speed: %d, %s duplex%s\n", phydev->speed,
+ (phydev->duplex) ? "full" : "half",
+ (phydev->port == PORT_FIBRE) ? ", fiber mode" : "");


Maybe this was intentional as I see such in the MACB driver as well.
Leaving this to Joe and original author of this driver to comment.


Thanks for reviewing.

In my syslog driver
https://lists.denx.de/pipermail/u-boot/2020-February/399551.html
I got this message everytime that I initialized the network.


Yeah, so we probably need set up a rule for network drivers?


I personally prefer drivers only to report errors.

I have proposed a patch to make log_*() functions fall back to printf()
or debug() for CONFIG_LOG_n.

[PATCH 1/1] log: output for CONFIG_LOG=n
https://lists.denx.de/pipermail/u-boot/2020-February/399593.html

So after that patch prossibly log_info() or log_debug() would be the
most adequate choice because it leaves determining the noisiness to the
user.

Best regards

Heinrich

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Daniel Schwierzeck]

On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli  wrote:
>
> Sorry Daniel,
> I seem unable to pass the message through.
>
> I have, in front of me two, very similar directories:
>
> u-boot.master:
> built from master + Weijie.v3 patches + my vocore2 patch.
>
> u-boot-mips:
> built from u-boot-mips/testing + my vocore2 patch.
>
> I was very careful not to change anything after patching.
>
> In both directories I do:
>
> make ARCH=mips CROSS_COMPILE=mipsel-linux- distclean
> make ARCH=mips CROSS_COMPILE=mipsel-linux- vocore2_defconfig
> make ARCH=mips CROSS_COMPILE=mipsel-linux-
>
> Both produce similarly-sized u-boot-mtmips.bin (Flash version)
> and u-boot.bin (RAM version).
>
> On my target I do:
>
> setenv autoload no; dhcp; tftpboot 8020 192.168.7.101:u-boot.bin; go
> ${fileaddr}
>
> In the case of the "master dir I get:
>
> => setenv autoload no; dhcp; tftpboot 8020 192.168.7.101:u-boot.bin;
> go ${fileaddr}
> BOOTP broadcast 1
> DHCP client bound to address 192.168.7.135 (115 ms)
> Using eth@1011 device
> TFTP from server 192.168.7.101; our IP address is 192.168.7.135
> Filename 'u-boot.bin'.
> Load address: 0x8020
> Loading: 
>  1.1 MiB/s
> done
> Bytes transferred = 527090 (80af2 hex)
> ## Starting application at 0x8020 ...
>
>
> U-Boot 2020.01-00648-gc46834052a-dirty (Feb 11 2020 - 09:30:52 +0100)
>
> CPU:   MediaTek MT7628A ver:1 eco:2
> Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
> Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
> Model: VoCore2
> DRAM:  128 MiB
> WDT:   Started with servicing (60s timeout)
> MMC:   mmc@1013: 0
> Loading Environment from SPI Flash... SF: Detected w25q128 with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> OK
> Model: VoCore2
> Net:
> Warning: eth@1011 (eth0) using random MAC address - 26:9f:0f:24:ae:39
> eth0: eth@1011
> Hit any key to stop autoboot:  0
> =>

ok, booting from RAM works. But what I meant with bootable is, that
you can write the
the u-boot-mtmips.bin to SPI flash and do a cold boot. Only then we
can merge your patch.

>
> If I do the same with product of "mips" dir I get:
>
> => setenv autoload no; dhcp; tftpboot 8020 192.168.7.101:u-boot.bin;
> go ${fileaddr}
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> BOOTP broadcast 4
> DHCP client bound to address 192.168.7.112 (3136 ms)
> Using eth@1011 device
> TFTP from server 192.168.7.101; our IP address is 192.168.7.112
> Filename 'u-boot.bin'.
> Load address: 0x8020
> Loading: 
>  1 MiB/s
> done
> Bytes transferred = 527390 (80c1e hex)
> ## Starting application at 0x8020 ...
> <*DEAD*>
>
> I am trying to understand where difference lies... and failing, to date :(
>
> I already sent "my vocore2 patch" (Note: that is a "git rebase -i"
> squashing the three commits in one, no change) earlier today;
> if You think it might be useful I can send also the complete
> "git format-patch" from a known u-boot master commit from
> where I branched off
> (currently 8b9cc858e0239823b051a9324431d511baf2b998)
>
> My "git log --oneline" on "master" is:
> c46834052a (HEAD -> weijie.v3.vocore.net, syno0/weijie.v3.vocore.net)
> Move back environment to SPI NOR. Changes to environment default settings.
> 7dbd7fc8bc Added network setup.
> 375435c35e (syno0/weijie.v3.vocore, weijie.v3.vocore) Add support for
> SoM "VoCore2".
> f4fa7f499e (syno0/weijie.v3, weijie.v3) mips: mtmips: add support for
> mt7628-rfb
> 724463aa9e mips: mtmips: enable SPL for all boards
> 1fe4eda6c3 mips: mtmips: add SPL support
> 5ea8181206 spl: nor: add lzma decompression support for legacy image
> 173aa9cb6c tools: binman: add etype file for u-boot-lzma-img
> 789a9085d3 Makefile: add support to generate LZMA compressed u-boot image
> e4721a8b98 lib: enable lzma decompression support for SPL build
> b769d64488 mips: add an option to enable u_boot_list section for SPL
> loaders in u-boot-spl.lds
> c704313c7e mips: enable support for appending dtb to spl binary
> 8801d2b226 dts: mtmips: add alternative pinmux node for uart2
> 4cda40c3ea mips: mtmips: rewrite lowlevel codes of mt7628
> 13299d7651 mips: add a option to support not reserving malloc space on
> initial stack
> eb8a3689b0 mips: add a mtmips-specific field to architecture-specific
> global data
> f5fda08bed configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all
> mtmips boards
> e95f8beabe mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
> 58246e0175 sysreset: add reset controller based reboot driver
> b6a20ebced mips: start.S: avoid overwriting outside gd when clearing
> global data in stack
> c2359e8947 mips: add an option to support initialize SRAM for initial stack
> a6eecdd28e mips: mtmips: add predefined i-cache/d-cache size and linesize
> b096b2e05f mips: add support to restore exception vector base before
> booting linux
> 2e5b1c00fd MIPS: allow override of get_tbclk()
> 8b9cc858e0 mx7ulp: Move SoC base address 

Re: [PATCH v3 5/5] doc: board: add rockchip subfolder

[Heinrich Schuchardt]

On 2/11/20 4:19 PM, Igor Opaniuk wrote:

From: Igor Opaniuk 

This fixes a warning when invoking make htmldocs:
checking consistency...
doc/board/rockchip/index.rst: WARNING: document isn't included in any toctree

Signed-off-by: Igor Opaniuk 


I stumbled over the same issue:
https://lists.denx.de/pipermail/u-boot/2020-February/399494.html

Reviewed-by: Heinrich Schuchardt 

Re: [PATCH v2 02/10] mmc: Add init() API

[Tom Rini]

On Tue, Feb 11, 2020 at 05:25:39PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20200211150800.d895b240...@gemini.denx.de> I wrote:
> >
> > So an easy work around for the problem is to clear the "nodupes"
> > setting in your subscription - alternatively we can try and patch
> > mailman to behave like we want it.
> 
> There is even a clean approach upstream [1]:
> 
> 
> [1] https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1825
> 
> Apparently the first RC where this commit is included is mailman
> 2.1.30rc1; we expect it will take ~ 1 month for v2.1.30 to get
> released, 2 months max.  If it's OK we will jsut wait for this
> release, then upgrade, and configure with this option set:
> 
> 1446 # The process which avoids sending a list copy of a message to a member 
> who
> 1447 # is also directly addressed in To: or Cc: can drop the address from Cc: 
> to
> 1448 # avoid growing a long Cc: list in long threads.  This can be 
> undesirable as
> 1449 # it can break DKIM signatures and possibly cause confusion.  To avoid 
> changes
> 1450 # to Cc: headers, set the list's drop_cc to No.
> 1451 DEFAULT_DROP_CC = Yes
> 
> 
> Agreed?

Agreed, thanks again!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"

[Wolfgang Denk]

Dear Rasmus Villemoes,

In message <20200205010812.20373-1-rasmus.villem...@prevas.dk> you wrote:
> Currently, there's no way to fetch the value of an environment
> variable whose name is stored in some other variable, or generated from
> such - in non-working pseudo-code,
>
>   ${${varname}}
>   ${array${index}}

HUSH does not support arrays anyway...

> This forces some scripts to needlessly duplicate logic and hardcode
> assumptions. For example, in an A/B scheme with three variables
>
> BOOT_ORDER # Either "A B" or "B A" depending on which slot was last updated
> BOOT_A_LEFT # 0..3
> BOOT_B_LEFT # 0..3
>
> when one needs to determine the slot to boot from, one does something
> like

Well, there _are_ other ways...

> This has been lightly tested in the sandbox. I'll add some proper unit
> tests, update the help texts and try to handle the Kconfig issue if
> this is something that might be accepted.

I'm pretty sure this will blow up in your face in real life, because
if side effects on existing shell scripts even if you don't
expect this.  This needs _lots_ of testing with existing code /
scripts.

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 greatest warriors are the ones who fight for peace."
- Holly Near

Re: [PATCH v2 02/10] mmc: Add init() API

[Wolfgang Denk]

Dear Tom,

In message <20200211150800.d895b240...@gemini.denx.de> I wrote:
>
> So an easy work around for the problem is to clear the "nodupes"
> setting in your subscription - alternatively we can try and patch
> mailman to behave like we want it.

There is even a clean approach upstream [1]:


[1] https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1825

Apparently the first RC where this commit is included is mailman
2.1.30rc1; we expect it will take ~ 1 month for v2.1.30 to get
released, 2 months max.  If it's OK we will jsut wait for this
release, then upgrade, and configure with this option set:

1446 # The process which avoids sending a list copy of a message to a member who
1447 # is also directly addressed in To: or Cc: can drop the address from Cc: to
1448 # avoid growing a long Cc: list in long threads.  This can be undesirable 
as
1449 # it can break DKIM signatures and possibly cause confusion.  To avoid 
changes
1450 # to Cc: headers, set the list's drop_cc to No.
1451 DEFAULT_DROP_CC = Yes


Agreed?

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
"If a computer can't directly address all the RAM you can  use,  it's
just a toy." - anonymous comp.sys.amiga posting, non-sequitir

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Mauro Condarelli]

Sorry Daniel,
I seem unable to pass the message through.

I have, in front of me two, very similar directories:

u-boot.master:
built from master + Weijie.v3 patches + my vocore2 patch.

u-boot-mips:
built from u-boot-mips/testing + my vocore2 patch.

I was very careful not to change anything after patching.

In both directories I do:

make ARCH=mips CROSS_COMPILE=mipsel-linux- distclean
make ARCH=mips CROSS_COMPILE=mipsel-linux- vocore2_defconfig
make ARCH=mips CROSS_COMPILE=mipsel-linux-

Both produce similarly-sized u-boot-mtmips.bin (Flash version)
and u-boot.bin (RAM version).

On my target I do:

setenv autoload no; dhcp; tftpboot 8020 192.168.7.101:u-boot.bin; go
${fileaddr}

In the case of the "master dir I get:

=> setenv autoload no; dhcp; tftpboot 8020 192.168.7.101:u-boot.bin;
go ${fileaddr}
BOOTP broadcast 1
DHCP client bound to address 192.168.7.135 (115 ms)
Using eth@1011 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.135
Filename 'u-boot.bin'.
Load address: 0x8020
Loading: 
     1.1 MiB/s
done
Bytes transferred = 527090 (80af2 hex)
## Starting application at 0x8020 ...


U-Boot 2020.01-00648-gc46834052a-dirty (Feb 11 2020 - 09:30:52 +0100)

CPU:   MediaTek MT7628A ver:1 eco:2
Boot:  DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: VoCore2
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
MMC:   mmc@1013: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
Model: VoCore2
Net:  
Warning: eth@1011 (eth0) using random MAC address - 26:9f:0f:24:ae:39
eth0: eth@1011
Hit any key to stop autoboot:  0
=>

If I do the same with product of "mips" dir I get:

=> setenv autoload no; dhcp; tftpboot 8020 192.168.7.101:u-boot.bin;
go ${fileaddr}
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.7.112 (3136 ms)
Using eth@1011 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.112
Filename 'u-boot.bin'.
Load address: 0x8020
Loading: 
     1 MiB/s
done
Bytes transferred = 527390 (80c1e hex)
## Starting application at 0x8020 ...
<*DEAD*>

I am trying to understand where difference lies... and failing, to date :(

I already sent "my vocore2 patch" (Note: that is a "git rebase -i"
squashing the three commits in one, no change) earlier today;
if You think it might be useful I can send also the complete
"git format-patch" from a known u-boot master commit from
where I branched off
(currently 8b9cc858e0239823b051a9324431d511baf2b998)

My "git log --oneline" on "master" is:
c46834052a (HEAD -> weijie.v3.vocore.net, syno0/weijie.v3.vocore.net)
Move back environment to SPI NOR. Changes to environment default settings.
7dbd7fc8bc Added network setup.
375435c35e (syno0/weijie.v3.vocore, weijie.v3.vocore) Add support for
SoM "VoCore2".
f4fa7f499e (syno0/weijie.v3, weijie.v3) mips: mtmips: add support for
mt7628-rfb
724463aa9e mips: mtmips: enable SPL for all boards
1fe4eda6c3 mips: mtmips: add SPL support
5ea8181206 spl: nor: add lzma decompression support for legacy image
173aa9cb6c tools: binman: add etype file for u-boot-lzma-img
789a9085d3 Makefile: add support to generate LZMA compressed u-boot image
e4721a8b98 lib: enable lzma decompression support for SPL build
b769d64488 mips: add an option to enable u_boot_list section for SPL
loaders in u-boot-spl.lds
c704313c7e mips: enable support for appending dtb to spl binary
8801d2b226 dts: mtmips: add alternative pinmux node for uart2
4cda40c3ea mips: mtmips: rewrite lowlevel codes of mt7628
13299d7651 mips: add a option to support not reserving malloc space on
initial stack
eb8a3689b0 mips: add a mtmips-specific field to architecture-specific
global data
f5fda08bed configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all
mtmips boards
e95f8beabe mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
58246e0175 sysreset: add reset controller based reboot driver
b6a20ebced mips: start.S: avoid overwriting outside gd when clearing
global data in stack
c2359e8947 mips: add an option to support initialize SRAM for initial stack
a6eecdd28e mips: mtmips: add predefined i-cache/d-cache size and linesize
b096b2e05f mips: add support to restore exception vector base before
booting linux
2e5b1c00fd MIPS: allow override of get_tbclk()
8b9cc858e0 mx7ulp: Move SoC base address to a common file
...

while in the "mips" directory I have:
cd23ee2179 (HEAD -> VoCore2) Move back environment to SPI NOR. Changes
to environment default settings.
ddc07fb968 Added network setup.
9eabc0c0bb Add support for SoM "VoCore2".
b3d1d5d05b (origin/testing, testing, master) mips: mtmips: add support
for mt7628-rfb

As said: there must be some difference, somewhere,
but it's not evident (to me) where it is and how to find it.

Thanks in Advance for any 

Re: [PATCH v3 00/21] Actions S700 SoC support

[Manivannan Sadhasivam]

Hi Amit,

On Sat, Jan 25, 2020 at 05:52:42PM +0530, Amit Singh Tomar wrote:
> Hi, 
> 
> This is continuation of work[1], submitted(v2) almost a year back.
> 
> It adds Cubieboard7[1] support based on Action Semi's S700 SoC[2], It's 
> Quad-core ARMv8 SoC
> with Cortex-A53 cores. Peripheral like UART seems to be compatible with S900 
> SoC(basic support
> for it is alreay present in u-boot).
> 
> First few patches(from 1/21 to 3/21) consolidates Actions Semiconductor SoCs 
> support in u-boot(mostly insprired
> by SUXNI as suggested by Andre). Idea is to move every bit out from 
> board/ucRobotics into arch/arm/mach-owl.
> It allows different SoCs to be driven by single "soc and Kconfig" file. It 
> also includes common clock driver
> for S700 and S900. Patches(from 4/21 to 6/21 and 10/21 to 12/21) enables S700 
> SoC support alongwith 
> Cubieboard7 board.
> 
> While at it, took the opportunity to sync S900 DT sources and 
> bindings(patches from 7/21 to 8/21) with 
> Linux(tag v5.5-rc6) and it is compiled-tested.
> 
> Patch(9/21) uses same name for ethernet clock binding and if it's ok, would 
> like to send it to LKML
> as well.
> 
> Patches(from 13/21 to 14/21) adds support for RTL 8201F PHY module and 
> introduce configuration option
> "RTL8201F_PHY_S700_RMII_TIMINGS" to fulfill specific timing requirements for 
> S700.
> 
> Patches(from 15/21 to 17/21) adds support for generic reset controller, 
> originally used for NEXELL[3]
> series but never gets merged and it can be used for S700.
> 
> Patches(from 18/21 to 21/21) are there to enable Ethenet support in S700, MAC 
> is based on Designware IP
> These patches re-uses the existing driver(drivers/net/designware.c) and 
> programs SoC specific bits to
> enable ethernet. SoC specific glue code is kept in dwmac_s700.c file, did it 
> this way as found it more
> cleaner(but having said that I am not really sure, if it's bit of a overkill 
> to have it) or we can keep
> this glue code somewhere in machine file?
> 
> S700 support is tested[4] on Cubieboard7 board and S900 support is just 
> compiled tested.
> 

Sorry for the late reply. Got swamped with lot of stuffs :(

Thanks a lot for the series! I will review it soon and test it on my S900
based Bubblegum 96 board. 

Thanks,
Mani

> Also, patches are rebased upon following commit:
> 2c871f9e084b2c03d1961884228a6901387ab8d6 Merge branch 
> '2020-01-22-master-imports'
> 
> Thanks
> -Amit
> 
> [1]: https://patchwork.ozlabs.org/cover/1020286/
> [2]: http://www.actions-semi.com/en/productview.aspx?id=225
> [3]: https://lists.denx.de/pipermail/u-boot/2017-November/313135.html
> [4]: https://paste.ubuntu.com/p/GkFPn2xJfn/
> 
> Amit Singh Tomar (21):
>   arm: actions: Add common framework for Actions Semi SoCs
>   arm: actions: rename sysmap-s900 to sysmap-owl
>   clk: actions: Add common clock driver
>   arm: add support Actions Semi S700
>   arm: actions: add S700 SoC device tree
>   actions:s700: add u-boot specific dts file
>   arm: dts: sync dts for Action Semi S900
>   actions: s900: add u-boot specific dts file
>   arm: dts: Use consistent name "CLK_ETHERNET" for the Ethernet clock
> binding
>   serial: actions: add uart support for s700
>   arm: add Cubieboard7 board support
>   actions: add Cubieboard7 README
>   net: phy: realtek: Add support for RTL8201F PHY module.
>   net: phy: realtek: Introduce PHY_RTL8201F_S700_RMII_TIMINGS to adjust
> rx/tx timings
>   reset: add driver for generic reset controllers
>   arm: dts: s700: add node for reset controller
>   owl: Kconfig: Enable dm reset and generic reset
>   net: designware: s700: Add glue code for S700 mac
>   arm: dts: s700: add node for ethernet controller
>   owl: Kconfig: Enable dm eth for OWL platform
>   configs: Enable mac and phy configs
> 
>  MAINTAINERS|   2 +
>  arch/arm/Kconfig   |   8 +-
>  arch/arm/dts/Makefile  |   6 +-
>  arch/arm/dts/s700-cubieboard7.dts  |  39 +++
>  arch/arm/dts/s700-u-boot.dtsi  |  39 +++
>  arch/arm/dts/s700.dtsi | 248 +++
>  arch/arm/dts/s900-u-boot.dtsi  |  17 ++
>  arch/arm/dts/s900.dtsi | 322 
> +++--
>  arch/arm/include/asm/arch-owl/clk_s900.h   |  57 -
>  arch/arm/include/asm/arch-owl/regs_s700.h  |  62 +
>  arch/arm/mach-owl/Kconfig  |  35 +--
>  arch/arm/mach-owl/Makefile |   3 +-
>  arch/arm/mach-owl/README.cubieboard7   |  88 +++
>  arch/arm/mach-owl/soc.c|  57 +
>  arch/arm/mach-owl/sysmap-owl.c |  32 +++
>  arch/arm/mach-owl/sysmap-s900.c|  32 ---
>  board/ucRobotics/bubblegum_96/Kconfig  |  15 --
>  board/ucRobotics/bubblegum_96/MAINTAINERS  |   6 -
>  board/ucRobotics/bubblegum_96/Makefile |   3 -
>  

Re: [PATCH v3 12/21] actions: add Cubieboard7 README

[Tom Rini]

On Sat, Jan 25, 2020 at 05:52:54PM +0530, Amit Singh Tomar wrote:

> Signed-off-by: Amit Singh Tomar 
> ---
> Changes since v2:
>   * No Change.
> Changes since v1:
> * No Change.
> ---
>  arch/arm/mach-owl/README.cubieboard7 | 88 
> 
>  1 file changed, 88 insertions(+)
>  create mode 100644 arch/arm/mach-owl/README.cubieboard7

This should be a rst file and reside in doc/board/ (and update the index
file).  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] RFC: nvedit: support doing one (extra) expansion of the value in "env set"

[Rasmus Villemoes]

On 05/02/2020 18.59, Simon Glass wrote:
> Hi Rasmus,
> 

>> This has been lightly tested in the sandbox. I'll add some proper unit
>> tests, update the help texts and try to handle the Kconfig issue if
>> this is something that might be accepted.
>>
>> Signed-off-by: Rasmus Villemoes 
>> ---
>>  cmd/nvedit.c | 17 -
>>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> Seems OK to me. 

Thanks. I'll go ahead and write some tests.

> I suppose we don't want to implement bash's nested
> expansion? ${var${suffix}}

It's not that easy to implement inside-out expansion, one needs to
juggle a lot of temporary buffers. So I went with the rather simple
one-extra-pass, which can mostly achieve the same things (although
perhaps the script needs to do a few extra steps).

Out of curiosity, what bash version supports the above?

$ echo $BASH_VERSION
4.4.20(1)-release
$ foo_a=3
$ foo_b=7
$ x=a
$ echo ${foo_${x}}
bash: ${foo_${x}}: bad substitution

however, this variant is supported:

$ var=foo_$x
$ echo ${var}
foo_a
$ echo ${!var}
3



> Regards,
> Simon
> 


-- 
Rasmus Villemoes
Software Developer
Prevas A/S
Hedeager 3
DK-8200 Aarhus N
+45 51210274
rasmus.villem...@prevas.dk
www.prevas.dk

Re: [PATCH 2/9] dma-mapping: fix the prototype of dma_unmap_single()

[Masahiro Yamada]

On Wed, Feb 5, 2020 at 9:17 AM Simon Glass  wrote:
>
> On Tue, 4 Feb 2020 at 04:09, Masahiro Yamada
>  wrote:
> >
> > dma_unmap_single() takes the dma address, not virtual address.
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  arch/arm/include/asm/dma-mapping.h   | 4 +---
> >  arch/nds32/include/asm/dma-mapping.h | 4 +---
> >  arch/riscv/include/asm/dma-mapping.h | 4 +---
> >  arch/x86/include/asm/dma-mapping.h   | 4 +---
> >  drivers/mmc/tmio-common.c| 2 +-
> >  drivers/mtd/nand/raw/denali.c| 2 +-
> >  drivers/net/macb.c   | 2 +-
> >  drivers/usb/dwc3/core.c  | 6 +++---
> >  drivers/usb/gadget/udc/udc-core.c| 2 +-
> >  9 files changed, 11 insertions(+), 19 deletions(-)
>
> Reviewed-by: Simon Glass 
>
> But please also add a comment to the header files.

Same here.

See my reply to 1/9.



--
Best Regards

Masahiro Yamada

[PATCH resend 3/5] mpc8xxx_spi: put max_cs to use

[Rasmus Villemoes]

Currently, max_cs is write-only; it's just set in
mpc8xxx_spi_ofdata_to_platdata and not otherwise used.

My mpc8309 was always resetting during an "sf probe 0". It turns out
dm_gpio_set_dir_flags() was being called with garbage, since nothing
had initialized priv->gpios[0] - our device tree used "cs-gpios"
rather than "gpios", so gpio_request_list_by_name() had returned 0.

That would have been a lot easier to figure out if the chip select
index was sanity checked, so rename max_cs to cs_count, and reject a
xfer with a too large cs index.

Signed-off-by: Rasmus Villemoes 
---
 drivers/spi/mpc8xxx_spi.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 1c7bf10f91..ac4d0a9bae 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -35,7 +35,7 @@ enum {
 struct mpc8xxx_priv {
spi8xxx_t *spi;
struct gpio_desc gpios[16];
-   int max_cs;
+   int cs_count;
 };
 
 static inline u32 to_prescale_mod(u32 val)
@@ -74,7 +74,7 @@ static int mpc8xxx_spi_ofdata_to_platdata(struct udevice *dev)
if (ret < 0)
return -EINVAL;
 
-   priv->max_cs = ret;
+   priv->cs_count = ret;
 
return 0;
 }
@@ -131,6 +131,11 @@ static int mpc8xxx_spi_xfer(struct udevice *dev, uint 
bitlen,
 
debug("%s: slave %s:%u dout %08X din %08X bitlen %u\n", __func__,
  bus->name, platdata->cs, *(uint *)dout, *(uint *)din, bitlen);
+   if (platdata->cs >= priv->cs_count) {
+   dev_err(dev, "chip select index %d too large (cs_count=%d)\n",
+   platdata->cs, priv->cs_count);
+   return -EINVAL;
+   }
 
if (flags & SPI_XFER_BEGIN)
mpc8xxx_spi_cs_activate(dev);
-- 
2.23.0

[PATCH resend 4/5] mpc8xxx_spi: always use 8-bit characters, don't read or write garbage

[Rasmus Villemoes]

There are a few problems with the current driver.

First, it unconditionally reads from dout/writes to din whether or not
those pointers are NULL. So for example a simple "sf probe" ends up
writing four bytes at address 0:

=> md.l 0x0 8
: 45454545 45454545 05050505 05050505
0010:   07070707 07070707
=> sf probe 0
mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB53618 din  bitlen 8
mpc8xxx_spi_xfer: slave spi@7000:0 dout  din 0FB536B8 bitlen 48
SF: Detected s25sl032p with page size 256 Bytes, erase size 64 KiB, total 4 MiB
=> md.l 0x0 8
: ff00 45454545 05050505 05050505
0010:   07070707 07070707

(here I've change the first debug statement to a printf, and made it
print the din/dout pointers rather than the uints they point at).

Second, as we can also see above, it always writes a full 32 bits,
even if a smaller amount was requested. So for example

=> mw.l $loadaddr 0xaabbccdd 8
=> md.l $loadaddr 8
0200: aabbccdd aabbccdd aabbccdd aabbccdd
0210: aabbccdd aabbccdd aabbccdd aabbccdd
=> sf read $loadaddr 0x400 6
device 0 offset 0x400, size 0x6
mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB536E8 din  bitlen 40
mpc8xxx_spi_xfer: slave spi@7000:0 dout  din 0200 bitlen 48
SF: 6 bytes @ 0x400 Read: OK
=> sf read 0x0210 0x400 8
device 0 offset 0x400, size 0x8
mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB53848 din  bitlen 40
mpc8xxx_spi_xfer: slave spi@7000:0 dout  din 0210 bitlen 64
SF: 8 bytes @ 0x400 Read: OK
=> md.l $loadaddr 8
0200: 45454545 4545 aabbccdd aabbccddEE..
0210: 45454545 45454545 aabbccdd aabbccdd

Finally, when the bitlen is 24 mod 32 (e.g. requesting to read 3 or 7
bytes), the last three bytes and up being the wrong ones, since the
driver does a full 32 bit read and then shifts the wrong byte out:

=> mw.l $loadaddr 0xaabbccdd 4
=> md.l $loadaddr 4
0200: aabbccdd aabbccdd aabbccdd aabbccdd
=> sf read $loadaddr 0x444 10
device 0 offset 0x444, size 0x10
mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB536E8 din  bitlen 40
mpc8xxx_spi_xfer: slave spi@7000:0 dout  din 0200 bitlen 128
SF: 16 bytes @ 0x444 Read: OK
=> md.l $loadaddr 4
0200: 552d426f 6f742032 3031392e 30342d30U-Boot 2019.04-0
=> mw.l $loadaddr 0xaabbccdd 4
=> sf read $loadaddr 0x444 0xb
device 0 offset 0x444, size 0xb
mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB536E8 din  bitlen 40
mpc8xxx_spi_xfer: slave spi@7000:0 dout  din 0200 bitlen 88
SF: 11 bytes @ 0x444 Read: OK
=> md.l $loadaddr 4
0200: 552d426f 6f742032 31392e00 aabbccddU-Boot 219..

Fix all of that by always using a character size of 8, and reject
transfers that are not a whole number of bytes. While it ends being
more work for the CPU, we're mostly bounded by the speed of the SPI
bus, and we avoid writing to the mode register in every loop.

Based on work by Klaus H. Sørensen.

Cc: Klaus H. Sorensen 
Signed-off-by: Rasmus Villemoes 
---
 drivers/spi/mpc8xxx_spi.c | 80 +--
 1 file changed, 27 insertions(+), 53 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index ac4d0a9bae..8ef2451411 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -27,6 +27,7 @@ enum {
SPI_MODE_EN= BIT(31 - 7),   /* Enable interface */
 
SPI_MODE_LEN_MASK = 0xf0,
+   SPI_MODE_LEN_SHIFT = 20,
SPI_MODE_PM_MASK = 0xf,
 
SPI_COM_LST = BIT(31 - 9),
@@ -43,23 +44,8 @@ static inline u32 to_prescale_mod(u32 val)
return (min(val, (u32)15) << 16);
 }
 
-static void set_char_len(spi8xxx_t *spi, u32 val)
-{
-   clrsetbits_be32(>mode, SPI_MODE_LEN_MASK, (val << 20));
-}
-
 #define SPI_TIMEOUT1000
 
-static int __spi_set_speed(spi8xxx_t *spi, uint speed)
-{
-   /* TODO(mario@gdsys.cc): This only ever sets one fixed speed */
-
-   /* Use SYSCLK / 8 (16.67MHz typ.) */
-   clrsetbits_be32(>mode, SPI_MODE_PM_MASK, to_prescale_mod(1));
-
-   return 0;
-}
-
 static int mpc8xxx_spi_ofdata_to_platdata(struct udevice *dev)
 {
struct mpc8xxx_priv *priv = dev_get_priv(dev);
@@ -82,14 +68,22 @@ static int mpc8xxx_spi_ofdata_to_platdata(struct udevice 
*dev)
 static int mpc8xxx_spi_probe(struct udevice *dev)
 {
struct mpc8xxx_priv *priv = dev_get_priv(dev);
+   spi8xxx_t *spi = priv->spi;
 
/*
 * SPI pins on the MPC83xx are not muxed, so all we do is initialize
 * some registers
 */
-   out_be32(>spi->mode, SPI_MODE_REV | SPI_MODE_MS | SPI_MODE_EN);
+   out_be32(>spi->mode, SPI_MODE_REV | SPI_MODE_MS);
+
+   /* set len to 8 bits */
+   setbits_be32(>mode, (8 - 1) << SPI_MODE_LEN_SHIFT);
 
-   __spi_set_speed(priv->spi, 1667);

[PATCH resend 2/5] gazerbeam: add clocks property to SPI node

[Rasmus Villemoes]

Prepare for supporting setting different speeds in mpc8xxx_spi.c.

Signed-off-by: Rasmus Villemoes 
---
 arch/powerpc/dts/gdsys/mpc8308.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/dts/gdsys/mpc8308.dtsi 
b/arch/powerpc/dts/gdsys/mpc8308.dtsi
index 23e7403d91..1a319e2328 100644
--- a/arch/powerpc/dts/gdsys/mpc8308.dtsi
+++ b/arch/powerpc/dts/gdsys/mpc8308.dtsi
@@ -17,6 +17,7 @@
 /dts-v1/;
 
 #include 
+#include 
 
 / {
compatible = "fsl,mpc8308rdb";
@@ -50,6 +51,11 @@
};
};
 
+   socclocks: clocks {
+   compatible = "fsl,mpc8308-clk";
+   #clock-cells = <1>;
+   };
+
board_lbc: localbus@e0005000 {
#address-cells = <2>;
#size-cells = <1>;
@@ -173,6 +179,7 @@
reg = <0x7000 0x1000>;
interrupts = <16 0x8>;
interrupt-parent = <>;
+   clocks = < MPC83XX_CLK_CSB>;
mode = "cpu";
};
 
-- 
2.23.0

[PATCH resend 1/5] gpio/mpc83xx_spisel_boot.c: gpio driver for SPISEL_BOOT signal

[Rasmus Villemoes]

From: "Klaus H. Sorensen" 

Some SoCs in the mpc83xx family, e.g. mpc8309, have a dedicated spi
chip select, SPISEL_BOOT, that is used by the boot code to boot from
flash.

This chip select will typically be used to select a SPI boot
flash. The SPISEL_BOOT signal is controlled by a single bit in the
SPI_CS register.

Implement a gpio driver for the spi chip select register. This allows a
spi driver capable of using gpios as chip select, to bind a chip select
to SPISEL_BOOT.

It may be a little odd to do this as a GPIO driver, since the signal
is neither GP or I, but it is quite convenient to present it to the
spi driver that way. The alternative it to teach mpc8xxx_spi to handle
the SPISEL_BOOT signal itself (that is how it's done in the linux
kernel, see commit 69b921acae8a)

Signed-off-by: Klaus H. Sorensen 
Signed-off-by: Rasmus Villemoes 
---
 .../gpio/fsl,mpc83xx-spisel-boot.txt  |  22 +++
 drivers/gpio/Kconfig  |   8 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/mpc83xx_spisel_boot.c| 148 ++
 4 files changed, 179 insertions(+)
 create mode 100644 doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt
 create mode 100644 drivers/gpio/mpc83xx_spisel_boot.c

diff --git a/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt 
b/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt
new file mode 100644
index 00..52d8bb0a5c
--- /dev/null
+++ b/doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt
@@ -0,0 +1,22 @@
+MPC83xx SPISEL_BOOT gpio controller
+
+Provide access to MPC83xx SPISEL_BOOT signal as a gpio to allow it to be
+easily bound as a SPI controller chip select.
+
+The SPISEL_BOOT signal is always an output.
+
+Required properties:
+
+- compatible: must be "fsl,mpc83xx-spisel-boot" or "fsl,mpc8309-spisel-boot".
+- reg: must point to the SPI_CS register in the SoC register map.
+- ngpios: number of gpios provided by driver, normally 1.
+
+Example:
+
+   spisel_boot: spisel_boot@14c {
+   compatible = "fsl,mpc8309-spisel-boot";
+   reg = <0x14c 0x04>;
+   #gpio-cells = <2>;
+   device_type = "gpio";
+   ngpios = <1>;
+   };
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c1ad5d64a3..73fdb8cb3b 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -383,6 +383,14 @@ config MPC8XXX_GPIO
  value setting, the open-drain feature, which can configure individual
  GPIOs to work as open-drain outputs, is supported.
 
+config MPC83XX_SPISEL_BOOT
+   bool "Freescale MPC83XX SPISEL_BOOT driver"
+   depends on DM_GPIO && ARCH_MPC830X
+   help
+ GPIO driver to set/clear dedicated SPISEL_BOOT output on MPC83XX.
+
+ This pin is typically used as spi chip select to a spi nor flash.
+
 config MT7621_GPIO
bool "MediaTek MT7621 GPIO driver"
depends on DM_GPIO && SOC_MT7628
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index ccc49e2eb0..bbeec30431 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_DM644X_GPIO) += da8xx_gpio.o
 obj-$(CONFIG_ALTERA_PIO)   += altera_pio.o
 obj-$(CONFIG_MPC83XX_GPIO) += mpc83xx_gpio.o
 obj-$(CONFIG_MPC8XXX_GPIO) += mpc8xxx_gpio.o
+obj-$(CONFIG_MPC83XX_SPISEL_BOOT)  += mpc83xx_spisel_boot.o
 obj-$(CONFIG_SH_GPIO_PFC)  += sh_pfc.o
 obj-$(CONFIG_OMAP_GPIO)+= omap_gpio.o
 obj-$(CONFIG_DB8500_GPIO)  += db8500_gpio.o
diff --git a/drivers/gpio/mpc83xx_spisel_boot.c 
b/drivers/gpio/mpc83xx_spisel_boot.c
new file mode 100644
index 00..c7b08404d9
--- /dev/null
+++ b/drivers/gpio/mpc83xx_spisel_boot.c
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019 DEIF A/S
+ *
+ * GPIO driver to set/clear SPISEL_BOOT pin on mpc83xx.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct mpc83xx_spisel_boot {
+   u32 __iomem *spi_cs;
+   ulong addr;
+   uint gpio_count;
+   ulong type;
+};
+
+static u32 gpio_mask(uint gpio)
+{
+   return (1U << (31 - (gpio)));
+}
+
+static int mpc83xx_spisel_boot_direction_input(struct udevice *dev, uint gpio)
+{
+   return -EINVAL;
+}
+
+static int mpc83xx_spisel_boot_set_value(struct udevice *dev, uint gpio, int 
value)
+{
+   struct mpc83xx_spisel_boot *data = dev_get_priv(dev);
+
+   debug("%s: gpio=%d, value=%u, gpio_mask=0x%08x\n", __func__,
+ gpio, value, gpio_mask(gpio));
+
+   if (value)
+   setbits_be32(data->spi_cs, gpio_mask(gpio));
+   else
+   clrbits_be32(data->spi_cs, gpio_mask(gpio));
+
+   return 0;
+}
+
+static int mpc83xx_spisel_boot_direction_output(struct udevice *dev, uint 
gpio, int value)
+{
+   return 0;
+}
+
+static int mpc83xx_spisel_boot_get_value(struct udevice *dev, uint gpio)
+{
+   struct mpc83xx_spisel_boot *data = dev_get_priv(dev);
+
+   return 

[PATCH resend 5/5] mpc8xxx_spi: implement real ->set_speed

[Rasmus Villemoes]

Not all boards have the same CSB frequency, nor do every SPI slave
necessarily support running at 16.7 MHz. So implement ->set_speed;
that also allows using a smaller PM (i.e., 0) for slaves that do
support a higher speed.

Based on work by Klaus H. Sørensen.

Cc: Klaus H. Sorensen 
Signed-off-by: Rasmus Villemoes 
---
 drivers/spi/mpc8xxx_spi.c | 64 ---
 1 file changed, 53 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 8ef2451411..1bde31ad34 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +29,7 @@ enum {
 
SPI_MODE_LEN_MASK = 0xf0,
SPI_MODE_LEN_SHIFT = 20,
+   SPI_MODE_PM_SHIFT = 16,
SPI_MODE_PM_MASK = 0xf,
 
SPI_COM_LST = BIT(31 - 9),
@@ -37,24 +39,19 @@ struct mpc8xxx_priv {
spi8xxx_t *spi;
struct gpio_desc gpios[16];
int cs_count;
+   ulong clk_rate;
 };
 
-static inline u32 to_prescale_mod(u32 val)
-{
-   return (min(val, (u32)15) << 16);
-}
-
 #define SPI_TIMEOUT1000
 
 static int mpc8xxx_spi_ofdata_to_platdata(struct udevice *dev)
 {
struct mpc8xxx_priv *priv = dev_get_priv(dev);
+   struct clk clk;
int ret;
 
priv->spi = (spi8xxx_t *)dev_read_addr(dev);
 
-   /* TODO(mario@gdsys.cc): Read clock and save the value */
-
ret = gpio_request_list_by_name(dev, "gpios", priv->gpios,
ARRAY_SIZE(priv->gpios), GPIOD_IS_OUT | 
GPIOD_ACTIVE_LOW);
if (ret < 0)
@@ -62,6 +59,18 @@ static int mpc8xxx_spi_ofdata_to_platdata(struct udevice 
*dev)
 
priv->cs_count = ret;
 
+   ret = clk_get_by_index(dev, 0, );
+   if (ret) {
+   dev_err(dev, "%s: clock not defined\n", __func__);
+   return ret;
+   }
+
+   priv->clk_rate = clk_get_rate();
+   if (!priv->clk_rate) {
+   dev_err(dev, "%s: failed to get clock rate\n", __func__);
+   return -EINVAL;
+   }
+
return 0;
 }
 
@@ -79,10 +88,6 @@ static int mpc8xxx_spi_probe(struct udevice *dev)
/* set len to 8 bits */
setbits_be32(>mode, (8 - 1) << SPI_MODE_LEN_SHIFT);
 
-   /* TODO(mario@gdsys.cc): This only ever sets one fixed speed */
-   /* Use SYSCLK / 8 (16.67MHz typ.) */
-   clrsetbits_be32(>mode, SPI_MODE_PM_MASK, to_prescale_mod(1));
-
setbits_be32(>mode, SPI_MODE_EN);
 
/* Clear all SPI events */
@@ -204,6 +209,43 @@ static int mpc8xxx_spi_xfer(struct udevice *dev, uint 
bitlen,
 
 static int mpc8xxx_spi_set_speed(struct udevice *dev, uint speed)
 {
+   struct mpc8xxx_priv *priv = dev_get_priv(dev);
+   spi8xxx_t *spi = priv->spi;
+   u32 bits, mask, div16, pm;
+   u32 mode;
+   ulong clk;
+
+   clk = priv->clk_rate;
+   if (clk / 64 > speed) {
+   div16 = SPI_MODE_DIV16;
+   clk /= 16;
+   } else {
+   div16 = 0;
+   }
+   pm = (clk - 1)/(4*speed) + 1;
+   if (pm > 16) {
+   dev_err(dev, "requested speed %u too small\n", speed);
+   return -EINVAL;
+   }
+   pm--;
+
+   bits = div16 | (pm << SPI_MODE_PM_SHIFT);
+   mask = SPI_MODE_DIV16 | SPI_MODE_PM_MASK;
+   mode = in_be32(>mode);
+   if ((mode & mask) != bits) {
+   /* Must clear mode[EN] while changing speed. */
+   mode &= ~(mask | SPI_MODE_EN);
+   out_be32(>mode, mode);
+   mode |= bits;
+   out_be32(>mode, mode);
+   mode |= SPI_MODE_EN;
+   out_be32(>mode, mode);
+   }
+
+   debug("requested speed %u, set speed to %lu/(%s4*%u) == %lu\n",
+ speed, priv->clk_rate, div16 ? "16*" : "", pm + 1,
+ clk/(4*(pm + 1)));
+
return 0;
 }
 
-- 
2.23.0

[PATCH resend 0/5] spi: mpc8xxx_spi: bug fixes, real ->set_speed and a pseudo-gpio driver

[Rasmus Villemoes]

This is a combination of a single patch and a 4-part series sent
previously [1,2], this time with Jagan on Cc.

Patch 1 is a convenient pseudo-gpio driver for controlling a single
output signal on mpc830x. Since it's (usually) used as a chip select,
representing it as a gpio (without the gp or i) makes it simple to use
in device tree.

The remaining four fix bugs in the mpc8xxx_spi driver, most
importantly patch 4. Without it, reads and writes of certain lengths
from spi-nor fails, and stuff at physical address 0x0 gets overwritten
even if no input buffer is supplied (e.g. when sending a command).

Tested on an mpc8309-derived board. It would be nice if someone with
access to the gazerbeam board can test that this doesn't break that -
in particular, the "only do transfers that are multiple of 8 bits"
part.

[1] https://patchwork.ozlabs.org/patch/1219513/
[2] https://patchwork.ozlabs.org/cover/1218170/

Klaus H. Sorensen (1):
  gpio/mpc83xx_spisel_boot.c: gpio driver for SPISEL_BOOT signal

Rasmus Villemoes (4):
  gazerbeam: add clocks property to SPI node
  mpc8xxx_spi: put max_cs to use
  mpc8xxx_spi: always use 8-bit characters, don't read or write garbage
  mpc8xxx_spi: implement real ->set_speed

 arch/powerpc/dts/gdsys/mpc8308.dtsi   |   7 +
 .../gpio/fsl,mpc83xx-spisel-boot.txt  |  22 +++
 drivers/gpio/Kconfig  |   8 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/mpc83xx_spisel_boot.c| 148 ++
 drivers/spi/mpc8xxx_spi.c | 141 ++---
 6 files changed, 267 insertions(+), 60 deletions(-)
 create mode 100644 doc/device-tree-bindings/gpio/fsl,mpc83xx-spisel-boot.txt
 create mode 100644 drivers/gpio/mpc83xx_spisel_boot.c

-- 
2.23.0

[PATCH v3 2/5] doc: board: verdin-imx8mm: convert readme to reST

[Igor Opaniuk]

From: Igor Opaniuk 

Convert README to reStructuredText format.

Signed-off-by: Igor Opaniuk 
---

 board/toradex/verdin-imx8mm/README  |  88 --
 doc/board/toradex/index.rst |   1 +
 doc/board/toradex/verdin-imx8mm.rst | 112 
 3 files changed, 113 insertions(+), 88 deletions(-)
 delete mode 100644 board/toradex/verdin-imx8mm/README
 create mode 100644 doc/board/toradex/verdin-imx8mm.rst

diff --git a/board/toradex/verdin-imx8mm/README 
b/board/toradex/verdin-imx8mm/README
deleted file mode 100644
index 1dac969476..00
--- a/board/toradex/verdin-imx8mm/README
+++ /dev/null
@@ -1,88 +0,0 @@
-U-Boot for the Toradex Verdin iMX8M Mini Module
-
-Quick Start
-===
-
-- Build the ARM trusted firmware binary
-- Get the DDR firmware
-- Build U-Boot
-- Flash to eMMC
-- Boot
-
-Get and Build the ARM Trusted Firmware (Trusted Firmware A)
-===
-
-$ echo "Downloading and building TF-A..."
-$ git clone -b imx_4.14.98_2.3.0 
https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf
-
-Please edit `plat/imx/imx8mm/include/platform_def.h` so it contains proper
-values for UART configuration and BL31 base address (correct values listed
-below):
-#define BL31_BASE  0x91
-#define IMX_BOOT_UART_BASE 0x3086
-#define DEBUG_CONSOLE  1
-
-Then build ATF (TF-A):
-$ make PLAT=imx8mm bl31
-
-Get the DDR Firmware
-
-
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.4.1.bin
-$ chmod +x firmware-imx-8.4.1.bin
-$ ./firmware-imx-8.4.1.bin
-$ cp firmware-imx-8.4.1/firmware/ddr/synopsys/lpddr4*.bin ./
-
-Build U-Boot
-
-
-$ export CROSS_COMPILE=aarch64-linux-gnu-
-$ make verdin-imx8mm_defconfig
-$ make flash.bin
-
-Flash to eMMC
-=
-
-> tftpboot ${loadaddr} flash.bin
-> setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
-> mmc dev 0 1 && mmc write ${loadaddr} 0x2 ${blkcnt}
-
-As a convenience, instead of the last two commands one may also use the update
-U-Boot wrapper:
-> run update_uboot
-
-Boot
-
-
-ATF, U-boot proper and u-boot.dtb images are packed into FIT image,
-which is loaded and parsed by SPL.
-
-Boot sequence is:
-SPL ---> ATF (TF-A) ---> U-boot proper
-
-Output:
-U-Boot SPL 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
-Normal Boot
-Trying to boot from MMC1
-NOTICE:  Configuring TZASC380
-NOTICE:  RDC off
-NOTICE:  BL31: v2.0(release):rel_imx_4.14.98_2.3.0-0-g09c5cc994-dirty
-NOTICE:  BL31: Built : 01:11:41, Jan 25 2020
-NOTICE:  sip svc init
-
-
-U-Boot 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
-
-CPU:   Freescale i.MX8MMQ rev1.0 at 0 MHz
-Reset cause: POR
-DRAM:  2 GiB
-MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
-Loading Environment from MMC... OK
-In:serial
-Out:   serial
-Err:   serial
-Model: Toradex Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT V1.0A, Serial# 06535149
-Net:   eth0: ethernet@30be
-Hit any key to stop autoboot:  0
-Verdin iMX8MM #
diff --git a/doc/board/toradex/index.rst b/doc/board/toradex/index.rst
index aa418d6bad..6cd2ade9f4 100644
--- a/doc/board/toradex/index.rst
+++ b/doc/board/toradex/index.rst
@@ -7,3 +7,4 @@ Toradex
:maxdepth: 2
 
colibri_imx7
+   verdin-imx8mm
diff --git a/doc/board/toradex/verdin-imx8mm.rst 
b/doc/board/toradex/verdin-imx8mm.rst
new file mode 100644
index 00..5363251dee
--- /dev/null
+++ b/doc/board/toradex/verdin-imx8mm.rst
@@ -0,0 +1,112 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Verdin iMX8M Mini Module
+===
+
+Quick Start
+---
+
+- Build the ARM trusted firmware binary
+- Get the DDR firmware
+- Build U-Boot
+- Flash to eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware (Trusted Firmware A)
+---
+
+.. code-block:: bash
+
+$ echo "Downloading and building TF-A..."
+$ git clone -b imx_4.14.98_2.3.0 \
+  https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf
+
+Please edit ``plat/imx/imx8mm/include/platform_def.h`` so it contains proper
+values for UART configuration and BL31 base address (correct values listed
+below):
+
+.. code-block:: bash
+
+#define BL31_BASE   0x91
+#define IMX_BOOT_UART_BASE  0x3086
+#define DEBUG_CONSOLE   1
+
+Then build ATF (TF-A):
+
+.. code-block:: bash
+
+$ make PLAT=imx8mm bl31
+
+Get the DDR Firmware
+
+
+.. code-block:: bash
+
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.4.1.bin
+$ chmod +x firmware-imx-8.4.1.bin
+$ ./firmware-imx-8.4.1.bin
+$ cp firmware-imx-8.4.1/firmware/ddr/synopsys/lpddr4*.bin ./
+
+Build U-Boot
+
+.. code-block:: bash
+
+$ export CROSS_COMPILE=aarch64-linux-gnu-
+$ make verdin-imx8mm_defconfig
+$ make flash.bin
+
+Flash to eMMC
+-
+
+.. 

[PATCH v3 4/5] doc: board: colibri-imx8x: convert readme to reST

[Igor Opaniuk]

From: Igor Opaniuk 

Convert README to reStructuredText format.

Signed-off-by: Igor Opaniuk 
---

 board/toradex/colibri-imx8x/README  | 66 ---
 doc/board/toradex/colibri-imx8x.rst | 82 +
 doc/board/toradex/index.rst |  1 +
 3 files changed, 83 insertions(+), 66 deletions(-)
 delete mode 100644 board/toradex/colibri-imx8x/README
 create mode 100644 doc/board/toradex/colibri-imx8x.rst

diff --git a/board/toradex/colibri-imx8x/README 
b/board/toradex/colibri-imx8x/README
deleted file mode 100644
index 708bb3e51c..00
--- a/board/toradex/colibri-imx8x/README
+++ /dev/null
@@ -1,66 +0,0 @@
-U-Boot for the Toradex Colibri iMX8QXP V1.0B Module
-
-Quick Start
-===
-
-- Build the ARM trusted firmware binary
-- Get scfw_tcm.bin and ahab-container.img
-- Build U-Boot
-- Load U-Boot binary using uuu
-- Flash U-Boot binary into the eMMC
-- Boot
-
-Get and Build the ARM Trusted Firmware
-==
-
-$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf/
-$ make PLAT=imx8qxp bl31
-
-Get scfw_tcm.bin and ahab-container.img
-===
-
-$ wget 
https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-bsp/imx-sc-firmware/files/mx8qx-colibri-scfw-tcm.bin?raw=true
-$ mv mx8qx-colibri-scfw-tcm.bin\?raw\=true mx8qx-colibri-scfw-tcm.bin
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
-$ chmod +x firmware-imx-8.0.bin
-$ ./firmware-imx-8.0.bin
-
-Copy the following binaries to the U-Boot folder:
-
-$ cp imx-atf/build/imx8qxp/release/bl31.bin .
-$ cp u-boot/u-boot.bin .
-
-Copy the following firmware to the U-Boot folder:
-
-$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
-
-Build U-Boot
-
-
-$ make colibri-imx8qxp_defconfig
-$ make u-boot-dtb.imx
-
-Load the U-Boot Binary Using UUU
-
-
-Get the latest version of the universal update utility (uuu) aka mfgtools 3.0:
-
-https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
-
-Put the module into USB recovery aka serial downloader mode, connect USB device
-to your host and execute uuu:
-
-sudo ./uuu u-boot/u-boot-dtb.imx
-
-Flash the U-Boot Binary into the eMMC
-=
-
-Burn the u-boot-dtb.imx binary to the primary eMMC hardware boot area 
partition:
-
-load mmc 1:1 $loadaddr u-boot-dtb.imx
-setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
-mmc dev 0 1
-mmc write ${loadaddr} 0x0 ${blkcnt}
-
-Boot
diff --git a/doc/board/toradex/colibri-imx8x.rst 
b/doc/board/toradex/colibri-imx8x.rst
new file mode 100644
index 00..ce9195af73
--- /dev/null
+++ b/doc/board/toradex/colibri-imx8x.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Colibri iMX8QXP V1.0B Module
+===
+
+Quick Start
+---
+
+- Build the ARM trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Load U-Boot binary using uuu
+- Flash U-Boot binary into the eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware
+--
+
+.. code-block:: bash
+
+$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf/
+$ make PLAT=imx8qxp bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---
+.. code-block:: bash
+
+$ wget https://github.com/toradex/meta-fsl-bsp-release/blob/
+   toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-
+   bsp/imx-sc-firmware/files/mx8qx-colibri-scfw-tcm.bin?raw=true
+$ mv mx8qx-colibri-scfw-tcm.bin\?raw\=true mx8qx-colibri-scfw-tcm.bin
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+$ chmod +x firmware-imx-8.0.bin
+$ ./firmware-imx-8.0.bin
+
+Copy the following binaries to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp imx-atf/build/imx8qxp/release/bl31.bin .
+$ cp u-boot/u-boot.bin .
+
+Copy the following firmware to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+   $ make colibri-imx8qxp_defconfig
+   $ make u-boot-dtb.imx
+
+Load the U-Boot Binary Using UUU
+
+
+Get the latest version of the universal update utility (uuu) aka ``mfgtools 
3.0``:
+
+https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
+
+Put the module into USB recovery aka serial downloader mode, connect USB device
+to your host and execute ``uuu``:
+
+.. code-block:: bash
+
+sudo ./uuu u-boot/u-boot-dtb.imx
+
+Flash the U-Boot Binary into the eMMC
+-
+
+Burn the ``u-boot-dtb.imx`` binary to 

[PATCH v3 3/5] doc: board: apalis-imx8: convert readme to reST

[Igor Opaniuk]

From: Igor Opaniuk 

Convert README to reStructuredText format.

Signed-off-by: Igor Opaniuk 
---

 board/toradex/apalis-imx8/README  | 66 
 doc/board/toradex/apalix-imx8.rst | 83 +++
 doc/board/toradex/index.rst   |  1 +
 3 files changed, 84 insertions(+), 66 deletions(-)
 delete mode 100644 board/toradex/apalis-imx8/README
 create mode 100644 doc/board/toradex/apalix-imx8.rst

diff --git a/board/toradex/apalis-imx8/README b/board/toradex/apalis-imx8/README
deleted file mode 100644
index e6e3dcb367..00
--- a/board/toradex/apalis-imx8/README
+++ /dev/null
@@ -1,66 +0,0 @@
-U-Boot for the Toradex Apalis iMX8QM V1.0B Module
-
-Quick Start
-===
-
-- Build the ARM trusted firmware binary
-- Get scfw_tcm.bin and ahab-container.img
-- Build U-Boot
-- Load U-Boot binary using uuu
-- Flash U-Boot binary into the eMMC
-- Boot
-
-Get and Build the ARM Trusted Firmware
-==
-
-$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf/
-$ make PLAT=imx8qm bl31
-
-Get scfw_tcm.bin and ahab-container.img
-===
-
-$ wget 
https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-bsp/imx-sc-firmware/files/mx8qm-apalis-scfw-tcm.bin?raw=true
-$ mv mx8qm-apalis-scfw-tcm.bin\?raw\=true mx8qm-apalis-scfw-tcm.bin
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
-$ chmod +x firmware-imx-8.0.bin
-$ ./firmware-imx-8.0.bin
-
-Copy the following binaries to the U-Boot folder:
-
-$ cp imx-atf/build/imx8qm/release/bl31.bin .
-$ cp u-boot/u-boot.bin .
-
-Copy the following firmware to the U-Boot folder:
-
-$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
-
-Build U-Boot
-
-
-$ make apalis-imx8qm_defconfig
-$ make u-boot-dtb.imx
-
-Load the U-Boot Binary Using UUU
-
-
-Get the latest version of the universal update utility (uuu) aka mfgtools 3.0:
-
-https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
-
-Put the module into USB recovery aka serial downloader mode, connect USB device
-to your host and execute uuu:
-
-sudo ./uuu u-boot/u-boot-dtb.imx
-
-Flash the U-Boot Binary into the eMMC
-=
-
-Burn the u-boot-dtb.imx binary to the primary eMMC hardware boot area 
partition:
-
-load mmc 1:1 $loadaddr u-boot-dtb.imx
-setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
-mmc dev 0 1
-mmc write ${loadaddr} 0x0 ${blkcnt}
-
-Boot
diff --git a/doc/board/toradex/apalix-imx8.rst 
b/doc/board/toradex/apalix-imx8.rst
new file mode 100644
index 00..e0c2929032
--- /dev/null
+++ b/doc/board/toradex/apalix-imx8.rst
@@ -0,0 +1,83 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Apalis iMX8QM V1.0B Module
+=
+
+Quick Start
+---
+
+- Build the ARM trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Load U-Boot binary using uuu
+- Flash U-Boot binary into the eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware
+--
+
+.. code-block:: bash
+
+$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf/
+$ make PLAT=imx8qm bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---
+
+.. code-block:: bash
+
+$ wget 
https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-
+  bsp/imx-sc-firmware/files/mx8qm-apalis-scfw-tcm.bin?raw=true
+$ mv mx8qm-apalis-scfw-tcm.bin\?raw\=true mx8qm-apalis-scfw-tcm.bin
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+$ chmod +x firmware-imx-8.0.bin
+$ ./firmware-imx-8.0.bin
+
+Copy the following binaries to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp imx-atf/build/imx8qm/release/bl31.bin .
+$ cp u-boot/u-boot.bin .
+
+Copy the following firmware to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
+
+Build U-Boot
+
+.. code-block:: bash
+
+$ make apalis-imx8qm_defconfig
+$ make u-boot-dtb.imx
+
+Load the U-Boot Binary Using UUU
+
+
+Get the latest version of the universal update utility (uuu) aka ``mfgtools 
3.0``:
+
+https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
+
+Put the module into USB recovery aka serial downloader mode, connect USB device
+to your host and execute uuu:
+
+.. code-block:: bash
+
+sudo ./uuu u-boot/u-boot-dtb.imx
+
+Flash the U-Boot Binary into the eMMC
+-
+
+Burn the ``u-boot-dtb.imx`` binary to the primary eMMC hardware boot area
+partition and boot:
+

[PATCH v3 5/5] doc: board: add rockchip subfolder

[Igor Opaniuk]

From: Igor Opaniuk 

This fixes a warning when invoking make htmldocs:
checking consistency...
doc/board/rockchip/index.rst: WARNING: document isn't included in any toctree

Signed-off-by: Igor Opaniuk 
---

 doc/board/index.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/board/index.rst b/doc/board/index.rst
index f2f5907b8c..f061e8ecfc 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -14,6 +14,7 @@ Board-specific doc
google/index
intel/index
renesas/index
+   rockchip/index
sifive/index
toradex/index
xilinx/index
-- 
2.17.1

[PATCH v3 1/5] doc: board: colibri_imx7: add readme.rst

[Igor Opaniuk]

From: Igor Opaniuk 

- add initial index for toradex boards reST documentation
- add initial readme.rst file which provides all needed information
for obtaining a workable image ready for flashing
for both eMMC/NAND versions of Colibri iMX7.

Signed-off-by: Igor Opaniuk 
---

 doc/board/index.rst|   1 +
 doc/board/toradex/colibri_imx7.rst | 128 +
 doc/board/toradex/index.rst|   9 ++
 3 files changed, 138 insertions(+)
 create mode 100644 doc/board/toradex/colibri_imx7.rst
 create mode 100644 doc/board/toradex/index.rst

diff --git a/doc/board/index.rst b/doc/board/index.rst
index 00e72f57cd..f2f5907b8c 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -15,4 +15,5 @@ Board-specific doc
intel/index
renesas/index
sifive/index
+   toradex/index
xilinx/index
diff --git a/doc/board/toradex/colibri_imx7.rst 
b/doc/board/toradex/colibri_imx7.rst
new file mode 100644
index 00..9d770251af
--- /dev/null
+++ b/doc/board/toradex/colibri_imx7.rst
@@ -0,0 +1,128 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Colibri iMX7
+===
+
+Quick Start
+---
+
+- Build U-Boot
+- NAND IMX image adjustments before flashing
+- Flashing manually U-Boot to eMMC
+- Flashing manually U-Boot to NAND
+- Using ``update_uboot`` script
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+$ export CROSS_COMPILE=arm-linux-gnueabi-
+$ export ARCH=arm
+$ make colibri_imx7_emmc_defconfig # For NAND: colibri_imx7_defconfig
+$ make
+
+After build succeeds, you will obtain final ``u-boot-dtb.imx`` IMX specific
+image, ready for flashing (but check next section for additional
+adjustments).
+
+Final IMX program image includes (section ``6.6.7`` from `IMX7DRM
+`_):
+
+* **Image vector table** (IVT) for BootROM
+* **Boot data** -indicates the program image location, program image size
+  in bytes, and the plugin flag.
+* **Device configuration data**
+* **User image**: U-Boot image (``u-boot-dtb.bin``)
+
+
+IMX image adjustments prior to flashing
+
+
+1. U-Boot for both Colibri iMX7 NAND and eMMC versions
+is built with HABv4 support (`AN4581.pdf
+`_)
+enabled by default, which requires to generate a proper
+Command Sequence File (CSF) by srktool from NXP (not included in the
+U-Boot tree, check additional details in introduction_habv4.txt)
+and concatenate it to the final ``u-boot-dtb.imx``.
+
+2. In case if you don't want to generate a proper ``CSF`` (for any reason),
+you still need to pad the IMX image so i has the same size as specified in
+in **Boot Data** section of IMX image.
+To obtain this value, run:
+
+.. code-block:: bash
+
+$ od -X -N 0x30 u-boot-dtb.imx
+000402000d1 8780  877ff42c
+020877ff420 877ff400 878a5000 
+
+040877ff000 000a8060  40b401d2
+    
+
+Where:
+
+* ``877ff400`` - IVT self address
+* ``877ff000`` - Program image address
+* ``000a8060`` - Program image size
+
+To calculate the padding:
+
+* IVT offset = ``0x877ff400`` - ``0x877ff000`` = ``0x400``
+* Program image size = ``0xa8060`` - ``0x400`` = ``0xa7c60``
+
+and then pad the image:
+
+.. code-block:: bash
+
+$ objcopy -I binary -O binary --pad-to 0xa7c60 --gap-fill=0x00 \
+u-boot-dtb.imx u-boot-dtb.imx.zero-padded
+
+3. Also, according to requirement from ``6.6.7.1``, the final image
+should have ``0x400`` offset for initial IVT table.
+
+For eMMC setup we handle this by flashing it to ``0x400``, howewer
+for NAND setup we adjust the image prior to flashing, adding padding in the
+beginning of the image.
+
+.. code-block:: bash
+
+$ dd if=u-boot-dtb.imx.zero-padded of=u-boot-dtb.imx.ready bs=1024 seek=1
+
+Flash U-Boot IMX image to eMMC
+--
+
+Flash the ``u-boot-dtb.imx.zero-padded`` binary to the primary eMMC hardware
+boot area partition:
+
+.. code-block:: bash
+
+
+=> load mmc 1:1 $loadaddr u-boot-dtb.imx.zero-padded
+=> setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+=> mmc dev 0 1
+=> mmc write ${loadaddr} 0x2 ${blkcnt}
+
+Flash U-Boot IMX image to NAND
+--
+
+.. code-block:: bash
+
+=> load mmc 1:1 $loadaddr u-boot-dtb.imx.ready
+=> nand erase.part u-boot1
+=> nand write ${loadaddr} u-boot1 ${filesize}
+=> nand erase.part u-boot2
+=> nand write ${loadaddr} u-boot2 ${filesize}
+
+Using update_uboot script
+-
+
+You can also usb U-Boot env update_uboot script,
+which wraps all eMMC/NAND specific command invocation:
+
+.. code-block:: bash
+
+=> load mmc 1:1 $loadaddr u-boot-dtb.imx.ready
+=> run update_uboot
+
diff --git a/doc/board/toradex/index.rst b/doc/board/toradex/index.rst
new file mode 100644

Re: [PATCH 1/9] dma-mapping: fix the prototype of dma_map_single()

[Masahiro Yamada]

Hi Simon,

On Wed, Feb 5, 2020 at 9:17 AM Simon Glass  wrote:
>
> On Tue, 4 Feb 2020 at 04:09, Masahiro Yamada
>  wrote:
> >
> > Make dma_map_single() return the dma address, and remove the
> > pointless volatile.
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  arch/arm/include/asm/dma-mapping.h   | 5 +++--
> >  arch/nds32/include/asm/dma-mapping.h | 5 +++--
> >  arch/riscv/include/asm/dma-mapping.h | 5 +++--
> >  arch/x86/include/asm/dma-mapping.h   | 5 +++--
> >  4 files changed, 12 insertions(+), 8 deletions(-)
>
> Reviewed-by: Simon Glass 
>
> But please can you add a full function comment in the header files?


I can comment them, but it is tedious to duplicate
exactly the same description to all of these architectures.

So, my next plan is to merge them into
include/asm-generic/dma-mapping.h,
then make it a single point of comments.

Each arch's  can simply wraps


It would be beyond the scope of this series
(since my main motivation is fix the mmc/sdhci bug).

So, I want to just let this series go in.

After it lands, I can factoring them out,
and add some comments.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 02/10] mmc: Add init() API

[Wolfgang Denk]

Dear Tom,

In message <20200211135633.8b4d0240...@gemini.denx.de> I wrote:
>
> > I'm a little wary of changing the global setting for everyone as well.
> > Perhaps we just need to note the problem happened for now and see if it
> > really happens again in the future, such that we need to consider such a
> > heavy-handed work-around.  Thanks for looking into this more!
>
> We will continue to look into this a bit deeper; I will report back.

Running some more tests confirms that

1) mailman indeed removes entries from the Cc: address list, if
   these refer to subscribers _and_ these have the "nodupes" flag
   set;

2) unsetting the "nodupes" option makes the problem go away.


The statement in [1] suggests that this is considered "intentional
by design", though I cannot follow the argument that otherwise Cc:
lists would grow in long threads.  Apparently there are many
different opinions, see for example [3].

The code snippet given in the original bug description [2] is still
about the same in the version of mailman which we are running
(v2.1.26) so it should be easy to remove the responsible "else"
branch...


So an easy work around for the problem is to clear the "nodupes"
setting in your subscription - alternatively we can try and patch
mailman to behave like we want it.


What do you think should we do?


[1] https://bugs.launchpad.net/mailman/+bug/1216960/comments/1
[2] https://bugs.launchpad.net/mailman/+bug/1216960
[3] https://bugs.launchpad.net/mailman/+bug/266682


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
"All my life I wanted to be someone; I guess I should have been  more
specific."  - Jane Wagner

Re: [PATCH] ARM: keystone2: enable initrd fixup for LPAE addressing

[Tom Rini]

On Tue, Feb 11, 2020 at 09:25:52AM +0530, Lokesh Vutla wrote:

> From: Tero Kristo 
> 
> Keystone2 u-boot loads the initrd image into non-LPAE addressed memory
> but linux kernel is running in LPAE. This causes a conflict as kernel
> detects that non-memory address is passed and kernel ignores initrd.
> There is an existing fixup logic to modify the address in the proper
> configuration, but this is disabled at the moment. Enable the fixup
> by setting the env variable for this so that initrd can be used
> properly.
> 
> Signed-off-by: Tero Kristo 
> Signed-off-by: Lokesh Vutla 
> ---
> - This fixes boot on k2g platforms.
> 
>  include/configs/ti_armv7_keystone2.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/ti_armv7_keystone2.h 
> b/include/configs/ti_armv7_keystone2.h
> index ba12428dbe..1b014c1022 100644
> --- a/include/configs/ti_armv7_keystone2.h
> +++ b/include/configs/ti_armv7_keystone2.h
> @@ -213,6 +213,7 @@
>   "tftp_root=/\0" \
>   "nfs_root=/export\0"\
>   "mem_lpae=1\0"  \
> + "uinitrd_fixup=1\0" \
>   "addr_ubi=0x8200\0" \
>   "addr_secdb_key=0xc00\0"\
>   "name_kern=zImage\0"\

OK, hold up.  Why is any of this code needed and can't the normal
bootm_size / bootm_low / etc as documented in the README enforce these
constraints?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] mmc: fsl_esdhc: actually enable cache snooping on mpc830x

[Rasmus Villemoes]

On 06/02/2020 05.14, Y.b. Lu wrote:
>> -Original Message-
>> From: Peng Fan 
>> Sent: Wednesday, February 5, 2020 3:08 PM
>> To: Rasmus Villemoes ; u-boot@lists.denx.de;
>> Y.b. Lu 
>> Cc: Mario Six 
>> Subject: RE: [PATCH] mmc: fsl_esdhc: actually enable cache snooping on
>> mpc830x
>>
>>> Subject: [PATCH] mmc: fsl_esdhc: actually enable cache snooping on
>> mpc830x
>>
>> + Y.b
>>
>> Are you ok with this patch?
> 
> The mpc830x is old Freescale PowerPC platforms I don't have.
> But I agree the fix-up.
> 
> Reviewed-by: Yangbo Lu 

Thanks. Any chance this could make it to master before the 2020.04 release?

Rasmus

Re: [PATCH resend 0/2] gpio: mpc8xxx: honour shadow register when writing gpdat

[Rasmus Villemoes]

On 28/01/2020 13.04, Rasmus Villemoes wrote:

> Rasmus Villemoes (2):
>   gpio: mpc8xxx: don't modify gpdat when setting gpio as input
>   gpio: mpc8xxx: don't do RMW on gpdat register when setting value
> 
>  drivers/gpio/mpc8xxx_gpio.c | 41 ++---
>  1 file changed, 15 insertions(+), 26 deletions(-)

ping

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Stefan]

On 11.02.20 14:54, Daniel Schwierzeck wrote:

On Tue, Feb 11, 2020 at 11:58 AM Mauro Condarelli  wrote:


Thanks Daniel.

On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:

Hi Mauro,

Am 10.02.20 um 21:20 schrieb Mauro Condarelli:

FYI
I've been using this patchset for over a week without any adverse effect.
It allowed me to port to VoCore2 board.
Should I add a "Tested-by" flag?
If so: how should I do it?

Regards
Mauro Codarelli


sorry that I could respond to your questions earlier. I've pushed the
complete patch set from Weijie to:

https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing

I tried to use this repo/branch, but something is wrong (or I goofed badly).

Maybe this helps you with development. If you have a bootable patch set
(you can do MMC later) for your VoCore2 board, please submit a regular
patch series based on that branch so that we can review again.

I *do* have a bootable patchset built on top of master + Nemirovsky
"reconfigurable cpu clocks" + Weijie v3.
Result is fully working, including net and mmc/SD.

This patchset applies cleanly to uboot-mips/testing and compile
apparently without errors, but resulting u-boot.bin does not work.
By "does not work" I mean it does not utter a single char on debug
serial.

I tried to do a complete diff between my working tree and this
non-working one and there are tons of differences, but I couldn't
spot anything that might be relevant.

I am unsure on how to proceed; please advise.


but do you reach the U-Boot prompt? If I apply your patch and build
it, I need to be able to program the resulting U-Boot image to SPI
flash and boot to U-Boot prompt. Also note that the final U-Boot image
with SPL is now called u-boot-mtmips.bin. Don't try to use u-boot.bin.


A quick remark on this, as I've forgotten to write about this:

I would like to change the resulting image name from this specific
"u-boot-mips.bin" to the already known "u-boot-with-spl.bin" name.
There is no need to introduce a new name here and there is nothing
"mtmips" specific in this image type.

Thanks,
Stefan

dm: core: Board failing to boot since commit 82de42fa1468 (parent data/probe)

[Wolfgang Wallner]

Hello Simon,

Since commit 82de42fa1468 ("dm: core: Allocate parent data separate from
probing parent") I have trouble booting my board (a custom Apollo Lake design
booted via Coreboot + U-Boot).

I think this is because the function ns16550_serial_ofdata_to_platdata() of
the UART driver noew tries to access the PCI bus before it is probed.
I'm aware of the comment which you have added to pci-uclass.c [1].

So the correct way to fix this would be to adapt the uart driver in ns16550.c?

regards, Wolfgang

Detail information:

As far as I understand the situation the following things happen:
 * My debug UART is probed
 * This triggers a call to ns16550_serial_ofdata_to_platdata()
 * This function tries to read BAR0 from the PCI devices
 * Reading BAR0 returns 0x, as the PCI bus has not been probed yet
 * The serial driver tries to read from a non-existing register based on this
   invalid BAR0 value and hangs indefinitely.

This is confirmed by the warning which you have introduced a few commits ealier
in commit 4886287ee4f9 ("pci: Print a warning if the bus is accessed before
probing"):

  "dm_pci_get_bdf() PCI: Device 'uart@18,2' on unprobed bus 'pci'"

[1] "A common cause of this problem is that this function is called in the
ofdata_to_platdata() method of @dev. Accessing the PCI bus in that
method is not allowed, since it has not yet been probed. To fix this,
move that access to the probe() method of @dev instead."

Re: [PATCH 2/3] tools: add fdt_add_pubkey

[Alex Kiernan]

On Tue, Feb 11, 2020 at 10:22 AM Rasmus Villemoes
 wrote:
>
> On 11/02/2020 10.54, Alex Kiernan wrote:
> > On Tue, Feb 11, 2020 at 9:49 AM Rasmus Villemoes
> >  wrote:
> >>
> >> Having to use the -K option to mkimage to populate U-Boot's .dtb with the
> >> public key while signing the kernel FIT image is often a little
> >> awkward. In particular, when using a meta-build system such as
> >> bitbake/Yocto, having the tasks of the kernel and U-Boot recipes
> >> intertwined, modifying deployed artifacts and rebuilding U-Boot with
> >> an updated .dtb is quite cumbersome. Also, in some scenarios one may
> >> wish to build U-Boot complete with the public key(s) embedded in the
> >> .dtb without the corresponding private keys being present on the same
> >> build host.
> >>
> >
> > Have you started looking at the required bitbake pieces? You're
> > definitely dealing with a piece of pain that I'd like resolved!
>
> Not really, but I know that something like this is a necessary first
> part - and I'm glad to know I'm not the only one struggling with this.
>
> For now I've come to the conclusion that kernel-fitimage.bbclass is not
> worth the trouble (for example, I need to create two different fit
> images with different initramfs, but a fit image without initramfs is
> pointless in my case, and there's no way to use kernel-fitimage.bbclass
> for that), so I just set KERNEL_IMAGETYPE to vmlinux, then have my own
> extra tasks doing the objcopy -O binary, gzip, and mkimage the different
> fit images I need.
>

kernel-fitimage is a nightmare... every time someone touches it the
risk of it breaking for someone else is pretty high. FWIW my flow
through it is just kernel (no initramfs), DTBs and configurations,
with keys pre-embedded in U-Boot, so avoiding the loop back through
that otherwise happens. But I could do with the ability to compose
configurations in it, which isn't easy with it today.

I suspect leaving kernel-fitimage to one side and starting again (with
tests) has a lot of merit!

> [I'm also thinking that adding a companion tool for doing the signing
> part might make sense at some point - it's somewhat counter-intuituve
> that the .its contains some of the information (base name of key and
> algorithm - mkimage currently just segfaults if key-name-hint is
> accidentally omitted from the .its), while mkimage needs to be fed with
> another part (directory holding the keys).]
>
> Rasmus



--
Alex Kiernan

Re: [PATCH v2 02/10] mmc: Add init() API

[Wolfgang Denk]

Dear Tom,

In message <20200210142800.GJ13379@bill-the-cat> you wrote:
> 
> I'm a little wary of changing the global setting for everyone as well.
> Perhaps we just need to note the problem happened for now and see if it
> really happens again in the future, such that we need to consider such a
> heavy-handed work-around.  Thanks for looking into this more!

We will continue to look into this a bit deeper; I will report back.

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
Do not follow where the path may leadgo instead where there is no
path and leave a trail.

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Daniel Schwierzeck]

On Tue, Feb 11, 2020 at 11:58 AM Mauro Condarelli  wrote:
>
> Thanks Daniel.
>
> On 2/10/20 10:28 PM, Daniel Schwierzeck wrote:
> > Hi Mauro,
> >
> > Am 10.02.20 um 21:20 schrieb Mauro Condarelli:
> >> FYI
> >> I've been using this patchset for over a week without any adverse effect.
> >> It allowed me to port to VoCore2 board.
> >> Should I add a "Tested-by" flag?
> >> If so: how should I do it?
> >>
> >> Regards
> >> Mauro Codarelli
> >>
> > sorry that I could respond to your questions earlier. I've pushed the
> > complete patch set from Weijie to:
> >
> > https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
> I tried to use this repo/branch, but something is wrong (or I goofed badly).
> > Maybe this helps you with development. If you have a bootable patch set
> > (you can do MMC later) for your VoCore2 board, please submit a regular
> > patch series based on that branch so that we can review again.
> I *do* have a bootable patchset built on top of master + Nemirovsky
> "reconfigurable cpu clocks" + Weijie v3.
> Result is fully working, including net and mmc/SD.
>
> This patchset applies cleanly to uboot-mips/testing and compile
> apparently without errors, but resulting u-boot.bin does not work.
> By "does not work" I mean it does not utter a single char on debug
> serial.
>
> I tried to do a complete diff between my working tree and this
> non-working one and there are tons of differences, but I couldn't
> spot anything that might be relevant.
>
> I am unsure on how to proceed; please advise.

but do you reach the U-Boot prompt? If I apply your patch and build
it, I need to be able to program the resulting U-Boot image to SPI
flash and boot to U-Boot prompt. Also note that the final U-Boot image
with SPL is now called u-boot-mtmips.bin. Don't try to use u-boot.bin.

Regarding debug UART you also need to configure the serial driver with
"make menuconfig" (register base, clocks, baud rate etc.). There is no
driver model or device-tree involved at that point. I think Stefan
already told you the correct settings and you need this
board_early_init_f magic for the pinmux (don't forget to enable
CONFIG_BOARD_EARLY_INIT_F). But for the production mode debug UART
should be disabled anyway. SPL UART is different than debug UART.
AFAIU the regular driver model and device-tree stuff should work
there. For the pinmux you'll need the new CONFIG_SPL_UART2_SPIS_PINMUX
option. According to the code, you'll also need to configure
CONFIG_CONS_INDEX = 3.

[PATCH v1 3/3] colibri-imx8x: convert readme to reStructuredText

[Igor Opaniuk]

From: Igor Opaniuk 

Convert README to reStructuredText format.

Signed-off-by: Igor Opaniuk 
---

 board/toradex/colibri-imx8x/README | 66 -
 board/toradex/colibri-imx8x/readme.rst | 82 ++
 2 files changed, 82 insertions(+), 66 deletions(-)
 delete mode 100644 board/toradex/colibri-imx8x/README
 create mode 100644 board/toradex/colibri-imx8x/readme.rst

diff --git a/board/toradex/colibri-imx8x/README 
b/board/toradex/colibri-imx8x/README
deleted file mode 100644
index 708bb3e51c..00
--- a/board/toradex/colibri-imx8x/README
+++ /dev/null
@@ -1,66 +0,0 @@
-U-Boot for the Toradex Colibri iMX8QXP V1.0B Module
-
-Quick Start
-===
-
-- Build the ARM trusted firmware binary
-- Get scfw_tcm.bin and ahab-container.img
-- Build U-Boot
-- Load U-Boot binary using uuu
-- Flash U-Boot binary into the eMMC
-- Boot
-
-Get and Build the ARM Trusted Firmware
-==
-
-$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf/
-$ make PLAT=imx8qxp bl31
-
-Get scfw_tcm.bin and ahab-container.img
-===
-
-$ wget 
https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-bsp/imx-sc-firmware/files/mx8qx-colibri-scfw-tcm.bin?raw=true
-$ mv mx8qx-colibri-scfw-tcm.bin\?raw\=true mx8qx-colibri-scfw-tcm.bin
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
-$ chmod +x firmware-imx-8.0.bin
-$ ./firmware-imx-8.0.bin
-
-Copy the following binaries to the U-Boot folder:
-
-$ cp imx-atf/build/imx8qxp/release/bl31.bin .
-$ cp u-boot/u-boot.bin .
-
-Copy the following firmware to the U-Boot folder:
-
-$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
-
-Build U-Boot
-
-
-$ make colibri-imx8qxp_defconfig
-$ make u-boot-dtb.imx
-
-Load the U-Boot Binary Using UUU
-
-
-Get the latest version of the universal update utility (uuu) aka mfgtools 3.0:
-
-https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
-
-Put the module into USB recovery aka serial downloader mode, connect USB device
-to your host and execute uuu:
-
-sudo ./uuu u-boot/u-boot-dtb.imx
-
-Flash the U-Boot Binary into the eMMC
-=
-
-Burn the u-boot-dtb.imx binary to the primary eMMC hardware boot area 
partition:
-
-load mmc 1:1 $loadaddr u-boot-dtb.imx
-setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
-mmc dev 0 1
-mmc write ${loadaddr} 0x0 ${blkcnt}
-
-Boot
diff --git a/board/toradex/colibri-imx8x/readme.rst 
b/board/toradex/colibri-imx8x/readme.rst
new file mode 100644
index 00..140616c28d
--- /dev/null
+++ b/board/toradex/colibri-imx8x/readme.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for the Toradex Colibri iMX8QXP V1.0B Module
+===
+
+Quick Start
+---
+
+- Build the ARM trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Load U-Boot binary using uuu
+- Flash U-Boot binary into the eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware
+--
+
+.. code-block:: bash
+
+$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf/
+$ make PLAT=imx8qxp bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---
+.. code-block:: bash
+
+$ wget https://github.com/toradex/meta-fsl-bsp-release/blob/
+   toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-
+   bsp/imx-sc-firmware/files/mx8qx-colibri-scfw-tcm.bin?raw=true
+$ mv mx8qx-colibri-scfw-tcm.bin\?raw\=true mx8qx-colibri-scfw-tcm.bin
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+$ chmod +x firmware-imx-8.0.bin
+$ ./firmware-imx-8.0.bin
+
+Copy the following binaries to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp imx-atf/build/imx8qxp/release/bl31.bin .
+$ cp u-boot/u-boot.bin .
+
+Copy the following firmware to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+   $ make colibri-imx8qxp_defconfig
+   $ make u-boot-dtb.imx
+
+Load the U-Boot Binary Using UUU
+
+
+Get the latest version of the universal update utility (uuu) aka ``mfgtools 
3.0``:
+
+https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
+
+Put the module into USB recovery aka serial downloader mode, connect USB device
+to your host and execute ``uuu``:
+
+.. code-block:: bash
+
+sudo ./uuu u-boot/u-boot-dtb.imx
+
+Flash the U-Boot Binary into the eMMC
+-
+
+Burn the ``u-boot-dtb.imx`` binary to the 

[PATCH v1 1/3] verdix-imx8mm: convert readme to reStructuredText

[Igor Opaniuk]

From: Igor Opaniuk 

Convert README to reStructuredText format.

Signed-off-by: Igor Opaniuk 
---

 board/toradex/verdin-imx8mm/README |  88 ---
 board/toradex/verdin-imx8mm/readme.rst | 112 +
 2 files changed, 112 insertions(+), 88 deletions(-)
 delete mode 100644 board/toradex/verdin-imx8mm/README
 create mode 100644 board/toradex/verdin-imx8mm/readme.rst

diff --git a/board/toradex/verdin-imx8mm/README 
b/board/toradex/verdin-imx8mm/README
deleted file mode 100644
index 1dac969476..00
--- a/board/toradex/verdin-imx8mm/README
+++ /dev/null
@@ -1,88 +0,0 @@
-U-Boot for the Toradex Verdin iMX8M Mini Module
-
-Quick Start
-===
-
-- Build the ARM trusted firmware binary
-- Get the DDR firmware
-- Build U-Boot
-- Flash to eMMC
-- Boot
-
-Get and Build the ARM Trusted Firmware (Trusted Firmware A)
-===
-
-$ echo "Downloading and building TF-A..."
-$ git clone -b imx_4.14.98_2.3.0 
https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf
-
-Please edit `plat/imx/imx8mm/include/platform_def.h` so it contains proper
-values for UART configuration and BL31 base address (correct values listed
-below):
-#define BL31_BASE  0x91
-#define IMX_BOOT_UART_BASE 0x3086
-#define DEBUG_CONSOLE  1
-
-Then build ATF (TF-A):
-$ make PLAT=imx8mm bl31
-
-Get the DDR Firmware
-
-
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.4.1.bin
-$ chmod +x firmware-imx-8.4.1.bin
-$ ./firmware-imx-8.4.1.bin
-$ cp firmware-imx-8.4.1/firmware/ddr/synopsys/lpddr4*.bin ./
-
-Build U-Boot
-
-
-$ export CROSS_COMPILE=aarch64-linux-gnu-
-$ make verdin-imx8mm_defconfig
-$ make flash.bin
-
-Flash to eMMC
-=
-
-> tftpboot ${loadaddr} flash.bin
-> setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
-> mmc dev 0 1 && mmc write ${loadaddr} 0x2 ${blkcnt}
-
-As a convenience, instead of the last two commands one may also use the update
-U-Boot wrapper:
-> run update_uboot
-
-Boot
-
-
-ATF, U-boot proper and u-boot.dtb images are packed into FIT image,
-which is loaded and parsed by SPL.
-
-Boot sequence is:
-SPL ---> ATF (TF-A) ---> U-boot proper
-
-Output:
-U-Boot SPL 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
-Normal Boot
-Trying to boot from MMC1
-NOTICE:  Configuring TZASC380
-NOTICE:  RDC off
-NOTICE:  BL31: v2.0(release):rel_imx_4.14.98_2.3.0-0-g09c5cc994-dirty
-NOTICE:  BL31: Built : 01:11:41, Jan 25 2020
-NOTICE:  sip svc init
-
-
-U-Boot 2020.01-00187-gd411d164e5 (Jan 26 2020 - 04:47:26 +0100)
-
-CPU:   Freescale i.MX8MMQ rev1.0 at 0 MHz
-Reset cause: POR
-DRAM:  2 GiB
-MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
-Loading Environment from MMC... OK
-In:serial
-Out:   serial
-Err:   serial
-Model: Toradex Verdin iMX8M Mini Quad 2GB Wi-Fi / BT IT V1.0A, Serial# 06535149
-Net:   eth0: ethernet@30be
-Hit any key to stop autoboot:  0
-Verdin iMX8MM #
diff --git a/board/toradex/verdin-imx8mm/readme.rst 
b/board/toradex/verdin-imx8mm/readme.rst
new file mode 100644
index 00..bd10713165
--- /dev/null
+++ b/board/toradex/verdin-imx8mm/readme.rst
@@ -0,0 +1,112 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for the Toradex Verdin iMX8M Mini Module
+===
+
+Quick Start
+---
+
+- Build the ARM trusted firmware binary
+- Get the DDR firmware
+- Build U-Boot
+- Flash to eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware (Trusted Firmware A)
+---
+
+.. code-block:: bash
+
+$ echo "Downloading and building TF-A..."
+$ git clone -b imx_4.14.98_2.3.0 \
+  https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf
+
+Please edit ``plat/imx/imx8mm/include/platform_def.h`` so it contains proper
+values for UART configuration and BL31 base address (correct values listed
+below):
+
+.. code-block:: bash
+
+#define BL31_BASE   0x91
+#define IMX_BOOT_UART_BASE  0x3086
+#define DEBUG_CONSOLE   1
+
+Then build ATF (TF-A):
+
+.. code-block:: bash
+
+$ make PLAT=imx8mm bl31
+
+Get the DDR Firmware
+
+
+.. code-block:: bash
+
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.4.1.bin
+$ chmod +x firmware-imx-8.4.1.bin
+$ ./firmware-imx-8.4.1.bin
+$ cp firmware-imx-8.4.1/firmware/ddr/synopsys/lpddr4*.bin ./
+
+Build U-Boot
+
+.. code-block:: bash
+
+$ export CROSS_COMPILE=aarch64-linux-gnu-
+$ make verdin-imx8mm_defconfig
+$ make flash.bin
+
+Flash to eMMC
+-
+
+.. code-block:: bash
+
+> tftpboot ${loadaddr} flash.bin
+> setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+> mmc dev 0 1 && mmc write ${loadaddr} 0x2 ${blkcnt}
+
+As a convenience, instead of the last two commands one may also use the 

[PATCH v1 2/3] apalis-imx8: convert readme to reStructuredText

[Igor Opaniuk]

From: Igor Opaniuk 

Convert README to reStructuredText format.

Signed-off-by: Igor Opaniuk 
---

 board/toradex/apalis-imx8/README | 66 --
 board/toradex/apalis-imx8/readme.rst | 83 
 2 files changed, 83 insertions(+), 66 deletions(-)
 delete mode 100644 board/toradex/apalis-imx8/README
 create mode 100644 board/toradex/apalis-imx8/readme.rst

diff --git a/board/toradex/apalis-imx8/README b/board/toradex/apalis-imx8/README
deleted file mode 100644
index e6e3dcb367..00
--- a/board/toradex/apalis-imx8/README
+++ /dev/null
@@ -1,66 +0,0 @@
-U-Boot for the Toradex Apalis iMX8QM V1.0B Module
-
-Quick Start
-===
-
-- Build the ARM trusted firmware binary
-- Get scfw_tcm.bin and ahab-container.img
-- Build U-Boot
-- Load U-Boot binary using uuu
-- Flash U-Boot binary into the eMMC
-- Boot
-
-Get and Build the ARM Trusted Firmware
-==
-
-$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
-$ cd imx-atf/
-$ make PLAT=imx8qm bl31
-
-Get scfw_tcm.bin and ahab-container.img
-===
-
-$ wget 
https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-bsp/imx-sc-firmware/files/mx8qm-apalis-scfw-tcm.bin?raw=true
-$ mv mx8qm-apalis-scfw-tcm.bin\?raw\=true mx8qm-apalis-scfw-tcm.bin
-$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
-$ chmod +x firmware-imx-8.0.bin
-$ ./firmware-imx-8.0.bin
-
-Copy the following binaries to the U-Boot folder:
-
-$ cp imx-atf/build/imx8qm/release/bl31.bin .
-$ cp u-boot/u-boot.bin .
-
-Copy the following firmware to the U-Boot folder:
-
-$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
-
-Build U-Boot
-
-
-$ make apalis-imx8qm_defconfig
-$ make u-boot-dtb.imx
-
-Load the U-Boot Binary Using UUU
-
-
-Get the latest version of the universal update utility (uuu) aka mfgtools 3.0:
-
-https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
-
-Put the module into USB recovery aka serial downloader mode, connect USB device
-to your host and execute uuu:
-
-sudo ./uuu u-boot/u-boot-dtb.imx
-
-Flash the U-Boot Binary into the eMMC
-=
-
-Burn the u-boot-dtb.imx binary to the primary eMMC hardware boot area 
partition:
-
-load mmc 1:1 $loadaddr u-boot-dtb.imx
-setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
-mmc dev 0 1
-mmc write ${loadaddr} 0x0 ${blkcnt}
-
-Boot
diff --git a/board/toradex/apalis-imx8/readme.rst 
b/board/toradex/apalis-imx8/readme.rst
new file mode 100644
index 00..95e2649c90
--- /dev/null
+++ b/board/toradex/apalis-imx8/readme.rst
@@ -0,0 +1,83 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for the Toradex Apalis iMX8QM V1.0B Module
+=
+
+Quick Start
+---
+
+- Build the ARM trusted firmware binary
+- Get scfw_tcm.bin and ahab-container.img
+- Build U-Boot
+- Load U-Boot binary using uuu
+- Flash U-Boot binary into the eMMC
+- Boot
+
+Get and Build the ARM Trusted Firmware
+--
+
+.. code-block:: bash
+
+$ git clone -b imx_4.14.78_1.0.0_ga 
https://source.codeaurora.org/external/imx/imx-atf
+$ cd imx-atf/
+$ make PLAT=imx8qm bl31
+
+Get scfw_tcm.bin and ahab-container.img
+---
+
+.. code-block:: bash
+
+$ wget 
https://github.com/toradex/meta-fsl-bsp-release/blob/toradex-sumo-4.14.78-1.0.0_ga-bringup/imx/meta-bsp/recipes-
+  bsp/imx-sc-firmware/files/mx8qm-apalis-scfw-tcm.bin?raw=true
+$ mv mx8qm-apalis-scfw-tcm.bin\?raw\=true mx8qm-apalis-scfw-tcm.bin
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
+$ chmod +x firmware-imx-8.0.bin
+$ ./firmware-imx-8.0.bin
+
+Copy the following binaries to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp imx-atf/build/imx8qm/release/bl31.bin .
+$ cp u-boot/u-boot.bin .
+
+Copy the following firmware to the U-Boot folder:
+
+.. code-block:: bash
+
+$ cp firmware-imx-8.0/firmware/seco/ahab-container.img .
+
+Build U-Boot
+
+.. code-block:: bash
+
+$ make apalis-imx8qm_defconfig
+$ make u-boot-dtb.imx
+
+Load the U-Boot Binary Using UUU
+
+
+Get the latest version of the universal update utility (uuu) aka ``mfgtools 
3.0``:
+
+https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
+
+Put the module into USB recovery aka serial downloader mode, connect USB device
+to your host and execute uuu:
+
+.. code-block:: bash
+
+sudo ./uuu u-boot/u-boot-dtb.imx
+
+Flash the U-Boot Binary into the eMMC
+-
+
+Burn the ``u-boot-dtb.imx`` binary to the primary eMMC hardware boot area
+partition and boot:
+
+.. 

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Stefan]

On 11.02.20 13:34, Mauro Condarelli wrote:

Thanks for the fast answer, Stefan.

On 2/11/20 12:16 PM, Stefan wrote:

Hi Mauro,
===8<

https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing

I tried to use this repo/branch, but something is wrong (or I goofed
badly).


Just a quick reply: I tested u-boot-mips/testing today and it works just
fine on both LinkIt and the GARDENA board. So there is nothing wrong
with this repository AFAICT.

Suspect is there's something wrong with handling of SPL_UART2_SPIS_PINMUX
(that's where our boards are different), but I couldn't spot any relevant
difference.


Correct, I have not selected this one. You need to select it via "make
menuconfig" for your board and save it to your defconfig by "make
savedefconfig".

If this does not work, then please double-check, if the correct code is
called in this pinx-mux case.


You might need to rebase your patch on top of this branch, as some files
might have changes in the meantime.

What is the recommended procedure, in this case?
I did a:
   git format-patch --full-index -o ../transport weijie.v3
on old branch ("weijie.v3" is the branch on which I added Weijie's patches,
of course), an then I tried simply (on u-boot-mips):
   git checkout -b vocore2 testing
   git am -3 ../transport/*


This sounds like a valid approach.

There are many ways. I usually use "git rebase" for this:

In your case:

- Check out your current working branch
- git checkout -b new-version
- git rebase u-boot-mips/testing

The rebase command will most likely issue some warnings or errors on
files that you need to manually fix. After this "git rebase --continue".
But the output will tell you, what to do.

But again, your approach looks also fine.

Thanks,
Stefan

Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628

[Mauro Condarelli]

Thanks for the fast answer, Stefan.

On 2/11/20 12:16 PM, Stefan wrote:
> Hi Mauro,
> ===8<
>>> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
>> I tried to use this repo/branch, but something is wrong (or I goofed
>> badly).
>
> Just a quick reply: I tested u-boot-mips/testing today and it works just
> fine on both LinkIt and the GARDENA board. So there is nothing wrong
> with this repository AFAICT.
Suspect is there's something wrong with handling of SPL_UART2_SPIS_PINMUX
(that's where our boards are different), but I couldn't spot any relevant
difference.

> You might need to rebase your patch on top of this branch, as some files
> might have changes in the meantime.
What is the recommended procedure, in this case?
I did a:
  git format-patch --full-index -o ../transport weijie.v3
on old branch ("weijie.v3" is the branch on which I added Weijie's patches,
of course), an then I tried simply (on u-boot-mips):
  git checkout -b vocore2 testing
  git am -3 ../transport/*

>
> Thanks,
> Stefan
> ===8<
Regards
Mauro

Re: [PATCH] dm: fix design.rst document

[Tom Rini]

On Sun, Feb 09, 2020 at 07:57:41PM +0100, Dario Binacchi wrote:

> The patch fixes some errors.
> 
> Signed-off-by: Dario Binacchi 
> Reviewed-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature