[U-Boot] [PATCH 4/4] test/py: test_fs: add tests for creating/deleting many files

2019-05-12 Thread AKASHI Takahiro
Two test cases are added under test_fs_ext:
test case 10: for root directory
test case 11: for non-root directory

Those will verify a behavior fixed by the commits related to
root directory
("fs: fat: allocate a new cluster for root directory of fat32" and
"fs: fat: flush a directory cluster properly").

Signed-off-by: AKASHI Takahiro 
---
 test/py/tests/test_fs/test_ext.py | 84 +++
 1 file changed, 84 insertions(+)

diff --git a/test/py/tests/test_fs/test_ext.py 
b/test/py/tests/test_fs/test_ext.py
index 2c47738b8df2..361f440dd6d4 100644
--- a/test/py/tests/test_fs/test_ext.py
+++ b/test/py/tests/test_fs/test_ext.py
@@ -233,3 +233,87 @@ class TestFsExt(object):
 % (fs_type, ADDR, MIN_FILE)])
 assert('Unable to write "/dir1' in ''.join(output))
 assert_fs_integrity(fs_type, fs_img)
+
+def test_fs_ext10(self, u_boot_console, fs_obj_ext):
+"""
+'Test Case 10 - create/delete as many directories under root directory
+as amount of directory entries goes beyond one cluster size)'
+"""
+fs_type,fs_img,md5val = fs_obj_ext
+with u_boot_console.log.section('Test Case 10 - create/delete (many)'):
+# Test Case 10a - Create many files
+#   Please note that the size of directory entry is 32 bytes.
+#   So one typical cluster may holds 64 (2048/32) entries.
+output = u_boot_console.run_command(
+'host bind 0 %s' % fs_img)
+
+for i in range(0, 66):
+output = u_boot_console.run_command(
+'%swrite host 0:0 %x /FILE0123456789_%02x 100'
+% (fs_type, ADDR, i))
+output = u_boot_console.run_command('%sls host 0:0 /' % fs_type)
+assert('FILE0123456789_00' in output)
+assert('FILE0123456789_41' in output)
+
+# Test Case 10b - Delete many files
+for i in range(0, 66):
+output = u_boot_console.run_command(
+'%srm host 0:0 /FILE0123456789_%02x'
+% (fs_type, i))
+output = u_boot_console.run_command('%sls host 0:0 /' % fs_type)
+assert(not 'FILE0123456789_00' in output)
+assert(not 'FILE0123456789_41' in output)
+
+# Test Case 10c - Create many files again
+# Please note no.64 and 65 are intentionally re-created
+for i in range(64, 128):
+output = u_boot_console.run_command(
+'%swrite host 0:0 %x /FILE0123456789_%02x 100'
+% (fs_type, ADDR, i))
+output = u_boot_console.run_command('%sls host 0:0 /' % fs_type)
+assert('FILE0123456789_40' in output)
+assert('FILE0123456789_79' in output)
+
+assert_fs_integrity(fs_type, fs_img)
+
+def test_fs_ext11(self, u_boot_console, fs_obj_ext):
+"""
+'Test Case 11 - create/delete as many directories under non-root
+directory as amount of directory entries goes beyond one cluster size)'
+"""
+fs_type,fs_img,md5val = fs_obj_ext
+with u_boot_console.log.section('Test Case 10 - create/delete (many)'):
+# Test Case 11a - Create many files
+#   Please note that the size of directory entry is 32 bytes.
+#   So one typical cluster may holds 64 (2048/32) entries.
+output = u_boot_console.run_command(
+'host bind 0 %s' % fs_img)
+
+for i in range(0, 66):
+output = u_boot_console.run_command(
+'%swrite host 0:0 %x /dir1/FILE0123456789_%02x 100'
+% (fs_type, ADDR, i))
+output = u_boot_console.run_command('%sls host 0:0 /dir1' % 
fs_type)
+assert('FILE0123456789_00' in output)
+assert('FILE0123456789_41' in output)
+
+# Test Case 11b - Delete many files
+for i in range(0, 66):
+output = u_boot_console.run_command(
+'%srm host 0:0 /dir1/FILE0123456789_%02x'
+% (fs_type, i))
+output = u_boot_console.run_command('%sls host 0:0 /dir1' % 
fs_type)
+assert(not 'FILE0123456789_00' in output)
+assert(not 'FILE0123456789_41' in output)
+
+# Test Case 11c - Create many files again
+# Please note no.64 and 65 are intentionally re-created
+for i in range(64, 128):
+output = u_boot_console.run_command(
+'%swrite host 0:0 %x /dir1/FILE0123456789_%02x 100'
+% (fs_type, ADDR, i))
+output = u_boot_console.run_command('%sls host 0:0 /dir1' % 
fs_type)
+assert('FILE0123456789_40' in output)
+assert('FILE0123456789_79' in output)
+
+assert_fs_integrity(fs_type, fs_img)
-- 
2.21.0


[U-Boot] [PATCH 0/4] fs: fat: fixes for write under root directory

2019-05-12 Thread AKASHI Takahiro
This patch set contains three (independent) bug fixes relating to
write operations to root directory. See each commit message
for more details.

Without those fixes, you may lose files that you created under root
directory or will see the file system corrupted. This will happen
particularly when you create (or even delete) many files repeatedly
under root directory.
(Non-root directory won't be affected.)

I only tested my patches on limited number of file system instances,
and hope that other people will also try them.

-Takahiro Akashi

AKASHI Takahiro (4):
  fs: fat:  write to non-cluster-aligned root directory
  fs: fat: flush a directory cluster properly
  fs: fat: allocate a new cluster for root directory of fat32
  test/py: test_fs: add tests for creating/deleting many files

 fs/fat/fat.c  |  15 ++--
 fs/fat/fat_write.c| 117 +++---
 test/py/tests/test_fs/test_ext.py |  84 +
 3 files changed, 165 insertions(+), 51 deletions(-)

-- 
2.21.0

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


[U-Boot] [PATCH 1/4] fs: fat: write to non-cluster-aligned root directory

2019-05-12 Thread AKASHI Takahiro
With the commit below, fat now correctly handles a file read under
a non-cluster-aligned root directory of fat12/16.
Write operation should be fixed in the same manner.

Fixes: commit 9b18358dc05d ("fs: fat: fix reading non-cluster-aligned
   root directory")
Signed-off-by: AKASHI Takahiro 
Cc: Anssi Hannula 
---
 fs/fat/fat.c   | 15 -
 fs/fat/fat_write.c | 78 +++---
 2 files changed, 61 insertions(+), 32 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index c5997c21735f..fccaa385d187 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -619,13 +619,14 @@ static int get_fs_info(fsdata *mydata)
return -1;
}
 
-   debug("FAT%d, fat_sect: %d, fatlength: %d\n",
-  mydata->fatsize, mydata->fat_sect, mydata->fatlength);
-   debug("Rootdir begins at cluster: %d, sector: %d, offset: %x\n"
-  "Data begins at: %d\n",
-  mydata->root_cluster,
-  mydata->rootdir_sect,
-  mydata->rootdir_sect * mydata->sect_size, mydata->data_begin);
+   debug("FAT%d, fat_sect: %d, fatlength: %d, num: %d\n",
+ mydata->fatsize, mydata->fat_sect, mydata->fatlength,
+ mydata->fats);
+   debug("Rootdir begins at cluster: %d, sector: %d, size: %x\n"
+ "Data begins at: %d\n",
+ mydata->root_cluster,
+ mydata->rootdir_sect,
+ mydata->rootdir_size * mydata->sect_size, mydata->data_begin);
debug("Sector size: %d, cluster size: %d\n", mydata->sect_size,
  mydata->clust_size);
 
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 852f874e5817..3bc0dd637521 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -388,29 +388,23 @@ static __u32 determine_fatent(fsdata *mydata, __u32 entry)
 }
 
 /**
- * set_cluster() - write data to cluster
+ * set_sectors() - write data to sectors
  *
- * Write 'size' bytes from 'buffer' into the specified cluster.
+ * Write 'size' bytes from 'buffer' into the specified sector.
  *
  * @mydata:data to be written
- * @clustnum:  cluster to be written to
+ * @startsect: sector to be written to
  * @buffer:data to be written
  * @size:  bytes to be written (but not more than the size of a cluster)
  * Return: 0 on success, -1 otherwise
  */
 static int
-set_cluster(fsdata *mydata, u32 clustnum, u8 *buffer, u32 size)
+set_sectors(fsdata *mydata, u32 startsect, u8 *buffer, u32 size)
 {
-   u32 idx = 0;
-   u32 startsect;
+   u32 nsects = 0;
int ret;
 
-   if (clustnum > 0)
-   startsect = clust_to_sect(mydata, clustnum);
-   else
-   startsect = mydata->rootdir_sect;
-
-   debug("clustnum: %d, startsect: %d\n", clustnum, startsect);
+   debug("startsect: %d\n", startsect);
 
if ((unsigned long)buffer & (ARCH_DMA_MINALIGN - 1)) {
ALLOC_CACHE_ALIGN_BUFFER(__u8, tmpbuf, mydata->sect_size);
@@ -429,17 +423,16 @@ set_cluster(fsdata *mydata, u32 clustnum, u8 *buffer, u32 
size)
size -= mydata->sect_size;
}
} else if (size >= mydata->sect_size) {
-   idx = size / mydata->sect_size;
-   ret = disk_write(startsect, idx, buffer);
-   if (ret != idx) {
+   nsects = size / mydata->sect_size;
+   ret = disk_write(startsect, nsects, buffer);
+   if (ret != nsects) {
debug("Error writing data (got %d)\n", ret);
return -1;
}
 
-   startsect += idx;
-   idx *= mydata->sect_size;
-   buffer += idx;
-   size -= idx;
+   startsect += nsects;
+   buffer += nsects * mydata->sect_size;
+   size -= nsects * mydata->sect_size;
}
 
if (size) {
@@ -457,6 +450,44 @@ set_cluster(fsdata *mydata, u32 clustnum, u8 *buffer, u32 
size)
return 0;
 }
 
+/**
+ * set_cluster() - write data to cluster
+ *
+ * Write 'size' bytes from 'buffer' into the specified cluster.
+ *
+ * @mydata:data to be written
+ * @clustnum:  cluster to be written to
+ * @buffer:data to be written
+ * @size:  bytes to be written (but not more than the size of a cluster)
+ * Return: 0 on success, -1 otherwise
+ */
+static int
+set_cluster(fsdata *mydata, u32 clustnum, u8 *buffer, u32 size)
+{
+   return set_sectors(mydata, clust_to_sect(mydata, clustnum),
+  buffer, size);
+}
+
+static int
+flush_dir(fat_itr *itr)
+{
+   fsdata *mydata = itr->fsdata;
+   u32 startsect, sect_offset, nsects;
+
+   if (!itr->is_root || mydata->fatsize == 32)
+   return set_cluster(mydata, itr->clust, itr->block,
+  mydata->clust_size * mydata->sect_size);
+
+   sect_offset = itr->clust * mydata->clust_size;
+   startsect = mydata->rootdir_sect + 

[U-Boot] [PATCH 2/4] fs: fat: flush a directory cluster properly

2019-05-12 Thread AKASHI Takahiro
When a long name directory entry is created, multiple directory entries
may be occupied across a directory cluster boundary. Since only one
directory cluster is cached in a directory iterator, a first cluster must
be written back to device before switching over a second cluster.

Without this patch, some added files may be lost even if you don't see
any failures on write operation.

Signed-off-by: AKASHI Takahiro 
---
 fs/fat/fat_write.c | 33 ++---
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 3bc0dd637521..da1753d545ac 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -209,7 +209,8 @@ name11_12:
return 1;
 }
 
-static int flush_dir_table(fat_itr *itr);
+static int new_dir_table(fat_itr *itr);
+static int flush_dir(fat_itr *itr);
 
 /*
  * Fill dir_slot entries with appropriate name, id, and attr
@@ -242,19 +243,15 @@ fill_dir_slot(fat_itr *itr, const char *l_name)
memcpy(itr->dent, slotptr, sizeof(dir_slot));
slotptr--;
counter--;
+
+   if (itr->remaining == 0)
+   flush_dir(itr);
+
if (!fat_itr_next(itr))
-   if (!itr->dent && !itr->is_root && flush_dir_table(itr))
+   if (!itr->dent && !itr->is_root && new_dir_table(itr))
return -1;
}
 
-   if (!itr->dent && !itr->is_root)
-   /*
-* don't care return value here because we have already
-* finished completing an entry with name, only ending up
-* no more entry left
-*/
-   flush_dir_table(itr);
-
return 0;
 }
 
@@ -621,18 +618,14 @@ static int find_empty_cluster(fsdata *mydata)
 }
 
 /*
- * Write directory entries in itr's buffer to block device
+ * Allocate a cluster for additional directory entries
  */
-static int flush_dir_table(fat_itr *itr)
+static int new_dir_table(fat_itr *itr)
 {
fsdata *mydata = itr->fsdata;
int dir_newclust = 0;
unsigned int bytesperclust = mydata->clust_size * mydata->sect_size;
 
-   if (set_cluster(mydata, itr->clust, itr->block, bytesperclust) != 0) {
-   printf("error: writing directory entry\n");
-   return -1;
-   }
dir_newclust = find_empty_cluster(mydata);
set_fatent_value(mydata, itr->clust, dir_newclust);
if (mydata->fatsize == 32)
@@ -987,7 +980,7 @@ static dir_entry *find_directory_entry(fat_itr *itr, char 
*filename)
return itr->dent;
}
 
-   if (!itr->dent && !itr->is_root && flush_dir_table(itr))
+   if (!itr->dent && !itr->is_root && new_dir_table(itr))
/* indicate that allocating dent failed */
itr->dent = NULL;
 
@@ -1172,14 +1165,16 @@ int file_fat_write_at(const char *filename, loff_t pos, 
void *buffer,
 
memset(itr->dent, 0, sizeof(*itr->dent));
 
-   /* Set short name to set alias checksum field in dir_slot */
+   /* Calculate checksum for short name */
set_name(itr->dent, filename);
+
+   /* Set long name entries */
if (fill_dir_slot(itr, filename)) {
ret = -EIO;
goto exit;
}
 
-   /* Set attribute as archive for regular file */
+   /* Set short name entry */
fill_dentry(itr->fsdata, itr->dent, filename, 0, size, 0x20);
 
retdent = itr->dent;
-- 
2.21.0

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


[U-Boot] [PATCH 3/4] fs: fat: allocate a new cluster for root directory of fat32

2019-05-12 Thread AKASHI Takahiro
Contrary to fat12/16, fat32 can have root directory at any location
and its size can be expanded.
Without this patch, root directory won't grow properly and so we will
eventually fail to add files under root directory. Please note that this
can happen even if you delete many files as deleted directory entries
are not reclaimed but just marked as "deleted" under the current
implementation.

Signed-off-by: AKASHI Takahiro 
---
 fs/fat/fat_write.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index da1753d545ac..3bb9eac097eb 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -247,8 +247,11 @@ fill_dir_slot(fat_itr *itr, const char *l_name)
if (itr->remaining == 0)
flush_dir(itr);
 
+   /* allocate a cluster for more entries */
if (!fat_itr_next(itr))
-   if (!itr->dent && !itr->is_root && new_dir_table(itr))
+   if (!itr->dent &&
+   (!itr->is_root || itr->fsdata->fatsize == 32) &&
+   new_dir_table(itr))
return -1;
}
 
@@ -980,7 +983,10 @@ static dir_entry *find_directory_entry(fat_itr *itr, char 
*filename)
return itr->dent;
}
 
-   if (!itr->dent && !itr->is_root && new_dir_table(itr))
+   /* allocate a cluster for more entries */
+   if (!itr->dent &&
+   (!itr->is_root || itr->fsdata->fatsize == 32) &&
+   new_dir_table(itr))
/* indicate that allocating dent failed */
itr->dent = NULL;
 
-- 
2.21.0

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


Re: [U-Boot] [PATCH v2 2/5] spi: add spi-mem driver for MediaTek MT7629 SoC

2019-05-12 Thread Weijie Gao
On Tue, 2019-05-07 at 18:42 +0530, Jagan Teki wrote:
> On Sun, May 5, 2019 at 2:59 PM Weijie Gao  wrote:
> >
> > This patch adds spi-mem driver for MediaTek MT7629 SoC to access SPI-NOR
> > and SPI-NAND flashes.
> >
> > Cc: Jagan Teki 
> > Signed-off-by: Weijie Gao 
> > ---
> > Changes since v1: rename mtk_spimem to spi_snfi_spi. change pinctrl name.
> > ---
> >  drivers/spi/Kconfig|   9 +
> >  drivers/spi/Makefile   |   1 +
> >  drivers/spi/mtk_snfi_spi.c | 325 +
> >  3 files changed, 335 insertions(+)
> >  create mode 100644 drivers/spi/mtk_snfi_spi.c
> >
> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > index 92d7ca6d8cb..a3feca97f59 100644
> > --- a/drivers/spi/Kconfig
> > +++ b/drivers/spi/Kconfig
> > @@ -139,6 +139,15 @@ config MT7621_SPI
> >   the SPI NOR flash on platforms embedding this Ralink / MediaTek
> >   SPI core, like MT7621/7628/7688.
> >
> > +config MTK_SNFI_SPI
> > +   bool "Mediatek SPI memory controller driver"
> > +   depends on SPI_MEM
> > +   help
> > + Enable the Mediatek SPI memory controller driver. This driver is
> > + originally based on the MediaTek SNFI IP core. It can only be
> > + used to access SPI memory devices like SPI-NOR or SPI-NAND on
> > + platforms embedding this IP core, like MT7622/M7629.
> > +
> >  config MVEBU_A3700_SPI
> > bool "Marvell Armada 3700 SPI driver"
> > select CLK_ARMADA_3720
> > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> > index f1e3becd2b7..5c639634777 100644
> > --- a/drivers/spi/Makefile
> > +++ b/drivers/spi/Makefile
> > @@ -36,6 +36,7 @@ obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
> >  obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
> >  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
> >  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
> > +obj-$(CONFIG_MTK_SNFI_SPI) += mtk_snfi_spi.o
> >  obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
> >  obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o
> >  obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
> > diff --git a/drivers/spi/mtk_snfi_spi.c b/drivers/spi/mtk_snfi_spi.c
> > new file mode 100644
> > index 000..230b7243d6f
> > --- /dev/null
> > +++ b/drivers/spi/mtk_snfi_spi.c
> > @@ -0,0 +1,325 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2019 MediaTek Inc. All Rights Reserved.
> > + *
> > + * Author: Weijie Gao 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define SNFI_MAC_CTL   0x500
> > +#define MAC_XIO_SELBIT(4)
> > +#define SF_MAC_EN  BIT(3)
> > +#define SF_TRIGBIT(2)
> > +#define WIP_READY  BIT(1)
> > +#define WIPBIT(0)
> > +
> > +#define SNFI_MAC_OUTL  0x504
> > +#define SNFI_MAC_INL   0x508
> > +
> > +#define SNFI_MISC_CTL  0x538
> > +#define SW_RST BIT(28)
> > +#define FIFO_RD_LTC_SHIFT  25
> > +#define FIFO_RD_LTCGENMASK(26, 25)
> > +#define LATCH_LAT_SHIFT8
> > +#define LATCH_LAT  GENMASK(9, 8)
> > +#define CS_DESELECT_CYC_SHIFT  0
> > +#define CS_DESELECT_CYCGENMASK(4, 0)
> > +
> > +#define SNF_STA_CTL1   0x550
> > +#define SPI_STATE  GENMASK(3, 0)
> > +
> > +#define SNFI_GPRAM_OFFSET  0x800
> > +#define SNFI_GPRAM_SIZE0x80
> > +
> > +#define SNFI_POLL_INTERVAL 50
> > +#define SNFI_RST_POLL_INTERVAL 100
> > +
> > +struct mtk_snfi_priv {
> > +   void __iomem *base;
> > +
> > +   struct udevice *dev;
> 
> Do we really need this dev? seems like you are passing priv and get
> the dev, why can't you pass the dev directly?
> 
> Look like it is not possible since the spi_mem ops not using udevice,
> did you observed this?

The dev in the priv struct is a mistake. It will be removed.

spi_mem_ops is only a subset of dm_spi_ops, which means there must be a
spi udevice for the spi slave device. I've checked source codes for both
spi-uclass.c, sf-uclass.c, sf_probe.c and spi-nor-core.c and I'm sure
udevice is available by referencing from spi_slave.

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


[U-Boot] [RESEND][PATCH v2] armv8: Add workaround for USB erratum A-050106

2019-05-12 Thread Ran Wang
USB3.0 Receiver needs to enable fixed equalization
for each of PHY instances in an SOC. This is similar
to erratum A-009007, but this one is for LX2160A,
and the register value is different.

Signed-off-by: Ran Wang 
---
Change in v2:
- Move function erratum_a050106() under the scope of
  CONFIG_FSL_LSCH3 to avoid compilation warning of
  'defined but not used'.

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  4 
 arch/arm/cpu/armv8/fsl-layerscape/soc.c| 13 -
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h |  5 +
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index f48481f..f99b9d1 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -191,6 +191,7 @@ config ARCH_LX2160A
select SYS_FSL_DDR_VER_50
select SYS_FSL_EC1
select SYS_FSL_EC2
+   select SYS_FSL_ERRATUM_A050106
select SYS_FSL_HAS_RGMII
select SYS_FSL_HAS_SEC
select SYS_FSL_HAS_CCN508
@@ -335,6 +336,9 @@ config SYS_FSL_ERRATUM_A009008
 config SYS_FSL_ERRATUM_A009798
bool "Workaround for USB PHY erratum A009798"
 
+config SYS_FSL_ERRATUM_A050106
+   bool "Workaround for USB PHY erratum A050106"
+
 config SYS_FSL_ERRATUM_A010315
bool "Workaround for PCIe erratum A010315"
 
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 06f3edb..ab5c408 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -139,7 +139,8 @@ static void erratum_a008997(void)
out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, USB_PHY_RX_EQ_VAL_3);  
\
out_be16((phy) + SCFG_USB_PHY_RX_OVRD_IN_HI, USB_PHY_RX_EQ_VAL_4)
 
-#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A)
+#elif defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A) || \
+   defined(CONFIG_ARCH_LX2160A)
 
 #define PROGRAM_USB_PHY_RX_OVRD_IN_HI(phy) \
out_le16((phy) + DCSR_USB_PHY_RX_OVRD_IN_HI, USB_PHY_RX_EQ_VAL_1); \
@@ -172,6 +173,15 @@ static void erratum_a009007(void)
 }
 
 #if defined(CONFIG_FSL_LSCH3)
+static void erratum_a050106(void)
+{
+#if defined(CONFIG_ARCH_LX2160A)
+   void __iomem *dcsr = (void __iomem *)DCSR_BASE;
+
+   PROGRAM_USB_PHY_RX_OVRD_IN_HI(dcsr + DCSR_USB_PHY1);
+   PROGRAM_USB_PHY_RX_OVRD_IN_HI(dcsr + DCSR_USB_PHY2);
+#endif
+}
 /*
  * This erratum requires setting a value to eddrtqcr1 to
  * optimal the DDR performance.
@@ -323,6 +333,7 @@ void fsl_lsch3_early_init_f(void)
erratum_a009798();
erratum_a008997();
erratum_a009007();
+   erratum_a050106();
 #ifdef CONFIG_CHAIN_OF_TRUST
/* In case of Secure Boot, the IBR configures the SMMU
* to allow only Secure transactions.
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 9fab88a..5727656 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -209,8 +209,13 @@
 #define DCSR_USB_PHY_RX_OVRD_IN_HI 0x200C
 #define USB_PHY_RX_EQ_VAL_10x
 #define USB_PHY_RX_EQ_VAL_20x0080
+#if defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LS1088A)
 #define USB_PHY_RX_EQ_VAL_30x0380
 #define USB_PHY_RX_EQ_VAL_40x0b80
+#elif defined(CONFIG_ARCH_LX2160A)
+#define USB_PHY_RX_EQ_VAL_30x0080
+#define USB_PHY_RX_EQ_VAL_40x0880
+#endif
 
 #define TP_ITYP_AV 0x0001  /* Initiator available */
 #define TP_ITYP_TYPE(x)(((x) & 0x6) >> 1)  /* Initiator Type */
-- 
2.7.4

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


Re: [U-Boot] [PATCH v2] include: android_bl_msg.h: Initial import

2019-05-12 Thread AKASHI Takahiro
On Fri, May 10, 2019 at 04:12:10PM +0300, Sam Protsenko wrote:
> From: Eugeniu Rosca 
> 
> Import the bootloader_message.h (former bootloader.h) from AOSP.
> 
> The bootloader_message.h basically defines the flash layout of a
> dedicated partition (usually called 'misc') and is needed in U-Boot
> in order to be able to implement a subset of Android Bootloader
> Requirements [1], specifically dealing with:
>  - Communication between the bootloader and recovery
>  - Handling of A/B (Seamless) System Updates [2]
>  - Passing the reboot reason [3]
> 
> With respect to the in-tree vs out-of-tree file differences:
>  - license matches https://patchwork.ozlabs.org/patch/1003998/
>  - filename is changed to android_bl_msg.h, as per Simon's comment [4]
>  - minimize the future integration/update efforts from the source.
>Particularly, the __UBOOT__ macro helps with isolating the
>U-Boot-unrelated parts (e.g. includes/function prototypes/etc)
> 
> [1] https://source.android.com/devices/bootloader
> [2] https://source.android.com/devices/tech/ota/ab/
> [3] https://source.android.com/devices/bootloader/boot-reason
> [4] https://patchwork.ozlabs.org/patch/1003998/#2046141
> 
> Signed-off-by: Eugeniu Rosca 
> Signed-off-by: Sam Protsenko 
> ---
> Changes in v2:
>  * Remove struct typedefs, as it breaks Linux kernel style outside of
>this file, it bloats namespace (old struct names still remain in the
>namespace) and increases the delta w.r.t. AOSP file version
>  * Add specific AOSP commit-id where this file was imported from
>(as per Tom's comment)
>  * Update this file to the most recent version from AOSP
> 
>  include/android_bl_msg.h | 264 +++
>  1 file changed, 264 insertions(+)
>  create mode 100644 include/android_bl_msg.h
> 
> diff --git a/include/android_bl_msg.h b/include/android_bl_msg.h
> new file mode 100644
> index 00..7bb69ef431
> --- /dev/null
> +++ b/include/android_bl_msg.h
> @@ -0,0 +1,264 @@
> +// SPDX-License-Identifier: BSD-2-Clause
> +/*
> + * This file was taken from the AOSP Project.
> + * Repository: https://android.googlesource.com/platform/bootable/recovery/
> + * File: bootloader_message/include/bootloader_message/bootloader_message.h
> + * Commit: 9423d2f6b7ef ("Merge "Track libziparchive API change."")
> + *
> + * Please keep this file with minimal changes with respect to AOSP version!
> + *
> + * Copyright (C) 2008 The Android Open Source Project
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");

Which license, BSD-2 (in SPDX) or Apache v2, is applied to this file?
If the latter, it is said incompatible with GPLv2, isn't it?

-Takahiro Akashi

> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +#ifndef _BOOTLOADER_MESSAGE_H
> +#define _BOOTLOADER_MESSAGE_H
> +
> +#ifndef __UBOOT__
> +#include 
> +#include 
> +#include 
> +#else
> +#include 
> +#endif
> +
> +// Spaces used by misc partition are as below:
> +// 0   - 2K For bootloader_message
> +// 2K  - 16KUsed by Vendor's bootloader (the 2K - 4K range may be 
> optionally used
> +//  as bootloader_message_ab struct)
> +// 16K - 64KUsed by uncrypt and recovery to store wipe_package for A/B 
> devices
> +// Note that these offsets are admitted by bootloader,recovery and uncrypt, 
> so they
> +// are not configurable without changing all of them.
> +static const size_t BOOTLOADER_MESSAGE_OFFSET_IN_MISC = 0;
> +static const size_t WIPE_PACKAGE_OFFSET_IN_MISC = 16 * 1024;
> +
> +/* Bootloader Message (2-KiB)
> + *
> + * This structure describes the content of a block in flash
> + * that is used for recovery and the bootloader to talk to
> + * each other.
> + *
> + * The command field is updated by linux when it wants to
> + * reboot into recovery or to update radio or bootloader firmware.
> + * It is also updated by the bootloader when firmware update
> + * is complete (to boot into recovery for any final cleanup)
> + *
> + * The status field was used by the bootloader after the completion
> + * of an "update-radio" or "update-hboot" command, which has been
> + * deprecated since Froyo.
> + *
> + * The recovery field is only written by linux and used
> + * for the system to send a message to recovery or the
> + * other way around.
> + *
> + * The stage field is written by packages which restart themselves
> + * multiple times, so that the UI can reflect which invocation of the
> + * package it is.  If the value is of the format "#/#" (eg, "1/3"),
> + * the UI 

[U-Boot] [PATCH 2/2] watchdog: imx: Add DM support

2019-05-12 Thread Marek Vasut
Add DM and DT probing support to iMX watchdog driver. This should
allow boards to move over to this driver, enable SYSRESET_WATCHDOG
to handle cpu_reset() if required.

Signed-off-by: Marek Vasut 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 drivers/watchdog/Kconfig|   2 +-
 drivers/watchdog/imx_watchdog.c | 119 +++-
 2 files changed, 104 insertions(+), 17 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f909d40f45..b2ebe528ab 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -129,7 +129,7 @@ config XILINX_TB_WATCHDOG
 
 config IMX_WATCHDOG
bool "Enable Watchdog Timer support for IMX and LSCH2 of NXP"
-   select HW_WATCHDOG
+   select HW_WATCHDOG if !WDT
help
   Select this to enable the IMX and LSCH2 of Layerscape watchdog
   driver.
diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c
index 14cc618074..53a3e9f5c7 100644
--- a/drivers/watchdog/imx_watchdog.c
+++ b/drivers/watchdog/imx_watchdog.c
@@ -5,7 +5,9 @@
  */
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #ifdef CONFIG_FSL_LSCH2
@@ -13,20 +15,40 @@
 #endif
 #include 
 
-#ifdef CONFIG_IMX_WATCHDOG
-void hw_watchdog_reset(void)
+static void imx_watchdog_expire_now(struct watchdog_regs *wdog)
+{
+   clrsetbits_le16(>wcr, WCR_WT_MSK, WCR_WDE);
+
+   writew(0x, >wsr);
+   writew(0x, >wsr); /* load minimum 1/2 second timeout */
+   while (1) {
+   /*
+* spin for .5 seconds before reset
+*/
+   }
+}
+
+#if !defined(CONFIG_IMX_WATCHDOG) || \
+(defined(CONFIG_IMX_WATCHDOG) && !CONFIG_IS_ENABLED(WDT))
+void __attribute__((weak)) reset_cpu(ulong addr)
 {
-#ifndef CONFIG_WATCHDOG_RESET_DISABLE
struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
 
+   imx_watchdog_expire_now(wdog);
+}
+#endif
+
+#if defined(CONFIG_IMX_WATCHDOG)
+static void imx_watchdog_reset(struct watchdog_regs *wdog)
+{
+#ifndef CONFIG_WATCHDOG_RESET_DISABLE
writew(0x, >wsr);
writew(0x, >wsr);
 #endif /* CONFIG_WATCHDOG_RESET_DISABLE*/
 }
 
-void hw_watchdog_init(void)
+static void imx_watchdog_init(struct watchdog_regs *wdog)
 {
-   struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
u16 timeout;
 
/*
@@ -44,21 +66,86 @@ void hw_watchdog_init(void)
writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS |
WCR_WDA | SET_WCR_WT(timeout), >wcr);
 #endif /* CONFIG_FSL_LSCH2*/
-   hw_watchdog_reset();
+   imx_watchdog_reset(wdog);
 }
-#endif
 
-void __attribute__((weak)) reset_cpu(ulong addr)
+#if !CONFIG_IS_ENABLED(WDT)
+void hw_watchdog_reset(void)
 {
struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
 
-   clrsetbits_le16(>wcr, WCR_WT_MSK, WCR_WDE);
+   imx_watchdog_reset(wdog);
+}
 
-   writew(0x, >wsr);
-   writew(0x, >wsr); /* load minimum 1/2 second timeout */
-   while (1) {
-   /*
-* spin for .5 seconds before reset
-*/
-   }
+void hw_watchdog_init(void)
+{
+   struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
+
+   imx_watchdog_init(wdog);
+}
+#else
+struct imx_wdt_priv {
+   void __iomem *base;
+};
+
+static int imx_wdt_reset(struct udevice *dev)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+
+   imx_watchdog_reset(priv->base);
+
+   return 0;
+}
+
+static int imx_wdt_expire_now(struct udevice *dev, ulong flags)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+
+   imx_watchdog_expire_now(priv->base);
+   hang();
+
+   return 0;
+}
+
+static int imx_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+
+   imx_watchdog_init(priv->base);
+
+   return 0;
+}
+
+static int imx_wdt_probe(struct udevice *dev)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+
+   priv->base = dev_read_addr_ptr(dev);
+   if (!priv->base)
+   return -ENOENT;
+
+   return 0;
 }
+
+static const struct wdt_ops imx_wdt_ops = {
+   .start  = imx_wdt_start,
+   .reset  = imx_wdt_reset,
+   .expire_now = imx_wdt_expire_now,
+};
+
+static const struct udevice_id imx_wdt_ids[] = {
+   { .compatible = "fsl,imx21-wdt" },
+   {}
+};
+
+U_BOOT_DRIVER(imx_wdt) = {
+   .name   = "imx_wdt",
+   .id = UCLASS_WDT,
+   .of_match   = imx_wdt_ids,
+   .probe  = imx_wdt_probe,
+   .ops= _wdt_ops,
+   .priv_auto_alloc_size = sizeof(struct imx_wdt_priv),
+   .flags  = DM_FLAG_PRE_RELOC,
+};
+#endif
+#endif
-- 
2.20.1

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


[U-Boot] [PATCH 1/2] watchdog: Split WDT from SPL_WDT

2019-05-12 Thread Marek Vasut
Use CONFIG_IS_ENABLED(WDT) to permit use of WDT in SPL without DM,
while the full U-Boot can use rich DM/DT WDT driver.

Signed-off-by: Marek Vasut 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 common/board_r.c  | 2 +-
 common/spl/spl.c  | 2 +-
 drivers/watchdog/Makefile | 2 +-
 include/asm-generic/global_data.h | 2 +-
 include/wdt.h | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/common/board_r.c b/common/board_r.c
index 150e8cd424..988e40abb2 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -678,7 +678,7 @@ static init_fnc_t init_sequence_r[] = {
 #ifdef CONFIG_DM
initr_dm,
 #endif
-#if defined(CONFIG_WDT)
+#if CONFIG_IS_ENABLED(WDT)
initr_watchdog,
 #endif
 #if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV) || \
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 0a6a47c202..f22f854718 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -601,7 +601,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_board_init();
 #endif
 
-#if defined(CONFIG_SPL_WATCHDOG_SUPPORT) && defined(CONFIG_WDT)
+#if defined(CONFIG_SPL_WATCHDOG_SUPPORT) && CONFIG_IS_ENABLED(WDT)
initr_watchdog();
 #endif
 
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 40b2f4bc66..4b94ae988c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
 obj-$(CONFIG_DESIGNWARE_WATCHDOG) += designware_wdt.o
 obj-$(CONFIG_TANGIER_WATCHDOG) += tangier_wdt.o
 obj-$(CONFIG_ULP_WATCHDOG) += ulp_wdog.o
-obj-$(CONFIG_WDT) += wdt-uclass.o
+obj-$(CONFIG_$(SPL_TPL_)WDT) += wdt-uclass.o
 obj-$(CONFIG_WDT_SANDBOX) += sandbox_wdt.o
 obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
 obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index 02a3ed6838..7c2220643b 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -137,7 +137,7 @@ typedef struct global_data {
 #if defined(CONFIG_TRANSLATION_OFFSET)
fdt_addr_t translation_offset;  /* optional translation offset */
 #endif
-#if defined(CONFIG_WDT)
+#if CONFIG_IS_ENABLED(WDT)
struct udevice *watchdog_dev;
 #endif
 } gd_t;
diff --git a/include/wdt.h b/include/wdt.h
index aa77d3e9b4..5bcff24ab3 100644
--- a/include/wdt.h
+++ b/include/wdt.h
@@ -106,7 +106,7 @@ struct wdt_ops {
int (*expire_now)(struct udevice *dev, ulong flags);
 };
 
-#if defined(CONFIG_WDT)
+#if CONFIG_IS_ENABLED(WDT)
 #ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS
 #define CONFIG_WATCHDOG_TIMEOUT_MSECS  (60 * 1000)
 #endif
-- 
2.20.1

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


Re: [U-Boot] [PATCH 6/8] ARM: imx: dh-imx6: Convert SATA support to DM

2019-05-12 Thread Marek Vasut
On 5/12/19 12:04 PM, Stefan Roese wrote:
> On 12.05.19 02:57, Marek Vasut wrote:
>> Enable DM SATA support on DHCOM iMX6 PDK2.
>> Convert board code to match the DM support.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Fabio Estevam 
>> Cc: Ludwig Zenz 
>> Cc: Stefano Babic 
>> ---
>>   board/dhelectronics/dh_imx6/dh_imx6.c | 55 +--
>>   configs/dh_imx6_defconfig |  2 +
>>   include/configs/dh_imx6.h |  5 ---
>>   3 files changed, 53 insertions(+), 9 deletions(-)
>>
>> diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c
>> b/board/dhelectronics/dh_imx6/dh_imx6.c
>> index 193bb0eade..2381df84b4 100644
>> --- a/board/dhelectronics/dh_imx6/dh_imx6.c
>> +++ b/board/dhelectronics/dh_imx6/dh_imx6.c
>> @@ -20,6 +20,8 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -302,10 +304,6 @@ int board_init(void)
>>   }
>>   #endif
>>   -#ifdef CONFIG_SATA
>> -    setup_sata();
>> -#endif
>> -
>>   setup_dhcom_mac_from_fuse();
>>     return 0;
>> @@ -384,3 +382,52 @@ int checkboard(void)
>>   puts("Board: DHCOM i.MX6\n");
>>   return 0;
>>   }
>> +
>> +#if CONFIG_IS_ENABLED(AHCI)
>> +static int sata_imx_probe(struct udevice *dev)
>> +{
>> +    int i, err;
>> +
>> +    for (i = 0; i < 10; i++) {
>> +    err = setup_sata();
>> +    if (err) {
>> +    printf("SATA setup failed: %d\n", err);
>> +    return err;
>> +    }
>> +
>> +    udelay(100);
>> +
>> +    err = dwc_ahsata_probe(dev);
>> +    if (!err)
>> +    break;
>> +
>> +    /* There is no device on the SATA port */
>> +    if (sata_dm_port_status(0, 0) == 0)
>> +    break;
>> +
>> +    /* There's a device, but link not established. Retry */
>> +    device_remove(dev, DM_REMOVE_NORMAL);
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +struct ahci_ops sata_imx_ops = {
>> +    .port_status = dwc_ahsata_port_status,
>> +    .reset    = dwc_ahsata_bus_reset,
>> +    .scan    = dwc_ahsata_scan,
>> +};
>> +
>> +static const struct udevice_id sata_imx_ids[] = {
>> +    { .compatible = "fsl,imx6q-ahci" },
>> +    { }
>> +};
>> +
>> +U_BOOT_DRIVER(sata_imx) = {
>> +    .name    = "dwc_ahci",
>> +    .id    = UCLASS_AHCI,
>> +    .of_match    = sata_imx_ids,
>> +    .ops    = _imx_ops,
>> +    .probe    = sata_imx_probe,
>> +};
>> +#endif /* AHCI */
> 
> Is this code dh_imx6 specific in any way? If not, then it would be
> better placed in drivers/ata, so that other i.MX6 boards might use
> it as well. Or am I missing something?

It's a copy-paste from apalis-imx6. In fact, it already is in
drivers/ata (see CONFIG_DWC_AHSATA_AHCI), so I'll just fix up the apalis
board and update this patch.

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


Re: [U-Boot] [PATCH v2] arm: socfpga: Re-add support for Aries MCV SoM and MCVEV[KP] board

2019-05-12 Thread Marek Vasut
On 5/12/19 7:25 PM, Wolfgang Grandegger wrote:
> Re-add support for Aries Embedded MCV SoM, which is CycloneV based
> and the associated MCVEVK and MCVEVP baseboard. The board can boot
> from eMMC. Ethernet and USB is supported.
> 
> The Aries Embedded boards have been removed with commit 03b54997d568
> ("board/aries: Remove"). I will now take care of them.
> 
> The device-tree files are from mainline Linux commit e93c9c99a629
> ("Linux v5.1)".
> 
> Signed-off-by: Wolfgang Grandegger 
> CC: Marek Vasut 
> CC: Simon Goldschmidt 

Reviewed-by: Marek Vasut 

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


Re: [U-Boot] [linux-sunxi] Re: [PATCH v3 3/3] arm: sunxi: h6: fix reset using r_wdog

2019-05-12 Thread Clément Péron
On Sun, 12 May 2019 at 20:23, Jagan Teki  wrote:
>
> On Fri, Apr 19, 2019 at 2:49 PM Clément Péron  wrote:
> >
> > Hi,
> >
> > On Fri, 19 Apr 2019 at 10:24, Jagan Teki  wrote:
> > >
> > > On Fri, Apr 19, 2019 at 1:23 PM Clément Péron  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > +Chen-Yu Tsai for test and +Icenowy because she try to contact AW
> > > > about this issue.
> > > >
> > > > On Wed, 17 Apr 2019 at 19:41, Clément Péron  
> > > > wrote:
> > > > >
> > > > > WDOG is broken for some H6 rev. The board is not
> > > > > reseted correctly.
> > > > >
> > > > > Use the R_WDOG instead.
> > > >
> > > > The issue is real except on Pine H64 and Rongpin RP-H6B which seems to
> > > > be NOT affected.
> > > > Lot of users on OrangePi boards (Lite2 / One Plus and 3) are
> > > > complaining about this issue.
> > > >
> > > > We perform a simple watchdog test on different board :
> > > >
> > > > Chen-Yu Tsai :
> > > > Pine h64 = H6 V200-AWIN H6448BA 7782 => OK
> > > > OrangePi Lite 2 = H6 V200-AWIN H8068BA 61C2 => KO
> > > >
> > > > Martin Ayotte :
> > > > PineH64 = H8069BA 6892 => OK
> > > > Orange Pi 3 = HA047BA 69W2 => KO
> > > > OPiOnePlus = H7310BA 6842 => KO
> > > > OPiLite2 = H6448BA 6662 => KO
> > > >
> > > > Clément Péron:
> > > > Beelink GS1 = H6 V200-AWIN H7309BA 6842 => KO
> > > >
> > > > After the series of result, Icenowy try to reach Allwinner about this
> > > > issue but they seems not interested to investigate it.
> > > >
> > > > I'm not sure if it's an HW errata or if there something misconfigured
> > > > but the result is here WDOG doesn't make these boards reboot.
> > > > And this should not happens !
> > >
> > > How about Linux? same issue.
> > Yes, Linux use PSCI, call ATF and we have the same issue as ATF use
> > the watchdog to reboot.
>

Hi,

> There is an RFC for watchdog, can you have any change to add reset_cpu
> via that driver (ofcourse it's a rework)?
It's indeed a more proper way but it's a different work.
I'm only trying to fix the reboot issue on some H6 boards.
Moreover modifying this part will require some testing on different
Allwinner boards that I don't have.

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


Re: [U-Boot] [PATCH 1/1] pci: pci_mvebu: ignore the local device

2019-05-12 Thread Marek Behun
> Is there a PCIe bridge involved in either of these? In the pre-history
> of Kirkwood (which I believe has the same or similar IP block for
> PCIe) I've hit platforms where the PCIe I/O fails because something
> about the host bridge interferes with a real bridge on the bus where a
> directly connected device worked fine. Marvell were shipping a patch
> that adds a fake PCIe bridge in their LSP and I think that is what was
> eventually ported to upstream Linux.

Hi Chris,
there is no real bridge on Turris Omnia, the devices are connected
directly to CPU.
Marek
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] ARM: imx: cm_fx6: Drop ad-hoc SATA binding

2019-05-12 Thread Marek Vasut
Drop the ad-hoc AHCI binding code, this is superseded by
CONFIG_DWC_AHSATA_AHCI=y resp. drivers/ata/dwc_ahsata.c

Signed-off-by: Marek Vasut 
Cc: Christopher Spinrath 
Cc: Fabio Estevam 
Cc: Igor Grinberg 
Cc: Nikita Kiryanov 
Cc: Stefano Babic 
---
 board/compulab/cm_fx6/cm_fx6.c | 63 --
 configs/cm_fx6_defconfig   |  1 -
 2 files changed, 64 deletions(-)

diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index d42f57d4b7..b8f15cf3ab 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
@@ -724,66 +724,3 @@ U_BOOT_DEVICE(cm_fx6_serial) = {
.name   = "serial_mxc",
.platdata = _fx6_mxc_serial_plat,
 };
-
-#if CONFIG_IS_ENABLED(AHCI)
-static int sata_imx_probe(struct udevice *dev)
-{
-   int i, err;
-
-   /* Make sure this gpio has logical 0 value */
-   gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
-   udelay(100);
-   cm_fx6_sata_power(1);
-
-   for (i = 0; i < CM_FX6_SATA_INIT_RETRIES; i++) {
-   err = setup_sata();
-   if (err) {
-   printf("SATA setup failed: %d\n", err);
-   return err;
-   }
-
-   udelay(100);
-
-   err = dwc_ahsata_probe(dev);
-   if (!err)
-   break;
-
-   /* There is no device on the SATA port */
-   if (sata_dm_port_status(0, 0) == 0)
-   break;
-
-   /* There's a device, but link not established. Retry */
-   device_remove(dev, DM_REMOVE_NORMAL);
-   }
-
-   return 0;
-}
-
-static int sata_imx_remove(struct udevice *dev)
-{
-   cm_fx6_sata_power(0);
-   mdelay(250);
-
-   return 0;
-}
-
-struct ahci_ops sata_imx_ops = {
-   .port_status = dwc_ahsata_port_status,
-   .reset  = dwc_ahsata_bus_reset,
-   .scan   = dwc_ahsata_scan,
-};
-
-static const struct udevice_id sata_imx_ids[] = {
-   { .compatible = "fsl,imx6q-ahci" },
-   { }
-};
-
-U_BOOT_DRIVER(sata_imx) = {
-   .name   = "dwc_ahci",
-   .id = UCLASS_AHCI,
-   .of_match   = sata_imx_ids,
-   .ops= _imx_ops,
-   .probe  = sata_imx_probe,
-   .remove = sata_imx_remove,  /* reset bus to stop it */
-};
-#endif /* AHCI */
diff --git a/configs/cm_fx6_defconfig b/configs/cm_fx6_defconfig
index ce3f9de3f9..e928cbc948 100644
--- a/configs/cm_fx6_defconfig
+++ b/configs/cm_fx6_defconfig
@@ -52,7 +52,6 @@ CONFIG_DEFAULT_DEVICE_TREE="imx6q-cm-fx6"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DWC_AHSATA=y
-# CONFIG_DWC_AHSATA_AHCI is not set
 CONFIG_DM_KEYBOARD=y
 CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
-- 
2.20.1

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


[U-Boot] [PATCH] ARM: imx: apalis_imx6: Drop ad-hoc SATA binding

2019-05-12 Thread Marek Vasut
Drop the ad-hoc AHCI binding code, this is superseded by
CONFIG_DWC_AHSATA_AHCI=y resp. drivers/ata/dwc_ahsata.c

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Marcel Ziswiler 
Cc: Max Krummenacher 
Cc: Stefan Agner 
Cc: Stefano Babic 
---
 board/toradex/apalis_imx6/apalis_imx6.c | 49 -
 1 file changed, 49 deletions(-)

diff --git a/board/toradex/apalis_imx6/apalis_imx6.c 
b/board/toradex/apalis_imx6/apalis_imx6.c
index 3e59185438..b502d4ef13 100644
--- a/board/toradex/apalis_imx6/apalis_imx6.c
+++ b/board/toradex/apalis_imx6/apalis_imx6.c
@@ -1131,52 +1131,3 @@ U_BOOT_DEVICE(mxc_serial) = {
.name = "serial_mxc",
.platdata = _serial_plat,
 };
-
-#if CONFIG_IS_ENABLED(AHCI)
-static int sata_imx_probe(struct udevice *dev)
-{
-   int i, err;
-
-   for (i = 0; i < APALIS_IMX6_SATA_INIT_RETRIES; i++) {
-   err = setup_sata();
-   if (err) {
-   printf("SATA setup failed: %d\n", err);
-   return err;
-   }
-
-   udelay(100);
-
-   err = dwc_ahsata_probe(dev);
-   if (!err)
-   break;
-
-   /* There is no device on the SATA port */
-   if (sata_dm_port_status(0, 0) == 0)
-   break;
-
-   /* There's a device, but link not established. Retry */
-   device_remove(dev, DM_REMOVE_NORMAL);
-   }
-
-   return 0;
-}
-
-struct ahci_ops sata_imx_ops = {
-   .port_status = dwc_ahsata_port_status,
-   .reset  = dwc_ahsata_bus_reset,
-   .scan   = dwc_ahsata_scan,
-};
-
-static const struct udevice_id sata_imx_ids[] = {
-   { .compatible = "fsl,imx6q-ahci" },
-   { }
-};
-
-U_BOOT_DRIVER(sata_imx) = {
-   .name   = "dwc_ahci",
-   .id = UCLASS_AHCI,
-   .of_match   = sata_imx_ids,
-   .ops= _imx_ops,
-   .probe  = sata_imx_probe,
-};
-#endif /* AHCI */
-- 
2.20.1

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


Re: [U-Boot] [PATCH 1/1] pci: pci_mvebu: ignore the local device

2019-05-12 Thread Chris Packham
Hi Marek,

On Fri, May 10, 2019 at 11:44 PM Marek Behun  wrote:
>
> On Fri, 10 May 2019 10:15:25 +0200
> Stefan Roese  wrote:
>
> > On 10.05.19 04:56, Marek Behún wrote:
> > > The local device (host "bridge"?) on pci_mvebu controller reports
> > > PCI_CLASS_MEMORY_OTHER in the class register.
> > >
> > > This does not work in U-Boot, because U-Boot then tries to autoconfigure
> > > this device in pci_auto.c. This causes the real connected PCIe device
> > > not to work (in U-Boot nor in Linux).
> >
> > What exactly does not work or is the issue here with the current
> > implementation in Linux? I'm asking, since we have not noticed any
> > issues here?
> >
> ath10k firmware fails to load for network device.
> SATA device timeouts on a PCIe SATA expander.
> As if some PCIe I/O did not work. The devices are still enumerated and
> recognized by Linux, but simply won't work. Nor in U-Boot.

Is there a PCIe bridge involved in either of these? In the pre-history
of Kirkwood (which I believe has the same or similar IP block for
PCIe) I've hit platforms where the PCIe I/O fails because something
about the host bridge interferes with a real bridge on the bus where a
directly connected device worked fine. Marvell were shipping a patch
that adds a fake PCIe bridge in their LSP and I think that is what was
eventually ported to upstream Linux.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: mvebu: armada-370-xp.dtsi: Add "u-boot, dm-pre-reloc" to "internal-regs"

2019-05-12 Thread Chris Packham
On Sun, May 12, 2019 at 10:09 PM Stefan Roese  wrote:
>
> On 11.05.19 02:09, Chris Packham wrote:
> >
> >
> > On Fri, 10 May 2019, 11:34 PM Stefan Roese,  > > wrote:
> >
> > Without this U-Boot specific property, booting on Armada XP theadorable
> > fails in SPL. All nodes in the "internal-regs" (simple-bus) DT node are
> > not scanned, so the UART node is missing (and others).
> >
> > I'm not adding this property in an *u-boot.dtsi file, since there is
> > none matching the generic rules for all files including this dtsi
> > file. So to not miss any of the boards using this dtsi file, I'm
> > adding it to this file directly, which makes the Linux merge a less
> > easy unforunately.
> >
> > Signed-off-by: Stefan Roese mailto:s...@denx.de>>
> > Cc: Chris Packham  > >
> > Cc: Marek Behún mailto:marek.be...@nic.cz>>
> >
> >
> > Thanks. Is this a regression from my last sync? The only Armada XP
> > like platform I had access to was msys and that doesn't use SPL (yet).
>
> I'm not 100% sure if its only a regression caused by your DT sync or
> also by this patch:
>
> c7a88dae "dm: remove pre reloc properties in SPL and TPL device tree"
>
> I stopped debugging at some point, once I had the node enabled in the
> SPL DT again.
>
> > Reviewed-by: Chris Packham  > >

^^^ Gah, this is from the gmail app on my tablet it seems intent on
linkifying things now. This has been known to make the patchwork
client spew html into the patch when you download it.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 00/11] dm: Removal of some boards due to DM_MMC deadline

2019-05-12 Thread Simon Glass
Hi Tom,

On Sun, 12 May 2019 at 13:03, Simon Glass  wrote:
>
> Hi Tom,
>
> On Sat, 11 May 2019 at 13:36, Tom Rini  wrote:
> >
> > + Peng, the new MMC maintainer
> >
> > On Sat, May 11, 2019 at 01:23:45PM -0600, Simon Glass wrote:
> >
> > > This series starts the process of removing boards which have not been
> > > converted to driver model for MMC.
> >
> > I'm sorry, no.  Like I've been saying in the SPI thread, and I thought I
> > had made clear elsewhere:
> > - This release we move the drivers to depend on BROKEN.  Jagan has a
> >   patch right now that makes BROKEN make another warning happen, but I'm
> >   not 100% sure I like this, but also haven't had a chance to try my
> >   idea of just removing the driver from the build and seeing if the
> >   boards link, or how hard making them link again is.
> > - Next release we can remove the _drivers_ that depend on BROKEN.
>
> Sorry I must have missed this, have had very little time in the past
> few months. I did see mention of BROKEN elsewhere but had somehow not
> made the connection.
>
> Could we get a note added to MIGRATION.txt perhaps?
>
> >
> > Yes, this will result in a bunch of boards that aren't nearly so
> > functional as they would be expected to be.  This in turn might lead to:
> > - Someone stepping up as they care about the hardware
> > - Removing of the boards down the line when it's clear no one has been
> >   using them as there's a big window where generally key drivers aren't
> >   there anymore.
>
> Sounds like a great plan, and much better and easier than removal
> (which is a real pain to create patches for).

I've hit a snag though. s32v234evb doesn't even support
CONFIG_OF_CONTROL. What should we do in that case?

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


[U-Boot] SAMA5D2x and falcon boot mode

2019-05-12 Thread Andy Pont

Hello!

Does anyone know if U-Boot for the Microchip (Atmel) SAMA5D2x devices 
supports the Falcon (SPL -> Linux) boot mode?


-Andy.





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


[U-Boot] [PATCH v2 1/1] efi_loader: out of resources in AllocatePages()

2019-05-12 Thread Heinrich Schuchardt
According to the UEFI AllocatePages() has to return EFI_OUT_OF_RESOURCES if
sufficient memory is not available.

Change the return value.

UEFI SCT II (2017): 3.2.1 AllocatePages(), 5.1.2.1.8

Signed-off-by: Heinrich Schuchardt 
---
v2
fix typo in title: %s/resource/resources/
---
 lib/efi_loader/efi_memory.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index b75722dac3..adbeb1db6b 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -424,7 +424,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
/* Any page */
addr = efi_find_free_memory(len, -1ULL);
if (!addr) {
-   r = EFI_NOT_FOUND;
+   r = EFI_OUT_OF_RESOURCES;
break;
}
break;
@@ -432,7 +432,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
/* Max address */
addr = efi_find_free_memory(len, *memory);
if (!addr) {
-   r = EFI_NOT_FOUND;
+   r = EFI_OUT_OF_RESOURCES;
break;
}
break;
--
2.20.1

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


Re: [U-Boot] [PATCH 02/11] Add a simple script to remove boards

2019-05-12 Thread Simon Glass
Hi Tom,

On Sat, 11 May 2019 at 13:44, Tom Rini  wrote:
>
> On Sat, May 11, 2019 at 01:23:47PM -0600, Simon Glass wrote:
>
> > This script attempts to create a git commit which removes a single board.
> > It is quite fallible and everything it does needs checking. But it can
> > help speed up the process.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  tools/rmboard.py | 150 +++
> >  1 file changed, 150 insertions(+)
> >  create mode 100755 tools/rmboard.py
> >
> > diff --git a/tools/rmboard.py b/tools/rmboard.py
> > new file mode 100755
> > index 00..17952f795d
> > --- /dev/null
> > +++ b/tools/rmboard.py
> > @@ -0,0 +1,150 @@
> > +#! /usr/bin/python
> > +# SPDX-License-Identifier: GPL-2.0+
> > +# Copyright 2019 Google LLC
>
> Is this python3 or python2?  Since we have a lot of python2 stuff
> currently, I want to be sure we're just adding python3 now, thanks.

It works with both (for me).

I have code that fixes up patman and a few libraries as well. Will see
if I can tidy it up and send it.

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


Re: [U-Boot] [PATCH 00/11] dm: Removal of some boards due to DM_MMC deadline

2019-05-12 Thread Simon Glass
Hi Tom,

On Sat, 11 May 2019 at 13:36, Tom Rini  wrote:
>
> + Peng, the new MMC maintainer
>
> On Sat, May 11, 2019 at 01:23:45PM -0600, Simon Glass wrote:
>
> > This series starts the process of removing boards which have not been
> > converted to driver model for MMC.
>
> I'm sorry, no.  Like I've been saying in the SPI thread, and I thought I
> had made clear elsewhere:
> - This release we move the drivers to depend on BROKEN.  Jagan has a
>   patch right now that makes BROKEN make another warning happen, but I'm
>   not 100% sure I like this, but also haven't had a chance to try my
>   idea of just removing the driver from the build and seeing if the
>   boards link, or how hard making them link again is.
> - Next release we can remove the _drivers_ that depend on BROKEN.

Sorry I must have missed this, have had very little time in the past
few months. I did see mention of BROKEN elsewhere but had somehow not
made the connection.

Could we get a note added to MIGRATION.txt perhaps?

>
> Yes, this will result in a bunch of boards that aren't nearly so
> functional as they would be expected to be.  This in turn might lead to:
> - Someone stepping up as they care about the hardware
> - Removing of the boards down the line when it's clear no one has been
>   using them as there's a big window where generally key drivers aren't
>   there anymore.

Sounds like a great plan, and much better and easier than removal
(which is a real pain to create patches for).

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


[U-Boot] [PATCH 1/1] efi_loader: comments for efi_install_fdt()

2019-05-12 Thread Heinrich Schuchardt
Describe that efi_install_fdt() defaults to using the device tree
indicated by environment variable fdtcontroladdr.

ACPI tables and device trees are mutually exclusive.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 0b3c5cdb90..c19256e00d 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -196,11 +196,16 @@ static void *get_config_table(const efi_guid_t *guid)

 /**
  * efi_install_fdt() - install fdt passed by a command argument
+ *
+ * If fdt_opt is available, the device tree located at that memory address will
+ * will be installed as configuration table, otherwise the device tree located
+ * at the address indicated by environment variable fdtcontroladdr will be 
used.
+ *
+ * On architectures (x86) using ACPI tables device trees shall not be installed
+ * as configuration table.
+ *
  * @fdt_opt:   pointer to argument
  * Return: status code
- *
- * If specified, fdt will be installed as configuration table,
- * otherwise no fdt will be passed.
  */
 static efi_status_t efi_install_fdt(const char *fdt_opt)
 {
--
2.20.1

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


[U-Boot] [PATCH 1/1] efi_loader: deduplicate code in cmd/bootefi.c

2019-05-12 Thread Heinrich Schuchardt
Move duplicate initialization code to single instance.

Adjust comments of concerned functions.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/bootefi.c | 99 +++
 1 file changed, 37 insertions(+), 62 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 52116b308c..0b3c5cdb90 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -314,32 +314,15 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle)
 }

 /**
- * do_efibootmgr() - execute EFI Boot Manager
+ * do_efibootmgr() - execute EFI boot manager
  *
- * @fdt_opt:   string of fdt start address
  * Return: status code
- *
- * Execute EFI Boot Manager
  */
-static int do_efibootmgr(const char *fdt_opt)
+static int do_efibootmgr(void)
 {
efi_handle_t handle;
efi_status_t ret;

-   /* Initialize EFI drivers */
-   ret = efi_init_obj_list();
-   if (ret != EFI_SUCCESS) {
-   printf("Error: Cannot initialize UEFI sub-system, r = %lu\n",
-  ret & ~EFI_ERROR_MASK);
-   return CMD_RET_FAILURE;
-   }
-
-   ret = efi_install_fdt(fdt_opt);
-   if (ret == EFI_INVALID_PARAMETER)
-   return CMD_RET_USAGE;
-   else if (ret != EFI_SUCCESS)
-   return CMD_RET_FAILURE;
-
ret = efi_bootmgr_load();
if (ret != EFI_SUCCESS) {
printf("EFI boot manager: Cannot load any image\n");
@@ -355,16 +338,15 @@ static int do_efibootmgr(const char *fdt_opt)
 }

 /*
- * do_bootefi_image() - execute EFI binary from command line
+ * do_bootefi_image() - execute EFI binary
+ *
+ * Set up memory image for the binary to be loaded, prepare device path, and
+ * then call do_bootefi_exec() to execute it.
  *
  * @image_opt: string of image start address
- * @fdt_opt:   string of fdt start address
  * Return: status code
- *
- * Set up memory image for the binary to be loaded, prepare
- * device path and then call do_bootefi_exec() to execute it.
  */
-static int do_bootefi_image(const char *image_opt, const char *fdt_opt)
+static int do_bootefi_image(const char *image_opt)
 {
void *image_buf;
struct efi_device_path *device_path, *image_path;
@@ -374,20 +356,6 @@ static int do_bootefi_image(const char *image_opt, const 
char *fdt_opt)
efi_handle_t mem_handle = NULL, handle;
efi_status_t ret;

-   /* Initialize EFI drivers */
-   ret = efi_init_obj_list();
-   if (ret != EFI_SUCCESS) {
-   printf("Error: Cannot initialize UEFI sub-system, r = %lu\n",
-  ret & ~EFI_ERROR_MASK);
-   return CMD_RET_FAILURE;
-   }
-
-   ret = efi_install_fdt(fdt_opt);
-   if (ret == EFI_INVALID_PARAMETER)
-   return CMD_RET_USAGE;
-   else if (ret != EFI_SUCCESS)
-   return CMD_RET_FAILURE;
-
 #ifdef CONFIG_CMD_BOOTEFI_HELLO
if (!strcmp(image_opt, "hello")) {
char *saddr;
@@ -547,33 +515,16 @@ static void bootefi_run_finish(struct 
efi_loaded_image_obj *image_obj,
 }

 /**
- * do_efi_selftest() - execute EFI Selftest
+ * do_efi_selftest() - execute EFI selftest
  *
- * @fdt_opt:   string of fdt start address
  * Return: status code
- *
- * Execute EFI Selftest
  */
-static int do_efi_selftest(const char *fdt_opt)
+static int do_efi_selftest(void)
 {
struct efi_loaded_image_obj *image_obj;
struct efi_loaded_image *loaded_image_info;
efi_status_t ret;

-   /* Initialize EFI drivers */
-   ret = efi_init_obj_list();
-   if (ret != EFI_SUCCESS) {
-   printf("Error: Cannot initialize UEFI sub-system, r = %lu\n",
-  ret & ~EFI_ERROR_MASK);
-   return CMD_RET_FAILURE;
-   }
-
-   ret = efi_install_fdt(fdt_opt);
-   if (ret == EFI_INVALID_PARAMETER)
-   return CMD_RET_USAGE;
-   else if (ret != EFI_SUCCESS)
-   return CMD_RET_FAILURE;
-
ret = bootefi_test_prepare(_obj, _image_info,
   "\\selftest", "efi_selftest");
if (ret != EFI_SUCCESS)
@@ -587,20 +538,44 @@ static int do_efi_selftest(const char *fdt_opt)
 }
 #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */

-/* Interpreter command to boot an arbitrary EFI image from memory */
+/**
+ * do_bootefi() - execute `bootefi` command
+ *
+ * @cmdtp: table entry describing command
+ * @flag:  bitmap indicating how the command was invoked
+ * @argc:  number of arguments
+ * @argv:  command line arguments
+ * Return: status code
+ */
 static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
 {
+   efi_status_t ret;
+
if (argc < 2)
return CMD_RET_USAGE;

+   /* Initialize EFI drivers */
+   ret = efi_init_obj_list();
+   if (ret != EFI_SUCCESS) {
+   printf("Error: Cannot initialize UEFI sub-system, r = %lu\n",
+  ret & ~EFI_ERROR_MASK);
+   

Re: [U-Boot] [linux-sunxi] Re: [PATCH v3 3/3] arm: sunxi: h6: fix reset using r_wdog

2019-05-12 Thread Jagan Teki
On Fri, Apr 19, 2019 at 2:49 PM Clément Péron  wrote:
>
> Hi,
>
> On Fri, 19 Apr 2019 at 10:24, Jagan Teki  wrote:
> >
> > On Fri, Apr 19, 2019 at 1:23 PM Clément Péron  wrote:
> > >
> > > Hi,
> > >
> > > +Chen-Yu Tsai for test and +Icenowy because she try to contact AW
> > > about this issue.
> > >
> > > On Wed, 17 Apr 2019 at 19:41, Clément Péron  wrote:
> > > >
> > > > WDOG is broken for some H6 rev. The board is not
> > > > reseted correctly.
> > > >
> > > > Use the R_WDOG instead.
> > >
> > > The issue is real except on Pine H64 and Rongpin RP-H6B which seems to
> > > be NOT affected.
> > > Lot of users on OrangePi boards (Lite2 / One Plus and 3) are
> > > complaining about this issue.
> > >
> > > We perform a simple watchdog test on different board :
> > >
> > > Chen-Yu Tsai :
> > > Pine h64 = H6 V200-AWIN H6448BA 7782 => OK
> > > OrangePi Lite 2 = H6 V200-AWIN H8068BA 61C2 => KO
> > >
> > > Martin Ayotte :
> > > PineH64 = H8069BA 6892 => OK
> > > Orange Pi 3 = HA047BA 69W2 => KO
> > > OPiOnePlus = H7310BA 6842 => KO
> > > OPiLite2 = H6448BA 6662 => KO
> > >
> > > Clément Péron:
> > > Beelink GS1 = H6 V200-AWIN H7309BA 6842 => KO
> > >
> > > After the series of result, Icenowy try to reach Allwinner about this
> > > issue but they seems not interested to investigate it.
> > >
> > > I'm not sure if it's an HW errata or if there something misconfigured
> > > but the result is here WDOG doesn't make these boards reboot.
> > > And this should not happens !
> >
> > How about Linux? same issue.
> Yes, Linux use PSCI, call ATF and we have the same issue as ATF use
> the watchdog to reboot.

There is an RFC for watchdog, can you have any change to add reset_cpu
via that driver (ofcourse it's a rework)?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/3] arm: sunxi: h6: fix reset using r_wdog

2019-05-12 Thread Clément Péron
Hi Jagan,

Is there anything you need to merge this patch?

Thanks,
Clément


On Mon, 29 Apr 2019 at 22:28, Clément Péron  wrote:
>
> Hi Jagan,
>
> FYI the patch on ATF has been merged just now. It has been tested by
> André Przywara on A64, H5 and H6.
>
> https://github.com/ARM-software/arm-trusted-firmware/commit/523ab5be1a84e9aa15fb62c3a15a6338b01d3961
>
> Thanks,
> Clement
>
> On Fri, 19 Apr 2019 at 11:19, Clément Péron  wrote:
> >
> > Hi,
> >
> > On Fri, 19 Apr 2019 at 10:24, Jagan Teki  wrote:
> > >
> > > On Fri, Apr 19, 2019 at 1:23 PM Clément Péron  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > +Chen-Yu Tsai for test and +Icenowy because she try to contact AW
> > > > about this issue.
> > > >
> > > > On Wed, 17 Apr 2019 at 19:41, Clément Péron  
> > > > wrote:
> > > > >
> > > > > WDOG is broken for some H6 rev. The board is not
> > > > > reseted correctly.
> > > > >
> > > > > Use the R_WDOG instead.
> > > >
> > > > The issue is real except on Pine H64 and Rongpin RP-H6B which seems to
> > > > be NOT affected.
> > > > Lot of users on OrangePi boards (Lite2 / One Plus and 3) are
> > > > complaining about this issue.
> > > >
> > > > We perform a simple watchdog test on different board :
> > > >
> > > > Chen-Yu Tsai :
> > > > Pine h64 = H6 V200-AWIN H6448BA 7782 => OK
> > > > OrangePi Lite 2 = H6 V200-AWIN H8068BA 61C2 => KO
> > > >
> > > > Martin Ayotte :
> > > > PineH64 = H8069BA 6892 => OK
> > > > Orange Pi 3 = HA047BA 69W2 => KO
> > > > OPiOnePlus = H7310BA 6842 => KO
> > > > OPiLite2 = H6448BA 6662 => KO
> > > >
> > > > Clément Péron:
> > > > Beelink GS1 = H6 V200-AWIN H7309BA 6842 => KO
> > > >
> > > > After the series of result, Icenowy try to reach Allwinner about this
> > > > issue but they seems not interested to investigate it.
> > > >
> > > > I'm not sure if it's an HW errata or if there something misconfigured
> > > > but the result is here WDOG doesn't make these boards reboot.
> > > > And this should not happens !
> > >
> > > How about Linux? same issue.
> > Yes, Linux use PSCI, call ATF and we have the same issue as ATF use
> > the watchdog to reboot.
> >
> > Clement
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [RFC PATCH] drivers: ata: ahci_sunxi: Increased SATA/AHCI DMA TX/RX FIFOs

2019-05-12 Thread Maxime Ripard
Hi,

On Sun, May 12, 2019 at 06:08:19PM +0200, U.Mutlu wrote:
> Hi Maxime & Others,
>
> what follows is a somewhat lengthy technical story behind this patch;
> you can just skip it and jump to the end.
>
>
> As can be seen in the ahci_sunxi.c, the port used in this patch
> is this one (32bit):
>   #define AHCI_P0DMACR0x0170
> It's a so called "Vendor Specific Port" according to the SATA/AHCI specs by 
> Intel.
> The data behind it is actually a struct, consisting of 4 fields,
> each 4bits long, plus a 16bits long field that is marked as Reserved
> in secondary literature (see below):
>
> struct AHCI_P0DMACR_t
> {
>   unsigned TXTS  : 4,
>RXTS  : 4,
>TXABL : 4,
>RXABL : 4,
>Res1  : 16;
> };
>
> This struct is just my creation for my own tests as it's not part of the
> driver source. The patch touches only the first 2 fields: TXTS and RXTS.
>
> See this similar product documentation by Texas Instruments for the above 
> struct:
> https://www.ti.com/lit/ug/sprugj8c/sprugj8c.pdf
> TMS320C674x/OMAP-L1x Processor, Serial ATA (SATA) Controller, User's Guide,
> Literature Number: SPRUGJ8C, March 2011,
> Page 68, Chapter 4.33 "Port DMA Control Register (P0DMACR)"
>
> The above TI document describes the two fields as follows:
>
> TXTS:
>   Transmit Transaction Size (TX_TRANSACTION_SIZE). This field defines the
> DMA transaction size in
>   DWORDs for transmit (system bus read, device write) operation. [...]
>
> RXTS:
>   Receive Transaction Size (RX_TRANSACTION_SIZE). This field defines the
> Port DMA transaction size
>   in DWORDs for receive (system bus write, device read) operation. [...]
>
>
> So, in my patch the fields TXTS and RXTS are set to 3 each.
> Without the patch, these fields seem to have some random content
> (I'vee seen 5 and 6, 4 and 4, and 0 and 0 on different devices),
> as the previous code doesn't touch these 2 fields (ie. these two fields
> are not within the used old mask of 0xff00; cf. ahci_sunxi.c, function
> ahci_sunxi_start_engine(...)).
>
>
> Some background story in my hunt for obtaining product documentation:
>
> I couldn't find any product documentation for the SATA/AHCI
> in these SoCs by Allwinner Technology (allwinnertech.com),
> unlike with such products from other such companies.
>
> I asked Allwinner, but they just said that the A20 of my SBC
> would (allegedly) no more be actual and that the support for it
> has ended (but this statement somehow cannot be true as the
> A20 SoC is still continued being marketed at their website).
> They instead sent me a bunch of really irrelevant PDFs which have
> nothing to do with SATA/AHCI.
>
> So, the company Allwinner Technology unfortunately was not cooperative
> to provide me information on their SATA/AHCI-implementation in their SoCs :-(
> Even the ports used in the actual ahci_sunxi.c in the linux tree are 
> undocumented;
> it is even commented with "/* This magic is from the original code */"
> and below it many ports are used for which no documentation is available,
> or at least I couldn't find any on the Internet. And the initial programmer
> in 2014 and prior was Daniel Wang (danielw...@allwinnertech.com),
> but email to that address bounces.
>
> So, I was forced to research secondary literature from other vendors
> like Texas Instruments (thanks TI !) and Intel, and also studying
> very old source codes in the old Linux repositories (as it differs
> much from the current version) going back to the year 2014, and had
> to do many (blind) experiments until I found this solution.
>
> The above given User's Guide by Texas Instruments (and their such
> documents for their newer such products) helped me much to find the solution.
> It's of course not really the correct documentation for the Allwinner SoCs,
> but still better than nothing.
>
> If I only had the right documentation, then I for sure could try
> to further improve that already achieved result by this patch,
> as with SATA-II upto 300 MiB/s is possible.
>
>
> Yes, I'll resend the patch with some appropriate comments.

That's awesome research and explanation, thanks! :)

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


[U-Boot] [PATCH v2] arm: socfpga: Re-add support for Aries MCV SoM and MCVEV[KP] board

2019-05-12 Thread Wolfgang Grandegger
Re-add support for Aries Embedded MCV SoM, which is CycloneV based
and the associated MCVEVK and MCVEVP baseboard. The board can boot
from eMMC. Ethernet and USB is supported.

The Aries Embedded boards have been removed with commit 03b54997d568
("board/aries: Remove"). I will now take care of them.

The device-tree files are from mainline Linux commit e93c9c99a629
("Linux v5.1)".

Signed-off-by: Wolfgang Grandegger 
CC: Marek Vasut 
CC: Simon Goldschmidt 
---

Changes in v2:
- remove "aries" in .travis.yml
- add "socfpga_legacy_reset_compat=1" and "bootm_size=0xa00" to
  the default environment
- use PARTUUID to define the Linux root device 
- include "socfpga-common-u-boot.dtsi" also adding the missing
  "u-boot,dm-pre-reloc" for the "rst" odr "sdr" nodes
- add supported DTS files to the MAINTAINERS file

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/socfpga_cyclone5_mcv.dtsi   |  22 +
 arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi |  34 ++
 arch/arm/dts/socfpga_cyclone5_mcvevk.dts |  81 +++
 arch/arm/mach-socfpga/Kconfig|   7 +
 board/aries/mcvevk/MAINTAINERS   |   9 +
 board/aries/mcvevk/Makefile  |   7 +
 board/aries/mcvevk/qts/iocsr_config.h| 659 +++
 board/aries/mcvevk/qts/pinmux_config.h   | 218 
 board/aries/mcvevk/qts/pll_config.h  |  84 +++
 board/aries/mcvevk/qts/sdram_config.h| 343 
 board/aries/mcvevk/socfpga.c |   5 +
 configs/socfpga_mcvevk_defconfig |  59 ++
 include/configs/socfpga_mcvevk.h | 103 
 14 files changed, 1632 insertions(+)
 create mode 100644 arch/arm/dts/socfpga_cyclone5_mcv.dtsi
 create mode 100644 arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_cyclone5_mcvevk.dts
 create mode 100644 board/aries/mcvevk/MAINTAINERS
 create mode 100644 board/aries/mcvevk/Makefile
 create mode 100644 board/aries/mcvevk/qts/iocsr_config.h
 create mode 100644 board/aries/mcvevk/qts/pinmux_config.h
 create mode 100644 board/aries/mcvevk/qts/pll_config.h
 create mode 100644 board/aries/mcvevk/qts/sdram_config.h
 create mode 100644 board/aries/mcvevk/socfpga.c
 create mode 100644 configs/socfpga_mcvevk_defconfig
 create mode 100644 include/configs/socfpga_mcvevk.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8e082f2..139c224 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -276,6 +276,7 @@ dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
 dtb-$(CONFIG_ARCH_SOCFPGA) +=  \
socfpga_arria5_socdk.dtb\
socfpga_arria10_socdk_sdmmc.dtb \
+   socfpga_cyclone5_mcvevk.dtb \
socfpga_cyclone5_is1.dtb\
socfpga_cyclone5_socdk.dtb  \
socfpga_cyclone5_dbm_soc1.dtb   \
diff --git a/arch/arm/dts/socfpga_cyclone5_mcv.dtsi 
b/arch/arm/dts/socfpga_cyclone5_mcv.dtsi
new file mode 100644
index 000..bd92806
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_mcv.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2015 Marek Vasut 
+ */
+
+#include "socfpga_cyclone5.dtsi"
+
+/ {
+   model = "Aries/DENX MCV";
+   compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+
+   memory@0 {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x4000>; /* 1 GiB */
+   };
+};
+
+ {/* On-SoM eMMC */
+   bus-width = <8>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi 
b/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
new file mode 100644
index 000..79f5d92
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_mcvevk-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (C) 2015 Marek Vasut 
+ * Copyright (C) 2019 Wolfgang Grandegger 
+ */
+
+#include "socfpga-common-u-boot.dtsi"
+
+ {
+   status = "disabled";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   clock-frequency = <1>;
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   bank-name = "porta";
+};
+
+ {
+   bank-name = "portb";
+};
+
+ {
+   bank-name = "portc";
+};
diff --git a/arch/arm/dts/socfpga_cyclone5_mcvevk.dts 
b/arch/arm/dts/socfpga_cyclone5_mcvevk.dts
new file mode 100644
index 000..ceaec29
--- /dev/null
+++ b/arch/arm/dts/socfpga_cyclone5_mcvevk.dts
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2015 Marek Vasut 
+ */
+
+#include "socfpga_cyclone5_mcv.dtsi"
+
+/ {
+   model = "Aries/DENX MCV EVK";
+   compatible = "denx,mcvevk", "altr,socfpga-cyclone5", "altr,socfpga";
+
+   aliases {
+   ethernet0 = 
+   stmpe-i2c0 = 
+   };
+
+   chosen {
+   

Re: [RFC PATCH] drivers: ata: ahci_sunxi: Increased SATA/AHCI DMA TX/RX FIFOs

2019-05-12 Thread U.Mutlu

Hi Maxime & Others,

what follows is a somewhat lengthy technical story behind this patch;
you can just skip it and jump to the end.


As can be seen in the ahci_sunxi.c, the port used in this patch
is this one (32bit):
  #define AHCI_P0DMACR0x0170
It's a so called "Vendor Specific Port" according to the SATA/AHCI specs by 
Intel.
The data behind it is actually a struct, consisting of 4 fields,
each 4bits long, plus a 16bits long field that is marked as Reserved
in secondary literature (see below):

struct AHCI_P0DMACR_t
{
  unsigned TXTS  : 4,
   RXTS  : 4,
   TXABL : 4,
   RXABL : 4,
   Res1  : 16;
};

This struct is just my creation for my own tests as it's not part of the
driver source. The patch touches only the first 2 fields: TXTS and RXTS.

See this similar product documentation by Texas Instruments for the above 
struct:
https://www.ti.com/lit/ug/sprugj8c/sprugj8c.pdf
TMS320C674x/OMAP-L1x Processor, Serial ATA (SATA) Controller, User's Guide,
Literature Number: SPRUGJ8C, March 2011,
Page 68, Chapter 4.33 "Port DMA Control Register (P0DMACR)"

The above TI document describes the two fields as follows:

TXTS:
  Transmit Transaction Size (TX_TRANSACTION_SIZE). This field defines the DMA 
transaction size in

  DWORDs for transmit (system bus read, device write) operation. [...]

RXTS:
  Receive Transaction Size (RX_TRANSACTION_SIZE). This field defines the Port 
DMA transaction size

  in DWORDs for receive (system bus write, device read) operation. [...]


So, in my patch the fields TXTS and RXTS are set to 3 each.
Without the patch, these fields seem to have some random content
(I'vee seen 5 and 6, 4 and 4, and 0 and 0 on different devices),
as the previous code doesn't touch these 2 fields (ie. these two fields
are not within the used old mask of 0xff00; cf. ahci_sunxi.c, function 
ahci_sunxi_start_engine(...)).



Some background story in my hunt for obtaining product documentation:

I couldn't find any product documentation for the SATA/AHCI
in these SoCs by Allwinner Technology (allwinnertech.com),
unlike with such products from other such companies.

I asked Allwinner, but they just said that the A20 of my SBC
would (allegedly) no more be actual and that the support for it
has ended (but this statement somehow cannot be true as the
A20 SoC is still continued being marketed at their website).
They instead sent me a bunch of really irrelevant PDFs which have
nothing to do with SATA/AHCI.

So, the company Allwinner Technology unfortunately was not cooperative
to provide me information on their SATA/AHCI-implementation in their SoCs :-(
Even the ports used in the actual ahci_sunxi.c in the linux tree are 
undocumented;
it is even commented with "/* This magic is from the original code */"
and below it many ports are used for which no documentation is available,
or at least I couldn't find any on the Internet. And the initial programmer
in 2014 and prior was Daniel Wang (danielw...@allwinnertech.com),
but email to that address bounces.

So, I was forced to research secondary literature from other vendors
like Texas Instruments (thanks TI !) and Intel, and also studying
very old source codes in the old Linux repositories (as it differs
much from the current version) going back to the year 2014, and had
to do many (blind) experiments until I found this solution.

The above given User's Guide by Texas Instruments (and their such
documents for their newer such products) helped me much to find the solution.
It's of course not really the correct documentation for the Allwinner SoCs,
but still better than nothing.

If I only had the right documentation, then I for sure could try
to further improve that already achieved result by this patch,
as with SATA-II upto 300 MiB/s is possible.


Yes, I'll resend the patch with some appropriate comments.

Uenal Mutlu



Maxime Ripard wrote on 05/12/2019 02:12 PM:

Hi,

On Fri, May 10, 2019 at 09:25:50PM +0200, Uenal Mutlu wrote:

Increasing the SATA/AHCI DMA TX/RX FIFOs (P0DMACR.TXTS and .RXTS) from
default 0x0 each to 0x3 each gives a write performance boost of 120MB/s
from lame 36MB/s to 45MB/s previously. Read performance is about 200MB/s
[tested on SSD using dd bs=4K count=512K].

Tested on the Banana Pi R1 (aka Lamobo R1) and Banana Pi M1 SBCs
with Allwinner A20 32bit-SoCs (ARMv7-a / arm-linux-gnueabihf).
These devices are RaspberryPi-like small devices.

RFC: Since more than about 25 similar SBC/SoC models do use the
ahci_sunxi driver, users are encouraged to test it on all the
affected boards and give feedback.

List of the affected sunxi and other boards and SoCs with SATA using
the ahci_sunxi driver:
   $ grep -i -e "^" arch/arm/boot/dts/sun*dts
   and http://linux-sunxi.org/Category:Devices_with_SATA_port

Signed-off-by: Uenal Mutlu 
---
  drivers/ata/ahci_sunxi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_sunxi.c b/drivers/ata/ahci_sunxi.c
index 911710643305..257986431c79 

Re: [RFC PATCH] drivers: ata: ahci_sunxi: Increased SATA/AHCI DMA TX/RX FIFOs

2019-05-12 Thread Maxime Ripard
Hi,

On Fri, May 10, 2019 at 09:25:50PM +0200, Uenal Mutlu wrote:
> Increasing the SATA/AHCI DMA TX/RX FIFOs (P0DMACR.TXTS and .RXTS) from
> default 0x0 each to 0x3 each gives a write performance boost of 120MB/s
> from lame 36MB/s to 45MB/s previously. Read performance is about 200MB/s
> [tested on SSD using dd bs=4K count=512K].
>
> Tested on the Banana Pi R1 (aka Lamobo R1) and Banana Pi M1 SBCs
> with Allwinner A20 32bit-SoCs (ARMv7-a / arm-linux-gnueabihf).
> These devices are RaspberryPi-like small devices.
>
> RFC: Since more than about 25 similar SBC/SoC models do use the
> ahci_sunxi driver, users are encouraged to test it on all the
> affected boards and give feedback.
>
> List of the affected sunxi and other boards and SoCs with SATA using
> the ahci_sunxi driver:
>   $ grep -i -e "^" arch/arm/boot/dts/sun*dts
>   and http://linux-sunxi.org/Category:Devices_with_SATA_port
>
> Signed-off-by: Uenal Mutlu 
> ---
>  drivers/ata/ahci_sunxi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/ata/ahci_sunxi.c b/drivers/ata/ahci_sunxi.c
> index 911710643305..257986431c79 100644
> --- a/drivers/ata/ahci_sunxi.c
> +++ b/drivers/ata/ahci_sunxi.c
> @@ -158,7 +158,7 @@ static void ahci_sunxi_start_engine(struct ata_port *ap)
>   struct ahci_host_priv *hpriv = ap->host->private_data;
>
>   /* Setup DMA before DMA start */
> - sunxi_clrsetbits(hpriv->mmio + AHCI_P0DMACR, 0xff00, 0x4400);
> + sunxi_clrsetbits(hpriv->mmio + AHCI_P0DMACR, 0x, 0x4433);

Having comments / defines here would be great, once fixed:
Acked-by: Maxime Ripard 

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [U-Boot] [PATCH] arm: mvebu: armada-370-xp.dtsi: Add "u-boot, dm-pre-reloc" to "internal-regs"

2019-05-12 Thread Stefan Roese

On 11.05.19 02:09, Chris Packham wrote:



On Fri, 10 May 2019, 11:34 PM Stefan Roese, mailto:s...@denx.de>> wrote:

Without this U-Boot specific property, booting on Armada XP theadorable
fails in SPL. All nodes in the "internal-regs" (simple-bus) DT node are
not scanned, so the UART node is missing (and others).

I'm not adding this property in an *u-boot.dtsi file, since there is
none matching the generic rules for all files including this dtsi
file. So to not miss any of the boards using this dtsi file, I'm
adding it to this file directly, which makes the Linux merge a less
easy unforunately.

Signed-off-by: Stefan Roese mailto:s...@denx.de>>
Cc: Chris Packham mailto:judge.pack...@gmail.com>>
Cc: Marek Behún mailto:marek.be...@nic.cz>>


Thanks. Is this a regression from my last sync? The only Armada XP
like platform I had access to was msys and that doesn't use SPL (yet).


I'm not 100% sure if its only a regression caused by your DT sync or
also by this patch:

c7a88dae "dm: remove pre reloc properties in SPL and TPL device tree"

I stopped debugging at some point, once I had the node enabled in the
SPL DT again.
 

Reviewed-by: Chris Packham mailto:judge.pack...@gmail.com>>


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


Re: [U-Boot] [PATCH 6/8] ARM: imx: dh-imx6: Convert SATA support to DM

2019-05-12 Thread Stefan Roese

On 12.05.19 02:57, Marek Vasut wrote:

Enable DM SATA support on DHCOM iMX6 PDK2.
Convert board code to match the DM support.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Ludwig Zenz 
Cc: Stefano Babic 
---
  board/dhelectronics/dh_imx6/dh_imx6.c | 55 +--
  configs/dh_imx6_defconfig |  2 +
  include/configs/dh_imx6.h |  5 ---
  3 files changed, 53 insertions(+), 9 deletions(-)

diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c 
b/board/dhelectronics/dh_imx6/dh_imx6.c
index 193bb0eade..2381df84b4 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6.c
@@ -20,6 +20,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -302,10 +304,6 @@ int board_init(void)
}
  #endif
  
-#ifdef CONFIG_SATA

-   setup_sata();
-#endif
-
setup_dhcom_mac_from_fuse();
  
  	return 0;

@@ -384,3 +382,52 @@ int checkboard(void)
puts("Board: DHCOM i.MX6\n");
return 0;
  }
+
+#if CONFIG_IS_ENABLED(AHCI)
+static int sata_imx_probe(struct udevice *dev)
+{
+   int i, err;
+
+   for (i = 0; i < 10; i++) {
+   err = setup_sata();
+   if (err) {
+   printf("SATA setup failed: %d\n", err);
+   return err;
+   }
+
+   udelay(100);
+
+   err = dwc_ahsata_probe(dev);
+   if (!err)
+   break;
+
+   /* There is no device on the SATA port */
+   if (sata_dm_port_status(0, 0) == 0)
+   break;
+
+   /* There's a device, but link not established. Retry */
+   device_remove(dev, DM_REMOVE_NORMAL);
+   }
+
+   return 0;
+}
+
+struct ahci_ops sata_imx_ops = {
+   .port_status = dwc_ahsata_port_status,
+   .reset  = dwc_ahsata_bus_reset,
+   .scan   = dwc_ahsata_scan,
+};
+
+static const struct udevice_id sata_imx_ids[] = {
+   { .compatible = "fsl,imx6q-ahci" },
+   { }
+};
+
+U_BOOT_DRIVER(sata_imx) = {
+   .name   = "dwc_ahci",
+   .id = UCLASS_AHCI,
+   .of_match   = sata_imx_ids,
+   .ops= _imx_ops,
+   .probe  = sata_imx_probe,
+};
+#endif /* AHCI */


Is this code dh_imx6 specific in any way? If not, then it would be
better placed in drivers/ata, so that other i.MX6 boards might use
it as well. Or am I missing something?

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


Re: [U-Boot] [PATCH 03/11] solidrun: Fix soldrun typo

2019-05-12 Thread Stefan Roese

On 11.05.19 21:23, Simon Glass wrote:

This file in the MAINTAINERS file is incorrect. Fix it.

Signed-off-by: Simon Glass 


Thanks for catching this one:

Reviewed-by: Stefan Roese 

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


[U-Boot] [PATCH 1/1] fs: fat: correct file name normalization

2019-05-12 Thread Heinrich Schuchardt
File names may not contain control characters (< 0x20).
Simplify the coding.

Signed-off-by: Heinrich Schuchardt 
---
 fs/fat/fat_write.c | 48 +++---
 1 file changed, 20 insertions(+), 28 deletions(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 852f874e58..2a74199236 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -1009,40 +1009,32 @@ again:
return 0;
 }

+/**
+ * normalize_longname() - check long file name and convert to lower case
+ *
+ * We assume here that the FAT file system is using an 8bit code page.
+ * Linux typically uses CP437, EDK2 assumes CP1250.
+ *
+ * @l_filename:preallocated buffer receiving the normalized name
+ * @filename:  filename to normalize
+ * Return: 0 on success, -1 on failure
+ */
 static int normalize_longname(char *l_filename, const char *filename)
 {
-   const char *p, legal[] = "!#$%&\'()-.@^`_{}~";
-   unsigned char c;
-   int name_len;
-
-   /* Check that the filename is valid */
-   for (p = filename; p < filename + strlen(filename); p++) {
-   c = *p;
-
-   if (('0' <= c) && (c <= '9'))
-   continue;
-   if (('A' <= c) && (c <= 'Z'))
-   continue;
-   if (('a' <= c) && (c <= 'z'))
-   continue;
-   if (strchr(legal, c))
-   continue;
-   /* extended code */
-   if ((0x80 <= c) && (c <= 0xff))
-   continue;
+   const char *p, illegal[] = "<>:\"/\\|?*";

+   if (strlen(filename) >= VFAT_MAXLEN_BYTES)
return -1;
-   }

-   /* Normalize it */
-   name_len = strlen(filename);
-   if (name_len >= VFAT_MAXLEN_BYTES)
-   /* should return an error? */
-   name_len = VFAT_MAXLEN_BYTES - 1;
+   for (p = filename; *p; ++p) {
+   if ((unsigned char)*p < 0x20)
+   return -1;
+   if (strchr(illegal, *p))
+   return -1;
+   }

-   memcpy(l_filename, filename, name_len);
-   l_filename[name_len] = 0; /* terminate the string */
-   downcase(l_filename, INT_MAX);
+   strcpy(l_filename, filename);
+   downcase(l_filename, VFAT_MAXLEN_BYTES);

return 0;
 }
--
2.20.1

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