Re: [U-Boot] [PATCH] driver/mtd/spi: Default page size Spansion flash "S25FS512S" is 256b

[Ashish Kumar]

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, May 9, 2018 4:44 PM
> To: Ashish Kumar 
> Cc: U-Boot Mailing List 
> Subject: Re: [U-Boot] [PATCH] driver/mtd/spi: Default page size Spansion flash
> "S25FS512S" is 256b
> 
> On Mon, May 7, 2018 at 4:01 PM, Ashish Kumar 
> wrote:
> > Signed-off-by: Ashish Kumar 
> > ---
> >  drivers/mtd/spi/spi_flash.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> > index 3d24a08..ce420cb 100644
> > --- a/drivers/mtd/spi/spi_flash.c
> > +++ b/drivers/mtd/spi/spi_flash.c
> > @@ -1046,14 +1046,15 @@ int spi_flash_scan(struct spi_flash *flash)
> > flash->shift = (flash->dual_flash & SF_DUAL_PARALLEL_FLASH) ? 1 : 0;
> > flash->page_size = info->page_size;
> > /*
> > -* The Spansion S25FL032P and S25FL064P have 256b pages, yet use the
> > -* 0x4d00 Extended JEDEC code. The rest of the Spansion flashes with
> > -* the 0x4d00 Extended JEDEC code have 512b pages. All of the others
> > -* have 256b pages.
> > +* The Spansion S25FS512S, S25FL032P and S25FL064P have 256b pages,
> > +* yet use the 0x4d00 Extended JEDEC code. The rest of the Spansion
> > +* flashes with the 0x4d00 Extended JEDEC code have 512b pages.
> > +* All of the others have 256b pages.
> >  */
> > if (JEDEC_EXT(info) == 0x4d00) {
> > if ((JEDEC_ID(info) != 0x0215) &&
> > -   (JEDEC_ID(info) != 0x0216))
> > +   (JEDEC_ID(info) != 0x0216) &&
> > +   (JEDEC_ID(info) != 0x0220))
> 
> 0220 is JEDEC ID for S25FS512S which is 512 is it? commit message says 256b?
Yes, 0220 is for S25FS512S. The loops says all JEDEC EXT starting 0x4d00 is 
512b, except 215,216 and 220.

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

Re: [U-Boot] [PATCH v3 0/8] riscv: Enable efi_loader support

[Rick Chen]

> >
> > Then I think if I don't want enter this auto flow, what can I do ?
> >
> > 1 Remove CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig  But it
> > still enter auto flow.
> >
> > 2 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the
> > CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h  And Remove
> > CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig  And it will NOT
> > enter auto flow
> >
> > #ifdef CONFIG_DISTRO_DEFAULTS
> > /* Enable distro boot */
> > #define BOOT_TARGET_DEVICES(func) \
> > func(MMC, mmc, 0) \
> > func(DHCP, dhcp, na)
> >
> > #include 
> >
> > #define CONFIG_EXTRA_ENV_SETTINGS   \
> > "kernel_addr_r=0x0008\0" \
> > "pxefile_addr_r=0x01f0\0" \
> > "scriptaddr=0x01f0\0" \
> > "fdt_addr_r=0x0200\0" \
> > "ramdisk_addr_r=0x0280\0" \
> > BOOTENV #endif
> >
> > 3 Add #ifdef CONFIG_DISTRO_DEFAULTS to encapsulate the
> > CONFIG_EXTRA_ENV_SETTINGS in nx25-ae250.h  And do NOT Remove
> > CONFIG_DISTRO_DEFAULTS=y from nx25-ae250_defconfig  But disable
> CONFIG_DISTRO_DEFAULTS from make menuconfig
> >General setup  --->
> >  [ ] Select defaults suitable for booting general purpose Linux
> > distributions  And it still enter auto flow
> >
> > Offering this information for you.
>
> This is the same for all distro enabled boards. The basic idea is that U-Boot 
> ships
> with something that "just boots" for simple use cases.
>
> If you want something more advanced, you usually want to put something very
> target specific in there anyway, such as "bootm $nor_flash". In that case, you
> adapt the CONFIG_BOOTCOMMAND parameter to whatever you want.
>
> The boot command can also be overridden using the environment. So if you have
> working environment store, you can change the U-Boot variable "bootcmd" and
> U-Boot will run that instead when it boots.
>
> The alternative to this default behavior would be no bootcmd at all which 
> means
> you just get dropped into the U-Boot prompt. While that's reasonably useful 
> for
> developers, it isn't for people deploying U-Boot on real target systems :).
>
>
> Alex

Thanks for your advises.

After you send those patchs into main trunk.
I will fetch and push them to u-boot-riscv.git :)

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

[U-Boot] [PATCH v2] efi_loader: fix off-by-one bug in efi_get_variable

[Ivan Gorinov]

efi_get_variable() always stores an extra zero byte after the output data.
When the returned data size matches the output buffer size, the extra zero
byte is stored past the end of the output buffer.

Signed-off-by: Ivan Gorinov 
---
 lib/efi_loader/efi_variable.c | 64 +--
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6c177da..b1e6a73 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -50,7 +50,7 @@
(strlen("efi_---_") + \
(MAX_VAR_NAME * MAX_UTF8_PER_UTF16))
 
-static int hex(unsigned char ch)
+static int hex(char ch)
 {
if (ch >= 'a' && ch <= 'f')
return ch-'a'+10;
@@ -61,44 +61,41 @@ static int hex(unsigned char ch)
return -1;
 }
 
-static const char *hex2mem(u8 *mem, const char *hexstr, int count)
+static int hex2mem(u8 *mem, const char *hexstr, int size)
 {
-   memset(mem, 0, count/2);
+   u8 data;
+   int nibble;
+   char ch;
+   int i, k;
 
-   do {
-   int nibble;
+   memset(mem, 0, size);
 
-   *mem = 0;
+   for (i = 0; i < size; i += 1) {
+   data = 0;
+   for (k = 0; k < 2; k += 1) {
+   ch = *(hexstr++);
 
-   if (!count || !*hexstr)
-   break;
-
-   nibble = hex(*hexstr);
-   if (nibble < 0)
-   break;
-
-   *mem = nibble;
-   count--;
-   hexstr++;
-
-   if (!count || !*hexstr)
-   break;
+   if (!ch) {
+   if (k == 0)
+   return i;
+   else
+   return -1;
+   }
 
-   nibble = hex(*hexstr);
-   if (nibble < 0)
-   break;
+   nibble = hex(ch);
+   if (nibble < 0)
+   return -1;
 
-   *mem = (*mem << 4) | nibble;
-   count--;
-   hexstr++;
-   mem++;
+   hexstr++;
 
-   } while (1);
+   data <<= 4;
+   data |= nibble;
 
-   if (*hexstr)
-   return hexstr;
+   }
+   mem[i] = data;
+   }
 
-   return NULL;
+   return i;
 }
 
 static char *mem2hex(char *hexstr, const u8 *mem, int count)
@@ -210,8 +207,11 @@ efi_status_t EFIAPI efi_get_variable(s16 *variable_name,
if ((s = prefix(val, "(blob)"))) {
unsigned len = strlen(s);
 
+   if (len & 1)
+   return EFI_EXIT(EFI_DEVICE_ERROR);
+
/* two characters per byte: */
-   len = DIV_ROUND_UP(len, 2);
+   len /= 2;
*data_size = len;
 
if (in_size < len)
@@ -220,7 +220,7 @@ efi_status_t EFIAPI efi_get_variable(s16 *variable_name,
if (!data)
return EFI_EXIT(EFI_INVALID_PARAMETER);
 
-   if (hex2mem(data, s, len * 2))
+   if (hex2mem(data, s, len) != len)
return EFI_EXIT(EFI_DEVICE_ERROR);
 
debug("%s: got value: \"%s\"\n", __func__, s);
-- 
2.7.4

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

Re: [U-Boot] [U-Boot,V2] imx: mx7: psci: add system reset support

[Peng Fan]

> -Original Message-
> From: Trent Piepho [mailto:tpie...@impinj.com]
> Sent: 2018年5月10日 3:22
> To: Peng Fan ; christian.gmei...@gmail.com; Anson
> Huang ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; sba...@denx.de
> Cc: Fabio Estevam 
> Subject: Re: [U-Boot,V2] imx: mx7: psci: add system reset support
> 
> On Wed, 2018-05-09 at 01:13 +, Peng Fan wrote:
> > > +0800, Anson Huang wrote:
> > > > > > Add i.MX7 PSCI system reset support, linux kernel now can use
> "reboot"
> > > > > > command to reset system.
> > > > >
> > > > >
> > > > > > +__secure void imx_system_reset(void) {
> > > > > > +   writew(1 << 2, WDOG1_BASE_ADDR); }
> > > > >
> > > > > This does not work properly on our board.
> > > >
> > > > You could try write 0x14 to WDOG1_BASE_ADDR to see whether it works.
> > > > Here using (1 << 2) triggers both SRS and WDOG_B which seems wrong.
> > >
> > > It works when the Linux driver does that and appears to work
> > > identically when uboot does it that way.
> > >
> > > Triggering both SRS and WDOG_B does not work as it causes a very
> > > short wdog_b assertion.
> >
> > Yes.
> 
> In case it wasn't clear, this code is in the new 2018.05 u-boot release and I 
> think
> will cause a problem for any imx7d board using the typical reset erratum 
> option
> of connecting wdog_b to a pfuze3000 pmic's pwrwon pin.
> 
> An external watchdog monitor chip, I think as used on sabreD for instance,
> might still respond to the short pulse and allow it work.

I understand this. 

> 
> > > There is a little difficulty here in just changing the code to use
> > > WCR_WDE|WCR_SRS, as that would be wrong if the board does not use an
> > > external signal.  The Linux driver uses the device tree to determine
> > > what to do, but this will not work for PSCI.
> >
> > U-Boot need parse the device tree and configure the WDOG accordingly.
> 
> Yes, but consider the difficulties:
> 
> There could be multiple Linux device trees, e.g. in a FIT image and chosen 
> based
> on board revision.  Should the PSCI code use the u-boot device tree?  Which
> would then need to also have this board revision support.  Or should it use 
> the
> Linux DT, which it would need to get information from when the kernel DT is
> prepared before boot?
> 
> Of the five external watchdog signals from the iMX7d, which one should be 
> used?
> I believe each imx watchdog configured in Linux will register a reset handler
> that are called in turn, so Linux should handle this ok.  The uboot PSCI 
> currently
> assumes wdog1 is the correct one to use.
> 
> The Linux driver interfaces with Linux pinctl to iomux the watchdog signal.  
> The
> PSCI code is assuming the wdog signal is correctly muxed.
> Default iomux values doesn't have any wdog signal routed to a pin.
> 
> Not impossible, but it is not so simple as the original three lines of code 
> might
> have made it seem at first glance.

The imx_system_reset might could be moved to per board specific. Then the board
owner could have their own imeplementation.

Stefano, what do you think?

> 
> If one has the Linux imx watchdog driver working, to use as watchdog, then one
> gets a wdog system reset for free with all the above taken care of.  Which
> makes me wonder if disabling the PSCI reset might not be a better option in 
> that
> situration.

Just wonder, since you are using psci, you have the power related code ready?

-Peng.

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

[U-Boot] [PATCH 2/2] gadget: f_thor: update to support more than 4GB file as thor 5.0

[Seung-Woo Kim]

During file download, it only uses 32bit variable for file size and
it limits maximum file size less than 4GB. Update to support more
than 4GB file with using two 32bit variables for file size as thor
protocol 5.0.

Signed-off-by: Seung-Woo Kim 
---
 drivers/usb/gadget/f_thor.c |   10 +++---
 drivers/usb/gadget/f_thor.h |2 +-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index 6d38cb6..c8eda05 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -262,8 +262,10 @@ static long long int process_rqt_download(const struct 
rqt_box *rqt)
 
switch (rqt->rqt_data) {
case RQT_DL_INIT:
-   thor_file_size = rqt->int_data[0];
-   debug("INIT: total %d bytes\n", rqt->int_data[0]);
+   thor_file_size = (unsigned long long int)rqt->int_data[0] +
+(((unsigned long long int)rqt->int_data[1])
+ << 32);
+   debug("INIT: total %llu bytes\n", thor_file_size);
break;
case RQT_DL_FILE_INFO:
file_type = rqt->int_data[0];
@@ -274,7 +276,9 @@ static long long int process_rqt_download(const struct 
rqt_box *rqt)
break;
}
 
-   thor_file_size = rqt->int_data[1];
+   thor_file_size = (unsigned long long int)rqt->int_data[1] +
+(((unsigned long long int)rqt->int_data[2])
+ << 32);
memcpy(f_name, rqt->str_data[0], F_NAME_BUF_SIZE);
f_name[F_NAME_BUF_SIZE] = '\0';
 
diff --git a/drivers/usb/gadget/f_thor.h b/drivers/usb/gadget/f_thor.h
index 47abc8a..8ba3fa2 100644
--- a/drivers/usb/gadget/f_thor.h
+++ b/drivers/usb/gadget/f_thor.h
@@ -34,7 +34,7 @@ struct usb_cdc_attribute_vendor_descriptor {
__u8 DAUValue;
 } __packed;
 
-#define VER_PROTOCOL_MAJOR 4
+#define VER_PROTOCOL_MAJOR 5
 #define VER_PROTOCOL_MINOR 0
 
 enum rqt {
-- 
1.7.9.5

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

[U-Boot] [PATCH 1/2] gadget: f_thor: fix filename overflow

[Seung-Woo Kim]

The thor sender can send filename without null character and it is
used without consideration of overflow. Actually, character array
for filename is assigned with DEFINE_CACHE_ALIGN_BUFFER() and it
is bigger than size of memcpy, so there was no real overflow.
Fix filename overflow for code level integrity.

Signed-off-by: Seung-Woo Kim 
---
 drivers/usb/gadget/f_thor.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index f874509..6d38cb6 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -47,7 +47,7 @@ DEFINE_CACHE_ALIGN_BUFFER(unsigned char, thor_rx_data_buf,
 /* ** */
 /* THOR protocol - transmission handling */
 /* ** */
-DEFINE_CACHE_ALIGN_BUFFER(char, f_name, F_NAME_BUF_SIZE);
+DEFINE_CACHE_ALIGN_BUFFER(char, f_name, F_NAME_BUF_SIZE + 1);
 static unsigned long long int thor_file_size;
 static int alt_setting_num;
 
@@ -276,6 +276,7 @@ static long long int process_rqt_download(const struct 
rqt_box *rqt)
 
thor_file_size = rqt->int_data[1];
memcpy(f_name, rqt->str_data[0], F_NAME_BUF_SIZE);
+   f_name[F_NAME_BUF_SIZE] = '\0';
 
debug("INFO: name(%s, %d), size(%llu), type(%d)\n",
  f_name, 0, thor_file_size, file_type);
-- 
1.7.9.5

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

[U-Boot] [PATCH v3 5/6] ARM: mvebu: a38x: restore support for setting timing

[Chris Packham]

This restores support for configuring the timing mode based on the
ddr_topology. This was originally implemented in commit 90bcc3d38d2b
("driver/ddr: Add support for setting timing in hws_topology_map") but
was removed as part of the upstream sync.

Signed-off-by: Chris Packham 
---

Changes in v3: None
Changes in v2: None

 board/CZ.NIC/turris_omnia/turris_omnia.c  | 6 --
 board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 3 ++-
 board/Marvell/db-88f6820-gp/db-88f6820-gp.c   | 3 ++-
 board/gdsys/a38x/controlcenterdc.c| 3 ++-
 board/solidrun/clearfog/clearfog.c| 3 ++-
 drivers/ddr/marvell/a38x/ddr3_training.c  | 8 
 drivers/ddr/marvell/a38x/ddr_topology_def.h   | 3 +++
 drivers/ddr/marvell/a38x/mv_ddr_plat.c| 5 -
 drivers/ddr/marvell/a38x/mv_ddr_topology.h| 6 ++
 9 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 29f81cdccfd4..da663cf1bb0c 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -214,7 +214,8 @@ static struct mv_ddr_topology_map board_topology_map_1g = {
MV_DDR_DIE_CAP_4GBIT,   /* mem_size */
DDR_FREQ_800,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_NORMAL} },  /* temperature */
+   MV_DDR_TEMP_NORMAL, /* temperature */
+   MV_DDR_TIM_2T} },   /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
@@ -235,7 +236,8 @@ static struct mv_ddr_topology_map board_topology_map_2g = {
MV_DDR_DIE_CAP_8GBIT,   /* mem_size */
DDR_FREQ_800,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_NORMAL} },  /* temperature */
+   MV_DDR_TEMP_NORMAL, /* temperature */
+   MV_DDR_TIM_2T} },   /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c 
b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
index e39dc75f9228..92d7ae77f07e 100644
--- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
+++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
@@ -69,7 +69,8 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_DIE_CAP_2GBIT,   /* mem_size */
DDR_FREQ_800,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_LOW} }, /* temperature */
+   MV_DDR_TEMP_LOW,/* temperature */
+   MV_DDR_TIM_DEFAULT} },  /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c 
b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
index ee12ca68ec2a..a8cfe8af0a88 100644
--- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
+++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
@@ -90,7 +90,8 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_DIE_CAP_4GBIT,   /* mem_size */
DDR_FREQ_800,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_LOW} }, /* temperature */
+   MV_DDR_TEMP_LOW,/* temperature */
+   MV_DDR_TIM_DEFAULT} },  /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
diff --git a/board/gdsys/a38x/controlcenterdc.c 
b/board/gdsys/a38x/controlcenterdc.c
index f750e47b7228..320bc100c9da 100644
--- a/board/gdsys/a38x/controlcenterdc.c
+++ b/board/gdsys/a38x/controlcenterdc.c
@@ -53,7 +53,8 @@ static struct mv_ddr_topology_map ddr_topology_map = {
MV_DDR_DIE_CAP_4GBIT,   /* mem_size */
DDR_FREQ_533,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_LOW} }, /* temperature */
+   MV_DDR_TEMP_LOW,/* temperature */
+   MV_DDR_TIM_DEFAULT} },  /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
diff --git a/board/solidrun/clearfog/clearfog.c 

[U-Boot] [PATCH v3 2/6] ARM: mvebu: a38x: move sys_env_device_rev_get

[Chris Packham]

Move sys_env_device_rev_get() from the ddr training code to
sys_env_lib.c (which currently resides with the serdes code). This
brings sys_env_device_rev_get() into line with sys_env_device_id_get()
and sys_env_model_get().

Signed-off-by: Chris Packham 
---

Changes in v3: None
Changes in v2:
- remove unused #include

 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c | 26 +--
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  1 -
 drivers/ddr/marvell/a38x/ddr3_init.c  | 24 -
 3 files changed, 24 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c 
b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
index d26068e1d774..d387893af37d 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
@@ -12,8 +12,6 @@
 #include "seq_exec.h"
 #include "sys_env_lib.h"
 
-#include "../../../drivers/ddr/marvell/a38x/ddr3_a38x.h"
-
 #ifdef CONFIG_ARMADA_38X
 enum unit_id sys_env_soc_unit_nums[MAX_UNITS_ID][MAX_DEV_ID_NUM] = {
 /* 68206810 6811 6828 */
@@ -234,3 +232,27 @@ u32 sys_env_device_id_get(void)
 
return g_dev_id;
 }
+
+/*
+ * sys_env_device_rev_get - Get Marvell controller device revision number
+ *
+ * DESCRIPTION:
+ *   This function returns 8bit describing the device revision as defined
+ *   Revision ID Register.
+ *
+ * INPUT:
+ *   None.
+ *
+ * OUTPUT:
+ *   None.
+ *
+ * RETURN:
+ *   8bit desscribing Marvell controller revision number
+ */
+u8 sys_env_device_rev_get(void)
+{
+   u32 value;
+
+   value = reg_read(DEV_VERSION_ID_REG);
+   return (value & (REVISON_ID_MASK)) >> REVISON_ID_OFFS;
+}
diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h 
b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
index c5461067fd88..953445b7d7ae 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
+++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
@@ -7,7 +7,6 @@
 #define _SYS_ENV_LIB_H
 
 #include "../../../drivers/ddr/marvell/a38x/ddr3_init.h"
-#include "../../../drivers/ddr/marvell/a38x/ddr3_hws_hw_training.h"
 
 /* Serdes definitions */
 #define COMMON_PHY_BASE_ADDR   0x18300
diff --git a/drivers/ddr/marvell/a38x/ddr3_init.c 
b/drivers/ddr/marvell/a38x/ddr3_init.c
index 6ee13c10e493..1c5b1f75ca4f 100644
--- a/drivers/ddr/marvell/a38x/ddr3_init.c
+++ b/drivers/ddr/marvell/a38x/ddr3_init.c
@@ -107,30 +107,6 @@ static int ddr3_hws_tune_training_params(u8 dev_num);
 /* A39x revisions */
 #define MV_88F69XX_Z1_ID   0x2
 
-/*
- * sys_env_device_rev_get - Get Marvell controller device revision number
- *
- * DESCRIPTION:
- *   This function returns 8bit describing the device revision as defined
- *   Revision ID Register.
- *
- * INPUT:
- *   None.
- *
- * OUTPUT:
- *   None.
- *
- * RETURN:
- *   8bit desscribing Marvell controller revision number
- */
-u8 sys_env_device_rev_get(void)
-{
-   u32 value;
-
-   value = reg_read(DEV_VERSION_ID_REG);
-   return (value & (REVISON_ID_MASK)) >> REVISON_ID_OFFS;
-}
-
 /*
  * sys_env_dlb_config_ptr_get
  *
-- 
2.17.0

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

[U-Boot] [PATCH v3 6/6] ARM: mvebu: a38x: use non-zero size for ddr scrubbing

[Chris Packham]

From: Chris Packham 

Make ddr3_calc_mem_cs_size() global scope and use it in
ddr3_new_tip_ecc_scrub to correctly initialize all of DDR memory.

Signed-off-by: Chris Packham 
---

Changes in v3: None
Changes in v2: None

 drivers/ddr/marvell/a38x/mv_ddr_plat.c | 2 +-
 drivers/ddr/marvell/a38x/mv_ddr_plat.h | 1 +
 drivers/ddr/marvell/a38x/xor.c | 3 +++
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c 
b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
index 2070bb38b099..2f318cb9ea7b 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
@@ -995,7 +995,7 @@ static u32 ddr3_get_device_size(u32 cs)
}
 }
 
-static int ddr3_calc_mem_cs_size(u32 cs, uint64_t *cs_size)
+int ddr3_calc_mem_cs_size(u32 cs, uint64_t *cs_size)
 {
u32 cs_mem_size;
 
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.h 
b/drivers/ddr/marvell/a38x/mv_ddr_plat.h
index 61f10302fcca..9c5fdecd9341 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_plat.h
+++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.h
@@ -232,4 +232,5 @@ u32 mv_ddr_dm_pad_get(void);
 int mv_ddr_pre_training_fixup(void);
 int mv_ddr_post_training_fixup(void);
 int mv_ddr_manual_cal_do(void);
+int ddr3_calc_mem_cs_size(u32 cs, uint64_t *cs_size);
 #endif /* _MV_DDR_PLAT_H */
diff --git a/drivers/ddr/marvell/a38x/xor.c b/drivers/ddr/marvell/a38x/xor.c
index 024cecd777c5..f859596d8953 100644
--- a/drivers/ddr/marvell/a38x/xor.c
+++ b/drivers/ddr/marvell/a38x/xor.c
@@ -347,6 +347,9 @@ void ddr3_new_tip_ecc_scrub(void)
for (cs_c = 0; cs_c < max_cs; cs_c++)
cs_ena |= 1 << cs_c;
 
+   /* assume that all CS have same size */
+   ddr3_calc_mem_cs_size(0, _mem_size);
+
mv_sys_xor_init(max_cs, cs_ena, cs_mem_size, 0);
total_mem_size = max_cs * cs_mem_size;
mv_xor_mem_init(0, 0, total_mem_size, 0xdeadbeef, 0xdeadbeef);
-- 
2.17.0

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

[U-Boot] [PATCH v3 3/6] ARM: mvebu: a38x: remove some unused code

[Chris Packham]

No in-tree code defines SUPPORT_STATIC_DUNIT_CONFIG or
STATIC_ALGO_SUPPORT. Remove ddr3_a38x_mc_static.h and use unifdef to
remove unused sections in the rest of the ddr/marvell/a38x code.

Signed-off-by: Chris Packham 
---
Much of this code is moved/removed in the updated DDR code so this
commit helps minimise the final delta.

Changes in v3: None
Changes in v2: None

 drivers/ddr/marvell/a38x/ddr3_a38x.c  |  51 --
 .../ddr/marvell/a38x/ddr3_a38x_mc_static.h| 225 -
 drivers/ddr/marvell/a38x/ddr3_debug.c |   9 -
 drivers/ddr/marvell/a38x/ddr3_init.c  |  29 --
 drivers/ddr/marvell/a38x/ddr3_init.h  |   1 -
 drivers/ddr/marvell/a38x/ddr3_training.c  |  41 --
 .../ddr/marvell/a38x/ddr3_training_static.c   | 438 --
 7 files changed, 794 deletions(-)
 delete mode 100644 drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h

diff --git a/drivers/ddr/marvell/a38x/ddr3_a38x.c 
b/drivers/ddr/marvell/a38x/ddr3_a38x.c
index e152e842aef1..c356d0900870 100644
--- a/drivers/ddr/marvell/a38x/ddr3_a38x.c
+++ b/drivers/ddr/marvell/a38x/ddr3_a38x.c
@@ -76,41 +76,6 @@ struct trip_delay_element 
a38x_board_round_trip_delay_array[] = {
{ 4282, 6160 }  /* ECC PUP */
 };
 
-#ifdef STATIC_ALGO_SUPPORT
-/* package trace */
-static struct trip_delay_element a38x_package_round_trip_delay_array[] = {
-   /* IF BUS DQ_DELAY CK_DELAY */
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 }
-};
-
-static int a38x_silicon_delay_offset[] = {
-   /* board 0 */
-   0,
-   /* board 1 */
-   0,
-   /* board 2 */
-   0
-};
-#endif
 
 static u8 a38x_bw_per_freq[DDR_FREQ_LIMIT] = {
0x3,/* DDR_FREQ_100 */
@@ -367,22 +332,6 @@ static int ddr3_tip_init_a38x_silicon(u32 dev_num, u32 
board_id)
 
ddr3_tip_register_dq_table(dev_num, dq_bit_map_2_phy_pin);
 
-#ifdef STATIC_ALGO_SUPPORT
-   {
-   struct hws_tip_static_config_info static_config;
-   u32 board_offset =
-   board_id * A38X_NUMBER_OF_INTERFACES *
-   tm->num_of_bus_per_interface;
-
-   static_config.silicon_delay =
-   a38x_silicon_delay_offset[board_id];
-   static_config.package_trace_arr =
-   a38x_package_round_trip_delay_array;
-   static_config.board_trace_arr =
-   _board_round_trip_delay_array[board_offset];
-   ddr3_tip_init_static_config_db(dev_num, _config);
-   }
-#endif
status = ddr3_tip_a38x_get_init_freq(dev_num, _freq);
if (MV_OK != status) {
DEBUG_TRAINING_ACCESS(DEBUG_LEVEL_ERROR,
diff --git a/drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h 
b/drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h
deleted file mode 100644
index a5b4f7045895..
--- a/drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h
+++ /dev/null
@@ -1,225 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (C) Marvell International Ltd. and its affiliates
- */
-
-#ifndef _DDR3_A38X_MC_STATIC_H
-#define _DDR3_A38X_MC_STATIC_H
-
-#include "ddr3_a38x.h"
-
-#ifdef SUPPORT_STATIC_DUNIT_CONFIG
-
-#ifdef CONFIG_CUSTOMER_BOARD_SUPPORT
-static struct reg_data ddr3_customer_800[] = {
-   /* parameters for customer board (based on 800MHZ) */
-   {0x1400,0x7b00cc30, 0x},
-   {0x1404,0x36301820, 0x},
-   {0x1408,0x5415baab, 0x},
-   {0x140c,0x38411def, 0x},
-   {0x1410,0x1830, 0x},
-   {0x1414,0x0700, 0x},
-   {0x1424,0x0060f3ff, 0x},
-   {0x1428,0x0011a940, 0x},
-   {0x142c,0x28c5134,  0x},
-   {0x1474,0x, 0x},
-   {0x147c,0xd771, 0x},
-   {0x1494,0x0003, 0x},
-   {0x149c,0x0300, 0x},
-   {0x14a8,0x, 0x},
-   {0x14cc,0xbd09000d, 0x},
-   {0x1504,0xfff1, 0x},
-   {0x150c,0xffe5, 0x},
-   {0x1514,0x, 0x},
-   {0x151c,0x, 0x},
-   {0x1538,0x0b0b, 0x},
-   {0x153c,0x0c0c, 0x},
-   {0x15d0,0x0670, 0x},
-   {0x15d4,0x0046, 0x},
-   {0x15d8,0x0010, 0x},
-   {0x15dc,0x, 0x},
-   {0x15e0,0x0023, 0x},
-   {0x15e4,0x00203c18, 0x},
-   

[U-Boot] [PATCH v3 1/6] ARM: mvebu: a38x: move definition of PEX_CFG_DIRECT_ACCESS

[Chris Packham]

PEX_CFG_DIRECT_ACCESS was defined in ddr3_hws_hw_training_def.h despite
only being used in the serdes code. Move this definition to ctrl_pex.h
where all the other PEX defines are. Also remove the duplicate
definition of PEX_DEVICE_AND_VENDOR_ID which is already defined in
ctrl_pex.h.

Signed-off-by: Chris Packham 
---

Changes in v3: None
Changes in v2: None

 arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h  | 1 +
 drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h 
b/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
index 53ed4eab3203..3f30b6bf972e 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
+++ b/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
@@ -46,6 +46,7 @@
 
 /* Controller revision info */
 #define PEX_DEVICE_AND_VENDOR_ID   0x000
+#define PEX_CFG_DIRECT_ACCESS(if, reg) (PEX_IF_REGS_BASE(if) + (reg))
 
 /* PCI Express Configuration Address Register */
 #define PXCAR_REG_NUM_OFFS 2
diff --git a/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h 
b/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h
index c99437be22aa..a87fc404cb7d 100644
--- a/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h
+++ b/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h
@@ -421,8 +421,6 @@
 
 /* Power Management Clock Gating Control Register */
 #define POWER_MNG_CTRL_REG 0x18220
-#define PEX_DEVICE_AND_VENDOR_ID   0x000
-#define PEX_CFG_DIRECT_ACCESS(if, reg) (PEX_IF_REGS_BASE(if) + (reg))
 #define PMC_PEXSTOPCLOCK_OFFS(p)   ((p) < 8 ? (5 + (p)) : (18 + (p)))
 #define PMC_PEXSTOPCLOCK_MASK(p)   (1 << PMC_PEXSTOPCLOCK_OFFS(p))
 #define PMC_PEXSTOPCLOCK_EN(p) (1 << PMC_PEXSTOPCLOCK_OFFS(p))
-- 
2.17.0

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

[U-Boot] [PATCH v3 0/6] ARM: mvebu: a38x: updates to ddr training code

[Chris Packham]

This series updates the ddr training code in u-boot with the latest
publicly available version from Marvell which can be found at
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git
(mv_ddr-armada-17.10 branch).

I've tried to make the delta as small as possible without breaking
bisect-ability.

The first 2 patches have already been sent as
http://patchwork.ozlabs.org/patch/894866/ and
http://patchwork.ozlabs.org/patch/894865/

The bulk of the changes are in patch 4. Naturally this doesn't pass
checkpatch.pl but I'm erring on the side of being able to diff with the
upstream source. Also due to it's size this patch may not make it to the
mailing list so the full series can be retrieved from the mv-ddr branch
of https://github.com/cpackham/u-boot.git.

I've tested this series on the db-88f6820-amc board and on a custom
board that is not upstream (yet). I've also build tested the other a38x
boards. More testing on actual hardware would be greatly appreciated.

This version is rebased against master to mop up the SPDX changes.

Changes in v3:
- Update to current SPDX style

Changes in v2:
- remove unused #include

Chris Packham (6):
  ARM: mvebu: a38x: move definition of PEX_CFG_DIRECT_ACCESS
  ARM: mvebu: a38x: move sys_env_device_rev_get
  ARM: mvebu: a38x: remove some unused code
  ARM: mvebu: a38x: sync ddr training code with upstream
  ARM: mvebu: a38x: restore support for setting timing
  ARM: mvebu: a38x: use non-zero size for ddr scrubbing

 arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h|1 +
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |   26 +-
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |1 -
 board/CZ.NIC/turris_omnia/turris_omnia.c  |   38 +-
 board/Marvell/db-88f6820-amc/db-88f6820-amc.c |   21 +-
 board/Marvell/db-88f6820-gp/db-88f6820-gp.c   |   21 +-
 board/gdsys/a38x/controlcenterdc.c|   22 +-
 board/solidrun/clearfog/clearfog.c|   21 +-
 drivers/ddr/marvell/a38x/Makefile |   10 +-
 drivers/ddr/marvell/a38x/ddr3_a38x.c  |  736 
 drivers/ddr/marvell/a38x/ddr3_a38x.h  |   92 -
 .../ddr/marvell/a38x/ddr3_a38x_mc_static.h|  225 ---
 drivers/ddr/marvell/a38x/ddr3_a38x_topology.h |   21 -
 drivers/ddr/marvell/a38x/ddr3_a38x_training.c |   39 -
 drivers/ddr/marvell/a38x/ddr3_debug.c |  742 +---
 .../ddr/marvell/a38x/ddr3_hws_hw_training.c   |  147 --
 .../ddr/marvell/a38x/ddr3_hws_hw_training.h   |   48 -
 .../marvell/a38x/ddr3_hws_hw_training_def.h   |  463 -
 .../ddr/marvell/a38x/ddr3_hws_sil_training.h  |   16 -
 drivers/ddr/marvell/a38x/ddr3_init.c  |  798 ++---
 drivers/ddr/marvell/a38x/ddr3_init.h  |  300 +---
 drivers/ddr/marvell/a38x/ddr3_logging_def.h   |   10 +-
 .../ddr/marvell/a38x/ddr3_patterns_64bit.h|1 +
 drivers/ddr/marvell/a38x/ddr3_topology_def.h  |6 +-
 drivers/ddr/marvell/a38x/ddr3_training.c  | 1491 ++---
 drivers/ddr/marvell/a38x/ddr3_training_bist.c |  548 --
 .../a38x/ddr3_training_centralization.c   |  108 +-
 drivers/ddr/marvell/a38x/ddr3_training_db.c   |  267 ++-
 .../ddr/marvell/a38x/ddr3_training_hw_algo.c  |   98 +-
 drivers/ddr/marvell/a38x/ddr3_training_ip.h   |   19 +-
 .../ddr/marvell/a38x/ddr3_training_ip_bist.h  |6 +-
 .../ddr/marvell/a38x/ddr3_training_ip_db.h|   71 +-
 .../ddr/marvell/a38x/ddr3_training_ip_def.h   |   34 +-
 .../marvell/a38x/ddr3_training_ip_engine.c| 1134 -
 .../marvell/a38x/ddr3_training_ip_engine.h|9 +-
 .../ddr/marvell/a38x/ddr3_training_ip_flow.h  |  305 +---
 .../marvell/a38x/ddr3_training_ip_prv_if.h|   17 +-
 .../marvell/a38x/ddr3_training_ip_static.h|   30 -
 .../ddr/marvell/a38x/ddr3_training_leveling.c | 1347 ---
 .../ddr/marvell/a38x/ddr3_training_leveling.h |2 +-
 drivers/ddr/marvell/a38x/ddr3_training_pbs.c  |  201 ++-
 .../ddr/marvell/a38x/ddr3_training_static.c   |  538 --
 drivers/ddr/marvell/a38x/ddr_ml_wrapper.h |  148 ++
 drivers/ddr/marvell/a38x/ddr_topology_def.h   |   82 +-
 .../ddr/marvell/a38x/mv_ddr_build_message.c   |1 +
 drivers/ddr/marvell/a38x/mv_ddr_common.c  |   47 +
 drivers/ddr/marvell/a38x/mv_ddr_common.h  |   20 +
 drivers/ddr/marvell/a38x/mv_ddr_plat.c| 1450 
 drivers/ddr/marvell/a38x/mv_ddr_plat.h|  236 +++
 drivers/ddr/marvell/a38x/mv_ddr_regs.h|  446 +
 drivers/ddr/marvell/a38x/mv_ddr_spd.c |  377 +
 drivers/ddr/marvell/a38x/mv_ddr_spd.h |  289 
 drivers/ddr/marvell/a38x/mv_ddr_sys_env_lib.c |  102 ++
 drivers/ddr/marvell/a38x/mv_ddr_sys_env_lib.h |  117 ++
 drivers/ddr/marvell/a38x/mv_ddr_topology.c|  197 +++
 drivers/ddr/marvell/a38x/mv_ddr_topology.h|  129 ++
 drivers/ddr/marvell/a38x/seq_exec.h   |   64 +
 drivers/ddr/marvell/a38x/silicon_if.h |   16 -
 drivers/ddr/marvell/a38x/xor.c|  185 +-
 drivers/ddr/marvell/a38x/xor.h|3 +-
 60 files 

Re: [U-Boot] [PATCH 09/12] ARM: kirkwood: Add device-tree for nsa310s

[Chris Packham]

On Thu, May 10, 2018 at 6:27 AM bodhi bodhi  wrote:

> Hi Chris,

> What we have in Linux mainline is Zyxel NSA310 (Marvell 88f6281). The
Zyxel NSA310S (Marvell 88f6702) is actually a different box, which has not
been mainlined yet.

> By the way, there are 3 variations of the Zyxel NSA310 box. This box has
some combination of: red USB Led, lm85 sensor, adt7476 sensor that make
them slighly different. The mainlined NSA310 DTS is for the one with
adt7476 sensor.


Ah OK. I did see 2 boards in the kernel, this was one of the "educated
guesses" which turns out not to to be a good guess. For now I'll just drop
this conversion from the series.


> Regards
> bodhi


> On Tue, May 8, 2018 at 3:34 AM, Chris Packham 
wrote:

>> Import the dts files from Linux 4.17 and enable CONFIG_OF_CONTROL.

>> Signed-off-by: Chris Packham 
>> ---

>>   arch/arm/dts/kirkwood-nsa310.dts | 139 
>>   arch/arm/dts/kirkwood-nsa3x0-common.dtsi | 158 +++
>>   configs/nsa310s_defconfig|   3 +-
>>   3 files changed, 299 insertions(+), 1 deletion(-)
>>   create mode 100644 arch/arm/dts/kirkwood-nsa310.dts
>>   create mode 100644 arch/arm/dts/kirkwood-nsa3x0-common.dtsi

>> diff --git a/arch/arm/dts/kirkwood-nsa310.dts
b/arch/arm/dts/kirkwood-nsa310.dts
>> new file mode 100644
>> index ..9b861c2e76c5
>> --- /dev/null
>> +++ b/arch/arm/dts/kirkwood-nsa310.dts
>> @@ -0,0 +1,139 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/dts-v1/;
>> +
>> +#include "kirkwood-nsa3x0-common.dtsi"
>> +
>> +/ {
>> +   compatible = "zyxel,nsa310", "marvell,kirkwood-88f6281",
"marvell,kirkwood";
>> +
>> +   memory {
>> +   device_type = "memory";
>> +   reg = <0x 0x1000>;
>> +   };
>> +
>> +   chosen {
>> +   bootargs = "console=ttyS0,115200";
>> +   stdout-path = 
>> +   };
>> +
>> +   ocp@f100 {
>> +   pinctrl: pin-controller@1 {
>> +   pinctrl-0 = <_unknown>;
>> +   pinctrl-names = "default";
>> +
>> +   pmx_led_esata_green: pmx-led-esata-green {
>> +   marvell,pins = "mpp12";
>> +   marvell,function = "gpio";
>> +   };
>> +
>> +   pmx_led_esata_red: pmx-led-esata-red {
>> +   marvell,pins = "mpp13";
>> +   marvell,function = "gpio";
>> +   };
>> +
>> +   pmx_led_usb_green: pmx-led-usb-green {
>> +   marvell,pins = "mpp15";
>> +   marvell,function = "gpio";
>> +   };
>> +
>> +   pmx_led_usb_red: pmx-led-usb-red {
>> +   marvell,pins = "mpp16";
>> +   marvell,function = "gpio";
>> +   };
>> +
>> +   pmx_led_sys_green: pmx-led-sys-green {
>> +   marvell,pins = "mpp28";
>> +   marvell,function = "gpio";
>> +   };
>> +
>> +   pmx_led_sys_red: pmx-led-sys-red {
>> +   marvell,pins = "mpp29";
>> +   marvell,function = "gpio";
>> +   };
>> +
>> +   pmx_led_hdd_green: pmx-led-hdd-green {
>> +   marvell,pins = "mpp41";
>> +   marvell,function = "gpio";
>> +   };
>> +
>> +   pmx_led_hdd_red: pmx-led-hdd-red {
>> +   marvell,pins = "mpp42";
>> +   marvell,function = "gpio";
>> +   };
>> +
>> +   pmx_unknown: pmx-unknown {
>> +   marvell,pins = "mpp44";
>> +   marvell,function = "gpio";
>> +   };
>> +
>> +   };
>> +
>> +   i2c@11000 {
>> +   status = "okay";
>> +
>> +   adt7476: adt7476a@2e {
>> +   compatible = "adi,adt7476";
>> +   reg = <0x2e>;
>> +   };
>> +   };
>> +   };
>> +
>> +   gpio-leds {
>> +   compatible = "gpio-leds";
>> +   pinctrl-0 = <_led_esata_green _led_esata_red
>> +_led_usb_green _led_usb_red
>> +_led_sys_green _led_sys_red
>> +_led_copy_green _led_copy_red
>> +_led_hdd_green _led_hdd_red>;
>> +   pinctrl-names = "default";
>> +
>> +   green-sys {
>> +   label = "nsa310:green:sys";

Re: [U-Boot] [U-Boot,V2] imx: mx7: psci: add system reset support

[Trent Piepho]

On Wed, 2018-05-09 at 01:13 +, Peng Fan wrote:
> > +0800, Anson Huang wrote:
> > > > > Add i.MX7 PSCI system reset support, linux kernel now can use "reboot"
> > > > > command to reset system.
> > > > 
> > > > 
> > > > > +__secure void imx_system_reset(void) {
> > > > > + writew(1 << 2, WDOG1_BASE_ADDR); }
> > > > 
> > > > This does not work properly on our board.
> > > 
> > > You could try write 0x14 to WDOG1_BASE_ADDR to see whether it works.
> > > Here using (1 << 2) triggers both SRS and WDOG_B which seems wrong.
> > 
> > It works when the Linux driver does that and appears to work identically 
> > when
> > uboot does it that way.
> > 
> > Triggering both SRS and WDOG_B does not work as it causes a very short
> > wdog_b assertion.
> 
> Yes.

In case it wasn't clear, this code is in the new 2018.05 u-boot release
and I think will cause a problem for any imx7d board using the typical
reset erratum option of connecting wdog_b to a pfuze3000 pmic's pwrwon
pin.

An external watchdog monitor chip, I think as used on sabreD for
instance, might still respond to the short pulse and allow it work.

> > There is a little difficulty here in just changing the code to use
> > WCR_WDE|WCR_SRS, as that would be wrong if the board does not use an
> > external signal.  The Linux driver uses the device tree to determine what 
> > to do,
> > but this will not work for PSCI.
> 
> U-Boot need parse the device tree and configure the WDOG accordingly.

Yes, but consider the difficulties:

There could be multiple Linux device trees, e.g. in a FIT image and
chosen based on board revision.  Should the PSCI code use the u-boot
device tree?  Which would then need to also have this board revision
support.  Or should it use the Linux DT, which it would need to get
information from when the kernel DT is prepared before boot?

Of the five external watchdog signals from the iMX7d, which one should
be used?  I believe each imx watchdog configured in Linux will register
a reset handler that are called in turn, so Linux should handle this
ok.  The uboot PSCI currently assumes wdog1 is the correct one to use.

The Linux driver interfaces with Linux pinctl to iomux the watchdog
signal.  The PSCI code is assuming the wdog signal is correctly muxed.
Default iomux values doesn't have any wdog signal routed to a pin.

Not impossible, but it is not so simple as the original three lines of
code might have made it seem at first glance.

If one has the Linux imx watchdog driver working, to use as watchdog,
then one gets a wdog system reset for free with all the above taken
care of.  Which makes me wonder if disabling the PSCI reset might not
be a better option in that situration.

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

Re: [U-Boot] [PATCHv2 2/3] buildman: support newer gcc versions from kernel.org

[Tom Rini]

On Wed, May 09, 2018 at 07:16:34AM -0400, Tom Rini wrote:
> On Wed, May 09, 2018 at 12:27:38PM +0200, Daniel Schwierzeck wrote:
> > 
> > 
> > On 08.05.2018 02:50, Tom Rini wrote:
> > > From: Daniel Schwierzeck 
> > > 
> > > Add support for gcc versions 7.3.0, 6.4.0 and 4.9.4.
> > > 
> > > Also use a regex for matching the tarball names. Some gcc versions
> > > use '-ARCH-' instead of '_ARCH-'.
> > > 
> > > As part of this, we switch TravisCI to also using these toolchains for
> > > all platforms.
> > > 
> > > Signed-off-by: Daniel Schwierzeck 
> > > Signed-off-by: Tom Rini 
> > > ---
> > > Changes in v2:
> > > - Change to only 7.3.0 / 6.4.0 / 4.9.4 for gcc versions.  Update
> > >   .travis.yml for x86_64 toolchain and fetch all toolchains.
> > > - Fold in the old patch I had to expand and update SH builds as we
> > >   cannot build without those changes.
> > > ---
> > >  .travis.yml | 38 ++
> > >  tools/buildman/toolchain.py |  6 +++---
> > >  2 files changed, 29 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/.travis.yml b/.travis.yml
> > > index 57f38e11698b..b07ce9b8ceb4 100644
> > > --- a/.travis.yml
> > > +++ b/.travis.yml
> > > @@ -21,7 +21,6 @@ addons:
> > >  - python-virtualenv
> > >  - swig
> > >  - libpython-dev
> > > -- gcc-powerpc-linux-gnu
> > >  - iasl
> > >  - grub-efi-ia32-bin
> > >  - rpm2cpio
> > > @@ -29,6 +28,11 @@ addons:
> > >  - device-tree-compiler
> > >  - lzop
> > >  
> > > +before_install:
> > > + - sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
> > > + - sudo apt-get update -q
> > > + - sudo apt-get install libisl15 -y
> > > +
> > >  install:
> > >   # Clone uboot-test-hooks
> > >   - git clone --depth=1 git://github.com/swarren/uboot-test-hooks.git 
> > > /tmp/uboot-test-hooks
> > > @@ -36,10 +40,8 @@ install:
> > >   - ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname`
> > >   # prepare buildman environment
> > >   - echo -e "[toolchain]\nroot = /usr" > ~/.buildman
> > > - - echo -e "aarch64 = 
> > > /tmp/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu" >> ~/.buildman
> > > - - echo -e "arm = 
> > > /tmp/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf" >> ~/.buildman
> > >   - echo -e "arc = 
> > > /tmp/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install" >> 
> > > ~/.buildman
> > > - - echo -e "\n[toolchain-alias]\nsh = sh4\nopenrisc = or32" >> 
> > > ~/.buildman
> > > + - echo -e "\n[toolchain-alias]\nsh = sh2" >> ~/.buildman
> > >   - cat ~/.buildman
> > >   - virtualenv /tmp/venv
> > >   - . /tmp/venv/bin/activate
> > > @@ -64,10 +66,10 @@ before_script:
> > >- if [[ "${TOOLCHAIN}" == *microblaze* ]]; then 
> > > ./tools/buildman/buildman --fetch-arch microblaze ; fi
> > >- if [[ "${TOOLCHAIN}" == *mips* ]]; then ./tools/buildman/buildman 
> > > --fetch-arch mips ; fi
> > >- if [[ "${TOOLCHAIN}" == *or32* ]]; then ./tools/buildman/buildman 
> > > --fetch-arch or32 ; fi
> > > -  - if [[ "${TOOLCHAIN}" == *sh4* ]]; then ./tools/buildman/buildman 
> > > --fetch-arch sh4 ; fi
> > > +  - if [[ "${TOOLCHAIN}" == *sh* ]]; then ./tools/buildman/buildman 
> > > --fetch-arch sh2 ; fi
> > >- if [[ "${TOOLCHAIN}" == *x86_64* ]]; then
> > >./tools/buildman/buildman --fetch-arch x86_64;
> > > -  echo -e "\n[toolchain-prefix]\nx86 = 
> > > ${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-"
> > >  >> ~/.buildman;
> > > +  echo -e "\n[toolchain-prefix]\nx86 = 
> > > ${HOME}/.buildman-toolchains/gcc-7.3.0-nolibc/x86_64-linux/bin/x86_64-linux-"
> > >  >> ~/.buildman;
> > 
> > you could add "x86 = x86_64" to section [toolchain-alias] to avoid
> > hard-coding this
> 
> There's some amount of "fun" going on in order to build all of
> arch/{sandbox,x86} with the same toolchain.  I'll double check what we
> can get away with in terms of toolchain-prefix vs toolchain-alias.
> Thanks!

Building 32bit x86 with the toolchain this way _seems_ to be what
triggers https://travis-ci.org/trini/u-boot/jobs/376853382#L916 which is
pretty odd.  I'm confirming right now what I suspect...

-- 
Tom


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

Re: [U-Boot] [PATCH 1/1] arm: print instructions pointed to by pc

[Alexander Graf]

> Am 09.05.2018 um 22:16 schrieb Heinrich Schuchardt :
> 
> If an exception occurs in a loaded image and the relocation offset is
> unknown, it is helful to know the instructions pointed to by the
> program counter. This patch adds the missing output.
> 
> A possible output is:
> *pc: defe e7ff 8010 e8bd abb9 9ffc f7d5 9ffc
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> arch/arm/lib/interrupts.c | 4 
> 1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
> index cda4d48460..24fa3d433d 100644
> --- a/arch/arm/lib/interrupts.c
> +++ b/arch/arm/lib/interrupts.c
> @@ -60,6 +60,8 @@ static void show_efi_loaded_images(struct pt_regs *regs)
> void show_regs (struct pt_regs *regs)
> {
>unsigned long __maybe_unused flags;
> +/* The least significant bit chooses thumb, remove it. */
> +u16 *pc = (u16 *)(instruction_pointer(regs) & ~1);

u16 values are quite bad for this. Non-thumb instruuctions are 32bit, so will 
be swapped in the output. Even with thumb you may get 32bit long ones.

Better just output everything as bytes. Then a simple xxd -ps -r can convert it 
into a binary you can throw objdump on.

Alex

>const char __maybe_unused *processor_modes[] = {
>"USER_26","FIQ_26","IRQ_26","SVC_26",
>"UK4_26","UK5_26","UK6_26","UK7_26",
> @@ -97,6 +99,8 @@ void show_regs (struct pt_regs *regs)
>fast_interrupts_enabled (regs) ? "on" : "off",
>processor_modes[processor_mode (regs)],
>thumb_mode (regs) ? " (T)" : "");
> +printf("*pc: %04x %04x %04x %04x %04x %04x %04x %04x\n",
> +   pc[0], pc[1], pc[2], pc[3], pc[4], pc[5], pc[6], pc[7]);
> }
> 
> /* fixup PC to point to the instruction leading to the exception */
> -- 
> 2.17.0
> 

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

Re: [U-Boot] [PATCH 1/1] efi_loader: always check parameters in efi_cout_query_mode()

[Heinrich Schuchardt]

On 05/09/2018 11:18 PM, Tom Rini wrote:
> On Wed, May 09, 2018 at 11:13:37PM +0200, Heinrich Schuchardt wrote:
>> On 05/09/2018 10:00 PM, Tom Rini wrote:
>>> On Sun, Apr 29, 2018 at 08:02:46PM +0200, Heinrich Schuchardt wrote:
>>>
 If we cannot determine the size of the serial terminal we still have
 to check the parameters of efi_cout_query_mode().

 Querying the size of the serial terminal drains the keyboard buffer.
 So make sure we do this during the initialization and not in the midst
 of an EFI application.

 Signed-off-by: Heinrich Schuchardt 
>>
>> 
>>
>>>
>>> Even without this patch with a newer gcc we see:
>>> https://travis-ci.org/trini/u-boot/jobs/376853382#L916
>>>
>>> Can you address that while doing this fixup as well?  Thanks!
>>>
>>
>> I don't doubt there is an issue. But why don't we see the error outside
>> of Travis CI? Do we set different flags when building?
>>
>> Can't see it with
>> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
>> nor with
>> gcc (Debian 7.3.0-17) 7.3.0
> 
> As a warning or an error?  The toolchain in question is
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_x86_64-linux.tar.xz
> and on that specific branch is where I'm testing moving buildman up.
> Thanks!

When I run

git checkout master
make qemu-x86_defconfig
make -j6

I see no warning.

I strongly dislike using buildman locally because it pulls in binaries
from some dubious source which are not even signed.

Best regards

Heinrich

> 
> 
> 
> ___
> 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 1/1] efi_loader: always check parameters in efi_cout_query_mode()

[Tom Rini]

On Wed, May 09, 2018 at 11:13:37PM +0200, Heinrich Schuchardt wrote:
> On 05/09/2018 10:00 PM, Tom Rini wrote:
> > On Sun, Apr 29, 2018 at 08:02:46PM +0200, Heinrich Schuchardt wrote:
> > 
> >> If we cannot determine the size of the serial terminal we still have
> >> to check the parameters of efi_cout_query_mode().
> >>
> >> Querying the size of the serial terminal drains the keyboard buffer.
> >> So make sure we do this during the initialization and not in the midst
> >> of an EFI application.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> 
> 
> 
> > 
> > Even without this patch with a newer gcc we see:
> > https://travis-ci.org/trini/u-boot/jobs/376853382#L916
> > 
> > Can you address that while doing this fixup as well?  Thanks!
> > 
> 
> I don't doubt there is an issue. But why don't we see the error outside
> of Travis CI? Do we set different flags when building?
> 
> Can't see it with
> gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
> nor with
> gcc (Debian 7.3.0-17) 7.3.0

As a warning or an error?  The toolchain in question is
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/x86_64-gcc-7.3.0-nolibc_x86_64-linux.tar.xz
and on that specific branch is where I'm testing moving buildman up.
Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/1] efi_loader: always check parameters in efi_cout_query_mode()

[Heinrich Schuchardt]

On 05/09/2018 10:00 PM, Tom Rini wrote:
> On Sun, Apr 29, 2018 at 08:02:46PM +0200, Heinrich Schuchardt wrote:
> 
>> If we cannot determine the size of the serial terminal we still have
>> to check the parameters of efi_cout_query_mode().
>>
>> Querying the size of the serial terminal drains the keyboard buffer.
>> So make sure we do this during the initialization and not in the midst
>> of an EFI application.
>>
>> Signed-off-by: Heinrich Schuchardt 



> 
> Even without this patch with a newer gcc we see:
> https://travis-ci.org/trini/u-boot/jobs/376853382#L916
> 
> Can you address that while doing this fixup as well?  Thanks!
> 

I don't doubt there is an issue. But why don't we see the error outside
of Travis CI? Do we set different flags when building?

Can't see it with
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
nor with
gcc (Debian 7.3.0-17) 7.3.0

Best regards

Heinrich

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

Re: [U-Boot] GCC 7.x vs. C++ comments

[Wolfgang Denk]

Dear Tom,

In message <20180509161456.gm12...@bill-the-cat.ec.rr.com> you wrote:
> 
> I don't want to have it buried here but maybe it's time to talk about
> fully adopting C99 (or, GNU C99).  Did you happen to read
> https://lkml.org/lkml/2017/11/25/133 that Yamada-san passed along?
> Having read that after converting the tags that my first regex missed,
> maybe we were wrong 18 years ago.

OK.  You know my opinion.

> > is silly.  We don't use these in Makefiles, or in shell scripts, or
> > in ...
>
> We sometimes do for Makefiles, almost always do in shell scripts.

You misunderstand.  I meant: we do not use C++ comments in Makefiles
or in shell scripts, or in most other non-C code...

I drop out of this discussion here - thanks.

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
"Ada is PL/I trying to be Smalltalk. - Codoso diBlini
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] arm: print instructions pointed to by pc

[Heinrich Schuchardt]

If an exception occurs in a loaded image and the relocation offset is
unknown, it is helful to know the instructions pointed to by the
program counter. This patch adds the missing output.

A possible output is:
*pc: defe e7ff 8010 e8bd abb9 9ffc f7d5 9ffc

Signed-off-by: Heinrich Schuchardt 
---
 arch/arm/lib/interrupts.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
index cda4d48460..24fa3d433d 100644
--- a/arch/arm/lib/interrupts.c
+++ b/arch/arm/lib/interrupts.c
@@ -60,6 +60,8 @@ static void show_efi_loaded_images(struct pt_regs *regs)
 void show_regs (struct pt_regs *regs)
 {
unsigned long __maybe_unused flags;
+   /* The least significant bit chooses thumb, remove it. */
+   u16 *pc = (u16 *)(instruction_pointer(regs) & ~1);
const char __maybe_unused *processor_modes[] = {
"USER_26",  "FIQ_26",   "IRQ_26",   "SVC_26",
"UK4_26",   "UK5_26",   "UK6_26",   "UK7_26",
@@ -97,6 +99,8 @@ void show_regs (struct pt_regs *regs)
fast_interrupts_enabled (regs) ? "on" : "off",
processor_modes[processor_mode (regs)],
thumb_mode (regs) ? " (T)" : "");
+   printf("*pc: %04x %04x %04x %04x %04x %04x %04x %04x\n",
+  pc[0], pc[1], pc[2], pc[3], pc[4], pc[5], pc[6], pc[7]);
 }
 
 /* fixup PC to point to the instruction leading to the exception */
-- 
2.17.0

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

Re: [U-Boot] [PATCH 1/1] efi_loader: always check parameters in efi_cout_query_mode()

[Tom Rini]

On Sun, Apr 29, 2018 at 08:02:46PM +0200, Heinrich Schuchardt wrote:

> If we cannot determine the size of the serial terminal we still have
> to check the parameters of efi_cout_query_mode().
> 
> Querying the size of the serial terminal drains the keyboard buffer.
> So make sure we do this during the initialization and not in the midst
> of an EFI application.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_console.c | 90 
> +++-
>  1 file changed, 48 insertions(+), 42 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index d687362a50..f1b8db55d6 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -13,8 +13,6 @@
>  #include 
>  #include 
>  
> -static bool console_size_queried;
> -
>  #define EFI_COUT_MODE_2 2
>  #define EFI_MAX_COUT_MODE 3
>  
> @@ -206,6 +204,51 @@ static int query_console_serial(int *rows, int *cols)
>   return 0;
>  }
>  
> +/*
> + * Update the mode table.
> + *
> + * By default the only mode available is 80x25. If the console has at least 
> 50
> + * lines, enable mode 80x50. If we can query the console size and it is 
> neither
> + * 80x25 nor 80x50, set it as an additional mode.
> + */
> +static void query_console_size(void)
> +{
> + const char *stdout_name = env_get("stdout");
> + int rows, cols;
> +
> + if (stdout_name && !strcmp(stdout_name, "vidconsole") &&
> + IS_ENABLED(CONFIG_DM_VIDEO)) {
> + struct stdio_dev *stdout_dev =
> + stdio_get_by_name("vidconsole");
> + struct udevice *dev = stdout_dev->priv;
> + struct vidconsole_priv *priv =
> + dev_get_uclass_priv(dev);
> + rows = priv->rows;
> + cols = priv->cols;
> + } else if (query_console_serial(, )) {
> + return;
> + }
> +
> + /* Test if we can have Mode 1 */
> + if (cols >= 80 && rows >= 50) {
> + efi_cout_modes[1].present = 1;
> + efi_con_mode.max_mode = 2;
> + }
> +
> + /*
> +  * Install our mode as mode 2 if it is different
> +  * than mode 0 or 1 and set it as the currently selected mode
> +  */
> + if (!cout_mode_matches(_cout_modes[0], rows, cols) &&
> + !cout_mode_matches(_cout_modes[1], rows, cols)) {
> + efi_cout_modes[EFI_COUT_MODE_2].columns = cols;
> + efi_cout_modes[EFI_COUT_MODE_2].rows = rows;
> + efi_cout_modes[EFI_COUT_MODE_2].present = 1;
> + efi_con_mode.max_mode = EFI_MAX_COUT_MODE;
> + efi_con_mode.mode = EFI_COUT_MODE_2;
> + }
> +}
> +
>  static efi_status_t EFIAPI efi_cout_query_mode(
>   struct efi_simple_text_output_protocol *this,
>   unsigned long mode_number, unsigned long *columns,
> @@ -213,52 +256,12 @@ static efi_status_t EFIAPI efi_cout_query_mode(
>  {
>   EFI_ENTRY("%p, %ld, %p, %p", this, mode_number, columns, rows);
>  
> - if (!console_size_queried) {
> - const char *stdout_name = env_get("stdout");
> - int rows, cols;
> -
> - console_size_queried = true;
> -
> - if (stdout_name && !strcmp(stdout_name, "vidconsole") &&
> - IS_ENABLED(CONFIG_DM_VIDEO)) {
> - struct stdio_dev *stdout_dev =
> - stdio_get_by_name("vidconsole");
> - struct udevice *dev = stdout_dev->priv;
> - struct vidconsole_priv *priv =
> - dev_get_uclass_priv(dev);
> - rows = priv->rows;
> - cols = priv->cols;
> - } else if (query_console_serial(, )) {
> - goto out;
> - }
> -
> - /* Test if we can have Mode 1 */
> - if (cols >= 80 && rows >= 50) {
> - efi_cout_modes[1].present = 1;
> - efi_con_mode.max_mode = 2;
> - }
> -
> - /*
> -  * Install our mode as mode 2 if it is different
> -  * than mode 0 or 1 and set it  as the currently selected mode
> -  */
> - if (!cout_mode_matches(_cout_modes[0], rows, cols) &&
> - !cout_mode_matches(_cout_modes[1], rows, cols)) {
> - efi_cout_modes[EFI_COUT_MODE_2].columns = cols;
> - efi_cout_modes[EFI_COUT_MODE_2].rows = rows;
> - efi_cout_modes[EFI_COUT_MODE_2].present = 1;
> - efi_con_mode.max_mode = EFI_MAX_COUT_MODE;
> - efi_con_mode.mode = EFI_COUT_MODE_2;
> - }
> - }
> -
>   if (mode_number >= efi_con_mode.max_mode)
>   return EFI_EXIT(EFI_UNSUPPORTED);
>  
>   if (efi_cout_modes[mode_number].present != 1)
>   return EFI_EXIT(EFI_UNSUPPORTED);
>  
> 

Re: [U-Boot] [PATCH 09/12] ARM: kirkwood: Add device-tree for nsa310s

[bodhi bodhi]

Hi Chris,

What we have in Linux mainline is Zyxel NSA310 (Marvell 88f6281). The Zyxel
NSA310S (Marvell 88f6702) is actually a different box, which has not been
mainlined yet.

By the way, there are 3 variations of the Zyxel NSA310 box. This box has
some combination of: red USB Led, lm85 sensor, adt7476 sensor that make
them slighly different. The mainlined NSA310 DTS is for the one with adt7476
sensor.

Regards
bodhi


On Tue, May 8, 2018 at 3:34 AM, Chris Packham 
wrote:

> Import the dts files from Linux 4.17 and enable CONFIG_OF_CONTROL.
>
> Signed-off-by: Chris Packham 
> ---
>
>  arch/arm/dts/kirkwood-nsa310.dts | 139 
>  arch/arm/dts/kirkwood-nsa3x0-common.dtsi | 158 +++
>  configs/nsa310s_defconfig|   3 +-
>  3 files changed, 299 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/kirkwood-nsa310.dts
>  create mode 100644 arch/arm/dts/kirkwood-nsa3x0-common.dtsi
>
> diff --git a/arch/arm/dts/kirkwood-nsa310.dts b/arch/arm/dts/kirkwood-
> nsa310.dts
> new file mode 100644
> index ..9b861c2e76c5
> --- /dev/null
> +++ b/arch/arm/dts/kirkwood-nsa310.dts
> @@ -0,0 +1,139 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +
> +#include "kirkwood-nsa3x0-common.dtsi"
> +
> +/ {
> +   compatible = "zyxel,nsa310", "marvell,kirkwood-88f6281",
> "marvell,kirkwood";
> +
> +   memory {
> +   device_type = "memory";
> +   reg = <0x 0x1000>;
> +   };
> +
> +   chosen {
> +   bootargs = "console=ttyS0,115200";
> +   stdout-path = 
> +   };
> +
> +   ocp@f100 {
> +   pinctrl: pin-controller@1 {
> +   pinctrl-0 = <_unknown>;
> +   pinctrl-names = "default";
> +
> +   pmx_led_esata_green: pmx-led-esata-green {
> +   marvell,pins = "mpp12";
> +   marvell,function = "gpio";
> +   };
> +
> +   pmx_led_esata_red: pmx-led-esata-red {
> +   marvell,pins = "mpp13";
> +   marvell,function = "gpio";
> +   };
> +
> +   pmx_led_usb_green: pmx-led-usb-green {
> +   marvell,pins = "mpp15";
> +   marvell,function = "gpio";
> +   };
> +
> +   pmx_led_usb_red: pmx-led-usb-red {
> +   marvell,pins = "mpp16";
> +   marvell,function = "gpio";
> +   };
> +
> +   pmx_led_sys_green: pmx-led-sys-green {
> +   marvell,pins = "mpp28";
> +   marvell,function = "gpio";
> +   };
> +
> +   pmx_led_sys_red: pmx-led-sys-red {
> +   marvell,pins = "mpp29";
> +   marvell,function = "gpio";
> +   };
> +
> +   pmx_led_hdd_green: pmx-led-hdd-green {
> +   marvell,pins = "mpp41";
> +   marvell,function = "gpio";
> +   };
> +
> +   pmx_led_hdd_red: pmx-led-hdd-red {
> +   marvell,pins = "mpp42";
> +   marvell,function = "gpio";
> +   };
> +
> +   pmx_unknown: pmx-unknown {
> +   marvell,pins = "mpp44";
> +   marvell,function = "gpio";
> +   };
> +
> +   };
> +
> +   i2c@11000 {
> +   status = "okay";
> +
> +   adt7476: adt7476a@2e {
> +   compatible = "adi,adt7476";
> +   reg = <0x2e>;
> +   };
> +   };
> +   };
> +
> +   gpio-leds {
> +   compatible = "gpio-leds";
> +   pinctrl-0 = <_led_esata_green _led_esata_red
> +_led_usb_green _led_usb_red
> +_led_sys_green _led_sys_red
> +_led_copy_green _led_copy_red
> +_led_hdd_green _led_hdd_red>;
> +   pinctrl-names = "default";
> +
> +   green-sys {
> +   label = "nsa310:green:sys";
> +   gpios = < 28 GPIO_ACTIVE_HIGH>;
> +   };
> +   red-sys {
> +   label = "nsa310:red:sys";
> +   gpios = < 29 GPIO_ACTIVE_HIGH>;
> +   };
> +   green-hdd {
> +   label = "nsa310:green:hdd";
> +   gpios = < 9 

[U-Boot] [PATCH v2] arm: zynq: Add initial support for Avnet MiniZed

[Ibai Erkiaga]

Initial support for Avnet MiniZed board. Tested UART1 (serial console),
QSPI(Flash), SDHCI1 (eMMC), USB.

Signed-off-by: Ibai Erkiaga 
---
Changes for v2:
-board model changed to use Avent prefix
-usb phy driver changed usb-no-xceiv
-removed gpio and intc binding
-fixed-partitions usage
---
U-Boot 2018.05-00023-gdf332c1-dirty (May 09 2018 - 14:50:51 +0100)

Model: Avnet Zynq MiniZed Development Board
Board: Xilinx Zynq
Silicon: v3.1
DRAM:  ECC disabled 512 MiB
MMC:   sdhci@e0101000: 0
Loading Environment from SPI Flash... SF: Detected n25q128 with page size 256 
Bytes, erase size 64 KiB, total 16 MiB
OK
In:serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Net:   No ethernet found.
Hit any key to stop autoboot:  0
Zynq> fatls mmc 0
 16783864   image.ub
  183   wpa_supplicant.conf
  1391116   smallboot.bin

3 file(s), 0 dir(s)

Zynq> sf probe 0 0 0
SF: Detected n25q128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB
Zynq> usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 1 Storage Device(s) found
Zynq> fatls usb 0
   12   test.txt

1 file(s), 0 dir(s)

Zynq>
---
 arch/arm/dts/Makefile  |1 +
 arch/arm/dts/zynq-minized.dts  |  104 
 configs/zynq_minized_defconfig |   68 ++
 3 files changed, 173 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/dts/zynq-minized.dts
 create mode 100644 configs/zynq_minized_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6fe93a8..5c5f8a8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -129,6 +129,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-cc108.dtb \
zynq-cse-qspi-single.dtb \
zynq-microzed.dtb \
+   zynq-minized.dtb \
zynq-picozed.dtb \
zynq-syzygy-hub.dtb \
zynq-topic-miami.dtb \
diff --git a/arch/arm/dts/zynq-minized.dts b/arch/arm/dts/zynq-minized.dts
new file mode 100644
index 000..68fe09a
--- /dev/null
+++ b/arch/arm/dts/zynq-minized.dts
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * dts file for Avnet MiniZed board
+ *
+ * (C) Copyright 2017 - 2018, Xilinx, Inc.
+ *
+ * Ibai Erkiaga 
+ */
+
+/dts-v1/;
+#include "zynq-7000.dtsi"
+
+/ {
+   model = "Avnet Zynq MiniZed Development Board";
+   compatible = "avnet,minized", "xlnx,zynq-7000";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   spi0 = 
+   mmc0 = 
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x2000>;
+   };
+
+   chosen {
+   bootargs = "";
+   stdout-path = "serial0:115200n8";
+   };
+
+   usb_phy0: phy0 {
+   compatible = "usb-nop-xceiv";
+   #phy-cells = <0>;
+   };
+};
+
+ {
+   status = "okay";
+   is-dual = <0>;
+   num-cs = <1>;
+   flash@0 {
+   compatible = "micron,m25p128";
+   reg = <0x0>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   spi-max-frequency = <5000>;
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   partition@0 {
+   label = "boot";
+   reg = <0x0 0xff>;
+   };
+
+   partition@027 {
+   label = "kernel";
+   reg = <0x27 0xd8>;
+   };
+
+   partition@ff {
+   label = "bootenv";
+   reg = <0xff 0x1>;
+   };
+
+   partition@100 {
+   label = "spare";
+   reg = <0x100 0x0>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   dr_mode = "host";
+   usb-phy = <_phy0>;
+   usb-reset = < 7 0>; /* USB_RST_N-MIO7 */ };
+
+ {
+   status = "okay";
+   non-removable;
+   bus-width = <4>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mmccard: mmccard@0 {
+   compatible = "mmc-card";
+   reg = <0>;
+   broken-hpi;
+   };
+};
diff --git a/configs/zynq_minized_defconfig b/configs/zynq_minized_defconfig
new file mode 100644
index 000..05cfc0e
--- /dev/null
+++ b/configs/zynq_minized_defconfig
@@ -0,0 +1,68 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ZYNQ=y
+CONFIG_SYS_TEXT_BASE=0x400

Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Am 09.05.2018 um 14:33 schrieb klaus.go...@theobroma-systems.com:




On 09.05.2018, at 10:19, Markus Krebs  wrote:

Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:

On 2018-05-08, Vagrant Cascadian wrote:

On 2018-05-05, Tom Rini wrote:

On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:

Markus Krebs discovered that the sheevaplug target has again grown and
installation overlaps where the u-boot env is saved since u-boot
~2017.09. Running saveenv overwrites u-boot, and installing u-boot
overwrites any prior environment settings.

...

I've added the maintainer to the list as well.  I would suggest looking
for things to trim out, perhaps CMD_MEMTEST ?


Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
*lot* left to disable in the config, but that's a significant start...

And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
down to 432k! Thanks to beeble for the suggestion.
Anyone who has a sheevaplug can test that it actually boots with
CONFIG_SYS_THUMB_BUILD=y enabled?


I could test it, but I don't know the config-file where I can change those 
options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).


Both are Kconfig options. So just disable it via menuconfig or in your .config 
file



Thanks. The modified u-boot (size indeed 441592 bytes only) boots!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rockchip: set SYS_NS16550_MEM32 for all SoCs

[Philipp Tomsich]

> Add back part of patch send out as
> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have
> gotten lost when it got merged to set SYS_NS16550_MEM32.
> 
> Allows serial output to work on tinker-rk3288 again after
> c3c0331db1fb7b1f4ff41e144fc04353b37c785c.
> 
> Signed-off-by: Kever Yang 
> Signed-off-by: Jonathan Gray 
> Cc: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> Tested-by: Heinrich Schuchardt 
> ---
>  include/configs/rockchip-common.h | 2 ++
>  1 file changed, 2 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] driver: net: fsl-mc: updated copyright info

[York Sun]

On 05/09/2018 12:26 AM, Yogesh Narayan Gaur wrote:
> Updated copyright info for the issues reported after running
> check-legal test.
> 
> Signed-off-by: Yogesh Gaur 
> Reviewed-by: York Sun 
> ---
> Legally NXP and Freescale Semiconductor are same entity.
> Changes for v2:
> - Rebase to top as per York's comment.
> 

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH][v3] mtd: nand: fsl_ifc: Fix nand waitfunc return value

[York Sun]

On 05/01/2018 03:52 AM, Jagdish Gediya wrote:
> As per the IFC hardware manual, Most significant byte in
> nand_fsr register is the outcome of NAND READ STATUS command.
> 
> So status value need to be shifted as per the nand
> framework requirement.
> 
> Signed-off-by: Jagdish Gediya 
> Reviewed-by: Prabhakar Kushwaha 
> ---
> Changes for v2:
>   - Change the waitfunc return value according to semantic
> enforced by framework.
> 
> Changes for v3:
>   - Change commit message as per York's suggestion.

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH] armv8/fsl-lsch2: make the workaround for PIN MUX erratum A010539 robust

[York Sun]

On 04/25/2018 01:26 AM, Z.q. Hou wrote:
> From: Hou Zhiqiang 
> 
> Mask HRESET_B after cleared the the RCW_SRC, because in the workaround
> we override the RCW_SRC and if HRESET_B is issued after the override
> then SoC cannot find valid RCW as the RCW_SRC was overwritten and result
> in hang. So we need to mask HRESET_B in case user asserts it, and the
> PORESET_B should be asserted which leads to resampling of cfg_rcw_src
> pins and loading of correct RCW_SRC.
> 
> Signed-off-by: Hou Zhiqiang 
> ---

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

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

Re: [U-Boot] [PATCH] armv8/fsl-lsch2: correct QMAN clock

[York Sun]

On 04/25/2018 03:29 AM, Z.q. Hou wrote:
> From: Hou Zhiqiang 
> 
> Signed-off-by: Hou Zhiqiang 
> ---

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH v2] armv8: sec_firmware: Add support for multiple loadables

[York Sun]

On 04/23/2018 05:20 AM, Sumit Garg wrote:
> Enable support for multiple loadable images in SEC firmware FIT image.
> Also add example "sec_firmware_ppa.its" file.
> 
> Signed-off-by: Sumit Garg 
> ---
> 
> Changes in v2:
> Added example "sec_firmware_ppa.its" file. Also added printf instead of
> debug in case of error scenario.

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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

Re: [U-Boot] powerpc: mpc85xx: Improve Work-around for Erratum A005125

[York Sun]

On 04/22/2018 11:27 PM, Takuma Ueba wrote:
> powerpc/mpc85xx: Work-around for Erratum A005125 must be applied to all cores.
> 
> Signed-off-by: Yoshihisa Morizumi 
> Signed-off-by: Takuma Ueba 
> ---

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH] armv8: ls1088: Update 1900MT/s DDR timing to bring consistency

[York Sun]

On 04/18/2018 12:07 AM, Ashish Kumar wrote:
> Signed-off-by: Ashish Kumar 
> ---

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

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

Re: [U-Boot] [PATCH] armv8: ls1088aqds: Enable mdio commands on u-boot prompt

[York Sun]

On 04/13/2018 01:58 AM, Ashish Kumar wrote:
> Signed-off-by: Ashish Kumar 
> ---
>  board/freescale/ls1088a/eth_ls1088aqds.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
Applied to fsl-qoriq master, awaiting upstream.
Thanks.

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

Re: [U-Boot] [PATCH][v2] armv8: sec_firmware: Remove JR3 from device tree node in all cases

[York Sun]

On 04/12/2018 05:53 AM, Ruchika Gupta wrote:
> JR3 was getting removed from device tree only if random number generation
> was successful. However, if SEC firmware is present,JR3 should be removed
> from device tree node irrespective of the random seed generation as
> SEC firmware reserves it for it's use. Not removing it in case of random
> number generation failure causes the kernel to crash.
> 
> Random number generation was being called twice. This is not required.
> If SEC firmware is running, SIP call can be made to the SEC firmware to
> get the random number. This call itself would return failure if function
> is not supported. Duplicate calling of random number generation function
> has been removed
> 
> Signed-off-by: Ruchika Gupta 
> ---
> Changes from v1:
> Removed unused variable rand from the sec_firmware_support_hwrng function
> 
Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [Patch v2] armv8: ls1088a: Move CONFIG_BOOTARGS and CONFIG_CMD_GREPENV to defconfig

[York Sun]

On 03/26/2018 04:32 AM, Ashish Kumar wrote:
> Signed-off-by: Ashish Kumar 
> ---
> v2:  Rebase to top
> 

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH] armv8: layerscape: Avoid code duplication for TZASC Instantiation

[York Sun]

On 03/26/2018 03:54 AM, Sriram Dash wrote:
> TZASC controller configurations are similar.
> Put them in a macro and avoid code duplication.
> 
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Sriram Dash 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 62 
> +++-
>  1 file changed, 34 insertions(+), 28 deletions(-)
> 
Applied to fsl-qoriq master, awaiting upstream.
Thanks.

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

Re: [U-Boot] [PATCH][v3] mtd: nand: fsl_ifc: Fix eccstat array overflow for IFC ver >= 2.0.0

[York Sun]

On 03/23/2018 04:17 AM, Jagdish Gediya wrote:
> Number of ECC status registers i.e. (ECCSTATx) has been increased in IFC
> version 2.0.0 due to increase in SRAM size. This is causing eccstat
> array to over flow.
> 
> So, replace eccstat array with u32 variable to make it fail-safe and
> independent of number of ECC status registers or SRAM size.
> 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Jagdish Gediya 
> ---
> Changes for v2:
>   - Resolve checkpatch error
>   - Give suitable name to variable and do proper initialization.
> 
> Changes for v3:
>   - Changes to avoid reading of register twice if sector_start
> is multiple of 4.

I don't see any comment on this patch. So it is applied to fsl-qoriq
master, awaiting upstream.

Thanks.

York

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

Re: [U-Boot] [PATCH] spi: fsl_qspi: Introduce is_controller_busy function

[York Sun]

On 03/22/2018 02:46 AM, Rajat Srivastava wrote:
> Some SoCs have different endianness of QSPI IP if compared
> to endianness of core. The function is_controller_busy()
> checks if the QSPI controller is busy or not, considering
> the endianness of the QSPI IP.
> 
> Signed-off-by: Rajat Srivastava 
> Reviewed-by: York Sun 
> ---
>  drivers/spi/fsl_qspi.c | 31 +--
>  1 file changed, 21 insertions(+), 10 deletions(-)

Applied to fsl-qoriq master, awaiting upstream.
Thanks.

York

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

Re: [U-Boot] [PATCH v2] arm: ti: boot: Extract PARTS_DEFAULT to boot.h

[Andrew F. Davis]

On 04/19/2018 03:57 PM, Sam Protsenko wrote:
> Eliminate code duplication: the same PARTS_DEFAULT was defined in
> am57xx_evm.h and in dra7xx_evm.h. Extract it to environment/boot.h and
> use in all OMAP5-based boards.
> 
> Signed-off-by: Sam Protsenko 
> ---


Acked-by: Andrew F. Davis 


>  include/configs/am57xx_evm.h   | 25 -
>  include/configs/cl-som-am57x.h |  2 ++
>  include/configs/cm_t54.h   |  2 ++
>  include/configs/dra7xx_evm.h   | 25 -
>  include/environment/ti/boot.h  | 27 +--
>  5 files changed, 29 insertions(+), 52 deletions(-)
> 
> diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
> index d1f73f76a4..886a5696f5 100644
> --- a/include/configs/am57xx_evm.h
> +++ b/include/configs/am57xx_evm.h
> @@ -38,31 +38,6 @@
>  
>  #define CONFIG_SYS_OMAP_ABE_SYSCK
>  
> -/* Define the default GPT table for eMMC */
> -#define PARTS_DEFAULT \
> - /* Linux partitions */ \
> - "uuid_disk=${uuid_gpt_disk};" \
> - "name=bootloader,start=384K,size=1792K,uuid=${uuid_gpt_bootloader};" \
> - "name=rootfs,start=2688K,size=-,uuid=${uuid_gpt_rootfs}\0" \
> - /* Android partitions */ \
> - "partitions_android=" \
> - "uuid_disk=${uuid_gpt_disk};" \
> - "name=xloader,start=128K,size=256K,uuid=${uuid_gpt_xloader};" \
> - "name=bootloader,size=1792K,uuid=${uuid_gpt_bootloader};" \
> - "name=environment,size=128K,uuid=${uuid_gpt_environment};" \
> - "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
> - "name=reserved,size=256K,uuid=${uuid_gpt_reserved};" \
> - "name=efs,size=16M,uuid=${uuid_gpt_efs};" \
> - "name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
> - "name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
> - "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
> - "name=system,size=768M,uuid=${uuid_gpt_system};" \
> - "name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
> - "name=cache,size=256M,uuid=${uuid_gpt_cache};" \
> - "name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
> - "name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \
> - "name=userdata,size=-,uuid=${uuid_gpt_userdata}"
> -
>  #define DFUARGS \
>   "dfu_bufsiz=0x1\0" \
>   DFU_ALT_INFO_MMC \
> diff --git a/include/configs/cl-som-am57x.h b/include/configs/cl-som-am57x.h
> index 9c70cf0b37..709e0375b3 100644
> --- a/include/configs/cl-som-am57x.h
> +++ b/include/configs/cl-som-am57x.h
> @@ -18,6 +18,8 @@
>  
>  #define CONFIG_SYS_OMAP_ABE_SYSCK
>  
> +#define PARTS_DEFAULT
> +
>  #include 
>  
>  /* misc */
> diff --git a/include/configs/cm_t54.h b/include/configs/cm_t54.h
> index 6123cd374d..f0d76ed806 100644
> --- a/include/configs/cm_t54.h
> +++ b/include/configs/cm_t54.h
> @@ -14,6 +14,8 @@
>  #define CONFIG_CM_T54
>  #define CONFIG_DRAM_2G
>  
> +#define PARTS_DEFAULT
> +
>  #include 
>  
>  /* EEPROM related defines */
> diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
> index 917a05d701..9b3fb2c913 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -45,31 +45,6 @@
>  #define CONFIG_SYS_OMAP_ABE_SYSCK
>  
>  #ifndef CONFIG_SPL_BUILD
> -/* Define the default GPT table for eMMC */
> -#define PARTS_DEFAULT \
> - /* Linux partitions */ \
> - "uuid_disk=${uuid_gpt_disk};" \
> - "name=bootloader,start=384K,size=1792K,uuid=${uuid_gpt_bootloader};" \
> - "name=rootfs,start=2688K,size=-,uuid=${uuid_gpt_rootfs}\0" \
> - /* Android partitions */ \
> - "partitions_android=" \
> - "uuid_disk=${uuid_gpt_disk};" \
> - "name=xloader,start=128K,size=256K,uuid=${uuid_gpt_xloader};" \
> - "name=bootloader,size=1792K,uuid=${uuid_gpt_bootloader};" \
> - "name=environment,size=128K,uuid=${uuid_gpt_environment};" \
> - "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
> - "name=reserved,size=256K,uuid=${uuid_gpt_reserved};" \
> - "name=efs,size=16M,uuid=${uuid_gpt_efs};" \
> - "name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
> - "name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
> - "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
> - "name=system,size=768M,uuid=${uuid_gpt_system};" \
> - "name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
> - "name=cache,size=256M,uuid=${uuid_gpt_cache};" \
> - "name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
> - "name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \
> - "name=userdata,size=-,uuid=${uuid_gpt_userdata}"
> -
>  #define DFUARGS \
>   "dfu_bufsiz=0x1\0" \
>   DFU_ALT_INFO_MMC \
> diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h
> index 24b7783f88..4f3d748b5c 100644
> --- a/include/environment/ti/boot.h
> +++ b/include/environment/ti/boot.h
> @@ -15,8 +15,31 @@
>  #endif
>  
>  #ifndef PARTS_DEFAULT
> -#define PARTS_DEFAULT
> -#endif
> +/* Define the default GPT table for eMMC */
> +#define PARTS_DEFAULT \
> + /* Linux partitions */ \
> +   

Re: [U-Boot] [PATCH] rockchip: set SYS_NS16550_MEM32 for all SoCs

[Heinrich Schuchardt]

On 05/08/2018 12:43 PM, Jonathan Gray wrote:
> Add back part of patch send out as
> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have
> gotten lost when it got merged to set SYS_NS16550_MEM32.
> 
> Allows serial output to work on tinker-rk3288 again after
> c3c0331db1fb7b1f4ff41e144fc04353b37c785c.
> 
> Signed-off-by: Philipp Tomsich 
> Signed-off-by: Jonathan Gray 
> Cc: Philipp Tomsich 

With the patch I get a serial console on the Asus Tinker-Board (RK3288).

Tested-by: Heinrich Schuchardt 

> ---
>  include/configs/rockchip-common.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/configs/rockchip-common.h 
> b/include/configs/rockchip-common.h
> index dee82ca99d..68e1105a4b 100644
> --- a/include/configs/rockchip-common.h
> +++ b/include/configs/rockchip-common.h
> @@ -7,6 +7,8 @@
>  #define _ROCKCHIP_COMMON_H_
>  #include 
>  
> +#define CONFIG_SYS_NS16550_MEM32
> +
>  #ifndef CONFIG_SPL_BUILD
>  
>  /* First try to boot from SD (index 0), then eMMC (index 1) */
> 

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

Re: [U-Boot] GCC 7.x vs. C++ comments

[Tom Rini]

On Wed, May 09, 2018 at 06:07:50PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180509154052.5e0b4240...@gemini.denx.de> I wrote:
> > 
> > > - Don't like // style comments
> > > - Visually inconsistent / jarring
> > 
> > - Against existing coding style.
> 
> Also, the SPDX tag is rarely a separate comment line.  In most
> cases, it is part of a larger file header, say for example:
> 
> common/main.c:
> 
> /*
>  * (C) Copyright 2000
>  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>  *
>  * SPDX-License-Identifier: GPL-2.0+
>  */
> 
> 
> Do you suggest to reformat this into something like:
> 
> /*
>  * (C) Copyright 2000
>  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>  */
> 
> // SPDX-License-Identifier: GPL-2.0+
> 
> ?

I know it's going to annoy you more, but yes, that's already _done_:
$ head -n5 common/main.c
// SPDX-License-Identifier: GPL-2.0+
/*
 * (C) Copyright 2000
 * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 */

It was about 97% automatic perl regex + sed insert and 3% "Ugh, this
file does not follow the normal conventional comment style at all".

> If yes, then please explain which sense this would make?  It is just
> unnecessay work, and the result is inconsistent and ugly.
> 
> 
> > > - Has tooling to enforce correctly formatted tags.
> 
> I forgot to ask which "tooling" you have in mind here?  I did not
> see anything like that in the kernel source tree.  What am I
> missing?

This started because I updated checkpatch.pl and that in turn checks if
new files have an SPDX tag and if so, does it match the kernel style
formatting.  The first email:
https://lists.denx.de/pipermail/u-boot/2018-April/325510.html
that brought this up.  And yes, I run checkpatch.pl on everything before
every pull/push.

-- 
Tom


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

Re: [U-Boot] GCC 7.x vs. C++ comments

[Tom Rini]

On Wed, May 09, 2018 at 05:40:52PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180509134905.gk12...@bill-the-cat.ec.rr.com> you wrote:
> > 
> > > Marek already said what was on my mind, and got ignored.
> > > Would it have changed anything if I had posted another complaint?
> >
> > Ignored, no.  Counts as a veto?  No.  And if you had chimed in too, I
> > don't know if that would have gotten anyone else to also chime in.
> 
> This does not really convince me.
> 
> IMO it makes no sense to blow up mailing list traffic with extensive
> voting for such things. Marek said everything that needed to be
> said, and repeating it would IMO not add any weight to it.  If you
> really want a poll including more people, then explicitly start one
> - but please not on the mailing list, at least not fuch such
> details.

I honestly couldn't think of a better way to see if anyone cared besides
an RFC to the mailing list.

> > It's not futile, but here's as best I can tell, the arguments:
> > Against Linux Kernel style SPDX tags:
> 
> I think this argument is wrong from the start.  This is not about
> "Linux Kernel style SPDX tags".  There is two different topics,
> which are actually independent, and should be treated as such:
> 
> - Linux Kernel style SPDX tags, or rather more modern SPDX tags
>   including the needed operators to deal with exceptions, multiple
>   licenses, etc.  When I invented the SPDX tags I did not foresee
>   this need (my fault), but I'm still proud that U-Boot introduced
>   this mechanism at all.
> 
>   Yes, it is necessary to adapt the new developments in this area.

And for the record, it's a good thing you did.  Since we were the best
example of a project going all-in on the tags for a long while I know
the people that did the kernel scheme looked at what we had.

> - Comment style.  This is just a matter of coding style and
>   preferences.  Whether you use C comments (single line or
>   multi-line) or C++ comments does not make any difference
>   technically.

I disagree on these being separate.  I copy/pasted the relevant part of
the kernel documentation as an update to our doc but where it goes
(first line) and how it goes (comments like ) are as much a part of
the style as the syntax.  I'd argue that where the license copies go and
some directory structure there-of is also part of it but I think our
locations are more set in stone, but we can live with it.

>   U-Boot has been discouraging the use of C++ comments for 18 years,
>   and I still see no good reason to change this.  [And yes, we also
>   have the rule not to meddle with code copied from other projects.]

I don't want to have it buried here but maybe it's time to talk about
fully adopting C99 (or, GNU C99).  Did you happen to read
https://lkml.org/lkml/2017/11/25/133 that Yamada-san passed along?
Having read that after converting the tags that my first regex missed,
maybe we were wrong 18 years ago.

> > - Don't like // style comments
> > - Visually inconsistent / jarring
> 
> - Against existing coding style.
> 
> 
> > For Linux Kernel style SPDX tags:
> > - Has higher visibility.
> 
> ??? I can't parse this.  In which way has
> 
> // SPDX-License-Identifier: GPL-2.0+
> 
> "higher visibility" than
> 
> /* SPDX-License-Identifier: GPL-2.0+ */
> 
> or even

I was pointing out first line vs somewhere within the top comment block
as I don't consider comment format vs location different items.

> /*
>  * SPDX-License-Identifier: GPL-2.0+
>  */
> 
> ?
> 
> [IMO, the last form is the most visible one.]
> 
> And since when do we care about a single line of white space or two
> when it comes to consistency or readability?
> 
> > - Has tooling to enforce correctly formatted tags.
> 
> 
> > - Shorter (enforced as a single line comment means we don't have people
> >   spacing around it).
> 
> Come on, this argument is really lame.

That the SPDX tag meant the same as the whole license text was part of
the reason to convert.

> > - Consistent expectations for our overlapping developer community.
> 
> Please explain?  Who associates SPDX tags with C++ comments?  This

This is again part of the difference in counting comment format as part
of it, or not.

> is silly.  We don't use these in Makefiles, or in shell scripts, or
> in ...

We sometimes do for Makefiles, almost always do in shell scripts.

> And when talking about consistency - what about this in the current
> Linux Kernel tree:
> 
> arch/x86/kernel/apic/apic_common.c: * SPDX-License-Identifier: GPL-2.0
> arch/s390/tools/gen_opcode_table.c:/* SPDX-License-Identifier: GPL-2.0 */
> arch/arm64/crypto/sha3-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */
> arch/arm64/crypto/sha512-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */
> arch/riscv/kernel/ftrace.c:/* SPDX-License-Identifier: GPL-2.0 */
> arch/riscv/kernel/module-sections.c:/* SPDX-License-Identifier: GPL-2.0
> drivers/tty/hvc/hvc_riscv_sbi.c:/* SPDX-License-Identifier: GPL-2.0 */
> 

Re: [U-Boot] GCC 7.x vs. C++ comments

[Wolfgang Denk]

Dear Tom,

In message <20180509154052.5e0b4240...@gemini.denx.de> I wrote:
> 
> > - Don't like // style comments
> > - Visually inconsistent / jarring
> 
> - Against existing coding style.

Also, the SPDX tag is rarely a separate comment line.  In most
cases, it is part of a larger file header, say for example:

common/main.c:

/*
 * (C) Copyright 2000
 * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 *
 * SPDX-License-Identifier: GPL-2.0+
 */


Do you suggest to reformat this into something like:

/*
 * (C) Copyright 2000
 * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 */

// SPDX-License-Identifier: GPL-2.0+

?

If yes, then please explain which sense this would make?  It is just
unnecessay work, and the result is inconsistent and ugly.


> > - Has tooling to enforce correctly formatted tags.

I forgot to ask which "tooling" you have in mind here?  I did not
see anything like that in the kernel source tree.  What am I
missing?

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
This restaurant was advertising breakfast  any  time.  So  I  ordered
french toast in the renaissance.- Steven Wright, comedian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] GCC 7.x vs. C++ comments

[Wolfgang Denk]

Dear Tom,

In message <20180509134905.gk12...@bill-the-cat.ec.rr.com> you wrote:
> 
> > Marek already said what was on my mind, and got ignored.
> > Would it have changed anything if I had posted another complaint?
>
> Ignored, no.  Counts as a veto?  No.  And if you had chimed in too, I
> don't know if that would have gotten anyone else to also chime in.

This does not really convince me.

IMO it makes no sense to blow up mailing list traffic with extensive
voting for such things. Marek said everything that needed to be
said, and repeating it would IMO not add any weight to it.  If you
really want a poll including more people, then explicitly start one
- but please not on the mailing list, at least not fuch such
details.

> It's not futile, but here's as best I can tell, the arguments:
> Against Linux Kernel style SPDX tags:

I think this argument is wrong from the start.  This is not about
"Linux Kernel style SPDX tags".  There is two different topics,
which are actually independent, and should be treated as such:

- Linux Kernel style SPDX tags, or rather more modern SPDX tags
  including the needed operators to deal with exceptions, multiple
  licenses, etc.  When I invented the SPDX tags I did not foresee
  this need (my fault), but I'm still proud that U-Boot introduced
  this mechanism at all.

  Yes, it is necessary to adapt the new developments in this area.

- Comment style.  This is just a matter of coding style and
  preferences.  Whether you use C comments (single line or
  multi-line) or C++ comments does not make any difference
  technically.

  U-Boot has been discouraging the use of C++ comments for 18 years,
  and I still see no good reason to change this.  [And yes, we also
  have the rule not to meddle with code copied from other projects.]

> - Don't like // style comments
> - Visually inconsistent / jarring

- Against existing coding style.


> For Linux Kernel style SPDX tags:
> - Has higher visibility.

??? I can't parse this.  In which way has

// SPDX-License-Identifier: GPL-2.0+

"higher visibility" than

/* SPDX-License-Identifier: GPL-2.0+ */

or even

/*
 * SPDX-License-Identifier: GPL-2.0+
 */

?

[IMO, the last form is the most visible one.]

And since when do we care about a single line of white space or two
when it comes to consistency or readability?

> - Has tooling to enforce correctly formatted tags.


> - Shorter (enforced as a single line comment means we don't have people
>   spacing around it).

Come on, this argument is really lame.

> - Consistent expectations for our overlapping developer community.

Please explain?  Who associates SPDX tags with C++ comments?  This
is silly.  We don't use these in Makefiles, or in shell scripts, or
in ...

And when talking about consistency - what about this in the current
Linux Kernel tree:

arch/x86/kernel/apic/apic_common.c: * SPDX-License-Identifier: GPL-2.0
arch/s390/tools/gen_opcode_table.c:/* SPDX-License-Identifier: GPL-2.0 */
arch/arm64/crypto/sha3-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */
arch/arm64/crypto/sha512-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */
arch/riscv/kernel/ftrace.c:/* SPDX-License-Identifier: GPL-2.0 */
arch/riscv/kernel/module-sections.c:/* SPDX-License-Identifier: GPL-2.0
drivers/tty/hvc/hvc_riscv_sbi.c:/* SPDX-License-Identifier: GPL-2.0 */
drivers/memory/brcmstb_dpfe.c: * SPDX-License-Identifier: GPL-2.0
drivers/soc/amlogic/meson-mx-socinfo.c: * SPDX-License-Identifier: GPL-2.0+
drivers/soc/amlogic/meson-gx-pwrc-vpu.c: * SPDX-License-Identifier: GPL-2.0+
drivers/soc/amlogic/meson-gx-socinfo.c: * SPDX-License-Identifier: GPL-2.0+
drivers/i2c/busses/i2c-sprd.c: * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c: * SPDX-License-Identifier: 
(GPL-2.0+ or MIT)
drivers/pinctrl/meson/pinctrl-meson-axg.c: * SPDX-License-Identifier: (GPL-2.0+ 
or MIT)
drivers/virt/vboxguest/vboxguest_core.c:/* SPDX-License-Identifier: (GPL-2.0 OR 
CDDL-1.0) */
drivers/virt/vboxguest/vboxguest_linux.c:/* SPDX-License-Identifier: GPL-2.0 */
drivers/virt/vboxguest/vboxguest_utils.c:/* SPDX-License-Identifier: (GPL-2.0 
OR CDDL-1.0) */
drivers/watchdog/rtd119x_wdt.c: * SPDX-License-Identifier: GPL-2.0+
drivers/rtc/rtc-rtd119x.c: * SPDX-License-Identifier: GPL-2.0+
drivers/rtc/rtc-sc27xx.c: * SPDX-License-Identifier: GPL-2.0
...


Yes, 47 files is only a small fraction compared against the 5261
C files with C++ commented tags. But consistency of apparently not a
real issue when it comes to comment style in Linux.


> Things that could be taken, without changing overall formatting:
> - Logic operators for exceptions/dual-license/etc

Right, this is completely independent and out of question here.

> If people speak up against the change now that we've done it, we could
> revert and then add in the "LICENSE-A OR LICENSE-B" change.  Thanks!

I have always been against the use of C++ comments in U-Boot (and in
general in non C++ code), and I still am against it.

Not that this 

[U-Boot] [PATCH] drivers/net/vsc9953: Initialize action RAM in VCAP complex

[radu-andrei.bulie]

From: Radu Bulie 

VCAP tables must be initialized even if no advanced classification
is used. If no initialization is performed, then ECC error will
be observed by the user when the first packet enters the l2switch.
The error is marked in MPIC_EISR0 -bit 29 which means - Internal RAM
multi-bit ECC error.
This patch fixes the aforementioned ECC error by performing the
initialization of VCAP tables.

Signed-off-by: Radu Bulie 
---
 drivers/net/vsc9953.c | 134 ++
 include/vsc9953.h |  58 ++
 2 files changed, 192 insertions(+)

diff --git a/drivers/net/vsc9953.c b/drivers/net/vsc9953.c
index 2388438..f90181d 100644
--- a/drivers/net/vsc9953.c
+++ b/drivers/net/vsc9953.c
@@ -2469,6 +2469,139 @@ void vsc9953_default_configuration(void)
debug("VSC9953: failed to set default aggregation code mode\n");
 }
 
+static void vcap_entry2cache_init(u32 target, u32 entry_words)
+{
+   int i;
+
+   for (i = 0; i < entry_words; i++) {
+   out_le32((unsigned int *)(VSC9953_OFFSET +
+   VSC9953_VCAP_CACHE_ENTRY_DAT(target, i)), 0x00);
+   out_le32((unsigned int *)(VSC9953_OFFSET +
+   VSC9953_VCAP_CACHE_MASK_DAT(target, i)), 0xFF);
+   }
+
+   out_le32((unsigned int *)(VSC9953_OFFSET +
+   VSC9953_VCAP_CACHE_TG_DAT(target)), 0x00);
+   out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CFG_MV_CFG(target)),
+VSC9953_VCAP_CFG_MV_CFG_SIZE(entry_words));
+}
+
+static void vcap_action2cache_init(u32 target, u32 action_words,
+  u32 counter_words)
+{
+   int i;
+
+   for (i = 0; i < action_words; i++)
+   out_le32((unsigned int *)(VSC9953_OFFSET +
+  VSC9953_VCAP_CACHE_ACTION_DAT(target, i)), 0x00);
+
+   for (i = 0; i < counter_words; i++)
+   out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CACHE_CNT_DAT(target, i)), 0x00);
+}
+
+static int vcap_cmd(u32 target, u16 ix, int cmd, int sel, int entry_count)
+{
+   u32 tgt = target;
+   u32 value = (VSC9953_VCAP_UPDATE_CTRL_UPDATE_CMD(cmd) |
+VSC9953_VCAP_UPDATE_CTRL_UPDATE_ADDR(ix) |
+VSC9953_VCAP_UPDATE_CTRL_UPDATE_SHOT);
+
+   if ((sel & TCAM_SEL_ENTRY) && ix >= entry_count)
+   return CMD_RET_FAILURE;
+
+   if (!(sel & TCAM_SEL_ENTRY))
+   value |= VSC9953_VCAP_UPDATE_CTRL_UPDATE_ENTRY_DIS;
+
+   if (!(sel & TCAM_SEL_ACTION))
+   value |= VSC9953_VCAP_UPDATE_CTRL_UPDATE_ACTION_DIS;
+
+   if (!(sel & TCAM_SEL_COUNTER))
+   value |= VSC9953_VCAP_UPDATE_CTRL_UPDATE_CNT_DIS;
+
+   out_le32((unsigned int *)(VSC9953_OFFSET +
+   VSC9953_VCAP_CFG_UPDATE_CTRL(tgt)), value);
+
+   do {
+   value = in_le32((unsigned int *)(VSC9953_OFFSET +
+   VSC9953_VCAP_CFG_UPDATE_CTRL(tgt)));
+
+   } while (value & VSC9953_VCAP_UPDATE_CTRL_UPDATE_SHOT);
+
+   return CMD_RET_SUCCESS;
+}
+
+static void vsc9953_vcap_init(void)
+{
+   u32 tgt = VSC9953_ES0;
+   int cmd_ret;
+
+   /* write entries */
+   vcap_entry2cache_init(tgt, ENTRY_WORDS_ES0);
+   cmd_ret = vcap_cmd(tgt, 0, TCAM_CMD_INITIALIZE, TCAM_SEL_ENTRY,
+  ENTRY_WORDS_ES0);
+   if (cmd_ret != CMD_RET_SUCCESS)
+   debug("VSC9953:%d invalid TCAM_SEL_ENTRY\n",
+ __LINE__);
+
+   /* write actions and counters */
+   vcap_action2cache_init(tgt, BITS_TO_DWORD(91), BITS_TO_DWORD(1));
+   out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CFG_MV_CFG(tgt)),
+VSC9953_VCAP_CFG_MV_CFG_SIZE(VSC9953_ES0_CNT + VSC9953_PORTS));
+   cmd_ret = vcap_cmd(tgt, 0, TCAM_CMD_INITIALIZE,
+  TCAM_SEL_ACTION | TCAM_SEL_COUNTER, ENTRY_WORDS_ES0);
+   if (cmd_ret != CMD_RET_SUCCESS)
+   debug("VSC9953:%d invalid TCAM_SEL_ACTION | TCAM_SEL_COUNTER\n",
+ __LINE__);
+
+   tgt = VSC9953_IS1;
+
+   /* write entries */
+   vcap_entry2cache_init(tgt, ENTRY_WORDS_IS1);
+   cmd_ret = vcap_cmd(tgt, 0, TCAM_CMD_INITIALIZE, TCAM_SEL_ENTRY,
+  ENTRY_WORDS_IS1);
+   if (cmd_ret != CMD_RET_SUCCESS)
+   debug("VSC9953:%d invalid TCAM_SEL_ENTRY\n",
+ __LINE__);
+
+   /* write actions and counters */
+   vcap_action2cache_init(tgt, BITS_TO_DWORD(320), BITS_TO_DWORD(4));
+   out_le32((unsigned int *)(VSC9953_OFFSET +
+ VSC9953_VCAP_CFG_MV_CFG(tgt)),
+VSC9953_VCAP_CFG_MV_CFG_SIZE(VSC9953_IS1_CNT + 1));
+ 

Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups

[Eugeniu Rosca]

On Wed, May 09, 2018 at 07:23:19AM -0400, Tom Rini wrote:
> On Wed, May 09, 2018 at 08:32:56AM +, yamada.masah...@socionext.com wrote:
> > Tom will make a decision.
> > 
> > Just my thought.
> > 
> > 
> > U-Boot is basically a mirror of Linux.
> > 
> > Syncing Kconfig will add new tool requirement, flex & bison, for building 
> > U-Boot,
> > but this is OK because Linux does it.
> > 
> > U-Boot follows Linux, for example, recently U-Boot adopted Linux-like SPDX 
> > license tag style.
> > 
> > 
> > And, you understand well the points for resyncing.
> > Yes, other parts must be adjusted.
> > 
> > So, I am happy if you contribute to this work.
> 
> Yes, I'm fine adding flex/bison as build requirements.  And I'm also
> fine with anyone that feels they can handle doing the re-sync doing the
> re-sync, thanks folks!
> 
> -- 
> Tom

I will take care of it in the next days.
Thanks for your support, Tom, Masahiro and Petr.

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

Re: [U-Boot] [PATCH 2/2] ARM: Add a new arch + board for QEMU's 'virt' machine

[Paulo Neves]

Hello I have successfully built u-boot and launched qemu with the
flags proposed by the patch. My problems start when I try to boot the
kernel

What is the linux kernel defconfig that should be used to boot this
machine? I tried the versatile one but they are different in some key
places like the sd card. The end result is that I can only see
Starting Kernel, and nothing else. What bootargs do you pass to the
kernel to have the serial output in qemu?

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

Re: [U-Boot] GCC 7.x vs. C++ comments

[Dr. Philipp Tomsich]

> On 9 May 2018, at 15:49, Tom Rini  wrote:
> 
> On Wed, May 09, 2018 at 02:46:54PM +0200, Wolfgang Denk wrote:
>> Dear Tom,
>> 
>> In message <20180509114828.gg12...@bill-the-cat.ec.rr.com> you wrote:
>>> 
>>> We should go and update [1] to note some special exemptions to the rule.
>> 
>> I'm not happy about this.
>> 
>>> I see you missed out on the SPDX thread over here:
>>> https://lists.denx.de/pipermail/u-boot/2018-May/327544.html and repeat
>> 
>> Marek already said what was on my mind, and got ignored.
>> Would it have changed anything if I had posted another complaint?
> 
> Ignored, no.  Counts as a veto?  No.  And if you had chimed in too, I
> don't know if that would have gotten anyone else to also chime in.
> Looking over the thread again there's two yes votes, two no votes, two
> people that chimed in on the thread but didn't express a yes or no to
> the change, and then no one else has said anything.  The main thing I
> see currently is a whole lot of ambivalence.

Although I am ambivalent to the underlying discussion, I have strong
opinions regarding the language/standard-compliance...

My vote goes to C++ comments and upgrading the language standard
to C99 (or rather gnu99, as our code uses extensions).  This will (at least
somewhat) match how the default C compliance level in GCC has evolved
over the GCC 6 through GCC 8 release cycles.

And while we’re at it, we should allow "for (int i = 0; …”-style C99 declaration
of loop iterations within the loop-head.

> 
>> I'm doing now, and apparently I get ignored, too.  So what exactly
>> is your argument?
>> 
>>> myself, I see it as more worthwhile to (a) follow the kernel in this
>>> area (for both tooling and consistency and ease of development for our
>>> overlapping community) (b) save space (in just about every conversion we
>>> went from 2 lines to 1 line).  Thanks!
>> 
>> OK, so you decided, and any additional discussion is futile...
> 
> It's not futile, but here's as best I can tell, the arguments:
> Against Linux Kernel style SPDX tags:
> - Don't like // style comments
> - Visually inconsistent / jarring
> 
> For Linux Kernel style SPDX tags:
> - Has higher visibility.
> - Has tooling to enforce correctly formatted tags.
> - Shorter (enforced as a single line comment means we don't have people
>  spacing around it).
> - Consistent expectations for our overlapping developer community.
> 
> Things that could be taken, without changing overall formatting:
> - Logic operators for exceptions/dual-license/etc
> 
> If people speak up against the change now that we've done it, we could
> revert and then add in the "LICENSE-A OR LICENSE-B" change.  Thanks!
> 
> -- 
> Tom

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

Re: [U-Boot] GCC 7.x vs. C++ comments

[Tom Rini]

On Wed, May 09, 2018 at 02:46:54PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180509114828.gg12...@bill-the-cat.ec.rr.com> you wrote:
> > 
> > We should go and update [1] to note some special exemptions to the rule.
> 
> I'm not happy about this.
> 
> > I see you missed out on the SPDX thread over here:
> > https://lists.denx.de/pipermail/u-boot/2018-May/327544.html and repeat
> 
> Marek already said what was on my mind, and got ignored.
> Would it have changed anything if I had posted another complaint?

Ignored, no.  Counts as a veto?  No.  And if you had chimed in too, I
don't know if that would have gotten anyone else to also chime in.
Looking over the thread again there's two yes votes, two no votes, two
people that chimed in on the thread but didn't express a yes or no to
the change, and then no one else has said anything.  The main thing I
see currently is a whole lot of ambivalence.

> I'm doing now, and apparently I get ignored, too.  So what exactly
> is your argument?
> 
> > myself, I see it as more worthwhile to (a) follow the kernel in this
> > area (for both tooling and consistency and ease of development for our
> > overlapping community) (b) save space (in just about every conversion we
> > went from 2 lines to 1 line).  Thanks!
> 
> OK, so you decided, and any additional discussion is futile...

It's not futile, but here's as best I can tell, the arguments:
Against Linux Kernel style SPDX tags:
- Don't like // style comments
- Visually inconsistent / jarring

For Linux Kernel style SPDX tags:
- Has higher visibility.
- Has tooling to enforce correctly formatted tags.
- Shorter (enforced as a single line comment means we don't have people
  spacing around it).
- Consistent expectations for our overlapping developer community.

Things that could be taken, without changing overall formatting:
- Logic operators for exceptions/dual-license/etc

If people speak up against the change now that we've done it, we could
revert and then add in the "LICENSE-A OR LICENSE-B" change.  Thanks!

-- 
Tom


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

[U-Boot] [PATCH v2 2/2] test: fs: fs-test: Modified test 1 to do a ls to a nonexistent dir

[Eugen Hristev]

Added a simple ls to a nonexistent directory for test 1.
In case the driver is broken for a nonexistent directory, U-boot
might crash.

Here is an example failed output:

=> # Test Case 1 - ls
=> ext4ls host 0:0
   4096 .
   4096 ..
  16384 lost+found
   4096 SUBDIR
  262144 2.5GB.file
 1048576 1MB.file
=> # In addition, test with a nonexistent directory to see if we crash.
=> ext4ls host 0:0 invalid_d
** Can not find directory. **
./test/fs/fs-test.sh: line 161: 25786 Segmentation fault  (core dumped) 
$UBOOT  <
---

Hello,

Not sure whether this is the best test for this case, but I tried to do
a separate case and:
cannot really tell if it passed or not by just watching the output
(several FS show nothing, EXT4 shows "Can not find directory"),
so not really any string I can grep for to send to pass_fail function.
So, I decided to add another command to test no 1, which is a basic 'ls' test
to some 'invalid_d' directory.
Like this, we won't see anything in the output, but, if U-boot crashes, the
whole test series fails.


 test/fs/fs-test.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh
index 20d5dd8..6bb5311 100755
--- a/test/fs/fs-test.sh
+++ b/test/fs/fs-test.sh
@@ -225,6 +225,8 @@ setenv bind 'if test "\$sb" != sb; then sb bind 0 "$1"; fi'
 run bind
 # Test Case 1 - ls
 ${PREFIX}ls host${SUFFIX} $6
+# In addition, test with a nonexistent directory to see if we crash.
+${PREFIX}ls host${SUFFIX} invalid_d
 #
 # We want ${PREFIX}size host 0:0 $3 for host commands and
 # sb size hostfs - $3 for hostfs commands.
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/2] fs: ext4: fix crash on ext4ls

[Eugen Hristev]

Found a crash while issuing ext4ls with a non-existent directory.
Crash test:

=> ext4ls mmc 0 1
** Can not find directory. **
data abort
pc : [<3fd7c2ec>]  lr : [<3fd93ed8>]
reloc pc : [<26f142ec>]lr : [<26f2bed8>]
sp : 3f963338  ip : 3fdc3dc4 fp : 3fd6b370
r10: 0004  r9 : 3f967ec0 r8 : 3f96db68
r7 : 3fdc99b4  r6 :  r5 : 3f96dc88  r4 : 3fdcbc8c
r3 : fffa  r2 :  r1 : 3f96e0bc  r0 : 0002
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

Tested on SAMA5D2_Xplained board (sama5d2_xplained_mmc_defconfig)

Looks like crash is introduced by commit:
"fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls

Issue is that dirnode is not initialized, and then freed if the call
to ext4_ls fails. ext4_ls will not change the value of dirnode in this case
thus we have a crash with data abort.

I added initialization and a check for dirname being NULL.

Fixes: "fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
Cc: Stefan Brüns 
Cc: Tom Rini 
Signed-off-by: Eugen Hristev 
---
Changes in v2:
 - Added test case in test/fs/fs-test.sh in a different commit

 fs/ext4/ext4fs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 4b36a3e..2a28031 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -164,7 +164,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
 
 int ext4fs_ls(const char *dirname)
 {
-   struct ext2fs_node *dirnode;
+   struct ext2fs_node *dirnode = NULL;
int status;
 
if (dirname == NULL)
@@ -174,7 +174,8 @@ int ext4fs_ls(const char *dirname)
  FILETYPE_DIRECTORY);
if (status != 1) {
printf("** Can not find directory. **\n");
-   ext4fs_free_node(dirnode, _root->diropen);
+   if (dirnode)
+   ext4fs_free_node(dirnode, _root->diropen);
return 1;
}
 
-- 
2.7.4

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

[U-Boot] SPL too big for Turris Omnia in v2018.05

[guillaume . gardet]

Hi,

While trying to build u-boot for Turris Omnia board in v2018.05 with GCC 7.3.1, 
I get the following error:

  MKIMAGE u-boot-spl.kwb
Error: Image header (incl. SPL image) too big!
header=0x240f1 CONFIG_SYS_U_BOOT_OFFS=0x24000!
Increase CONFIG_SYS_U_BOOT_OFFS!
Error: Image header (incl. SPL image) too big!
header=0x240f1 CONFIG_SYS_U_BOOT_OFFS=0x24000!
Increase CONFIG_SYS_U_BOOT_OFFS!
Could not create image
make: *** [Makefile:1097: u-boot-spl.kwb] Error 1



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

Re: [U-Boot] [PATCH 3/3] i2c: Drop CONFIG_SH_SH7734_I2C

[Heiko Schocher]

Hello Tuomas,

Am 09.05.2018 um 14:24 schrieb Tuomas Tynkkynen:

Last user of this driver went away in May 2017 in commit
eb5ba3aefdf0f6c ("i2c: Drop use of CONFIG_I2C_HARD").

Signed-off-by: Tuomas Tynkkynen 
---
  doc/driver-model/i2c-howto.txt |   1 -
  drivers/i2c/Makefile   |   1 -
  drivers/i2c/sh_sh7734_i2c.c| 376 -
  3 files changed, 378 deletions(-)
  delete mode 100644 drivers/i2c/sh_sh7734_i2c.c


Thanks!

Acked-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH 2/3] i2c: Drop CONFIG_TSI108_I2C

[Heiko Schocher]

Hello Tuomas,

Am 09.05.2018 um 14:24 schrieb Tuomas Tynkkynen:

Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")

Signed-off-by: Tuomas Tynkkynen 
---
  doc/driver-model/i2c-howto.txt |   1 -
  drivers/i2c/Makefile   |   1 -
  drivers/i2c/tsi108_i2c.c   | 275 -
  include/tsi108.h   | 207 ---
  4 files changed, 484 deletions(-)
  delete mode 100644 drivers/i2c/tsi108_i2c.c
  delete mode 100644 include/tsi108.h


Acked-by: Heiko Schocher 

Thanks!

bye,
Heiko


diff --git a/doc/driver-model/i2c-howto.txt b/doc/driver-model/i2c-howto.txt
index 605d3ef7ad..1b2c5312c4 100644
--- a/doc/driver-model/i2c-howto.txt
+++ b/doc/driver-model/i2c-howto.txt
@@ -16,7 +16,6 @@ ones remain:
 sh_i2c
 sh_sh7734_i2c
 soft_i2c
-   tsi108_i2c
 zynq_i2c
  
  The deadline for this work is the end of June 2017. If no one steps

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index e8bb6327fb..795dd33c64 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
  obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
  
  obj-$(CONFIG_I2C_MV) += mv_i2c.o

-obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
  obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
  obj-$(CONFIG_SYS_I2C) += i2c_core.o
  obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
diff --git a/drivers/i2c/tsi108_i2c.c b/drivers/i2c/tsi108_i2c.c
deleted file mode 100644
index 208c0900ef..00
--- a/drivers/i2c/tsi108_i2c.c
+++ /dev/null
@@ -1,275 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2004 Tundra Semiconductor Corp.
- * Author: Alex Bounine
- *
- * NOTE: This driver should be converted to driver model before June 2017.
- * Please see doc/driver-model/i2c-howto.txt for instructions.
- */
-
-#include 
-#include 
-
-#include 
-
-#if defined(CONFIG_CMD_I2C)
-
-#define I2C_DELAY  10
-#undef  DEBUG_I2C
-
-#ifdef DEBUG_I2C
-#define DPRINT(x) printf (x)
-#else
-#define DPRINT(x)
-#endif
-
-/* All functions assume that Tsi108 I2C block is the only master on the bus */
-/* I2C read helper function */
-
-void i2c_init(int speed, int slaveaddr)
-{
-   /*
-* The TSI108 has a fixed I2C clock rate and doesn't support slave
-* operation.  This function only exists as a stub to fit into the
-* U-Boot I2C API.
-*/
-}
-
-static int i2c_read_byte (
-   uint i2c_chan,  /* I2C channel number: 0 - main, 1 - SDC SPD */
-   uchar chip_addr,/* I2C device address on the bus */
-   uint byte_addr, /* Byte address within I2C device */
-   uchar * buffer  /* pointer to data buffer */
-   )
-{
-   u32 temp;
-   u32 to_count = I2C_DELAY;
-   u32 op_status = TSI108_I2C_TIMEOUT_ERR;
-   u32 chan_offset = TSI108_I2C_OFFSET;
-
-   DPRINT (("I2C read_byte() %d 0x%02x 0x%02x\n",
-   i2c_chan, chip_addr, byte_addr));
-
-   if (0 != i2c_chan)
-   chan_offset = TSI108_I2C_SDRAM_OFFSET;
-
-   /* Check if I2C operation is in progress */
-   temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + I2C_CNTRL2);
-
-   if (0 == (temp & (I2C_CNTRL2_RD_STATUS | I2C_CNTRL2_WR_STATUS |
- I2C_CNTRL2_START))) {
-   /* Set device address and operation (read = 0) */
-   temp = (byte_addr << 16) | ((chip_addr & 0x07) << 8) |
-   ((chip_addr >> 3) & 0x0F);
-   *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + 
I2C_CNTRL1) =
-   temp;
-
-   /* Issue the read command
-* (at this moment all other parameters are 0
-* (size = 1 byte, lane = 0)
-*/
-
-   *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + 
I2C_CNTRL2) =
-   (I2C_CNTRL2_START);
-
-   /* Wait until operation completed */
-   do {
-   /* Read I2C operation status */
-   temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + 
chan_offset + I2C_CNTRL2);
-
-   if (0 == (temp & (I2C_CNTRL2_RD_STATUS | 
I2C_CNTRL2_START))) {
-   if (0 == (temp &
-(I2C_CNTRL2_I2C_CFGERR |
- I2C_CNTRL2_I2C_TO_ERR))
-   ) {
-   op_status = TSI108_I2C_SUCCESS;
-
-   temp = *(u32 *) 
(CONFIG_SYS_TSI108_CSR_BASE +
-chan_offset +
-I2C_RD_DATA);
-
-   *buffer = (u8) (temp & 0xFF);
-   } else 

Re: [U-Boot] GCC 7.x vs. C++ comments

[Wolfgang Denk]

Dear Tom,

In message <20180509114828.gg12...@bill-the-cat.ec.rr.com> you wrote:
> 
> We should go and update [1] to note some special exemptions to the rule.

I'm not happy about this.

> I see you missed out on the SPDX thread over here:
> https://lists.denx.de/pipermail/u-boot/2018-May/327544.html and repeat

Marek already said what was on my mind, and got ignored.
Would it have changed anything if I had posted another complaint?

I'm doing now, and apparently I get ignored, too.  So what exactly
is your argument?

> myself, I see it as more worthwhile to (a) follow the kernel in this
> area (for both tooling and consistency and ease of development for our
> overlapping community) (b) save space (in just about every conversion we
> went from 2 lines to 1 line).  Thanks!

OK, so you decided, and any additional discussion is futile...

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
It is practically impossible to teach good programming style to  stu-
dents that have had prior exposure to BASIC: as potential programmers
they are mentally mutilated beyond hope of regeneration.   - Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: zynq: Add initial support for Avnet MiniZed

[Michal Simek]

On 4.5.2018 11:40, Ibai Erkiaga wrote:
> Initial support for Avnet MiniZed board. Tested UART1 (serial console),
> QSPI(Flash), SDHCI1 (eMMC), USB.
> 
> Signed-off-by: Ibai Erkiaga 
> ---
>  arch/arm/dts/Makefile  |1 +
>  arch/arm/dts/zynq-minized.dts  |  115 
> 
>  configs/zynq_minized_defconfig |   68 +++
>  3 files changed, 184 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/dts/zynq-minized.dts
>  create mode 100644 configs/zynq_minized_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index ac7667b..ba1e261 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -131,6 +131,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
>   zynq-cc108.dtb \
>   zynq-cse-qspi-single.dtb \
>   zynq-microzed.dtb \
> + zynq-minized.dtb \
>   zynq-picozed.dtb \
>   zynq-syzygy-hub.dtb \
>   zynq-topic-miami.dtb \
> diff --git a/arch/arm/dts/zynq-minized.dts b/arch/arm/dts/zynq-minized.dts
> new file mode 100644
> index 000..ecf1bc0
> --- /dev/null
> +++ b/arch/arm/dts/zynq-minized.dts
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Avnet MiniZed board
> + *
> + * (C) Copyright 2017 - 2018, Xilinx, Inc.
> + *
> + * Ibai Erkiaga 
> + */
> +
> +/dts-v1/;
> +#include "zynq-7000.dtsi"
> +
> +/ {
> + model = "Zynq MiniZed Development Board";
> + compatible = "xlnx,zynq-zed", "xlnx,zynq-7000";

My patch for adding avnet prefix to kernel was accepted.
That's why use:
model = "Avnet Zynq MiniZed Development Board";
compatible = "avnet,minized", "xlnx,zynq-7000";

> +
> + aliases {
> + serial0 = 
> + serial1 = 
> + spi0 = 
> + mmc0 = 
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x2000>;
> + };
> +
> + chosen {
> + bootargs = "";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + usb_phy0: phy0@e0002000 {
> + compatible = "ulpi-phy";
> + #phy-cells = <0>;
> + reg = <0xe0002000 0x1000>;
> + view-port = <0x0170>;
> + drv-vbus;
> + };

Please check other boards. This ulpi-phy is just in Xilinx git repo.

> +};
> +
> + {
> + emio-gpio-width = <4>;
> + gpio-mask-high = <0x0>;
> + gpio-mask-low = <0x5600>;

This is not the part of binding.

> +};
> +
> + {
> + num_cpus = <2>;
> + num_interrupts = <96>;

this is not the part of kernel intc binding doc.
It looks like qemu binding.


> +};
> +
> + {
> + status = "okay";
> + is-dual = <0>;
> + num-cs = <1>;
> + flash@0 {
> + compatible = "micron,m25p128";
> + reg = <0x0>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + spi-max-frequency = <5000>;
> +

please use "fixed-partitions" here.


> + partition@0x {

remove 0x from node name and the same below.

> + label = "boot";
> + reg = <0x0 0xff>;
> + };
> +
> + partition@0x0027 {
> + label = "kernel";
> + reg = <0x27 0xd8>;
> + };
> +
> + partition@0x00ff {
> + label = "bootenv";
> + reg = <0xff 0x1>;
> + };
> +
> + partition@0x0100 {
> + label = "spare";
> + reg = <0x100 0x0>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <_phy0>;
> + usb-reset = < 7 0>; /* USB_RST_N-MIO7 */
> +};
> +
> + {
> + status = "okay";
> + non-removable;
> + bus-width= <4>;

missing space.

> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + mmccard: mmccard@0 {
> + compatible = "mmc-card";
> + reg = <0>;
> + broken-hpi;
> + };
> +};
> diff --git a/configs/zynq_minized_defconfig b/configs/zynq_minized_defconfig
> new file mode 100644
> index 000..05cfc0e
> --- /dev/null
> +++ b/configs/zynq_minized_defconfig
> @@ -0,0 +1,68 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ZYNQ=y
> +CONFIG_SYS_TEXT_BASE=0x400
> +CONFIG_SPL=y
> +CONFIG_SPL_STACK_R_ADDR=0x20
> +CONFIG_DEFAULT_DEVICE_TREE="zynq-minized"
> +CONFIG_DEBUG_UART=y
> +CONFIG_DISTRO_DEFAULTS=y
> +CONFIG_FIT=y
> +CONFIG_FIT_SIGNATURE=y
> +CONFIG_FIT_VERBOSE=y
> +CONFIG_BOOTCOMMAND="run $modeboot || run distro_bootcmd"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_OS_BOOT=y
> +CONFIG_SYS_PROMPT="Zynq> "
> +CONFIG_CMD_THOR_DOWNLOAD=y
> +CONFIG_CMD_DFU=y
> +# CONFIG_CMD_FLASH is not 

Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug

[klaus . goger]

> On 09.05.2018, at 10:19, Markus Krebs  wrote:
> 
> Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:
>> On 2018-05-08, Vagrant Cascadian wrote:
>>> On 2018-05-05, Tom Rini wrote:
 On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
> Markus Krebs discovered that the sheevaplug target has again grown and
> installation overlaps where the u-boot env is saved since u-boot
> ~2017.09. Running saveenv overwrites u-boot, and installing u-boot
> overwrites any prior environment settings.
>> ...
 I've added the maintainer to the list as well.  I would suggest looking
 for things to trim out, perhaps CMD_MEMTEST ?
>>> 
>>> Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
>>> EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
>>> *lot* left to disable in the config, but that's a significant start...
>> And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
>> down to 432k! Thanks to beeble for the suggestion.
>> Anyone who has a sheevaplug can test that it actually boots with
>> CONFIG_SYS_THUMB_BUILD=y enabled?
> 
> I could test it, but I don't know the config-file where I can change those 
> options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).

Both are Kconfig options. So just disable it via menuconfig or in your .config 
file
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/3] net: Drop CONFIG_TSI108_ETH

[Tuomas Tynkkynen]

Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/net/Makefile |1 -
 drivers/net/tsi108_eth.c | 1015 --
 include/netdev.h |1 -
 scripts/config_whitelist.txt |1 -
 4 files changed, 1018 deletions(-)
 delete mode 100644 drivers/net/tsi108_eth.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 851f82fb01..584bfdf2f9 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -58,7 +58,6 @@ obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
 obj-$(CONFIG_TSEC_ENET) += tsec.o fsl_mdio.o
 obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o
 obj-$(CONFIG_FMAN_ENET) += fsl_mdio.o
-obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o
 obj-$(CONFIG_ULI526X) += uli526x.o
 obj-$(CONFIG_VSC7385_ENET) += vsc7385.o
 obj-$(CONFIG_XILINX_AXIEMAC) += xilinx_axi_emac.o
diff --git a/drivers/net/tsi108_eth.c b/drivers/net/tsi108_eth.c
deleted file mode 100644
index 108cf61647..00
--- a/drivers/net/tsi108_eth.c
+++ /dev/null
@@ -1,1015 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/***
- *
- * Copyright (c) 2005 Freescale Semiconductor, Inc.
- *
- * Description:
- *   Ethernet interface for Tundra TSI108 bridge chip
- *
- ***/
-
-#include 
-
-#if !defined(CONFIG_TSI108_ETH_NUM_PORTS) || (CONFIG_TSI108_ETH_NUM_PORTS > 2)
-#error "CONFIG_TSI108_ETH_NUM_PORTS must be defined as 1 or 2"
-#endif
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#ifdef DEBUG
-#define TSI108_ETH_DEBUG 7
-#else
-#define TSI108_ETH_DEBUG 0
-#endif
-
-#if TSI108_ETH_DEBUG > 0
-#define debug_lev(lev, fmt, args...) \
-if (lev <= TSI108_ETH_DEBUG) \
-printf ("%s %d: " fmt, __FUNCTION__, __LINE__, ##args)
-#else
-#define debug_lev(lev, fmt, args...) do{}while(0)
-#endif
-
-#define RX_PRINT_ERRORS
-#define TX_PRINT_ERRORS
-
-#define ETH_BASE   (CONFIG_SYS_TSI108_CSR_BASE + 0x6000)
-
-#define ETH_PORT_OFFSET0x400
-
-#define __REG32(base, offset) (*((volatile u32 *)((char *)(base) + (offset
-
-#define reg_MAC_CONFIG_1(base) __REG32(base, 0x)
-#define MAC_CONFIG_1_TX_ENABLE (0x0001)
-#define MAC_CONFIG_1_SYNC_TX_ENABLE(0x0002)
-#define MAC_CONFIG_1_RX_ENABLE (0x0004)
-#define MAC_CONFIG_1_SYNC_RX_ENABLE(0x0008)
-#define MAC_CONFIG_1_TX_FLOW_CONTROL   (0x0010)
-#define MAC_CONFIG_1_RX_FLOW_CONTROL   (0x0020)
-#define MAC_CONFIG_1_LOOP_BACK (0x0100)
-#define MAC_CONFIG_1_RESET_TX_FUNCTION (0x0001)
-#define MAC_CONFIG_1_RESET_RX_FUNCTION (0x0002)
-#define MAC_CONFIG_1_RESET_TX_MAC  (0x0004)
-#define MAC_CONFIG_1_RESET_RX_MAC  (0x0008)
-#define MAC_CONFIG_1_SIM_RESET (0x4000)
-#define MAC_CONFIG_1_SOFT_RESET(0x8000)
-
-#define reg_MAC_CONFIG_2(base) __REG32(base, 0x0004)
-#define MAC_CONFIG_2_FULL_DUPLEX   (0x0001)
-#define MAC_CONFIG_2_CRC_ENABLE(0x0002)
-#define MAC_CONFIG_2_PAD_CRC   (0x0004)
-#define MAC_CONFIG_2_LENGTH_CHECK  (0x0010)
-#define MAC_CONFIG_2_HUGE_FRAME(0x0020)
-#define MAC_CONFIG_2_INTERFACE_MODE(val)   (((val) & 0x3) << 8)
-#define MAC_CONFIG_2_PREAMBLE_LENGTH(val)  (((val) & 0xf) << 12)
-#define INTERFACE_MODE_NIBBLE  1   /* 10/100 Mb/s MII) */
-#define INTERFACE_MODE_BYTE2   /* 1000 Mb/s GMII/TBI */
-
-#define reg_MAXIMUM_FRAME_LENGTH(base) __REG32(base, 0x0010)
-
-#define reg_MII_MGMT_CONFIG(base)  __REG32(base, 0x0020)
-#define MII_MGMT_CONFIG_MGMT_CLOCK_SELECT(val) ((val) & 0x7)
-#define MII_MGMT_CONFIG_NO_PREAMBLE(0x0010)
-#define MII_MGMT_CONFIG_SCAN_INCREMENT (0x0020)
-#define MII_MGMT_CONFIG_RESET_MGMT (0x8000)
-
-#define reg_MII_MGMT_COMMAND(base) __REG32(base, 0x0024)
-#define MII_MGMT_COMMAND_READ_CYCLE(0x0001)
-#define MII_MGMT_COMMAND_SCAN_CYCLE(0x0002)
-
-#define reg_MII_MGMT_ADDRESS(base) __REG32(base, 0x0028)
-#define reg_MII_MGMT_CONTROL(base) __REG32(base, 0x002c)
-#define reg_MII_MGMT_STATUS(base)  __REG32(base, 0x0030)
-
-#define reg_MII_MGMT_INDICATORS(base)  __REG32(base, 0x0034)
-#define MII_MGMT_INDICATORS_BUSY   (0x0001)
-#define MII_MGMT_INDICATORS_SCAN   (0x0002)
-#define MII_MGMT_INDICATORS_NOT_VALID  (0x0004)
-
-#define reg_INTERFACE_STATUS(base) __REG32(base, 0x003c)
-#define INTERFACE_STATUS_LINK_FAIL (0x0008)
-#define INTERFACE_STATUS_EXCESS_DEFER  (0x0200)
-
-#define reg_STATION_ADDRESS_1(base)__REG32(base, 

[U-Boot] [PATCH 3/3] i2c: Drop CONFIG_SH_SH7734_I2C

[Tuomas Tynkkynen]

Last user of this driver went away in May 2017 in commit
eb5ba3aefdf0f6c ("i2c: Drop use of CONFIG_I2C_HARD").

Signed-off-by: Tuomas Tynkkynen 
---
 doc/driver-model/i2c-howto.txt |   1 -
 drivers/i2c/Makefile   |   1 -
 drivers/i2c/sh_sh7734_i2c.c| 376 -
 3 files changed, 378 deletions(-)
 delete mode 100644 drivers/i2c/sh_sh7734_i2c.c

diff --git a/doc/driver-model/i2c-howto.txt b/doc/driver-model/i2c-howto.txt
index 1b2c5312c4..8ba2f6e267 100644
--- a/doc/driver-model/i2c-howto.txt
+++ b/doc/driver-model/i2c-howto.txt
@@ -14,7 +14,6 @@ ones remain:
ppc4xx_i2c
rcar_i2c
sh_i2c
-   sh_sh7734_i2c
soft_i2c
zynq_i2c
 
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 795dd33c64..e32d65dc2f 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
 obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
 
 obj-$(CONFIG_I2C_MV) += mv_i2c.o
-obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
 obj-$(CONFIG_SYS_I2C) += i2c_core.o
 obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
 obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
diff --git a/drivers/i2c/sh_sh7734_i2c.c b/drivers/i2c/sh_sh7734_i2c.c
deleted file mode 100644
index 6fe356baca..00
--- a/drivers/i2c/sh_sh7734_i2c.c
+++ /dev/null
@@ -1,376 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2012 Nobuhiro Iwamatsu 
- * Copyright (C) 2012 Renesas Solutions Corp.
- *
- * NOTE: This driver should be converted to driver model before June 2017.
- * Please see doc/driver-model/i2c-howto.txt for instructions.
- */
-
-#include 
-#include 
-#include 
-
-struct sh_i2c {
-   u8 iccr1;
-   u8 iccr2;
-   u8 icmr;
-   u8 icier;
-   u8 icsr;
-   u8 sar;
-   u8 icdrt;
-   u8 icdrr;
-   u8 nf2cyc;
-   u8 __pad0;
-   u8 __pad1;
-};
-
-static struct sh_i2c *base;
-static u8 iccr1_cks, nf2cyc;
-
-/* ICCR1 */
-#define SH_I2C_ICCR1_ICE   (1 << 7)
-#define SH_I2C_ICCR1_RCVD  (1 << 6)
-#define SH_I2C_ICCR1_MST   (1 << 5)
-#define SH_I2C_ICCR1_TRS   (1 << 4)
-#define SH_I2C_ICCR1_MTRS  \
-   (SH_I2C_ICCR1_MST | SH_I2C_ICCR1_TRS)
-
-/* ICCR1 */
-#define SH_I2C_ICCR2_BBSY  (1 << 7)
-#define SH_I2C_ICCR2_SCP   (1 << 6)
-#define SH_I2C_ICCR2_SDAO  (1 << 5)
-#define SH_I2C_ICCR2_SDAOP (1 << 4)
-#define SH_I2C_ICCR2_SCLO  (1 << 3)
-#define SH_I2C_ICCR2_IICRST(1 << 1)
-
-#define SH_I2C_ICIER_TIE   (1 << 7)
-#define SH_I2C_ICIER_TEIE  (1 << 6)
-#define SH_I2C_ICIER_RIE   (1 << 5)
-#define SH_I2C_ICIER_NAKIE (1 << 4)
-#define SH_I2C_ICIER_STIE  (1 << 3)
-#define SH_I2C_ICIER_ACKE  (1 << 2)
-#define SH_I2C_ICIER_ACKBR (1 << 1)
-#define SH_I2C_ICIER_ACKBT (1 << 0)
-
-#define SH_I2C_ICSR_TDRE   (1 << 7)
-#define SH_I2C_ICSR_TEND   (1 << 6)
-#define SH_I2C_ICSR_RDRF   (1 << 5)
-#define SH_I2C_ICSR_NACKF  (1 << 4)
-#define SH_I2C_ICSR_STOP   (1 << 3)
-#define SH_I2C_ICSR_ALOVE  (1 << 2)
-#define SH_I2C_ICSR_AAS(1 << 1)
-#define SH_I2C_ICSR_ADZ(1 << 0)
-
-#define IRQ_WAIT 1000
-
-static void sh_i2c_send_stop(struct sh_i2c *base)
-{
-   clrbits_8(>iccr2, SH_I2C_ICCR2_BBSY | SH_I2C_ICCR2_SCP);
-}
-
-static int check_icsr_bits(struct sh_i2c *base, u8 bits)
-{
-   int i;
-
-   for (i = 0; i < IRQ_WAIT; i++) {
-   if (bits & readb(>icsr))
-   return 0;
-   udelay(10);
-   }
-
-   return 1;
-}
-
-static int check_stop(struct sh_i2c *base)
-{
-   int ret = check_icsr_bits(base, SH_I2C_ICSR_STOP);
-   clrbits_8(>icsr, SH_I2C_ICSR_STOP);
-
-   return ret;
-}
-
-static int check_tend(struct sh_i2c *base, int stop)
-{
-   int ret = check_icsr_bits(base, SH_I2C_ICSR_TEND);
-
-   if (stop) {
-   clrbits_8(>icsr, SH_I2C_ICSR_STOP);
-   sh_i2c_send_stop(base);
-   }
-
-   clrbits_8(>icsr, SH_I2C_ICSR_TEND);
-   return ret;
-}
-
-static int check_tdre(struct sh_i2c *base)
-{
-   return check_icsr_bits(base, SH_I2C_ICSR_TDRE);
-}
-
-static int check_rdrf(struct sh_i2c *base)
-{
-   return check_icsr_bits(base, SH_I2C_ICSR_RDRF);
-}
-
-static int check_bbsy(struct sh_i2c *base)
-{
-   int i;
-
-   for (i = 0 ; i < IRQ_WAIT ; i++) {
-   if (!(SH_I2C_ICCR2_BBSY & readb(>iccr2)))
-   return 0;
-   udelay(10);
-   }
-   return 1;
-}
-
-static int check_ackbr(struct sh_i2c *base)
-{
-   int i;
-
-   for (i = 0 ; i < IRQ_WAIT ; i++) {
-   if (!(SH_I2C_ICIER_ACKBR & readb(>icier)))
-   return 0;
-   udelay(10);
-   }
-
-   return 1;
-}
-
-static void sh_i2c_reset(struct sh_i2c *base)
-{
-   setbits_8(>iccr2, SH_I2C_ICCR2_IICRST);
-
-   udelay(100);
-
-   

[U-Boot] [PATCH 2/3] i2c: Drop CONFIG_TSI108_I2C

[Tuomas Tynkkynen]

Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")

Signed-off-by: Tuomas Tynkkynen 
---
 doc/driver-model/i2c-howto.txt |   1 -
 drivers/i2c/Makefile   |   1 -
 drivers/i2c/tsi108_i2c.c   | 275 -
 include/tsi108.h   | 207 ---
 4 files changed, 484 deletions(-)
 delete mode 100644 drivers/i2c/tsi108_i2c.c
 delete mode 100644 include/tsi108.h

diff --git a/doc/driver-model/i2c-howto.txt b/doc/driver-model/i2c-howto.txt
index 605d3ef7ad..1b2c5312c4 100644
--- a/doc/driver-model/i2c-howto.txt
+++ b/doc/driver-model/i2c-howto.txt
@@ -16,7 +16,6 @@ ones remain:
sh_i2c
sh_sh7734_i2c
soft_i2c
-   tsi108_i2c
zynq_i2c
 
 The deadline for this work is the end of June 2017. If no one steps
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index e8bb6327fb..795dd33c64 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
 obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
 
 obj-$(CONFIG_I2C_MV) += mv_i2c.o
-obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
 obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
 obj-$(CONFIG_SYS_I2C) += i2c_core.o
 obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
diff --git a/drivers/i2c/tsi108_i2c.c b/drivers/i2c/tsi108_i2c.c
deleted file mode 100644
index 208c0900ef..00
--- a/drivers/i2c/tsi108_i2c.c
+++ /dev/null
@@ -1,275 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2004 Tundra Semiconductor Corp.
- * Author: Alex Bounine
- *
- * NOTE: This driver should be converted to driver model before June 2017.
- * Please see doc/driver-model/i2c-howto.txt for instructions.
- */
-
-#include 
-#include 
-
-#include 
-
-#if defined(CONFIG_CMD_I2C)
-
-#define I2C_DELAY  10
-#undef  DEBUG_I2C
-
-#ifdef DEBUG_I2C
-#define DPRINT(x) printf (x)
-#else
-#define DPRINT(x)
-#endif
-
-/* All functions assume that Tsi108 I2C block is the only master on the bus */
-/* I2C read helper function */
-
-void i2c_init(int speed, int slaveaddr)
-{
-   /*
-* The TSI108 has a fixed I2C clock rate and doesn't support slave
-* operation.  This function only exists as a stub to fit into the
-* U-Boot I2C API.
-*/
-}
-
-static int i2c_read_byte (
-   uint i2c_chan,  /* I2C channel number: 0 - main, 1 - SDC SPD */
-   uchar chip_addr,/* I2C device address on the bus */
-   uint byte_addr, /* Byte address within I2C device */
-   uchar * buffer  /* pointer to data buffer */
-   )
-{
-   u32 temp;
-   u32 to_count = I2C_DELAY;
-   u32 op_status = TSI108_I2C_TIMEOUT_ERR;
-   u32 chan_offset = TSI108_I2C_OFFSET;
-
-   DPRINT (("I2C read_byte() %d 0x%02x 0x%02x\n",
-   i2c_chan, chip_addr, byte_addr));
-
-   if (0 != i2c_chan)
-   chan_offset = TSI108_I2C_SDRAM_OFFSET;
-
-   /* Check if I2C operation is in progress */
-   temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + I2C_CNTRL2);
-
-   if (0 == (temp & (I2C_CNTRL2_RD_STATUS | I2C_CNTRL2_WR_STATUS |
- I2C_CNTRL2_START))) {
-   /* Set device address and operation (read = 0) */
-   temp = (byte_addr << 16) | ((chip_addr & 0x07) << 8) |
-   ((chip_addr >> 3) & 0x0F);
-   *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + 
I2C_CNTRL1) =
-   temp;
-
-   /* Issue the read command
-* (at this moment all other parameters are 0
-* (size = 1 byte, lane = 0)
-*/
-
-   *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + chan_offset + 
I2C_CNTRL2) =
-   (I2C_CNTRL2_START);
-
-   /* Wait until operation completed */
-   do {
-   /* Read I2C operation status */
-   temp = *(u32 *) (CONFIG_SYS_TSI108_CSR_BASE + 
chan_offset + I2C_CNTRL2);
-
-   if (0 == (temp & (I2C_CNTRL2_RD_STATUS | 
I2C_CNTRL2_START))) {
-   if (0 == (temp &
-(I2C_CNTRL2_I2C_CFGERR |
- I2C_CNTRL2_I2C_TO_ERR))
-   ) {
-   op_status = TSI108_I2C_SUCCESS;
-
-   temp = *(u32 *) 
(CONFIG_SYS_TSI108_CSR_BASE +
-chan_offset +
-I2C_RD_DATA);
-
-   *buffer = (u8) (temp & 0xFF);
-   } else {
-   /* report HW error */
-   op_status = TSI108_I2C_IF_ERROR;
-
-   

Re: [U-Boot] [PATCH] fs: ext4: fix crash on ext4ls

[Tom Rini]

On Wed, May 09, 2018 at 12:57:35PM +0300, Eugen Hristev wrote:
> Found a crash while issuing ext4ls with a non-existent directory.
> Crash test:
> 
> => ext4ls mmc 0 1
> ** Can not find directory. **
> data abort
> pc : [<3fd7c2ec>]  lr : [<3fd93ed8>]
> reloc pc : [<26f142ec>]lr : [<26f2bed8>]
> sp : 3f963338  ip : 3fdc3dc4 fp : 3fd6b370
> r10: 0004  r9 : 3f967ec0 r8 : 3f96db68
> r7 : 3fdc99b4  r6 :  r5 : 3f96dc88  r4 : 3fdcbc8c
> r3 : fffa  r2 :  r1 : 3f96e0bc  r0 : 0002
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> Tested on SAMA5D2_Xplained board (sama5d2_xplained_mmc_defconfig)
> 
> Looks like crash is introduced by commit:
> "fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
> 
> Issue is that dirnode is not initialized, and then freed if the call
> to ext4_ls fails. ext4_ls will not change the value of dirnode in this case
> thus we have a crash with data abort.
> 
> I added initialization and a check for dirname being NULL.
> 
> Fixes: "fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
> Cc: Stefan Brüns 
> Cc: Tom Rini 
> Signed-off-by: Eugen Hristev 
> ---
> Hello,
> 
> Regarding this fix, I am not sure if we actually need to free the node, but
> according to commit "fa9ca8a" , it was added to fix Coverity case.
> So, I decided to keep the free call under if statement if variable is NULL.
> If a different fix is required, please advise and I can change and resend.
> 
> Thanks !
> 
>  fs/ext4/ext4fs.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
> index 4b36a3e..2a28031 100644
> --- a/fs/ext4/ext4fs.c
> +++ b/fs/ext4/ext4fs.c
> @@ -164,7 +164,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
>  
>  int ext4fs_ls(const char *dirname)
>  {
> - struct ext2fs_node *dirnode;
> + struct ext2fs_node *dirnode = NULL;
>   int status;
>  
>   if (dirname == NULL)
> @@ -174,7 +174,8 @@ int ext4fs_ls(const char *dirname)
> FILETYPE_DIRECTORY);
>   if (status != 1) {
>   printf("** Can not find directory. **\n");
> - ext4fs_free_node(dirnode, _root->diropen);
> + if (dirnode)
> + ext4fs_free_node(dirnode, _root->diropen);
>   return 1;
>   }

This looks good.  Can you please do a v2 that also updates
test/fs/fs-test.sh to have a test for this case?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver

[Jagan Teki]

On Wed, May 9, 2018 at 5:22 PM, Siva Durga Prasad Paladugu
 wrote:
> Hi,
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: Wednesday, May 09, 2018 4:47 PM
>> To: Siva Durga Prasad Paladugu 
>> Cc: Jagan Teki ; U-Boot-Denx > b...@lists.denx.de>; michal.si...@xilinx.com
>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> ZynqMP qspi driver
>>
>> On Wed, May 9, 2018 at 4:44 PM, Siva Durga Prasad Paladugu
>>  wrote:
>> > Hi Jagan,
>> >
>> >> -Original Message-
>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> Sent: Wednesday, May 09, 2018 4:18 PM
>> >> To: Siva Durga Prasad Paladugu 
>> >> Cc: Jagan Teki ; U-Boot-Denx > >> b...@lists.denx.de>; michal.si...@xilinx.com
>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>> >> for ZynqMP qspi driver
>> >>
>> >> On Wed, May 9, 2018 at 4:08 PM, Jagan Teki
>> 
>> >> wrote:
>> >> > On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
>> >> >  wrote:
>> >> >> Hi Jagan,
>> >> >>
>> >> >>> -Original Message-
>> >> >>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> >>> Sent: Wednesday, May 09, 2018 1:22 PM
>> >> >>> To: Siva Durga Prasad Paladugu 
>> >> >>> Cc: Jagan Teki ; U-Boot-Denx > >> >>> b...@lists.denx.de>; michal.si...@xilinx.com
>> >> >>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
>> >> >>> support for ZynqMP qspi driver
>> >> >>>
>> >> >>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
>> >> >>>  wrote:
>> >> >>> >
>> >> >>> > Hi,
>> >> >>> >
>> >> >>> >> -Original Message-
>> >> >>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> >>> >> Sent: Wednesday, May 09, 2018 1:12 PM
>> >> >>> >> To: Siva Durga Prasad Paladugu 
>> >> >>> >> Cc: Jagan Teki ; U-Boot-Denx > >> >>> >> b...@lists.denx.de>; michal.si...@xilinx.com
>> >> >>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
>> >> >>> >> support for ZynqMP qspi driver
>> >> >>> >>
>> >> >>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>> >> >>> >>  wrote:
>> >> >>> >> > Hi Jagan,
>> >> >>> >> >
>> >> >>> >> >> -Original Message-
>> >> >>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> >> >>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
>> >> >>> >> >> To: Siva Durga Prasad Paladugu 
>> >> >>> >> >> Cc: U-Boot-Denx ;
>> >> >>> >> >> michal.si...@xilinx.com
>> >> >>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>> >> >>> >> >> for
>> >> >>> >> ZynqMP
>> >> >>> >> >> qspi driver
>> >> >>> >> >>
>> >> >>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>> >> >>> >> >>  wrote:
>> >> >>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This
>> >> >>> >> >> > driver is responsible for communicating with qspi flash
>> devices.
>> >> >>> >> >> >
>> >> >>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
>> >> >>> >> >> > 
>> >> >>> >> >> > ---
>> >> >>> >> >> > Changes for v3:
>> >> >>> >> >> > - Renamed all macros, functions, files and configs as per
>> >> >>> >> >> > comment
>> >> >>> >> >> > - Used wait_for_bit wherever required
>> >> >>> >> >> > - Removed unnecessary header inclusion
>> >> >>> >> >> >
>> >> >>> >> >> > Changes for v2:
>> >> >>> >> >> > - Rebased on top of latest master
>> >> >>> >> >> > - Moved macro definitions to .h file as per comment
>> >> >>> >> >> > - Fixed magic values with macros as per comment
>> >> >>> >> >> > ---
>> >> >>> >> >> >  arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h |
>> 154
>> >> >>> ++
>> >> >>> >> >> >  drivers/spi/Kconfig |   7 +
>> >> >>> >> >> >  drivers/spi/Makefile|   1 +
>> >> >>> >> >> >  drivers/spi/zynqmp_gqspi.c  | 670
>> >> >>> >> >> 
>> >> >>> >> >> >  4 files changed, 832 insertions(+)  create mode 100644
>> >> >>> >> >> > arch/arm/include/asm/arch-
>> >> >>> >> >> zynqmp/zynqmp_gqspi.h
>> >> >>> >> >> >  create mode 100644 drivers/spi/zynqmp_gqspi.c
>> >> >>> >> >> >
>> >> >>> >> >> > diff --git a/arch/arm/include/asm/arch-
>> >> zynqmp/zynqmp_gqspi.h
>> >> >>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >> >>> >> >>
>> >> >>> >> >> already asked you to move this header code in driver .c
>> >> >>> >> >> file
>> >> >>> >> >
>> >> >>> >> > You might have missed my reply to your earlier comment on
>> this.
>> >> >>> >> > These were moved to .h based on comment from Lukasz in v1.
>> >> >>> >> > I don’t have any issue in having them anywhere. 

Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver

[Siva Durga Prasad Paladugu]

Hi,

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, May 09, 2018 4:47 PM
> To: Siva Durga Prasad Paladugu 
> Cc: Jagan Teki ; U-Boot-Denx  b...@lists.denx.de>; michal.si...@xilinx.com
> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> ZynqMP qspi driver
> 
> On Wed, May 9, 2018 at 4:44 PM, Siva Durga Prasad Paladugu
>  wrote:
> > Hi Jagan,
> >
> >> -Original Message-
> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> Sent: Wednesday, May 09, 2018 4:18 PM
> >> To: Siva Durga Prasad Paladugu 
> >> Cc: Jagan Teki ; U-Boot-Denx  >> b...@lists.denx.de>; michal.si...@xilinx.com
> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
> >> for ZynqMP qspi driver
> >>
> >> On Wed, May 9, 2018 at 4:08 PM, Jagan Teki
> 
> >> wrote:
> >> > On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
> >> >  wrote:
> >> >> Hi Jagan,
> >> >>
> >> >>> -Original Message-
> >> >>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >>> Sent: Wednesday, May 09, 2018 1:22 PM
> >> >>> To: Siva Durga Prasad Paladugu 
> >> >>> Cc: Jagan Teki ; U-Boot-Denx  >> >>> b...@lists.denx.de>; michal.si...@xilinx.com
> >> >>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
> >> >>> support for ZynqMP qspi driver
> >> >>>
> >> >>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
> >> >>>  wrote:
> >> >>> >
> >> >>> > Hi,
> >> >>> >
> >> >>> >> -Original Message-
> >> >>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >> >>> >> Sent: Wednesday, May 09, 2018 1:12 PM
> >> >>> >> To: Siva Durga Prasad Paladugu 
> >> >>> >> Cc: Jagan Teki ; U-Boot-Denx  >> >>> >> b...@lists.denx.de>; michal.si...@xilinx.com
> >> >>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
> >> >>> >> support for ZynqMP qspi driver
> >> >>> >>
> >> >>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
> >> >>> >>  wrote:
> >> >>> >> > Hi Jagan,
> >> >>> >> >
> >> >>> >> >> -Original Message-
> >> >>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> >> >>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
> >> >>> >> >> To: Siva Durga Prasad Paladugu 
> >> >>> >> >> Cc: U-Boot-Denx ;
> >> >>> >> >> michal.si...@xilinx.com
> >> >>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
> >> >>> >> >> for
> >> >>> >> ZynqMP
> >> >>> >> >> qspi driver
> >> >>> >> >>
> >> >>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
> >> >>> >> >>  wrote:
> >> >>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This
> >> >>> >> >> > driver is responsible for communicating with qspi flash
> devices.
> >> >>> >> >> >
> >> >>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
> >> >>> >> >> > 
> >> >>> >> >> > ---
> >> >>> >> >> > Changes for v3:
> >> >>> >> >> > - Renamed all macros, functions, files and configs as per
> >> >>> >> >> > comment
> >> >>> >> >> > - Used wait_for_bit wherever required
> >> >>> >> >> > - Removed unnecessary header inclusion
> >> >>> >> >> >
> >> >>> >> >> > Changes for v2:
> >> >>> >> >> > - Rebased on top of latest master
> >> >>> >> >> > - Moved macro definitions to .h file as per comment
> >> >>> >> >> > - Fixed magic values with macros as per comment
> >> >>> >> >> > ---
> >> >>> >> >> >  arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h |
> 154
> >> >>> ++
> >> >>> >> >> >  drivers/spi/Kconfig |   7 +
> >> >>> >> >> >  drivers/spi/Makefile|   1 +
> >> >>> >> >> >  drivers/spi/zynqmp_gqspi.c  | 670
> >> >>> >> >> 
> >> >>> >> >> >  4 files changed, 832 insertions(+)  create mode 100644
> >> >>> >> >> > arch/arm/include/asm/arch-
> >> >>> >> >> zynqmp/zynqmp_gqspi.h
> >> >>> >> >> >  create mode 100644 drivers/spi/zynqmp_gqspi.c
> >> >>> >> >> >
> >> >>> >> >> > diff --git a/arch/arm/include/asm/arch-
> >> zynqmp/zynqmp_gqspi.h
> >> >>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> >> >>> >> >>
> >> >>> >> >> already asked you to move this header code in driver .c
> >> >>> >> >> file
> >> >>> >> >
> >> >>> >> > You might have missed my reply to your earlier comment on
> this.
> >> >>> >> > These were moved to .h based on comment from Lukasz in v1.
> >> >>> >> > I don’t have any issue in having them anywhere. Let me know
> >> >>> >> > your
> >> >>> choice.
> >> >>> >>
> >> >>> >> I'm trying to align Linux code, better to move like that and
> >> >>> >> make sure to use similar macros.
> >> >>> >>
> >> >>> 

Re: [U-Boot] GCC 7.x vs. C++ comments

[Tom Rini]

On Wed, May 09, 2018 at 01:38:37PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180509111627.gd12...@bill-the-cat.ec.rr.com> you wrote:
> > 
> > > What’s your preferred solution:
> > >   (a) change these comments
> > >   (b) change our Makefiles to let GCC know that we are compiling 
> > > gnu99/C99?
> > > 
> > > Neither solution is too appealing to me, so I am asking...
> >
> > Lets go with (b) which I guess what a more modern toolchain defaults to
> > anyhow.  Thanks!
> 
> I disagree.  UI-Boot always discouraged the use of C++ comments, see
> for example bullet # 5 at [1]. We should clearly fix the comments,
> please.
> 
> [1] http://www.denx.de/wiki/U-Boot/Coding

We should go and update [1] to note some special exemptions to the rule.
I see you missed out on the SPDX thread over here:
https://lists.denx.de/pipermail/u-boot/2018-May/327544.html and repeat
myself, I see it as more worthwhile to (a) follow the kernel in this
area (for both tooling and consistency and ease of development for our
overlapping community) (b) save space (in just about every conversion we
went from 2 lines to 1 line).  Thanks!

-- 
Tom


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

Re: [U-Boot] GCC 7.x vs. C++ comments

[Wolfgang Denk]

Dear Tom,

In message <20180509111627.gd12...@bill-the-cat.ec.rr.com> you wrote:
> 
> > What’s your preferred solution:
> > (a) change these comments
> > (b) change our Makefiles to let GCC know that we are compiling 
> > gnu99/C99?
> > 
> > Neither solution is too appealing to me, so I am asking...
>
> Lets go with (b) which I guess what a more modern toolchain defaults to
> anyhow.  Thanks!

I disagree.  UI-Boot always discouraged the use of C++ comments, see
for example bullet # 5 at [1]. We should clearly fix the comments,
please.

[1] http://www.denx.de/wiki/U-Boot/Coding

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
"It takes all sorts of in & out-door schooling to get adapted  to  my
kind of fooling"   - R. Frost
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] arm: ls1021aqds: config: enable CONFIG_ID_EEPROM for mac command

[Jagdish Gediya]

Signed-off-by: Jagdish Gediya 
---
 include/configs/ls1021aqds.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 0b4a6a4..79a84c4 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -351,6 +351,15 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_I2C_MXC_I2C2/* enable I2C bus 2 */
 #define CONFIG_SYS_I2C_MXC_I2C3/* enable I2C bus 3 */
 
+/* EEPROM */
+#define CONFIG_ID_EEPROM
+#define CONFIG_SYS_I2C_EEPROM_NXID
+#define CONFIG_SYS_EEPROM_BUS_NUM  0
+#define CONFIG_SYS_I2C_EEPROM_ADDR 0x57
+#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS  3
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  5
+
 /*
  * I2C bus multiplexer
  */
-- 
2.7.4

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

Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups

[Tom Rini]

On Wed, May 09, 2018 at 08:32:56AM +, yamada.masah...@socionext.com wrote:
> Hi Engeniu,
> 
> > -Original Message-
> > From: Eugeniu Rosca [mailto:ero...@de.adit-jv.com]
> > Sent: Wednesday, May 09, 2018 5:04 PM
> > To: Tom Rini ; Yamada, Masahiro/山田 真弘
> > ; Petr Vorel 
> > Cc: Ulf Magnusson ; Simon Glass ;
> > U-Boot Mailing List ; Eugeniu Rosca
> > ; Eugeniu Rosca 
> > Subject: Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups
> > 
> > Masahiro, Tom, Petr,
> > 
> > Thanks for your prompt feedback.
> > 
> > > On Wed, May 09, 2018 at 10:27:00AM +0900, Masahiro Yamada wrote:
> > > > I prefer syncing to check-picking.
> > > > [...]
> > > > Would you do that please?
> > > > Or, do you want me to do it?
> > 
> > I would happily attempt that. However, see my below question.
> > 
> > On Tue, May 08, 2018 at 09:31:42PM -0400, Tom Rini wrote:
> > > I'd greatly appreciate it if you can do a sync up to v4.17-rc4 or so.
> > 
> > Just to avoid any miscommunication, is my understanding correct that
> > this is an explicit request for Masahiro to take care of the update? I
> > would totally understand this.
> > 
> > FWIW, here is some statistics of the kernel kconfig development in the
> > v4.10..v4.17-rc4 commit range:
> > 
> > - 86 non-merge change-sets:
> > git rev-list --no-merges --count v4.10..v4.17-rc4 -- scripts/kconfig/
> > 86
> > 
> > - 8 Kconfig commits which touch non-Kconfig files too (ignoring
> >   Documentation) and hence might require more delicate conflict
> >   resolution:
> > 
> > for c in $(git rev-list --reverse --no-merges v4.10..v4.17-rc4 --
> > scripts/kconfig/); do
> >   if (git log --full-diff --format="" --name-only -1 $c -- scripts/kconfig
> > |
> > egrep -v "scripts/kconfig|Documentation" > /dev/null); then
> >   git --no-pager log --oneline $c -1;
> >   fi;
> > done
> > 
> > cb77f0d623ff scripts: Switch to more portable Perl shebang
> > bb3290d91695 Remove gperf usage from toolchain
> > b24413180f56 License cleanup: add SPDX GPL-2.0 license identifier to files
> > with no license
> > 07a422bb213a kbuild: restore autoksyms.h touch to the top Makefile
> > 911a91c39cab kconfig: rename silentoldconfig to syncconfig
> > 598893002745 .gitignore: move *.lex.c *.tab.[ch] patterns to the
> > top-level .gitignore
> > 9a8dfb394c04 kbuild: clean up *.lex.c and *.tab.[ch] patterns from
> > top-level Makefile
> > b23d1a241f4e kbuild: add %.lex.c and %.tab.[ch] to 'targets' automatically
> > 
> > I also think that the most sensitive part of this update is related to:
> > - changed tooling requirements for hosts, e.g. flex and bison seem to
> >   be required starting with commit 29c833061c1d ("kconfig: generate
> >   lexer and parser during build instead of shipping").
> > - dropped silentoldconfig support, starting with commit cedd55d49dee
> >   ("kconfig: Remove silentoldconfig from help and docs; fix
> >   kconfig/conf's help").
> > 
> > There might be questions from users experiencing build errors/warnings
> > after the update, same as we've seen in [1].
> > 
> > [1] https://patchwork.kernel.org/patch/10318503/
> > 
> > I would appreciate if Tom answers the question raised in the beginning
> > of my post.
> 
> 
> Tom will make a decision.
> 
> Just my thought.
> 
> 
> U-Boot is basically a mirror of Linux.
> 
> Syncing Kconfig will add new tool requirement, flex & bison, for building 
> U-Boot,
> but this is OK because Linux does it.
> 
> U-Boot follows Linux, for example, recently U-Boot adopted Linux-like SPDX 
> license tag style.
> 
> 
> And, you understand well the points for resyncing.
> Yes, other parts must be adjusted.
> 
> So, I am happy if you contribute to this work.

Yes, I'm fine adding flex/bison as build requirements.  And I'm also
fine with anyone that feels they can handle doing the re-sync doing the
re-sync, thanks folks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/3] spi: sh_qspi: full DM conversion

[Jagan Teki]

What I understand from this is you made changes on top of your
previous patch which is wrong. Since the first patch is not accepted
and request for changes you need to make changes on top. Since this is
v2 you mentioned 'changes for v2' what is been fixed/updated with this
version.

On Wed, May 9, 2018 at 12:06 PM, Akash Gajjar  wrote:
> v1->v2
> New in v2
> update Kconfig
> replace __sh_qspi_setup to sh_qspi_setup
> add missing memeber of platform data
>
> Signed-off-by: Akash Gajjar 
> ---

Changes you need to write it here?

>  drivers/spi/Kconfig| 12 +-
>  drivers/spi/sh_qspi.c  | 49 
> +++---
>  include/dm/platform_data/qspi_sh.h |  4 
>  3 files changed, 31 insertions(+), 34 deletions(-)
>

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

Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver

[Jagan Teki]

On Wed, May 9, 2018 at 4:44 PM, Siva Durga Prasad Paladugu
 wrote:
> Hi Jagan,
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: Wednesday, May 09, 2018 4:18 PM
>> To: Siva Durga Prasad Paladugu 
>> Cc: Jagan Teki ; U-Boot-Denx > b...@lists.denx.de>; michal.si...@xilinx.com
>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> ZynqMP qspi driver
>>
>> On Wed, May 9, 2018 at 4:08 PM, Jagan Teki 
>> wrote:
>> > On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
>> >  wrote:
>> >> Hi Jagan,
>> >>
>> >>> -Original Message-
>> >>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >>> Sent: Wednesday, May 09, 2018 1:22 PM
>> >>> To: Siva Durga Prasad Paladugu 
>> >>> Cc: Jagan Teki ; U-Boot-Denx > >>> b...@lists.denx.de>; michal.si...@xilinx.com
>> >>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>> >>> for ZynqMP qspi driver
>> >>>
>> >>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
>> >>>  wrote:
>> >>> >
>> >>> > Hi,
>> >>> >
>> >>> >> -Original Message-
>> >>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >>> >> Sent: Wednesday, May 09, 2018 1:12 PM
>> >>> >> To: Siva Durga Prasad Paladugu 
>> >>> >> Cc: Jagan Teki ; U-Boot-Denx > >>> >> b...@lists.denx.de>; michal.si...@xilinx.com
>> >>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
>> >>> >> support for ZynqMP qspi driver
>> >>> >>
>> >>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>> >>> >>  wrote:
>> >>> >> > Hi Jagan,
>> >>> >> >
>> >>> >> >> -Original Message-
>> >>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> >>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
>> >>> >> >> To: Siva Durga Prasad Paladugu 
>> >>> >> >> Cc: U-Boot-Denx ;
>> >>> >> >> michal.si...@xilinx.com
>> >>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> >>> >> ZynqMP
>> >>> >> >> qspi driver
>> >>> >> >>
>> >>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>> >>> >> >>  wrote:
>> >>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This
>> >>> >> >> > driver is responsible for communicating with qspi flash devices.
>> >>> >> >> >
>> >>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
>> >>> >> >> > 
>> >>> >> >> > ---
>> >>> >> >> > Changes for v3:
>> >>> >> >> > - Renamed all macros, functions, files and configs as per
>> >>> >> >> > comment
>> >>> >> >> > - Used wait_for_bit wherever required
>> >>> >> >> > - Removed unnecessary header inclusion
>> >>> >> >> >
>> >>> >> >> > Changes for v2:
>> >>> >> >> > - Rebased on top of latest master
>> >>> >> >> > - Moved macro definitions to .h file as per comment
>> >>> >> >> > - Fixed magic values with macros as per comment
>> >>> >> >> > ---
>> >>> >> >> >  arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
>> >>> ++
>> >>> >> >> >  drivers/spi/Kconfig |   7 +
>> >>> >> >> >  drivers/spi/Makefile|   1 +
>> >>> >> >> >  drivers/spi/zynqmp_gqspi.c  | 670
>> >>> >> >> 
>> >>> >> >> >  4 files changed, 832 insertions(+)  create mode 100644
>> >>> >> >> > arch/arm/include/asm/arch-
>> >>> >> >> zynqmp/zynqmp_gqspi.h
>> >>> >> >> >  create mode 100644 drivers/spi/zynqmp_gqspi.c
>> >>> >> >> >
>> >>> >> >> > diff --git a/arch/arm/include/asm/arch-
>> zynqmp/zynqmp_gqspi.h
>> >>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >>> >> >>
>> >>> >> >> already asked you to move this header code in driver .c file
>> >>> >> >
>> >>> >> > You might have missed my reply to your earlier comment on this.
>> >>> >> > These were moved to .h based on comment from Lukasz in v1.
>> >>> >> > I don’t have any issue in having them anywhere. Let me know
>> >>> >> > your
>> >>> choice.
>> >>> >>
>> >>> >> I'm trying to align Linux code, better to move like that and make
>> >>> >> sure to use similar macros.
>> >>> >>
>> >>> >> >
>> >>> >
>> >>> > [snip]
>> >>> >
>> >>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct
>> zynqmp_qspi_priv
>> >>> >> *priv) {
>> >>> >> >> > +   u8 command = 1;
>> >>> >> >> > +   u32 gen_fifo_cmd;
>> >>> >> >> > +   u32 bytecount = 0;
>> >>> >> >> > +
>> >>> >> >> > +   while (priv->len) {
>> >>> >> >> > +   gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
>> >>> >> >> > +   gen_fifo_cmd |= GQSPI_GFIFO_TX;
>> >>> >> >> > +
>> >>> >> >> > +   if (command) {
>> >>> >> >> > +   command = 0;
>> >>> >> >> > +   last_cmd = 

Re: [U-Boot] [PATCHv2 2/3] buildman: support newer gcc versions from kernel.org

[Tom Rini]

On Wed, May 09, 2018 at 12:27:38PM +0200, Daniel Schwierzeck wrote:
> 
> 
> On 08.05.2018 02:50, Tom Rini wrote:
> > From: Daniel Schwierzeck 
> > 
> > Add support for gcc versions 7.3.0, 6.4.0 and 4.9.4.
> > 
> > Also use a regex for matching the tarball names. Some gcc versions
> > use '-ARCH-' instead of '_ARCH-'.
> > 
> > As part of this, we switch TravisCI to also using these toolchains for
> > all platforms.
> > 
> > Signed-off-by: Daniel Schwierzeck 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - Change to only 7.3.0 / 6.4.0 / 4.9.4 for gcc versions.  Update
> >   .travis.yml for x86_64 toolchain and fetch all toolchains.
> > - Fold in the old patch I had to expand and update SH builds as we
> >   cannot build without those changes.
> > ---
> >  .travis.yml | 38 ++
> >  tools/buildman/toolchain.py |  6 +++---
> >  2 files changed, 29 insertions(+), 15 deletions(-)
> > 
> > diff --git a/.travis.yml b/.travis.yml
> > index 57f38e11698b..b07ce9b8ceb4 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -21,7 +21,6 @@ addons:
> >  - python-virtualenv
> >  - swig
> >  - libpython-dev
> > -- gcc-powerpc-linux-gnu
> >  - iasl
> >  - grub-efi-ia32-bin
> >  - rpm2cpio
> > @@ -29,6 +28,11 @@ addons:
> >  - device-tree-compiler
> >  - lzop
> >  
> > +before_install:
> > + - sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
> > + - sudo apt-get update -q
> > + - sudo apt-get install libisl15 -y
> > +
> >  install:
> >   # Clone uboot-test-hooks
> >   - git clone --depth=1 git://github.com/swarren/uboot-test-hooks.git 
> > /tmp/uboot-test-hooks
> > @@ -36,10 +40,8 @@ install:
> >   - ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname`
> >   # prepare buildman environment
> >   - echo -e "[toolchain]\nroot = /usr" > ~/.buildman
> > - - echo -e "aarch64 = 
> > /tmp/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu" >> ~/.buildman
> > - - echo -e "arm = 
> > /tmp/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf" >> ~/.buildman
> >   - echo -e "arc = 
> > /tmp/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install" >> ~/.buildman
> > - - echo -e "\n[toolchain-alias]\nsh = sh4\nopenrisc = or32" >> ~/.buildman
> > + - echo -e "\n[toolchain-alias]\nsh = sh2" >> ~/.buildman
> >   - cat ~/.buildman
> >   - virtualenv /tmp/venv
> >   - . /tmp/venv/bin/activate
> > @@ -64,10 +66,10 @@ before_script:
> >- if [[ "${TOOLCHAIN}" == *microblaze* ]]; then 
> > ./tools/buildman/buildman --fetch-arch microblaze ; fi
> >- if [[ "${TOOLCHAIN}" == *mips* ]]; then ./tools/buildman/buildman 
> > --fetch-arch mips ; fi
> >- if [[ "${TOOLCHAIN}" == *or32* ]]; then ./tools/buildman/buildman 
> > --fetch-arch or32 ; fi
> > -  - if [[ "${TOOLCHAIN}" == *sh4* ]]; then ./tools/buildman/buildman 
> > --fetch-arch sh4 ; fi
> > +  - if [[ "${TOOLCHAIN}" == *sh* ]]; then ./tools/buildman/buildman 
> > --fetch-arch sh2 ; fi
> >- if [[ "${TOOLCHAIN}" == *x86_64* ]]; then
> >./tools/buildman/buildman --fetch-arch x86_64;
> > -  echo -e "\n[toolchain-prefix]\nx86 = 
> > ${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-"
> >  >> ~/.buildman;
> > +  echo -e "\n[toolchain-prefix]\nx86 = 
> > ${HOME}/.buildman-toolchains/gcc-7.3.0-nolibc/x86_64-linux/bin/x86_64-linux-"
> >  >> ~/.buildman;
> 
> you could add "x86 = x86_64" to section [toolchain-alias] to avoid
> hard-coding this

There's some amount of "fun" going on in order to build all of
arch/{sandbox,x86} with the same toolchain.  I'll double check what we
can get away with in terms of toolchain-prefix vs toolchain-alias.
Thanks!

-- 
Tom


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

Re: [U-Boot] GCC 7.x vs. C++ comments

[Tom Rini]

On Wed, May 09, 2018 at 10:46:10AM +0200, Dr. Philipp Tomsich wrote:
> Tom,
> 
> I recently ran a local buildman with a came across these:
> >   cc -Wp,-MD,tools/.gen_eth_addr.d -Wall -Wstrict-prototypes -O2 
> > -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude 
> > -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC 
> > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -o tools/gen_eth_addr 
> > tools/gen_eth_addr.c  
> > tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in 
> > ISO C90
> >  // SPDX-License-Identifier: GPL-2.0+
> >  ^
> > tools/gen_eth_addr.c:1:1: warning: (this will be reported only once per 
> > input file)
> >   cc -Wp,-MD,tools/.gen_ethaddr_crc.o.d -Wall -Wstrict-prototypes -O2 
> > -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude 
> > -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC 
> > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o 
> > tools/gen_ethaddr_crc.o tools/gen_ethaddr_crc.c
> > tools/gen_ethaddr_crc.c:1:1: warning: C++ style comments are not allowed in 
> > ISO C90
> >  // SPDX-License-Identifier: GPL-2.0+
> >  ^
> > tools/gen_ethaddr_crc.c:1:1: warning: (this will be reported only once per 
> > input file)
> >   echo "#include <../lib/crc8.c>" >tools/lib/crc8.c
> >   cc -Wp,-MD,tools/lib/.crc8.o.d -Wall -Wstrict-prototypes -O2 
> > -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude 
> > -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC 
> > -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o tools/lib/crc8.o 
> > tools/lib/crc8.c
> > In file included from tools/lib/crc8.c:1:0:
> > ./tools/../lib/crc8.c:1:1: warning: C++ style comments are not allowed in 
> > ISO C90
> >  // SPDX-License-Identifier: GPL-2.0+
> >  ^
> 
> The system compiler was a
> > Using built-in specs.
> > COLLECT_GCC=cc
> > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
> > Target: x86_64-linux-gnu
> > Configured with: ../src/configure -v --with-pkgversion='Debian 
> > 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
> > --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
> > --program-suffix=-4.9 --enable-shared --enable-linker-build-id 
> > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> > --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
> > --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
> > --enable-libstdcxx-time=yes --enable-gnu-unique-object 
> > --disable-vtable-verify --enable-plugin --with-system-zlib 
> > --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
> > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre 
> > --enable-java-home 
> > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
> > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
> > --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> > --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
> > --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
> > --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
> > --target=x86_64-linux-gnu
> > Thread model: posix
> > gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) 
> 
> 
> What’s your preferred solution:
>   (a) change these comments
>   (b) change our Makefiles to let GCC know that we are compiling 
> gnu99/C99?
> 
> Neither solution is too appealing to me, so I am asking...

Lets go with (b) which I guess what a more modern toolchain defaults to
anyhow.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver

[Siva Durga Prasad Paladugu]

Hi Jagan,

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Wednesday, May 09, 2018 4:18 PM
> To: Siva Durga Prasad Paladugu 
> Cc: Jagan Teki ; U-Boot-Denx  b...@lists.denx.de>; michal.si...@xilinx.com
> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> ZynqMP qspi driver
> 
> On Wed, May 9, 2018 at 4:08 PM, Jagan Teki 
> wrote:
> > On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
> >  wrote:
> >> Hi Jagan,
> >>
> >>> -Original Message-
> >>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >>> Sent: Wednesday, May 09, 2018 1:22 PM
> >>> To: Siva Durga Prasad Paladugu 
> >>> Cc: Jagan Teki ; U-Boot-Denx  >>> b...@lists.denx.de>; michal.si...@xilinx.com
> >>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
> >>> for ZynqMP qspi driver
> >>>
> >>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
> >>>  wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> >> -Original Message-
> >>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> >>> >> Sent: Wednesday, May 09, 2018 1:12 PM
> >>> >> To: Siva Durga Prasad Paladugu 
> >>> >> Cc: Jagan Teki ; U-Boot-Denx  >>> >> b...@lists.denx.de>; michal.si...@xilinx.com
> >>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add
> >>> >> support for ZynqMP qspi driver
> >>> >>
> >>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
> >>> >>  wrote:
> >>> >> > Hi Jagan,
> >>> >> >
> >>> >> >> -Original Message-
> >>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
> >>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
> >>> >> >> To: Siva Durga Prasad Paladugu 
> >>> >> >> Cc: U-Boot-Denx ;
> >>> >> >> michal.si...@xilinx.com
> >>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
> >>> >> ZynqMP
> >>> >> >> qspi driver
> >>> >> >>
> >>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
> >>> >> >>  wrote:
> >>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This
> >>> >> >> > driver is responsible for communicating with qspi flash devices.
> >>> >> >> >
> >>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
> >>> >> >> > 
> >>> >> >> > ---
> >>> >> >> > Changes for v3:
> >>> >> >> > - Renamed all macros, functions, files and configs as per
> >>> >> >> > comment
> >>> >> >> > - Used wait_for_bit wherever required
> >>> >> >> > - Removed unnecessary header inclusion
> >>> >> >> >
> >>> >> >> > Changes for v2:
> >>> >> >> > - Rebased on top of latest master
> >>> >> >> > - Moved macro definitions to .h file as per comment
> >>> >> >> > - Fixed magic values with macros as per comment
> >>> >> >> > ---
> >>> >> >> >  arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
> >>> ++
> >>> >> >> >  drivers/spi/Kconfig |   7 +
> >>> >> >> >  drivers/spi/Makefile|   1 +
> >>> >> >> >  drivers/spi/zynqmp_gqspi.c  | 670
> >>> >> >> 
> >>> >> >> >  4 files changed, 832 insertions(+)  create mode 100644
> >>> >> >> > arch/arm/include/asm/arch-
> >>> >> >> zynqmp/zynqmp_gqspi.h
> >>> >> >> >  create mode 100644 drivers/spi/zynqmp_gqspi.c
> >>> >> >> >
> >>> >> >> > diff --git a/arch/arm/include/asm/arch-
> zynqmp/zynqmp_gqspi.h
> >>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
> >>> >> >>
> >>> >> >> already asked you to move this header code in driver .c file
> >>> >> >
> >>> >> > You might have missed my reply to your earlier comment on this.
> >>> >> > These were moved to .h based on comment from Lukasz in v1.
> >>> >> > I don’t have any issue in having them anywhere. Let me know
> >>> >> > your
> >>> choice.
> >>> >>
> >>> >> I'm trying to align Linux code, better to move like that and make
> >>> >> sure to use similar macros.
> >>> >>
> >>> >> >
> >>> >
> >>> > [snip]
> >>> >
> >>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct
> zynqmp_qspi_priv
> >>> >> *priv) {
> >>> >> >> > +   u8 command = 1;
> >>> >> >> > +   u32 gen_fifo_cmd;
> >>> >> >> > +   u32 bytecount = 0;
> >>> >> >> > +
> >>> >> >> > +   while (priv->len) {
> >>> >> >> > +   gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
> >>> >> >> > +   gen_fifo_cmd |= GQSPI_GFIFO_TX;
> >>> >> >> > +
> >>> >> >> > +   if (command) {
> >>> >> >> > +   command = 0;
> >>> >> >> > +   last_cmd = *(u8 *)priv->tx_buf;
> >>> >> >> > +   }
> >>> >> >>
> >>> >> >> don't understand this code can you explain? command assigned
> 1
> >>> >> >> it will not updated anywhere?
> >>> >> >
> >>> >> > I 

Re: [U-Boot] [PATCH] driver/mtd/spi: Default page size Spansion flash "S25FS512S" is 256b

[Jagan Teki]

On Mon, May 7, 2018 at 4:01 PM, Ashish Kumar  wrote:
> Signed-off-by: Ashish Kumar 
> ---
>  drivers/mtd/spi/spi_flash.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 3d24a08..ce420cb 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -1046,14 +1046,15 @@ int spi_flash_scan(struct spi_flash *flash)
> flash->shift = (flash->dual_flash & SF_DUAL_PARALLEL_FLASH) ? 1 : 0;
> flash->page_size = info->page_size;
> /*
> -* The Spansion S25FL032P and S25FL064P have 256b pages, yet use the
> -* 0x4d00 Extended JEDEC code. The rest of the Spansion flashes with
> -* the 0x4d00 Extended JEDEC code have 512b pages. All of the others
> -* have 256b pages.
> +* The Spansion S25FS512S, S25FL032P and S25FL064P have 256b pages,
> +* yet use the 0x4d00 Extended JEDEC code. The rest of the Spansion
> +* flashes with the 0x4d00 Extended JEDEC code have 512b pages.
> +* All of the others have 256b pages.
>  */
> if (JEDEC_EXT(info) == 0x4d00) {
> if ((JEDEC_ID(info) != 0x0215) &&
> -   (JEDEC_ID(info) != 0x0216))
> +   (JEDEC_ID(info) != 0x0216) &&
> +   (JEDEC_ID(info) != 0x0220))

0220 is JEDEC ID for S25FS512S which is 512 is it? commit message says 256b?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Pull request: u-boot-sunxi/master

[Jagan Teki]

Hi Tom,

Please pull this PR.

thanks,
Jagan.

The following changes since commit b25f8e2112b1582ce6386e846800a31bab688e50:

  Merge git://git.denx.de/u-boot-imx (2018-04-30 07:14:05 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-sunxi.git master

for you to fetch changes up to f3df7758b5fb4e1f8eb8f2bbd9b9354054884502:

  board: sunxi: sun8i-v40: Add Bananapi M2 Berry support (2018-05-07 11:33:19 
+0530)


Chen-Yu Tsai (5):
  sunxi: Disable R_I2C for Libre Computer Board ALL-H3-CC H3 ver.
  sunxi: Split out common board design for ALL-H3-CC device tree
  sunxi: Add Libre Computer Board ALL-H3-CC H2+ ver.
  sunxi: Add Libre Computer Board ALL-H3-CC H5 ver.
  sunxi: Sort dts Makefile entries for H3

Jagan Teki (2):
  ARM: dts: sun8i: Sync r40 dtsi from Linux
  board: sunxi: sun8i-v40: Add Bananapi M2 Berry support

 arch/arm/dts/Makefile  |  15 +-
 arch/arm/dts/sun50i-h5-libretech-all-h3-cc.dts |  13 ++
 arch/arm/dts/sun8i-h2-plus-libretech-all-h3-cc.dts |  13 ++
 arch/arm/dts/sun8i-h3-libretech-all-h3-cc.dts  | 166 +-
 arch/arm/dts/sun8i-r40.dtsi|  43 +
 arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts   | 132 +++
 arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi| 168 ++
 board/sunxi/MAINTAINERS|   9 +-
 configs/bananapi_m2_berry_defconfig|  14 ++
 configs/libretech_all_h3_cc_h2_plus_defconfig  |  15 ++
 configs/libretech_all_h3_cc_h3_defconfig   |   2 -
 configs/libretech_all_h3_cc_h5_defconfig   |  15 ++
 include/dt-bindings/clock/sun8i-r40-ccu.h  | 187 +
 include/dt-bindings/reset/sun8i-r40-ccu.h  | 130 ++
 14 files changed, 749 insertions(+), 173 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h3-cc.dts
 create mode 100644 arch/arm/dts/sun8i-h2-plus-libretech-all-h3-cc.dts
 create mode 100644 arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts
 create mode 100644 arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi
 create mode 100644 configs/bananapi_m2_berry_defconfig
 create mode 100644 configs/libretech_all_h3_cc_h2_plus_defconfig
 create mode 100644 configs/libretech_all_h3_cc_h5_defconfig
 create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] ARM: dts: sun8i: Sync r40 dtsi from Linux

[Jagan Teki]

On Fri, Apr 27, 2018 at 5:33 PM, Jagan Teki  wrote:
> Sync sun8i-r40.dtsi changes from Linux with
>
> Merge: a406778618d0 088345fc3553
> Author: Stephen Rothwell 
> Date:   Tue Apr 24 14:15:02 2018 +1000
>
> Merge branch 'akpm/master'
>
> Signed-off-by: Jagan Teki 
> ---

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

Re: [U-Boot] [PATCH v2 2/2] board: sunxi: sun8i-v4: Add Bananapi M2 Berry support

[Jagan Teki]

On Wed, May 2, 2018 at 2:46 PM, Maxime Ripard  wrote:
> On Fri, Apr 27, 2018 at 05:33:42PM +0530, Jagan Teki wrote:
>> Banana Pi BPI-M2 Berry is a quad-core mini single board computer
>> built with Allwinner V40 SoC. It features
>> - Quad Core ARM Cortex A7 CPU V40
>> - 1GB of RAM .
>> - microSD/SATA port..
>> - onboard WiFi and BT
>> - 4 USB A 2.0 ports
>> - 1 USB OTG port
>> - 1 HDMI port
>> - 1 audio jack
>> - DC power port
>>
>> Signed-off-by: Jagan Teki 
>
> There's a typo in your commit title, it should be v40 and not
> v4. Otherwise it looks good,
> Acked-by: Maxime Ripard 

Fixed and Applied to u-boot-sunxi/master
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups

[Eugeniu Rosca]

Masahiro, Tom, Petr,

Thanks for your prompt feedback.

> On Wed, May 09, 2018 at 10:27:00AM +0900, Masahiro Yamada wrote:
> > I prefer syncing to check-picking.
> > [...]
> > Would you do that please?
> > Or, do you want me to do it?

I would happily attempt that. However, see my below question.

On Tue, May 08, 2018 at 09:31:42PM -0400, Tom Rini wrote:
> I'd greatly appreciate it if you can do a sync up to v4.17-rc4 or so.

Just to avoid any miscommunication, is my understanding correct that
this is an explicit request for Masahiro to take care of the update? I
would totally understand this.

FWIW, here is some statistics of the kernel kconfig development in the
v4.10..v4.17-rc4 commit range:

- 86 non-merge change-sets:
git rev-list --no-merges --count v4.10..v4.17-rc4 -- scripts/kconfig/
86

- 8 Kconfig commits which touch non-Kconfig files too (ignoring
  Documentation) and hence might require more delicate conflict
  resolution:

for c in $(git rev-list --reverse --no-merges v4.10..v4.17-rc4 -- 
scripts/kconfig/); do
  if (git log --full-diff --format="" --name-only -1 $c -- scripts/kconfig  |
egrep -v "scripts/kconfig|Documentation" > /dev/null); then
  git --no-pager log --oneline $c -1;
  fi;
done

cb77f0d623ff scripts: Switch to more portable Perl shebang
bb3290d91695 Remove gperf usage from toolchain
b24413180f56 License cleanup: add SPDX GPL-2.0 license identifier to files with 
no license
07a422bb213a kbuild: restore autoksyms.h touch to the top Makefile
911a91c39cab kconfig: rename silentoldconfig to syncconfig
598893002745 .gitignore: move *.lex.c *.tab.[ch] patterns to the top-level 
.gitignore
9a8dfb394c04 kbuild: clean up *.lex.c and *.tab.[ch] patterns from top-level 
Makefile
b23d1a241f4e kbuild: add %.lex.c and %.tab.[ch] to 'targets' automatically

I also think that the most sensitive part of this update is related to:
- changed tooling requirements for hosts, e.g. flex and bison seem to
  be required starting with commit 29c833061c1d ("kconfig: generate
  lexer and parser during build instead of shipping").
- dropped silentoldconfig support, starting with commit cedd55d49dee
  ("kconfig: Remove silentoldconfig from help and docs; fix
  kconfig/conf's help").

There might be questions from users experiencing build errors/warnings
after the update, same as we've seen in [1].

[1] https://patchwork.kernel.org/patch/10318503/

I would appreciate if Tom answers the question raised in the beginning
of my post.

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

Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Am 08.05.2018 um 22:54 schrieb Vagrant Cascadian:

On 2018-05-08, Vagrant Cascadian wrote:

On 2018-05-05, Tom Rini wrote:

On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:

Markus Krebs discovered that the sheevaplug target has again grown and
installation overlaps where the u-boot env is saved since u-boot
~2017.09. Running saveenv overwrites u-boot, and installing u-boot
overwrites any prior environment settings.

...

I've added the maintainer to the list as well.  I would suggest looking
for things to trim out, perhaps CMD_MEMTEST ?


Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
*lot* left to disable in the config, but that's a significant start...


And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
down to 432k! Thanks to beeble for the suggestion.

Anyone who has a sheevaplug can test that it actually boots with
CONFIG_SYS_THUMB_BUILD=y enabled?


I could test it, but I don't know the config-file where I can change 
those options (EFI_LOADER, CONFIG_SYS_THUMB_BUILD).

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

[U-Boot] [PATCH v2 3/3] spi: mxs_spi: full dm conversion

[Akash Gajjar]

v1->v2
register cs_info method
remove unused function __mxs_spi_setup
merged __spi_xfer function to spi_xfer
printf replaced by debug

Signed-off-by: Akash Gajjar 
---
 drivers/spi/mxs_spi.c | 169 --
 1 file changed, 81 insertions(+), 88 deletions(-)

diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index 0af2eee..3054438 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -82,7 +82,7 @@ static int mxs_spi_xfer_pio(struct mxs_spi_priv *priv,
 
if (mxs_wait_mask_set(_regs->hw_ssp_ctrl0_reg,
SSP_CTRL0_RUN, MXS_SPI_MAX_TIMEOUT)) {
-   printf("MXS SPI: Timeout waiting for start\n");
+   debug("MXS SPI: Timeout waiting for start\n");
return -ETIMEDOUT;
}
 
@@ -94,7 +94,7 @@ static int mxs_spi_xfer_pio(struct mxs_spi_priv *priv,
if (!write) {
if (mxs_wait_mask_clr(_regs->hw_ssp_status_reg,
SSP_STATUS_FIFO_EMPTY, MXS_SPI_MAX_TIMEOUT)) {
-   printf("MXS SPI: Timeout waiting for data\n");
+   debug("MXS SPI: Timeout waiting for data\n");
return -ETIMEDOUT;
}
 
@@ -104,7 +104,7 @@ static int mxs_spi_xfer_pio(struct mxs_spi_priv *priv,
 
if (mxs_wait_mask_clr(_regs->hw_ssp_ctrl0_reg,
SSP_CTRL0_RUN, MXS_SPI_MAX_TIMEOUT)) {
-   printf("MXS SPI: Timeout waiting for finish\n");
+   debug("MXS SPI: Timeout waiting for finish\n");
return -ETIMEDOUT;
}
}
@@ -233,78 +233,6 @@ static int mxs_spi_xfer_dma(struct mxs_spi_priv *priv,
return ret;
 }
 
-static int __spi_xfer(struct mxs_spi_priv *priv, unsigned int bitlen,
-   const void *dout, void *din, unsigned long flags)
-{
-   struct mxs_ssp_regs *ssp_regs = priv->regs;
-   int len = bitlen / 8;
-   char dummy;
-   int write = 0;
-   char *data = NULL;
-   int dma = 1;
-
-   if (bitlen == 0) {
-   if (flags & SPI_XFER_END) {
-   din = (void *)
-   len = 1;
-   } else
-   return 0;
-   }
-
-   /* Half-duplex only */
-   if (din && dout)
-   return -EINVAL;
-   /* No data */
-   if (!din && !dout)
-   return 0;
-
-   if (dout) {
-   data = (char *)dout;
-   write = 1;
-   } else if (din) {
-   data = (char *)din;
-   write = 0;
-   }
-
-   /*
-* Check for alignment, if the buffer is aligned, do DMA transfer,
-* PIO otherwise. This is a temporary workaround until proper bounce
-* buffer is in place.
-*/
-   if (dma) {
-   if (((uint32_t)data) & (ARCH_DMA_MINALIGN - 1))
-   dma = 0;
-   if (((uint32_t)len) & (ARCH_DMA_MINALIGN - 1))
-   dma = 0;
-   }
-
-   if (!dma || (len < MXSSSP_SMALL_TRANSFER)) {
-   writel(SSP_CTRL1_DMA_ENABLE, _regs->hw_ssp_ctrl1_clr);
-   return mxs_spi_xfer_pio(priv, data, len, write, flags);
-   } else {
-   writel(SSP_CTRL1_DMA_ENABLE, _regs->hw_ssp_ctrl1_set);
-   return mxs_spi_xfer_dma(priv, data, len, write, flags);
-   }
-}
-
-static int __mxs_spi_setup(struct mxs_spi_priv *mxs_spi, uint bus)
-{
-   struct mxs_spi_priv *priv = mxs_spi;
-   int err;
-
-   priv->max_khz = max_hz / 1000;
-   priv->mode = mode;
-   priv->regs = mxs_ssp_regs_by_bus(bus);
-   priv->bus = bus;
-
-   if (mxs_dma_init_channel(MXS_DMA_CHANNEL_AHB_APBH_SSP0 + priv->bus)) {
-   printf("%s: DMA init channel error %d\n", __func__, err);
-   return err;
-   }
-
-   return 0;
-}
-
 static int mxs_spi_claim_bus(struct udevice *dev)
 {
struct udevice *bus = dev_get_parent(dev);
@@ -321,8 +249,6 @@ static int mxs_spi_claim_bus(struct udevice *dev)
 
 static int mxs_spi_release_bus(struct udevice *dev)
 {
-   /* TODO */
-
return 0;
 }
 
@@ -335,7 +261,7 @@ static int mxs_spi_set_speed(struct udevice *bus, uint 
speed)
speed = plat->max_khz;
 
priv->max_khz = speed;
-   printf("%s speed %u\n", __func__, speed);
+   debug("%s speed %u\n", __func__, speed);
 
mxs_set_ssp_busclock(plat->bus, priv->max_khz);
 
@@ -348,8 +274,8 @@ static int mxs_spi_set_mode(struct udevice *bus, uint mode)
struct mxs_ssp_regs *ssp_regs = priv->regs;
u32 reg;
 
-   printf("%s mode %u\n", __func__, mode);
priv->mode = mode;
+   debug("%s mode %u\n", __func__, mode);
 
reg = SSP_CTRL1_SSP_MODE_SPI | SSP_CTRL1_WORD_LENGTH_EIGHT_BITS;

[U-Boot] [PATCH v1 1/1] spi: lpc32xx_ssp: DM conversion

[Akash Gajjar]

From: Akash Gajjar 

This patch adds support for DM to the LPC32xx SSP SPI driver.

Some TODOs are left over for later, These would be enhancements to the
original functionality, and can come later. The legacy functionality is
removed in this version.

Signed-off-by: Akash Gajjar 
---
 drivers/spi/Kconfig|  10 +-
 drivers/spi/lpc32xx_ssp.c  | 145 +++--
 include/dm/platform_data/spi_lpc32xx_ssp.h |  15 +++
 3 files changed, 93 insertions(+), 77 deletions(-)
 create mode 100644 include/dm/platform_data/spi_lpc32xx_ssp.h

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ec92b84..2297d4a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -99,6 +99,11 @@ config ICH_SPI
  access the SPI NOR flash on platforms embedding this Intel
  ICH IP core.
 
+config LPC32XX_SSP
+   bool "LPC32XX SPI Driver"
+   help
+ Enable support for SPI on LPC32xx
+
 config MVEBU_A3700_SPI
bool "Marvell Armada 3700 SPI driver"
help
@@ -277,11 +282,6 @@ config KIRKWOOD_SPI
  Enable support for SPI on various Marvell SoCs, such as
  Kirkwood and Armada 375.
 
-config LPC32XX_SSP
-   bool "LPC32XX SPI Driver"
-   help
- Enable support for SPI on LPC32xx
-
 config MPC8XX_SPI
bool "MPC8XX SPI Driver"
depends on MPC8xx
diff --git a/drivers/spi/lpc32xx_ssp.c b/drivers/spi/lpc32xx_ssp.c
index e2a593b..ae41b57 100644
--- a/drivers/spi/lpc32xx_ssp.c
+++ b/drivers/spi/lpc32xx_ssp.c
@@ -4,6 +4,9 @@
  * (C) Copyright 2014  DENX Software Engineering GmbH
  * Written-by: Albert ARIBAUD 
  *
+ * Support for device model:
+ * Copyright (C) 2018 Akash Gajjar 
+ *
  * SPDX-License-Identifier: GPL-2.0+
  */
 
@@ -13,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* SSP chip registers */
 struct ssp_regs {
@@ -36,90 +41,36 @@ struct ssp_regs {
 /* SSP status RX FIFO not empty bit */
 #define SSP_SR_RNE 0x0004
 
-/* lpc32xx spi slave */
-struct lpc32xx_spi_slave {
-   struct spi_slave slave;
+struct lpc32xx_ssp_spi_priv {
struct ssp_regs *regs;
 };
 
-static inline struct lpc32xx_spi_slave *to_lpc32xx_spi_slave(
-   struct spi_slave *slave)
+static int lpc32xx_ssp_spi_claim_bus(struct udevice *dev)
 {
-   return container_of(slave, struct lpc32xx_spi_slave, slave);
-}
-
-/* spi_init is called during boot when CONFIG_CMD_SPI is defined */
-void spi_init(void)
-{
-   /*
-*  nothing to do: clocking was enabled in lpc32xx_ssp_enable()
-* and configuration will be done in spi_setup_slave()
-   */
+   return 0;
 }
 
-/* the following is called in sequence by do_spi_xfer() */
-
-struct spi_slave *spi_setup_slave(uint bus, uint cs, uint max_hz, uint mode)
+static int lpc32xx_ssp_spi_release_bus(struct udevice *dev)
 {
-   struct lpc32xx_spi_slave *lslave;
-
-   /* we only set up SSP0 for now, so ignore bus */
-
-   if (mode & SPI_3WIRE) {
-   pr_err("3-wire mode not supported");
-   return NULL;
-   }
-
-   if (mode & SPI_SLAVE) {
-   pr_err("slave mode not supported\n");
-   return NULL;
-   }
-
-   if (mode & SPI_PREAMBLE) {
-   pr_err("preamble byte skipping not supported\n");
-   return NULL;
-   }
-
-   lslave = spi_alloc_slave(struct lpc32xx_spi_slave, bus, cs);
-   if (!lslave) {
-   printf("SPI_error: Fail to allocate lpc32xx_spi_slave\n");
-   return NULL;
-   }
-
-   lslave->regs = (struct ssp_regs *)SSP0_BASE;
-
-   /*
-* 8 bit frame, SPI fmt, 500kbps -> clock divider is 26.
-* Set SCR to 0 and CPSDVSR to 26.
-*/
-
-   writel(0x7, >regs->cr0); /* 8-bit chunks, SPI, 1 clk/bit */
-   writel(26, >regs->cpsr); /* SSP clock = HCLK/26 = 500kbps */
-   writel(0, >regs->imsc); /* do not raise any interrupts */
-   writel(0, >regs->icr); /* clear any pending interrupt */
-   writel(0, >regs->dmacr); /* do not do DMAs */
-   writel(SSP_CR1_SSP_ENABLE, >regs->cr1); /* enable SSP0 */
-   return >slave;
+   return 0;
 }
 
-void spi_free_slave(struct spi_slave *slave)
+static int lpc32xx_ssp_spi_set_speed(struct udevice *bus, uint hz)
 {
-   struct lpc32xx_spi_slave *lslave = to_lpc32xx_spi_slave(slave);
-
-   debug("(lpc32xx) spi_free_slave: 0x%08x\n", (u32)lslave);
-   free(lslave);
+   return 0;
 }
 
-int spi_claim_bus(struct spi_slave *slave)
+static int lpc32xx_ssp_spi_set_mode(struct udevice *bus, uint mode)
 {
-   /* only one bus and slave so far, always available */
return 0;
 }
 
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
-   const void *dout, void *din, unsigned long flags)
+static int lpc32xx_ssp_spi_xfer(struct udevice *dev, uint bitlen,
+  

[U-Boot] [PATCH v2 2/3] spi: sh_spi: full DM conversion

[Akash Gajjar]

v1->v2
New in v2
add cs_info method
remove fixed regs address
add missing platform struct missing member
moved priv struct into sh_spi.c
remove unnecessary space and comments

Signed-off-by: Akash Gajjar 
---
 drivers/spi/sh_spi.c  | 44 +++
 drivers/spi/sh_spi.h  |  4 
 include/dm/platform_data/spi_sh.h |  5 -
 3 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/drivers/spi/sh_spi.c b/drivers/spi/sh_spi.c
index b308ec8..db14031 100644
--- a/drivers/spi/sh_spi.c
+++ b/drivers/spi/sh_spi.c
@@ -2,7 +2,7 @@
  * SH SPI driver
  *
  * Support for device model:
- * Copyright (C) 2018  Akash Gajjar 
+ * Copyright (C) 2018  Akash Gajjar 
  * Harshit Shah 
  *
  * Copyright (C) 2011-2012 Renesas Solutions Corp.
@@ -19,6 +19,11 @@
 #include 
 #include "sh_spi.h"
 
+struct sh_spi_priv {
+   struct sh_spi_regs  *regs;
+   u32 cs;
+};
+
 static void sh_spi_write(unsigned long data, unsigned long *reg)
 {
writel(data, reg);
@@ -86,10 +91,11 @@ static void sh_spi_set_cs(struct sh_spi_regs *regs, 
unsigned int cs)
sh_spi_set_bit(val, >cr4);
 }
 
-static void __spi_setup(struct sh_spi_regs *regs, uint cs)
+static void spi_setup(struct sh_spi_priv *priv)
 {
-   /* initialize spi */
-   regs = (struct sh_spi_regs *)CONFIG_SH_SPI_BASE;
+   struct sh_spi_regs *regs = priv->regs;
+   u32 cs = priv->cs;
+
/* SPI sycle stop */
sh_spi_write(0xfe, >cr1);
/* CR1 init */
@@ -106,7 +112,7 @@ static void __spi_setup(struct sh_spi_regs *regs, uint cs)
 }
 
 static int sh_spi_send(struct sh_spi_regs *regs, const unsigned char *tx_data,
-   unsigned int len, unsigned long flags)
+   unsigned int len, unsigned long flags)
 {
int i, cur_len, ret = 0;
int remain = (int)len;
@@ -151,7 +157,7 @@ static int sh_spi_send(struct sh_spi_regs *regs, const 
unsigned char *tx_data,
 }
 
 static int sh_spi_receive(struct sh_spi_regs *regs, unsigned char *rx_data,
-   unsigned int len, unsigned long flags)
+   unsigned int len, unsigned long flags)
 {
int i;
 
@@ -227,12 +233,29 @@ static int sh_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
return ret;
 }
 
+static int sh_spi_cs_info(struct udevice *bus, uint cs,
+   struct spi_cs_info *info)
+{
+   struct sh_spi_priv *priv = dev_get_priv(bus);
+
+   if (cs >= priv->cs) {
+   printf("no cs %u\n", cs);
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
 static int sh_spi_probe(struct udevice *bus)
 {
+   struct sh_spi_platdata *plat = bus->platdata;
struct sh_spi_priv *priv = dev_get_priv(bus);
struct sh_spi_regs *regs = priv->regs;
 
-   __spi_setup(regs, priv->cs);
+   priv->regs = plat->regs;
+   priv->cs = plat->cs;
+
+   spi_setup(priv);
 
return 0;
 }
@@ -248,8 +271,9 @@ static int sh_spi_ofdata_to_platadata(struct udevice *bus)
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
 
+   plat->regs = (struct sh_spi_regs *regs)addr;
plat->cs = fdtdec_get_int(gd->fdt_blob, dev_of_offset(bus),
-   "num-cs", 4);
+   "num-cs", 4);
 
return 0;
 }
@@ -259,10 +283,12 @@ static const struct dm_spi_ops mvebu_spi_ops = {
.xfer   = sh_spi_xfer,
.set_speed  = sh_spi_set_speed,
.set_mode   = sh_spi_set_mode,
+   .cs_info= sh_spi_cs_info,
 };
 
+/* TODO: update compatible device tree */
 static const struct udevice_id sh_spi_ids[] = {
-   { .compatible = "sh,sh_spi" },
+   { .compatible = " " },
 };
 #endif
 
diff --git a/drivers/spi/sh_spi.h b/drivers/spi/sh_spi.h
index 87a253f..f945744 100644
--- a/drivers/spi/sh_spi.h
+++ b/drivers/spi/sh_spi.h
@@ -55,10 +55,6 @@ struct sh_spi_regs {
 #define SH_SPI_FIFO_SIZE   32
 #define SH_SPI_NUM_CS  4
 
-struct sh_spi_priv {
-   struct sh_spi_regs  *regs;
-};
-
 static inline struct sh_spi *to_sh_spi(struct spi_slave *slave)
 {
return container_of(slave, struct sh_spi, slave);
diff --git a/include/dm/platform_data/spi_sh.h 
b/include/dm/platform_data/spi_sh.h
index b4d63dc..c6d0ac5 100644
--- a/include/dm/platform_data/spi_sh.h
+++ b/include/dm/platform_data/spi_sh.h
@@ -2,16 +2,11 @@
  * Copyright (C) 2018 Akash Gajjar 
  *
  * SPDX-License-Identifier:GPL-2.0+
- *
  */
 
 #ifndef __spi_sh_h
 #define __spi_sh_h
 
-/*
- * struct sh_spi_platdata - information about a sh spi module
- *
- */
 struct sh_spi_platdata {
struct sh_spi_regs  *regs;
u8 cs;
-- 
2.7.4

___

[U-Boot] [PATCH v2 1/3] spi: sh_qspi: full DM conversion

[Akash Gajjar]

v1->v2
New in v2
update Kconfig
replace __sh_qspi_setup to sh_qspi_setup
add missing memeber of platform data

Signed-off-by: Akash Gajjar 
---
 drivers/spi/Kconfig| 12 +-
 drivers/spi/sh_qspi.c  | 49 +++---
 include/dm/platform_data/qspi_sh.h |  4 
 3 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ec92b84..81079c5 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -155,6 +155,12 @@ config SANDBOX_SPI
};
  };
 
+config SH_QSPI
+   bool "Renesas Quad SPI driver"
+   help
+ Enable the Renesas Quad SPI controller driver. This driver can be
+ used on Renesas SoCs.
+
 config STM32_QSPI
bool "STM32F7 QSPI driver"
depends on STM32F7
@@ -259,12 +265,6 @@ config SH_SPI
  Enable the SuperH SPI controller driver. This driver can be used
  on various SuperH SoCs, such as SH7757.
 
-config SH_QSPI
-   bool "Renesas Quad SPI driver"
-   help
- Enable the Renesas Quad SPI controller driver. This driver can be
- used on Renesas SoCs.
-
 config TI_QSPI
bool "TI QSPI driver"
help
diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
index 5fdd52e..b81cee5 100644
--- a/drivers/spi/sh_qspi.c
+++ b/drivers/spi/sh_qspi.c
@@ -77,49 +77,48 @@ struct sh_qspi_priv {
struct sh_qspi_regs *regs;
 };
 
-static int __sh_qspi_setup(struct sh_qspi_priv *priv)
+static void sh_qspi_setup(struct sh_qspi_priv *priv)
 {
-   /* QSPI initialize */
-   priv->regs = (struct sh_qspi_regs *)SH_QSPI_BASE;
+   struct sh_qspi_regs *regs = priv->regs;
 
/* Set master mode only */
-   writeb(SPCR_MSTR, >regs->spcr);
+   writeb(SPCR_MSTR, >spcr);
 
/* Set SSL signal level */
-   writeb(0x00, >regs->sslp);
+   writeb(0x00, >sslp);
 
/* Set MOSI signal value when transfer is in idle state */
-   writeb(SPPCR_IO3FV | SPPCR_IO2FV, >regs->sppcr);
+   writeb(SPPCR_IO3FV | SPPCR_IO2FV, >sppcr);
 
/* Set bit rate. See 58.3.8 Quad Serial Peripheral Interface */
-   writeb(0x01, >regs->spbr);
+   writeb(0x01, >spbr);
 
/* Disable Dummy Data Transmission */
-   writeb(0x00, >regs->spdcr);
+   writeb(0x00, >spdcr);
 
/* Set clock delay value */
-   writeb(0x00, >regs->spckd);
+   writeb(0x00, >spckd);
 
/* Set SSL negation delay value */
-   writeb(0x00, >regs->sslnd);
+   writeb(0x00, >sslnd);
 
/* Set next-access delay value */
-   writeb(0x00, >regs->spnd);
+   writeb(0x00, >spnd);
 
/* Set equence command */
-   writew(SPCMD_INIT2, >regs->spcmd0);
+   writew(SPCMD_INIT2, >spcmd0);
 
/* Reset transfer and receive Buffer */
-   setbits_8(>regs->spbfcr, SPBFCR_TXRST | SPBFCR_RXRST);
+   setbits_8(>spbfcr, SPBFCR_TXRST | SPBFCR_RXRST);
 
/* Clear transfer and receive Buffer control bit */
-   clrbits_8(>regs->spbfcr, SPBFCR_TXRST | SPBFCR_RXRST);
+   clrbits_8(>spbfcr, SPBFCR_TXRST | SPBFCR_RXRST);
 
/* Set equence control method. Use equence0 only */
-   writeb(0x00, >regs->spscr);
+   writeb(0x00, >spscr);
 
/* Enable SPI function */
-   setbits_8(>regs->spcr, SPCR_SPE);
+   setbits_8(>spcr, SPCR_SPE);
 }
 
 static int sh_qspi_set_speed(struct udevice *bus, uint hz)
@@ -156,7 +155,7 @@ static int sh_qspi_xfer(struct udevice *dev, unsigned int 
bitlen,
 
if (dout == NULL && din == NULL) {
if (flags & SPI_XFER_END)
-   spi_cs_deactivate(regs);
+   spi_cs_deactivate(regs);/* TODO */
return 0;
}
 
@@ -168,7 +167,7 @@ static int sh_qspi_xfer(struct udevice *dev, unsigned int 
bitlen,
nbyte = bitlen / 8;
 
if (flags & SPI_XFER_BEGIN) {
-   spi_cs_activate(regs);
+   spi_cs_activate(regs);  /* TODO */
 
/* Set 1048576 byte */
writel(0x10, spbmul0);
@@ -219,7 +218,7 @@ static int sh_qspi_xfer(struct udevice *dev, unsigned int 
bitlen,
}
 
if (flags & SPI_XFER_END)
-   spi_cs_deactivate(regs);
+   spi_cs_deactivate(regs);/* TODO */
 
return ret;
 }
@@ -229,7 +228,9 @@ static int sh_qspi_probe(struct udevice *bus)
struct sh_qspi_platdata *plat = bus->platdata;
struct sh_qspi_priv *priv = dev_get_priv(bus);
 
-   __sh_qspi_setup(priv);
+   priv->regs = plat->regs;
+
+   sh_qspi_setup(priv);
 
return 0;
 }
@@ -252,14 +253,14 @@ static int sh_qspi_ofdata_to_platadata(struct udevice 
*bus)
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
 
-   plat->cs = fdtdec_get_int(gd->fdt_blob, dev_of_offset(bus),
-   "num-cs", 4);
+   plat->regs = 

Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver

[Jagan Teki]

On Wed, May 9, 2018 at 4:08 PM, Jagan Teki  wrote:
> On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
>  wrote:
>> Hi Jagan,
>>
>>> -Original Message-
>>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>>> Sent: Wednesday, May 09, 2018 1:22 PM
>>> To: Siva Durga Prasad Paladugu 
>>> Cc: Jagan Teki ; U-Boot-Denx >> b...@lists.denx.de>; michal.si...@xilinx.com
>>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>>> ZynqMP qspi driver
>>>
>>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
>>>  wrote:
>>> >
>>> > Hi,
>>> >
>>> >> -Original Message-
>>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>>> >> Sent: Wednesday, May 09, 2018 1:12 PM
>>> >> To: Siva Durga Prasad Paladugu 
>>> >> Cc: Jagan Teki ; U-Boot-Denx >> >> b...@lists.denx.de>; michal.si...@xilinx.com
>>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>>> >> for ZynqMP qspi driver
>>> >>
>>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>>> >>  wrote:
>>> >> > Hi Jagan,
>>> >> >
>>> >> >> -Original Message-
>>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
>>> >> >> To: Siva Durga Prasad Paladugu 
>>> >> >> Cc: U-Boot-Denx ; michal.si...@xilinx.com
>>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>>> >> ZynqMP
>>> >> >> qspi driver
>>> >> >>
>>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>>> >> >>  wrote:
>>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This driver
>>> >> >> > is responsible for communicating with qspi flash devices.
>>> >> >> >
>>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
>>> >> >> > 
>>> >> >> > ---
>>> >> >> > Changes for v3:
>>> >> >> > - Renamed all macros, functions, files and configs as per
>>> >> >> > comment
>>> >> >> > - Used wait_for_bit wherever required
>>> >> >> > - Removed unnecessary header inclusion
>>> >> >> >
>>> >> >> > Changes for v2:
>>> >> >> > - Rebased on top of latest master
>>> >> >> > - Moved macro definitions to .h file as per comment
>>> >> >> > - Fixed magic values with macros as per comment
>>> >> >> > ---
>>> >> >> >  arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
>>> ++
>>> >> >> >  drivers/spi/Kconfig |   7 +
>>> >> >> >  drivers/spi/Makefile|   1 +
>>> >> >> >  drivers/spi/zynqmp_gqspi.c  | 670
>>> >> >> 
>>> >> >> >  4 files changed, 832 insertions(+)  create mode 100644
>>> >> >> > arch/arm/include/asm/arch-
>>> >> >> zynqmp/zynqmp_gqspi.h
>>> >> >> >  create mode 100644 drivers/spi/zynqmp_gqspi.c
>>> >> >> >
>>> >> >> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>>> >> >>
>>> >> >> already asked you to move this header code in driver .c file
>>> >> >
>>> >> > You might have missed my reply to your earlier comment on this.
>>> >> > These were moved to .h based on comment from Lukasz in v1.
>>> >> > I don’t have any issue in having them anywhere. Let me know your
>>> choice.
>>> >>
>>> >> I'm trying to align Linux code, better to move like that and make
>>> >> sure to use similar macros.
>>> >>
>>> >> >
>>> >
>>> > [snip]
>>> >
>>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv
>>> >> *priv) {
>>> >> >> > +   u8 command = 1;
>>> >> >> > +   u32 gen_fifo_cmd;
>>> >> >> > +   u32 bytecount = 0;
>>> >> >> > +
>>> >> >> > +   while (priv->len) {
>>> >> >> > +   gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
>>> >> >> > +   gen_fifo_cmd |= GQSPI_GFIFO_TX;
>>> >> >> > +
>>> >> >> > +   if (command) {
>>> >> >> > +   command = 0;
>>> >> >> > +   last_cmd = *(u8 *)priv->tx_buf;
>>> >> >> > +   }
>>> >> >>
>>> >> >> don't understand this code can you explain? command assigned 1 it
>>> >> >> will not updated anywhere?
>>> >> >
>>> >> > I want to store last command sent. As the first byte in loop only
>>> >> > contains command, it ensures it fills only for one time and next
>>> >> > time it
>>> >> may contain data to be sent along with command.
>>> >> > Command initialized to 1 while declaring it above(u8 command = 1).
>>> >>
>>> >> Ok the first TX buf has command and reused in tx and rx fifo, how
>>> >> come to use use same in rx fifo? why is is last_cmd it is first_cmd?
>>> >
>>> > This holds the command that was sent last to the device before we use in
>>> tx/rx fill, hence used this name.
>>>
>>> ie. what I wonder, usually the spi transfer start with cmd + 

Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for ZynqMP qspi driver

[Jagan Teki]

On Wed, May 9, 2018 at 1:31 PM, Siva Durga Prasad Paladugu
 wrote:
> Hi Jagan,
>
>> -Original Message-
>> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> Sent: Wednesday, May 09, 2018 1:22 PM
>> To: Siva Durga Prasad Paladugu 
>> Cc: Jagan Teki ; U-Boot-Denx > b...@lists.denx.de>; michal.si...@xilinx.com
>> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> ZynqMP qspi driver
>>
>> On Wed, May 9, 2018 at 1:20 PM, Siva Durga Prasad Paladugu
>>  wrote:
>> >
>> > Hi,
>> >
>> >> -Original Message-
>> >> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>> >> Sent: Wednesday, May 09, 2018 1:12 PM
>> >> To: Siva Durga Prasad Paladugu 
>> >> Cc: Jagan Teki ; U-Boot-Denx > >> b...@lists.denx.de>; michal.si...@xilinx.com
>> >> Subject: Re: [U-Boot] [PATCH v3 1/2] spi: zynqmp_gqspi: Add support
>> >> for ZynqMP qspi driver
>> >>
>> >> On Wed, May 9, 2018 at 12:33 PM, Siva Durga Prasad Paladugu
>> >>  wrote:
>> >> > Hi Jagan,
>> >> >
>> >> >> -Original Message-
>> >> >> From: Jagan Teki [mailto:ja...@amarulasolutions.com]
>> >> >> Sent: Wednesday, May 09, 2018 12:01 PM
>> >> >> To: Siva Durga Prasad Paladugu 
>> >> >> Cc: U-Boot-Denx ; michal.si...@xilinx.com
>> >> >> Subject: Re: [PATCH v3 1/2] spi: zynqmp_gqspi: Add support for
>> >> ZynqMP
>> >> >> qspi driver
>> >> >>
>> >> >> On Tue, May 8, 2018 at 3:43 PM, Siva Durga Prasad Paladugu
>> >> >>  wrote:
>> >> >> > This patch adds qspi driver support for ZynqMP SoC. This driver
>> >> >> > is responsible for communicating with qspi flash devices.
>> >> >> >
>> >> >> > Signed-off-by: Siva Durga Prasad Paladugu
>> >> >> > 
>> >> >> > ---
>> >> >> > Changes for v3:
>> >> >> > - Renamed all macros, functions, files and configs as per
>> >> >> > comment
>> >> >> > - Used wait_for_bit wherever required
>> >> >> > - Removed unnecessary header inclusion
>> >> >> >
>> >> >> > Changes for v2:
>> >> >> > - Rebased on top of latest master
>> >> >> > - Moved macro definitions to .h file as per comment
>> >> >> > - Fixed magic values with macros as per comment
>> >> >> > ---
>> >> >> >  arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h | 154
>> ++
>> >> >> >  drivers/spi/Kconfig |   7 +
>> >> >> >  drivers/spi/Makefile|   1 +
>> >> >> >  drivers/spi/zynqmp_gqspi.c  | 670
>> >> >> 
>> >> >> >  4 files changed, 832 insertions(+)  create mode 100644
>> >> >> > arch/arm/include/asm/arch-
>> >> >> zynqmp/zynqmp_gqspi.h
>> >> >> >  create mode 100644 drivers/spi/zynqmp_gqspi.c
>> >> >> >
>> >> >> > diff --git a/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >> >> > b/arch/arm/include/asm/arch-zynqmp/zynqmp_gqspi.h
>> >> >>
>> >> >> already asked you to move this header code in driver .c file
>> >> >
>> >> > You might have missed my reply to your earlier comment on this.
>> >> > These were moved to .h based on comment from Lukasz in v1.
>> >> > I don’t have any issue in having them anywhere. Let me know your
>> choice.
>> >>
>> >> I'm trying to align Linux code, better to move like that and make
>> >> sure to use similar macros.
>> >>
>> >> >
>> >
>> > [snip]
>> >
>> >> >> > +static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv
>> >> *priv) {
>> >> >> > +   u8 command = 1;
>> >> >> > +   u32 gen_fifo_cmd;
>> >> >> > +   u32 bytecount = 0;
>> >> >> > +
>> >> >> > +   while (priv->len) {
>> >> >> > +   gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
>> >> >> > +   gen_fifo_cmd |= GQSPI_GFIFO_TX;
>> >> >> > +
>> >> >> > +   if (command) {
>> >> >> > +   command = 0;
>> >> >> > +   last_cmd = *(u8 *)priv->tx_buf;
>> >> >> > +   }
>> >> >>
>> >> >> don't understand this code can you explain? command assigned 1 it
>> >> >> will not updated anywhere?
>> >> >
>> >> > I want to store last command sent. As the first byte in loop only
>> >> > contains command, it ensures it fills only for one time and next
>> >> > time it
>> >> may contain data to be sent along with command.
>> >> > Command initialized to 1 while declaring it above(u8 command = 1).
>> >>
>> >> Ok the first TX buf has command and reused in tx and rx fifo, how
>> >> come to use use same in rx fifo? why is is last_cmd it is first_cmd?
>> >
>> > This holds the command that was sent last to the device before we use in
>> tx/rx fill, hence used this name.
>>
>> ie. what I wonder, usually the spi transfer start with cmd + data in that 
>> case
>> it would be the first command, did gqspi work reverse way?
>
> It's also same as others :-), the last_cmd holds the recent command that was 
> sent to the device.
> Its just 

Re: [U-Boot] [PATCHv2 2/3] buildman: support newer gcc versions from kernel.org

[Daniel Schwierzeck]

On 08.05.2018 02:50, Tom Rini wrote:
> From: Daniel Schwierzeck 
> 
> Add support for gcc versions 7.3.0, 6.4.0 and 4.9.4.
> 
> Also use a regex for matching the tarball names. Some gcc versions
> use '-ARCH-' instead of '_ARCH-'.
> 
> As part of this, we switch TravisCI to also using these toolchains for
> all platforms.
> 
> Signed-off-by: Daniel Schwierzeck 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2:
> - Change to only 7.3.0 / 6.4.0 / 4.9.4 for gcc versions.  Update
>   .travis.yml for x86_64 toolchain and fetch all toolchains.
> - Fold in the old patch I had to expand and update SH builds as we
>   cannot build without those changes.
> ---
>  .travis.yml | 38 ++
>  tools/buildman/toolchain.py |  6 +++---
>  2 files changed, 29 insertions(+), 15 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 57f38e11698b..b07ce9b8ceb4 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -21,7 +21,6 @@ addons:
>  - python-virtualenv
>  - swig
>  - libpython-dev
> -- gcc-powerpc-linux-gnu
>  - iasl
>  - grub-efi-ia32-bin
>  - rpm2cpio
> @@ -29,6 +28,11 @@ addons:
>  - device-tree-compiler
>  - lzop
>  
> +before_install:
> + - sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
> + - sudo apt-get update -q
> + - sudo apt-get install libisl15 -y
> +
>  install:
>   # Clone uboot-test-hooks
>   - git clone --depth=1 git://github.com/swarren/uboot-test-hooks.git 
> /tmp/uboot-test-hooks
> @@ -36,10 +40,8 @@ install:
>   - ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname`
>   # prepare buildman environment
>   - echo -e "[toolchain]\nroot = /usr" > ~/.buildman
> - - echo -e "aarch64 = 
> /tmp/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu" >> ~/.buildman
> - - echo -e "arm = /tmp/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf" 
> >> ~/.buildman
>   - echo -e "arc = 
> /tmp/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install" >> ~/.buildman
> - - echo -e "\n[toolchain-alias]\nsh = sh4\nopenrisc = or32" >> ~/.buildman
> + - echo -e "\n[toolchain-alias]\nsh = sh2" >> ~/.buildman
>   - cat ~/.buildman
>   - virtualenv /tmp/venv
>   - . /tmp/venv/bin/activate
> @@ -64,10 +66,10 @@ before_script:
>- if [[ "${TOOLCHAIN}" == *microblaze* ]]; then ./tools/buildman/buildman 
> --fetch-arch microblaze ; fi
>- if [[ "${TOOLCHAIN}" == *mips* ]]; then ./tools/buildman/buildman 
> --fetch-arch mips ; fi
>- if [[ "${TOOLCHAIN}" == *or32* ]]; then ./tools/buildman/buildman 
> --fetch-arch or32 ; fi
> -  - if [[ "${TOOLCHAIN}" == *sh4* ]]; then ./tools/buildman/buildman 
> --fetch-arch sh4 ; fi
> +  - if [[ "${TOOLCHAIN}" == *sh* ]]; then ./tools/buildman/buildman 
> --fetch-arch sh2 ; fi
>- if [[ "${TOOLCHAIN}" == *x86_64* ]]; then
>./tools/buildman/buildman --fetch-arch x86_64;
> -  echo -e "\n[toolchain-prefix]\nx86 = 
> ${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-" 
> >> ~/.buildman;
> +  echo -e "\n[toolchain-prefix]\nx86 = 
> ${HOME}/.buildman-toolchains/gcc-7.3.0-nolibc/x86_64-linux/bin/x86_64-linux-" 
> >> ~/.buildman;

you could add "x86 = x86_64" to section [toolchain-alias] to avoid
hard-coding this

>  fi
>- if [[ "${TOOLCHAIN}" == arc ]]; then
> wget 
> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2017.09-release/arc_gnu_2017.09_prebuilt_uclibc_le_archs_linux_install.tar.gz
>  &&
> @@ -80,11 +82,10 @@ before_script:
>  fi
># If TOOLCHAIN is unset, we're on some flavour of ARM.
>- if [[ "${TOOLCHAIN}" == "" ]]; then
> -   wget 
> http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/aarch64-linux-gnu/gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu.tar.xz
>  &&
> -   wget 
> http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/arm-linux-gnueabihf/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf.tar.xz
>  &&
> -   tar -C /tmp -xf 
> gcc-linaro-6.3.1-2017.02-x86_64_aarch64-linux-gnu.tar.xz &&
> -   tar -C /tmp -xf 
> gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf.tar.xz;
> +   ./tools/buildman/buildman --fetch-arch arm &&
> +   ./tools/buildman/buildman --fetch-arch aarch64;
>  fi
> +  - if [[ "${TOOLCHAIN}" == "powerpc" ]]; then ./tools/buildman/buildman 
> --fetch-arch powerpc; fi
>- if [[ "${TOOLCHAIN}" == "riscv" ]]; then
>  wget 
> https://github.com/PkmX/riscv-prebuilt-toolchains/releases/download/20180111/riscv32-unknown-elf-toolchain.tar.gz
>  &&
>  tar -C /tmp -xf riscv32-unknown-elf-toolchain.tar.gz &&
> @@ -227,26 +228,37 @@ matrix:
>TOOLCHAIN="mips"
>  - env:
>  - BUILDMAN="mpc83xx"
> +  TOOLCHAIN="powerpc"
>  - env:
>  - BUILDMAN="mpc85xx -x freescale"
> +  TOOLCHAIN="powerpc"
>  - env:
>  - BUILDMAN="mpc85xx -x t208xrdb -x t4qds -x 

Re: [U-Boot] [PATCH v2 0/6] ARM: mvebu: a38x: updates to ddr training code

[Stefan Roese]

Hi Chris,

On 09.04.2018 12:12, Chris Packham wrote:

This series updates the ddr training code in u-boot with the latest
publicly available version from Marvell which can be found at
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git
(mv_ddr-armada-17.10 branch).

I've tried to make the delta as small as possible without breaking
bisect-ability.

The first 2 patches have already been sent as
http://patchwork.ozlabs.org/patch/894866/ and
http://patchwork.ozlabs.org/patch/894865/

The bulk of the changes are in patch 4. Naturally this doesn't pass
checkpatch.pl but I'm erring on the side of being able to diff with the
upstream source. Also due to it's size this patch may not make it to the
mailing list so the full series can be retrieved from the mv-ddr branch
of https://github.com/cpackham/u-boot.git.

I've tested this series on the db-88f6820-amc board and on a custom
board that is not upstream (yet). I've also build tested the other a38x
boards. More testing on actual hardware would be greatly appreciated.

Changes in v2:
- remove unused #include


Many thanks for working on this. I tried to apply the patches today
but failed. Most likely the license SPDX tag changes recently
applied are the problem. Could you please rebase again against
latest master and re-send?

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

[U-Boot] [PATCH] configs: sama5d2_xplained: enable ext4 command support

[Eugen Hristev]

To support loading the zImage + DTB from the rootfs ext4 partitions,
enable the ext4 command support.

Based on original work by Wenyou Yang

Signed-off-by: Eugen Hristev 
---
 configs/sama5d2_xplained_mmc_defconfig  | 1 +
 configs/sama5d2_xplained_spiflash_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/sama5d2_xplained_mmc_defconfig 
b/configs/sama5d2_xplained_mmc_defconfig
index 066fdb3..6d1dc92 100644
--- a/configs/sama5d2_xplained_mmc_defconfig
+++ b/configs/sama5d2_xplained_mmc_defconfig
@@ -34,6 +34,7 @@ CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
+CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
diff --git a/configs/sama5d2_xplained_spiflash_defconfig 
b/configs/sama5d2_xplained_spiflash_defconfig
index 87bca1f..f4333ea 100644
--- a/configs/sama5d2_xplained_spiflash_defconfig
+++ b/configs/sama5d2_xplained_spiflash_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
+CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
-- 
2.7.4

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

Re: [U-Boot] [PATCH] efi_loader: fix off-by-one bug in efi_get_variable

[Heinrich Schuchardt]

On 05/09/2018 12:50 AM, Ivan Gorinov wrote:

efi_get_variable() always stores an extra zero byte after the output data.
When the returned data size matches the output buffer size, the extra zero
byte is stored past the end of the output buffer.

Signed-off-by: Ivan Gorinov 


Thanks for the patch.

There other issues we might want to fix:

If the blob has an uneven number of hexadecimal digits 2 N + 1 the 
function hex2mem is called with count = 2 N + 2. hex('\0') will return 
-1, hex2mem returns NULL, and the blob is happily considered as correct. 
We should create an error instead.


There is no need for the argument count at all as hexstr is '\0' terminated.


---
  lib/efi_loader/efi_variable.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6c177da..d031338 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -68,11 +68,11 @@ static const char *hex2mem(u8 *mem, const char *hexstr, int 
count)
do {
int nibble;
  
-		*mem = 0;

-
if (!count || !*hexstr)
break;
  
+		*mem = 0;

+


Why should we have this line at all? We set *mem = nibble below.

Regards

Heinrich


nibble = hex(*hexstr);
if (nibble < 0)
break;


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

[U-Boot] [PATCH] fs: ext4: fix crash on ext4ls

[Eugen Hristev]

Found a crash while issuing ext4ls with a non-existent directory.
Crash test:

=> ext4ls mmc 0 1
** Can not find directory. **
data abort
pc : [<3fd7c2ec>]  lr : [<3fd93ed8>]
reloc pc : [<26f142ec>]lr : [<26f2bed8>]
sp : 3f963338  ip : 3fdc3dc4 fp : 3fd6b370
r10: 0004  r9 : 3f967ec0 r8 : 3f96db68
r7 : 3fdc99b4  r6 :  r5 : 3f96dc88  r4 : 3fdcbc8c
r3 : fffa  r2 :  r1 : 3f96e0bc  r0 : 0002
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

Tested on SAMA5D2_Xplained board (sama5d2_xplained_mmc_defconfig)

Looks like crash is introduced by commit:
"fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls

Issue is that dirnode is not initialized, and then freed if the call
to ext4_ls fails. ext4_ls will not change the value of dirnode in this case
thus we have a crash with data abort.

I added initialization and a check for dirname being NULL.

Fixes: "fa9ca8a" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
Cc: Stefan Brüns 
Cc: Tom Rini 
Signed-off-by: Eugen Hristev 
---
Hello,

Regarding this fix, I am not sure if we actually need to free the node, but
according to commit "fa9ca8a" , it was added to fix Coverity case.
So, I decided to keep the free call under if statement if variable is NULL.
If a different fix is required, please advise and I can change and resend.

Thanks !

 fs/ext4/ext4fs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 4b36a3e..2a28031 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -164,7 +164,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
 
 int ext4fs_ls(const char *dirname)
 {
-   struct ext2fs_node *dirnode;
+   struct ext2fs_node *dirnode = NULL;
int status;
 
if (dirname == NULL)
@@ -174,7 +174,8 @@ int ext4fs_ls(const char *dirname)
  FILETYPE_DIRECTORY);
if (status != 1) {
printf("** Can not find directory. **\n");
-   ext4fs_free_node(dirnode, _root->diropen);
+   if (dirnode)
+   ext4fs_free_node(dirnode, _root->diropen);
return 1;
}
 
-- 
2.7.4

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

Re: [U-Boot] [UBOOT PATCH v3 0/7] Add support of SD3.0 UHS modes for ZynqMP

[Michal Simek]

Hi Jaehoon,

On 2.5.2018 04:05, Jaehoon Chung wrote:
> On 04/30/2018 06:02 PM, Michal Simek wrote:
>> Hi Tom,
>>
>> On 19.4.2018 09:07, Siva Durga Prasad Paladugu wrote:
>>> This patch series is meant to add SD3.0 support for ZynqMP
>>> platform.
>>> The first five patches in the series mostly setting up
>>> things in sdhci layer to support SD3.0 , the sixth patch
>>> is to add SD3.0 support for ZynqMP platform and the last
>>> patch is to enable this support for ZynqMP zcu102 rev1.0
>>> eval board.
>>>
>>> Siva Durga Prasad Paladugu (7):
>>>   mmc: sdhci: Add support for disabling clock
>>>   mmc: sdhci: Handle execute tuning command in sdhci_send_command
>>>   sdhci: Add new sdhci ops for platform specific tuning and delays
>>>   mmc: sdhci: Invoke platform specific tuning and delay routines
>>>   mmc : sdhci: Read capabilities register1 and update host caps
>>>   mmc: zynq_sdhci: Add support for SD3.0
>>>   zynqmp: zcu102: Enable UHS support for ZCU102 Rev1.0 board
>>>
>>>  board/xilinx/zynqmp/Makefile  |   2 +
>>>  board/xilinx/zynqmp/tap_delays.c  | 229 
>>> +
>>>  configs/xilinx_zynqmp_zcu102_rev1_0_defconfig |   2 +
>>>  drivers/mmc/sdhci.c   |  63 ++-
>>>  drivers/mmc/zynq_sdhci.c  | 231 
>>> +-
>>>  include/sdhci.h   |   8 +
>>>  include/zynqmp_tap_delay.h|  20 +++
>>>  7 files changed, 547 insertions(+), 8 deletions(-)
>>>  create mode 100644 board/xilinx/zynqmp/tap_delays.c
>>>  create mode 100644 include/zynqmp_tap_delay.h
>>>
>>
>> It looks like that Jaehoon is out or busy with something else. Can you
>> please recommend someone to take a look at these patches? Definitely
>> feel free to look at it self.
> 
> Sorry. First, I checked the patches that delegate to me on patchwork.
> So I missed this patchset. I will check this on Today.

It looks like that Today wasn't really Today.
Anyway giving you one more day and then will apply it via my tree.

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

Re: [U-Boot] [PATCH] efi_loader: fix off-by-one bug in efi_get_variable

[Alexander Graf]

On 05/09/2018 12:50 AM, Ivan Gorinov wrote:

efi_get_variable() always stores an extra zero byte after the output data.
When the returned data size matches the output buffer size, the extra zero
byte is stored past the end of the output buffer.

Signed-off-by: Ivan Gorinov 


Thanks to the memset right above the loop we can just remove the *mem = 
0 line altogether, no?


Alex


---
  lib/efi_loader/efi_variable.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6c177da..d031338 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -68,11 +68,11 @@ static const char *hex2mem(u8 *mem, const char *hexstr, int 
count)
do {
int nibble;
  
-		*mem = 0;

-
if (!count || !*hexstr)
break;
  
+		*mem = 0;

+
nibble = hex(*hexstr);
if (nibble < 0)
break;



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

Re: [U-Boot] [U-Boot,1/3] sf: Add GigaDevice gd25q32b entry

[Philipp Tomsich]

> Add entry for GigaDevice gd25q32b part.
> 
> Signed-off-by: Marty E. Plummer 
> ---
>  drivers/mtd/spi/spi_flash_ids.c | 1 +
>  1 file changed, 1 insertion(+)
> 

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

[U-Boot] GCC 7.x vs. C++ comments

[Dr. Philipp Tomsich]

Tom,

I recently ran a local buildman with a came across these:
>   cc -Wp,-MD,tools/.gen_eth_addr.d -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude 
> -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC 
> -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -o tools/gen_eth_addr 
> tools/gen_eth_addr.c  
> tools/gen_eth_addr.c:1:1: warning: C++ style comments are not allowed in ISO 
> C90
>  // SPDX-License-Identifier: GPL-2.0+
>  ^
> tools/gen_eth_addr.c:1:1: warning: (this will be reported only once per input 
> file)
>   cc -Wp,-MD,tools/.gen_ethaddr_crc.o.d -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude 
> -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC 
> -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o tools/gen_ethaddr_crc.o 
> tools/gen_ethaddr_crc.c
> tools/gen_ethaddr_crc.c:1:1: warning: C++ style comments are not allowed in 
> ISO C90
>  // SPDX-License-Identifier: GPL-2.0+
>  ^
> tools/gen_ethaddr_crc.c:1:1: warning: (this will be reported only once per 
> input file)
>   echo "#include <../lib/crc8.c>" >tools/lib/crc8.c
>   cc -Wp,-MD,tools/lib/.crc8.o.d -Wall -Wstrict-prototypes -O2 
> -fomit-frame-pointer-include ./include/compiler.h -idirafterinclude 
> -idirafter./arch/arm/include -I./scripts/dtc/libfdt -I./tools -DUSE_HOSTCC 
> -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE -pedantic -c -o tools/lib/crc8.o 
> tools/lib/crc8.c
> In file included from tools/lib/crc8.c:1:0:
> ./tools/../lib/crc8.c:1:1: warning: C++ style comments are not allowed in ISO 
> C90
>  // SPDX-License-Identifier: GPL-2.0+
>  ^

The system compiler was a
> Using built-in specs.
> COLLECT_GCC=cc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 
> 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
> --program-suffix=-4.9 --enable-shared --enable-linker-build-id 
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
> --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
> --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
> --enable-libstdcxx-time=yes --enable-gnu-unique-object 
> --disable-vtable-verify --enable-plugin --with-system-zlib 
> --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
> --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
> --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
> --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) 


What’s your preferred solution:
(a) change these comments
(b) change our Makefiles to let GCC know that we are compiling 
gnu99/C99?

Neither solution is too appealing to me, so I am asking...

Thanks,
Philipp.



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

Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups

[Petr Vorel]

Hi Eugeniu,

> FWIW, here is some statistics of the kernel kconfig development in the
> v4.10..v4.17-rc4 commit range:

> - 86 non-merge change-sets:
> git rev-list --no-merges --count v4.10..v4.17-rc4 -- scripts/kconfig/
> 86
FYI: I send some time ago a patchset to update kconfig in buildroot, where 
delta is even
bigger as sync was to 3.13-rc5 (+ some fixes).

> Eugeniu.

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/buildroot/list/?series=40942
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups

[yamada.masahiro]

Hi Engeniu,

> -Original Message-
> From: Eugeniu Rosca [mailto:ero...@de.adit-jv.com]
> Sent: Wednesday, May 09, 2018 5:04 PM
> To: Tom Rini ; Yamada, Masahiro/山田 真弘
> ; Petr Vorel 
> Cc: Ulf Magnusson ; Simon Glass ;
> U-Boot Mailing List ; Eugeniu Rosca
> ; Eugeniu Rosca 
> Subject: Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups
> 
> Masahiro, Tom, Petr,
> 
> Thanks for your prompt feedback.
> 
> > On Wed, May 09, 2018 at 10:27:00AM +0900, Masahiro Yamada wrote:
> > > I prefer syncing to check-picking.
> > > [...]
> > > Would you do that please?
> > > Or, do you want me to do it?
> 
> I would happily attempt that. However, see my below question.
> 
> On Tue, May 08, 2018 at 09:31:42PM -0400, Tom Rini wrote:
> > I'd greatly appreciate it if you can do a sync up to v4.17-rc4 or so.
> 
> Just to avoid any miscommunication, is my understanding correct that
> this is an explicit request for Masahiro to take care of the update? I
> would totally understand this.
> 
> FWIW, here is some statistics of the kernel kconfig development in the
> v4.10..v4.17-rc4 commit range:
> 
> - 86 non-merge change-sets:
> git rev-list --no-merges --count v4.10..v4.17-rc4 -- scripts/kconfig/
> 86
> 
> - 8 Kconfig commits which touch non-Kconfig files too (ignoring
>   Documentation) and hence might require more delicate conflict
>   resolution:
> 
> for c in $(git rev-list --reverse --no-merges v4.10..v4.17-rc4 --
> scripts/kconfig/); do
>   if (git log --full-diff --format="" --name-only -1 $c -- scripts/kconfig
> |
> egrep -v "scripts/kconfig|Documentation" > /dev/null); then
>   git --no-pager log --oneline $c -1;
>   fi;
> done
> 
> cb77f0d623ff scripts: Switch to more portable Perl shebang
> bb3290d91695 Remove gperf usage from toolchain
> b24413180f56 License cleanup: add SPDX GPL-2.0 license identifier to files
> with no license
> 07a422bb213a kbuild: restore autoksyms.h touch to the top Makefile
> 911a91c39cab kconfig: rename silentoldconfig to syncconfig
> 598893002745 .gitignore: move *.lex.c *.tab.[ch] patterns to the
> top-level .gitignore
> 9a8dfb394c04 kbuild: clean up *.lex.c and *.tab.[ch] patterns from
> top-level Makefile
> b23d1a241f4e kbuild: add %.lex.c and %.tab.[ch] to 'targets' automatically
> 
> I also think that the most sensitive part of this update is related to:
> - changed tooling requirements for hosts, e.g. flex and bison seem to
>   be required starting with commit 29c833061c1d ("kconfig: generate
>   lexer and parser during build instead of shipping").
> - dropped silentoldconfig support, starting with commit cedd55d49dee
>   ("kconfig: Remove silentoldconfig from help and docs; fix
>   kconfig/conf's help").
> 
> There might be questions from users experiencing build errors/warnings
> after the update, same as we've seen in [1].
> 
> [1] https://patchwork.kernel.org/patch/10318503/
> 
> I would appreciate if Tom answers the question raised in the beginning
> of my post.


Tom will make a decision.

Just my thought.


U-Boot is basically a mirror of Linux.

Syncing Kconfig will add new tool requirement, flex & bison, for building 
U-Boot,
but this is OK because Linux does it.

U-Boot follows Linux, for example, recently U-Boot adopted Linux-like SPDX 
license tag style.


And, you understand well the points for resyncing.
Yes, other parts must be adjusted.

So, I am happy if you contribute to this work.

Thanks!

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

Re: [U-Boot] [PATCH] rockchip: set SYS_NS16550_MEM32 for all SoCs

[Dr. Philipp Tomsich]

Kever,

if this affects all SoCs, then apparently nobody tested -rc3 … I had made sure 
that
all these last-minute changes had gone in before rc3.

Regards,
Philipp.

> On 9 May 2018, at 10:12, Dr. Philipp Tomsich 
>  wrote:
> 
> Kever,
> 
> There were a number a merge conflicts with this series and it looks like I 
> missed
> one of them.  This is the risk when I try to resolve conflicts instead of 
> asking for 
> a series to be rebased onto master…
> 
> Regards,
> Philipp.
> 
>> On 9 May 2018, at 10:06, Kever Yang  wrote:
>> 
>> Hi Jonathan,
>> 
>> 
>>Thanks for the patch, and it's interesting how this is missing,
>> 
>> it means all the rockchip socs can not get console output with v2018.05 :(
>> 
>> 
>> Thanks,
>> - Kever
>> On 05/08/2018 06:43 PM, Jonathan Gray wrote:
>>> Add back part of patch send out as
>>> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have
>>> gotten lost when it got merged to set SYS_NS16550_MEM32.
>>> 
>>> Allows serial output to work on tinker-rk3288 again after
>>> c3c0331db1fb7b1f4ff41e144fc04353b37c785c.
>>> 
>>> Signed-off-by: Kever Yang 
>>> Signed-off-by: Jonathan Gray 
>>> Cc: Philipp Tomsich 
>>> ---
>>> include/configs/rockchip-common.h | 2 ++
>>> 1 file changed, 2 insertions(+)
>>> 
>>> diff --git a/include/configs/rockchip-common.h 
>>> b/include/configs/rockchip-common.h
>>> index dee82ca99d..68e1105a4b 100644
>>> --- a/include/configs/rockchip-common.h
>>> +++ b/include/configs/rockchip-common.h
>>> @@ -7,6 +7,8 @@
>>> #define _ROCKCHIP_COMMON_H_
>>> #include 
>>> 
>>> +#define CONFIG_SYS_NS16550_MEM32
>>> +
>>> #ifndef CONFIG_SPL_BUILD
>>> 
>>> /* First try to boot from SD (index 0), then eMMC (index 1) */
>> 
>> 
> 
> ___
> 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] rockchip: set SYS_NS16550_MEM32 for all SoCs

[Philipp Tomsich]

> Add back part of patch send out as
> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have
> gotten lost when it got merged to set SYS_NS16550_MEM32.
> 
> Allows serial output to work on tinker-rk3288 again after
> c3c0331db1fb7b1f4ff41e144fc04353b37c785c.
> 
> Signed-off-by: Kever Yang 
> Signed-off-by: Jonathan Gray 
> Cc: Philipp Tomsich 
> ---
>  include/configs/rockchip-common.h | 2 ++
>  1 file changed, 2 insertions(+)
> 

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

Re: [U-Boot] rockchip: set SYS_NS16550_MEM32 for all SoCs

[Philipp Tomsich]

> Add back part of patch send out as
> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have
> gotten lost when it got merged to set SYS_NS16550_MEM32.
> 
> Allows serial output to work on tinker-rk3288 again after
> c3c0331db1fb7b1f4ff41e144fc04353b37c785c.
> 
> Signed-off-by: Kever Yang 
> Signed-off-by: Jonathan Gray 
> Cc: Philipp Tomsich 
> ---
>  include/configs/rockchip-common.h | 2 ++
>  1 file changed, 2 insertions(+)
> 

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

Re: [U-Boot] rockchip: set SYS_NS16550_MEM32 for all SoCs

[Philipp Tomsich]

> Add back part of patch send out as
> 'rockchip: enable SYS_NS16550 for all SoCs by default' that seems to have
> gotten lost when it got merged to set SYS_NS16550_MEM32.
> 
> Allows serial output to work on tinker-rk3288 again after
> c3c0331db1fb7b1f4ff41e144fc04353b37c785c.
> 
> Signed-off-by: Kever Yang 
> Signed-off-by: Jonathan Gray 
> Cc: Philipp Tomsich 
> ---
>  include/configs/rockchip-common.h | 2 ++
>  1 file changed, 2 insertions(+)
> 

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