Re: [U-Boot] [PATCH 07/11] efi_loader: fix events

[Heinrich Schuchardt]

On 10/10/2017 02:23 PM, Rob Clark wrote:

An event can be created with type==0, Shell.efi does this for an event
that is set when Ctrl-C is typed.  So our current approach of having a
fixed set of timer slots, and determining which slots are unused by
type==0 doesn't work so well.  But we don't have any particularly good
reason to have a fixed table of events, so just dynamically allocate
them and keep a list.

Also fixes an incorrect implementation of CheckEvent() which was (a)
incorrectly returning an error if type==0, and (b) didn't handle the
case of an unsignaled event with a notify callback.

With these fixes (plus implementation of SIMPLE_TEXT_INPUT_EX protocol),
Ctrl-C works in Shell.efi.

Signed-off-by: Rob Clark 
---
  include/efi_loader.h  |   1 +
  lib/efi_loader/efi_boottime.c | 217 +-
  2 files changed, 111 insertions(+), 107 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index e6e55d2cb4..2232caca44 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -154,6 +154,7 @@ struct efi_event {
enum efi_timer_delay trigger_type;
bool is_queued;
bool is_signaled;
+   struct list_head link;
  };
  
  
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c

index 39dcc72648..19fafe546c 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -350,11 +350,26 @@ static efi_status_t efi_create_handle(void **handle)
return r;
  }
  
+static LIST_HEAD(efi_events);

+
  /*
- * Our event capabilities are very limited. Only a small limited
- * number of events is allowed to coexist.
+ * Check if a pointer is a valid event.
+ *
+ * It might be nice at some point to extend this to a more general
+ * mechanism to check if pointers passed from the EFI world are
+ * valid objects of a particular type.
   */
-static struct efi_event efi_events[16];
+static bool efi_is_event(const void *obj)
+{
+   struct efi_event *evt;
+
+   list_for_each_entry(evt, _events, link) {
+   if (evt == obj)
+   return true;
+   }
+
+   return false;
+}
  
  /*

   * Create an event.
@@ -377,7 +392,7 @@ efi_status_t efi_create_event(uint32_t type, UINTN 
notify_tpl,
void *context),
  void *notify_context, struct efi_event **event)
  {
-   int i;
+   struct efi_event *evt;
  
  	if (event == NULL)

return EFI_INVALID_PARAMETER;
@@ -389,21 +404,24 @@ efi_status_t efi_create_event(uint32_t type, UINTN 
notify_tpl,
notify_function == NULL)
return EFI_INVALID_PARAMETER;
  
-	for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {

-   if (efi_events[i].type)
-   continue;
-   efi_events[i].type = type;
-   efi_events[i].notify_tpl = notify_tpl;
-   efi_events[i].notify_function = notify_function;
-   efi_events[i].notify_context = notify_context;
-   /* Disable timers on bootup */
-   efi_events[i].trigger_next = -1ULL;
-   efi_events[i].is_queued = false;
-   efi_events[i].is_signaled = false;
-   *event = _events[i];
-   return EFI_SUCCESS;
-   }
-   return EFI_OUT_OF_RESOURCES;
+   evt = calloc(1, sizeof(*evt));
+   if (!evt)
+   return EFI_OUT_OF_RESOURCES;
+
+   evt->type = type;
+   evt->notify_tpl = notify_tpl;
+   evt->notify_function = notify_function;
+   evt->notify_context = notify_context;
+   /* Disable timers on bootup */
+   evt->trigger_next = -1ULL;
+   evt->is_queued = false;
+   evt->is_signaled = false;
+
+   list_add_tail(>link, _events);
+
+   *event = evt;
+
+   return EFI_SUCCESS;
  }
  
  /*

@@ -443,30 +461,31 @@ static efi_status_t EFIAPI efi_create_event_ext(
   */
  void efi_timer_check(void)
  {
-   int i;
+   struct efi_event *evt;
u64 now = timer_get_us();
  
-	for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {

-   if (!efi_events[i].type)
-   continue;
-   if (efi_events[i].is_queued)
-   efi_signal_event(_events[i]);
-   if (!(efi_events[i].type & EVT_TIMER) ||
-   now < efi_events[i].trigger_next)
+   /*
+* TODO perhaps optimize a bit and track the time of next
+* timer to expire?
+*/
+   list_for_each_entry(evt, _events, link) {
+   if (evt->is_queued)
+   efi_signal_event(evt);
+   if (!(evt->type & EVT_TIMER) ||
+   now < evt->trigger_next)
continue;
-   switch (efi_events[i].trigger_type) {
+   switch (evt->trigger_type) {
case EFI_TIMER_RELATIVE:
-   

Re: [U-Boot] [PATCH] spi: kirkwood_spi: implement workaround for FE-9144572

[Chris Packham]

On Fri, Oct 13, 2017 at 2:05 PM, Chris Packham  wrote:
> Erratum NO. FE-9144572: The device SPI interface supports frequencies of
> up to 50 MHz.  However, due to this erratum, when the device core clock
> is 250 MHz and the SPI interfaces is configured for 50MHz SPI clock and
> CPOL=CPHA=1 there might occur data corruption on reads from the SPI
> device.
>
> Implement the workaround by setting the TMISO_SAMPLE value to 0x2
> in the timing1 register.
>
> Signed-off-by: Chris Packham 
> ---

I've based this as much as I can on the equivalent implementation in the
Linux kernel[1], but there are differences in the u-boot spi
infrastructure that means I can't be as specific when qualifying whether
the workaround is needed.

[1] - 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi-orion.c#n248

>
>  arch/arm/include/asm/arch-mvebu/spi.h |  6 
>  drivers/spi/kirkwood_spi.c| 62 
> +--
>  2 files changed, 65 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mvebu/spi.h 
> b/arch/arm/include/asm/arch-mvebu/spi.h
> index 3545aed17347..1de510ea6da9 100644
> --- a/arch/arm/include/asm/arch-mvebu/spi.h
> +++ b/arch/arm/include/asm/arch-mvebu/spi.h
> @@ -57,6 +57,12 @@ struct kwspi_registers {
>  #define KWSPI_TXLSBF   (1 << 13)
>  #define KWSPI_RXLSBF   (1 << 14)
>
> +/* Timing Parameters 1 Register */
> +#define KW_SPI_TMISO_SAMPLE_OFFSET 6
> +#define KW_SPI_TMISO_SAMPLE_MASK   (0x3 << KW_SPI_TMISO_SAMPLE_OFFSET)
> +#define KW_SPI_TMISO_SAMPLE_1  (1 << KW_SPI_TMISO_SAMPLE_OFFSET)
> +#define KW_SPI_TMISO_SAMPLE_2  (2 << KW_SPI_TMISO_SAMPLE_OFFSET)
> +
>  #define KWSPI_IRQUNMASK1 /* unmask SPI interrupt */
>  #define KWSPI_IRQMASK  0 /* mask SPI interrupt */
>  #define KWSPI_SMEMRDIRQ1 /* SerMem data xfer ready irq */
> diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
> index 0c6bd295cde9..7992556d49eb 100644
> --- a/drivers/spi/kirkwood_spi.c
> +++ b/drivers/spi/kirkwood_spi.c
> @@ -243,6 +243,16 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
> bitlen,
>
>  /* Here now the DM part */
>
> +enum mvebu_spi_type {
> +   ORION_SPI,
> +   ARMADA_SPI,
> +};
> +
> +struct mvebu_spi_dev {
> +   enum mvebu_spi_type typ;
> +   boolis_errata_50mhz_ac;
> +};
> +
>  struct mvebu_spi_platdata {
> struct kwspi_registers *spireg;
>  };
> @@ -269,10 +279,30 @@ static int mvebu_spi_set_speed(struct udevice *bus, 
> uint hz)
> return 0;
>  }
>
> +static void
> +mvebu_spi_50mhz_ac_timing_erratum(struct udevice *bus, uint mode)
> +{
> +   struct mvebu_spi_platdata *plat = dev_get_platdata(bus);
> +   struct kwspi_registers *reg = plat->spireg;
> +   u32 data = readl(>timing1);
> +
> +   data &= ~KW_SPI_TMISO_SAMPLE_MASK;
> +
> +   if (CONFIG_SYS_TCLK == 25000 &&
> +   mode & SPI_CPOL &&
> +   mode & SPI_CPHA)
> +   data |= KW_SPI_TMISO_SAMPLE_2;
> +   else
> +   data |= KW_SPI_TMISO_SAMPLE_1;
> +
> +   writel(data, >timing1);
> +}
> +
>  static int mvebu_spi_set_mode(struct udevice *bus, uint mode)
>  {
> struct mvebu_spi_platdata *plat = dev_get_platdata(bus);
> struct kwspi_registers *reg = plat->spireg;
> +   const struct mvebu_spi_dev *drvdata;
> u32 data = readl(>cfg);
>
> data &= ~(KWSPI_CPHA | KWSPI_CPOL | KWSPI_RXLSBF | KWSPI_TXLSBF);
> @@ -286,6 +316,10 @@ static int mvebu_spi_set_mode(struct udevice *bus, uint 
> mode)
>
> writel(data, >cfg);
>
> +   drvdata = (struct mvebu_spi_dev *)dev_get_driver_data(bus);
> +   if (drvdata->is_errata_50mhz_ac)
> +   mvebu_spi_50mhz_ac_timing_erratum(bus, mode);
> +
> return 0;
>  }
>
> @@ -343,10 +377,32 @@ static const struct dm_spi_ops mvebu_spi_ops = {
>  */
>  };
>
> +static const struct mvebu_spi_dev armada_xp_spi_dev_data = {
> +   .typ = ARMADA_SPI,
> +};
> +
> +static const struct mvebu_spi_dev armada_375_spi_dev_data = {
> +   .typ = ARMADA_SPI,
> +};
> +
> +static const struct mvebu_spi_dev armada_380_spi_dev_data = {
> +   .typ = ARMADA_SPI,
> +   .is_errata_50mhz_ac = true,
> +};
> +
>  static const struct udevice_id mvebu_spi_ids[] = {
> -   { .compatible = "marvell,armada-375-spi" },
> -   { .compatible = "marvell,armada-380-spi" },
> -   { .compatible = "marvell,armada-xp-spi" },
> +   {
> +   .compatible = "marvell,armada-375-spi",
> +   .data = (ulong)_375_spi_dev_data
> +   },
> +   {
> +   .compatible = "marvell,armada-380-spi",
> +   .data = (ulong)_380_spi_dev_data
> +   },
> +   {
> +   .compatible = "marvell,armada-xp-spi",
> +   .data = (ulong)_xp_spi_dev_data
> +   },
> { 

[U-Boot] [PATCH 2/4] arm: dra7xx: Add vendor partition to Android GPT table for eMMC

[Praneeth Bajjuri]

From: Vishal Mahaveer 

Add vendor partition to Android GPT table for eMMC.

A Vendor image contains SoC-specific code and configuration.

Prior to Android 8.0, the vendor partition was optional ;
files belonging to these images were placed in boot.img or system.img
with symlinks (such as /vendor >/system/vendor ) when absent.

Android 8.0 makes the vendor partition mandatory

The goal is to modularize Android partitions with standard interface between
the Android Platform (on system.img ) and vendor-provided code(on vendor.img).

This standard interface enables the Android Platform to be updated
without affecting the SoC partitions. This makes it possible to upgrade a
device system.img from Android 8.0 to Android P while other images (such as
vendor.img) remain at Android 8.0. This modularity enables timely
Android platform upgrades (such as monthly security updates )
without requiring SoC/ODM partners to update SoC- and device-specific code.

Signed-off-by: Vishal Mahaveer 
Signed-off-by: Praneeth Bajjuri 
---
 include/configs/dra7xx_evm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 717861f..e5e 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -66,6 +66,7 @@
"name=recovery,size=10M,uuid=${uuid_gpt_recovery};" \
"name=boot,size=10M,uuid=${uuid_gpt_boot};" \
"name=system,size=768M,uuid=${uuid_gpt_system};" \
+   "name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
"name=cache,size=256M,uuid=${uuid_gpt_cache};" \
"name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
"name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \
-- 
1.9.1

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

[U-Boot] [PATCH 3/4] omap-common: fastboot: extend cpu type for DRA71x rev 2.1

[Praneeth Bajjuri]

From: Vishal Mahaveer 

DRA71x processors are reduced pin and software compatible
derivative of DRA72 processors. Extend support for this
revision in "getvar cpu" command.

Signed-off-by: Vishal Mahaveer 
[prane...@ti.com: rebase to u-boot master]
Signed-off-by: Praneeth Bajjuri 
---
 arch/arm/mach-omap2/utils.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/utils.c b/arch/arm/mach-omap2/utils.c
index d4f171b..2bd8290 100644
--- a/arch/arm/mach-omap2/utils.c
+++ b/arch/arm/mach-omap2/utils.c
@@ -33,6 +33,7 @@ static void omap_set_fastboot_cpu(void)
break;
case DRA722_ES1_0:
case DRA722_ES2_0:
+   case DRA722_ES2_1:
cpu = "DRA722";
break;
default:
-- 
1.9.1

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

[U-Boot] [PATCH 4/4] arm: dra76: fastboot: extend cpu type for getvar command

[Praneeth Bajjuri]

'commit fa24eca1f20a ("omap: Add routine for setting fastboot variables")'
adds initial support and usage of "fastboot getvar" command
for DRA75x and DRA72x devices.

and
'commit 0f9e6aee9dbc ("arm: dra76: Add support for ES1.0 detection")'
adds initial dra76 device definition

This patch is to extend usage of "fastboot getvar" for DRA76 device.

Signed-off-by: Praneeth Bajjuri 
---
 arch/arm/mach-omap2/utils.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/utils.c b/arch/arm/mach-omap2/utils.c
index 2bd8290..2e87780 100644
--- a/arch/arm/mach-omap2/utils.c
+++ b/arch/arm/mach-omap2/utils.c
@@ -26,6 +26,9 @@ static void omap_set_fastboot_cpu(void)
u32 cpu_rev = omap_revision();
 
switch (cpu_rev) {
+   case DRA762_ES1_0:
+   cpu = "DRA762";
+   break;
case DRA752_ES1_0:
case DRA752_ES1_1:
case DRA752_ES2_0:
-- 
1.9.1

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

[U-Boot] [PATCH 1/4] arm: am57xx: Add vendor partition to Android GPT table for eMMC

[Praneeth Bajjuri]

Add vendor partition to Android GPT table for eMMC.

A Vendor image contains SoC-specific code and configuration.

Prior to Android 8.0, the vendor partition was optional ;
files belonging to these images were placed in boot.img or system.img
with symlinks (such as /vendor >/system/vendor ) when absent.

Android 8.0 makes the vendor partition mandatory

The goal is to modularize Android partitions with standard interface between
the Android Platform (on system.img ) and vendor-provided code(on vendor.img).

This standard interface enables the Android Platform to be updated
without affecting the SoC partitions. This makes it possible to upgrade a
device system.img from Android 8.0 to Android P while other images (such as
vendor.img) remain at Android 8.0. This modularity enables timely
Android platform upgrades (such as monthly security updates )
without requiring SoC/ODM partners to update SoC- and device-specific code.

Signed-off-by: Praneeth Bajjuri 
---
 include/configs/am57xx_evm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index 5427974..ebb0474 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -59,6 +59,7 @@
"name=recovery,size=10M,uuid=${uuid_gpt_recovery};" \
"name=boot,size=10M,uuid=${uuid_gpt_boot};" \
"name=system,size=768M,uuid=${uuid_gpt_system};" \
+   "name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
"name=cache,size=256M,uuid=${uuid_gpt_cache};" \
"name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
"name=ipu2,size=1M,uuid=${uuid_gpt_ipu2};" \
-- 
1.9.1

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

[U-Boot] [PATCH] libfdt: give setup.py optional interpreter

[Matt Weber]

If building in a sandboxed environment where a
alternate python interpreter is desired. Allow
configuring of the PYTHON variable to specify
the interpreter to invoke setup.py.

Signed-off-by: Matthew Weber 
---
 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 77706a9..30505dc 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -136,7 +136,7 @@ tools/_libfdt.so: $(LIBFDT_SRCS) $(LIBFDT_SWIG)
CPPFLAGS="$(_hostc_flags)" OBJDIR=tools \
SOURCES="$(LIBFDT_SRCS) tools/libfdt.i" \
SWIG_OPTS="-I$(srctree)/lib/libfdt -I$(srctree)/lib" \
-   $(libfdt_tree)/pylibfdt/setup.py --quiet build_ext \
+   $(PYTHON) $(libfdt_tree)/pylibfdt/setup.py --quiet build_ext \
--build-lib tools
 
 ifneq ($(CONFIG_MX23)$(CONFIG_MX28),)
-- 
1.8.3.1

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

[U-Boot] [PATCH] spi: kirkwood_spi: implement workaround for FE-9144572

[Chris Packham]

Erratum NO. FE-9144572: The device SPI interface supports frequencies of
up to 50 MHz.  However, due to this erratum, when the device core clock
is 250 MHz and the SPI interfaces is configured for 50MHz SPI clock and
CPOL=CPHA=1 there might occur data corruption on reads from the SPI
device.

Implement the workaround by setting the TMISO_SAMPLE value to 0x2
in the timing1 register.

Signed-off-by: Chris Packham 
---

 arch/arm/include/asm/arch-mvebu/spi.h |  6 
 drivers/spi/kirkwood_spi.c| 62 +--
 2 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-mvebu/spi.h 
b/arch/arm/include/asm/arch-mvebu/spi.h
index 3545aed17347..1de510ea6da9 100644
--- a/arch/arm/include/asm/arch-mvebu/spi.h
+++ b/arch/arm/include/asm/arch-mvebu/spi.h
@@ -57,6 +57,12 @@ struct kwspi_registers {
 #define KWSPI_TXLSBF   (1 << 13)
 #define KWSPI_RXLSBF   (1 << 14)
 
+/* Timing Parameters 1 Register */
+#define KW_SPI_TMISO_SAMPLE_OFFSET 6
+#define KW_SPI_TMISO_SAMPLE_MASK   (0x3 << KW_SPI_TMISO_SAMPLE_OFFSET)
+#define KW_SPI_TMISO_SAMPLE_1  (1 << KW_SPI_TMISO_SAMPLE_OFFSET)
+#define KW_SPI_TMISO_SAMPLE_2  (2 << KW_SPI_TMISO_SAMPLE_OFFSET)
+
 #define KWSPI_IRQUNMASK1 /* unmask SPI interrupt */
 #define KWSPI_IRQMASK  0 /* mask SPI interrupt */
 #define KWSPI_SMEMRDIRQ1 /* SerMem data xfer ready irq */
diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index 0c6bd295cde9..7992556d49eb 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -243,6 +243,16 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
 
 /* Here now the DM part */
 
+enum mvebu_spi_type {
+   ORION_SPI,
+   ARMADA_SPI,
+};
+
+struct mvebu_spi_dev {
+   enum mvebu_spi_type typ;
+   boolis_errata_50mhz_ac;
+};
+
 struct mvebu_spi_platdata {
struct kwspi_registers *spireg;
 };
@@ -269,10 +279,30 @@ static int mvebu_spi_set_speed(struct udevice *bus, uint 
hz)
return 0;
 }
 
+static void
+mvebu_spi_50mhz_ac_timing_erratum(struct udevice *bus, uint mode)
+{
+   struct mvebu_spi_platdata *plat = dev_get_platdata(bus);
+   struct kwspi_registers *reg = plat->spireg;
+   u32 data = readl(>timing1);
+
+   data &= ~KW_SPI_TMISO_SAMPLE_MASK;
+
+   if (CONFIG_SYS_TCLK == 25000 &&
+   mode & SPI_CPOL &&
+   mode & SPI_CPHA)
+   data |= KW_SPI_TMISO_SAMPLE_2;
+   else
+   data |= KW_SPI_TMISO_SAMPLE_1;
+
+   writel(data, >timing1);
+}
+
 static int mvebu_spi_set_mode(struct udevice *bus, uint mode)
 {
struct mvebu_spi_platdata *plat = dev_get_platdata(bus);
struct kwspi_registers *reg = plat->spireg;
+   const struct mvebu_spi_dev *drvdata;
u32 data = readl(>cfg);
 
data &= ~(KWSPI_CPHA | KWSPI_CPOL | KWSPI_RXLSBF | KWSPI_TXLSBF);
@@ -286,6 +316,10 @@ static int mvebu_spi_set_mode(struct udevice *bus, uint 
mode)
 
writel(data, >cfg);
 
+   drvdata = (struct mvebu_spi_dev *)dev_get_driver_data(bus);
+   if (drvdata->is_errata_50mhz_ac)
+   mvebu_spi_50mhz_ac_timing_erratum(bus, mode);
+
return 0;
 }
 
@@ -343,10 +377,32 @@ static const struct dm_spi_ops mvebu_spi_ops = {
 */
 };
 
+static const struct mvebu_spi_dev armada_xp_spi_dev_data = {
+   .typ = ARMADA_SPI,
+};
+
+static const struct mvebu_spi_dev armada_375_spi_dev_data = {
+   .typ = ARMADA_SPI,
+};
+
+static const struct mvebu_spi_dev armada_380_spi_dev_data = {
+   .typ = ARMADA_SPI,
+   .is_errata_50mhz_ac = true,
+};
+
 static const struct udevice_id mvebu_spi_ids[] = {
-   { .compatible = "marvell,armada-375-spi" },
-   { .compatible = "marvell,armada-380-spi" },
-   { .compatible = "marvell,armada-xp-spi" },
+   {
+   .compatible = "marvell,armada-375-spi",
+   .data = (ulong)_375_spi_dev_data
+   },
+   {
+   .compatible = "marvell,armada-380-spi",
+   .data = (ulong)_380_spi_dev_data
+   },
+   {
+   .compatible = "marvell,armada-xp-spi",
+   .data = (ulong)_xp_spi_dev_data
+   },
{ }
 };
 
-- 
2.14.2

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Rob Clark]

On Thu, Oct 12, 2017 at 7:48 PM, Heinrich Schuchardt  wrote:
> On 10/12/2017 11:26 PM, Rob Clark wrote:
>> On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt  
>> wrote:
>>> On 10/12/2017 04:28 PM, Rob Clark wrote:
 On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
> On 10/12/2017 03:40 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
>> wrote:
>>>
>>>
>>> On 10/12/2017 02:48 PM, Rob Clark wrote:

 On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>
>
>
> On 12.10.17 00:07, Rob Clark wrote:
>>
>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
>> wrote:
>>>
>>>
>>>
>>> On 10.10.17 14:23, Rob Clark wrote:

 In some cases, it is quite useful to have (for example) EFI on
 screen
 but u-boot on serial port.

 This adds two new optional environment variables, "efiin" and
 "efiout",
 which can be used to set EFI console input/output independently of
 u-boot's input/output.  If unset, EFI console will default to 
 stdin/
 stdout as before.

 Signed-off-by: Rob Clark 
>>>
>>>
>>> With this patch, we lose the ability to have the efi in/out go to
>>> both
>>> graphical and serial console, right? This is critical functionality
>>> to
>>> have, since we don't necessarily know which output/input a user ends
>>> up
>>> using.
>>
>>
>> I'll think about how to support iomux.. but some things like console
>> size are just not going to work properly there.  And as long as we 
>> fix
>
>
> Yeah, those probably would need to get special cased.
>
>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
>> simply not set efiout var and have things working as before, so you
>> don't loose any existing functionality (although, like I said, if the
>> two different consoles have different sizes things aren't going to
>> work properly for anything other than simple cases).
>>
>> In most cases, the display driver should be able to detect whether a
>> display is connected.. this is what I've done on dragonboard410c, so
>> if no display plugged in, 'efiout=vidconsole' fails and you fall back
>> to serial, else you get efi on screen like you would on a "real"
>> computer.  For boards that have a display driver that isn't able to 
>> do
>> the basic check of whether a cable is plugged in, just don't set
>> "efiout" (or fix the display driver) ;-)
>
>
> Are you sure that's what happens on a "real" computer? As far as I
> remember from all ARM servers running edk2 based firmware that I've
> touched so far, the default is always to display on serial *and*
> graphical output at the same time.


 Well, I suppose some of the arm64 server vendors have done a better
 job than others on firmware.. you'd hope they would probe EDID, and
 report correct console dimensions based on display resolution, etc.

 Doing both serial and display works for simple stuff, but it goes
 badly once the efi payload starts trying to change the cursor position
 and write to specific parts of the screen (which both Shell.efi and
 grub try to do).

 BR,
 -R

>>> Hello Rob,
>>>
>>> I do not know which program you use for connecting to your serial
>>> console. I
>>> use minicom which is a Debian/Ubuntu package. I had no problem using
>>> grub,
>>> vim, nano or any other console program.
>>>
>>> Minicom just provides a VT100 emulation and that is close enough to what
>>> Linux expects.
>>
>> fwiw, I generally use kermit so my terminal emulator is whatever
>> "xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
>> isn't so much the issue..
>>
>>> So I would not see what should be so special about Shell.efi.
>>
>> I'm not explaining the problem well, but you can see basically the
>> same issue if you resize your terminal emulator to something smaller
>> than what grub/shell/etc think you are using.
>>
>> I guess if they just fall back to assuming 80x25 like agraf mentioned,
>> that would kind of work.  It just means shell or grub will only use
>> the tiny upper-left corner of your monitor.
>>
>>> My U-Boot system all have video but I never have a monitor connected.
>>>

Re: [U-Boot] [PATCH] drivers: pci: imx: fix imx_pcie_remove function

[Fabio Estevam]

Hi David,

On Wed, Oct 11, 2017 at 5:18 AM, David Müller (ELSOFT AG)
 wrote:
> Hi Fabio
>
> Fabio Estevam wrote:
>> From: Sven-Ola Tuecke 
>>
>> However, at least on some i.MX6 custom boards, when calling
>
> By "some", I assume that not all i.MX6 systems are showing this
> behaviour. Does anyone have an idea which systems are affected and which
> are not?

Yes, the mx6 board I have access to do not show this issue.
Not sure why it fails on your board and on Sven's.

>> assert_core_reset() as part of the first-time PCIe init, read access
>> to PCIE_PL_PFLR simply hangs. Surround this readl() with
>> imx_pcie_fix_dabt_handler() does not help. For this reason, the forced
>> LTSSM detection is only used on the second assert_core_reset() that is
>> called shorly before starting the Linux kernel.
>>
>> Signed-off-by: Sven-Ola Tuecke 
>> Signed-off-by: Fabio Estevam 
>
> Seems to work on our board therefore
>
> Tested-by: David Müller 

Thanks for testing and glad it works for both of you.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] U-Boot fails to read NAND initialized by Linux

[Ivan Bublikov]

Hello,
It's probably just a simple case of misconfiguration of U-Boot or Linux, and 
someone with knowledgecould easily set me straight looking at the symptom. Many 
thanks in advance!

Summary:Linux can write and read NAND flash, but U-boot thinks all NAND blocks 
are bad.(Linux 4.1.15, U-boot 2015-04, 1Gbyte Micron NAND MT29F8G08ABBCA)
Details:Using Linux command line, I wrote and verified a Linux kernel at offset 
64Mb.To do that, when I boot Linux, I tell it (on the kernel command line) that 
it hasa 64Mb partition at offset 0and another at offset 64Mb.I wrote data using 
commands:flash_erase /dev/mtd1 0 0nandwrite -p /dev/mtd1 -p zImageAnd verified 
bydd if=/dev/mtd1 of=testFrom Linux viewpoint the flash works just fine. I read 
the same data that I wrote.
BTW, While Linux boots, it prints:Bad block table found at page 262080, version 
0x01Bad block table found at page 262016, version 0x01
Now I want to use U-Boot to load and start Linux from flash where it's written 
at offset 64Mb.==> nand read ${loadaddr} 400 200 // at offset 64Mb read 
32MbAttempt to read outside the flash area0 bytes read: ERROR
I investigated a little by enabling debug output in U-boot - it appears that 
U-boot scans the entire flash for bad blocks, looking at the first byte on the 
OOB area - if that byte is not ff it thinks the block is bad. So I added a 
printf to print the bytes it finds, and found them to be:block# byte04e1
fe2fe(The flash spec says that "factory-bad" blocks are signified by 0 
in those bytes)
I don't really know anything about MTD drivers. My working theory at the moment 
is that Linuxlegitimately marked the blocks like that, and U-boot should be 
using the "Bad block table" Linux created on the flash, instead of scanning all 
blocks. Apparently, U-boot doesn't understand what Linux has done to the flash.
 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH u-boot 3/3] arm: add initial support for Amlogic P212 based on Meson GXL family

[Neil Armstrong]

This adds platform code for the Amlogic P212 reference board based on a
Meson GXL (S905X) SoC with the Meson GXL configuration.

This initial submission only supports UART and MMC/SDCard, support for the
internal Ethernet PHY in Work In Progress.

Signed-off-by: Neil Armstrong 
---
 arch/arm/mach-meson/Kconfig| 22 ++
 board/amlogic/p212/Kconfig | 12 ++
 board/amlogic/p212/MAINTAINERS |  6 +++
 board/amlogic/p212/Makefile|  8 
 board/amlogic/p212/README  | 96 ++
 board/amlogic/p212/p212.c  | 21 +
 configs/p212_defconfig | 31 ++
 include/configs/p212.h | 22 ++
 8 files changed, 218 insertions(+)
 create mode 100644 board/amlogic/p212/Kconfig
 create mode 100644 board/amlogic/p212/MAINTAINERS
 create mode 100644 board/amlogic/p212/Makefile
 create mode 100644 board/amlogic/p212/README
 create mode 100644 board/amlogic/p212/p212.c
 create mode 100644 configs/p212_defconfig
 create mode 100644 include/configs/p212.h

diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index af3be59..d4bd230 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -9,6 +9,15 @@ config MESON_GXBB
  The Amlogic Meson GXBaby (S905) is an ARM SoC with a
  quad-core Cortex-A53 CPU and a Mali-450 GPU.
 
+config MESON_GXL
+   bool "Support Meson GXL"
+   select ARM64
+   select DM
+   select DM_SERIAL
+   help
+ The Amlogic Meson GXL (S905X and S905X) is an ARM SoC with a
+ quad-core Cortex-A53 CPU and a Mali-450 GPU.
+
 if MESON_GXBB
 
 config TARGET_ODROID_C2
@@ -20,6 +29,17 @@ config TARGET_ODROID_C2
 
 endif
 
+if MESON_GXL
+
+config TARGET_P212
+   bool "P212"
+   help
+ P212 is a reference dessign board based on Meson GXL S905X SoC
+ with 2 GiB of RAM, Ethernet, HDMI, 2 USB, micro-SD slot,
+ eMMC, IR receiver, CVBS+Audio jack and a SDIO WiFi module.
+
+endif
+
 config SYS_SOC
default "meson"
 
@@ -28,4 +48,6 @@ config SYS_MALLOC_F_LEN
 
 source "board/amlogic/odroid-c2/Kconfig"
 
+source "board/amlogic/p212/Kconfig"
+
 endif
diff --git a/board/amlogic/p212/Kconfig b/board/amlogic/p212/Kconfig
new file mode 100644
index 000..720c92b
--- /dev/null
+++ b/board/amlogic/p212/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_P212
+
+config SYS_BOARD
+   default "p212"
+
+config SYS_VENDOR
+   default "amlogic"
+
+config SYS_CONFIG_NAME
+   default "p212"
+
+endif
diff --git a/board/amlogic/p212/MAINTAINERS b/board/amlogic/p212/MAINTAINERS
new file mode 100644
index 000..6575f17
--- /dev/null
+++ b/board/amlogic/p212/MAINTAINERS
@@ -0,0 +1,6 @@
+P212
+M: Neil Armstrong 
+S: Maintained
+F: board/amlogic/p212/
+F: include/configs/p212.h
+F: configs/p212_defconfig
diff --git a/board/amlogic/p212/Makefile b/board/amlogic/p212/Makefile
new file mode 100644
index 000..960a661
--- /dev/null
+++ b/board/amlogic/p212/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2016 BayLibre, SAS
+# Author: Neil Armstrong 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := p212.o
diff --git a/board/amlogic/p212/README b/board/amlogic/p212/README
new file mode 100644
index 000..979502d
--- /dev/null
+++ b/board/amlogic/p212/README
@@ -0,0 +1,96 @@
+U-Boot for Amlogic P212
+===
+
+P212 is a reference board manufactured by Amlogic with the following
+specifications:
+
+ - Amlogic S905X ARM Cortex-A53 quad-core SoC @ 1.5GHz
+ - ARM Mali 450 GPU
+ - 2GB DDR3 SDRAM
+ - 10/100 Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 2 x USB 2.0 Host
+ - eMMC, microSD
+ - Infrared receiver
+ - SDIO WiFi Module
+ - CVBS+Stereo Audio Jack
+
+Schematics are available from Amlogic on demand.
+
+Currently the u-boot port supports the following devices:
+ - serial
+ - eMMC, microSD
+
+u-boot compilation
+==
+
+ > export ARCH=arm
+ > export CROSS_COMPILE=aarch64-none-elf-
+ > make p212_defconfig
+ > make
+
+Image creation
+==
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+ > wget 
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ > wget 
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ > export 
PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ > git clone https://github.com/BayLibre/u-boot.git -b 
n-amlogic-openlinux-20170606 amlogic-u-boot
+ > cd amlogic-u-boot
+ > make gxl_p212_v1_defconfig

[U-Boot] [PATCH u-boot 1/3] ARM: dts: Synchronize Amlogic from Linux Mainline 4.13.5

[Neil Armstrong]

Synchronize the Amlogic ARM64 dts from mainline Linux 4.13.5

In the preparation of the support of the Amlogic P212 board,
import the corresponding meson-gxl-s905x-p212.dts file.

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/meson-gx.dtsi|  13 +-
 arch/arm/dts/meson-gxbb-odroidc2.dts  | 108 ++---
 arch/arm/dts/meson-gxbb.dtsi  | 220 +++
 arch/arm/dts/meson-gxl-mali.dtsi  |  43 ++
 arch/arm/dts/meson-gxl-s905x-p212.dts |  95 +
 arch/arm/dts/meson-gxl-s905x-p212.dtsi| 173 
 arch/arm/dts/meson-gxl-s905x.dtsi |  55 +++
 arch/arm/dts/meson-gxl.dtsi   | 628 ++
 include/dt-bindings/gpio/meson-gxl-gpio.h | 131 +++
 10 files changed, 1326 insertions(+), 143 deletions(-)
 create mode 100644 arch/arm/dts/meson-gxl-mali.dtsi
 create mode 100644 arch/arm/dts/meson-gxl-s905x-p212.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905x-p212.dtsi
 create mode 100644 arch/arm/dts/meson-gxl-s905x.dtsi
 create mode 100644 arch/arm/dts/meson-gxl.dtsi
 create mode 100644 include/dt-bindings/gpio/meson-gxl-gpio.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5b90280..8a07f53 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -54,7 +54,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3399-puma-ddr1866.dtb \
rv1108-evb.dtb
 dtb-$(CONFIG_ARCH_MESON) += \
-   meson-gxbb-odroidc2.dtb
+   meson-gxbb-odroidc2.dtb \
+   meson-gxl-s905x-p212.dtb
 dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
tegra20-paz00.dtb \
diff --git a/arch/arm/dts/meson-gx.dtsi b/arch/arm/dts/meson-gx.dtsi
index 436b875..738ed68 100644
--- a/arch/arm/dts/meson-gx.dtsi
+++ b/arch/arm/dts/meson-gx.dtsi
@@ -200,7 +200,7 @@
};
 
scpi_sensors: sensors {
-   compatible = "arm,scpi-sensors";
+   compatible = "amlogic,meson-gxbb-scpi-sensors", 
"arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
};
@@ -304,6 +304,15 @@
status = "disabled";
};
 
+   spicc: spi@8d80 {
+   compatible = "amlogic,meson-gx-spicc";
+   reg = <0x0 0x08d80 0x0 0x80>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
spifc: spi@8c80 {
compatible = "amlogic,meson-gx-spifc", 
"amlogic,meson-gxbb-spifc";
reg = <0x0 0x08c80 0x0 0x80>;
@@ -391,7 +400,7 @@
};
 
pwm_AO_ab: pwm@550 {
-   compatible = "amlogic,meson-gx-pwm", 
"amlogic,meson-gxbb-pwm";
+   compatible = "amlogic,meson-gx-ao-pwm", 
"amlogic,meson-gxbb-ao-pwm";
reg = <0x0 0x00550 0x0 0x10>;
#pwm-cells = <3>;
status = "disabled";
diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts 
b/arch/arm/dts/meson-gxbb-odroidc2.dts
index 54a9c6a..d147c85 100644
--- a/arch/arm/dts/meson-gxbb-odroidc2.dts
+++ b/arch/arm/dts/meson-gxbb-odroidc2.dts
@@ -137,16 +137,6 @@
};
 };
 
-_clocks {
-   status = "disabled";
-};
-
-_AO {
-   status = "okay";
-   pinctrl-0 = <_ao_a_pins>;
-   pinctrl-names = "default";
-};
-
  {
status = "okay";
pinctrl-0 = <_rgmii_pins>;
@@ -172,6 +162,33 @@
};
 };
 
+_ao {
+   /*
+* WARNING: The USB Hub on the Odroid-C2 needs a reset signal
+* to be turned high in order to be detected by the USB Controller
+* This signal should be handled by a USB specific power sequence
+* in order to reset the Hub when USB bus is powered down.
+*/
+   usb-hub {
+   gpio-hog;
+   gpios = ;
+   output-high;
+   line-name = "usb-hub-reset";
+   };
+};
+
+_A {
+   status = "okay";
+   pinctrl-0 = <_a_pins>;
+   pinctrl-names = "default";
+};
+
+ {
+   status = "okay";
+   pinctrl-0 = <_input_ao_pins>;
+   pinctrl-names = "default";
+};
+
 _aobus {
gpio-line-names = "UART TX", "UART RX", "VCCK En", "TF 3V3/1V8 En",
  "USB HUB nRESET", "USB OTG Power En",
@@ -223,55 +240,15 @@
  "";
 };
 
- {
-   status = "okay";
-   pinctrl-0 = <_input_ao_pins>;
-   pinctrl-names = "default";
-};
-
-_A {
-   status = "okay";
-   pinctrl-0 = <_a_pins>;
-   pinctrl-names = "default";
-};
-
-_ao {
-   /*
-* WARNING: The 

[U-Boot] [PATCH u-boot 2/3] pinctrl: meson: Add GXL Support

[Neil Armstrong]

Add the Amlogic Meson GXL pinctrl support based on the GXBB driver and
the synchronized DTS from Linux 4.13.5

Signed-off-by: Neil Armstrong 
---
 drivers/pinctrl/meson/Kconfig |   4 +
 drivers/pinctrl/meson/Makefile|   1 +
 drivers/pinctrl/meson/pinctrl-meson-gxl.c | 736 ++
 3 files changed, 741 insertions(+)
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson-gxl.c

diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
index c3e6901..27ba890 100644
--- a/drivers/pinctrl/meson/Kconfig
+++ b/drivers/pinctrl/meson/Kconfig
@@ -8,4 +8,8 @@ config PINCTRL_MESON_GXBB
bool "Amlogic Meson GXBB SoC pinctrl driver"
select PINCTRL_MESON
 
+config PINCTRL_MESON_GXL
+   bool "Amlogic Meson GXL SoC pinctrl driver"
+   select PINCTRL_MESON
+
 endif
diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
index 6dde4bc..18921e3 100644
--- a/drivers/pinctrl/meson/Makefile
+++ b/drivers/pinctrl/meson/Makefile
@@ -4,3 +4,4 @@
 
 obj-y  += pinctrl-meson.o
 obj-$(CONFIG_PINCTRL_MESON_GXBB)   += pinctrl-meson-gxbb.o
+obj-$(CONFIG_PINCTRL_MESON_GXL)+= pinctrl-meson-gxl.o
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxl.c 
b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
new file mode 100644
index 000..eebfaa9
--- /dev/null
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
@@ -0,0 +1,736 @@
+/*
+ * (C) Copyright 2016 - Beniamino Galvani 
+ *
+ * Based on code from Linux kernel:
+ *   Copyright (C) 2016 Endless Mobile, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-meson.h"
+
+#define EE_OFF 10
+
+static const unsigned int emmc_nand_d07_pins[] = {
+   PIN(BOOT_0, EE_OFF), PIN(BOOT_1, EE_OFF), PIN(BOOT_2, EE_OFF),
+   PIN(BOOT_3, EE_OFF), PIN(BOOT_4, EE_OFF), PIN(BOOT_5, EE_OFF),
+   PIN(BOOT_6, EE_OFF), PIN(BOOT_7, EE_OFF),
+};
+static const unsigned int emmc_clk_pins[] = { PIN(BOOT_8, EE_OFF) };
+static const unsigned int emmc_cmd_pins[] = { PIN(BOOT_10, EE_OFF) };
+static const unsigned int emmc_ds_pins[] = { PIN(BOOT_15, EE_OFF) };
+
+static const unsigned int nor_d_pins[] = { PIN(BOOT_11, EE_OFF) };
+static const unsigned int nor_q_pins[] = { PIN(BOOT_12, EE_OFF) };
+static const unsigned int nor_c_pins[] = { PIN(BOOT_13, EE_OFF) };
+static const unsigned int nor_cs_pins[]= { PIN(BOOT_15, 
EE_OFF) };
+
+static const unsigned int spi_mosi_pins[]  = { PIN(GPIOX_8, EE_OFF) };
+static const unsigned int spi_miso_pins[]  = { PIN(GPIOX_9, EE_OFF) };
+static const unsigned int spi_ss0_pins[]   = { PIN(GPIOX_10, EE_OFF) };
+static const unsigned int spi_sclk_pins[]  = { PIN(GPIOX_11, EE_OFF) };
+
+static const unsigned int sdcard_d0_pins[] = { PIN(CARD_1, EE_OFF) };
+static const unsigned int sdcard_d1_pins[] = { PIN(CARD_0, EE_OFF) };
+static const unsigned int sdcard_d2_pins[] = { PIN(CARD_5, EE_OFF) };
+static const unsigned int sdcard_d3_pins[] = { PIN(CARD_4, EE_OFF) };
+static const unsigned int sdcard_cmd_pins[] = { PIN(CARD_3, EE_OFF) };
+static const unsigned int sdcard_clk_pins[] = { PIN(CARD_2, EE_OFF) };
+
+static const unsigned int sdio_d0_pins[] = { PIN(GPIOX_0, EE_OFF) };
+static const unsigned int sdio_d1_pins[] = { PIN(GPIOX_1, EE_OFF) };
+static const unsigned int sdio_d2_pins[] = { PIN(GPIOX_2, EE_OFF) };
+static const unsigned int sdio_d3_pins[] = { PIN(GPIOX_3, EE_OFF) };
+static const unsigned int sdio_cmd_pins[] = { PIN(GPIOX_4, EE_OFF) };
+static const unsigned int sdio_clk_pins[] = { PIN(GPIOX_5, EE_OFF) };
+static const unsigned int sdio_irq_pins[] = { PIN(GPIOX_7, EE_OFF) };
+
+static const unsigned int nand_ce0_pins[]  = { PIN(BOOT_8, EE_OFF) };
+static const unsigned int nand_ce1_pins[]  = { PIN(BOOT_9, EE_OFF) };
+static const unsigned int nand_rb0_pins[]  = { PIN(BOOT_10, EE_OFF) };
+static const unsigned int nand_ale_pins[]  = { PIN(BOOT_11, EE_OFF) };
+static const unsigned int nand_cle_pins[]  = { PIN(BOOT_12, EE_OFF) };
+static const unsigned int nand_wen_clk_pins[]  = { PIN(BOOT_13, EE_OFF) };
+static const unsigned int nand_ren_wr_pins[]   = { PIN(BOOT_14, EE_OFF) };
+static const unsigned int nand_dqs_pins[]  = { PIN(BOOT_15, EE_OFF) };
+
+static const unsigned int uart_tx_a_pins[] = { PIN(GPIOX_12, EE_OFF) };
+static const unsigned int uart_rx_a_pins[] = { PIN(GPIOX_13, EE_OFF) };
+static const unsigned int uart_cts_a_pins[]= { PIN(GPIOX_14, EE_OFF) };
+static const unsigned int uart_rts_a_pins[]= { PIN(GPIOX_15, EE_OFF) };
+
+static const unsigned int uart_tx_b_pins[] = { PIN(GPIODV_24, EE_OFF) };
+static const unsigned int uart_rx_b_pins[] = { PIN(GPIODV_25, EE_OFF) };
+static const unsigned int uart_cts_b_pins[]= { PIN(GPIODV_26, EE_OFF) };
+static const unsigned int uart_rts_b_pins[] 

[U-Boot] [PATCH u-boot 0/3] Add initial support for Amlogic P212 Reference board

[Neil Armstrong]

This patchset aimed to add minimal support for the Amlogic P212 reference board
from Amlogic based on the Meson S905X SoC from the Meson GXL SoC Family.

The initial support is composed of :
- GXL pinctrl driver
- Minimal boot support with serial, MMC and SDCard
- Updated DTS from Linux 4.13.5

Commands to generate a valid binary are provided in the board README.

The following work will be pushed later on :
- Support for dynamic reading of DDR memory size from registers
- Support for the Internal Ethernet PHY is WiP
- USB DWC3 Host Support with PHY support

This patchset can boot Linux Mainline 4.14-rc4 with the Video Pipeline disables,
since it currently depends on Power Domains initialization from Vendor u-boot.
Dedicated reset and init code for the Video Pipeline for mainline Linux is in
the work.

Neil Armstrong (3):
  ARM: dts: Synchronize Amlogic from Linux Mainline 4.13.5
  pinctrl: meson: Add GXL Support
  arm: add initial support for Amlogic P212 based on Meson GXL family

 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/meson-gx.dtsi|  13 +-
 arch/arm/dts/meson-gxbb-odroidc2.dts  | 108 ++---
 arch/arm/dts/meson-gxbb.dtsi  | 220 +
 arch/arm/dts/meson-gxl-mali.dtsi  |  43 ++
 arch/arm/dts/meson-gxl-s905x-p212.dts |  95 
 arch/arm/dts/meson-gxl-s905x-p212.dtsi| 173 +++
 arch/arm/dts/meson-gxl-s905x.dtsi |  55 +++
 arch/arm/dts/meson-gxl.dtsi   | 628 +
 arch/arm/mach-meson/Kconfig   |  22 +
 board/amlogic/p212/Kconfig|  12 +
 board/amlogic/p212/MAINTAINERS|   6 +
 board/amlogic/p212/Makefile   |   8 +
 board/amlogic/p212/README |  96 
 board/amlogic/p212/p212.c |  21 +
 configs/p212_defconfig|  31 ++
 drivers/pinctrl/meson/Kconfig |   4 +
 drivers/pinctrl/meson/Makefile|   1 +
 drivers/pinctrl/meson/pinctrl-meson-gxl.c | 736 ++
 include/configs/p212.h|  22 +
 include/dt-bindings/gpio/meson-gxl-gpio.h | 131 ++
 21 files changed, 2285 insertions(+), 143 deletions(-)
 create mode 100644 arch/arm/dts/meson-gxl-mali.dtsi
 create mode 100644 arch/arm/dts/meson-gxl-s905x-p212.dts
 create mode 100644 arch/arm/dts/meson-gxl-s905x-p212.dtsi
 create mode 100644 arch/arm/dts/meson-gxl-s905x.dtsi
 create mode 100644 arch/arm/dts/meson-gxl.dtsi
 create mode 100644 board/amlogic/p212/Kconfig
 create mode 100644 board/amlogic/p212/MAINTAINERS
 create mode 100644 board/amlogic/p212/Makefile
 create mode 100644 board/amlogic/p212/README
 create mode 100644 board/amlogic/p212/p212.c
 create mode 100644 configs/p212_defconfig
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson-gxl.c
 create mode 100644 include/configs/p212.h
 create mode 100644 include/dt-bindings/gpio/meson-gxl-gpio.h

-- 
2.7.4

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

Re: [U-Boot] [PATCH u-boot 2/3] pinctrl: meson: Add GXL Support

[Tom Rini]

On Thu, Oct 12, 2017 at 03:50:31PM +0200, Neil Armstrong wrote:

> Add the Amlogic Meson GXL pinctrl support based on the GXBB driver and
> the synchronized DTS from Linux 4.13.5
> 
> Signed-off-by: Neil Armstrong 

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 u-boot 1/3] ARM: dts: Synchronize Amlogic from Linux Mainline 4.13.5

[Tom Rini]

On Thu, Oct 12, 2017 at 03:50:30PM +0200, Neil Armstrong wrote:

> Synchronize the Amlogic ARM64 dts from mainline Linux 4.13.5
> 
> In the preparation of the support of the Amlogic P212 board,
> import the corresponding meson-gxl-s905x-p212.dts file.
> 
> Signed-off-by: Neil Armstrong 

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 u-boot 3/3] arm: add initial support for Amlogic P212 based on Meson GXL family

[Tom Rini]

On Thu, Oct 12, 2017 at 03:50:32PM +0200, Neil Armstrong wrote:

> This adds platform code for the Amlogic P212 reference board based on a
> Meson GXL (S905X) SoC with the Meson GXL configuration.
> 
> This initial submission only supports UART and MMC/SDCard, support for the
> internal Ethernet PHY in Work In Progress.
> 
> Signed-off-by: Neil Armstrong 

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] Please pull u-boot-fsl-qoriq master

[Tom Rini]

On Thu, Oct 12, 2017 at 02:51:21PM +, York Sun wrote:

> Tom,
> 
> The following changes since commit 39dd65a059e503883dbf16d4c00ac083d15837da:
> 
>   sandbox: Enable btrfs support (2017-10-03 08:44:55 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fsl-qoriq.git
> 
> for you to fetch changes up to 23af484b0156baaafd578222d73513418df78f09:
> 
>   armv8: ls1043ardb_sdcard: prepare falcon boot (2017-10-09 08:48:45 -0700)
> 

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] board: ti: dra71x-evm: Hook LDO1 of LP8733 to EN_PIN

[Tom Rini]

On Thu, Oct 12, 2017 at 10:18:45AM +0530, Keerthy wrote:

> All regulators are hooked to EN_Pin at reset so that EN Pin controls
> their state. Hook the LDO1 regulator to EN pin which at reset is not
> hooked. This applies only to LP8733.
> 
> Signed-off-by: Keerthy 

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] [PULL] Please pull u-boot-imx

[Tom Rini]

On Thu, Oct 12, 2017 at 06:29:05PM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> 
> The following changes since commit 1b22c5ba496ffc9b0702919d58c410ed1527ab63:
> 
>   Merge git://git.denx.de/u-boot-i2c (2017-10-11 08:38:20 -0400)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 0a333602df9fd9dcd6f58c8c098b29a3bd1dffcc:
> 
>   ARM: imx6: Add DHCOM i.MX6 PDK board support (2017-10-12 18:01:06 +0200)
> 

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] Please pull from u-boot-i2c

[Tom Rini]

On Wed, Oct 11, 2017 at 11:02:12AM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c master
> 
> The following changes since commit 45c9d96ae40b0c4292eb67d687f0bf698a0ce72b:
> 
>   configs: Re-sync CONFIG_CMD_IMLS with moveconfig (2017-10-10 17:52:07 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> for you to fetch changes up to 5bc90a8953a902152bd640322ffc8111dccbe3ab:
> 
>   i2c: muxes: pca954x: look up width from chip_desc (2017-10-11 06:17:22 
> +0200)
> 

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 05/11] efi_loader: move efi_search_obj up in code

[Heinrich Schuchardt]

On 10/09/2017 06:49 AM, Simon Glass wrote:
> On 7 October 2017 at 22:57, Heinrich Schuchardt  wrote:
>> To avoid a forward declaration move efi_search_obj before
>> all protocol services functions.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  lib/efi_loader/efi_boottime.c | 41 +
>>  1 file changed, 21 insertions(+), 20 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
Hello Alex,

could this patch be merged?

You merged all preceding patches of the series.

Regards

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Heinrich Schuchardt]

On 10/12/2017 11:26 PM, Rob Clark wrote:
> On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt  
> wrote:
>> On 10/12/2017 04:28 PM, Rob Clark wrote:
>>> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
 On 10/12/2017 03:40 PM, Rob Clark wrote:
>
> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
> wrote:
>>
>>
>> On 10/12/2017 02:48 PM, Rob Clark wrote:
>>>
>>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:



 On 12.10.17 00:07, Rob Clark wrote:
>
> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
> wrote:
>>
>>
>>
>> On 10.10.17 14:23, Rob Clark wrote:
>>>
>>> In some cases, it is quite useful to have (for example) EFI on
>>> screen
>>> but u-boot on serial port.
>>>
>>> This adds two new optional environment variables, "efiin" and
>>> "efiout",
>>> which can be used to set EFI console input/output independently of
>>> u-boot's input/output.  If unset, EFI console will default to stdin/
>>> stdout as before.
>>>
>>> Signed-off-by: Rob Clark 
>>
>>
>> With this patch, we lose the ability to have the efi in/out go to
>> both
>> graphical and serial console, right? This is critical functionality
>> to
>> have, since we don't necessarily know which output/input a user ends
>> up
>> using.
>
>
> I'll think about how to support iomux.. but some things like console
> size are just not going to work properly there.  And as long as we fix


 Yeah, those probably would need to get special cased.

> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
> simply not set efiout var and have things working as before, so you
> don't loose any existing functionality (although, like I said, if the
> two different consoles have different sizes things aren't going to
> work properly for anything other than simple cases).
>
> In most cases, the display driver should be able to detect whether a
> display is connected.. this is what I've done on dragonboard410c, so
> if no display plugged in, 'efiout=vidconsole' fails and you fall back
> to serial, else you get efi on screen like you would on a "real"
> computer.  For boards that have a display driver that isn't able to do
> the basic check of whether a cable is plugged in, just don't set
> "efiout" (or fix the display driver) ;-)


 Are you sure that's what happens on a "real" computer? As far as I
 remember from all ARM servers running edk2 based firmware that I've
 touched so far, the default is always to display on serial *and*
 graphical output at the same time.
>>>
>>>
>>> Well, I suppose some of the arm64 server vendors have done a better
>>> job than others on firmware.. you'd hope they would probe EDID, and
>>> report correct console dimensions based on display resolution, etc.
>>>
>>> Doing both serial and display works for simple stuff, but it goes
>>> badly once the efi payload starts trying to change the cursor position
>>> and write to specific parts of the screen (which both Shell.efi and
>>> grub try to do).
>>>
>>> BR,
>>> -R
>>>
>> Hello Rob,
>>
>> I do not know which program you use for connecting to your serial
>> console. I
>> use minicom which is a Debian/Ubuntu package. I had no problem using
>> grub,
>> vim, nano or any other console program.
>>
>> Minicom just provides a VT100 emulation and that is close enough to what
>> Linux expects.
>
> fwiw, I generally use kermit so my terminal emulator is whatever
> "xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
> isn't so much the issue..
>
>> So I would not see what should be so special about Shell.efi.
>
> I'm not explaining the problem well, but you can see basically the
> same issue if you resize your terminal emulator to something smaller
> than what grub/shell/etc think you are using.
>
> I guess if they just fall back to assuming 80x25 like agraf mentioned,
> that would kind of work.  It just means shell or grub will only use
> the tiny upper-left corner of your monitor.
>
>> My U-Boot system all have video but I never have a monitor connected.
>>
>> So being able to use serial even if video is available is a necessity.
>
> If the video driver doesn't detect that it is unconnected, someone
> should really fix that, otherwise you'll have problems booting an
> 

[U-Boot] [PATCH 1/1] dm: tegra: correct type for tegra_xusb_padctl_lane_find_function

[Heinrich Schuchardt]

tegra_xusb_padctl_lane_find_function returns int and not
unsigned int.

Detecting an error (func < 0) is not possible if variable
func is defined as unsigned.

Detected by cppcheck.

Signed-off-by: Heinrich Schuchardt 
---
 arch/arm/mach-tegra/xusb-padctl-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/xusb-padctl-common.c 
b/arch/arm/mach-tegra/xusb-padctl-common.c
index c8a468a034..b2411123cb 100644
--- a/arch/arm/mach-tegra/xusb-padctl-common.c
+++ b/arch/arm/mach-tegra/xusb-padctl-common.c
@@ -152,7 +152,7 @@ tegra_xusb_padctl_group_apply(struct tegra_xusb_padctl 
*padctl,
 
for (i = 0; i < group->num_pins; i++) {
const struct tegra_xusb_padctl_lane *lane;
-   unsigned int func;
+   int func;
u32 value;
 
lane = tegra_xusb_padctl_find_lane(padctl, group->pins[i]);
-- 
2.14.1

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Rob Clark]

On Thu, Oct 12, 2017 at 6:38 PM, Heinrich Schuchardt  wrote:
> On 10/12/2017 04:28 PM, Rob Clark wrote:
>> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
>>> On 10/12/2017 03:40 PM, Rob Clark wrote:

 On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
 wrote:
>
>
> On 10/12/2017 02:48 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>>
>>>
>>>
>>> On 12.10.17 00:07, Rob Clark wrote:

 On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
 wrote:
>
>
>
> On 10.10.17 14:23, Rob Clark wrote:
>>
>> In some cases, it is quite useful to have (for example) EFI on
>> screen
>> but u-boot on serial port.
>>
>> This adds two new optional environment variables, "efiin" and
>> "efiout",
>> which can be used to set EFI console input/output independently of
>> u-boot's input/output.  If unset, EFI console will default to stdin/
>> stdout as before.
>>
>> Signed-off-by: Rob Clark 
>
>
> With this patch, we lose the ability to have the efi in/out go to
> both
> graphical and serial console, right? This is critical functionality
> to
> have, since we don't necessarily know which output/input a user ends
> up
> using.


 I'll think about how to support iomux.. but some things like console
 size are just not going to work properly there.  And as long as we fix
>>>
>>>
>>> Yeah, those probably would need to get special cased.
>>>
 the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
 simply not set efiout var and have things working as before, so you
 don't loose any existing functionality (although, like I said, if the
 two different consoles have different sizes things aren't going to
 work properly for anything other than simple cases).

 In most cases, the display driver should be able to detect whether a
 display is connected.. this is what I've done on dragonboard410c, so
 if no display plugged in, 'efiout=vidconsole' fails and you fall back
 to serial, else you get efi on screen like you would on a "real"
 computer.  For boards that have a display driver that isn't able to do
 the basic check of whether a cable is plugged in, just don't set
 "efiout" (or fix the display driver) ;-)
>>>
>>>
>>> Are you sure that's what happens on a "real" computer? As far as I
>>> remember from all ARM servers running edk2 based firmware that I've
>>> touched so far, the default is always to display on serial *and*
>>> graphical output at the same time.
>>
>>
>> Well, I suppose some of the arm64 server vendors have done a better
>> job than others on firmware.. you'd hope they would probe EDID, and
>> report correct console dimensions based on display resolution, etc.
>>
>> Doing both serial and display works for simple stuff, but it goes
>> badly once the efi payload starts trying to change the cursor position
>> and write to specific parts of the screen (which both Shell.efi and
>> grub try to do).
>>
>> BR,
>> -R
>>
> Hello Rob,
>
> I do not know which program you use for connecting to your serial
> console. I
> use minicom which is a Debian/Ubuntu package. I had no problem using
> grub,
> vim, nano or any other console program.
>
> Minicom just provides a VT100 emulation and that is close enough to what
> Linux expects.

 fwiw, I generally use kermit so my terminal emulator is whatever
 "xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
 isn't so much the issue..

> So I would not see what should be so special about Shell.efi.

 I'm not explaining the problem well, but you can see basically the
 same issue if you resize your terminal emulator to something smaller
 than what grub/shell/etc think you are using.

 I guess if they just fall back to assuming 80x25 like agraf mentioned,
 that would kind of work.  It just means shell or grub will only use
 the tiny upper-left corner of your monitor.

> My U-Boot system all have video but I never have a monitor connected.
>
> So being able to use serial even if video is available is a necessity.

 If the video driver doesn't detect that it is unconnected, someone
 should really fix that, otherwise you'll have problems booting an
 image where grub tries to use gfxterm if GOP is present (but we are
 really getting off topic here)

 Either way, you still have the option of not 

[U-Boot] [PATCH 1/1] arm64: zynqmp: remove unnecessary logical constraint

[Heinrich Schuchardt]

In

if (a || b)
else if (!a)

the constraint (!a) is always true if else is reached and
can be removed.

Signed-off-by: Heinrich Schuchardt 
---
 arch/arm/cpu/armv8/zynqmp/cpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index 1b5066a826..9b83e51885 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -198,7 +198,7 @@ int zynqmp_mmio_write(const u32 address,
 {
if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3)
return zynqmp_mmio_rawwrite(address, mask, value);
-   else if (!IS_ENABLED(CONFIG_SPL_BUILD))
+   else
return invoke_smc(ZYNQMP_MMIO_WRITE, address, mask,
  value, 0, NULL);
 
@@ -215,7 +215,7 @@ int zynqmp_mmio_read(const u32 address, u32 *value)
 
if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
ret = zynqmp_mmio_rawread(address, value);
-   } else if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+   } else {
ret = invoke_smc(ZYNQMP_MMIO_READ, address, 0, 0,
 0, ret_payload);
*value = ret_payload[1];
-- 
2.14.1

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

[U-Boot] [PATCH 1/1] efi_selftest: correctly check return values

[Heinrich Schuchardt]

When cancelling the timer we should check the return
value provided by the set_timer service.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/efi_selftest_events.c | 2 +-
 lib/efi_selftest/efi_selftest_tpl.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_selftest/efi_selftest_events.c 
b/lib/efi_selftest/efi_selftest_events.c
index b2cdc150da..081f31257f 100644
--- a/lib/efi_selftest/efi_selftest_events.c
+++ b/lib/efi_selftest/efi_selftest_events.c
@@ -186,7 +186,7 @@ static int execute(void)
return EFI_ST_FAILURE;
}
ret = boottime->set_timer(event_wait, EFI_TIMER_STOP, 0);
-   if (index != 0) {
+   if (ret != EFI_SUCCESS) {
efi_st_error("Could not cancel timer\n");
return EFI_ST_FAILURE;
}
diff --git a/lib/efi_selftest/efi_selftest_tpl.c 
b/lib/efi_selftest/efi_selftest_tpl.c
index b8c0e70262..ddb67ed268 100644
--- a/lib/efi_selftest/efi_selftest_tpl.c
+++ b/lib/efi_selftest/efi_selftest_tpl.c
@@ -207,7 +207,7 @@ static int execute(void)
return EFI_ST_FAILURE;
}
ret = boottime->set_timer(event_wait, EFI_TIMER_STOP, 0);
-   if (index != 0) {
+   if (ret != EFI_SUCCESS) {
efi_st_error("Could not cancel timer\n");
return EFI_ST_FAILURE;
}
-- 
2.14.1

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Heinrich Schuchardt]

On 10/12/2017 04:28 PM, Rob Clark wrote:
> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
>> On 10/12/2017 03:40 PM, Rob Clark wrote:
>>>
>>> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
>>> wrote:


 On 10/12/2017 02:48 PM, Rob Clark wrote:
>
> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>
>>
>>
>> On 12.10.17 00:07, Rob Clark wrote:
>>>
>>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
>>> wrote:



 On 10.10.17 14:23, Rob Clark wrote:
>
> In some cases, it is quite useful to have (for example) EFI on
> screen
> but u-boot on serial port.
>
> This adds two new optional environment variables, "efiin" and
> "efiout",
> which can be used to set EFI console input/output independently of
> u-boot's input/output.  If unset, EFI console will default to stdin/
> stdout as before.
>
> Signed-off-by: Rob Clark 


 With this patch, we lose the ability to have the efi in/out go to
 both
 graphical and serial console, right? This is critical functionality
 to
 have, since we don't necessarily know which output/input a user ends
 up
 using.
>>>
>>>
>>> I'll think about how to support iomux.. but some things like console
>>> size are just not going to work properly there.  And as long as we fix
>>
>>
>> Yeah, those probably would need to get special cased.
>>
>>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
>>> simply not set efiout var and have things working as before, so you
>>> don't loose any existing functionality (although, like I said, if the
>>> two different consoles have different sizes things aren't going to
>>> work properly for anything other than simple cases).
>>>
>>> In most cases, the display driver should be able to detect whether a
>>> display is connected.. this is what I've done on dragonboard410c, so
>>> if no display plugged in, 'efiout=vidconsole' fails and you fall back
>>> to serial, else you get efi on screen like you would on a "real"
>>> computer.  For boards that have a display driver that isn't able to do
>>> the basic check of whether a cable is plugged in, just don't set
>>> "efiout" (or fix the display driver) ;-)
>>
>>
>> Are you sure that's what happens on a "real" computer? As far as I
>> remember from all ARM servers running edk2 based firmware that I've
>> touched so far, the default is always to display on serial *and*
>> graphical output at the same time.
>
>
> Well, I suppose some of the arm64 server vendors have done a better
> job than others on firmware.. you'd hope they would probe EDID, and
> report correct console dimensions based on display resolution, etc.
>
> Doing both serial and display works for simple stuff, but it goes
> badly once the efi payload starts trying to change the cursor position
> and write to specific parts of the screen (which both Shell.efi and
> grub try to do).
>
> BR,
> -R
>
 Hello Rob,

 I do not know which program you use for connecting to your serial
 console. I
 use minicom which is a Debian/Ubuntu package. I had no problem using
 grub,
 vim, nano or any other console program.

 Minicom just provides a VT100 emulation and that is close enough to what
 Linux expects.
>>>
>>> fwiw, I generally use kermit so my terminal emulator is whatever
>>> "xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
>>> isn't so much the issue..
>>>
 So I would not see what should be so special about Shell.efi.
>>>
>>> I'm not explaining the problem well, but you can see basically the
>>> same issue if you resize your terminal emulator to something smaller
>>> than what grub/shell/etc think you are using.
>>>
>>> I guess if they just fall back to assuming 80x25 like agraf mentioned,
>>> that would kind of work.  It just means shell or grub will only use
>>> the tiny upper-left corner of your monitor.
>>>
 My U-Boot system all have video but I never have a monitor connected.

 So being able to use serial even if video is available is a necessity.
>>>
>>> If the video driver doesn't detect that it is unconnected, someone
>>> should really fix that, otherwise you'll have problems booting an
>>> image where grub tries to use gfxterm if GOP is present (but we are
>>> really getting off topic here)
>>>
>>> Either way, you still have the option of not setting efiout (or
>>> setting it to serial)
>>>
>>> But for end users (at least of boards that I care about), if they plug
>>> in a monitor they should get grub on screen.  Not everyone has a
>>> serial 

[U-Boot] reading ubi from a NAND for programming to other devices

[Tim Harvey]

Greetings,

I'm looking to understand what methods are available for
reading/writing ubi/ubifs from an existing NAND flash in order to
duplicate the contents onto another device in U-Boot, Linux, and with
JTAG flashing for production.

Typically I create ubi's using ubinize then I can use U-Boot 'nand
erase' and 'nand write' or JTAG to write the ubi without issues.
However if I use U-Boot 'nand read' to read a ubi then write it back
using the same method I get 'ubi0 warning: ubi_io_read: error -74 (ECC
error)' and 'ubi0 error: ubi_io_read: error -74 (ECC error)' messages
from Linux when its mounted. I find I run into the same problem when
JTAG programming ubi's: no issues when using a ubi created via ubinize
but when flashing one that came from a U-Boot 'nand read' I see ubi
errors when mounting it.

Some testing shows me that I can't use U-Boot nand read/erase/write
once U-Boot has 'attached' the UBI (via the U-Boot 'ubi part' command)
which scans and re-sizes the volume.

If I on the other hand take a ubi from U-Boot 'nand read' and use
Linux ubiformat to flash that onto a new device I get no ubi
warnings/errors when its mounted. My understanding is that ubiformat
is simply preserving erase counters but there must be something else
its doing.

What's going on here and what can I do in U-Boot/JTAG to properly
write ubi that's been read from an existing system? I'm hoping there
is a method that doesn't require iterating over the individual volumes
within the ubi.

Best Regards,

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

[U-Boot] [PATCH 1/1] usbtty: fix typos

[Heinrich Schuchardt]

Fix typos in USB tty driver.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/serial/usbtty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/usbtty.c b/drivers/serial/usbtty.c
index 353109c070..182385e499 100644
--- a/drivers/serial/usbtty.c
+++ b/drivers/serial/usbtty.c
@@ -525,7 +525,7 @@ int drv_usbtty_init (void)
char * tt;
int snlen;
 
-   /* Ger seiral number */
+   /* Get serial number */
sn = env_get("serial#");
if (!sn)
sn = "";
-- 
2.11.0

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

Re: [U-Boot] [PATCH] mx6slevk: Use PARTUUID to specify the rootfs location

[Tom Rini]

On Thu, Oct 12, 2017 at 04:10:27PM -0300, Fabio Estevam wrote:
> On Thu, Oct 12, 2017 at 4:00 PM, Tom Rini  wrote:
> 
> > Shouldn't mmcpart be changed to 2 here as well and finduud be part uuid
> > ${mmcdev}:${mmcpart} ?  This would also make things a bit more
> > scriptable for use in other distros.
> 
> mmcpart is still used to load kernel and dtb from the fat partition,
> so it should remain at 1.
> 
> I can probably remove this partition scheme assumptions from U-Boot
> and use distro_config instead for the next release.

OK, 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] mx6slevk: Use PARTUUID to specify the rootfs location

[Fabio Estevam]

On Thu, Oct 12, 2017 at 4:00 PM, Tom Rini  wrote:

> Shouldn't mmcpart be changed to 2 here as well and finduud be part uuid
> ${mmcdev}:${mmcpart} ?  This would also make things a bit more
> scriptable for use in other distros.

mmcpart is still used to load kernel and dtb from the fat partition,
so it should remain at 1.

I can probably remove this partition scheme assumptions from U-Boot
and use distro_config instead for the next release.

Thanks


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

[U-Boot] [PATCH] imx: Fix regression with CONFIG_DM_MMC=y

[Fabio Estevam]

From: Fabio Estevam 

When CONFIG_DM_MMC=y, CONFIG_BLK should be selected, otherwise the
SD/eMMC card cannot be used.

Also, select CONFIG_DM_USB=y when CONFIG_USB=y to avoid build failure.

Tested on mx6slevk, mx7dsabresd and mx6ullevk.

Signed-off-by: Fabio Estevam 
---
 configs/mx6slevk_defconfig| 2 +-
 configs/mx6slevk_spinor_defconfig | 2 +-
 configs/mx6sllevk_defconfig   | 1 -
 configs/mx6sllevk_plugin_defconfig| 1 -
 configs/mx6sxsabreauto_defconfig  | 2 +-
 configs/mx6ull_14x14_evk_defconfig| 1 -
 configs/mx6ull_14x14_evk_plugin_defconfig | 1 -
 configs/mx7dsabresd_defconfig | 1 -
 configs/mx7dsabresd_secure_defconfig  | 1 -
 configs/mx7ulp_evk_defconfig  | 1 -
 configs/mx7ulp_evk_plugin_defconfig   | 1 -
 11 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/configs/mx6slevk_defconfig b/configs/mx6slevk_defconfig
index 16e2cca..7b1ddac 100644
--- a/configs/mx6slevk_defconfig
+++ b/configs/mx6slevk_defconfig
@@ -28,7 +28,6 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
-# CONFIG_BLK is not set
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
@@ -45,6 +44,7 @@ CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_THERMAL=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
diff --git a/configs/mx6slevk_spinor_defconfig 
b/configs/mx6slevk_spinor_defconfig
index 020d19f..4b9c04e 100644
--- a/configs/mx6slevk_spinor_defconfig
+++ b/configs/mx6slevk_spinor_defconfig
@@ -28,7 +28,6 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_DM=y
-# CONFIG_BLK is not set
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
@@ -45,6 +44,7 @@ CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_THERMAL=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
diff --git a/configs/mx6sllevk_defconfig b/configs/mx6sllevk_defconfig
index a7daafc..30b9ad7 100644
--- a/configs/mx6sllevk_defconfig
+++ b/configs/mx6sllevk_defconfig
@@ -24,7 +24,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_MMC=y
-# CONFIG_BLK is not set
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
diff --git a/configs/mx6sllevk_plugin_defconfig 
b/configs/mx6sllevk_plugin_defconfig
index b8948d8..b5301c3 100644
--- a/configs/mx6sllevk_plugin_defconfig
+++ b/configs/mx6sllevk_plugin_defconfig
@@ -25,7 +25,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_MMC=y
-# CONFIG_BLK is not set
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
diff --git a/configs/mx6sxsabreauto_defconfig b/configs/mx6sxsabreauto_defconfig
index ca8453b..5ef95d1 100644
--- a/configs/mx6sxsabreauto_defconfig
+++ b/configs/mx6sxsabreauto_defconfig
@@ -28,7 +28,6 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
-# CONFIG_BLK is not set
 CONFIG_DM_GPIO=y
 CONFIG_DM_PCA953X=y
 CONFIG_DM_I2C=y
@@ -47,6 +46,7 @@ CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_FSL_QSPI=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
diff --git a/configs/mx6ull_14x14_evk_defconfig 
b/configs/mx6ull_14x14_evk_defconfig
index 115c926..c9147fc 100644
--- a/configs/mx6ull_14x14_evk_defconfig
+++ b/configs/mx6ull_14x14_evk_defconfig
@@ -21,7 +21,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_MMC=y
-# CONFIG_BLK is not set
 CONFIG_DM_GPIO=y
 CONFIG_DM_74X164=y
 CONFIG_DM_I2C=y
diff --git a/configs/mx6ull_14x14_evk_plugin_defconfig 
b/configs/mx6ull_14x14_evk_plugin_defconfig
index d6511ff..f0cc85f 100644
--- a/configs/mx6ull_14x14_evk_plugin_defconfig
+++ b/configs/mx6ull_14x14_evk_plugin_defconfig
@@ -22,7 +22,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_MMC=y
-# CONFIG_BLK is not set
 CONFIG_DM_GPIO=y
 CONFIG_DM_74X164=y
 CONFIG_DM_I2C=y
diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig
index 1917f4b..9a4857d 100644
--- a/configs/mx7dsabresd_defconfig
+++ b/configs/mx7dsabresd_defconfig
@@ -37,7 +37,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DM_GPIO=y
diff --git a/configs/mx7dsabresd_secure_defconfig 
b/configs/mx7dsabresd_secure_defconfig
index 416ddcf..b33c2b6 100644
--- a/configs/mx7dsabresd_secure_defconfig
+++ b/configs/mx7dsabresd_secure_defconfig
@@ -39,7 +39,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DM_GPIO=y
diff --git a/configs/mx7ulp_evk_defconfig b/configs/mx7ulp_evk_defconfig
index 0470fbd..e344dd9 100644
--- 

Re: [U-Boot] [PATCH] mx6slevk: Use PARTUUID to specify the rootfs location

[Tom Rini]

On Mon, Oct 02, 2017 at 10:11:37AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> mx6slevk can run different kernel versions, such as NXP 4.1 or mainline.
> 
> Currently the rootfs location is passed via mmcblk number and the
> problem with this approach is that the mmcblk number for the SD
> card changes depending on the kernel version.
> 
> In order to avoid such issue, use the UUID method to specify the
> rootfs location.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  configs/mx6slevk_defconfig | 1 +
>  configs/mx6slevk_spl_defconfig | 1 +
>  include/configs/mx6slevk.h | 5 +++--
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/configs/mx6slevk_defconfig b/configs/mx6slevk_defconfig
> index 1c28942..641fa85 100644
> --- a/configs/mx6slevk_defconfig
> +++ b/configs/mx6slevk_defconfig
> @@ -13,6 +13,7 @@ CONFIG_CMD_BOOTZ=y
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> +CONFIG_CMD_PART=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_USB=y
>  # CONFIG_CMD_SETEXPR is not set
> diff --git a/configs/mx6slevk_spl_defconfig b/configs/mx6slevk_spl_defconfig
> index 4d4f273..8fadbcc 100644
> --- a/configs/mx6slevk_spl_defconfig
> +++ b/configs/mx6slevk_spl_defconfig
> @@ -21,6 +21,7 @@ CONFIG_CMD_BOOTZ=y
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
> +CONFIG_CMD_PART=y
>  CONFIG_CMD_SF=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_DHCP=y
> diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
> index 25c83e8..9ddb143 100644
> --- a/include/configs/mx6slevk.h
> +++ b/include/configs/mx6slevk.h
> @@ -53,9 +53,9 @@
>   "ip_dyn=yes\0" \
>   "mmcdev=1\0" \
>   "mmcpart=1\0" \
> - "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
> + "finduuid=part uuid mmc 1:2 uuid\0" \
>   "mmcargs=setenv bootargs console=${console},${baudrate} " \
> - "root=${mmcroot}\0" \
> + "root=PARTUUID=${uuid} rootwait rw\0" \

Shouldn't mmcpart be changed to 2 here as well and finduud be part uuid
${mmcdev}:${mmcpart} ?  This would also make things a bit more
scriptable for use in other distros.

-- 
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] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

[Tom Rini]

On Thu, Oct 12, 2017 at 03:39:56PM -0300, Fabio Estevam wrote:
> On Thu, Oct 12, 2017 at 3:38 PM, Tom Rini  wrote:
> 
> > Yes, just work on the imx* targets.  For am33xx/am43xx/am57xx we don't
> > want to swap things around as we then get rid of USB gadget support.
> > It's a bit tricky atm to get all cases covered as, iirc, there's
> > something outstanding for the USB gadget case for DM.
> 
> Ok, so in this case, should I fix this by touching only the imx6 defconfigs?

Yes, 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 V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

[Fabio Estevam]

On Thu, Oct 12, 2017 at 3:38 PM, Tom Rini  wrote:

> Yes, just work on the imx* targets.  For am33xx/am43xx/am57xx we don't
> want to swap things around as we then get rid of USB gadget support.
> It's a bit tricky atm to get all cases covered as, iirc, there's
> something outstanding for the USB gadget case for DM.

Ok, so in this case, should I fix this by touching only the imx6 defconfigs?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

[Tom Rini]

On Thu, Oct 12, 2017 at 03:35:38PM -0300, Fabio Estevam wrote:
> Tom,
> 
> On Thu, Oct 12, 2017 at 1:33 PM, Tom Rini  wrote:
> 
> > OK, disregard what I had been saying.  At this point, it's a matter of
> > correcting and testing boards to have either DM_MMC (and DM_USB and BLK)
> > on, or having DM_MMC off (because they want USB gadget support).
> 
> Here is what I tried:
> https://pastebin.com/yYEdC5fA
> 
> but then am335x_hs_evm_defconfig fails like this:
> 
>   LD  spl/drivers/built-in.o
>   LD  spl/u-boot-spl
> /usr/bin/arm-linux-gnueabi-ld.bfd: u-boot-spl section `.rodata' will
> not fit in region `.sram'
> /usr/bin/arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 7212 bytes
> scripts/Makefile.spl:358: recipe for target 'spl/u-boot-spl' failed
> make[1]: *** [spl/u-boot-spl] Error 1
> Makefile:1407: recipe for target 'spl/u-boot-spl' failed
> make: *** [spl/u-boot-spl] Error
> 
> Suggestions?

Yes, just work on the imx* targets.  For am33xx/am43xx/am57xx we don't
want to swap things around as we then get rid of USB gadget support.
It's a bit tricky atm to get all cases covered as, iirc, there's
something outstanding for the USB gadget case for DM.

-- 
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] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

[Fabio Estevam]

Tom,

On Thu, Oct 12, 2017 at 1:33 PM, Tom Rini  wrote:

> OK, disregard what I had been saying.  At this point, it's a matter of
> correcting and testing boards to have either DM_MMC (and DM_USB and BLK)
> on, or having DM_MMC off (because they want USB gadget support).

Here is what I tried:
https://pastebin.com/yYEdC5fA

but then am335x_hs_evm_defconfig fails like this:

  LD  spl/drivers/built-in.o
  LD  spl/u-boot-spl
/usr/bin/arm-linux-gnueabi-ld.bfd: u-boot-spl section `.rodata' will
not fit in region `.sram'
/usr/bin/arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 7212 bytes
scripts/Makefile.spl:358: recipe for target 'spl/u-boot-spl' failed
make[1]: *** [spl/u-boot-spl] Error 1
Makefile:1407: recipe for target 'spl/u-boot-spl' failed
make: *** [spl/u-boot-spl] Error

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

Re: [U-Boot] [PATCH] mx6slevk: Fix MMC breakage for the SPL target

[Stefano Babic]

Hi Fabio,

On 12/10/2017 18:27, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Sun, Oct 1, 2017 at 4:23 PM, Fabio Estevam  wrote:
>> From: Fabio Estevam 
>>
>> Commit 001cdbbb32ef1f6 ("imx: mx6slevk: enable more DM drivers") breaks
>> MMC support in U-Boot proper on the mx6slevk_spl_defconfig target:
>>
>> U-Boot SPL 2017.09-00396-g6ca43a5 (Oct 01 2017 - 16:20:18)
>> Trying to boot from MMC1
>>
>> U-Boot 2017.09-00396-g6ca43a5 (Oct 01 2017 - 16:20:18 -0300)
>>
>> CPU:   Freescale i.MX6SL rev1.0 792 MHz (running at 396 MHz)
>> CPU:   Commercial temperature grade (0C to 95C) at 33C
>> Reset cause: POR
>> Board: MX6SLEVK
>> I2C:   ready
>> DRAM:  1 GiB
>> MMC:   FSL_SDHC: 0
>> MMC Device 1 not found
>> *** Warning - No MMC card found, using default environment
>>
>> Fix this by re-introducing the U-Boot proper mmc init code inside
>> board_mmc_init().
>>
>> Signed-off-by: Fabio Estevam 
> 
> Please disregard this patch and others I sent related to the MMC
> breakage. We are discussing in another thread a more generic way to
> fix these problems.
> 

Yes, I dropped this and "mx6slevk: Remove some DM drivers". They won't
be merged.

Best regards,
Stefano

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

[U-Boot] 'filesize' env var - making U-Boot command more scriptable?

[Tim Harvey]

Greetings,

Various U-Boot commands that deal with files/blobs end up setting the
'filesize' env variable to be used for subsequent commands which is
very handy. I haven't found this documented anywhere but a scan of the
code looks like this is done by
ximg/unzip/load/ini/lzmadec/reiser/cramfs/pxe/cbfs/jffs2/zfs/nvedit/zip/bootm_os/dfu_mmc/fs/ubifs/net.

I've seen other commands that allow a usage that will allow specifying
a var name to put a result in.

I've noticed commands such as 'ubi' and 'nand' would benefit from
setting filesize when dealing with volume names and partition names.
I've also noticed how some commands (ie nand) are good about reporting
sizes in hex but others (ie ubi) report them in decimal only making it
difficult for someone to even cut-and-paste sizes to following
commands.

Has there been a desire or proposal to make this more standard or come
up with something different?

Regards,

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

Re: [U-Boot] [PATCH V2] imx: mx7dsabresd: include BLK for MMC/eMMC support of driver model

[Tom Rini]

On Wed, Oct 11, 2017 at 06:17:12PM -0400, Tom Rini wrote:
> On Wed, Oct 11, 2017 at 07:07:04PM -0300, Fabio Estevam wrote:
> > On Wed, Oct 11, 2017 at 6:55 PM, Tom Rini  wrote:
> > 
> > > Yes, I think that's it, along with removing the default y if DM_MMC from
> > > the BLK entry.  Thanks!
> > 
> > Ok, if I do as suggested:
> > 
> > --- a/drivers/block/Kconfig
> > +++ b/drivers/block/Kconfig
> > @@ -1,7 +1,6 @@
> >  config BLK
> > bool "Support block devices"
> > depends on DM
> > -   default y if DM_MMC
> > help
> >   Enable support for block devices, such as SCSI, MMC and USB
> >   flash sticks. These provide a block-level interface which permits
> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> > index 94050836..f4c953c 100644
> > --- a/drivers/mmc/Kconfig
> > +++ b/drivers/mmc/Kconfig
> > @@ -13,6 +13,7 @@ config MMC
> >  config DM_MMC
> > bool "Enable MMC controllers using Driver Model"
> > depends on DM
> > +   select BLK
> > help
> >   This enables the MultiMediaCard (MMC) uclass which supports MMC 
> > and
> >   Secure Digital I/O (SDIO) cards. Both removable (SD, micro-SD, 
> > etc.)
> > 
> > Then mx7dsabresd_defconfig build and boots fine.
> > 
> > However, mx6slevk_defconfig fails to build like this:
> > 
> >   CC  common/usb_storage.o
> > common/usb_storage.c: In function ‘usb_stor_probe_device’:
> > common/usb_storage.c:208:30: error: ‘struct usb_device’ has no member
> > named ‘dev’
> >   data = dev_get_platdata(udev->dev);
> >   ^
> > common/usb_storage.c:218:32: error: ‘struct usb_device’ has no member
> > named ‘dev’
> >ret = blk_create_devicef(udev->dev, "usb_storage_blk", str,
> > ^
> > I can fix it by doing:
> > 
> > --- a/configs/mx6slevk_defconfig
> > +++ b/configs/mx6slevk_defconfig
> > @@ -44,6 +44,7 @@ CONFIG_DM_REGULATOR_FIXED=y
> >  CONFIG_DM_REGULATOR_GPIO=y
> >  CONFIG_DM_THERMAL=y
> >  CONFIG_USB=y
> > +CONFIG_DM_USB=y
> >  CONFIG_USB_STORAGE=y
> >  CONFIG_USB_HOST_ETHER=y
> >  CONFIG_USB_ETHER_ASIX=y
> > 
> > Is there a better fix for this breakage?
> 
> Hmmm.  So, if you have DM and DM_MMC, you need BLK.  If you have DM and
> BLK and USB, you also need DM_USB (and vice-versa, if you have DM and DM_USB 
> and
> not DM_MMC, things will break too, on another platform I bet).  So,
> DM_USB should also select BLK I think.  The case like mx6slkevk where
> you have DM_USB supported by not enabled are a bug of sorts where it
> needs to also be enabling DM_USB.  I think I'll need to do a world build
> to see what fails in this case, unless you want to do it?  Thanks!

OK, disregard what I had been saying.  At this point, it's a matter of
correcting and testing boards to have either DM_MMC (and DM_USB and BLK)
on, or having DM_MMC off (because they want USB gadget support).

-- 
Tom


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

[U-Boot] [PULL] Please pull u-boot-imx

[Stefano Babic]

Hi Tom,

please pull from u-boot-imx, thanks !


The following changes since commit 1b22c5ba496ffc9b0702919d58c410ed1527ab63:

  Merge git://git.denx.de/u-boot-i2c (2017-10-11 08:38:20 -0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to 0a333602df9fd9dcd6f58c8c098b29a3bd1dffcc:

  ARM: imx6: Add DHCOM i.MX6 PDK board support (2017-10-12 18:01:06 +0200)


Anatolij Gustschin (2):
  imx6: disable clock command and print_cpuinfo code in SPL
  i.mx6ul: xpress: update UART init for current board revision

Diego Dorta (8):
  imx: Include  header file
  imx: sys_proto: Add a prototype for board_mmc_get_env_dev()
  mx6: soc: Include  header file
  mx6sabresd: Include  header file
  usb: ehci-ci: Add a prototype for board_ehci_power()
  mx6sabresd: Include  header file
  mx6: clock: Add a prototype for do_mx6_showclocks()
  mx6: sys_proto: Add prototypes for imx6_pcie_toggle() functions

Fabio Estevam (13):
  mx6sabresd: Avoid calling setup_display() from SPL code
  cgtqmx6eval: Avoid calling setup_display() from SPL code
  wandboard: Avoid calling setup_display() from SPL code
  mx6cuboxi: Avoid calling setup_display() from SPL code
  apalis_imx6: Avoid calling setup_display() from SPL code
  colibri_imx6: Avoid calling setup_display() from SPL code
  mx53loco: Let CONFIG_DISPLAY_CPUINFO be selected
  README.imx6: Prefer loading SPL via the new SDP mechanism
  mx6: toradex: Remove custom CONFIG_SPL_PAD_TO definition
  mx7ulp_evk: Move CONFIG_CMD_BOOTZ to Kconfig
  topic_miami: Remove CONFIG_CMD_BOOTZ undef
  wandboard: Add support for the latest revd1 revision
  mx6slevk: Use PARTUUID to specify the rootfs location

Ilya Ledvich (1):
  arm: imx7d: add support for Compulab cl-som-imx7

Jagan Teki (2):
  icore: configs: Fix merge conflict issue
  icorem6_rqs: env: Return mmc devno

Marek Vasut (1):
  ARM: imx6: Add DHCOM i.MX6 PDK board support

Otavio Salvador (2):
  mx25pdk: Use generic filesystem commands
  mx25pdk: Remove duplicated define

Stefan Agner (1):
  doc: update imx_usb_loader URL

Sven-Ola Tuecke (1):
  drivers: pci: imx: fix imx_pcie_remove function

Uri Mashiach (4):
  imx: mx7: fix the CCM_ macros
  imx: mx7: DDR controller configuration for the i.MX7 architecture
  imx: mx7: SPL support for i.MX7
  imx: mx7: spl: remove redundant SATA definitionas

 arch/arm/include/asm/arch-mx6/clock.h   |   1 +
 arch/arm/include/asm/arch-mx6/sys_proto.h   |   3 +
 arch/arm/include/asm/arch-mx7/crm_regs.h|  51 +
 arch/arm/include/asm/arch-mx7/imx-regs.h|   2 +
 arch/arm/include/asm/arch-mx7/mx7-ddr.h | 155
++
 arch/arm/include/asm/arch-mx7/sys_proto.h   |   1 +
 arch/arm/include/asm/mach-imx/sys_proto.h   |   2 +
 arch/arm/mach-imx/cpu.c |   4 +-
 arch/arm/mach-imx/mx6/Kconfig   |  10 ++
 arch/arm/mach-imx/mx6/clock.c   |  30 ++---
 arch/arm/mach-imx/mx6/soc.c |   1 +
 arch/arm/mach-imx/mx7/Kconfig   |   8 ++
 arch/arm/mach-imx/mx7/Makefile  |   2 +-
 arch/arm/mach-imx/mx7/ddr.c | 201
+
 arch/arm/mach-imx/spl.c |  23 +++-
 board/advantech/dms-ba16/dms-ba16.c |   1 +
 board/aristainetos/aristainetos.c   |   1 +
 board/beckhoff/mx53cx9020/mx53cx9020.c  |   1 +
 board/ccv/xpress/xpress.c   |  14 ++-
 board/compulab/cl-som-imx7/Kconfig  |  28 +
 board/compulab/cl-som-imx7/MAINTAINERS  |   6 +
 board/compulab/cl-som-imx7/Makefile |  17 +++
 board/compulab/cl-som-imx7/cl-som-imx7.c| 331
++
 board/compulab/cl-som-imx7/common.c |  46 
 board/compulab/cl-som-imx7/common.h |  32 ++
 board/dhelectronics/dh_imx6/dh_imx6_spl.c   | 399
+
 board/el/el6x/el6x.c|   1 +
 board/embest/mx6boards/mx6boards.c  |   1 +
 board/engicam/icorem6_rqs/icorem6_rqs.c |   3 +-
 board/freescale/mx51evk/mx51evk.c   |   1 +
 board/freescale/mx53loco/mx53loco.c |   1 +
 board/freescale/mx6sabreauto/mx6sabreauto.c |   1 +
 board/freescale/mx6sabresd/mx6sabresd.c |   9 +-
 board/ge/bx50v3/bx50v3.c|   1 +
 board/logicpd/imx6/imx6logic.c  |   1 +
 board/solidrun/mx6cuboxi/mx6cuboxi.c|  15 +--
 board/technologic/ts4800/ts4800.c   |   1 +
 board/toradex/apalis_imx6/apalis_imx6.c |   9 +-
 board/toradex/colibri_imx6/colibri_imx6.c   |   8 +-
 board/wandboard/wandboard.c | 113 +--
 configs/cl-som-imx7_defconfig   |  54 +
 

Re: [U-Boot] [PATCH] mx6slevk: Fix MMC breakage for the SPL target

[Fabio Estevam]

Hi Stefano,

On Sun, Oct 1, 2017 at 4:23 PM, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> Commit 001cdbbb32ef1f6 ("imx: mx6slevk: enable more DM drivers") breaks
> MMC support in U-Boot proper on the mx6slevk_spl_defconfig target:
>
> U-Boot SPL 2017.09-00396-g6ca43a5 (Oct 01 2017 - 16:20:18)
> Trying to boot from MMC1
>
> U-Boot 2017.09-00396-g6ca43a5 (Oct 01 2017 - 16:20:18 -0300)
>
> CPU:   Freescale i.MX6SL rev1.0 792 MHz (running at 396 MHz)
> CPU:   Commercial temperature grade (0C to 95C) at 33C
> Reset cause: POR
> Board: MX6SLEVK
> I2C:   ready
> DRAM:  1 GiB
> MMC:   FSL_SDHC: 0
> MMC Device 1 not found
> *** Warning - No MMC card found, using default environment
>
> Fix this by re-introducing the U-Boot proper mmc init code inside
> board_mmc_init().
>
> Signed-off-by: Fabio Estevam 

Please disregard this patch and others I sent related to the MMC
breakage. We are discussing in another thread a more generic way to
fix these problems.

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Alexander Graf]

Am 12.10.2017 um 18:00 schrieb Mark Kettenis :

>> From: Rob Clark 
>> Date: Thu, 12 Oct 2017 10:28:43 -0400
>> 
>>> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
 On 10/12/2017 03:40 PM, Rob Clark wrote:
 
 On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
 wrote:
> 
> 
>> On 10/12/2017 02:48 PM, Rob Clark wrote:
>> 
>>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>> 
>>> 
>>> 
 On 12.10.17 00:07, Rob Clark wrote:
 
 On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
 wrote:
> 
> 
> 
>> On 10.10.17 14:23, Rob Clark wrote:
>> 
>> In some cases, it is quite useful to have (for example) EFI on
>> screen
>> but u-boot on serial port.
>> 
>> This adds two new optional environment variables, "efiin" and
>> "efiout",
>> which can be used to set EFI console input/output independently of
>> u-boot's input/output.  If unset, EFI console will default to stdin/
>> stdout as before.
>> 
>> Signed-off-by: Rob Clark 
> 
> 
> With this patch, we lose the ability to have the efi in/out go to
> both
> graphical and serial console, right? This is critical functionality
> to
> have, since we don't necessarily know which output/input a user ends
> up
> using.
 
 
 I'll think about how to support iomux.. but some things like console
 size are just not going to work properly there.  And as long as we fix
>>> 
>>> 
>>> Yeah, those probably would need to get special cased.
>>> 
 the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
 simply not set efiout var and have things working as before, so you
 don't loose any existing functionality (although, like I said, if the
 two different consoles have different sizes things aren't going to
 work properly for anything other than simple cases).
 
 In most cases, the display driver should be able to detect whether a
 display is connected.. this is what I've done on dragonboard410c, so
 if no display plugged in, 'efiout=vidconsole' fails and you fall back
 to serial, else you get efi on screen like you would on a "real"
 computer.  For boards that have a display driver that isn't able to do
 the basic check of whether a cable is plugged in, just don't set
 "efiout" (or fix the display driver) ;-)
>>> 
>>> 
>>> Are you sure that's what happens on a "real" computer? As far as I
>>> remember from all ARM servers running edk2 based firmware that I've
>>> touched so far, the default is always to display on serial *and*
>>> graphical output at the same time.
>> 
>> 
>> Well, I suppose some of the arm64 server vendors have done a better
>> job than others on firmware.. you'd hope they would probe EDID, and
>> report correct console dimensions based on display resolution, etc.
>> 
>> Doing both serial and display works for simple stuff, but it goes
>> badly once the efi payload starts trying to change the cursor position
>> and write to specific parts of the screen (which both Shell.efi and
>> grub try to do).
>> 
>> BR,
>> -R
>> 
> Hello Rob,
> 
> I do not know which program you use for connecting to your serial
> console. I
> use minicom which is a Debian/Ubuntu package. I had no problem using
> grub,
> vim, nano or any other console program.
> 
> Minicom just provides a VT100 emulation and that is close enough to what
> Linux expects.
 
 fwiw, I generally use kermit so my terminal emulator is whatever
 "xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
 isn't so much the issue..
 
> So I would not see what should be so special about Shell.efi.
 
 I'm not explaining the problem well, but you can see basically the
 same issue if you resize your terminal emulator to something smaller
 than what grub/shell/etc think you are using.
 
 I guess if they just fall back to assuming 80x25 like agraf mentioned,
 that would kind of work.  It just means shell or grub will only use
 the tiny upper-left corner of your monitor.
 
> My U-Boot system all have video but I never have a monitor connected.
> 
> So being able to use serial even if video is available is a necessity.
 
 If the video driver doesn't detect that it is unconnected, someone
 should really fix that, otherwise you'll have problems booting an
 image where grub tries to use gfxterm if GOP is present (but we are
 really 

Re: [U-Boot] [PATCH] mx6slevk: Use PARTUUID to specify the rootfs location

[Stefano Babic]

On 02/10/2017 15:11, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> mx6slevk can run different kernel versions, such as NXP 4.1 or mainline.
> 
> Currently the rootfs location is passed via mmcblk number and the
> problem with this approach is that the mmcblk number for the SD
> card changes depending on the kernel version.
> 
> In order to avoid such issue, use the UUID method to specify the
> rootfs location.
> 
> Signed-off-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


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

Re: [U-Boot] [PATCH] drivers: pci: imx: fix imx_pcie_remove function

[Stefano Babic]

On 05/10/2017 13:46, Fabio Estevam wrote:
> From: Sven-Ola Tuecke 
> 
> We have at least a minor count of boards, that failed to re-initialize
> PCI express in the Linux kernel. Typical failure rate is 20% on affected
> boards. This is mitigated by commit 6ecbe1375671 ("drivers: pci: imx:
> add imx_pcie_remove function").
> 
> However, at least on some i.MX6 custom boards, when calling
> assert_core_reset() as part of the first-time PCIe init, read access
> to PCIE_PL_PFLR simply hangs. Surround this readl() with 
> imx_pcie_fix_dabt_handler() does not help. For this reason, the forced
> LTSSM detection is only used on the second assert_core_reset() that is
> called shorly before starting the Linux kernel.
> 
> Signed-off-by: Sven-Ola Tuecke 
> Signed-off-by: Fabio Estevam 
> ---


Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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

Re: [U-Boot] [PATCH] i.mx6ul: xpress: update UART init for current board revision

[Stefano Babic]

On 02/10/2017 21:32, Anatolij Gustschin wrote:
> UART pinmux has been changed on the last board revision. Change
> board pinmux accordingly. Console is on UART7 now, add pinmux,
> base address and update console string in environment.
> 
> Signed-off-by: Anatolij Gustschin 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


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

Re: [U-Boot] [PATCH 1/2] mx6: clock: Add a prototype for do_mx6_showclocks()

[Stefano Babic]

On 05/10/2017 14:15, Diego Dorta wrote:
> When compiling with W=1 the following warning is observed:
> 
> arch/arm/mach-imx/mx6/clock.c:1268:5: warning: no previous prototype for 
> ‘do_mx6_showclocks’ [-Wmissing-prototypes] int do_mx6_showclocks(cmd_tbl_t 
> *cmdtp, int flag, int argc, char * const argv[])
> 
> Remove this warning by adding the function prototype into arch-mx6/clock.h 
> file.
> 
> Signed-off-by: Diego Dorta 
> ---
>  arch/arm/include/asm/arch-mx6/clock.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/include/asm/arch-mx6/clock.h 
> b/arch/arm/include/asm/arch-mx6/clock.h
> index 2d9c45e..26afefb 100644
> --- a/arch/arm/include/asm/arch-mx6/clock.h
> +++ b/arch/arm/include/asm/arch-mx6/clock.h
> @@ -80,4 +80,5 @@ void enable_thermal_clk(void);
>  void mxs_set_lcdclk(u32 base_addr, u32 freq);
>  void select_ldb_di_clock_source(enum ldb_di_clock clk);
>  void enable_eim_clk(unsigned char enable);
> +int do_mx6_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[]);
>  #endif /* __ASM_ARCH_CLOCK_H */
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 2/2] mx6: sys_proto: Add prototypes for imx6_pcie_toggle() functions

[Stefano Babic]

On 05/10/2017 14:15, Diego Dorta wrote:
> When compiling with W=1 errors are observed:
> 
> drivers/pci/pcie_imx.c:517:12: warning: no previous prototype for 
> ‘imx6_pcie_toggle_power’ [-Wmissing-prototypes] __weak int 
> imx6_pcie_toggle_power(void)
> 
> drivers/pci/pcie_imx.c:528:12: warning: no previous prototype for 
> ‘imx6_pcie_toggle_reset’ [-Wmissing-prototypes] __weak int 
> imx6_pcie_toggle_reset(void)
> 
> Remove these warnings by adding the functions prototypes on 
> arch-mx6/sys_proto.
> 
> Signed-off-by: Diego Dorta 
> ---
>  arch/arm/include/asm/arch-mx6/sys_proto.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
> b/arch/arm/include/asm/arch-mx6/sys_proto.h
> index ba73943..b22a7a0 100644
> --- a/arch/arm/include/asm/arch-mx6/sys_proto.h
> +++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
> @@ -13,3 +13,6 @@
>  
>  #define is_usbotg_phy_active(void) (!(readl(USB_PHY0_BASE_ADDR + USBPHY_PWD) 
> & \
>  USBPHY_PWD_RXPWDRX))
> +
> +int imx6_pcie_toggle_power(void);
> +int imx6_pcie_toggle_reset(void);
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] imx: mx7: spl: remove redundant SATA definitionas

[Stefano Babic]

On 10/10/2017 08:13, Uri Mashiach wrote:
> The i.MX7 SOC doesn't include the SATA interface.
> 
> Signed-off-by: Uri Mashiach 
> ---
>  include/configs/imx7_spl.h | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/include/configs/imx7_spl.h b/include/configs/imx7_spl.h
> index e562cdb..b89dba6 100644
> --- a/include/configs/imx7_spl.h
> +++ b/include/configs/imx7_spl.h
> @@ -41,12 +41,6 @@
>  #define CONFIG_SYS_MONITOR_LEN   409600  /* 400 KB */
>  #endif
>  
> -/* SATA support */
> -#if defined(CONFIG_SPL_SATA_SUPPORT)
> -#define CONFIG_SPL_SATA_BOOT_DEVICE  0
> -#define CONFIG_SYS_SATA_FAT_BOOT_PARTITION   1
> -#endif
> -
>  /* Define the payload for FAT/EXT support */
>  #if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
>  # ifdef CONFIG_OF_CONTROL
> 

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH V2] ARM: imx6: Add DHCOM i.MX6 PDK board support

[Stefano Babic]

On 09/10/2017 21:51, Marek Vasut wrote:
> Add support for the DHCOM i.MX6 PDK board. This board has:
> - FEC ethernet
> - EHCI USB host
> - 3x SDMMC
> 
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
> ---
> V2: Use get_cpu_type() and imx_get_mac_from_fuse()
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Mark Kettenis]

> From: Rob Clark 
> Date: Thu, 12 Oct 2017 10:28:43 -0400
> 
> On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
> > On 10/12/2017 03:40 PM, Rob Clark wrote:
> >>
> >> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
> >> wrote:
> >>>
> >>>
> >>> On 10/12/2017 02:48 PM, Rob Clark wrote:
> 
>  On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
> >
> >
> >
> > On 12.10.17 00:07, Rob Clark wrote:
> >>
> >> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 10.10.17 14:23, Rob Clark wrote:
> 
>  In some cases, it is quite useful to have (for example) EFI on
>  screen
>  but u-boot on serial port.
> 
>  This adds two new optional environment variables, "efiin" and
>  "efiout",
>  which can be used to set EFI console input/output independently of
>  u-boot's input/output.  If unset, EFI console will default to stdin/
>  stdout as before.
> 
>  Signed-off-by: Rob Clark 
> >>>
> >>>
> >>> With this patch, we lose the ability to have the efi in/out go to
> >>> both
> >>> graphical and serial console, right? This is critical functionality
> >>> to
> >>> have, since we don't necessarily know which output/input a user ends
> >>> up
> >>> using.
> >>
> >>
> >> I'll think about how to support iomux.. but some things like console
> >> size are just not going to work properly there.  And as long as we fix
> >
> >
> > Yeah, those probably would need to get special cased.
> >
> >> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
> >> simply not set efiout var and have things working as before, so you
> >> don't loose any existing functionality (although, like I said, if the
> >> two different consoles have different sizes things aren't going to
> >> work properly for anything other than simple cases).
> >>
> >> In most cases, the display driver should be able to detect whether a
> >> display is connected.. this is what I've done on dragonboard410c, so
> >> if no display plugged in, 'efiout=vidconsole' fails and you fall back
> >> to serial, else you get efi on screen like you would on a "real"
> >> computer.  For boards that have a display driver that isn't able to do
> >> the basic check of whether a cable is plugged in, just don't set
> >> "efiout" (or fix the display driver) ;-)
> >
> >
> > Are you sure that's what happens on a "real" computer? As far as I
> > remember from all ARM servers running edk2 based firmware that I've
> > touched so far, the default is always to display on serial *and*
> > graphical output at the same time.
> 
> 
>  Well, I suppose some of the arm64 server vendors have done a better
>  job than others on firmware.. you'd hope they would probe EDID, and
>  report correct console dimensions based on display resolution, etc.
> 
>  Doing both serial and display works for simple stuff, but it goes
>  badly once the efi payload starts trying to change the cursor position
>  and write to specific parts of the screen (which both Shell.efi and
>  grub try to do).
> 
>  BR,
>  -R
> 
> >>> Hello Rob,
> >>>
> >>> I do not know which program you use for connecting to your serial
> >>> console. I
> >>> use minicom which is a Debian/Ubuntu package. I had no problem using
> >>> grub,
> >>> vim, nano or any other console program.
> >>>
> >>> Minicom just provides a VT100 emulation and that is close enough to what
> >>> Linux expects.
> >>
> >> fwiw, I generally use kermit so my terminal emulator is whatever
> >> "xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
> >> isn't so much the issue..
> >>
> >>> So I would not see what should be so special about Shell.efi.
> >>
> >> I'm not explaining the problem well, but you can see basically the
> >> same issue if you resize your terminal emulator to something smaller
> >> than what grub/shell/etc think you are using.
> >>
> >> I guess if they just fall back to assuming 80x25 like agraf mentioned,
> >> that would kind of work.  It just means shell or grub will only use
> >> the tiny upper-left corner of your monitor.
> >>
> >>> My U-Boot system all have video but I never have a monitor connected.
> >>>
> >>> So being able to use serial even if video is available is a necessity.
> >>
> >> If the video driver doesn't detect that it is unconnected, someone
> >> should really fix that, otherwise you'll have problems booting an
> >> image where grub tries to use gfxterm if GOP is present (but we are
> >> really getting off topic here)
> >>
> >> Either way, you still have the option of not setting efiout (or
> >> setting it to serial)

[U-Boot] Rebase on u-boot-imx !

[Stefano Babic]

Hi iMXers,

I was preparing to send my PR to Tom, but the request pull reveals that
something went wrong. A lot of files not related to iMX was part of PR.
I have tried to find the reason, but no way.

I have then rebased u-boot-imx on Tom's (but not yet pushed to server),
and applied all patches. It looks like ok now, but you will note that I
rebased. Sorry for inconvenience.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH v2 2/2] icorem6_rqs: env: Return mmc devno

[Stefano Babic]

On 12/10/2017 16:44, Jagan Teki wrote:
> Instead of changing mmc devno from dts nodes better
> to return the detected devno so-that env trigger the same.
> 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v2:
> - None
> 
>  board/engicam/icorem6_rqs/icorem6_rqs.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/board/engicam/icorem6_rqs/icorem6_rqs.c 
> b/board/engicam/icorem6_rqs/icorem6_rqs.c
> index 2a321dc..0114889 100644
> --- a/board/engicam/icorem6_rqs/icorem6_rqs.c
> +++ b/board/engicam/icorem6_rqs/icorem6_rqs.c
> @@ -27,8 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #ifdef CONFIG_ENV_IS_IN_MMC
>  int board_mmc_get_env_dev(int devno)
>  {
> - /* dev 0 for SD/eSD, dev 1 for MMC/eMMC */
> - return (devno == 3) ? 1 : 0;
> + return devno;
>  }
>  #endif
>  
> 

Reviewed-by: Stefano Babic 

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] power: extend prefix match to regulator-name property

[Felix Brack]

On 12.10.2017 14:53, Chen-Yu Tsai wrote:
> On Thu, Oct 12, 2017 at 8:24 PM, Felix Brack  wrote:
>> On 12.10.2017 04:46, Chen-Yu Tsai wrote:
>>> On Mon, Oct 9, 2017 at 6:04 PM, Felix Brack  wrote:
 This patch extends pmic_bind_children prefix matching. In addition to
 the node name the property regulator-name is used while trying to match
 prefixes. This allows assigning different drivers to regulator nodes
 named regulator@1 and regulator@10 for example.
>>>
>>> No. See the regulator bindings:
>>>
>>> Optional properties:
>>> - regulator-name: A string used as a descriptive name for regulator outputs
>>>
>> The actual regulator.txt states:
>>
>> Optional properties:
>>  - regulator-name: a string, required by the regulator uclass
>>
>> This was the reason for choosing the regulator-name property.
> 
> Mine was from the Linux Kernel. Are there two sets of bindings?
> Shouldn't there be just one?
> 
Mine was from U-Boot as this is the U-Boot mailing list and things do
not seem to be fully synchronized between LINUX and U-Boot.

>>> This can vary from board to board. The name should match the power rail
>>> name of the board (which may not be the same as the regulator chip's
>>> output name).
>>>
>> Exactly. I totally agree but as stated in an earlier post: I did not
>> define the names for the regulators and modifying them is almost
>> certainly not the right way to go. Let me explain this briefly. The
>> regulator names I'm trying to match are those from tps65910.dtsi, an
>> include file. The exact same file is part of the LINUX kernel. Therefore
>> I resigned suggesting the modification of the node names.
> 
> First, it is an include file. Board files are free to override the
> name. We did that for sunxi at first, have the .dtsi file provide
> some default names, then have board .dts files override them with
> names that make more sense. Later on we just dropped the default
> names altogether.
>
I am definitely confused now, maybe we are using same terms for
different things. When I'm talking about a 'name' I mean the 'node name'
 according to DT specification (as for instance returned by
ofnode_get_name). I'm not talking about a property or a node label. The
following code defines a node name 'regulator@2' ore more precisely a
node named 'regulator' having unit-address 2:

vdd1_reg: regulator@2 {
reg = <2>;
regulator-compatible = "vdd1";
};

This is found in tps65910.dtsi include file. You say "board files are
free to override the name". Hence I could include the tps65910.dtsi into
my board dts file and kind of rename node 'regulator@2' by let's say
'buck_vdd1@2'?
The only way of "overriding" I can think of is by not including the dtsi
file and redefining all nodes.

> The same pattern is also seen in tps65910.dtsi and am3517-craneboard.dts.
> And also am335x-evm.dts, which the tps65910.dtsi was tested with.
>
Looking at the am3517-craneboard.dts file I don't see how node names are
getting overwritten. What gets set, changed or overwritten is the node
property regulator-name.

> Now I couldn't find the binding document for tps65910, but looking
> at tps65217 instead, it says:
> 
> - regulators: list of regulators provided by this controller, must be named
>   after their hardware counterparts: dcdc[1-3] and ldo[1-4]
> 
> And indeed that is what's used in the example.
>
Yes, exactly and correct. Again, this tps65217.txt does only exist in
LINUX and not in U-Boot.

> So clearly the dts files aren't following the binding.
>
And what about the dtsi files? Are they correct in defining node names
as 'regulator@[unit-address]'?

>>
>>> If you have multiple regulator nodes which need to be differentiated,
>>> you need to use the deprecated "regulator-compatible" property, or just
>>> use the standard compatible property.
>>>
>> Good point. I would not use a deprecated property but the compatible
>> property seems reasonable to me. So you agree that the patch's concept
>> could be retained while substituting the node-name property by the
>> compatible property?
> 
> If you're going to modify the binding and/or device tree files, please
> do it in both places. Ideally the platform should have one canonical
> source for them.
> 
> Linux's standard regulator DT matching code only matches against node
> names and the deprecated "regulator-compatible" property. Not even the
> standard "compatible" is used, though I see a few PMICs using that.
> So even if you do get them working this way in U-boot, it's still not
> going to work in Linux, and you might get other comments when pushing
> your changes.
> 
I guess if LINUX would not match against the regulator-compatible
property but only against the node name things would not work properly.
Again looking the file tps65217.dtsi shows that every regulator node
(named regulator@0 to regulator@6) defines the regulator-compatible
property. Only matching against this property therefore makes things
working.

Felix

Re: [U-Boot] [U-Boot, 05/11] efi_loader: console support for color attributes

[Alexander Graf]

> Shell.efi uses this, and supporting color attributes makes things look
> nicer.  Map the EFI fg/bg color attributes to ANSI escape sequences.
> Not all colors have a perfect match, but spec just says "Devices
> supporting a different number of text colors are required to emulate the
> above colors to the best of the device’s capabilities".
> 
> Signed-off-by: Rob Clark 
> Tested-by: Heinrich Schuchardt 
> Reviewed-by: Alexander Graf 

Thanks, applied to efi-next

Alex

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

Re: [U-Boot] [U-Boot, 10/11] efi_loader: Add mem-mapped for fallback

[Alexander Graf]

> When we don't have a real device/image path, such as 'bootefi hello',
> construct a mem-mapped device-path.
> 
> This fixes 'bootefi hello' after devicepath refactoring.
> 
> Fixes: 95c5553ea2 ("efi_loader: refactor boot device and loaded_image 
> handling")
> Signed-off-by: Rob Clark 
> Acked-by: Heinrich Schuchardt 

Thanks, applied to efi-next

Alex

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

[U-Boot] Please pull u-boot-fsl-qoriq master

[York Sun]

Tom,

The following changes since commit 39dd65a059e503883dbf16d4c00ac083d15837da:

  sandbox: Enable btrfs support (2017-10-03 08:44:55 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-fsl-qoriq.git

for you to fetch changes up to 23af484b0156baaafd578222d73513418df78f09:

  armv8: ls1043ardb_sdcard: prepare falcon boot (2017-10-09 08:48:45 -0700)


Bogdan Purcareata (1):
  armv8: ls1088a: Update MC boot sequence

Fabio Estevam (1):
  armv7: ls1021aiot: Move CONFIG_CMD_BOOTZ to Kconfig

Gong Qianyu (1):
  armv8: ls1046aqds: Fix NAND offset for Fman ucode and env

Ran Wang (1):
  armv8: Apply workaround for USB erratum A-009007 to LS1088A

Sumit Garg (1):
  armv8: fsl-layerscape: Allocate Secure memory from first ddr region

York Sun (7):
  spl: fix assignment of board info to global data
  cmd: spl: fix compiling error when CONFIG_CMD_SPL_WRITE_SIZE not
defined
  armv8: fsl-layerscape: Avoid running dram_init_banksize again
  armv8: ls1043ardb: Use static DDR setting for SPL boot
  armv8: layerscape: Enable falcon boot
  armv8: ls1043ardb: Enable spl_board_init() function
  armv8: ls1043ardb_sdcard: prepare falcon boot

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |   1 +
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  77 ++--
 .../arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 140
+
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   4 +-
 arch/arm/cpu/armv8/fsl-layerscape/spl.c|  26 
 arch/arm/include/asm/system.h  |   4 +-
 arch/arm/lib/spl.c |  11 ++
 board/freescale/ls1043ardb/ddr.c   |  46 +++
 board/freescale/ls1043ardb/ddr.h   |  69 ++
 board/freescale/ls1088a/eth_ls1088aqds.c   |  14 ++-
 board/freescale/ls1088a/eth_ls1088ardb.c   |  13 +-
 cmd/spl.c  |   2 +
 common/spl/spl.c   |  10 +-
 configs/ls1021aiot_qspi_defconfig  |   1 +
 configs/ls1021aiot_sdcard_defconfig|   1 +
 configs/ls1043ardb_nand_SECURE_BOOT_defconfig  |   1 +
 configs/ls1043ardb_nand_defconfig  |   1 +
 configs/ls1043ardb_sdcard_SECURE_BOOT_defconfig|   1 +
 configs/ls1043ardb_sdcard_defconfig|   2 +
 include/configs/ls1021aiot.h   |   1 -
 include/configs/ls1043a_common.h   |   7 +-
 include/configs/ls1043ardb.h   |  11 +-
 include/configs/ls1046a_common.h   |   2 +-
 include/configs/ls1046aqds.h   |   2 +-
 include/configs/ls1088a_common.h   |   6 +
 include/spl.h  |   1 +
 26 files changed, 387 insertions(+), 67 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon

Thanks.

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

[U-Boot] [PATCH v2 2/2] icorem6_rqs: env: Return mmc devno

[Jagan Teki]

Instead of changing mmc devno from dts nodes better
to return the detected devno so-that env trigger the same.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- None

 board/engicam/icorem6_rqs/icorem6_rqs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/board/engicam/icorem6_rqs/icorem6_rqs.c 
b/board/engicam/icorem6_rqs/icorem6_rqs.c
index 2a321dc..0114889 100644
--- a/board/engicam/icorem6_rqs/icorem6_rqs.c
+++ b/board/engicam/icorem6_rqs/icorem6_rqs.c
@@ -27,8 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #ifdef CONFIG_ENV_IS_IN_MMC
 int board_mmc_get_env_dev(int devno)
 {
-   /* dev 0 for SD/eSD, dev 1 for MMC/eMMC */
-   return (devno == 3) ? 1 : 0;
+   return devno;
 }
 #endif
 
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/2] icore: configs: Fix merge conflict issue

[Jagan Teki]

Fix for finding mmc devices on i.MX6Q icore boards
added in below comment
"icorem6: Fix to find MMC devices"
(sha1: a2b137b38d925df91afef52f5122927de024f81a)

which is reverted in during u-boot-imx merge
" Merge git://git.denx.de/u-boot-imx"
(sha1: 6aee2ab68c362ace5a59f89a63abed82e0bf19e5)

This patch, is recreated to fix merge conflict.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- None

 configs/imx6qdl_icore_mmc_defconfig | 1 -
 configs/imx6qdl_icore_rqs_defconfig | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/imx6qdl_icore_mmc_defconfig 
b/configs/imx6qdl_icore_mmc_defconfig
index 7a1735a..28e4ce9 100644
--- a/configs/imx6qdl_icore_mmc_defconfig
+++ b/configs/imx6qdl_icore_mmc_defconfig
@@ -36,7 +36,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_LIST="imx6q-icore imx6dl-icore"
 CONFIG_ENV_IS_IN_MMC=y
-# CONFIG_BLK is not set
 CONFIG_SYS_I2C_MXC=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_SMSC=y
diff --git a/configs/imx6qdl_icore_rqs_defconfig 
b/configs/imx6qdl_icore_rqs_defconfig
index 1d02ad0..fbe9651 100644
--- a/configs/imx6qdl_icore_rqs_defconfig
+++ b/configs/imx6qdl_icore_rqs_defconfig
@@ -33,7 +33,6 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_LIST="imx6q-icore-rqs imx6dl-icore-rqs"
 CONFIG_ENV_IS_IN_MMC=y
-# CONFIG_BLK is not set
 CONFIG_SYS_I2C_MXC=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
-- 
2.7.4

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Alexander Graf]

On 10/12/2017 04:28 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:

On 10/12/2017 03:40 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
wrote:


On 10/12/2017 02:48 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:



On 12.10.17 00:07, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
wrote:



On 10.10.17 14:23, Rob Clark wrote:

In some cases, it is quite useful to have (for example) EFI on
screen
but u-boot on serial port.

This adds two new optional environment variables, "efiin" and
"efiout",
which can be used to set EFI console input/output independently of
u-boot's input/output.  If unset, EFI console will default to stdin/
stdout as before.

Signed-off-by: Rob Clark 


With this patch, we lose the ability to have the efi in/out go to
both
graphical and serial console, right? This is critical functionality
to
have, since we don't necessarily know which output/input a user ends
up
using.


I'll think about how to support iomux.. but some things like console
size are just not going to work properly there.  And as long as we fix


Yeah, those probably would need to get special cased.


the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
simply not set efiout var and have things working as before, so you
don't loose any existing functionality (although, like I said, if the
two different consoles have different sizes things aren't going to
work properly for anything other than simple cases).

In most cases, the display driver should be able to detect whether a
display is connected.. this is what I've done on dragonboard410c, so
if no display plugged in, 'efiout=vidconsole' fails and you fall back
to serial, else you get efi on screen like you would on a "real"
computer.  For boards that have a display driver that isn't able to do
the basic check of whether a cable is plugged in, just don't set
"efiout" (or fix the display driver) ;-)


Are you sure that's what happens on a "real" computer? As far as I
remember from all ARM servers running edk2 based firmware that I've
touched so far, the default is always to display on serial *and*
graphical output at the same time.


Well, I suppose some of the arm64 server vendors have done a better
job than others on firmware.. you'd hope they would probe EDID, and
report correct console dimensions based on display resolution, etc.

Doing both serial and display works for simple stuff, but it goes
badly once the efi payload starts trying to change the cursor position
and write to specific parts of the screen (which both Shell.efi and
grub try to do).

BR,
-R


Hello Rob,

I do not know which program you use for connecting to your serial
console. I
use minicom which is a Debian/Ubuntu package. I had no problem using
grub,
vim, nano or any other console program.

Minicom just provides a VT100 emulation and that is close enough to what
Linux expects.

fwiw, I generally use kermit so my terminal emulator is whatever
"xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
isn't so much the issue..


So I would not see what should be so special about Shell.efi.

I'm not explaining the problem well, but you can see basically the
same issue if you resize your terminal emulator to something smaller
than what grub/shell/etc think you are using.

I guess if they just fall back to assuming 80x25 like agraf mentioned,
that would kind of work.  It just means shell or grub will only use
the tiny upper-left corner of your monitor.


My U-Boot system all have video but I never have a monitor connected.

So being able to use serial even if video is available is a necessity.

If the video driver doesn't detect that it is unconnected, someone
should really fix that, otherwise you'll have problems booting an
image where grub tries to use gfxterm if GOP is present (but we are
really getting off topic here)

Either way, you still have the option of not setting efiout (or
setting it to serial)

But for end users (at least of boards that I care about), if they plug
in a monitor they should get grub on screen.  Not everyone has a
serial cable attached.


I fully agree there. The same applies the other way around too. Even if they
have a monitor attached, they should get grub on serial if serial is a valid
output :). Just attaching a monitor doesn't mean you only use that monitor
to control the system.

We could, I suppose, try probing the serial console's size, as an
approximation of hotplug detect for serial.  If we timeout without
getting a response, assume no serial console.

That would also let us pick the minimum of each dimension to report to
the payload, which is less horrible than just having an 80x25 grub
menu on your 4k screen.  And if no serial attached, then we can use
the full screen.


Now we're talking - that sounds much nicer indeed :)


Alex

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Rob Clark]

On Thu, Oct 12, 2017 at 9:50 AM, Alexander Graf  wrote:
> On 10/12/2017 03:40 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt 
>> wrote:
>>>
>>>
>>> On 10/12/2017 02:48 PM, Rob Clark wrote:

 On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>
>
>
> On 12.10.17 00:07, Rob Clark wrote:
>>
>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf 
>> wrote:
>>>
>>>
>>>
>>> On 10.10.17 14:23, Rob Clark wrote:

 In some cases, it is quite useful to have (for example) EFI on
 screen
 but u-boot on serial port.

 This adds two new optional environment variables, "efiin" and
 "efiout",
 which can be used to set EFI console input/output independently of
 u-boot's input/output.  If unset, EFI console will default to stdin/
 stdout as before.

 Signed-off-by: Rob Clark 
>>>
>>>
>>> With this patch, we lose the ability to have the efi in/out go to
>>> both
>>> graphical and serial console, right? This is critical functionality
>>> to
>>> have, since we don't necessarily know which output/input a user ends
>>> up
>>> using.
>>
>>
>> I'll think about how to support iomux.. but some things like console
>> size are just not going to work properly there.  And as long as we fix
>
>
> Yeah, those probably would need to get special cased.
>
>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
>> simply not set efiout var and have things working as before, so you
>> don't loose any existing functionality (although, like I said, if the
>> two different consoles have different sizes things aren't going to
>> work properly for anything other than simple cases).
>>
>> In most cases, the display driver should be able to detect whether a
>> display is connected.. this is what I've done on dragonboard410c, so
>> if no display plugged in, 'efiout=vidconsole' fails and you fall back
>> to serial, else you get efi on screen like you would on a "real"
>> computer.  For boards that have a display driver that isn't able to do
>> the basic check of whether a cable is plugged in, just don't set
>> "efiout" (or fix the display driver) ;-)
>
>
> Are you sure that's what happens on a "real" computer? As far as I
> remember from all ARM servers running edk2 based firmware that I've
> touched so far, the default is always to display on serial *and*
> graphical output at the same time.


 Well, I suppose some of the arm64 server vendors have done a better
 job than others on firmware.. you'd hope they would probe EDID, and
 report correct console dimensions based on display resolution, etc.

 Doing both serial and display works for simple stuff, but it goes
 badly once the efi payload starts trying to change the cursor position
 and write to specific parts of the screen (which both Shell.efi and
 grub try to do).

 BR,
 -R

>>> Hello Rob,
>>>
>>> I do not know which program you use for connecting to your serial
>>> console. I
>>> use minicom which is a Debian/Ubuntu package. I had no problem using
>>> grub,
>>> vim, nano or any other console program.
>>>
>>> Minicom just provides a VT100 emulation and that is close enough to what
>>> Linux expects.
>>
>> fwiw, I generally use kermit so my terminal emulator is whatever
>> "xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
>> isn't so much the issue..
>>
>>> So I would not see what should be so special about Shell.efi.
>>
>> I'm not explaining the problem well, but you can see basically the
>> same issue if you resize your terminal emulator to something smaller
>> than what grub/shell/etc think you are using.
>>
>> I guess if they just fall back to assuming 80x25 like agraf mentioned,
>> that would kind of work.  It just means shell or grub will only use
>> the tiny upper-left corner of your monitor.
>>
>>> My U-Boot system all have video but I never have a monitor connected.
>>>
>>> So being able to use serial even if video is available is a necessity.
>>
>> If the video driver doesn't detect that it is unconnected, someone
>> should really fix that, otherwise you'll have problems booting an
>> image where grub tries to use gfxterm if GOP is present (but we are
>> really getting off topic here)
>>
>> Either way, you still have the option of not setting efiout (or
>> setting it to serial)
>>
>> But for end users (at least of boards that I care about), if they plug
>> in a monitor they should get grub on screen.  Not everyone has a
>> serial cable attached.
>
>
> I fully agree there. The same applies the other way around too. Even if they
> have a monitor attached, they should get grub on serial if serial 

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Rob Clark]

On Thu, Oct 12, 2017 at 9:44 AM, Mark Kettenis  wrote:
>> From: Rob Clark 
>> Date: Thu, 12 Oct 2017 08:48:39 -0400
>>
>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>> >
>> >
>> > On 12.10.17 00:07, Rob Clark wrote:
>> >> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  wrote:
>> >>>
>> >>>
>> >>> On 10.10.17 14:23, Rob Clark wrote:
>>  In some cases, it is quite useful to have (for example) EFI on screen
>>  but u-boot on serial port.
>> 
>>  This adds two new optional environment variables, "efiin" and "efiout",
>>  which can be used to set EFI console input/output independently of
>>  u-boot's input/output.  If unset, EFI console will default to stdin/
>>  stdout as before.
>> 
>>  Signed-off-by: Rob Clark 
>> >>>
>> >>> With this patch, we lose the ability to have the efi in/out go to both
>> >>> graphical and serial console, right? This is critical functionality to
>> >>> have, since we don't necessarily know which output/input a user ends up
>> >>> using.
>
> Seconded.  In many cases I'd want to continue using serial as the
> console even if a display is connected.

Sure, and this patch isn't preventing that.

>> >> I'll think about how to support iomux.. but some things like console
>> >> size are just not going to work properly there.  And as long as we fix
>> >
>> > Yeah, those probably would need to get special cased.
>> >
>> >> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
>> >> simply not set efiout var and have things working as before, so you
>> >> don't loose any existing functionality (although, like I said, if the
>> >> two different consoles have different sizes things aren't going to
>> >> work properly for anything other than simple cases).
>> >>
>> >> In most cases, the display driver should be able to detect whether a
>> >> display is connected.. this is what I've done on dragonboard410c, so
>> >> if no display plugged in, 'efiout=vidconsole' fails and you fall back
>> >> to serial, else you get efi on screen like you would on a "real"
>> >> computer.  For boards that have a display driver that isn't able to do
>> >> the basic check of whether a cable is plugged in, just don't set
>> >> "efiout" (or fix the display driver) ;-)
>
> Display detection will always be somewhat fragile.  The old Sun
> workstations used to base the decision on whether a keyboard was
> connected.  With no keyboard detected the output would always go to
> serial.

s/always/sometimes/

For analog outputs it can be more tricky.  For any display technology
from this century, it isn't really that hard.

Boards that cannot reliably detect whether a display is connected
probably don't want to set efiout.

>> > Are you sure that's what happens on a "real" computer? As far as I
>> > remember from all ARM servers running edk2 based firmware that I've
>> > touched so far, the default is always to display on serial *and*
>> > graphical output at the same time.
>>
>> Well, I suppose some of the arm64 server vendors have done a better
>> job than others on firmware.. you'd hope they would probe EDID, and
>> report correct console dimensions based on display resolution, etc.
>>
>> Doing both serial and display works for simple stuff, but it goes
>> badly once the efi payload starts trying to change the cursor position
>> and write to specific parts of the screen (which both Shell.efi and
>> grub try to do).
>
> From my point of view a bootloader should only do "simple stuff".  All
> this fancy display stuff makes a serial console much harder to use.

Sure, but people who tinker with u-boot and low level stuff aren't the
only target audience here.

This patch provides a (completely optional) way to provide a sane
default that doesn't require a serial cable, yet still works with one
if you don't have a display connected.. some people expect to be able
to just plug in display + keyboard + power and get to a grub boot
menu, just like you would on an x86/uefi system.

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Alexander Graf]

On 10/12/2017 03:40 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt  wrote:


On 10/12/2017 02:48 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:



On 12.10.17 00:07, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  wrote:



On 10.10.17 14:23, Rob Clark wrote:

In some cases, it is quite useful to have (for example) EFI on screen
but u-boot on serial port.

This adds two new optional environment variables, "efiin" and
"efiout",
which can be used to set EFI console input/output independently of
u-boot's input/output.  If unset, EFI console will default to stdin/
stdout as before.

Signed-off-by: Rob Clark 


With this patch, we lose the ability to have the efi in/out go to both
graphical and serial console, right? This is critical functionality to
have, since we don't necessarily know which output/input a user ends up
using.


I'll think about how to support iomux.. but some things like console
size are just not going to work properly there.  And as long as we fix


Yeah, those probably would need to get special cased.


the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
simply not set efiout var and have things working as before, so you
don't loose any existing functionality (although, like I said, if the
two different consoles have different sizes things aren't going to
work properly for anything other than simple cases).

In most cases, the display driver should be able to detect whether a
display is connected.. this is what I've done on dragonboard410c, so
if no display plugged in, 'efiout=vidconsole' fails and you fall back
to serial, else you get efi on screen like you would on a "real"
computer.  For boards that have a display driver that isn't able to do
the basic check of whether a cable is plugged in, just don't set
"efiout" (or fix the display driver) ;-)


Are you sure that's what happens on a "real" computer? As far as I
remember from all ARM servers running edk2 based firmware that I've
touched so far, the default is always to display on serial *and*
graphical output at the same time.


Well, I suppose some of the arm64 server vendors have done a better
job than others on firmware.. you'd hope they would probe EDID, and
report correct console dimensions based on display resolution, etc.

Doing both serial and display works for simple stuff, but it goes
badly once the efi payload starts trying to change the cursor position
and write to specific parts of the screen (which both Shell.efi and
grub try to do).

BR,
-R


Hello Rob,

I do not know which program you use for connecting to your serial console. I
use minicom which is a Debian/Ubuntu package. I had no problem using grub,
vim, nano or any other console program.

Minicom just provides a VT100 emulation and that is close enough to what
Linux expects.

fwiw, I generally use kermit so my terminal emulator is whatever
"xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
isn't so much the issue..


So I would not see what should be so special about Shell.efi.

I'm not explaining the problem well, but you can see basically the
same issue if you resize your terminal emulator to something smaller
than what grub/shell/etc think you are using.

I guess if they just fall back to assuming 80x25 like agraf mentioned,
that would kind of work.  It just means shell or grub will only use
the tiny upper-left corner of your monitor.


My U-Boot system all have video but I never have a monitor connected.

So being able to use serial even if video is available is a necessity.

If the video driver doesn't detect that it is unconnected, someone
should really fix that, otherwise you'll have problems booting an
image where grub tries to use gfxterm if GOP is present (but we are
really getting off topic here)

Either way, you still have the option of not setting efiout (or
setting it to serial)

But for end users (at least of boards that I care about), if they plug
in a monitor they should get grub on screen.  Not everyone has a
serial cable attached.


I fully agree there. The same applies the other way around too. Even if 
they have a monitor attached, they should get grub on serial if serial 
is a valid output :). Just attaching a monitor doesn't mean you only use 
that monitor to control the system.


I think for multi-out we really just have to do what edk2 does and limit 
the screen size to 80x25. I guess you'd just create an iomux target 
there that would return the fake size info?



Alex

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Mark Kettenis]

> From: Rob Clark 
> Date: Thu, 12 Oct 2017 08:48:39 -0400
> 
> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
> >
> >
> > On 12.10.17 00:07, Rob Clark wrote:
> >> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  wrote:
> >>>
> >>>
> >>> On 10.10.17 14:23, Rob Clark wrote:
>  In some cases, it is quite useful to have (for example) EFI on screen
>  but u-boot on serial port.
> 
>  This adds two new optional environment variables, "efiin" and "efiout",
>  which can be used to set EFI console input/output independently of
>  u-boot's input/output.  If unset, EFI console will default to stdin/
>  stdout as before.
> 
>  Signed-off-by: Rob Clark 
> >>>
> >>> With this patch, we lose the ability to have the efi in/out go to both
> >>> graphical and serial console, right? This is critical functionality to
> >>> have, since we don't necessarily know which output/input a user ends up
> >>> using.

Seconded.  In many cases I'd want to continue using serial as the
console even if a display is connected.

> >> I'll think about how to support iomux.. but some things like console
> >> size are just not going to work properly there.  And as long as we fix
> >
> > Yeah, those probably would need to get special cased.
> >
> >> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
> >> simply not set efiout var and have things working as before, so you
> >> don't loose any existing functionality (although, like I said, if the
> >> two different consoles have different sizes things aren't going to
> >> work properly for anything other than simple cases).
> >>
> >> In most cases, the display driver should be able to detect whether a
> >> display is connected.. this is what I've done on dragonboard410c, so
> >> if no display plugged in, 'efiout=vidconsole' fails and you fall back
> >> to serial, else you get efi on screen like you would on a "real"
> >> computer.  For boards that have a display driver that isn't able to do
> >> the basic check of whether a cable is plugged in, just don't set
> >> "efiout" (or fix the display driver) ;-)

Display detection will always be somewhat fragile.  The old Sun
workstations used to base the decision on whether a keyboard was
connected.  With no keyboard detected the output would always go to
serial.

> > Are you sure that's what happens on a "real" computer? As far as I
> > remember from all ARM servers running edk2 based firmware that I've
> > touched so far, the default is always to display on serial *and*
> > graphical output at the same time.
> 
> Well, I suppose some of the arm64 server vendors have done a better
> job than others on firmware.. you'd hope they would probe EDID, and
> report correct console dimensions based on display resolution, etc.
> 
> Doing both serial and display works for simple stuff, but it goes
> badly once the efi payload starts trying to change the cursor position
> and write to specific parts of the screen (which both Shell.efi and
> grub try to do).

From my point of view a bootloader should only do "simple stuff".  All
this fancy display stuff makes a serial console much harder to use.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Rob Clark]

On Thu, Oct 12, 2017 at 9:11 AM, Alexander Graf  wrote:
> On 10/12/2017 02:48 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>>
>>>
>>> On 12.10.17 00:07, Rob Clark wrote:

 On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  wrote:
>
>
> On 10.10.17 14:23, Rob Clark wrote:
>>
>> In some cases, it is quite useful to have (for example) EFI on screen
>> but u-boot on serial port.
>>
>> This adds two new optional environment variables, "efiin" and
>> "efiout",
>> which can be used to set EFI console input/output independently of
>> u-boot's input/output.  If unset, EFI console will default to stdin/
>> stdout as before.
>>
>> Signed-off-by: Rob Clark 
>
> With this patch, we lose the ability to have the efi in/out go to both
> graphical and serial console, right? This is critical functionality to
> have, since we don't necessarily know which output/input a user ends up
> using.

 I'll think about how to support iomux.. but some things like console
 size are just not going to work properly there.  And as long as we fix
>>>
>>> Yeah, those probably would need to get special cased.
>>>
 the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
 simply not set efiout var and have things working as before, so you
 don't loose any existing functionality (although, like I said, if the
 two different consoles have different sizes things aren't going to
 work properly for anything other than simple cases).

 In most cases, the display driver should be able to detect whether a
 display is connected.. this is what I've done on dragonboard410c, so
 if no display plugged in, 'efiout=vidconsole' fails and you fall back
 to serial, else you get efi on screen like you would on a "real"
 computer.  For boards that have a display driver that isn't able to do
 the basic check of whether a cable is plugged in, just don't set
 "efiout" (or fix the display driver) ;-)
>>>
>>> Are you sure that's what happens on a "real" computer? As far as I
>>> remember from all ARM servers running edk2 based firmware that I've
>>> touched so far, the default is always to display on serial *and*
>>> graphical output at the same time.
>>
>> Well, I suppose some of the arm64 server vendors have done a better
>> job than others on firmware.. you'd hope they would probe EDID, and
>> report correct console dimensions based on display resolution, etc.
>
>
> Not sure that's terribly helpful. Most of these servers have built-in BMC
> chips that just go to a fake video console, so they always get EDID
> information, but that doesn't mean that it's sensible for what the user ends
> up seeing.
>
> I think what happens is that in most cases they just assume you have a 80x25
> console :).

oh, right.. BMC's..  well, let's not strive to be as horrible as
enterprise hardware ;-)

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Rob Clark]

On Thu, Oct 12, 2017 at 9:05 AM, Heinrich Schuchardt  wrote:
>
>
> On 10/12/2017 02:48 PM, Rob Clark wrote:
>>
>> On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>>>
>>>
>>>
>>> On 12.10.17 00:07, Rob Clark wrote:

 On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  wrote:
>
>
>
> On 10.10.17 14:23, Rob Clark wrote:
>>
>> In some cases, it is quite useful to have (for example) EFI on screen
>> but u-boot on serial port.
>>
>> This adds two new optional environment variables, "efiin" and
>> "efiout",
>> which can be used to set EFI console input/output independently of
>> u-boot's input/output.  If unset, EFI console will default to stdin/
>> stdout as before.
>>
>> Signed-off-by: Rob Clark 
>
>
> With this patch, we lose the ability to have the efi in/out go to both
> graphical and serial console, right? This is critical functionality to
> have, since we don't necessarily know which output/input a user ends up
> using.


 I'll think about how to support iomux.. but some things like console
 size are just not going to work properly there.  And as long as we fix
>>>
>>>
>>> Yeah, those probably would need to get special cased.
>>>
 the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
 simply not set efiout var and have things working as before, so you
 don't loose any existing functionality (although, like I said, if the
 two different consoles have different sizes things aren't going to
 work properly for anything other than simple cases).

 In most cases, the display driver should be able to detect whether a
 display is connected.. this is what I've done on dragonboard410c, so
 if no display plugged in, 'efiout=vidconsole' fails and you fall back
 to serial, else you get efi on screen like you would on a "real"
 computer.  For boards that have a display driver that isn't able to do
 the basic check of whether a cable is plugged in, just don't set
 "efiout" (or fix the display driver) ;-)
>>>
>>>
>>> Are you sure that's what happens on a "real" computer? As far as I
>>> remember from all ARM servers running edk2 based firmware that I've
>>> touched so far, the default is always to display on serial *and*
>>> graphical output at the same time.
>>
>>
>> Well, I suppose some of the arm64 server vendors have done a better
>> job than others on firmware.. you'd hope they would probe EDID, and
>> report correct console dimensions based on display resolution, etc.
>>
>> Doing both serial and display works for simple stuff, but it goes
>> badly once the efi payload starts trying to change the cursor position
>> and write to specific parts of the screen (which both Shell.efi and
>> grub try to do).
>>
>> BR,
>> -R
>>
> Hello Rob,
>
> I do not know which program you use for connecting to your serial console. I
> use minicom which is a Debian/Ubuntu package. I had no problem using grub,
> vim, nano or any other console program.
>
> Minicom just provides a VT100 emulation and that is close enough to what
> Linux expects.

fwiw, I generally use kermit so my terminal emulator is whatever
"xterm" type app I'm using.  (Currently a big fan of Tilix).. but that
isn't so much the issue..

> So I would not see what should be so special about Shell.efi.

I'm not explaining the problem well, but you can see basically the
same issue if you resize your terminal emulator to something smaller
than what grub/shell/etc think you are using.

I guess if they just fall back to assuming 80x25 like agraf mentioned,
that would kind of work.  It just means shell or grub will only use
the tiny upper-left corner of your monitor.

> My U-Boot system all have video but I never have a monitor connected.
>
> So being able to use serial even if video is available is a necessity.

If the video driver doesn't detect that it is unconnected, someone
should really fix that, otherwise you'll have problems booting an
image where grub tries to use gfxterm if GOP is present (but we are
really getting off topic here)

Either way, you still have the option of not setting efiout (or
setting it to serial)

But for end users (at least of boards that I care about), if they plug
in a monitor they should get grub on screen.  Not everyone has a
serial cable attached.

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Alexander Graf]

On 10/12/2017 02:48 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:


On 12.10.17 00:07, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  wrote:


On 10.10.17 14:23, Rob Clark wrote:

In some cases, it is quite useful to have (for example) EFI on screen
but u-boot on serial port.

This adds two new optional environment variables, "efiin" and "efiout",
which can be used to set EFI console input/output independently of
u-boot's input/output.  If unset, EFI console will default to stdin/
stdout as before.

Signed-off-by: Rob Clark 

With this patch, we lose the ability to have the efi in/out go to both
graphical and serial console, right? This is critical functionality to
have, since we don't necessarily know which output/input a user ends up
using.

I'll think about how to support iomux.. but some things like console
size are just not going to work properly there.  And as long as we fix

Yeah, those probably would need to get special cased.


the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
simply not set efiout var and have things working as before, so you
don't loose any existing functionality (although, like I said, if the
two different consoles have different sizes things aren't going to
work properly for anything other than simple cases).

In most cases, the display driver should be able to detect whether a
display is connected.. this is what I've done on dragonboard410c, so
if no display plugged in, 'efiout=vidconsole' fails and you fall back
to serial, else you get efi on screen like you would on a "real"
computer.  For boards that have a display driver that isn't able to do
the basic check of whether a cable is plugged in, just don't set
"efiout" (or fix the display driver) ;-)

Are you sure that's what happens on a "real" computer? As far as I
remember from all ARM servers running edk2 based firmware that I've
touched so far, the default is always to display on serial *and*
graphical output at the same time.

Well, I suppose some of the arm64 server vendors have done a better
job than others on firmware.. you'd hope they would probe EDID, and
report correct console dimensions based on display resolution, etc.


Not sure that's terribly helpful. Most of these servers have built-in 
BMC chips that just go to a fake video console, so they always get EDID 
information, but that doesn't mean that it's sensible for what the user 
ends up seeing.


I think what happens is that in most cases they just assume you have a 
80x25 console :).



Doing both serial and display works for simple stuff, but it goes
badly once the efi payload starts trying to change the cursor position
and write to specific parts of the screen (which both Shell.efi and
grub try to do).


Yes, and on basically all arm servers what you see happening is that 
grub gets squeezed into 80x25 for the text output. For graphical output, 
at least SUSE usually just defaults to gfxterm which directly drives GOP.



Alex

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Heinrich Schuchardt]

On 10/12/2017 02:48 PM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:



On 12.10.17 00:07, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  wrote:



On 10.10.17 14:23, Rob Clark wrote:

In some cases, it is quite useful to have (for example) EFI on screen
but u-boot on serial port.

This adds two new optional environment variables, "efiin" and "efiout",
which can be used to set EFI console input/output independently of
u-boot's input/output.  If unset, EFI console will default to stdin/
stdout as before.

Signed-off-by: Rob Clark 


With this patch, we lose the ability to have the efi in/out go to both
graphical and serial console, right? This is critical functionality to
have, since we don't necessarily know which output/input a user ends up
using.


I'll think about how to support iomux.. but some things like console
size are just not going to work properly there.  And as long as we fix


Yeah, those probably would need to get special cased.


the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
simply not set efiout var and have things working as before, so you
don't loose any existing functionality (although, like I said, if the
two different consoles have different sizes things aren't going to
work properly for anything other than simple cases).

In most cases, the display driver should be able to detect whether a
display is connected.. this is what I've done on dragonboard410c, so
if no display plugged in, 'efiout=vidconsole' fails and you fall back
to serial, else you get efi on screen like you would on a "real"
computer.  For boards that have a display driver that isn't able to do
the basic check of whether a cable is plugged in, just don't set
"efiout" (or fix the display driver) ;-)


Are you sure that's what happens on a "real" computer? As far as I
remember from all ARM servers running edk2 based firmware that I've
touched so far, the default is always to display on serial *and*
graphical output at the same time.


Well, I suppose some of the arm64 server vendors have done a better
job than others on firmware.. you'd hope they would probe EDID, and
report correct console dimensions based on display resolution, etc.

Doing both serial and display works for simple stuff, but it goes
badly once the efi payload starts trying to change the cursor position
and write to specific parts of the screen (which both Shell.efi and
grub try to do).

BR,
-R


Hello Rob,

I do not know which program you use for connecting to your serial 
console. I use minicom which is a Debian/Ubuntu package. I had no 
problem using grub, vim, nano or any other console program.


Minicom just provides a VT100 emulation and that is close enough to what 
Linux expects.


So I would not see what should be so special about Shell.efi.

My U-Boot system all have video but I never have a monitor connected.

So being able to use serial even if video is available is a necessity.

Best regards

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

Re: [U-Boot] [PATCH] power: extend prefix match to regulator-name property

[Chen-Yu Tsai]

On Thu, Oct 12, 2017 at 8:24 PM, Felix Brack  wrote:
> On 12.10.2017 04:46, Chen-Yu Tsai wrote:
>> On Mon, Oct 9, 2017 at 6:04 PM, Felix Brack  wrote:
>>> This patch extends pmic_bind_children prefix matching. In addition to
>>> the node name the property regulator-name is used while trying to match
>>> prefixes. This allows assigning different drivers to regulator nodes
>>> named regulator@1 and regulator@10 for example.
>>
>> No. See the regulator bindings:
>>
>> Optional properties:
>> - regulator-name: A string used as a descriptive name for regulator outputs
>>
> The actual regulator.txt states:
>
> Optional properties:
>  - regulator-name: a string, required by the regulator uclass
>
> This was the reason for choosing the regulator-name property.

Mine was from the Linux Kernel. Are there two sets of bindings?
Shouldn't there be just one?

>> This can vary from board to board. The name should match the power rail
>> name of the board (which may not be the same as the regulator chip's
>> output name).
>>
> Exactly. I totally agree but as stated in an earlier post: I did not
> define the names for the regulators and modifying them is almost
> certainly not the right way to go. Let me explain this briefly. The
> regulator names I'm trying to match are those from tps65910.dtsi, an
> include file. The exact same file is part of the LINUX kernel. Therefore
> I resigned suggesting the modification of the node names.

First, it is an include file. Board files are free to override the
name. We did that for sunxi at first, have the .dtsi file provide
some default names, then have board .dts files override them with
names that make more sense. Later on we just dropped the default
names altogether.

The same pattern is also seen in tps65910.dtsi and am3517-craneboard.dts.
And also am335x-evm.dts, which the tps65910.dtsi was tested with.

Now I couldn't find the binding document for tps65910, but looking
at tps65217 instead, it says:

- regulators: list of regulators provided by this controller, must be named
  after their hardware counterparts: dcdc[1-3] and ldo[1-4]

And indeed that is what's used in the example.

So clearly the dts files aren't following the binding.

>
>> If you have multiple regulator nodes which need to be differentiated,
>> you need to use the deprecated "regulator-compatible" property, or just
>> use the standard compatible property.
>>
> Good point. I would not use a deprecated property but the compatible
> property seems reasonable to me. So you agree that the patch's concept
> could be retained while substituting the node-name property by the
> compatible property?

If you're going to modify the binding and/or device tree files, please
do it in both places. Ideally the platform should have one canonical
source for them.

Linux's standard regulator DT matching code only matches against node
names and the deprecated "regulator-compatible" property. Not even the
standard "compatible" is used, though I see a few PMICs using that.
So even if you do get them working this way in U-boot, it's still not
going to work in Linux, and you might get other comments when pushing
your changes.

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

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Rob Clark]

On Thu, Oct 12, 2017 at 3:15 AM, Alexander Graf  wrote:
>
>
> On 12.10.17 00:07, Rob Clark wrote:
>> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  wrote:
>>>
>>>
>>> On 10.10.17 14:23, Rob Clark wrote:
 In some cases, it is quite useful to have (for example) EFI on screen
 but u-boot on serial port.

 This adds two new optional environment variables, "efiin" and "efiout",
 which can be used to set EFI console input/output independently of
 u-boot's input/output.  If unset, EFI console will default to stdin/
 stdout as before.

 Signed-off-by: Rob Clark 
>>>
>>> With this patch, we lose the ability to have the efi in/out go to both
>>> graphical and serial console, right? This is critical functionality to
>>> have, since we don't necessarily know which output/input a user ends up
>>> using.
>>
>> I'll think about how to support iomux.. but some things like console
>> size are just not going to work properly there.  And as long as we fix
>
> Yeah, those probably would need to get special cased.
>
>> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
>> simply not set efiout var and have things working as before, so you
>> don't loose any existing functionality (although, like I said, if the
>> two different consoles have different sizes things aren't going to
>> work properly for anything other than simple cases).
>>
>> In most cases, the display driver should be able to detect whether a
>> display is connected.. this is what I've done on dragonboard410c, so
>> if no display plugged in, 'efiout=vidconsole' fails and you fall back
>> to serial, else you get efi on screen like you would on a "real"
>> computer.  For boards that have a display driver that isn't able to do
>> the basic check of whether a cable is plugged in, just don't set
>> "efiout" (or fix the display driver) ;-)
>
> Are you sure that's what happens on a "real" computer? As far as I
> remember from all ARM servers running edk2 based firmware that I've
> touched so far, the default is always to display on serial *and*
> graphical output at the same time.

Well, I suppose some of the arm64 server vendors have done a better
job than others on firmware.. you'd hope they would probe EDID, and
report correct console dimensions based on display resolution, etc.

Doing both serial and display works for simple stuff, but it goes
badly once the efi payload starts trying to change the cursor position
and write to specific parts of the screen (which both Shell.efi and
grub try to do).

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

Re: [U-Boot] [PATCH] power: extend prefix match to regulator-name property

[Felix Brack]

On 12.10.2017 04:46, Chen-Yu Tsai wrote:
> On Mon, Oct 9, 2017 at 6:04 PM, Felix Brack  wrote:
>> This patch extends pmic_bind_children prefix matching. In addition to
>> the node name the property regulator-name is used while trying to match
>> prefixes. This allows assigning different drivers to regulator nodes
>> named regulator@1 and regulator@10 for example.
> 
> No. See the regulator bindings:
> 
> Optional properties:
> - regulator-name: A string used as a descriptive name for regulator outputs
> 
The actual regulator.txt states:

Optional properties:
 - regulator-name: a string, required by the regulator uclass

This was the reason for choosing the regulator-name property.

> This can vary from board to board. The name should match the power rail
> name of the board (which may not be the same as the regulator chip's
> output name).
> 
Exactly. I totally agree but as stated in an earlier post: I did not
define the names for the regulators and modifying them is almost
certainly not the right way to go. Let me explain this briefly. The
regulator names I'm trying to match are those from tps65910.dtsi, an
include file. The exact same file is part of the LINUX kernel. Therefore
I resigned suggesting the modification of the node names.

> If you have multiple regulator nodes which need to be differentiated,
> you need to use the deprecated "regulator-compatible" property, or just
> use the standard compatible property.
> 
Good point. I would not use a deprecated property but the compatible
property seems reasonable to me. So you agree that the patch's concept
could be retained while substituting the node-name property by the
compatible property?

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

[U-Boot] u-boot environment utilities and mmc device(calculate fw_env.config parameters)

[MOHAMMAD RASIM]

Hi,
How can i calculate the numbers to plug in the configuration file of 
uboot tools(fw_env.config)?
My device doesn't have mtd devices instead it uses mmc block device, 
here are some info about the device


*$*lsblk -o FSTYPE,NAME,SIZE,PHY-SEC,LOG-SEC,ALIGNMENT,TYPE
NAME  SIZE PHY-SEC LOG-SEC ALIGNMENT TYPE
mmcblk0boot0    4M 512 512 0 disk
mmcblk0boot1    4M 512 512 0 disk
mmcblk0           14.6G 512 512    0 disk

u-boot reports the following partition table:

#
Partition table get from SPL is :
    name    offset size  flag
===
   0: bootloader 0 40  0
   1: reserved 240 400  0
   2: cache    6c0 2000  2
   3: env 2740 80  0
   4: logo    2840 200  1
   5: recovery    2ac0 200  1
   6: rsv 2d40 80  1
   7: tee 2e40 80  1
   8: crypt   2f40 200  1
   9: misc    31c0 200  1
  10: instaboot   3440 2000  1
  11: boot    54c0 200  1
  12: system  5740 4000  1
  13: data    97c0 30c20  4
mmc read lba=0x12000, blocks=0x2
mmc read lba=0x12002, blocks=0x2
mmc_read_partition_tbl: mmc read partition OK!
eMMC/TSD partition table have been checked OK!
mmc env offset: 0x2740
##

So the env offset is 2740 and size is 80 but when i try to plug 
them in fw_env.config using /dev/mmcblk0 as a device I still get bad CRC 
error

using hexdump i can get the environment at position 677392

###
$hexdump -C -s 677392 -n 4384 /dev/mmcblk0
000a5610  62 6f 6f 74 63 6d 64 3d  72 75 6e 20 73 74 6f 72 |bootcmd=run 
stor|
000a5620  65 62 6f 6f 74 00 62 6f  6f 74 64 65 6c 61 79 3d 
|eboot.bootdelay=|
000a5630  31 00 62 61 75 64 72 61  74 65 3d 31 31 35 32 30 
|1.baudrate=11520|
000a5640  30 00 65 74 68 61 64 64  72 3d 30 30 3a 31 35 3a 
|0.ethaddr=00:15:|
000a5650  31 38 3a 30 31 3a 38 31  3a 33 31 00 69 70 61 64 
|18:01:81:31.ipad|
000a5660  64 72 3d 31 30 2e 31 38  2e 39 2e 39 37 00 73 65 
|dr=10.18.9.97.se|
000a5670  72 76 65 72 69 70 3d 31  30 2e 31 38 2e 39 2e 31 
|rverip=10.18.9.1|
000a5680  31 33 00 70 72 65 62 6f  6f 74 3d 72 75 6e 20 66 
|13.preboot=run f|
000a5690  61 63 74 6f 72 79 5f 72  65 73 65 74 5f 70 6f 77 
|actory_reset_pow|
000a56a0  65 72 6f 66 66 5f 70 72  6f 74 65 63 74 3b 72 75 
|eroff_protect;ru|
000a56b0  6e 20 75 70 67 72 61 64  65 5f 63 68 65 63 6b 3b  |n 
upgrade_check;|
000a56c0  72 75 6e 20 62 6f 6f 74  6d 6f 64 65 5f 63 68 65  |run 
bootmode_che|
000a56d0  63 6b 3b 72 75 6e 20 69  6e 69 74 5f 64 69 73 70  |ck;run 
init_disp|
000a56e0  6c 61 79 3b 72 75 6e 20  73 74 6f 72 65 61 72 67  |lay;run 
storearg|
000a56f0  73 3b 72 75 6e 20 75 70  64 61 74 65 5f 6b 65 79  |s;run 
update_key|
000a5700  3b 72 75 6e 20 69 72 72  65 6d 6f 74 65 5f 75 70  |;run 
irremote_up|
000a5710  64 61 74 65 3b 72 75 6e  20 73 77 69 74 63 68 5f |date;run 
switch_|
000a5720  62 6f 6f 74 6d 6f 64 65  3b 00 67 61 74 65 77 61 
|bootmode;.gatewa|
000a5730  79 69 70 3d 31 30 2e 31  38 2e 39 2e 31 00 6e 65 
|yip=10.18.9.1.ne|
000a5740  74 6d 61 73 6b 3d 32 35  35 2e 32 35 35 2e 32 35 
|tmask=255.255.25|
000a5750  35 2e 30 00 68 6f 73 74  6e 61 6d 65 3d 61 72 6d 
|5.0.hostname=arm|
000a5760  5f 67 78 62 62 00 66 69  72 73 74 62 6f 6f 74 3d 
|_gxbb.firstboot=|
000a5770  31 00 75 70 67 72 61 64  65 5f 73 74 65 70 3d 30 
|1.upgrade_step=0|
000a5780  00 6c 6f 61 64 61 64 64  72 3d 31 30 38 30 30 30 
|.loadaddr=108000|
000a5790  30 00 6f 75 74 70 75 74  6d 6f 64 65 3d 31 30 38 
|0.outputmode=108|
000a57a0  30 70 36 30 68 7a 00 68  64 6d 69 6d 6f 64 65 3d 
|0p60hz.hdmimode=|
000a57b0  31 30 38 30 70 36 30 68  7a 00 63 76 62 73 6d 6f 
|1080p60hz.cvbsmo|
000a57c0  64 65 3d 35 37 36 63 76  62 73 00 64 69 73 70 6c 
|de=576cvbs.displ|
000a57d0  61 79 5f 77 69 64 74 68  3d 31 39 32 30 00 64 69 
|ay_width=1920.di|
000a57e0  73 70 6c 61 79 5f 68 65  69 67 68 74 3d 31 30 38 
|splay_height=108|
000a57f0  30 00 64 69 73 70 6c 61  79 5f 62 70 70 3d 31 36 
|0.display_bpp=16|
000a5800  00 64 69 73 70 6c 61 79  5f 63 6f 6c 6f 72 5f 69 
|.display_color_i|
000a5810  6e 64 65 78 3d 31 36 00  64 69 73 70 6c 61 79 5f 
|ndex=16.display_|
000a5820  6c 61 79 65 72 3d 6f 73  64 31 00 64 69 73 70 6c 
|layer=osd1.displ|
000a5830  61 79 5f 63 6f 6c 6f 72  5f 66 67 3d 30 78 66 66 
|ay_color_fg=0xff|
000a5840  66 66 00 64 69 73 70 6c  61 79 5f 63 6f 6c 6f 72 

Re: [U-Boot] [PATCH v5 00/18] rockchip: back-to-bootrom: replace assembly-implementation with C-code

[Heiko Stuebner]

Am Dienstag, 10. Oktober 2017, 16:21:00 CEST schrieb Philipp Tomsich:
> 
> Recent discussions confirmed (what the code always assumed): the
> Rockchip BROM always enters U-Boot with the stack-pointer valid
> (i.e. the U-Boot startup code is running off the BROM stack).
> 
> We can thus replace the back-to-bootrom code (i.e. both the
> save_boot_params and back_to_bootrom implementations) using C-code
> based on setjmp/longjmp.  The new implementation is already structured
> to allow an easy drop-in of Andy's changes to enter download-mode when
> returning to the BROM.
> 
> This turned out to require a some tweaking to system.h (making sure
> that the prototype for save_boot_params_ret is visible for A64)and
> start.S (so binutils knows that this is a possible function entry and
> it can correctly insert A32-to-Thumb transitions) and taking the axe
> to setjmp.h (which created quite a few issues with it not expecting
> A32/T32/Thumb call-sites and some fragility from GCC being smart about
> the clobber-list of the inline assembly... which led to r9 not being
> saved or restored).
> 
> For v4+: To fix issues with the RK3188 support, this also updates the
> boot0 hook changes (i.e. allowing the boot0-hook to insert code/data
> before the ARM vector table) that Kever had submitted this spring and
> implements a similar "early back-to-bootrom" as suggested by Pawel
> (for the RK3066) as a generic mechanism.

This series on rk3188-radxarock
Tested-by: Heiko Stuebner 

It can enter SPL and from there also enter into proper uboot.

At first I was about to complain that it broke mid-series until I
realized that I'll of course need to adapt my image build script
to not try to use a TPL binary :-D


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

[U-Boot] [PATCH 2/2] x86: Turn off running VGA ROM during S3 resume

[Bin Meng]

This is only needed when graphics console is used. For kernel with
native graphics driver, this can be turned off to speed up.

Change this option's default to n in the Kconfig.

Signed-off-by: Bin Meng 
---

 arch/x86/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 38a6187..c869ae2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -677,7 +677,6 @@ config HAVE_ACPI_RESUME
 config S3_VGA_ROM_RUN
bool "Re-run VGA option ROMs on S3 resume"
depends on HAVE_ACPI_RESUME
-   default y if HAVE_ACPI_RESUME
help
  Execute VGA option ROMs in U-Boot when resuming from S3. Normally
  this is needed when graphics console is being used in the kernel.
-- 
2.7.4

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

[U-Boot] [PATCH 1/2] x86: baytrail: Fix unstable ACPI S3 resume

[Bin Meng]

It was observed that when booting a Ubuntu 16.04 kernel, doing ACPI
S3 suspend/resume sometimes causes the Ubuntu kernel hang forever.
The issue is however not reproduced with a kernel built from i386/
x86_64 defconfig configuration.

The unstability is actually caused by unexpected interrupts being
generated during the S3 resume. For some unknown reason, FSP (gold4)
for BayTrail configures the GPIO DFX5 PAD to enable level interrupt
(bit 24 and 25). As this pin keeps generating interrupts during an
S3 resume, and there is no IRQ requester in the kernel to handle it,
the kernel seems to hang and does not continue resuming.

Clear the mysterious interrupt bits for this pin.

Reported-by: Stefan Roese 
Signed-off-by: Bin Meng 
---

 arch/x86/cpu/baytrail/valleyview.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/cpu/baytrail/valleyview.c 
b/arch/x86/cpu/baytrail/valleyview.c
index c58f6a8..9af1bda 100644
--- a/arch/x86/cpu/baytrail/valleyview.c
+++ b/arch/x86/cpu/baytrail/valleyview.c
@@ -10,6 +10,13 @@
 #include 
 #include 
 #include 
+#include 
+
+/* GPIO SUS */
+#define GPIO_SUS_PAD_BASE  (IO_BASE_ADDRESS + IO_BASE_OFFSET_GPSSUS)
+#define GPIO_SUS_DFX5_CONF00x150
+#define BYT_TRIG_LVL   BIT(24)
+#define BYT_TRIG_POS   BIT(25)
 
 #ifndef CONFIG_EFI_APP
 int arch_cpu_init(void)
@@ -33,6 +40,21 @@ int arch_misc_init(void)
mrccache_save();
 #endif
 
+   /*
+* For some unknown reason, FSP (gold4) for BayTrail configures
+* the GPIO DFX5 PAD to enable level interrupt (bit 24 and 25).
+* This does not cause any issue when Linux kernel runs w/ or w/o
+* the pinctrl driver for BayTrail. However this causes unstable
+* S3 resume if the pinctrl driver is included in the kernel build.
+* As this pin keeps generating interrupts during an S3 resume,
+* and there is no IRQ requester in the kernel to handle it, the
+* kernel seems to hang and does not continue resuming.
+*
+* Clear the mysterious interrupt bits for this pin.
+*/
+   clrbits_le32(GPIO_SUS_PAD_BASE + GPIO_SUS_DFX5_CONF0,
+BYT_TRIG_LVL | BYT_TRIG_POS);
+
return 0;
 }
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH 03/11] efi_loader: Initial EFI_UNICODE_COLLATION_PROTOCOL

[Alexander Graf]

On 10/11/2017 10:47 PM, Alexander Graf wrote:


On 11.10.17 22:30, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:36 AM, Alexander Graf  wrote:


On 10.10.17 14:22, Rob Clark wrote:

From: Leif Lindholm 

Not complete, but enough for Shell.efi and SCT.efi.

Initial skeleton written by Leif, and then implementation by myself.

Cc: Leif Lindholm 
Signed-off-by: Rob Clark 
---
  include/efi_api.h |  41 ++
  include/efi_loader.h  |   3 +
  lib/efi_loader/Makefile   |   2 +-
  lib/efi_loader/efi_boottime.c |   6 ++
  lib/efi_loader/efi_unicode.c  | 170 ++
  5 files changed, 221 insertions(+), 1 deletion(-)
  create mode 100644 lib/efi_loader/efi_unicode.c

diff --git a/include/efi_api.h b/include/efi_api.h
index 164147dc87..38dd1240c1 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -797,6 +797,47 @@ struct efi_hii_string_protocol {
   efi_uintn_t *secondary_languages_size);
  };

+/*
+ * Both UNICODE_COLLATION protocols seem to be the same thing, but
+ * advertised with two different GUID's because, why not?
+ */
+
+#define EFI_UNICODE_COLLATION_PROTOCOL_GUID \
+ EFI_GUID(0x1d85cd7f, 0xf43d, 0x11d2, \
+  0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
+#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
+ EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
+  0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
+
+struct efi_unicode_collation_protocol {
+ efi_intn_t (EFIAPI *stri_coll)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t s1,
+ efi_string_t s2);
+ bool (EFIAPI *metai_match)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t string,
+ efi_string_t pattern);
+ void (EFIAPI *str_lwr)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t string);
+ void (EFIAPI *str_upr)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t string);
+ void (EFIAPI *fat_to_str)(
+ struct efi_unicode_collation_protocol *this,
+ efi_uintn_t fat_size,
+ uint8_t *fat,
+ efi_string_t string);
+ bool (EFIAPI *str_to_fat)(
+ struct efi_unicode_collation_protocol *this,
+ efi_string_t string,
+ efi_uintn_t fat_size,
+ uint8_t *fat);
+ uint8_t *supported_languages;
+};
+
  #define EFI_GOP_GUID \
   EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 591bf07e7a..af6812b2b4 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -83,6 +83,7 @@ extern const struct efi_device_path_utilities_protocol 
efi_device_path_utilities
  extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
  extern const struct efi_hii_database_protocol efi_hii_database;
  extern const struct efi_hii_string_protocol efi_hii_string;
+extern const struct efi_unicode_collation_protocol efi_unicode_collation;

  uint16_t *efi_dp_str(struct efi_device_path *dp);

@@ -97,6 +98,8 @@ extern const efi_guid_t 
efi_guid_device_path_utilities_protocol;
  extern const efi_guid_t efi_guid_hii_config_routing_protocol;
  extern const efi_guid_t efi_guid_hii_database_protocol;
  extern const efi_guid_t efi_guid_hii_string_protocol;
+extern const efi_guid_t efi_guid_unicode_collation_protocol;
+extern const efi_guid_t efi_guid_unicode_collation_protocol2;

  extern unsigned int __efi_runtime_start, __efi_runtime_stop;
  extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 725e0cba85..7ea96a4f1c 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -17,7 +17,7 @@ endif
  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
-obj-y += efi_device_path_utilities.o efi_hii.o
+obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
  obj-y += efi_file.o efi_variable.o efi_bootmgr.o
  obj-$(CONFIG_LCD) += efi_gop.o
  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index c179afc25a..b568f3f162 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1166,6 +1166,12 @@ void efi_setup_loaded_image(struct efi_loaded_image 
*info, struct efi_object *ob
   obj->protocols[7].guid = _guid_hii_config_routing_protocol;
   obj->protocols[7].protocol_interface = (void *)_hii_config_routing;

+ obj->protocols[8].guid = _guid_unicode_collation_protocol;
+ obj->protocols[8].protocol_interface = (void *)_unicode_collation;
+
+ 

Re: [U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols

[Alexander Graf]

On 10/12/2017 11:55 AM, Rob Clark wrote:

On Thu, Oct 12, 2017 at 3:13 AM, Alexander Graf  wrote:


On 12.10.17 00:02, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf  wrote:


On 10.10.17 14:22, Rob Clark wrote:

From: Leif Lindholm 

Enough implementation of the following protocols to run Shell.efi and
SCT.efi:

   EfiHiiConfigRoutingProtocolGuid
   EfiHiiDatabaseProtocol
   EfiHiiStringProtocol

We'll fill in the rest once SCT is running properly so we can validate
the implementation against the conformance test suite.

Initial skeleton written by Leif, and then implementation by myself.

Cc: Leif Lindholm 
Signed-off-by: Rob Clark 
---
  include/efi_api.h | 261 ++
  include/efi_loader.h  |   6 +
  lib/efi_loader/Makefile   |   2 +-
  lib/efi_loader/efi_boottime.c |   9 +
  lib/efi_loader/efi_hii.c  | 507 ++
  5 files changed, 784 insertions(+), 1 deletion(-)
  create mode 100644 lib/efi_loader/efi_hii.c

diff --git a/include/efi_api.h b/include/efi_api.h
index ffdba7fe1a..164147dc87 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -16,6 +16,7 @@
  #define _EFI_API_H

  #include 
+#include 

  #ifdef CONFIG_EFI_LOADER
  #include 
@@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
   uint16_t node_length);
  };

+#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
+ EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
+  0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
+
+typedef uint16_t efi_string_id_t;
+
+struct efi_hii_config_routing_protocol {
+ efi_status_t(EFIAPI *extract_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t request,
+ efi_string_t *progress,
+ efi_string_t *results);
+ efi_status_t(EFIAPI *export_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ efi_string_t *results);
+ efi_status_t(EFIAPI *route_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t configuration,
+ efi_string_t *progress);
+ efi_status_t(EFIAPI *block_to_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t config_request,
+ const uint8_t *block,
+ const efi_uintn_t block_size,
+ efi_string_t *config,
+ efi_string_t *progress);
+ efi_status_t(EFIAPI *config_to_block)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t config_resp,
+ const uint8_t *block,
+ const efi_uintn_t *block_size,
+ efi_string_t *progress);
+ efi_status_t(EFIAPI *get_alt_config)(
+ const struct efi_hii_config_routing_protocol *this,
+ const efi_string_t config_resp,
+ const efi_guid_t *guid,
+ const efi_string_t name,
+ const struct efi_device_path *device_path,
+ const efi_string_t alt_cfg_id,
+ efi_string_t *alt_cfg_resp);
+};
+
+#define EFI_HII_DATABASE_PROTOCOL_GUID\
+ EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
+  0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
+
+typedef enum {
+ EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
+ EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
+ EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
+ EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
+ EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, EFI_KEY_B6,
+ EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
+ EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
+ EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
+ EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
+ EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
+ EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
+ EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, EFI_KEY_D8,
+ EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
+ EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
+ EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
+ EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, EFI_KEY_E9,
+ EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
+ EFI_KEY_INS, EFI_KEY_HOME, EFI_KEY_PG_UP, EFI_KEY_NLCK, EFI_KEY_SLASH,
+ EFI_KEY_ASTERISK, EFI_KEY_MINUS, EFI_KEY_ESC, EFI_KEY_F1, EFI_KEY_F2,
+ EFI_KEY_F3, EFI_KEY_F4, EFI_KEY_F5, EFI_KEY_F6, EFI_KEY_F7, EFI_KEY_F8,
+ EFI_KEY_F9, EFI_KEY_F10, EFI_KEY_F11, EFI_KEY_F12, EFI_KEY_PRINT,
+ EFI_KEY_SLCK, EFI_KEY_PAUSE,
+} efi_key;
+

Re: [U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols

[Rob Clark]

On Thu, Oct 12, 2017 at 3:13 AM, Alexander Graf  wrote:
>
>
> On 12.10.17 00:02, Rob Clark wrote:
>> On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf  wrote:
>>>
>>>
>>> On 10.10.17 14:22, Rob Clark wrote:
 From: Leif Lindholm 

 Enough implementation of the following protocols to run Shell.efi and
 SCT.efi:

   EfiHiiConfigRoutingProtocolGuid
   EfiHiiDatabaseProtocol
   EfiHiiStringProtocol

 We'll fill in the rest once SCT is running properly so we can validate
 the implementation against the conformance test suite.

 Initial skeleton written by Leif, and then implementation by myself.

 Cc: Leif Lindholm 
 Signed-off-by: Rob Clark 
 ---
  include/efi_api.h | 261 ++
  include/efi_loader.h  |   6 +
  lib/efi_loader/Makefile   |   2 +-
  lib/efi_loader/efi_boottime.c |   9 +
  lib/efi_loader/efi_hii.c  | 507 
 ++
  5 files changed, 784 insertions(+), 1 deletion(-)
  create mode 100644 lib/efi_loader/efi_hii.c

 diff --git a/include/efi_api.h b/include/efi_api.h
 index ffdba7fe1a..164147dc87 100644
 --- a/include/efi_api.h
 +++ b/include/efi_api.h
 @@ -16,6 +16,7 @@
  #define _EFI_API_H

  #include 
 +#include 

  #ifdef CONFIG_EFI_LOADER
  #include 
 @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
   uint16_t node_length);
  };

 +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
 + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
 +  0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
 +
 +typedef uint16_t efi_string_id_t;
 +
 +struct efi_hii_config_routing_protocol {
 + efi_status_t(EFIAPI *extract_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t request,
 + efi_string_t *progress,
 + efi_string_t *results);
 + efi_status_t(EFIAPI *export_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + efi_string_t *results);
 + efi_status_t(EFIAPI *route_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t configuration,
 + efi_string_t *progress);
 + efi_status_t(EFIAPI *block_to_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t config_request,
 + const uint8_t *block,
 + const efi_uintn_t block_size,
 + efi_string_t *config,
 + efi_string_t *progress);
 + efi_status_t(EFIAPI *config_to_block)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t config_resp,
 + const uint8_t *block,
 + const efi_uintn_t *block_size,
 + efi_string_t *progress);
 + efi_status_t(EFIAPI *get_alt_config)(
 + const struct efi_hii_config_routing_protocol *this,
 + const efi_string_t config_resp,
 + const efi_guid_t *guid,
 + const efi_string_t name,
 + const struct efi_device_path *device_path,
 + const efi_string_t alt_cfg_id,
 + efi_string_t *alt_cfg_resp);
 +};
 +
 +#define EFI_HII_DATABASE_PROTOCOL_GUID\
 + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
 +  0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
 +
 +typedef enum {
 + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
 + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, 
 EFI_KEY_LEFT_ARROW,
 + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
 + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
 + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, 
 EFI_KEY_B6,
 + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
 + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
 + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
 + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
 + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
 + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
 + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, 
 EFI_KEY_D8,
 + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
 + EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, 
 EFI_KEY_EIGHT,
 + EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
 

[U-Boot] [PATCH] armv8: ls1088aqds: Change phy mode to PHY_INTERFACE_MODE_RGMII_ID

[Ashish Kumar]

Since TX delay is now enabled only in PHY_INTERFACE_MODE_RGMII_ID
PHY_INTERFACE_MODE_RGMII_TXID.

These change where introduced in phy driver in commit titled
"net: phy: realtek: fix enabling of the TX-delay for RTL8211F"

Signed-off-by: Ashish Kumar 
---
 board/freescale/ls1088a/eth_ls1088aqds.c | 1 +
 drivers/net/ldpaa_eth/ls1088a.c  | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/board/freescale/ls1088a/eth_ls1088aqds.c 
b/board/freescale/ls1088a/eth_ls1088aqds.c
index f5320eb..f056fde 100644
--- a/board/freescale/ls1088a/eth_ls1088aqds.c
+++ b/board/freescale/ls1088a/eth_ls1088aqds.c
@@ -637,6 +637,7 @@ int board_eth_init(bd_t *bis)
for (i = WRIOP1_DPMAC1; i < NUM_WRIOP_PORTS; i++) {
switch (wriop_get_enet_if(i)) {
case PHY_INTERFACE_MODE_RGMII:
+   case PHY_INTERFACE_MODE_RGMII_ID:
ls1088a_handle_phy_interface_rgmii(i);
break;
case PHY_INTERFACE_MODE_QSGMII:
diff --git a/drivers/net/ldpaa_eth/ls1088a.c b/drivers/net/ldpaa_eth/ls1088a.c
index 061935e..780a239 100644
--- a/drivers/net/ldpaa_eth/ls1088a.c
+++ b/drivers/net/ldpaa_eth/ls1088a.c
@@ -99,7 +99,7 @@ void fsl_rgmii_init(void)
ec >>= FSL_CHASSIS3_RCWSR25_EC1_PRTCL_SHIFT;
 
if (!ec)
-   wriop_init_dpmac_enet_if(4, PHY_INTERFACE_MODE_RGMII);
+   wriop_init_dpmac_enet_if(4, PHY_INTERFACE_MODE_RGMII_ID);
 #endif
 
 #ifdef CONFIG_SYS_FSL_EC2
@@ -108,7 +108,7 @@ void fsl_rgmii_init(void)
ec >>= FSL_CHASSIS3_RCWSR25_EC2_PRTCL_SHIFT;
 
if (!ec)
-   wriop_init_dpmac_enet_if(5, PHY_INTERFACE_MODE_RGMII);
+   wriop_init_dpmac_enet_if(5, PHY_INTERFACE_MODE_RGMII_ID);
 #endif
 }
 #endif
-- 
2.7.4

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

[U-Boot] [PATCH] rockchip: rk3399: init CPU clock when rkclk_init()

[Kever Yang]

Init the CPU and its buses to speed up the boot time.
Move rkclk_init() to a place after rk3399_configure_cpu has defined
at the same time, or else there will be a warning.

Signed-off-by: Kever Yang 
---

 drivers/clk/rockchip/clk_rk3399.c | 157 +++---
 1 file changed, 79 insertions(+), 78 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 50faf5d..b9b1ead 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -398,84 +398,6 @@ static int pll_para_config(u32 freq_hz, struct pll_div 
*div)
return 0;
 }
 
-#ifdef CONFIG_SPL_BUILD
-static void rkclk_init(struct rk3399_cru *cru)
-{
-   u32 aclk_div;
-   u32 hclk_div;
-   u32 pclk_div;
-
-   /*
-* some cru registers changed by bootrom, we'd better reset them to
-* reset/default values described in TRM to avoid confusion in kernel.
-* Please consider these three lines as a fix of bootrom bug.
-*/
-   rk_clrsetreg(>clksel_con[12], 0x, 0x4101);
-   rk_clrsetreg(>clksel_con[19], 0x, 0x033f);
-   rk_clrsetreg(>clksel_con[56], 0x0003, 0x0003);
-
-   /* configure gpll cpll */
-   rkclk_set_pll(>gpll_con[0], _init_cfg);
-   rkclk_set_pll(>cpll_con[0], _init_cfg);
-
-   /* configure perihp aclk, hclk, pclk */
-   aclk_div = GPLL_HZ / PERIHP_ACLK_HZ - 1;
-   assert((aclk_div + 1) * PERIHP_ACLK_HZ == GPLL_HZ && aclk_div < 0x1f);
-
-   hclk_div = PERIHP_ACLK_HZ / PERIHP_HCLK_HZ - 1;
-   assert((hclk_div + 1) * PERIHP_HCLK_HZ ==
-  PERIHP_ACLK_HZ && (hclk_div < 0x4));
-
-   pclk_div = PERIHP_ACLK_HZ / PERIHP_PCLK_HZ - 1;
-   assert((pclk_div + 1) * PERIHP_PCLK_HZ ==
-  PERIHP_ACLK_HZ && (pclk_div < 0x7));
-
-   rk_clrsetreg(>clksel_con[14],
-PCLK_PERIHP_DIV_CON_MASK | HCLK_PERIHP_DIV_CON_MASK |
-ACLK_PERIHP_PLL_SEL_MASK | ACLK_PERIHP_DIV_CON_MASK,
-pclk_div << PCLK_PERIHP_DIV_CON_SHIFT |
-hclk_div << HCLK_PERIHP_DIV_CON_SHIFT |
-ACLK_PERIHP_PLL_SEL_GPLL << ACLK_PERIHP_PLL_SEL_SHIFT |
-aclk_div << ACLK_PERIHP_DIV_CON_SHIFT);
-
-   /* configure perilp0 aclk, hclk, pclk */
-   aclk_div = GPLL_HZ / PERILP0_ACLK_HZ - 1;
-   assert((aclk_div + 1) * PERILP0_ACLK_HZ == GPLL_HZ && aclk_div < 0x1f);
-
-   hclk_div = PERILP0_ACLK_HZ / PERILP0_HCLK_HZ - 1;
-   assert((hclk_div + 1) * PERILP0_HCLK_HZ ==
-  PERILP0_ACLK_HZ && (hclk_div < 0x4));
-
-   pclk_div = PERILP0_ACLK_HZ / PERILP0_PCLK_HZ - 1;
-   assert((pclk_div + 1) * PERILP0_PCLK_HZ ==
-  PERILP0_ACLK_HZ && (pclk_div < 0x7));
-
-   rk_clrsetreg(>clksel_con[23],
-PCLK_PERILP0_DIV_CON_MASK | HCLK_PERILP0_DIV_CON_MASK |
-ACLK_PERILP0_PLL_SEL_MASK | ACLK_PERILP0_DIV_CON_MASK,
-pclk_div << PCLK_PERILP0_DIV_CON_SHIFT |
-hclk_div << HCLK_PERILP0_DIV_CON_SHIFT |
-ACLK_PERILP0_PLL_SEL_GPLL << ACLK_PERILP0_PLL_SEL_SHIFT |
-aclk_div << ACLK_PERILP0_DIV_CON_SHIFT);
-
-   /* perilp1 hclk select gpll as source */
-   hclk_div = GPLL_HZ / PERILP1_HCLK_HZ - 1;
-   assert((hclk_div + 1) * PERILP1_HCLK_HZ ==
-  GPLL_HZ && (hclk_div < 0x1f));
-
-   pclk_div = PERILP1_HCLK_HZ / PERILP1_HCLK_HZ - 1;
-   assert((pclk_div + 1) * PERILP1_HCLK_HZ ==
-  PERILP1_HCLK_HZ && (hclk_div < 0x7));
-
-   rk_clrsetreg(>clksel_con[25],
-PCLK_PERILP1_DIV_CON_MASK | HCLK_PERILP1_DIV_CON_MASK |
-HCLK_PERILP1_PLL_SEL_MASK,
-pclk_div << PCLK_PERILP1_DIV_CON_SHIFT |
-hclk_div << HCLK_PERILP1_DIV_CON_SHIFT |
-HCLK_PERILP1_PLL_SEL_GPLL << HCLK_PERILP1_PLL_SEL_SHIFT);
-}
-#endif
-
 void rk3399_configure_cpu(struct rk3399_cru *cru,
  enum apll_l_frequencies apll_l_freq)
 {
@@ -1004,6 +926,85 @@ static struct clk_ops rk3399_clk_ops = {
.enable = rk3399_clk_enable,
 };
 
+#ifdef CONFIG_SPL_BUILD
+static void rkclk_init(struct rk3399_cru *cru)
+{
+   u32 aclk_div;
+   u32 hclk_div;
+   u32 pclk_div;
+
+   rk3399_configure_cpu(cru, APLL_L_600_MHZ);
+   /*
+* some cru registers changed by bootrom, we'd better reset them to
+* reset/default values described in TRM to avoid confusion in kernel.
+* Please consider these three lines as a fix of bootrom bug.
+*/
+   rk_clrsetreg(>clksel_con[12], 0x, 0x4101);
+   rk_clrsetreg(>clksel_con[19], 0x, 0x033f);
+   rk_clrsetreg(>clksel_con[56], 0x0003, 0x0003);
+
+   /* configure gpll cpll */
+   rkclk_set_pll(>gpll_con[0], _init_cfg);
+   rkclk_set_pll(>cpll_con[0], _init_cfg);
+
+   /* configure 

Re: [U-Boot] [PATCH 06/11] efi_loader: Decouple EFI input/output from stdin/stdout

[Alexander Graf]

On 12.10.17 00:07, Rob Clark wrote:
> On Wed, Oct 11, 2017 at 10:45 AM, Alexander Graf  wrote:
>>
>>
>> On 10.10.17 14:23, Rob Clark wrote:
>>> In some cases, it is quite useful to have (for example) EFI on screen
>>> but u-boot on serial port.
>>>
>>> This adds two new optional environment variables, "efiin" and "efiout",
>>> which can be used to set EFI console input/output independently of
>>> u-boot's input/output.  If unset, EFI console will default to stdin/
>>> stdout as before.
>>>
>>> Signed-off-by: Rob Clark 
>>
>> With this patch, we lose the ability to have the efi in/out go to both
>> graphical and serial console, right? This is critical functionality to
>> have, since we don't necessarily know which output/input a user ends up
>> using.
> 
> I'll think about how to support iomux.. but some things like console
> size are just not going to work properly there.  And as long as we fix

Yeah, those probably would need to get special cased.

> the stdout shenanigans (ie. what I was seeing w/ qemu-x86) you can
> simply not set efiout var and have things working as before, so you
> don't loose any existing functionality (although, like I said, if the
> two different consoles have different sizes things aren't going to
> work properly for anything other than simple cases).
> 
> In most cases, the display driver should be able to detect whether a
> display is connected.. this is what I've done on dragonboard410c, so
> if no display plugged in, 'efiout=vidconsole' fails and you fall back
> to serial, else you get efi on screen like you would on a "real"
> computer.  For boards that have a display driver that isn't able to do
> the basic check of whether a cable is plugged in, just don't set
> "efiout" (or fix the display driver) ;-)

Are you sure that's what happens on a "real" computer? As far as I
remember from all ARM servers running edk2 based firmware that I've
touched so far, the default is always to display on serial *and*
graphical output at the same time.


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

Re: [U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols

[Alexander Graf]

On 12.10.17 00:02, Rob Clark wrote:
> On Wed, Oct 11, 2017 at 10:30 AM, Alexander Graf  wrote:
>>
>>
>> On 10.10.17 14:22, Rob Clark wrote:
>>> From: Leif Lindholm 
>>>
>>> Enough implementation of the following protocols to run Shell.efi and
>>> SCT.efi:
>>>
>>>   EfiHiiConfigRoutingProtocolGuid
>>>   EfiHiiDatabaseProtocol
>>>   EfiHiiStringProtocol
>>>
>>> We'll fill in the rest once SCT is running properly so we can validate
>>> the implementation against the conformance test suite.
>>>
>>> Initial skeleton written by Leif, and then implementation by myself.
>>>
>>> Cc: Leif Lindholm 
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  include/efi_api.h | 261 ++
>>>  include/efi_loader.h  |   6 +
>>>  lib/efi_loader/Makefile   |   2 +-
>>>  lib/efi_loader/efi_boottime.c |   9 +
>>>  lib/efi_loader/efi_hii.c  | 507 
>>> ++
>>>  5 files changed, 784 insertions(+), 1 deletion(-)
>>>  create mode 100644 lib/efi_loader/efi_hii.c
>>>
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index ffdba7fe1a..164147dc87 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -16,6 +16,7 @@
>>>  #define _EFI_API_H
>>>
>>>  #include 
>>> +#include 
>>>
>>>  #ifdef CONFIG_EFI_LOADER
>>>  #include 
>>> @@ -536,6 +537,266 @@ struct efi_device_path_utilities_protocol {
>>>   uint16_t node_length);
>>>  };
>>>
>>> +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
>>> + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
>>> +  0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
>>> +
>>> +typedef uint16_t efi_string_id_t;
>>> +
>>> +struct efi_hii_config_routing_protocol {
>>> + efi_status_t(EFIAPI *extract_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t request,
>>> + efi_string_t *progress,
>>> + efi_string_t *results);
>>> + efi_status_t(EFIAPI *export_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + efi_string_t *results);
>>> + efi_status_t(EFIAPI *route_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t configuration,
>>> + efi_string_t *progress);
>>> + efi_status_t(EFIAPI *block_to_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t config_request,
>>> + const uint8_t *block,
>>> + const efi_uintn_t block_size,
>>> + efi_string_t *config,
>>> + efi_string_t *progress);
>>> + efi_status_t(EFIAPI *config_to_block)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t config_resp,
>>> + const uint8_t *block,
>>> + const efi_uintn_t *block_size,
>>> + efi_string_t *progress);
>>> + efi_status_t(EFIAPI *get_alt_config)(
>>> + const struct efi_hii_config_routing_protocol *this,
>>> + const efi_string_t config_resp,
>>> + const efi_guid_t *guid,
>>> + const efi_string_t name,
>>> + const struct efi_device_path *device_path,
>>> + const efi_string_t alt_cfg_id,
>>> + efi_string_t *alt_cfg_resp);
>>> +};
>>> +
>>> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
>>> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
>>> +  0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
>>> +
>>> +typedef enum {
>>> + EFI_KEY_LCTRL, EFI_KEY_A0, EFI_KEY_LALT, EFI_KEY_SPACE_BAR,
>>> + EFI_KEY_A2, EFI_KEY_A3, EFI_KEY_A4, EFI_KEY_RCTRL, EFI_KEY_LEFT_ARROW,
>>> + EFI_KEY_DOWN_ARROW, EFI_KEY_RIGHT_ARROW, EFI_KEY_ZERO,
>>> + EFI_KEY_PERIOD, EFI_KEY_ENTER, EFI_KEY_LSHIFT, EFI_KEY_B0,
>>> + EFI_KEY_B1, EFI_KEY_B2, EFI_KEY_B3, EFI_KEY_B4, EFI_KEY_B5, 
>>> EFI_KEY_B6,
>>> + EFI_KEY_B7, EFI_KEY_B8, EFI_KEY_B9, EFI_KEY_B10, EFI_KEY_RSHIFT,
>>> + EFI_KEY_UP_ARROW, EFI_KEY_ONE, EFI_KEY_TWO, EFI_KEY_THREE,
>>> + EFI_KEY_CAPS_LOCK, EFI_KEY_C1, EFI_KEY_C2, EFI_KEY_C3, EFI_KEY_C4,
>>> + EFI_KEY_C5, EFI_KEY_C6, EFI_KEY_C7, EFI_KEY_C8, EFI_KEY_C9,
>>> + EFI_KEY_C10, EFI_KEY_C11, EFI_KEY_C12, EFI_KEY_FOUR, EFI_KEY_FIVE,
>>> + EFI_KEY_SIX, EFI_KEY_PLUS, EFI_KEY_TAB, EFI_KEY_D1, EFI_KEY_D2,
>>> + EFI_KEY_D3, EFI_KEY_D4, EFI_KEY_D5, EFI_KEY_D6, EFI_KEY_D7, 
>>> EFI_KEY_D8,
>>> + EFI_KEY_D9, EFI_KEY_D10, EFI_KEY_D11, EFI_KEY_D12, EFI_KEY_D13,
>>> + EFI_KEY_DEL, EFI_KEY_END, EFI_KEY_PG_DN, EFI_KEY_SEVEN, EFI_KEY_EIGHT,
>>> + EFI_KEY_NINE, EFI_KEY_E0, EFI_KEY_E1, EFI_KEY_E2, EFI_KEY_E3,
>>> + EFI_KEY_E4, EFI_KEY_E5, EFI_KEY_E6, EFI_KEY_E7, EFI_KEY_E8, 
>>> EFI_KEY_E9,
>>> + EFI_KEY_E10, EFI_KEY_E11, EFI_KEY_E12, EFI_KEY_BACK_SPACE,
>>> + EFI_KEY_INS, EFI_KEY_HOME, 

Re: [U-Boot] [PATCH 01/11] efi_loader: Initial EFI_DEVICE_PATH_UTILITIES_PROTOCOL

[Heinrich Schuchardt]

On 10/11/2017 10:32 PM, Rob Clark wrote:

On Wed, Oct 11, 2017 at 10:07 AM, Alexander Graf  wrote:



On 10.10.17 14:22, Rob Clark wrote:

From: Leif Lindholm 

Not complete, but enough for Shell.efi and SCT.efi.  We'll implement the
rest as needed or once we have SCT running properly so there is a way to
validate the interface against the conformance test suite.

Initial skeleton written by Leif, and then implementation by myself.

Cc: Leif Lindholm 
Signed-off-by: Rob Clark 
---
  include/efi_api.h  | 34 +++-
  include/efi_loader.h   |  2 +
  lib/efi_loader/Makefile|  1 +
  lib/efi_loader/efi_boottime.c  |  4 ++
  lib/efi_loader/efi_device_path_utilities.c | 88 ++
  5 files changed, 127 insertions(+), 2 deletions(-)
  create mode 100644 lib/efi_loader/efi_device_path_utilities.c

diff --git a/include/efi_api.h b/include/efi_api.h
index a9a6494afe..ffdba7fe1a 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -28,8 +28,9 @@ enum efi_timer_delay {
   EFI_TIMER_RELATIVE = 2
  };

-#define UINTN size_t
-typedef long INTN;
+#define UINTN size_t   /* TODO this should be removed in a future patch */


$ git grep UINTN | wc -l
13

Just send a preceding patch that introduces efi_uintn_t and replaces all
occurences of UINTN with it.

The uintn bits shouldn't be part of the
EFI_DEVICE_PATH_UTILITIES_PROTOCOL patch anyways :).



Heinrich mentioned he was doing that, so I didn't want to step on
feet.  I figured this was the easiest approach regardless of the order
of merging patches (should be simple enough to drop the duplicate
efi_uintn_t)


I do not mind if you put the change in one of your patches. Just do what 
is needed to get your patch series merged.


Best regards

Heinrich



BR,
-R


+typedef size_t efi_uintn_t;
+typedef ssize_t efi_intn_t;
  typedef uint16_t *efi_string_t;



Alex



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

[U-Boot] [PATCH v2] armv8: configs: ls1012a: correct the generic timer frequency issue

[andy.tang]

From: Yuantian Tang 

On ls1012a soc, core clock source frequency is 100Mhz.
Generic timer frequency is derived from core clock source divided
by 4, which is 25Mhz. So assign timer frequency to 25Mhz here.

Signed-off-by: Tang Yuantian 
---
v2:
- refine the commit message

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

diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index 096799eb64..a4e78f335f 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -32,7 +32,7 @@
 #define CONFIG_SYS_DDR_BLOCK2_BASE 0x88000ULL
 
 /* Generic Timer Definitions */
-#define COUNTER_FREQUENCY  CONFIG_SYS_CLK_FREQ/4   /* 25MHz */
+#define COUNTER_FREQUENCY  2500/* 25MHz */
 
 /* CSU */
 #define CONFIG_LAYERSCAPE_NS_ACCESS
-- 
2.14.1

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

Re: [U-Boot] [PATCH] x86: minnowmax: Adjust VGA rom address

[Bin Meng]

On Sat, Oct 7, 2017 at 5:44 PM, Stefan Roese  wrote:
> On 07.10.2017 11:43, Bin Meng wrote:
>>
>> Adjust VGA rom address to 0xfffb so that u-boot.rom image
>> can be built again.
>>
>> Signed-off-by: Bin Meng 
>
>
> Reviewed-by: Stefan Roese 

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 v3 5/5] ls1088aqds: Enable USB command on QDS for qspi-boot

[Bin Meng]

On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang  wrote:
> Signed-off-by: Amrita Kumari 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Ran Wang 
> ---
> Change in v3:
> - none
>
> Change in v2:
> Remove macro CONFIG_HAS_FSL_XHCI_USB and CONFIG_USB_XHCI_FSL
> and CONFIG_USB_MAX_CONTROLLER_COUNT from ls1088aqds.h since
> Kconfig option has covered.
>
> Change in v1:
> Rebased to
> ba39608 ARM: DRA72x: Add support for detection of DRA71x SR 2.1
>
>  configs/ls1088aqds_qspi_defconfig | 8 
>  1 file changed, 8 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 4/5] ls1088ardb: Enable USB command RDB qspi-boot

[Bin Meng]

On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang  wrote:
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Amrita Kumari 
> Signed-off-by: Ran Wang 
> ---
> Change in v3:
> 1.Move HAS_FSL_XHCI_USB and USB_XHCI_FSL define to other patch file.
>
> Change in v2:
> 1.Adjust USB nodes position in dts to keep them sorted in
>   unit-address.
> 2.Move macro CONFIG_HAS_FSL_XHCI_USB and CONFIG_USB_XHCI_FSL
>   to Kconfig option.
> 3.Remove CONFIG_USB_MAX_CONTROLLER_COUNT.
>
> Change in v1:
> Rebased to
> ba39608 ARM: DRA72x: Add support for detection of DRA71x SR 2.1
>
>  arch/arm/dts/fsl-ls1088a.dtsi | 14 ++
>  configs/ls1088ardb_qspi_defconfig |  8 
>  include/linux/usb/xhci-fsl.h  |  2 +-
>  3 files changed, 23 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 v3 3/5] arm: layerscape: Remove CONFIG_USB_MAX_CONTROLLER_COUNT

[Bin Meng]

Hi Ran,

On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang  wrote:
> Because COMFIG_DM_USB have been enabled and will not use it anymore.

nits: has been enabled

>
> Signed-off-by: Ran Wang 
> ---
> Change in v3:
> New patch file.
>
>  include/configs/ls1012afrdm.h | 5 -
>  include/configs/ls1012aqds.h  | 3 ---
>  include/configs/ls1012ardb.h  | 4 
>  include/configs/ls1021aiot.h  | 3 ---
>  include/configs/ls1021aqds.h  | 3 ---
>  include/configs/ls1021atwr.h  | 3 ---
>  include/configs/ls1043aqds.h  | 3 ---
>  include/configs/ls1043ardb.h  | 5 -
>  include/configs/ls1046aqds.h  | 3 ---
>  include/configs/ls1046ardb.h  | 5 -
>  include/configs/ls2080aqds.h  | 5 -
>  include/configs/ls2080ardb.h  | 5 -
>  12 files changed, 47 deletions(-)
>

Other than that,
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 v3 2/5] usb: host: Move CONFIG_XHCI_FSL to Kconfig

[Bin Meng]

Hi Ran,

On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang  wrote:
> use Kconfig to select xhci accordingly.
>
> Signed-off-by: Ran Wang 
> ---
> Change in v3:
> New patch file.
>
>  drivers/usb/host/Kconfig  | 6 ++
>  include/configs/ls1012afrdm.h | 1 -
>  include/configs/ls1012aqds.h  | 1 -
>  include/configs/ls1012ardb.h  | 1 -
>  include/configs/ls1021aiot.h  | 1 -
>  include/configs/ls1021aqds.h  | 1 -
>  include/configs/ls1021atwr.h  | 1 -
>  include/configs/ls1043aqds.h  | 1 -
>  include/configs/ls1043ardb.h  | 1 -
>  include/configs/ls1046aqds.h  | 1 -
>  include/configs/ls1046ardb.h  | 1 -
>  include/configs/ls2080aqds.h  | 1 -
>  include/configs/ls2080ardb.h  | 1 -
>  scripts/config_whitelist.txt  | 1 -
>  14 files changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index f797a2568c..70e38a0425 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -71,6 +71,12 @@ config USB_XHCI_DRA7XX_INDEX
>   Select the DRA7XX xHCI USB index.
>   Current supported values: 0, 1.
>
> +config USB_XHCI_FSL
> +   bool "Support for NXPLayerscape on-chip xHCI USB controller"

nits: NXP Layerscape

> +   default y if ARCH_LS1021A || FSL_LSCH3 || FSL_LSCH2
> +   depends on !SPL_NO_USB
> +   help
> + Enables support for the on-chip xHCI controller on NXP Layerscape 
> SoCs.
>  endif # USB_XHCI_HCD
>
>  config USB_EHCI_HCD
> diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h
> index 2e5af9cc4e..2e9c619bd5 100644
> --- a/include/configs/ls1012afrdm.h
> +++ b/include/configs/ls1012afrdm.h
> @@ -34,7 +34,6 @@
>  /*
>  * USB
>  */
> -#define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT 1
>
>  #define CONFIG_CMD_MEMINFO
> diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
> index e0949d0b53..70bf72c431 100644
> --- a/include/configs/ls1012aqds.h
> +++ b/include/configs/ls1012aqds.h
> @@ -119,7 +119,6 @@
>  #endif
>
>  /*XHCI Support - enabled by default*/
> -#define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT 1
>
>  /*  MMC  */
> diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
> index 66ff004384..110fcc6323 100644
> --- a/include/configs/ls1012ardb.h
> +++ b/include/configs/ls1012ardb.h
> @@ -22,7 +22,6 @@
>  /*
>  * USB
>  */
> -#define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT 1
>
>  /*
> diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h
> index 2cbea87d95..dac4a81e2a 100644
> --- a/include/configs/ls1021aiot.h
> +++ b/include/configs/ls1021aiot.h
> @@ -20,7 +20,6 @@
>  #define CONFIG_SYS_INIT_RAM_SIZE   OCRAM_SIZE
>
>  /* XHCI Support - enabled by default */
> -#define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT1
>
>  #define CONFIG_SYS_CLK_FREQ1
> diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
> index 0046ded536..8346e3658f 100644
> --- a/include/configs/ls1021aqds.h
> +++ b/include/configs/ls1021aqds.h
> @@ -405,7 +405,6 @@ unsigned long get_board_ddr_clk(void);
>  #endif
>
>  /*XHCI Support - enabled by default*/
> -#define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT1
>
>  /*
> diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
> index 0172c9015d..8ccc81642d 100644
> --- a/include/configs/ls1021atwr.h
> +++ b/include/configs/ls1021atwr.h
> @@ -45,7 +45,6 @@
>  #endif
>
>  /* XHCI Support - enabled by default */
> -#define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT1
>
>  #define CONFIG_SYS_CLK_FREQ1
> diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h
> index 607c289d17..641ffc1400 100644
> --- a/include/configs/ls1043aqds.h
> +++ b/include/configs/ls1043aqds.h
> @@ -371,7 +371,6 @@ unsigned long get_board_ddr_clk(void);
>  #endif
>
>  /* USB */
> -#define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT3
>
>  /*
> diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h
> index 866817d579..0e02be445a 100644
> --- a/include/configs/ls1043ardb.h
> +++ b/include/configs/ls1043ardb.h
> @@ -281,7 +281,6 @@
>
>  /* USB */
>  #ifndef SPL_NO_USB
> -#define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT3
>  #endif
>
> diff --git a/include/configs/ls1046aqds.h b/include/configs/ls1046aqds.h
> index d47616f2e7..2f2602f098 100644
> --- a/include/configs/ls1046aqds.h
> +++ b/include/configs/ls1046aqds.h
> @@ -137,7 +137,6 @@ unsigned long get_board_ddr_clk(void);
>  #endif
>
>  /* USB */
> -#define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT 3
>
>  /* SATA */
> diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h
> index 32b08d8229..40ce8ff462 100644
> --- 

Re: [U-Boot] [PATCH v3 1/5] arm64: layerscape: Move CONFIG_HAS_FSL_XHCI_USB to Kconfig

[Bin Meng]

Hi Ran,

On Wed, Oct 11, 2017 at 1:30 PM, Ran Wang  wrote:
> Use Kconfig to select QE-HDLC and USB pin-mux.
>
> Signed-off-by: Ran Wang 
> ---
> Change in v3:
> New patch file.
>
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 7 +++
>  include/configs/ls1012afrdm.h | 4 
>  include/configs/ls1012aqds.h  | 4 
>  include/configs/ls1012ardb.h  | 4 
>  include/configs/ls1021aiot.h  | 4 
>  include/configs/ls1021aqds.h  | 4 
>  include/configs/ls1021atwr.h  | 4 
>  include/configs/ls1043aqds.h  | 3 ---
>  include/configs/ls1043ardb.h  | 3 ---
>  include/configs/ls1046aqds.h  | 3 ---
>  include/configs/ls1046ardb.h  | 3 ---
>  include/configs/ls2080aqds.h  | 1 -
>  include/configs/ls2080ardb.h  | 1 -
>  scripts/config_whitelist.txt  | 1 -
>  14 files changed, 7 insertions(+), 39 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index 3518d8601d..9fda8a1e83 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -489,3 +489,10 @@ config SYS_MC_RSV_MEM_ALIGN
>
>  config SPL_LDSCRIPT
> default "arch/arm/cpu/armv8/u-boot-spl.lds" if ARCH_LS1043A || 
> ARCH_LS1046A || ARCH_LS2080A
> +
> +config HAS_FSL_XHCI_USB
> +   bool
> +   default y if ARCH_LS1043A || ARCH_LS1046A

How about LS2080? I see there is modification on 2080 related files in
this patch.

> +   help
> + For some SoC(such as LS1043A and LS1046A), USB and QE-HDLC multi-use

nits: SoCs (

What is multi-use? I think you wanted to say: multiplex

> + the pins, select it when pin assigned to USB.

nits: when pin is assigned

> diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h
> index 6b1ba578e9..2e5af9cc4e 100644
> --- a/include/configs/ls1012afrdm.h
> +++ b/include/configs/ls1012afrdm.h
> @@ -34,12 +34,8 @@
>  /*
>  * USB
>  */
> -#define CONFIG_HAS_FSL_XHCI_USB
> -
> -#ifdef CONFIG_HAS_FSL_XHCI_USB
>  #define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT 1
> -#endif
>
>  #define CONFIG_CMD_MEMINFO
>  #define CONFIG_CMD_MEMTEST
> diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
> index b3121d2c21..e0949d0b53 100644
> --- a/include/configs/ls1012aqds.h
> +++ b/include/configs/ls1012aqds.h
> @@ -119,12 +119,8 @@
>  #endif
>
>  /*XHCI Support - enabled by default*/
> -#define CONFIG_HAS_FSL_XHCI_USB
> -
> -#ifdef CONFIG_HAS_FSL_XHCI_USB
>  #define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT 1
> -#endif
>
>  /*  MMC  */
>  #ifdef CONFIG_MMC
> diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
> index e9edcd2bc9..66ff004384 100644
> --- a/include/configs/ls1012ardb.h
> +++ b/include/configs/ls1012ardb.h
> @@ -22,12 +22,8 @@
>  /*
>  * USB
>  */
> -#define CONFIG_HAS_FSL_XHCI_USB
> -
> -#ifdef CONFIG_HAS_FSL_XHCI_USB
>  #define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT 1
> -#endif
>
>  /*
>   * I2C IO expander
> diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h
> index 3fe7b8f44c..2cbea87d95 100644
> --- a/include/configs/ls1021aiot.h
> +++ b/include/configs/ls1021aiot.h
> @@ -20,12 +20,8 @@
>  #define CONFIG_SYS_INIT_RAM_SIZE   OCRAM_SIZE
>
>  /* XHCI Support - enabled by default */
> -#define CONFIG_HAS_FSL_XHCI_USB
> -
> -#ifdef CONFIG_HAS_FSL_XHCI_USB
>  #define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT1
> -#endif
>
>  #define CONFIG_SYS_CLK_FREQ1
>  #define CONFIG_DDR_CLK_FREQ1
> diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
> index f3d3aa2271..0046ded536 100644
> --- a/include/configs/ls1021aqds.h
> +++ b/include/configs/ls1021aqds.h
> @@ -405,12 +405,8 @@ unsigned long get_board_ddr_clk(void);
>  #endif
>
>  /*XHCI Support - enabled by default*/
> -#define CONFIG_HAS_FSL_XHCI_USB
> -
> -#ifdef CONFIG_HAS_FSL_XHCI_USB
>  #define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT1
> -#endif
>
>  /*
>   * Video
> diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
> index 852ff57fb6..0172c9015d 100644
> --- a/include/configs/ls1021atwr.h
> +++ b/include/configs/ls1021atwr.h
> @@ -45,12 +45,8 @@
>  #endif
>
>  /* XHCI Support - enabled by default */
> -#define CONFIG_HAS_FSL_XHCI_USB
> -
> -#ifdef CONFIG_HAS_FSL_XHCI_USB
>  #define CONFIG_USB_XHCI_FSL
>  #define CONFIG_USB_MAX_CONTROLLER_COUNT1
> -#endif
>
>  #define CONFIG_SYS_CLK_FREQ1
>  #define CONFIG_DDR_CLK_FREQ1
> diff --git a/include/configs/ls1043aqds.h b/include/configs/ls1043aqds.h
> index 5aadd92efd..607c289d17 100644
> ---