Re: [U-Boot] [PATCH v4 0/1] imx: support i.MX8QM ROM 7720 a1 board

[Peng Fan]

> Subject: [PATCH v4 0/1] imx: support i.MX8QM ROM 7720 a1 board
> 
> Hello list,
> 
> need some information howto avoid the imx-mkimage repo and create full
> boostream directly from u-boot with all the binary blobs.

Try the diff, and see whether it helps.
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 08ee52edbf..4d0f0970df 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -159,10 +159,8 @@ MKIMAGEFLAGS_flash.bin = -n spl/u-boot-spl.cfgout -T 
$(IMAGE_TYPE) -e 0x10
 flash.bin: MKIMAGEOUTPUT = flash.log

 flash.bin: spl/u-boot-spl.bin u-boot.itb FORCE
-ifeq ($(SPL_DEPFILE_EXISTS),0)
$(call if_changed,mkimage)
 endif
-endif

 else
 MKIMAGEFLAGS_SPL = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \

Regards,
Peng.

> 
> Best regards,
> 
> Oliver
> 
> 
> Oliver Graute (1):
>   imx: support i.MX8QM ROM 7720 a1 board
> 
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/imx8qm-rom7720-a1.dts| 373
> ++
>  arch/arm/mach-imx/imx8/Kconfig|   7 +
>  board/advantech/imx8qm_rom7720_a1/Kconfig |  14 +
>  board/advantech/imx8qm_rom7720_a1/MAINTAINERS |   6 +
>  board/advantech/imx8qm_rom7720_a1/Makefile|  11 +
>  board/advantech/imx8qm_rom7720_a1/README  |  70 
>  .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 141 +++
>  .../advantech/imx8qm_rom7720_a1/imximage.cfg  |  21 +
>  board/advantech/imx8qm_rom7720_a1/spl.c   | 223 +++
>  configs/imx8qm_rom7720_a1_4G_defconfig|  83 
>  include/configs/imx8qm_rom7720.h  | 176 +
>  12 files changed, 1126 insertions(+)
>  create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts
>  create mode 100644 board/advantech/imx8qm_rom7720_a1/Kconfig
>  create mode 100644
> board/advantech/imx8qm_rom7720_a1/MAINTAINERS
>  create mode 100644 board/advantech/imx8qm_rom7720_a1/Makefile
>  create mode 100644 board/advantech/imx8qm_rom7720_a1/README
>  create mode 100644
> board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
>  create mode 100644 board/advantech/imx8qm_rom7720_a1/imximage.cfg
>  create mode 100644 board/advantech/imx8qm_rom7720_a1/spl.c
>  create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig
>  create mode 100644 include/configs/imx8qm_rom7720.h
> 
> --
> 2.17.1

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

Re: [U-Boot] [PATCH 1/1] doc: slimbootloader: Update Linux booting steps on QEMU

[Park, Aiden]

Hi Bin,

> -Original Message-
> From: Park, Aiden
> Sent: Sunday, August 25, 2019 9:56 PM
> To: 'Bin Meng' 
> Cc: Andy Shevchenko ; u-boot@lists.denx.de
> Subject: RE: [PATCH 1/1] doc: slimbootloader: Update Linux booting steps on
> QEMU
> 
> Hi Bin,
> 
> > -Original Message-
> > From: Bin Meng [mailto:bmeng...@gmail.com]
> > Sent: Sunday, August 25, 2019 9:47 PM
> > To: Park, Aiden 
> > Cc: Andy Shevchenko ; u-boot@lists.denx.de
> > Subject: Re: [PATCH 1/1] doc: slimbootloader: Update Linux booting
> > steps on QEMU
> >
> > Hi Aiden,
> >
> > On Mon, Aug 26, 2019 at 11:20 AM Park, Aiden  wrote:
> > >
> > > Hi Bin,
> > >
> > > > -Original Message-
> > > > From: Bin Meng [mailto:bmeng...@gmail.com]
> > > > Sent: Sunday, August 25, 2019 7:36 PM
> > > > To: Park, Aiden 
> > > > Cc: Andy Shevchenko ;
> > > > u-boot@lists.denx.de
> > > > Subject: Re: [PATCH 1/1] doc: slimbootloader: Update Linux booting
> > > > steps on QEMU
> > > >
> > > > Hi Aiden,
> > > >
> > > > On Fri, Aug 23, 2019 at 5:31 AM Park, Aiden  
> > > > wrote:
> > > > >
> > > > > Add steps to test Linux booting on QEMU with Yocto image.
> > > > >
> > > > > Signed-off-by: Aiden Park 
> > > > > ---
> > > > >  doc/board/intel/slimbootloader.rst | 22 ++
> > > > >  1 file changed, 22 insertions(+)
> > > > >
> > > > > diff --git a/doc/board/intel/slimbootloader.rst
> > > > > b/doc/board/intel/slimbootloader.rst
> > > > > index 07c9b126f7..375e676804 100644
> > > > > --- a/doc/board/intel/slimbootloader.rst
> > > > > +++ b/doc/board/intel/slimbootloader.rst
> > > > > @@ -86,6 +86,28 @@ The PayloadId can be any 4 Bytes value.
> > > > >
> > > > > $ qemu-system-x86_64 -machine q35 -nographic -serial
> > > > > mon:stdio -pflash Outputs/qemu/SlimBootloader.bin
> > > > >
> > > > > +Test Linux booting on QEMU target
> > > > > +-
> > > > > +
> > > > > +Let's use LeafHill (APL) Yocto image for testing.
> > > > > +Download it from
> > > > > +http://downloads.yoctoproject.org/releases/yocto/yocto-
> > > > 2.0/machines/leafhill/.
> > > > > +
> > > > > +1. Prepare Yocto hard disk image::
> > > > > +
> > > > > +   $ wget
> > > > > + http://downloads.yoctoproject.org/releases/yocto/yocto-
> > > > 2.0/machines/leafhill/leafhill-4.0-jethro-2.0.tar.bz2
> > > > > +   $ tar -xvf leafhill-4.0-jethro-2.0.tar.bz2
> > > > > +   $ ls -l
> > > > > + leafhill-4.0-jethro-2.0/binary/core-image-sato-intel-corei7-64
> > > > > + .h
> > > > > + ddim
> > > > > + g
> > > >
> > > > nits: this line is not necessary
> > > >
> > > This is just to show unzipped file path and make sure the file exists 
> > > properly.
> > >
> > > > > +
> > > > > +2. Launch Slim Bootloader on QEMU with disk image::
> > > > > +
> > > > > +   $ qemu-system-x86_64 -machine q35 -nographic -serial
> > > > > + mon:stdio -pflash Outputs/qemu/SlimBootloader.bin -drive
> > > > > + id=mydrive,if=none,file=/path/to/core-image-sato-intel-corei7-
> > > > > + 64 .hdd img,format=raw -device ide-hd,drive=mydrive
> > > > > +
> > > > > +3. Update boot environment values on shell::
> > > > > +
> > > > > +   => setenv bootfile vmlinuz
> > > > > +   => setenv bootdev scsi
> > > > > +   => boot
> > > >
> > > > I followed all the instructions here, and I see the same problem
> > > > as I reported
> > > > before: Invalid Boot Flag.
> > > >
> > > > => setenv bootfile vmlinuz
> > > > => setenv bootdev scsi
> > > > => boot
> > > > scanning bus for devices...
> > > > SATA link 0 timeout.
> > > > SATA link 1 timeout.
> > > > SATA link 2 timeout.
> > > > SATA link 3 timeout.
> > > > SATA link 4 timeout.
> > > > Target spinup took 0 ms.
> > > > AHCI 0001. 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode
> > > > flags: ncq only
> > > > Error: Invalid Boot Flag (found 0x, expected 0xaa55)
> > > >
> > > This has a dependency on a patch -
> > > https://patchwork.ozlabs.org/patch/1150306/
> > > which is still waiting to be applied.
> > >
> >
> > Thanks, now I am able to boot the Yocto Linux kernel image.
> >
> > Reviewed-by: Bin Meng 
> > Tested-by: Bin Meng 
> >
> Thanks Bin for your testing.
> 
> > However when testing, I noticed that SlimBootloader does not support
> > multicore? If I passed "-smp 2" or "-smp 4" to QEMU, it failed to
> > boot. Logs
> > below:
> >
> > MP Init (Wakeup)
> > MP Init (Run)
> > Detected 2 CPU threads
> >  CPU  0 APIC ID: 0
> >  CPU  1 APIC ID: 1
> > PCI Enum
> > Call FspNotifyPhase(20) ... Success
> > ACPI Init
> > Less MADT entries than Number of cores..
> > ACPI Ret: Out of Resources
> > Error: Out of Resources
> >
> > ACPI error !
> > STAGE_2: System halted!
> >
> We simply verified a single core system only with QEMU.
> Let me fix this MADT issue on Slim Bootloader side.
> Thanks a lot for bringing up this issue!
> 
Now, Slim Bootloader supports -smp option on QEMU with the latest code base.
Thanks again for bringing this up.

> > Regards,
> > Bin
> 
> Best Regards,
> Aiden

Best Regards,
Aiden

Re: [U-Boot] [PATCH v3 2/2] x86: efi_loader: Use efi_add_conventional_memory_map()

[Park, Aiden]

Hi Bin,

> -Original Message-
> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Tuesday, September 3, 2019 12:21 PM
> To: Park, Aiden ; Bin Meng ;
> Alexander Graf ; u-boot@lists.denx.de
> Subject: Re: [PATCH v3 2/2] x86: efi_loader: Use
> efi_add_conventional_memory_map()
> 
> On 9/3/19 7:43 PM, Park, Aiden wrote:
> > Use efi_add_conventional_memory_map() to configure EFI conventional
> > memory properly with ram_top value. This will give 32bit mode U-Boot
> > proper conventional memory regions even if e820 has a entry which is
> > greater than 32bit address space.
> >
> > Signed-off-by: Aiden Park 
> 
> Together with Bin's patch series for supporting >3GB
> (https://lists.denx.de/pipermail/u-boot/2019-August/382332.html) I see the
> following memory map on an 8GB qemu-x86_defconfig
> (CONFIG_CMD_EFIDEBUG=y):
> 
> ==> efidebug memmap
> Type StartEnd  Attributes
>    ==
> CONVENTIONAL -000a WB
> RESERVED 000a-0010 WB
> CONVENTIONAL 0010-becf4000 WB
> LOADER DATA  becf4000-becf5000 WB
> BOOT DATAbecf5000-becf6000 WB
> RUNTIME DATA becf6000-bed07000 WB|RT
> BOOT DATAbed07000-bed09000 WB
> RESERVED bed09000-bed0a000 WB
> BOOT DATAbed0a000-bed0c000 WB
> RUNTIME DATA bed0c000-bed0d000 WB|RT
> LOADER DATA  bed0d000-bff4f000 WB
> RUNTIME CODE bff4f000-bff5 WB|RT
> LOADER DATA  bff5-c000 WB
> RESERVED e000-f000 WB
> BOOT DATA0001-00024000 WB
> 
> Close to 3GB in low memory and 5 GB above the 4GB boundary.
> 
> Tested-by: Heinrich Schuchardt 
> Reviewed-by: Heinrich Schuchardt 
> 
> @Bin:
> If you plan to create a pull request for RC4, you can take both patches to 
> avoid
> unnecessary dependencies.
> 
> Otherwise I will try to get patch 1/2 into RC4.
> 
In U-Boot master branch, it looks Heinrich did pull request with patch 1/2 and
it was already merged. Can you merge patch 2/2 as well? This blocks OS booting
on real hardware. Appreciate your help.

> Best regards
> 
> Heinrich

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

[U-Boot] [PATCH 6/6] configs: j721e_evm_a72_defconfig: Add HBMC related configs

[Vignesh Raghavendra]

Enable HBMC and HyperFlash in A72 SPL and A72 U-Boot

Signed-off-by: Vignesh Raghavendra 
---
 configs/j721e_evm_a72_defconfig | 12 
 1 file changed, 12 insertions(+)

diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 56df452fb6ca..ef91d07aa33f 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -34,6 +34,7 @@ CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_CMD_ASKENV=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_SF=y
 # CONFIG_CMD_SETEXPR is not set
@@ -63,6 +64,15 @@ CONFIG_MISC=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_AM654=y
+CONFIG_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_MTD_DEVICE=y
+CONFIG_FLASH_CFI_DRIVER=y
+CONFIG_CFI_FLASH=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_HBMC_AM654=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
@@ -85,3 +95,5 @@ CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_TI_SCI=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0,nor0=47034000.hyperbus"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=47034000.hyperbus:512k(hbmc.tiboot3),2m(hbmc.tispl),4m(hbmc.u-boot),256k(hbmc.env),1m(hbmc.sysfw),-@8m(hbmc.rootfs)"
-- 
2.23.0

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

[U-Boot] [PATCH 2/6] mtd: Add TI HyperBus Memory Controller driver

[Vignesh Raghavendra]

AM654/J721e has HyperBus Memory Controller that supports HyperFlash and
HyperRAM devices. It provides a memory mapped interface to interact with
these devices. Add a driver to support the same.
Driver calibrates the controller, setups up for MMIO access and probes
HyperFlash child node.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/mtd/Kconfig  |   7 +++
 drivers/mtd/Makefile |   1 +
 drivers/mtd/hbmc-am654.c | 105 +++
 3 files changed, 113 insertions(+)
 create mode 100644 drivers/mtd/hbmc-am654.c

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 0050fb2b9bf1..37f379d47803 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -94,6 +94,13 @@ config RENESAS_RPC_HF
  This enables access to Hyperflash memory through the Renesas
  RCar Gen3 RPC controller.
 
+config HBMC_AM654
+   bool "HyperBus controller driver for AM65x SoC"
+   depends on SYSCON
+   help
+This is the driver for HyperBus controller on TI's AM65x and
+other SoCs
+
 source "drivers/mtd/nand/Kconfig"
 
 source "drivers/mtd/spi/Kconfig"
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 22ceda93c06d..293079d709aa 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -18,5 +18,6 @@ obj-$(CONFIG_FLASH_PIC32) += pic32_flash.o
 obj-$(CONFIG_ST_SMI) += st_smi.o
 obj-$(CONFIG_STM32_FLASH) += stm32_flash.o
 obj-$(CONFIG_RENESAS_RPC_HF) += renesas_rpc_hf.o
+obj-$(CONFIG_HBMC_AM654) += hbmc-am654.o
 
 obj-y += nand/
diff --git a/drivers/mtd/hbmc-am654.c b/drivers/mtd/hbmc-am654.c
new file mode 100644
index ..5a560f1253ba
--- /dev/null
+++ b/drivers/mtd/hbmc-am654.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+// Author: Vignesh Raghavendra 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FSS_SYSC_REG   0x4
+
+#define HYPERBUS_CALIB_COUNT 25
+
+struct am654_hbmc_priv {
+   void __iomem *mmiobase;
+   bool calibrated;
+};
+
+/* Calibrate by looking for "QRY" string within the CFI space */
+static int am654_hyperbus_calibrate(struct udevice *dev)
+{
+   struct am654_hbmc_priv *priv = dev_get_priv(dev);
+   int count = HYPERBUS_CALIB_COUNT;
+   int pass_count = 0;
+   u16 qry[3];
+
+   if (priv->calibrated)
+   return 0;
+
+   writew(0xF0, priv->mmiobase);
+   writew(0x98, priv->mmiobase + 0xaa);
+
+   while (count--) {
+   qry[0] = readw(priv->mmiobase + 0x20);
+   qry[1] = readw(priv->mmiobase + 0x22);
+   qry[2] = readw(priv->mmiobase + 0x24);
+
+   if (qry[0] == 'Q' && qry[1] == 'R' && qry[2] == 'Y')
+   pass_count++;
+   else
+   pass_count = 0;
+   if (pass_count == 5)
+   break;
+   }
+   writew(0xF0, priv->mmiobase);
+   writew(0xFF, priv->mmiobase);
+
+   return pass_count == 5;
+}
+
+static int am654_select_hbmc(struct udevice *dev)
+{
+   struct regmap *regmap = syscon_get_regmap(dev_get_parent(dev));
+
+   return regmap_update_bits(regmap, FSS_SYSC_REG, 0x2, 0x2);
+}
+
+static int am654_hbmc_bind(struct udevice *dev)
+{
+   return dm_scan_fdt_dev(dev);
+}
+
+static int am654_hbmc_probe(struct udevice *dev)
+{
+   struct am654_hbmc_priv *priv = dev_get_priv(dev);
+   int ret;
+
+   priv->mmiobase = devfdt_remap_addr_index(dev, 1);
+   if (dev_read_bool(dev, "mux-controls")) {
+   ret = am654_select_hbmc(dev);
+   if (ret) {
+   dev_err(dev, "Failed to select HBMC mux\n");
+   return ret;
+   }
+   }
+
+   if (!priv->calibrated) {
+   ret = am654_hyperbus_calibrate(dev);
+   if (!ret) {
+   dev_err(dev, "Calibration Failed\n");
+   return -EIO;
+   }
+   }
+   priv->calibrated = true;
+
+   return 0;
+}
+
+static const struct udevice_id am654_hbmc_dt_ids[] = {
+   {
+   .compatible = "ti,am654-hbmc",
+   },
+   { /* end of table */ }
+};
+
+U_BOOT_DRIVER(hbmc_am654) = {
+   .name   = "hbmc-am654",
+   .id = UCLASS_MTD,
+   .of_match = am654_hbmc_dt_ids,
+   .probe = am654_hbmc_probe,
+   .bind = am654_hbmc_bind,
+   .priv_auto_alloc_size = sizeof(struct am654_hbmc_priv),
+};
-- 
2.23.0

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

[U-Boot] [PATCH 1/6] mtd: cfi_flash: Use CONFIG_SYS_MONITOR_BASE only when defined

[Vignesh Raghavendra]

Make use of CONFIG_SYS_MONITOR_BASE only when available to avoid build
error when CONFIG_SYS_MONITOR_BASE is not defined.

Signed-off-by: Vignesh Raghavendra 
---
 drivers/mtd/cfi_flash.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index c59254c76e3e..fea15fb523d8 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -178,7 +178,8 @@ __maybe_weak u64 flash_read64(void *addr)
 /*---
  */
 #if defined(CONFIG_ENV_IS_IN_FLASH) || defined(CONFIG_ENV_ADDR_REDUND) || \
-   (CONFIG_SYS_MONITOR_BASE >= CONFIG_SYS_FLASH_BASE)
+   (defined(CONFIG_SYS_MONITOR_BASE) && \
+   (CONFIG_SYS_MONITOR_BASE >= CONFIG_SYS_FLASH_BASE))
 static flash_info_t *flash_get_info(ulong base)
 {
int i;
@@ -2329,12 +2330,14 @@ static void flash_protect_default(void)
 #endif
 
/* Monitor protection ON by default */
+#ifdef CONFIG_SYS_MONITOR_BASE
 #if (CONFIG_SYS_MONITOR_BASE >= CONFIG_SYS_FLASH_BASE) && \
(!defined(CONFIG_MONITOR_IS_IN_RAM))
flash_protect(FLAG_PROTECT_SET,
  CONFIG_SYS_MONITOR_BASE,
  CONFIG_SYS_MONITOR_BASE + monitor_flash_len  - 1,
  flash_get_info(CONFIG_SYS_MONITOR_BASE));
+#endif
 #endif
 
/* Environment protection ON by default */
-- 
2.23.0

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

[U-Boot] [PATCH 3/6] arm: dts: k3-j721e-mcu-wakeup: Add HyperBus Controller node

[Vignesh Raghavendra]

Add DT node for HyperBus Memory Controller in the FSS. On J721e, its not
possible to use OSPI0 and HBMC simultaneously as they are muxed within
the Flash Subsystem hence disable HBMC by default as keep OSPI enabled.
Bootloader will fixup DT when it detects HyperFlash instead of OSPI.

Signed-off-by: Vignesh Raghavendra 
---
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi 
b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
index 01a8f4a9908f..bb652f2fb8d4 100644
--- a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
@@ -118,4 +118,30 @@
loczrama = <1>;
};
};
+
+   fss: fss@4700 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0x0 0x4700 0x0 0x100>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   hbmc_mux: hbmc-mux {
+   compatible = "mmio-mux";
+   #mux-control-cells = <1>;
+   mux-reg-masks = <0x4 0x2>; /* HBMC select */
+   };
+
+   hbmc: hyperbus@47034000 {
+   compatible = "ti,j721e-hbmc", "ti,am654-hbmc";
+   reg = <0x0 0x47034000 0x0 0x100>,
+   <0x5 0x 0x1 0x000>;
+   power-domains = <_pds 102 TI_SCI_PD_EXCLUSIVE>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   mux-controls = <_mux 0>;
+   assigned-clocks = <_clks 102 0>;
+   assigned-clock-rates = <1>;
+   };
+   };
 };
-- 
2.23.0

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

[U-Boot] [PATCH 4/6] arm: dts: k3-j721e-som-p0: Add HyperFlash node

[Vignesh Raghavendra]

J721e SoM as a 64MB HyperFlash on board. Add pinmux and DT node for the
same.

Signed-off-by: Vignesh Raghavendra 
---
 arch/arm/dts/k3-j721e-som-p0.dtsi | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-som-p0.dtsi 
b/arch/arm/dts/k3-j721e-som-p0.dtsi
index 1884fc70148f..1e1519f1c900 100644
--- a/arch/arm/dts/k3-j721e-som-p0.dtsi
+++ b/arch/arm/dts/k3-j721e-som-p0.dtsi
@@ -27,3 +27,37 @@
};
};
 };
+
+_pmx0 {
+   mcu_fss0_hpb0_pins_default: mcu-fss0-hpb0-pins-default {
+   pinctrl-single,pins = <
+   J721E_WKUP_IOPAD(0x0, PIN_OUTPUT, 1) /* (E20) 
MCU_OSPI0_CLK.MCU_HYPERBUS0_CK */
+   J721E_WKUP_IOPAD(0x4, PIN_OUTPUT, 1) /* (C21) 
MCU_OSPI0_LBCLKO.MCU_HYPERBUS0_CKn */
+   J721E_WKUP_IOPAD(0x2c, PIN_OUTPUT, 1) /* (F19) 
MCU_OSPI0_CSn0.MCU_HYPERBUS0_CSn0 */
+   J721E_WKUP_IOPAD(0x54, PIN_OUTPUT, 3) /* (E22) 
MCU_OSPI1_CSn1.MCU_HYPERBUS0_CSn1 */
+   J721E_WKUP_IOPAD(0x30, PIN_OUTPUT, 1) /* (E19) 
MCU_OSPI0_CSn1.MCU_HYPERBUS0_RESETn */
+   J721E_WKUP_IOPAD(0x8, PIN_INPUT, 1) /* (D21) 
MCU_OSPI0_DQS.MCU_HYPERBUS0_RWDS */
+   J721E_WKUP_IOPAD(0xc, PIN_INPUT, 1) /* (D20) 
MCU_OSPI0_D0.MCU_HYPERBUS0_DQ0 */
+   J721E_WKUP_IOPAD(0x10, PIN_INPUT, 1) /* (G19) 
MCU_OSPI0_D1.MCU_HYPERBUS0_DQ1 */
+   J721E_WKUP_IOPAD(0x14, PIN_INPUT, 1) /* (G20) 
MCU_OSPI0_D2.MCU_HYPERBUS0_DQ2 */
+   J721E_WKUP_IOPAD(0x18, PIN_INPUT, 1) /* (F20) 
MCU_OSPI0_D3.MCU_HYPERBUS0_DQ3 */
+   J721E_WKUP_IOPAD(0x1c, PIN_INPUT, 1) /* (F21) 
MCU_OSPI0_D4.MCU_HYPERBUS0_DQ4 */
+   J721E_WKUP_IOPAD(0x20, PIN_INPUT, 1) /* (E21) 
MCU_OSPI0_D5.MCU_HYPERBUS0_DQ5 */
+   J721E_WKUP_IOPAD(0x24, PIN_INPUT, 1) /* (B22) 
MCU_OSPI0_D6.MCU_HYPERBUS0_DQ6 */
+   J721E_WKUP_IOPAD(0x28, PIN_INPUT, 1) /* (G21) 
MCU_OSPI0_D7.MCU_HYPERBUS0_DQ7 */
+   >;
+   };
+};
+
+ {
+   status = "disabled";
+   pinctrl-names = "default";
+   pinctrl-0 = <_fss0_hpb0_pins_default>;
+   ranges = <0x0 0x0 0x5 0x0 0x400>, /* 64MB Flash on CS0 */
+<0x1 0x0 0x5 0x400 0x80>; /* 8MB RAM on CS1 */
+
+   flash@0,0 {
+   compatible = "cypress,hyperflash", "cfi-flash";
+   reg = <0x0 0x0 0x400>;
+   };
+};
-- 
2.23.0

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

[U-Boot] [PATCH 5/6] configs: j721e_evm.h: Define CONFIG_SYS_MAX_FLASH_BANKS_DETECT

[Vignesh Raghavendra]

Define CONFIG_SYS_MAX_FLASH_BANKS_DETECT so that number of flash banks
are automatically detected by CFI flash driver

Signed-off-by: Vignesh Raghavendra 
---
 include/configs/j721e_evm.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index dbe226b46d43..8d4040df9bd4 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -56,6 +56,9 @@
 #define CONFIG_SYS_BOOTM_LEN   SZ_64M
 #define CONFIG_CQSPI_REF_CLK   1
 
+/* HyperFlash related configuration */
+#define CONFIG_SYS_MAX_FLASH_BANKS_DETECT 1
+
 /* U-Boot general configuration */
 #define EXTRA_ENV_J721E_BOARD_SETTINGS \
"default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0"  \
-- 
2.23.0

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

[U-Boot] [PATCH 0/6] J721e: Add HyperBus support

[Vignesh Raghavendra]

This series adds support for HyperBus Memory Controller of TI's J721e
and AM654 SoCs.

Vignesh Raghavendra (6):
  mtd: cfi_flash: Use CONFIG_SYS_MONITOR_BASE only when defined
  mtd: Add TI HyperBus Memory Controller driver
  arm: dts: k3-j721e-mcu-wakeup: Add HyperBus Controller node
  arm: dts: k3-j721e-som-p0: Add HyperFlash node
  configs: j721e_evm.h: Define CONFIG_SYS_MAX_FLASH_BANKS_DETECT
  configs: j721e_evm_a72_defconfig: Add HBMC related configs

 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi |  26 +++
 arch/arm/dts/k3-j721e-som-p0.dtsi |  34 +
 configs/j721e_evm_a72_defconfig   |  12 +++
 drivers/mtd/Kconfig   |   7 ++
 drivers/mtd/Makefile  |   1 +
 drivers/mtd/cfi_flash.c   |   5 +-
 drivers/mtd/hbmc-am654.c  | 105 ++
 include/configs/j721e_evm.h   |   3 +
 8 files changed, 192 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/hbmc-am654.c

-- 
2.23.0

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

Re: [U-Boot] Regressions in MTD / SPI FLASH

[Vignesh Raghavendra]

Hi,

On 10/09/19 12:18 AM, Eugeniy Paltsev wrote:
> Hi!
> Comments are inlined:
> 
>> On 04/09/19 11:37 PM, Eugeniy Paltsev wrote:
>>> We faced with regressions caused by
>>> commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
>>> This switch was performed by removing entire u-boot spi-flash
>>> core implementation and copying it from another project.
>>> However the switch is performed without proper testing and
>>> investigations about fixes/improvements were made in u-boot
>>> spi-flash core. This results in regressions.
>>>
>>
>> Apologies for the trouble...
>> As stated in cover letter, this change was necessary as U-Boot SPI flash
>> stack at that time did not features such as 4 byte addressing, SFDP
>> parsing, SPI controllers with MMIO interfaces etc. Also there was need
>> to move to SPI MEM framework to support both SPI NAND and SPI NOR
>> flashes using a single SPI controller drivers.
>> I have to disagree on the part that there was no proper testing... As
>> evident from mailing list archives, patch series was reviewed by
>> multiple reviewers and tested on their platforms as well...
>> Unfortunately its impossible to get all boards owners to test it.
> 
> I'm not talking about getting all customers board and testing changes on them.
> It could be done another way - i.e. like it is done for u-boot driver-model 
> migration:
> by introducing the option for choosing which stack will be used and allow 
> customers
> to switch the flash IC they use to new stack until some deadline.
> 

I did start off with this. But maintaining two stacks is too cumbersome
and adds to code size (which is a big factor for SPL stage)


>>> One of regression we faced with is related to SST26 flash series which
>>> is used on HSDK board. The cause is that SST26 protection ops
>>> implementation was dropped. The fix of this regression is send
>>> as a patch in this series.
>>>
>>
>> I retained most U-Boot specific code as is (like support for BANK
>> address registers, restriction in transfer sizes) but I somehow
>> overlooked this part. Sorry for that
>>
>>> However there are another regressions. I.E: we also faced with broken
>>> SPI flash on another SNPS boards - AXS101 and AXS103. They use different
>>> flash IC (n25q512ax3) and I didn't investigate the cause yet.
>>>
>>
>> Could you provide more details here:
>> What exactly fails? Is the detected correctly? Does reads work fine? Is
>> Erase or Write broken?
> 
> It seems to me that something is wrong with protection ops.
> The erase and write finish without errors however nothing actually happens.
> 

I doubt so, because if the blocks were protected, erase/write would have failed
and Read status/Read flag status register should have reported error values. 
Anyways, I guess I found a wrt how 4 Byte addressing is handled wrt n25q512* 
series.

Could you try with below patch helps[1]? 
If not please provide logs similar what you have provide now.

If below patch does not help, then please try enabling CONFIG_SPI_FLASH_BAR and 
see if that helps.

[1]

---8<-

From 1de4c447cd4b2590c98f9ceccf8ed32029b42d36 Mon Sep 17 00:00:00 2001
From: Vignesh Raghavendra 
Date: Tue, 10 Sep 2019 10:25:17 +0530
Subject: [TST PATCH] mtd: spi: spi-nor-ids: Disable SPI_NOR_4B_OPCODES

Not all variants of n25q256* and n25q512* support 4 Byte stateless
addressing and there is no easy way to discover this at runtime.
Therefore don't set SPI_NOR_4B_OPCODES for these flashes

Signed-off-by: Vignesh Raghavendra 
---
 drivers/mtd/spi/spi-nor-ids.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index a3920ba520e0..66ac3256e8f5 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -161,12 +161,10 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q064a",0x20bb17, 0, 64 * 1024,  128, SECT_4K | 
SPI_NOR_QUAD_READ) },
{ INFO("n25q128a11",  0x20bb18, 0, 64 * 1024,  256, SECT_4K | 
SPI_NOR_QUAD_READ) },
{ INFO("n25q128a13",  0x20ba18, 0, 64 * 1024,  256, SECT_4K | 
SPI_NOR_QUAD_READ) },
-   { INFO("n25q256a",0x20ba19, 0, 64 * 1024,  512, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
-   { INFO("n25q256ax1",  0x20bb19, 0, 64 * 1024,  512, SECT_4K | 
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
-   { INFO6("mt25qu512a",  0x20bb20, 0x104400, 64 * 1024, 1024,
-SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
-   { INFO("n25q512a",0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
-   { INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+   { INFO("n25q256a",0x20ba19, 0, 64 * 1024,  512, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+   { INFO("n25q256ax1",  0x20bb19, 0, 64 * 1024,  512, SECT_4K | 
SPI_NOR_QUAD_READ) },
+   { 

Re: [U-Boot] [PATCH 07/10] ufs: Add glue layer driver for TI J721E devices

[Vignesh Raghavendra]

On 09/09/19 1:49 PM, Faiz Abbas wrote:
> Add glue layer driver for the controller present on TI's J721E devices.
> 
> Signed-off-by: Faiz Abbas 
> ---
>  drivers/ufs/Kconfig|  6 +++
>  drivers/ufs/Makefile   |  1 +
>  drivers/ufs/ti-j721e-ufs.c | 75 ++
>  3 files changed, 82 insertions(+)
>  create mode 100644 drivers/ufs/ti-j721e-ufs.c
> 
> diff --git a/drivers/ufs/Kconfig b/drivers/ufs/Kconfig
> index a320b4561f..4875e9448e 100644
> --- a/drivers/ufs/Kconfig
> +++ b/drivers/ufs/Kconfig
> @@ -14,4 +14,10 @@ config CADENCE_UFS
> This selects the platform driver for the Cadence UFS host
> controller present on present TI's J721e devices.
>  
> +config TI_J721E_UFS
> + bool "Glue Layer driver for UFS on TI J721E devices"
> + help
> +   This selects the glue layer driver for Cadence controller
> +   present on TI's J721E devices.
> +
>  endmenu
> diff --git a/drivers/ufs/Makefile b/drivers/ufs/Makefile
> index 9262bd6cd0..62ed016608 100644
> --- a/drivers/ufs/Makefile
> +++ b/drivers/ufs/Makefile
> @@ -5,3 +5,4 @@
>  
>  obj-$(CONFIG_UFS) += ufs.o ufs-uclass.o
>  obj-$(CONFIG_CADENCE_UFS) += cdns-platform.o
> +obj-$(CONFIG_TI_J721E_UFS) += ti-j721e-ufs.o
> diff --git a/drivers/ufs/ti-j721e-ufs.c b/drivers/ufs/ti-j721e-ufs.c
> new file mode 100644
> index 00..249d3796c0
> --- /dev/null
> +++ b/drivers/ufs/ti-j721e-ufs.c
> @@ -0,0 +1,75 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 

#include 

should be sufficient instead of two includes.

> +#include 
> +#include 
> +
> +#define UFS_SS_CTRL 0x4
> +#define UFS_SS_RST_N_PCSBIT(0)
> +#define UFS_SS_CLK_26MHZBIT(4)
> +
> +static int ti_j721e_ufs_probe(struct udevice *dev)
> +{
> + struct power_domain ufs_pwrdmn;
> + struct regmap *map;
> + unsigned int clock;
> + struct clk clk;
> + u32 reg = 0;
> + int ret;
> +
> + ret = power_domain_get(dev, _pwrdmn);
> + if (ret) {
> + dev_err(dev, "failed to get power domain %d\n", ret);
> + return ret;
> + }
> +
> + ret = power_domain_on(_pwrdmn);
> + if (ret) {
> + dev_err(dev, "Power domain on failed\n");
> + return ret;
> + }

Core takes care of enabling power domain before calling probe. So this
can be dropped

> +
> + ret = regmap_init_mem(dev_ofnode(dev), );
> + if (ret)
> + return ret;
> +


I think regmap is an overkill here.. We are just accessing a single
register and within dedicated wrapper space. Just use regular IO accessors.



> + ret = clk_get_by_index(dev, 0, );
> + if (ret) {
> + dev_err(dev, "failed to get M-PHY clock\n");
> + return ret;
> + }
> +
> + clock = clk_get_rate();
> + if (IS_ERR_VALUE(clock)) {
> + dev_err(dev, "failed to get rate\n");
> + return ret;
> + }
> +
> + if (clock == 2600)
> + reg |= UFS_SS_CLK_26MHZ;
> + /* Take UFS slave device out of reset */
> + reg |= UFS_SS_RST_N_PCS;
> + regmap_write(map, UFS_SS_CTRL, reg);
> +

To be safe, put the slave back to reset before jumping to kernel so that
card does not see any glitches when kernel is doing any
re-initialization of clocks etc.
This can be done in driver remove callback (and needs DM_FLAG_OS_PREPARE
flag to be set in driver declaration)

> + return dm_scan_fdt_dev(dev);
> +}
> +
> +static const struct udevice_id ti_j721e_ufs_ids[] = {
> + {
> + .compatible = "ti,j721e-ufs",
> + },
> + {},
> +};
> +
> +U_BOOT_DRIVER(ti_j721e_ufs) = {
> + .name   = "ti-j721e-ufs",
> + .id = UCLASS_UFS,
> + .of_match   = ti_j721e_ufs_ids,
> + .probe  = ti_j721e_ufs_probe,
> +};
> 

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

Re: [U-Boot] [PATCH 05/10] ufs: Add Initial Support for UFS subsystem

[Vignesh Raghavendra]

On 09/09/19 1:49 PM, Faiz Abbas wrote:
> Add Support for UFS Host Controller Interface (UFSHCI) for communicating
> with Universal Flash Storage (UFS) devices. The steps to initialize the
> host controller interface are the following:
> 
> - Initiate the Host Controller Initialization process by writing to the
> Host controller enable register.
> - Configure the Host Controller base address registers by allocating a
> host memory space and related data structures.
> - Unipro link startup procedure
> - Check for connected device
> - Configure UFS host controller to process requests
> 

I am guessing code is derived from Linux kernel? Could you add kernel
version from which this code is borrowed from?

> Also register this host controller as a SCSI host controller.
> 
> Signed-off-by: Faiz Abbas 
> ---
>  MAINTAINERS  |5 +
>  drivers/Kconfig  |2 +
>  drivers/Makefile |1 +
>  drivers/ufs/Kconfig  |9 +
>  drivers/ufs/Makefile |6 +
>  drivers/ufs/ufs-uclass.c |   16 +
>  drivers/ufs/ufs.c| 1973 ++
>  drivers/ufs/ufs.h|  918 ++
>  drivers/ufs/unipro.h |  270 ++

Should UFS reside under SCSI framework given that UFS follows SAM?
driver/scsi/ufs?

Regards
Vignesh

>  include/dm/uclass-id.h   |1 +
>  include/ufs.h|7 +
>  11 files changed, 3208 insertions(+)
>  create mode 100644 drivers/ufs/Kconfig
>  create mode 100644 drivers/ufs/Makefile
>  create mode 100644 drivers/ufs/ufs-uclass.c
>  create mode 100644 drivers/ufs/ufs.c
>  create mode 100644 drivers/ufs/ufs.h
>  create mode 100644 drivers/ufs/unipro.h
>  create mode 100644 include/ufs.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 36625795a4..ed3a4c352c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -772,6 +772,11 @@ S:   Maintained
>  T:   git git://git.denx.de/u-boot-ubi.git
>  F:   drivers/mtd/ubi/
>  
> +UFS
> +M:   Faiz Abbas 
> +S:   Maintained
> +F:   drivers/ufs/
> +
>  USB
>  M:   Marek Vasut 
>  S:   Maintained
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 96ff4f566a..61bbe88d6c 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -118,6 +118,8 @@ source "drivers/tpm/Kconfig"
>  
>  source "drivers/usb/Kconfig"
>  
> +source "drivers/ufs/Kconfig"
> +
>  source "drivers/video/Kconfig"
>  
>  source "drivers/virtio/Kconfig"
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 6635dabd2c..2794bef18a 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -111,6 +111,7 @@ obj-y += soc/
>  obj-y += thermal/
>  obj-$(CONFIG_TEE) += tee/
>  obj-y += axi/
> +obj-y += ufs/
>  obj-$(CONFIG_W1) += w1/
>  obj-$(CONFIG_W1_EEPROM) += w1-eeprom/
>  
> diff --git a/drivers/ufs/Kconfig b/drivers/ufs/Kconfig
> new file mode 100644
> index 00..538aad8cd9
> --- /dev/null
> +++ b/drivers/ufs/Kconfig
> @@ -0,0 +1,9 @@
> +menu "UFS Host Controller Support"
> +
> +config UFS
> + bool "Support UFS controllers"
> + select DM_SCSI

DM_SCSI has further dependencies, so its preferred not to use select

depends on DM_SCSI

Also if this is moved under drivers/scsi/ then this Kconfig file can be
sourced conditionally

> + help
> +   This selects support for Universal Flash Subsystem (UFS).
> +   Say Y here if you want UFS Support.
> +endmenu
> diff --git a/drivers/ufs/Makefile b/drivers/ufs/Makefile
> new file mode 100644
> index 00..b8df759f66
> --- /dev/null
> +++ b/drivers/ufs/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
> +#
> +
> +obj-$(CONFIG_UFS) += ufs.o ufs-uclass.o
> diff --git a/drivers/ufs/ufs-uclass.c b/drivers/ufs/ufs-uclass.c
> new file mode 100644
> index 00..920bfa64e1
> --- /dev/null
> +++ b/drivers/ufs/ufs-uclass.c
> @@ -0,0 +1,16 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/**
> + * ufs-uclass.c - Universal Flash Subsystem (UFS) Uclass driver
> + *
> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
> + */
> +
> +#include 
> +#include "ufs.h"
> +#include 
> +
> +UCLASS_DRIVER(ufs) = {
> + .id = UCLASS_UFS,
> + .name   = "ufs",
> + .per_device_auto_alloc_size = sizeof(struct ufs_hba),
> +};

[...]

> +#endif /* _UNIPRO_H_ */
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index 09e0ad5391..a606b8c41b 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -96,6 +96,7 @@ enum uclass_id {
>   UCLASS_THERMAL, /* Thermal sensor */
>   UCLASS_TIMER,   /* Timer device */
>   UCLASS_TPM, /* Trusted Platform Module TIS interface */
> + UCLASS_UFS, /* Universale Flash Storage */

s/Universale/Universal

>   UCLASS_USB, /* USB bus */
>   UCLASS_USB_DEV_GENERIC, /* USB generic device */
>   UCLASS_USB_HUB, /* USB hub */
> diff --git a/include/ufs.h b/include/ufs.h
> 

Re: [U-Boot] [PATCH 02/10] scsi: Add max_bytes to scsi_platdata

[Vignesh Raghavendra]

On 09/09/19 1:49 PM, Faiz Abbas wrote:
> diff --git a/include/scsi.h b/include/scsi.h
> index 81ab43c842..076bdbc6a0 100644
> --- a/include/scsi.h
> +++ b/include/scsi.h
> @@ -168,6 +168,7 @@ struct scsi_platdata {
>   unsigned long base;
>   unsigned long max_lun;
>   unsigned long max_id;
> + unsigned long max_bytes;

Please add description of the new field. Also, could the name be bit
more specific like max_bytes_per_req?


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

Re: [U-Boot] [PATCH v1 6/7] mmc: fsl_esdhc: Add emmc hs200 support

[Yinbo Zhu]

Hi York Sun,

Could you help me merge that series patch to uboot upstream tree.

Regards,
Yinbo Zhu
Original Message-
From: Peng Fan 
Sent: 2019年8月28日 9:04
To: Yinbo Zhu ; York Sun ; 
u-boot@lists.denx.de
Cc: Jiafei Pan ; Yinbo Zhu ; Xiaobo Xie 

Subject: RE: [U-Boot] [PATCH v1 6/7] mmc: fsl_esdhc: Add emmc hs200 support

> Subject: [U-Boot] [PATCH v1 6/7] mmc: fsl_esdhc: Add emmc hs200 
> support
> 
> Add eMMC hs200 mode support for increasing ls1028/ls1012/lx2160 eMMC 
> work performance, but without tuning procedure which will cause mmc 
> doesn't work. and this should be TODO work.
> 
> Signed-off-by: Yinbo Zhu 

Acked-by: Peng Fan 

> ---
>  drivers/mmc/fsl_esdhc.c | 34 +++---
>  include/fsl_esdhc.h |  4 
>  2 files changed, 23 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
> 07318472a7..28d2312ef7 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -395,10 +395,6 @@ static int esdhc_send_cmd_common(struct 
> fsl_esdhc_priv *priv, struct mmc *mmc,
>   esdhc_write32(>cmdarg, cmd->cmdarg);
>   esdhc_write32(>xfertyp, xfertyp);
> 
> - if ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK) ||
> - (cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200))
> - flags = IRQSTAT_BRR;
> -
>   /* Wait for the command to complete */
>   start = get_timer(0);
>   while (!(esdhc_read32(>irqstat) & flags)) { @@ -458,12 +454,6 
> @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv *priv, 
> struct mmc *mmc,  #ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO
>   esdhc_pio_read_write(priv, data);
>  #else
> - flags = DATA_COMPLETE;
> - if ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK) ||
> - (cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200))
> {
> - flags = IRQSTAT_BRR;
> - }
> -
>   do {
>   irqstat = esdhc_read32(>irqstat);
> 
> @@ -476,7 +466,7 @@ static int esdhc_send_cmd_common(struct 
> fsl_esdhc_priv *priv, struct mmc *mmc,
>   err = -ECOMM;
>   goto out;
>   }
> - } while ((irqstat & flags) != flags);
> + } while ((irqstat & DATA_COMPLETE) != DATA_COMPLETE);
> 
>   /*
>* Need invalidate the dcache here again to avoid any @@ -517,7
> +507,9 @@ static void set_sysctl(struct fsl_esdhc_priv *priv, struct 
> +mmc
> *mmc, uint clock)
>   int div = 1;
>   int pre_div = 2;
>   int ddr_pre_div = mmc->ddr_mode ? 2 : 1;
> - int sdhc_clk = priv->sdhc_clk;
> + unsigned int sdhc_clk = priv->sdhc_clk;
> + u32 time_out;
> + u32 value;
>   uint clk;
> 
>   if (clock < mmc->cfg->f_min)
> @@ -538,11 +530,18 @@ static void set_sysctl(struct fsl_esdhc_priv 
> *priv, struct mmc *mmc, uint clock)
> 
>   esdhc_clrsetbits32(>sysctl, SYSCTL_CLOCK_MASK, clk);
> 
> - udelay(1);
> + time_out = 20;
> + value = PRSSTAT_SDSTB;
> + while (!(esdhc_read32(>prsstat) & value)) {
> + if (time_out == 0) {
> + printf("fsl_esdhc: Internal clock never stabilised.\n");
> + break;
> + }
> + time_out--;
> + mdelay(1);
> + }
> 
>   esdhc_setbits32(>sysctl, SYSCTL_PEREN | SYSCTL_CKEN);
> -
> - priv->clock = clock;
>  }
> 
>  #ifdef CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK
> @@ -1024,6 +1023,8 @@ static int fsl_esdhc_probe(struct udevice *dev)
>   return ret;
>   }
> 
> + mmc_of_parse(dev, >cfg);
> +
>   mmc = >mmc;
>   mmc->cfg = >cfg;
>   mmc->dev = dev;
> @@ -1081,6 +1082,9 @@ static const struct dm_mmc_ops fsl_esdhc_ops = {
>   .get_cd = fsl_esdhc_get_cd,
>   .send_cmd   = fsl_esdhc_send_cmd,
>   .set_ios= fsl_esdhc_set_ios,
> +#ifdef MMC_SUPPORTS_TUNING
> + .execute_tuning = fsl_esdhc_execute_tuning, #endif
>  };
>  #endif
> 
> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h index 
> 7d7e946ab3..3f496b4cea 100644
> --- a/include/fsl_esdhc.h
> +++ b/include/fsl_esdhc.h
> @@ -205,6 +205,10 @@ struct fsl_esdhc_cfg {  int 
> fsl_esdhc_mmc_init(bd_t *bis);  int fsl_esdhc_initialize(bd_t *bis, 
> struct fsl_esdhc_cfg *cfg);  void fdt_fixup_esdhc(void *blob, bd_t 
> *bd);
> +#ifdef MMC_SUPPORTS_TUNING
> +static inline int fsl_esdhc_execute_tuning(struct udevice *dev,
> + uint32_t opcode) {return 0; }
> +#endif
>  #else
>  static inline int fsl_esdhc_mmc_init(bd_t *bis) { return -ENOSYS; }  
> static inline void fdt_fixup_esdhc(void *blob, bd_t *bd) {}
> --
> 2.17.1
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.d enx.de%2Flistinfo%2Fu-bootdata=02%7C01%7CPeng.Fan%40nxp.com
> 

Re: [U-Boot] [PATCH] spl: dm_mmc: Initialize only the required mmc device

[Peng Fan]

> Subject: [PATCH] spl: dm_mmc: Initialize only the required mmc device
> 
> In SPL, all the available mmc devices gets initialized during boot.
> This might not work in cases where clocks are not available for certain mmc
> devices(other than boot device) and the support for enabling device might not
> be ready.
> 
> Texas Instruments' K3 J721E device having a central system controller
> (dmsc) is one such example falling in this category. Below is the sequence for
> the failing scenario:
> - ROM comes up in SD mode and loads SPL by just initialing SD card.
> - SPL loads dmsc firmware from SD Card.
> Since ROM has enabled SD, SPL need not enable the SD, just need to re
> initialize the card. But SPL is trying to initialize other MMC instances which
> are in disabled state. Since dmsc firmware is not yet available, devices 
> cannot
> be enabled. So in SPL, initialize only the mmc device that is needed.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  common/spl/spl_mmc.c | 14 --
>  drivers/mmc/mmc.c| 24 
>  include/mmc.h|  1 +
>  3 files changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index
> b3619889f7..303f0f80bf 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -113,31 +113,25 @@ static int spl_mmc_get_device_index(u32
> boot_device)
> 
>  static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
> { -#if CONFIG_IS_ENABLED(DM_MMC)
> - struct udevice *dev;
> -#endif
>   int err, mmc_dev;
> 
>   mmc_dev = spl_mmc_get_device_index(boot_device);
>   if (mmc_dev < 0)
>   return mmc_dev;
> 
> +#if CONFIG_IS_ENABLED(DM_MMC)
> + err = mmc_init_device(mmc_dev);
> +#else
>   err = mmc_initialize(NULL);
> +#endif /* DM_MMC */
>   if (err) {
>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>   printf("spl: could not initialize mmc. error: %d\n", err);  
> #endif
>   return err;
>   }
> -
> -#if CONFIG_IS_ENABLED(DM_MMC)
> - err = uclass_get_device(UCLASS_MMC, mmc_dev, );
> - if (!err)
> - *mmcp = mmc_get_mmc_dev(dev);
> -#else
>   *mmcp = find_mmc_device(mmc_dev);
>   err = *mmcp ? 0 : -ENODEV;
> -#endif
>   if (err) {
>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>   printf("spl: could not find mmc device %d. error: %d\n", diff 
> --git
> a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index eecc7d687e..ec8f92ce8f
> 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2998,6 +2998,30 @@ int mmc_initialize(bd_t *bis)
>   return 0;
>  }
> 
> +#if CONFIG_IS_ENABLED(DM_MMC)
> +int mmc_init_device(int num)
> +{
> + struct udevice *dev;
> + struct mmc *m;
> + int ret;
> +
> + ret = uclass_get_device(UCLASS_MMC, num, );
> + if (ret)
> + return ret;
> +
> + m = mmc_get_mmc_dev(dev);
> + if (!m)
> + return 0;
> +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
> + mmc_set_preinit(m, 1);
> +#endif
> + if (m->preinit)
> + mmc_start_init(m);
> +
> + return 0;
> +}
> +#endif
> +
>  #ifdef CONFIG_CMD_BKOPS_ENABLE
>  int mmc_set_bkops_enable(struct mmc *mmc)  { diff --git
> a/include/mmc.h b/include/mmc.h index 46422f41a4..878b4c9e57 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -698,6 +698,7 @@ void mmc_destroy(struct mmc *mmc);
>   */
>  int mmc_unbind(struct udevice *dev);
>  int mmc_initialize(bd_t *bis);
> +int mmc_init_device(int num);
>  int mmc_init(struct mmc *mmc);
>  int mmc_send_tuning(struct mmc *mmc, u32 opcode, int *cmd_error);

Reviewed-by: Peng Fan 

> 
> --
> 2.22.0

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

Re: [U-Boot] [PATCH] usb: xhci-dwc3: Add support for dis_u2_susphy_quirk

[Bin Meng]

On Tue, Sep 10, 2019 at 2:52 AM Neil Armstrong  wrote:
>
> This quirk is necessary for the Amlogic GXL SoCs otherwise the
> Port 2 PHY doesn't get out of suspend and U-Boot resets the board after:
>
> XHCI timeout on event type 33... cannot recover.
> BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()!
> BUG!
>
> This quirk is also handled in the dwc3 core code, but until the
> xhci-dwc3 driver uses the dwc3 core, the quirk must be handled here
> to fix USB support on the Amlogic libretech-cc and libretech-ac board
> when a device is only plugged in the OTG port.
>
> Cc: Yuri Frolov 
> Cc: Bin Meng 
> Fixes: dc9cdf859e ("usb: dwc3: Add DWC3 controller driver support")
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/usb/host/xhci-dwc3.c | 3 +++
>  1 file changed, 3 insertions(+)
>

Thanks for your efforts tracing this down!

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

Re: [U-Boot] [PATCH 1/2] Convert CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE to Kconfig

[Peng Fan]

+Y.b

> -Original Message-
> From: Sébastien Szymanski 
> Sent: 2019年9月9日 14:36
> To: Peng Fan ; u-boot@lists.denx.de
> Cc: Fabio Estevam ; Otavio Salvador
> 
> Subject: Re: [PATCH 1/2] Convert CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
> to Kconfig
> 
> Hello,
> 
> On 9/9/19 3:59 AM, Peng Fan wrote:
> >> Subject: [PATCH 1/2] Convert CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
> to
> >> Kconfig
> >>
> >> This converts the following to Kconfig:
> >>
> >> CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
> >>
> >> Signed-off-by: Sébastien Szymanski
> 
> >> ---
> >>  configs/warp7_defconfig  | 1 +
> >>  configs/warp_defconfig   | 1 +
> >>  drivers/mmc/Kconfig  | 6 ++
> >>  include/configs/warp.h   | 1 -
> >>  include/configs/warp7.h  | 1 -
> >>  scripts/config_whitelist.txt | 1 -
> >>  6 files changed, 8 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index
> >> a022454976..9a167d2c43 100644
> >> --- a/configs/warp7_defconfig
> >> +++ b/configs/warp7_defconfig
> >> @@ -40,6 +40,7 @@ CONFIG_DM_I2C=y
> >>  CONFIG_DM_MMC=y
> >>  CONFIG_SUPPORT_EMMC_BOOT=y
> >>  CONFIG_FSL_USDHC=y
> >> +CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE=y
> >>  CONFIG_PINCTRL=y
> >>  CONFIG_PINCTRL_IMX7=y
> >>  CONFIG_DM_PMIC=y
> >> diff --git a/configs/warp_defconfig b/configs/warp_defconfig index
> >> 7a6ea6f8c6..d719dc779a 100644
> >> --- a/configs/warp_defconfig
> >> +++ b/configs/warp_defconfig
> >> @@ -31,6 +31,7 @@ CONFIG_ENV_IS_IN_MMC=y
> CONFIG_DFU_MMC=y
> >> CONFIG_SUPPORT_EMMC_BOOT=y  CONFIG_FSL_USDHC=y
> >> +CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE=y
> >>  CONFIG_USB=y
> >>  CONFIG_USB_STORAGE=y
> >>  CONFIG_USB_GADGET=y
> >> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
> >> 0ccb1ea701..f61b17b86b 100644
> >> --- a/drivers/mmc/Kconfig
> >> +++ b/drivers/mmc/Kconfig
> >> @@ -701,6 +701,12 @@ config FSL_USDHC
> >>help
> >>  This enables the Ultra Secured Digital Host Controller
> >> enhancements
> >>
> >> +config SYS_FSL_ESDHC_HAS_DDR_MODE
> >> +  depends on FSL_ESDHC || FSL_ESDHC_IMX
> >
> > Please drop FSL_ESDHC.
> 
> Why ? SYS_FSL_ESDHC_HAS_DDR_MODE is used in fsl_esdhc.c too.

Y.b, is this currently used by fsl_esdhc.c?

Thanks,
Peng.

> 
> Regards,
> 
> >
> > Regards,
> > Peng.
> >
> >> +  bool "Enable Dual Data Rate support"
> >> +  help
> >> +This enables Dual Data Rate support (DDR52)
> >> +
> >>  endmenu
> >>
> >>  config SYS_FSL_ERRATUM_ESDHC111
> >> diff --git a/include/configs/warp.h b/include/configs/warp.h index
> >> 5345f5314d..a00c535b50 100644
> >> --- a/include/configs/warp.h
> >> +++ b/include/configs/warp.h
> >> @@ -22,7 +22,6 @@
> >>
> >>  /* MMC Configs */
> >>  #define CONFIG_SYS_FSL_ESDHC_ADDR USDHC2_BASE_ADDR
> >> -#define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
> >>
> >>  /* Watchdog */
> >>  #define CONFIG_WATCHDOG_TIMEOUT_MSECS 3 /* 30s */ diff
> --git
> >> a/include/configs/warp7.h b/include/configs/warp7.h index
> >> 73541fe176..aa259cd9ef 100644
> >> --- a/include/configs/warp7.h
> >> +++ b/include/configs/warp7.h
> >> @@ -18,7 +18,6 @@
> >>
> >>  /* MMC Config*/
> >>  #define CONFIG_SYS_FSL_ESDHC_ADDR   USDHC3_BASE_ADDR
> >> -#define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
> >>  #define CONFIG_SYS_MMC_IMG_LOAD_PART  1
> >>
> >>  /* Switch on SERIAL_TAG */
> >> diff --git a/scripts/config_whitelist.txt
> >> b/scripts/config_whitelist.txt index b18eab1707..49c041b59e 100644
> >> --- a/scripts/config_whitelist.txt
> >> +++ b/scripts/config_whitelist.txt
> >> @@ -2555,7 +2555,6 @@ CONFIG_SYS_FSL_ERRATUM_A_004934
> >> CONFIG_SYS_FSL_ESDHC_ADDR  CONFIG_SYS_FSL_ESDHC_BE
> >> CONFIG_SYS_FSL_ESDHC_BROKEN_TIMEOUT
> >> -CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
> >>  CONFIG_SYS_FSL_ESDHC_LE
> >>  CONFIG_SYS_FSL_ESDHC_NUM
> >>  CONFIG_SYS_FSL_ESDHC_P1010_BROKEN_SDCLK
> >> --
> >> 2.21.0
> >
> --
> Sébastien Szymanski, Armadeus Systems
> Software engineer
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] FAT errors

[AKASHI Takahiro]

On Sun, Sep 08, 2019 at 01:49:30AM +0200, Heinrich Schuchardt wrote:
> On 9/5/19 10:37 AM, AKASHI Takahiro wrote:
> >On Thu, Sep 05, 2019 at 08:43:43AM +0200, Heinrich Schuchardt wrote:
> >>Currently we do no have a maintainer for the FAT file system. Takahiro
> >>has done a great job fixing some of the most prominent deficiencies. But
> >>still the driver is not in good shape:
> >>
> >>I once again ran upon errors in FAT when executing the UEFI SCT.
> >>
> >>Here is some of the output of
> >>dosfsck -w -r -l -a -v -t
> >>The full output has hundreds of errors recorded.
> >
> >While I don't deny shifting to other code base for FAT,
> >I'm willing to debug the current code if you send me
> >binary data of corrupted file system.
> >The first 1MB or so, which will contains directory meta data,
> >would be good enough as I said before.
> >
> >I think that most errors stem from wrong long-file-name handling.
> >
> >-Takahiro Akashi
> 
> The SCT test that really shows the trouble is for
> EFI_FILE_PROTOCOL.GetInfo(). On FAT16 it hits the 512 files per
> directory limit.

Please note that, on FAT16, the root directory can have a fixed
number of blocks and that there is definitely an upper limit of
maximum number of entries allowed under it.

> Both on FAT16 and FAT32 it crashes when saving the log.

Did you see any message, or the file system got corrupted silently?

-Takahiro Akashi

> Observed on qemu_arm64_defconfig with edk2-test HEAD.
> 
> Best regards
> 
> Heinrich
> 
> >
> >
> >>Orphaned long file name part "Sct.log"
> >>   Auto-deleting.
> >>Orphaned long file name part "Sct.log"
> >>   Auto-deleting.
> >>/Log/RuntimeServicesTest/VariableServicesTest0/QueryVariableInfo_Conf_0_0_61758774-91A3-47DD-BDBD-B81094A5F62D.log
> >>   Duplicate directory entry.
> >>   FirstSize 4712 bytes, date 01:00:00 Dec 31 1979
> >>   Second   Size 5086 bytes, date 01:00:00 Dec 31 1979
> >>   Auto-renaming second.
> >>   Renamed to FSCK.008
> >>
> >>BareBox is using a (somewhat outdated) copy of this library with a
> >>little bit of wrapper code:
> >>
> >>FatFs - Generic FAT Filesystem Module
> >>http://elm-chan.org/fsw/ff/00index_e.html
> >>http://elm-chan.org/fsw/ff/arc/ff13c.zip
> >>
> >>The same library is also used for Arduinos:
> >>https://github.com/stm32duino/FatFs
> >>
> >>Shouldn't we try just the same?
> >>
> >>Best regards
> >>
> >>Heinrich
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Using CONFIG_ENV_FLAGS_LIST

[AKASHI Takahiro]

On Mon, Sep 09, 2019 at 02:04:50PM +0200, Lukasz Majewski wrote:
> Hi Claudius,
> 
> > Hi Lukasz,
> > 
> > On 07/09/2019 00.23, Lukasz Majewski wrote:
> > > Hi Claudius,
> > >   
> > >> Hi,
> > >>
> > >> I am currently looking into variable flags in order to make some
> > >> variables read-only for secure boot.
> > >>
> > >> The idea is that the u-boot binary is signed, while the environment
> > >> file/partition is not. So the built-in default environment of
> > >> u-boot can be trusted, while the external environment cannot. The
> > >> assumption is that those flags can be used to customize the
> > >> validation when the external environment is loaded or
> > >> scripts/commands are executed.
> > >>
> > >> From the '/README' I gather that the access attributes can be any
> > >> of "any", "read-only", "write-once" or "change-default".
> > >>
> > >> I first tried to restrict the variables by choosing 'read-only',
> > >> but apparently this applies to the internal environment as well,
> > >> and now those variables are not loaded from the internal
> > >> environment.
> > >>
> > >> Then I tried 'write-once', this worked now as expected from within
> > >> u-boot, but I could modify the environment from the linux userspace
> > >> via fw_setenv and those changes appear in u-boot as well. The same
> > >> for 'change-default'.
> > >>
> > >> Is there another way to fill the internal environment variable hash
> > >> table, so that 'read-only' works as expected?
> > >>
> > >> Heiko wrote some patches that change the behavior of the
> > >> environment loading so that the internal environment is loaded
> > >> first before the external environment. This way 'write-once'
> > >> should work as expected, but I think 'read-only' should work that
> > >> way already and we are missing something here.  
> > > 
> > > I think that Wolfgang had a long discussion with Takahiro AKASHI
> > > (both CC'ed) about similar problem with u-boot envs.  
> > 
> > Were there any conclusions here?
> 
> I don't know if there was any conclusion (or patches).

No. As a matter of fact, I gave up my idea of modifying flags
(attributes) features of U-Boot environment.

> > 
> > For me this 'flags' feature looks more and more like its was not build
> > to save guard the loading from unsigned and untrusted external
> > environments. I think what we would need here is some sort of variable
> > whitelist with some additional checks (type and size), but still allow
> > the u-boot scripts and commands to modify the variables in the hash
> > table (for filesize, ipaddr etc.) at boot time.
> 
> 
> Maybe Takahiro could shed some light on his work and you could discuss
> if your both work could be aligned?

Instead, I'm proposing 'multiple contexts' to be allowed for U-Boot
environment[1]. The idea here is that we may have separated backing
storage areas, for different variable domains with different needs
in U-Boot environment.
For example, in my implementation of UEFI variables,
one for volatile (non-persistent) variables and
another for non-volatile (persistent and auto-saved) variables.
(Please note that a context is allowed *not* to have any backing storage.)

while I'm not sure yet exactly what Claudius's requirement is,
please take a look at my patch below and find out if my work will
fit your expectation.

[1] https://lists.denx.de/pipermail/u-boot/2019-September/382835.html

Thanks,
-Takahiro Akashi

> 
> > 
> > regards,
> > Claudius
> > 
> > > 
> > > For example:
> > > https://patchwork.ozlabs.org/patch/1158770/
> > >   
> > >>
> > >> Thanks,
> > >> Claudius
> > >>  
> > > 
> > > 
> > > 
> > > Best regards,
> > > 
> > > Lukasz Majewski
> > > 
> > > --
> > > 
> > > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > > lu...@denx.de 
> > 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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

Re: [U-Boot] [EXT][xhci] XHCI Short Packet Issues

[Aaron Williams]

Hi Bin,

I have some more data. It looks like U-Boot is not properly handling the short 
transfer case according to section 4.10.1.1.2 in the XHCI 3.1 specification. 
In this case, when the data fits in the first TRB, two transfer event TRBs 
will be generated. The first one will indicate that there is a short packet 
and points to the first TRB and the length is calculated based on the TRB 
pointed to, not the total TRB. A second success TRB is also received.

This seems consistent with what I am seeing. U-Boot does not handle this at 
all. It expects there to always be a single transfer event TRB with the length 
calculated based on the total length, not the TRB length. I can re-work this 
so that short packets can be better handled. 

The easiest way to test this is with a USB Ethernet dongle then modifying 
drivers/usb/eth/usb_ether.c to force it to allocate a buffer that will span 
64K where packets fit in the first half. I have attached this patch to force 
the XHCI problem to manifest itself.

-Aaron

On Friday, July 12, 2019 8:51:41 PM PDT Aaron Williams wrote:
> No, it's our Marvell OcteonTX2 SoC. I put in what I thought was a fix, but
> I'm still working on it. This issue only shows up when using a USB Ethernet
> device where the rx buffer crosses a 64K boundary and the packet is
> received in the first buffer. I don't know how other hardware behaves in
> this situation. The case I'm seeing this is where the receive buffer starts
> at 128 bytes away from a 64K boundary so two receive TRBs are used. The
> first is for 128 bytes and the other is for the rest of the buffer. This is
> with the asix88179.
> 
> I am seeing some other strange behavior which is leading me to believe there
> may be some underlying hardware issue which I am looking into. In my case
> I'm seeing the transfer event response length with a short packet (13)
> saying it's 48 bytes (the size of the ARP packet) instead of 5K - 48 which
> is what it looks like the code expects.
> 
> I am in contact now with one of our hardware designers who can hopefully
> answer what's going on.
> 
> -Aaron
> 
> From: Bin Meng 
> 
> Sent: Wednesday, July 10, 2019 9:57 PM
> 
> To: Aaron Williams
> 
> Cc: u-boot@lists.denx.de
> 
> Subject: [EXT] Re: [U-Boot] [u-boot][xhci] Dealing with XHCI controllers
> with spurious success
> 
>  
> 
> 
> External Email
> 
> 
> 
> --
> 
> Hi Aaron,
> 
> On Thu, Jul 11, 2019 at 12:50 PM Aaron Williams  
wrote:
> > Hi All,
> > 
> > 
> > 
> > I'm running into a problem with the XHCI driver on our SOC where I am
> > getting spurious success TRBs after a short packet response. In this
> > particular case, the driver for a USB network controller has a receive
> > buffer that crosses a 64K boundary. This results
>  in two TRBs being created to handle this with the first TRB having the
> chain and ISP bits set and the second having the IOC and ISP bits set as
> expected in this case.
> > The network controller has a short response (as is expected) followed by a
> > success response event (which is also valid) for the second TRB.  The
> > U-Boot XHCI driver, however, does not handle this properly. The
> > xhci_bulk_tx function only looks at the first
>  response and does not dequeue the second success response. The problem is
> when the next transaction occurs it dequeues the success response from the
> previous transaction so the responses events no longer match the TRBs. At
> some point the network driver goes from receive to transmit and at this
> point the driver panics because the event is still a response from a
> previous receive event and not the transmit event causing the endpoints to
> mismatch. This only happens in the two TRB case due to the receive buffer
> crossing a 64K boundary. The short packet response points to the first TRB
> and the success points to the second TRB.
> > In the Linux driver I see the XHCI_SPURIOUS_SUCCESS flag is available. I'm
> > not certain if this applies to our hardware or not. In any case, this
> > could be solved in one of two ways. One way to solve this is to make sure
> > that any driver where a short response
>  is possible to not have the buffer cross a 64K boundary. The other (and
> correct) solution is to have the XHCI driver handle this case. If a short
> packet response is received and there are multiple TRBs involved, check if
> there is an additional success response that points to the last TRB.
> 
> > To me it seems valid that the two response events are received. The
> > specification only says that there will be one response if the TRB has
> > both the ISP and IOC bits set, but this is not the case. I came across
> > this commit in the Linux kernel which seems to
>  address this case:
> https://kernel.opensuse.org/cgit/kernel/commit/?id=ad808333d8201d53075a11bc8
> dd83b81f3d68f0b
> 
> 
> 
> 
> 
> Are you using an Intel SoC? From the commit you gave, it looks it only
> 
> applies to a specific Intel 

Re: [U-Boot] Should I create a new UCLASS for Bootstate or Add new Ops to UCLASS_BOOTCOUNT ??

[Philipp Tomsich]

Joel,

> On 10.09.2019, at 01:07, Simon Glass  wrote:
> 
> Hi Joel,
> 
> On Sat, 7 Sep 2019 at 18:34, Joel Peshkin  wrote:
>> 
>> 
>> Hi Simon,
>> 
>>   I need to create and upstream driver for a set of functions that manage 
>> volatile information that persist across reboots.   These are simple 
>> registers that survive reboot but get cleared on power-cycle.   The key 
>> operations we need to implement are ...
>> 
>> boot_state_set_alternate_image_once()
>>Called before rebooting  (from uboot proper or from Linux)... sets flags 
>> to cause the next reboot to select an alternate image
>> 
>> boot_state_getandclear_alternate_image()
>>Called during boot (during SPL or TPL if using dual-uboot images as we 
>> do).  Gets the status of the alternate_image flag and clears it.

Could you elaborate how these are used?
This sounds a lot like an A/B partition scheme, but I’d like to fully 
understand the use cases and what data is stored where before commenting in 
more detail.

>> In our implementation, we have registers that always clear on power-cycle, 
>> but survive the soft reboot.  Other implementations, where there is no such 
>> register, would still only use the alternate image once as long as the boot 
>> attempt reaches the getandclear_alternate_image() function, so drivers 
>> similar to those available in bootcount could easily handle the same 
>> function.
>> 
>>   Would you prefer that I create a new UCLASS or is it OK to extend the 
>> UCLASS_BOOTCOUNT operations and upstream the new operations, supported on a 
>> subset of the drivers that implement UCLASS_BOOTCOUNT ??
> 
> I think that adding new operations makes sense for now.
> 
> I've added a few other people for thoughts.
> 
> Regards,
> Simon

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

Re: [U-Boot] Should I create a new UCLASS for Bootstate or Add new Ops to UCLASS_BOOTCOUNT ??

[Simon Glass]

Hi Joel,

On Sat, 7 Sep 2019 at 18:34, Joel Peshkin  wrote:
>
>
> Hi Simon,
>
>I need to create and upstream driver for a set of functions that manage 
> volatile information that persist across reboots.   These are simple 
> registers that survive reboot but get cleared on power-cycle.   The key 
> operations we need to implement are ...
>
> boot_state_set_alternate_image_once()
> Called before rebooting  (from uboot proper or from Linux)... sets flags 
> to cause the next reboot to select an alternate image
>
> boot_state_getandclear_alternate_image()
> Called during boot (during SPL or TPL if using dual-uboot images as we 
> do).  Gets the status of the alternate_image flag and clears it.
>
> In our implementation, we have registers that always clear on power-cycle, 
> but survive the soft reboot.  Other implementations, where there is no such 
> register, would still only use the alternate image once as long as the boot 
> attempt reaches the getandclear_alternate_image() function, so drivers 
> similar to those available in bootcount could easily handle the same function.
>
>Would you prefer that I create a new UCLASS or is it OK to extend the 
> UCLASS_BOOTCOUNT operations and upstream the new operations, supported on a 
> subset of the drivers that implement UCLASS_BOOTCOUNT ??

I think that adding new operations makes sense for now.

I've added a few other people for thoughts.

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

Re: [U-Boot] Buffer overrun risk in UBI SPL for secure boot

[Joel Peshkin]

Hi Heiko,

Adding a size limit without breaking things turns out to be much more
difficult that it would seem.  So, instead of capping the size, we have
changed the memory map we are using for uboot.  It is probably worthwhile
for others using UBISPL in a secure boot nevironment to do the same.

   Traditionally, uboot SPL or TPL loads or relocates to an address near
the top of memory and then builds its stack downwards from the top of
memory.   That means that any address we use for a volume.load_address will
eventually step on something if the volume is large enough.   So, we move
everything down by a size that is sufficient for any image that UBISPL may
need to load (32M) and place the CONFIG_SPL_LOAD_FIT_ADDRESS  Above the
stack where it can grow without hitting anything until it causes an
exception.

   I'm not sure if there is anything else to be done for this situation
except to caution people implementing secure boot environments to be aware
of their surroundings.

Regards,

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

Re: [U-Boot] U-Boot: Environment flags broken for U-Boot

[Tom Rini]

On Wed, Sep 04, 2019 at 01:30:02PM -0500, Joe Hershberger wrote:
> On Wed, Sep 4, 2019 at 1:01 PM Tom Rini  wrote:
> >
> > On Tue, Sep 03, 2019 at 10:04:42AM +0200, Wolfgang Denk wrote:
> > > Dear Tom,
> > >
> > > In message  Heiko Schocher 
> > > wrote:
> > > >
> > > > I am just testing U-Boot Environment flags and they do not work anymore 
> > > > with
> > > > current mainline U-Boot ...
> > > ...
> > > > reason is your commit:
> > > >
> > > > commit 7d4776545b0f8a8827e5d061206faf61c9ba6ea9
> > > > Author: Patrick Delaunay 
> > > > Date:   Thu Apr 18 17:32:49 2019 +0200
> > > >
> > > >  env: solve compilation error in SPL
> > >
> > >
> > > Looking into the history of this, I wonder if we could / should
> > > have prevented this.
> >
> > Looking over my scripts, yes, I overlooked the problem.  The 'edison'
> > platform shows the same issue that Heiko's platform does but I
> > overlooked the size change.  I'm modifying my script currently so it
> > will show more details and this should jump out more rather than the
> > size noise of "changes in a general area".  Now interesting enough,
> > sandbox didn't blow up here but does also enable the env flags options.
> >
> > > As far as I can see, Patrick's patch series has not been reviewed by
> > > others, probably because general intetest in STM32 is not that big
> > > at the moment.  I can see no Acked-by:, Reviewed-by: nor Tested-by:
> > > tags - nothing.
> > >
> > > The whole patch series was then pulled from the u-boot-stm
> > > repository.
> > >
> > >
> > > However, there was not only STM related code in there.  There were
> > > changes to common code like the environment handling.  common code
> > > was changed without review and without testing.
> >
> > To be clear, it was tested, but sadly the environment flags code is not
> > heavily used / enabled.  More in a moment.
> >
> > > Are there ways to prevent this?
> > >
> > > Yes, we can appeal to the custodians to be more careful, but I
> > > assume they are already doing their best.
> > >
> > > It might have even been better if this had been a sub-system with a
> > > clear maintainer, but there is no such person for the environment
> > > code.
> > >
> > > How can we prevent this in the future?
> > >
> > > Should we define "interested developers" for such areas that have no
> > > custodian (the "Designated reviewer") entry in the MAINTAINERS file
> > > could be used for this, for example)?
> >
> > This, along with some other environment related patches were things I
> > was keeping an eye on to see if perhaps Joe would have had time to look
> > at before it went in (as the env flag stuff came from him).  I also try
> 
> I wasn't aware of it as I wasn't Cc'ed on this series. I generally
> don't have time to troll the list in general, which is a bit of a
> problem since I also missed the discussions on the UEFI env changes,
> some of which are already in, and are not how I would have implemented
> it. I only found out that it was in work from Grant Likely at his talk
> in San Diego.
> 
> > and make use of the "Needs Review / ACK" flag in patchwork for things
> > that stand out.  Looking over the merge contents again, that particular
> > one would not have.
> >
> > So, things that would help in the future:
> > - An explicit environment maintainer
> 
> I would gladly volunteer for this role if Wolfgang would co-maintain
> to keep me in line. He seems to have an uncanny ability to keep all
> the cases in his head.

Wolfgang, what do you say?  It's certainly an area we could use a
custodian in.

-- 
Tom


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

Re: [U-Boot] [PATCH] clk: sifive: Fix ethernet regression on HiFive Unleashed

[Marcus Comstedt]

Hi Bin,

Bin Meng  writes:

>> Yes, but in which Linux?  This whole thing started because U-Boot will
>
> The latest Linux kernel v5.3.

Thanks.  I'll try it later.  As if to prove my point, the one from
5.2.11 (which is the Linux version I'm currently running) did not work
(I got MMC but no ethernet)...


> I checked kernel 4.14 and found it did not ship the SiFive Unleased
> board DTS in the kernel tree. Are you sure it's 4.14?

It's the one shipped with the H5U, which I'm pretty sure ran Linux
4.14 at the time (as part of the "Freedom U SDK") since 4.15 was not
out yet.  It looks like SiFive never added the DTS to their own Linux
tree (https://github.com/sifive/riscv-linux).


> I don't think Linux is to be blamed for this case. They have a policy
> to maintain the the backward compatibility for the DT land. The issue
> what you were facing here is an out of tree DTB (the vendors') is
> incompatible with the kernel's. Once the kernel accepts a DTS,
> bringing in any out-of-tree DT with changes reviewed to in-tree,
> future compatibility will be assured.

Isn't the reason that the DTS accepted by the kernel is different from
the out-of-tree vendor one that the review process caused changes in
the DTS then?  It seems unlikely that the vendor (SiFive) would
deliberately submit an incompatible DTS for inclusion...


  // Marcus


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

[U-Boot] [PATCH v2 1/2] MTD: SPI: add missing SST26* flash IC protection ops

[Eugeniy Paltsev]

Commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
performs switch from previous 'spi_flash' infrastructure without
proper testing/investigations which results in a regressions for
SST26 flash series.

Add missing SST26* flash IC protection ops which were introduced
previously by
Commit 3d4fed87a5fa (mtd: sf: Add support of sst26wf* flash ICs
protection ops)

Signed-off-by: Eugeniy Paltsev 
---
 drivers/mtd/spi/sf_internal.h  |   1 +
 drivers/mtd/spi/spi-nor-core.c | 181 +
 include/linux/mtd/spi-nor.h|   4 +
 3 files changed, 186 insertions(+)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index a6bf734830a..e6da768bf36 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -65,6 +65,7 @@ struct flash_info {
 #define NO_CHIP_ERASE  BIT(12) /* Chip does not support chip erase */
 #define SPI_NOR_SKIP_SFDP  BIT(13) /* Skip parsing of SFDP tables */
 #define USE_CLSR   BIT(14) /* use CLSR command */
+#define SPI_NOR_HAS_SST26LOCK  BIT(15) /* Flash supports lock/unlock via BPR */
 };
 
 extern const struct flash_info spi_nor_ids[];
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 1acff745d1a..990e39d7c2f 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -945,6 +945,177 @@ read_err:
 }
 
 #ifdef CONFIG_SPI_FLASH_SST
+/*
+ * sst26 flash series has its own block protection implementation:
+ * 4x   - 8  KByte blocks - read & write protection bits - upper addresses
+ * 1x   - 32 KByte blocks - write protection bits
+ * rest - 64 KByte blocks - write protection bits
+ * 1x   - 32 KByte blocks - write protection bits
+ * 4x   - 8  KByte blocks - read & write protection bits - lower addresses
+ *
+ * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
+ * will be treated as single block.
+ */
+#define SST26_BPR_8K_NUM   4
+#define SST26_MAX_BPR_REG_LEN  (18 + 1)
+#define SST26_BOUND_REG_SIZE   ((32 + SST26_BPR_8K_NUM * 8) * SZ_1K)
+
+enum lock_ctl {
+   SST26_CTL_LOCK,
+   SST26_CTL_UNLOCK,
+   SST26_CTL_CHECK
+};
+
+static bool sst26_process_bpr(u32 bpr_size, u8 *cmd, u32 bit, enum lock_ctl 
ctl)
+{
+   switch (ctl) {
+   case SST26_CTL_LOCK:
+   cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
+   break;
+   case SST26_CTL_UNLOCK:
+   cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
+   break;
+   case SST26_CTL_CHECK:
+   return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 8));
+   }
+
+   return false;
+}
+
+/*
+ * Lock, unlock or check lock status of the flash region of the flash 
(depending
+ * on the lock_ctl value)
+ */
+static int sst26_lock_ctl(struct spi_nor *nor, loff_t ofs, uint64_t len, enum 
lock_ctl ctl)
+{
+   struct mtd_info *mtd = >mtd;
+   u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
+   bool lower_64k = false, upper_64k = false;
+   u8 bpr_buff[SST26_MAX_BPR_REG_LEN] = {};
+   int ret;
+
+   /* Check length and offset for 64k alignment */
+   if ((ofs & (SZ_64K - 1)) || (len & (SZ_64K - 1))) {
+   dev_err(nor->dev, "length or offset is not 64KiB allighned\n");
+   return -EINVAL;
+   }
+
+   if (ofs + len > mtd->size) {
+   dev_err(nor->dev, "range is more than device size: %#llx + 
%#llx > %#llx\n",
+   ofs, len, mtd->size);
+   return -EINVAL;
+   }
+
+   /* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
+   if (mtd->size != SZ_2M &&
+   mtd->size != SZ_4M &&
+   mtd->size != SZ_8M)
+   return -EINVAL;
+
+   bpr_size = 2 + (mtd->size / SZ_64K / 8);
+
+   ret = nor->read_reg(nor, SPINOR_OP_READ_BPR, bpr_buff, bpr_size);
+   if (ret < 0) {
+   dev_err(nor->dev, "fail to read block-protection register\n");
+   return ret;
+   }
+
+   rptr_64k = min_t(u32, ofs + len, mtd->size - SST26_BOUND_REG_SIZE);
+   lptr_64k = max_t(u32, ofs, SST26_BOUND_REG_SIZE);
+
+   upper_64k = ((ofs + len) > (mtd->size - SST26_BOUND_REG_SIZE));
+   lower_64k = (ofs < SST26_BOUND_REG_SIZE);
+
+   /* Lower bits in block-protection register are about 64k region */
+   bpr_ptr = lptr_64k / SZ_64K - 1;
+
+   /* Process 64K blocks region */
+   while (lptr_64k < rptr_64k) {
+   if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
+   return EACCES;
+
+   bpr_ptr++;
+   lptr_64k += SZ_64K;
+   }
+
+   /* 32K and 8K region bits in BPR are after 64k region bits */
+   bpr_ptr = (mtd->size - 2 * SST26_BOUND_REG_SIZE) / SZ_64K;
+
+   /* Process lower 32K block region */
+   if (lower_64k)
+   if (sst26_process_bpr(bpr_size, bpr_buff, bpr_ptr, ctl))
+   return 

[U-Boot] [PATCH v2 2/2] MTD: SPI: enable protection ops for SST26 flash series

[Eugeniy Paltsev]

Commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
performs switch from previous 'spi_flash' infrastructure without
proper testing/investigations which results in a regressions for
SST26 flash series.

Enable protection ops for SST26 flash series which were
previously enabled by
Commit 3d4fed87a5fa (mtd: sf: Add support of sst26wf* flash ICs
protection ops)

Signed-off-by: Eugeniy Paltsev 
---
 drivers/mtd/spi/spi-nor-ids.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index a3920ba520e..6996c0a2864 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -214,10 +214,10 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("sst25wf040b", 0x621613, 0, 64 * 1024,  8, SECT_4K) },
{ INFO("sst25wf040",  0xbf2504, 0, 64 * 1024,  8, SECT_4K | SST_WRITE) 
},
{ INFO("sst25wf080",  0xbf2505, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) 
},
-   { INFO("sst26vf064b", 0xbf2643, 0, 64 * 1024, 128, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
-   { INFO("sst26wf016",  0xbf2651, 0, 64 * 1024,  32, SECT_4K) },
-   { INFO("sst26wf032",  0xbf2622, 0, 64 * 1024,  64, SECT_4K) },
-   { INFO("sst26wf064",  0xbf2643, 0, 64 * 1024, 128, SECT_4K) },
+   { INFO("sst26vf064b", 0xbf2643, 0, 64 * 1024, 128, SECT_4K | 
SPI_NOR_HAS_SST26LOCK | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+   { INFO("sst26wf016",  0xbf2651, 0, 64 * 1024,  32, SECT_4K | 
SPI_NOR_HAS_SST26LOCK) },
+   { INFO("sst26wf032",  0xbf2622, 0, 64 * 1024,  64, SECT_4K | 
SPI_NOR_HAS_SST26LOCK) },
+   { INFO("sst26wf064",  0xbf2643, 0, 64 * 1024, 128, SECT_4K | 
SPI_NOR_HAS_SST26LOCK) },
 #endif
 #ifdef CONFIG_SPI_FLASH_STMICRO/* STMICRO */
/* ST Microelectronics -- newer production may have feature updates */
-- 
2.21.0

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

Re: [U-Boot] [PATCH 1/1] MTD: SPI: revert removing SST26* flash IC protection ops

[Eugeniy Paltsev]

>On Wed, Sep 4, 2019 at 11:37 PM Eugeniy Paltsev
> wrote:
>>
>> Commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
>> performs switch from previous 'spi_flash' infrastructure without
>> proper testing/investigations which results in regressions.
>>
>> Fix regression related to SST26 flash IC series which is lacking
>> protection ops implementation which were introduced previously by
>> Commit 3d4fed87a5fa (mtd: sf: Add support of sst26wf* flash ICs
>> protection ops)
>>
>> Signed-off-by: Eugeniy Paltsev 
>> ---
>> Tom, could you please pick this patch to 2019.10?
>>
[snip]
>> +   { INFO("sst26wf032",  0xbf2622, 0, 64 * 1024,  64, SECT_4K | 
>> SPI_NOR_HAS_SST26LOCK) },
>> +   { INFO("sst26wf064",  0xbf2643, 0, 64 * 1024, 128, SECT_4K | 
>> SPI_NOR_HAS_SST26LOCK) },
>
>Thought the commit message says it is revert, the patch contents seems
>adding new changes.

Revert of removing functionality is adding functionality, isn't it? ;)

> So, better add them by saying missing
>functionalities. If possible please break the patches into multiple
>patches.

Ok, I'll split this patch for adding SST26 protection ops part and 
applying this ops to corresponding flash ICs.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] usb: xhci-dwc3: Add support for dis_u2_susphy_quirk

[Neil Armstrong]

This quirk is necessary for the Amlogic GXL SoCs otherwise the
Port 2 PHY doesn't get out of suspend and U-Boot resets the board after:

XHCI timeout on event type 33... cannot recover.
BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()!
BUG!

This quirk is also handled in the dwc3 core code, but until the
xhci-dwc3 driver uses the dwc3 core, the quirk must be handled here
to fix USB support on the Amlogic libretech-cc and libretech-ac board
when a device is only plugged in the OTG port.

Cc: Yuri Frolov 
Cc: Bin Meng 
Fixes: dc9cdf859e ("usb: dwc3: Add DWC3 controller driver support")
Signed-off-by: Neil Armstrong 
---
 drivers/usb/host/xhci-dwc3.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index 9e8cae7ae4..55a1b22cf6 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -150,6 +150,9 @@ static int xhci_dwc3_probe(struct udevice *dev)
if (dev_read_bool(dev, "snps,dis-u2-freeclk-exists-quirk"))
reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;
 
+   if (dev_read_bool(dev, "snps,dis_u2_susphy_quirk"))
+   reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
+
writel(reg, _reg->g_usb2phycfg[0]);
 
dr_mode = usb_get_dr_mode(dev_of_offset(dev));
-- 
2.17.1

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

Re: [U-Boot] Regressions in MTD / SPI FLASH

[Eugeniy Paltsev]

Hi!
Comments are inlined:

>On 04/09/19 11:37 PM, Eugeniy Paltsev wrote:
>> We faced with regressions caused by
>> commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
>> This switch was performed by removing entire u-boot spi-flash
>> core implementation and copying it from another project.
>> However the switch is performed without proper testing and
>> investigations about fixes/improvements were made in u-boot
>> spi-flash core. This results in regressions.
>>
>
>Apologies for the trouble...
>As stated in cover letter, this change was necessary as U-Boot SPI flash
>stack at that time did not features such as 4 byte addressing, SFDP
>parsing, SPI controllers with MMIO interfaces etc. Also there was need
>to move to SPI MEM framework to support both SPI NAND and SPI NOR
>flashes using a single SPI controller drivers.
>I have to disagree on the part that there was no proper testing... As
>evident from mailing list archives, patch series was reviewed by
>multiple reviewers and tested on their platforms as well...
>Unfortunately its impossible to get all boards owners to test it.

I'm not talking about getting all customers board and testing changes on them.
It could be done another way - i.e. like it is done for u-boot driver-model 
migration:
by introducing the option for choosing which stack will be used and allow 
customers
to switch the flash IC they use to new stack until some deadline.

>> One of regression we faced with is related to SST26 flash series which
>> is used on HSDK board. The cause is that SST26 protection ops
>> implementation was dropped. The fix of this regression is send
>> as a patch in this series.
>>
>
>I retained most U-Boot specific code as is (like support for BANK
>address registers, restriction in transfer sizes) but I somehow
>overlooked this part. Sorry for that
>
>> However there are another regressions. I.E: we also faced with broken
>> SPI flash on another SNPS boards - AXS101 and AXS103. They use different
>> flash IC (n25q512ax3) and I didn't investigate the cause yet.
>>
>
>Could you provide more details here:
>What exactly fails? Is the detected correctly? Does reads work fine? Is
>Erase or Write broken?

It seems to me that something is wrong with protection ops.
The erase and write finish without errors however nothing actually happens.

>Could you enable debug prints in your driver as well as debug prints in
>spi_mem_exec_op() (in drivers/spi/spi-mem.c) and post the logs?


Here is it.
As you can see all commands finish successfully however erase and write don't
change flash content.
->8-
AXS# sf probe && echo OK
spi_flash_std_probe: slave=9fdabfc0, cs=0
9f | [6B in] 20 ba 20 10 00 00 [ret 0]
SF: Detected n25q512ax3 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
OK
AXS# sf read 0x8100 0x18 0x10 && echo OK
device 0 offset 0x18, size 0x10
0c 00 18 00 00 | [16B in] 53 00 f8 d9 04 00 52 fc ff ff 80 de ad be af af [ret 
0]
SF: 16 bytes @ 0x18 Read: OK
OK
AXS# md.b 0x8100 0x10
8100: 53 00 f8 d9 04 00 52 fc ff ff 80 de ad be af afS.R.
AXS# sf protect unlock 0x0 0x400 && echo OK
05 | [1B in] 00 [ret 0]
OK
AXS# sf erase 0x18 0x1000 && echo OK
06 | [0B -] [ret 0]
21 00 18 00 00 | [0B -] [ret 0]
05 | [1B in] 02 [ret 0]
70 | [1B in] 80 [ret 0]
04 | [0B -] [ret 0]
SF: 4096 bytes @ 0x18 Erased: OK
OK
AXS# sf read 0x8100 0x18 0x10 && echo OK
device 0 offset 0x18, size 0x10
0c 00 18 00 00 | [16B in] 53 00 f8 d9 04 00 52 fc ff ff 80 de ad be af af [ret 
0]
SF: 16 bytes @ 0x18 Read: OK
OK
AXS# md.b 0x8100 0x10
8100: 53 00 f8 d9 04 00 52 fc ff ff 80 de ad be af afS.R.
AXS# mw 0x8100 0 5
AXS# sf write 0x8100 0x18 0x10 && echo OK
device 0 offset 0x18, size 0x10
06 | [0B -] [ret 0]
12 00 18 00 00 | [16B out] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ret 
0]
05 | [1B in] 00 [ret 0]
70 | [1B in] 80 [ret 0]
SF: 16 bytes @ 0x18 Written: OK
OK
AXS# sf read 0x8100 0x18 0x10 && echo OK
device 0 offset 0x18, size 0x10
0c 00 18 00 00 | [16B in] 53 00 f8 d9 04 00 52 fc ff ff 80 de ad be af af [ret 
0]
SF: 16 bytes @ 0x18 Read: OK
OK
AXS# md.b 0x8100 0x10
8100: 53 00 f8 d9 04 00 52 fc ff ff 80 de ad be af afS.R.
->8-


Here is how it should work (tested on v2018.09):
->8-
AXS# sf probe && echo OK
SF: Detected n25q512 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
OK
AXS# sf read 0x8100 0x18 0x10 && echo OK
device 0 offset 0x18, size 0x10
SF: 16 bytes @ 0x18 Read: OK
OK
AXS# md.b 0x8100 0x10
8100: 53 00 f8 d9 04 00 52 fc ff ff 80 de ad be af afS.R.
AXS# sf protect unlock 0x0 0x400 && echo OK
AXS#
AXS# sf erase 0x18 0x1000 && echo OK
SF: 

[U-Boot] [PATCHv1 5/5] arm: socfpga: enable RSU build

[richard . gong]

From: Richard Gong 

Add build support for RSU.

Signed-off-by: Richard Gong 
---
 arch/arm/mach-socfpga/Makefile | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index fc1181c..17ec0bf 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -33,6 +33,12 @@ obj-y+= mailbox_s10.o
 obj-y  += misc_s10.o
 obj-y  += mmu-arm64_s10.o
 obj-y  += reset_manager_s10.o
+ifndef CONFIG_SPL_BUILD
+obj-y   += rsu.o
+obj-y   += rsu_ll_qspi.o
+obj-y   += rsu_misc.o
+obj-y   += rsu_s10.o
+endif
 obj-y  += system_manager_s10.o
 obj-y  += timer_s10.o
 obj-y  += wrap_pinmux_config_s10.o
-- 
2.7.4

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

[U-Boot] [PATCHv1 4/5] arm: socfpga: stratix10: add console commands for RSU support

[richard . gong]

From: Richard Gong 

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

This patch provides console commands to exercises the RSU APIs at
Intel Stratix10 SoC. The commands use the term "slot" to refer to a
sub-partition which is intended to contain a production image, and the
term "priority" to refer to the fact that the images are loaded by
firmware in the defined order.

The provided console commands are below, you can also refer to the
header file rsu.h for the details of RSU APIs:
slot_count
slot_by_name
slot_get_info
slot_size
slot_priority
slot_erase
slot_program_buf
slot_program_buf_raw
slot_verify_buf
slot_verify_buf_raw
slot_enable
slot_disable
slot_load
slot_load_factory
slot_rename
status_log
list
dtb
update
notify
clear_error_status
reset_retry_counter

Signed-off-by: Richard Gong 
Signed-off-by: Radu Bacrau 
Signed-off-by: Chin Liang See 
---
 arch/arm/mach-socfpga/include/mach/rsu_s10.h |  46 ++
 arch/arm/mach-socfpga/rsu_s10.c  | 817 +++
 2 files changed, 863 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/include/mach/rsu_s10.h
 create mode 100644 arch/arm/mach-socfpga/rsu_s10.c

diff --git a/arch/arm/mach-socfpga/include/mach/rsu_s10.h 
b/arch/arm/mach-socfpga/include/mach/rsu_s10.h
new file mode 100644
index 000..9a4ec53
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/rsu_s10.h
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Intel Corporation
+ *
+ */
+#ifndef _RSU_S10_H_
+#define _RSU_S10_H_
+
+extern u32 smc_rsu_update_address;
+
+#define RSU_S10_CPB_MAGIC_NUMBER   0x57789609
+#define RSU_S10_SPT_MAGIC_NUMBER   0x57713427
+
+#define SPT0_INDEX 1
+#define SPT1_INDEX 3
+
+/* CMF pointer block */
+struct socfpga_rsu_s10_cpb {
+   u32 magic_number;
+   u32 header_size;
+   u32 total_size;
+   u32 reserved1;
+   u32 iptab_offset;
+   u32 nslots;
+   u32 reserved2;
+   u64 pointer_slot[508];
+};
+
+/* sub partition slot */
+struct socfpga_rsu_s10_spt_slot {
+   char name[16];
+   u32 offset[2];
+   u32 length;
+   u32 flag;
+};
+
+/* sub partition table */
+struct socfpga_rsu_s10_spt {
+   u32 magic_number;
+   u32 version;
+   u32 entries;
+   u32 reserved[5];
+   struct socfpga_rsu_s10_spt_slot spt_slot[127];
+};
+
+#endif /* _RSU_S10_H_ */
diff --git a/arch/arm/mach-socfpga/rsu_s10.c b/arch/arm/mach-socfpga/rsu_s10.c
new file mode 100644
index 000..8127e08
--- /dev/null
+++ b/arch/arm/mach-socfpga/rsu_s10.c
@@ -0,0 +1,817 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2019 Intel Corporation
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct socfpga_rsu_s10_cpb rsu_cpb = {0};
+struct socfpga_rsu_s10_spt rsu_spt = {0};
+u32 rsu_spt0_offset = 0, rsu_spt1_offset = 0;
+
+static int initialized;
+
+static int rsu_print_status(void)
+{
+   struct rsu_status_info status_info;
+
+   if (mbox_rsu_status((u32 *)_info, sizeof(status_info))) {
+   puts("RSU: Firmware or flash content not supporting RSU\n");
+   return -ENOTSUPP;
+   }
+   puts("RSU: Remote System Update Status\n");
+   printf("Current Image\t: 0x%08llx\n", status_info.current_image);
+   printf("Last Fail Image\t: 0x%08llx\n", status_info.fail_image);
+   printf("State\t\t: 0x%08x\n", status_info.state);
+   printf("Version\t\t: 0x%08x\n", status_info.version);
+   printf("Error location\t: 0x%08x\n", status_info.error_location);
+   printf("Error details\t: 0x%08x\n", status_info.error_details);
+   if (status_info.version)
+   printf("Retry counter\t: 0x%08x\n", status_info.retry_counter);
+
+   return 0;
+}
+
+static void rsu_print_spt_slot(void)
+{
+   int i;
+
+   puts("RSU: Sub-partition table content\n");
+   for (i = 0; i < rsu_spt.entries; i++) {
+   printf("%16s\tOffset:0x%08x%08x\tLength:0x%08x\tFlag:0x%08x\n",
+  rsu_spt.spt_slot[i].name,
+  rsu_spt.spt_slot[i].offset[1],
+  rsu_spt.spt_slot[i].offset[0],
+  rsu_spt.spt_slot[i].length,
+  rsu_spt.spt_slot[i].flag);
+   }
+}
+
+static void rsu_print_cpb_slot(void)
+{
+   int i, j = 1;
+
+   puts("RSU: CMF pointer block's image pointer list\n");
+   for (i = rsu_cpb.nslots - 1; i >= 0; i--) {
+   if (rsu_cpb.pointer_slot[i] != ~0 &&
+   rsu_cpb.pointer_slot[i] != 0) {
+   printf("Priority %d 

[U-Boot] [PATCHv1 3/5] arm: socfpga: stratix10: add environment variables for RSU support

[richard . gong]

From: Richard Gong 

Add two RSU environment variables:
1. rsu_log_level
the variable is unsigned integer and its default value is
RSU_DEBUG (7), which only show log with RSU_INFO,RSU_WARNING and
RSU_ERR.

To enable all logs (RSU_ERR, RSU_WARNING, RSU_INFO and RSU_DEBUG),
you need set log level to 8 or above via “setenv rsu_log_level 8”.

To disable all logs, you need set log level to 3 or below.

2. rsu_protected_slot
by default there is no protected RSU slot, you need run
"setenv rsu_protected_slot ” to set a slot protected,
and “setenv rsu_protected_slot ” to unset a protected
slot.

Signed-off-by: Richard Gong 
---
 arch/arm/mach-socfpga/misc_s10.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index 0a5fab1..c9a6f00 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -21,6 +21,8 @@
 
 #include 
 
+#define RSU_DEFAULT_LOG_LEVEL  7
+
 DECLARE_GLOBAL_DATA_PTR;
 
 static struct socfpga_system_manager *sysmgr_regs =
@@ -136,10 +138,17 @@ int print_cpuinfo(void)
 int arch_misc_init(void)
 {
char qspi_string[13];
+   char level[4];
+
+   snprintf(level, sizeof(level), "%u", RSU_DEFAULT_LOG_LEVEL);
 
sprintf(qspi_string, "<0x%08x>", cm_get_qspi_controller_clk_hz());
env_set("qspi_clock", qspi_string);
 
+   /* setup for RSU */
+   env_set("rsu_protected_slot", "");
+   env_set("rsu_log_level", level);
+
socfpga_set_phymode();
return 0;
 }
-- 
2.7.4

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

[U-Boot] [PATCHv1 2/5] arm: socfpga: stratix10: add RSU support for Stratix10 SoC

[richard . gong]

From: Richard Gong 

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

This patch adds RSU support which allows user to perform a complete set
of RSU operations:
1. Provides support for creating the initial flash images for a
   system to support RSU.
2. Allows several production images to be tried in a specific
   order until one of them is successful.
3. Loads a factory image if no production image is available, or
   all production images failed.
4. Provides users with the ability to add and remove production
   images.
5. Provides user with the ability to change the order in which
   production images are loaded.
6. Provides user with the ability to load a specific image from
   flash. The image is a production or factory image.
7. Provides user with information on which image is currently
   running, and what errors were encountered by RSU.

Signed-off-by: Richard Gong 
---
 arch/arm/mach-socfpga/include/mach/rsu.h  |  244 ++
 arch/arm/mach-socfpga/include/mach/rsu_ll.h   |   71 ++
 arch/arm/mach-socfpga/include/mach/rsu_misc.h |   46 ++
 arch/arm/mach-socfpga/rsu.c   |  569 ++
 arch/arm/mach-socfpga/rsu_ll_qspi.c   | 1033 +
 arch/arm/mach-socfpga/rsu_misc.c  |  527 +
 6 files changed, 2490 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/include/mach/rsu.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/rsu_ll.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/rsu_misc.h
 create mode 100644 arch/arm/mach-socfpga/rsu.c
 create mode 100644 arch/arm/mach-socfpga/rsu_ll_qspi.c
 create mode 100644 arch/arm/mach-socfpga/rsu_misc.c

diff --git a/arch/arm/mach-socfpga/include/mach/rsu.h 
b/arch/arm/mach-socfpga/include/mach/rsu.h
new file mode 100644
index 000..3b1868a
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/rsu.h
@@ -0,0 +1,244 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Intel Corporation
+ *
+ */
+
+#ifndef __RSU_H__
+#define __RSU_H__
+
+#include 
+
+/* RSU Error Codes */
+#define EINTF  1
+#define ECFG   2
+#define ESLOTNUM   3
+#define EFORMAT4
+#define EERASE 5
+#define EPROGRAM   6
+#define ECMP   7
+#define ESIZE  8
+#define ENAME  9
+#define EFILEIO10
+#define ECALLBACK  11
+#define ELOWLEVEL  12
+#define EWRPROT13
+#define EARGS  14
+
+/* RSU Notify Bitmasks */
+#define RSU_NOTIFY_IGNORE_STAGE BIT(18)
+#define RSU_NOTIFY_CLEAR_ERROR_STATUS   BIT(17)
+#define RSU_NOTIFY_RESET_RETRY_COUNTER  BIT(16)
+
+/**
+ * struct rsu_status_info - firmware status log info structure
+ * @current_image:address of image currently running in flash
+ * @fail_image: address of failed image in flash
+ * @state: the state of RSU system
+ * @version: the version number of RSU firmware
+ * @error_location: the error offset inside the failed image
+ * @error_details: error code
+ * @retry_counter: current image retry counter
+ *
+ * This structure is used to capture firmware status log information
+ */
+struct rsu_status_info {
+   u64 current_image;
+   u64 fail_image;
+   u32 state;
+   u32 version;
+   u32 error_location;
+   u32 error_details;
+   u32 retry_counter;
+};
+
+/**
+ * struct rsu_slot_info - slot information structure
+ * @name: a slot name
+ * @offset: a slot offset
+ * @size: the size of a slot
+ * @priority: the priority of a slot
+ *
+ * This structure is used to capture the slot information details
+ */
+struct rsu_slot_info {
+   char name[16];
+   u64 offset;
+   u32 size;
+   int priority;
+};
+
+/**
+ * rsu_init() - initialize flash driver, SPT and CPB data
+ * @filename: NULL for qspi
+ *
+ * Returns: 0 on success, or error code
+ */
+int rsu_init(char *filename);
+
+/**
+ * rsu_exit() - free flash driver, clean SPT and CPB data
+ */
+void rsu_exit(void);
+
+/**
+ * rsu_slot_count() - get the number of slots defined
+ *
+ * Returns: the number of defined slots
+ */
+int rsu_slot_count(void);
+
+/**
+ * rsu_slot_by_name() - get slot number based on name
+ * @name: name of slot
+ *
+ * Return:slot number on success, or error code
+ */
+int rsu_slot_by_name(char *name);
+
+/**
+ * rsu_slot_get_info() - get the attributes of a slot
+ * @slot: slot number
+ * @info: pointer to info structure to be filled in
+ *
+ * Returns: 0 on success, or error code
+ */
+int rsu_slot_get_info(int slot, struct rsu_slot_info *info);
+
+/**
+ * rsu_slot_size() - get the size of a slot
+ * @slot: slot number
+ *
+ * Returns: the size of the slot in bytes, or error code
+ */
+int rsu_slot_size(int slot);
+

[U-Boot] [PATCHv1 1/5] arm: socfpga: stratix10: add RSU mailbox support

[richard . gong]

From: Richard Gong 

Add Remote System Update (RSU) related mailbox support. This includes
RSU_STATUS which reports status of bitstream loaded by Configuration
Management Firmware (CMF), RSU_UPDATE which will invokes CMF to load new
bitstream, GET_SUBPARTITION_TABLE which will query CMF on the start
address of sub-partition table, HPS_STAGE_NOTIFY which notifies firmware
the stage of HPS code execution and related functions to support Secure
Monitor Call (SMC).

Signed-off-by: Richard Gong 
Signed-off-by: Radu Bacrau 
Signed-off-by: Ley Foon Tan 
Signed-off-by: Chin Liang See 
---
 arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 36 +--
 arch/arm/mach-socfpga/mailbox_s10.c  | 45 
 2 files changed, 71 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h 
b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
index ae728a5..979fd06 100644
--- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
@@ -77,16 +77,20 @@ enum ALT_SDM_MBOX_RESP_CODE {
 };
 
 /* Mailbox command list */
-#define MBOX_RESTART   2
-#define MBOX_CONFIG_STATUS 4
-#define MBOX_RECONFIG  6
-#define MBOX_RECONFIG_MSEL 7
-#define MBOX_RECONFIG_DATA 8
-#define MBOX_RECONFIG_STATUS   9
-#define MBOX_QSPI_OPEN 50
-#define MBOX_QSPI_CLOSE51
-#define MBOX_QSPI_DIRECT   59
-#define MBOX_REBOOT_HPS71
+#define MBOX_RESTART   2
+#define MBOX_CONFIG_STATUS 4
+#define MBOX_RECONFIG  6
+#define MBOX_RECONFIG_MSEL 7
+#define MBOX_RECONFIG_DATA 8
+#define MBOX_RECONFIG_STATUS   9
+#define MBOX_QSPI_OPEN 50
+#define MBOX_QSPI_CLOSE51
+#define MBOX_QSPI_DIRECT   59
+#define MBOX_REBOOT_HPS71
+#define MBOX_GET_SUBPARTITION_TABLE90
+#define MBOX_RSU_STATUS91
+#define MBOX_RSU_UPDATE92
+#define MBOX_HPS_STAGE_NOTIFY  93
 
 /* Mailbox registers */
 #define MBOX_CIN   0   /* command valid offset */
@@ -130,6 +134,11 @@ enum ALT_SDM_MBOX_RESP_CODE {
 #define RCF_SOFTFUNC_STATUS_SEU_ERROR  BIT(3)
 #define RCF_PIN_STATUS_NSTATUS BIT(31)
 
+/* Defines for HPS_STAGE_NOTIFY */
+#define HPS_EXECUTION_STATE_FSBL   0
+#define HPS_EXECUTION_STATE_SSBL   1
+#define HPS_EXECUTION_STATE_OS 2
+
 int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg, u8 urgent,
  u32 *resp_buf_len, u32 *resp_buf);
 int mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
@@ -146,6 +155,13 @@ int mbox_qspi_open(void);
 #endif
 
 int mbox_reset_cold(void);
+int mbox_rsu_get_spt_offset(u32 *resp_buf, u32 resp_buf_len);
+int mbox_rsu_status(u32 *resp_buf, u32 resp_buf_len);
+int mbox_rsu_status_psci(u32 *resp_buf, u32 resp_buf_len);
+int mbox_rsu_update(u32 *flash_offset);
+int mbox_rsu_update_psci(u32 *flash_offset);
+int mbox_hps_stage_notify(u32 execution_stage);
+int mbox_hps_stage_notify_psci(u32 execution_stage);
 int mbox_get_fpga_config_status(u32 cmd);
 int mbox_get_fpga_config_status_psci(u32 cmd);
 #endif /* _MAILBOX_S10_H_ */
diff --git a/arch/arm/mach-socfpga/mailbox_s10.c 
b/arch/arm/mach-socfpga/mailbox_s10.c
index 4498ab5..6774390 100644
--- a/arch/arm/mach-socfpga/mailbox_s10.c
+++ b/arch/arm/mach-socfpga/mailbox_s10.c
@@ -342,6 +342,39 @@ int mbox_reset_cold(void)
return 0;
 }
 
+int mbox_rsu_get_spt_offset(u32 *resp_buf, u32 resp_buf_len)
+{
+   return mbox_send_cmd(MBOX_ID_UBOOT, MBOX_GET_SUBPARTITION_TABLE,
+MBOX_CMD_DIRECT, 0, NULL, 0, (u32 *)_buf_len,
+(u32 *)resp_buf);
+}
+
+int mbox_rsu_status(u32 *resp_buf, u32 resp_buf_len)
+{
+   return mbox_send_cmd(MBOX_ID_UBOOT, MBOX_RSU_STATUS, MBOX_CMD_DIRECT, 0,
+NULL, 0, (u32 *)_buf_len, (u32 *)resp_buf);
+}
+
+int __secure mbox_rsu_status_psci(u32 *resp_buf, u32 resp_buf_len)
+{
+   return mbox_send_cmd_psci(MBOX_ID_UBOOT, MBOX_RSU_STATUS,
+ MBOX_CMD_DIRECT, 0, NULL, 0,
+ (u32 *)_buf_len, (u32 *)resp_buf);
+}
+
+int mbox_rsu_update(u32 *flash_offset)
+{
+   return mbox_send_cmd(MBOX_ID_UBOOT, MBOX_RSU_UPDATE, MBOX_CMD_DIRECT, 2,
+(u32 *)flash_offset, 0, 0, NULL);
+}
+
+int __secure mbox_rsu_update_psci(u32 *flash_offset)
+{
+   return mbox_send_cmd_psci(MBOX_ID_UBOOT, MBOX_RSU_UPDATE,
+ MBOX_CMD_DIRECT, 2, (u32 *)flash_offset,
+ 0, 0, NULL);
+}
+
 /* Accepted commands: CONFIG_STATUS or RECONFIG_STATUS */
 static __always_inline int mbox_get_fpga_config_status_common(u32 cmd)
 {
@@ -380,6 +413,12 @@ static __always_inline 

[U-Boot] [PATCHv1 0/5] support remote system update on Intel Stratix10 SoC

[richard . gong]

From: Richard Gong 

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

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

The patches have reviewed by other colleagues at Intel.

Richard Gong (5):
  arm: socfpga: stratix10: add RSU mailbox support
  arm: socfpga: stratix10: add RSU support for Stratix10 SoC
  arm: socfpga: stratix10: add environment variables for RSU support
  arm: socfpga: stratix10: add console commands for RSU support
  arm: socfpga: enable RSU build

 arch/arm/mach-socfpga/Makefile   |6 +
 arch/arm/mach-socfpga/include/mach/mailbox_s10.h |   36 +-
 arch/arm/mach-socfpga/include/mach/rsu.h |  244 +
 arch/arm/mach-socfpga/include/mach/rsu_ll.h  |   71 ++
 arch/arm/mach-socfpga/include/mach/rsu_misc.h|   46 +
 arch/arm/mach-socfpga/include/mach/rsu_s10.h |   46 +
 arch/arm/mach-socfpga/mailbox_s10.c  |   45 +
 arch/arm/mach-socfpga/misc_s10.c |9 +
 arch/arm/mach-socfpga/rsu.c  |  569 
 arch/arm/mach-socfpga/rsu_ll_qspi.c  | 1033 ++
 arch/arm/mach-socfpga/rsu_misc.c |  527 +++
 arch/arm/mach-socfpga/rsu_s10.c  |  817 +
 12 files changed, 3439 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/rsu.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/rsu_ll.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/rsu_misc.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/rsu_s10.h
 create mode 100644 arch/arm/mach-socfpga/rsu.c
 create mode 100644 arch/arm/mach-socfpga/rsu_ll_qspi.c
 create mode 100644 arch/arm/mach-socfpga/rsu_misc.c
 create mode 100644 arch/arm/mach-socfpga/rsu_s10.c

-- 
2.7.4

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

Re: [U-Boot] [RFC][PATCH] bootcount: add support to customize bootcount variable name

[Philippe REYNES]

Hi Wolfgang,

> Dear Philippe,
> 
> In message <1568037413-28155-1-git-send-email-philippe.rey...@softathome.com>
> you wrote:
>> This commit add an option to customize the bootcount variable
>> name in the u-boot environment. To stay compatible with old config,
>> the default name is bootcount.
> 
> Which exact problem are you trying to fix with this commit?

I have severals layers in my boot chain, and I want to use bootcount
in severals layers to manage boot issues. If severals layers use the
same variable name (bootcount) and a boot issue happen, I can't find
the layer that fails.

So I propose to "customize" the bootcount variable name.

> I mean, we have a ton of variable names with fixed meaning, which
> have been in use for nearly 2 decades - bootcmd, bootargs,
> bootcount, ...
> 
> What is wrong with the "boootcount" name?

As it is "unique", I can't chain severals bootcount.
That's why I propose an option to customize the bootcount name variable.

I know that it's a "corner case" and that you could prefer to avoid
adding another option, that's why I've proposed this option as a RFC.

> Best regards,
> 
> Wolfgang Denk

Best regards,
Philippe Reynes
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: ti: Add missing "=" from previous fix

[Tom Rini]

On Mon, Sep 09, 2019 at 10:57:24AM -0400, Tom Rini wrote:

> While the original patch to fix a regression in distro boot for mmc on
> these platforms had the correct syntax, I broke the change while
> applying.  Add back in the missing "=" here so that the syntax is
> correct.
> 
> Reported-by: Andre Heider 
> Fixes: 27e0f3bcf075 ("arm: ti: Fix regression in distro boot for mmc")
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PULL] u-boot-mmc mmc-9-6-2019

[Tom Rini]

On Mon, Sep 09, 2019 at 01:12:16AM +, Peng Fan wrote:

> Hi Tom,
> 
> Please pull u-boot-mmc tag mmc-9-6-2019.
> 
> 
> Bug fixes to mmc_spi
> Add Aspeed SD driver
> Fix dw_mmc timeout calculation
> Fix timeout values passed to mmc_wait_dat0
> sdhci dt caps/mask update
> 
> 
> CI: https://travis-ci.org/MrVan/u-boot/builds/581484942
> Note: there is a failure in this build that MAINTAINER check failed,
> Because there is a patch in this pull request touched aspeed defconfig
> but there is no MAINTAINER for this file.

This is a case where looking at the test itself can be useful.  What was
failing is checking that tools/genboardcfg.py has no output.  Running it
manually shows that it was complaining that a value in the aspeed
defconfig changed while parsing everything as CONFIG_MMC went from 'n'
to 'y'.  I've fixed this up as it's clearly intended to be 'y' now.

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH v2] rpi4: enable dram bank initialization

[matthias . bgg]

From: Matthias Brugger 

When booting through the efi stub, the memory map get's created by
reading the dram bank information. Depending on the version of the RPi4
this information changes. Read the device tree to initialize the dram
bank data structure. This way the kernel is able to access the whole
range of available memory.

Signed-off-by: Matthias Brugger 
---
This patch is based on basic RPi4 support implemented by series:
https://www.mail-archive.com/u-boot@lists.denx.de/msg335667.html
which is part of v2019.10-rc4

To actually work correctly we need the series that fixes the libftd:
https://patchwork.ozlabs.org/cover/1158304/

Changes in v2:
- don't call dram_init_banksize if OF_BOARD is not used

 board/raspberrypi/rpi/rpi.c | 10 ++
 configs/rpi_4_defconfig |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index fa57d50c95..9e0abdda31 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -312,6 +312,16 @@ int dram_init(void)
return 0;
 }
 
+#ifdef CONFIG_OF_BOARD
+#ifdef CONFIG_BCM2711
+int dram_init_banksize(void)
+{
+   return fdtdec_decode_ram_size(gd->fdt_blob, NULL, 0, NULL,
+(phys_size_t *)>ram_size, gd->bd);
+}
+#endif
+#endif
+
 static void set_fdtfile(void)
 {
const char *fdtfile;
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index da8c960a2a..c639ac93de 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x0008
 CONFIG_TARGET_RPI_4=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_NR_DRAM_BANKS=1
+CONFIG_NR_DRAM_BANKS=2
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
 CONFIG_OF_BOARD=y
 CONFIG_OF_BOARD_SETUP=y
-- 
2.22.0

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

Re: [U-Boot] [RFC][PATCH] bootcount: add support to customize bootcount variable name

[Wolfgang Denk]

Dear Philippe,

In message <1568037413-28155-1-git-send-email-philippe.rey...@softathome.com> 
you wrote:
> This commit add an option to customize the bootcount variable
> name in the u-boot environment. To stay compatible with old config,
> the default name is bootcount.

Which exact problem are you trying to fix with this commit?

I mean, we have a ton of variable names with fixed meaning, which
have been in use for nearly 2 decades - bootcmd, bootargs,
bootcount, ...

What is wrong with the "boootcount" name?

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
In general, if you think something isn't in Perl, try it out, because
it usually is :-) - Larry Wall in <1991jul31.174523.9...@netlabs.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [usb dwc3] xHCI driver -- a hint needed.

[Neil Armstrong]

Hi Bin,


On 08/09/2019 14:35, Bin Meng wrote:
> Hi Neil,
> 
> On Sun, Sep 8, 2019 at 8:33 PM Neil Armstrong  wrote:
>>
>> Hi Bin,
>>
>> Le 07/09/2019 à 05:44, Bin Meng a écrit :
>>> Hi Neil,
>>>
>>> On Thu, Sep 5, 2019 at 11:48 PM Neil Armstrong  
>>> wrote:

 Hi Bin,

 I've been having the same behavior on the Amlogic S905X SoC with a DWC3 
 XHCI controller
 connected to 2 HS-only PHYs and no SS PHY.

 When a device is connected on the second PHY, I have the same BUG(),
 but no more when a device is also connected on the first PHY, and no issues
 at all on the first PHY.

 XHCI timeout on event type 33... cannot recover.

 What kind of debug output would you need to debug this ?

 => When Port 1 is disconnected, but Port 2 is populated:
 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 
 length 0x0
 clear port connect change, actual port 2 status  = 0x6e1
 ...
 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 
 length 0x0
 ...
 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 
 length 0x4
 SPEED = FULLSPEED
 ...
 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 
 length 0x0
 ...
 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 
 length 0x4
 SPEED = FULLSPEED
 ...
 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 
 length 0x0
 clear port reset change, actual port 2 status  = 0x603


 => When Port 1 is populated:
 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 
 length 0x0
 clear port connect change, actual port 2 status  = 0x6e1
 ...
 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 
 length 0x0
 ...
 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 
 length 0x4
 SPEED = FULLSPEED
 ...
 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 
 length 0x0
 ...
 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 
 length 0x4
 SPEED = HIGHSPEED
 ...
 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 
 length 0x0
 clear port reset change, actual port 2 status  = 0xe03

 When Port 1 is populated, Port 2 status correctly switches to HIGHSPEED,
 but why ?

>>>
>>> This looks really strange. Sounds like a hardware internal state
>>> depends on the first USB port. Do you know if Linux works?
>>
>> Yes, Linux works fine, is it worth tracing the Linux XHCI driver aswell ?
> 
> Yes, that will definitely help.

I did a extensive debug and print session today agains the amlogic u-boot 
release and Linux,

and only :
clrbits_le32(_reg->g_usb2phycfg, DWC3_GUSB2PHYCFG_SUSPHY);

was missing in drivers/usb/host/xhci-dwc3.c

because xhci-dwc3 is not using the dwc3 core init.

it should use the dwc3 core init instead of a copy, that correctly handles
the quirks.

Neil

> 
> Regards,
> Bin
> 

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

Re: [U-Boot] [PATCH 00/10] Add Support for UFS subsystem for TI's J721e

[Tom Rini]

On Mon, Sep 09, 2019 at 08:27:23PM +0530, Faiz Abbas wrote:
> Hi Tom,
> 
> On 09/09/19 8:22 PM, Tom Rini wrote:
> > On Mon, Sep 09, 2019 at 01:49:49PM +0530, Faiz Abbas wrote:
> >> The following patches add support for the Universal Flash Storage (UFS)
> >> subsystem and its implementation on TI's J721e platform.
> >>
> >> The UFS Application Layer (UAP) uses SCSI SAM-4 command set for
> >> communication with the device. Therefore, the first 4 patches prepare
> >> the scsi layer for compatibility with UFS. Patch 9 also adds support for
> >> initializing and configuring the device from the U-boot command line.
> >>
> >> The UFS Transport Protocol Layer (UTP) and UFS Interconnect Layer (UIC)
> >> are implemented with patch 5. This series only adds support for
> >> detect and read/write operations to the LUNs present in the remote
> >> device. Task Management operations and configuration of LUNs will be
> >> added in a future series.
> >>
> >> Patches 6 through 10 add platform driver, device tree and config support
> >> for TI's J721E devices.
> >>
> >> Log: https://pastebin.ubuntu.com/p/fTPZsxNjZM/
> >>
> >> Tested on top of Lokesh's tree:
> >> https://github.com/lokeshvutla/u-boot
> >> Branch: j721e-full-boot
> >>
> >> References:
> >>
> >> [1] JESD220D UFS 3.0:
> >>https://www.jedec.org/standards-documents/docs/jesd220c
> >> [2] JESD223D UFS Host Controller Interface (UFSHCI) version 3.0:
> >>https://www.jedec.org/standards-documents/docs/jesd223c
> >>
> >> Faiz Abbas (10):
> >>   scsi: Simplify scsi_read()/_write()
> >>   scsi: Add max_bytes to scsi_platdata
> >>   scsi: Retry inquiry 3 times to overcome Unit Attention condition
> >>   scsi: Add dma direction member to command structure
> >>   ufs: Add Initial Support for UFS subsystem
> >>   ufs: Add Support for Cadence platform UFS driver
> >>   ufs: Add glue layer driver for TI J721E devices
> >>   arm: dts: k3-j721e-main: Add UFS nodes
> >>   cmd: Add Support for UFS commands
> >>   configs: j721e_evm_a72: Enable configs for UFS
> >>
> >>  arch/arm/dts/k3-j721e-main.dtsi |   25 +
> >>  cmd/Kconfig |7 +
> >>  cmd/Makefile|2 +-
> >>  cmd/ufs.c   |   28 +
> >>  configs/j721e_evm_a72_defconfig |7 +-
> >>  drivers/Kconfig |2 +
> >>  drivers/Makefile|1 +
> >>  drivers/scsi/scsi.c |   83 +-
> >>  drivers/ufs/Kconfig |   23 +
> >>  drivers/ufs/Makefile|8 +
> >>  drivers/ufs/cdns-platform.c |  122 ++
> >>  drivers/ufs/ti-j721e-ufs.c  |   75 ++
> >>  drivers/ufs/ufs-uclass.c|   16 +
> >>  drivers/ufs/ufs.c   | 1973 +++
> >>  drivers/ufs/ufs.h   |  918 ++
> >>  drivers/ufs/unipro.h|  270 +
> >>  include/dm/uclass-id.h  |1 +
> >>  include/scsi.h  |4 +
> >>  include/ufs.h   |7 +
> >>  19 files changed, 3526 insertions(+), 46 deletions(-)
> >>  create mode 100644 cmd/ufs.c
> >>  create mode 100644 drivers/ufs/Kconfig
> >>  create mode 100644 drivers/ufs/Makefile
> >>  create mode 100644 drivers/ufs/cdns-platform.c
> >>  create mode 100644 drivers/ufs/ti-j721e-ufs.c
> >>  create mode 100644 drivers/ufs/ufs-uclass.c
> >>  create mode 100644 drivers/ufs/ufs.c
> >>  create mode 100644 drivers/ufs/ufs.h
> >>  create mode 100644 drivers/ufs/unipro.h
> >>  create mode 100644 include/ufs.h
> > 
> > I'm glad to see this support coming, it's something we need.  Would you
> > be willing to list yourself as the maintainer in the top-level
> > MAINTAINER file for drivers/ufs at least?  Thanks!
> > 
> 
> I did add to the MAINTAINER file in patch 5. Was that supposed to be a
> separate patch?

Ah, funny enough it's not in the diffstat here :)  Thanks!

-- 
Tom


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

[U-Boot] [PATCH 6/6] net: ti: cpsw: convert to use dev/ofnode api

[Grygorii Strashko]

Conver TI CPSW driver to use dev/ofnode api.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ti/cpsw.c | 118 ++
 include/cpsw.h|   2 +-
 2 files changed, 51 insertions(+), 69 deletions(-)

diff --git a/drivers/net/ti/cpsw.c b/drivers/net/ti/cpsw.c
index 55edff3b8d..4a990be93e 100644
--- a/drivers/net/ti/cpsw.c
+++ b/drivers/net/ti/cpsw.c
@@ -19,12 +19,9 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "cpsw_mdio.h"
 
-DECLARE_GLOBAL_DATA_PTR;
-
 #define BITMASK(bits)  (BIT(bits) - 1)
 #define NUM_DESCS  (PKTBUFSRX * 2)
 #define PKT_MIN60
@@ -860,8 +857,8 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct 
cpsw_slave *slave)
phydev->advertising = phydev->supported;
 
 #ifdef CONFIG_DM_ETH
-   if (slave->data->phy_of_handle)
-   phydev->node = offset_to_ofnode(slave->data->phy_of_handle);
+   if (ofnode_valid(slave->data->phy_of_handle))
+   phydev->node = slave->data->phy_of_handle;
 #endif
 
priv->phydev = phydev;
@@ -1049,12 +1046,6 @@ static const struct eth_ops cpsw_eth_ops = {
.stop   = cpsw_eth_stop,
 };
 
-static inline fdt_addr_t cpsw_get_addr_by_node(const void *fdt, int node)
-{
-   return fdtdec_get_addr_size_auto_noparent(fdt, node, "reg", 0, NULL,
- false);
-}
-
 static void cpsw_gmii_sel_am3352(struct cpsw_priv *priv,
 phy_interface_t phy_mode)
 {
@@ -1188,38 +1179,37 @@ static int cpsw_eth_probe(struct udevice *dev)
 
 #if CONFIG_IS_ENABLED(OF_CONTROL)
 static void cpsw_eth_of_parse_slave(struct cpsw_platform_data *data,
-   int slave_index, int subnode)
+   int slave_index, ofnode subnode)
 {
-   struct cpsw_slave_data  *slave_data;
-   const void *fdt = gd->fdt_blob;
+   struct ofnode_phandle_args out_args;
+   struct cpsw_slave_data *slave_data;
const char *phy_mode;
-   int max_speed = -1;
u32 phy_id[2];
+   int ret;
 
slave_data = >slave_data[slave_index];
 
-   phy_mode = fdt_getprop(fdt, subnode, "phy-mode", NULL);
+   phy_mode = ofnode_read_string(subnode, "phy-mode");
if (phy_mode)
-   slave_data->phy_if =
-   phy_get_interface_by_name(phy_mode);
+   slave_data->phy_if = phy_get_interface_by_name(phy_mode);
 
-   slave_data->phy_of_handle = fdtdec_lookup_phandle(fdt, subnode,
- "phy-handle");
+   ret = ofnode_parse_phandle_with_args(subnode, "phy-handle",
+NULL, 0, 0, _args);
+   if (!ret) {
+   slave_data->phy_of_handle = out_args.node;
 
-   if (data->slave_data[slave_index].phy_of_handle >= 0) {
-   slave_data->phy_addr =
-   fdtdec_get_int(fdt, slave_data->phy_of_handle,
-  "reg", -1);
+   ret = ofnode_read_s32(slave_data->phy_of_handle, "reg",
+ _data->phy_addr);
+   if (ret)
+   printf("error: phy addr not found in dt\n");
} else {
-   fdtdec_get_int_array(fdt, subnode, "phy_id",
-phy_id, 2);
-   slave_data->phy_addr = phy_id[1];
+   ret = ofnode_read_u32_array(subnode, "phy_id", phy_id, 2);
+   if (ret)
+   printf("error: phy_id read failed\n");
}
 
-   max_speed = fdtdec_get_int(fdt, subnode,
-  "max-speed", max_speed);
-   if (max_speed > 0)
-   slave_data->max_speed = max_speed;
+   slave_data->max_speed = ofnode_read_s32_default(subnode,
+   "max-speed", 0);
 }
 
 static int cpsw_eth_ofdata_to_platdata(struct udevice *dev)
@@ -1227,17 +1217,14 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
struct eth_pdata *pdata = dev_get_platdata(dev);
struct cpsw_platform_data *data;
struct gpio_desc *mode_gpios;
-   const void *fdt = gd->fdt_blob;
-   int node = dev_of_offset(dev);
-   int subnode;
int slave_index = 0;
-   int active_slave;
int num_mode_gpios;
+   ofnode subnode;
int ret;
 
data = calloc(1, sizeof(struct cpsw_platform_data));
pdata->priv_pdata = data;
-   pdata->iobase = devfdt_get_addr(dev);
+   pdata->iobase = dev_read_addr(dev);
data->version = CPSW_CTRL_VERSION_2;
data->bd_ram_ofs = CPSW_BD_OFFSET;
data->ale_reg_ofs = CPSW_ALE_OFFSET;
@@ -1248,36 +1235,37 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
pdata->phy_interface = -1;
 
data->cpsw_base = pdata->iobase;
-   

[U-Boot] [PATCH 1/6] net: ti: cpsw: enable 10Mbps link speed support in rgmii mode

[Grygorii Strashko]

According to TRMs the 10Mbps link speed is supported in RGMII only when
CPSW2G MAC SL is configured for External Control ("in band") mode
CPSW_SL_MACCTRL.EXT_EN(18) = 1.

Hence update cpsw_slave_update_link() to follow documentation.

[1] https://patchwork.kernel.org/patch/10285239/
Signed-off-by: Grygorii Strashko 
---
 drivers/net/ti/cpsw.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ti/cpsw.c b/drivers/net/ti/cpsw.c
index 20ddb44dd8..f0d008f0f5 100644
--- a/drivers/net/ti/cpsw.c
+++ b/drivers/net/ti/cpsw.c
@@ -33,6 +33,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define GIGABITEN  BIT(7)
 #define FULLDUPLEXEN   BIT(0)
 #define MIIEN  BIT(15)
+#define CTL_EXT_EN BIT(18)
 /* DMA Registers */
 #define CPDMA_TXCONTROL0x004
 #define CPDMA_RXCONTROL0x014
@@ -489,6 +490,8 @@ static int cpsw_slave_update_link(struct cpsw_slave *slave,
mac_control |= FULLDUPLEXEN;
if (phy->speed == 100)
mac_control |= MIIEN;
+   if (phy->speed == 10 && phy_interface_is_rgmii(phy))
+   mac_control |= CTL_EXT_EN;
}
 
if (mac_control == slave->mac_control)
-- 
2.17.1

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

[U-Boot] [PATCH 3/6] net: ti: cpsw: add support for standard eth "max-speed" dt property

[Grygorii Strashko]

This patch adds support for standard Ethernet "max-speed" DT property to
allow PHY link speed limitation.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ti/cpsw.c | 14 ++
 include/cpsw.h|  1 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/net/ti/cpsw.c b/drivers/net/ti/cpsw.c
index 533c167995..af4db89341 100644
--- a/drivers/net/ti/cpsw.c
+++ b/drivers/net/ti/cpsw.c
@@ -839,6 +839,7 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct 
cpsw_slave *slave)
 {
struct phy_device *phydev;
u32 supported = PHY_GBIT_FEATURES;
+   int ret;
 
phydev = phy_connect(priv->bus,
slave->data->phy_addr,
@@ -849,6 +850,13 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct 
cpsw_slave *slave)
return -1;
 
phydev->supported &= supported;
+   if (slave->data->max_speed) {
+   ret = phy_set_supported(phydev, slave->data->max_speed);
+   if (ret)
+   return ret;
+   dev_dbg(priv->dev, "Port %u speed forced to %uMbit\n",
+   slave->slave_num + 1, slave->data->max_speed);
+   }
phydev->advertising = phydev->supported;
 
 #ifdef CONFIG_DM_ETH
@@ -1185,6 +1193,7 @@ static void cpsw_eth_of_parse_slave(struct 
cpsw_platform_data *data,
struct cpsw_slave_data  *slave_data;
const void *fdt = gd->fdt_blob;
const char *phy_mode;
+   int max_speed = -1;
u32 phy_id[2];
 
slave_data = >slave_data[slave_index];
@@ -1206,6 +1215,11 @@ static void cpsw_eth_of_parse_slave(struct 
cpsw_platform_data *data,
 phy_id, 2);
slave_data->phy_addr = phy_id[1];
}
+
+   max_speed = fdtdec_get_int(fdt, subnode,
+  "max-speed", max_speed);
+   if (max_speed > 0)
+   slave_data->max_speed = max_speed;
 }
 
 static int cpsw_eth_ofdata_to_platdata(struct udevice *dev)
diff --git a/include/cpsw.h b/include/cpsw.h
index 96ff254f98..c7532fc866 100644
--- a/include/cpsw.h
+++ b/include/cpsw.h
@@ -39,6 +39,7 @@ struct cpsw_slave_data {
int phy_addr;
int phy_if;
int phy_of_handle;
+   int max_speed;
 };
 
 enum {
-- 
2.17.1

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

[U-Boot] [PATCH 5/6] net: ti: am65x-cpsw: fix mac tx internal delay for rgmii-rxid mode

[Grygorii Strashko]

Now AM65x CPSW2G driver will disable MAC TX internal delay for PHY
interface mode "rgmii-rxid" which is incorrect. Hence, fix it by keeping
default value (enabled) for MAC TX internal delay when "rgmii-rxid"
interface mode is selected.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ti/am65-cpsw-nuss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index e11fbdeed3..06b0663950 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -234,11 +234,11 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv 
*priv,
break;
 
case PHY_INTERFACE_MODE_RGMII:
+   case PHY_INTERFACE_MODE_RGMII_RXID:
mode = AM65_GMII_SEL_MODE_RGMII;
break;
 
case PHY_INTERFACE_MODE_RGMII_ID:
-   case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
mode = AM65_GMII_SEL_MODE_RGMII;
rgmii_id = true;
-- 
2.17.1

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

[U-Boot] [PATCH 4/6] net: ti: cpsw: fix mac tx internal delay for rgmii-rxid mode

[Grygorii Strashko]

Now TI CPSW driver will disable MAC TX internal delay for PHY interface
mode "rgmii-rxid" which is incorrect.

Hence, fix it by keeping default value (enabled) for MAC TX internal delay
when "rgmii-rxid" interface mode is selected.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ti/cpsw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ti/cpsw.c b/drivers/net/ti/cpsw.c
index af4db89341..55edff3b8d 100644
--- a/drivers/net/ti/cpsw.c
+++ b/drivers/net/ti/cpsw.c
@@ -1072,10 +1072,10 @@ static void cpsw_gmii_sel_am3352(struct cpsw_priv *priv,
break;
 
case PHY_INTERFACE_MODE_RGMII:
+   case PHY_INTERFACE_MODE_RGMII_RXID:
mode = AM33XX_GMII_SEL_MODE_RGMII;
break;
case PHY_INTERFACE_MODE_RGMII_ID:
-   case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
mode = AM33XX_GMII_SEL_MODE_RGMII;
rgmii_id = true;
-- 
2.17.1

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

[U-Boot] [PATCH 2/6] net: ti: cpsw: move parsing of dt port's parameters in separate func

[Grygorii Strashko]

Move parsing of dt port's parameters in separate func for better code
readability.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ti/cpsw.c | 57 +--
 1 file changed, 33 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ti/cpsw.c b/drivers/net/ti/cpsw.c
index f0d008f0f5..533c167995 100644
--- a/drivers/net/ti/cpsw.c
+++ b/drivers/net/ti/cpsw.c
@@ -1179,12 +1179,40 @@ static int cpsw_eth_probe(struct udevice *dev)
 }
 
 #if CONFIG_IS_ENABLED(OF_CONTROL)
+static void cpsw_eth_of_parse_slave(struct cpsw_platform_data *data,
+   int slave_index, int subnode)
+{
+   struct cpsw_slave_data  *slave_data;
+   const void *fdt = gd->fdt_blob;
+   const char *phy_mode;
+   u32 phy_id[2];
+
+   slave_data = >slave_data[slave_index];
+
+   phy_mode = fdt_getprop(fdt, subnode, "phy-mode", NULL);
+   if (phy_mode)
+   slave_data->phy_if =
+   phy_get_interface_by_name(phy_mode);
+
+   slave_data->phy_of_handle = fdtdec_lookup_phandle(fdt, subnode,
+ "phy-handle");
+
+   if (data->slave_data[slave_index].phy_of_handle >= 0) {
+   slave_data->phy_addr =
+   fdtdec_get_int(fdt, slave_data->phy_of_handle,
+  "reg", -1);
+   } else {
+   fdtdec_get_int_array(fdt, subnode, "phy_id",
+phy_id, 2);
+   slave_data->phy_addr = phy_id[1];
+   }
+}
+
 static int cpsw_eth_ofdata_to_platdata(struct udevice *dev)
 {
struct eth_pdata *pdata = dev_get_platdata(dev);
struct cpsw_platform_data *data;
struct gpio_desc *mode_gpios;
-   const char *phy_mode;
const void *fdt = gd->fdt_blob;
int node = dev_of_offset(dev);
int subnode;
@@ -1267,30 +1295,10 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
}
 
if (!strncmp(name, "slave", 5)) {
-   u32 phy_id[2];
-
if (slave_index >= data->slaves)
continue;
-   phy_mode = fdt_getprop(fdt, subnode, "phy-mode", NULL);
-   if (phy_mode)
-   data->slave_data[slave_index].phy_if =
-   phy_get_interface_by_name(phy_mode);
-
-   data->slave_data[slave_index].phy_of_handle =
-   fdtdec_lookup_phandle(fdt, subnode,
- "phy-handle");
-
-   if (data->slave_data[slave_index].phy_of_handle >= 0) {
-   data->slave_data[slave_index].phy_addr =
-   fdtdec_get_int(gd->fdt_blob,
-   
data->slave_data[slave_index].phy_of_handle,
-  "reg", -1);
-   } else {
-   fdtdec_get_int_array(fdt, subnode, "phy_id",
-phy_id, 2);
-   data->slave_data[slave_index].phy_addr =
-   phy_id[1];
-   }
+
+   cpsw_eth_of_parse_slave(data, slave_index, subnode);
slave_index++;
}
 
@@ -1331,7 +1339,8 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
 
pdata->phy_interface = data->slave_data[active_slave].phy_if;
if (pdata->phy_interface == -1) {
-   debug("%s: Invalid PHY interface '%s'\n", __func__, phy_mode);
+   debug("%s: Invalid PHY interface '%s'\n", __func__,
+ phy_string_for_interface(pdata->phy_interface));
return -EINVAL;
}
 
-- 
2.17.1

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

[U-Boot] [PATCH 0/6] net: ti: net: to: set of fixes and improvements

[Grygorii Strashko]

Hi All,

This series introduces set of fixes and improvements for TI CPSW and AM654x
CPSW networking drivers.

Patch 1 - Enables support of 10Mbit link speeds for TI CPSW driver.
Patch 3 - Adds support of standard Ethernet "max-speed" DT property.
Patches 4-5 - fix mac tx internal delay for rgmii-rxid mode
Patches 2,6 - are code improvements


Grygorii Strashko (6):
  net: ti: cpsw: enable 10Mbps link speed support in rgmii mode
  net: ti: cpsw: move parsing of dt port's parameters in separate func
  net: ti: cpsw: add support for standard eth "max-speed" dt property
  net: ti: cpsw: fix mac tx internal delay for rgmii-rxid mode
  net: ti: am65x-cpsw: fix mac tx internal delay for rgmii-rxid mode
  net: ti: cpsw: convert to use dev/ofnode api

 drivers/net/ti/am65-cpsw-nuss.c |   2 +-
 drivers/net/ti/cpsw.c   | 154 +---
 include/cpsw.h  |   3 +-
 3 files changed, 84 insertions(+), 75 deletions(-)

-- 
2.17.1

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

[U-Boot] [PATCH] arm: ti: Add missing "=" from previous fix

[Tom Rini]

While the original patch to fix a regression in distro boot for mmc on
these platforms had the correct syntax, I broke the change while
applying.  Add back in the missing "=" here so that the syntax is
correct.

Reported-by: Andre Heider 
Fixes: 27e0f3bcf075 ("arm: ti: Fix regression in distro boot for mmc")
Signed-off-by: Tom Rini 
---
 include/environment/ti/mmc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/environment/ti/mmc.h b/include/environment/ti/mmc.h
index ef053766088b..bb4af0a3d54b 100644
--- a/include/environment/ti/mmc.h
+++ b/include/environment/ti/mmc.h
@@ -56,7 +56,7 @@
"bootz; " \
"fi;\0" \
"mmcboot=mmc dev ${mmcdev}; " \
-   "devnum ${mmcdev}; " \
+   "devnum=${mmcdev}; " \
"setenv devtype mmc; " \
"if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \
-- 
2.7.4

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

Re: [U-Boot] [PATCH 00/10] Add Support for UFS subsystem for TI's J721e

[Faiz Abbas]

Hi Tom,

On 09/09/19 8:22 PM, Tom Rini wrote:
> On Mon, Sep 09, 2019 at 01:49:49PM +0530, Faiz Abbas wrote:
>> The following patches add support for the Universal Flash Storage (UFS)
>> subsystem and its implementation on TI's J721e platform.
>>
>> The UFS Application Layer (UAP) uses SCSI SAM-4 command set for
>> communication with the device. Therefore, the first 4 patches prepare
>> the scsi layer for compatibility with UFS. Patch 9 also adds support for
>> initializing and configuring the device from the U-boot command line.
>>
>> The UFS Transport Protocol Layer (UTP) and UFS Interconnect Layer (UIC)
>> are implemented with patch 5. This series only adds support for
>> detect and read/write operations to the LUNs present in the remote
>> device. Task Management operations and configuration of LUNs will be
>> added in a future series.
>>
>> Patches 6 through 10 add platform driver, device tree and config support
>> for TI's J721E devices.
>>
>> Log: https://pastebin.ubuntu.com/p/fTPZsxNjZM/
>>
>> Tested on top of Lokesh's tree:
>> https://github.com/lokeshvutla/u-boot
>> Branch: j721e-full-boot
>>
>> References:
>>
>> [1] JESD220D UFS 3.0:
>>  https://www.jedec.org/standards-documents/docs/jesd220c
>> [2] JESD223D UFS Host Controller Interface (UFSHCI) version 3.0:
>>  https://www.jedec.org/standards-documents/docs/jesd223c
>>
>> Faiz Abbas (10):
>>   scsi: Simplify scsi_read()/_write()
>>   scsi: Add max_bytes to scsi_platdata
>>   scsi: Retry inquiry 3 times to overcome Unit Attention condition
>>   scsi: Add dma direction member to command structure
>>   ufs: Add Initial Support for UFS subsystem
>>   ufs: Add Support for Cadence platform UFS driver
>>   ufs: Add glue layer driver for TI J721E devices
>>   arm: dts: k3-j721e-main: Add UFS nodes
>>   cmd: Add Support for UFS commands
>>   configs: j721e_evm_a72: Enable configs for UFS
>>
>>  arch/arm/dts/k3-j721e-main.dtsi |   25 +
>>  cmd/Kconfig |7 +
>>  cmd/Makefile|2 +-
>>  cmd/ufs.c   |   28 +
>>  configs/j721e_evm_a72_defconfig |7 +-
>>  drivers/Kconfig |2 +
>>  drivers/Makefile|1 +
>>  drivers/scsi/scsi.c |   83 +-
>>  drivers/ufs/Kconfig |   23 +
>>  drivers/ufs/Makefile|8 +
>>  drivers/ufs/cdns-platform.c |  122 ++
>>  drivers/ufs/ti-j721e-ufs.c  |   75 ++
>>  drivers/ufs/ufs-uclass.c|   16 +
>>  drivers/ufs/ufs.c   | 1973 +++
>>  drivers/ufs/ufs.h   |  918 ++
>>  drivers/ufs/unipro.h|  270 +
>>  include/dm/uclass-id.h  |1 +
>>  include/scsi.h  |4 +
>>  include/ufs.h   |7 +
>>  19 files changed, 3526 insertions(+), 46 deletions(-)
>>  create mode 100644 cmd/ufs.c
>>  create mode 100644 drivers/ufs/Kconfig
>>  create mode 100644 drivers/ufs/Makefile
>>  create mode 100644 drivers/ufs/cdns-platform.c
>>  create mode 100644 drivers/ufs/ti-j721e-ufs.c
>>  create mode 100644 drivers/ufs/ufs-uclass.c
>>  create mode 100644 drivers/ufs/ufs.c
>>  create mode 100644 drivers/ufs/ufs.h
>>  create mode 100644 drivers/ufs/unipro.h
>>  create mode 100644 include/ufs.h
> 
> I'm glad to see this support coming, it's something we need.  Would you
> be willing to list yourself as the maintainer in the top-level
> MAINTAINER file for drivers/ufs at least?  Thanks!
> 

I did add to the MAINTAINER file in patch 5. Was that supposed to be a
separate patch?

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

Re: [U-Boot] Regression after "distro: not taint environment variables if possible"

[Tom Rini]

On Mon, Sep 09, 2019 at 12:17:47PM +0200, Andre Heider wrote:
> Hi,
> 
> wrt my other mail "TI mmc env bug?", Nuno sent a proper patch, yet the
> commit has the syntax error (missing "="):
> 
> https://gitlab.denx.de/u-boot/u-boot/commit/27e0f3bcf07530a9cd272953797efda54ebb8f5e

Ugh, I don't know how that happened.  Thanks for pointing it out, I'll
fix it ASAP.

> 
> Regards,
> Andre
> 
> On 27/08/2019 02:17, Tom Rini wrote:
> >On Wed, Jul 10, 2019 at 01:46:57PM +0200, Nuno Gonçalves wrote:
> >
> >>Hi,
> >>
> >>I found out that my Beaglebone didn't boot after:
> >>
> >>https://github.com/u-boot/u-boot/commit/13dd6665ed18f72380ca596931d609bc108d4b82
> >>
> >>I digged out the reason that this patch makes devnum a local variable,
> >>and it ends up shadowed by other code that sets devnum as a env
> >>variable.
> >>
> >>For example to boot on the beaglebone I had to remove the setenv as in
> >>the patch below.
> >>
> >>This only fixes for my board. Many other will likely have regressions.
> >>
> >>Fixing it for all boards in a reliable way I think is very complex,
> >>unless the strategy is to wait for board maintainers to fix it as they
> >>need it, but I wonder how many latent bugs this will create for corner
> >>boot cases.
> >>
> >>Maybe this change is not worth it?
> >>
> >>Thanks,
> >>Nuno
> >
> >I've checked other usages here and only the TI case looks to have been a
> >problem.  I reworded the commit message as well.
> >
> >Applied to u-boot/master, thanks!
> >
> >
> >___
> >U-Boot mailing list
> >U-Boot@lists.denx.de
> >https://lists.denx.de/listinfo/u-boot
> >
> 

-- 
Tom


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

Re: [U-Boot] [PATCH 00/10] Add Support for UFS subsystem for TI's J721e

[Tom Rini]

On Mon, Sep 09, 2019 at 01:49:49PM +0530, Faiz Abbas wrote:
> The following patches add support for the Universal Flash Storage (UFS)
> subsystem and its implementation on TI's J721e platform.
> 
> The UFS Application Layer (UAP) uses SCSI SAM-4 command set for
> communication with the device. Therefore, the first 4 patches prepare
> the scsi layer for compatibility with UFS. Patch 9 also adds support for
> initializing and configuring the device from the U-boot command line.
> 
> The UFS Transport Protocol Layer (UTP) and UFS Interconnect Layer (UIC)
> are implemented with patch 5. This series only adds support for
> detect and read/write operations to the LUNs present in the remote
> device. Task Management operations and configuration of LUNs will be
> added in a future series.
> 
> Patches 6 through 10 add platform driver, device tree and config support
> for TI's J721E devices.
> 
> Log: https://pastebin.ubuntu.com/p/fTPZsxNjZM/
> 
> Tested on top of Lokesh's tree:
> https://github.com/lokeshvutla/u-boot
> Branch: j721e-full-boot
> 
> References:
> 
> [1] JESD220D UFS 3.0:
>   https://www.jedec.org/standards-documents/docs/jesd220c
> [2] JESD223D UFS Host Controller Interface (UFSHCI) version 3.0:
>   https://www.jedec.org/standards-documents/docs/jesd223c
> 
> Faiz Abbas (10):
>   scsi: Simplify scsi_read()/_write()
>   scsi: Add max_bytes to scsi_platdata
>   scsi: Retry inquiry 3 times to overcome Unit Attention condition
>   scsi: Add dma direction member to command structure
>   ufs: Add Initial Support for UFS subsystem
>   ufs: Add Support for Cadence platform UFS driver
>   ufs: Add glue layer driver for TI J721E devices
>   arm: dts: k3-j721e-main: Add UFS nodes
>   cmd: Add Support for UFS commands
>   configs: j721e_evm_a72: Enable configs for UFS
> 
>  arch/arm/dts/k3-j721e-main.dtsi |   25 +
>  cmd/Kconfig |7 +
>  cmd/Makefile|2 +-
>  cmd/ufs.c   |   28 +
>  configs/j721e_evm_a72_defconfig |7 +-
>  drivers/Kconfig |2 +
>  drivers/Makefile|1 +
>  drivers/scsi/scsi.c |   83 +-
>  drivers/ufs/Kconfig |   23 +
>  drivers/ufs/Makefile|8 +
>  drivers/ufs/cdns-platform.c |  122 ++
>  drivers/ufs/ti-j721e-ufs.c  |   75 ++
>  drivers/ufs/ufs-uclass.c|   16 +
>  drivers/ufs/ufs.c   | 1973 +++
>  drivers/ufs/ufs.h   |  918 ++
>  drivers/ufs/unipro.h|  270 +
>  include/dm/uclass-id.h  |1 +
>  include/scsi.h  |4 +
>  include/ufs.h   |7 +
>  19 files changed, 3526 insertions(+), 46 deletions(-)
>  create mode 100644 cmd/ufs.c
>  create mode 100644 drivers/ufs/Kconfig
>  create mode 100644 drivers/ufs/Makefile
>  create mode 100644 drivers/ufs/cdns-platform.c
>  create mode 100644 drivers/ufs/ti-j721e-ufs.c
>  create mode 100644 drivers/ufs/ufs-uclass.c
>  create mode 100644 drivers/ufs/ufs.c
>  create mode 100644 drivers/ufs/ufs.h
>  create mode 100644 drivers/ufs/unipro.h
>  create mode 100644 include/ufs.h

I'm glad to see this support coming, it's something we need.  Would you
be willing to list yourself as the maintainer in the top-level
MAINTAINER file for drivers/ufs at least?  Thanks!

-- 
Tom


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

[U-Boot] [RFC][PATCH] bootcount: add support to customize bootcount variable name

[Philippe Reynes]

This commit add an option to customize the bootcount variable
name in the u-boot environment. To stay compatible with old config,
the default name is bootcount.

Signed-off-by: Philippe Reynes 
---
 drivers/bootcount/Kconfig | 8 
 drivers/bootcount/bootcount_env.c | 4 ++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index b7c29f2..0088bf8 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -161,4 +161,12 @@ config SYS_BOOTCOUNT_MAGIC
help
  Set the magic value used for the boot counter.
 
+config SYS_BOOTCOUNT_NAME
+   string "Name of the bootcount variable in the env"
+   default "bootcount"
+   depends on BOOTCOUNT_ENV
+   help
+ Set the name of the variable that count the number of boot.
+ Usually this variable is named 'bootcount'.
+
 endif
diff --git a/drivers/bootcount/bootcount_env.c 
b/drivers/bootcount/bootcount_env.c
index b75c900..d5a38c8 100644
--- a/drivers/bootcount/bootcount_env.c
+++ b/drivers/bootcount/bootcount_env.c
@@ -12,7 +12,7 @@ void bootcount_store(ulong a)
int upgrade_available = env_get_ulong("upgrade_available", 10, 0);
 
if (upgrade_available) {
-   env_set_ulong("bootcount", a);
+   env_set_ulong(CONFIG_SYS_BOOTCOUNT_NAME, a);
env_save();
}
 }
@@ -23,7 +23,7 @@ ulong bootcount_load(void)
ulong val = 0;
 
if (upgrade_available)
-   val = env_get_ulong("bootcount", 10, 0);
+   val = env_get_ulong(CONFIG_SYS_BOOTCOUNT_NAME, 10, 0);
 
return val;
 }
-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver

[Sherry Sun]

Hi Jean,

> 
> Hi Sherry,
> 
> On 03/09/2019 14:44, Sherry Sun wrote:
> > Hi Jean,
> >
> >>
> >> On 02/09/2019 13:29, Sherry Sun wrote:
> >>> Hi Vignesh,
> >>>
>  Hi Sherry,
> 
>  [...]
> >> AFAIK, U-Boot does not support runtime switching of USB port to
> >> host from device and vice versa. This is the case for existing
> >> driver like
>  DWC3/MUSB etc.
> >> Ideally we would need a role switch driver that unbinds and
> >> rebinds host vs device driver as when required based on U-Boot
> >> cmd or via an API (if required to be done during SPL stage etc).
> > I wonder if we can add two subnodes under the wrapper node as
> > below,
>  one bind to usb gadget driver and another bind to usb host driver.
> > So if we want to use usb device, just call the gadget driver, and
> > if want to
>  use usb host, just call the host driver. The driver will probe
>  correspond
> >> node.
> > I'm not sure if it is feasible, what do you think about it?
> >
> > usbss0: cdns_usb@4104000 {
> > compatible = "ti,j721e-usb";
> > []
> > usb0: usb@601 { /* xhci reg address*/
> > compatible = "cdns,usb3-1.0.1";
> > dr_mode = "host";
> > []
> > }
> > usb1: usb@602 { /* dev reg address*/
> > compatible = "cdns,usb3-1.0.1";
> > dr_mode = "peripheral";
> > []
> > }
> >   }
> >
>  But this is not how DT would look in kernel. There will be single
>  DT node representing both Host and Device node. DT repesentation
>  should not be changed based on OS/bootloader, its HW description
>  and must
> >> remain same.
>  Unbinding host/gadget driver and rebinding with a different role
>  should not be hard as the U-Boot core infrastructure exists.
> 
>  Moreover if xhci reg and dev reg are separated into different nodes
>  dont we still need access to OTG register block to switch b/w host
>  and
> >> device mode?
> >>> I think we may not need to access OTG register if we add two
> >>> subnodes for
> >> gadget and host.
> >>> But I see a for loop in dwc3_glue_bind() as follows, if there only
> >>> one single
> >> node representing both Host and Device node under usb wrapper node,
> >> why we need this for loop?
> >>> 212 for (node = fdt_first_subnode(fdt, dev_of_offset(parent)); node >
> 0;
> >>> 213  node = fdt_next_subnode(fdt, node)) {
> >> I believe this is a legacy from the code it was inspired from.
> >>
> >> Indeed the loop is not required.
> >>
> >> Like Vignesh I think we must stick with the dt-bindings used by the kernel.
> > Thanks for your reply, I understand now.
> >
> >> BTW we are working on the USB3 support right now that is lacking in our
> tree.
> >> I choose to keep the PHY drivers as close as possible to their linux
> >> version. I'll probably start posting preliminary patches this week.
> >>
> >> If you have the USB3 working in the kernel, can you point to a tree
> >> where I can have a look at the drivers and dt-bindings ?
> > Sure, you can see our downstream kernel code at my github, here is the
> link address:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
> .com%2Fsherrysun1%2Flinux-
> imx.gitdata=02%7C01%7Csherry.sun%40nxp.com%7C368ba21c33c048
> fd137208d735199870%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> C637036256383501199sdata=y4AB0RpG%2F7Skk34yccpkW9TQsDWpi
> 6OJhtlRWid1DM0%3Dreserved=0.
> > And look forward to seeing your patches in uboot maillist.
> 
> It will take some times before I can post on the mailing list because I did 
> the
> work on top TI's u-boot. But you can find the patches under
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
> .com%2Fjjhiblot%2Fu-
> boot%2Ftree%2Fusb3_cleanup_v2data=02%7C01%7Csherry.sun%40n
> xp.com%7C368ba21c33c048fd137208d735199870%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C637036256383511193sdata=ozU9gYDTO
> %2FkoB4NwU1R2omGw9%2F%2Fyf6MPxBz1%2FtQ8Lgg%3Dreserved=
> 0.
>  b.com%2Fjjhiblot%2Fu-
> boot%2Ftree%2Fusb3_cleanup_v2data=02%7C01%7Csherry.sun%40n
> xp.com%7C368ba21c33c048fd137208d735199870%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C637036256383511193sdata=ozU9gYDTO
> %2FkoB4NwU1R2omGw9%2F%2Fyf6MPxBz1%2FtQ8Lgg%3Dreserved=
> 0>
> 
> The DTS bindings are the same as under Linux. The CDNS3 driver is a port of
> the iteration v11 of the linux driver that has just been merged in the linux 
> usb
> tree
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke
> rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fbalbi%2Fusb.git%2Flog
> %2F%3Fh%3Dnextdata=02%7C01%7Csherry.sun%40nxp.com%7C368b
> a21c33c048fd137208d735199870%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 

Re: [U-Boot] [PATCH 0/3] Support distro boot in pico-imx7d BL33 case

[Jun Nie]

Peng Fan  于2019年9月3日周二 上午9:39写道：
>
> Hi Jun,
>
> > Subject: Re: [PATCH 0/3] Support distro boot in pico-imx7d BL33 case
> >
> > Jun Nie  于2019年8月8日周四 下午12:04写道：
> > >
> > > Jun Nie  于2019年7月16日周二 下午3:43写道：
> > > >
> > > > Support distro boot in pico-imx7d BL33 case with changing the
> > > > enviroment variables. While the other two patches are for polishing
> > > > clock code and for feature enablement.
> > > >
> > > > Jun Nie (3):
> > > >   pico-imx7d: add config to enable CAAM
> > > >   pico-imx7d: Support distro boot for FIT image case
> > > >   pico-imx7d: polish uart clock id definition
> > > >
> > > >  arch/arm/include/asm/arch-mx7/clock.h | 18 +
> > > >  configs/pico-imx7d_bl33_defconfig |  1 +
> > > >  include/configs/pico-imx7d.h  | 37
> > +++
> > > >  3 files changed, 13 insertions(+), 43 deletions(-)
> > > >
> > > > --
> > >
> > > Hi Vanessa,
> > >
> > > Do you have any comments on these 3 patches? Or we can merge it now?
> > Thanks!
> > >
> > > Best Regards
> > > Jun
> >
> > Hi,
> >
> > Does anyone has comments on these patches? Maybe we can merge them as
> > no comments for a long time. Thanks!
>
> I could merge this patchset into nxp-imx and send pull request to Stefano, if 
> you
> are fine with that.
>
> Regards,
> Peng.

Peng,

It is appreciated to help on this. Any comments from Stefan? Thanks!

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

[U-Boot] [PATCH v2] imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode

[Lukasz Majewski]

This change tries to fix the following problem:

- The board boots (to be more precise - ROM loads SPL) from a slow SPI-NOR
  memory.
  As a result the spl_boot_device() will return SPI-NOR as a boot device
  (which is correct).

- The problem is that in 'falcon boot' the eMMC is used as a boot medium to
  load kernel from its partition.
  Calling spl_boot_device() will break things as it returns SPI-NOR device.

To fix this issue the new CONFIG_SPL_FORCE_MMC_BOOT Kconfig flag is
introduced to handle this special use case. By default it is not defined,
so there is no change in the legacy code flow.

Signed-off-by: Lukasz Majewski 


---

Changes in v2:
- Update/enhance the Kconfig description of the SPL_FORCE_MMC_BOOT.

This patch is a follow up of previous discussion/fix:
https://patchwork.ozlabs.org/patch/796237/

Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/580272414
---
 arch/arm/mach-imx/spl.c | 11 +++
 common/spl/Kconfig  |  9 +
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 1f230aca3397..daa3d8f7ed94 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -178,7 +178,18 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev, 
const char *name)
 /* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */
 u32 spl_boot_mode(const u32 boot_device)
 {
+/*
+ * When CONFIG_SPL_FORCE_MMC_BOOT is defined the 'boot_device' is used
+ * unconditionally to decide about device to use for booting.
+ * This is crucial for falcon boot mode, when board boots up (i.e. ROM
+ * loads SPL) from slow SPI-NOR memory and afterwards the SPL's 'falcon' boot
+ * mode is used to load Linux OS from eMMC partition.
+ */
+#ifdef CONFIG_SPL_FORCE_MMC_BOOT
+   switch (boot_device) {
+#else
switch (spl_boot_device()) {
+#endif
/* for MMC return either RAW or FAT mode */
case BOOT_DEVICE_MMC1:
case BOOT_DEVICE_MMC2:
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index f467eca2be72..fe800840beb6 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -607,6 +607,15 @@ config SPL_MMC_SUPPORT
  this option to build the drivers in drivers/mmc as part of an SPL
  build.
 
+config SPL_FORCE_MMC_BOOT
+   bool "Force SPL booting from MMC"
+   depends on SPL_MMC_SUPPORT
+   default n
+   help
+ Force SPL to use MMC device for Linux kernel booting even when the
+ SoC ROM recognized boot medium is not eMMC/SD. This is crucial for
+ factory or 'falcon mode' booting.
+
 config SPL_MMC_TINY
bool "Tiny MMC framework in SPL"
depends on SPL_MMC_SUPPORT
-- 
2.11.0

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

Re: [U-Boot] Using CONFIG_ENV_FLAGS_LIST

[Stefano Babic]

On 09/09/19 14:54, Claudius Heine wrote:
> Hi Stefano,
> 
> On 09/09/2019 13.26, Stefano Babic wrote:
>> Hi Claudius,
>>
>> On 02/09/19 16:02, Claudius Heine wrote:
>>> Hi,
>>>
>>> I am currently looking into variable flags in order to make some
>>> variables read-only for secure boot.
>>>
>>> The idea is that the u-boot binary is signed, while the environment
>>> file/partition is not. So the built-in default environment of u-boot can
>>> be trusted, while the external environment cannot. The assumption is
>>> that those flags can be used to customize the validation when the
>>> external environment is loaded or scripts/commands are executed.
>>>
>>> From the '/README' I gather that the access attributes can be any of
>>> "any", "read-only", "write-once" or "change-default".
>>>
>>> I first tried to restrict the variables by choosing 'read-only', but
>>> apparently this applies to the internal environment as well, and now
>>> those variables are not loaded from the internal environment.
>>>
>>> Then I tried 'write-once', this worked now as expected from within
>>> u-boot, but I could modify the environment from the linux userspace via
>>> fw_setenv and those changes appear in u-boot as well. The same for
>>> 'change-default'.
>>>
>>> Is there another way to fill the internal environment variable hash
>>> table, so that 'read-only' works as expected?
>>>
>>> Heiko wrote some patches that change the behavior of the environment
>>> loading so that the internal environment is loaded first before the
>>> external environment.
>>
>> But I think this is not mainlined.
> 
> Correct.
> 
>>
>>> This way 'write-once' should work as expected, but
>>> I think 'read-only' should work that way already and we are missing
>>> something here.
>>
>> But '.flags' shoudl also be set as write once, else it is possible to
>> rewrite the .flags variable making all environment read-write.
>>
>> Heiko's patch is a work-around to get a signed environment. What I had
>> for is to provide a signed environment (outside U-Boot with
>> libubootenv), and U-Boot just verifies as it does for a kernel image -
>> U-Boot does not need a private key, but U-Boot loses "saveenv" and the
>> environment can be changed only from user space.
> 
> Interesting, however loosing 'saveenv' from within u-boot would very
> inconvenient though.

Yes, but saveenv means that the environment must be signed and u-boot
must know the private key, with all consequences. I guess it could go
just with TPM support.

> If the environment signature is invalid, would you
> end up without one or load the internal one as fallback?

The internal is always the falloback - and because if you need this
feature, you have secure boot, U-Boot is signed and then the internal
environment is signed, too.

> If you load the
> internal environment, can it query the external environment verification
> state to handle this case and restore the external environment somehow?

If I understand the question, I think yes. When external environment is
loaded, it could be verified with a public key. And if verified, this
becomes the environment.

Regards,
Stefano


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

[U-Boot] [PATCH v2 4/4] test: dm: spi: Fix sandbox dm_test_spi_find()

[Bin Meng]

Per sandbox_cs_info(), sandbox spi controller only supports chip
select 0. Current test case tries to locate devices on chip select
1, and any call to spi_get_bus_and_cs() or spi_cs_info() with cs
number 1 should not return 0.

This updates the test case to handle it correctly.

Signed-off-by: Bin Meng 

---

Changes in v2:
- new patch to fix sandbox dm_test_spi_find()

 test/dm/spi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test/dm/spi.c b/test/dm/spi.c
index ffd789c..8e417ac 100644
--- a/test/dm/spi.c
+++ b/test/dm/spi.c
@@ -77,10 +77,10 @@ static int dm_test_spi_find(struct unit_test_state *uts)
/* We should be able to add something to another chip select */
ut_assertok(sandbox_sf_bind_emul(state, busnum, cs_b, bus, node,
 "name"));
-   ut_assertok(spi_get_bus_and_cs(busnum, cs_b, speed, mode,
+   ut_asserteq(-EINVAL, spi_get_bus_and_cs(busnum, cs_b, speed, mode,
   "spi_flash_std", "name", , ));
-   ut_assertok(spi_cs_info(bus, cs_b, ));
-   ut_asserteq_ptr(info.dev, slave->dev);
+   ut_asserteq(-EINVAL, spi_cs_info(bus, cs_b, ));
+   ut_asserteq_ptr(NULL, info.dev);
 
/*
 * Since we are about to destroy all devices, we must tell sandbox
-- 
2.7.4

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

[U-Boot] [PATCH v2 3/4] dm: spi: Check cs number before accessing slaves

[Bin Meng]

Add chip select number check in spi_find_chip_select().

Signed-off-by: Bin Meng 

---

Changes in v2:
- move the chip select number check to spi_find_chip_select()

 drivers/spi/spi-uclass.c | 45 ++---
 include/spi.h|  3 ++-
 2 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 24de0b5..cdeceb5 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -179,7 +179,32 @@ int spi_chip_select(struct udevice *dev)
 
 int spi_find_chip_select(struct udevice *bus, int cs, struct udevice **devp)
 {
+   struct dm_spi_ops *ops;
+   struct spi_cs_info info;
struct udevice *dev;
+   int ret;
+
+   /*
+* Ask the driver. For the moment we don't have CS info.
+* When we do we could provide the driver with a helper function
+* to figure out what chip selects are valid, or just handle the
+* request.
+*/
+   ops = spi_get_ops(bus);
+   if (ops->cs_info) {
+   ret = ops->cs_info(bus, cs, );
+   } else {
+   /*
+* We could assume there is at least one valid chip select.
+* The driver didn't care enough to tell us.
+*/
+   ret = 0;
+   }
+
+   if (ret) {
+   printf("Invalid cs %d (err=%d)\n", cs, ret);
+   return ret;
+   }
 
for (device_find_first_child(bus, ); dev;
 device_find_next_child()) {
@@ -214,7 +239,6 @@ int spi_cs_is_valid(unsigned int busnum, unsigned int cs)
 int spi_cs_info(struct udevice *bus, uint cs, struct spi_cs_info *info)
 {
struct spi_cs_info local_info;
-   struct dm_spi_ops *ops;
int ret;
 
if (!info)
@@ -223,24 +247,7 @@ int spi_cs_info(struct udevice *bus, uint cs, struct 
spi_cs_info *info)
/* If there is a device attached, return it */
info->dev = NULL;
ret = spi_find_chip_select(bus, cs, >dev);
-   if (!ret)
-   return 0;
-
-   /*
-* Otherwise ask the driver. For the moment we don't have CS info.
-* When we do we could provide the driver with a helper function
-* to figure out what chip selects are valid, or just handle the
-* request.
-*/
-   ops = spi_get_ops(bus);
-   if (ops->cs_info)
-   return ops->cs_info(bus, cs, info);
-
-   /*
-* We could assume there is at least one valid chip select.
-* The driver didn't care enough to tell us.
-*/
-   return 0;
+   return ret == -ENODEV ? 0 : ret;
 }
 
 int spi_find_bus_and_cs(int busnum, int cs, struct udevice **busp,
diff --git a/include/spi.h b/include/spi.h
index cc344de..6b144bc 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -528,7 +528,8 @@ int spi_chip_select(struct udevice *slave);
  * @bus:   SPI bus to search
  * @cs:Chip select to look for
  * @devp:  Returns the slave device if found
- * @return 0 if found, -ENODEV on error
+ * @return 0 if found, -EINVAL if cs is invalid, -ENODEV if no device attached,
+ *other -ve value on error
  */
 int spi_find_chip_select(struct udevice *bus, int cs, struct udevice **devp);
 
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/4] dm: spi: Return 0 if driver does not implement ops->cs_info

[Bin Meng]

If an SPI controller driver does not implement ops->cs_info, that
probably means any chip select number could be valid, hence let's
return 0 for spi_cs_info().

Signed-off-by: Bin Meng 
Reviewed-by: Jagan Teki 

---

Changes in v2:
- update spi-howto.rst to reflect the code changes

 doc/driver-model/spi-howto.rst | 4 ++--
 drivers/spi/spi-uclass.c   | 7 +++
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/doc/driver-model/spi-howto.rst b/doc/driver-model/spi-howto.rst
index a538fdc..7e64fae 100644
--- a/doc/driver-model/spi-howto.rst
+++ b/doc/driver-model/spi-howto.rst
@@ -634,8 +634,8 @@ method for cs_info() to deal with this. If you don't 
provide it, then the
 device tree will be used to determine what chip selects are valid.
 
 Return -ENODEV if the supplied chip select is invalid, or 0 if it is valid.
-If you don't provide the cs_info() method, -ENODEV is assumed for all
-chip selects that do not appear in the device tree.
+If you don't provide the cs_info() method, 0 is assumed for all chip selects
+that do not appear in the device tree.
 
 
 Test it
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 88cb2a1..24de0b5 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -237,11 +237,10 @@ int spi_cs_info(struct udevice *bus, uint cs, struct 
spi_cs_info *info)
return ops->cs_info(bus, cs, info);
 
/*
-* We could assume there is at least one valid chip select, but best
-* to be sure and return an error in this case. The driver didn't
-* care enough to tell us.
+* We could assume there is at least one valid chip select.
+* The driver didn't care enough to tell us.
 */
-   return -ENODEV;
+   return 0;
 }
 
 int spi_find_bus_and_cs(int busnum, int cs, struct udevice **busp,
-- 
2.7.4

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

[U-Boot] [PATCH v2 2/4] dm: spi: Change cs_info op to return -EINVAL for invalid cs num

[Bin Meng]

We need distinguish the following two situations in various SPI APIs:

- given chip select num is invalid
- given chip select num is valid, but no device is attached

Currently -ENODEV is returned for both cases.

For the first case, it's more reasonable to return -EINVAL instead of
-ENODEV for invalid chip select numbers.

Signed-off-by: Bin Meng 

---

Changes in v2:
- new patch to change cs_info op to return -EINVAL for invalid cs num

 doc/driver-model/spi-howto.rst | 4 ++--
 drivers/spi/ath79_spi.c| 2 +-
 drivers/spi/bcm63xx_hsspi.c| 2 +-
 drivers/spi/bcm63xx_spi.c  | 2 +-
 drivers/spi/sandbox_spi.c  | 2 +-
 drivers/spi/tegra20_sflash.c   | 2 +-
 include/spi.h  | 2 +-
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/driver-model/spi-howto.rst b/doc/driver-model/spi-howto.rst
index 7e64fae..451dc08 100644
--- a/doc/driver-model/spi-howto.rst
+++ b/doc/driver-model/spi-howto.rst
@@ -116,7 +116,7 @@ Put this code at the bottom of your existing driver file:
static int exynos_cs_info(struct udevice *bus, uint cs,
  struct spi_cs_info *info)
{
-   return -ENODEV;
+   return -EINVAL;
}
 
static const struct dm_spi_ops exynos_spi_ops = {
@@ -633,7 +633,7 @@ is not obvious from outside the driver. In this case you 
can provide a
 method for cs_info() to deal with this. If you don't provide it, then the
 device tree will be used to determine what chip selects are valid.
 
-Return -ENODEV if the supplied chip select is invalid, or 0 if it is valid.
+Return -EINVAL if the supplied chip select is invalid, or 0 if it is valid.
 If you don't provide the cs_info() method, 0 is assumed for all chip selects
 that do not appear in the device tree.
 
diff --git a/drivers/spi/ath79_spi.c b/drivers/spi/ath79_spi.c
index 4fd3c05..2070692 100644
--- a/drivers/spi/ath79_spi.c
+++ b/drivers/spi/ath79_spi.c
@@ -198,7 +198,7 @@ static int ath79_cs_info(struct udevice *bus, uint cs,
 {
/* Always allow activity on CS 0/1/2 */
if (cs >= 3)
-   return -ENODEV;
+   return -EINVAL;
 
return 0;
 }
diff --git a/drivers/spi/bcm63xx_hsspi.c b/drivers/spi/bcm63xx_hsspi.c
index 4f527fa7..f1e246e 100644
--- a/drivers/spi/bcm63xx_hsspi.c
+++ b/drivers/spi/bcm63xx_hsspi.c
@@ -108,7 +108,7 @@ static int bcm63xx_hsspi_cs_info(struct udevice *bus, uint 
cs,
 
if (cs >= priv->num_cs) {
printf("no cs %u\n", cs);
-   return -ENODEV;
+   return -EINVAL;
}
 
return 0;
diff --git a/drivers/spi/bcm63xx_spi.c b/drivers/spi/bcm63xx_spi.c
index 4d19e03..69f88c9 100644
--- a/drivers/spi/bcm63xx_spi.c
+++ b/drivers/spi/bcm63xx_spi.c
@@ -130,7 +130,7 @@ static int bcm63xx_spi_cs_info(struct udevice *bus, uint cs,
 
if (cs >= priv->num_cs) {
printf("no cs %u\n", cs);
-   return -ENODEV;
+   return -EINVAL;
}
 
return 0;
diff --git a/drivers/spi/sandbox_spi.c b/drivers/spi/sandbox_spi.c
index 906401e..16473ec 100644
--- a/drivers/spi/sandbox_spi.c
+++ b/drivers/spi/sandbox_spi.c
@@ -117,7 +117,7 @@ static int sandbox_cs_info(struct udevice *bus, uint cs,
 {
/* Always allow activity on CS 0 */
if (cs >= 1)
-   return -ENODEV;
+   return -EINVAL;
 
return 0;
 }
diff --git a/drivers/spi/tegra20_sflash.c b/drivers/spi/tegra20_sflash.c
index a54b10f..567e33f 100644
--- a/drivers/spi/tegra20_sflash.c
+++ b/drivers/spi/tegra20_sflash.c
@@ -78,7 +78,7 @@ int tegra20_sflash_cs_info(struct udevice *bus, unsigned int 
cs,
 {
/* Tegra20 SPI-Flash - only 1 device ('bus/cs') */
if (cs != 0)
-   return -ENODEV;
+   return -EINVAL;
else
return 0;
 }
diff --git a/include/spi.h b/include/spi.h
index 3785941..cc344de 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -438,7 +438,7 @@ struct dm_spi_ops {
 * @cs: The chip select (0..n-1)
 * @info:   Returns information about the chip select, if valid.
 *  On entry info->dev is NULL
-* @return 0 if OK (and @info is set up), -ENODEV if the chip select
+* @return 0 if OK (and @info is set up), -EINVAL if the chip select
 * is invalid, other -ve value on error
 */
int (*cs_info)(struct udevice *bus, uint cs, struct spi_cs_info *info);
-- 
2.7.4

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

Re: [U-Boot] Using CONFIG_ENV_FLAGS_LIST

[Claudius Heine]

Hi Stefano,

On 09/09/2019 13.26, Stefano Babic wrote:
> Hi Claudius,
> 
> On 02/09/19 16:02, Claudius Heine wrote:
>> Hi,
>>
>> I am currently looking into variable flags in order to make some
>> variables read-only for secure boot.
>>
>> The idea is that the u-boot binary is signed, while the environment
>> file/partition is not. So the built-in default environment of u-boot can
>> be trusted, while the external environment cannot. The assumption is
>> that those flags can be used to customize the validation when the
>> external environment is loaded or scripts/commands are executed.
>>
>> From the '/README' I gather that the access attributes can be any of
>> "any", "read-only", "write-once" or "change-default".
>>
>> I first tried to restrict the variables by choosing 'read-only', but
>> apparently this applies to the internal environment as well, and now
>> those variables are not loaded from the internal environment.
>>
>> Then I tried 'write-once', this worked now as expected from within
>> u-boot, but I could modify the environment from the linux userspace via
>> fw_setenv and those changes appear in u-boot as well. The same for
>> 'change-default'.
>>
>> Is there another way to fill the internal environment variable hash
>> table, so that 'read-only' works as expected?
>>
>> Heiko wrote some patches that change the behavior of the environment
>> loading so that the internal environment is loaded first before the
>> external environment.
> 
> But I think this is not mainlined.

Correct.

> 
>> This way 'write-once' should work as expected, but
>> I think 'read-only' should work that way already and we are missing
>> something here.
> 
> But '.flags' shoudl also be set as write once, else it is possible to
> rewrite the .flags variable making all environment read-write.
> 
> Heiko's patch is a work-around to get a signed environment. What I had
> for is to provide a signed environment (outside U-Boot with
> libubootenv), and U-Boot just verifies as it does for a kernel image -
> U-Boot does not need a private key, but U-Boot loses "saveenv" and the
> environment can be changed only from user space.

Interesting, however loosing 'saveenv' from within u-boot would very
inconvenient though. If the environment signature is invalid, would you
end up without one or load the internal one as fallback? If you load the
internal environment, can it query the external environment verification
state to handle this case and restore the external environment somehow?

regards,
Claudius

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

   PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
 Keyserver: hkp://pool.sks-keyservers.net



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

Re: [U-Boot] Using CONFIG_ENV_FLAGS_LIST

[Lukasz Majewski]

Hi Claudius,

> Hi Lukasz,
> 
> On 07/09/2019 00.23, Lukasz Majewski wrote:
> > Hi Claudius,
> >   
> >> Hi,
> >>
> >> I am currently looking into variable flags in order to make some
> >> variables read-only for secure boot.
> >>
> >> The idea is that the u-boot binary is signed, while the environment
> >> file/partition is not. So the built-in default environment of
> >> u-boot can be trusted, while the external environment cannot. The
> >> assumption is that those flags can be used to customize the
> >> validation when the external environment is loaded or
> >> scripts/commands are executed.
> >>
> >> From the '/README' I gather that the access attributes can be any
> >> of "any", "read-only", "write-once" or "change-default".
> >>
> >> I first tried to restrict the variables by choosing 'read-only',
> >> but apparently this applies to the internal environment as well,
> >> and now those variables are not loaded from the internal
> >> environment.
> >>
> >> Then I tried 'write-once', this worked now as expected from within
> >> u-boot, but I could modify the environment from the linux userspace
> >> via fw_setenv and those changes appear in u-boot as well. The same
> >> for 'change-default'.
> >>
> >> Is there another way to fill the internal environment variable hash
> >> table, so that 'read-only' works as expected?
> >>
> >> Heiko wrote some patches that change the behavior of the
> >> environment loading so that the internal environment is loaded
> >> first before the external environment. This way 'write-once'
> >> should work as expected, but I think 'read-only' should work that
> >> way already and we are missing something here.  
> > 
> > I think that Wolfgang had a long discussion with Takahiro AKASHI
> > (both CC'ed) about similar problem with u-boot envs.  
> 
> Were there any conclusions here?

I don't know if there was any conclusion (or patches).

> 
> For me this 'flags' feature looks more and more like its was not build
> to save guard the loading from unsigned and untrusted external
> environments. I think what we would need here is some sort of variable
> whitelist with some additional checks (type and size), but still allow
> the u-boot scripts and commands to modify the variables in the hash
> table (for filesize, ipaddr etc.) at boot time.


Maybe Takahiro could shed some light on his work and you could discuss
if your both work could be aligned?


> 
> regards,
> Claudius
> 
> > 
> > For example:
> > https://patchwork.ozlabs.org/patch/1158770/
> >   
> >>
> >> Thanks,
> >> Claudius
> >>  
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lu...@denx.de 
> 



Best regards,

Lukasz Majewski

--

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


pgpBTPVlKAXtN.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/3] spi: Split CONFIG_DM_SPI* to CONFIG_{SPL_TPL}DM_SPI*

[Lukasz Majewski]

On Mon, 9 Sep 2019 11:11:50 +
Schrempf Frieder  wrote:

> Hi Lukasz,
> 
> On 05.09.19 20:09, Tom Rini wrote:
> > On Thu, Sep 05, 2019 at 12:16:36AM +0200, Lukasz Majewski wrote:  
> >> This patch series introduces new SPL and TPL specific Kconfig
> >> entries for DM_SPI* options. Such change allows using the spi
> >> driver in SPL/TPL or U-Boot proper.
> >>
> >> First two patches - related to ls10{42}* NXP soc fix some issues
> >> with defining the DM_SPI* defines in .h file instead of
> >> Kconfig.
> >>
> >> This series doesn't introduce build breaks, but board maintainers
> >> are kindly asked to check if their boards still boots.
> >>
> >> Buildman setup for binary size regression checking:
> >>
> >> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
> >> --output-dir=../BUILD/ --force-build -CveE
> >> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
> >> --output-dir=../BUILD/ -Ssdel  
> > 
> > So you did fix the ls1043 problems but ls1046 is still a problem.  
> 
> I was trying to clean up this config mess some weeks ago. I stumbled 
> over the same issues (size deltas below) when I tested with buildman
> and finally gave up on it. This was my testing branch for reference:
> [1].
> 
> Thanks for your work and I hope you/we can get this sorted out
> somehow...

For now I've only posted the patch to introduce SPL_DM_SPI in Kconig:
https://patchwork.ozlabs.org/patch/1159655/

> 
> Regards,
> Frieder
> 
> [1]:
> https://github.com/fschrempf/u-boot/commits/non_dm_spi_flash_in_spl
> 
> > There's also changes in (add 'B' to the buildman flags above for
> > this info):
> > x86: (for 26/26 boards) spl/u-boot-spl:all -31.6
> > spl/u-boot-spl:data -11.4 spl/u-boot-spl:rodata -6.3
> > spl/u-boot-spl:text -13.9 qemu-x86_64: spl/u-boot-spl:all -821
> > spl/u-boot-spl:data -296 spl/u-boot-spl:rodata -164
> > spl/u-boot-spl:text -361 spl-u-boot-spl: add: 0/-10, grow: 0/0
> > bytes: 0/-657 (-657) function   old
> > new   delta spi_flash_post_bind  3
> >  -  -3 dev_get_parent_priv 11   -
> >   -11 spi_post_probe  35   -
> > -35 spi_child_post_bind 37   - -37
> > spi_child_pre_probe 46   - -46
> > _u_boot_list_2_driver_2_spi_generic_drv  68   - -68
> > _u_boot_list_2_uclass_2_spi_nor 76   - -76
> > _u_boot_list_2_uclass_2_spi_generic 76   - -76
> > _u_boot_list_2_uclass_2_spi 76   - -76
> > spi_slave_ofdata_to_platdata   229   --229 arm:
> > (for 688/688 boards) all -19.6 bss -4.5 rodata -2.2
> > spl/u-boot-spl:all -12.2 spl/u-boot-spl:bss -1.1
> > spl/u-boot-spl:data -1.9 spl/u-boot-spl:rodata -2.0
> > spl/u-boot-spl:text -7.2 text -12.9 uniphier_v7: bss -8 rodata
> > +8 opos6uldev : bss -8 rodata +8 uniphier_ld4_sld8: bss -8
> > rodata +8 da850evm   : spl/u-boot-spl:all -614
> > spl/u-boot-spl:data -144 spl/u-boot-spl:rodata -150
> > spl/u-boot-spl:text -320 spl-u-boot-spl: add: 2/-15, grow: 2/0
> > bytes: 112/-574 (-462) function
> > old new   delta spi_flash_probe 38
> > 82 +44 spi_setup_slave  -
> > 42 +42 spl_spi_load_image 124 144
> >   +20 spi_free_slave   -   6
> > +6 spi_flash_std_remove 4   -  -4
> > spi_flash_post_bind  4   -  -4
> > spi_flash_cmd_get_sw_write_prot  8   -  -8
> > aeabi_uidivmod_from_thumb8   -  -8
> > spi_flash_std_get_sw_write_prot 18   - -18
> > spi_flash_read_dm   20   - -20
> > __aeabi_uidivmod24   - -24
> > __aeabi_idivmod 24   - -24
> > spi_flash_std_write 42   - -42
> > spi_flash_std_read  42   - -42
> > spi_flash_probe_bus_cs  56   - -56
> > _u_boot_list_2_driver_2_spi_flash_std   68   - -68
> > _u_boot_list_2_uclass_2_spi_nor 76   - -76
> > spi_flash_std_probe 88   - -88
> > spi_flash_std_erase 92   - -92
> > da850evm_nand  : spl/u-boot-spl:all -614 spl/u-boot-spl:data -144
> > spl/u-boot-spl:rodata -150 spl/u-boot-spl:text -320 spl-u-boot-spl:
> > add: 2/-15, grow: 2/0 bytes: 112/-574 (-462) function
> > old new   delta spi_flash_probe
> > 38  82 +44 spi_setup_slave
> > -  42 +42 spl_spi_load_image
> >  124 144 +20 spi_free_slave
> >   -   6  +6 spi_flash_std_remove 4
> >  -  -4 spi_flash_post_bind   

Re: [U-Boot] [RFC] xz compression for U-Boot images

[Wolfgang Denk]

Dear Heinrich,

In message <845c6856-5a75-2789-18d1-a1e8f9d1f...@gmx.de> you wrote:
> 
> Are you aware off any prior efforts to prepend U-Boot with a
> self-extractor?

No - why add yet aother level of complexity?

> With xz a U-Boot image can be compressed by a factor of more than 2.5.
> The self-extractor would have to comprise RAM setup (if not handled by
> SPL), the decompression code, and the cache reset.

Why not adding the decompression stage into SPL, then?

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
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy  arrangement  for
the people.   - Eleanor Roosevelt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver

[Jean-Jacques Hiblot]

Hi Sherry,

On 03/09/2019 14:44, Sherry Sun wrote:

Hi Jean,



On 02/09/2019 13:29, Sherry Sun wrote:

Hi Vignesh,


Hi Sherry,

[...]

AFAIK, U-Boot does not support runtime switching of USB port to
host from device and vice versa. This is the case for existing
driver like

DWC3/MUSB etc.

Ideally we would need a role switch driver that unbinds and rebinds
host vs device driver as when required based on U-Boot cmd or via
an API (if required to be done during SPL stage etc).

I wonder if we can add two subnodes under the wrapper node as below,

one bind to usb gadget driver and another bind to usb host driver.

So if we want to use usb device, just call the gadget driver, and if
want to

use usb host, just call the host driver. The driver will probe correspond

node.

I'm not sure if it is feasible, what do you think about it?

usbss0: cdns_usb@4104000 {
compatible = "ti,j721e-usb";
[]
usb0: usb@601 { /* xhci reg address*/
compatible = "cdns,usb3-1.0.1";
dr_mode = "host";
[]
}
usb1: usb@602 { /* dev reg address*/
compatible = "cdns,usb3-1.0.1";
dr_mode = "peripheral";
[]
}
  }


But this is not how DT would look in kernel. There will be single DT
node representing both Host and Device node. DT repesentation should
not be changed based on OS/bootloader, its HW description and must

remain same.

Unbinding host/gadget driver and rebinding with a different role
should not be hard as the U-Boot core infrastructure exists.

Moreover if xhci reg and dev reg are separated into different nodes
dont we still need access to OTG register block to switch b/w host and

device mode?

I think we may not need to access OTG register if we add two subnodes for

gadget and host.

But I see a for loop in dwc3_glue_bind() as follows, if there only one single

node representing both Host and Device node under usb wrapper node, why
we need this for loop?

212 for (node = fdt_first_subnode(fdt, dev_of_offset(parent)); node > 0;
213  node = fdt_next_subnode(fdt, node)) {

I believe this is a legacy from the code it was inspired from.

Indeed the loop is not required.

Like Vignesh I think we must stick with the dt-bindings used by the kernel.

Thanks for your reply, I understand now.


BTW we are working on the USB3 support right now that is lacking in our tree.
I choose to keep the PHY drivers as close as possible to their linux version. 
I'll
probably start posting preliminary patches this week.

If you have the USB3 working in the kernel, can you point to a tree where I
can have a look at the drivers and dt-bindings ?

Sure, you can see our downstream kernel code at my github, here is the link 
address: https://github.com/sherrysun1/linux-imx.git.
And look forward to seeing your patches in uboot maillist.


It will take some times before I can post on the mailing list because I 
did the work on top TI's u-boot. But you can find the patches under 
https://github.com/jjhiblot/u-boot/tree/usb3_cleanup_v2. 



The DTS bindings are the same as under Linux. The CDNS3 driver is a port 
of the iteration v11 of the linux driver that has just been merged in 
the linux usb tree 
(https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git/log/?h=next)


Care has been taken to keep the changes with linux minimal to ease the 
maintenance: the drivers are quite new and will probably evolve quite a 
bit in the next few months.


JJ



Best regards
Sherry sun


JJ


Best regards
Sherry sun


Regards
Vignesh


Best regards
Sherry sun


Regards
Vignesh


Best regards
Sherry sun


JJ


Then when binding the wrapper node, it will hard-coded the two

subnodes

to different driver(gadge/host driver) according to the dr_mode
property

in

nodes.


Do you think I understand it right?
Best regards
Sherry sun


Best regards
Sherry sun


JJ




+   { }
+};

___
U-Boot mailing list
U-Boot@lists.denx.de
https://l


ists.ddata=02%7C01%7Csherry.sun%40nxp.com%7C7d1d76a7124f4c3f

e9

9d08d72d3ddf82%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63

70276

16080089878sdata=70BPVQkomokcNpxsHRD3njfZQvuG51VSD1QKBjQ

o1kA%3

Dreserved=0
enx.de%2Flistinfo%2Fu-


bootdata=02%7C01%7Csherry.sun%40nxp.com%7C35f1d34da1ea4b7
670ba08d72b823e9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
C637025710721487079sdata=Nfk0qWtSViz60wJHAOr2m5tgIwTWjNwI

GrNOxDH6HC0%3Dreserved=0

--
Regards
Vignesh

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

Re: [U-Boot] [PATCH] rpi4: enable dram bank initialization

[Andrei Gherzan]

On 06/09/2019 13.58, Matthias Brugger wrote:
>
> On 06/09/2019 14:11, Alexander Graf wrote:
>> On 06.09.19 13:56, matthias@kernel.org wrote:
>>> From: Matthias Brugger 
>>>
>>> When booting through the efi stub, the memory map get's created by
>>> reading the dram bank information. Depending on the version of the RPi4
>>> this information changes. Read the device tree to initialize the dram
>>> bank data structure. This way the kernel is able to access the whole
>>> range of available memory.
>>>
>>> Signed-off-by: Matthias Brugger 
>>> ---
>>> This patch is based on basic RPi4 support implemented by series:
>>> https://www.mail-archive.com/u-boot@lists.denx.de/msg335667.html
>>>
>>> To actually work correctly we need the series that fixes the libftd:
>>> https://patchwork.ozlabs.org/cover/1158304/
>>>
>>>   board/raspberrypi/rpi/rpi.c | 8 
>>>   configs/rpi_4_defconfig | 2 +-
>>>   2 files changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>>> index fa57d50c95..eea8a69551 100644
>>> --- a/board/raspberrypi/rpi/rpi.c
>>> +++ b/board/raspberrypi/rpi/rpi.c
>>> @@ -312,6 +312,14 @@ int dram_init(void)
>>>   return 0;
>>>   }
>>>   +#ifdef CONFIG_BCM2711
>>> +int dram_init_banksize(void)
>>> +{
>>> +    return fdtdec_decode_ram_size(gd->fdt_blob, NULL, 0, NULL,
>>
>> This also depends on CONFIG_OF_BOARD, no?
>>
> I would need to double check if at this point gd->fdt_blob is in it's final
> state or might get updated afterwards.
>
> Actually I think we should change all RPi configs to OF_BOARD, which would 
> also
> be necessary to implement a single binary for RPi3 and RPi4. But that's 
> another
> story.
Looks good to me.

-- 
Andrei Gherzan
Head Of Devices | balena.io
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan

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

[U-Boot] u-boot working version for Rasberry Pi 4

[Sachin Mehrotra]

Dear Concern,

I am working for u-boot for rpi4, may I know do we have updated working version 
for Raspberry Pi 4.
I was testing the version https://gitlab.denx.de/u-boot/u-boot with 
rpi4 but getting error in 
file arch/arm/cpu/armv8/cpu.c:13 if I run for raspberry pi 4.

Please guide or send me the link for the working version of u-boot for 
rasbessry pi 4

Thanks in advance.

Best Regards / Mit freundlichen Grüßen,
Sachin Mehrotra
Application Engineer
Security Solution Center
Phone: +49  89 12 22 32 533

Swissbit AG
BU Security
Leuchtenbergring 3
D-81677 Munich
Germany


Email:  
sachin.mehro...@swissbit.com
Website: www.swissbit.com

[swissbit]

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

Re: [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory...

[Moses Christopher]

Hi Simon,


Thanks for the prompt reply.

On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, <
simon.k.r.goldschm...@gmail.com> wrote:

Hi,

On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher
 wrote:
> Hello together,
>
> I was trying to build u-boot and spl for the arm target and tried to boot
via usb-ethernet.
> I found an issue with one of the commit made in the early 2019,
> http://patchwork.ozlabs.org/patch/1024795/
>
> When using this CONFIG_LMB the max_size or the lmb_get_free_size(,
load_addr); returns 0, no matter what.
> And it triggers the following error,
> TFTP error: trying to overwrite reserved memory...
> I did a quick fix by adding #undef CONFIG_LMB in the file, net/tftp.c
> So, I would like to know why this doesn’t work as it was working before
applying this patch ?

Can you add "#define DEBUG" as the first line in 'lib/lmb.c'? That
should give you debug
output when lmb is used.


I did add DEBUG macro to lmb.c but the function having the debug messages
isn't getting called. I suppose it was from fs/fs.c

FYI,
I'm trying to load SPL and uboot on RAM, using USB-ETH. Also the
environment is not stored separately, neither the device tree.


The lmb code works by getting the RAM size, adding reserved areas and then
only
allowing allocations in non-reserved areay. However, the RAM size is
not fully used
depending on some config options and/or environment variables. There's
possibly
something wrong in your configuration around that.


Because, earlier to this patch, net/tftp.c isn't actually checking for the
reserved memory regions and is able to download the files properly on the
RAM and it works. I know, that's not a good approach, hence you've made the
necessary changes to correct it.

Could you kindly provide me some information, where I can read more about
the reserved memory regions and how exactly some region is treated as
reserved region ?

Also, it'd be great if you could provide some information related to the
configuration of Reserved and free addresses of RAM.

Thank you for your patience and time.

Regards,
Simon

>
> Best regards,
> Moses Christopher

Best regards,
Moses Christopher
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode

[Stefano Babic]

On 09/09/19 10:02, Lukasz Majewski wrote:
> Hi Heiko, Stefano
> 
>> Hello Lukasz,
>>
>> Am 05.09.2019 um 11:42 schrieb Lukasz Majewski:
>>> Hi Stefano,
>>>   
 On 04/09/19 12:35, Lukasz Majewski wrote:  
> On Wed, 4 Sep 2019 11:54:40 +0200
> Lukasz Majewski  wrote:
>  
>> Hi Stefano, Heiko,
>> 
>>> On 04/09/19 10:46, Lukasz Majewski wrote:  
 Hi Heiko,
  
> Hello Lukasz,
>
> added Stefano to cc as he is the imx custodian.  

 I've relied on patman ... Thanks for adding Stefano to CC.
  
>
> Am 03.09.2019 um 23:43 schrieb Lukasz Majewski:  
>> This change tries to fix the following problem:
>>
>> - The board boots (to be more precise - ROM loads SPL) from a
>> slow SPI-NOR memory.
>> As a result the spl_boot_device() will return SPI-NOR as
>> a boot device (which is correct).
>>
>> - The problem is that in 'falcon boot' the eMMC is used as a
>> boot medium to load kernel from its partition.
>> Calling spl_boot_device() will break things as it returns
>> SPI-NOR device.
>>
>> To fix this issue the new CONFIG_SPL_FORCE_MMC_BOOT Kconfig
>> flag is introduced to handle this special use case. By
>> default it is not defined, so there is no change in the
>> legacy code flow.
>>
>> Signed-off-by: Lukasz Majewski 
>>
>>
>> ---
>>
>> This patch is a follow up of previous discussion/fix:
>> https://patchwork.ozlabs.org/patch/796237/
>>
>> Travis-CI:
>> https://travis-ci.org/lmajewski/u-boot-dfu/builds/580272414
>> ---
>>arch/arm/mach-imx/spl.c | 11 +++
>>common/spl/Kconfig  |  7 +++
>>2 files changed, 18 insertions(+)  
>
> I have just similiar change for an imx6ull based board ...  

 Also one more of my boards uses this trick (i.MX28 based one).
  
> just antoher usecase: In factory empty board boots into USB
> SDP mode, and SPL gets loaded with usb_loader ... SPL detects
> a sd card (there is no sd card slot mounted, mmc boot is
> disabled! They attach only one for installing software)  

 So there is no dedicated SD card slot (also the mmc is disabled
 on that point).
 Instead, in the factory the sd card is attached to pads - just
 for this time.
  
> and boots U-Boot and system from sd card.
> Than all software gets installed fully automated with the help
> of swupdate ...  

 Ok.
  
> 
>> diff --git a/arch/arm/mach-imx/spl.c
>> b/arch/arm/mach-imx/spl.c index 1f230aca3397..daa3d8f7ed94
>> 100644 --- a/arch/arm/mach-imx/spl.c
>> +++ b/arch/arm/mach-imx/spl.c
>> @@ -178,7 +178,18 @@ int g_dnl_bind_fixup(struct
>> usb_device_descriptor *dev, const char *name) /* called from
>> spl_mmc to see type of boot mode for storage (RAW or FAT) */
>> u32 spl_boot_mode(const u32 boot_device) {
>> +/*
>> + * When CONFIG_SPL_FORCE_MMC_BOOT is defined the
>> 'boot_device' is used
>> + * unconditionally to decide about device to use for
>> booting.
>> + * This is crucial for falcon boot mode, when board boots up
>> (i.e. ROM
>> + * loads SPL) from slow SPI-NOR memory and afterwards the
>> SPL's 'falcon' boot
>> + * mode is used to load Linux OS from eMMC partition.
>> + */
>> +#ifdef CONFIG_SPL_FORCE_MMC_BOOT
>> +switch (boot_device) {
>> +#else
>>  switch (spl_boot_device()) {
>> +#endif  
>
> Just dummy question .. couldn;t we switch to use always
> boot_device?  

 Stefano has provided some rationale for the need of
 spl_boot_device() in the previous version of this fix [1]:

 https://patchwork.ozlabs.org/patch/796237/

  
>
> In my case I had a board specific:
>
> void board_boot_order(u32 *spl_boot_list)
> {
>   spl_boot_list[0] = BOOT_DEVICE_MMC1;
>   spl_boot_list[1] = BOOT_DEVICE_SPI;
>   spl_boot_list[2] = BOOT_DEVICE_BOARD;
>   spl_boot_list[3] = BOOT_DEVICE_NONE;
> }
>
> which leads that BOOT_DEVICE_MMC1 is passed to spl_boot_mode()
>   

 Is your board normally booting from MMC or SPI-NOR (from where
 SoC ROM loads SPL) ?
  
>
> If MMC1 is not found, it tries to boot U-Boot from SPI, and if
> this is empty, as fallback 

Re: [U-Boot] Using CONFIG_ENV_FLAGS_LIST

[Stefano Babic]

Hi Claudius,

On 02/09/19 16:02, Claudius Heine wrote:
> Hi,
> 
> I am currently looking into variable flags in order to make some
> variables read-only for secure boot.
> 
> The idea is that the u-boot binary is signed, while the environment
> file/partition is not. So the built-in default environment of u-boot can
> be trusted, while the external environment cannot. The assumption is
> that those flags can be used to customize the validation when the
> external environment is loaded or scripts/commands are executed.
> 
> From the '/README' I gather that the access attributes can be any of
> "any", "read-only", "write-once" or "change-default".
> 
> I first tried to restrict the variables by choosing 'read-only', but
> apparently this applies to the internal environment as well, and now
> those variables are not loaded from the internal environment.
> 
> Then I tried 'write-once', this worked now as expected from within
> u-boot, but I could modify the environment from the linux userspace via
> fw_setenv and those changes appear in u-boot as well. The same for
> 'change-default'.
> 
> Is there another way to fill the internal environment variable hash
> table, so that 'read-only' works as expected?
> 
> Heiko wrote some patches that change the behavior of the environment
> loading so that the internal environment is loaded first before the
> external environment.

But I think this is not mainlined.

> This way 'write-once' should work as expected, but
> I think 'read-only' should work that way already and we are missing
> something here.

But '.flags' shoudl also be set as write once, else it is possible to
rewrite the .flags variable making all environment read-write.

Heiko's patch is a work-around to get a signed environment. What I had
for is to provide a signed environment (outside U-Boot with
libubootenv), and U-Boot just verifies as it does for a kernel image -
U-Boot does not need a private key, but U-Boot loses "saveenv" and the
environment can be changed only from user space.

Regards,
Stefano



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

Re: [U-Boot] [PATCH] MAINTAINERS: Change fsl-qoriq, mpc86xx, mpc85xx maintainers

[Prabhakar Kushwaha]

> -Original Message-
> From: U-Boot  On Behalf Of Prabhakar
> Kushwaha
> Sent: Monday, September 9, 2019 4:55 PM
> To: u-boot@lists.denx.de
> Cc: tr...@konsulko.com; York Sun ; Priyanka Jain
> 
> Subject: [U-Boot] [PATCH] MAINTAINERS: Change fsl-qoriq, mpc86xx, mpc85xx
> maintainers
> 
> From: Priyanka Jain 
> 
> Change maintainers to Priyanka Jain for fsl-qoriq, mpc85xx
> 
> Signed-off-by: Priyanka Jain 
> ---

Acked-by: Prabhakar Kushwaha 

--pk

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

[U-Boot] [PATCH] MAINTAINERS: Change fsl-qoriq, mpc86xx, mpc85xx maintainers

[Prabhakar Kushwaha]

From: Priyanka Jain 

Change maintainers to Priyanka Jain for fsl-qoriq, mpc85xx

Signed-off-by: Priyanka Jain 
---
 MAINTAINERS | 6 +++---
 board/freescale/mpc8536ds/MAINTAINERS   | 2 +-
 board/freescale/mpc8541cds/MAINTAINERS  | 2 +-
 board/freescale/mpc8544ds/MAINTAINERS   | 2 +-
 board/freescale/mpc8548cds/MAINTAINERS  | 2 +-
 board/freescale/mpc8555cds/MAINTAINERS  | 2 +-
 board/freescale/mpc8568mds/MAINTAINERS  | 2 +-
 board/freescale/mpc8569mds/MAINTAINERS  | 2 +-
 board/freescale/mpc8572ds/MAINTAINERS   | 2 +-
 board/freescale/mpc8610hpcd/MAINTAINERS | 2 +-
 board/freescale/mpc8641hpcn/MAINTAINERS | 2 +-
 doc/git-mailrc  | 8 
 12 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 08222fd569..e752e4b3de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -565,7 +565,7 @@ S:  Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-freebsd.git
 
 FREESCALE QORIQ
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git
 F: drivers/watchdog/sp805_wdt.c
@@ -723,13 +723,13 @@ F:arch/powerpc/cpu/mpc83xx/
 F: arch/powerpc/include/asm/arch-mpc83xx/
 
 POWERPC MPC85XX
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx.git
 F: arch/powerpc/cpu/mpc85xx/
 
 POWERPC MPC86XX
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-mpc86xx.git
 F: arch/powerpc/cpu/mpc86xx/
diff --git a/board/freescale/mpc8536ds/MAINTAINERS 
b/board/freescale/mpc8536ds/MAINTAINERS
index d640f89845..5ce5164e49 100644
--- a/board/freescale/mpc8536ds/MAINTAINERS
+++ b/board/freescale/mpc8536ds/MAINTAINERS
@@ -1,5 +1,5 @@
 MPC8536DS BOARD
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 F: board/freescale/mpc8536ds/
 F: include/configs/MPC8536DS.h
diff --git a/board/freescale/mpc8541cds/MAINTAINERS 
b/board/freescale/mpc8541cds/MAINTAINERS
index 100077608b..cf3b9cf5f7 100644
--- a/board/freescale/mpc8541cds/MAINTAINERS
+++ b/board/freescale/mpc8541cds/MAINTAINERS
@@ -1,5 +1,5 @@
 MPC8541CDS BOARD
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 F: board/freescale/mpc8541cds/
 F: include/configs/MPC8541CDS.h
diff --git a/board/freescale/mpc8544ds/MAINTAINERS 
b/board/freescale/mpc8544ds/MAINTAINERS
index 78019fbfea..74e7249e47 100644
--- a/board/freescale/mpc8544ds/MAINTAINERS
+++ b/board/freescale/mpc8544ds/MAINTAINERS
@@ -1,5 +1,5 @@
 MPC8544DS BOARD
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 F: board/freescale/mpc8544ds/
 F: include/configs/MPC8544DS.h
diff --git a/board/freescale/mpc8548cds/MAINTAINERS 
b/board/freescale/mpc8548cds/MAINTAINERS
index 385dc85576..fbbedb1d1d 100644
--- a/board/freescale/mpc8548cds/MAINTAINERS
+++ b/board/freescale/mpc8548cds/MAINTAINERS
@@ -1,5 +1,5 @@
 MPC8548CDS BOARD
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 F: board/freescale/mpc8548cds/
 F: include/configs/MPC8548CDS.h
diff --git a/board/freescale/mpc8555cds/MAINTAINERS 
b/board/freescale/mpc8555cds/MAINTAINERS
index 815cffec1b..8f32febd91 100644
--- a/board/freescale/mpc8555cds/MAINTAINERS
+++ b/board/freescale/mpc8555cds/MAINTAINERS
@@ -1,5 +1,5 @@
 MPC8555CDS BOARD
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 F: board/freescale/mpc8555cds/
 F: include/configs/MPC8555CDS.h
diff --git a/board/freescale/mpc8568mds/MAINTAINERS 
b/board/freescale/mpc8568mds/MAINTAINERS
index 79f04d1a90..f4747866d2 100644
--- a/board/freescale/mpc8568mds/MAINTAINERS
+++ b/board/freescale/mpc8568mds/MAINTAINERS
@@ -1,5 +1,5 @@
 MPC8568MDS BOARD
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 F: board/freescale/mpc8568mds/
 F: include/configs/MPC8568MDS.h
diff --git a/board/freescale/mpc8569mds/MAINTAINERS 
b/board/freescale/mpc8569mds/MAINTAINERS
index b2e3bdfa11..9df3f3cca8 100644
--- a/board/freescale/mpc8569mds/MAINTAINERS
+++ b/board/freescale/mpc8569mds/MAINTAINERS
@@ -1,5 +1,5 @@
 MPC8569MDS BOARD
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 F: board/freescale/mpc8569mds/
 F: include/configs/MPC8569MDS.h
diff --git a/board/freescale/mpc8572ds/MAINTAINERS 
b/board/freescale/mpc8572ds/MAINTAINERS
index 80a3096653..d7e9b1f41f 100644
--- a/board/freescale/mpc8572ds/MAINTAINERS
+++ b/board/freescale/mpc8572ds/MAINTAINERS
@@ -1,5 +1,5 @@
 MPC8572DS BOARD
-M: Prabhakar Kushwaha 
+M: Priyanka Jain 
 S: Maintained
 F: board/freescale/mpc8572ds/
 F: include/configs/MPC8572DS.h
diff --git a/board/freescale/mpc8610hpcd/MAINTAINERS 
b/board/freescale/mpc8610hpcd/MAINTAINERS
index 633c5ed192..9b1e0cd4e5 100644
--- 

Re: [U-Boot] [PATCH v3 0/3] spi: Split CONFIG_DM_SPI* to CONFIG_{SPL_TPL}DM_SPI*

[Schrempf Frieder]

Hi Lukasz,

On 05.09.19 20:09, Tom Rini wrote:
> On Thu, Sep 05, 2019 at 12:16:36AM +0200, Lukasz Majewski wrote:
>> This patch series introduces new SPL and TPL specific Kconfig entries for
>> DM_SPI* options. Such change allows using the spi driver in SPL/TPL or
>> U-Boot proper.
>>
>> First two patches - related to ls10{42}* NXP soc fix some issues with
>> defining the DM_SPI* defines in .h file instead of Kconfig.
>>
>> This series doesn't introduce build breaks, but board maintainers are kindly
>> asked to check if their boards still boots.
>>
>> Buildman setup for binary size regression checking:
>>
>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043 --output-dir=../BUILD/ 
>> --force-build -CveE
>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043 --output-dir=../BUILD/ 
>> -Ssdel
> 
> So you did fix the ls1043 problems but ls1046 is still a problem.

I was trying to clean up this config mess some weeks ago. I stumbled 
over the same issues (size deltas below) when I tested with buildman and 
finally gave up on it. This was my testing branch for reference: [1].

Thanks for your work and I hope you/we can get this sorted out somehow...

Regards,
Frieder

[1]: https://github.com/fschrempf/u-boot/commits/non_dm_spi_flash_in_spl

> There's also changes in (add 'B' to the buildman flags above for this
> info):
> x86: (for 26/26 boards) spl/u-boot-spl:all -31.6 spl/u-boot-spl:data 
> -11.4 spl/u-boot-spl:rodata -6.3 spl/u-boot-spl:text -13.9
>  qemu-x86_64: spl/u-boot-spl:all -821 spl/u-boot-spl:data 
> -296 spl/u-boot-spl:rodata -164 spl/u-boot-spl:text -361
> spl-u-boot-spl: add: 0/-10, grow: 0/0 bytes: 0/-657 (-657)
>   function   old new   
> delta
>   spi_flash_post_bind  3   -  
> -3
>   dev_get_parent_priv 11   - 
> -11
>   spi_post_probe  35   - 
> -35
>   spi_child_post_bind 37   - 
> -37
>   spi_child_pre_probe 46   - 
> -46
>   _u_boot_list_2_driver_2_spi_generic_drv  68   - 
> -68
>   _u_boot_list_2_uclass_2_spi_nor 76   - 
> -76
>   _u_boot_list_2_uclass_2_spi_generic 76   - 
> -76
>   _u_boot_list_2_uclass_2_spi 76   - 
> -76
>   spi_slave_ofdata_to_platdata   229   -
> -229
> arm: (for 688/688 boards) all -19.6 bss -4.5 rodata -2.2 
> spl/u-boot-spl:all -12.2 spl/u-boot-spl:bss -1.1 spl/u-boot-spl:data -1.9 
> spl/u-boot-spl:rodata -2.0 spl/u-boot-spl:text -7.2 text -12.9
>  uniphier_v7: bss -8 rodata +8
>  opos6uldev : bss -8 rodata +8
>  uniphier_ld4_sld8: bss -8 rodata +8
>  da850evm   : spl/u-boot-spl:all -614 spl/u-boot-spl:data 
> -144 spl/u-boot-spl:rodata -150 spl/u-boot-spl:text -320
> spl-u-boot-spl: add: 2/-15, grow: 2/0 bytes: 112/-574 (-462)
>   function   old new   
> delta
>   spi_flash_probe 38  82 
> +44
>   spi_setup_slave  -  42 
> +42
>   spl_spi_load_image 124 144 
> +20
>   spi_free_slave   -   6  
> +6
>   spi_flash_std_remove 4   -  
> -4
>   spi_flash_post_bind  4   -  
> -4
>   spi_flash_cmd_get_sw_write_prot  8   -  
> -8
>   aeabi_uidivmod_from_thumb8   -  
> -8
>   spi_flash_std_get_sw_write_prot 18   - 
> -18
>   spi_flash_read_dm   20   - 
> -20
>   __aeabi_uidivmod24   - 
> -24
>   __aeabi_idivmod 24   - 
> -24
>   spi_flash_std_write 42   - 
> -42
>   spi_flash_std_read  42   - 
> -42
>   spi_flash_probe_bus_cs  56   - 
> -56
>   _u_boot_list_2_driver_2_spi_flash_std   68   - 
> -68
>   _u_boot_list_2_uclass_2_spi_nor 76   - 
> -76
>   spi_flash_std_probe 88   - 
> -88
>   spi_flash_std_erase 92   - 
> -92
>  da850evm_nand  : spl/u-boot-spl:all -614 

Re: [U-Boot] Using CONFIG_ENV_FLAGS_LIST

[Claudius Heine]

Hi Lukasz,

On 07/09/2019 00.23, Lukasz Majewski wrote:
> Hi Claudius,
> 
>> Hi,
>>
>> I am currently looking into variable flags in order to make some
>> variables read-only for secure boot.
>>
>> The idea is that the u-boot binary is signed, while the environment
>> file/partition is not. So the built-in default environment of u-boot
>> can be trusted, while the external environment cannot. The assumption
>> is that those flags can be used to customize the validation when the
>> external environment is loaded or scripts/commands are executed.
>>
>> From the '/README' I gather that the access attributes can be any of
>> "any", "read-only", "write-once" or "change-default".
>>
>> I first tried to restrict the variables by choosing 'read-only', but
>> apparently this applies to the internal environment as well, and now
>> those variables are not loaded from the internal environment.
>>
>> Then I tried 'write-once', this worked now as expected from within
>> u-boot, but I could modify the environment from the linux userspace
>> via fw_setenv and those changes appear in u-boot as well. The same for
>> 'change-default'.
>>
>> Is there another way to fill the internal environment variable hash
>> table, so that 'read-only' works as expected?
>>
>> Heiko wrote some patches that change the behavior of the environment
>> loading so that the internal environment is loaded first before the
>> external environment. This way 'write-once' should work as expected,
>> but I think 'read-only' should work that way already and we are
>> missing something here.
> 
> I think that Wolfgang had a long discussion with Takahiro AKASHI (both
> CC'ed) about similar problem with u-boot envs.

Were there any conclusions here?

For me this 'flags' feature looks more and more like its was not build
to save guard the loading from unsigned and untrusted external
environments. I think what we would need here is some sort of variable
whitelist with some additional checks (type and size), but still allow
the u-boot scripts and commands to modify the variables in the hash
table (for filesize, ipaddr etc.) at boot time.

regards,
Claudius

> 
> For example:
> https://patchwork.ozlabs.org/patch/1158770/
> 
>>
>> Thanks,
>> Claudius
>>
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
> 

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

   PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
 Keyserver: hkp://pool.sks-keyservers.net



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

Re: [U-Boot] FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V

[David Abdurachmanov]

On Mon, Sep 9, 2019 at 8:05 AM Anup Patel  wrote:
>
> Hi,
>
> I think keeping FDT placement in-sync between U-Boot and OpenSBI
> across platforms is going to be painful.
>
> I suggest that for all platforms U-Boot explicitly load FDT from somewhere
> so:
> 1. U-Boot ${fdt_addr_r} default value will be recommended location of FDT
> 2. U-Boot ${fdtcontroladdr} will always point to copy of FDT passed by OpenSBI
> 3. To forward FDT passed by OpenSBI to Linux, U-Boot users can always 
> explicitly
> copy FDT from ${fdtcontroladdr} to ${fdt_addr_r} using U-Boot copy command
>
> I also suspect that in-future for certain platforms FDT passed to U-Boot and
> FDT passed to Linux might be little different due to U-Boot specific changes
> in DTS.
>
> Thoughts ??

Do not forget PXE and EXTLINUX boot options. These options must
always be able to override DTB from previous stages. See below what
PXE/EXT use. For Fedora/RISCV we end up in scenario #2 and thus
fdt_addr needs to be set if DTB is coming from somewhere in the firmware.
This is why we had CONFIG_PREBOOT to set it.

[..]
* Scenario 1: If fdt_addr_r specified and "fdt" label is defined in
* pxe file, retrieve fdt blob from server. Pass fdt_addr_r to bootm,
* and adjust argc appropriately.
*
* Scenario 2: If there is an fdt_addr specified, pass it along to
* bootm, and adjust argc appropriately.
*
* Scenario 3: fdt blob is not available.
[..]

david

>
> Regards,
> Anup
>
> > -Original Message-
> > From: Atish Patra
> > Sent: Sunday, September 8, 2019 5:40 PM
> > To: david.abdurachma...@sifive.com; Alistair Francis
> > ; Anup Patel 
> > Cc: u-boot@lists.denx.de; open...@lists.infradead.org
> > Subject: FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V
> >
> > Hi All,
> >
> > I noticed following issues around U-Boot fdt location in Unleashed and Qemu
> > virt machine.
> >
> > OpenSBI copies the FDT to following addresses for respective platforms
> >
> > Qemu: 0x8220
> > Unleashed:0x8800
> >
> >
> > As CONFIG_PRIOR_STAGE is set for both platforms, fdt is first copied to
> > gd->fdt_blob and then gets relocated to a different address(gd-
> > >new_fdt) in function reloc_fdt.
> >
> > As a result, FDT is present at two locations.
> >
> > 1. 0x8800(Unleashed)/0x8220(Qemu) : OpenSBI copied FDT to this
> > address.
> > 2. gd->new_fdt: U-Boot relocated the fdt to this address.
> > fdtcontroladdr will also point to this address.
> >
> > However, commit ac12c6190927 (riscv: set CONFIG_SYS_BOOTM_LEN to
> > SZ_64M) in U-boot changed Qemu config so that fdt_addr_r points to
> > 0x8800 which is wrong as nobody copies fdt to above address in Qemu.
> > Also, 5.3-rc+ kernels overwrite the address pointed by fdtcontroladdr.
> >
> > As a result, fdtcontroladdr won't work on any platform and fdt_addr_r will
> > work only for Unleashed but not for Qemu.
> >
> > I am not sure what should be the ideal solution to avoid these kind of fdt
> > placement issues in future. Here are the few possible ones.
> >
> > 1. Change the FDT_JUMP_ADDR in OpenSBI to 0x8800(RAM+128MB) for
> > Qemu as well. This won't work as Qemu copies initrd to that address. I guess
> > best next option is to copy to 0x8400(RAM+64MB) and U-boot config for
> > Qemu accordingly.
> >
> > 2. Change fdt_addr_r to 0x8220 in Qemu. Update documentation to use
> > fdt only from fdt_addr_r not fdtcontroladdr.
> >
> > @david: What was the reason behind changing it for Qemu ?
> >
> > 3. Fix gd->new_fdt computation. This may affect every board which is not a
> > very good idea either.
> >
> > 4. Mandate loading fdt only from tftp or sdcard which is the safest option 
> > and
> > will avoid these kind of complications. However, I think a default booting
> > method without tftp server should at least work. Let me know if that is not 
> > a
> > sane request. In that case, we should update documentation to clearly say
> > that only tftpboot or sdcard loading method works.
> >
> >
> > --
> > Regards,
> > Atish
> ___
> opensbi mailing list
> open...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/opensbi
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Regression after "distro: not taint environment variables if possible"

[Andre Heider]

Hi,

wrt my other mail "TI mmc env bug?", Nuno sent a proper patch, yet the 
commit has the syntax error (missing "="):


https://gitlab.denx.de/u-boot/u-boot/commit/27e0f3bcf07530a9cd272953797efda54ebb8f5e

Regards,
Andre

On 27/08/2019 02:17, Tom Rini wrote:

On Wed, Jul 10, 2019 at 01:46:57PM +0200, Nuno Gonçalves wrote:


Hi,

I found out that my Beaglebone didn't boot after:

https://github.com/u-boot/u-boot/commit/13dd6665ed18f72380ca596931d609bc108d4b82

I digged out the reason that this patch makes devnum a local variable,
and it ends up shadowed by other code that sets devnum as a env
variable.

For example to boot on the beaglebone I had to remove the setenv as in
the patch below.

This only fixes for my board. Many other will likely have regressions.

Fixing it for all boards in a reliable way I think is very complex,
unless the strategy is to wait for board maintainers to fix it as they
need it, but I wonder how many latent bugs this will create for corner
boot cases.

Maybe this change is not worth it?

Thanks,
Nuno


I've checked other usages here and only the TI case looks to have been a
problem.  I reworded the commit message as well.

Applied to u-boot/master, thanks!


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



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

Re: [U-Boot] FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V

[David Abdurachmanov]

On Sun, Sep 8, 2019 at 3:10 PM Atish Patra  wrote:
>
> Hi All,
>
> I noticed following issues around U-Boot fdt location in Unleashed and
> Qemu virt machine.
>
> OpenSBI copies the FDT to following addresses for respective platforms
>
> Qemu:   0x8220
> Unleashed:  0x8800
>
>
> As CONFIG_PRIOR_STAGE is set for both platforms, fdt is first copied to
> gd->fdt_blob and then gets relocated to a different address(gd-
> >new_fdt) in function reloc_fdt.
>
> As a result, FDT is present at two locations.
>
> 1. 0x8800(Unleashed)/0x8220(Qemu) : OpenSBI copied FDT to this
> address.
> 2. gd->new_fdt: U-Boot relocated the fdt to this address.
> fdtcontroladdr will also point to this address.
>
> However, commit ac12c6190927 (riscv: set CONFIG_SYS_BOOTM_LEN to
> SZ_64M) in U-boot changed Qemu config so that fdt_addr_r points to
> 0x8800 which is wrong as nobody copies fdt to above address in
> Qemu.
> Also, 5.3-rc+ kernels overwrite the address pointed by fdtcontroladdr.
>
> As a result, fdtcontroladdr won't work on any platform and fdt_addr_r
> will work only for Unleashed but not for Qemu.
>
> I am not sure what should be the ideal solution to avoid these kind of
> fdt placement issues in future. Here are the few possible ones.
>
> 1. Change the FDT_JUMP_ADDR in OpenSBI to 0x8800(RAM+128MB) for
> Qemu as well. This won't work as Qemu copies initrd to that address. I
> guess best next option is to copy to 0x8400(RAM+64MB) and U-boot
> config for Qemu accordingly.
>
> 2. Change fdt_addr_r to 0x8220 in Qemu. Update documentation to use
> fdt only from fdt_addr_r not fdtcontroladdr.
>
> @david: What was the reason behind changing it for Qemu ?

Not enough space for the kernel. Thus it was moved from 16M to 64M
(which was a  common thing for some ARM boards, e.g. 96Boards).

I that point I didn't know about QEMU limitation and initrd placement
(IIUC only if you use -initrd).
>
> 3. Fix gd->new_fdt computation. This may affect every board which is
> not a very good idea either.
>
> 4. Mandate loading fdt only from tftp or sdcard which is the safest
> option and will avoid these kind of complications. However, I think a
> default booting method without tftp server should at least work. Let me
> know if that is not a sane request. In that case, we should update
> documentation to clearly say that only tftpboot or sdcard loading
> method works.

I don't think we should require this. FDT should be part of the firmware
(FSBL, U-Boot SPI, OpenSBI, U-Boot, etc.). There should be a way to
override the default one from the firmware (e.g. via tfptboot, PXE or
EXTLINUX configs), but that's optional as majority people will not do
that.

david

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

[U-Boot] [PATCH] spl: Introduce SPL_DM_SPI Kconfig define

[Lukasz Majewski]

This define indicates if DM_SPI shall be supported in SPL. This allows
proper operation of DM converted SPI drivers in SPL, which use
#if !CONFIG_IS_ENABLED(DM_SPI) to also support not yet DM/DTS converted
boards.

Signed-off-by: Lukasz Majewski 

---

Applied on top of -master branch:
SHA1: 448f11f7503995746a7b71e5e3b3a831c4651be9

This patch is a first step for converting SPI #defines to Kconfig.
It was a part of "CONFIG_DM_SPI* to CONFIG_$(SPL_TPL_)DM_SPI*" patch:
https://patchwork.ozlabs.org/patch/1158141/

which in spite of not introducing the apparent build breaks, was
responsible for some deltas in SPL and U-Boot proper sizes (some parts of
SPI code was not compiled in). To fix those board/SoC access to real HW is
necessary as well as deep understanding of SPL SPI requirements.

---
 common/spl/Kconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 7c3391cabe..183ecf6264 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -683,6 +683,13 @@ config SPL_UBI
  Enable support for loading payloads from UBI. See
  README.ubispl for more info.
 
+if SPL_DM
+config SPL_DM_SPI
+   bool "Support SPI DM drivers in SPL"
+   help
+ Enable support for SPI DM drivers in SPL.
+
+endif
 if SPL_UBI
 config SPL_UBI_LOAD_BY_VOLNAME
bool "Support loading volumes by name"
-- 
2.11.0

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

Re: [U-Boot] [GIT PULL] rpi: updates for v2019.10

[Andrei Gherzan]

On 07/09/2019 18.49, Tom Rini wrote:
> On Fri, Sep 06, 2019 at 06:41:09PM +0200, Matthias Brugger wrote:
>
>> Hi Tom,
>>
>> Please have a look on the following updates for Raspberry Pi.
>> Especially we introduce basic RPi4 support \o/
>>
>> I did some mistake while creating the tag, so I had to fix the rebase and
>> overwrite the tag. That's why travis-ci [1] is not yet finished. Nevertheless
>> travis-ci finished successfully with the old tag (same patches but different
>> base) [2].
>>
>> Regards,
>> Matthias
>>
>> [1] https://travis-ci.org/mbgg/u-boot/builds/581754574
>> [2] https://travis-ci.org/mbgg/u-boot/builds/581603847
>>
> Applied to u-boot/master, thanks!
Great news.

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan

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

[U-Boot] [PATCH] spl: dm_mmc: Initialize only the required mmc device

[Lokesh Vutla]

In SPL, all the available mmc devices gets initialized during boot.
This might not work in cases where clocks are not available for
certain mmc devices(other than boot device) and the support for
enabling device might not be ready.

Texas Instruments' K3 J721E device having a central system controller
(dmsc) is one such example falling in this category. Below is the
sequence for the failing scenario:
- ROM comes up in SD mode and loads SPL by just initialing SD card.
- SPL loads dmsc firmware from SD Card.
Since ROM has enabled SD, SPL need not enable the SD, just need
to re initialize the card. But SPL is trying to initialize other MMC
instances which are in disabled state. Since dmsc firmware is not yet
available, devices cannot be enabled. So in SPL, initialize only the
mmc device that is needed.

Signed-off-by: Lokesh Vutla 
---
 common/spl/spl_mmc.c | 14 --
 drivers/mmc/mmc.c| 24 
 include/mmc.h|  1 +
 3 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index b3619889f7..303f0f80bf 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -113,31 +113,25 @@ static int spl_mmc_get_device_index(u32 boot_device)
 
 static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
 {
-#if CONFIG_IS_ENABLED(DM_MMC)
-   struct udevice *dev;
-#endif
int err, mmc_dev;
 
mmc_dev = spl_mmc_get_device_index(boot_device);
if (mmc_dev < 0)
return mmc_dev;
 
+#if CONFIG_IS_ENABLED(DM_MMC)
+   err = mmc_init_device(mmc_dev);
+#else
err = mmc_initialize(NULL);
+#endif /* DM_MMC */
if (err) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf("spl: could not initialize mmc. error: %d\n", err);
 #endif
return err;
}
-
-#if CONFIG_IS_ENABLED(DM_MMC)
-   err = uclass_get_device(UCLASS_MMC, mmc_dev, );
-   if (!err)
-   *mmcp = mmc_get_mmc_dev(dev);
-#else
*mmcp = find_mmc_device(mmc_dev);
err = *mmcp ? 0 : -ENODEV;
-#endif
if (err) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf("spl: could not find mmc device %d. error: %d\n",
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index eecc7d687e..ec8f92ce8f 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2998,6 +2998,30 @@ int mmc_initialize(bd_t *bis)
return 0;
 }
 
+#if CONFIG_IS_ENABLED(DM_MMC)
+int mmc_init_device(int num)
+{
+   struct udevice *dev;
+   struct mmc *m;
+   int ret;
+
+   ret = uclass_get_device(UCLASS_MMC, num, );
+   if (ret)
+   return ret;
+
+   m = mmc_get_mmc_dev(dev);
+   if (!m)
+   return 0;
+#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
+   mmc_set_preinit(m, 1);
+#endif
+   if (m->preinit)
+   mmc_start_init(m);
+
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_CMD_BKOPS_ENABLE
 int mmc_set_bkops_enable(struct mmc *mmc)
 {
diff --git a/include/mmc.h b/include/mmc.h
index 46422f41a4..878b4c9e57 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -698,6 +698,7 @@ void mmc_destroy(struct mmc *mmc);
  */
 int mmc_unbind(struct udevice *dev);
 int mmc_initialize(bd_t *bis);
+int mmc_init_device(int num);
 int mmc_init(struct mmc *mmc);
 int mmc_send_tuning(struct mmc *mmc, u32 opcode, int *cmd_error);
 
-- 
2.22.0

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

[U-Boot] [PATCH 07/10] ufs: Add glue layer driver for TI J721E devices

[Faiz Abbas]

Add glue layer driver for the controller present on TI's J721E devices.

Signed-off-by: Faiz Abbas 
---
 drivers/ufs/Kconfig|  6 +++
 drivers/ufs/Makefile   |  1 +
 drivers/ufs/ti-j721e-ufs.c | 75 ++
 3 files changed, 82 insertions(+)
 create mode 100644 drivers/ufs/ti-j721e-ufs.c

diff --git a/drivers/ufs/Kconfig b/drivers/ufs/Kconfig
index a320b4561f..4875e9448e 100644
--- a/drivers/ufs/Kconfig
+++ b/drivers/ufs/Kconfig
@@ -14,4 +14,10 @@ config CADENCE_UFS
  This selects the platform driver for the Cadence UFS host
  controller present on present TI's J721e devices.
 
+config TI_J721E_UFS
+   bool "Glue Layer driver for UFS on TI J721E devices"
+   help
+ This selects the glue layer driver for Cadence controller
+ present on TI's J721E devices.
+
 endmenu
diff --git a/drivers/ufs/Makefile b/drivers/ufs/Makefile
index 9262bd6cd0..62ed016608 100644
--- a/drivers/ufs/Makefile
+++ b/drivers/ufs/Makefile
@@ -5,3 +5,4 @@
 
 obj-$(CONFIG_UFS) += ufs.o ufs-uclass.o
 obj-$(CONFIG_CADENCE_UFS) += cdns-platform.o
+obj-$(CONFIG_TI_J721E_UFS) += ti-j721e-ufs.o
diff --git a/drivers/ufs/ti-j721e-ufs.c b/drivers/ufs/ti-j721e-ufs.c
new file mode 100644
index 00..249d3796c0
--- /dev/null
+++ b/drivers/ufs/ti-j721e-ufs.c
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UFS_SS_CTRL 0x4
+#define UFS_SS_RST_N_PCSBIT(0)
+#define UFS_SS_CLK_26MHZBIT(4)
+
+static int ti_j721e_ufs_probe(struct udevice *dev)
+{
+   struct power_domain ufs_pwrdmn;
+   struct regmap *map;
+   unsigned int clock;
+   struct clk clk;
+   u32 reg = 0;
+   int ret;
+
+   ret = power_domain_get(dev, _pwrdmn);
+   if (ret) {
+   dev_err(dev, "failed to get power domain %d\n", ret);
+   return ret;
+   }
+
+   ret = power_domain_on(_pwrdmn);
+   if (ret) {
+   dev_err(dev, "Power domain on failed\n");
+   return ret;
+   }
+
+   ret = regmap_init_mem(dev_ofnode(dev), );
+   if (ret)
+   return ret;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret) {
+   dev_err(dev, "failed to get M-PHY clock\n");
+   return ret;
+   }
+
+   clock = clk_get_rate();
+   if (IS_ERR_VALUE(clock)) {
+   dev_err(dev, "failed to get rate\n");
+   return ret;
+   }
+
+   if (clock == 2600)
+   reg |= UFS_SS_CLK_26MHZ;
+   /* Take UFS slave device out of reset */
+   reg |= UFS_SS_RST_N_PCS;
+   regmap_write(map, UFS_SS_CTRL, reg);
+
+   return dm_scan_fdt_dev(dev);
+}
+
+static const struct udevice_id ti_j721e_ufs_ids[] = {
+   {
+   .compatible = "ti,j721e-ufs",
+   },
+   {},
+};
+
+U_BOOT_DRIVER(ti_j721e_ufs) = {
+   .name   = "ti-j721e-ufs",
+   .id = UCLASS_UFS,
+   .of_match   = ti_j721e_ufs_ids,
+   .probe  = ti_j721e_ufs_probe,
+};
-- 
2.19.2

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

[U-Boot] [PATCH 10/10] configs: j721e_evm_a72: Enable configs for UFS

[Faiz Abbas]

Enable SCSI and UFS related configs.

Signed-off-by: Faiz Abbas 
---
 configs/j721e_evm_a72_defconfig | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 237dc6b601..4c7d1173b4 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -36,11 +36,12 @@ CONFIG_CMD_ASKENV=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_SF=y
+CONFIG_CMD_UFS=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_TIME=y
 CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_ISO_PARTITION is not set
-# CONFIG_EFI_PARTITION is not set
+# CONFIG_SPL_PARTITION_UUIDS is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-common-proc-board"
@@ -76,6 +77,7 @@ CONFIG_TI_SCI_POWER_DOMAIN=y
 CONFIG_K3_SYSTEM_CONTROLLER=y
 CONFIG_DM_RESET=y
 CONFIG_RESET_TI_SCI=y
+CONFIG_SCSI=y
 CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
@@ -83,4 +85,7 @@ CONFIG_CADENCE_QSPI=y
 CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_TI_SCI=y
+CONFIG_UFS=y
+CONFIG_CADENCE_UFS=y
+CONFIG_TI_J721E_UFS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.19.2

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

[U-Boot] [PATCH 09/10] cmd: Add Support for UFS commands

[Faiz Abbas]

Add Support for commands to initialize and configure UFS devices.

TODO: Add Support for commands to resize and reconfigure LUNs
Signed-off-by: Faiz Abbas 
---
 cmd/Kconfig  |  7 +++
 cmd/Makefile |  2 +-
 cmd/ufs.c| 28 
 3 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 cmd/ufs.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 0badcb3fe0..e0c78c6b52 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1070,6 +1070,13 @@ config CMD_TSI148
  This provides various sub-commands to initialise and configure the
  Turndra tsi148 device. See the command help for full details.
 
+config CMD_UFS
+   bool "Enable UFS - Universal Flash Subsystem commands"
+   depends on UFS
+   help
+ "This provides commands to initialise and configure universal flash
+  subsystem commands"
+
 config CMD_UNIVERSE
bool "universe - Command to set up the Turndra Universe controller"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index f982564ab9..dc7869a35a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -143,7 +143,7 @@ obj-$(CONFIG_CMD_UNZIP) += unzip.o
 obj-$(CONFIG_CMD_VIRTIO) += virtio.o
 obj-$(CONFIG_CMD_WDT) += wdt.o
 obj-$(CONFIG_CMD_LZMADEC) += lzmadec.o
-
+obj-$(CONFIG_CMD_UFS) += ufs.o
 obj-$(CONFIG_CMD_USB) += usb.o disk.o
 obj-$(CONFIG_CMD_FASTBOOT) += fastboot.o
 obj-$(CONFIG_CMD_FS_UUID) += fs_uuid.o
diff --git a/cmd/ufs.c b/cmd/ufs.c
new file mode 100644
index 00..7e5bbf97d9
--- /dev/null
+++ b/cmd/ufs.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * ufs.c - UFS specific U-boot commands
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *
+ */
+#include 
+#include 
+#include 
+
+static int do_ufs(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   if (argc >= 2) {
+   if (!strcmp(argv[1], "init")) {
+   ufs_probe();
+
+   return CMD_RET_SUCCESS;
+   }
+   }
+
+   return CMD_RET_USAGE;
+}
+
+U_BOOT_CMD(ufs, 2, 1, do_ufs,
+  "UFS  sub system",
+  "init - init UFS subsystem\n"
+);
-- 
2.19.2

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

[U-Boot] [PATCH 05/10] ufs: Add Initial Support for UFS subsystem

[Faiz Abbas]

Add Support for UFS Host Controller Interface (UFSHCI) for communicating
with Universal Flash Storage (UFS) devices. The steps to initialize the
host controller interface are the following:

- Initiate the Host Controller Initialization process by writing to the
Host controller enable register.
- Configure the Host Controller base address registers by allocating a
host memory space and related data structures.
- Unipro link startup procedure
- Check for connected device
- Configure UFS host controller to process requests

Also register this host controller as a SCSI host controller.

Signed-off-by: Faiz Abbas 
---
 MAINTAINERS  |5 +
 drivers/Kconfig  |2 +
 drivers/Makefile |1 +
 drivers/ufs/Kconfig  |9 +
 drivers/ufs/Makefile |6 +
 drivers/ufs/ufs-uclass.c |   16 +
 drivers/ufs/ufs.c| 1973 ++
 drivers/ufs/ufs.h|  918 ++
 drivers/ufs/unipro.h |  270 ++
 include/dm/uclass-id.h   |1 +
 include/ufs.h|7 +
 11 files changed, 3208 insertions(+)
 create mode 100644 drivers/ufs/Kconfig
 create mode 100644 drivers/ufs/Makefile
 create mode 100644 drivers/ufs/ufs-uclass.c
 create mode 100644 drivers/ufs/ufs.c
 create mode 100644 drivers/ufs/ufs.h
 create mode 100644 drivers/ufs/unipro.h
 create mode 100644 include/ufs.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 36625795a4..ed3a4c352c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -772,6 +772,11 @@ S: Maintained
 T: git git://git.denx.de/u-boot-ubi.git
 F: drivers/mtd/ubi/
 
+UFS
+M: Faiz Abbas 
+S: Maintained
+F: drivers/ufs/
+
 USB
 M: Marek Vasut 
 S: Maintained
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 96ff4f566a..61bbe88d6c 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -118,6 +118,8 @@ source "drivers/tpm/Kconfig"
 
 source "drivers/usb/Kconfig"
 
+source "drivers/ufs/Kconfig"
+
 source "drivers/video/Kconfig"
 
 source "drivers/virtio/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 6635dabd2c..2794bef18a 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -111,6 +111,7 @@ obj-y += soc/
 obj-y += thermal/
 obj-$(CONFIG_TEE) += tee/
 obj-y += axi/
+obj-y += ufs/
 obj-$(CONFIG_W1) += w1/
 obj-$(CONFIG_W1_EEPROM) += w1-eeprom/
 
diff --git a/drivers/ufs/Kconfig b/drivers/ufs/Kconfig
new file mode 100644
index 00..538aad8cd9
--- /dev/null
+++ b/drivers/ufs/Kconfig
@@ -0,0 +1,9 @@
+menu "UFS Host Controller Support"
+
+config UFS
+   bool "Support UFS controllers"
+   select DM_SCSI
+   help
+ This selects support for Universal Flash Subsystem (UFS).
+ Say Y here if you want UFS Support.
+endmenu
diff --git a/drivers/ufs/Makefile b/drivers/ufs/Makefile
new file mode 100644
index 00..b8df759f66
--- /dev/null
+++ b/drivers/ufs/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+#
+
+obj-$(CONFIG_UFS) += ufs.o ufs-uclass.o
diff --git a/drivers/ufs/ufs-uclass.c b/drivers/ufs/ufs-uclass.c
new file mode 100644
index 00..920bfa64e1
--- /dev/null
+++ b/drivers/ufs/ufs-uclass.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * ufs-uclass.c - Universal Flash Subsystem (UFS) Uclass driver
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ */
+
+#include 
+#include "ufs.h"
+#include 
+
+UCLASS_DRIVER(ufs) = {
+   .id = UCLASS_UFS,
+   .name   = "ufs",
+   .per_device_auto_alloc_size = sizeof(struct ufs_hba),
+};
diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
new file mode 100644
index 00..88c3e15d78
--- /dev/null
+++ b/drivers/ufs/ufs.c
@@ -0,0 +1,1973 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * ufs.c - Universal Flash Subsystem (UFS) driver
+ *
+ * Taken from Linux Kernel v5.2 (drivers/scsi/ufs/ufshcd.c) and ported
+ * to u-boot.
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "ufs.h"
+
+#define UFSHCD_ENABLE_INTRS(UTP_TRANSFER_REQ_COMPL |\
+UTP_TASK_REQ_COMPL |\
+UFSHCD_ERROR_MASK)
+/* maximum number of link-startup retries */
+#define DME_LINKSTARTUP_RETRIES 3
+
+/* maximum number of retries for a general UIC command  */
+#define UFS_UIC_COMMAND_RETRIES 3
+
+/* Query request retries */
+#define QUERY_REQ_RETRIES 3
+/* Query request timeout */
+#define QUERY_REQ_TIMEOUT 1500 /* 1.5 seconds */
+
+/* maximum timeout in ms for a general UIC command */
+#define UFS_UIC_CMD_TIMEOUT1000
+/* NOP OUT retries waiting for NOP IN response */
+#define NOP_OUT_RETRIES10
+/* Timeout after 30 msecs if NOP OUT hangs without response */
+#define NOP_OUT_TIMEOUT30 /* msecs */
+
+/* Only use one Task Tag for all requests */
+#define TASK_TAG  

[U-Boot] [PATCH 08/10] arm: dts: k3-j721e-main: Add UFS nodes

[Faiz Abbas]

Add TI UFS glue layer and Cadence UFS Host controller DT nodes.

Signed-off-by: Faiz Abbas 
---
 arch/arm/dts/k3-j721e-main.dtsi | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-main.dtsi b/arch/arm/dts/k3-j721e-main.dtsi
index 3445784293..23a7cb9d3a 100644
--- a/arch/arm/dts/k3-j721e-main.dtsi
+++ b/arch/arm/dts/k3-j721e-main.dtsi
@@ -228,4 +228,29 @@
ti,trm-icp = <0x8>;
dma-coherent;
};
+
+   ufs_wrapper: ufs-wrapper@4e8 {
+   compatible = "ti,j721e-ufs";
+   reg = <0x0 0x4e8 0x0 0x100>;
+   power-domains = <_pds 277 TI_SCI_PD_EXCLUSIVE>;
+   clocks = <_clks 277 1>;
+   assigned-clocks = <_clks 277 1>;
+   assigned-clock-parents = <_clks 277 4>;
+   ranges;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   ufs@4e84000 {
+   compatible = "cdns,ufshc-m31-16nm", "jedec,ufs-2.0";
+   reg = <0x0 0x4e84000 0x0 0x1>;
+   interrupts = ;
+   power-domains = <_pds 277 TI_SCI_PD_EXCLUSIVE>;
+   freq-table-hz = <0 0>, <0 0>;
+   clocks = <_clks 277 0>, <_clks 277 1>;
+   clock-names = "core_clk", "phy_clk";
+   assigned-clocks = <_clks 277 1>;
+   assigned-clock-parents = <_clks 277 4>;
+   dma-coherent;
+   };
+   };
 };
-- 
2.19.2

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

[U-Boot] [PATCH 02/10] scsi: Add max_bytes to scsi_platdata

[Faiz Abbas]

Add max_platdata to scsi_platdata to enable the host driver to limit the
number of bytes that can be read/written per request.

Signed-off-by: Faiz Abbas 
---
 drivers/scsi/scsi.c | 45 ++---
 include/scsi.h  |  1 +
 2 files changed, 27 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 82a0bf7cc6..fd1b4b776d 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -44,7 +44,7 @@ static struct blk_desc 
scsi_dev_desc[CONFIG_SYS_SCSI_MAX_DEVICE];
 #endif
 
 /* almost the maximum amount of the scsi_ext command.. */
-#define SCSI_MAX_READ_BLK 0x
+#define SCSI_MAX_BLK 0x
 #define SCSI_LBA48_READ0xFFF
 
 static void scsi_print_error(struct scsi_cmd *pccb)
@@ -145,7 +145,8 @@ static ulong scsi_read(struct udevice *dev, lbaint_t blknr, 
lbaint_t blkcnt,
 {
struct blk_desc *block_dev = dev_get_uclass_platdata(dev);
struct udevice *bdev = dev->parent;
-   lbaint_t start, blks;
+   struct scsi_platdata *uc_plat = dev_get_uclass_platdata(bdev);
+   lbaint_t start, blks, max_blks;
uintptr_t buf_addr;
unsigned short smallblks = 0;
struct scsi_cmd *pccb = (struct scsi_cmd *)
@@ -156,6 +157,11 @@ static ulong scsi_read(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcnt,
buf_addr = (unsigned long)buffer;
start = blknr;
blks = blkcnt;
+   if (uc_plat->max_bytes)
+   max_blks = uc_plat->max_bytes / block_dev->blksz;
+   else
+   max_blks = SCSI_MAX_BLK;
+
debug("\nscsi_read: dev %d startblk " LBAF
  ", blccnt " LBAF " buffer %lx\n",
  block_dev->devnum, start, blks, (unsigned long)buffer);
@@ -164,20 +170,19 @@ static ulong scsi_read(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcnt,
 #ifdef CONFIG_SYS_64BIT_LBA
if (start > SCSI_LBA48_READ) {
unsigned long blocks;
-   blocks = min_t(lbaint_t, blks, SCSI_MAX_READ_BLK);
+   blocks = min_t(lbaint_t, blks, max_blks);
pccb->datalen = block_dev->blksz * blocks;
scsi_setup_read16(pccb, start, blocks);
start += blocks;
blks -= blocks;
} else
 #endif
-   if (blks > SCSI_MAX_READ_BLK) {
-   pccb->datalen = block_dev->blksz *
-   SCSI_MAX_READ_BLK;
-   smallblks = SCSI_MAX_READ_BLK;
+   if (blks > max_blks) {
+   pccb->datalen = block_dev->blksz * max_blks;
+   smallblks = max_blks;
scsi_setup_read_ext(pccb, start, smallblks);
-   start += SCSI_MAX_READ_BLK;
-   blks -= SCSI_MAX_READ_BLK;
+   start += max_blks;
+   blks -= max_blks;
} else {
pccb->datalen = block_dev->blksz * blks;
smallblks = (unsigned short)blks;
@@ -204,15 +209,13 @@ static ulong scsi_read(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcnt,
  * scsi_write
  */
 
-/* Almost the maximum amount of the scsi_ext command.. */
-#define SCSI_MAX_WRITE_BLK 0x
-
 static ulong scsi_write(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
const void *buffer)
 {
struct blk_desc *block_dev = dev_get_uclass_platdata(dev);
struct udevice *bdev = dev->parent;
-   lbaint_t start, blks;
+   struct scsi_platdata *uc_plat = dev_get_uclass_priv(bdev);
+   lbaint_t start, blks, max_blks;
uintptr_t buf_addr;
unsigned short smallblks;
struct scsi_cmd *pccb = (struct scsi_cmd *)
@@ -223,17 +226,21 @@ static ulong scsi_write(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcnt,
buf_addr = (unsigned long)buffer;
start = blknr;
blks = blkcnt;
+   if (uc_plat->max_bytes)
+   max_blks = uc_plat->max_bytes / block_dev->blksz;
+   else
+   max_blks = SCSI_MAX_BLK;
+
debug("\n%s: dev %d startblk " LBAF ", blccnt " LBAF " buffer %lx\n",
  __func__, block_dev->devnum, start, blks, (unsigned long)buffer);
do {
pccb->pdata = (unsigned char *)buf_addr;
-   if (blks > SCSI_MAX_WRITE_BLK) {
-   pccb->datalen = (block_dev->blksz *
-SCSI_MAX_WRITE_BLK);
-   smallblks = SCSI_MAX_WRITE_BLK;
+   if (blks > SCSI_MAX_BLK) {
+   pccb->datalen = block_dev->blksz * max_blks;
+   smallblks = max_blks;
scsi_setup_write_ext(pccb, start, smallblks);
-   start += SCSI_MAX_WRITE_BLK;
-   blks -= SCSI_MAX_WRITE_BLK;
+   start += 

[U-Boot] [PATCH 06/10] ufs: Add Support for Cadence platform UFS driver

[Faiz Abbas]

Add Support for the platform driver for the Cadence device present on
TI's J721e device.

Signed-off-by: Faiz Abbas 
---
 drivers/ufs/Kconfig |   8 +++
 drivers/ufs/Makefile|   1 +
 drivers/ufs/cdns-platform.c | 122 
 3 files changed, 131 insertions(+)
 create mode 100644 drivers/ufs/cdns-platform.c

diff --git a/drivers/ufs/Kconfig b/drivers/ufs/Kconfig
index 538aad8cd9..a320b4561f 100644
--- a/drivers/ufs/Kconfig
+++ b/drivers/ufs/Kconfig
@@ -6,4 +6,12 @@ config UFS
help
  This selects support for Universal Flash Subsystem (UFS).
  Say Y here if you want UFS Support.
+
+config CADENCE_UFS
+   bool "Cadence platform driver for UFS"
+   depends on UFS
+help
+ This selects the platform driver for the Cadence UFS host
+ controller present on present TI's J721e devices.
+
 endmenu
diff --git a/drivers/ufs/Makefile b/drivers/ufs/Makefile
index b8df759f66..9262bd6cd0 100644
--- a/drivers/ufs/Makefile
+++ b/drivers/ufs/Makefile
@@ -4,3 +4,4 @@
 #
 
 obj-$(CONFIG_UFS) += ufs.o ufs-uclass.o
+obj-$(CONFIG_CADENCE_UFS) += cdns-platform.o
diff --git a/drivers/ufs/cdns-platform.c b/drivers/ufs/cdns-platform.c
new file mode 100644
index 00..c80f4253e4
--- /dev/null
+++ b/drivers/ufs/cdns-platform.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * cdns-platform.c - Platform driver for Cadence UFSHCI device
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "ufs.h"
+
+#define USEC_PER_SEC   100L
+
+#define CDNS_UFS_REG_HCLKDIV   0xFC
+#define CDNS_UFS_REG_PHY_XCFGD10x113C
+
+static int cdns_ufs_link_startup_notify(struct ufs_hba *hba,
+   enum ufs_notify_change_status status)
+{
+   hba->quirks |= UFSHCD_QUIRK_BROKEN_LCC;
+   switch (status) {
+   case PRE_CHANGE:
+   return ufshcd_dme_set(hba,
+ UIC_ARG_MIB(PA_LOCAL_TX_LCC_ENABLE),
+ 0);
+   case POST_CHANGE:
+   ;
+   }
+
+   return 0;
+}
+
+static int cdns_ufs_set_hclkdiv(struct ufs_hba *hba)
+{
+   struct clk clk;
+   unsigned long core_clk_rate = 0;
+   u32 core_clk_div = 0;
+   int ret;
+
+   ret = clk_get_by_name(hba->dev, "core_clk", );
+   if (ret) {
+   dev_err(hba->dev, "failed to get core_clk clock\n");
+   return ret;
+   }
+
+   core_clk_rate = clk_get_rate();
+   if (IS_ERR_VALUE(core_clk_rate)) {
+   dev_err(hba->dev, "%s: unable to find core_clk rate\n",
+   __func__);
+   return core_clk_rate;
+   }
+
+   core_clk_div = core_clk_rate / USEC_PER_SEC;
+   ufshcd_writel(hba, core_clk_div, CDNS_UFS_REG_HCLKDIV);
+
+   return 0;
+}
+
+static int cdns_ufs_hce_enable_notify(struct ufs_hba *hba,
+ enum ufs_notify_change_status status)
+{
+   switch (status) {
+   case PRE_CHANGE:
+   return cdns_ufs_set_hclkdiv(hba);
+   case POST_CHANGE:
+   ;
+   }
+
+   return 0;
+}
+
+static int cdns_ufs_init(struct ufs_hba *hba)
+{
+   u32 data;
+
+   /* Increase RX_Advanced_Min_ActivateTime_Capability */
+   data = ufshcd_readl(hba, CDNS_UFS_REG_PHY_XCFGD1);
+   data |= BIT(24);
+   ufshcd_writel(hba, data, CDNS_UFS_REG_PHY_XCFGD1);
+
+   return 0;
+}
+
+static struct ufs_hba_ops cdns_pltfm_hba_ops = {
+   .init = cdns_ufs_init,
+   .hce_enable_notify = cdns_ufs_hce_enable_notify,
+   .link_startup_notify = cdns_ufs_link_startup_notify,
+};
+
+static int cdns_ufs_pltfm_probe(struct udevice *dev)
+{
+   int err = ufshcd_probe(dev, _pltfm_hba_ops);
+   if (err)
+   dev_err(dev, "ufshcd_probe() failed %d\n", err);
+
+   return err;
+}
+
+static int cdns_ufs_pltfm_bind(struct udevice *dev)
+{
+   struct udevice *scsi_dev;
+
+   return ufs_scsi_bind(dev, _dev);
+}
+
+static const struct udevice_id cdns_ufs_pltfm_ids[] = {
+   {
+   .compatible = "cdns,ufshc-m31-16nm",
+   },
+   {},
+};
+
+U_BOOT_DRIVER(cdns_ufs_pltfm) = {
+   .name   = "cdns-ufs-pltfm",
+   .id =  UCLASS_UFS,
+   .of_match   = cdns_ufs_pltfm_ids,
+   .probe  = cdns_ufs_pltfm_probe,
+   .bind   = cdns_ufs_pltfm_bind,
+};
-- 
2.19.2

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

[U-Boot] [PATCH 03/10] scsi: Retry inquiry 3 times to overcome Unit Attention condition

[Faiz Abbas]

The UFS SCSI device LUNs are observed to return failure the first time a
unit ready inquiry is sent and pass on the second try. Send this
inquiry 3 times to make sure device is ready.

Signed-off-by: Faiz Abbas 
---
 drivers/scsi/scsi.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index fd1b4b776d..7b7d388557 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -478,6 +478,7 @@ static int scsi_detect_dev(struct udevice *dev, int target, 
int lun,
lbaint_t capacity;
unsigned long blksz;
struct scsi_cmd *pccb = (struct scsi_cmd *)
+   int count, err;
 
pccb->target = target;
pccb->lun = lun;
@@ -513,9 +514,14 @@ static int scsi_detect_dev(struct udevice *dev, int 
target, int lun,
dev_desc->target = pccb->target;
dev_desc->lun = pccb->lun;
 
-   pccb->datalen = 0;
-   scsi_setup_test_unit_ready(pccb);
-   if (scsi_exec(dev, pccb)) {
+   for (count = 0; count < 3; count++) {
+   pccb->datalen = 0;
+   scsi_setup_test_unit_ready(pccb);
+   err = scsi_exec(dev, pccb);
+   if (!err)
+   break;
+   }
+   if (err) {
if (dev_desc->removable) {
dev_desc->type = perq;
goto removable;
-- 
2.19.2

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

[U-Boot] [PATCH 04/10] scsi: Add dma direction member to command structure

[Faiz Abbas]

Some SCSI devices like UFS use DMA for executing scsi commands and hence
need to know the direction of transfer of the dma. Add a dma_dir element
to the command structure to facilitate this.

Signed-off-by: Faiz Abbas 
---
 drivers/scsi/scsi.c | 4 
 include/scsi.h  | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 7b7d388557..719e0fbfe6 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -167,6 +167,7 @@ static ulong scsi_read(struct udevice *dev, lbaint_t blknr, 
lbaint_t blkcnt,
  block_dev->devnum, start, blks, (unsigned long)buffer);
do {
pccb->pdata = (unsigned char *)buf_addr;
+   pccb->dma_dir = DMA_FROM_DEVICE;
 #ifdef CONFIG_SYS_64BIT_LBA
if (start > SCSI_LBA48_READ) {
unsigned long blocks;
@@ -235,6 +236,7 @@ static ulong scsi_write(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcnt,
  __func__, block_dev->devnum, start, blks, (unsigned long)buffer);
do {
pccb->pdata = (unsigned char *)buf_addr;
+   pccb->dma_dir = DMA_TO_DEVICE;
if (blks > SCSI_MAX_BLK) {
pccb->datalen = block_dev->blksz * max_blks;
smallblks = max_blks;
@@ -382,6 +384,7 @@ static int scsi_read_capacity(struct udevice *dev, struct 
scsi_cmd *pccb,
pccb->msgout[0] = SCSI_IDENTIFY; /* NOT USED */
 
pccb->datalen = 16;
+   pccb->dma_dir = DMA_FROM_DEVICE;
if (scsi_exec(dev, pccb))
return 1;
 
@@ -484,6 +487,7 @@ static int scsi_detect_dev(struct udevice *dev, int target, 
int lun,
pccb->lun = lun;
pccb->pdata = (unsigned char *)
pccb->datalen = 512;
+   pccb->dma_dir = DMA_FROM_DEVICE;
scsi_setup_inquiry(pccb);
if (scsi_exec(dev, pccb)) {
if (pccb->contr_stat == SCSI_SEL_TIME_OUT) {
diff --git a/include/scsi.h b/include/scsi.h
index 076bdbc6a0..7bb2d3ac0f 100644
--- a/include/scsi.h
+++ b/include/scsi.h
@@ -6,6 +6,8 @@
  #ifndef _SCSI_H
  #define _SCSI_H
 
+#include 
+
 struct scsi_cmd {
unsigned char   cmd[16];
/* command */
/* for request sense */
@@ -26,6 +28,7 @@ struct scsi_cmd {
unsigned long   trans_bytes;/* tranfered 
bytes  */
 
unsigned intpriv;
+   enum dma_data_direction dma_dir;
 };
 
 /*---
-- 
2.19.2

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

[U-Boot] [PATCH 01/10] scsi: Simplify scsi_read()/_write()

[Faiz Abbas]

With no non-DM driver using scsi_read()/_write() APIs, remove
the legacy implementations.

Signed-off-by: Faiz Abbas 
---
 drivers/scsi/scsi.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 75900d8228..82a0bf7cc6 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -140,20 +140,11 @@ static void scsi_setup_inquiry(struct scsi_cmd *pccb)
pccb->msgout[0] = SCSI_IDENTIFY; /* NOT USED */
 }
 
-#ifdef CONFIG_BLK
 static ulong scsi_read(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
   void *buffer)
-#else
-static ulong scsi_read(struct blk_desc *block_dev, lbaint_t blknr,
-  lbaint_t blkcnt, void *buffer)
-#endif
 {
-#ifdef CONFIG_BLK
struct blk_desc *block_dev = dev_get_uclass_platdata(dev);
struct udevice *bdev = dev->parent;
-#else
-   struct udevice *bdev = NULL;
-#endif
lbaint_t start, blks;
uintptr_t buf_addr;
unsigned short smallblks = 0;
@@ -216,20 +207,11 @@ static ulong scsi_read(struct blk_desc *block_dev, 
lbaint_t blknr,
 /* Almost the maximum amount of the scsi_ext command.. */
 #define SCSI_MAX_WRITE_BLK 0x
 
-#ifdef CONFIG_BLK
 static ulong scsi_write(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
const void *buffer)
-#else
-static ulong scsi_write(struct blk_desc *block_dev, lbaint_t blknr,
-   lbaint_t blkcnt, const void *buffer)
-#endif
 {
-#ifdef CONFIG_BLK
struct blk_desc *block_dev = dev_get_uclass_platdata(dev);
struct udevice *bdev = dev->parent;
-#else
-   struct udevice *bdev = NULL;
-#endif
lbaint_t start, blks;
uintptr_t buf_addr;
unsigned short smallblks;
@@ -449,10 +431,6 @@ static void scsi_init_dev_desc_priv(struct blk_desc 
*dev_desc)
dev_desc->product[0] = 0;
dev_desc->revision[0] = 0;
dev_desc->removable = false;
-#if !CONFIG_IS_ENABLED(BLK)
-   dev_desc->block_read = scsi_read;
-   dev_desc->block_write = scsi_write;
-#endif
 }
 
 #if !defined(CONFIG_DM_SCSI)
-- 
2.19.2

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

[U-Boot] [PATCH 00/10] Add Support for UFS subsystem for TI's J721e

[Faiz Abbas]

The following patches add support for the Universal Flash Storage (UFS)
subsystem and its implementation on TI's J721e platform.

The UFS Application Layer (UAP) uses SCSI SAM-4 command set for
communication with the device. Therefore, the first 4 patches prepare
the scsi layer for compatibility with UFS. Patch 9 also adds support for
initializing and configuring the device from the U-boot command line.

The UFS Transport Protocol Layer (UTP) and UFS Interconnect Layer (UIC)
are implemented with patch 5. This series only adds support for
detect and read/write operations to the LUNs present in the remote
device. Task Management operations and configuration of LUNs will be
added in a future series.

Patches 6 through 10 add platform driver, device tree and config support
for TI's J721E devices.

Log: https://pastebin.ubuntu.com/p/fTPZsxNjZM/

Tested on top of Lokesh's tree:
https://github.com/lokeshvutla/u-boot
Branch: j721e-full-boot

References:

[1] JESD220D UFS 3.0:
https://www.jedec.org/standards-documents/docs/jesd220c
[2] JESD223D UFS Host Controller Interface (UFSHCI) version 3.0:
https://www.jedec.org/standards-documents/docs/jesd223c

Faiz Abbas (10):
  scsi: Simplify scsi_read()/_write()
  scsi: Add max_bytes to scsi_platdata
  scsi: Retry inquiry 3 times to overcome Unit Attention condition
  scsi: Add dma direction member to command structure
  ufs: Add Initial Support for UFS subsystem
  ufs: Add Support for Cadence platform UFS driver
  ufs: Add glue layer driver for TI J721E devices
  arm: dts: k3-j721e-main: Add UFS nodes
  cmd: Add Support for UFS commands
  configs: j721e_evm_a72: Enable configs for UFS

 arch/arm/dts/k3-j721e-main.dtsi |   25 +
 cmd/Kconfig |7 +
 cmd/Makefile|2 +-
 cmd/ufs.c   |   28 +
 configs/j721e_evm_a72_defconfig |7 +-
 drivers/Kconfig |2 +
 drivers/Makefile|1 +
 drivers/scsi/scsi.c |   83 +-
 drivers/ufs/Kconfig |   23 +
 drivers/ufs/Makefile|8 +
 drivers/ufs/cdns-platform.c |  122 ++
 drivers/ufs/ti-j721e-ufs.c  |   75 ++
 drivers/ufs/ufs-uclass.c|   16 +
 drivers/ufs/ufs.c   | 1973 +++
 drivers/ufs/ufs.h   |  918 ++
 drivers/ufs/unipro.h|  270 +
 include/dm/uclass-id.h  |1 +
 include/scsi.h  |4 +
 include/ufs.h   |7 +
 19 files changed, 3526 insertions(+), 46 deletions(-)
 create mode 100644 cmd/ufs.c
 create mode 100644 drivers/ufs/Kconfig
 create mode 100644 drivers/ufs/Makefile
 create mode 100644 drivers/ufs/cdns-platform.c
 create mode 100644 drivers/ufs/ti-j721e-ufs.c
 create mode 100644 drivers/ufs/ufs-uclass.c
 create mode 100644 drivers/ufs/ufs.c
 create mode 100644 drivers/ufs/ufs.h
 create mode 100644 drivers/ufs/unipro.h
 create mode 100644 include/ufs.h

-- 
2.19.2

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

Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms

[Schrempf Frieder]

Hi Ashish,

On 27.08.19 11:56, Ashish Kumar wrote:
> 
> 
>> -Original Message-
>> From: Schrempf Frieder 
>> Sent: Wednesday, August 14, 2019 5:41 PM
>> To: Ashish Kumar ; Ye Li ;
>> ja...@amarulasolutions.com
>> Cc: Fabio Estevam ; u-boot@lists.denx.de; dl-
>> uboot-imx 
>> Subject: Re: [EXT] Re: [U-Boot] [PATCH 1/6] spi: fsl_qspi: Fix DDR mode
>> setting for latest iMX platforms
>>
>> Caution: EXT Email
>>
>> Sorry, I hit the "Send" button too early ;)
>>
>> On 14.08.19 14:07, Frieder Schrempf wrote:
>>> Hi Ashish,
>>>
>>> On 14.08.19 14:02, Ashish Kumar wrote:


> -Original Message-
> From: U-Boot  On Behalf Of Schrempf
> Frieder
> Sent: Wednesday, August 14, 2019 5:07 PM
> To: Ye Li ; ja...@amarulasolutions.com
> Cc: Fabio Estevam ; u-boot@lists.denx.de;
>> dl-
> uboot-imx 
> Subject: [EXT] Re: [U-Boot] [PATCH 1/6] spi: fsl_qspi: Fix DDR mode
> setting for latest iMX platforms
>
> Caution: EXT Email
>
> Hi Ye,
>
> On 14.08.19 12:08, Ye Li wrote:
>> On latest iMX platforms like iMX7D/iMX6UL/iMX8MQ, the QSPI
>> controller is updated to have TDH field in FLSHCR register.
>> According to reference manual, this TDH must be set to 1 when
>> DDR_EN is set.
>> Otherwise, the TX DDR delay logic won't be enabled.
>
> This is actually an issue I have experienced myself. But in our case
> this behavior only happened on i.MX6ULL not on i.MX6UL. Either the
> QSPI controller hardware or the BootROM code changed when moving
> from UL to ULL. For details see: [1].
>
>>
>> Another issue in DDR mode is the MCR register will be overwritten
>> in every read/write/erase operation. This causes DDR_EN been
>> cleared while TDH=1, then no clk2x output for TX data shift and all
>> operations will fail.
>
> The best way to fix all of these things (also the ones in the other
> patches) would be to fix them in Linux and port the driver from
> Linux to U- Boot. Actually I've already done most of the porting
> [2],
 Hello Frieder,

 I had tested your porting and it was not functional on u-boot.
 I found that only erase, read up to TX/RX buf size is working or
 something like that.
 Also ip and AHB mode cannot be used at time in code. Previously only
 IP mode was used in u-boot, Since endianness across different
 QSPI-IP(ls1012, ls1043, ls1021 big endian), (ls1088,ls2088 little
 endian) is not consistent on various silicon's. I am not sure if
 Yogesh who worked with you on Linux porting gave you this information
 about endianness inconsistency.
>>>
>>> Ok, thanks for your feedback. The endianness for the different SoCs
>>> can be handled by the device data.
>>
>> Does this work correctly in Linux, or does the Linux driver need fixes?
>>
>>>
 Please suggest way forward. How to correct this issue?
>>
>> The first thigh would be to make sure the Linux driver works for all 
>> platforms
>> and then do the porting to U-Boot. I will be out of office for
>> 10 days. After that I can try to work on this, but I need support and 
>> testing for
>> other platforms. I only have i.MX6UL/ULL.
> 
> Hi Frieder,
> 
> I have found some break though after porting to 2019.10 and few modification 
> in driver code, I will update in a weeks' time. Please  do not invest time on 
> this.
> If I need some help I will update.

Thanks for your work. Do you already have some news? Can you share your 
results?

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

Re: [U-Boot] [PATCH] imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode

[Lukasz Majewski]

Hi Heiko, Stefano

> Hello Lukasz,
> 
> Am 05.09.2019 um 11:42 schrieb Lukasz Majewski:
> > Hi Stefano,
> >   
> >> On 04/09/19 12:35, Lukasz Majewski wrote:  
> >>> On Wed, 4 Sep 2019 11:54:40 +0200
> >>> Lukasz Majewski  wrote:
> >>>  
>  Hi Stefano, Heiko,
>  
> > On 04/09/19 10:46, Lukasz Majewski wrote:  
> >> Hi Heiko,
> >>  
> >>> Hello Lukasz,
> >>>
> >>> added Stefano to cc as he is the imx custodian.  
> >>
> >> I've relied on patman ... Thanks for adding Stefano to CC.
> >>  
> >>>
> >>> Am 03.09.2019 um 23:43 schrieb Lukasz Majewski:  
>  This change tries to fix the following problem:
> 
>  - The board boots (to be more precise - ROM loads SPL) from a
>  slow SPI-NOR memory.
>  As a result the spl_boot_device() will return SPI-NOR as
>  a boot device (which is correct).
> 
>  - The problem is that in 'falcon boot' the eMMC is used as a
>  boot medium to load kernel from its partition.
>  Calling spl_boot_device() will break things as it returns
>  SPI-NOR device.
> 
>  To fix this issue the new CONFIG_SPL_FORCE_MMC_BOOT Kconfig
>  flag is introduced to handle this special use case. By
>  default it is not defined, so there is no change in the
>  legacy code flow.
> 
>  Signed-off-by: Lukasz Majewski 
> 
> 
>  ---
> 
>  This patch is a follow up of previous discussion/fix:
>  https://patchwork.ozlabs.org/patch/796237/
> 
>  Travis-CI:
>  https://travis-ci.org/lmajewski/u-boot-dfu/builds/580272414
>  ---
> arch/arm/mach-imx/spl.c | 11 +++
> common/spl/Kconfig  |  7 +++
> 2 files changed, 18 insertions(+)  
> >>>
> >>> I have just similiar change for an imx6ull based board ...  
> >>
> >> Also one more of my boards uses this trick (i.MX28 based one).
> >>  
> >>> just antoher usecase: In factory empty board boots into USB
> >>> SDP mode, and SPL gets loaded with usb_loader ... SPL detects
> >>> a sd card (there is no sd card slot mounted, mmc boot is
> >>> disabled! They attach only one for installing software)  
> >>
> >> So there is no dedicated SD card slot (also the mmc is disabled
> >> on that point).
> >> Instead, in the factory the sd card is attached to pads - just
> >> for this time.
> >>  
> >>> and boots U-Boot and system from sd card.
> >>> Than all software gets installed fully automated with the help
> >>> of swupdate ...  
> >>
> >> Ok.
> >>  
> >>> 
>  diff --git a/arch/arm/mach-imx/spl.c
>  b/arch/arm/mach-imx/spl.c index 1f230aca3397..daa3d8f7ed94
>  100644 --- a/arch/arm/mach-imx/spl.c
>  +++ b/arch/arm/mach-imx/spl.c
>  @@ -178,7 +178,18 @@ int g_dnl_bind_fixup(struct
>  usb_device_descriptor *dev, const char *name) /* called from
>  spl_mmc to see type of boot mode for storage (RAW or FAT) */
>  u32 spl_boot_mode(const u32 boot_device) {
>  +/*
>  + * When CONFIG_SPL_FORCE_MMC_BOOT is defined the
>  'boot_device' is used
>  + * unconditionally to decide about device to use for
>  booting.
>  + * This is crucial for falcon boot mode, when board boots up
>  (i.e. ROM
>  + * loads SPL) from slow SPI-NOR memory and afterwards the
>  SPL's 'falcon' boot
>  + * mode is used to load Linux OS from eMMC partition.
>  + */
>  +#ifdef CONFIG_SPL_FORCE_MMC_BOOT
>  +switch (boot_device) {
>  +#else
>   switch (spl_boot_device()) {
>  +#endif  
> >>>
> >>> Just dummy question .. couldn;t we switch to use always
> >>> boot_device?  
> >>
> >> Stefano has provided some rationale for the need of
> >> spl_boot_device() in the previous version of this fix [1]:
> >>
> >> https://patchwork.ozlabs.org/patch/796237/
> >>
> >>  
> >>>
> >>> In my case I had a board specific:
> >>>
> >>> void board_boot_order(u32 *spl_boot_list)
> >>> {
> >>>   spl_boot_list[0] = BOOT_DEVICE_MMC1;
> >>>   spl_boot_list[1] = BOOT_DEVICE_SPI;
> >>>   spl_boot_list[2] = BOOT_DEVICE_BOARD;
> >>>   spl_boot_list[3] = BOOT_DEVICE_NONE;
> >>> }
> >>>
> >>> which leads that BOOT_DEVICE_MMC1 is passed to spl_boot_mode()
> >>>   
> >>
> >> Is your board normally booting from MMC or SPI-NOR (from where
> >> SoC ROM loads SPL) ?
> >>  
> >>>
> >>> If MMC1 is not found, it tries to boot U-Boot from SPI, and if
> >>> this is empty, as fallback board go into USB SDP mode.
> >>>
> >>> The 

Re: [U-Boot] Regressions in MTD / SPI FLASH

[Schrempf Frieder]

Hi Eugeniy,

On 04.09.19 20:07, Eugeniy Paltsev wrote:
> We faced with regressions caused by
> commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
> This switch was performed by removing entire u-boot spi-flash
> core implementation and copying it from another project.
> However the switch is performed without proper testing and
> investigations about fixes/improvements were made in u-boot
> spi-flash core. This results in regressions.
> 
> One of regression we faced with is related to SST26 flash series which
> is used on HSDK board. The cause is that SST26 protection ops
> implementation was dropped. The fix of this regression is send
> as a patch in this series.
> 
> However there are another regressions. I.E: we also faced with broken
> SPI flash on another SNPS boards - AXS101 and AXS103. They use different
> flash IC (n25q512ax3) and I didn't investigate the cause yet.
> 
> I can also expect regressions among other u-boot users
> and I believe that subsystem changes mustn't be done such harmful way.

Actually such changes are only as much "harmful" as they are not tested 
on all of the hardware and this depends only on how many developers with 
specific boards step up to test these changes.

As Vignesh already explained, syncing the framework from Linux to U-Boot 
was desperately needed and I'm very glad, that he did the work. 
Otherwise we would still be stuck with rather old and unmaintainable 
code, that would even cause more issues in the long term.

Regards
Frieder

> 
> Eugeniy Paltsev (1):
>MTD: SPI: revert removing SST26* flash IC protection ops
> 
>   drivers/mtd/spi/sf_internal.h  |   1 +
>   drivers/mtd/spi/spi-nor-core.c | 181 +
>   drivers/mtd/spi/spi-nor-ids.c  |   8 +-
>   include/linux/mtd/spi-nor.h|   4 +
>   4 files changed, 190 insertions(+), 4 deletions(-)
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] TI mmc env bug?

[Andre Heider]

Hi,

Nuno, I think I spotted a syntax error in 'mmcboot' while looking at 
unrelated boot problems on my boneblack:


27e0f3bcf07530a9cd272953797efda54ebb8f5e
diff --git a/include/environment/ti/mmc.h b/include/environment/ti/mmc.h
index ef05376608..bb4af0a3d5 100644
--- a/include/environment/ti/mmc.h
+++ b/include/environment/ti/mmc.h
@@ -56,7 +56,7 @@
"bootz; " \
"fi;\0" \
"mmcboot=mmc dev ${mmcdev}; " \
-   "devnum ${mmcdev}; " \
+   "devnum=${mmcdev}; " \
"setenv devtype mmc; " \
"if mmc rescan; then " \
"echo SD/MMC found on device ${mmcdev};" \

Totally untested though. In case it's a proper fix, I won't be around 
this week to send a proper patch to fix the regression fix ;)


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

Re: [U-Boot] [PATCH v6 1/4] dm: spi: Convert Freescale ESPI driver to driver model

[Prabhakar Kushwaha]

> -Original Message-
> From: Jagan Teki 
> Sent: Monday, September 9, 2019 11:37 AM
> To: Xiaowei Bao 
> Cc: Prabhakar Kushwaha ; w...@denx.de;
> Shengzhou Liu ; Ruchika Gupta
> ; s...@chromium.org; Chuanhua Han
> ; Jagdish Gediya ;
> bmeng...@gmail.com; u-boot@lists.denx.de; York Sun ;
> Jiafei Pan 
> Subject: Re: [PATCH v6 1/4] dm: spi: Convert Freescale ESPI driver to driver
> model
> 
> On Mon, Sep 9, 2019 at 9:27 AM Xiaowei Bao  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Prabhakar Kushwaha
> > > Sent: 2019年8月26日 23:12
> > > To: Xiaowei Bao ; w...@denx.de; Shengzhou Liu
> > > ; Ruchika Gupta ;
> > > ja...@amarulasolutions.com; s...@chromium.org; Chuanhua Han
> > > ; Jagdish Gediya ;
> > > bmeng...@gmail.com; u-boot@lists.denx.de
> > > Cc: York Sun ; Xiaowei Bao 
> > > Subject: RE: [PATCH v6 1/4] dm: spi: Convert Freescale ESPI driver
> > > to driver model
> > >
> > > Dear Jagan,
> > >
> > > > -Original Message-
> > > > From: Xiaowei Bao 
> > > > Sent: Monday, August 26, 2019 2:55 PM
> > > > To: w...@denx.de; Shengzhou Liu ; Ruchika
> > > > Gupta ; ja...@amarulasolutions.com;
> > > s...@chromium.org;
> > > > Prabhakar Kushwaha ; Chuanhua Han
> > > > ; Jagdish Gediya ;
> > > > bmeng...@gmail.com; u-boot@lists.denx.de
> > > > Cc: York Sun ; Xiaowei Bao 
> > > > Subject: [PATCH v6 1/4] dm: spi: Convert Freescale ESPI driver to
> > > > driver model
> > > >
> > > > From: Chuanhua Han 
> > > >
> > > > Modify the Freescale ESPI driver to support the driver model.
> > > > Also resolved the following problems:
> > > >
> > > > = WARNING == This
> > > board does
> > > > not use CONFIG_DM_SPI. Please update the board before v2019.04 for
> > > > no dm conversion and v2019.07 for partially dm converted drivers.
> > > > Failure to update can lead to driver/board removal See doc/driver-
> > > > model/MIGRATION.txt for more info.
> > > > 
> > > > = WARNING == This
> > > board does
> > > > not use CONFIG_DM_SPI_FLASH. Please update the board to use
> > > > CONFIG_SPI_FLASH before the v2019.07 release.
> > > > Failure to update by the deadline may result in board removal.
> > > > See doc/driver-model/MIGRATION.txt for more info.
> > > > 
> > > >
> > > > Signed-off-by: Chuanhua Han 
> > > > Signed-off-by: Xiaowei Bao 
> > > > ---
> > > > depends on:
> > > > https://patc
> > > > hwo
> > > >
> > >
> rk.ozlabs.org%2Fcover%2F1146494%2Fdata=02%7C01%7Cprabhakar.k
> > > us
> > > >
> > > hwaha%40nxp.com%7Ccc2424972d4e4d6835f908d72a08b877%7C686ea1d3
> > > bc2
> > > >
> > > b4c6fa92cd99c5c301635%7C0%7C0%7C637024089250212151sdata=
> > > 3Ki9
> > > > mrnn9YXWMR0vjoDmeE2eKBIn1RKlgnRC81SZQbU%3Dreserved=0
> > > > Changes in v6:
> > > > - Change #ifndef CONFIG_DM_SPI to #if !CONFIG_IS_ENABLED(DM_SPI).
> > > > Changes in v5:
> > > > - Modify the function spi_cs_activate to fsl_spi_cs_activate.
> > > > - Move cs to the parameter of the fsl_spi_cs_activate function.
> > > > Changes in v4:
> > > > - Update copyright information.
> > > > - Move the fsl_espi_platdata data structure to the
> > > > include/dm/platform_data/.
> > > > - Merge the contents of the fsl_espi_priv structure into the
> > > > fsl_spi_slave structure.
> > > > - Implement the fsl_espi_set_speed function.
> > > > - Implement the fsl_espi_set_mode function.
> > > > - Implement the espi_release_bus function.
> > > > - Remove unwanted fsl_espi_bind functions.
> > > > - Implement the fsl_espi_child_pre_probe function as needed.
> > > > - Use #if CONFIG_IS_ENABLED(OF_CONTROL) &&
> > > > !CONFIG_IS_ENABLED(OF_PLATDATA).
> > > > Changes in v3:
> > > > - Add a cover-letter for this patch set.
> > > > Changes in v2:
> > > > - The fsl_espi driver support both OF_CONTROL and PLATDATA.
> > > >
> > > >  drivers/spi/fsl_espi.c  | 445
> > > ++--
> > > >  drivers/spi/fsl_espi.c  | 445
> > > ++--
> > > >  include/dm/platform_data/fsl_espi.h |  16 ++
> > > >  2 files changed, 337 insertions(+), 124 deletions(-)  create mode
> > > > 100644
> > >
> > > Please review this patch-set and provide your comments.
> > >
> > > Once reviewed, I will send pull request via mpc85xx tree
> >
> > Hi Prabhakar and Jagan,
> >
> > What is the progress, if there are any comments, please let me know,
> > if no comments, please help to merge it, thanks a lot.
> 
> I marked my r-b tag, and Prabhakar would take this via his tree (as he
> mentioned)

Thanks Jagan..

We will pull it via our tree

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