[U-Boot] [PATCH 1/1] efi_add_handle() - description of efi_add_handle()

2019-05-01 Thread Heinrich Schuchardt
Correct the comments describing function efi_add_handle().

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_boottime.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 601b0a2cb8..cbf912f72b 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -423,10 +423,12 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer)
 }

 /**
- * efi_add_handle() - add a new object to the object list
- * @obj: object to be added
+ * efi_add_handle() - add a new handle to the object list
  *
- * The protocols list is initialized. The object handle is set.
+ * @handle:handle to be added
+ *
+ * The protocols list is initialized. The handle is added to the list of known
+ * UEFI objects.
  */
 void efi_add_handle(efi_handle_t handle)
 {
--
2.20.1

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


[U-Boot] [PATCH v2 1/1] efi_loader: description of efi_add_handle()

2019-05-01 Thread Heinrich Schuchardt
Correct the comments describing function efi_add_handle().

Signed-off-by: Heinrich Schuchardt 
---
v2
title should start with efi_loader
---
 lib/efi_loader/efi_boottime.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 601b0a2cb8..cbf912f72b 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -423,10 +423,12 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer)
 }

 /**
- * efi_add_handle() - add a new object to the object list
- * @obj: object to be added
+ * efi_add_handle() - add a new handle to the object list
  *
- * The protocols list is initialized. The object handle is set.
+ * @handle:handle to be added
+ *
+ * The protocols list is initialized. The handle is added to the list of known
+ * UEFI objects.
  */
 void efi_add_handle(efi_handle_t handle)
 {
--
2.20.1

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


Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)

2019-05-01 Thread Simon Goldschmidt



On 01.05.19 00:34, Julius Werner wrote:

On Tue, Apr 30, 2019 at 11:25 AM Simon Goldschmidt
 wrote:


Am 18.04.2019 um 23:08 schrieb Julius Werner:

This patch adds support for compressing non-kernel image nodes in a FIT
image (kernel nodes could already be compressed previously). This can
reduce the size of FIT images and therefore improve boot times
(especially when an image bundles many different kernel FDTs). The
images will automatically be decompressed on load.

This patch does not support extracting compatible strings from
compressed FDTs, so it's not very helpful in conjunction with
CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
that select the configuration to load explicitly.

Signed-off-by: Julius Werner 
---
   common/image-fit.c | 83 +++---
   1 file changed, 49 insertions(+), 34 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index ac901e131c..006e828b79 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -22,6 +22,7 @@
   DECLARE_GLOBAL_DATA_PTR;
   #endif /* !USE_HOSTCC*/

+#include 
   #include 
   #include 
   #include 
@@ -1576,6 +1577,13 @@ int fit_conf_find_compat(const void *fit, const void 
*fdt)
 kfdt_name);
   continue;
   }
+
+ if (!fit_image_check_comp(fit, kfdt_noffset, IH_COMP_NONE)) {
+ debug("Can't extract compat from \"%s\" (compressed)\n",
+   kfdt_name);
+ continue;
+ }
+


What's this block good for in this patch? Looks like it belongs to 2/2?


This is necessary because I'm removing the (image_type ==
IH_TYPE_FLATDT && !fit_image_check_comp(fit, noffset, IH_COMP_NONE))
check below. Previously, this function would just always hard fail
with compressed FDTs. With this patch, compressed FDTs can be loaded,
but they can't be used for compat string matching -- that's why I need
to add this check here to prevent it. You can still use compressed
FDTs when selecting a configuration explicitly (e.g. bootm
0x100#conf@1). The next patch will then add another feature that
makes it possible to have compat string matching with compressed FDTs.


Oh, ok. Guess I was just surprised that it says "can't extract compat" 
when it tries to check "comp"...







   /*
* Get a pointer to this configuration's fdt.
*/
@@ -1795,11 +1803,12 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
   const char *fit_uname_config;
   const char *fit_base_uname_config;
   const void *fit;
- const void *buf;
+ void *buf;
+ void *loadbuf;
   size_t size;
   int type_ok, os_ok;
- ulong load, data, len;
- uint8_t os;
+ ulong load, load_end, data, len;
+ uint8_t os, comp;
   #ifndef USE_HOSTCC
   uint8_t os_arch;
   #endif
@@ -1895,12 +1904,6 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
   images->os.arch = os_arch;
   #endif

- if (image_type == IH_TYPE_FLATDT &&
- !fit_image_check_comp(fit, noffset, IH_COMP_NONE)) {
- puts("FDT image is compressed");
- return -EPROTONOSUPPORT;
- }
-
   bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL);
   type_ok = fit_image_check_type(fit, noffset, image_type) ||
 fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
@@ -1931,7 +1934,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
   bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);

   /* get image data address and length */
- if (fit_image_get_data_and_size(fit, noffset, &buf, &size)) {
+ if (fit_image_get_data_and_size(fit, noffset,
+ (const void **)&buf, &size)) {
   printf("Could not find %s subimage data!\n", prop_name);
   bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
   return -ENOENT;
@@ -1939,30 +1943,15 @@ int fit_image_load(bootm_headers_t *images, ulong addr,

   #if !defined(USE_HOSTCC) && defined(CONFIG_FIT_IMAGE_POST_PROCESS)
   /* perform any post-processing on the image data */
- board_fit_image_post_process((void **)&buf, &size);
+ board_fit_image_post_process(&buf, &size);
   #endif

   len = (ulong)size;

- /* verify that image data is a proper FDT blob */
- if (image_type == IH_TYPE_FLATDT && fdt_check_header(buf)) {
- puts("Subimage data is not a FDT");
- return -ENOEXEC;
- }
-
   bootstage_mark(bootstage_id + BOOTSTAGE_SUB_GET_DATA_OK);

- /*
-  * Work-around for eldk-4.2 which gives this warning if we try to
-  * cast in the unmap_sysmem() call:
-  * warning: initialization discards qualifiers from pointer target type
-  */
- {
- void *vbuf = (void *)buf;
-
- data = map_to_sysmem(vbuf);
- }
-
+ data = map_to_sysmem(buf);
+ load = data;
  

Re: [U-Boot] [PATCH v2 3/4] watchdog: stm32mp: Add watchdog driver

2019-05-01 Thread Stefan Roese

On 30.04.19 17:26, Patrice Chotard wrote:

This patch adds IWDG (Independent WatchDoG) support for
STM32MP platform.

Signed-off-by: Christophe Kerello 
Signed-off-by: Patrice Chotard 
---

Changes in v2:
- Rename timeout variable in timeout_ms in stm32mp_wdt_start()


Reviewed-by: Stefan Roese 

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


Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.

2019-05-01 Thread Marek Vasut
On 5/1/19 12:06 AM, Atish Patra wrote:
> On 4/30/19 2:42 PM, Marek Vasut wrote:
>> On 4/30/19 10:38 PM, Atish Patra wrote:
>>> On 4/30/19 12:11 PM, Marek Vasut wrote:
 On 4/30/19 8:13 PM, Atish Patra wrote:
> On 4/30/19 2:52 AM, Marek Vasut wrote:
>> On 4/30/19 3:27 AM, Atish Patra wrote:
>>
>> [...]
>>
> Yes. FIT image parsing can be done in that way. However, the idea
> was
> here to load Image.gz directly. Image.gz is default compressed
> Linux
> kernel image format in RISC-V.

 Sigh, and the image header is compressed as well, so there's no
 way to
 identify the image format, right ? And there's no decompressor, so
 the
 dcompressing has to be done by bootloader, which would need some
 sort of
 very smart way of figuring out which exact compression method is
 used ?

>>> Yes. Image.gz is always gunzip. So checking first two bytes is
>>> enough to
>>> confirm that it is a gz file.
>>
>> What happens once people start feeding it more exotic compression
>> methods, like LZ4 or LZO or LZMA for example ?
>>
>
> booti command help will clearly state that it can only boot kernel
> from
> Image or Image.gz.
>
> static char booti_help_text[] =
>    "[addr [initrd[:size]] [fdt]]\n"
> -    "    - boot arm64 Linux Image stored in memory\n"
> +    "    - boot arm64 Linux Image or riscv Linux Image/Image.gz
> stored
> in memory\n"

 Obvious question -- does this Image.gz stuff apply to arm64 ?

>>>
>>> arm64 builds Image.gz but booti for arm64 doesn't use it. I guess
>>> Image.gz can be used in FIT image for ARM64 but I am not sure which
>>> platform actually uses it.
>>>
>>> This patch only enables support for RISC-V.
>>
>> Can't this be made generic ?
>>
> 
> I think so if I just move the gzip detection and decompression code to
> cmd/booti.c.
> 
> I will update the v3 patch with this.

Nice, thanks.

But since you're basically implementing file(1)-lite, I wonder whether
there isn't similar code somewhere in u-boot already.

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


Re: [U-Boot] [PATCH 1/5] mtd: spi-nor: fix page program issue when using spi-mem driver

2019-05-01 Thread Shyam Saini
Hi Weijie,

> Some SPI controllers can't write nor->page_size bytes in a single step
> because their TX FIFO is too small, but when that happens we should
> make sure a WRITE_EN command before each write access and READ_SR command
> after each write access is issued.
>
> We should allow nor->write() to return a size that is smaller than the
> requested write size to gracefully handle this case.
>
> Also, the spi_nor_write_data() should return the actual number of bytes
> that were written during the spi_mem_exec_op() operation.
>
> This patch is a combination of two commits backported from kernel:
>
>   commit 630d6bd8a3b4 ("mtd: spi-nor: Support controllers with limit ...")
>   commit 3baa8ec88c2f ("mtd: devices: m25p80: Make sure WRITE_EN is ...")
>
> Cc: Vignesh R 
> Signed-off-by: Weijie Gao 
> ---
>  drivers/mtd/spi/spi-nor-core.c | 27 ---
>  1 file changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index c4e2f6a..1acff74 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -116,7 +116,6 @@ static ssize_t spi_nor_write_data(struct spi_nor *nor, 
> loff_t to, size_t len,
>SPI_MEM_OP_ADDR(nor->addr_width, to, 1),
>SPI_MEM_OP_NO_DUMMY,
>SPI_MEM_OP_DATA_OUT(len, buf, 1));
> -   size_t remaining = len;
> int ret;
>
> /* get transfer protocols. */
> @@ -127,22 +126,16 @@ static ssize_t spi_nor_write_data(struct spi_nor *nor, 
> loff_t to, size_t len,
> if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
> op.addr.nbytes = 0;
>
> -   while (remaining) {
> -   op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
> -   ret = spi_mem_adjust_op_size(nor->spi, &op);
> -   if (ret)
> -   return ret;
> -
> -   ret = spi_mem_exec_op(nor->spi, &op);
> -   if (ret)
> -   return ret;
> +   ret = spi_mem_adjust_op_size(nor->spi, &op);
> +   if (ret)
> +   return ret;
> +   op.data.nbytes = len < op.data.nbytes ? len : op.data.nbytes;
>
> -   op.addr.val += op.data.nbytes;
> -   remaining -= op.data.nbytes;
> -   op.data.buf.out += op.data.nbytes;
> -   }
> +   ret = spi_mem_exec_op(nor->spi, &op);
> +   if (ret)
> +   return ret;
>
> -   return len;
> +   return op.data.nbytes;
>  }
>
>  /*
> @@ -1101,10 +1094,6 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t 
> to, size_t len,
> goto write_err;
> *retlen += written;
> i += written;
> -   if (written != page_remain) {
> -   ret = -EIO;
> -   goto write_err;
> -   }
> }
>

I've tested it on Zynq MicroZed board and it is working, so

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


[U-Boot] [PATCH 1/3] net: mscc: luton: Update network driver for pcb90

2019-05-01 Thread Horatiu Vultur
Update Luton network driver to have support also for pcb90. The pcb90
has 24 ports from which 12 ports are connected to SerDes6G.

Signed-off-by: Horatiu Vultur 
---
 drivers/net/mscc_eswitch/Makefile   |   2 +-
 drivers/net/mscc_eswitch/luton_switch.c | 415 
 2 files changed, 258 insertions(+), 159 deletions(-)

diff --git a/drivers/net/mscc_eswitch/Makefile 
b/drivers/net/mscc_eswitch/Makefile
index 9c208d1..02f39a7 100644
--- a/drivers/net/mscc_eswitch/Makefile
+++ b/drivers/net/mscc_eswitch/Makefile
@@ -1,6 +1,6 @@
 
 obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_xfer.o 
mscc_mac_table.o
-obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_miim.o mscc_xfer.o 
mscc_mac_table.o
+obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_xfer.o mscc_mac_table.o
 obj-$(CONFIG_MSCC_JR2_SWITCH) += jr2_switch.o mscc_xfer.o
 obj-$(CONFIG_MSCC_SERVALT_SWITCH) += servalt_switch.o mscc_xfer.o
 obj-$(CONFIG_MSCC_SERVAL_SWITCH) += serval_switch.o mscc_xfer.o 
mscc_mac_table.o
diff --git a/drivers/net/mscc_eswitch/luton_switch.c 
b/drivers/net/mscc_eswitch/luton_switch.c
index 6667614..94852b0 100644
--- a/drivers/net/mscc_eswitch/luton_switch.c
+++ b/drivers/net/mscc_eswitch/luton_switch.c
@@ -15,10 +15,21 @@
 #include 
 #include 
 
-#include "mscc_miim.h"
 #include "mscc_xfer.h"
 #include "mscc_mac_table.h"
 
+#define GCB_MIIM_MII_STATUS0x0
+#defineGCB_MIIM_STAT_BUSY  BIT(3)
+#define GCB_MIIM_MII_CMD   0x8
+#defineGCB_MIIM_MII_CMD_OPR_WRITE  BIT(1)
+#defineGCB_MIIM_MII_CMD_OPR_READ   BIT(2)
+#defineGCB_MIIM_MII_CMD_WRDATA(x)  ((x) << 4)
+#defineGCB_MIIM_MII_CMD_REGAD(x)   ((x) << 20)
+#defineGCB_MIIM_MII_CMD_PHYAD(x)   ((x) << 25)
+#defineGCB_MIIM_MII_CMD_VLDBIT(31)
+#define GCB_MIIM_DATA  0xC
+#defineGCB_MIIM_DATA_ERROR (0x2 << 16)
+
 #define ANA_PORT_VLAN_CFG(x)   (0x00 + 0x80 * (x))
 #defineANA_PORT_VLAN_CFG_AWARE_ENA BIT(20)
 #defineANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18)
@@ -136,61 +147,53 @@
 #define PGID_UNICAST   29
 #define PGID_SRC   80
 
-enum luton_target {
-   PORT0,
-   PORT1,
-   PORT2,
-   PORT3,
-   PORT4,
-   PORT5,
-   PORT6,
-   PORT7,
-   PORT8,
-   PORT9,
-   PORT10,
-   PORT11,
-   PORT12,
-   PORT13,
-   PORT14,
-   PORT15,
-   PORT16,
-   PORT17,
-   PORT18,
-   PORT19,
-   PORT20,
-   PORT21,
-   PORT22,
-   PORT23,
-   SYS,
+static const char * const regs_names[] = {
+   "port0", "port1", "port2", "port3", "port4", "port5", "port6", "port7",
+   "port8", "port9", "port10", "port11", "port12", "port13", "port14",
+   "port15", "port16", "port17", "port18", "port19", "port20", "port21",
+   "port22", "port23",
+   "sys", "ana", "rew", "gcb", "qs", "hsio",
+};
+
+#define REGS_NAMES_COUNT ARRAY_SIZE(regs_names) + 1
+#define MAX_PORT 24
+
+enum luton_ctrl_regs {
+   SYS = MAX_PORT,
ANA,
REW,
GCB,
QS,
-   HSIO,
-   TARGET_MAX,
+   HSIO
 };
 
-#define MAX_PORT (PORT23 - PORT0 + 1)
+#define MIN_INT_PORT   0
+#define PORT10 10
+#define PORT11 11
+#define MAX_INT_PORT   12
+#define MIN_EXT_PORT   MAX_INT_PORT
+#define MAX_EXT_PORT   MAX_PORT
 
-#define MIN_INT_PORT PORT0
-#define MAX_INT_PORT (PORT11 - PORT0  + 1)
-#define MIN_EXT_PORT PORT12
-#define MAX_EXT_PORT MAX_PORT
+#define LUTON_MIIM_BUS_COUNT 2
 
-enum luton_mdio_target {
-   MIIM,
-   TARGET_MDIO_MAX,
+struct luton_phy_port_t {
+   size_t phy_addr;
+   struct mii_dev *bus;
+   u8 serdes_index;
+   u8 phy_mode;
 };
 
-enum luton_phy_id {
-   INTERNAL,
-   EXTERNAL,
-   NUM_PHY,
+struct luton_private {
+   void __iomem *regs[REGS_NAMES_COUNT];
+   struct mii_dev *bus[LUTON_MIIM_BUS_COUNT];
+   struct luton_phy_port_t ports[MAX_PORT];
 };
 
-struct luton_private {
-   void __iomem *regs[TARGET_MAX];
-   struct mii_dev *bus[NUM_PHY];
+struct mscc_miim_dev {
+   void __iomem *regs;
+   phys_addr_t miim_base;
+   unsigned long miim_size;
+   struct mii_dev *bus;
 };
 
 static const unsigned long luton_regs_qs[] = {
@@ -207,53 +210,85 @@ static const unsigned long luton_regs_ana_table[] = {
[MSCC_ANA_TABLES_MACACCESS] = 0x11b8,
 };
 
-static struct mscc_miim_dev miim[NUM_PHY];
+static struct mscc_miim_dev miim[LUTON_MIIM_BUS_COUNT];
+static int miim_count = -1;
 
-static struct mii_dev *luton_mdiobus_init(struct udevice *dev,
- int mdiobus_id)
+static int mscc_miim_wait_ready(struct mscc_miim_dev *miim)
+{
+   return wait_f

[U-Boot] [PATCH 0/3] Update Luton network driver

2019-05-01 Thread Horatiu Vultur
Update Luton network driver to add support for all the ports
on pcb90. The existing support is only for first 12 ports, with
this patch adds support for another 12 ports.

This patch series is based on u-boot-mips/master.

Horatiu Vultur (3):
  net: mscc: luton: Update network driver for pcb90
  board: mscc: luton: Update MSCC Luton board
  net: mscc: ocelot: Update DTS for Luton pcb90

 arch/mips/dts/luton_pcb090.dts  | 228 ++
 arch/mips/dts/luton_pcb091.dts  | 132 ++
 arch/mips/dts/mscc,luton.dtsi   | 126 ++
 board/mscc/luton/luton.c|  13 +-
 drivers/net/mscc_eswitch/Makefile   |   2 +-
 drivers/net/mscc_eswitch/luton_switch.c | 415 
 include/dt-bindings/mscc/luton_data.h   |  17 ++
 7 files changed, 576 insertions(+), 357 deletions(-)
 create mode 100644 include/dt-bindings/mscc/luton_data.h

-- 
2.7.4

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


[U-Boot] [PATCH 2/3] board: mscc: luton: Update MSCC Luton board

2019-05-01 Thread Horatiu Vultur
Implement method board_phy_config to configure the external phys
on the pcb90.

Signed-off-by: Horatiu Vultur 
---
 board/mscc/luton/luton.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/board/mscc/luton/luton.c b/board/mscc/luton/luton.c
index 807c717..114f7fd 100644
--- a/board/mscc/luton/luton.c
+++ b/board/mscc/luton/luton.c
@@ -6,8 +6,7 @@
 #include 
 #include 
 #include 
-
-DECLARE_GLOBAL_DATA_PTR;
+#include 
 
 enum {
BOARD_TYPE_PCB090 = 0xAABBCD00,
@@ -36,6 +35,16 @@ int board_early_init_r(void)
return 0;
 }
 
+int board_phy_config(struct phy_device *phydev)
+{
+   phy_write(phydev, 0, 31, 0x10);
+   phy_write(phydev, 0, 18, 0x80A0);
+   while (phy_read(phydev, 0, 18) & 0x8000)
+   ;
+   phy_write(phydev, 0, 31, 0);
+   return 0;
+}
+
 static void do_board_detect(void)
 {
u32 chipid = (readl(BASE_DEVCPU_GCB + CHIP_ID) >> 12) & 0x;
-- 
2.7.4

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


[U-Boot] [PATCH 3/3] net: mscc: ocelot: Update DTS for Luton pcb90

2019-05-01 Thread Horatiu Vultur
Update device tree for luton to add support for luton pcb90.
This pcb has 24 ports from which 12 ports are connected to
SerDes6G.

Signed-off-by: Horatiu Vultur 
---
 arch/mips/dts/luton_pcb090.dts| 228 +++---
 arch/mips/dts/luton_pcb091.dts| 132 +---
 arch/mips/dts/mscc,luton.dtsi | 126 +++
 include/dt-bindings/mscc/luton_data.h |  17 +++
 4 files changed, 307 insertions(+), 196 deletions(-)
 create mode 100644 include/dt-bindings/mscc/luton_data.h

diff --git a/arch/mips/dts/luton_pcb090.dts b/arch/mips/dts/luton_pcb090.dts
index fe457ba..ea3e3b7 100644
--- a/arch/mips/dts/luton_pcb090.dts
+++ b/arch/mips/dts/luton_pcb090.dts
@@ -5,6 +5,7 @@
 
 /dts-v1/;
 #include "mscc,luton.dtsi"
+#include 
 
 / {
model = "Luton26 PCB090 Reference Board";
@@ -57,52 +58,195 @@
 
 &mdio0 {
status = "okay";
-};
-
-&port0 {
-   phy-handle = <&phy0>;
-};
-
-&port1 {
-   phy-handle = <&phy1>;
-};
-
-&port2 {
-   phy-handle = <&phy2>;
-};
-
-&port3 {
-   phy-handle = <&phy3>;
-};
-
-&port4 {
-   phy-handle = <&phy4>;
-};
-
-&port5 {
-   phy-handle = <&phy5>;
-};
-
-&port6 {
-   phy-handle = <&phy6>;
-};
-
-&port7 {
-   phy-handle = <&phy7>;
-};
 
-&port8 {
-   phy-handle = <&phy8>;
+   phy0: ethernet-phy@0 {
+   reg = <0>;
+   };
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+   phy2: ethernet-phy@2 {
+   reg = <2>;
+   };
+   phy3: ethernet-phy@3 {
+   reg = <3>;
+   };
+   phy4: ethernet-phy@4 {
+   reg = <4>;
+   };
+   phy5: ethernet-phy@5 {
+   reg = <5>;
+   };
+   phy6: ethernet-phy@6 {
+   reg = <6>;
+   };
+   phy7: ethernet-phy@7 {
+   reg = <7>;
+   };
+   phy8: ethernet-phy@8 {
+   reg = <8>;
+   };
+   phy9: ethernet-phy@9 {
+   reg = <9>;
+   };
+   phy10: ethernet-phy@10 {
+   reg = <10>;
+   };
+   phy11: ethernet-phy@11 {
+   reg = <11>;
+   };
 };
 
-&port9 {
-   phy-handle = <&phy9>;
-};
+&mdio1 {
+   status = "okay";
 
-&port10 {
-   phy-handle = <&phy10>;
+   phy12: ethernet-phy@12 {
+   reg = <0>;
+   };
+   phy13: ethernet-phy@13 {
+   reg = <1>;
+   };
+   phy14: ethernet-phy@14 {
+   reg = <2>;
+   };
+   phy15: ethernet-phy@15 {
+   reg = <3>;
+   };
+   phy16: ethernet-phy@16 {
+   reg = <4>;
+   };
+   phy17: ethernet-phy@17 {
+   reg = <5>;
+   };
+   phy18: ethernet-phy@18 {
+   reg = <6>;
+   };
+   phy19: ethernet-phy@19 {
+   reg = <7>;
+   };
+   phy20: ethernet-phy@20 {
+   reg = <8>;
+   };
+   phy21: ethernet-phy@21 {
+   reg = <9>;
+   };
+   phy22: ethernet-phy@22 {
+   reg = <10>;
+   };
+   phy23: ethernet-phy@23 {
+   reg = <11>;
+   };
 };
 
-&port11 {
-   phy-handle = <&phy11>;
+&switch {
+   ethernet-ports {
+   port0: port@0 {
+   reg = <0>;
+   phy-handle = <&phy0>;
+   };
+   port1: port@1 {
+   reg = <1>;
+   phy-handle = <&phy1>;
+   };
+   port2: port@2 {
+   reg = <2>;
+   phy-handle = <&phy2>;
+   };
+   port3: port@3 {
+   reg = <3>;
+   phy-handle = <&phy3>;
+   };
+   port4: port@4 {
+   reg = <4>;
+   phy-handle = <&phy4>;
+   };
+   port5: port@5 {
+   reg = <5>;
+   phy-handle = <&phy5>;
+   };
+   port6: port@6 {
+   reg = <6>;
+   phy-handle = <&phy6>;
+   };
+   port7: port@7 {
+   reg = <7>;
+   phy-handle = <&phy7>;
+   };
+   port8: port@8 {
+   reg = <8>;
+   phy-handle = <&phy8>;
+   };
+   port9: port@9 {
+   reg = <9>;
+   phy-handle = <&phy9>;
+   };
+   port10: port@10 {
+   reg = <10>;
+   phy-handle = <&phy10>;
+   };
+   port11: port@11 {
+   reg = <11>;
+   phy-handle = <&phy11>;
+   };
+   port12: port@12 {
+   reg = <12>;
+   phy-handle = <&phy12>;
+   phys = <&serdes_hsio 12 SERDES6G(1) PHY_MODE_QSG

Re: [U-Boot] Pull request: u-boot-imx u-boot-imx-20190426

2019-05-01 Thread Tom Rini
On Tue, Apr 30, 2019 at 06:09:59PM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> next chunk of patches, another big chunk will follow. Please pull from
> u-boot-imx, thanks !
> 
> Travis:

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 2/2] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.

2019-05-01 Thread Tom Rini
On Mon, Apr 29, 2019 at 04:12:30PM -0700, Vagrant Cascadian wrote:

> Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig.
> 
> Signed-off-by: Vagrant Cascadian 

Reviewed-by: Tom Rini 

-- 
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 02/50] binman: Don't show image-skip message by default

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
>
> This message is not very important since it is simply indicating that the
> user's instructions are being followed. Only show it when the verbosity
> level is above the default.
>
> Also drop the unnecessary extra newline on this message, which causes two
> line breaks.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Update commit message to mention dropping the \n
> - Update testSelectImage() to test in normal and verbose modes
>
>  tools/binman/control.py |  4 ++--
>  tools/binman/ftest.py   | 26 +++---
>  2 files changed, 21 insertions(+), 9 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 05/50] cros_ec: Use a hyphen in the uclass name

2019-05-01 Thread Bin Meng
Hi Simon,

On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
>
> Device-tree rules require that aliases use a hyphen rather than a
> underscore. Update the uclass name to fit with this.
>
> This allows device-tree aliases to be used to refer to cros-ec devices,
> for example:
>
> aliases {
> cros-ec0 = &ec;
> cros-ec1 = &pd;
> };

Thanks for adding the explanation here. But I was wondering since this
is required by DT rules for the aliases node, do we have to require
all UCLASS_DRIVERs to have name with hyphen instead of underscore?

>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Update the commit message to explain the implications on aliases
>
>  drivers/misc/cros_ec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2 06/50] spl: Allow sandbox to build a device-tree file

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
>
> At present only OF_SEPARATE is considered valid for building a device-tree
> file in SPL. However sandbox uses OF_HOSTFILE instead. Update the logic to
> handle this and make it easier to understand.
>
> Note that the new logic is not quite the same as the old logic. It was
> previously assumed that checking for:
>
>$(CONFIG_$(SPL_TPL_)OF_CONTROL)
>$(CONFIG_OF_SEPARATE)
>$(CONFIG_$(SPL_TPL_)OF_PLATDATA)
>
> producing 'yy' meant that the first two were 'y' and the last was empty.
> Strictly speaking it would be possible for any two of the three to be 'y'
> and still yield the same result. However, that was not the intention of
> the new logic, since OF_PLATDATA always ensures that no device-tree file
> is included. So in effect the new logic is the same, with the addition of
> OF_HOSTFILE as an option for OP_SEPARATE.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add a better explanation of the logic change, in the commit message
>
>  scripts/Makefile.spl | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2 07/50] binman: Allow sections to have an offset

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
>
> At present sections are always placed automatically. Even if an 'offset'
> property is provided it is ignored. Update the logic to support an offset
> for sections.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Fix map output when section offset is not set (make it 0)
> - Add a test for sections with offsets
>
>  tools/binman/README   |  7 +
>  tools/binman/bsection.py  |  9 +++---
>  tools/binman/etype/section.py |  3 +-
>  tools/binman/ftest.py | 18 
>  tools/binman/test/101_sections_offset.dts | 35 +++
>  5 files changed, 67 insertions(+), 5 deletions(-)
>  create mode 100644 tools/binman/test/101_sections_offset.dts
>

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


[U-Boot] Booting imx_4.14.98_2.0.0_ga on i.MX8QM MEK Board

2019-05-01 Thread Marcel Ziswiler
Hi Peng, Stefano and Fabio

We are currently trying to boot the Linux kernel from NXP's downstream
Linux BSP 4.14.98_2.0.0_ga with mainline U-Boot. However, that
currently seems to crash as follows:

...
[1.563380] 5a09.serial: ttyLP3 at MMIO 0x5a090010 (irq = 72,
base_baud = 500) is a FSL_LPUART
[1.575723] arm-smmu 5140.iommu: probing hardware
configuration...
[1.582278] arm-smmu 5140.iommu: SMMUv2 with:
[1.586993] Synchronous External Abort: synchronous external abort
(0x96000210) at 0x0fa40020
[1.596233] Internal error: : 96000210 [#1] PREEMPT SMP
[1.601458] Modules linked in:
[1.604521] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.14.98-
imx_4.14.98_2.0.0_ga+g5d6cbea #1
[1.613132] Hardware name: Freescale i.MX8QM MEK (DT)
[1.618180] task: 8008f6c98000 task.stack: 08068000
[1.624119] PC is at arm_smmu_device_probe+0x334/0xc58
[1.629256] LR is at arm_smmu_device_probe+0x334/0xc58
[1.634399] pc : [] lr : []
pstate: 4045
[1.641792] sp : 0806bbf0
[1.645100] x29: 0806bbf0 x28: 094dab58
[1.650417] x27: 0007 x26: 093b046c
[1.655733] x25:  x24: 
[1.661050] x23: 0fa40020 x22: 8008f72e3410
[1.666367] x21: 0021 x20: 0fa4
[1.671684] x19: 8008f78e3218 x18: 0010
[1.677000] x17: 0001 x16: 
[1.682308] x15:  x14: 896a5547
[1.687625] x13: 096a x12: 094f8df8
[1.692942] x11: 086373a0 x10: 0806b850
[1.698259] x9 : 0006 x8 : 203276554d4d5320
[1.703575] x7 : 3a756d6d6f692e30 x6 : 00e4
[1.708892] x5 :  x4 : 
[1.714209] x3 :  x2 : 09512f68
[1.719526] x1 : 8008f6c98000 x0 : 0025
[1.724845] Process swapper/0 (pid: 1, stack limit =
0x08068000)
[1.731545] Call trace:
[1.733994] Exception stack(0x0806bab0 to
0x0806bbf0)
[1.740441] baa0:   0025
8008f6c98000
[1.748275] bac0: 09512f68  

[1.756111] bae0: 00e4 3a756d6d6f692e30 203276554d4d5320
0006
[1.763947] bb00: 0806b850 086373a0 094f8df8
096a
[1.771783] bb20: 896a5547  
0001
[1.779619] bb40: 0010 8008f78e3218 0fa4
0021
[1.787458] bb60: 8008f72e3410 0fa40020 

[1.795292] bb80: 093b046c 0007 094dab58
0806bbf0
[1.803130] bba0: 0865108c 0806bbf0 0865108c
4045
[1.810964] bbc0: 0002  

[1.818799] bbe0: 0806bbf0 0865108c
[1.823678] [] arm_smmu_device_probe+0x334/0xc58
[1.829867] [] platform_drv_probe+0x58/0xb8
[1.835612] [] driver_probe_device+0x210/0x2d0
[1.841624] [] __driver_attach+0xbc/0xc0
[1.847117] [] bus_for_each_dev+0x4c/0x98
[1.852691] [] driver_attach+0x20/0x28
[1.858001] [] bus_add_driver+0x1b8/0x228
[1.863575] [] driver_register+0x60/0xf8
[1.869057] []
__platform_driver_register+0x40/0x48
[1.875502] [] arm_smmu_driver_init+0x1c/0x24
[1.881424] [] do_one_initcall+0x38/0x128
[1.887004] [] kernel_init_freeable+0x188/0x22c
[1.893102] [] kernel_init+0x10/0x108
[1.898325] [] ret_from_fork+0x10/0x18
[1.903637] Code: 911ac021 1a9f17e2 11000442 94020db0 (b94002f7)
[1.909748] ---[ end trace c4668f185ae22c3f ]---
[1.914394] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[1.914394]
[1.923532] SMP: stopping secondary CPUs
[1.927458] Kernel Offset: disabled
[1.930950] CPU features: 0x180200c
[1.934441] Memory Limit: none
[1.937501] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x000b
[1.937501]

Does any of you know what exactly could be going on?

BTW: The exact same crash is observed on Apalis iMX8 as well, while
both the i.MX8QXP MEK as well as Colibri iMX8QXP boot that same
downstream Linux kernel just fine. Must be something i.MX 8QuadMax
specific...

Cheers

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


Re: [U-Boot] [PATCH v2 17/50] x86: broadwell: Allow SDRAM init from SPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present, for broadwell, SDRAM is always set up in U-Boot proper since
> the 64-bit mode (which uses SDRAM init in SPL) is not supported.
>
> Update the code to allow SDRAM init in SPL instead so that U-Boot proper
> can be loaded into SDRAM and run from there. This allows U-Boot to be
> compressed to reduce space, since it is not necessary to run it directly
> from flash. It could later allow us to support 64-bit U-Boot on broadwell.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Update commit message to make it clear this patch is just for broadwell
> - Bring in sdram_console_tx_byte() to allow debugging
>
>  arch/x86/cpu/broadwell/Makefile  |   2 +-
>  arch/x86/cpu/broadwell/northbridge.c | 100 +++
>  arch/x86/cpu/broadwell/sdram.c   |  93 -
>  3 files changed, 101 insertions(+), 94 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 20/50] x86: Add support for starting from SPL/TPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> When a previous phase of U-Boot has run we need to adjust the init of
> subsequent states to avoid messing up the CPU state.
>
> Add a new version of the start logic for SPL, when it boots from TPL
> (start_from tpl.c) and a new version for U-Boot when it boots from SPL.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add xorl to TPL code also
> - Update comments in start_from_tpl to correctly explain SPL state
>
>  arch/x86/Makefile | 12 ++
>  arch/x86/cpu/Makefile | 15 +++-
>  arch/x86/cpu/start_from_spl.S | 71 +++
>  arch/x86/cpu/start_from_tpl.S | 49 
>  4 files changed, 146 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/cpu/start_from_spl.S
>  create mode 100644 arch/x86/cpu/start_from_tpl.S
>

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


Re: [U-Boot] [PATCH v2 01/10] rockchip: enable DEBUG_UART_BOARD_INIT by default

2019-05-01 Thread Philipp Tomsich
> All Rockchip SoCs use DEBUG_UART_BOARD_INIT to init per board
> UART IOMUX, enable it by default.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/Kconfig   | 1 +
>  arch/arm/mach-rockchip/Kconfig | 4 
>  2 files changed, 1 insertion(+), 4 deletions(-)
> 

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 02/10] rockchip; kylin-rk3036: enabl DEBUG UART

2019-05-01 Thread Philipp Tomsich
> Enable debug uart for kylin board in defconfig.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  configs/kylin-rk3036_defconfig | 4 
>  1 file changed, 4 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 04/10] rockchip: rk3188: add board_debug_uart_init()

2019-05-01 Thread Philipp Tomsich
> Use board_debug_uart_init() for UART iomux init instead of
> do it in board_init_f, and move the function to soc file so
> that we can find all the soc/board setting in soc file and
> use a common board file.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/mach-rockchip/rk3188-board-spl.c | 28 +-
>  arch/arm/mach-rockchip/rk3188/Makefile|  1 +
>  arch/arm/mach-rockchip/rk3188/rk3188.c| 36 +++
>  3 files changed, 38 insertions(+), 27 deletions(-)
>  create mode 100644 arch/arm/mach-rockchip/rk3188/rk3188.c
> 

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 05/10] rockchip: rk322x: move board_debug_uart_init() to rk322x.c

2019-05-01 Thread Philipp Tomsich
> Move the function to soc file so
> that we can find all the soc/board setting in soc file and
> use a common board file later for all rockchip SoCs.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/mach-rockchip/rk322x-board-spl.c | 44 ++-
>  arch/arm/mach-rockchip/rk322x-board.c | 30 +---
>  arch/arm/mach-rockchip/rk322x/Makefile|  2 +-
>  arch/arm/mach-rockchip/rk322x/rk322x.c| 44 +++
>  4 files changed, 48 insertions(+), 72 deletions(-)
>  create mode 100644 arch/arm/mach-rockchip/rk322x/rk322x.c
> 

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 06/10] rockchip: rk3288: use grf structure to access soc_con2

2019-05-01 Thread Philipp Tomsich
> Prefer to use structure to access register if we can.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/mach-rockchip/rk3288/rk3288.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 

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 08/10] rockchip: rk3368: move board_debug_uart_init() to rk3368.c

2019-05-01 Thread Philipp Tomsich
> Move the function to soc file so
> that we can find all the soc/board setting in soc file and
> use a common board file later for all rockchip SoCs.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> Tested-by: Andy Yan 
> ---
> 
>  arch/arm/mach-rockchip/rk3368-board-spl.c |  8 --
>  arch/arm/mach-rockchip/rk3368-board-tpl.c | 33 +--
>  arch/arm/mach-rockchip/rk3368/rk3368.c| 31 +
>  3 files changed, 32 insertions(+), 40 deletions(-)
> 

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 03/10] rockchip: rk3036: add board_debug_uart_init()

2019-05-01 Thread Philipp Tomsich
> Use board_debug_uart_init() for UART iomux init instead of
> do it in board_init_f, and move the function to soc file so
> that we can find all the soc/board setting in soc file and
> use a common board file.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/mach-rockchip/rk3036-board-spl.c | 20 +---
>  arch/arm/mach-rockchip/rk3036/Makefile|  1 +
>  arch/arm/mach-rockchip/rk3036/rk3036.c| 39 +++
>  3 files changed, 41 insertions(+), 19 deletions(-)
>  create mode 100644 arch/arm/mach-rockchip/rk3036/rk3036.c
> 

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 10/10] rockchip: rk3399: add board_debug_uart_init()

2019-05-01 Thread Philipp Tomsich
> Use board_debug_uart_init() for UART iomux init instead of
> do it in board_init_f, and move the function to soc file so
> that we can find all the soc/board setting in soc file and
> use a common board file for all rockchip SoCs later.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/mach-rockchip/rk3399-board-spl.c | 50 +--
>  arch/arm/mach-rockchip/rk3399/rk3399.c| 50 +++
>  2 files changed, 51 insertions(+), 49 deletions(-)
> 

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 07/10] rockchip: rk3288: add board_debug_uart_init()

2019-05-01 Thread Philipp Tomsich
> Use board_debug_uart_init() for UART iomux init instead of
> do it in board_init_f, and move the function to soc file so
> that we can find all the soc/board setting in soc file and
> use a common board file for all rockchip SoCs later.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/mach-rockchip/rk3288-board-spl.c | 12 ++--
>  arch/arm/mach-rockchip/rk3288-board-tpl.c | 16 ++--
>  arch/arm/mach-rockchip/rk3288/rk3288.c| 13 +
>  3 files changed, 17 insertions(+), 24 deletions(-)
> 

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 09/10] rockchip: rk3399: use grf structure to access reg

2019-05-01 Thread Philipp Tomsich
> Prefer to use structure to access register if we could.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> Tested-by: Andy Yan 
> ---
> 
>  arch/arm/mach-rockchip/rk3399/rk3399.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 

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 3/3] rockchip: correct ARCH_SOC name

2019-05-01 Thread Philipp Tomsich
> The ARCH_SOC name default as 'rockchip' and we put all the
> header file in 'arch/arm/include/asm/arch-rockchip/', but
> the 'rockchip' is not the SOC name, let's correct it after
> we update all the source file.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsiich 
> ---
> 
>  arch/arm/mach-rockchip/rk3036/Kconfig | 2 +-
>  arch/arm/mach-rockchip/rk3128/Kconfig | 2 +-
>  arch/arm/mach-rockchip/rk3188/Kconfig | 2 +-
>  arch/arm/mach-rockchip/rk322x/Kconfig | 2 +-
>  arch/arm/mach-rockchip/rk3288/Kconfig | 2 +-
>  arch/arm/mach-rockchip/rk3328/Kconfig | 2 +-
>  arch/arm/mach-rockchip/rk3368/Kconfig | 2 +-
>  arch/arm/mach-rockchip/rk3399/Kconfig | 2 +-
>  arch/arm/mach-rockchip/rv1108/Kconfig | 2 +-
>  9 files changed, 9 insertions(+), 9 deletions(-)
> 

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 2/3] rockchip: use 'arch-rockchip' as header file path

2019-05-01 Thread Philipp Tomsich
> Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common
> header file path, so that we can get the correct path directly.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  .../include/asm/arch-rockchip/ddr_rk3188.h|  2 +-
>  arch/arm/mach-rockchip/Kconfig|  2 +-
>  arch/arm/mach-rockchip/boot_mode.c|  2 +-
>  arch/arm/mach-rockchip/bootrom.c  |  4 ++--
>  arch/arm/mach-rockchip/rk3036-board-spl.c | 12 +--
>  arch/arm/mach-rockchip/rk3036-board.c | 10 +-
>  arch/arm/mach-rockchip/rk3036/clk_rk3036.c|  4 ++--
>  arch/arm/mach-rockchip/rk3036/sdram_rk3036.c  | 12 +--
>  arch/arm/mach-rockchip/rk3036/syscon_rk3036.c |  2 +-
>  arch/arm/mach-rockchip/rk3128-board.c | 10 +-
>  arch/arm/mach-rockchip/rk3128/clk_rk3128.c|  4 ++--
>  arch/arm/mach-rockchip/rk3128/syscon_rk3128.c |  2 +-
>  arch/arm/mach-rockchip/rk3188-board-spl.c | 16 +++
>  arch/arm/mach-rockchip/rk3188-board.c | 10 +-
>  arch/arm/mach-rockchip/rk3188/clk_rk3188.c|  4 ++--
>  arch/arm/mach-rockchip/rk3188/syscon_rk3188.c |  2 +-
>  arch/arm/mach-rockchip/rk322x-board-spl.c | 12 +--
>  arch/arm/mach-rockchip/rk322x-board.c | 10 +-
>  arch/arm/mach-rockchip/rk322x/clk_rk322x.c|  4 ++--
>  arch/arm/mach-rockchip/rk322x/syscon_rk322x.c |  2 +-
>  arch/arm/mach-rockchip/rk3288-board-spl.c | 20 +--
>  arch/arm/mach-rockchip/rk3288-board-tpl.c | 14 ++---
>  arch/arm/mach-rockchip/rk3288-board.c | 12 +--
>  arch/arm/mach-rockchip/rk3288/clk_rk3288.c|  4 ++--
>  arch/arm/mach-rockchip/rk3288/rk3288.c|  2 +-
>  arch/arm/mach-rockchip/rk3288/syscon_rk3288.c |  2 +-
>  arch/arm/mach-rockchip/rk3328/clk_rk3328.c|  4 ++--
>  arch/arm/mach-rockchip/rk3328/rk3328.c|  2 +-
>  arch/arm/mach-rockchip/rk3328/syscon_rk3328.c |  2 +-
>  arch/arm/mach-rockchip/rk3368-board-spl.c | 10 +-
>  arch/arm/mach-rockchip/rk3368-board-tpl.c | 12 +--
>  arch/arm/mach-rockchip/rk3368/clk_rk3368.c|  4 ++--
>  arch/arm/mach-rockchip/rk3368/rk3368.c|  6 +++---
>  arch/arm/mach-rockchip/rk3368/syscon_rk3368.c |  2 +-
>  arch/arm/mach-rockchip/rk3399-board-spl.c | 12 +--
>  arch/arm/mach-rockchip/rk3399-board.c |  2 +-
>  arch/arm/mach-rockchip/rk3399/clk_rk3399.c|  4 ++--
>  arch/arm/mach-rockchip/rk3399/rk3399.c|  2 +-
>  arch/arm/mach-rockchip/rk3399/syscon_rk3399.c |  2 +-
>  arch/arm/mach-rockchip/rk_timer.c |  2 +-
>  arch/arm/mach-rockchip/rv1108/clk_rv1108.c|  4 ++--
>  arch/arm/mach-rockchip/rv1108/syscon_rv1108.c |  2 +-
>  arch/arm/mach-rockchip/sdram_common.c |  2 +-
>  board/elgin/elgin_rv1108/elgin_rv1108.c   |  4 ++--
>  board/rockchip/evb_rk3036/evb_rk3036.c|  4 ++--
>  board/rockchip/evb_rk3229/evb_rk3229.c|  2 +-
>  board/rockchip/evb_rk3399/evb-rk3399.c|  2 +-
>  board/rockchip/evb_rv1108/evb_rv1108.c|  4 ++--
>  board/rockchip/kylin_rk3036/kylin_rk3036.c|  4 ++--
>  board/rockchip/sheep_rk3368/sheep_rk3368.c|  4 ++--
>  .../lion_rk3368/lion_rk3368.c |  6 +++---
>  .../puma_rk3399/puma-rk3399.c | 10 +-
>  board/vamrs/rock960_rk3399/rock960-rk3399.c   |  2 +-
>  cmd/rockusb.c |  2 +-
>  drivers/clk/rockchip/clk_rk3036.c |  6 +++---
>  drivers/clk/rockchip/clk_rk3128.c |  6 +++---
>  drivers/clk/rockchip/clk_rk3188.c |  8 
>  drivers/clk/rockchip/clk_rk322x.c |  6 +++---
>  drivers/clk/rockchip/clk_rk3288.c |  8 
>  drivers/clk/rockchip/clk_rk3328.c |  8 
>  drivers/clk/rockchip/clk_rk3368.c |  6 +++---
>  drivers/clk/rockchip/clk_rk3399.c |  6 +++---
>  drivers/clk/rockchip/clk_rv1108.c |  6 +++---
>  drivers/gpio/rk_gpio.c|  3 ++-
>  drivers/i2c/rk_i2c.c  |  6 +++---
>  drivers/mmc/rockchip_dw_mmc.c |  4 ++--
>  drivers/net/gmac_rockchip.c   | 18 -
>  drivers/pwm/rk_pwm.c  |  2 +-
>  drivers/ram/rockchip/dmc-rk3368.c | 12 +--
>  drivers/ram/rockchip/sdram_rk3128.c   |  6 +++---
>  drivers/ram/rockchip/sdram_rk3188.c   | 14 ++---
>  drivers/ram/rockchip/sdram_rk322x.c   | 16 +++
>  drivers/ram/rockchip/sdram_rk3288.c   | 14 ++---
>  drivers/ram/rockchip/sdram_rk3328.c   |  6 +++---
>  drivers/ram/rockchip/sdram_rk3399.c   | 12 +--
>  drivers/reset/reset-rockchip.c|  2 +-
>  drivers/serial/serial_rockchip.c  |  2 +-
>  drivers/sound/rockchip_sound.c|  2 +-
>  drivers/spi/rk_spi.c 

Re: [U-Boot] [PATCH 1/3] rockchip: arm: use 'arch-rockchip' for common header

2019-05-01 Thread Philipp Tomsich
> rockchip platform header file is in 'arch-rockchip'
> instead of arch-$(SOC) for all SoCs.
> 
> Signed-off-by: Kever Yang 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  arch/arm/cpu/armv8/start.S  | 4 
>  arch/arm/include/asm/gpio.h | 2 +-
>  arch/arm/lib/vectors.S  | 5 -
>  3 files changed, 9 insertions(+), 2 deletions(-)
> 

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 30/50] x86: ivybridge: Implement PCH_REQ_PMBASE_INFO

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Implement this ioctl() to support power off.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add new patch to implement PCH_REQ_PMBASE_INFO on ivybridge
>
>  arch/x86/cpu/ivybridge/bd82x6x.c | 15 +++
>  1 file changed, 15 insertions(+)
>

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


Re: [U-Boot] [PATCH v2 28/50] x86: sysreset: Separate out the EFI code

2019-05-01 Thread Bin Meng
+Heinrich,

On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> The EFI implementation of reset sits inside the driver and is called
> directly from outside the driver, breaking the normal driver-model
> conventions. Worse, it passed NULL as the device pointer, hoping that
> the called function won't use it, which breaks as soon as code is added
> to use it.
>
> Separate out the implementation to improve the situation enough to allow
> a future patch to add new sysreset features.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add new patch to separate out the EFI code in sysreset
>
>  drivers/sysreset/sysreset_x86.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
> index 009f3766027..d484ec5de49 100644
> --- a/drivers/sysreset/sysreset_x86.c
> +++ b/drivers/sysreset/sysreset_x86.c
> @@ -12,8 +12,7 @@
>  #include 
>  #include 
>
> -static __efi_runtime int x86_sysreset_request(struct udevice *dev,
> - enum sysreset_t type)

I remember last time I tried when booting Linux from EFI loader on
U-Boot, calling from kernel into the EFI runtime was broken. Not sure
what the latest status is.

> +static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type)
>  {
> int value;
>
> @@ -39,11 +38,18 @@ void __efi_runtime EFIAPI efi_reset_system(
> efi_status_t reset_status,
> unsigned long data_size, void *reset_data)
>  {
> +   int value;
> +
> +   /*
> +* inline this code since we are not caused in the context of a
> +* udevice and passing NULL to x86_sysreset_request() is too horrible.
> +*/
> if (reset_type == EFI_RESET_COLD ||
>  reset_type == EFI_RESET_PLATFORM_SPECIFIC)
> -   x86_sysreset_request(NULL, SYSRESET_COLD);
> -   else if (reset_type == EFI_RESET_WARM)
> -   x86_sysreset_request(NULL, SYSRESET_WARM);
> +   value = SYS_RST | RST_CPU | FULL_RST;
> +   else /* assume EFI_RESET_WARM since we cannot return an error */
> +   value = SYS_RST | RST_CPU;
> +   outb(value, IO_PORT_RESET);
>
> /* TODO EFI_RESET_SHUTDOWN */
>
> --

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


Re: [U-Boot] [PATCH v2 29/50] x86: pch: Add an ioctl to read power-management info

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add a new ioctl() request to read information about the power-management
> system. This can be used to power off the device.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add new patch to add an ioctl to read power-management info
>
>  include/pch.h | 18 ++
>  1 file changed, 18 insertions(+)
>

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


Re: [U-Boot] [PATCH 1/6] arm: dts: imx8qm: add lpuart1, lpuart2, lpuart3, lpuart4

2019-05-01 Thread Max Krummenacher
Reviewed-by: Max Krummenacher 

On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Add support for lpuart1, lpuart2, lpuart3 and lpuart4.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  arch/arm/dts/fsl-imx8qm.dtsi | 80 
>  1 file changed, 80 insertions(+)
> 
> diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi
> index b39c40bd98..db01959990 100644
> --- a/arch/arm/dts/fsl-imx8qm.dtsi
> +++ b/arch/arm/dts/fsl-imx8qm.dtsi
> @@ -22,6 +22,10 @@
>   ethernet0 = &fec1;
>   ethernet1 = &fec2;
>   serial0 = &lpuart0;
> + serial1 = &lpuart1;
> + serial2 = &lpuart2;
> + serial3 = &lpuart3;
> + serial4 = &lpuart4;
>   mmc0 = &usdhc1;
>   mmc1 = &usdhc2;
>   mmc2 = &usdhc3;
> @@ -193,6 +197,30 @@
>   power-domains = <&pd_dma>;
>   wakeup-irq = <345>;
>   };
> + pd_dma_lpuart1: PD_DMA_UART1 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <&pd_dma>;
> + wakeup-irq = <346>;
> + };
> + pd_dma_lpuart2: PD_DMA_UART2 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <&pd_dma>;
> + wakeup-irq = <347>;
> + };
> + pd_dma_lpuart3: PD_DMA_UART3 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <&pd_dma>;
> + wakeup-irq = <348>;
> + };
> + pd_dma_lpuart4: PD_DMA_UART4 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <&pd_dma>;
> + wakeup-irq = <349>;
> + };
>   };
>   };
>  
> @@ -297,6 +325,58 @@
>   status = "disabled";
>   };
>  
> + lpuart1: serial@5a07 {
> + compatible = "fsl,imx8qm-lpuart";
> + reg = <0x0 0x5a07 0x0 0x1000>;
> + interrupts = ;
> + clocks = <&clk IMX8QM_UART1_CLK>,
> +  <&clk IMX8QM_UART1_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = <&clk IMX8QM_UART1_CLK>;
> + assigned-clock-rates = <8000>;
> + power-domains = <&pd_dma_lpuart1>;
> + status = "disabled";
> + };
> +
> + lpuart2: serial@5a08 {
> + compatible = "fsl,imx8qm-lpuart";
> + reg = <0x0 0x5a08 0x0 0x1000>;
> + interrupts = ;
> + clocks = <&clk IMX8QM_UART2_CLK>,
> +  <&clk IMX8QM_UART2_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = <&clk IMX8QM_UART2_CLK>;
> + assigned-clock-rates = <8000>;
> + power-domains = <&pd_dma_lpuart2>;
> + status = "disabled";
> + };
> +
> + lpuart3: serial@5a09 {
> + compatible = "fsl,imx8qm-lpuart";
> + reg = <0x0 0x5a09 0x0 0x1000>;
> + interrupts = ;
> + clocks = <&clk IMX8QM_UART3_CLK>,
> +  <&clk IMX8QM_UART3_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = <&clk IMX8QM_UART3_CLK>;
> + assigned-clock-rates = <8000>;
> + power-domains = <&pd_dma_lpuart3>;
> + status = "disabled";
> + };
> +
> + lpuart4: serial@5a0a {
> + compatible = "fsl,imx8qm-lpuart";
> + reg = <0x0 0x5a0a 0x0 0x1000>;
> + interrupts = ;
> + clocks = <&clk IMX8QM_UART4_CLK>,
> +  <&clk IMX8QM_UART4_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = <&clk IMX8QM_UART4_CLK>;
> + assigned-clock-rates = <8000>;
> + power-domains = <&pd_dma_lpuart4>;
> + status = "disabled";
> + };
> +
>   usdhc1: usdhc@5b01 {
>   compatible = "fsl,imx8qm-usdhc", "fsl,imx6sl-usdhc";
>   interrupt-parent = <&gic>;

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


Re: [U-Boot] [PATCH 6/6] board: toradex: add apalis imx8qm 4gb wb it v1.0b module support

2019-05-01 Thread Max Krummenacher
See review comments below. (Marked with 'Review Max:')

With the issue resolved:
Reviewed-by: Max Krummenacher 

On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> This commit adds initial support for the Toradex Apalis iMX8QM 4GB WB IT
> V1.0B module. Unlike the V1.0A early access samples exclusively booting
> from SD card, they are now strapped to boot from eFuses which are
> factory fused to properly boot from their on-module eMMC. U-Boot
> supports either booting from the on-module eMMC or may be used for
> recovery purpose using the universal update utility (uuu) aka mfgtools
> 3.0.
> 
> Functionality wise the following is known to be working:
> - eMMC, 8-bit and 4-bit MMC/SD card slots
> - Gigabit Ethernet
> - GPIOs
> - I2C
> 
> Unfortunately, there is no USB functionality for the i.MX 8QM as of yet.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  arch/arm/dts/Makefile   |   1 +
>  arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi  | 128 
>  arch/arm/dts/fsl-imx8qm-apalis.dts  | 615 
>  arch/arm/mach-imx/imx8/Kconfig  |   6 +
>  board/toradex/apalis-imx8qm/Kconfig |  30 +
>  board/toradex/apalis-imx8qm/MAINTAINERS |   9 +
>  board/toradex/apalis-imx8qm/Makefile|   6 +
>  board/toradex/apalis-imx8qm/README  |  66 +++
>  board/toradex/apalis-imx8qm/apalis-imx8qm.c | 157 +
>  board/toradex/apalis-imx8qm/imximage.cfg|  24 +
>  configs/apalis-imx8qm_defconfig |  56 ++
>  include/configs/apalis-imx8qm.h | 178 ++
>  12 files changed, 1276 insertions(+)
>  create mode 100644 arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi
>  create mode 100644 arch/arm/dts/fsl-imx8qm-apalis.dts
>  create mode 100644 board/toradex/apalis-imx8qm/Kconfig
>  create mode 100644 board/toradex/apalis-imx8qm/MAINTAINERS
>  create mode 100644 board/toradex/apalis-imx8qm/Makefile
>  create mode 100644 board/toradex/apalis-imx8qm/README
>  create mode 100644 board/toradex/apalis-imx8qm/apalis-imx8qm.c
>  create mode 100644 board/toradex/apalis-imx8qm/imximage.cfg
>  create mode 100644 configs/apalis-imx8qm_defconfig
>  create mode 100644 include/configs/apalis-imx8qm.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index e1f18c2833..c7260968b5 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -567,6 +567,7 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>  
>  dtb-$(CONFIG_ARCH_IMX8) += \
> + fsl-imx8qm-apalis.dtb \
>   fsl-imx8qm-mek.dtb \
>   fsl-imx8qxp-colibri.dtb \
>   fsl-imx8qxp-mek.dtb
> diff --git a/arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi 
> b/arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi
> new file mode 100644
> index 00..7b1a9550e4
> --- /dev/null
> +++ b/arch/arm/dts/fsl-imx8qm-apalis-u-boot.dtsi
> @@ -0,0 +1,128 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2019 Toradex AG
> + */
> +
> +&mu {
> + u-boot,dm-spl;
> +};
> +
> +&clk {
> + u-boot,dm-spl;
> +};
> +
> +&iomuxc {
> + u-boot,dm-spl;
> +};
> +
> +&pd_lsio {
> + u-boot,dm-spl;
> +};
> +
> +&pd_lsio_gpio0 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_lsio_gpio1 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_lsio_gpio2 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_lsio_gpio3 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_lsio_gpio4 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_lsio_gpio5 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_lsio_gpio6 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_lsio_gpio7 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_conn {
> + u-boot,dm-spl;
> +};
> +
> +&pd_conn_sdch0 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_conn_sdch1 {
> + u-boot,dm-spl;
> +};
> +
> +&pd_conn_sdch2 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio0 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio1 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio2 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio3 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio4 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio5 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio6 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio7 {
> + u-boot,dm-spl;
> +};
> +
> +&lpuart0 {
> + u-boot,dm-spl;
> +};
> +
> +&lpuart1 {
> + u-boot,dm-spl;
> +};
> +
> +&lpuart2 {
> + u-boot,dm-spl;
> +};
> +
> +&lpuart3 {
> + u-boot,dm-spl;
> +};
> +
> +&usdhc1 {
> + u-boot,dm-spl;
> +};
> +
> +&usdhc2 {
> + u-boot,dm-spl;
> +};
> +
> +&usdhc3 {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/fsl-imx8qm-apalis.dts 
> b/arch/arm/dts/fsl-imx8qm-apalis.dts
> new file mode 100644
> index 00..9b1f8aa32d
> --- /dev/null
> +++ b/arch/arm/dts/fsl-imx8qm-apalis.dts
> @@ -0,0 +1,615 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Copyright 2017-2019 Toradex
> + */
> +
> +/dts-v1/;
> +
> +/* First 128KB is for PSCI ATF. */
> +/memreserve/ 0x8000 0x0002;
> +
> +#include "fsl-imx8qm.dtsi"
> +#include "fsl-imx8qm-apalis-u-boot.dtsi"
> +
> +/ {
>

Re: [U-Boot] [PATCH 4/6] imx8qm: fix cpu frequency reporting

2019-05-01 Thread Max Krummenacher
See review comment below.

With the issue resolved:
Reviewed-by: Max Krummenacher 

On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote:
> CPU frequency reporting failed with the following error message being
> printed:
> 
> sc_pm_get_clock_rate: resource:507 clk:2: res:3
> Could not read CPU frequency: -22
> CPU:   NXP i.MX8QM RevB A53 at 0 MHz
> 
> Fix this by differentiating between the A35 as found on the i.MX 8QXP
> and the A53 as found on the i.MX 8QM SoCs.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  arch/arm/mach-imx/imx8/cpu.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
> index 12716e7e9e..0d01e3fc3b 100644
> --- a/arch/arm/mach-imx/imx8/cpu.c
> +++ b/arch/arm/mach-imx/imx8/cpu.c
> @@ -654,8 +654,9 @@ static ulong imx8_get_cpu_rate(void)
>  {
>   ulong rate;
>   int ret;
> + int type = is_cortex_a35() ? SC_R_A35 : SC_R_A53;

The related get_core_name() below foresees that the code could run on
a cortex_a72. So we should here also test with is_cortex_a72 and then
use SC_R_A72 to avoid a follow-up patch for a future i.MX8 SKU or changed
configuration.

Regards,
Max

>  
> - ret = sc_pm_get_clock_rate(-1, SC_R_A35, SC_PM_CLK_CPU,
> + ret = sc_pm_get_clock_rate(-1, type, SC_PM_CLK_CPU,
>  (sc_pm_clock_rate_t *)&rate);
>   if (ret) {
>   printf("Could not read CPU frequency: %d\n", ret);

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


Re: [U-Boot] [PATCH 2/6] arm: dts: imx8qm: add support for i2c0, i2c1, i2c2, i2c3 and i2c4

2019-05-01 Thread Max Krummenacher
Reviewed-by: Max Krummenacher 

On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Add support for i2c0, i2c1, i2c2, i2c3 and i2c4.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  arch/arm/dts/fsl-imx8qm.dtsi | 75 
>  1 file changed, 75 insertions(+)
> 
> diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi
> index db01959990..af060db3a1 100644
> --- a/arch/arm/dts/fsl-imx8qm.dtsi
> +++ b/arch/arm/dts/fsl-imx8qm.dtsi
> @@ -29,6 +29,11 @@
>   mmc0 = &usdhc1;
>   mmc1 = &usdhc2;
>   mmc2 = &usdhc3;
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + i2c2 = &i2c2;
> + i2c3 = &i2c3;
> + i2c4 = &i2c4;
>   };
>  
>   memory@8000 {
> @@ -224,6 +229,76 @@
>   };
>   };
>  
> + i2c0: i2c@5a80 {
> + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
> + reg = <0x0 0x5a80 0x0 0x4000>;
> + interrupts = ;
> + interrupt-parent = <&gic>;
> + clocks = <&clk IMX8QM_I2C0_CLK>,
> +  <&clk IMX8QM_I2C0_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = <&clk IMX8QM_I2C0_CLK>;
> + assigned-clock-rates = <2400>;
> + power-domains = <&pd_dma_lpi2c0>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@5a81 {
> + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
> + reg = <0x0 0x5a81 0x0 0x4000>;
> + interrupts = ;
> + interrupt-parent = <&gic>;
> + clocks = <&clk IMX8QM_I2C1_CLK>,
> +  <&clk IMX8QM_I2C1_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = <&clk IMX8QM_I2C1_CLK>;
> + assigned-clock-rates = <2400>;
> + power-domains = <&pd_dma_lpi2c1>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c@5a82 {
> + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
> + reg = <0x0 0x5a82 0x0 0x4000>;
> + interrupts = ;
> + interrupt-parent = <&gic>;
> + clocks = <&clk IMX8QM_I2C2_CLK>,
> +  <&clk IMX8QM_I2C2_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = <&clk IMX8QM_I2C2_CLK>;
> + assigned-clock-rates = <2400>;
> + power-domains = <&pd_dma_lpi2c2>;
> + status = "disabled";
> + };
> +
> + i2c3: i2c@5a83 {
> + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
> + reg = <0x0 0x5a83 0x0 0x4000>;
> + interrupts = ;
> + interrupt-parent = <&gic>;
> + clocks = <&clk IMX8QM_I2C3_CLK>,
> +  <&clk IMX8QM_I2C3_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = <&clk IMX8QM_I2C3_CLK>;
> + assigned-clock-rates = <2400>;
> + power-domains = <&pd_dma_lpi2c3>;
> + status = "disabled";
> + };
> +
> + i2c4: i2c@5a84 {
> + compatible = "fsl,imx8qm-lpi2c", "fsl,imx7ulp-lpi2c";
> + reg = <0x0 0x5a84 0x0 0x4000>;
> + interrupts = ;
> + interrupt-parent = <&gic>;
> + clocks = <&clk IMX8QM_I2C4_CLK>,
> +  <&clk IMX8QM_I2C4_IPG_CLK>;
> + clock-names = "per", "ipg";
> + assigned-clocks = <&clk IMX8QM_I2C4_CLK>;
> + assigned-clock-rates = <2400>;
> + power-domains = <&pd_dma_lpi2c4>;
> + status = "disabled";
> + };
> +
>   gpio0: gpio@5d08 {
>   compatible = "fsl,imx8qm-gpio", "fsl,imx35-gpio";
>   reg = <0x0 0x5d08 0x0 0x1>;

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


Re: [U-Boot] [PATCH 5/6] imx8: fuse: fix fuse driver

2019-05-01 Thread Max Krummenacher
Reviewed-by: Max Krummenacher 

On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote:
> This fixes the i.MX 8 fuse driver to actually build for i.MX 8QM as
> well.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  drivers/misc/imx8/fuse.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/misc/imx8/fuse.c b/drivers/misc/imx8/fuse.c
> index 29d2256a22..2f2fad2c17 100644
> --- a/drivers/misc/imx8/fuse.c
> +++ b/drivers/misc/imx8/fuse.c
> @@ -15,13 +15,11 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define FSL_ECC_WORD_START_1  0x10
>  #define FSL_ECC_WORD_END_10x10F
>  
> -#ifdef CONFIG_IMX8QXP
>  #define FSL_ECC_WORD_START_2  0x220
>  #define FSL_ECC_WORD_END_20x31F
>  
>  #define FSL_QXP_FUSE_GAP_START0x110
>  #define FSL_QXP_FUSE_GAP_END  0x21F
> -#endif
>  
>  #define FSL_SIP_OTP_READ 0xc20A
>  #define FSL_SIP_OTP_WRITE0xc20B

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


Re: [U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address

2019-05-01 Thread Stephen Finucane
On Tue, 2019-04-30 at 14:28 +0200, Eugeniu Rosca wrote:
> Hi Jeremy,
> 
> Would you kindly feedback if it's possible to include commit
> https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932
> into U-Boot's patchwork to avoid occasional glitches in the
> description of U-Boot commits?

This is included in 2.1.1 [1] which patchwork.ozlabs.org was recently
updated to [2], so you should have this fix now. Let me know if I've
missed something.

Stephen

[1] https://github.com/getpatchwork/patchwork/commit/8060b9a671
[2] https://lists.ozlabs.org/pipermail/patchwork/2019-April/005746.html

> On Sun, Apr 14, 2019 at 07:39:19PM -0400, Tom Rini wrote:
> > On Sun, Apr 14, 2019 at 10:13:15PM +0200, Eugeniu Rosca wrote:
> > > Hi Simon,
> > >  CC: Tom, Yamada-san, Jiri, Stephen,
> > > 
> > > On Sat, Mar 30, 2019 at 03:19:23PM -0600, Simon Glass wrote:
> > > > Hi Eugeniu,
> > > > 
> > > > On Mon, 25 Mar 2019 at 04:44, Eugeniu Rosca <
> > > > ero...@de.adit-jv.com> wrote:
> > > > > Hello Simon,
> > > > > 
> > > > > On Sun, Mar 10, 2019 at 03:51:47PM -0600, Simon Glass wrote:
> > > > > [..]
> > > > > > Reviewed-by: Simon Glass 
> > > > > 
> > > > > Can this fix go to u-boot-dm or is more review required?
> > > > > 
> > > > 
> > > > Yes it looks like it is in my queue.
> > > > 
> > > > Regards,
> > > > Simon
> > > 
> > > First, many thanks for pushing the fix to u-boot-dm.
> > > 
> > > Second, I would like to (repeatedly [0]) point out a pretty rare
> > > corruption of patch metadata, which places the 'Reviewed-by:'
> > > (and actually any other "*-by: ") signature on top of the '='
> > > line if the latter is present in commit description (see [1]).
> > > 
> > > As Yamada-san pointed out in [0], this is presumably caused by a
> > > patchwork bug and after some grepping through the patchwork git
> > > history, it looks like the issue is already fixed in patchwork
> > > master
> > > thanks to Jiri and Stephen via commit [2].
> > > 
> > > My guess is that the U-Boot patchwork version might not be
> > > containing
> > > this recent fix, hence still showcasing the wrong behavior?
> > > 
> > > FWIW, at least below U-Boot commits exhibit the same
> > > inconsistency:
> > > 
> > > u-boot $> for c in $(git log --format=%h --grep "^==="); \
> > >   do \
> > >   git log --format=%B -1 $c | grep -B 2 "^===" |
> > > \
> > >   grep -q "by:.*@" && git --no-pager log --oneline -1
> > > $c; \
> > >   done
> > > 
> > > 0506620f4f49 sata: sata_mv: Add DM support to enable CONFIG_BLK
> > > usage
> > > 9bfacf249b10 core: ofnode: Fix ASAN-reported stack-buffer-
> > > overflow in of_get_address
> > > e1904f4530a3 common: avb_verify: Fix division by zero in
> > > mmc_byte_io()
> > > e91610da7c8a kconfig: re-sync with Linux 4.17-rc4
> > > e810565e23cd i.MX6DL: mamoj: Add PFUZE100 support
> > > dda9892171c3 i.MX6DL: mamoj: Add I2C support
> > > a0b0ff0ae643 arm: dra7xx: Fix Linux boot from eMMC
> > > f6d245b8c56c arm: am57xx: Fix Linux boot from eMMC
> > > 67ff9e11f397 wandboard: move environment partition farther from
> > > u-boot.img
> > > 
> > > [0] https://marc.info/?l=u-boot&m=152643616902958&w=2
> > > [1] http://git.denx.de/?p=u-boot.git;a=commitdiff;h=9bfacf249b10
> > > [2] 
> > > https://github.com/getpatchwork/patchwork/commit/67faf96ab96d932
> > > ("parser: fix parsing of patches with headings")
> > 
> > Adding in Jeremy since we just use the ozlabs patchwork, thanks!
> > 
> > -- 
> > Tom


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


[U-Boot] [PATCH v3] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig

2019-05-01 Thread Alex Kiernan
This converts the following to Kconfig:
   CONFIG_SUPPORT_EMMC_BOOT

As requested by Michal Simek , these boards
have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated:

  xilinx_zynqmp_zc1275_revB
  xilinx_zynqmp_zc1751_xm018_dc4
  xilinx_zynqmp_zc1751_xm019_dc5
  xilinx_zynqmp_zcu100_revC
  xilinx_zynqmp_zcu102_rev1_0
  xilinx_zynqmp_zcu102_revA
  xilinx_zynqmp_zcu102_revB
  xilinx_zynqmp_zcu104_revA
  xilinx_zynqmp_zcu104_revC
  xilinx_zynqmp_zcu106_revA
  xilinx_zynqmp_zcu111_revA

Signed-off-by: Alex Kiernan 
Acked-by: Lukasz Majewski 
Acked-by: Patrick Delaunay 
Acked-by: Ramon Fried 
Reviewed-by: Andy Shevchenko 
Tested-by: Sébastien Szymanski 
---
Green travis build:

https://travis-ci.org/akiernan/u-boot/builds/526591535

Testing for configuration changes shows just the expected xilinx_zynqmp
boards:

boards.cfg is up to date. Nothing to do.
Summary of 2 commits for 1365 boards (4 threads, 1 job per thread)
01: Prepare v2019.07-rc1
   arm:  w+   blanche db-88f6281-bp-nand Nintendo_NES_Classic_Edition 
ts4600 kc1 vining_2000 topic_miamilite bcm7260 tqma6dl_mba6_spi dserve_dsrv9703c
  m68k:  w+   M5485BFE
   powerpc:  w+   MPC8313ERDB_NAND_66 P3041DS_SRIO_PCIE_BOOT P1022DS_36BIT_NAND 
xpedite550x P5040DS_SDCARD Cyrus_P5040 T2080RDB_SRIO_PCIE_BOOT
02: Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig
   x86:  +   conga-qeval20-qa3-e3845-internal-uart
theadorable-x86-conga-qa3-e3845-pcie-x4 bayleybay dfi-bt700-q7x-151
theadorable-x86-dfi-bt700 galileo theadorable-x86-conga-qa3-e3845 minnowmax
som-db5800-som-6867 conga-qeval20-qa3-e3845
   aarch64:  w+   ls1088ardb_sdcard_qspi_SECURE_BOOT am65x_hs_evm_a53 pine_h64
pinebook pine64-lts bananapi_m2_plus_h5 xilinx_versal_mini_emmc1
xilinx_versal_mini_emmc0 mvebu_espressobin-88f3720 ls1012aqds_tfa_SECURE_BOOT
bubblegum_96 bcm958712k amarula_a64_relic uDPU oceanic_5205_5inmfd
libretech_all_h3_cc_h5 nanopi_neo2 bananapi_m64 orangepi_prime hikey
orangepi_pc2 nanopi_neo_plus2 s32v234evb pine64_plus orangepi_one_plus
emlid_neutis_n5_devboard turris_mox orangepi_win a64-olinuxino imx8qxp_mek
xilinx_zynqmp_mini_emmc1 ls2080aqds_nand rpi_3 ls2080aqds_qspi
xilinx_zynqmp_mini_emmc0 ls2080aqds_sdcard am65x_evm_a53 orangepi_zero_plus
socfpga_stratix10 ls1046ardb_sdcard_SECURE_BOOT imx8mq_evk orangepi_lite2
ls2080a_simu nanopi_a64 ls1043ardb_sdcard_SECURE_BOOT mvebu_mcbin-88f8040
mvebu_db_armada8k sopine_baseboard orangepi_zero_plus2 clearfog_gt_8k
mvebu_db-88f3720
   powerpc:  w+   T4240RDB T1024RDB_SPIFLASH T2081QDS_SRIO_PCIE_BOOT
T2080QDS_SPIFLASH P3041DS_NAND P1020RDB-PC_36BIT MPC837XEMDS_HOST
P1024RDB_SPIFLASH P2020RDB-PC_36BIT_SPIFLASH P1010RDB-PB_SPIFLASH_SECBOOT hrcon
P5020DS_NAND T1024QDS_SPIFLASH P1010RDB-PA_36BIT_NAND P1021RDB-PC
P1010RDB-PB_SDCARD P1010RDB-PB_36BIT_NOR T1024QDS_DDR4_SECURE_BOOT
P1020UTM-PC_36BIT controlcenterd_36BIT_SDCARD P5020DS_SRIO_PCIE_BOOT
P1020MBG-PC_36BIT_SDCARD BSC9132QDS_SDCARD_DDRCLK133_SECURE P2041RDB_SPIFLASH
P3041DS T2081QDS P1025RDB_SDCARD T2080QDS T4240QDS T1040D4RDB
BSC9132QDS_NAND_DDRCLK133_SECURE P1010RDB-PA_36BIT_SPIFLASH_SECBOOT
T4240RDB_SDCARD TWR-P1025 P1010RDB-PB_36BIT_NAND T1023RDB_NAND
P1022DS_36BIT_SDCARD P2041RDB_SECURE_BOOT T1024QDS_NAND P1021RDB-PC_SPIFLASH
P5020DS_NAND_SECURE_BOOT P1010RDB-PA_SPIFLASH_SECBOOT MPC8536DS_SDCARD
T1040RDB_SPIFLASH BSC9132QDS_SDCARD_DDRCLK100 T1024RDB_NAND T2081QDS_SPIFLASH
P1010RDB-PB_36BIT_NOR_SECBOOT P5020DS BSC9132QDS_NOR_DDRCLK100_SECURE
T1023RDB_SDCARD P1020UTM-PC P3041DS_SECURE_BOOT Cyrus_P5020
P1010RDB-PB_36BIT_SDCARD P2020RDB-PC UCP1020 T4160QDS_NAND P1020MBG-PC_36BIT
P1020RDB-PC_36BIT_NAND T1042D4RDB_SECURE_BOOT P5040DS_SECURE_BOOT
P1020RDB-PC_SDCARD T2080RDB P1025RDB_36BIT P5040DS_NAND T4240QDS_SECURE_BOOT
P3041DS_SDCARD T1024QDS P5040DS_NAND_SECURE_BOOT T1042RDB_PI_NAND
P1010RDB-PA_SPIFLASH P1020RDB-PD_SPIFLASH T2080RDB_NAND
P1010RDB-PB_36BIT_SPIFLASH_SECBOOT P1010RDB-PB_NAND_SECBOOT P1022DS_SDCARD
P1020RDB-PC_36BIT_SPIFLASH T1042RDB_PI_SDCARD
BSC9132QDS_SPIFLASH_DDRCLK100_SECURE P3041DS_NAND_SECURE_BOOT T2081QDS_NAND
BSC9132QDS_SDCARD_DDRCLK133 T4160QDS_SDCARD T2080QDS_SDCARD
P1020RDB-PC_SPIFLASH T1042RDB T4160QDS_SECURE_BOOT P1021RDB-PC_NAND P1020RDB-PD
P2041RDB_SDCARD T1040D4RDB_SPIFLASH T2080RDB_SECURE_BOOT
P1010RDB-PA_36BIT_NOR_SECBOOT T1040QDS P1010RDB-PA_36BIT_NOR T1042D4RDB
P1021RDB-PC_SDCARD P1025RDB P2020RDB-PC_SPIFLASH MPC837XEMDS
P4080DS_SECURE_BOOT T1040QDS_SECURE_BOOT strider_con_dp T1040QDS_DDR4
P1010RDB-PA_36BIT_SDCARD P1010RDB-PB_NOR T2080RDB_SPIFLASH
P1021RDB-PC_36BIT_SPIFLASH P1020RDB-PC_36BIT_SDCARD T1024QDS_DDR4
P1010RDB-PB_36BIT_NAND_SECBOOT P1020RDB-PC_NAND T2080QDS_NAND
BSC9132QDS_SPIFLASH_DDRCLK133 controlcenterd_36BIT_SDCARD_DEVELOP
strider_cpu_dp P5020DS_SDCARD P1010RDB-PA_NOR T2080QDS_SRIO_PCIE_BOOT
P5020DS_SPIFLASH P1022DS_SPIFLASH UCP1020_SPIFLASH BSC9132QDS_NAND_DDRCLK100
MPC8308RDB T1040D4RDB_NAND T4160QDS P1010RDB-PA_NAND_SECBOOT T4160RDB
BSC9132QDS_SPIFLASH_DDRCLK133_SECURE P1010RDB-PA_NOR_SECBOOT
controlcenterd_TRAILBLAZER

[U-Boot] [PATCH] tools/Makefile: fix HOSTCFLAGS with CROSS_BUILD_TOOLS

2019-05-01 Thread Fabrice Fontaine
When CROSS_BUILD_TOOLS is set, set HOSTCFLAGS to CFLAGS otherwise CC
will be used with HOSTCFLAGS which seems wrong

Signed-off-by: Fabrice Fontaine 
---
 tools/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/Makefile b/tools/Makefile
index 12a3027e23..eadeba417d 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -272,6 +272,7 @@ subdir- += env
 
 ifneq ($(CROSS_BUILD_TOOLS),)
 override HOSTCC = $(CC)
+override HOSTCFLAGS = $(CFLAGS)
 
 quiet_cmd_crosstools_strip = STRIP   $^
   cmd_crosstools_strip = $(STRIP) $^; touch $@
-- 
2.20.1

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


Re: [U-Boot] [PATCH 3/6] clk: imx8qm: fix usdhc2 clocks

2019-05-01 Thread Max Krummenacher
Reviewed-by: Max Krummenacher 

On Tue, 2019-04-30 at 12:06 +0200, Marcel Ziswiler wrote:
> Trying to bring up uSDHC2 the following error message was observed:
> 
> MMC:   imx8_clk_set_rate(Invalid clk ID #60)
> imx8_clk_set_rate(Invalid clk ID #60)
> usdhc@5b03 - probe failed: -22
> 
> This commit fixes this by properly setting resp. clocks.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  drivers/clk/imx/clk-imx8qm.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/clk/imx/clk-imx8qm.c b/drivers/clk/imx/clk-imx8qm.c
> index 6b5561e178..a6b09d2109 100644
> --- a/drivers/clk/imx/clk-imx8qm.c
> +++ b/drivers/clk/imx/clk-imx8qm.c
> @@ -80,6 +80,12 @@ ulong imx8_clk_get_rate(struct clk *clk)
>   resource = SC_R_SDHC_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_SDHC2_IPG_CLK:
> + case IMX8QM_SDHC2_CLK:
> + case IMX8QM_SDHC2_DIV:
> + resource = SC_R_SDHC_2;
> + pm_clk = SC_PM_CLK_PER;
> + break;
>   case IMX8QM_UART0_IPG_CLK:
>   case IMX8QM_UART0_CLK:
>   resource = SC_R_UART_0;
> @@ -185,6 +191,12 @@ ulong imx8_clk_set_rate(struct clk *clk, unsigned long 
> rate)
>   resource = SC_R_SDHC_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_SDHC2_IPG_CLK:
> + case IMX8QM_SDHC2_CLK:
> + case IMX8QM_SDHC2_DIV:
> + resource = SC_R_SDHC_2;
> + pm_clk = SC_PM_CLK_PER;
> + break;
>   case IMX8QM_ENET0_IPG_CLK:
>   case IMX8QM_ENET0_AHB_CLK:
>   case IMX8QM_ENET0_REF_DIV:
> @@ -273,6 +285,12 @@ int __imx8_clk_enable(struct clk *clk, bool enable)
>   resource = SC_R_SDHC_1;
>   pm_clk = SC_PM_CLK_PER;
>   break;
> + case IMX8QM_SDHC2_IPG_CLK:
> + case IMX8QM_SDHC2_CLK:
> + case IMX8QM_SDHC2_DIV:
> + resource = SC_R_SDHC_2;
> + pm_clk = SC_PM_CLK_PER;
> + break;
>   case IMX8QM_ENET0_IPG_CLK:
>   case IMX8QM_ENET0_AHB_CLK:
>   case IMX8QM_ENET0_REF_DIV:

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


Re: [U-Boot] [PATCH v2 31/50] x86: broadwell: Implement PCH_REQ_PMBASE_INFO

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Implement this ioctl() to support power off.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add new patch to implement PCH_REQ_PMBASE_INFO on broadwell
>
>  arch/x86/cpu/broadwell/pch.c | 25 +
>  1 file changed, 25 insertions(+)
>

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


Re: [U-Boot] [PATCH v3] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig

2019-05-01 Thread Tom Rini
On Wed, May 01, 2019 at 07:58:27AM +, Alex Kiernan wrote:
> This converts the following to Kconfig:
>CONFIG_SUPPORT_EMMC_BOOT
> 
> As requested by Michal Simek , these boards
> have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated:
> 
>   xilinx_zynqmp_zc1275_revB
>   xilinx_zynqmp_zc1751_xm018_dc4
>   xilinx_zynqmp_zc1751_xm019_dc5
>   xilinx_zynqmp_zcu100_revC
>   xilinx_zynqmp_zcu102_rev1_0
>   xilinx_zynqmp_zcu102_revA
>   xilinx_zynqmp_zcu102_revB
>   xilinx_zynqmp_zcu104_revA
>   xilinx_zynqmp_zcu104_revC
>   xilinx_zynqmp_zcu106_revA
>   xilinx_zynqmp_zcu111_revA
> 
> Signed-off-by: Alex Kiernan 
> Acked-by: Lukasz Majewski 
> Acked-by: Patrick Delaunay 
> Acked-by: Ramon Fried 
> Reviewed-by: Andy Shevchenko 
> Tested-by: Sébastien Szymanski 
> ---
> Green travis build:
> 
> https://travis-ci.org/akiernan/u-boot/builds/526591535
> 
> Testing for configuration changes shows just the expected xilinx_zynqmp
> boards:

So, FWIW, what I do (and will do for this patch when I check it out
before pushing) ends up as:
$ export SOURCE_DATE_EPOCH=`date +%s`
$ ./tools/buildman/buildman -o /tmp/test -b master --force-build --step 0 \
  -SCdvel \
  'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv'
$ ./tools/buildman/buildman -o /tmp/test -b master --step 0 -Ssdel \
  'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv'

With the patch applied in some branch that has 'master' as the upstream.
This is basically a world-build and will size compare before/after,
noting changes.  If I see a size difference (outside of a few boards
that include the config in the binary and so grow slightly on
conversions), I use:
$ export SOURCE_DATE_EPOCH=`date +%s`
$ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SBCdevlk BOARD
$ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SsBdevlk BOARD

Which probably has a few more flags than required but will also tell
which functions within the binary have changed and so a good place to
hunt down what didn't convert correctly and why.

-- 
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 32/50] x86: sysreset: Implement power-off if available

2019-05-01 Thread Bin Meng
Hi Simon,

On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> On modern x86 devices we can power the system off using the power-
> management features of the PCH. Add an implementation for this.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add new patch to implement power-off if available
>
>  drivers/sysreset/sysreset_x86.c | 82 +
>  1 file changed, 82 insertions(+)
>
> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
> index d484ec5de49..bd759aa8bf4 100644
> --- a/drivers/sysreset/sysreset_x86.c
> +++ b/drivers/sysreset/sysreset_x86.c
> @@ -7,14 +7,80 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>
> +struct x86_sysreset_platdata {
> +   struct udevice *pch;
> +};
> +
> +#define   PWRBTN_STS   (1 << 8)
> +
> +#define   SLP_EN   (1 << 13)
> +#define   SLP_TYP  (7 << 10)
> +#defineSLP_TYP_S5  7
> +

There are macros from acpi_s3.h that can be used directly here.

> +/*
> + * Power down the machine by using the power management sleep control
> + * of the chipset. This will currently only work on Intel chipsets.
> + * However, adapting it to new chipsets is fairly simple. You will
> + * have to find the IO address of the power management register block
> + * in your southbridge, and look up the appropriate SLP_TYP_S5 value
> + * from your southbridge's data sheet.
> + *
> + * This function never returns.
> + */
> +int pch_sysreset_power_off(struct udevice *dev)
> +{
> +   struct x86_sysreset_platdata *plat = dev_get_platdata(dev);
> +   struct pch_pmbase_info pm;
> +   u32 reg32;
> +   int ret;
> +
> +   if (!plat->pch)
> +   return -ENOENT;
> +   ret = pch_ioctl(plat->pch, PCH_REQ_PMBASE_INFO, &pm, sizeof(pm));
> +   if (ret)
> +   return ret;
> +
> +
> +   /* Mask interrupts or system might stay in a coma

nits: wrong multi-line comment format

> +* (not executing code anymore, but not powered off either)
> +*/
> +   asm("cli");
> +
> +   /*
> +* Avoid any GPI waking the system from S5* or the system might stay 
> in
> +* a coma
> +*/
> +   outl(0x, pm.base + pm.gpio0_en_ofs);
> +
> +   /* Clear Power Button Status */
> +   outw(PWRBTN_STS, pm.base + pm.pm1_sts_ofs);
> +
> +   /* PMBASE + 4, Bit 10-12, Sleeping Type, * set to 111 -> S5, soft_off 
> */
> +   reg32 = inl(pm.base + pm.pm1_cnt_ofs);
> +
> +   /* Set Sleeping Type to S5 (poweroff) */
> +   reg32 &= ~(SLP_EN | SLP_TYP);
> +   reg32 |= SLP_TYP_S5;
> +   outl(reg32, pm.base + pm.pm1_cnt_ofs);
> +
> +   /* Now set the Sleep Enable bit */
> +   reg32 |= SLP_EN;
> +   outl(reg32, pm.base + pm.pm1_cnt_ofs);
> +
> +   for (;;)
> +   asm("hlt");
> +}
> +
>  static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type)
>  {
> int value;
> +   int ret;
>
> switch (type) {
> case SYSRESET_WARM:
> @@ -23,6 +89,11 @@ static int x86_sysreset_request(struct udevice *dev, enum 
> sysreset_t type)
> case SYSRESET_COLD:
> value = SYS_RST | RST_CPU | FULL_RST;
> break;
> +   case SYSRESET_POWER_OFF:
> +   ret = pch_sysreset_power_off(dev);
> +   if (ret)
> +   return ret;
> +   return -EINPROGRESS;
> default:
> return -ENOSYS;
> }
> @@ -57,6 +128,15 @@ void __efi_runtime EFIAPI efi_reset_system(
>  }
>  #endif
>
> +static int x86_sysreset_probe(struct udevice *dev)
> +{
> +   struct x86_sysreset_platdata *plat = dev_get_platdata(dev);
> +
> +   /* Locate the PCH if there is one. It isn't essential */
> +   uclass_first_device(UCLASS_PCH, &plat->pch);
> +
> +   return 0;
> +}
>
>  static const struct udevice_id x86_sysreset_ids[] = {
> { .compatible = "x86,reset" },
> @@ -72,4 +152,6 @@ U_BOOT_DRIVER(x86_sysreset) = {
> .id = UCLASS_SYSRESET,
> .of_match = x86_sysreset_ids,
> .ops = &x86_sysreset_ops,
> +   .probe = x86_sysreset_probe,
> +   .platdata_auto_alloc_size   = sizeof(struct 
> x86_sysreset_platdata),
>  };
> --

Other than above two,
Reviewed-by: Bin Meng 

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


Re: [U-Boot] EFIBootGuard for CIP and SecureBoot

2019-05-01 Thread Peter Jones
On Sat, Apr 27, 2019 at 09:56:08AM +0200, Alexander Graf wrote:
> 
> >>> UEFI gets a bad rap at being complicated, but I think the U-Boot work
> >>> has shown that implementing the core UEFI ABI doesn't require much code
> >>> and isn't the complicated mess they everyone fears it to be.
> >> Depends on how much you start to rely on UEFI features.
> > The format for a UEFI capsule is described in the
> > EFI_FIRMWARE_MANAGEMENT_PROTOCOL chapter of the UEFI spec. Essentially
> 
> Are you sure? I thought that protocol was about other devices in the
> system, not the main firmware. It also seems to be optional - so we
> could just have a board specific function to implement CapsuleUpdate,
> but no cruft for all the other bits in the spec.

There's no requirement to use that format in order to use capsule
updates, but some vendors have found it convenient.  There's also no
requirement to implement the EFI_FIRMWARE_MANAGEMENT_PROTOCOL at all -
and the only place it's distinctly useful from an application point of
view (i.e. while trying to drive a firmware update) is if you want to
independently update two of the same kind of peripheral device's
firmware from within a UEFI application.  It's not clear to me that's a
very interesting use case from an EBBR point of view - I'm haven't seen
much demand for it on server, laptop, or desktop systems either.

But it's also how option ROMs register their firmware to be updated via
UpdateCapsule().  That's interesting on machines where you regularly
expect peripherals to be in PCIe slots, but I'm still not sure it's that
useful for EBBR style devices.  I guess it could be useful in the
thunderbolt case, but I think in order to avoid thwarting DMA attack
mitigations, that would best be done from the OS just like for USB
devices.

> That's where the idea came from to just put a fit image into the capsule
> body (set CapsuleGUID to a newly defined FIT-GUID). With that, we could
> share a lot of code inside of U-Boot, as DT parsing is already there. We
> could then have individual segments, that can either be data or command
> payloads and thus a capsule update could basically just be a few data
> segments with a U-Boot script.

This makes a lot of sense to me, though there have been some pain points
about this approach in the past.  The biggest one is because the
EFI_FIRMWARE_MANAGEMENT_PROTOCOL capsule format has a header on it
that's the same as the EFI_CAPSULE_HEADER structure, which we have to
add in fwupd if we can't find it.  If we plan on recommending that
vendors implement these ad-hoc firmware blobs, we should also require
that when they do so, they already include the EFI_CAPSULE_HEADER on the
image, with a GUID that matches what's in the ESRT, and is specifically
not EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID.

> > it is a file containing multiple UEFI binaries which are individually
> > signed and can be loaded as UEFI boottime drivers. Further payloads are
> > passed to the SetImage() method of the EFI_FIRMWARE_MANAGEMENT_PROTOCOL.
> >
> > Two ways for the delivery of a capsule are defined.

Three, I think?  I'm not seeing why an application can't also call
FMP->SetImage() to do this when it's present.  I'm not sure it's worth
supporting at all, though.

> > Capsules can be delivered by placing a file in the
> > \EFI\UpdateCapsule directory or by calling the UpdateCapsule() boot
> > service. The UpdateCapsule() boot service can either be implemented
> > as available at boottime only or as a full runtime service.

Right now in fwupd we support only boot-service calls to do this,
because of the history of bugs with SetVirtualAddressMap() and
ExitBootServices(), and because it's the only thing required to be
tested for Windows logo cert.  I suspect MS has made that the case
because of the exact same bugs.

The path-based mechanism makes a lot of sense with EBBR, but runtime
UpdateCapsule() is a lot more viable here than on the desktop or
servers as well.  The reason I say that is because with these devices
we're more in a situation where the hardware vendor is likely to be
producing the kernel as well, so there's a better integration testing
story here.

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


Re: [U-Boot] [PATCH v2 01/50] binman: Don't generate an error in 'text' entry constructor

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
>
> It is not good practice to raise an exception in a constructor. In this
> case the 'text' entry may not actually be used, if -i is used to filter
> out the images that get built.
>
> Move the exception to where the data is actually used.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  tools/binman/etype/text.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 02/50] binman: Don't show image-skip message by default

2019-05-01 Thread Bin Meng
On Wed, May 1, 2019 at 7:59 PM Bin Meng  wrote:
>
> On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
> >
> > This message is not very important since it is simply indicating that the
> > user's instructions are being followed. Only show it when the verbosity
> > level is above the default.
> >
> > Also drop the unnecessary extra newline on this message, which causes two
> > line breaks.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Update commit message to mention dropping the \n
> > - Update testSelectImage() to test in normal and verbose modes
> >
> >  tools/binman/control.py |  4 ++--
> >  tools/binman/ftest.py   | 26 +++---
> >  2 files changed, 21 insertions(+), 9 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH v2 03/50] binman: Add a missing comment in Entry_vblock

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
>
> An important property is missing. Update the entry comment to include
> this.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  tools/binman/etype/vblock.py | 1 +
>  1 file changed, 1 insertion(+)
>

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


Re: [U-Boot] [PATCH v2 04/50] dm: core: Fix translate condition in ofnode_get_addr_size()

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
>
> Update the condition to translate only if this is enabled for SPL.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  drivers/core/ofnode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2 10/50] x86: Add a way to reinit the cpu

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> We cannot init the CPU fully both than once during a boot. Add a new
> function which can be called to figure out the CPU identity, but which
> does not change anything. For x86_64, this is empty for now.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/i386/cpu.c   | 113 ++
>  arch/x86/cpu/x86_64/cpu.c |   5 ++
>  arch/x86/include/asm/u-boot-x86.h |  20 ++
>  3 files changed, 94 insertions(+), 44 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 07/50] binman: Allow sections to have an offset

2019-05-01 Thread Bin Meng
On Wed, May 1, 2019 at 8:13 PM Bin Meng  wrote:
>
> On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
> >
> > At present sections are always placed automatically. Even if an 'offset'
> > property is provided it is ignored. Update the logic to support an offset
> > for sections.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Fix map output when section offset is not set (make it 0)
> > - Add a test for sections with offsets
> >
> >  tools/binman/README   |  7 +
> >  tools/binman/bsection.py  |  9 +++---
> >  tools/binman/etype/section.py |  3 +-
> >  tools/binman/ftest.py | 18 
> >  tools/binman/test/101_sections_offset.dts | 35 +++
> >  5 files changed, 67 insertions(+), 5 deletions(-)
> >  create mode 100644 tools/binman/test/101_sections_offset.dts
> >
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH v2 08/50] x86: start64: Fix copyright message

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
>
> There is a typo in this header. Fix it.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/start64.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2 09/50] x86: mp_init: Use proper error numbers

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present many of the functions in this file return -1 as an error
> number. which is -EPERM. Update the code to use real error numbers.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/mp_init.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 06/50] spl: Allow sandbox to build a device-tree file

2019-05-01 Thread Bin Meng
On Wed, May 1, 2019 at 8:13 PM Bin Meng  wrote:
>
> On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
> >
> > At present only OF_SEPARATE is considered valid for building a device-tree
> > file in SPL. However sandbox uses OF_HOSTFILE instead. Update the logic to
> > handle this and make it easier to understand.
> >
> > Note that the new logic is not quite the same as the old logic. It was
> > previously assumed that checking for:
> >
> >$(CONFIG_$(SPL_TPL_)OF_CONTROL)
> >$(CONFIG_OF_SEPARATE)
> >$(CONFIG_$(SPL_TPL_)OF_PLATDATA)
> >
> > producing 'yy' meant that the first two were 'y' and the last was empty.
> > Strictly speaking it would be possible for any two of the three to be 'y'
> > and still yield the same result. However, that was not the intention of
> > the new logic, since OF_PLATDATA always ensures that no device-tree file
> > is included. So in effect the new logic is the same, with the addition of
> > OF_HOSTFILE as an option for OP_SEPARATE.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Add a better explanation of the logic change, in the commit message
> >
> >  scripts/Makefile.spl | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH v2 11/50] x86: dts: Add device-tree labels for rtc and reset

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add labels for these nodes so that board DT files can reference them.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/dts/reset.dtsi | 2 +-
>  arch/x86/dts/rtc.dtsi   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 13/50] x86: Support SPL and TPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present only chromebook_link64 supports SPL. It is useful to eb able to
> support both TPL and SPL to implement verified boot on x86.
>
> Enable the options for both along with some suitable default options
> needed to boot through these phases.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/Kconfig | 31 +++
>  arch/x86/Kconfig |  1 -
>  2 files changed, 31 insertions(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2 12/50] x86: Update a stale comment about ifdtool

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> We use binman to build the x86 image now. Update a comment which still
> refers to ifdtool.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2:
> - Update the comment in fsp_cap.S too
>
>  arch/x86/cpu/intel_common/car.S | 2 +-
>  arch/x86/lib/fsp/fsp_car.S  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 15/50] x86: Add a handoff header file

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add an arch-specific handoff header so that we can use the HANDOFF feature
> on x86 devices.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/include/asm/handoff.h | 15 +++
>  1 file changed, 15 insertions(+)
>  create mode 100644 arch/x86/include/asm/handoff.h
>

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


Re: [U-Boot] [PATCH v2 14/50] x86: Support booting with TPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Some boards want to use TPL as the first phase of U-Boot. This allows
> selection of A or B SPL phases, thus allowing the memory init to be
> upgraded in the field.
>
> Add a new Kconfig option for this.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/Kconfig | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2 16/50] x86: broadwell: Improve SDRAM debugging output

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add debugging during SDRAM init so that problems are easier to
> diagnose.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/broadwell/sdram.c | 32 
>  1 file changed, 20 insertions(+), 12 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 20/50] x86: Add support for starting from SPL/TPL

2019-05-01 Thread Bin Meng
On Wed, May 1, 2019 at 9:03 PM Bin Meng  wrote:
>
> On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
> >
> > When a previous phase of U-Boot has run we need to adjust the init of
> > subsequent states to avoid messing up the CPU state.
> >
> > Add a new version of the start logic for SPL, when it boots from TPL
> > (start_from tpl.c) and a new version for U-Boot when it boots from SPL.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Add xorl to TPL code also
> > - Update comments in start_from_tpl to correctly explain SPL state
> >
> >  arch/x86/Makefile | 12 ++
> >  arch/x86/cpu/Makefile | 15 +++-
> >  arch/x86/cpu/start_from_spl.S | 71 +++
> >  arch/x86/cpu/start_from_tpl.S | 49 
> >  4 files changed, 146 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/x86/cpu/start_from_spl.S
> >  create mode 100644 arch/x86/cpu/start_from_tpl.S
> >
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH v2 17/50] x86: broadwell: Allow SDRAM init from SPL

2019-05-01 Thread Bin Meng
On Wed, May 1, 2019 at 9:03 PM Bin Meng  wrote:
>
> On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
> >
> > At present, for broadwell, SDRAM is always set up in U-Boot proper since
> > the 64-bit mode (which uses SDRAM init in SPL) is not supported.
> >
> > Update the code to allow SDRAM init in SPL instead so that U-Boot proper
> > can be loaded into SDRAM and run from there. This allows U-Boot to be
> > compressed to reduce space, since it is not necessary to run it directly
> > from flash. It could later allow us to support 64-bit U-Boot on broadwell.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Update commit message to make it clear this patch is just for broadwell
> > - Bring in sdram_console_tx_byte() to allow debugging
> >
> >  arch/x86/cpu/broadwell/Makefile  |   2 +-
> >  arch/x86/cpu/broadwell/northbridge.c | 100 +++
> >  arch/x86/cpu/broadwell/sdram.c   |  93 -
> >  3 files changed, 101 insertions(+), 94 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH v2 18/50] x86: Move init of debug UART to cpu.c

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present the debug UART is set up in sdram.c which is not the best place
> since it has nothing in particular to do with SDRAM. Since we want to
> support initing this in SPL too, move it to a common file.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/broadwell/cpu.c   | 13 +
>  arch/x86/cpu/broadwell/sdram.c | 11 ---
>  2 files changed, 13 insertions(+), 11 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 19/50] x86: broadwell: Split CPU init

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Split the CPU init into two parts - the 'full' init which happens in the
> first U-Boot phase, and the rest of the init that happens on subsequent
> stages.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/broadwell/Makefile   |   1 +
>  arch/x86/cpu/broadwell/cpu.c  | 673 -
>  arch/x86/cpu/broadwell/cpu_full.c | 694 ++
>  3 files changed, 695 insertions(+), 673 deletions(-)
>  create mode 100644 arch/x86/cpu/broadwell/cpu_full.c
>

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


Re: [U-Boot] [PATCH v2 21/50] x86: Allow 16-bit init to be in TPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present we support having 16-bit init be in SPL or U-Boot proper, but
> not TPL. Add support for this so that TPL can boot.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  Makefile   |  1 +
>  arch/x86/Makefile  |  4 ++--
>  arch/x86/cpu/intel_common/Makefile |  2 +-
>  arch/x86/cpu/u-boot-spl.lds|  2 +-
>  scripts/Makefile.spl   | 10 +-
>  5 files changed, 14 insertions(+), 5 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 22/50] x86: broadwell: Allow booting from SPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present broadwell only supports booting straight into U-Boot proper.
> Add a separate init file to boot from SPL into U-Boot proper, and select
> it when SPL is in use.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/broadwell/Makefile   | 15 +++
>  arch/x86/cpu/broadwell/cpu_from_spl.c | 63 +++
>  2 files changed, 78 insertions(+)
>  create mode 100644 arch/x86/cpu/broadwell/cpu_from_spl.c
>

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


Re: [U-Boot] [PATCH v2 25/50] x86: Support saving MRC data from SPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> When SPL is used to set up the memory controller we want to save the MRC
> data in SPL to avoid needing to pass it up to U-Boot proper to save. Add a
> function to handle that.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/include/asm/mrccache.h | 11 ++
>  arch/x86/lib/mrccache.c | 36 -
>  2 files changed, 38 insertions(+), 9 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 24/50] x86: Add common Intel code for SPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add an implementation of arch_cpu_init_f() so that the x86 SPL code builds
> and identifies the CPU.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/intel_common/Makefile   |  6 ++
>  arch/x86/cpu/intel_common/cpu_from_spl.c | 27 
>  2 files changed, 33 insertions(+)
>  create mode 100644 arch/x86/cpu/intel_common/cpu_from_spl.c
>

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


Re: [U-Boot] [PATCH v2 23/50] x86: broadwell: Select refcode and CPU code for SPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Allow broadwell to build for SPL and include the reference code.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/broadwell/Makefile | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 26/50] x86: Add a simple TPL implementation

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add the required CPU code so that TPL builds correctly. Also update the
> SPL code to deal with being booted from TPL.
>
> Reviewed-by: Bin Meng 
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/x86/include/asm/spl.h|  17 -
>  arch/x86/lib/Makefile |   9 ++-
>  arch/x86/lib/spl.c|  44 ++-
>  arch/x86/lib/tpl.c| 118 ++
>  include/configs/chromebook_link.h |   3 -
>  include/configs/qemu-x86.h|   3 -
>  6 files changed, 183 insertions(+), 11 deletions(-)
>  create mode 100644 arch/x86/lib/tpl.c
>

This patch does not apply cleanly.

Applying: x86: Add a simple TPL implementation
error: patch failed: include/configs/chromebook_link.h:20
error: include/configs/chromebook_link.h: patch does not apply
error: patch failed: include/configs/qemu-x86.h:37
error: include/configs/qemu-x86.h: patch does not apply
Patch failed at 0001 x86: Add a simple TPL implementation

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


Re: [U-Boot] [PATCH v2 27/50] x86: mrccache: Add more debugging

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> When the MRC cache fails to save it is useful to have some debugging info
> to indicate what when wrong. Add some more debug() calls.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/lib/mrccache.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 29/50] x86: pch: Add an ioctl to read power-management info

2019-05-01 Thread Bin Meng
On Wed, May 1, 2019 at 9:42 PM Bin Meng  wrote:
>
> On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
> >
> > Add a new ioctl() request to read information about the power-management
> > system. This can be used to power off the device.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Add new patch to add an ioctl to read power-management info
> >
> >  include/pch.h | 18 ++
> >  1 file changed, 18 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH v2 30/50] x86: ivybridge: Implement PCH_REQ_PMBASE_INFO

2019-05-01 Thread Bin Meng
On Wed, May 1, 2019 at 9:42 PM Bin Meng  wrote:
>
> On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
> >
> > Implement this ioctl() to support power off.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Add new patch to implement PCH_REQ_PMBASE_INFO on ivybridge
> >
> >  arch/x86/cpu/ivybridge/bd82x6x.c | 15 +++
> >  1 file changed, 15 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH v2 33/50] x86: Support TPL in Intel common code

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Update the Makefie rules to ensure that the correct files are built when
> TPL is being used.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/intel_common/Makefile | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 31/50] x86: broadwell: Implement PCH_REQ_PMBASE_INFO

2019-05-01 Thread Bin Meng
On Wed, May 1, 2019 at 10:50 PM Bin Meng  wrote:
>
> On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
> >
> > Implement this ioctl() to support power off.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v2:
> > - Add new patch to implement PCH_REQ_PMBASE_INFO on broadwell
> >
> >  arch/x86/cpu/broadwell/pch.c | 25 +
> >  1 file changed, 25 insertions(+)
> >
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH v2 35/50] x86: Don't generate a bootstage report in SPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> This report is normally generated by U-Boot proper. Correct the condition
> here so that it respects the Kconfig options for bootstage.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/lib/bootm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2 34/50] x86: Don't set up MTRRs in SPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> The MTRRs are normally set up in U-Boot proper, so avoid setting them up
> in SPL as well.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/lib/init_helpers.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2 36/50] x86: Support PCI VGA ROM when TPL is used

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> When TPL is in use, U-Boot proper should support initing the VGA ROM even
> though the 32-bit init portion is in SPL. Update the condition to handle
> this.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  drivers/pci/pci_rom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2 37/50] x86: sysreset: Implement the get_last() method

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add a default implementation of this method which always indicates that
> the last reset was a power-on reset. This is the most likely type of reset
> and without a PCH-specific driver we cannot determine any other type.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/sysreset/sysreset_x86.c | 6 ++
>  1 file changed, 6 insertions(+)
>

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


Re: [U-Boot] [PATCH v3] Convert CONFIG_SUPPORT_EMMC_BOOT to Kconfig

2019-05-01 Thread Alex Kiernan
On Wed, May 1, 2019 at 3:49 PM Tom Rini  wrote:
>
> On Wed, May 01, 2019 at 07:58:27AM +, Alex Kiernan wrote:
> > This converts the following to Kconfig:
> >CONFIG_SUPPORT_EMMC_BOOT
> >
> > As requested by Michal Simek , these boards
> > have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated:
> >
> >   xilinx_zynqmp_zc1275_revB
> >   xilinx_zynqmp_zc1751_xm018_dc4
> >   xilinx_zynqmp_zc1751_xm019_dc5
> >   xilinx_zynqmp_zcu100_revC
> >   xilinx_zynqmp_zcu102_rev1_0
> >   xilinx_zynqmp_zcu102_revA
> >   xilinx_zynqmp_zcu102_revB
> >   xilinx_zynqmp_zcu104_revA
> >   xilinx_zynqmp_zcu104_revC
> >   xilinx_zynqmp_zcu106_revA
> >   xilinx_zynqmp_zcu111_revA
> >
> > Signed-off-by: Alex Kiernan 
> > Acked-by: Lukasz Majewski 
> > Acked-by: Patrick Delaunay 
> > Acked-by: Ramon Fried 
> > Reviewed-by: Andy Shevchenko 
> > Tested-by: Sébastien Szymanski 
> > ---
> > Green travis build:
> >
> > https://travis-ci.org/akiernan/u-boot/builds/526591535
> >
> > Testing for configuration changes shows just the expected xilinx_zynqmp
> > boards:
>
> So, FWIW, what I do (and will do for this patch when I check it out
> before pushing) ends up as:
> $ export SOURCE_DATE_EPOCH=`date +%s`
> $ ./tools/buildman/buildman -o /tmp/test -b master --force-build --step 0 \
>   -SCdvel \
>   'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv'
> $ ./tools/buildman/buildman -o /tmp/test -b master --step 0 -Ssdel \
>   'arc|arm|sandbox|x86|aarch64|powerpc|m68k|nios2|nds32|sh|mips|xtensa|riscv'
>
> With the patch applied in some branch that has 'master' as the upstream.
> This is basically a world-build and will size compare before/after,
> noting changes.  If I see a size difference (outside of a few boards
> that include the config in the binary and so grow slightly on
> conversions), I use:
> $ export SOURCE_DATE_EPOCH=`date +%s`
> $ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SBCdevlk BOARD
> $ ./tools/buildman/buildman -o /tmp/brd -b master --step 0 -SsBdevlk BOARD
>
> Which probably has a few more flags than required but will also tell
> which functions within the binary have changed and so a good place to
> hunt down what didn't convert correctly and why.
>

That's a useful set of snippets - thanks!

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


Re: [U-Boot] [PATCH v2 39/50] x86: samus: Update device tree for SPL

2019-05-01 Thread Bin Meng
Hi Simon,

On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add tags to allow required nodes to be present in SPL / TPL. Also enable
> the sysreset driver.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  arch/x86/dts/chromebook_samus.dts | 38 +++
>  1 file changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/dts/chromebook_samus.dts 
> b/arch/x86/dts/chromebook_samus.dts
> index 35211ed81b1..6664c3b7d36 100644
> --- a/arch/x86/dts/chromebook_samus.dts
> +++ b/arch/x86/dts/chromebook_samus.dts
> @@ -17,6 +17,7 @@
> spi0 = &spi;
> usb0 = &usb_0;
> usb1 = &usb_1;
> +   cros-ec0 = &cros_ec;
> };
>
> config {
> @@ -73,6 +74,7 @@
>
> /* Put this first: it is the default */
> gpio_unused: gpio-unused {
> +   u-boot,dm-pre-reloc;
> mode-gpio;
> direction = ;
> owner = ;
> @@ -80,6 +82,7 @@
> };
>
> gpio_acpi_sci: acpi-sci {
> +   u-boot,dm-pre-reloc;
> mode-gpio;
> direction = ;
> invert;
> @@ -87,6 +90,7 @@
> };
>
> gpio_acpi_smi: acpi-smi {
> +   u-boot,dm-pre-reloc;
> mode-gpio;
> direction = ;
> invert;
> @@ -94,12 +98,14 @@
> };
>
> gpio_input: gpio-input {
> +   u-boot,dm-pre-reloc;
> mode-gpio;
> direction = ;
> owner = ;
> };
>
> gpio_input_invert: gpio-input-invert {
> +   u-boot,dm-pre-reloc;
> mode-gpio;
> direction = ;
> owner = ;
> @@ -107,9 +113,11 @@
> };
>
> gpio_native: gpio-native {
> +   u-boot,dm-pre-reloc;
> };
>
> gpio_out_high: gpio-out-high {
> +   u-boot,dm-pre-reloc;
> mode-gpio;
> direction = ;
> output-value = <1>;
> @@ -118,6 +126,7 @@
> };
>
> gpio_out_low: gpio-out-low {
> +   u-boot,dm-pre-reloc;
> mode-gpio;
> direction = ;
> output-value = <0>;
> @@ -126,6 +135,7 @@
> };
>
> gpio_pirq: gpio-pirq {
> +   u-boot,dm-pre-reloc;
> mode-gpio;
> direction = ;
> owner = ;
> @@ -133,6 +143,7 @@
> };
>
> soc_gpio@0 {
> +   u-boot,dm-pre-reloc;
> config =
> <0 &gpio_unused 0>, /* unused */
> <1 &gpio_unused 0>, /* unused */
> @@ -250,8 +261,10 @@
> spd {
> #address-cells = <1>;
> #size-cells = <0>;
> +   u-boot,dm-pre-reloc;
> samsung_4 {
> reg = <6>;
> +   u-boot,dm-pre-reloc;
> data = [91 20 f1 03 04 11 05 0b
> 03 11 01 08 0a 00 50 01
> 78 78 90 50 90 11 50 e0
> @@ -291,6 +304,7 @@
>  * columns 10, density 4096 mb, x32
>  */
> reg = <8>;
> +   u-boot,dm-pre-reloc;
> data = [91 20 f1 03 04 11 05 0b
> 03 11 01 08 0a 00 50 01
> 78 78 90 50 90 11 50 e0
> @@ -326,6 +340,7 @@
> };
> samsung_8 {
> reg = <10>;
> +   u-boot,dm-pre-reloc;
> data = [91 20 f1 03 04 12 05 0a
> 03 11 01 08 0a 00 50 01
> 78 78 90 50 90 11 50 e0
> @@ -365,6 +380,7 @@
>  * columns 11, density 4096 mb, x16
>  */
> reg = <12>;
> +   

Re: [U-Boot] [PATCH v2 41/50] x86: Update device tree for TPL

2019-05-01 Thread Bin Meng
Hi Simon,

On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add TPL binaries to the device x86 binman desciption. When enabled, TPL
> will start first, doing the 16-bit init, then jump to SPL and finally
> U-Boot proper.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/x86/dts/u-boot.dtsi | 26 --
>  1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
> index 1050236330a..70e9c8f7acd 100644
> --- a/arch/x86/dts/u-boot.dtsi
> +++ b/arch/x86/dts/u-boot.dtsi
> @@ -22,7 +22,21 @@
> filename = CONFIG_INTEL_ME_FILE;
> };
>  #endif
> -#ifdef CONFIG_SPL
> +#ifdef CONFIG_TPL
> +   u-boot-spl {
> +   offset = ;
> +   };
> +   u-boot-spl-dtb {
> +   };
> +   u-boot-tpl-with-ucode-ptr {
> +   offset = ;
> +   };
> +   u-boot-tpl-dtb {
> +   };

nits: since TPL starts before SPL, can we put the TPL* nodes before SPL* nodes?

> +   u-boot {
> +   offset = ;
> +   };
> +#elif defined(CONFIG_SPL)
> u-boot-spl-with-ucode-ptr {
> offset = ;
> };
> @@ -31,7 +45,11 @@
> type = "u-boot-dtb-with-ucode";
> };
> u-boot {
> +#if CONFIG_SYS_TEXT_BASE == 0x111

The magic number comparison does not look good.

> offset = <0xfff0>;
> +#else
> +   offset = ;
> +#endif
> };
>  #else
> u-boot-with-ucode-ptr {
> @@ -77,7 +95,11 @@
> offset = ;
> };
>  #endif
> -#ifdef CONFIG_SPL
> +#ifdef CONFIG_TPL
> +   x86-start16-tpl {
> +   offset = ;
> +   };
> +#elif defined(CONFIG_SPL)
> x86-start16-spl {
> offset = ;
> };
> --

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


Re: [U-Boot] [PATCH v2 45/50] Revert "pci: Scale MAX_PCI_REGIONS based on CONFIG_NR_DRAM_BANKS"

2019-05-01 Thread Bin Meng
+Thierry

On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> This reverts commit aec4298ccb337106fd0115b91d846a022fdf301d.
>
> Unfortunately this has a dramatic impact on the pre-relocation memory
> used on x86 platforms (increasing it by 2KB) since it increases the
> overhead for each PCI device from 220 bytes to 412 bytes.
>
> The offending line is in UCLASS_DRIVER(pci):
>
> .per_device_auto_alloc_size = sizeof(struct pci_controller),
>
> This means that all PCI devices have the controller struct associated
> with them. The solution is to move the regions[] member out of the array,
> makes its size dynamic, or split UCLASS_PCI into controllers and
> non-controllers, as the comment suggests.
>
> For now, revert the commit to get things running again.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  include/pci.h | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 46/50] x86: Enable the RTC on all boards

2019-05-01 Thread Bin Meng
Hi Simon,

On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> With the move to Kconfig this option should be set in Kconfig, not in the
> config header file. Move it.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add new patch to enable the RTC in Kconfig
>
>  arch/Kconfig  | 1 +
>  configs/chromebook_link_defconfig | 1 +
>  include/configs/x86-common.h  | 1 -
>  3 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index a1d1ac301d6..2a93b72dbc4 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -165,6 +165,7 @@ config X86
> imply USB_ETHER_SMSC95XX
> imply USB_HOST_ETHER
> imply PCH
> +   imply RTC_MC146818
>
> # Thing to enable for when SPL/TPL are enabled: SPL
> imply SPL_DM
> diff --git a/configs/chromebook_link_defconfig 
> b/configs/chromebook_link_defconfig
> index 6058dfaf0f2..b1c5095ec92 100644
> --- a/configs/chromebook_link_defconfig
> +++ b/configs/chromebook_link_defconfig
> @@ -53,6 +53,7 @@ CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_INTEL=y
>  CONFIG_CROS_EC=y
>  CONFIG_CROS_EC_LPC=y
> +CONFIG_RTC_MC146818=y

This has been implied in arch/Kconfig above, why adding another one here?

>  CONFIG_SYS_NS16550=y
>  CONFIG_SOUND=y
>  CONFIG_SPI=y

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


Re: [U-Boot] [PATCH v2 47/50] x86: Update the memory map a little

2019-05-01 Thread Bin Meng
Hi Simon,

On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> The memory map currently omits the environment and the MRC region. Add
> these in for completeness.
>

I think the commit tile should be updated to add the "samus" tag.

> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  doc/README.x86 | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH v2 48/50] x86: broadwell: Update PCH to work in TPL

2019-05-01 Thread Bin Meng
On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> The early init should only happen once. Update the probe method to
> deal with TPL, SPL and U-Boot proper.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add a new patch to update PCH to work in TPL
>
>  arch/x86/cpu/broadwell/pch.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 49/50] x86: Add a way to jump from TPL to SPL

2019-05-01 Thread Bin Meng
Hi Simon,

On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:
>
> When TPL finishes it needs to jump to SPL with the stack set up correctly.
> Add a function to handle this.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add a new patch allowing jumping from TPL to SPL
>
>  arch/x86/cpu/start.S | 13 +
>  1 file changed, 13 insertions(+)
>

Reviewed-by: Bin Meng 

But I don't see any patch in this series that makes use of this new
jump_to_spl()?

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


Re: [U-Boot] [PATCH v2 00/50] x86: Add support for booting from TPL

2019-05-01 Thread Bin Meng
Hi Simon,

On Fri, Apr 26, 2019 at 11:59 AM Simon Glass  wrote:
>
> At present SPL is used on 64-bit platforms, to allow SPL to be built as
> a 32-bit program and U-Boot proper to be built as 64-bit.
>
> However it is useful to be able to use SPL on any x86 platform, where
> U-Boot needs to be updated in the field. Then SPL can select which U-Boot
> to run (A or B) and most of the code can be updated. Similarly, using TPL
> allows both SPL and U-Boot to be updated. This is the best approach, since
> it means that all of U-Boot proper as well as SPL (in particular SDRAM
> init) can be updated in the field. This provides for the smallest possible
> amount of read-only (non-updateable) code: just the TPL code.
>
> This series contains a number of changes to allow x86 boards to use TPL,
> SPL and U-Boot proper. As a test, it is enabled for samus with a new
> chromebook_samus_tpl board.
>

I've applied 32 patches in this series to u-boot-x86/master. Remaining
patches need to rebase on that.

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


[U-Boot] [PATCH 1/1] efi_selftest: test exit_data

2019-05-01 Thread Heinrich Schuchardt
Amend the unit test 'start image exit' to transfer a string as exit data.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_selftest.h  |  2 +-
 lib/efi_selftest/efi_selftest_miniapp_exit.c| 17 -
 lib/efi_selftest/efi_selftest_startimage_exit.c | 15 ++-
 3 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/include/efi_selftest.h b/include/efi_selftest.h
index 49d3d6d0b4..dd42e49023 100644
--- a/include/efi_selftest.h
+++ b/include/efi_selftest.h
@@ -16,7 +16,7 @@

 #define EFI_ST_SUCCESS 0
 #define EFI_ST_FAILURE 1
-
+#define EFI_ST_SUCCESS_STR L"SUCCESS"
 /*
  * Prints a message.
  */
diff --git a/lib/efi_selftest/efi_selftest_miniapp_exit.c 
b/lib/efi_selftest/efi_selftest_miniapp_exit.c
index b3ca109d81..6b5cfb01cf 100644
--- a/lib/efi_selftest/efi_selftest_miniapp_exit.c
+++ b/lib/efi_selftest/efi_selftest_miniapp_exit.c
@@ -9,7 +9,7 @@
  */

 #include 
-#include 
+#include 

 static efi_guid_t loaded_image_protocol_guid = EFI_LOADED_IMAGE_PROTOCOL_GUID;

@@ -66,15 +66,22 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
 struct efi_system_table *systable)
 {
struct efi_simple_text_output_protocol *con_out = systable->con_out;
-   efi_status_t ret = EFI_UNSUPPORTED;
+   efi_status_t ret;
+   u16 text[] = EFI_ST_SUCCESS_STR;

con_out->output_string(con_out, L"EFI application calling Exit\n");

-   if (check_loaded_image_protocol(handle, systable) != EFI_SUCCESS)
+   if (check_loaded_image_protocol(handle, systable) != EFI_SUCCESS) {
+   con_out->output_string(con_out,
+  L"Loaded image protocol missing\n");
ret = EFI_NOT_FOUND;
+   goto out;
+   }

-   /* The return value is checked by the calling test */
-   systable->boottime->exit(handle, ret, 0, NULL);
+   /* This return value is expected by the calling test */
+   ret = EFI_UNSUPPORTED;
+out:
+   systable->boottime->exit(handle, ret, sizeof(text), text);

/*
 * This statement should not be reached.
diff --git a/lib/efi_selftest/efi_selftest_startimage_exit.c 
b/lib/efi_selftest/efi_selftest_startimage_exit.c
index fa4b7d4a9b..96049dea86 100644
--- a/lib/efi_selftest/efi_selftest_startimage_exit.c
+++ b/lib/efi_selftest/efi_selftest_startimage_exit.c
@@ -123,6 +123,9 @@ static int execute(void)
 {
efi_status_t ret;
efi_handle_t handle;
+   efi_uintn_t exit_data_size = 0;
+   u16 *exit_data = NULL;
+   u16 expected_text[] = EFI_ST_SUCCESS_STR;

ret = boottime->load_image(false, image_handle, NULL, image,
   img.length, &handle);
@@ -130,11 +133,21 @@ static int execute(void)
efi_st_error("Failed to load image\n");
return EFI_ST_FAILURE;
}
-   ret = boottime->start_image(handle, NULL, NULL);
+   ret = boottime->start_image(handle, &exit_data_size, &exit_data);
if (ret != EFI_UNSUPPORTED) {
efi_st_error("Wrong return value from application\n");
return EFI_ST_FAILURE;
}
+   if (!exit_data || exit_data_size != sizeof(expected_text) ||
+   efi_st_memcmp(exit_data, expected_text, sizeof(expected_text))) {
+   efi_st_error("Incorrect exit data\n");
+   return EFI_ST_FAILURE;
+   }
+   ret = boottime->free_pool(exit_data);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("Failed to free exit data\n");
+   return EFI_ST_FAILURE;
+   }

return EFI_ST_SUCCESS;
 }
--
2.20.1

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


Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.

2019-05-01 Thread Atish Patra

On 5/1/19 3:34 AM, Marek Vasut wrote:

On 5/1/19 12:06 AM, Atish Patra wrote:

On 4/30/19 2:42 PM, Marek Vasut wrote:

On 4/30/19 10:38 PM, Atish Patra wrote:

On 4/30/19 12:11 PM, Marek Vasut wrote:

On 4/30/19 8:13 PM, Atish Patra wrote:

On 4/30/19 2:52 AM, Marek Vasut wrote:

On 4/30/19 3:27 AM, Atish Patra wrote:

[...]


Yes. FIT image parsing can be done in that way. However, the idea
was
here to load Image.gz directly. Image.gz is default compressed
Linux
kernel image format in RISC-V.


Sigh, and the image header is compressed as well, so there's no
way to
identify the image format, right ? And there's no decompressor, so
the
dcompressing has to be done by bootloader, which would need some
sort of
very smart way of figuring out which exact compression method is
used ?


Yes. Image.gz is always gunzip. So checking first two bytes is
enough to
confirm that it is a gz file.


What happens once people start feeding it more exotic compression
methods, like LZ4 or LZO or LZMA for example ?



booti command help will clearly state that it can only boot kernel
from
Image or Image.gz.

static char booti_help_text[] =
    "[addr [initrd[:size]] [fdt]]\n"
-    "    - boot arm64 Linux Image stored in memory\n"
+    "    - boot arm64 Linux Image or riscv Linux Image/Image.gz
stored
in memory\n"


Obvious question -- does this Image.gz stuff apply to arm64 ?



arm64 builds Image.gz but booti for arm64 doesn't use it. I guess
Image.gz can be used in FIT image for ARM64 but I am not sure which
platform actually uses it.

This patch only enables support for RISC-V.


Can't this be made generic ?



I think so if I just move the gzip detection and decompression code to
cmd/booti.c.

I will update the v3 patch with this.


Nice, thanks.

But since you're basically implementing file(1)-lite, I wonder whether
there isn't similar code somewhere in u-boot already.

I was hoping to find one as well. But I couldn't. I can add a generic gz 
detection function(same file(1)-lite approach) to a lib/gunzip.c


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


[U-Boot] WaRP7 nok on master

2019-05-01 Thread Pierre-Jean Texier

Hi Fabio, Stefano,

Just FYI, I just tested the U-Boot master branch (with u-boot-imx merges).
And I have some problems when the WaRP7 boot-up.
In fact, no output...

However, on u-boot-imx, everything works well (tags/u-boot-imx-20190426).

After some manipulation with git bisect, it appears that the problem 
comes from commit [1].
So, with a git revert 3a7c45f6a7725808e2e82908be4bc90d4d78e737, 
everything works again.


Without this revert, the WaRP7 is not
functional (also the pico-pi i.MX7 if DM_SERIAL is implemented, tested 
by Joris in CC).




Thanks

BR
/Pierre-Jean

[1] 
https://github.com/trini/u-boot/commit/3a7c45f6a7725808e2e82908be4bc90d4d78e737


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


Re: [U-Boot] [PATCH v2 28/50] x86: sysreset: Separate out the EFI code

2019-05-01 Thread Heinrich Schuchardt

On 5/1/19 3:42 PM, Bin Meng wrote:

+Heinrich,

On Fri, Apr 26, 2019 at 12:00 PM Simon Glass  wrote:


The EFI implementation of reset sits inside the driver and is called
directly from outside the driver, breaking the normal driver-model
conventions. Worse, it passed NULL as the device pointer, hoping that
the called function won't use it, which breaks as soon as code is added
to use it.

Separate out the implementation to improve the situation enough to allow
a future patch to add new sysreset features.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add new patch to separate out the EFI code in sysreset

  drivers/sysreset/sysreset_x86.c | 16 +++-
  1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
index 009f3766027..d484ec5de49 100644
--- a/drivers/sysreset/sysreset_x86.c
+++ b/drivers/sysreset/sysreset_x86.c
@@ -12,8 +12,7 @@
  #include 
  #include 

-static __efi_runtime int x86_sysreset_request(struct udevice *dev,
- enum sysreset_t type)


I remember last time I tried when booting Linux from EFI loader on
U-Boot, calling from kernel into the EFI runtime was broken. Not sure
what the latest status is.


I have no x86 system using U-Boot. On ARM I am not aware of problems.

Last year I had no success booting up qemu-x86_defconfig with Linux via
EFI. Maybe I should retry.

Best regards

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


Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y

2019-05-01 Thread Eugeniu Rosca
Hi Heinrich,

Thank you for reviewing this series.

On Tue, Apr 30, 2019 at 09:07:09PM +0200, Heinrich Schuchardt wrote:
[..]
> This patch may ameliorate the situation for GUIDs a bit. But I dislike:

In general, we can find reasons to dislike anything, since there is room
for improvement in virtually anything.

> 
> - This patch is a uuid only solution to introduce time ticks as source
>   of entropy.

I would like to clarify once again what this patch is about. It _fixes_
(hence I will rewrite the summary line in the next patch revision) a
concrete real-life problem of providing repeatable (not predictable -
which implies some effort in my mind - but literally repeatable) uuid
values on enabling CONFIG_RANDOM_UUID.

It is my understanding that CONFIG_RANDOM_UUID (based on its name
and help message) does promise random uuids to the user. If so, then
U-Boot simply breaks this promise.

While doing additional research on PRNG, it looks to me that there is
an established class of PRNG-specific problems, commonly known as
"unseeded randomness" for which I am also able to find below CVE/CWE:
 - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0285
   ("CVE-2015-0285 openssl: handshake with unseeded PRNG")
 - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-9019
   ("CVE-2015-9019 libxslt: math.random() in xslt uses unseeded randomness")
 - https://cwe.mitre.org/data/definitions/336.html
   ("CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)")

The above tells me that using the same seed yields the same sequence
of random numbers. That's precisely the topic of this patch: simply
switching from unseeded PRNG to seeded PRNG.

And yes, this patch is deliberately limited to UUID naming function,
since it is lib/uuid's responsibility to seed the PRNG. The same is
true for other callers of rand() and rand_r(). All of them seed the
PRNG prior to getting a random value from it.

> - With timer ticks you possibly introduce very little entropy.

Theoretically, yes. Practically, the improvement to the current state
of affairs is huge and this has been testified by the test results
linked in the description. 

Again, this patch is not about improving the random pattern of the UUID
values (sorry for the misleading title). It is really about _enabling_
any kind of randomness in those values at all.

> - Our random number generator with only 32 state bits remains
>   sub-standard.

I believe this is orthogonal to my patch and can be improved
independently. In addition, whatever is the bit-width of U-Boot PRNG
(I can find shootouts between various 64/128/256-bit PRNG) its essence
will not change. It will remain a deterministic number generator,
whose randomness will still be dictated by the seed.

> 
> This is the current situation:
> 
> net/bootp.c uses the MAC address to seed the random number generator and
> uses random numbers for defining waits.
> 
> lib/uuid.c is using it for UUID generation.

I can see that rfc4122 suggests including MAC address in the UUID, but
it also warns that MAC address could be unavailable:

 ---
   For systems with no IEEE address, a randomly or pseudo-randomly
   generated value may be used;
 ---

The guess is right. Some SoCs like R-Car3 (in contrast to e.g. i.MX6)
don't provide any OTP memory/register containing their unique MAC
address. Needless to say some machines would never connect to IEEE
network. So, it looks to me that MAC address cannot be taken as
consistent source of entropy for UUID in U-Boot.

> 
> In the UEFI sub-system I would like to implement the EFI_RNG_PROTOCOL.
> Linux uses it for randomizing memory layout. iPXE needs it for secure
> network connections. This requires a good random number generator with
> sufficient entropy.
> 
> We already have implemented a single hardware random number generator in
> drivers/crypto/ace_sha.c (CONFIG_EXYNOS_ACE_SHA).
> 
> Many other CPUs come with a hardware random number generator. In Linux's
> drivers/char/hw_random/ I found, e.g.
> 
> - meson-rng.c (Amlogic)
> - mtk-rng.c (MediaTek)
> - st-rng.c (STMicroelectronics)
> - imx-rng.c (Freescale)

To the best of my knowledge, there is no HW RNG on R-Car3, so our only
option is currently U-Boot PRNG.

> 
> I think we should have a u-class for hardware RNGs as one source of entropy.
> 
> I would like a random number generator with a high number of state bits
> (> 127) that we initialize with hardware RNG bits and other sources of
> entropy. A nice discussion of how Linux does it can be found in [1].

All sound like future topics to me, orthogonal to this patch.
Let me know if I misunderstood anything. TIA!

> 
> Best regards
> 
> Heinrich
> 
> [1]
> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf
> 

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


Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y

2019-05-01 Thread Tom Rini
On Wed, May 01, 2019 at 09:08:31PM +0200, Eugeniu Rosca wrote:
> Hi Heinrich,
> 
> Thank you for reviewing this series.
> 
> On Tue, Apr 30, 2019 at 09:07:09PM +0200, Heinrich Schuchardt wrote:
> [..]
> > This patch may ameliorate the situation for GUIDs a bit. But I dislike:
> 
> In general, we can find reasons to dislike anything, since there is room
> for improvement in virtually anything.
> 
> > 
> > - This patch is a uuid only solution to introduce time ticks as source
> >   of entropy.
> 
> I would like to clarify once again what this patch is about. It _fixes_
> (hence I will rewrite the summary line in the next patch revision) a
> concrete real-life problem of providing repeatable (not predictable -
> which implies some effort in my mind - but literally repeatable) uuid
> values on enabling CONFIG_RANDOM_UUID.
> 
> It is my understanding that CONFIG_RANDOM_UUID (based on its name
> and help message) does promise random uuids to the user. If so, then
> U-Boot simply breaks this promise.
> 
> While doing additional research on PRNG, it looks to me that there is
> an established class of PRNG-specific problems, commonly known as
> "unseeded randomness" for which I am also able to find below CVE/CWE:
>  - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0285
>("CVE-2015-0285 openssl: handshake with unseeded PRNG")
>  - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-9019
>("CVE-2015-9019 libxslt: math.random() in xslt uses unseeded randomness")
>  - https://cwe.mitre.org/data/definitions/336.html
>("CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)")
> 
> The above tells me that using the same seed yields the same sequence
> of random numbers. That's precisely the topic of this patch: simply
> switching from unseeded PRNG to seeded PRNG.
> 
> And yes, this patch is deliberately limited to UUID naming function,
> since it is lib/uuid's responsibility to seed the PRNG. The same is
> true for other callers of rand() and rand_r(). All of them seed the
> PRNG prior to getting a random value from it.
> 
> > - With timer ticks you possibly introduce very little entropy.
> 
> Theoretically, yes. Practically, the improvement to the current state
> of affairs is huge and this has been testified by the test results
> linked in the description. 
> 
> Again, this patch is not about improving the random pattern of the UUID
> values (sorry for the misleading title). It is really about _enabling_
> any kind of randomness in those values at all.
> 
> > - Our random number generator with only 32 state bits remains
> >   sub-standard.
> 
> I believe this is orthogonal to my patch and can be improved
> independently. In addition, whatever is the bit-width of U-Boot PRNG
> (I can find shootouts between various 64/128/256-bit PRNG) its essence
> will not change. It will remain a deterministic number generator,
> whose randomness will still be dictated by the seed.
> 
> > 
> > This is the current situation:
> > 
> > net/bootp.c uses the MAC address to seed the random number generator and
> > uses random numbers for defining waits.
> > 
> > lib/uuid.c is using it for UUID generation.
> 
> I can see that rfc4122 suggests including MAC address in the UUID, but
> it also warns that MAC address could be unavailable:
> 
>  ---
>For systems with no IEEE address, a randomly or pseudo-randomly
>generated value may be used;
>  ---
> 
> The guess is right. Some SoCs like R-Car3 (in contrast to e.g. i.MX6)
> don't provide any OTP memory/register containing their unique MAC
> address. Needless to say some machines would never connect to IEEE
> network. So, it looks to me that MAC address cannot be taken as
> consistent source of entropy for UUID in U-Boot.

Indeed, we have a lot of platforms where the MAC is not a great source.

> > In the UEFI sub-system I would like to implement the EFI_RNG_PROTOCOL.
> > Linux uses it for randomizing memory layout. iPXE needs it for secure
> > network connections. This requires a good random number generator with
> > sufficient entropy.
> > 
> > We already have implemented a single hardware random number generator in
> > drivers/crypto/ace_sha.c (CONFIG_EXYNOS_ACE_SHA).
> > 
> > Many other CPUs come with a hardware random number generator. In Linux's
> > drivers/char/hw_random/ I found, e.g.
> > 
> > - meson-rng.c (Amlogic)
> > - mtk-rng.c (MediaTek)
> > - st-rng.c (STMicroelectronics)
> > - imx-rng.c (Freescale)
> 
> To the best of my knowledge, there is no HW RNG on R-Car3, so our only
> option is currently U-Boot PRNG.

And we have a lot of systems without HW RNG.

> > I think we should have a u-class for hardware RNGs as one source of entropy.
> > 
> > I would like a random number generator with a high number of state bits
> > (> 127) that we initialize with hardware RNG bits and other sources of
> > entropy. A nice discussion of how Linux does it can be found in [1].
> 
> All sound like future topics to me, orthogonal to this patch.
> Let me k

[U-Boot] [v3 PATCH] RISCV: image: Add booti support.

2019-05-01 Thread Atish Patra
This patch adds booti support for RISC-V Linux kernel. The existing
bootm method will also continue to work as it is.

It depends on the following kernel patch which adds the header to the
flat Image. Gzip compressed Image (Image.gz) support is not enabled with
this patch.

https://patchwork.kernel.org/patch/10925543/

Tested on HiFive Unleashed and QEMU.

Signed-off-by: Atish Patra 
--
Changes from v2->v3
1. Updated the image header structure as per kernel patch.
2. Removed Image.gz support as it will be added as separate RFC patch.
---
 arch/riscv/lib/Makefile |  1 +
 arch/riscv/lib/image.c  | 55 +
 cmd/Kconfig |  2 +-
 cmd/booti.c |  8 --
 4 files changed, 63 insertions(+), 3 deletions(-)
 create mode 100644 arch/riscv/lib/image.c

diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 1c332db436a9..6ae6ebbeafda 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -7,6 +7,7 @@
 # Rick Chen, Andes Technology Corporation 
 
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
+obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
 obj-$(CONFIG_CMD_GO) += boot.o
 obj-y  += cache.o
 obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
new file mode 100644
index ..d063beb7dfbe
--- /dev/null
+++ b/arch/riscv/lib/image.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ * Authors:
+ * Atish Patra 
+ * Based on arm/lib/image.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* ASCII version of "RISCV" defined in Linux kernel */
+#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
+
+struct linux_image_h {
+   uint32_tcode0;  /* Executable code */
+   uint32_tcode1;  /* Executable code */
+   uint64_ttext_offset;/* Image load offset */
+   uint64_timage_size; /* Effective Image size */
+   uint64_tres1;   /* reserved */
+   uint64_tres2;   /* reserved */
+   uint64_tres3;   /* reserved */
+   uint64_tmagic;  /* Magic number */
+   uint32_tres4;   /* reserved */
+   uint32_tres5;   /* reserved */
+};
+
+int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
+   bool force_reloc)
+{
+   struct linux_image_h *lhdr;
+
+   lhdr = (struct linux_image_h *)map_sysmem(image, 0);
+
+   if (lhdr->magic != LINUX_RISCV_IMAGE_MAGIC) {
+   puts("Bad Linux RISCV Image magic!\n");
+   return -EINVAL;
+   }
+
+   if (lhdr->image_size == 0) {
+   puts("Image lacks image_size field, error!\n");
+   return -EINVAL;
+   }
+   *size = lhdr->image_size;
+   *relocated_addr = gd->ram_base + lhdr->text_offset;
+
+   unmap_sysmem(lhdr);
+
+   return 0;
+}
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 2bdbfcb3d091..d427b66d3714 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -212,7 +212,7 @@ config CMD_BOOTZ
 
 config CMD_BOOTI
bool "booti"
-   depends on ARM64
+   depends on ARM64 || RISCV
default y
help
  Boot an AArch64 Linux Kernel image from memory.
diff --git a/cmd/booti.c b/cmd/booti.c
index 04353b68eccc..c22ba9bae2e4 100644
--- a/cmd/booti.c
+++ b/cmd/booti.c
@@ -77,7 +77,11 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
bootm_disable_interrupts();
 
images.os.os = IH_OS_LINUX;
+   #ifdef CONFIG_RISCV_SMODE
+   images.os.arch = IH_ARCH_RISCV;
+   #elif CONFIG_ARM64
images.os.arch = IH_ARCH_ARM64;
+   #endif
ret = do_bootm_states(cmdtp, flag, argc, argv,
 #ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
  BOOTM_STATE_RAMDISK |
@@ -92,7 +96,7 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 #ifdef CONFIG_SYS_LONGHELP
 static char booti_help_text[] =
"[addr [initrd[:size]] [fdt]]\n"
-   "- boot arm64 Linux Image stored in memory\n"
+   "- boot arm64/riscv Linux Image stored in memory\n"
"\tThe argument 'initrd' is optional and specifies the address\n"
"\tof an initrd in memory. The optional parameter ':size' allows\n"
"\tspecifying the size of a RAW initrd.\n"
@@ -107,5 +111,5 @@ static char booti_help_text[] =
 
 U_BOOT_CMD(
booti,  CONFIG_SYS_MAXARGS, 1,  do_booti,
-   "boot arm64 Linux Image image from memory", booti_help_text
+   "boot arm64/riscv Linux Image image from memory", booti_help_text
 );
-- 
2.21.0

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


Re: [U-Boot] [v3 PATCH] RISCV: image: Add booti support.

2019-05-01 Thread Tom Rini
On Wed, May 01, 2019 at 01:07:31PM -0700, Atish Patra wrote:

> This patch adds booti support for RISC-V Linux kernel. The existing
> bootm method will also continue to work as it is.
> 
> It depends on the following kernel patch which adds the header to the
> flat Image. Gzip compressed Image (Image.gz) support is not enabled with
> this patch.
> 
> https://patchwork.kernel.org/patch/10925543/
> 
> Tested on HiFive Unleashed and QEMU.
> 
> Signed-off-by: Atish Patra 
> --
> Changes from v2->v3
> 1. Updated the image header structure as per kernel patch.
> 2. Removed Image.gz support as it will be added as separate RFC patch.

Reviewed-by: Tom Rini 

-- 
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 u-boot-marvell v2.1 15/15] i2c: mvtwsi: fix reading status register after interrupt

2019-05-01 Thread Marek Behún
The twsi_wait function reads the control register for interrupt flag,
and if interrupt flag is present, it immediately reads status register.

On our device this sometimes causes bad value being read from status
register, as if the value was not yet updated.

My theory is that the controller does approximately this:
  1. sets interrupt flag in control register,
  2. sets the value of status register,
  3. causes an interrupt

In U-Boot we do not use interrupts, so I think that it is possible that
sometimes the status register in the twsi_wait function is read between
points 1 and 2.

The bug does not appear if I add a small delay before reading status
register.

Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i)
function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status
register.

Signed-off-by: Marek Behún 
Acked-by: Heiko Schocher 
Cc: Mario Six 
Cc: Stefan Roese 
Cc: Baruch Siach 
---
 drivers/i2c/mvtwsi.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 74ac0a4aa7..0a2dafcec6 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -271,6 +271,17 @@ static int twsi_wait(struct mvtwsi_registers *twsi, int 
expected_status,
do {
control = readl(&twsi->control);
if (control & MVTWSI_CONTROL_IFLG) {
+   /*
+* On Armada 38x it seems that the controller works as
+* if it first set the MVTWSI_CONTROL_IFLAG in the
+* control register and only after that it changed the
+* status register.
+* This sometimes caused weird bugs which only appeared
+* on selected I2C speeds and even then only sometimes.
+* We therefore add here a simple ndealy(100), which
+* seems to fix this weird bug.
+*/
+   ndelay(100);
status = readl(&twsi->status);
if (status == expected_status)
return 0;
-- 
2.21.0

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


  1   2   >