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

[Ashish Kumar]

> -Original Message-
> From: Stefan Roese 
> Sent: Wednesday, September 11, 2019 11:17 AM
> To: Schrempf Frieder ; Ashish Kumar
> ; Ye Li ;
> ja...@amarulasolutions.com
> Cc: Fabio Estevam ; u-boot@lists.denx.de; dl-
> uboot-imx 
> Subject: Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode
> setting for latest iMX platforms
> 
> Caution: EXT Email
> 
> Hi Ashish,
> Hi Frieder,
> 
> On 09.09.19 10:10, Schrempf Frieder wrote:
> > 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-
> b...@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?
> 
> I'm most likely currently running in similar issues on tests with the i.MX6ULL
> EVK. QSPI does not work reliably. So before digging deeper into the QSPI
> driver, I wanted to check on the status of any updates in the driver. Is there
> anything available that I could use for testing already?
Hi Stefan,  Frieder,

The spi-mem version is still under debug, I could make it working for 
ls1088rdb, ls1046rdb, but it is failing for 
ls1012ardb and ls2088ardb and untested for i.mx and other Layerscape 
silicon/boards . It is derived from work done by Frieder earlier. This version 
can be found here:
https://github.com/erashish007/u-boot-spi-mem/tree/spi-mem-port

There is completely working version of fsl_qspi.c based 

[U-Boot] [PATCH v2 2/2] efi_loader: device_path: show a host device in understandable form

[AKASHI Takahiro]

It would be better to give a user-friendly text to a host device
on sandbox instead of just dumping its guid.

=> host bind 0 /opt/disk/uboot_sandbox_fat.img
=> efi devices
Device   Device Path
 
15c1f3a0 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
15c20f00 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Hostdev(0)

Signed-off-by: AKASHI Takahiro 
---
 lib/efi_loader/efi_device_path_to_text.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/efi_loader/efi_device_path_to_text.c 
b/lib/efi_loader/efi_device_path_to_text.c
index 96fd08971b73..40a06b70e08a 100644
--- a/lib/efi_loader/efi_device_path_to_text.c
+++ b/lib/efi_loader/efi_device_path_to_text.c
@@ -62,6 +62,11 @@ static char *dp_hardware(char *s, struct efi_device_path *dp)
case DEVICE_PATH_SUB_TYPE_VENDOR: {
struct efi_device_path_vendor *vdp =
(struct efi_device_path_vendor *)dp;
+#ifdef CONFIG_SANDBOX
+   if (!guidcmp(>guid, _guid_host_dev))
+   s += sprintf(s, "Hostdev(%d)", vdp->vendor_data[0]);
+   else
+#endif
s += sprintf(s, "VenHw(%pUl)", >guid);
break;
}
-- 
2.21.0

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

[U-Boot] [PATCH v2 0/2] efi_loader: device_path: support Sandbox's host device

[AKASHI Takahiro]

Changes in v2 (Sept 12, 2019)
* use "vendor device path" with dedicate guid instead of LUN
* add patch#2 for pretty printing

AKASHI Takahiro (2):
  efi_loader: device_path: support Sandbox's "host" devices
  efi_loader: device_path: show a host device in understandable form

 include/efi_loader.h |  8 ++
 lib/efi_loader/efi_device_path.c | 33 
 lib/efi_loader/efi_device_path_to_text.c |  5 
 3 files changed, 46 insertions(+)

-- 
2.21.0

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

[U-Boot] [PATCH v2 1/2] efi_loader: device_path: support Sandbox's "host" devices

[AKASHI Takahiro]

Sandbox's "host" devices are currently described as UCLASS_ROOT udevice
with DEV_IF_HOST block device. As the current implementation of
efi_device_path doesn't support such a type, any "host" device
on sandbox cannot be seen as a distinct object.

For example,
  => host bind 0 /foo/disk.img

  => efi devices
  Scanning disk host0...
  Found 1 disks
  Device   Device Path
   
  15c19970 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
  15c19d70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)

  => efi dh
  Handle   Protocols
   
  15c19970 Device Path, Device Path To Text, Device Path Utilities, 
Unicode Collation 2, HII String, HII Database, HII Config Routing
  15c19ba0 Driver Binding
  15c19c10 Simple Text Output
  15c19c80 Simple Text Input, Simple Text Input Ex
  15c19d70 Block IO, Device Path, Simple File System

As you can see here, efi_root (0x15c19970) and host0 device
(0x15c19d70) has the same representation of device path.

This is not only inconvenient, but also confusing since two different
efi objects are associated with the same device path and
efi_dp_find_obj() will possibly return a wrong result.

Solution:
Each "host" device should be given an additional device path node
of "vendor device path" to make it distinguishable.

Signed-off-by: AKASHI Takahiro 
---
 include/efi_loader.h |  8 
 lib/efi_loader/efi_device_path.c | 33 
 2 files changed, 41 insertions(+)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 5298ea7997f7..38330f2f5463 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -24,6 +24,10 @@
 #define U_BOOT_GUID \
EFI_GUID(0xe61d73b9, 0xa384, 0x4acc, \
 0xae, 0xab, 0x82, 0xe8, 0x28, 0xf3, 0x62, 0x8b)
+/* GUID used as host device on sandbox */
+#define U_BOOT_HOST_DEV_GUID \
+   EFI_GUID(0xbbe4e671, 0x5773, 0x4ea1, \
+0x9a, 0xab, 0x3a, 0x7d, 0xbf, 0x40, 0xc4, 0x82)
 
 /* Root node */
 extern efi_handle_t efi_root;
@@ -121,6 +125,10 @@ uint16_t *efi_dp_str(struct efi_device_path *dp);
 
 /* GUID of the U-Boot root node */
 extern const efi_guid_t efi_u_boot_guid;
+#ifdef CONFIG_SANDBOX
+/* GUID of U-Boot host device on sandbox */
+extern const efi_guid_t efi_guid_host_dev;
+#endif
 /* GUID of the EFI_BLOCK_IO_PROTOCOL */
 extern const efi_guid_t efi_block_io_guid;
 extern const efi_guid_t efi_global_variable_guid;
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index eeeb80683607..611bab514286 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -12,8 +12,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
+#ifdef CONFIG_SANDBOX
+const efi_guid_t efi_guid_host_dev = U_BOOT_HOST_DEV_GUID;
+#endif
+
 /* template END node: */
 static const struct efi_device_path END = {
.type = DEVICE_PATH_TYPE_END,
@@ -445,6 +450,16 @@ static unsigned dp_size(struct udevice *dev)
case UCLASS_MMC:
return dp_size(dev->parent) +
sizeof(struct efi_device_path_sd_mmc_path);
+#endif
+#ifdef CONFIG_SANDBOX
+   case UCLASS_ROOT:
+/*
+ * Sandbox's host device will be represented
+ * as vendor device with extra one byte for
+ * device number
+ */
+   return dp_size(dev->parent)
+   + sizeof(struct efi_device_path_vendor) + 1;
 #endif
default:
return dp_size(dev->parent);
@@ -505,6 +520,24 @@ static void *dp_fill(void *buf, struct udevice *dev)
 #ifdef CONFIG_BLK
case UCLASS_BLK:
switch (dev->parent->uclass->uc_drv->id) {
+#ifdef CONFIG_SANDBOX
+   case UCLASS_ROOT: {
+   /* stop traversing parents at this point: */
+   struct efi_device_path_vendor *dp = buf;
+   struct blk_desc *desc = dev_get_uclass_platdata(dev);
+
+   dp_fill(buf, dev->parent);
+   dp = buf;
+   ++dp;
+   dp->dp.type = DEVICE_PATH_TYPE_HARDWARE_DEVICE;
+   dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_VENDOR;
+   dp->dp.length = sizeof(*dp) + 1;
+   memcpy(>guid, _guid_host_dev,
+  sizeof(efi_guid_t));
+   dp->vendor_data[0] = desc->devnum;
+   return >vendor_data[1];
+   }
+#endif
 #ifdef CONFIG_IDE
case UCLASS_IDE: {
struct efi_device_path_atapi *dp =
-- 
2.21.0

___
U-Boot mailing list

[U-Boot] [PATCH v2 1/3] fs: export fs_close()

[AKASHI Takahiro]

This function is always paired with either fs_set_blk_desc() or
fs_set_blk_desc_with_part(). So just export it.

Signed-off-by: AKASHI Takahiro 
---
 fs/fs.c  | 2 +-
 include/fs.h | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/fs.c b/fs/fs.c
index d8a4ced4698e..64ba25fea8bf 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -389,7 +389,7 @@ int fs_set_blk_dev_with_part(struct blk_desc *desc, int 
part)
return -1;
 }
 
-static void fs_close(void)
+void fs_close(void)
 {
struct fstype_info *info = fs_get_info(fs_type);
 
diff --git a/include/fs.h b/include/fs.h
index 7601b0343bcd..5a1244d57fd2 100644
--- a/include/fs.h
+++ b/include/fs.h
@@ -37,6 +37,13 @@ int fs_set_blk_dev(const char *ifname, const char 
*dev_part_str, int fstype);
  */
 int fs_set_blk_dev_with_part(struct blk_desc *desc, int part);
 
+/**
+ * fs_close() - Unset current block device and partition
+ *
+ * Should be paired with either fs_set_blk_dev() or fs_set_dev_with_part()
+ */
+void fs_close(void);
+
 /**
  * fs_get_type_name() - Get type of current filesystem
  *
-- 
2.21.0

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

[U-Boot] [PATCH v2 2/3] efi_loader: disk: install FILE_SYSTEM_PROTOCOL only if available

[AKASHI Takahiro]

In the current implementation, EFI_SIMPLEFILE_SYSTEM_PROTOCOL is always
installed to all the partitions even if some of them may house no file
system.

With this patch, that protocol will be installed only if FAT file system
exists.

Signed-off-by: AKASHI Takahiro 
---
 lib/efi_loader/efi_disk.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 7a6b06821a47..d72f455901f2 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -217,6 +218,19 @@ efi_fs_from_path(struct efi_device_path *full_path)
return handler->protocol_interface;
 }
 
+static int efi_fs_exists(struct blk_desc *desc, int part)
+{
+   if (fs_set_blk_dev_with_part(desc, part))
+   return 0;
+
+   if (strcmp(fs_get_type_name(), "fat"))
+   return 0;
+
+   fs_close();
+
+   return 1;
+}
+
 /*
  * Create a handle for a partition or disk
  *
@@ -270,7 +284,7 @@ static efi_status_t efi_disk_add_dev(
   diskobj->dp);
if (ret != EFI_SUCCESS)
return ret;
-   if (part >= 1) {
+   if (part >= 1 && efi_fs_exists(desc, part)) {
diskobj->volume = efi_simple_file_system(desc, part,
 diskobj->dp);
ret = efi_add_protocol(>header,
-- 
2.21.0

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

[U-Boot] [PATCH v2 0/3] efi_loader: disk: install FILE_SYSTEM_PROTOCOL to whole disk

[AKASHI Takahiro]

Changes in v2 (Sept 12, 2019)
* add patch#1 and #2
* install the protocol only if a file system does exist

AKASHI Takahiro (3):
  fs: export fs_close()
  efi_loader: disk: install FILE_SYSTEM_PROTOCOL only if available
  efi_loader: disk: install file system protocol to a whole disk

 fs/fs.c   |  2 +-
 include/fs.h  |  7 +++
 lib/efi_loader/efi_disk.c | 19 ++-
 3 files changed, 26 insertions(+), 2 deletions(-)

-- 
2.21.0

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

[U-Boot] [PATCH v2 3/3] efi_loader: disk: install file system protocol to a whole disk

[AKASHI Takahiro]

Currently, a whole disk without any partitions is not associated
with EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. So even if it houses FAT
file system, there is a chance that we may not be able to access
it, particularly, when accesses are to be attempted after searching
that protocol against a device handle.

With this patch, EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is installed
to such a disk if part_get_info() shows there is not partition
table installed on it.

Signed-off-by: AKASHI Takahiro 
---
 lib/efi_loader/efi_disk.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index d72f455901f2..d36f22cedc52 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -253,6 +253,7 @@ static efi_status_t efi_disk_add_dev(
struct efi_disk_obj **disk)
 {
struct efi_disk_obj *diskobj;
+   disk_partition_t info;
efi_status_t ret;
 
/* Don't add empty devices */
@@ -284,7 +285,9 @@ static efi_status_t efi_disk_add_dev(
   diskobj->dp);
if (ret != EFI_SUCCESS)
return ret;
-   if (part >= 1 && efi_fs_exists(desc, part)) {
+   /* partitions or whole disk without partitions */
+   if ((part >= 1 || part_get_info(desc, part, )) &&
+   efi_fs_exists(desc, part)) {
diskobj->volume = efi_simple_file_system(desc, part,
 diskobj->dp);
ret = efi_add_protocol(>header,
-- 
2.21.0

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

[U-Boot] Tinker-rk3288 SPL broken with MMC timeout

[Jagan Teki]

I have seen this even on v2019.07 release, and the only release that
it got working with on v2019.01 (SPL, BROM_RETURN)

Any idea? here is the log dump.

U-Boot TPL 2019.10-rc3-00297-g5ba8b12543 (Sep 12 2019 - 08:50:36)
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-rc3-00297-g5ba8b12543 (Sep 12 2019 - 08:50:36 +0530)
Trying to boot from MMC1
spl: mmc init failed with error: -110
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

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

[U-Boot] Pull request: u-boot-rockchip-20190912

[Kever Yang]

Hi Tom,

Please pull the rockchip update:
- add idbloader.img target for rockchip tpl+spl;
- usb ehci/ohci: go on process if clock driver don't have clk_enable();
- remove clk_enable() for rockchip clock drivers;
- add boot order for rockpro64

Gitlab CI:
https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/652

Thanks,
- Kever

The following changes since commit 001c8ea94ae710d8340829237a7d788b25ce2ae7:

  Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2019-09-10 
08:52:00 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
tags/u-boot-rockchip-20190912

for you to fetch changes up to 326b2624192336c99ba18d5151b51d0c07c23193:

  doc: lion_rk3368: use idbloader.img for rk3368 (2019-09-11 16:16:12 +0800)


Kever Yang (9):
  rockchip: rk3399: dts: add boot order for rockpro64
  usb: ehci-generic: don't probe fail if there is no clk_enable() ops
  usb: ohci-generic: don't probe fail if there is no clk_enable() ops
  rockchip: clk: rk3288: remove clk_enable()
  rockchip: clk: rk3328: remove clk_enable()
  rockchip: clk: rk3368: remove clk_enable()
  rockchip: clk: rk3399: remove clk_enable()
  rockchip: not depends on TPL_BUILD for rk3188 makefile including
  rockchip: clean makefile for misc.c

Matwey V. Kornilov (3):
  rockchip, Makefile: add idbloader.img target
  doc: rockchip: use idbloader.img for rk3288, rk3328, rk3399
  doc: lion_rk3368: use idbloader.img for rk3368

 Makefile   | 12 ++
 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi  |  5 
 arch/arm/mach-rockchip/Makefile|  8 ++-
 board/theobroma-systems/lion_rk3368/README |  4 +---
 doc/README.rockchip| 21 ++---
 drivers/clk/rockchip/clk_rk3288.c  | 23 ---
 drivers/clk/rockchip/clk_rk3328.c  | 12 --
 drivers/clk/rockchip/clk_rk3368.c  | 19 ---
 drivers/clk/rockchip/clk_rk3399.c  | 37 --
 drivers/usb/host/ehci-generic.c|  2 +-
 drivers/usb/host/ohci-generic.c|  2 +-
 11 files changed, 24 insertions(+), 121 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] habv4: tools: Avoid hardcoded CSF size for SPL targets

[Peng Fan]

Hi Breno,

> Subject: [PATCH 2/4] habv4: tools: Avoid hardcoded CSF size for SPL targets

I saw this patch in imx/master, not in Tom's tree. But this patch breaks
build for other archs, such as arc and etc.

Regards,
Peng.

> 
> Currently it's not possible to authenticate the U-Boot proper of
> mx6ul_14x14_evk_defconfig target:
> 
> Authenticate image from DDR location 0x877fffc0...
> bad magic magic=0x0 length=0x00 version=0x3 bad length magic=0x0
> length=0x00 version=0x3 bad version magic=0x0 length=0x00 version=0x3
> spl: ERROR:  image authentication fail
> 
> Commit 0633e134784a ("imx: hab: Increase CSF_SIZE for i.MX6 and
> i.MX7 devices") has increased CSF_SIZE to avoid a possible issue when
> booting encrypted boot images.
> 
> Commit d21bd69b6e95 ("tools: mkimage: add firmware-ivt image type for
> HAB verification") is hardcoding the CSF and IVT sizes, the new CSF size is 
> not
> being considered and u-boot-ivt.img fails to boot.
> 
> Avoid hardcoded CSF and IVT size to fix this issue.
> 
> Signed-off-by: Breno Lima 
> ---
>  common/image.c| 8 +---
>  tools/default_image.c | 5 -
>  2 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/common/image.c b/common/image.c index
> 9f9538fac2..fc19dfdd9c 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -54,6 +54,8 @@ static const image_header_t *image_get_ramdisk(ulong
> rd_addr, uint8_t arch,  #endif /* !USE_HOSTCC*/
> 
>  #include 
> +#include 
> +#include 
> 
>  #ifndef CONFIG_SYS_BARGSIZE
>  #define CONFIG_SYS_BARGSIZE 512
> @@ -369,9 +371,9 @@ void image_print_contents(const void *ptr)
>   }
>   } else if (image_check_type(hdr, IH_TYPE_FIRMWARE_IVT)) {
>   printf("HAB Blocks:   0x%08x   0x   0x%08x\n",
> - image_get_load(hdr) - image_get_header_size(),
> - image_get_size(hdr) + image_get_header_size()
> - - 0x1FE0);
> + image_get_load(hdr) - image_get_header_size(),
> + (int)(image_get_size(hdr) + image_get_header_size()
> + + sizeof(flash_header_v2_t) - CONFIG_CSF_SIZE));
>   }
>  }
> 
> diff --git a/tools/default_image.c b/tools/default_image.c index
> 4b7d1ed4a1..7a26232779 100644
> --- a/tools/default_image.c
> +++ b/tools/default_image.c
> @@ -19,6 +19,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> 
>  static image_header_t header;
> 
> @@ -106,7 +108,8 @@ static void image_set_header(void *ptr, struct stat
> *sbuf, int ifd,
> 
>   if (params->type == IH_TYPE_FIRMWARE_IVT)
>   /* Add size of CSF minus IVT */
> - imagesize = sbuf->st_size - sizeof(image_header_t) + 0x1FE0;
> + imagesize = sbuf->st_size - sizeof(image_header_t)
> + + CONFIG_CSF_SIZE - sizeof(flash_header_v2_t);
>   else
>   imagesize = sbuf->st_size - sizeof(image_header_t);
> 
> --
> 2.17.1

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

Re: [U-Boot] efi_loader: LoadOptions (bootargs)

[AKASHI Takahiro]

On Wed, Sep 11, 2019 at 07:39:07PM +0200, Heinrich Schuchardt wrote:
> On 9/11/19 8:14 AM, AKASHI Takahiro wrote:
> >Heinrich,
> >
> >On Fri, Aug 23, 2019 at 08:42:27AM +0900, AKASHI Takahiro wrote:
> >>On Thu, Aug 22, 2019 at 07:53:46PM +0200, Heinrich Schuchardt wrote:
> >>>On 8/22/19 11:03 AM, AKASHI Takahiro wrote:
> Heinrich,
> 
> I'm now wondering whether LoadedImage's LoadOptions, which comes
> from "bootargs" variable, should contain a command(application) name
> as a first argument or not.
> 
> When I tried some efi application (efitools), I found that it expected
> so. For example, efitools' UpdateVars.efi takes
>  Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file
> 
> and I had to passed arguments by specifying "foo db DB.auth" for
> "bootargs" where foo makes no sense.
> 
> What do you think about this issue?
> >>>
> >>>Do you relate to
> >>>https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git?
> >>
> >>Yes.
> >>
> >>>This style of parsing LoadOptions is defined by the EFI shell. See
> >>>function ParseCommandLineToArgs() in
> >>>ShellPkg/Application/Shell/ShellParametersProtocol.c.
> >>
> >>So do you mean that Shell.efi is responsible for adding a command name
> >>to LoadOptions (or bootargs) as a first parameter or that LoadOptions
> >>is solely for Shell environment?
> 
> LoadOptions are used to communicate with any EFI binary including the
> Linux kernels. Inside the EFI shell Shell.efi takes care of passing the
> executable name as a first parameter.
> 
> If a user chooses to call an EFI binary which expects its own name as
> first parameter via bootefi, the user should simply add it to
> LoadOptions via 'setenv bootargs'.

Right, but
my concern is that a user normally doesn't care/know if an application
expects that it would be invoked from Shell or with Shell-style arguments.

> I would not change anything in bootefi. Otherwise you start passing
> 'vmlinux' or 'grubaa64.efi' as command line arguments to Linux.

How can users distinguish vmlinux or whatever else from
other apps that would expect Shell-style arguments in general?

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> >>
> >>If so, should we do the same thing at bootefi?
> >
> >Any comment?
> >
> >-Takahiro Akashi
> >
> >
> >>>If UpdateVars.efi would work differently it could not be launched via
> >>>the shell.
> >>
> >>Well, I'm trying to run UpdateVars.efi in a standalone way
> >>by invoking it directly from bootefi/bootmgr and it obviously fails
> >>due to this issue.
> >>
> >>Thanks,
> >>-Takashiro Akashi
> >>
> >>
> >>>Best regards
> >>>
> >>>Heinrich
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: disk: install file system protocol to a whole disk

[AKASHI Takahiro]

On Wed, Sep 11, 2019 at 07:31:31PM +0200, Heinrich Schuchardt wrote:
> On 9/11/19 8:16 AM, AKASHI Takahiro wrote:
> >Heinrich,
> >
> >On Fri, Aug 23, 2019 at 09:04:21AM +0900, AKASHI Takahiro wrote:
> >>On Thu, Aug 22, 2019 at 12:52:41PM +0200, Heinrich Schuchardt wrote:
> >>>On 8/22/19 11:11 AM, Mark Kettenis wrote:
> >From: AKASHI Takahiro 
> >Date: Thu, 22 Aug 2019 17:06:25 +0900
> >
> >Currently, a whole disk without any partitions is not associated
> >with EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. So even if it houses FAT
> >file system, there is a chance that we may not be able to access
> >it, particularly, when accesses are to be attempted after searching
> >that protocol against a device handle.
> >
> >With this patch, EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is installed
> >to such a disk if part_get_info() shows there is not partition
> >table installed on it.
> 
> Do other UEFI implementations support this?
> >>>
> >>>What use cases exist that come without partition table?
> >>
> >>I didn't find any *explicit* description in UEFI specification
> >>that mandates that any block device should have a partition table.
> >>It may be mandatory for boot(able) disks, but for others?
> >>
> >>>You can create an MBR with partition table that is a valid start of a
> >>>file system.
> >>
> >>Obviously we can do that, but if this is not a mandatory requirement,
> >>we'd better support no-partitioned cases.
> 
> I did not mean this as a requirement but as a source of errors.
> 
> My idea is that could have an MBR which by chance looks like the start
> of a file system. When you now expose this non-existent file system the
> UEFI client may create havoc.

See below.

> >
> >Any further comments?
> >
> >-Takahiro Akashi
> >
> >>
> >>>So you should first check if a partition table exists. Only if none
> >>>exists you can test for a possible file system.
> >>
> >>I don't get your point. Are you saying that we should support a file system
> >>for a disk only if it has a file system?
> >>This is not true even for existing partitions as FILE_SYSTEM PROTOCOL
> >>is always installed to every partition whether or not it really
> >>houses a file system under the current implementation.
> 
> That sounds like a bug. If a partition isn't formatted we would not even
> know whether to call the FAT or the EXT4 driver.

Yes, the issue does exist in the current implementation.
So a good approach is
1. Check if a partition table is installed or not
2. If yes,
   2-1 If a partition has a file system, install FILE_SYSTEM_PROTOCOL
   to *that* partition.
   2-2 not install FILE_SYSTEM_PROTOCOL to a whole disk
3. If no, and only if a file system exists, install FILE_SYSTEM_PROTOCOL
   to a whole disk

(2.1) and additional check at (3) should be added.

-Takahiro Akashi


> Regards
> 
> Heinrich
> 
> >>
> >>Thanks,
> >>-Takahiro Akashi
> >>
> >>
> >>>Best regards
> >>>
> >>>Heinrich
> >>>
> 
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  lib/efi_loader/efi_disk.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> >diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> >index 7a6b06821a47..548fe667e6f8 100644
> >--- a/lib/efi_loader/efi_disk.c
> >+++ b/lib/efi_loader/efi_disk.c
> >@@ -239,6 +239,7 @@ static efi_status_t efi_disk_add_dev(
> > struct efi_disk_obj **disk)
> >  {
> > struct efi_disk_obj *diskobj;
> >+disk_partition_t info;
> > efi_status_t ret;
> >
> > /* Don't add empty devices */
> >@@ -270,7 +271,8 @@ static efi_status_t efi_disk_add_dev(
> >diskobj->dp);
> > if (ret != EFI_SUCCESS)
> > return ret;
> >-if (part >= 1) {
> >+/* partitions or whole disk without partitions */
> >+if (part >= 1 || part_get_info(desc, part, )) {
> > diskobj->volume = efi_simple_file_system(desc, part,
> >  diskobj->dp);
> > ret = efi_add_protocol(>header,
> >--
> >2.21.0
> >
> >___
> >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] Issue in u-boot; TFTP error: trying to overwrite reserved memory...

[Simon Goldschmidt]

On 11.09.19 21:33, Moses Christopher wrote:


On Wed, 11 Sep, 2019, 9:12 PM Simon Goldschmidt, 
> wrote:




On 11.09.19 20:59, Moses Christopher wrote:
 >
 > On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt,
 > mailto:simon.k.r.goldschm...@gmail.com>
 > >> wrote:
 >
 >     On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher
 >     mailto:moseschristoph...@gmail.com>
>>
 >     wrote:
 >      >
 >      >
 >      >
 >      > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt,
 >     mailto:simon.k.r.goldschm...@gmail.com>
 >     >> wrote:
 >      >>
 >      >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher
 >      >> mailto:moseschristoph...@gmail.com>
 >     >> wrote:
 >      >> >
 >      >> > Hi Simon,
 >      >> >
 >      >> >
 >      >> > Thanks for the prompt reply.
 >      >> >
 >      >> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt,
 >     mailto:simon.k.r.goldschm...@gmail.com>
 >     >> wrote:
 >      >> >
 >      >> > Hi,
 >      >> >
 >      >> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher
 >      >> > mailto:moseschristoph...@gmail.com>
 >     >> 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
 >      >>
 >      >> Right, tftp.c is missing the call to that funcftion.
Could you
 >     add the
 >      >> call to 'lmb_dump_all();'
 >      >> right below 'lmb_init_and_reserve()' in tftp.c?
 >      >>
 >      >> That should give you the output required. And while at
it, tell us
 >      >> what 'load_addr' is set to
 >      >> (by adding a printf in tftp.c, too).
 >      >>
 >      >> Thanks,
 >      >> Simon
 >      >
 >      >
 >      > Thanks for your patience and time.
 >      >
 >      > Please find the log below,
 >      >
 >      >
 >      >
 >      > DHCP client bound to address 172.17.0.2 (1285 ms)
 >      >
 >      > Using usb_ether device
 >      >
 >      > TFTP from server 172.17.0.1; our IP address is 172.17.0.2
 >      >
 >      > Filename 'u-boot.img'.
 >      >
 >      > lmb_dump_all:
 >      >
 >      >     memory.cnt             = 0x0
 >      >
 >      >     memory.size            = 0xx
 >      >
 >      >
 >      >
 >      >     reserved.cnt           = 0x0
 >      >
 >      >     reserved.size          = 0xx
 >      >
 >      > load_addr: 0x8200
 >      >
 >      >
 >      >
 >      > TFTP error: trying to overwrite reserved memory...
 >      >
 >      > Problem booting with BOOTP
 >      >
 >      >
 >      >
 >      > In my u-boot it shows the DRAM size properly as 256MiB
 >      >
 >      > So, do I need to configure my RAM size in SPL stage as
well, such
 >     that SPL is aware of the memory size ?
 >
 >     Ehrm, are you doing this from SPL?
 >
 >
 > Yes, SPL loads u-boot onto the DRAM from Network, when the NAND
is empty.
 >
 > By flashing the same MLO and u-boot binaries onto the NAND, and then
 > doing *dhcp MLO *from u-boot prompt gives the following log,
 >
 > Using usb_ether device
 > 

[U-Boot] Why do we need both MDIO and MII commands

[Ramon Fried]

Hi.
Marek raised this issue in IRC several weeks ago and I was wondering
the same. why do we support this two commands which accomplish
basically the same ?

Can we ditch the mii comand and move the missing functionality to the
mdio command ?

Thanks,
Ramon.
___
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]

On Wed, 11 Sep, 2019, 9:12 PM Simon Goldschmidt, <
simon.k.r.goldschm...@gmail.com> wrote:

>
>
> On 11.09.19 20:59, Moses Christopher wrote:
> >
> > On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt,
> >  > > wrote:
> >
> > On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher
> > mailto:moseschristoph...@gmail.com>>
> > wrote:
> >  >
> >  >
> >  >
> >  > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt,
> >  > > wrote:
> >  >>
> >  >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher
> >  >>  > > wrote:
> >  >> >
> >  >> > Hi Simon,
> >  >> >
> >  >> >
> >  >> > Thanks for the prompt reply.
> >  >> >
> >  >> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt,
> >  > > 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
> >  >>
> >  >> Right, tftp.c is missing the call to that funcftion. Could you
> > add the
> >  >> call to 'lmb_dump_all();'
> >  >> right below 'lmb_init_and_reserve()' in tftp.c?
> >  >>
> >  >> That should give you the output required. And while at it, tell
> us
> >  >> what 'load_addr' is set to
> >  >> (by adding a printf in tftp.c, too).
> >  >>
> >  >> Thanks,
> >  >> Simon
> >  >
> >  >
> >  > Thanks for your patience and time.
> >  >
> >  > Please find the log below,
> >  >
> >  >
> >  >
> >  > DHCP client bound to address 172.17.0.2 (1285 ms)
> >  >
> >  > Using usb_ether device
> >  >
> >  > TFTP from server 172.17.0.1; our IP address is 172.17.0.2
> >  >
> >  > Filename 'u-boot.img'.
> >  >
> >  > lmb_dump_all:
> >  >
> >  > memory.cnt = 0x0
> >  >
> >  > memory.size= 0xx
> >  >
> >  >
> >  >
> >  > reserved.cnt   = 0x0
> >  >
> >  > reserved.size  = 0xx
> >  >
> >  > load_addr: 0x8200
> >  >
> >  >
> >  >
> >  > TFTP error: trying to overwrite reserved memory...
> >  >
> >  > Problem booting with BOOTP
> >  >
> >  >
> >  >
> >  > In my u-boot it shows the DRAM size properly as 256MiB
> >  >
> >  > So, do I need to configure my RAM size in SPL stage as well, such
> > that SPL is aware of the memory size ?
> >
> > Ehrm, are you doing this from SPL?
> >
> >
> > Yes, SPL loads u-boot onto the DRAM from Network, when the NAND is empty.
> >
> > By flashing the same MLO and u-boot binaries onto the NAND, and then
> > doing *dhcp MLO *from u-boot prompt gives the following log,
> >
> > Using usb_ether device
> > TFTP from server 172.17.0.1; our IP address is 172.17.0.2
> > Filename 'MLO'.
> > *lmb_dump_all:**
> > memory.cnt = 0x1
> > memory.size = 0x0
> > memory.reg[0x0].base = 0x8000
> > .size = 0x1000
> >
> > reserved.cnt = 0x1
> > reserved.size = 0x0
> > reserved.reg[0x0].base = 0x8df2ab98
> > .size = 0x20d5468*
> > load_addr: 0x8020
>
> OK, so that works for a start ;-)
>
> >
> >
> >
> > You need the RAM size for 'lmb_init_and_reserve()' to read, yes.
> > Otherwise it can't know
> > where to safely allocate things.
> >
> > Regards,
> > Simon
> >
> >
> > Would you think, SPL should also do the same or is this valid only for
> > u-boot ?
>
> Yes, SPL should do the same.
>
> >
> > Because, during SPL stage, the RAM would be mostly free anyway, so would
> > you think, we can just use this lmb check only for u-boot but not for
> SPL ?
>
> No. SPL still needs this check. On some platforms, SPL runs with BSS,
> 

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

[Moses Christopher]

On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt, <
simon.k.r.goldschm...@gmail.com> wrote:

> On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher
>  wrote:
> >
> >
> >
> > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, <
> simon.k.r.goldschm...@gmail.com> wrote:
> >>
> >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher
> >>  wrote:
> >> >
> >> > 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
> >>
> >> Right, tftp.c is missing the call to that funcftion. Could you add the
> >> call to 'lmb_dump_all();'
> >> right below 'lmb_init_and_reserve()' in tftp.c?
> >>
> >> That should give you the output required. And while at it, tell us
> >> what 'load_addr' is set to
> >> (by adding a printf in tftp.c, too).
> >>
> >> Thanks,
> >> Simon
> >
> >
> > Thanks for your patience and time.
> >
> > Please find the log below,
> >
> >
> >
> > DHCP client bound to address 172.17.0.2 (1285 ms)
> >
> > Using usb_ether device
> >
> > TFTP from server 172.17.0.1; our IP address is 172.17.0.2
> >
> > Filename 'u-boot.img'.
> >
> > lmb_dump_all:
> >
> > memory.cnt = 0x0
> >
> > memory.size= 0xx
> >
> >
> >
> > reserved.cnt   = 0x0
> >
> > reserved.size  = 0xx
> >
> > load_addr: 0x8200
> >
> >
> >
> > TFTP error: trying to overwrite reserved memory...
> >
> > Problem booting with BOOTP
> >
> >
> >
> > In my u-boot it shows the DRAM size properly as 256MiB
> >
> > So, do I need to configure my RAM size in SPL stage as well, such that
> SPL is aware of the memory size ?
>
> Ehrm, are you doing this from SPL?
>

Yes, SPL loads u-boot onto the DRAM from Network, when the NAND is empty.

By flashing the same MLO and u-boot binaries onto the NAND, and then
doing *dhcp
MLO *from u-boot prompt gives the following log,

Using usb_ether device
TFTP from server 172.17.0.1; our IP address is 172.17.0.2
Filename 'MLO'.
*lmb_dump_all:*








*memory.cnt = 0x1memory.size = 0x0memory.reg[0x0].base = 0x8000.size =
0x1000reserved.cnt = 0x1reserved.size = 0x0reserved.reg[0x0].base =
0x8df2ab98.size = 0x20d5468*
load_addr: 0x8020


>
> You need the RAM size for 'lmb_init_and_reserve()' to read, yes.
> Otherwise it can't know
> where to safely allocate things.
>
> Regards,
> Simon
>

Would you think, SPL should also do the same or is this valid only for
u-boot ?

Because, during SPL stage, the RAM would be mostly free anyway, so would
you think, we can just use this lmb check only for u-boot but not for SPL ?

Regards,
Moses Christopher

>

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

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

[Simon Goldschmidt]

On 11.09.19 20:59, Moses Christopher wrote:


On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt, 
> wrote:


On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher
mailto:moseschristoph...@gmail.com>>
wrote:
 >
 >
 >
 > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt,
mailto:simon.k.r.goldschm...@gmail.com>> wrote:
 >>
 >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher
 >> mailto:moseschristoph...@gmail.com>> wrote:
 >> >
 >> > Hi Simon,
 >> >
 >> >
 >> > Thanks for the prompt reply.
 >> >
 >> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt,
mailto:simon.k.r.goldschm...@gmail.com>> wrote:
 >> >
 >> > Hi,
 >> >
 >> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher
 >> > mailto:moseschristoph...@gmail.com>> 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
 >>
 >> Right, tftp.c is missing the call to that funcftion. Could you
add the
 >> call to 'lmb_dump_all();'
 >> right below 'lmb_init_and_reserve()' in tftp.c?
 >>
 >> That should give you the output required. And while at it, tell us
 >> what 'load_addr' is set to
 >> (by adding a printf in tftp.c, too).
 >>
 >> Thanks,
 >> Simon
 >
 >
 > Thanks for your patience and time.
 >
 > Please find the log below,
 >
 >
 >
 > DHCP client bound to address 172.17.0.2 (1285 ms)
 >
 > Using usb_ether device
 >
 > TFTP from server 172.17.0.1; our IP address is 172.17.0.2
 >
 > Filename 'u-boot.img'.
 >
 > lmb_dump_all:
 >
 >     memory.cnt             = 0x0
 >
 >     memory.size            = 0xx
 >
 >
 >
 >     reserved.cnt           = 0x0
 >
 >     reserved.size          = 0xx
 >
 > load_addr: 0x8200
 >
 >
 >
 > TFTP error: trying to overwrite reserved memory...
 >
 > Problem booting with BOOTP
 >
 >
 >
 > In my u-boot it shows the DRAM size properly as 256MiB
 >
 > So, do I need to configure my RAM size in SPL stage as well, such
that SPL is aware of the memory size ?

Ehrm, are you doing this from SPL?


Yes, SPL loads u-boot onto the DRAM from Network, when the NAND is empty.

By flashing the same MLO and u-boot binaries onto the NAND, and then 
doing *dhcp MLO *from u-boot prompt gives the following log,


Using usb_ether device
TFTP from server 172.17.0.1; our IP address is 172.17.0.2
Filename 'MLO'.
*lmb_dump_all:**
memory.cnt = 0x1
memory.size = 0x0
memory.reg[0x0].base = 0x8000
.size = 0x1000

reserved.cnt = 0x1
reserved.size = 0x0
reserved.reg[0x0].base = 0x8df2ab98
.size = 0x20d5468*
load_addr: 0x8020


OK, so that works for a start ;-)





You need the RAM size for 'lmb_init_and_reserve()' to read, yes.
Otherwise it can't know
where to safely allocate things.

Regards,
Simon


Would you think, SPL should also do the same or is this valid only for 
u-boot ?


Yes, SPL should do the same.



Because, during SPL stage, the RAM would be mostly free anyway, so would 
you think, we can just use this lmb check only for u-boot but not for SPL ?


No. SPL still needs this check. On some platforms, SPL runs with BSS, 
stack or heap in RAM when executing this, so this is still an attack 
vector that should be prevented.


Even if SPL does not use DRAM (only SRAM), we still have to check that 
we only write into valid DRAM addresses. E.g. a file larger than the 
DRAM would write to whatever comes next in the address range...


Which platform are you running this on, does SPL use a devicetree? In 
any case, you need your SPL to provide the valid RAM range.


Regards,
Simon



Regards,
Moses Christopher

 >

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

Re: [U-Boot] efi_loader: LoadOptions (bootargs)

[Heinrich Schuchardt]

On 9/11/19 8:14 AM, AKASHI Takahiro wrote:

Heinrich,

On Fri, Aug 23, 2019 at 08:42:27AM +0900, AKASHI Takahiro wrote:

On Thu, Aug 22, 2019 at 07:53:46PM +0200, Heinrich Schuchardt wrote:

On 8/22/19 11:03 AM, AKASHI Takahiro wrote:

Heinrich,

I'm now wondering whether LoadedImage's LoadOptions, which comes

>from "bootargs" variable, should contain a command(application) name

as a first argument or not.

When I tried some efi application (efitools), I found that it expected
so. For example, efitools' UpdateVars.efi takes
 Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file

and I had to passed arguments by specifying "foo db DB.auth" for
"bootargs" where foo makes no sense.

What do you think about this issue?


Do you relate to
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git?


Yes.


This style of parsing LoadOptions is defined by the EFI shell. See
function ParseCommandLineToArgs() in
ShellPkg/Application/Shell/ShellParametersProtocol.c.


So do you mean that Shell.efi is responsible for adding a command name
to LoadOptions (or bootargs) as a first parameter or that LoadOptions
is solely for Shell environment?


LoadOptions are used to communicate with any EFI binary including the
Linux kernels. Inside the EFI shell Shell.efi takes care of passing the
executable name as a first parameter.

If a user chooses to call an EFI binary which expects its own name as
first parameter via bootefi, the user should simply add it to
LoadOptions via 'setenv bootargs'.

I would not change anything in bootefi. Otherwise you start passing
'vmlinux' or 'grubaa64.efi' as command line arguments to Linux.

Best regards

Heinrich



If so, should we do the same thing at bootefi?


Any comment?

-Takahiro Akashi



If UpdateVars.efi would work differently it could not be launched via
the shell.


Well, I'm trying to run UpdateVars.efi in a standalone way
by invoking it directly from bootefi/bootmgr and it obviously fails
due to this issue.

Thanks,
-Takashiro Akashi



Best regards

Heinrich




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

Re: [U-Boot] [PATCH] efi_loader: disk: install file system protocol to a whole disk

[Heinrich Schuchardt]

On 9/11/19 8:16 AM, AKASHI Takahiro wrote:

Heinrich,

On Fri, Aug 23, 2019 at 09:04:21AM +0900, AKASHI Takahiro wrote:

On Thu, Aug 22, 2019 at 12:52:41PM +0200, Heinrich Schuchardt wrote:

On 8/22/19 11:11 AM, Mark Kettenis wrote:

From: AKASHI Takahiro 
Date: Thu, 22 Aug 2019 17:06:25 +0900

Currently, a whole disk without any partitions is not associated
with EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. So even if it houses FAT
file system, there is a chance that we may not be able to access
it, particularly, when accesses are to be attempted after searching
that protocol against a device handle.

With this patch, EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is installed
to such a disk if part_get_info() shows there is not partition
table installed on it.


Do other UEFI implementations support this?


What use cases exist that come without partition table?


I didn't find any *explicit* description in UEFI specification
that mandates that any block device should have a partition table.
It may be mandatory for boot(able) disks, but for others?


You can create an MBR with partition table that is a valid start of a
file system.


Obviously we can do that, but if this is not a mandatory requirement,
we'd better support no-partitioned cases.


I did not mean this as a requirement but as a source of errors.

My idea is that could have an MBR which by chance looks like the start
of a file system. When you now expose this non-existent file system the
UEFI client may create havoc.



Any further comments?

-Takahiro Akashi




So you should first check if a partition table exists. Only if none
exists you can test for a possible file system.


I don't get your point. Are you saying that we should support a file system
for a disk only if it has a file system?
This is not true even for existing partitions as FILE_SYSTEM PROTOCOL
is always installed to every partition whether or not it really
houses a file system under the current implementation.


That sounds like a bug. If a partition isn't formatted we would not even
know whether to call the FAT or the EXT4 driver.

Regards

Heinrich



Thanks,
-Takahiro Akashi



Best regards

Heinrich




Signed-off-by: AKASHI Takahiro 
---
  lib/efi_loader/efi_disk.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 7a6b06821a47..548fe667e6f8 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -239,6 +239,7 @@ static efi_status_t efi_disk_add_dev(
struct efi_disk_obj **disk)
  {
struct efi_disk_obj *diskobj;
+   disk_partition_t info;
efi_status_t ret;

/* Don't add empty devices */
@@ -270,7 +271,8 @@ static efi_status_t efi_disk_add_dev(
   diskobj->dp);
if (ret != EFI_SUCCESS)
return ret;
-   if (part >= 1) {
+   /* partitions or whole disk without partitions */
+   if (part >= 1 || part_get_info(desc, part, )) {
diskobj->volume = efi_simple_file_system(desc, part,
 diskobj->dp);
ret = efi_add_protocol(>header,
--
2.21.0

___
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] [PATCH 2/2] efi_loader: device_path: support Sandbox's "host" devices

[Heinrich Schuchardt]

On 9/11/19 8:35 AM, AKASHI Takahiro wrote:

Heinrich,

Apologies for having not replied.

On Fri, Aug 23, 2019 at 08:09:45PM +0200, Heinrich Schuchardt wrote:

On 8/23/19 1:34 AM, AKASHI Takahiro wrote:

On Thu, Aug 22, 2019 at 08:19:24PM +0200, Heinrich Schuchardt wrote:

On 8/22/19 10:54 AM, AKASHI Takahiro wrote:

Sandbox's "host" devices are currently described as UCLASS_ROOT udevice
with DEV_IF_HOST block device. As the current implementation of
efi_device_path doesn't support such a type, any "host" device
on sandbox cannot be seen as a distinct object.

For example,
   => host bind 0 /foo/disk.img

   => efi devices
   Scanning disk host0...
   Found 1 disks
   Device   Device Path
    
   15c19970 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
   15c19d70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)

   => efi dh
   Handle   Protocols
    
   15c19970 Device Path, Device Path To Text, Device Path Utilities, 
Unicode Collation 2, HII String, HII Database, HII Config Routing
   15c19ba0 Driver Binding
   15c19c10 Simple Text Output
   15c19c80 Simple Text Input, Simple Text Input Ex
   15c19d70 Block IO, Device Path, Simple File System

As you can see here, efi_root (0x15c19970) and host0 device
(0x15c19d70) has the same representation of device path.

This is not only inconvenient, but also confusing since two different
efi objects are associated with the same device path and
efi_dp_find_obj() will possibly return a wrong result.

Solution:
Each "host" device should be given an additional device path node
of Logical Unit Number(LUN) to make it distinguishable. The result
would be:
   Device   Device Path
    
   15c19970 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
   15c19d70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/LUN(0)

Signed-off-by: AKASHI Takahiro 
---
  lib/efi_loader/efi_device_path.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index eeeb80683607..565bb6888fe1 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -12,6 +12,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 

  /* template END node: */
@@ -422,6 +423,10 @@ static unsigned dp_size(struct udevice *dev)

switch (dev->driver->id) {
case UCLASS_ROOT:
+#ifdef CONFIG_SANDBOX
+   /* stop traversing parents at this point: */
+   return sizeof(ROOT) + sizeof(struct efi_device_path_lun);
+#endif
case UCLASS_SIMPLE_BUS:
/* stop traversing parents at this point: */
return sizeof(ROOT);
@@ -505,6 +510,23 @@ static void *dp_fill(void *buf, struct udevice *dev)
  #ifdef CONFIG_BLK
case UCLASS_BLK:
switch (dev->parent->uclass->uc_drv->id) {
+#ifdef CONFIG_SANDBOX
+   case UCLASS_ROOT: {
+   /* stop traversing parents at this point: */
+   struct efi_device_path_vendor *vdp = buf;
+   struct efi_device_path_lun *dp;
+   struct host_block_dev *host_dev = dev_get_platdata(dev);
+   struct blk_desc *desc = dev_get_uclass_platdata(dev);
+
+   *vdp++ = ROOT;
+   dp = (struct efi_device_path_lun *)vdp;
+   dp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
+   dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_LUN;
+   dp->dp.length = sizeof(*dp);
+   dp->logical_unit_number = desc->devnum;
+   return ++dp;
+   }
+#endif
  #ifdef CONFIG_IDE
case UCLASS_IDE: {
struct efi_device_path_atapi *dp =



Hello Takahiro,

thank you for pointing out that currently we generate the same device
path twice. This for sure is something we need to fix.

In the table below you will find the device tree for

./u-boot -d arch/sandbox/dts/test.dtb

In the device tree I see exactly one root node. I see no device called
host0.


"Host0" or whatever other host device is a pseudo device which will
be dynamically created, like other hot-pluggable devices, by "host bind"
command on sandbox U-Boot. So it won't appear in device tree.

-Takahiro Akashi


Thank you for the explanation.

The host device is shown in the device tree:


"device tree" is a confusing term. Is "dm tree" better?


The README calls it Live Device Tree.
./doc/driver-model/livetree.rst

But yes I mean the tree of the driver model.





make sandbox_defconfig
make
./u-boot
=> host bind 0 ../sct-amd64.img
=> dm tree
  Class Index  Probed  DriverName
---
  root 0  

[U-Boot] [PATCH] net: rtl8169: Support RTL-8168c/8111c

[Thierry Reding]

From: Thierry Reding 

This version of the RTL-8168 chip can be found on some add-in cards sold
by CSL-Computer GmbH & Co. KG. The chip isn't special in any way, but it
needs to have the ChipCmd register programmed after the DMA descriptors
have been set up, so make sure that happens by adding an entry to the
chip information table.

Signed-off-by: Thierry Reding 
---
 drivers/net/rtl8169.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index 521e5909a256..d887d00928f6 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -252,6 +252,7 @@ static struct {
{"RTL-8169sc/8110sc",   0x18, 0xff7e1880,},
{"RTL-8168b/8111sb",0x30, 0xff7e1880,},
{"RTL-8168b/8111sb",0x38, 0xff7e1880,},
+   {"RTL-8168c/8111c", 0x3c, 0xff7e1880,},
{"RTL-8168d/8111d", 0x28, 0xff7e1880,},
{"RTL-8168evl/8111evl", 0x2e, 0xff7e1880,},
{"RTL-8168/8111g",  0x4c, 0xff7e1880,},
-- 
2.23.0

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

[U-Boot] [PATCH 1/1] efi_loader parameter checks EFI_FILE_PROTOCOL.SetInfo()

[Heinrich Schuchardt]

We do not support volume label changes. No parameter checks are needed
here.

When the info for as file is changed the buffer must always contain a file
name.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_file.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index b79dc5fd29..98edd9830c 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -695,7 +695,9 @@ static efi_status_t EFIAPI efi_file_setinfo(struct 
efi_file_handle *file,
char *new_file_name, *pos;
loff_t file_size;

-   if (buffer_size < sizeof(struct efi_file_info)) {
+   /* The buffer will always contain a file name. */
+   if (buffer_size < sizeof(struct efi_file_info) + 2 ||
+   buffer_size < info->size) {
ret = EFI_BAD_BUFFER_SIZE;
goto out;
}
@@ -735,12 +737,8 @@ static efi_status_t EFIAPI efi_file_setinfo(struct 
efi_file_handle *file,
 * TODO: Support read only
 */
ret = EFI_SUCCESS;
-   } else if (!guidcmp(info_type, _file_system_info_guid)) {
-   if (buffer_size < sizeof(struct efi_file_system_info)) {
-   ret = EFI_BAD_BUFFER_SIZE;
-   goto out;
-   }
} else {
+   /* TODO: We do not support changing the volume label */
ret = EFI_UNSUPPORTED;
}
 out:
--
2.23.0

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

[U-Boot] [PATCH 1/1] efi_loader: check parameters EFI_FILE_PROTOCOL.GetInfo()

[Heinrich Schuchardt]

Check the parameters of EFI_FILE_PROTOCOL.GetInfo() to avoid possible NULL
dereference.

Check the buffer size for EFI_FILE_SYSTEM_INFO.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_file.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 2f03ae71fc..b79dc5fd29 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -596,6 +596,12 @@ static efi_status_t EFIAPI efi_file_getinfo(struct 
efi_file_handle *file,

EFI_ENTRY("%p, %pUl, %p, %p", file, info_type, buffer_size, buffer);

+   if (!file || !info_type || !buffer_size ||
+   (*buffer_size && !buffer)) {
+   ret = EFI_INVALID_PARAMETER;
+   goto error;
+   }
+
if (!guidcmp(info_type, _file_info_guid)) {
struct efi_file_info *info = buffer;
char *filename = basename(fh);
--
2.23.0

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

[U-Boot] [PATCH 1/1] efi_loader: volume name in EFI_FILE_PROTOCOL.GetInfo()

[Heinrich Schuchardt]

We cannot determine the volume name in U-Boot. Instead of providing a dummy
volume name in case of EFI_FILE_SYSTEM_INFO and EFI_UNSUPPORTED in case of
EFI_FILE_SYSTEM_VOLUME_LABEL consistently return an empty string.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_api.h |  4 
 lib/efi_loader/efi_file.c | 18 --
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index cb895f31e5..b665036c8d 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -1505,6 +1505,10 @@ struct efi_simple_file_system_protocol {
EFI_GUID(0x09576e93, 0x6d3f, 0x11d2, \
 0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)

+#define EFI_FILE_SYSTEM_VOLUME_LABEL_ID \
+   EFI_GUID(0xdb47d7d3, 0xfe81, 0x11d3, \
+0x9a, 0x35, 0x00, 0x90, 0x27, 0x3f, 0xC1, 0x4d)
+
 #define EFI_FILE_MODE_READ 0x0001
 #define EFI_FILE_MODE_WRITE0x0002
 #define EFI_FILE_MODE_CREATE   0x8000
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 504b1d1755..2f03ae71fc 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -15,6 +15,9 @@
 /* GUID for file system information */
 const efi_guid_t efi_file_system_info_guid = EFI_FILE_SYSTEM_INFO_GUID;

+/* GUID to obtain the volume label */
+const efi_guid_t efi_system_volume_label_id = EFI_FILE_SYSTEM_VOLUME_LABEL_ID;
+
 struct file_system {
struct efi_simple_file_system_protocol base;
struct efi_device_path *dp;
@@ -637,9 +640,7 @@ static efi_status_t EFIAPI efi_file_getinfo(struct 
efi_file_handle *file,
ret = EFI_DEVICE_ERROR;
goto error;
}
-   required_size = sizeof(*info) + 2 *
-   (utf8_utf16_strlen((const char *)part.name) +
-1);
+   required_size = sizeof(*info) + 2;
if (*buffer_size < required_size) {
*buffer_size = required_size;
ret = EFI_BUFFER_TOO_SMALL;
@@ -655,10 +656,15 @@ static efi_status_t EFIAPI efi_file_getinfo(struct 
efi_file_handle *file,
info->block_size = part.blksz;
/*
 * TODO: The volume label is not available in U-Boot.
-* Use the partition name as substitute.
 */
-   dst = info->volume_label;
-   utf8_utf16_strcpy(, (const char *)part.name);
+   info->volume_label[0] = 0;
+   } else if (!guidcmp(info_type, _system_volume_label_id)) {
+   if (*buffer_size < 2) {
+   *buffer_size = 2;
+   ret = EFI_BUFFER_TOO_SMALL;
+   goto error;
+   }
+   *(u16 *)buffer = 0;
} else {
ret = EFI_UNSUPPORTED;
}
--
2.23.0

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

[U-Boot] [PATCH] arm64: versal: Remove unneeded configs for mini configurations

[Michal Simek]

From: Siva Durga Prasad Paladugu 

The PSCI_RESET and EXPERT are not needed for mini configurations so remove
them to save space.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 configs/xilinx_versal_mini_defconfig   | 2 ++
 configs/xilinx_versal_mini_emmc0_defconfig | 2 ++
 configs/xilinx_versal_mini_emmc1_defconfig | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/configs/xilinx_versal_mini_defconfig 
b/configs/xilinx_versal_mini_defconfig
index 98759d0705e2..742aa1208aeb 100644
--- a/configs/xilinx_versal_mini_defconfig
+++ b/configs/xilinx_versal_mini_defconfig
@@ -8,6 +8,8 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_SYS_MALLOC_LEN=0x2000
 CONFIG_SYS_MEM_RSVD_FOR_MMU=y
 CONFIG_COUNTER_FREQUENCY=272
+# CONFIG_PSCI_RESET is not set
+# CONFIG_EXPERT is not set
 # CONFIG_LEGACY_IMAGE_FORMAT is not set
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 # CONFIG_BOARD_LATE_INIT is not set
diff --git a/configs/xilinx_versal_mini_emmc0_defconfig 
b/configs/xilinx_versal_mini_emmc0_defconfig
index 49386e21d3d0..7610abf4dbab 100644
--- a/configs/xilinx_versal_mini_emmc0_defconfig
+++ b/configs/xilinx_versal_mini_emmc0_defconfig
@@ -7,6 +7,8 @@ CONFIG_ENV_SIZE=0x80
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SYS_MALLOC_LEN=0x8
 CONFIG_COUNTER_FREQUENCY=272
+# CONFIG_PSCI_RESET is not set
+# CONFIG_EXPERT is not set
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 # CONFIG_BOARD_LATE_INIT is not set
 # CONFIG_DISPLAY_CPUINFO is not set
diff --git a/configs/xilinx_versal_mini_emmc1_defconfig 
b/configs/xilinx_versal_mini_emmc1_defconfig
index 5de1873dad65..ffc913a6eb97 100644
--- a/configs/xilinx_versal_mini_emmc1_defconfig
+++ b/configs/xilinx_versal_mini_emmc1_defconfig
@@ -7,6 +7,8 @@ CONFIG_ENV_SIZE=0x80
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SYS_MALLOC_LEN=0x8
 CONFIG_COUNTER_FREQUENCY=272
+# CONFIG_PSCI_RESET is not set
+# CONFIG_EXPERT is not set
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 # CONFIG_BOARD_LATE_INIT is not set
 # CONFIG_DISPLAY_CPUINFO is not set
-- 
2.17.1

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

[U-Boot] [PATCH] arm64: versal: mini_emmc: Enable fatwrite support

[Michal Simek]

From: Siva Durga Prasad Paladugu 

This patch enable fatwrite support for mini emmc configurations.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 configs/xilinx_versal_mini_emmc0_defconfig | 1 +
 configs/xilinx_versal_mini_emmc1_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/xilinx_versal_mini_emmc0_defconfig 
b/configs/xilinx_versal_mini_emmc0_defconfig
index 08d23243bee4..49386e21d3d0 100644
--- a/configs/xilinx_versal_mini_emmc0_defconfig
+++ b/configs/xilinx_versal_mini_emmc0_defconfig
@@ -50,4 +50,5 @@ CONFIG_DEFAULT_DEVICE_TREE="versal-mini-emmc0"
 # CONFIG_DM_DEVICE_REMOVE is not set
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
+CONFIG_FAT_WRITE=y
 # CONFIG_EFI_LOADER is not set
diff --git a/configs/xilinx_versal_mini_emmc1_defconfig 
b/configs/xilinx_versal_mini_emmc1_defconfig
index fef5cadd6ea7..5de1873dad65 100644
--- a/configs/xilinx_versal_mini_emmc1_defconfig
+++ b/configs/xilinx_versal_mini_emmc1_defconfig
@@ -50,4 +50,5 @@ CONFIG_DEFAULT_DEVICE_TREE="versal-mini-emmc1"
 # CONFIG_DM_DEVICE_REMOVE is not set
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ZYNQ=y
+CONFIG_FAT_WRITE=y
 # CONFIG_EFI_LOADER is not set
-- 
2.17.1

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

[U-Boot] [PATCH] env: Kconfig: Add environment default offset in versal

[Michal Simek]

From: T Karthik Reddy 

This patch adds default offset & sector size values for environment
variables to save in qspi/ospi flash for versal.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

 env/Kconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/env/Kconfig b/env/Kconfig
index 74db2f38cc19..e4ba12ece3f6 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -473,6 +473,7 @@ config ENV_OFFSET
default 0x88000 if ARCH_SUNXI
default 0xE if ARCH_ZYNQ
default 0x1E0 if ARCH_ZYNQMP
+   default 0x7F4 if ARCH_VERSAL
default 0 if ARC
default 0x14 if ARCH_AT91
default 0x26 if ARCH_OMAP2PLUS
@@ -491,8 +492,8 @@ config ENV_SIZE
 
 config ENV_SECT_SIZE
hex "Environment Sector-Size"
-   depends on (!ENV_IS_NOWHERE && (ARCH_ZYNQ || ARCH_ZYNQMP || 
ARCH_OMAP2PLUS || ARCH_AT91) )|| ARCH_STM32MP
-   default 0x4 if ARCH_ZYNQMP
+   depends on (!ENV_IS_NOWHERE && (ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL 
|| ARCH_OMAP2PLUS || ARCH_AT91) )|| ARCH_STM32MP
+   default 0x4 if ARCH_ZYNQMP || ARCH_VERSAL
default 0x2 if ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
help
  Size of the sector containing the environment.
-- 
2.17.1

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

[U-Boot] [PATCH] drivers: usb: dwc3: setup phy before dwc3 core soft reset

[Michal Simek]

From: T Karthik Reddy 

Phy setup should be done before dwc3 soft core reset as it is done
in linux & this fixes unreliable detection of usb cable on host side.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/usb/dwc3/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 56e2a046bf06..2498f0efb1a4 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -440,6 +440,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
goto err0;
}
 
+   dwc3_phy_setup(dwc);
+
ret = dwc3_core_soft_reset(dwc);
if (ret)
goto err0;
@@ -514,8 +516,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
 
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
 
-   dwc3_phy_setup(dwc);
-
ret = dwc3_alloc_scratch_buffers(dwc);
if (ret)
goto err0;
-- 
2.17.1

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

[U-Boot] [PATCH] arm64: zynqmp: Enable 2 NAND chips support for zynqmp_mini_nand

[Michal Simek]

From: T Karthik Reddy 

This patch enables 2 nand chips support for zynqmp mini nand

Signed-off-by: T Karthik Reddy 
Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

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

diff --git a/configs/xilinx_zynqmp_mini_nand_defconfig 
b/configs/xilinx_zynqmp_mini_nand_defconfig
index 4be624813ccf..2b896f79a72e 100644
--- a/configs/xilinx_zynqmp_mini_nand_defconfig
+++ b/configs/xilinx_zynqmp_mini_nand_defconfig
@@ -49,4 +49,5 @@ CONFIG_DEFAULT_DEVICE_TREE="zynqmp-mini-nand"
 # CONFIG_MMC is not set
 CONFIG_NAND=y
 CONFIG_NAND_ARASAN=y
+CONFIG_SYS_NAND_MAX_CHIPS=2
 # CONFIG_EFI_LOADER is not set
-- 
2.17.1

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

[Simon Goldschmidt]

On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher
 wrote:
>
>
>
> On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, 
>  wrote:
>>
>> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher
>>  wrote:
>> >
>> > Hi Simon,
>> >
>> >
>> > Thanks for the prompt reply.
>> >
>> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, 
>> >  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
>>
>> Right, tftp.c is missing the call to that funcftion. Could you add the
>> call to 'lmb_dump_all();'
>> right below 'lmb_init_and_reserve()' in tftp.c?
>>
>> That should give you the output required. And while at it, tell us
>> what 'load_addr' is set to
>> (by adding a printf in tftp.c, too).
>>
>> Thanks,
>> Simon
>
>
> Thanks for your patience and time.
>
> Please find the log below,
>
>
>
> DHCP client bound to address 172.17.0.2 (1285 ms)
>
> Using usb_ether device
>
> TFTP from server 172.17.0.1; our IP address is 172.17.0.2
>
> Filename 'u-boot.img'.
>
> lmb_dump_all:
>
> memory.cnt = 0x0
>
> memory.size= 0xx
>
>
>
> reserved.cnt   = 0x0
>
> reserved.size  = 0xx
>
> load_addr: 0x8200
>
>
>
> TFTP error: trying to overwrite reserved memory...
>
> Problem booting with BOOTP
>
>
>
> In my u-boot it shows the DRAM size properly as 256MiB
>
> So, do I need to configure my RAM size in SPL stage as well, such that SPL is 
> aware of the memory size ?

Ehrm, are you doing this from SPL?

You need the RAM size for 'lmb_init_and_reserve()' to read, yes.
Otherwise it can't know
where to safely allocate things.

Regards,
Simon


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

[U-Boot] [PATCH v2] doc: README.xilinx: Add dt bindings

[Michal Simek]

From: T Karthik Reddy 

Devicetree bindings are already specified in Linux kernel documentation.
Instead of maintaining same dt bindings in U-Boot doc specify path to dt
bindings in Linux kernel & documenting specific changes that are in U-Boot.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

Changes in v2:
- Convert file to reST format - reported by Bin
- Fix commit message

 doc/board/xilinx/index.rst  |  1 +
 doc/board/xilinx/xilinx.rst | 38 +
 2 files changed, 39 insertions(+)
 create mode 100644 doc/board/xilinx/xilinx.rst

diff --git a/doc/board/xilinx/index.rst b/doc/board/xilinx/index.rst
index 2416fbd216cd..47f09290af03 100644
--- a/doc/board/xilinx/index.rst
+++ b/doc/board/xilinx/index.rst
@@ -6,4 +6,5 @@ Xilinx
 .. toctree::
:maxdepth: 2
 
+   xilinx
zynq
diff --git a/doc/board/xilinx/xilinx.rst b/doc/board/xilinx/xilinx.rst
new file mode 100644
index ..f6ea5dbe2158
--- /dev/null
+++ b/doc/board/xilinx/xilinx.rst
@@ -0,0 +1,38 @@
+.. SPDX-License-Identifier: GPL-2.0+
+..  (C) Copyright 2019 Xilinx, Inc.
+
+U-Boot device tree bindings
+
+
+All the device tree bindings used in U-Boot are specified in Linux
+kernel. Please refer dt bindings from below specified paths in Linux
+kernel.
+
+* ata
+   - Documentation/devicetree/bindings/ata/ahci-ceva.txt
+* gpio
+   - Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
+   - Documentation/devicetree/bindings/gpio/gpio-zynq.txt
+* i2c
+   - Documentation/devicetree/bindings/i2c/i2c-xiic.txt
+   - Documentation/devicetree/bindings/i2c/i2c-cadence.txt
+* mmc
+   - Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+* net
+   - Documentation/devicetree/bindings/net/macb.txt
+   - Documentation/devicetree/bindings/net/xilinx_axienet.txt
+   - Documentation/devicetree/bindings/net/xilinx_emaclite.txt
+* serial
+   - Documentation/devicetree/bindings/serial/cdns,uart.txt
+   - Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.txt
+* spi
+   - Documentation/devicetree/bindings/spi/spi-cadence.txt
+   - Documentation/devicetree/bindings/spi/spi-xilinx.txt
+   - Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
+   - Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
+* usb
+   - Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
+   - Documentation/devicetree/bindings/usb/dwc3.txt
+   - Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+* wdt
+   - Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
-- 
2.17.1

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

Re: [U-Boot] [PATCH] env: Add CONFIG_ENV_SUPPORT

[Patrick DELAUNAY]

Hi Wolfgang an Tom,

> 
> Dear Patrick,
> 
> In message <9c7801afb8c94c638933cf33746ae...@sfhdag6node3.st.com>
> you wrote:
> >
> > And I agree the name seens not perfect.
> >
> > > > - CONFIG_SPL_ENV_SUPPORT for SPL
> > > > - CONFIG_TPL_ENV_SUPPORT for TPL
> >
> > These pre-existing name are defined in common/spl/Kconfig
> >
> > With the same issue (env/common.o env/env.o are always compiled for
> > SPL/TPL so it is alo bad names)
> 
> Correct.
> 
> > > So please reconsider this whole implementation, and make sure that
> > > only a single macro ise used everywhere to enable these features.
> >
> > But, if I use the same CONFIG for the 3 binary SPL,TPL and U-Boot, l
> > increase the size of TPL/SPL for all the platforms when these
> > additional features are not needed.
> 
> Either the U-Boot environment makes use of these features, then they have to 
> be
> enabled, and exactly the same way in SPL, TPL and U-Boot proper.  Or you don't
> need them, then they can be disabled, but again in a consistent way in SPL, 
> TPL,
> and U-Boot proper.
> 
> It is not acceptable to have for example .flags support in U-Boot, but not is 
> SPL.
> If you cannot affort the size in SPL (and need environment there at all), 
> then you
> cannot have it in U-Boot either.
> Yes, this is sad, but anything else would break the implementation of these
> features, and given that they are often used to implement some level of 
> protection
> or security, introduce massive security issues.
> 
> 
> So if SPL size is critical, you can try do not access the environment at all 
> and omit
> _all_ of the environment code there; or you can try to arrange for a read-only
> implementation (omitting at least the code needed for "env save" including 
> write
> routines to storage).  But you CANNOT omit the extensions if these are 
> present in
> U-Boot proper.

I am working on a update of the first proposal and I will delivered it in 2 
step:

1- a  simple patch to solve the regression
(to have short term solution  / integration in master as requested by Tom)

2- introduction of CONFGI_ENV_FULL_SUPPORT
=> compilation of attr / flags / callback for TPL/SPL/U-boot
=> feature can't be remove in SPL/TPL independently 
As proposed by Wolfgang


> Best regards,
> 
> Wolfgang Denk
> 

Regards

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

[U-Boot] [RFC PATCH] mmc: sdhci: add support for switching to UHS-I modes on ZynqMP Platform

[Michal Simek]

From: T Karthik Reddy 

This patch adds support for switching to UHS-I modes on ZynqMP platform.
There is one issue with the ZynqMP ZCU102 where it is not able to power
cycle the SD card. Due to this once the card is initialized in UHS-I
mode it cannot be reinitialized in UHS-I mode again. So to solve this
issue there are some of the checks are made in place to ensure that the
card operates in UHS-I mode even on reinitialization. This will enable
the SD host controller to run SD at UHS-I mode in u-boot if it was
running at UHS-I mode already.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

 drivers/mmc/mmc.c | 20 
 include/mmc.h |  2 ++
 2 files changed, 22 insertions(+)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index c8f71cd0c1b6..3d25f11942ff 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1711,6 +1711,26 @@ static int sd_select_mode_and_width(struct mmc *mmc, 
uint card_caps)
/* Restrict card's capabilities by what the host can do */
caps = card_caps & mmc->host_caps;
 
+   /*
+* If the card is already in 1.8V and the system doesn't have
+* mechanism to power cycle the SD card, it will respond with no 1.8V
+* supported in OCR response. Below check will confirm if the above
+* condition has occurred.
+*
+* If the host is supporting UHS modes and the card is supporting SD
+* specification 3.0 and above, it can operate at UHS modes.
+*/
+#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT)
+   if (!uhs_en && !(mmc_host_is_spi(mmc)) &&
+   mmc->scr[0] & SD_SCR0_SPEC3 &&
+   (mmc->card_caps & MMC_MODE_MASK) >= MMC_CAP(UHS_SDR50) &&
+   (mmc->host_caps & MMC_MODE_MASK) >= MMC_CAP(UHS_SDR50)) {
+   uhs_en = true;
+   err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
+   if (err)
+   return err;
+   }
+#endif
if (!uhs_en)
caps &= ~UHS_CAPS;
 
diff --git a/include/mmc.h b/include/mmc.h
index 686ba0065654..e959ffef2948 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -66,6 +66,7 @@
 #define MMC_MODE_HS200 MMC_CAP(MMC_HS_200)
 #define MMC_MODE_HS400 MMC_CAP(MMC_HS_400)
 #define MMC_MODE_HS400_ES  MMC_CAP(MMC_HS_400_ES)
+#define MMC_MODE_MASK  (MMC_CAP(MMC_MODES_END) - 1)
 
 #define MMC_CAP_NONREMOVABLE   BIT(14)
 #define MMC_CAP_NEEDS_POLL BIT(15)
@@ -140,6 +141,7 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
 /* SCR definitions in different words */
 #define SD_HIGHSPEED_BUSY  0x0002
 #define SD_HIGHSPEED_SUPPORTED 0x0002
+#define SD_SCR0_SPEC3  BIT(15)
 
 #define UHS_SDR12_BUS_SPEED0
 #define HIGH_SPEED_BUS_SPEED   1
-- 
2.17.1

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

[U-Boot] [PATCH] mmc: zynq_sdhci: Remove check for DM_MMC config

[Michal Simek]

From: Siva Durga Prasad Paladugu 

The zynq_sdhci drivers depends on DM_MMC in Kconfig so no need to check for
DM_MMC in the driver so this patch removes it.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/mmc/zynq_sdhci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 3225a7ac9385..529eec9c45cd 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -190,7 +190,7 @@ static void arasan_sdhci_set_control_reg(struct sdhci_host 
*host)
 }
 #endif
 
-#if defined(CONFIG_DM_MMC) && defined(CONFIG_ARCH_ZYNQMP)
+#if defined(CONFIG_ARCH_ZYNQMP)
 const struct sdhci_ops arasan_ops = {
.platform_execute_tuning= _sdhci_execute_tuning,
.set_delay = _sdhci_set_tapdelay,
@@ -266,7 +266,7 @@ static int arasan_sdhci_ofdata_to_platdata(struct udevice 
*dev)
 
priv->host->name = dev->name;
 
-#if defined(CONFIG_DM_MMC) && defined(CONFIG_ARCH_ZYNQMP)
+#if defined(CONFIG_ARCH_ZYNQMP)
priv->host->ops = _ops;
 #endif
 
-- 
2.17.1

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

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

[Faiz Abbas]

Vignesh,

On 10/09/19 9:18 AM, Vignesh Raghavendra wrote:
> 
> 
> 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.

Replaced it.

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

Ok.

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

Ok. Going back to writel/readl calls.

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

Implemented this for v2. Thanks.

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

[U-Boot] [PATCH] arm64: zynqmp: Switch spi-flash to jedec, spi-nor compatible

[Michal Simek]

Change has been done across the whole tree only zynqmp-mini-qspi hasn't
been fixed.
Origin changed done by commit ffd4c7c2ecb7
("dts: switch spi-flash to jedec, spi-nor compatible")

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-mini-qspi.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/zynqmp-mini-qspi.dts 
b/arch/arm/dts/zynqmp-mini-qspi.dts
index 1716d5179ddf..e4ba5ae9b683 100644
--- a/arch/arm/dts/zynqmp-mini-qspi.dts
+++ b/arch/arm/dts/zynqmp-mini-qspi.dts
@@ -64,7 +64,7 @@
  {
status = "okay";
flash0: flash@0 {
-   compatible = "n25q512a11", "spi-flash";
+   compatible = "n25q512a11", "jedec,spi-nor";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0>;
-- 
2.17.1

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

Re: [U-Boot] [PATCH] doc: README.xilinx: Add dt bindings

[Michal Simek]

On 11. 09. 19 15:43, Bin Meng wrote:
> On Wed, Sep 11, 2019 at 9:41 PM Michal Simek  wrote:
>>
>> From: T Karthik Reddy 
>>
>> Devicetree bindings are already specified in linux kernel
>> documentation. Instead of maintaining same dt bindings in u-boot
>> we are specifying path to dt bindings in linux kernel & documenting
>> specific changes that are in u-boot.
>>
>> Signed-off-by: T Karthik Reddy 
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  doc/README.xilinx | 34 ++
>>  1 file changed, 34 insertions(+)
>>  create mode 100644 doc/README.xilinx
>>
> 
> Please stop creating plaint text docs. Instead create reST format docs. 
> Thanks!

Ok. Will take a look.

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

Re: [U-Boot] [PATCH] doc: README.xilinx: Add dt bindings

[Bin Meng]

On Wed, Sep 11, 2019 at 9:41 PM Michal Simek  wrote:
>
> From: T Karthik Reddy 
>
> Devicetree bindings are already specified in linux kernel
> documentation. Instead of maintaining same dt bindings in u-boot
> we are specifying path to dt bindings in linux kernel & documenting
> specific changes that are in u-boot.
>
> Signed-off-by: T Karthik Reddy 
> Signed-off-by: Michal Simek 
> ---
>
>  doc/README.xilinx | 34 ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 doc/README.xilinx
>

Please stop creating plaint text docs. Instead create reST format docs. Thanks!

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

[U-Boot] [PATCH] doc: README.xilinx: Add dt bindings

[Michal Simek]

From: T Karthik Reddy 

Devicetree bindings are already specified in linux kernel
documentation. Instead of maintaining same dt bindings in u-boot
we are specifying path to dt bindings in linux kernel & documenting
specific changes that are in u-boot.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

 doc/README.xilinx | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 doc/README.xilinx

diff --git a/doc/README.xilinx b/doc/README.xilinx
new file mode 100644
index ..22e9c89c16b7
--- /dev/null
+++ b/doc/README.xilinx
@@ -0,0 +1,34 @@
+U-Boot device tree bindings:
+
+
+All the device tree bindings used in u-boot are specified in Linux
+kernel. Please refer dt bindings from below specified paths in Linux
+kernel.
+
+ata:   Documentation/devicetree/bindings/ata/ahci-ceva.txt
+
+gpio:  Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
+   Documentation/devicetree/bindings/gpio/gpio-zynq.txt
+
+i2c:   Documentation/devicetree/bindings/i2c/i2c-xiic.txt
+   Documentation/devicetree/bindings/i2c/i2c-cadence.txt
+
+mmc:   Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+
+net:   Documentation/devicetree/bindings/net/macb.txt
+   Documentation/devicetree/bindings/net/xilinx_axienet.txt
+   Documentation/devicetree/bindings/net/xilinx_emaclite.txt
+
+serial:Documentation/devicetree/bindings/serial/cdns,uart.txt
+   Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.txt
+
+spi:   Documentation/devicetree/bindings/spi/spi-cadence.txt
+   Documentation/devicetree/bindings/spi/spi-xilinx.txt
+   Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
+   Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
+
+usb:   Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
+   Documentation/devicetree/bindings/usb/dwc3.txt
+   Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+
+wdt:   Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
-- 
2.17.1

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

Re: [U-Boot] [PATCH PATCH v4 00/15] Add support for applications of overlays in SPL

[Jean-Jacques Hiblot]

Hi Simon,

On 13/08/2019 11:33, Simon Glass wrote:

Hi Jean-Jacques,

On Mon, 5 Aug 2019 at 03:44, Jean-Jacques Hiblot  wrote:


The purpose of this series is to provide the SPL with ability to apply
overlays for u-boot. this is only a RFC so far, to get a feedback on the
approach.

Our use-case is the support of the daughter boards of the AM65x EVM. In
Linux, each board is supported by a unique overlay. The presence of the
boards is detected at runtime, and some useful features (like USB) are
implemented on those daughter boards. Instead of providing multiple dtbs
and fall in a combinatorial pit, we propose to use DT overlays.

But why do this in SPL? Is it so U-Boot can use the DT with overlays
itself for driver model?


Sorry for the long delay.

You are right, the goal is to be able to apply DTB overlays in the SPL 
so that u-boot the DTB+ overlays for its driver model.


Our platform for example has optional daughter cards with various 
combination of PCIe, USB and Ethernet.


At the kernel level the hardware is described in separate overlays. 
U-boot is responsible to detect the HW and load/apply the needed overlays.


We want to do the same in u-boot and the SPL will load/apply the right 
overlays.


JJ




Patch #2 "spl: fit: Add support for applying DT overlay" has been posted
a few weeks ago by Michal Simek.
Patch #3 to #6 amend Michal's patch.
Patch #7 to #9 are simple fixes for the Makefile
Patch #10 is used to reduce the complexity of the Makefile by having FIT
generator scripts provide their dependencies
Patch #12-#13 allow to use the board driver in SPL
Patch #14-#15 adds a way to dynamically select the DT overlays. That is
were we would use HW detection to select the required overlays. In that
case, the board driver code tells what overlay it needs (it gives the
name of the node).

On arm, if overlay are supported, this series increases the size of the SPL
by 3.2 kB.

Travis build : https://travis-ci.org/jjhiblot/u-boot/builds/567779404

Changes in v4:
- use CONFIG_IS_ENABLED() instead of #idef
- make sure that the temp buffer is freed in all cases
- Use the board driver infrastructure to get the image names from the
board code.
- Remove a patch that passed the board name to the FIT generator. If needed
the generator can get it from elsewhere
- Add a fix to not load the firmware twice (once as a firmware and once as
a loadable)

Changes in v3:
- Add a new config option: SPL_LOAD_FIT_APPLY_OVERLAY. By default, it is
not selected.
- removed the RFC prefix. This work will be needed soon by TI's AM65x
platform. and can probably benefit other modular platforms
- removed the last patch that provided an example of how to use this with
on a DRA76.
- removed the patch that made u-boot.img a symlink to u-boot.itb because
it breaks the build of many platforms (because files required to build the
ITB are missing)
- removed the patch to reduce the footprint of the am335x SPL. (already
merged)
- Made the boot flow more permissive (don't fail immediately if an overlay
is not present) and more verbose when an error occures
- handle the dependencies of the FIT generation in a more generic way
- use a dedicated kconfig option to enable the application of the overlays
by the SPL.

Changes in v2:
- reworked board_fit_get_additionnal_images() and how it used in spl_fit.c
- removed dtbo generation from dtso files and use .dts extension for the
   overlays
- add dynamic allocation usage in a separate patch
- defconfig change for the am335x_evm

Jean-Jacques Hiblot (14):
   spl: fit: don't load the firmware twice
   spl: fit: Make room in the FDT before applying overlays
   spl: fit: allocate a temporary buffer to load the overlays
   spl: fit: Do not fail immediately if an overlay is not available
   spl: fit: be more verbose when an error occurs when applying the
 overlays
   Makefile.lib: include /__symbols__ in dtb if
 SPL_LOAD_FIT_APPLY_OVERLAY is enabled
   Makefile: Fix tests for CONFIG_SPL_LOAD_FIT and
 CONFIG_SPL_FIT_GENERATOR
   Makefile: Fix u-boot.itb generation when building outside the source
 tree
   Makefile: Query the SPL Fit Generator for its dependencies
   spl: fit: constify the output parameter of spl_fit_get_image_name()
   drivers: board: Make the board drivers available in SPL
   drivers: board: Add get_fit_loadable()
   include: board: provide empty stubs when the BOARD option is not
 selected
   spl: fit: Allow the board to tell if more images must be loaded from
 FIT

Michal Simek (1):
   spl: fit: Add support for applying DT overlay

  Kconfig   |   9 ++
  Makefile  |  23 ++--
  arch/arm/mach-imx/mkimage_fit_atf.sh  |   5 +
  arch/arm/mach-rockchip/make_fit_atf.py|   7 ++
  board/sunxi/mksunxi_fit_atf.sh|   4 +
  .../lion_rk3368/fit_spl_atf.its   |   6 +-
  .../puma_rk3399/fit_spl_atf.sh|   6 +
  common/spl/spl_fit.c

[U-Boot] [PATCH] cmd: avoid decimal conversion

[Michal Simek]

From: T Karthik Reddy 

This patch uses auto instead of decimal in simple_strtoul().

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

 cmd/test.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/cmd/test.c b/cmd/test.c
index fa0c349f0827..258bfd880653 100644
--- a/cmd/test.c
+++ b/cmd/test.c
@@ -113,28 +113,28 @@ static int do_test(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
expr = strcmp(ap[0], ap[2]) > 0;
break;
case OP_INT_EQ:
-   expr = simple_strtol(ap[0], NULL, 10) ==
-   simple_strtol(ap[2], NULL, 10);
+   expr = simple_strtol(ap[0], NULL, 0) ==
+   simple_strtol(ap[2], NULL, 0);
break;
case OP_INT_NEQ:
-   expr = simple_strtol(ap[0], NULL, 10) !=
-   simple_strtol(ap[2], NULL, 10);
+   expr = simple_strtol(ap[0], NULL, 0) !=
+   simple_strtol(ap[2], NULL, 0);
break;
case OP_INT_LT:
-   expr = simple_strtol(ap[0], NULL, 10) <
-   simple_strtol(ap[2], NULL, 10);
+   expr = simple_strtol(ap[0], NULL, 0) <
+   simple_strtol(ap[2], NULL, 0);
break;
case OP_INT_LE:
-   expr = simple_strtol(ap[0], NULL, 10) <=
-   simple_strtol(ap[2], NULL, 10);
+   expr = simple_strtol(ap[0], NULL, 0) <=
+   simple_strtol(ap[2], NULL, 0);
break;
case OP_INT_GT:
-   expr = simple_strtol(ap[0], NULL, 10) >
-   simple_strtol(ap[2], NULL, 10);
+   expr = simple_strtol(ap[0], NULL, 0) >
+   simple_strtol(ap[2], NULL, 0);
break;
case OP_INT_GE:
-   expr = simple_strtol(ap[0], NULL, 10) >=
-   simple_strtol(ap[2], NULL, 10);
+   expr = simple_strtol(ap[0], NULL, 0) >=
+   simple_strtol(ap[2], NULL, 0);
break;
case OP_FILE_EXISTS:
expr = file_exists(ap[1], ap[2], ap[3], FS_TYPE_ANY);
-- 
2.17.1

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

Re: [U-Boot] Add support for imxrt

[Giulio Benetti]

Hi Stefano,

On 9/11/19 8:50 AM, Stefano Babic wrote:

Hi Giulio,

On 10/09/19 20:32, Giulio Benetti wrote:

Hello everybody,

I would like to port imxrt to u-boot and I would like to ask you:
- do you have the interest on upstreaming it?
if yes:
I've seen how they've dealt with 'stm32' and 'stm32mp' that is similar
to 'imxrt' and 'imx'. So should follow the same criterias for porting? I
mean adding the new folder 'mach-imxrt'?


Agree - we should follow the same schema.


Well, thanks for clarifying that to me.
Going to work on it soon.

Best regards
--
Giulio Benetti
Benetti Engineering sas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Add support for imxrt

[Giulio Benetti]

Hi Fabio,

On 9/11/19 12:23 AM, Fabio Estevam wrote:

Hi Giulio,

On Tue, Sep 10, 2019 at 3:32 PM Giulio Benetti
 wrote:


Hello everybody,

I would like to port imxrt to u-boot and I would like to ask you:
- do you have the interest on upstreaming it?
if yes:
I've seen how they've dealt with 'stm32' and 'stm32mp' that is similar
to 'imxrt' and 'imx'. So should follow the same criterias for porting? I
mean adding the new folder 'mach-imxrt'?


Yes, please submit the patches to the U-Boot list for review.


Ok, going to work on it then.

Best regards
--
Giulio Benetti
Benetti Engineering sas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH PATCH v4 04/15] spl: fit: allocate a temporary buffer to load the overlays

[Jean-Jacques Hiblot]

Hi Simon,

On 13/08/2019 11:33, Simon Glass wrote:

Hi Jean-Jacques,

On Mon, 5 Aug 2019 at 03:44, Jean-Jacques Hiblot  wrote:

If the node describing an overlay does not specify a load address, it will
be loaded at the address previously used.
Fixing it by allocating a temporary 64kB region that will be used as a
default load address.

How did you come to decide on 64KB? Might this be too large or too small?


It seemed big enough to me to accommodate a DTB overlay.

There is no easy way to know how big the buffer must be without reading 
it first because it can be compressed.





Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v4:
- make sure that the temp buffer is freed in all cases

Changes in v3: None
Changes in v2: None

  common/spl/spl_fit.c | 28 +++-
  1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ab47da5094..977074cd99 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -8,8 +8,9 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
+#include 

  #ifndef CONFIG_SYS_BOOTM_LEN
  #define CONFIG_SYS_BOOTM_LEN   (64 << 20)
@@ -302,33 +303,50 @@ static int spl_fit_append_fdt(struct spl_image_info 
*spl_image,
 spl_image->fdt_addr = (void *)image_info.load_addr;
  #if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
 if (CONFIG_IS_ENABLED(LOAD_FIT_APPLY_OVERLAY)) {
+   void *tmpbuffer;
+   /*
+* allocate 64KB of memory. This will be used to store the DT
+* overlay before it is applied. It may not be used depending on
+* how the overlay is stored, so don't fail yet if the
+* allocation failed.
+*/
+   tmpbuffer = malloc(64 * 1024);
+   if (!tmpbuffer)
+   debug("%s: unable to allocate space for overlays\n",
+ __func__);

Can you adjust this to only allocate buf when you find it is needed?

could be done.



+
 for (; ; index++) {
 node = spl_fit_get_image_node(fit, images, 
FIT_FDT_PROP,
   index);
 if (node < 0) {
 debug("%s: No additional FDT node\n", 
__func__);
-   return 0;
+   break;
 }

+   image_info.load_addr = (ulong)tmpbuffer;

map_to_sysmem() or this won't work on sandbox.

ok



 ret = spl_load_fit_image(info, sector, fit, 
base_offset,
  node, _info);
 if (ret < 0)
-   return ret;
+   break;

 /* Make room in FDT for changes from the overlay */
 ret = fdt_increase_size(spl_image->fdt_addr,
 image_info.size);
 if (ret < 0)
-   return ret;
+   break;

 ret = fdt_overlay_apply_verbose(spl_image->fdt_addr,
 (void 
*)image_info.load_addr);

map_sysmem()


 if (ret)
-   return ret;
+   break;

 debug("%s: DT overlay %s applied\n", __func__,
   fit_get_name(fit, node, NULL));
 }
+   if (tmpbuffer)
+   free(tmpbuffer);
+   if (ret)
+   return ret;
 }
 /* Try to make space, so we can inject details on the loadables */
 ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
--
2.17.1


Regads,
Simon


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

[Jean-Jacques Hiblot]

On 09/09/2019 18:03, Neil Armstrong wrote:

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.


I posted today the v4 of a series that uses the DWC3 core for host 
operations.


Can you give it try? The goal is ultimately to be able to replace 
platform-specific dwc3 host implementation.


JJ



Neil


Regards,
Bin




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

Re: [U-Boot] [PATCH] arm: at91: gardena-smart-gateway-at91sam: Enable CONFIG_SYS_NAND_USE_FLASH_BBT

[Stefan Roese]

Hi Eugen,

On 27.08.19 09:54, eugen.hris...@microchip.com wrote:



On 27.08.2019 09:14, Stefan Roese wrote:



This patch enables the BBT in NAND on the AT91SAM based GARDENA smart
Gateway. This is especially important, since the Linux driver also
enables this option and uses the BBT table pages. Without setting this
option, U-Boot will try to re-use these pages again (e.g. UBI).

Signed-off-by: Stefan Roese 
Cc: Eugen Hristev 
Cc: Tom Rini 
---
Eugen, I would advise you to double-check, if your AT91 based boards
using NAND also have this BBT option enabled in Linux. If yes, its
definitely necessary to enable it in U-Boot as well to match the same
layout.


Hi Stefan,

Thank you for the patch.
I will look into it with help of Tudor and provide some feedback.


Do you have any updates on this?

Would it be possible to apply this patch for the upcoming release?

Thanks,
Stefan
 

Eugen



   configs/gardena-smart-gateway-at91sam_defconfig | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/configs/gardena-smart-gateway-at91sam_defconfig 
b/configs/gardena-smart-gateway-at91sam_defconfig
index c495ba4612..4a2cc331a6 100644
--- a/configs/gardena-smart-gateway-at91sam_defconfig
+++ b/configs/gardena-smart-gateway-at91sam_defconfig
@@ -17,6 +17,7 @@ CONFIG_DEBUG_UART_BASE=0xf200
   CONFIG_DEBUG_UART_CLOCK=13200
   CONFIG_SMBIOS_PRODUCT_NAME="at91sam9x5ek"
   CONFIG_DEBUG_UART=y
+CONFIG_SPL_TEXT_BASE=0x30
   CONFIG_FIT=y
   CONFIG_NAND_BOOT=y
   CONFIG_BOOTDELAY=3
@@ -24,7 +25,6 @@ CONFIG_USE_BOOTARGS=y
   CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk 
mtdparts=atmel_nand:256k(bootstrap)ro,768k(uboot)ro,256k(env_redundant),256k(env),512k(dtb),6M(kernel)ro,-(rootfs)
 rootfstype=ubifs ubi.mtd=6 root=ubi0:rootfs rw"
   CONFIG_SYS_CONSOLE_IS_IN_ENV=y
   CONFIG_SYS_CONSOLE_INFO_QUIET=y
-CONFIG_SPL_TEXT_BASE=0x30
   CONFIG_SPL_SYS_MALLOC_SIMPLE=y
   CONFIG_SPL_SEPARATE_BSS=y
   # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
@@ -66,7 +66,6 @@ CONFIG_AT91_GPIO=y
   CONFIG_LED=y
   CONFIG_LED_GPIO=y
   # CONFIG_MMC is not set
-# CONFIG_SYS_NAND_USE_FLASH_BBT is not set
   CONFIG_NAND_ATMEL=y
   CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER=y
   CONFIG_DM_ETH=y


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



Viele Grüße,
Stefan

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

[U-Boot] [PATCH] board: atmel: sama5d27_wlsom1_ek: fix SPL OFFS on SPI

[Eugen.Hristev]

From: Eugen Hristev 

Fixes redefinition of CONFIG_SYS_SPI_U_BOOT_OFFS
This is now a Kconfig

Fixes: 3e541a6e8fba ("board: atmel: sama5d2_wlsom1_ek: add qspi support and 
qspi boot config")
Signed-off-by: Eugen Hristev 
---

From the initial submission of the board add patch until it was accepted,
SPI_U_BOOT_OFFS was converted to Kconfig. Fixed with this patch.


 configs/sama5d27_wlsom1_ek_qspiflash_defconfig | 3 ++-
 include/configs/sama5d27_wlsom1_ek.h   | 4 
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/configs/sama5d27_wlsom1_ek_qspiflash_defconfig 
b/configs/sama5d27_wlsom1_ek_qspiflash_defconfig
index ec05af1..82568e2 100644
--- a/configs/sama5d27_wlsom1_ek_qspiflash_defconfig
+++ b/configs/sama5d27_wlsom1_ek_qspiflash_defconfig
@@ -16,6 +16,7 @@ CONFIG_ENV_SECT_SIZE=0x1000
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DEBUG_UART=y
+CONFIG_SPL_TEXT_BASE=0x20
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
 CONFIG_FIT=y
 CONFIG_SYS_EXTRA_OPTIONS="SAMA5D2"
@@ -26,12 +27,12 @@ CONFIG_USE_BOOTARGS=y
 CONFIG_MISC_INIT_R=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_SPL_TEXT_BASE=0x20
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_DISPLAY_PRINT=y
 # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_AT91_MCK_BYPASS=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x4
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
diff --git a/include/configs/sama5d27_wlsom1_ek.h 
b/include/configs/sama5d27_wlsom1_ek.h
index 250eb73..6bcbc06 100644
--- a/include/configs/sama5d27_wlsom1_ek.h
+++ b/include/configs/sama5d27_wlsom1_ek.h
@@ -43,8 +43,4 @@
 #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"
 #endif
 
-#ifdef CONFIG_QSPI_BOOT
-#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x4
-#endif
-
 #endif
-- 
2.7.4

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

Re: [U-Boot] [RFC PATCH v1 0/5] imx: nandbcb: support for i.MX7 and bcb only updates

[Peng Fan]

+Alice who is also working on same feature including more nand chips and
i.MX family support.

Regards,
Peng.

> Subject: [RFC PATCH v1 0/5] imx: nandbcb: support for i.MX7 and bcb only
> updates
> 
> This introduces support for writing BCB(FCB/FDDT) for i.MX7 and additional
> subcommand for writing BCB only (without firmware).
> 
> Igor Opaniuk (5):
>   imx: gpmi: add defines for hw randominizer
>   nand: mxs_nand: add API for switching different BCH layouts
>   imx: nandbcb: add support for i.MX7
>   imx: nandbcb: refactor update function
>   imx: nandbcb: add support for writing BCB only
> 
>  arch/arm/include/asm/mach-imx/imx-nandbcb.h |  12 +
>  arch/arm/include/asm/mach-imx/regs-gpmi.h   |   5 +
>  arch/arm/mach-imx/Kconfig   |   2 +-
>  arch/arm/mach-imx/Makefile  |   1 +
>  arch/arm/mach-imx/cmd_nandbcb.c | 308
> +++-
>  drivers/mtd/nand/raw/mxs_nand.c | 120 
>  include/mxs_nand.h  |  25 ++
>  7 files changed, 397 insertions(+), 76 deletions(-)
> 
> --
> 2.17.1

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

[U-Boot] [NXP-IMX] please pull nxp-imx-9-11-2019

[Peng Fan]

Hi Stefano,

Please pull nxp-imx-9-11-2019. This pull request was based on imx/master.

But I also created a new branch based on origin/master, imx-master-9-11-2019 and
CI is based the branch: https://travis-ci.org/MrVan/u-boot/builds/583504418


Fix usb start issue for i.MX6Q-SDB DM
Move U-Boot specific dts change to u-boot.dtsi for i.MX6QDL
Fix U-Boot RAW sector for i.MX8QXP-MEK
i.MX8 Container support
misc i.MX8QM bug fix and update.


Thanks,
Peng.

The following changes since commit 333027284f9a591747ec469ede2b13b3fb8df65a:

  Merge branch 'nxp-imx-8-13' of https://github.com/MrVan/u-boot (2019-08-18 
12:10:11 +0200)

are available in the Git repository at:

  https://github.com/MrVan/u-boot.git nxp-imx-9-11-2019

for you to fetch changes up to cacc604a32591b682b1b6440c6f48f7fcdef3f8b:

  imx8: cpu: fix mac fuse word for i.MX8QM (2019-09-11 20:32:07 +0800)


Peng Fan (21):
  imx: mx6sabresd: fix usb start when DM enabled
  imx: imx6qdl: dtsi: move U-Boot specific change to u-boot.dtsi
  imx: imx8qxp_mek: fix CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
  imx8: support parsing i.MX8 Container file
  spl: mmc: support loading i.MX container format file
  imx: add container target
  imx8qxp_mek: switch to use container image
  imx8qm_mek: switch to use container image
  doc: imx: mkimage: introduce i.MX8 image format
  imx: sys_proto: add is_imx8qm helper
  imx8qm: power up SMMU
  imx8qm: correct fdt_file
  imx8: disable node when the resource is not owned
  configs: imx8qm/qxp_mek: enable CONFIG_OF_SYSTEM_SETUP
  imx: scu_api: add sc_rm_set_master_sid
  imx8: fdt: configure sid for masters
  imx8: save args passed from ATF
  imx8: fdt: add optee node
  imx: scu_api: add sc_pm_is_partition_started
  imx8: move i.MX8 cpu desc code to drivers/cpu/imx8_cpu.c
  imx8: cpu: fix mac fuse word for i.MX8QM

Ye Li (1):
  imx8: Probe the SCU driver by using uclass function

 Makefile|   8 
 arch/arm/dts/imx6qdl-u-boot.dtsi|   6 +++
 arch/arm/dts/imx6qdl.dtsi   |   3 --
 arch/arm/include/asm/arch-imx8/image.h  |  56 
 arch/arm/include/asm/arch-imx8/sci/rpc.h|   5 ++-
 arch/arm/include/asm/arch-imx8/sci/sci.h|   2 +
 arch/arm/include/asm/arch-imx8/sys_proto.h  |   1 +
 arch/arm/include/asm/mach-imx/sys_proto.h   |   1 +
 arch/arm/mach-imx/Makefile  |  14 +-
 arch/arm/mach-imx/imx8/Kconfig  |  13 ++
 arch/arm/mach-imx/imx8/Makefile |   7 ++-
 arch/arm/mach-imx/imx8/cpu.c| 189 
++--
 arch/arm/mach-imx/imx8/fdt.c| 292 

 arch/arm/mach-imx/imx8/lowlevel_init.S  |  36 
 arch/arm/mach-imx/imx8/parse-container.c| 120 
+++
 board/freescale/imx8qm_mek/README   |   4 +-
 board/freescale/imx8qm_mek/uboot-container.cfg  |  13 ++
 board/freescale/imx8qxp_mek/README  |   4 +-
 board/freescale/imx8qxp_mek/uboot-container.cfg |  13 ++
 common/spl/spl_mmc.c|  10 +
 configs/imx8qm_mek_defconfig|   9 ++--
 configs/imx8qxp_mek_defconfig   |   6 +--
 configs/mx6sabresd_defconfig|   1 +
 doc/imx/mkimage/imx8image.txt   |  45 +++
 drivers/cpu/Makefile|   1 +
 drivers/cpu/imx8_cpu.c  | 182 
+
 drivers/misc/imx8/scu_api.c |  49 +
 include/configs/imx8qm_mek.h|   2 +-
 include/configs/imx8qxp_mek.h   |   2 +-
 include/spl.h   |  12 ++
 30 files changed, 910 insertions(+), 196 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-imx8/image.h
 create mode 100644 arch/arm/mach-imx/imx8/fdt.c
 create mode 100644 arch/arm/mach-imx/imx8/lowlevel_init.S
 create mode 100644 arch/arm/mach-imx/imx8/parse-container.c
 create mode 100644 board/freescale/imx8qm_mek/uboot-container.cfg
 create mode 100644 board/freescale/imx8qxp_mek/uboot-container.cfg
 create mode 100644 doc/imx/mkimage/imx8image.txt
 create mode 100644 drivers/cpu/imx8_cpu.c
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] arm64: versal: Also record versal name to versal fragment

[Michal Simek]

Just to make sure that also drivers with versal name are assigned to proper
fragment.

Signed-off-by: Michal Simek 
---

Changes in v2:
- Avoid reporting myself with any universal platfrom - reported by Heinrich

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 08222fd56948..9b3c46eff0aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -403,6 +403,7 @@ M:  Michal Simek 
 S: Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze.git
 F: arch/arm/mach-versal/
+N: (?
-- 
2.17.1

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

[U-Boot] [PATCH v3] net: phy: Add gmiitorgmii converter support

[Michal Simek]

From: Siva Durga Prasad Paladugu 

This patch adds support for gmiitorgmii converter.
This converter sits between the MAC and the external phy
MAC <==> GMII2RGMII <==> RGMII_PHY.
The ethernet driver probes this bridge and this bridge driver
probes real phy driver and invokes the real phy functionalities
as requested. This bridge just needs to be configured based on
real phy negotiated speed and duplex.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

Changes in v3:
- Check that input interface type is gmii
- Hardcode rgmii interface type
- Add check for external phy detection
- Fill node pointer for external phy
- Define readext and writeext routines

Changes in v2:
- Include "net: phy: Fix logic around gmiitorgmii wiring" patch
- Update patch on the top of
 "net: phy: Add clause 45 identifier to phy_device
 (sha1: b3eabd82f21b4d9206622fc5aee16751d2f4be8f) which adds one more
 parameter to phy_device_create (bool is_c45)

It is quite a long time when I sent v2 on this. There were some changes we
found in connection to this driver and it's wiring.

DT binding is present here.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt

v2
https://lists.denx.de/pipermail/u-boot/2019-January/356777.html
v1
https://lists.denx.de/pipermail/u-boot/2018-November/349309.html

---
 drivers/net/phy/Kconfig |   7 ++
 drivers/net/phy/Makefile|   1 +
 drivers/net/phy/phy.c   |  42 
 drivers/net/phy/xilinx_gmii2rgmii.c | 144 
 include/phy.h   |   6 ++
 5 files changed, 200 insertions(+)
 create mode 100644 drivers/net/phy/xilinx_gmii2rgmii.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 2a3da068c90a..30bd8e765304 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -228,6 +228,13 @@ config PHY_VITESSE
 config PHY_XILINX
bool "Xilinx Ethernet PHYs support"
 
+config PHY_XILINX_GMII2RGMII
+   bool "Xilinx GMII to RGMII Ethernet PHYs support"
+   help
+ This adds support for Xilinx GMII to RGMII IP core. This IP acts
+ as bridge between MAC connected over GMII and external phy that
+ is connected over RGMII interface.
+
 config PHY_FIXED
bool "Fixed-Link PHY"
depends on DM_ETH
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 555da83630f4..76b6197009bc 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_PHY_SMSC) += smsc.o
 obj-$(CONFIG_PHY_TERANETICS) += teranetics.o
 obj-$(CONFIG_PHY_TI) += ti.o
 obj-$(CONFIG_PHY_XILINX) += xilinx_phy.o
+obj-$(CONFIG_PHY_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
 obj-$(CONFIG_PHY_VITESSE) += vitesse.o
 obj-$(CONFIG_PHY_MSCC) += mscc.o
 obj-$(CONFIG_PHY_FIXED) += fixed.o
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 8c4043445e86..f2d17aa91a07 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -544,6 +544,9 @@ int phy_init(void)
 #endif
 #ifdef CONFIG_PHY_FIXED
phy_fixed_init();
+#endif
+#ifdef CONFIG_PHY_XILINX_GMII2RGMII
+   phy_xilinx_gmii2rgmii_init();
 #endif
genphy_init();
 
@@ -918,6 +921,41 @@ void phy_connect_dev(struct phy_device *phydev, struct 
eth_device *dev)
debug("%s connected to %s\n", dev->name, phydev->drv->name);
 }
 
+#ifdef CONFIG_PHY_XILINX_GMII2RGMII
+#ifdef CONFIG_DM_ETH
+static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus,
+struct udevice *dev,
+phy_interface_t interface)
+#else
+static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus,
+struct eth_device *dev,
+phy_interface_t interface)
+#endif
+{
+   struct phy_device *phydev = NULL;
+   int sn = dev_of_offset(dev);
+   int off;
+
+   while (sn > 0) {
+   off = fdt_node_offset_by_compatible(gd->fdt_blob, sn,
+   "xlnx,gmii-to-rgmii-1.0");
+   if (off > 0) {
+   phydev = phy_device_create(bus, off,
+  PHY_GMII2RGMII_ID, false,
+  interface);
+   break;
+   }
+   if (off == -FDT_ERR_NOTFOUND)
+   sn = fdt_first_subnode(gd->fdt_blob, sn);
+   else
+   printf("%s: Error finding compat string:%d\n",
+  __func__, off);
+   }
+
+   return phydev;
+}
+#endif
+
 #ifdef CONFIG_PHY_FIXED
 #ifdef CONFIG_DM_ETH
 static struct phy_device *phy_connect_fixed(struct mii_dev *bus,
@@ -964,6 +1002,10 @@ struct phy_device *phy_connect(struct mii_dev *bus, int 
addr,
 

Re: [U-Boot] Use of the go command

[Wolfgang Denk]

Dear Gregor,

In message <42665f37f2da4296b1c923f92ac30...@tq-group.com> you wrote:
> 
> i use the go command from the hush shell to execute a function
> from environment. That function has been initially compiled in
> U-Boot and was first called in board_late_init().

Urg...

> I call the function by using 
> go #address

Go is supposed to be used with standalone programs only.

> My question is now: Is it safe to use the go command to execute
> U-boot functions or do I miss something here?

You are invoking undefined behaviour.

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
"No proper program contains  an  indication  which  as  an  operator-
applied  occurrence  identifies an operator-defining occurrence which
as an indication-applied occurrence identifies an indication-defining
occurrence different from the one identified by the given  indication
as an indication-applied occurrence."   - ALGOL 68 Report
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] xilinx: Add support for SBC

[Michal Simek]

On 11. 09. 19 9:18, Michal Simek wrote:
> There is a need to differentiate fit images for Zynq and ZynqMP U-Boot.
> Zynq is going to use u-boot-zynq.img and ZynqMP u-boot-zynqmp.img.
> 
> Signed-off-by: Michal Simek 
> ---
> 
>  include/configs/topic_miami.h   | 1 +
>  include/configs/xilinx_zynqmp.h | 2 +-
>  include/configs/zynq-common.h   | 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/configs/topic_miami.h b/include/configs/topic_miami.h
> index b98656dd4c17..2ff0f694bb69 100644
> --- a/include/configs/topic_miami.h
> +++ b/include/configs/topic_miami.h
> @@ -24,6 +24,7 @@
>  #undef CONFIG_SPL_ETH_SUPPORT
>  #undef CONFIG_SPL_MAX_FOOTPRINT
>  #define CONFIG_SPL_MAX_FOOTPRINT CONFIG_SYS_SPI_U_BOOT_OFFS
> +#undef CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
>  #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img"
>  
>  /* sspi command isn't useful */
> diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
> index a1c55a83069e..ddeb24a0af6e 100644
> --- a/include/configs/xilinx_zynqmp.h
> +++ b/include/configs/xilinx_zynqmp.h
> @@ -235,7 +235,7 @@
>  # define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR   0 /* unused */
>  # define CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS  0 /* unused */
>  # define CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR 0 /* unused */
> -# define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img"
> +# define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-zynqmp.img"
>  #endif
>  
>  #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_DFU)
> diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
> index ae08ebf2afc1..c765875ca85d 100644
> --- a/include/configs/zynq-common.h
> +++ b/include/configs/zynq-common.h
> @@ -277,7 +277,7 @@
>  /* MMC support */
>  #ifdef CONFIG_MMC_SDHCI_ZYNQ
>  #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
> -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot.img"
> +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-zynq.img"
>  #endif
>  
>  /* Address in RAM where the parameters must be copied by SPL. */
> 

Andre: This should be also aligned with generation of these files.
Mostly cp u-boot.img $CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
Have you played with this?

Thanks,
Michal

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

[U-Boot] [PATCH 2/5] ARM: zynq: Enable USB1 as secondary boot device

[Michal Simek]

Xilinx Zynq SoC has two usb controllers and both could be used as secondary
boot method.

Signed-off-by: Michal Simek 
---

 include/configs/zynq-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 824efa9c004b..de6c06ba3ce7 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -117,7 +117,7 @@
 #endif
 
 #ifdef CONFIG_CMD_USB
-#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
+#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0) func(USB, usb, 1)
 #else
 #define BOOT_TARGET_DEVICES_USB(func)
 #endif
-- 
2.17.1

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

[U-Boot] [PATCH 3/5] ARM: zynq: Fix NOR boot mode

[Michal Simek]

There are two typos in this command that's why it couldn't work properly.
This bootmode is almost unused from the beggining on this SoC.

Fixes: 90e97ab31e02 ("arm: zynq: Define distro boot commnads for qspi, nand and 
nor")
Signed-off-by: Michal Simek 
---

 include/configs/zynq-common.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index de6c06ba3ce7..09eada39023c 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -175,7 +175,8 @@
"nand "
 
 #define BOOTENV_DEV_NOR(devtypeu, devtypel, instance) \
-   "bootcmd_nor=cp.b $scropt_offset_nor $scriptaddr $script_size_f && " \
+   "script_offset_nor=0xE2FC\0"\
+   "bootcmd_nor=cp.b ${script_offset_nor} ${scriptaddr} ${script_size_f} 
&& " \
 "source ${scriptaddr}; echo SCRIPT FAILED: 
continuing...;\0"
 
 #define BOOTENV_DEV_NAME_NOR(devtypeu, devtypel, instance) \
@@ -205,7 +206,6 @@
"fdt_high=0x2000\0" \
"initrd_high=0x2000\0"  \
"scriptaddr=0x2\0"  \
-   "script_offser_nor=0xE2FC\0"\
"script_offset_f=0xFC\0"\
"script_size_f=0x4\0"   \
"loadbootenv_addr=0x200\0" \
-- 
2.17.1

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

[U-Boot] [PATCH 5/5] ARM: zynq: Remove all Xilinx private commands

[Michal Simek]

All platforms have been moved to distro boot that's why remove the rest of
configurations to have unified boot flow.

Signed-off-by: Michal Simek 
---

 include/configs/zynq-common.h | 54 ++-
 1 file changed, 3 insertions(+), 51 deletions(-)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 4b12be30c8aa..b6c9f2c8dd5b 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -152,12 +152,6 @@
 # define BOOT_TARGET_DEVICES_NOR(func)
 #endif
 
-#define BOOTENV_DEV_XILINX(devtypeu, devtypel, instance) \
-   "bootcmd_xilinx=run $modeboot\0"
-
-#define BOOTENV_DEV_NAME_XILINX(devtypeu, devtypel, instance) \
-   "xilinx "
-
 #define BOOTENV_DEV_QSPI(devtypeu, devtypel, instance) \
"bootcmd_qspi=sf probe 0 0 0 && " \
  "sf read ${scriptaddr} ${script_offset_f} 
${script_size_f} && " \
@@ -189,8 +183,7 @@
BOOT_TARGET_DEVICES_NOR(func) \
BOOT_TARGET_DEVICES_USB(func) \
BOOT_TARGET_DEVICES_PXE(func) \
-   BOOT_TARGET_DEVICES_DHCP(func) \
-   func(XILINX, xilinx, na)
+   BOOT_TARGET_DEVICES_DHCP(func)
 
 #include 
 #endif /* CONFIG_SPL_BUILD */
@@ -198,59 +191,18 @@
 /* Default environment */
 #ifndef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
-   "fit_image=fit.itb\0"   \
-   "load_addr=0x200\0" \
-   "fit_size=0x80\0"   \
-   "flash_off=0x10\0"  \
-   "nor_flash_off=0xE210\0"\
"fdt_high=0x2000\0" \
"initrd_high=0x2000\0"  \
"scriptaddr=0x2\0"  \
"script_offset_f=0xFC\0"\
"script_size_f=0x4\0"   \
-   "loadbootenv_addr=0x200\0" \
"fdt_addr_r=0x1f0\0"\
"pxefile_addr_r=0x200\0"\
"kernel_addr_r=0x200\0" \
"scriptaddr=0x300\0"\
"ramdisk_addr_r=0x310\0"\
-   "bootenv=uEnv.txt\0" \
-   "bootenv_dev=mmc\0" \
-   "loadbootenv=load ${bootenv_dev} 0 ${loadbootenv_addr} ${bootenv}\0" \
-   "importbootenv=echo Importing environment from ${bootenv_dev} ...; " \
-   "env import -t ${loadbootenv_addr} $filesize\0" \
-   "bootenv_existence_test=test -e ${bootenv_dev} 0 /${bootenv}\0" \
-   "setbootenv=if env run bootenv_existence_test; then " \
-   "if env run loadbootenv; then " \
-   "env run importbootenv; " \
-   "fi; " \
-   "fi; \0" \
-   "sd_loadbootenv=setenv bootenv_dev mmc && " \
-   "run setbootenv \0" \
-   "usb_loadbootenv=setenv bootenv_dev usb && usb start && run setbootenv 
\0" \
-   "preboot=if test $modeboot = sdboot; then " \
-   "run sd_loadbootenv; " \
-   "echo Checking if uenvcmd is set ...; " \
-   "if test -n $uenvcmd; then " \
-   "echo Running uenvcmd ...; " \
-   "run uenvcmd; " \
-   "fi; " \
-   "fi; \0" \
-   "norboot=echo Copying FIT from NOR flash to RAM... && " \
-   "cp.b ${nor_flash_off} ${load_addr} ${fit_size} && " \
-   "bootm ${load_addr}\0" \
-   "sdboot=echo Copying FIT from SD to RAM... && " \
-   "load mmc 0 ${load_addr} ${fit_image} && " \
-   "bootm ${load_addr}\0" \
-   "jtagboot=echo TFTPing FIT to RAM... && " \
-   "tftpboot ${load_addr} ${fit_image} && " \
-   "bootm ${load_addr}\0" \
-   "usbboot=if usb start; then " \
-   "echo Copying FIT from USB to RAM... && " \
-   "load usb 0 ${load_addr} ${fit_image} && " \
-   "bootm ${load_addr}; fi\0" \
-   DFU_ALT_INFO \
-   BOOTENV
+   DFU_ALT_INFO \
+   BOOTENV
 #endif
 
 /* Miscellaneous configurable options */
-- 
2.17.1

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

[U-Boot] [PATCH 4/5] ARM: zynq: Use {} around variables for qspi and nand boot cmds

[Michal Simek]

Follow conventions and used {} around variables.

Fixes: 90e97ab31e02 ("arm: zynq: Define distro boot commnads for qspi, nand and 
nor")
Signed-off-by: Michal Simek 
---

 include/configs/zynq-common.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 09eada39023c..4b12be30c8aa 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -160,7 +160,7 @@
 
 #define BOOTENV_DEV_QSPI(devtypeu, devtypel, instance) \
"bootcmd_qspi=sf probe 0 0 0 && " \
- "sf read $scriptaddr $script_offset_f $script_size_f && " 
\
+ "sf read ${scriptaddr} ${script_offset_f} 
${script_size_f} && " \
  "source ${scriptaddr}; echo SCRIPT FAILED: 
continuing...;\0"
 
 #define BOOTENV_DEV_NAME_QSPI(devtypeu, devtypel, instance) \
@@ -168,7 +168,7 @@
 
 #define BOOTENV_DEV_NAND(devtypeu, devtypel, instance) \
"bootcmd_nand=nand info && " \
- "nand read $scriptaddr $script_offset_f $script_size_f && 
" \
+ "nand read ${scriptaddr} ${script_offset_f} 
${script_size_f} && " \
  "source ${scriptaddr}; echo SCRIPT FAILED: 
continuing...;\0"
 
 #define BOOTENV_DEV_NAME_NAND(devtypeu, devtypel, instance) \
-- 
2.17.1

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

[U-Boot] [PATCH 1/5] ARM: zynq: Specify MMC controller number for boot sequence

[Michal Simek]

Xilinx Zynq SoC has two sdhci controllers but boot is only possible from
the first one. That's why there is a need to specify controller number.
mmc1 is supposed to be secondary boot device and should be also listed in
distribution boot.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynq/board.c | 2 +-
 include/configs/zynq-common.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 35191b2f813b..7cfe69db6935 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -52,7 +52,7 @@ int board_late_init(void)
env_set("modeboot", "norboot");
break;
case ZYNQ_BM_SD:
-   mode = "mmc";
+   mode = "mmc0";
env_set("modeboot", "sdboot");
break;
case ZYNQ_BM_JTAG:
diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 283a78494116..824efa9c004b 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -111,7 +111,7 @@
 #else
 
 #ifdef CONFIG_CMD_MMC
-#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0)
+#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1)
 #else
 #define BOOT_TARGET_DEVICES_MMC(func)
 #endif
-- 
2.17.1

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

[U-Boot] [PATCH 0/5] ARM: zynq: Boot variables cleanup

[Michal Simek]

Hi,

for quite a long time Xilinx was using private boot method. Pretty long time
ago we have enabled distribution boot method and provided time to do
transition to it. Right now it is good time to remove old methods and move
to distro boot fully.
It is also the part of unification between Xilinx Zynq/ZynqMP and Versal
SoCs to use the same boot methods.
This series convert Zynq.

Variable modeboot is still setup because Topic boards and Syzygy are using it.

Thanks,
Michal


Michal Simek (5):
  ARM: zynq: Specify MMC controller number for boot sequence
  ARM: zynq: Enable USB1 as secondary boot device
  ARM: zynq: Fix NOR boot mode
  ARM: zynq: Use {} around variables for qspi and nand boot cmds
  ARM: zynq: Remove all Xilinx private commands

 board/xilinx/zynq/board.c |  2 +-
 include/configs/zynq-common.h | 66 +--
 2 files changed, 10 insertions(+), 58 deletions(-)

-- 
2.17.1

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

[U-Boot] Use of the go command

[Herburger, Gregor]

Hello,

i use the go command from the hush shell to execute a function from 
environment. That function has been initially compiled in U-Boot and was first 
called in board_late_init(). 

I call the function by using 
go #address

on my Arm Cortex A-7 machine the do_go_exec becomes: 
e1a03000mov r3, r0
e1a1mov r0, r1
e1a01002mov r1, r2
e12fff13bx  r3

so instruction set is exchanged. This seems to work the function returns and 
returns back to the hush-shell. 
My question is now: Is it safe to use the go command to execute U-boot 
functions or do I miss something here?
Does the exchange of the instruction set have some influence on the further 
execution of U-boot.?

Mit freundlichen Grüßen / Best regards

i.A. Gregor Herburger
Entwicklung Software Delling
Tel. +49 8153 9308-809, Fax +49 8153 9308-7809
gregor.herbur...@tq-group.com 

TQ-Systems GmbH
Mühlstraße 2, Gut Delling, 82229 Seefeld
Amtsgericht München, HRB 105018
Sitz der Gesellschaft: Seefeld
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
www.tq-group.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 5/5] ARM: MediaTek: add basic support for MT8518 boards

[mingming lee]

This adds a general board file based on MT8518 SoCs from MediaTek.

Apart from the generic parts (cpu) we add some low level init codes
and initialize the early clocks.

This commit is adding the basic boot support for the MT8518 eMMC board.

Signed-off-by: mingming lee 
---
 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/mt8518-ap1-emmc.dts   | 104 +
 arch/arm/mach-mediatek/Kconfig |   1 +
 board/mediatek/mt8518/Kconfig  |  14 
 board/mediatek/mt8518/MAINTAINERS  |   6 ++
 board/mediatek/mt8518/Makefile |   3 +
 board/mediatek/mt8518/mt8518_ap1.c |  27 
 configs/mt8518_ap1_emmc_defconfig  |  54 +++
 include/configs/mt8518.h   |  73 
 9 files changed, 284 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/mt8518-ap1-emmc.dts
 create mode 100644 board/mediatek/mt8518/Kconfig
 create mode 100644 board/mediatek/mt8518/MAINTAINERS
 create mode 100644 board/mediatek/mt8518/Makefile
 create mode 100644 board/mediatek/mt8518/mt8518_ap1.c
 create mode 100644 configs/mt8518_ap1_emmc_defconfig
 create mode 100644 include/configs/mt8518.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index aac1b83d49..54ca31c995 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -788,7 +788,8 @@ dtb-$(CONFIG_SOC_K3_J721E) += 
k3-j721e-common-proc-board.dtb \
 dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7623n-bananapi-bpi-r2.dtb \
mt7629-rfb.dtb \
-   mt8516-pumpkin.dtb
+   mt8516-pumpkin.dtb \
+   mt8518-ap1-emmc.dtb
 
 dtb-$(CONFIG_TARGET_GE_BX50V3) += imx6q-bx50v3.dtb
 dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
diff --git a/arch/arm/dts/mt8518-ap1-emmc.dts b/arch/arm/dts/mt8518-ap1-emmc.dts
new file mode 100644
index 00..a542d65f59
--- /dev/null
+++ b/arch/arm/dts/mt8518-ap1-emmc.dts
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ * Author: Mingming Lee 
+ *
+ */
+
+/dts-v1/;
+
+#include 
+#include "mt8518.dtsi"
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   model = "MT8518 AP1 EMMC";
+
+   chosen {
+   stdout-path = 
+   tick-timer = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0x4000 0x1000>;
+   };
+
+   reg_1p8v: regulator-1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   reg_3p3v: regulator-3p3v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+   bus-width = <8>;
+   max-frequency = <2>;
+   cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+   cap-mmc-hw-reset;
+   vmmc-supply = <_3p3v>;
+   vqmmc-supply = <_1p8v>;
+   non-removable;
+   status = "okay";
+};
+
+ {
+   mmc0_pins_default: mmc0default {
+   mux {
+   function = "msdc";
+   groups =  "msdc0";
+   };
+
+   conf-cmd-data {
+   pins = "MSDC0_CMD", "MSDC0_DAT0", "MSDC0_DAT1",
+  "MSDC0_DAT2", "MSDC0_DAT3", "MSDC0_DAT4",
+  "MSDC0_DAT5", "MSDC0_DAT6", "MSDC0_DAT7";
+   input-enable;
+   bias-pull-up;
+   };
+
+   conf-clk {
+   pins = "MSDC0_CLK";
+   bias-pull-down;
+   };
+
+   conf-rst {
+   pins = "MSDC0_RSTB";
+   bias-pull-up;
+   };
+   };
+
+   uart0_pins: uart0 {
+   mux {
+   function = "uart";
+   groups = "uart0_0_rxd_txd";
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig
index 8e343c3182..a5808bd343 100644
--- a/arch/arm/mach-mediatek/Kconfig
+++ b/arch/arm/mach-mediatek/Kconfig
@@ -52,5 +52,6 @@ endchoice
 source "board/mediatek/mt7623/Kconfig"
 source "board/mediatek/mt7629/Kconfig"
 source "board/mediatek/pumpkin/Kconfig"
+source "board/mediatek/mt8518/Kconfig"
 
 endif
diff --git a/board/mediatek/mt8518/Kconfig b/board/mediatek/mt8518/Kconfig
new file mode 100644
index 

[U-Boot] [PATCH 4/5] pinctrl: add driver for MT8518

[mingming lee]

Add Pinctrl driver for MediaTek MT8518 SoC.

Signed-off-by: mingming lee 
---
 arch/arm/dts/mt8518.dtsi  |   9 +
 drivers/pinctrl/mediatek/Kconfig  |   4 +
 drivers/pinctrl/mediatek/Makefile |   1 +
 drivers/pinctrl/mediatek/pinctrl-mt8518.c | 411 ++
 4 files changed, 425 insertions(+)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8518.c

diff --git a/arch/arm/dts/mt8518.dtsi b/arch/arm/dts/mt8518.dtsi
index 39d001884f..d924944c2a 100644
--- a/arch/arm/dts/mt8518.dtsi
+++ b/arch/arm/dts/mt8518.dtsi
@@ -151,6 +151,15 @@
status = "disabled";
};
 
+   pinctrl: pinctrl@10005000 {
+   compatible = "mediatek,mt8518-pinctrl";
+   reg = <0x10005000 0x1000>;
+   gpio: gpio-controller {
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+   };
+
mmc0: mmc@1112 {
compatible = "mediatek,mt8516-mmc";
reg = <0x1112 0x1000>;
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 9930ca1faf..22ee62362b 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -16,4 +16,8 @@ config PINCTRL_MT8516
bool "MT8516 SoC pinctrl driver"
select PINCTRL_MTK
 
+config PINCTRL_MT8518
+bool "MT8518 SoC pinctrl driver"
+   select PINCTRL_MTK
+
 endif
diff --git a/drivers/pinctrl/mediatek/Makefile 
b/drivers/pinctrl/mediatek/Makefile
index c4f29088d2..0ab7b1595b 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_PINCTRL_MTK) += pinctrl-mtk-common.o
 obj-$(CONFIG_PINCTRL_MT7623) += pinctrl-mt7623.o
 obj-$(CONFIG_PINCTRL_MT7629) += pinctrl-mt7629.o
 obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-mt8516.o
+obj-$(CONFIG_PINCTRL_MT8518) += pinctrl-mt8518.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8518.c 
b/drivers/pinctrl/mediatek/pinctrl-mt8518.c
new file mode 100644
index 00..8d2cd948f6
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8518.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ * Author: Mingming Lee 
+ */
+
+#include 
+
+#include "pinctrl-mtk-common.h"
+
+#define PIN_FIELD(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, _x_bits)  \
+   PIN_FIELD_CALC(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit,   \
+  _x_bits, 16, false)
+
+static const struct mtk_pin_field_calc mt8518_pin_mode_range[] = {
+   PIN_FIELD_CALC(0, 119, 0x300, 0x10, 0, 3, 15, false),
+};
+
+static const struct mtk_pin_field_calc mt8518_pin_dir_range[] = {
+   PIN_FIELD(0, 119, 0x0, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt8518_pin_di_range[] = {
+   PIN_FIELD(0, 119, 0x200, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt8518_pin_do_range[] = {
+   PIN_FIELD(0, 119, 0x100, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt8518_pin_ies_range[] = {
+   PIN_FIELD(0, 2, 0x900, 0x10, 0, 1),
+   PIN_FIELD(3, 3, 0x920, 0x10, 9, 1),
+   PIN_FIELD(4, 4, 0x920, 0x10, 8, 1),
+   PIN_FIELD(5, 5, 0x920, 0x10, 7, 1),
+   PIN_FIELD(6, 6, 0x920, 0x10, 6, 1),
+   PIN_FIELD(7, 7, 0x920, 0x10, 10, 1),
+   PIN_FIELD(8, 8, 0x920, 0x10, 1, 1),
+   PIN_FIELD(9, 9, 0x920, 0x10, 0, 1),
+   PIN_FIELD(10, 10, 0x920, 0x10, 5, 1),
+   PIN_FIELD(11, 11, 0x920, 0x10, 4, 1),
+   PIN_FIELD(12, 12, 0x920, 0x10, 3, 1),
+   PIN_FIELD(13, 13, 0x920, 0x10, 2, 1),
+   PIN_FIELD(14, 14, 0x900, 0x10, 1, 1),
+   PIN_FIELD(15, 15, 0x900, 0x10, 2, 1),
+   PIN_FIELD(16, 16, 0x900, 0x10, 3, 1),
+   PIN_FIELD(17, 20, 0x900, 0x10, 4, 1),
+   PIN_FIELD(21, 22, 0x900, 0x10, 5, 1),
+   PIN_FIELD(23, 27, 0x910, 0x10, 15, 1),
+   PIN_FIELD(28, 28, 0x900, 0x10, 6, 1),
+   PIN_FIELD(29, 29, 0x930, 0x10, 2, 1),
+   PIN_FIELD(30, 30, 0x930, 0x10, 1, 1),
+   PIN_FIELD(31, 31, 0x930, 0x10, 6, 1),
+   PIN_FIELD(32, 32, 0x930, 0x10, 5, 1),
+   PIN_FIELD(33, 33, 0x930, 0x10, 4, 1),
+   PIN_FIELD(34, 35, 0x930, 0x10, 3, 1),
+   PIN_FIELD(36, 39, 0x900, 0x10, 7, 1),
+   PIN_FIELD(40, 41, 0x900, 0x10, 8, 1),
+   PIN_FIELD(42, 44, 0x900, 0x10, 9, 1),
+   PIN_FIELD(45, 47, 0x900, 0x10, 10, 1),
+   PIN_FIELD(48, 51, 0x900, 0x10, 11, 1),
+   PIN_FIELD(52, 55, 0x900, 0x10, 12, 1),
+   PIN_FIELD(56, 56, 0x900, 0x10, 13, 1),
+   PIN_FIELD(57, 57, 0x900, 0x10, 14, 1),
+   PIN_FIELD(58, 58, 0x900, 0x10, 15, 1),
+   PIN_FIELD(59, 60, 0x910, 0x10, 0, 1),
+
+   PIN_FIELD(61, 61, 0x910, 0x10, 1, 1),
+   PIN_FIELD(62, 62, 0x910, 0x10, 2, 1),
+   PIN_FIELD(63, 69, 0x910, 0x10, 3, 1),
+   PIN_FIELD(70, 70, 0x910, 0x10, 4, 1),
+   PIN_FIELD(71, 76, 0x910, 0x10, 5, 1),
+   PIN_FIELD(77, 80, 0x910, 0x10, 6, 1),
+   PIN_FIELD(81, 87, 0x910, 0x10, 7, 1),
+   

[U-Boot] [PATCH 3/5] mmc: mtk-sd: add HS200 support

[mingming lee]

add HS200 mode and tune support

Signed-off-by: mingming lee 
---
 drivers/mmc/mtk-sd.c | 30 --
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index f555357af2..bede4153b3 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -362,6 +362,8 @@ static u32 msdc_cmd_prepare_raw_cmd(struct msdc_host *host,
case MMC_CMD_WRITE_SINGLE_BLOCK:
case MMC_CMD_READ_SINGLE_BLOCK:
case SD_CMD_APP_SEND_SCR:
+   case MMC_CMD_SEND_TUNING_BLOCK:
+   case MMC_CMD_SEND_TUNING_BLOCK_HS200:
dtype = 1;
break;
case SD_CMD_SWITCH_FUNC: /* same as MMC_CMD_SWITCH */
@@ -467,6 +469,14 @@ static int msdc_start_command(struct msdc_host *host, 
struct mmc_cmd *cmd,
if (!msdc_cmd_is_ready(host))
return -EIO;
 
+   if ((readl(>base->msdc_fifocs) &
+   MSDC_FIFOCS_TXCNT_M) >> MSDC_FIFOCS_TXCNT_S ||
+   (readl(>base->msdc_fifocs) &
+   MSDC_FIFOCS_RXCNT_M) >> MSDC_FIFOCS_RXCNT_S) {
+   pr_err("TX/RX FIFO non-empty before start of IO. Reset\n");
+   msdc_reset_hw(host);
+   }
+
msdc_fifo_clr(host);
 
host->last_resp_type = cmd->resp_type;
@@ -650,14 +660,22 @@ static int msdc_ops_send_cmd(struct udevice *dev, struct 
mmc_cmd *cmd,
 struct mmc_data *data)
 {
struct msdc_host *host = dev_get_priv(dev);
-   int ret;
+   int cmd_ret, data_ret;
 
-   ret = msdc_start_command(host, cmd, data);
-   if (ret)
-   return ret;
+   cmd_ret = msdc_start_command(host, cmd, data);
+   if (cmd_ret &&
+   !(cmd_ret == -EIO &&
+   (cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK ||
+   cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200)))
+   return cmd_ret;
 
-   if (data)
-   return msdc_start_data(host, data);
+   if (data) {
+   data_ret = msdc_start_data(host, data);
+   if (cmd_ret)
+   return cmd_ret;
+   else
+   return data_ret;
+   }
 
return 0;
 }
-- 
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/5] clk: mediatek: add driver for MT8518

[mingming lee]

Add clock driver for MediaTek MT8518 SoC.

Signed-off-by: mingming lee 
---
 drivers/clk/mediatek/Makefile  |1 +
 drivers/clk/mediatek/clk-mt8518.c  | 1558 
 include/dt-bindings/clock/mt8518-clk.h |  249 
 3 files changed, 1808 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt8518.c
 create mode 100644 include/dt-bindings/clock/mt8518-clk.h

diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index a47a5bdbc2..e92bcd4efe 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_ARCH_MEDIATEK) += clk-mtk.o
 obj-$(CONFIG_TARGET_MT7623) += clk-mt7623.o
 obj-$(CONFIG_TARGET_MT7629) += clk-mt7629.o
 obj-$(CONFIG_TARGET_MT8516) += clk-mt8516.o
+obj-$(CONFIG_TARGET_MT8518) += clk-mt8518.o
diff --git a/drivers/clk/mediatek/clk-mt8518.c 
b/drivers/clk/mediatek/clk-mt8518.c
new file mode 100644
index 00..35b3db28e6
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt8518.c
@@ -0,0 +1,1558 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek clock driver for MT8518 SoC
+ *
+ * Copyright (C) 2019 BayLibre, SAS
+ * Author: Chen Zhong 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-mtk.h"
+
+#define MT8518_PLL_FMAX(3000UL * MHZ)
+#define MT8518_CON0_RST_BARBIT(27)
+
+/* apmixedsys */
+#define PLL(_id, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, _pd_reg,  \
+   _pd_shift, _pcw_reg, _pcw_shift) {  \
+   .id = _id,  \
+   .reg = _reg,\
+   .pwr_reg = _pwr_reg,\
+   .en_mask = _en_mask,\
+   .rst_bar_mask = MT8518_CON0_RST_BAR,\
+   .fmax = MT8518_PLL_FMAX,\
+   .flags = _flags,\
+   .pcwbits = _pcwbits,\
+   .pd_reg = _pd_reg,  \
+   .pd_shift = _pd_shift,  \
+   .pcw_reg = _pcw_reg,\
+   .pcw_shift = _pcw_shift,\
+   }
+
+static const struct mtk_pll_data apmixed_plls[] = {
+   PLL(CLK_APMIXED_ARMPLL, 0x0100, 0x0110, 0x0001,
+   0, 21, 0x0104, 24, 0x0104, 0),
+   PLL(CLK_APMIXED_MAINPLL, 0x0120, 0x0130, 0x0001,
+   HAVE_RST_BAR, 21, 0x0124, 24, 0x0124, 0),
+   PLL(CLK_APMIXED_UNIVPLL, 0x0140, 0x0150, 0x3001,
+   HAVE_RST_BAR, 7, 0x0144, 24, 0x0144, 0),
+   PLL(CLK_APMIXED_MMPLL, 0x0160, 0x0170, 0x0001,
+   0, 21, 0x0164, 24, 0x0164, 0),
+   PLL(CLK_APMIXED_APLL1, 0x0180, 0x0190, 0x0001,
+   0, 31, 0x0180, 1, 0x0184, 0),
+   PLL(CLK_APMIXED_APLL2, 0x01A0, 0x01B0, 0x0001,
+   0, 31, 0x01A0, 1, 0x01A4, 0),
+   PLL(CLK_APMIXED_TVDPLL, 0x01C0, 0x01D0, 0x0001,
+   0, 21, 0x01C4, 24, 0x01C4, 0),
+};
+
+/* topckgen */
+#define FACTOR0(_id, _parent, _mult, _div) \
+   FACTOR(_id, _parent, _mult, _div, CLK_PARENT_APMIXED)
+
+#define FACTOR1(_id, _parent, _mult, _div) \
+   FACTOR(_id, _parent, _mult, _div, CLK_PARENT_TOPCKGEN)
+
+#define FACTOR2(_id, _parent, _mult, _div) \
+   FACTOR(_id, _parent, _mult, _div, 0)
+
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+   FIXED_CLK(CLK_TOP_CLK_NULL, CLK_XTAL, 2600),
+   FIXED_CLK(CLK_TOP_FQ_TRNG_OUT0, CLK_TOP_CLK_NULL, 5),
+   FIXED_CLK(CLK_TOP_FQ_TRNG_OUT1, CLK_TOP_CLK_NULL, 5),
+   FIXED_CLK(CLK_TOP_CLK32K, CLK_XTAL, 32000),
+};
+
+static const struct mtk_fixed_factor top_fixed_divs[] = {
+   FACTOR2(CLK_TOP_DMPLL, CLK_XTAL, 1, 1),
+   FACTOR0(CLK_TOP_MAINPLL_D4, CLK_APMIXED_MAINPLL, 1, 4),
+   FACTOR0(CLK_TOP_MAINPLL_D8, CLK_APMIXED_MAINPLL, 1, 8),
+   FACTOR0(CLK_TOP_MAINPLL_D16, CLK_APMIXED_MAINPLL, 1, 16),
+   FACTOR0(CLK_TOP_MAINPLL_D11, CLK_APMIXED_MAINPLL, 1, 11),
+   FACTOR0(CLK_TOP_MAINPLL_D22, CLK_APMIXED_MAINPLL, 1, 22),
+   FACTOR0(CLK_TOP_MAINPLL_D3, CLK_APMIXED_MAINPLL, 1, 3),
+   FACTOR0(CLK_TOP_MAINPLL_D6, CLK_APMIXED_MAINPLL, 1, 6),
+   FACTOR0(CLK_TOP_MAINPLL_D12, CLK_APMIXED_MAINPLL, 1, 12),
+   FACTOR0(CLK_TOP_MAINPLL_D5, CLK_APMIXED_MAINPLL, 1, 5),
+   FACTOR0(CLK_TOP_MAINPLL_D10, CLK_APMIXED_MAINPLL, 1, 10),
+   FACTOR0(CLK_TOP_MAINPLL_D20, CLK_APMIXED_MAINPLL, 1, 20),
+   FACTOR0(CLK_TOP_MAINPLL_D40, CLK_APMIXED_MAINPLL, 1, 40),
+   FACTOR0(CLK_TOP_MAINPLL_D7, CLK_APMIXED_MAINPLL, 1, 7),
+   FACTOR0(CLK_TOP_MAINPLL_D14, CLK_APMIXED_MAINPLL, 1, 14),
+   FACTOR0(CLK_TOP_UNIVPLL_D2, CLK_APMIXED_UNIVPLL, 1, 2),
+   FACTOR0(CLK_TOP_UNIVPLL_D4, 

[U-Boot] [PATCH 0/5] Add support for MediaTek MT8518 Soc

[mingming lee]

This patch series adds basic boot support on eMMC for the MediaTek
MT8518 SoC based boards. This series add the clock, pinctrl drivers
and the SoC initializaton code.

mingming lee (5):
  ARM: MediaTek: Add support for MediaTek MT8518 SoC
  clk: mediatek: add driver for MT8518
  mmc: mtk-sd: add HS200 support
  pinctrl: add driver for MT8518
  ARM: MediaTek: add basic support for MT8518 boards

 arch/arm/dts/Makefile |3 +-
 arch/arm/dts/mt8518-ap1-emmc.dts  |  104 ++
 arch/arm/dts/mt8518.dtsi  |  210 +++
 arch/arm/mach-mediatek/Kconfig|   10 +
 arch/arm/mach-mediatek/Makefile   |1 +
 arch/arm/mach-mediatek/mt8518/Makefile|4 +
 arch/arm/mach-mediatek/mt8518/init.c  |  116 ++
 arch/arm/mach-mediatek/mt8518/lowlevel_init.S |   59 +
 board/mediatek/mt8518/Kconfig |   14 +
 board/mediatek/mt8518/MAINTAINERS |6 +
 board/mediatek/mt8518/Makefile|3 +
 board/mediatek/mt8518/mt8518_ap1.c|   27 +
 configs/mt8518_ap1_emmc_defconfig |   54 +
 drivers/clk/mediatek/Makefile |1 +
 drivers/clk/mediatek/clk-mt8518.c | 1558 +
 drivers/mmc/mtk-sd.c  |   30 +-
 drivers/pinctrl/mediatek/Kconfig  |4 +
 drivers/pinctrl/mediatek/Makefile |1 +
 drivers/pinctrl/mediatek/pinctrl-mt8518.c |  411 +
 include/configs/mt8518.h  |   73 +
 include/dt-bindings/clock/mt8518-clk.h|  249 +++
 21 files changed, 2931 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/dts/mt8518-ap1-emmc.dts
 create mode 100644 arch/arm/dts/mt8518.dtsi
 create mode 100644 arch/arm/mach-mediatek/mt8518/Makefile
 create mode 100644 arch/arm/mach-mediatek/mt8518/init.c
 create mode 100644 arch/arm/mach-mediatek/mt8518/lowlevel_init.S
 create mode 100644 board/mediatek/mt8518/Kconfig
 create mode 100644 board/mediatek/mt8518/MAINTAINERS
 create mode 100644 board/mediatek/mt8518/Makefile
 create mode 100644 board/mediatek/mt8518/mt8518_ap1.c
 create mode 100644 configs/mt8518_ap1_emmc_defconfig
 create mode 100644 drivers/clk/mediatek/clk-mt8518.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8518.c
 create mode 100644 include/configs/mt8518.h
 create mode 100644 include/dt-bindings/clock/mt8518-clk.h

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

[U-Boot] [PATCH 1/5] ARM: MediaTek: Add support for MediaTek MT8518 SoC

[mingming lee]

Add support for MediaTek MT8518 SoC. This include the file
that will initialize the SoC after boot and its device tree.

Signed-off-by: mingming lee 
---
 arch/arm/dts/mt8518.dtsi  | 201 ++
 arch/arm/mach-mediatek/Kconfig|   9 +
 arch/arm/mach-mediatek/Makefile   |   1 +
 arch/arm/mach-mediatek/mt8518/Makefile|   4 +
 arch/arm/mach-mediatek/mt8518/init.c  | 116 ++
 arch/arm/mach-mediatek/mt8518/lowlevel_init.S |  59 +
 6 files changed, 390 insertions(+)
 create mode 100644 arch/arm/dts/mt8518.dtsi
 create mode 100644 arch/arm/mach-mediatek/mt8518/Makefile
 create mode 100644 arch/arm/mach-mediatek/mt8518/init.c
 create mode 100644 arch/arm/mach-mediatek/mt8518/lowlevel_init.S

diff --git a/arch/arm/dts/mt8518.dtsi b/arch/arm/dts/mt8518.dtsi
new file mode 100644
index 00..39d001884f
--- /dev/null
+++ b/arch/arm/dts/mt8518.dtsi
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ * Author: Mingming Lee 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "mediatek,mt8518";
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "mediatek,mt8518-smp";
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0>;
+   clock-frequency = <13>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x1>;
+   clock-frequency = <13>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x2>;
+   clock-frequency = <13>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x3>;
+   clock-frequency = <13>;
+   };
+   };
+
+   chipid: chipid@0800 {
+   compatible = "mediatek,chipid";
+   reg = <0x0800 0x0004>,
+ <0x0804 0x0004>,
+ <0x0808 0x0004>,
+ <0x080c 0x0004>;
+   };
+
+   topckgen: clock-controller@1000 {
+   compatible = "mediatek,mt8518-topckgen";
+   reg = <0x1000 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   topckgen_cg: clock-controller-cg@1000 {
+   compatible = "mediatek,mt8518-topckgen-cg";
+   reg = <0x1000 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   apmixedsys: clock-controller@10018000 {
+   compatible = "mediatek,mt8518-apmixedsys";
+   reg = <0x10018000 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   gic: interrupt-controller@0c00 {
+compatible = "arm,gic-v3";
+   #interrupt-cells = <3>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   reg = <0xc00 0x4>,  /* GICD */
+ <0xc10 0x20>; /* GICR */
+   interrupts = ;
+   };
+
+   sysirq: interrupt-controller@10200a80 {
+   compatible = "mediatek,sysirq";
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   interrupt-parent = <>;
+   reg = <0x10200a80 0x50>;
+   };
+
+   apdma: dma-controller@11000480 {
+   compatible = "mediatek,mt8518-uart-dma",
+   "mediatek,mt6577-uart-dma";
+   reg = <0x11000480 0x80>,
+ <0x11000500 0x80>,
+ <0x11000580 0x80>,
+ <0x11000600 0x80>,
+ <0x11000980 0x80>,
+ <0x11000a00 0x80>;
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   clocks = < CLK_TOP_APDMA>;
+   clock-names = "apdma";
+   #dma-cells = <1>;
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupt-parent = <>;
+   interrupts = ,
+,
+,
+;
+   clock-frequency = <1300>;
+   };
+
+   timer0: apxgpt@10008000 {
+   compatible = "mediatek,timer",
+

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

[Moses Christopher]

On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, <
simon.k.r.goldschm...@gmail.com> wrote:

> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher
>  wrote:
> >
> > 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
>
> Right, tftp.c is missing the call to that funcftion. Could you add the
> call to 'lmb_dump_all();'
> right below 'lmb_init_and_reserve()' in tftp.c?
>
> That should give you the output required. And while at it, tell us
> what 'load_addr' is set to
> (by adding a printf in tftp.c, too).
>
> Thanks,
> Simon
>

Thanks for your patience and time.

Please find the log below,



DHCP client bound to address 172.17.0.2 (1285 ms)

Using usb_ether device

TFTP from server 172.17.0.1; our IP address is 172.17.0.2

Filename 'u-boot.img'.

*lmb_dump_all:*

*memory.cnt = 0x0*

*memory.size= 0xx*



*reserved.cnt   = 0x0*

*reserved.size  = 0xx*

*load_addr: 0x8200*



TFTP error: trying to overwrite reserved memory...

Problem booting with BOOTP



*In my u-boot it shows the DRAM size properly as 256MiB*

*So, do I need to configure my RAM size in SPL stage as well, such that SPL
is aware of the memory size ?*



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

[U-Boot] [PATCH v4 00/15] Improvement for the DWC3 USB generic driver and fixes for the K2 platforms

[Jean-Jacques Hiblot]

The K2 platforms have shown boot issues after switching to the DWC3 generic
driver. Those are due to the fact that the USB domains are not turned off
before booting linux and the phy were not properly initialized. Fixing it
by improving the DWC3-generic driver and handling the USB power domain in
the PHY driver.

Improvements to the DWC3 generic driver are:
- core: read quirks properties from DT and apply the fixes.
- add a new host driver that uses the DWC3 core (more generic than
xhci-dwc3). This should enable most platforms to drop their own version
of the xhci-driver to use the generic one instead.

This series also removes the now unused xhci-zynqmp driver and tries to
better manage the Kconfig options related to DWC3 gadget/host mode
selection.

This has been tested with K2 and DRA7 platforms (host and device modes).
Travis build: https://travis-ci.org/jjhiblot/u-boot/builds/583080674

Changes in v4:
- removed patches already merged (DWC3 fixes)
- update more defconfigs (u200, sei510, rock64-rk332 and odroid-n2)
- Fix the test of the USB_DWC3_GADGET option. IS_ENABLED() requires the
  whole option name including the 'CONFIG_' prefix

Changes in v3:
- updated log message when defaulting to super speed

Changes in v2:
Update commit log
Select USB_GADGET_DUALSPEED if USB_DWC3_GADGET is selected

Jean-Jacques Hiblot (15):
  usb: host: remove the xhci-zynqmp driver
  usb: dwc3: switch to peripheral mode when exiting
  usb: xhci: move xhci.h to include usb
  usb: dwc3: always use the inlined version of
dwc3_host_init/dwc3_host_exit
  usb: dwc3-generic: use platdata
  usb: dwc3-generic: factorize code
  usb: dwc3-generic: add a new host driver that uses the dwc3 core
  usb: dwc3-generic: if no max speed is specified in DT, assume super
speed
  usb: dwc3: Add dwc3_of_parse() to get quirks information from DT
  usb: dwc3: Kconfig: get rid of obsolete mode selection
  ARM: keystone: increase PSC timeout
  ARM: keystone: Do not enable the USB power domains at the board level
  phy: keystone-usb: handle the transition of the USB power domain
  configs: k2g_evm_defconfig: disable XHCI_DWC3 and enable
KEYSTONE_USB_PHY
  ARM: DTS: keystone: complete the description of the USB PHY devices

 MAINTAINERS   |   1 +
 arch/arm/dts/keystone-k2e-evm-u-boot.dtsi |  32 
 arch/arm/dts/keystone-k2g-evm-u-boot.dtsi |  28 
 arch/arm/dts/keystone-k2hk-evm-u-boot.dtsi|  14 ++
 arch/arm/dts/keystone-k2l-evm-u-boot.dtsi |  18 +++
 .../arm/mach-keystone/include/mach/psc_defs.h |   2 +-
 board/ti/ks2_evm/board.c  |  13 --
 configs/avnet_ultra96_rev1_defconfig  |   1 -
 configs/evb-rk3328_defconfig  |   1 +
 configs/k2g_evm_defconfig |   3 +-
 configs/odroid-n2_defconfig   |   1 +
 configs/rock64-rk3328_defconfig   |   1 +
 configs/sei510_defconfig  |   1 +
 configs/u200_defconfig|   1 +
 .../xilinx_zynqmp_zc1751_xm015_dc1_defconfig  |   1 -
 .../xilinx_zynqmp_zc1751_xm016_dc2_defconfig  |   1 -
 .../xilinx_zynqmp_zc1751_xm017_dc3_defconfig  |   1 -
 configs/xilinx_zynqmp_zcu100_revC_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig |   1 -
 configs/xilinx_zynqmp_zcu102_revA_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu102_revB_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu104_revA_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu104_revC_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu106_revA_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu111_revA_defconfig   |   1 -
 drivers/phy/keystone-usb-phy.c|  22 +++
 drivers/usb/dwc3/Kconfig  |  18 +--
 drivers/usb/dwc3/core.c   |  84 +-
 drivers/usb/dwc3/core.h   |   6 +-
 drivers/usb/dwc3/dwc3-generic.c   | 146 ++
 drivers/usb/host/Kconfig  |   7 -
 drivers/usb/host/Makefile |   1 -
 drivers/usb/host/xhci-dwc3.c  |   2 +-
 drivers/usb/host/xhci-exynos5.c   |   2 +-
 drivers/usb/host/xhci-fsl.c   |   2 +-
 drivers/usb/host/xhci-mem.c   |   2 +-
 drivers/usb/host/xhci-mvebu.c |   2 +-
 drivers/usb/host/xhci-omap.c  |   2 +-
 drivers/usb/host/xhci-pci.c   |   2 +-
 drivers/usb/host/xhci-rcar.c  |   2 +-
 drivers/usb/host/xhci-ring.c  |   2 +-
 drivers/usb/host/xhci-rockchip.c  |   2 +-
 drivers/usb/host/xhci-zynqmp.c| 146 --
 drivers/usb/host/xhci.c   |   2 +-
 drivers/usb/phy/omap_usb_phy.c|   2 +-
 {drivers/usb/host => include/usb}/xhci.h  |   0
 46 files changed, 331 insertions(+), 251 deletions(-)
 create mode 100644 arch/arm/dts/keystone-k2l-evm-u-boot.dtsi
 delete mode 100644 

[U-Boot] [PATCH 1/5] ARM: MediaTek: Add support for MediaTek MT8518 SoC

[mingming lee]

Add support for MediaTek MT8518 SoC. This include the file
that will initialize the SoC after boot and its device tree.

Signed-off-by: mingming lee 
---
 arch/arm/dts/mt8518.dtsi  | 201 ++
 arch/arm/mach-mediatek/Kconfig|   9 +
 arch/arm/mach-mediatek/Makefile   |   1 +
 arch/arm/mach-mediatek/mt8518/Makefile|   4 +
 arch/arm/mach-mediatek/mt8518/init.c  | 116 ++
 arch/arm/mach-mediatek/mt8518/lowlevel_init.S |  59 +
 6 files changed, 390 insertions(+)
 create mode 100644 arch/arm/dts/mt8518.dtsi
 create mode 100644 arch/arm/mach-mediatek/mt8518/Makefile
 create mode 100644 arch/arm/mach-mediatek/mt8518/init.c
 create mode 100644 arch/arm/mach-mediatek/mt8518/lowlevel_init.S

diff --git a/arch/arm/dts/mt8518.dtsi b/arch/arm/dts/mt8518.dtsi
new file mode 100644
index 00..39d001884f
--- /dev/null
+++ b/arch/arm/dts/mt8518.dtsi
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2019 MediaTek Inc.
+ * Author: Mingming Lee 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "mediatek,mt8518";
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "mediatek,mt8518-smp";
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0>;
+   clock-frequency = <13>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x1>;
+   clock-frequency = <13>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x2>;
+   clock-frequency = <13>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x3>;
+   clock-frequency = <13>;
+   };
+   };
+
+   chipid: chipid@0800 {
+   compatible = "mediatek,chipid";
+   reg = <0x0800 0x0004>,
+ <0x0804 0x0004>,
+ <0x0808 0x0004>,
+ <0x080c 0x0004>;
+   };
+
+   topckgen: clock-controller@1000 {
+   compatible = "mediatek,mt8518-topckgen";
+   reg = <0x1000 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   topckgen_cg: clock-controller-cg@1000 {
+   compatible = "mediatek,mt8518-topckgen-cg";
+   reg = <0x1000 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   apmixedsys: clock-controller@10018000 {
+   compatible = "mediatek,mt8518-apmixedsys";
+   reg = <0x10018000 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   gic: interrupt-controller@0c00 {
+compatible = "arm,gic-v3";
+   #interrupt-cells = <3>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   reg = <0xc00 0x4>,  /* GICD */
+ <0xc10 0x20>; /* GICR */
+   interrupts = ;
+   };
+
+   sysirq: interrupt-controller@10200a80 {
+   compatible = "mediatek,sysirq";
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   interrupt-parent = <>;
+   reg = <0x10200a80 0x50>;
+   };
+
+   apdma: dma-controller@11000480 {
+   compatible = "mediatek,mt8518-uart-dma",
+   "mediatek,mt6577-uart-dma";
+   reg = <0x11000480 0x80>,
+ <0x11000500 0x80>,
+ <0x11000580 0x80>,
+ <0x11000600 0x80>,
+ <0x11000980 0x80>,
+ <0x11000a00 0x80>;
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   clocks = < CLK_TOP_APDMA>;
+   clock-names = "apdma";
+   #dma-cells = <1>;
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupt-parent = <>;
+   interrupts = ,
+,
+,
+;
+   clock-frequency = <1300>;
+   };
+
+   timer0: apxgpt@10008000 {
+   compatible = "mediatek,timer",
+

[U-Boot] Add support for imxrt

[Giulio Benetti]

Hello everybody,

I would like to port imxrt to u-boot and I would like to ask you:
- do you have the interest on upstreaming it?
if yes:
I've seen how they've dealt with 'stm32' and 'stm32mp' that is similar 
to 'imxrt' and 'imx'. So should follow the same criterias for porting? I 
mean adding the new folder 'mach-imxrt'?


Also, do I find some of you in IRC sometimes?

Thanks in advance
Best regards
--
Giulio Benetti
Benetti Engineering sas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Vignesh Raghavendra]

Hi Ashish, Simon,

On 11/09/19 3:11 PM, Simon Goldschmidt wrote:
> 
> 
> Ashish Kumar mailto:ashish.ku...@nxp.com>>
> schrieb am Mi., 11. Sep. 2019, 10:49:
> 
> 
> 
> > -Original Message-
> > From: Vignesh Raghavendra mailto:vigne...@ti.com>>
> > Sent: Tuesday, September 10, 2019 10:36 PM
> > To: Jagan Teki mailto:ja...@openedev.com>>
> > Cc: Vignesh Raghavendra  >; u-boot@lists.denx.de
> ; Tom
> > Rini mailto:tr...@konsulko.com>>; Eugeniy Paltsev
> >  >; alexey.brod...@synopsys.com
> ; Ashish
> > Kumar mailto:ashish.ku...@nxp.com>>
> > Subject: [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
> > SPI_NOR_4B_OPCODES for n25q512* and n25q256*
> >
> > Caution: EXT Email
> >
> > Not all variants of n25q256* and n25q512* support 4 Byte stateless
> > addressing opcodes and there is no easy way to discover at runtime
> whether
> > the flash supports this feature or not.
> > Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
> Hi Vignesh,
> 
> I think it will be good to keep it here and disable this for boards
> by using not set flag in config
> Like
> # SPI_NOR_4B_OPCODES is not set
> 

SPI_NOR_4B_OPCODES is not a config option. Are you suggesting to add
one? config options don't scale well especially when same defconfig is
used for multiple boards that potentially have different flashes

> 
> I'd prefer to take this patch, as this is what Linux does. 

No, this is not what Linux does. There is no opt-in or opt-out option.
Decision to use 4 byte opcode is done at runtime based on flash that's
detected. Either based on info->flags for that part or by parsing SFDP
table. There is no config option of DT option to force 4 byte addressing

> I think it's better to have an opt-in option. That way, all chips work with 
> the
> default settings (even if that means some chips don't use 4 baste
> opcodes even if they could).
> 

One solution would be to look at SFDP tables of two variants of flash
and see if there are any differences that can be used as a clue.

Simon,
Could you provide dump of SFDP tables and all the 6 bytes READ ID of the
flash that you have?

I have asked Eugeniy to provide dumps from his flash on the other
thread. Lets see if something stands out.

Regards
Vignesh

> Still, so we have such an op-in possibility to enable 4 byte opcodes on
> these chips?
> 
> Regards,
> Simon
> 
> 
> Regards
> Ashish
> >
> > Signed-off-by: Vignesh Raghavendra  > For n25q512ax3:
> > Tested-by: Eugeniy Paltsev  >
> > ---
> >  drivers/mtd/spi/spi-nor-ids.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c
> b/drivers/mtd/spi/spi-nor-ids.c
> > index f32a6c7d464b..5a7fe07c8309 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -161,10 +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("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 | SPI_NOR_4B_OPCODES) },
> > -       { INFO("mt25qu512a (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("mt25qu512a (n25q512a)",    0x20bb20, 0, 64 * 1024,
> 1024,
> > SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> > +       { INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K |
> > + USE_FSR | SPI_NOR_QUAD_READ) },
> >         { INFO("n25q00",      0x20ba21, 0, 64 * 1024, 2048,
> SECT_4K | USE_FSR |
> > SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> >         { INFO("n25q00a",     0x20bb21, 0, 64 * 1024, 2048,
> SECT_4K | USE_FSR |
> > SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> >         { INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096,
> SECT_4K | USE_FSR |
> > SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> > --
> > 2.23.0
> 
> ___
> 

Re: [U-Boot] [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*

[Simon Goldschmidt]

Ashish Kumar  schrieb am Mi., 11. Sep. 2019, 10:49:

>
>
> > -Original Message-
> > From: Vignesh Raghavendra 
> > Sent: Tuesday, September 10, 2019 10:36 PM
> > To: Jagan Teki 
> > Cc: Vignesh Raghavendra ; u-boot@lists.denx.de; Tom
> > Rini ; Eugeniy Paltsev
> > ; alexey.brod...@synopsys.com; Ashish
> > Kumar 
> > Subject: [EXT] [PATCH 2/2] spi-nor: spi-nor-ids: Disable
> > SPI_NOR_4B_OPCODES for n25q512* and n25q256*
> >
> > Caution: EXT Email
> >
> > Not all variants of n25q256* and n25q512* support 4 Byte stateless
> > addressing opcodes and there is no easy way to discover at runtime
> whether
> > the flash supports this feature or not.
> > Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
> Hi Vignesh,
>
> I think it will be good to keep it here and disable this for boards by
> using not set flag in config
> Like
> # SPI_NOR_4B_OPCODES is not set
>

I'd prefer to take this patch, as this is what Linux does. I think it's
better to have an opt-in option. That way, all chips work with the default
settings (even if that means some chips don't use 4 baste opcodes even if
they could).

Still, so we have such an op-in possibility to enable 4 byte opcodes on
these chips?

Regards,
Simon


> Regards
> Ashish
> >
> > Signed-off-by: Vignesh Raghavendra  For n25q512ax3:
> > Tested-by: Eugeniy Paltsev 
> > ---
> >  drivers/mtd/spi/spi-nor-ids.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c
> b/drivers/mtd/spi/spi-nor-ids.c
> > index f32a6c7d464b..5a7fe07c8309 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -161,10 +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("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 | SPI_NOR_4B_OPCODES) },
> > -   { INFO("mt25qu512a (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("mt25qu512a (n25q512a)",0x20bb20, 0, 64 * 1024, 1024,
> > SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> > +   { INFO("n25q512ax3",  0x20ba20, 0, 64 * 1024, 1024, SECT_4K |
> > + USE_FSR | SPI_NOR_QUAD_READ) },
> > { INFO("n25q00",  0x20ba21, 0, 64 * 1024, 2048, SECT_4K |
> USE_FSR |
> > SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> > { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K |
> USE_FSR |
> > SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> > { INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K |
> USE_FSR |
> > SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> > --
> > 2.23.0
>
> ___
> 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 v4 12/15] ARM: keystone: Do not enable the USB power domains at the board level

[Jean-Jacques Hiblot]

This breaks linux boot sequence.
Observed on k2e and k2l platforms.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 board/ti/ks2_evm/board.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
index e9bc68049b..e3305fbaf6 100644
--- a/board/ti/ks2_evm/board.c
+++ b/board/ti/ks2_evm/board.c
@@ -67,20 +67,7 @@ struct image_header *spl_get_load_buffer(ssize_t offset, 
size_t size)
 
 int board_init(void)
 {
-#if CONFIG_IS_ENABLED(DM_USB)
-   int rc = psc_enable_module(KS2_LPSC_USB);
-
-   if (rc)
-   puts("Cannot enable USB0 module");
-#ifdef KS2_LPSC_USB_1
-   rc = psc_enable_module(KS2_LPSC_USB_1);
-   if (rc)
-   puts("Cannot enable USB1 module");
-#endif
-#endif
-
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
-
return 0;
 }
 
-- 
2.17.1

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

[U-Boot] [PATCH v4 03/15] usb: xhci: move xhci.h to include usb

[Jean-Jacques Hiblot]

The xhci.h header file is currently located under drivers/usb/xhci
Move it to the include/usb folder to make it available to drivers that
are not under drivers/usb/xhci

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 MAINTAINERS  | 1 +
 drivers/usb/host/xhci-dwc3.c | 2 +-
 drivers/usb/host/xhci-exynos5.c  | 2 +-
 drivers/usb/host/xhci-fsl.c  | 2 +-
 drivers/usb/host/xhci-mem.c  | 2 +-
 drivers/usb/host/xhci-mvebu.c| 2 +-
 drivers/usb/host/xhci-omap.c | 2 +-
 drivers/usb/host/xhci-pci.c  | 2 +-
 drivers/usb/host/xhci-rcar.c | 2 +-
 drivers/usb/host/xhci-ring.c | 2 +-
 drivers/usb/host/xhci-rockchip.c | 2 +-
 drivers/usb/host/xhci.c  | 2 +-
 drivers/usb/phy/omap_usb_phy.c   | 2 +-
 {drivers/usb/host => include/usb}/xhci.h | 0
 14 files changed, 13 insertions(+), 12 deletions(-)
 rename {drivers/usb/host => include/usb}/xhci.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 08222fd569..c19a39d6cb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -845,6 +845,7 @@ M:  Bin Meng 
 S: Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-usb.git topic-xhci
 F: drivers/usb/host/xhci*
+F: include/usb/xhci.h
 
 VIDEO
 M: Anatolij Gustschin 
diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index 9e8cae7ae4..b2e4e28d8c 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 
-#include "xhci.h"
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/usb/host/xhci-exynos5.c b/drivers/usb/host/xhci-exynos5.c
index c150f520bd..25c30c24f0 100644
--- a/drivers/usb/host/xhci-exynos5.c
+++ b/drivers/usb/host/xhci-exynos5.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-#include "xhci.h"
+#include 
 
 /* Declare global data pointer */
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/drivers/usb/host/xhci-fsl.c b/drivers/usb/host/xhci-fsl.c
index c0b98a8ec7..9e0c1b76e4 100644
--- a/drivers/usb/host/xhci-fsl.c
+++ b/drivers/usb/host/xhci-fsl.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 #include 
-#include "xhci.h"
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 84c2c3344a..530e979bb7 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 
-#include "xhci.h"
+#include 
 
 #define CACHELINE_SIZE CONFIG_SYS_CACHELINE_SIZE
 /**
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
index b6c6aaf78e..2b871046ae 100644
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-#include "xhci.h"
+#include 
 
 struct mvebu_xhci_platdata {
fdt_addr_t hcd_base;
diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index db007af37f..25b195f7d1 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 
-#include "xhci.h"
+#include 
 
 /* Declare global data pointer */
 static struct omap_xhci omap;
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index b995aef997..c1f60da541 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 #include 
-#include "xhci.h"
+#include 
 
 static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,
  struct xhci_hcor **ret_hcor)
diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
index f2e91ef0fe..c4d8811343 100644
--- a/drivers/usb/host/xhci-rcar.c
+++ b/drivers/usb/host/xhci-rcar.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-#include "xhci.h"
+#include 
 #include "xhci-rcar-r8a779x_usb3_v3.h"
 
 /* Register Offset */
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index b2cfd948f8..119b418487 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 
-#include "xhci.h"
+#include 
 
 /**
  * Is this TRB a link TRB or was the last TRB the last TRB in this event ring
diff --git a/drivers/usb/host/xhci-rockchip.c b/drivers/usb/host/xhci-rockchip.c
index e7b0dbcca5..b67722fe45 100644
--- a/drivers/usb/host/xhci-rockchip.c
+++ b/drivers/usb/host/xhci-rockchip.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 
-#include "xhci.h"
+#include 
 
 struct rockchip_xhci_platdata {
fdt_addr_t hcd_base;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b3e4dcd66f..abd23e23fd 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include "xhci.h"
+#include 
 
 #ifndef CONFIG_USB_MAX_CONTROLLER_COUNT
 #define CONFIG_USB_MAX_CONTROLLER_COUNT 1
diff --git a/drivers/usb/phy/omap_usb_phy.c 

[U-Boot] [PATCH v4 09/15] usb: dwc3: Add dwc3_of_parse() to get quirks information from DT

[Jean-Jacques Hiblot]

Add a new function that read quirk and configuration information from the
DT. The goal is to allow platforms using their own version of DWC3 driver
to migrate to the generic DWC3 driver.
The function is adapted from the function dwc3_get_properties() in the
linux dwc3 driver introduced in commit c5ac6116db35d.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v4: None
Changes in v3: None
Changes in v2:
Update commit log

 drivers/usb/dwc3/core.c | 65 +
 drivers/usb/dwc3/core.h |  1 +
 drivers/usb/dwc3/dwc3-generic.c |  6 ++-
 3 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 653c874fa6..1baad39796 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -888,6 +888,71 @@ int dwc3_shutdown_phy(struct udevice *dev, struct phy 
*usb_phys, int num_phys)
 #endif
 
 #if CONFIG_IS_ENABLED(DM_USB)
+void dwc3_of_parse(struct dwc3 *dwc)
+{
+   const u8 *tmp;
+   struct udevice *dev = dwc->dev;
+   u8 lpm_nyet_threshold;
+   u8 tx_de_emphasis;
+   u8 hird_threshold;
+
+   /* default to highest possible threshold */
+   lpm_nyet_threshold = 0xff;
+
+   /* default to -3.5dB de-emphasis */
+   tx_de_emphasis = 1;
+
+   /*
+* default to assert utmi_sleep_n and use maximum allowed HIRD
+* threshold value of 0b1100
+*/
+   hird_threshold = 12;
+
+   dwc->has_lpm_erratum = dev_read_bool(dev,
+   "snps,has-lpm-erratum");
+   tmp = dev_read_u8_array_ptr(dev, "snps,lpm-nyet-threshold", 1);
+   if (tmp)
+   lpm_nyet_threshold = *tmp;
+
+   dwc->is_utmi_l1_suspend = dev_read_bool(dev,
+   "snps,is-utmi-l1-suspend");
+   tmp = dev_read_u8_array_ptr(dev, "snps,hird-threshold", 1);
+   if (tmp)
+   hird_threshold = *tmp;
+
+   dwc->disable_scramble_quirk = dev_read_bool(dev,
+   "snps,disable_scramble_quirk");
+   dwc->u2exit_lfps_quirk = dev_read_bool(dev,
+   "snps,u2exit_lfps_quirk");
+   dwc->u2ss_inp3_quirk = dev_read_bool(dev,
+   "snps,u2ss_inp3_quirk");
+   dwc->req_p1p2p3_quirk = dev_read_bool(dev,
+   "snps,req_p1p2p3_quirk");
+   dwc->del_p1p2p3_quirk = dev_read_bool(dev,
+   "snps,del_p1p2p3_quirk");
+   dwc->del_phy_power_chg_quirk = dev_read_bool(dev,
+   "snps,del_phy_power_chg_quirk");
+   dwc->lfps_filter_quirk = dev_read_bool(dev,
+   "snps,lfps_filter_quirk");
+   dwc->rx_detect_poll_quirk = dev_read_bool(dev,
+   "snps,rx_detect_poll_quirk");
+   dwc->dis_u3_susphy_quirk = dev_read_bool(dev,
+   "snps,dis_u3_susphy_quirk");
+   dwc->dis_u2_susphy_quirk = dev_read_bool(dev,
+   "snps,dis_u2_susphy_quirk");
+   dwc->tx_de_emphasis_quirk = dev_read_bool(dev,
+   "snps,tx_de_emphasis_quirk");
+   tmp = dev_read_u8_array_ptr(dev, "snps,tx_de_emphasis", 1);
+   if (tmp)
+   tx_de_emphasis = *tmp;
+
+   dwc->lpm_nyet_threshold = lpm_nyet_threshold;
+   dwc->tx_de_emphasis = tx_de_emphasis;
+
+   dwc->hird_threshold = hird_threshold
+   | (dwc->is_utmi_l1_suspend << 4);
+}
+
 int dwc3_init(struct dwc3 *dwc)
 {
int ret;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4c89dfcad9..be9672266a 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -991,6 +991,7 @@ struct dwc3_gadget_ep_cmd_params {
 
 /* prototypes */
 int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
+void dwc3_of_parse(struct dwc3 *dwc);
 int dwc3_init(struct dwc3 *dwc);
 void dwc3_remove(struct dwc3 *dwc);
 
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index a3b65088f1..023e95395b 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -48,8 +48,12 @@ static int dwc3_generic_probe(struct udevice *dev,
struct dwc3_generic_plat *plat = dev_get_platdata(dev);
struct dwc3 *dwc3 = >dwc3;
 
+   dwc3->dev = dev;
dwc3->maximum_speed = plat->maximum_speed;
dwc3->dr_mode = plat->dr_mode;
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+   dwc3_of_parse(dwc3);
+#endif
 
rc = dwc3_setup_phy(dev, >phys, >num_phys);
if (rc)
@@ -57,7 +61,7 @@ static int dwc3_generic_probe(struct udevice *dev,
 
priv->base = map_physmem(plat->base, DWC3_OTG_REGS_END, MAP_NOCACHE);
dwc3->regs = priv->base + DWC3_GLOBALS_REGS_START;
-   dwc3->dev = dev;
+
 
rc =  dwc3_init(dwc3);
if (rc) {
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de

[U-Boot] [PATCH v4 14/15] configs: k2g_evm_defconfig: disable XHCI_DWC3 and enable KEYSTONE_USB_PHY

[Jean-Jacques Hiblot]

KEYSTONE_USB_PHY is now required for proper USB operations.
XHCI_DWC3 can be disabled as the xhci-dwc3 is not used anymore
USB_DWC3_GADGET can also be removed, it is now selected automatically.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 configs/k2g_evm_defconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig
index 27804517fe..865a643abe 100644
--- a/configs/k2g_evm_defconfig
+++ b/configs/k2g_evm_defconfig
@@ -63,6 +63,7 @@ CONFIG_MII=y
 CONFIG_DRIVER_TI_KEYSTONE_NET=y
 CONFIG_PHY=y
 CONFIG_NOP_PHY=y
+CONFIG_KEYSTONE_USB_PHY=y
 CONFIG_REMOTEPROC_TI_POWER=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
@@ -73,9 +74,7 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_DM_USB_GADGET=y
 CONFIG_USB_XHCI_HCD=y
-CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
-CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_GENERIC=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DOWNLOAD=y
-- 
2.17.1

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

[U-Boot] [PATCH v4 05/15] usb: dwc3-generic: use platdata

[Jean-Jacques Hiblot]

Separate platform data from the private data.
This is one step toward adding host support.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/usb/dwc3/dwc3-generic.c | 37 -
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 406bf0b362..f29b93d191 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -22,17 +22,22 @@
 #include 
 #include 
 
+struct dwc3_generic_plat {
+   fdt_addr_t base;
+   u32 maximum_speed;
+   enum usb_dr_mode dr_mode;
+};
+
 #if CONFIG_IS_ENABLED(DM_USB_GADGET)
-struct dwc3_generic_peripheral {
+struct dwc3_generic_priv {
struct dwc3 dwc3;
struct phy *phys;
int num_phys;
-   fdt_addr_t base;
 };
 
 int dm_usb_gadget_handle_interrupts(struct udevice *dev)
 {
-   struct dwc3_generic_peripheral *priv = dev_get_priv(dev);
+   struct dwc3_generic_priv *priv = dev_get_priv(dev);
struct dwc3 *dwc3 = >dwc3;
 
dwc3_gadget_uboot_handle_interrupt(dwc3);
@@ -43,14 +48,18 @@ int dm_usb_gadget_handle_interrupts(struct udevice *dev)
 static int dwc3_generic_peripheral_probe(struct udevice *dev)
 {
int rc;
-   struct dwc3_generic_peripheral *priv = dev_get_priv(dev);
+   struct dwc3_generic_priv *priv = dev_get_priv(dev);
+   struct dwc3_generic_plat *plat = dev_get_platdata(dev);
struct dwc3 *dwc3 = >dwc3;
 
+   dwc3->maximum_speed = plat->maximum_speed;
+   dwc3->dr_mode = plat->dr_mode;
+
rc = dwc3_setup_phy(dev, >phys, >num_phys);
if (rc)
return rc;
 
-   dwc3->regs = map_physmem(priv->base, DWC3_OTG_REGS_END, MAP_NOCACHE);
+   dwc3->regs = map_physmem(plat->base, DWC3_OTG_REGS_END, MAP_NOCACHE);
dwc3->regs += DWC3_GLOBALS_REGS_START;
dwc3->dev = dev;
 
@@ -65,7 +74,7 @@ static int dwc3_generic_peripheral_probe(struct udevice *dev)
 
 static int dwc3_generic_peripheral_remove(struct udevice *dev)
 {
-   struct dwc3_generic_peripheral *priv = dev_get_priv(dev);
+   struct dwc3_generic_priv *priv = dev_get_priv(dev);
struct dwc3 *dwc3 = >dwc3;
 
dwc3_remove(dwc3);
@@ -77,20 +86,19 @@ static int dwc3_generic_peripheral_remove(struct udevice 
*dev)
 
 static int dwc3_generic_peripheral_ofdata_to_platdata(struct udevice *dev)
 {
-   struct dwc3_generic_peripheral *priv = dev_get_priv(dev);
-   struct dwc3 *dwc3 = >dwc3;
+   struct dwc3_generic_plat *plat = dev_get_platdata(dev);
int node = dev_of_offset(dev);
 
-   priv->base = devfdt_get_addr(dev);
+   plat->base = devfdt_get_addr(dev);
 
-   dwc3->maximum_speed = usb_get_maximum_speed(node);
-   if (dwc3->maximum_speed == USB_SPEED_UNKNOWN) {
+   plat->maximum_speed = usb_get_maximum_speed(node);
+   if (plat->maximum_speed == USB_SPEED_UNKNOWN) {
pr_err("Invalid usb maximum speed\n");
return -ENODEV;
}
 
-   dwc3->dr_mode = usb_get_dr_mode(node);
-   if (dwc3->dr_mode == USB_DR_MODE_UNKNOWN) {
+   plat->dr_mode = usb_get_dr_mode(node);
+   if (plat->dr_mode == USB_DR_MODE_UNKNOWN) {
pr_err("Invalid usb mode setup\n");
return -ENODEV;
}
@@ -104,7 +112,8 @@ U_BOOT_DRIVER(dwc3_generic_peripheral) = {
.ofdata_to_platdata = dwc3_generic_peripheral_ofdata_to_platdata,
.probe = dwc3_generic_peripheral_probe,
.remove = dwc3_generic_peripheral_remove,
-   .priv_auto_alloc_size = sizeof(struct dwc3_generic_peripheral),
+   .priv_auto_alloc_size = sizeof(struct dwc3_generic_priv),
+   .platdata_auto_alloc_size = sizeof(struct dwc3_generic_plat),
 };
 #endif
 
-- 
2.17.1

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

[U-Boot] [PATCH v4 13/15] phy: keystone-usb: handle the transition of the USB power domain

[Jean-Jacques Hiblot]

There is no proper power domain support for the keystone platforms.
However we need to turn off the USB domains before jumping to linux or it
fail to boot (observed with k2e and k2l platforms).
This can be done in the PHY driver as it is dedicated only to the keystone
platforms and matches the required on/off sequence.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/phy/keystone-usb-phy.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/phy/keystone-usb-phy.c b/drivers/phy/keystone-usb-phy.c
index e8146cabfa..14ac62 100644
--- a/drivers/phy/keystone-usb-phy.c
+++ b/drivers/phy/keystone-usb-phy.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* USB PHY control register offsets */
 #define USB_PHY_CTL_UTMI   0x
@@ -22,15 +23,25 @@
 #define PHY_REF_SSP_EN BIT(29)
 
 struct keystone_usb_phy {
+   u32 psc_domain;
void __iomem *reg;
 };
 
 static int keystone_usb_init(struct phy *phy)
 {
u32 val;
+   int rc;
struct udevice *dev = phy->dev;
struct keystone_usb_phy *keystone = dev_get_priv(dev);
 
+   /* Release USB from reset */
+   rc = psc_enable_module(keystone->psc_domain);
+   if (rc) {
+   debug("Cannot enable USB module");
+   return -rc;
+   }
+   mdelay(10);
+
/*
 * VBUSVLDEXTSEL has a default value of 1 in BootCfg but shouldn't.
 * It should always be cleared because our USB PHY has an onchip VBUS
@@ -72,13 +83,24 @@ static int keystone_usb_power_off(struct phy *phy)
 
 static int keystone_usb_exit(struct phy *phy)
 {
+   struct udevice *dev = phy->dev;
+   struct keystone_usb_phy *keystone = dev_get_priv(dev);
+
+   if (psc_disable_module(keystone->psc_domain))
+   debug("failed to disable USB module!\n");
+
return 0;
 }
 
 static int keystone_usb_phy_probe(struct udevice *dev)
 {
+   int rc;
struct keystone_usb_phy *keystone = dev_get_priv(dev);
 
+   rc = dev_read_u32(dev, "psc-domain", >psc_domain);
+   if (rc)
+   return rc;
+
keystone->reg = dev_remap_addr_index(dev, 0);
if (!keystone->reg) {
pr_err("unable to remap usb phy\n");
-- 
2.17.1

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

[U-Boot] [PATCH v4 08/15] usb: dwc3-generic: if no max speed is specified in DT, assume super speed

[Jean-Jacques Hiblot]

There is no need to fail if the maximum speed is not specified.
If the speed is not specified, do the same as linux and assume super speed.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v4: None
Changes in v3:
- updated log message when defaulting to super speed

Changes in v2: None

 drivers/usb/dwc3/dwc3-generic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 4924d07553..a3b65088f1 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -89,8 +89,8 @@ static int dwc3_generic_ofdata_to_platdata(struct udevice 
*dev)
 
plat->maximum_speed = usb_get_maximum_speed(node);
if (plat->maximum_speed == USB_SPEED_UNKNOWN) {
-   pr_err("Invalid usb maximum speed\n");
-   return -ENODEV;
+   pr_info("No USB maximum speed specified. Using super speed\n");
+   plat->maximum_speed = USB_SPEED_SUPER;
}
 
plat->dr_mode = usb_get_dr_mode(node);
-- 
2.17.1

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

[U-Boot] [PATCH v4 10/15] usb: dwc3: Kconfig: get rid of obsolete mode selection

[Jean-Jacques Hiblot]

The mode selection for the DWC3 is kind of obsolete. The driver does not
have to be host only or gadget only. This choice is confusing.
All the remaining callers of dwc3_uboot_init() explicitly set dr_mode
before calling the function, so none rely on a default behavior.

Remove the choice menu and keep only the USB_DWC3_GADGET option. Enable it
by default if USB_GADGET and USB_DWC3 are enabled.
It must be disabled for the evb-rk3328 as it uses DWC2 for the gadget and
DWC3 for the host.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v4:
- update more defconfigs (u200, sei510, rock64-rk332 and odroid-n2)
- Fix the test of the USB_DWC3_GADGET option. IS_ENABLED() requires the
  whole option name including the 'CONFIG_' prefix

Changes in v3: None
Changes in v2:
Select USB_GADGET_DUALSPEED if USB_DWC3_GADGET is selected

 configs/evb-rk3328_defconfig|  1 +
 configs/odroid-n2_defconfig |  1 +
 configs/rock64-rk3328_defconfig |  1 +
 configs/sei510_defconfig|  1 +
 configs/u200_defconfig  |  1 +
 drivers/usb/dwc3/Kconfig| 18 ++
 drivers/usb/dwc3/core.c |  4 ++--
 7 files changed, 9 insertions(+), 18 deletions(-)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 37610774c1..f161c40ae7 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -86,6 +86,7 @@ CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_GENERIC=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Rockchip"
 CONFIG_USB_GADGET_VENDOR_NUM=0x2207
diff --git a/configs/odroid-n2_defconfig b/configs/odroid-n2_defconfig
index abd945a975..1caa391320 100644
--- a/configs/odroid-n2_defconfig
+++ b/configs/odroid-n2_defconfig
@@ -44,6 +44,7 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
 CONFIG_USB_DWC3_MESON_G12A=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig
index 3ab0af1158..60a0d1473c 100644
--- a/configs/rock64-rk3328_defconfig
+++ b/configs/rock64-rk3328_defconfig
@@ -88,6 +88,7 @@ CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_GENERIC=y
 CONFIG_USB_DWC2=y
 CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Rockchip"
 CONFIG_USB_GADGET_VENDOR_NUM=0x2207
diff --git a/configs/sei510_defconfig b/configs/sei510_defconfig
index 5aea81d873..7c34d0cab3 100644
--- a/configs/sei510_defconfig
+++ b/configs/sei510_defconfig
@@ -54,6 +54,7 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
 CONFIG_USB_DWC3_MESON_G12A=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_VENDOR_NUM=0x18d1
diff --git a/configs/u200_defconfig b/configs/u200_defconfig
index ced6ca84b6..009d564d6a 100644
--- a/configs/u200_defconfig
+++ b/configs/u200_defconfig
@@ -44,6 +44,7 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
 CONFIG_USB_DWC3_MESON_G12A=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_VENDOR_NUM=0x1b8e
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 25e1a38aee..c302486291 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -7,25 +7,11 @@ config USB_DWC3
 
 if USB_DWC3
 
-choice
-   bool "DWC3 Mode Selection"
-
-config USB_DWC3_HOST
-   bool "Host only mode"
-   depends on USB
-   help
- Select this when you want to use DWC3 in host mode only,
- thereby the gadget feature will be regressed.
-
 config USB_DWC3_GADGET
-   bool "Gadget only mode"
+   bool "USB Gadget support for DWC3"
+   default y
depends on USB_GADGET
select USB_GADGET_DUALSPEED
-   help
- Select this when you want to use DWC3 in gadget mode only,
- thereby the host feature will be regressed.
-
-endchoice
 
 comment "Platform Glue Driver Support"
 
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 1baad39796..10b3f837f2 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -707,9 +707,9 @@ int dwc3_uboot_init(struct dwc3_device *dwc3_dev)
return -ENOMEM;
}
 
-   if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
+   if (!IS_ENABLED(CONFIG_USB_DWC3_GADGET))
dwc->dr_mode = USB_DR_MODE_HOST;
-   else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
+   else if (!IS_ENABLED(CONFIG_USB_HOST))
dwc->dr_mode = USB_DR_MODE_PERIPHERAL;
 
if (dwc->dr_mode == USB_DR_MODE_UNKNOWN)
-- 
2.17.1

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

[U-Boot] [PATCH v4 15/15] ARM: DTS: keystone: complete the description of the USB PHY devices

[Jean-Jacques Hiblot]

As the PHY driver now handles the transitions of USB power domain, we
must add this information in the node of each PHY.
Also, the phy are expected in the "phys" property, not "usb-phys".
Also add the aliases for the USB ports on boards with more than a single
port.

Signed-off-by: Jean-Jacques Hiblot 

---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/dts/keystone-k2e-evm-u-boot.dtsi  | 32 ++
 arch/arm/dts/keystone-k2g-evm-u-boot.dtsi  | 28 +++
 arch/arm/dts/keystone-k2hk-evm-u-boot.dtsi | 14 ++
 arch/arm/dts/keystone-k2l-evm-u-boot.dtsi  | 18 
 4 files changed, 92 insertions(+)
 create mode 100644 arch/arm/dts/keystone-k2l-evm-u-boot.dtsi

diff --git a/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi 
b/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
index aecb4dde68..c94165ffe7 100644
--- a/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
+++ b/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
@@ -7,8 +7,40 @@
soc {
u-boot,dm-pre-reloc;
};
+   aliases {
+   usb0 = 
+   usb1 = 
+   };
 };
 
  {
u-boot,dm-pre-reloc;
 };
+
+_phy {
+   #phy-cells = <0>;
+   psc-domain = <2>;
+};
+
+ {
+   dwc3@269 {
+   phys = <_phy>;
+   dr_mode = "host";
+   snps,u2ss_inp3_quirk;
+   status = "okay";
+   };
+};
+
+_phy {
+   #phy-cells = <0>;
+   psc-domain = <1>;
+};
+
+ {
+   dwc3@2501 {
+   phys = <_phy>;
+   dr_mode = "peripheral";
+   snps,u2ss_inp3_quirk;
+   status = "okay";
+   };
+};
diff --git a/arch/arm/dts/keystone-k2g-evm-u-boot.dtsi 
b/arch/arm/dts/keystone-k2g-evm-u-boot.dtsi
index 80f1f60045..e8e70096ea 100644
--- a/arch/arm/dts/keystone-k2g-evm-u-boot.dtsi
+++ b/arch/arm/dts/keystone-k2g-evm-u-boot.dtsi
@@ -7,6 +7,10 @@
soc {
u-boot,dm-pre-reloc;
};
+   aliases {
+   usb0 = 
+   usb1 = 
+   };
 };
 
  {
@@ -16,3 +20,27 @@
  {
u-boot,dm-pre-reloc;
 };
+
+_phy {
+   compatible = "ti,keystone-usbphy";
+   #phy-cells = <0>;
+   reg = <0x2620738 24>;
+   psc-domain = <25>;
+};
+
+ {
+   phys = <_phy>;
+   snps,u2ss_inp3_quirk;
+};
+
+_phy {
+   compatible = "ti,keystone-usbphy";
+   #phy-cells = <0>;
+   reg = <0x2620750 24>;
+   psc-domain = <26>;
+};
+
+ {
+   phys = <_phy>;
+   snps,u2ss_inp3_quirk;
+};
diff --git a/arch/arm/dts/keystone-k2hk-evm-u-boot.dtsi 
b/arch/arm/dts/keystone-k2hk-evm-u-boot.dtsi
index aecb4dde68..1c2f349f5c 100644
--- a/arch/arm/dts/keystone-k2hk-evm-u-boot.dtsi
+++ b/arch/arm/dts/keystone-k2hk-evm-u-boot.dtsi
@@ -12,3 +12,17 @@
  {
u-boot,dm-pre-reloc;
 };
+
+_phy {
+   #phy-cells = <0>;
+   psc-domain = <2>;
+};
+
+ {
+   dwc3@269 {
+   phys = <_phy>;
+   dr_mode = "host";
+   snps,u2ss_inp3_quirk;
+   status = "okay";
+   };
+};
diff --git a/arch/arm/dts/keystone-k2l-evm-u-boot.dtsi 
b/arch/arm/dts/keystone-k2l-evm-u-boot.dtsi
new file mode 100644
index 00..0a507d0210
--- /dev/null
+++ b/arch/arm/dts/keystone-k2l-evm-u-boot.dtsi
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+_phy {
+   #phy-cells = <0>;
+   psc-domain = <2>;
+};
+
+ {
+   dwc3@269 {
+   phys = <_phy>;
+   dr_mode = "host";
+   snps,u2ss_inp3_quirk;
+   status = "okay";
+   };
+};
-- 
2.17.1

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

[U-Boot] [PATCH v4 04/15] usb: dwc3: always use the inlined version of dwc3_host_init/dwc3_host_exit

[Jean-Jacques Hiblot]

No one is actually implementing those functions.
We could remove calls to these altogether, but it does not really hurt to
keep the empty inlined version at the moment and it satisfies a symmetry
with the gadget mode.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/usb/dwc3/core.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index cfe29884e7..4c89dfcad9 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -994,15 +994,10 @@ int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
 int dwc3_init(struct dwc3 *dwc);
 void dwc3_remove(struct dwc3 *dwc);
 
-#ifdef CONFIG_USB_DWC3_HOST
-int dwc3_host_init(struct dwc3 *dwc);
-void dwc3_host_exit(struct dwc3 *dwc);
-#else
 static inline int dwc3_host_init(struct dwc3 *dwc)
 { return 0; }
 static inline void dwc3_host_exit(struct dwc3 *dwc)
 { }
-#endif
 
 #ifdef CONFIG_USB_DWC3_GADGET
 int dwc3_gadget_init(struct dwc3 *dwc);
-- 
2.17.1

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

[U-Boot] [PATCH v4 11/15] ARM: keystone: increase PSC timeout

[Jean-Jacques Hiblot]

Turning off the USB clocks may take longer than 100us.
Increase the timeout to 100ms.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/mach-keystone/include/mach/psc_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-keystone/include/mach/psc_defs.h 
b/arch/arm/mach-keystone/include/mach/psc_defs.h
index dfc22d5e90..f164f95bf2 100644
--- a/arch/arm/mach-keystone/include/mach/psc_defs.h
+++ b/arch/arm/mach-keystone/include/mach/psc_defs.h
@@ -94,7 +94,7 @@ static inline u32 boot_set_bitfield(u32 z, u32 f, u32 x, u32 
y)
  * Timeout limit on checking PTSTAT. This is the number of times the
  * wait function will be called before giving up.
  */
-#define PSC_PTSTAT_TIMEOUT_LIMIT100
+#define PSC_PTSTAT_TIMEOUT_LIMIT10
 
 u32 psc_get_domain_num(u32 mod_num);
 int psc_enable_module(u32 mod_num);
-- 
2.17.1

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

[U-Boot] [PATCH v4 06/15] usb: dwc3-generic: factorize code

[Jean-Jacques Hiblot]

Factor code for re-usability.
This is another step toward adding host support.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/usb/dwc3/dwc3-generic.c | 55 +
 1 file changed, 35 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index f29b93d191..d5c71d024f 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -28,27 +28,17 @@ struct dwc3_generic_plat {
enum usb_dr_mode dr_mode;
 };
 
-#if CONFIG_IS_ENABLED(DM_USB_GADGET)
 struct dwc3_generic_priv {
+   void *base;
struct dwc3 dwc3;
struct phy *phys;
int num_phys;
 };
 
-int dm_usb_gadget_handle_interrupts(struct udevice *dev)
-{
-   struct dwc3_generic_priv *priv = dev_get_priv(dev);
-   struct dwc3 *dwc3 = >dwc3;
-
-   dwc3_gadget_uboot_handle_interrupt(dwc3);
-
-   return 0;
-}
-
-static int dwc3_generic_peripheral_probe(struct udevice *dev)
+static int dwc3_generic_probe(struct udevice *dev,
+ struct dwc3_generic_priv *priv)
 {
int rc;
-   struct dwc3_generic_priv *priv = dev_get_priv(dev);
struct dwc3_generic_plat *plat = dev_get_platdata(dev);
struct dwc3 *dwc3 = >dwc3;
 
@@ -59,22 +49,22 @@ static int dwc3_generic_peripheral_probe(struct udevice 
*dev)
if (rc)
return rc;
 
-   dwc3->regs = map_physmem(plat->base, DWC3_OTG_REGS_END, MAP_NOCACHE);
-   dwc3->regs += DWC3_GLOBALS_REGS_START;
+   priv->base = map_physmem(plat->base, DWC3_OTG_REGS_END, MAP_NOCACHE);
+   dwc3->regs = priv->base + DWC3_GLOBALS_REGS_START;
dwc3->dev = dev;
 
rc =  dwc3_init(dwc3);
if (rc) {
-   unmap_physmem(dwc3->regs, MAP_NOCACHE);
+   unmap_physmem(priv->base, MAP_NOCACHE);
return rc;
}
 
return 0;
 }
 
-static int dwc3_generic_peripheral_remove(struct udevice *dev)
+static int dwc3_generic_remove(struct udevice *dev,
+  struct dwc3_generic_priv *priv)
 {
-   struct dwc3_generic_priv *priv = dev_get_priv(dev);
struct dwc3 *dwc3 = >dwc3;
 
dwc3_remove(dwc3);
@@ -84,7 +74,7 @@ static int dwc3_generic_peripheral_remove(struct udevice *dev)
return 0;
 }
 
-static int dwc3_generic_peripheral_ofdata_to_platdata(struct udevice *dev)
+static int dwc3_generic_ofdata_to_platdata(struct udevice *dev)
 {
struct dwc3_generic_plat *plat = dev_get_platdata(dev);
int node = dev_of_offset(dev);
@@ -106,10 +96,35 @@ static int 
dwc3_generic_peripheral_ofdata_to_platdata(struct udevice *dev)
return 0;
 }
 
+#if CONFIG_IS_ENABLED(DM_USB_GADGET)
+int dm_usb_gadget_handle_interrupts(struct udevice *dev)
+{
+   struct dwc3_generic_priv *priv = dev_get_priv(dev);
+   struct dwc3 *dwc3 = >dwc3;
+
+   dwc3_gadget_uboot_handle_interrupt(dwc3);
+
+   return 0;
+}
+
+static int dwc3_generic_peripheral_probe(struct udevice *dev)
+{
+   struct dwc3_generic_priv *priv = dev_get_priv(dev);
+
+   return dwc3_generic_probe(dev, priv);
+}
+
+static int dwc3_generic_peripheral_remove(struct udevice *dev)
+{
+   struct dwc3_generic_priv *priv = dev_get_priv(dev);
+
+   return dwc3_generic_remove(dev, priv);
+}
+
 U_BOOT_DRIVER(dwc3_generic_peripheral) = {
.name   = "dwc3-generic-peripheral",
.id = UCLASS_USB_GADGET_GENERIC,
-   .ofdata_to_platdata = dwc3_generic_peripheral_ofdata_to_platdata,
+   .ofdata_to_platdata = dwc3_generic_ofdata_to_platdata,
.probe = dwc3_generic_peripheral_probe,
.remove = dwc3_generic_peripheral_remove,
.priv_auto_alloc_size = sizeof(struct dwc3_generic_priv),
-- 
2.17.1

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

[U-Boot] [PATCH v4 01/15] usb: host: remove the xhci-zynqmp driver

[Jean-Jacques Hiblot]

This driver is not used anymore.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 configs/avnet_ultra96_rev1_defconfig  |   1 -
 .../xilinx_zynqmp_zc1751_xm015_dc1_defconfig  |   1 -
 .../xilinx_zynqmp_zc1751_xm016_dc2_defconfig  |   1 -
 .../xilinx_zynqmp_zc1751_xm017_dc3_defconfig  |   1 -
 configs/xilinx_zynqmp_zcu100_revC_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig |   1 -
 configs/xilinx_zynqmp_zcu102_revA_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu102_revB_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu104_revA_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu104_revC_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu106_revA_defconfig   |   1 -
 configs/xilinx_zynqmp_zcu111_revA_defconfig   |   1 -
 drivers/usb/host/Kconfig  |   7 -
 drivers/usb/host/Makefile |   1 -
 drivers/usb/host/xhci-zynqmp.c| 146 --
 15 files changed, 166 deletions(-)
 delete mode 100644 drivers/usb/host/xhci-zynqmp.c

diff --git a/configs/avnet_ultra96_rev1_defconfig 
b/configs/avnet_ultra96_rev1_defconfig
index b504332ff0..fcfebe9c78 100644
--- a/configs/avnet_ultra96_rev1_defconfig
+++ b/configs/avnet_ultra96_rev1_defconfig
@@ -75,7 +75,6 @@ CONFIG_ZYNQ_SPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_XHCI_ZYNQMP=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_GENERIC=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index 7b1f5e9d0a..8d906fa364 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -86,7 +86,6 @@ CONFIG_ZYNQMP_GQSPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_XHCI_ZYNQMP=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_GENERIC=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
index ae2554a8eb..198b92a18d 100644
--- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
@@ -77,7 +77,6 @@ CONFIG_SPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_XHCI_ZYNQMP=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_GENERIC=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig
index 559a61e8d0..0d93f3ceb1 100644
--- a/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig
@@ -74,7 +74,6 @@ CONFIG_SPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_XHCI_ZYNQMP=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_GENERIC=y
diff --git a/configs/xilinx_zynqmp_zcu100_revC_defconfig 
b/configs/xilinx_zynqmp_zcu100_revC_defconfig
index 4b3f72da74..3b0f81adf9 100644
--- a/configs/xilinx_zynqmp_zcu100_revC_defconfig
+++ b/configs/xilinx_zynqmp_zcu100_revC_defconfig
@@ -74,7 +74,6 @@ CONFIG_ZYNQ_SPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_XHCI_ZYNQMP=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_GENERIC=y
diff --git a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig 
b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
index ef291a7d38..7f10554594 100644
--- a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
@@ -101,7 +101,6 @@ CONFIG_ZYNQMP_GQSPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_XHCI_ZYNQMP=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_GENERIC=y
diff --git a/configs/xilinx_zynqmp_zcu102_revA_defconfig 
b/configs/xilinx_zynqmp_zcu102_revA_defconfig
index 975e9f5eb1..49f46dca09 100644
--- a/configs/xilinx_zynqmp_zcu102_revA_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revA_defconfig
@@ -100,7 +100,6 @@ CONFIG_ZYNQMP_GQSPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_XHCI_ZYNQMP=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_GENERIC=y
diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
b/configs/xilinx_zynqmp_zcu102_revB_defconfig
index 34918aa171..46ac6a3add 100644
--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
@@ -100,7 +100,6 @@ CONFIG_ZYNQMP_GQSPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_XHCI_ZYNQMP=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_GENERIC=y
diff --git a/configs/xilinx_zynqmp_zcu104_revA_defconfig 
b/configs/xilinx_zynqmp_zcu104_revA_defconfig
index e4090dc281..1672a684ac 100644
--- a/configs/xilinx_zynqmp_zcu104_revA_defconfig
+++ b/configs/xilinx_zynqmp_zcu104_revA_defconfig
@@ -85,7 +85,6 @@ CONFIG_ZYNQMP_GQSPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_XHCI_ZYNQMP=y
 CONFIG_USB_DWC3=y
 

[U-Boot] [PATCH v4 07/15] usb: dwc3-generic: add a new host driver that uses the dwc3 core

[Jean-Jacques Hiblot]

Currently the host driver used by dwc3-generic is "xhci-dwc3". This is
a functional driver but it doesn't use the dwc3 core and, in particular,
it lacks some bits that may be important.
For example on the k2 platforms, it is important that the phy are properly
suspended when the USB is not used anymore. The dwc3 core also has a
partial support for quirks.
The new driver can be used as a drop-in replacement for "xhci-dwc3".

In terms of implementation, it may seem strange that 2 private structures
dwc3_generic_host_priv and dwc3_generic_priv) are used. The reason for this
is simply that the xhci layer expects a struct xhci_ctrl at the beginning
of the private data and it seemed wasteful to include it also for the
peripheral case.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/usb/dwc3/core.c |  2 +-
 drivers/usb/dwc3/dwc3-generic.c | 54 -
 2 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index ae01490306..653c874fa6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -887,7 +887,7 @@ int dwc3_shutdown_phy(struct udevice *dev, struct phy 
*usb_phys, int num_phys)
 }
 #endif
 
-#if CONFIG_IS_ENABLED(DM_USB_GADGET)
+#if CONFIG_IS_ENABLED(DM_USB)
 int dwc3_init(struct dwc3 *dwc)
 {
int ret;
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index d5c71d024f..4924d07553 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -21,6 +21,7 @@
 #include "gadget.h"
 #include 
 #include 
+#include 
 
 struct dwc3_generic_plat {
fdt_addr_t base;
@@ -35,6 +36,11 @@ struct dwc3_generic_priv {
int num_phys;
 };
 
+struct dwc3_generic_host_priv {
+   struct xhci_ctrl xhci_ctrl;
+   struct dwc3_generic_priv gen_priv;
+};
+
 static int dwc3_generic_probe(struct udevice *dev,
  struct dwc3_generic_priv *priv)
 {
@@ -132,6 +138,50 @@ U_BOOT_DRIVER(dwc3_generic_peripheral) = {
 };
 #endif
 
+#if defined(CONFIG_SPL_USB_HOST_SUPPORT) || !defined(CONFIG_SPL_BUILD)
+static int dwc3_generic_host_probe(struct udevice *dev)
+{
+   struct xhci_hcor *hcor;
+   struct xhci_hccr *hccr;
+   struct dwc3_generic_host_priv *priv = dev_get_priv(dev);
+   int rc;
+
+   rc = dwc3_generic_probe(dev, >gen_priv);
+   if (rc)
+   return rc;
+
+   hccr = (struct xhci_hccr *)priv->gen_priv.base;
+   hcor = (struct xhci_hcor *)(priv->gen_priv.base +
+   HC_LENGTH(xhci_readl(&(hccr)->cr_capbase)));
+
+   return xhci_register(dev, hccr, hcor);
+}
+
+static int dwc3_generic_host_remove(struct udevice *dev)
+{
+   struct dwc3_generic_host_priv *priv = dev_get_priv(dev);
+   int rc;
+
+   rc = xhci_deregister(dev);
+   if (rc)
+   return rc;
+
+   return dwc3_generic_remove(dev, >gen_priv);
+}
+
+U_BOOT_DRIVER(dwc3_generic_host) = {
+   .name   = "dwc3-generic-host",
+   .id = UCLASS_USB,
+   .ofdata_to_platdata = dwc3_generic_ofdata_to_platdata,
+   .probe = dwc3_generic_host_probe,
+   .remove = dwc3_generic_host_remove,
+   .priv_auto_alloc_size = sizeof(struct dwc3_generic_host_priv),
+   .platdata_auto_alloc_size = sizeof(struct dwc3_generic_plat),
+   .ops = _usb_ops,
+   .flags = DM_FLAG_ALLOC_PRIV_DMA,
+};
+#endif
+
 struct dwc3_glue_data {
struct clk_bulk clks;
struct reset_ctl_bulk   resets;
@@ -252,10 +302,12 @@ static int dwc3_glue_bind(struct udevice *parent)
driver = "dwc3-generic-peripheral";
 #endif
break;
+#if defined(CONFIG_SPL_USB_HOST_SUPPORT) || !defined(CONFIG_SPL_BUILD)
case USB_DR_MODE_HOST:
debug("%s: dr_mode: HOST\n", __func__);
-   driver = "xhci-dwc3";
+   driver = "dwc3-generic-host";
break;
+#endif
default:
debug("%s: unsupported dr_mode\n", __func__);
return -ENODEV;
-- 
2.17.1

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

[U-Boot] [PATCH v4 02/15] usb: dwc3: switch to peripheral mode when exiting

[Jean-Jacques Hiblot]

This allow the phy to enter idle and then suspend.
the K2 platforms require the PHY to be suspended before the USB domain
clock can be turned off.

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

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/usb/dwc3/core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 56e2a046bf..ae01490306 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -581,6 +581,12 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
return 0;
 }
 
+static void dwc3_gadget_run(struct dwc3 *dwc)
+{
+   dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_RUN_STOP);
+   mdelay(100);
+}
+
 static void dwc3_core_exit_mode(struct dwc3 *dwc)
 {
switch (dwc->dr_mode) {
@@ -598,6 +604,13 @@ static void dwc3_core_exit_mode(struct dwc3 *dwc)
/* do nothing */
break;
}
+
+   /*
+* switch back to peripheral mode
+* This enables the phy to enter idle and then, if enabled, suspend.
+*/
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+   dwc3_gadget_run(dwc);
 }
 
 #define DWC3_ALIGN_MASK(16 - 1)
-- 
2.17.1

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

[U-Boot] [PATCH] net: phy: Define init routine and register generic phy driver

[Michal Simek]

From: Siva Durga Prasad Paladugu 

This patch define init routine for generic phy driver and registers it
using phy_register as this generic phy driver also needs to be relocated
incase of manual reloc.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/net/phy/phy.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index ae37dd6c1e37..8c4043445e86 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -458,6 +458,11 @@ static struct phy_driver genphy_driver = {
.shutdown   = genphy_shutdown,
 };
 
+int genphy_init(void)
+{
+   return phy_register(_driver);
+}
+
 static LIST_HEAD(phy_drivers);
 
 int phy_init(void)
@@ -540,6 +545,8 @@ int phy_init(void)
 #ifdef CONFIG_PHY_FIXED
phy_fixed_init();
 #endif
+   genphy_init();
+
return 0;
 }
 
-- 
2.17.1

___
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

[Bin Meng]

Hi Aaron,

On Tue, Sep 10, 2019 at 7:53 AM Aaron Williams  wrote:
>
> 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.
>

Thank you very much for your efforts on analyzing this. It looks short
packet indeed is not correctly handled in the bulk transfer. But in
the control transfer, looks it is being handled. Could you please
adding the same piece of codes to the xhci_bulk_tx() to see if it
fixes the issue?

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

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

Re: [U-Boot] [PATCH] zynqmp: firmware: Add Xilinx ZynqMP firmware driver

[Michal Simek]

On 11. 09. 19 10:54, Lokesh Vutla wrote:
> 
> 
> On 11/09/19 1:17 PM, Michal Simek wrote:
>> From: Rajan Vaja 
>>
>> Add simple ZynqMP firmware drive to populate child nodes under
>> zynqmp_firmware DT node.
>>
>> Signed-off-by: Rajan Vaja 
>> Signed-off-by: Michal Simek 
> 
> If this driver is only meant for populating child nodes, then simple-bus in
> compatible can solve the problem.

For u-boot this should be ok but it is not the part of kernel DT binding.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt?h=v5.3-rc8

Also adding simple-bus in u-boot DTS file would cause issues ok kernel
side when DT from u-boot is used in Linux.

My expectation is that we should move all functionality which we have in
platform code to this driver.

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

[U-Boot] [RFC PATCH v1 4/5] imx: nandbcb: refactor update function

[Igor Opaniuk]

From: Igor Opaniuk 

Move code for writing FCB/DBBT pages to a separate function

Signed-off-by: Igor Opaniuk 
---

 arch/arm/mach-imx/cmd_nandbcb.c | 221 ++--
 1 file changed, 122 insertions(+), 99 deletions(-)

diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index b7f651568f..72d8a5be28 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -64,7 +64,8 @@ static u32 calc_chksum(void *buf, size_t size)
return ~chksum;
 }
 
-static void fill_fcb(struct fcb_block *fcb, struct mtd_info *mtd)
+static void fill_fcb(struct fcb_block *fcb, struct mtd_info *mtd,
+u32 fw1_start, u32 fw2_start, u32 fw_pages)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
struct mxs_nand_info *nand_info = nand_get_controller_data(chip);
@@ -112,6 +113,11 @@ static void fill_fcb(struct fcb_block *fcb, struct 
mtd_info *mtd)
fcb->disbbm = 0;
fcb->disbbm_search = 0;
 
+   fcb->fw1_start = fw1_start; /* Firmware image starts on this sector */
+   fcb->fw2_start = fw2_start; /* Secondary FW Image starting Sector */
+   fcb->fw1_pages = fw_pages; /* Number of sectors in firmware image */
+   fcb->fw2_pages = fw_pages; /* Number of sector in secondary FW image */
+
fcb->checksum = calc_chksum((void *)fcb + 4, sizeof(*fcb) - 4);
 }
 
@@ -135,6 +141,109 @@ static int dbbt_fill_data(struct mtd_info *mtd, void 
*buf, int num_blocks)
return n_bad_blocks;
 }
 
+static int write_fcb_dbbt(struct mtd_info *mtd, struct fcb_block *fcb,
+ struct dbbt_block *dbbt, void *dbbt_data_page,
+ loff_t off)
+{
+   void *fcb_raw_page = 0;
+   int i, ret;
+   size_t dummy;
+
+   /*
+* We prepare raw page only for i.MX6, for i.MX7 we
+* leverage BCH hw module instead
+*/
+   if (is_mx6()) {
+   /* write fcb/dbbt */
+   fcb_raw_page = kzalloc(mtd->writesize + mtd->oobsize,
+  GFP_KERNEL);
+   if (!fcb_raw_page) {
+   debug("failed to allocate fcb_raw_page\n");
+   ret = -ENOMEM;
+   return ret;
+   }
+
+   memcpy(fcb_raw_page + 12, fcb, sizeof(struct fcb_block));
+   encode_hamming_13_8(fcb_raw_page + 12, fcb_raw_page +
+   12 + 512, 512);
+   /*
+* Set the first and second byte of OOB data to 0xFF,
+* not 0x00. These bytes are used as the Manufacturers Bad
+* Block Marker (MBBM). Since the FCB is mostly written to
+* the first page in a block, a scan for
+* factory bad blocks will detect these blocks as bad, e.g.
+* when function nand_scan_bbt() is executed to build a new
+* bad block table.
+*/
+   memset(fcb_raw_page + mtd->writesize, 0xFF, 2);
+   }
+   for (i = 0; i < 2; i++) {
+   if (mtd_block_isbad(mtd, off)) {
+   printf("Block %d is bad, skipped\n", i);
+   continue;
+   }
+
+   /*
+* User BCH ECC hardware module for i.MX7
+*/
+   if (is_mx7()) {
+   u32 off = i * mtd->erasesize;
+   size_t rwsize = sizeof(*fcb);
+
+   printf("Writing %d bytes to 0x%x: ", rwsize, off);
+
+   /* switch nand BCH to FCB compatible settings */
+   mxs_nand_mode_fcb(mtd);
+   ret = nand_write(mtd, off, ,
+(unsigned char *)fcb);
+   mxs_nand_mode_normal(mtd);
+
+   printf("%s\n", ret ? "ERROR" : "OK");
+   } else if (is_mx6()) {
+   /* raw write */
+   mtd_oob_ops_t ops = {
+   .datbuf = (u8 *)fcb_raw_page,
+   .oobbuf = ((u8 *)fcb_raw_page) +
+ mtd->writesize,
+   .len = mtd->writesize,
+   .ooblen = mtd->oobsize,
+   .mode = MTD_OPS_RAW
+   };
+
+   ret = mtd_write_oob(mtd, mtd->erasesize * i, );
+   if (ret)
+   goto fcb_raw_page_err;
+   debug("NAND fcb write: 0x%x offset 0x%x written: %s\n",
+ mtd->erasesize * i, ops.len, ret ?
+ "ERROR" : "OK");
+   }
+
+   ret = mtd_write(mtd, mtd->erasesize * i + mtd->writesize,
+   mtd->writesize, , (void *)dbbt);
+   if (ret)
+ 

[U-Boot] [RFC PATCH v1 5/5] imx: nandbcb: add support for writing BCB only

[Igor Opaniuk]

From: Igor Opaniuk 

Add subcommand for add writing BCB only, where we provide appropriate
offsets for firmware1 and firmware2 and size.

Example of usage:
> nandbcb bcbonly 0x0018 0x0008 0x0020
Writing 1024 bytes to 0x0: randomizing
OK
Writing 1024 bytes to 0x2: randomizing
OK

Signed-off-by: Igor Opaniuk 
---

 arch/arm/mach-imx/cmd_nandbcb.c | 92 -
 1 file changed, 91 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index 72d8a5be28..a02edfc582 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -364,6 +364,88 @@ err:
return ret;
 }
 
+static int do_nandbcb_bcbonly(int argc, char * const argv[])
+{
+   struct fcb_block *fcb;
+   struct dbbt_block *dbbt;
+   u32 fw_len, fw1_off, fw2_off;
+   struct mtd_info *mtd;
+   void *dbbt_page, *dbbt_data_page;
+   int dev, ret;
+
+   dev = nand_curr_device;
+   if ((dev < 0) || (dev >= CONFIG_SYS_MAX_NAND_DEVICE) ||
+   (!get_nand_dev_by_index(dev))) {
+   puts("No devices available\n");
+   return CMD_RET_FAILURE;
+   }
+
+   mtd = get_nand_dev_by_index(dev);
+
+   if (argc < 3)
+   return CMD_RET_FAILURE;
+
+   fw_len = simple_strtoul(argv[1], NULL, 16);
+   fw1_off = simple_strtoul(argv[2], NULL, 16);
+
+   if (argc > 3)
+   fw2_off = simple_strtoul(argv[3], NULL, 16);
+   else
+   fw2_off = fw1_off;
+
+   /* fill fcb */
+   fcb = kzalloc(sizeof(*fcb), GFP_KERNEL);
+   if (!fcb) {
+   debug("failed to allocate fcb\n");
+   ret = -ENOMEM;
+   return CMD_RET_FAILURE;
+   }
+
+   fill_fcb(fcb, mtd, fw1_off / mtd->writesize,
+fw2_off / mtd->writesize, fw_len / mtd->writesize);
+
+   /* fill dbbt */
+   dbbt_page = kzalloc(mtd->writesize, GFP_KERNEL);
+   if (!dbbt_page) {
+   debug("failed to allocate dbbt_page\n");
+   ret = -ENOMEM;
+   goto fcb_err;
+   }
+
+   dbbt_data_page = kzalloc(mtd->writesize, GFP_KERNEL);
+   if (!dbbt_data_page) {
+   debug("failed to allocate dbbt_data_page\n");
+   ret = -ENOMEM;
+   goto dbbt_page_err;
+   }
+
+   dbbt = dbbt_page;
+   dbbt->checksum = 0;
+   dbbt->fingerprint = DBBT_FINGERPRINT2;
+   dbbt->version = DBBT_VERSION_1;
+   ret = dbbt_fill_data(mtd, dbbt_data_page, 0);
+   if (ret < 0)
+   goto dbbt_data_page_err;
+   else if (ret > 0)
+   dbbt->dbbtpages = 1;
+
+   /* write fcb and dbbt to nand */
+   ret = write_fcb_dbbt(mtd, fcb, dbbt, dbbt_data_page, 0);
+dbbt_data_page_err:
+   kfree(dbbt_data_page);
+dbbt_page_err:
+   kfree(dbbt_page);
+fcb_err:
+   kfree(fcb);
+
+   if (ret < 0) {
+   printf("failed to write FCB/DBBT\n");
+   return CMD_RET_FAILURE;
+   }
+
+   return CMD_RET_SUCCESS;
+}
+
 static int do_nandbcb_update(int argc, char * const argv[])
 {
struct mtd_info *mtd;
@@ -420,6 +502,11 @@ static int do_nandbcb(cmd_tbl_t *cmdtp, int flag, int argc,
goto done;
}
 
+   if (strcmp(cmd, "bcbonly") == 0) {
+   ret = do_nandbcb_bcbonly(argc, argv);
+   goto done;
+   }
+
 done:
if (ret != -1)
return ret;
@@ -429,7 +516,10 @@ usage:
 
 static char nandbcb_help_text[] =
"update addr off|partition len  - update 'len' bytes starting at\n"
-   "   'off|part' to memory address 'addr', skipping  bad blocks";
+   "'off|part' to memory address 'addr', skipping  bad blocks\n"
+   "bcbonly fw-size fw1-off [fw2-off] - write only BCB (FCB and DBBT)\n"
+   "where `fw-size` is fw sizes in bytes, `fw1-off` and\n"
+   "and `fw2-off` - firmware offsets   ";
 
 U_BOOT_CMD(nandbcb, 5, 1, do_nandbcb,
   "i.MX6 Nand BCB",
-- 
2.17.1

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

[U-Boot] [RFC PATCH v1 2/5] nand: mxs_nand: add API for switching different BCH layouts

[Igor Opaniuk]

From: Igor Opaniuk 

On i.MX7 in a sake of reducing the disturbances caused by a neighboring
cells in the FCB page in the NAND chip, a randomizer is enabled when
reading the FCB page by ROM bootloader.

Add API for setting BCH to specific layout (and restoring it back) used by
ROM bootloader to be able to burn it in a proper way to NAND using
nandbcb command.

Signed-off-by: Igor Opaniuk 
Signed-off-by: Anti Sullin 
---

 drivers/mtd/nand/raw/mxs_nand.c | 120 
 include/mxs_nand.h  |  25 +++
 2 files changed, 145 insertions(+)

diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c
index a41b9620d0..53af00e531 100644
--- a/drivers/mtd/nand/raw/mxs_nand.c
+++ b/drivers/mtd/nand/raw/mxs_nand.c
@@ -740,6 +740,21 @@ static int mxs_nand_ecc_write_page(struct mtd_info *mtd,
d->cmd.pio_words[4] = (dma_addr_t)nand_info->data_buf;
d->cmd.pio_words[5] = (dma_addr_t)nand_info->oob_buf;
 
+#if CONFIG_IS_ENABLED(MX7)
+   if (nand_info->en_randomizer) {
+   d->cmd.pio_words[2] |= GPMI_ECCCTRL_RANDOMIZER_ENABLE |
+  GPMI_ECCCTRL_RANDOMIZER_TYPE2;
+   /*
+* Write NAND page number needed to be randomized
+* to GPMI_ECCCOUNT register.
+*
+* The value is between 0-255. For additional details
+* check 9.6.6.4 of i.MX7D Applications Processor reference
+*/
+   d->cmd.pio_words[3] |= (page % 255) << 16;
+   }
+#endif
+
mxs_dma_desc_append(channel, d);
 
/* Flush caches */
@@ -1003,6 +1018,10 @@ int mxs_nand_setup_ecc(struct mtd_info *mtd)
uint32_t tmp;
int ret;
 
+   nand_info->en_randomizer = 0;
+   nand_info->oobsize = mtd->oobsize;
+   nand_info->writesize = mtd->writesize;
+
ret = mxs_nand_set_geometry(mtd, geo);
if (ret)
return ret;
@@ -1020,6 +1039,7 @@ int mxs_nand_setup_ecc(struct mtd_info *mtd)
tmp |= (geo->gf_len == 14 ? 1 : 0) <<
BCH_FLASHLAYOUT0_GF13_0_GF14_1_OFFSET;
writel(tmp, _regs->hw_bch_flash0layout0);
+   nand_info->bch_flash0layout0 = tmp;
 
tmp = (mtd->writesize + mtd->oobsize)
<< BCH_FLASHLAYOUT1_PAGE_SIZE_OFFSET;
@@ -1028,6 +1048,7 @@ int mxs_nand_setup_ecc(struct mtd_info *mtd)
tmp |= (geo->gf_len == 14 ? 1 : 0) <<
BCH_FLASHLAYOUT1_GF13_0_GF14_1_OFFSET;
writel(tmp, _regs->hw_bch_flash0layout1);
+   nand_info->bch_flash0layout1 = tmp;
 
/* Set *all* chip selects to use layout 0 */
writel(0, _regs->hw_bch_layoutselect);
@@ -1303,3 +1324,102 @@ err:
free(nand_info);
 }
 #endif
+
+#if CONFIG_IS_ENABLED(MX7)
+/*
+ * Read NAND layout for FCB block generation.
+ */
+void mxs_nand_get_layout(struct mtd_info *mtd, struct mxs_nand_layout *l)
+{
+   struct mxs_bch_regs *bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
+   u32 tmp;
+
+   tmp = readl(_regs->hw_bch_flash0layout0);
+   l->nblocks = (tmp & BCH_FLASHLAYOUT0_NBLOCKS_MASK) >>
+   BCH_FLASHLAYOUT0_NBLOCKS_OFFSET;
+   l->meta_size = (tmp & BCH_FLASHLAYOUT0_META_SIZE_MASK) >>
+   BCH_FLASHLAYOUT0_META_SIZE_OFFSET;
+
+   tmp = readl(_regs->hw_bch_flash0layout1);
+   l->data0_size = 4 * ((tmp & BCH_FLASHLAYOUT0_DATA0_SIZE_MASK) >>
+   BCH_FLASHLAYOUT0_DATA0_SIZE_OFFSET);
+   l->ecc0 = (tmp & BCH_FLASHLAYOUT0_ECC0_MASK) >>
+   BCH_FLASHLAYOUT0_ECC0_OFFSET;
+   l->datan_size = 4 * ((tmp & BCH_FLASHLAYOUT1_DATAN_SIZE_MASK) >>
+   BCH_FLASHLAYOUT1_DATAN_SIZE_OFFSET);
+   l->eccn = (tmp & BCH_FLASHLAYOUT1_ECCN_MASK) >>
+   BCH_FLASHLAYOUT1_ECCN_OFFSET;
+}
+
+/*
+ * Set BCH to specific layout used by ROM bootloader to read FCB.
+ */
+void mxs_nand_mode_fcb(struct mtd_info *mtd)
+{
+   u32 tmp;
+   struct mxs_bch_regs *bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct mxs_nand_info *nand_info = nand_get_controller_data(nand);
+
+   nand_info->en_randomizer = 1;
+
+   mtd->writesize = 1024;
+   mtd->oobsize = 1862 - 1024;
+
+   /* 8 ecc_chunks_*/
+   tmp = 7 << BCH_FLASHLAYOUT0_NBLOCKS_OFFSET;
+   /* 32 bytes for metadata */
+   tmp |= 32 << BCH_FLASHLAYOUT0_META_SIZE_OFFSET;
+   /* using ECC62 level to be performed */
+   tmp |= 0x1F << BCH_FLASHLAYOUT0_ECC0_OFFSET;
+   /* 0x20 * 4 bytes of the data0 block */
+   tmp |= 0x20 << BCH_FLASHLAYOUT0_DATA0_SIZE_OFFSET;
+   tmp |= 0 << BCH_FLASHLAYOUT0_GF13_0_GF14_1_OFFSET;
+   writel(tmp, _regs->hw_bch_flash0layout0);
+
+   /* 1024 for data + 838 for OOB */
+   tmp = 1862 << BCH_FLASHLAYOUT1_PAGE_SIZE_OFFSET;
+   /* using ECC62 level to be performed */
+   tmp |= 0x1F << 

[U-Boot] [RFC PATCH v1 3/5] imx: nandbcb: add support for i.MX7

[Igor Opaniuk]

From: Igor Opaniuk 

Add support for updating FCB/DBBT on i.MX7:
- additional new fields in FCB structure
- Leverage hardware BCH/randomizer for writing FCB

Signed-off-by: Igor Opaniuk 
---

 arch/arm/include/asm/mach-imx/imx-nandbcb.h |  12 ++
 arch/arm/mach-imx/Kconfig   |   2 +-
 arch/arm/mach-imx/Makefile  |   1 +
 arch/arm/mach-imx/cmd_nandbcb.c | 129 +---
 4 files changed, 101 insertions(+), 43 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/imx-nandbcb.h 
b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
index 033659a038..37ebd03a42 100644
--- a/arch/arm/include/asm/mach-imx/imx-nandbcb.h
+++ b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
@@ -106,6 +106,18 @@ struct fcb_block {
 
/* The swap position of main area in spare area */
u32 spare_offset;
+#if CONFIG_IS_ENABLED(MX7)
+   u32 onfi_sync_enable;
+   u32 onfi_sync_speed;
+   u32 onfi_sync_nand_data;
+   u32 reserved2[6];
+   u32 disbbm_search;
+   u32 disbbm_search_limit;
+   u32 reserved3[15];
+   u32 read_retry_enable;
+   u32 reserved4[1];
+   u32 fill_to_1024[183];
+#endif
 };
 
 #endif /* _IMX_NAND_BCB_H_ */
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index d44f74e474..ee01494e97 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -81,7 +81,7 @@ config CMD_HDMIDETECT
 config CMD_NANDBCB
bool "i.MX6 NAND Boot Control Block(BCB) command"
depends on NAND && CMD_MTDPARTS
-   default y if ARCH_MX6 && NAND_MXS
+   default y if (ARCH_MX6 && NAND_MXS) || (ARCH_MX7 && NAND_MXS)
help
  Unlike normal 'nand write/erase' commands, this command update
  Boot Control Block(BCB) for i.MX6 platform NAND IP's.
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 08ee52edbf..2c53f76ff8 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -208,3 +208,4 @@ obj-$(CONFIG_MX7) += mx7/
 obj-$(CONFIG_ARCH_MX7ULP) += mx7ulp/
 obj-$(CONFIG_IMX8M) += imx8m/
 obj-$(CONFIG_ARCH_IMX8) += imx8/
+obj-$(CONFIG_CMD_WRITEBCB_MX7) += cmd_writebcb_mx7.o
diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index 065b814b2e..b7f651568f 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -67,26 +68,36 @@ static void fill_fcb(struct fcb_block *fcb, struct mtd_info 
*mtd)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
struct mxs_nand_info *nand_info = nand_get_controller_data(chip);
+   struct mxs_nand_layout l;
+
+   mxs_nand_get_layout(mtd, );
 
fcb->fingerprint = FCB_FINGERPRINT;
fcb->version = FCB_VERSION_1;
+
fcb->pagesize = mtd->writesize;
fcb->oob_pagesize = mtd->writesize + mtd->oobsize;
fcb->sectors = mtd->erasesize / mtd->writesize;
 
-   /* Divide ECC strength by two and save the value into FCB structure. */
-   fcb->ecc_level = nand_info->bch_geometry.ecc_strength >> 1;
-
-   fcb->ecc_type = fcb->ecc_level;
+   fcb->meta_size = l.meta_size;
+   fcb->nr_blocks = l.nblocks;
+   fcb->ecc_nr = l.data0_size;
+   fcb->ecc_level = l.ecc0;
+   fcb->ecc_size = l.datan_size;
+   fcb->ecc_type = l.eccn;
 
/* Also hardcoded in kobs-ng */
-   fcb->ecc_nr = 0x0200;
-   fcb->ecc_size = 0x0200;
-   fcb->datasetup = 80;
-   fcb->datahold = 60;
-   fcb->addr_setup = 25;
-   fcb->dsample_time = 6;
-   fcb->meta_size = 10;
+   if (is_mx6()) {
+   fcb->datasetup = 80;
+   fcb->datahold = 60;
+   fcb->addr_setup = 25;
+   fcb->dsample_time = 6;
+   } else if (is_mx7()) {
+   fcb->datasetup = 10;
+   fcb->datahold = 7;
+   fcb->addr_setup = 15;
+   fcb->dsample_time = 6;
+   }
 
/* DBBT search area starts at second page on first block */
fcb->dbbt_start = 1;
@@ -98,6 +109,9 @@ static void fill_fcb(struct fcb_block *fcb, struct mtd_info 
*mtd)
 
fcb->nr_blocks = mtd->writesize / fcb->ecc_nr - 1;
 
+   fcb->disbbm = 0;
+   fcb->disbbm_search = 0;
+
fcb->checksum = calc_chksum((void *)fcb + 4, sizeof(*fcb) - 4);
 }
 
@@ -133,6 +147,7 @@ static int nandbcb_update(struct mtd_info *mtd, loff_t off, 
size_t size,
size_t fwsize, dummy;
int i, ret;
 
+   fcb_raw_page = 0;
/* erase */
memset(, 0, sizeof(opts));
opts.offset = off;
@@ -223,45 +238,74 @@ static int nandbcb_update(struct mtd_info *mtd, loff_t 
off, size_t size,
else if (ret > 0)
dbbt->dbbtpages = 1;
 
-   /* write fcb/dbbt */
-   fcb_raw_page = kzalloc(mtd->writesize + mtd->oobsize, GFP_KERNEL);
-   if (!fcb_raw_page) {
-   debug("failed to allocate fcb_raw_page\n");

[U-Boot] [RFC PATCH v1 1/5] imx: gpmi: add defines for hw randominizer

[Igor Opaniuk]

From: Igor Opaniuk 

Extend GPMI Integrated ECC Control Register Description, include
additional defines for enabling randomizer function and providing
proper randomizer type.

For additional details check i.MX7 APR, section
9.6.6.3 GPMI Integrated ECC Control Register Description
(GPMI_ECCCTRLn)

Signed-off-by: Igor Opaniuk 
---

 arch/arm/include/asm/mach-imx/regs-gpmi.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/regs-gpmi.h 
b/arch/arm/include/asm/mach-imx/regs-gpmi.h
index 80cb731724..33daa53c45 100644
--- a/arch/arm/include/asm/mach-imx/regs-gpmi.h
+++ b/arch/arm/include/asm/mach-imx/regs-gpmi.h
@@ -70,6 +70,11 @@ struct mxs_gpmi_regs {
 #defineGPMI_ECCCTRL_ECC_CMD_OFFSET 13
 #defineGPMI_ECCCTRL_ECC_CMD_DECODE (0x0 << 13)
 #defineGPMI_ECCCTRL_ECC_CMD_ENCODE (0x1 << 13)
+#defineGPMI_ECCCTRL_RANDOMIZER_ENABLE  (1 << 11)
+#defineGPMI_ECCCTRL_RANDOMIZER_TYPE0   0
+#defineGPMI_ECCCTRL_RANDOMIZER_TYPE1   (1 << 9)
+#defineGPMI_ECCCTRL_RANDOMIZER_TYPE2   (2 << 9)
+
 #defineGPMI_ECCCTRL_ENABLE_ECC (1 << 12)
 #defineGPMI_ECCCTRL_BUFFER_MASK_MASK   0x1ff
 #defineGPMI_ECCCTRL_BUFFER_MASK_OFFSET 0
-- 
2.17.1

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

[U-Boot] [RFC PATCH v1 0/5] imx: nandbcb: support for i.MX7 and bcb only updates

[Igor Opaniuk]

This introduces support for writing BCB(FCB/FDDT) for i.MX7 and
additional subcommand for writing BCB only (without firmware).

Igor Opaniuk (5):
  imx: gpmi: add defines for hw randominizer
  nand: mxs_nand: add API for switching different BCH layouts
  imx: nandbcb: add support for i.MX7
  imx: nandbcb: refactor update function
  imx: nandbcb: add support for writing BCB only

 arch/arm/include/asm/mach-imx/imx-nandbcb.h |  12 +
 arch/arm/include/asm/mach-imx/regs-gpmi.h   |   5 +
 arch/arm/mach-imx/Kconfig   |   2 +-
 arch/arm/mach-imx/Makefile  |   1 +
 arch/arm/mach-imx/cmd_nandbcb.c | 308 +++-
 drivers/mtd/nand/raw/mxs_nand.c | 120 
 include/mxs_nand.h  |  25 ++
 7 files changed, 397 insertions(+), 76 deletions(-)

-- 
2.17.1

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

[U-Boot] [PATCH] ARM: zynq: dts: Added alias for usb node

[Michal Simek]

From: Vipul Kumar 

This patch added alias for usb node in dts file.

Signed-off-by: Vipul Kumar 
Signed-off-by: Michal Simek 
---

Vipul left Xilinx but he is origin author of this patch that's why I am
keeping him here.
---
 arch/arm/dts/zynq-zc702.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/zynq-zc702.dts b/arch/arm/dts/zynq-zc702.dts
index 54231cd5801a..d10695740fa9 100644
--- a/arch/arm/dts/zynq-zc702.dts
+++ b/arch/arm/dts/zynq-zc702.dts
@@ -16,6 +16,7 @@
serial0 = 
spi0 = 
mmc0 = 
+   usb0 = 
};
 
memory@0 {
-- 
2.17.1

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

[U-Boot] [PATCH] ARM: zynq: Align model name with DT

[Michal Simek]

Use model property to distinguish different configurations.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynq-cse-qspi-single.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/zynq-cse-qspi-single.dts 
b/arch/arm/dts/zynq-cse-qspi-single.dts
index 0d680dfc0688..ac6982a74e25 100644
--- a/arch/arm/dts/zynq-cse-qspi-single.dts
+++ b/arch/arm/dts/zynq-cse-qspi-single.dts
@@ -7,6 +7,10 @@
 
 #include "zynq-cse-qspi.dtsi"
 
+/ {
+   model = "Zynq CSE QSPI SINGLE Board";
+};
+
  {
spi-rx-bus-width = <4>;
 };
-- 
2.17.1

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

Re: [U-Boot] [PATCH] zynqmp: firmware: Add Xilinx ZynqMP firmware driver

[Lokesh Vutla]

On 11/09/19 1:17 PM, Michal Simek wrote:
> From: Rajan Vaja 
> 
> Add simple ZynqMP firmware drive to populate child nodes under
> zynqmp_firmware DT node.
> 
> Signed-off-by: Rajan Vaja 
> Signed-off-by: Michal Simek 

If this driver is only meant for populating child nodes, then simple-bus in
compatible can solve the problem.

Thanks and regards,
Loksh

> ---
> 
>  drivers/clk/Kconfig|  1 +
>  drivers/firmware/Kconfig   | 10 ++
>  drivers/firmware/Makefile  |  1 +
>  drivers/firmware/firmware-zynqmp.c | 15 +++
>  4 files changed, 27 insertions(+)
>  create mode 100644 drivers/firmware/firmware-zynqmp.c
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 95fe0aea2ce8..305cbd96f165 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -113,6 +113,7 @@ config CLK_ZYNQ
>  config CLK_ZYNQMP
>   bool "Enable clock driver support for ZynqMP"
>   depends on ARCH_ZYNQMP
> + select ZYNQMP_FIRMWARE
>   help
> This clock driver adds support for clock realted settings for
> ZynqMP platform.
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 873bc8c79679..b70a2063551c 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -26,3 +26,13 @@ config TI_SCI_PROTOCOL
>  
> This protocol library is used by client drivers to use the features
> provided by the system controller.
> +
> +config ZYNQMP_FIRMWARE
> + bool "ZynqMP Firmware interface"
> + select FIRMWARE
> + help
> +   Firmware interface driver is used by different
> +   drivers to communicate with the firmware for
> +   various platform management services.
> +   Say yes to enable ZynqMP firmware interface driver.
> +   If in doubt, say N.
> diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
> index 6c3e12968527..a0c250a473eb 100644
> --- a/drivers/firmware/Makefile
> +++ b/drivers/firmware/Makefile
> @@ -2,3 +2,4 @@ obj-$(CONFIG_FIRMWARE)+= firmware-uclass.o
>  obj-$(CONFIG_$(SPL_)ARM_PSCI_FW) += psci.o
>  obj-$(CONFIG_TI_SCI_PROTOCOL)+= ti_sci.o
>  obj-$(CONFIG_SANDBOX)+= firmware-sandbox.o
> +obj-$(CONFIG_ZYNQMP_FIRMWARE)+= firmware-zynqmp.o
> diff --git a/drivers/firmware/firmware-zynqmp.c 
> b/drivers/firmware/firmware-zynqmp.c
> new file mode 100644
> index ..b36eda1b04be
> --- /dev/null
> +++ b/drivers/firmware/firmware-zynqmp.c
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include 
> +
> +static const struct udevice_id zynqmp_firmware_ids[] = {
> + { .compatible = "xlnx,zynqmp-firmware" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(zynqmp_firmware) = {
> + .id = UCLASS_FIRMWARE,
> + .name = "zynqmp-firmware",
> + .probe = dm_scan_fdt_dev,
> + .of_match = zynqmp_firmware_ids,
> +};
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot