[U-Boot] [PATCH 5/6] board/BuR: provide real clock-frequency instead a divider

2018-01-08 Thread Hannes Schmelzer
Actual am335x-fb implementation takes now a real clock frequency instead
a divider. So this component doesn't need to know anymore some base
frequency of the LCDC, we simply provide the pixel-clock frequency.

Signed-off-by: Hannes Schmelzer 
---

 board/BuR/common/common.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/board/BuR/common/common.c b/board/BuR/common/common.c
index 7e49cdf..0c64bed 100644
--- a/board/BuR/common/common.c
+++ b/board/BuR/common/common.c
@@ -146,13 +146,7 @@ int load_lcdtiming(struct am335x_lcdpanel *panel)
pnltmp.vsw = FDTPROP(PATHTIM, "vsync-len");
pnltmp.pup_delay = FDTPROP(PATHTIM, "pupdelay");
pnltmp.pon_delay = FDTPROP(PATHTIM, "pondelay");
-
-   /* calc. proper clk-divisor */
-   dtbprop = FDTPROP(PATHTIM, "clock-frequency");
-   if (dtbprop != ~0UL)
-   pnltmp.pxl_clk_div = 19200 / dtbprop;
-   else
-   pnltmp.pxl_clk_div = ~0UL;
+   pnltmp.pxl_clk_div = FDTPROP(PATHTIM, "clock-frequency");
 
/* check polarity of control-signals */
dtbprop = FDTPROP(PATHTIM, "hsync-active");
@@ -202,7 +196,7 @@ int load_lcdtiming(struct am335x_lcdpanel *panel)
pnltmp.vfp = env_get_ulong("ds1_vfp", 10, ~0UL);
pnltmp.vbp = env_get_ulong("ds1_vbp", 10, ~0UL);
pnltmp.vsw = env_get_ulong("ds1_vsw", 10, ~0UL);
-   pnltmp.pxl_clk_div = env_get_ulong("ds1_pxlclkdiv", 10, ~0UL);
+   pnltmp.pxl_clk = env_get_ulong("ds1_pxlclk", 10, ~0UL);
pnltmp.pol = env_get_ulong("ds1_pol", 16, ~0UL);
pnltmp.pup_delay = env_get_ulong("ds1_pupdelay", 10, ~0UL);
pnltmp.pon_delay = env_get_ulong("ds1_tondelay", 10, ~0UL);
@@ -218,7 +212,7 @@ int load_lcdtiming(struct am335x_lcdpanel *panel)
   ~0UL == (pnltmp.vfp) ||
   ~0UL == (pnltmp.vbp) ||
   ~0UL == (pnltmp.vsw) ||
-  ~0UL == (pnltmp.pxl_clk_div) ||
+  ~0UL == (pnltmp.pxl_clk) ||
   ~0UL == (pnltmp.pol) ||
   ~0UL == (pnltmp.pup_delay) ||
   ~0UL == (pnltmp.pon_delay)
@@ -241,7 +235,7 @@ int load_lcdtiming(struct am335x_lcdpanel *panel)
pnltmp.hactive, pnltmp.vactive, pnltmp.bpp,
pnltmp.hfp, pnltmp.hbp, pnltmp.hsw,
pnltmp.vfp, pnltmp.vbp, pnltmp.vsw,
-   pnltmp.pxl_clk_div, pnltmp.pol, pnltmp.pon_delay);
+   pnltmp.pxl_clk, pnltmp.pol, pnltmp.pon_delay);
 
return -1;
}
-- 
2.7.4

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


[U-Boot] [PATCH 6/6] board/BuR: drop LCDC clock manipulation from board code

2018-01-08 Thread Hannes Schmelzer
The clock selection is done now from the am335x-fb code, so there is no
more need doing this in the board code.

Signed-off-by: Hannes Schmelzer 
---

 board/BuR/brppt1/board.c | 3 ---
 board/BuR/brxre1/board.c | 2 --
 2 files changed, 5 deletions(-)

diff --git a/board/BuR/brppt1/board.c b/board/BuR/brppt1/board.c
index 6083479..9f7b2d9 100644
--- a/board/BuR/brppt1/board.c
+++ b/board/BuR/brppt1/board.c
@@ -120,9 +120,6 @@ void am33xx_spl_board_init(void)
};
do_enable_clocks(clk_domains, clk_modules_tsspecific, 1);
 
-   /* setup LCD-Pixel Clock */
-   writel(0x2, >clklcdcpixelclk);  /* clock comes from perPLL M2 */
-
/* setup I2C */
enable_i2c_pin_mux();
i2c_set_bus_num(0);
diff --git a/board/BuR/brxre1/board.c b/board/BuR/brxre1/board.c
index 856ac3d..e176b60 100644
--- a/board/BuR/brxre1/board.c
+++ b/board/BuR/brxre1/board.c
@@ -121,8 +121,6 @@ void am33xx_spl_board_init(void)
0
};
do_enable_clocks(clk_domains, clk_modules_xre1specific, 1);
-   /* setup LCD-Pixel Clock */
-   writel(0x2, CM_DPLL + 0x34);
/* power-OFF LCD-Display */
gpio_direction_output(LCD_PWR, 0);
 
-- 
2.7.4

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


[U-Boot] [PATCH 3/6] am335x-fb: cosmetic: fix coding style

2018-01-08 Thread Hannes Schmelzer
Signed-off-by: Hannes Schmelzer 
---

 drivers/video/am335x-fb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/am335x-fb.c b/drivers/video/am335x-fb.c
index 8cdd2ec..5494c3c 100644
--- a/drivers/video/am335x-fb.c
+++ b/drivers/video/am335x-fb.c
@@ -108,11 +108,11 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
 {
u32 raster_ctrl = 0;
 
-   if (0 == gd->fb_base) {
+   if (gd->fb_base == NULL) {
printf("ERROR: no valid fb_base stored in GLOBAL_DATA_PTR!\n");
return -1;
}
-   if (0 == panel) {
+   if (panel == NULL) {
printf("ERROR: missing ptr to am335x_lcdpanel!\n");
return -1;
}
@@ -147,7 +147,7 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
gd->fb_base += 0x20;
 
/* turn ON display through powercontrol function if accessible */
-   if (0 != panel->panel_power_ctrl)
+   if (panel->panel_power_ctrl != NULL)
panel->panel_power_ctrl(1);
 
debug("am335x-fb: wait for stable power ...\n");
-- 
2.7.4

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


[U-Boot] [PATCH 4/6] am335x-fb: setup display PLL

2018-01-08 Thread Hannes Schmelzer
The LCDC IP-core an be feed from several clock sources, one of those is
a dedicated DPLL for generating a dividable base-clock for this IP-core.

The TRM specifies the maximum input frequency for the LCCD with 200 MHz,
so we must not exceed this value with the PLL frequency (which can lock
much higher).

This patch tries every combination of multipliers and divisors of the
PLL and the IP-core itself for getting as near as possible the the
requested panel->pxl_clk.

Signed-off-by: Hannes Schmelzer 
---

 drivers/video/am335x-fb.c | 54 ---
 drivers/video/am335x-fb.h |  2 +-
 2 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/drivers/video/am335x-fb.c b/drivers/video/am335x-fb.c
index 5494c3c..1be28e3 100644
--- a/drivers/video/am335x-fb.c
+++ b/drivers/video/am335x-fb.c
@@ -12,7 +12,11 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include "am335x-fb.h"
 
@@ -20,6 +24,7 @@
 #error "hw-base address of LCD-Controller (LCD_CNTL_BASE) not defined!"
 #endif
 
+#define LCDC_FMAX  2
 
 /* LCD Control Register */
 #define LCD_CLK_DIVISOR(x) ((x) << 8)
@@ -96,6 +101,7 @@ struct am335x_lcdhw {
 };
 
 static struct am335x_lcdhw *lcdhw = (void *)LCD_CNTL_BASE;
+
 DECLARE_GLOBAL_DATA_PTR;
 
 int lcd_get_size(int *line_length)
@@ -108,6 +114,11 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
 {
u32 raster_ctrl = 0;
 
+   struct cm_dpll *const cmdpll = (struct cm_dpll *)CM_DPLL;
+   struct dpll_params dpll_disp = { 1, 0, 1, -1, -1, -1, -1 };
+   unsigned int m, n, d, best_d = 2;
+   int err = 0, err_r = 0;
+
if (gd->fb_base == NULL) {
printf("ERROR: no valid fb_base stored in GLOBAL_DATA_PTR!\n");
return -1;
@@ -132,14 +143,51 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
return -1;
}
 
+   /* check given clock-frequency */
+   if (panel->pxl_clk > (LCDC_FMAX / 2)) {
+   pr_err("am335x-fb: requested pxl-clk: %d not supported!\n",
+  panel->pxl_clk);
+   return -1;
+   }
+
debug("setting up LCD-Controller for %dx%dx%d (hfp=%d,hbp=%d,hsw=%d / ",
  panel->hactive, panel->vactive, panel->bpp,
  panel->hfp, panel->hbp, panel->hsw);
-   debug("vfp=%d,vbp=%d,vsw=%d / clk-div=%d)\n",
- panel->vfp, panel->vfp, panel->vsw, panel->pxl_clk_div);
+   debug("vfp=%d,vbp=%d,vsw=%d / clk=%d)\n",
+ panel->vfp, panel->vfp, panel->vsw, panel->pxl_clk);
debug("using frambuffer at 0x%08x with size %d.\n",
  (unsigned int)gd->fb_base, FBSIZE(panel));
 
+   /* setup display pll for requested clock frequency */
+   err = panel->pxl_clk;
+   err_r = err;
+
+   for (d = 2; d < 255; d++) {
+   for (m = 2; m < 2047; m++) {
+   if ((V_OSCK * m) < (panel->pxl_clk * d))
+   continue;
+   n = (V_OSCK * m) / (panel->pxl_clk * d);
+   if (n > 127)
+   break;
+   if (((V_OSCK * m) / n) > LCDC_FMAX)
+   break;
+
+   err = abs((V_OSCK * m) / n / d - panel->pxl_clk);
+   if (err < err_r) {
+   err_r = err;
+   dpll_disp.m = m;
+   dpll_disp.n = n;
+   best_d = d;
+   }
+   }
+   }
+   debug("%s: PLL: best error %d Hz (M %d, N %d, DISP %d)\n",
+ __func__, err_r, dpll_disp.m, dpll_disp.n, best_d);
+   do_setup_dpll(_disp_regs, _disp);
+
+   /* clock source for LCDC from dispPLL M2 */
+   writel(0x0, >clklcdcpixelclk);
+
/* palette default entry */
memset((void *)gd->fb_base, 0, 0x20);
*(unsigned int *)gd->fb_base = 0x4000;
@@ -154,7 +202,7 @@ int am335xfb_init(struct am335x_lcdpanel *panel)
mdelay(panel->pup_delay);
lcdhw->clkc_enable = LCD_CORECLKEN | LCD_LIDDCLKEN | LCD_DMACLKEN;
lcdhw->raster_ctrl = 0;
-   lcdhw->ctrl = LCD_CLK_DIVISOR(panel->pxl_clk_div) | LCD_RASTER_MODE;
+   lcdhw->ctrl = LCD_CLK_DIVISOR(best_d) | LCD_RASTER_MODE;
lcdhw->lcddma_fb0_base = gd->fb_base;
lcdhw->lcddma_fb0_ceiling = gd->fb_base + FBSIZE(panel);
lcdhw->lcddma_fb1_base = gd->fb_base;
diff --git a/drivers/video/am335x-fb.h b/drivers/video/am335x-fb.h
index 1980eda..e25c361 100644
--- a/drivers/video/am335x-fb.h
+++ b/drivers/video/am335x-fb.h
@@ -53,7 +53,7 @@ struct am335x_lcdpanel {
unsigned intvfp;/* Vertical front porch */
unsigned intvbp;/* Vertical back porch */
unsigned intvsw;/* 

[U-Boot] [PATCH 1/6] mach-omap2: add AM335x Display PLL register definition

2018-01-08 Thread Hannes Schmelzer
Adds the register definition of the Display DPLL

Signed-off-by: Hannes Schmelzer 

---

 arch/arm/include/asm/arch-am33xx/clock.h  | 1 +
 arch/arm/mach-omap2/am33xx/clock_am33xx.c | 7 +++
 2 files changed, 8 insertions(+)

diff --git a/arch/arm/include/asm/arch-am33xx/clock.h 
b/arch/arm/include/asm/arch-am33xx/clock.h
index 5399bb8..9dbcd3a 100644
--- a/arch/arm/include/asm/arch-am33xx/clock.h
+++ b/arch/arm/include/asm/arch-am33xx/clock.h
@@ -104,6 +104,7 @@ extern const struct dpll_regs dpll_mpu_regs;
 extern const struct dpll_regs dpll_core_regs;
 extern const struct dpll_regs dpll_per_regs;
 extern const struct dpll_regs dpll_ddr_regs;
+extern const struct dpll_regs dpll_disp_regs;
 extern const struct dpll_params dpll_mpu_opp[NUM_CRYSTAL_FREQ][NUM_OPPS];
 extern const struct dpll_params dpll_core_1000MHz[NUM_CRYSTAL_FREQ];
 extern const struct dpll_params dpll_per_192MHz[NUM_CRYSTAL_FREQ];
diff --git a/arch/arm/mach-omap2/am33xx/clock_am33xx.c 
b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
index 1780bbd..9ab4d25 100644
--- a/arch/arm/mach-omap2/am33xx/clock_am33xx.c
+++ b/arch/arm/mach-omap2/am33xx/clock_am33xx.c
@@ -52,6 +52,13 @@ const struct dpll_regs dpll_ddr_regs = {
.cm_div_m2_dpll = CM_WKUP + 0xA0,
 };
 
+const struct dpll_regs dpll_disp_regs = {
+   .cm_clkmode_dpll= CM_WKUP + 0x98,
+   .cm_idlest_dpll = CM_WKUP + 0x48,
+   .cm_clksel_dpll = CM_WKUP + 0x54,
+   .cm_div_m2_dpll = CM_WKUP + 0xA4,
+};
+
 struct dpll_params dpll_mpu_opp100 = {
CONFIG_SYS_MPUCLK, OSC-1, 1, -1, -1, -1, -1};
 const struct dpll_params dpll_core_opp100 = {
-- 
2.7.4

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


[U-Boot] [PATCH 2/6] am335x-fb: cosmetic: update-copyright

2018-01-08 Thread Hannes Schmelzer
Signed-off-by: Hannes Schmelzer 
---

 drivers/video/am335x-fb.c | 4 ++--
 drivers/video/am335x-fb.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/am335x-fb.c b/drivers/video/am335x-fb.c
index a8b3e74..8cdd2ec 100644
--- a/drivers/video/am335x-fb.c
+++ b/drivers/video/am335x-fb.c
@@ -1,6 +1,6 @@
 /*
- * Copyright (C) 2013 Hannes Schmelzer 
- * Bernecker & Rainer Industrieelektronik GmbH - http://www.br-automation.com
+ * Copyright (C) 2018 Hannes Schmelzer 
+ * B Industrial Automation GmbH - http://www.br-automation.com
  *
  * minimal framebuffer driver for TI's AM335x SoC to be compatible with
  * Wolfgang Denk's LCD-Framework (CONFIG_LCD, common/lcd.c)
diff --git a/drivers/video/am335x-fb.h b/drivers/video/am335x-fb.h
index 3f4b567..1980eda 100644
--- a/drivers/video/am335x-fb.h
+++ b/drivers/video/am335x-fb.h
@@ -1,6 +1,6 @@
 /*
- * Copyright (C) 2013 Hannes Schmelzer  -
- * Bernecker & Rainer Industrieelektronik GmbH - http://www.br-automation.com
+ * Copyright (C) 2018 Hannes Schmelzer  -
+ * B Industrial Automation GmbH - http://www.br-automation.com
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
-- 
2.7.4

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


[U-Boot] [PATCH 0/6] am335x-fb: support display PLL for lcd-clock / pixel-clock

2018-01-08 Thread Hannes Schmelzer
In most cases days ago the LCDC IP-core clock on AM335x was sourced from
the peripheral PLL with 192 MHz and the pixel clock for the connected
lcd-screen was made more or less accurate with a divider inside LCDC IP-
core.

For certain displays, example a standard VGA with 25.17 MHz pixelclock,
it is almost impossible to generate a reasonably clock with the 192 MHz
base and a simple divider. For those cases we have to use the dedicated
DPLL_DISP generating a dividable clock-source for the LCDC.

This series does this with following steps:
- adding register definition of the display PLL to clock_am33xx
- calculate mult, dividers with lowest error and setup the display PLL,
selecting as clock-source for LCDC the display PLL.
- drop the hardcoded dependency in BuR/common to the 192 MHz and
provide a real clock-frequency instead a divider
- drop the clock selection for the LCDC within board code
- do minor cosmetic cleanups (updating copyright, coding style)


Hannes Schmelzer (6):
  mach-omap2: add AM335x Display PLL register definition
  am335x-fb: cosmetic: update-copyright
  am335x-fb: cosmetic: fix coding style
  am335x-fb: setup display PLL
  board/BuR: provide real clock-frequency instead a divider
  board/BuR: drop LCDC clock manipulation from board code

 arch/arm/include/asm/arch-am33xx/clock.h  |  1 +
 arch/arm/mach-omap2/am33xx/clock_am33xx.c |  7 
 board/BuR/brppt1/board.c  |  3 --
 board/BuR/brxre1/board.c  |  2 -
 board/BuR/common/common.c | 14 ++-
 drivers/video/am335x-fb.c | 64 +++
 drivers/video/am335x-fb.h |  6 +--
 7 files changed, 71 insertions(+), 26 deletions(-)

-- 
2.7.4

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


Re: [U-Boot] [U-boot] Odroidxu3/4 -s2mps11 bind pmic failed

2018-01-08 Thread Jaehoon Chung
On 01/09/2018 03:16 PM, Anand Moon wrote:
> Hi Jaehoon/ Lukasz
> 
> On 9 January 2018 at 04:17, Jaehoon Chung  wrote:
>> Hi,
>>
>> On 01/08/2018 03:57 PM, Anand Moon wrote:
>>> Hi Jaehoon,
>>
>> This topic is on u-boot side. so Removed the linux-samsung-soc mailing.
>>
>> [..snip..]
>>
> How can we invoke and verify the s2mps11 init function during board
> initialization ?

 When i have checked the above values, those are the reset value at each 
 registers.
 but some registers are different with reset values.

 do you want to change the pmic register value at init time?
>>> [snip]
>>>
>>> What I have debug at my end pmci is not getting invoke or initialize via 
>>> u-boot.
>>> Yes default value for all the control registers would be fine.
>>>
>>> I was looking into some missing feature like.
>>> s2mps11 regulator initialization via dts in u-boot.
>>>  s2mps11_pmic
>>>  .probe = s2mps11_probe
>>>  .bind = s2mps11_bind
>>
>> It needs to implement the regulator driver.
>> I will send the patch for s2mps11 regulator driver within this week.
>> Then i think that it will be set to values from device-tree.
>>
> 
> Thanks you very much.

When i send the patch, i will add you account.

> 
>>>
>>> Can we enable CONFIG_SPL_BUILD for Odroid platform.
>>> much of the core initialization is blocked under this flag.
>>> Is their any plan to make this feature working.
>>
>> Lukasz has already mentioned..
>>
> 
> My guess is the SOC (Samsung) should take initiative in enable
> CONFIG_SPL_BUILD option.
> since HardKernel is not complete open on sharing the singing utility as per 
> NDA.
> but they have shared the following link to help on this.
> 
> https://forum.odroid.com/viewtopic.php?f=98=6147
> 
> As per my knowledge earlier Artik10 base on Exynos5422 was supported
> by Samsung developers.
> so it should be easily.

Artik10 is also based on exynos5422. Yep, it can be used u-boot spl without 
signing.
But hardkernel boards needs to use the signed bl2 image.

It doesn't belong to me to share the signing utility. (I don't have any 
permission about it..sorry.)

Best Regards,
Jaehoon Chung

> 
> Best Regards
> -Anand
> 
>>>
>>> Best Regards
>>> -Anand
>>>
>>>
>>>
>>
> 
> 
> 

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


Re: [U-Boot] [PATCH] ARM: zynq: remove unused CONFIG_ZC770_XM01* options

2018-01-08 Thread Michal Simek
On 28.11.2017 07:58, Masahiro Yamada wrote:
> These are defined, but not referenced at all.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  configs/zynq_zc770_xm010_defconfig | 1 -
>  configs/zynq_zc770_xm011_defconfig | 1 -
>  configs/zynq_zc770_xm012_defconfig | 1 -
>  configs/zynq_zc770_xm013_defconfig | 1 -
>  4 files changed, 4 deletions(-)
> 
> diff --git a/configs/zynq_zc770_xm010_defconfig 
> b/configs/zynq_zc770_xm010_defconfig
> index dbca4a6..69042f8 100644
> --- a/configs/zynq_zc770_xm010_defconfig
> +++ b/configs/zynq_zc770_xm010_defconfig
> @@ -5,7 +5,6 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm010"
>  CONFIG_FIT=y
>  CONFIG_FIT_SIGNATURE=y
>  CONFIG_FIT_VERBOSE=y
> -CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM010"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_SPL=y
>  CONFIG_SPL_OS_BOOT=y
> diff --git a/configs/zynq_zc770_xm011_defconfig 
> b/configs/zynq_zc770_xm011_defconfig
> index b1511d8..e78f4a2 100644
> --- a/configs/zynq_zc770_xm011_defconfig
> +++ b/configs/zynq_zc770_xm011_defconfig
> @@ -6,7 +6,6 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm011"
>  CONFIG_FIT=y
>  CONFIG_FIT_SIGNATURE=y
>  CONFIG_FIT_VERBOSE=y
> -CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM011"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_SPL=y
>  CONFIG_SPL_OS_BOOT=y
> diff --git a/configs/zynq_zc770_xm012_defconfig 
> b/configs/zynq_zc770_xm012_defconfig
> index 71b379a..956f1a4 100644
> --- a/configs/zynq_zc770_xm012_defconfig
> +++ b/configs/zynq_zc770_xm012_defconfig
> @@ -6,7 +6,6 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm012"
>  CONFIG_FIT=y
>  CONFIG_FIT_SIGNATURE=y
>  CONFIG_FIT_VERBOSE=y
> -CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM012"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_SPL=y
>  CONFIG_SPL_OS_BOOT=y
> diff --git a/configs/zynq_zc770_xm013_defconfig 
> b/configs/zynq_zc770_xm013_defconfig
> index 4ffb2f9..fc26bd0 100644
> --- a/configs/zynq_zc770_xm013_defconfig
> +++ b/configs/zynq_zc770_xm013_defconfig
> @@ -6,7 +6,6 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm013"
>  CONFIG_FIT=y
>  CONFIG_FIT_SIGNATURE=y
>  CONFIG_FIT_VERBOSE=y
> -CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM013"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_SPL=y
>  CONFIG_SPL_OS_BOOT=y
> 

Applied.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




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


Re: [U-Boot] [PATCH] arm: zynq: Remove ZC770_ config option

2018-01-08 Thread Michal Simek
Hi Masahiro,

On 8.1.2018 17:33, Masahiro Yamada wrote:
> 2018-01-09 0:59 GMT+09:00 Michal Simek :
>> This option is obsolete and it is no longer valid.
>>
>> Signed-off-by: Michal Simek 
>> ---
> 
> I agree, although
> an equivalent patch has been delegated to you for some months.
> http://patchwork.ozlabs.org/patch/841993/
> 
> 
> The only difference is I did not touch config_whitelist.
> It was intentional since I know Tom periodically syncs it anyway.

I missed your patch but I will take it now.

Thanks,
Michal


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


Re: [U-Boot] [U-boot] Odroidxu3/4 -s2mps11 bind pmic failed

2018-01-08 Thread Anand Moon
Hi Jaehoon/ Lukasz

On 9 January 2018 at 04:17, Jaehoon Chung  wrote:
> Hi,
>
> On 01/08/2018 03:57 PM, Anand Moon wrote:
>> Hi Jaehoon,
>
> This topic is on u-boot side. so Removed the linux-samsung-soc mailing.
>
> [..snip..]
>
 How can we invoke and verify the s2mps11 init function during board
 initialization ?
>>>
>>> When i have checked the above values, those are the reset value at each 
>>> registers.
>>> but some registers are different with reset values.
>>>
>>> do you want to change the pmic register value at init time?
>> [snip]
>>
>> What I have debug at my end pmci is not getting invoke or initialize via 
>> u-boot.
>> Yes default value for all the control registers would be fine.
>>
>> I was looking into some missing feature like.
>> s2mps11 regulator initialization via dts in u-boot.
>>  s2mps11_pmic
>>  .probe = s2mps11_probe
>>  .bind = s2mps11_bind
>
> It needs to implement the regulator driver.
> I will send the patch for s2mps11 regulator driver within this week.
> Then i think that it will be set to values from device-tree.
>

Thanks you very much.

>>
>> Can we enable CONFIG_SPL_BUILD for Odroid platform.
>> much of the core initialization is blocked under this flag.
>> Is their any plan to make this feature working.
>
> Lukasz has already mentioned..
>

My guess is the SOC (Samsung) should take initiative in enable
CONFIG_SPL_BUILD option.
since HardKernel is not complete open on sharing the singing utility as per NDA.
but they have shared the following link to help on this.

https://forum.odroid.com/viewtopic.php?f=98=6147

As per my knowledge earlier Artik10 base on Exynos5422 was supported
by Samsung developers.
so it should be easily.

Best Regards
-Anand

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


[U-Boot] [PATCH] LS2088ARDB: Fix NOR fall back option failure

2018-01-08 Thread Vinitha Pillai-B57223
From: Vinitha V Pillai 

Signed-off-by: Vinitha V Pillai 
---
 include/configs/ls2080ardb.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h
index 6f3301c..8770c6b 100644
--- a/include/configs/ls2080ardb.h
+++ b/include/configs/ls2080ardb.h
@@ -375,7 +375,7 @@ unsigned long get_board_sys_clk(void);
"fdt_high=0xa000\0" \
"initrd_high=0x\0"  \
"fdt_addr=0x64f0\0" \
-   "kernel_addr=0x6500\0"  \
+   "kernel_addr=0x58100\0" \
"kernel_start=0x100\0"  \
"kernelheader_start=0x80\0" \
"scriptaddr=0x8000\0"   \
@@ -445,8 +445,8 @@ unsigned long get_board_sys_clk(void);
"&& esbc_validate 0x2078; " \
"env exists mcinitcmd && "  \
"fsl_mc lazyapply dpl 0x20d0; " \
-   "run distro_bootcmd;env exists secureboot " \
-   " && esbc_halt;run qspi_bootcmd; "
+   "run distro_bootcmd;run qspi_bootcmd; " \
+   "env exists secureboot && esbc_halt;"
 #elif defined(CONFIG_SD_BOOT)
 /* Try to boot an on-SD kernel first, then do normal distro boot */
 #define CONFIG_BOOTCOMMAND \
@@ -456,16 +456,16 @@ unsigned long get_board_sys_clk(void);
"env exists mcinitcmd && run mcinitcmd "\
"&& mmc read 0x8800 0x6800 0x800 "  \
"&& fsl_mc lazyapply dpl 0x8800; "  \
-   "run distro_bootcmd;env exists secureboot " \
-   "&& esbc_halt;run sd_bootcmd;"
+   "run distro_bootcmd;run sd_bootcmd; "   \
+   "env exists secureboot && esbc_halt;"
 #else
 /* Try to boot an on-NOR kernel first, then do normal distro boot */
 #define CONFIG_BOOTCOMMAND \
"env exists mcinitcmd && env exists secureboot "\
"&& esbc_validate 0x58078; env exists mcinitcmd "\
"&& fsl_mc lazyapply dpl 0x580d0;"  \
-   "run distro_bootcmd; env exists secureboot "\
-   "&& esbc_halt; run nor_bootcmd;"
+   "run distro_bootcmd;run nor_bootcmd; "  \
+   "env exists secureboot && esbc_halt;"
 #endif
 
 /* MAC/PHY configuration */
-- 
2.7.4

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


Re: [U-Boot] [PATCH 3/3] spi: cadence_qspi_apb: Make flash writes 32 bit aligned

2018-01-08 Thread Goldschmidt Simon
On Mon, 08/01/2018 12:18, Vignesh R wrote:
> Make flash writes 32 bit aligned by using bounce buffers to deal with non 32 
> bit
> aligned buffers. Allocate a 512 byte bounce buffer (max known page size
> currently) for this case.

Looking at drivers/mtd/spi/sf_dataflash.c, I see at least one chip
with 1024 byte page size (at45db642d).
This should probably be a constant somewhere, or at least be checked
at runtime, see below.

> This is required because as per TI K2G TRM[1], the external master is only
> permitted to issue 32-bit data interface writes until the last word of an 
> indirect
> transfer. Otherwise indirect writes is known to fail sometimes.
> 
> [1] http://www.ti.com/lit/ug/spruhy8g/spruhy8g.pdf
> 
> Signed-off-by: Vignesh R 
> ---
>  drivers/spi/cadence_qspi.c | 13 -
>  drivers/spi/cadence_qspi.h |  1 +
>  drivers/spi/cadence_qspi_apb.c | 10 +-
>  3 files changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c index
> 991a7160bdb8..49c9b477e678 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -158,6 +158,10 @@ static int cadence_spi_probe(struct udevice *bus)
> 
>   priv->regbase = plat->regbase;
>   priv->ahbbase = plat->ahbbase;
> + /* Bounce buf to handle unaligned writes. 512B is max pagesize */
> + priv->bounce_buf = malloc(512);

This should probably be a named constant.

> + if (!priv->bounce_buf)
> + return -ENOMEM;
> 
>   if (!priv->qspi_is_init) {
>   cadence_qspi_apb_controller_init(plat);
> @@ -259,8 +263,15 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned
> int bitlen,
>   err = cadence_qspi_apb_indirect_write_setup
>   (plat, priv->cmd_len, cmd_buf);
>   if (!err) {
> + const u8 *txbuf = dout;
> +
> + if ((uintptr_t)txbuf % 4) {
> + memcpy(priv->bounce_buf, dout,
> +data_bytes);

Without checking the size of the buffer allocated for bounce_buf here,
you risk a buffer overflow for chips with larger page size.

> + txbuf = priv->bounce_buf;
> + }
>   err = cadence_qspi_apb_indirect_write_execute
> - (plat, data_bytes, dout);
> + (plat, data_bytes, txbuf);
>   }
>   break;
>   default:
> diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h index
> 83154210bd95..c97419af3de3 100644
> --- a/drivers/spi/cadence_qspi.h
> +++ b/drivers/spi/cadence_qspi.h
> @@ -43,6 +43,7 @@ struct cadence_spi_priv {
>   unsigned intqspi_calibrated_hz;
>   unsigned intqspi_calibrated_cs;
>   unsigned intprevious_hz;
> + void*bounce_buf;
>  };
> 
>  /* Functions call declaration */
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index fa8af33ae19b..fd3ece4cb129 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -727,11 +727,11 @@ int cadence_qspi_apb_indirect_write_execute(struct
> cadence_spi_platdata *plat,
> 
>   while (remaining > 0) {
>   write_bytes = remaining > page_size ? page_size : remaining;
> - /* Handle non-4-byte aligned access to avoid data abort. */
> - if (((uintptr_t)txbuf % 4) || (write_bytes % 4))
> - writesb(plat->ahbbase, txbuf, write_bytes);
> - else
> - writesl(plat->ahbbase, txbuf, write_bytes >> 2);
> + writesl(plat->ahbbase, txbuf, write_bytes >> 2);
> + if (write_bytes % 4)
> + writesb(plat->ahbbase,
> + txbuf + rounddown(write_bytes, 4),
> + write_bytes % 4);
> 
>   ret = wait_for_bit("QSPI", plat->regbase +
> CQSPI_REG_SDRAMLEVEL,
>  CQSPI_REG_SDRAMLEVEL_WR_MASK <<
> --
> 2.15.1

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


[U-Boot] [PATCH v2] arm64: ls1012ardb: Add distro secure boot support

2018-01-08 Thread Sumit Garg
From: Vinitha Pillai-B57223 

Enable validation of boot.scr script prior to its execution dependent
on "secureboot" flag in environment. Enable fall back option to
qspi boot in case of secure boot.

Signed-off-by: Sumit Garg 
Signed-off-by: Vinitha Pillai 
---

Changes in v2:
Rebased to top of master

 configs/ls1012ardb_qspi_SECURE_BOOT_defconfig | 14 +++---
 include/configs/ls1012ardb.h  | 20 ++--
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig 
b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
index b6930be..2d5d9ad 100644
--- a/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
+++ b/configs/ls1012ardb_qspi_SECURE_BOOT_defconfig
@@ -2,7 +2,9 @@ CONFIG_ARM=y
 CONFIG_TARGET_LS1012ARDB=y
 CONFIG_SECURE_BOOT=y
 CONFIG_FSL_LS_PPA=y
+CONFIG_QSPI_AHB_INIT=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-rdb"
+CONFIG_DISTRO_DEFAULTS=y
 # CONFIG_SYS_MALLOC_F is not set
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
@@ -12,7 +14,7 @@ CONFIG_QSPI_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 
earlycon=uart8250,mmio,0x21c0500 quiet lpj=25"
-CONFIG_HUSH_PARSER=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_CMD_GREPENV=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
@@ -20,16 +22,13 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
+# CONFIG_BLK is not set
+CONFIG_DM_MMC=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
@@ -42,6 +41,7 @@ CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
index ab139b0..d161bb8 100644
--- a/include/configs/ls1012ardb.h
+++ b/include/configs/ls1012ardb.h
@@ -72,16 +72,20 @@
"initrd_high=0x\0"  \
"fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
+   "kernelheader_addr=0x80\0"  \
"scriptaddr=0x8000\0"   \
+   "scripthdraddr=0x8008\0"\
"fdtheader_addr_r=0x8010\0" \
"kernelheader_addr_r=0x8020\0"  \
"kernel_addr_r=0x8100\0"\
"fdt_addr_r=0x9000\0"   \
"load_addr=0xa000\0"\
"kernel_size=0x280\0"   \
+   "kernelheader_size=0x4\0"   \
"console=ttyS0,115200\0"\
BOOTENV \
"boot_scripts=ls1012ardb_boot.scr\0"\
+   "boot_script_hdr=hdr_ls1012ardb_bs.out\0"   \
"scan_dev_for_boot_part="   \
 "part list ${devtype} ${devnum} devplist; "\
 "env exists devplist || setenv devplist 1; "   \
@@ -99,15 +103,27 @@
"run scan_dev_for_scripts; "  \
"done;"   \
"\0"  \
+   "boot_a_script="  \
+   "load ${devtype} ${devnum}:${distro_bootpart} "  \
+   "${scriptaddr} ${prefix}${script}; "\
+   "env exists secureboot && load ${devtype} " \
+   "${devnum}:${distro_bootpart} " \
+   "${scripthdraddr} ${prefix}${boot_script_hdr} " \
+   "&& esbc_validate ${scripthdraddr};"\
+   "source ${scriptaddr}\0"  \
"installer=load mmc 0:2 $load_addr "\
   "/flex_installer_arm64.itb; "\
   "bootm $load_addr#$board\0"  \
"qspi_bootcmd=echo Trying load from qspi..;"\
"sf probe && sf read $load_addr "   \
-   "$kernel_addr $kernel_size && bootm $load_addr#$board\0"
+   "$kernel_addr $kernel_size; env exists secureboot " \
+   "&& sf read $kernelheader_addr_r $kernelheader_addr "   \
+   "$kernelheader_size && esbc_validate ${kernelheader_addr_r}; " \
+   "bootm $load_addr#$board\0"
 
 #undef CONFIG_BOOTCOMMAND
-#define CONFIG_BOOTCOMMAND "run distro_bootcmd;run qspi_bootcmd"
+#define CONFIG_BOOTCOMMAND "run distro_bootcmd; run qspi_bootcmd; "\
+  "env exists secureboot && esbc_halt;"
 
 #include 
 
-- 
1.9.1

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


Re: [U-Boot] [PATCH 0/3] cadence-quadspi: Fix issues with non 32bit aligned accesses

2018-01-08 Thread Goldschmidt Simon
On 08/01/2018 12:18m Vignesh R wrote:
> This series reverts use of bounce_buf.c for non-DMA related alignment 
> restriction
> and replaces it with local bounce buffer to handle problems with non 32 bit 
> aligned
> writes on TI platforms.
> Based on top of Jason's series:
> https://patchwork.ozlabs.org/cover/856431/
> 
> Tested on K2G EVM.
> 
> Goldschmidt Simon (1):
>   Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction
> when possible"
> 
> Vignesh R (2):
>   Revert "spi: cadence_qspi_apb: Use 32 bit indirect write transaction
> when possible"
>   spi: cadence_qspi_apb: Make flash writes 32 bit aligned
> 
>  drivers/spi/cadence_qspi.c   | 13 -
>  drivers/spi/cadence_qspi.h   |  1 +
>  drivers/spi/cadence_qspi_apb.c   | 42 
> +---
>  include/configs/k2g_evm.h|  1 -
>  include/configs/socfpga_common.h |  1 -
>  include/configs/stv0991.h|  1 -
>  6 files changed, 22 insertions(+), 37 deletions(-)

For this whole series:
Tested on a socfpga-cyclonev board (with a Micron N25QL256A):
Tested-by: Simon Goldschmidt 

After applying this series on top of Jason's v5, qspi on the socfpga
is finally working without local fixes!

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


Re: [U-Boot] [PATCH v2 01/12] riscv: cpu: Add nx25 to support RISC-V

2018-01-08 Thread 陳建志
Hi Tom

How about the Andes NX25 cpu for RISC-V arch patchsets [PATCH v2 x/12]
reviewing status ?
Is everything ok ?

Rick

2017-12-26 13:55 GMT+08:00 Andes :
> From: Rick Chen 
>
> Add Andes nx25 cpu core (called AndesStar V5) to support RISC-V arch
>
> Verifications:
> 1. startup and relocation ok.
> 2. boot from rom or ram both ok.
> 2. timer driver ok.
> 3. uart driver ok
> 4. mmc driver ok
> 5. spi driver ok.
> 6. 32/64 bit both ok.
>
> Detail verification message please see doc/README.ae250.
>
> Signed-off-by: Rick Chen 
> Signed-off-by: Rick Chen 
> Signed-off-by: Greentime Hu 
> Cc: Padmarao Begari 
> ---
>  arch/riscv/cpu/nx25/Makefile   |  10 ++
>  arch/riscv/cpu/nx25/cpu.c  |  33 +
>  arch/riscv/cpu/nx25/start.S| 291 
> +
>  arch/riscv/cpu/nx25/u-boot.lds |  69 ++
>  4 files changed, 403 insertions(+)
>  create mode 100644 arch/riscv/cpu/nx25/Makefile
>  create mode 100644 arch/riscv/cpu/nx25/cpu.c
>  create mode 100644 arch/riscv/cpu/nx25/start.S
>  create mode 100644 arch/riscv/cpu/nx25/u-boot.lds
>
> diff --git a/arch/riscv/cpu/nx25/Makefile b/arch/riscv/cpu/nx25/Makefile
> new file mode 100644
> index 000..5fcf100
> --- /dev/null
> +++ b/arch/riscv/cpu/nx25/Makefile
> @@ -0,0 +1,10 @@
> +#
> +# Copyright (C) 2017 Andes Technology Corporation
> +# Rick Chen, Andes Technology Corporation 
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +extra-y= start.o
> +
> +obj-y  := cpu.o
> diff --git a/arch/riscv/cpu/nx25/cpu.c b/arch/riscv/cpu/nx25/cpu.c
> new file mode 100644
> index 000..5478f4f
> --- /dev/null
> +++ b/arch/riscv/cpu/nx25/cpu.c
> @@ -0,0 +1,33 @@
> +/*
> + * Copyright (C) 2017 Andes Technology Corporation
> + * Rick Chen, Andes Technology Corporation 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +/* CPU specific code */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * cleanup_before_linux() is called just before we call linux
> + * it prepares the processor for linux
> + *
> + * we disable interrupt and caches.
> + */
> +int cleanup_before_linux(void)
> +{
> +   disable_interrupts();
> +
> +   /* turn off I/D-cache */
> +
> +   return 0;
> +}
> +
> +int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> +   disable_interrupts();
> +   panic("nx25-ae250 wdt not support yet.\n");
> +}
> diff --git a/arch/riscv/cpu/nx25/start.S b/arch/riscv/cpu/nx25/start.S
> new file mode 100644
> index 000..6a07663
> --- /dev/null
> +++ b/arch/riscv/cpu/nx25/start.S
> @@ -0,0 +1,291 @@
> +/*
> + * Startup Code for RISC-V Core
> + *
> + * Copyright (c) 2017 Microsemi Corporation.
> + * Copyright (c) 2017 Padmarao Begari 
> + *
> + * Copyright (C) 2017 Andes Technology Corporation
> + * Rick Chen, Andes Technology Corporation 
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifdef CONFIG_32BIT
> +#define LREG   lw
> +#define SREG   sw
> +#define REGBYTES   4
> +#define RELOC_TYPE R_RISCV_32
> +#define SYM_INDEX  0x8
> +#define SYM_SIZE   0x10
> +#else
> +#define LREG   ld
> +#define SREG   sd
> +#define REGBYTES   8
> +#define RELOC_TYPE R_RISCV_64
> +#define SYM_INDEX  0x20
> +#define SYM_SIZE   0x18
> +#endif
> +
> +.section  .text
> +.globl _start
> +_start:
> +   j handle_reset
> +
> +nmi_vector:
> +   j nmi_vector
> +
> +trap_vector:
> +   j trap_entry
> +
> +.global trap_entry
> +handle_reset:
> +   la t0, trap_entry
> +   csrw mtvec, t0
> +   csrwi mstatus, 0
> +   csrwi mie, 0
> +
> +/*
> + * Do CPU critical regs init only at reboot,
> + * not when booting from ram
> + */
> +#ifdef CONFIG_INIT_CRITICAL
> +   jal cpu_init_crit   /* Do CPU critical regs init */
> +#endif
> +
> +/*
> + * Set stackpointer in internal/ex RAM to call board_init_f
> + */
> +call_board_init_f:
> +   li  t0, -16
> +   li  t1, CONFIG_SYS_INIT_SP_ADDR
> +   and sp, t1, t0  /* force 16 byte alignment */
> +
> +#ifdef CONFIG_DEBUG_UART
> +   jal debug_uart_init
> +#endif
> +
> +call_board_init_f_0:
> +   mv  a0, sp
> +   jal board_init_f_alloc_reserve
> +   mv  sp, a0
> +   jal board_init_f_init_reserve
> +
> +   mv  a0, zero/* a0 <-- boot_flags = 0 */
> +   la t5, board_init_f
> +   jr t5   /* jump to board_init_f() */
> +
> +/*
> + * void relocate_code (addr_sp, gd, addr_moni)
> + *
> + * This "function" does not return, instead it continues in RAM
> + * after relocating the monitor 

Re: [U-Boot] [PATCH v6 0/2] Generic firmware loader

2018-01-08 Thread Chee, Tien Fong
On Isn, 2018-01-08 at 09:07 +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Wed, 3 Jan 2018 08:46:09 + Chee, Tien Fong wrote:
> > 
> > On Rab, 2017-12-27 at 13:04 +0800, tien.fong.c...@intel.com wrote:
> > Hi Lothar Waßmann,
> > > 
> > > From: Tien Fong Chee 
> > > 
> > > This patchset contains generic firmware loader which is very
> > > close to
> > > Linux
> > > firmware loader but for U-Boot framework. Generic firmware loader
> > > can
> > > be used
> > > load whatever into target location, and then consumer driver
> > > would
> > > use it to
> > > program whatever, ie. the FPGA. This version mainly resolved
> > > comments
> > > from
> > > Lothar Waßmann in [v5].
> > > 
> > Are you OK with the patches?
> > 
> Sorry for the delay. I have been on vacation until now.
> The patch series Looks good to me now.
> 
> Reviewed-By: Lothar Waßmann 
> 
Great, thanks for helping to review the codes.
> 
> Lothar Waßmann
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] u-boot/next and HS MMC patches

2018-01-08 Thread Jaehoon Chung
Hi,

On 01/09/2018 10:32 AM, Tom Rini wrote:
> Hey everyone,
> 
> I pulled the previous MMC PR into u-boot/next, so that we wouldn't have
> the current round of MMC improvements get lost.  Since then, there's
> been at least one update to the series to improve the binary size
> growth, and Masahiro has posted a round of fixes as well.  Can I please
> get a PR this week, against master, with everything relevant in it, so
> that we can move forward on additional improvements here?  Otherwise
> I'll take a look at what I need to do with what's in next currently.
> Thanks!

Sure, this week, i will send PR with other patches..
I will also send the patches about mmc. thanks.

Best Regards,
Jaehoon Chung

> 

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


Re: [U-Boot] [PATCH 04/07] fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE

2018-01-08 Thread Peter Robinson
On Tue, Jan 9, 2018 at 3:37 AM, Peter Robinson  wrote:
> On Fri, Jan 5, 2018 at 10:29 AM, Jorge Ramirez-Ortiz
>  wrote:
>> From: Rob Clark 
>>
>> Similar to CONFIG_OF_BOARD, but in this case the fdt is still built by
>> u-boot build.  This allows the board to patch the fdt, etc.
>>
>> In the specific case of dragonboard 410c, we pass the u-boot generated
>> fdt to the previous stage of bootloader (by embedding it in the
>> u-boot.img that is loaded by lk/aboot), which patches the fdt and passes
>> it back to u-boot.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  include/fdtdec.h |  3 ++-
>>  lib/fdtdec.c | 35 +++
>>  2 files changed, 25 insertions(+), 13 deletions(-)
>>
>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>> index 0fb3e07..4afb9ac 100644
>> --- a/include/fdtdec.h
>> +++ b/include/fdtdec.h
>> @@ -990,7 +990,8 @@ int fdtdec_setup(void);
>>
>>  /**
>>   * Board-specific FDT initialization. Returns the address to a device tree 
>> blob.
>> - * Called when CONFIG_OF_BOARD is defined.
>> + * Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is 
>> defined
>> + * and the board implements it.
>>   */
>>  void *board_fdt_blob_setup(void);
>>
>> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>> index 30ec6b9..cc3dfd6 100644
>> --- a/lib/fdtdec.c
>> +++ b/lib/fdtdec.c
>> @@ -1272,6 +1272,28 @@ static int uncompress_blob(const void *src, ulong 
>> sz_src, void **dstp)
>>  # endif
>>  #endif
>>
>> +#if CONFIG_IS_ENABLED(OF_SEPARATE)
>> +/*
>> + * For CONFIG_OF_SEPARATE, the board may optionally implement this to
>> + * provide and/or fixup the fdt.
>> + */
>> +__weak void *board_fdt_blob_setup(void)
>> +{
>> +   void *fdt_blob = NULL;
>> +#ifdef CONFIG_SPL_BUILD
>> +   /* FDT is at end of BSS unless it is in a different memory region */
>> +   if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
>> +   fdt_blob = (ulong *)&_image_binary_end;
>> +   else
>> +   fdt_blob = (ulong *)&__bss_end;
>> +#else
>> +   /* FDT is at end of image */
>> +   fdt_blob = (ulong *)&_end;
>> +#endif
>> +   return fdt_blob;
>> +}
>> +#endif
>
> For some reason now with 2018.01 I'm getting the following error when
> building on Fedora 28
>
> /builddir/build/BUILD/u-boot-2018.01/lib/fdtdec.c:1312: undefined
> reference to `board_fdt_blob_setup'
> /builddir/build/BUILD/u-boot-2018.01/lib/fdtdec.c:1312:(.text.fdtdec_setup+0x10):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `board_fdt_blob_setup'

The full output is available here:

The relevant bit for the firefly-3399 is:

  gcc -Wp,-MD,spl/drivers/sysreset/.sysreset_rockchip.o.d  -nostdinc
-isystem /usr/lib/gcc/aarch64-redhat-linux/7/include -Iinclude
-I/builddir/build/BUILD/u-boot-2018.01/include
-I/builddir/build/BUILD/u-boot-2018.01/arch/arm/include -include
/builddir/build/BUILD/u-boot-2018.01/include/linux/kconfig.h
-I/builddir/build/BUILD/u-boot-2018.01/spl/drivers/sysreset
-Ispl/drivers/sysreset -D__KERNEL__ -D__UBOOT__ -DCONFIG_SPL_BUILD
-Wall -Wstrict-prototypes -Wno-format-security -fno-builtin
-ffreestanding -fshort-wchar -Os -fno-stack-protector
-fno-delete-null-pointer-checks -g -fstack-usage
-Wno-format-nonliteral -Werror=date-time -ffunction-sections
-fdata-sections -D__ARM__ -mstrict-align -ffunction-sections
-fdata-sections -fno-common -ffixed-r9 -fno-common -ffixed-x18 -pipe
-march=armv8-a -D__LINUX_ARM_ARCH__=8
-I/builddir/build/BUILD/u-boot-2018.01/arch/arm/mach-rockchip/include
  -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(sysreset_rockchip)"
-D"KBUILD_MODNAME=KBUILD_STR(sysreset_rockchip)" -c -o
spl/drivers/sysreset/sysreset_rockchip.o
/builddir/build/BUILD/u-boot-2018.01/drivers/sysreset/sysreset_rockchip.c
   ld.bfd -r -o spl/drivers/sysreset/built-in.o
spl/drivers/sysreset/sysreset-uclass.o
spl/drivers/sysreset/sysreset_rockchip.o
   ld.bfd -r -o spl/drivers/ram/rockchip/built-in.o
spl/drivers/ram/rockchip/sdram_rk3399.o
   ld.bfd -r -o spl/drivers/ram/built-in.o
spl/drivers/ram/ram-uclass.o spl/drivers/ram/rockchip/built-in.o
   ld.bfd -r -o spl/drivers/serial/built-in.o
spl/drivers/serial/serial-uclass.o spl/drivers/serial/ns16550.o
   ld.bfd -r -o spl/drivers/built-in.o spl/drivers/clk/built-in.o
spl/drivers/core/built-in.o spl/drivers/misc/built-in.o
spl/drivers/sysreset/built-in.o spl/drivers/firmware/built-in.o
spl/drivers/mmc/built-in.o spl/drivers/pinctrl/built-in.o
spl/drivers/ram/built-in.o spl/drivers/serial/built-in.o
spl/drivers/block/built-in.o
  (cd spl && ld.bfd   -T u-boot-spl.lds  --gc-sections -Bstatic
--gc-sections  --no-dynamic-linker -Ttext 0xff8c2000
arch/arm/cpu/armv8/start.o --start-group
arch/arm/mach-rockchip/built-in.o arch/arm/cpu/armv8/built-in.o
arch/arm/cpu/built-in.o arch/arm/lib/built-in.o
board/rockchip/evb_rk3399/built-in.o common/spl/built-in.o
common/init/built-in.o 

Re: [U-Boot] [PATCH 04/07] fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE

2018-01-08 Thread Peter Robinson
On Fri, Jan 5, 2018 at 10:29 AM, Jorge Ramirez-Ortiz
 wrote:
> From: Rob Clark 
>
> Similar to CONFIG_OF_BOARD, but in this case the fdt is still built by
> u-boot build.  This allows the board to patch the fdt, etc.
>
> In the specific case of dragonboard 410c, we pass the u-boot generated
> fdt to the previous stage of bootloader (by embedding it in the
> u-boot.img that is loaded by lk/aboot), which patches the fdt and passes
> it back to u-boot.
>
> Signed-off-by: Rob Clark 
> ---
>  include/fdtdec.h |  3 ++-
>  lib/fdtdec.c | 35 +++
>  2 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 0fb3e07..4afb9ac 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -990,7 +990,8 @@ int fdtdec_setup(void);
>
>  /**
>   * Board-specific FDT initialization. Returns the address to a device tree 
> blob.
> - * Called when CONFIG_OF_BOARD is defined.
> + * Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is 
> defined
> + * and the board implements it.
>   */
>  void *board_fdt_blob_setup(void);
>
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 30ec6b9..cc3dfd6 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -1272,6 +1272,28 @@ static int uncompress_blob(const void *src, ulong 
> sz_src, void **dstp)
>  # endif
>  #endif
>
> +#if CONFIG_IS_ENABLED(OF_SEPARATE)
> +/*
> + * For CONFIG_OF_SEPARATE, the board may optionally implement this to
> + * provide and/or fixup the fdt.
> + */
> +__weak void *board_fdt_blob_setup(void)
> +{
> +   void *fdt_blob = NULL;
> +#ifdef CONFIG_SPL_BUILD
> +   /* FDT is at end of BSS unless it is in a different memory region */
> +   if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
> +   fdt_blob = (ulong *)&_image_binary_end;
> +   else
> +   fdt_blob = (ulong *)&__bss_end;
> +#else
> +   /* FDT is at end of image */
> +   fdt_blob = (ulong *)&_end;
> +#endif
> +   return fdt_blob;
> +}
> +#endif

For some reason now with 2018.01 I'm getting the following error when
building on Fedora 28

/builddir/build/BUILD/u-boot-2018.01/lib/fdtdec.c:1312: undefined
reference to `board_fdt_blob_setup'
/builddir/build/BUILD/u-boot-2018.01/lib/fdtdec.c:1312:(.text.fdtdec_setup+0x10):
relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`board_fdt_blob_setup'

I'm going to have a further look into it from my side (could be tweaks
to compile flags etc) but just FYI.

Peter

>  int fdtdec_setup(void)
>  {
>  #if CONFIG_IS_ENABLED(OF_CONTROL)
> @@ -1285,18 +1307,7 @@ int fdtdec_setup(void)
>  #  else
> gd->fdt_blob = __dtb_dt_begin;
>  #  endif
> -# elif defined CONFIG_OF_SEPARATE
> -#  ifdef CONFIG_SPL_BUILD
> -   /* FDT is at end of BSS unless it is in a different memory region */
> -   if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
> -   gd->fdt_blob = (ulong *)&_image_binary_end;
> -   else
> -   gd->fdt_blob = (ulong *)&__bss_end;
> -#  else
> -   /* FDT is at end of image */
> -   gd->fdt_blob = (ulong *)&_end;
> -#  endif
> -# elif defined(CONFIG_OF_BOARD)
> +# elif defined(CONFIG_OF_BOARD) || defined (CONFIG_OF_SEPARATE)
> /* Allow the board to override the fdt address. */
> gd->fdt_blob = board_fdt_blob_setup();
>  # elif defined(CONFIG_OF_HOSTFILE)
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 05/05] db820c: stop autoboot when vol- pressed

2018-01-08 Thread Peter Robinson
On Fri, Jan 5, 2018 at 10:29 AM, Jorge Ramirez-Ortiz
 wrote:
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  arch/arm/dts/dragonboard820c-uboot.dtsi  | 19 
>  board/qualcomm/dragonboard820c/dragonboard820c.c | 37 
> +++-
>  include/configs/dragonboard820c.h|  2 ++
>  3 files changed, 57 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/dragonboard820c-uboot.dtsi
>
> diff --git a/arch/arm/dts/dragonboard820c-uboot.dtsi 
> b/arch/arm/dts/dragonboard820c-uboot.dtsi
> new file mode 100644
> index 000..167e72c
> --- /dev/null
> +++ b/arch/arm/dts/dragonboard820c-uboot.dtsi
> @@ -0,0 +1,19 @@
> +/*
> + * U-Boot addition to handle Dragonboard 820c pins
> + *
> + * (C) Copyright 2017 Jorge Ramirez-Ortiz 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +_pon {
> +   key_vol_down {
> +   gpios = <_pon 1 0>;
> +   label = "key_vol_down";
> +   };
> +
> +   key_power {
> +   gpios = <_pon 0 0>;
> +   label = "key_power";
> +   };
> +};
> diff --git a/board/qualcomm/dragonboard820c/dragonboard820c.c 
> b/board/qualcomm/dragonboard820c/dragonboard820c.c
> index 8f40ba4..d4a20d2 100644
> --- a/board/qualcomm/dragonboard820c/dragonboard820c.c
> +++ b/board/qualcomm/dragonboard820c/dragonboard820c.c
> @@ -1,7 +1,7 @@
>  /*
>   * Board init file for Dragonboard 820C
>   *
> - * (C) Copyright 2017 Jorge Ramirez-Ortiz 
> + * (C) Copyright 2017 Jorge Ramirez-Ortiz 

For some reason this bit here causes issue for me either via patch or
"git am" so maybe just merge it with the original commit, no idea why
but not bothered either way more just FYI.

>   * SPDX-License-Identifier:GPL-2.0+
>   */
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -126,3 +127,37 @@ void reset_cpu(ulong addr)
>  {
> psci_system_reset();
>  }
> +
> +/* Check for vol- button - if pressed - stop autoboot */
> +int misc_init_r(void)
> +{
> +   struct udevice *pon;
> +   struct gpio_desc resin;
> +   int node, ret;
> +
> +   ret = uclass_get_device_by_name(UCLASS_GPIO, "pm8994_pon@800", );
> +   if (ret < 0) {
> +   printf("Failed to find PMIC pon node. Check device tree\n");
> +   return 0;
> +   }
> +
> +   node = fdt_subnode_offset(gd->fdt_blob, dev_of_offset(pon),
> + "key_vol_down");
> +   if (node < 0) {
> +   printf("Failed to find key_vol_down node. Check device 
> tree\n");
> +   return 0;
> +   }
> +
> +   if (gpio_request_by_name_nodev(offset_to_ofnode(node), "gpios", 0,
> +  , 0)) {
> +   printf("Failed to request key_vol_down button.\n");
> +   return 0;
> +   }
> +
> +   if (dm_gpio_get_value()) {
> +   env_set("bootdelay", "-1");
> +   printf("Power button pressed - dropping to console.\n");
> +   }
> +
> +   return 0;
> +}
> diff --git a/include/configs/dragonboard820c.h 
> b/include/configs/dragonboard820c.h
> index 76bcaf8..e0c3c0c 100644
> --- a/include/configs/dragonboard820c.h
> +++ b/include/configs/dragonboard820c.h
> @@ -12,6 +12,8 @@
>  #include 
>  #include 
>
> +#define CONFIG_MISC_INIT_R /* To stop autoboot */
> +
>  /* Physical Memory Map */
>  #define CONFIG_NR_DRAM_BANKS   2
>
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RFE : CONFIG_OF_LIBFDT_OVERLAY=y in configs/orangepi_one_defconfig

2018-01-08 Thread Peter Robinson
On Mon, Jan 8, 2018 at 7:01 AM, Ken Harris  wrote:
> Can you enable the "fdt apply" command on the "Orange Pi One" u-boot :

I think most AllWinner boards would likely want/need this
functionality in one form or another (maybe tablets/laptops based on
AllWinner are the exception here) so you might want to see how the
maintainers want to handle it more as a default than enabling it on
each individual device.

> diff --git a/configs/orangepi_one_defconfig b/configs/orangepi_one_defconfig
> index 36feab204c..edc6f549dc 100644
> --- a/configs/orangepi_one_defconfig
> +++ b/configs/orangepi_one_defconfig
> @@ -15,3 +15,6 @@ CONFIG_SPL=y
>  CONFIG_SUN8I_EMAC=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
> +CONFIG_OF_LIBFDT=y
> +CONFIG_OF_LIBFDT_OVERLAY=y
> +
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1 2/2] x86: tangier: Add Bluetooth to ACPI table

2018-01-08 Thread Bin Meng
On Mon, Jan 8, 2018 at 12:51 PM, Simon Glass  wrote:
> On 4 January 2018 at 09:40, Andy Shevchenko
>  wrote:
>> As defined on reference board followed by Intel Edison a Bluetooth
>> device is attached to HSU0, i.e. PCI :04.1.
>>
>> Describe it in ACPI accordingly.
>>
>> Note, we use BCM2E95 ID here as one most suitable for such device based
>> on the description in commit message of commit 89ab37b489d1
>> ("Bluetooth: hci_bcm: Add support for BCM2E95 and BCM2E96")
>> in the Linux kernel source tree.
>>
>> Signed-off-by: Andy Shevchenko 
>> ---
>>  .../include/asm/arch-tangier/acpi/southcluster.asl | 51 
>> ++
>>  1 file changed, 51 insertions(+)
>
> Reviewed-by: Simon Glass 

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 v1 1/2] x86: tangier: Use actual GPIO hardware numbers

2018-01-08 Thread Bin Meng
On Mon, Jan 8, 2018 at 12:51 PM, Simon Glass  wrote:
> On 4 January 2018 at 09:40, Andy Shevchenko
>  wrote:
>> The recent commit 03c4749dd6c7
>>   ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation")
>> in the Linux kernel reveals the issue we have in ACPI tables here,
>> i.e. we must use hardware numbers for GPIO resources and,
>> taking into consideration that GPIO and pin control are *different* IPs
>> on Intel Tangier, we need to supply numbers properly.
>>
>> Besides that, it improves user experience since the official documentation
>> for Intel Edison board is referring to GPIO hardware numbering scheme.
>>
>> Signed-off-by: Andy Shevchenko 
>> ---
>>
>> Bin, this is kinda urgent fix. I wouldn't like to have a release with
>> wrong numbering scheme, although there is none users yet, only couple
>> amateurs that are experimenting with the code.
>
> Reviewed-by: Simon Glass 

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


Re: [U-Boot] [PATCH v2] x86: Move commands from under arch/x86 to cmd/x86/

2018-01-08 Thread Bin Meng
On Mon, Jan 8, 2018 at 11:08 AM, Bin Meng  wrote:
> On Wed, Jan 3, 2018 at 9:54 PM, Tom Rini  wrote:
>> We only need to compile and link these files when building for full
>> U-Boot.  Move them to under cmd/x86/ to make sure they aren't linked in
>> and undiscarded due to u_boot_list_2_cmd_* being included).
>>
>> Cc: Bin Meng 
>> Signed-off-by: Tom Rini 
>> ---
>> Changes in v2:
>> - Format patch with -M
>> - Drop 'cmd_' from the new file name (and checked file content for now
>>   erroneous cmd in comments, none found).
>>
>>  arch/x86/lib/Makefile   | 1 -
>>  arch/x86/lib/fsp/Makefile   | 1 -
>>  cmd/Makefile| 2 ++
>>  cmd/x86/Makefile| 6 ++
>>  arch/x86/lib/fsp/cmd_fsp.c => cmd/x86/fsp.c | 0
>>  arch/x86/lib/cmd_mtrr.c => cmd/x86/mtrr.c   | 0
>>  6 files changed, 8 insertions(+), 2 deletions(-)
>>  create mode 100644 cmd/x86/Makefile
>>  rename arch/x86/lib/fsp/cmd_fsp.c => cmd/x86/fsp.c (100%)
>>  rename arch/x86/lib/cmd_mtrr.c => cmd/x86/mtrr.c (100%)
>>
>
> Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH 1/1] configs: x86: allow to override CONFIG_BOOTCOMMAND

2018-01-08 Thread Bin Meng
On Mon, Jan 8, 2018 at 11:10 AM, Bin Meng  wrote:
> On Wed, Jan 3, 2018 at 11:23 PM, Heinrich Schuchardt  
> wrote:
>> Allow to override CONFIG_BOOTCOMMAND in .config.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  include/configs/x86-common.h | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>
> Reviewed-by: Bin Meng 

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


[U-Boot] u-boot/next and HS MMC patches

2018-01-08 Thread Tom Rini
Hey everyone,

I pulled the previous MMC PR into u-boot/next, so that we wouldn't have
the current round of MMC improvements get lost.  Since then, there's
been at least one update to the series to improve the binary size
growth, and Masahiro has posted a round of fixes as well.  Can I please
get a PR this week, against master, with everything relevant in it, so
that we can move forward on additional improvements here?  Otherwise
I'll take a look at what I need to do with what's in next currently.
Thanks!

-- 
Tom


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


[U-Boot] [ANN] U-Boot v2018.01 is released

2018-01-08 Thread Tom Rini
Hey all,

I've released v2018.01 and it's now live on git and FTP and ACD (along
with PGP sig file).

Again, We've had a good all-around release, and I like it.

One thing I want to bring up now is that we're going to start making
conversion (and lack there-of) of things over to using DM a bigger
problem and possible reason for feature removal.  While I plan to make
some build-time warning happen (Simon had a good idea on this), I'm also
raising it here.

Another thing I'm going to spell out here, is that I'm officially moving
the merge window from closing on Saturday, to closing on Monday.  In
practice, that's what it's been for me for a long time, but I'm going to
update the ReleaseCycle page to reflect this now too.  It will still
continue to close when I release -rc1, which is on that Monday.

The current schedule is that v2018.01-rc1 will be tagged on January
29th, with -rc2 on the 12th of February, -rc3 on the 26th, -rc4 on the
5th of March and the release on March 12th.  I plan to continue to and
be more strict post -rc1 than I have historically been and contain
-rc2/-rc3 to fixes only.

Thanks again everyone!

-- 
Tom


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


[U-Boot] [PATCH 2/2] ARM: Tegra: p2771-0000: use calculcate env var feature

2018-01-08 Thread Stephen Warren
From: Stephen Warren 

Request that all environment variables containing hard-coded address be
calculated at boot time instead.

Signed-off-by: Stephen Warren 
---
 include/configs/p2771-.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/configs/p2771-.h b/include/configs/p2771-.h
index 5de7ae8c502d..29940a63de0d 100644
--- a/include/configs/p2771-.h
+++ b/include/configs/p2771-.h
@@ -24,6 +24,26 @@
 
 /* PCI host support */
 
+#define BOARD_EXTRA_ENV_SETTINGS \
+   "calculated_vars=kernel_addr_r fdt_addr_r scriptaddr pxefile_addr_r " \
+   "ramdisk_addr_r\0" \
+   "kernel_addr_r_align=0020\0" \
+   "kernel_addr_r_offset=0008\0" \
+   "kernel_addr_r_size=0200\0" \
+   "kernel_addr_r_aliases=loadaddr\0" \
+   "fdt_addr_r_align=0020\0" \
+   "fdt_addr_r_offset=\0" \
+   "fdt_addr_r_size=0020\0" \
+   "scriptaddr_align=0020\0" \
+   "scriptaddr_offset=\0" \
+   "scriptaddr_size=0020\0" \
+   "pxefile_addr_r_align=0020\0" \
+   "pxefile_addr_r_offset=\0" \
+   "pxefile_addr_r_size=0020\0" \
+   "ramdisk_addr_r_align=0020\0" \
+   "ramdisk_addr_r_offset=\0" \
+   "ramdisk_addr_r_size=0200\0"
+
 #include "tegra-common-post.h"
 
 /* Crystal is 38.4MHz. clk_m runs at half that rate */
-- 
2.15.1

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


[U-Boot] [PATCH 1/2] ARM: Tegra186: calculate load addresses at boot

2018-01-08 Thread Stephen Warren
From: Stephen Warren 

In the presence of potentially fragemented memory, we cannot hard-code
addresses into environment variables such as kernel_addr_r. Instead, we
must calculate those addresses at run-time based on available memory
locations. Implement the code to perform such runtime calculation, based
on requirements described in environment variables, to allow the user
full control over the allocation.

Signed-off-by: Stephen Warren 
---
 arch/arm/mach-tegra/tegra186/nvtboot_board.c | 265 ++-
 1 file changed, 264 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/tegra186/nvtboot_board.c 
b/arch/arm/mach-tegra/tegra186/nvtboot_board.c
index b94eb424aaa2..8ecb45444349 100644
--- a/arch/arm/mach-tegra/tegra186/nvtboot_board.c
+++ b/arch/arm/mach-tegra/tegra186/nvtboot_board.c
@@ -1,16 +1,278 @@
 /*
- * Copyright (c) 2016, NVIDIA CORPORATION.
+ * Copyright (c) 2016-2018, NVIDIA CORPORATION.
  *
  * SPDX-License-Identifier: GPL-2.0+
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
 
 extern unsigned long nvtboot_boot_x0;
 
+/*
+ * The following few functions run late during the boot process and dynamically
+ * calculate the load address of various binaries. To keep track of multiple
+ * allocations, some writable list of RAM banks must be used. tegra_mem_map[]
+ * is used for this purpose to avoid making yet another copy of the list of RAM
+ * banks. This is safe because tegra_mem_map[] is only used once during very
+ * early boot to create U-Boot's page tables, long before this code runs. If
+ * this assumption becomes invalid later, we can just fix the code to copy the
+ * list of RAM banks into some private data structure before running.
+ */
+
+extern struct mm_region tegra_mem_map[];
+
+static char *gen_varname(const char *var, const char *ext)
+{
+   size_t len_var = strlen(var);
+   size_t len_ext = strlen(ext);
+   size_t len = len_var + len_ext + 1;
+   char *varext = malloc(len);
+
+   if (!varext)
+   return 0;
+   strcpy(varext, var);
+   strcpy(varext + len_var, ext);
+   return varext;
+}
+
+static void mark_ram_allocated(int bank, u64 allocated_start, u64 
allocated_end)
+{
+   u64 bank_start = tegra_mem_map[bank].virt;
+   u64 bank_size = tegra_mem_map[bank].size;
+   u64 bank_end = bank_start + bank_size;
+   bool keep_front = allocated_start != bank_start;
+   bool keep_tail = allocated_end != bank_end;
+
+   if (keep_front && keep_tail) {
+   /*
+* There are CONFIG_NR_DRAM_BANKS DRAM entries in the array,
+* starting at index 1 (index 0 is MMIO). So, we are at DRAM
+* entry "bank" not "bank - 1" as for a typical 0-base array.
+* The number of remaining DRAM entries is therefore
+* "CONFIG_NR_DRAM_BANKS - bank". We want to duplicate the
+* current entry and shift up the remaining entries, dropping
+* the last one. Thus, we must copy one fewer entry than the
+* number remaining.
+*/
+   memmove(_mem_map[bank + 1], _mem_map[bank],
+   CONFIG_NR_DRAM_BANKS - bank - 1);
+   tegra_mem_map[bank].size = allocated_start - bank_start;
+   bank++;
+   tegra_mem_map[bank].virt = allocated_end;
+   tegra_mem_map[bank].phys = allocated_end;
+   tegra_mem_map[bank].size = bank_end - allocated_end;
+   } else if (keep_front) {
+   tegra_mem_map[bank].size = allocated_start - bank_start;
+   } else if (keep_tail) {
+   tegra_mem_map[bank].virt = allocated_end;
+   tegra_mem_map[bank].phys = allocated_end;
+   tegra_mem_map[bank].size = bank_end - allocated_end;
+   } else {
+   /*
+* We could move all subsequent banks down in the array but
+* that's not necessary for subsequent allocations to work, so
+* we skip doing so.
+*/
+   tegra_mem_map[bank].size = 0;
+   }
+}
+
+static void reserve_ram(u64 start, u64 size)
+{
+   int bank;
+   u64 end = start + size;
+
+   for (bank = 1; bank <= CONFIG_NR_DRAM_BANKS; bank++) {
+   u64 bank_start = tegra_mem_map[bank].virt;
+   u64 bank_size = tegra_mem_map[bank].size;
+   u64 bank_end = bank_start + bank_size;
+
+   if (end <= bank_start || start > bank_end)
+   continue;
+   mark_ram_allocated(bank, start, end);
+   break;
+   }
+}
+
+static u64 alloc_ram(u64 size, u64 align, u64 offset)
+{
+   int bank;
+
+   for (bank = 1; bank <= CONFIG_NR_DRAM_BANKS; bank++) {
+   u64 bank_start = tegra_mem_map[bank].virt;
+   u64 bank_size = 

Re: [U-Boot] [PATCH v3 1/1] vsprintf.c: add EFI device path printing

2018-01-08 Thread Heinrich Schuchardt

On 01/08/2018 11:11 PM, Simon Glass wrote:

HI Heinrich,

On 8 January 2018 at 08:09, Heinrich Schuchardt  wrote:



On 01/08/2018 04:52 AM, Simon Glass wrote:


On 26 December 2017 at 03:07, Heinrich Schuchardt 
wrote:


For debugging efi_loader we need the capability to print EFI
device paths. With this patch we can write:

  debug("device path: %pD", dp);

A possible output would be

  device path: /MemoryMapped(0x0,0x3ff93a82,0x3ff93a82)

This enhancement is not available when building without EFI support
and neither in the SPL nor in the API example.

Cc: Wolfgang Denk 
Cc: Simon Glass 
Suggested-by: Rob Clark 
Signed-off-by: Heinrich Schuchardt 
---
I propose Alex picks up this patch for the EFI tree.

v3:
  Return -ENOMEM if out of memory.
  Avoid missing dependency error when building the SPL of the
  API example.
v2:
  Panic if out of memory.
  Wolfgang suggested not to silently ignore an out of memory
  situation.
---
   examples/api/Makefile |  3 +++
   lib/vsprintf.c| 47
+--
   2 files changed, 44 insertions(+), 6 deletions(-)



Can you please add a test for this? It could go in the print unit
tests, perhaps?

Regards,
Simon


test/print_ut.c is only compiled with CONFIG_SANDBOX.

It seems your patches to enable EFI_LOADER in the sandbox did not make it
into v2018.01. Are you still working on these? Do you have a repo with a
working copy?


I was really not sure where to take it. It seemed that most of them
were ready to apply. I didn't check who they were assigned to.

Tree is u-boot-dm/efi-working

I can certainly pick it up again, but I do need to understand what is
holding it up.

Regards,
Simon



The patch series
https://patchwork.ozlabs.org/project/uboot/list/?series=16686
is assigned to Alex.

There are some unanswered review comments.

Best regards

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


Re: [U-Boot] [PATCH 16/16] efi_loader: consistently use efi_handle_t for handles

2018-01-08 Thread Heinrich Schuchardt

On 01/08/2018 04:37 AM, Simon Glass wrote:

On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:

We should consistently use the efi_handle_t typedef when
referring to handles.

Signed-off-by: Heinrich Schuchardt 
---
  cmd/bootefi.c | 10 -
  include/efi_api.h | 20 ++
  include/efi_loader.h  | 14 +++--
  lib/efi_loader/efi_boottime.c | 49 +++
  lib/efi_loader/efi_console.c  |  6 +++---
  5 files changed, 53 insertions(+), 46 deletions(-)



Reviewed-by: Simon Glass 

[...]


diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 98497db612..56b079cee8 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -503,21 +503,21 @@ int efi_console_register(void)
 struct efi_object *efi_console_input_obj;

 /* Create handles */
-   r = efi_create_handle((void **)_console_control_obj);
+   r = efi_create_handle((efi_handle_t *)_console_control_obj);


How come we need this cast?


Without any cast we get
"warning: passing argument 1 of ‘efi_create_handle’ from incompatible 
pointer type"


In most cases efi_handle_t is a (void *) pointer to a struct efi_object. 
But there is at least an exception for loaded images.


I would prefer if we could eliminate this insane duality. But that will 
need some careful cleanup.


Best regards

Heinrich



Regards,
Simon



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


Re: [U-Boot] [PATCH 11/16] efi_loader: implement DisconnectController

2018-01-08 Thread Heinrich Schuchardt

On 01/08/2018 04:35 AM, Simon Glass wrote:

Hi Heinrich,

On 17 December 2017 at 08:43, Heinrich Schuchardt  wrote:

Unfortunately we need a forward declaration because both
OpenProtocol and CloseProtocol have to call DisconnectController.
And DisconnectController calls both OpenProtcol and CloseProtocol.

Signed-off-by: Heinrich Schuchardt 
---
  lib/efi_loader/efi_boottime.c | 283 ++
  1 file changed, 261 insertions(+), 22 deletions(-)


Reviewed-by: Simon Glass 

I think it would be good to reduce the length of some of the identifies.

e.g. numbers_of_children -> child_count or num_children


number_of_children is what we used in the function definition in 
efi_api.h and is the name of the parameter in the UEFI spec.


I understand that you do not like bloat. But I tend to get confused when 
parameter names differ from the spec.


Regards

Heinrich



It's just too verbose for U-Boot IMO.

- Simon



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


Re: [U-Boot] [U-boot] Odroidxu3/4 -s2mps11 bind pmic failed

2018-01-08 Thread Jaehoon Chung
Hi, 

On 01/08/2018 03:57 PM, Anand Moon wrote:
> Hi Jaehoon,

This topic is on u-boot side. so Removed the linux-samsung-soc mailing.

[..snip..]

>>> How can we invoke and verify the s2mps11 init function during board
>>> initialization ?
>>
>> When i have checked the above values, those are the reset value at each 
>> registers.
>> but some registers are different with reset values.
>>
>> do you want to change the pmic register value at init time?
> [snip]
> 
> What I have debug at my end pmci is not getting invoke or initialize via 
> u-boot.
> Yes default value for all the control registers would be fine.
> 
> I was looking into some missing feature like.
> s2mps11 regulator initialization via dts in u-boot.
>  s2mps11_pmic
>  .probe = s2mps11_probe
>  .bind = s2mps11_bind

It needs to implement the regulator driver.
I will send the patch for s2mps11 regulator driver within this week.
Then i think that it will be set to values from device-tree.

> 
> Can we enable CONFIG_SPL_BUILD for Odroid platform.
> much of the core initialization is blocked under this flag.
> Is their any plan to make this feature working.

Lukasz has already mentioned..

> 
> Best Regards
> -Anand
> 
> 
> 

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


Re: [U-Boot] [PATCH 1/1] configs: x86: allow to override CONFIG_BOOTCOMMAND

2018-01-08 Thread Simon Glass
Hi Heinrich,

On 8 January 2018 at 13:57, Heinrich Schuchardt  wrote:
> On 01/08/2018 05:50 AM, Simon Glass wrote:
>>
>> Hi Heinrich,
>>
>> On 3 January 2018 at 08:23, Heinrich Schuchardt 
>> wrote:
>>>
>>> Allow to override CONFIG_BOOTCOMMAND in .config.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>   include/configs/x86-common.h | 2 ++
>>>   1 file changed, 2 insertions(+)
>>
>>
>> This is a Chrome OS boot line. I think you should consider whether it
>> should move into x86-chromebook.h or similar? Then you can just remove
>> it from the common file.
>
>
> I understand Chromebooks uses this boot line.
>
> theadorable-x86-common.h undefines CONFIG_BOOTCOMMAND anyway.
> For qemu I need to override the value.
>
> What about all the other x86 boards?
> They seem to have bootargs matching the CONFIG_BOOTCOMMAND.
>
> As they are not using distro boot, wouldn't removing the CONFIG_BOOTCOMMAND
> default value create havoc?
> As a downstream user I would not cherish such a change.
>
> I think it is safer to leave the default value where it is.
>
> Would you accept the patch as is?

Bin seems happy and I have no objection.

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


Re: [U-Boot] [PATCH 2/2] sysboot: Call bootm booti bootz then go on label_boot

2018-01-08 Thread Simon Glass
Hi Emmanuel,

On 8 January 2018 at 03:05, Emmanuel Vadot  wrote:
> On Sun, 7 Jan 2018 21:39:01 -0700
> Simon Glass  wrote:
>
>> Hi Emmanuel,
>>
>> On 2 January 2018 at 14:27, Emmanuel Vadot  wrote:
>> > As do_bootm/do_booti/do_bootz will not return if the boot succeded, always
>> > call them if enable by the config.
>> > Also add a fallback to go if the binary is a raw one.
>>
>> Do we not know which type of binary it is?
>
>  For which case ?
>
>> It seems like we should have some error checking here.
>
>  Each bootX function check the header/magic/etc ...
>  What kind of error checking do you want to add ?

Well, it looks like you have a fallback so that if the image does not
pass any of the header/magic checks you just jump to it,. Won't that
crash if (e.g.) someone uses a valid image but one for which support
is turned off in the U-Boot build?

I'm not sure of the solution, but perhaps we should have a CONFIG
option to enable this fallback?

>
>> >
>> > Signed-off-by: Emmanuel Vadot 
>> > ---
>> >  cmd/pxe.c | 12 +++-
>> >  1 file changed, 7 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/cmd/pxe.c b/cmd/pxe.c
>> > index 7043ad11fd..0ca6a964bc 100644
>> > --- a/cmd/pxe.c
>> > +++ b/cmd/pxe.c
>> > @@ -796,12 +796,14 @@ static int label_boot(cmd_tbl_t *cmdtp, struct 
>> > pxe_label *label)
>> > do_bootm(cmdtp, 0, bootm_argc, bootm_argv);
>> >  #ifdef CONFIG_CMD_BOOTI
>> > /* Try booting an AArch64 Linux kernel image */
>> > -   else
>> > -   do_booti(cmdtp, 0, bootm_argc, bootm_argv);
>> > -#elif defined(CONFIG_CMD_BOOTZ)
>> > +   do_booti(cmdtp, 0, bootm_argc, bootm_argv);
>> > +#endif
>> > +#if defined(CONFIG_CMD_BOOTZ)
>> > /* Try booting a Image */
>> > -   else
>> > -   do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
>> > +   do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
>> > +#endif
>> > +#if defined(CONFIG_CMD_GO)
>> > +   do_go(cmdtp, 0, bootm_argc, bootm_argv);
>> >  #endif
>> > unmap_sysmem(buf);
>> > return 1;
>> > --
>> > 2.15.1

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


Re: [U-Boot] [PATCH v3 1/1] vsprintf.c: add EFI device path printing

2018-01-08 Thread Simon Glass
HI Heinrich,

On 8 January 2018 at 08:09, Heinrich Schuchardt  wrote:
>
>
> On 01/08/2018 04:52 AM, Simon Glass wrote:
>>
>> On 26 December 2017 at 03:07, Heinrich Schuchardt 
>> wrote:
>>>
>>> For debugging efi_loader we need the capability to print EFI
>>> device paths. With this patch we can write:
>>>
>>>  debug("device path: %pD", dp);
>>>
>>> A possible output would be
>>>
>>>  device path: /MemoryMapped(0x0,0x3ff93a82,0x3ff93a82)
>>>
>>> This enhancement is not available when building without EFI support
>>> and neither in the SPL nor in the API example.
>>>
>>> Cc: Wolfgang Denk 
>>> Cc: Simon Glass 
>>> Suggested-by: Rob Clark 
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>> I propose Alex picks up this patch for the EFI tree.
>>>
>>> v3:
>>>  Return -ENOMEM if out of memory.
>>>  Avoid missing dependency error when building the SPL of the
>>>  API example.
>>> v2:
>>>  Panic if out of memory.
>>>  Wolfgang suggested not to silently ignore an out of memory
>>>  situation.
>>> ---
>>>   examples/api/Makefile |  3 +++
>>>   lib/vsprintf.c| 47
>>> +--
>>>   2 files changed, 44 insertions(+), 6 deletions(-)
>>
>>
>> Can you please add a test for this? It could go in the print unit
>> tests, perhaps?
>>
>> Regards,
>> Simon
>>
> test/print_ut.c is only compiled with CONFIG_SANDBOX.
>
> It seems your patches to enable EFI_LOADER in the sandbox did not make it
> into v2018.01. Are you still working on these? Do you have a repo with a
> working copy?

I was really not sure where to take it. It seemed that most of them
were ready to apply. I didn't check who they were assigned to.

Tree is u-boot-dm/efi-working

I can certainly pick it up again, but I do need to understand what is
holding it up.

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


Re: [U-Boot] [PATCH 3/4] ARMv8: Allow dynamic early stack pointer

2018-01-08 Thread Simon Glass
Hi Stephen,

On 8 January 2018 at 11:34, Stephen Warren  wrote:
>
> On 01/07/2018 08:40 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 19 December 2017 at 18:30, Stephen Warren  wrote:
>>>
>>> From: Stephen Warren 
>>>
>>> U-Boot typically uses a hard-coded value for the stack pointer before
>>> relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate
>>> the initial SP at run-time. This is useful to avoid hard-coding addresses
>>> into U-Boot, so that can be loaded and executed at arbitrary addresses and
>>> thus avoid using arbitrary addresses at runtime. This option's value is
>>> the offset added to &_bss_start in order to calculate the stack pointer.
>>> This offset should be large enough so that the early malloc region, global
>>> data (gd), and early stack usage do not overlap any appended DTB.
>>
>>
>> I don't see why this is an offset from bss_start - shouldn't it be bss_end?
>
>
> BSS can vary in size based on the set of config options enabled, code 
> growth/shrinkage, etc. Thus, basing the initial SP address on bss_end would 
> provide too much variability, and hence would be unsafe, whereas basing the 
> initial SP address on bss_start always provides the exact same amount of 
> available stack space (assuming an identical DTB for the comparison).

OK. I suppose we are no worse off anyway, since the DTB can vary in size.

>
>> Also this seems error-prone since we don't know how large the DTB is.
>> Can we improve this, e.g. by:
>>
>> - using binman to provide the stack start value or offset
>
>
> I'd rather not involve binman in the code generation process. Packaging is 
> fine, but I think the source code and makefiles should dictate everything 
> that goes into the actual binary to keep things simple.
>
> I did originally think about having binman patch up the init SP address, but 
> rejected it due to the complexity added by the extra step, and the fact that 
> we'd be inventing a new tool (the new part of binman implemented for this 
> feature) to do what we already have a perfectly good tool for already; the 
> linker. I'm also looking to backport this change to an older branch of U-Boot 
> that doesn't have binman, although I believe I'd have the same thought 
> process either way.
>

There is actually a feature for this, or something similar:

http://git.denx.de/?p=u-boot.git;a=blob;f=tools/binman/README;h=08c3e56bdef8d3ee47ac2ec86411465a78dbf567;hb=HEAD#l476

>> - checking the DTB size and automatically using the address
>> immediately after it finishes (again I suppose binman could provide
>> that)
>
>
> Perhaps we can add an extra step in binman that validates the build; i.e. 
> that (SYS_INIT_SP_BSS_OFFSET - size_of_dtb) > some_minimum_stack_size. That 
> would be a useful error check, but prevent binman having to edit parts of the 
> binary that were already created by the main build process. Note that for a 
> given build, it should be completely deterministic whether DTB corruption 
> occurs, and whether that corruption actually impacts U-Boot's operation, so 
> any such check would be pretty much equivalent to just running U-Boot and 
> seeing if it works. Admittedly the check might save some annoying debugging 
> though, so would be a good idea.

Sounds good. It could even be done in Makefile - we have a few checks
that that at present. But if binman is a better place, that is fine.

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


Re: [U-Boot] [PATCH 1/2] cmd: go: Make do_go available to outside boot.c

2018-01-08 Thread Simon Glass
Hi Emmanuel,

On 8 January 2018 at 03:00, Emmanuel Vadot  wrote:
>
>
>  Hello Simon,
>
> On Sun, 7 Jan 2018 21:38:29 -0700
> Simon Glass  wrote:
>
> > Hi Emmanuel,
> >
> > On 2 January 2018 at 14:27, Emmanuel Vadot  wrote:
> > > Some commands (like sysboot) might want to call go as they can encounter
> > > a raw binary.
> > > Make do_go callable for everyone.
> > >
> > > Signed-off-by: Emmanuel Vadot 
> > > ---
> > >  cmd/boot.c| 2 +-
> > >  include/command.h | 4 
> > >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > Can we instead move the code out of do_go() into another function
> > which accepts C arguments, and then call that from do_go()?
>
>  Sorry I do not understand what you mean.

int go_exec(ulong addr)
{
   existing code to jump to addr
}

do_go()
{
   existing code to parse args

   go_exec(addr)l
}

Then you can call go_eec() from cmd/boot.c

Regards,
Simon
___
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

2018-01-08 Thread Tom Rini
On Mon, Jan 08, 2018 at 05:54:38PM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> some fixes, please pull from u-boot-imx, thanks !
> 
> The following changes since commit 1314bd1192b4c67d28bdae7eee639588e88090cd:
> 
>   boards: amlogic: khadas-vim: Typo fixup (2018-01-02 07:57:34 -0500)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to ca9d211e2c7801bc3e194d325ece0d3b583b32d2:
> 
>   mtd: nand: mxs_nand_spl: Remove nand size print (2018-01-08 17:37:12
> +0100)
> 

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

2018-01-08 Thread Tom Rini
On Mon, Jan 08, 2018 at 06:50:36PM +0100, Stefano Babic wrote:
> Hi Tom,
> 
> On 08/01/2018 18:38, Tom Rini wrote:
> > On Mon, Jan 08, 2018 at 05:54:38PM +0100, Stefano Babic wrote:
> >> Hi Tom,
> >>
> >> some fixes, please pull from u-boot-imx, thanks !
> >>
> >> The following changes since commit 
> >> 1314bd1192b4c67d28bdae7eee639588e88090cd:
> >>
> >>   boards: amlogic: khadas-vim: Typo fixup (2018-01-02 07:57:34 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>   git://www.denx.de/git/u-boot-imx.git master
> >>
> >> for you to fetch changes up to ca9d211e2c7801bc3e194d325ece0d3b583b32d2:
> >>
> >>   mtd: nand: mxs_nand_spl: Remove nand size print (2018-01-08 17:37:12
> >> +0100)
> >>
> >> 
> >> Christopher Spinrath (3):
> >>   ARM: imx: cm_fx6: env: use standard variables
> >>   ARM: imx: cm_fx6: env: support distro boot command
> >>   ARM: imx: cm_fx6: env: don't run boot scripts twice
> >>
> >> Eran Matityahu (1):
> >>   imx: spl: Fix NAND bootmode detection
> >>
> >> Eric Nelson (1):
> >>   mx6: Add board mx6memcal for use in validating DDR
> >>
> >> Fabio Estevam (1):
> >>   mx6ull: Handle the CONFIG_MX6ULL cases correctly
> >>
> >> Jagan Teki (2):
> >>   board: engicam: Fix to remove legacy board/icorem6_rqs
> >>   mtd: nand: mxs_nand_spl: Remove nand size print
> >>
> >> Stefan Agner (3):
> >>   imx: move CONFIG_SYSCOUNTER_TIMER to Kconfig
> >>   imx: introduce CONFIG_GPT_TIMER
> >>   imx: initialize and use generic timer on i.MX 6UL/ULL
> > 
> > It's release day.  How many of these are release day candidate fixes?  I
> > know the MX6ULL thing is important, and the SPL bootmode thing looks so
> > too.
> 
> Yes, both are important - for MX6ULL this means both Fabio's and
> Stefan's patches. Eran's is a fix, too, and it should be in.
> 
> Jagan's is just a cleanup - this drops dead code in a Engicam board, and
> drop a couple of nasty print when booting from NAND. No big issue, but
> also no effects on the rest of code.
> 
> >  I do not know about the rest, are they?  Thanks!
> 
> It remains Cristopher's (small fixes just for cm_fx6 board) and Eric's.
> The last one is a very interesting thing because it replaces the
> proprietary ddr-stress tool from Freescale. It is not a fix, but it is
> very nice to have. It adds another target, so there is no changes in
> common code and if you do not argue, it will be nice to have in release.

OK.  I'm going to take it (applied message coming shortly) since we're
just now exiting the general US/EU winter holiday time-frame and I'll
use that as why most of this wasn't sent much sooner.  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH 1/1] configs: x86: allow to override CONFIG_BOOTCOMMAND

2018-01-08 Thread Heinrich Schuchardt

On 01/08/2018 05:50 AM, Simon Glass wrote:

Hi Heinrich,

On 3 January 2018 at 08:23, Heinrich Schuchardt  wrote:

Allow to override CONFIG_BOOTCOMMAND in .config.

Signed-off-by: Heinrich Schuchardt 
---
  include/configs/x86-common.h | 2 ++
  1 file changed, 2 insertions(+)


This is a Chrome OS boot line. I think you should consider whether it
should move into x86-chromebook.h or similar? Then you can just remove
it from the common file.


I understand Chromebooks uses this boot line.

theadorable-x86-common.h undefines CONFIG_BOOTCOMMAND anyway.
For qemu I need to override the value.

What about all the other x86 boards?
They seem to have bootargs matching the CONFIG_BOOTCOMMAND.

As they are not using distro boot, wouldn't removing the 
CONFIG_BOOTCOMMAND default value create havoc?

As a downstream user I would not cherish such a change.

I think it is safer to leave the default value where it is.

Would you accept the patch as is?

Best regards

Heinrich

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


Re: [U-Boot] [PATCH v3 2/3] board: freescale: ls1012a: LS1012A-2G5RDB board support

2018-01-08 Thread York Sun
On 11/29/2017 09:13 PM, Bhaskar Upadhaya wrote:
> LS1012A-2G5RDB belongs to LS1012A family with features
> 2 2.5G SGMII PFE MAC, SATA, USB 2.0/3.0, WiFi
> DDR, eMMC, QuadSPI, UART
> 
> Signed-off-by: Bhaskar Upadhaya 
> ---
> changes for v3:
>  1. remove pfe driver changes from this patch
>  2. remove PCIe, DSPI from ls1012a2g5rdb_qspi_defconfig
> 



> diff --git a/board/freescale/ls1012ardb/ls1012ardb.c 
> b/board/freescale/ls1012ardb/ls1012ardb.c
> index 41283db..9675335 100644
> --- a/board/freescale/ls1012ardb/ls1012ardb.c
> +++ b/board/freescale/ls1012ardb/ls1012ardb.c
> @@ -28,6 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  int checkboard(void)
>  {
> +#ifdef CONFIG_TARGET_LS1012ARDB
>   u8 in1;
>  
>   puts("Board: LS1012ARDB ");
> @@ -57,6 +58,9 @@ int checkboard(void)
>   puts(": bank2\n");
>   else
>   puts("unknown\n");
> +#else
> + puts("Board: LS1012A2G5RDB ");
> +#endif
>  
>   return 0;
>  }
> @@ -148,10 +152,12 @@ int esdhc_status_fixup(void *blob, const char *compat)
>*  10 - eMMC Memory
>*  11 - SPI
>*/
> +#ifdef CONFIG_TARGET_LS1012ARDB
>   if (i2c_read(I2C_MUX_IO1_ADDR, 0, 1, , 1) < 0) {
>   printf("Error reading i2c boot information!\n");
>   return 0; /* Don't want to hang() on this error */
>   }
> +#endif
>  
>   mux_sdhc2 = (io & 0x0c) >> 2;
>   /* Enable SDHC2 only when use SDIO wifi and eMMC */

Bhaskar,

Please double check changes to this file. I am seeing compiling errors
related to I2C_MUX_IO_ADDR, I2C_MUX_IO_1, SW_REV_MASK, SW_REV_D for
ls1012a2g5rdb_qspi on top of master branch.

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


Re: [U-Boot] [PATCH 3/3] drivers: net: pfe_eth: Disable autonegotiation for 2.5G SGMII

2018-01-08 Thread York Sun
On 11/29/2017 09:13 PM, Bhaskar Upadhaya wrote:
> PCS initialization sequence for 2.5G SGMII interface governs
> auto negotiation to be in disabled mode
> 
> Signed-off-by: Bhaskar Upadhaya 
> ---
> Depends on 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fcover%2F823205=02%7C01%7Cyork.sun%40nxp.com%7Cb59aad3d38094ace132e08d537b11a48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636476156146644483=4AvC%2FgaoUi5mwTuEZFJr1uSTV2n1%2BAVFyNIZhuQ3XUQ%3D=0
> 

Bhaskar,

I wonder if we can skip this patch and apply other patches. The PFE
patch set is not accepted yet.

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


Re: [U-Boot] [PATCH 3/4] ARMv8: Allow dynamic early stack pointer

2018-01-08 Thread Stephen Warren

On 01/07/2018 08:40 PM, Simon Glass wrote:

Hi Stephen,

On 19 December 2017 at 18:30, Stephen Warren  wrote:

From: Stephen Warren 

U-Boot typically uses a hard-coded value for the stack pointer before
relocation. Implement option SYS_INIT_SP_BSS_OFFSET to instead calculate
the initial SP at run-time. This is useful to avoid hard-coding addresses
into U-Boot, so that can be loaded and executed at arbitrary addresses and
thus avoid using arbitrary addresses at runtime. This option's value is
the offset added to &_bss_start in order to calculate the stack pointer.
This offset should be large enough so that the early malloc region, global
data (gd), and early stack usage do not overlap any appended DTB.


I don't see why this is an offset from bss_start - shouldn't it be bss_end?


BSS can vary in size based on the set of config options enabled, code 
growth/shrinkage, etc. Thus, basing the initial SP address on bss_end 
would provide too much variability, and hence would be unsafe, whereas 
basing the initial SP address on bss_start always provides the exact 
same amount of available stack space (assuming an identical DTB for the 
comparison).



Also this seems error-prone since we don't know how large the DTB is.
Can we improve this, e.g. by:

- using binman to provide the stack start value or offset


I'd rather not involve binman in the code generation process. Packaging 
is fine, but I think the source code and makefiles should dictate 
everything that goes into the actual binary to keep things simple.


I did originally think about having binman patch up the init SP address, 
but rejected it due to the complexity added by the extra step, and the 
fact that we'd be inventing a new tool (the new part of binman 
implemented for this feature) to do what we already have a perfectly 
good tool for already; the linker. I'm also looking to backport this 
change to an older branch of U-Boot that doesn't have binman, although I 
believe I'd have the same thought process either way.



- checking the DTB size and automatically using the address
immediately after it finishes (again I suppose binman could provide
that)


Perhaps we can add an extra step in binman that validates the build; 
i.e. that (SYS_INIT_SP_BSS_OFFSET - size_of_dtb) > 
some_minimum_stack_size. That would be a useful error check, but prevent 
binman having to edit parts of the binary that were already created by 
the main build process. Note that for a given build, it should be 
completely deterministic whether DTB corruption occurs, and whether that 
corruption actually impacts U-Boot's operation, so any such check would 
be pretty much equivalent to just running U-Boot and seeing if it works. 
Admittedly the check might save some annoying debugging though, so would 
be a good idea.

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


Re: [U-Boot] [PATCH v2 1/2] env: sf: Add support for env init for QSPI-NOR

2018-01-08 Thread York Sun
On 12/14/2017 04:06 AM, Ashish Kumar wrote:
> ENV variables can now be used before relocation.
> 
> Signed-off-by: Ashish Kumar 
> ---
> v2:
> replace & with && in #if
> 
> Tested on ls1088ardb.
> Tested on ls1012hexa after defining CONFIG_ENV_ADDR
> 
>  env/sf.c | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/env/sf.c b/env/sf.c
> index e51b1ae..a2e4c93 100644
> --- a/env/sf.c
> +++ b/env/sf.c
> @@ -34,6 +34,7 @@
>  
>  #ifndef CONFIG_SPL_BUILD
>  #define CMD_SAVEENV
> +#define INITENV
>  #endif
>  
>  #ifdef CONFIG_ENV_OFFSET_REDUND
> @@ -348,6 +349,23 @@ out:
>  }
>  #endif
>  
> +#if defined(INITENV) && defined(CONFIG_ENV_ADDR)
> +static int env_sf_init(void)
> +{
> + env_t *env_ptr = (env_t *)(CONFIG_ENV_ADDR);
> +
> + if (crc32(0, env_ptr->data, ENV_SIZE) == env_ptr->crc) {
> + gd->env_addr= (ulong)&(env_ptr->data);
> + gd->env_valid   = 1;
> + } else {
> + gd->env_addr = (ulong)_environment[0];
> + gd->env_valid = 1;
> + }
> +
> + return 0;
> +}
> +#endif
> +
>  U_BOOT_ENV_LOCATION(sf) = {
>   .location   = ENVL_SPI_FLASH,
>   ENV_NAME("SPI Flash")
> @@ -355,4 +373,7 @@ U_BOOT_ENV_LOCATION(sf) = {
>  #ifdef CMD_SAVEENV
>   .save   = env_save_ptr(env_sf_save),
>  #endif
> +#if defined(INITENV) && defined(CONFIG_ENV_ADDR)
> + .init   = env_sf_init,
> +#endif
>  };
> 

Please run get_maintainer.pl to get the CC list if you don't use patman.

I wonder how SPI worked before. Did it work, Simon and Jagan?

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


Re: [U-Boot] [PATCH 2/2] ARM: tegra: use LINUX_KERNEL_IMAGE_HEADER

2018-01-08 Thread Stephen Warren

On 01/07/2018 09:50 PM, Simon Glass wrote:

Hi Stephen,

On 2 January 2018 at 16:54, Stephen Warren  wrote:

From: Stephen Warren 

Enable CONFIG_LINUX_KERNEL_IMAGE_HEADER for all 64-bit Tegra boards.
cboot (the boot SW that runs before U-Boot) will eventually use this
information.


How does U-Boot use it? Does it not come from the FIT?


U-Boot doesn't use the header itself. Rather, the header provides 
information (e.g. BSS usage) to whatever SW is loading U-Boot into RAM. 
We don't use FIT at all; I'd rather our boot flow not know about 
bootloader-specific data formats.

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


Re: [U-Boot] [PATCH] freescale: vid: add support LTC3882 and rework of the VID support

2018-01-08 Thread York Sun
On 12/20/2017 12:18 AM, ying.zhang22...@nxp.com wrote:
> From: Zhang Ying-22455 
> 
> Add support new regular chip: LTC3882.
> 
> The origianl VID code didn't properly read the FUSESR on all chips
> and set the voltages on all chips. It didn't properly support the
> voltage regulators in use by NXP and report voltage changes.
> 
> Signed-off-by: Zhang Ying-22455 
> ---
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |9 +-
>  board/freescale/common/vid.c   |  465 
> +++-
>  board/freescale/common/vid.h   |   19 +
>  3 files changed, 291 insertions(+), 202 deletions(-)

Ying,

Please run checkpatch and fix the checks, warnings and errors.

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


Re: [U-Boot] [PATCH v2 06/13] drivers: usb: dwc3: add ti dwc3 peripheral driver with driver model support

2018-01-08 Thread Vignesh R
Hi Lukasz,

Revisiting this old thread...
On 21-Jun-17 1:39 PM, Lukasz Majewski wrote:
> Hi Vignesh,
[...]
 This is something to consult with Lukasz then.
>>>
>>> And it seems that we are heading to adding "gadget" infrastructure
>>> to DM.
>>>
>>
>> Yes, U-Boot is moving to DM for good and this has cascading effect.
>> I was actually trying to enable DM_ETH on some TI platforms which
>> forced me to move USB_ETH to DM as well and therefore seems like USB
>> gadget framework needs tweaks to adapt to DM...
> 

Did you get a chance to work on DM conversion of USB gadget framework?
Are there any plans to work on it as such?

> I've sketched following plan for gadget conversion:
> 
> 1. Each u-boot command (dfu, ums, thor and in the future rockchip I
> hope), which uses gadget goes through g_dnl_{register|unregister}, so
> the idea is to add this driver first to DM.
> 
> 2. Afterwards, we could add functions as children of g_dnl.
> 
> This would be easily modeled in Kconfig (to have g_dnl - gadget - menu
> with submenu to chose the USB function - e.g. f_dfu*).
> 
> However, we also need to take care of several UDC (USB device
> controller) drivers including also the "composite" usb layer.
> 
> This would be tougher to do since there are many udc drivers - but it
> should be possible to separate DM's UDC drivers and g_dnl/function
> code. 
> 
> Another problem is that some archs use gadgets (RNDIS?) without g_dnl
> and composite - on top of UDC driver (like musb).
> 
> For example:
> 
> board/ti/beagle/beagle.c -> board_eth_init()
>   |
>  \|/
> drivers/usb/gadget/ether.c -> usb_eth_initialize()
> [ether.c seems to partially support DM]
>   |
>  \|/
> (also in the ether.c)
>   _usb_eth_init() in which we loop on
>   usb_gadget_handle_interrupts()
> 
> 
> From what I see, the ether.c now supports DM and legacy code, so some
> work has been already done for DM
> 
>>
>>> I will do my best to provide some ideas for this task.
>>>
___
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

2018-01-08 Thread Stefano Babic
Hi Tom,

On 08/01/2018 18:38, Tom Rini wrote:
> On Mon, Jan 08, 2018 at 05:54:38PM +0100, Stefano Babic wrote:
>> Hi Tom,
>>
>> some fixes, please pull from u-boot-imx, thanks !
>>
>> The following changes since commit 1314bd1192b4c67d28bdae7eee639588e88090cd:
>>
>>   boards: amlogic: khadas-vim: Typo fixup (2018-01-02 07:57:34 -0500)
>>
>> are available in the git repository at:
>>
>>   git://www.denx.de/git/u-boot-imx.git master
>>
>> for you to fetch changes up to ca9d211e2c7801bc3e194d325ece0d3b583b32d2:
>>
>>   mtd: nand: mxs_nand_spl: Remove nand size print (2018-01-08 17:37:12
>> +0100)
>>
>> 
>> Christopher Spinrath (3):
>>   ARM: imx: cm_fx6: env: use standard variables
>>   ARM: imx: cm_fx6: env: support distro boot command
>>   ARM: imx: cm_fx6: env: don't run boot scripts twice
>>
>> Eran Matityahu (1):
>>   imx: spl: Fix NAND bootmode detection
>>
>> Eric Nelson (1):
>>   mx6: Add board mx6memcal for use in validating DDR
>>
>> Fabio Estevam (1):
>>   mx6ull: Handle the CONFIG_MX6ULL cases correctly
>>
>> Jagan Teki (2):
>>   board: engicam: Fix to remove legacy board/icorem6_rqs
>>   mtd: nand: mxs_nand_spl: Remove nand size print
>>
>> Stefan Agner (3):
>>   imx: move CONFIG_SYSCOUNTER_TIMER to Kconfig
>>   imx: introduce CONFIG_GPT_TIMER
>>   imx: initialize and use generic timer on i.MX 6UL/ULL
> 
> It's release day.  How many of these are release day candidate fixes?  I
> know the MX6ULL thing is important, and the SPL bootmode thing looks so
> too.

Yes, both are important - for MX6ULL this means both Fabio's and
Stefan's patches. Eran's is a fix, too, and it should be in.

Jagan's is just a cleanup - this drops dead code in a Engicam board, and
drop a couple of nasty print when booting from NAND. No big issue, but
also no effects on the rest of code.

>  I do not know about the rest, are they?  Thanks!

It remains Cristopher's (small fixes just for cm_fx6 board) and Eric's.
The last one is a very interesting thing because it replaces the
proprietary ddr-stress tool from Freescale. It is not a fix, but it is
very nice to have. It adds another target, so there is no changes in
common code and if you do not argue, it will be nice to have in release.

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


Re: [U-Boot] [PATCH] armv8: ls1088: Add USB and PCI configs in SD-BOOT defconfig

2018-01-08 Thread York Sun
On 01/01/2018 09:24 PM, Ashish Kumar wrote:
> Signed-off-by: Ashish Kumar 
> ---
> depends on: 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F853615%2F=02%7C01%7Cyork.sun%40nxp.com%7C71f45df66ff84071f9c808d551a1227d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636504674867120576=Qupa0iJaMMXN%2BHVOsCkYL8Y0IycNRSxULBG2NFsWyww%3D=0

Your dependency is to increase the CONFIG_SYS_MONITOR_LEN. Why are you
still using raw U-Boot image. If you use FIT image, the size should be
correct. Please try.

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


[U-Boot] [PATCH v5 22/24] arm: imx: hab: Define rvt_failsafe()

2018-01-08 Thread Bryan O'Donoghue
The hab_rvt_failsafe() callback according to the HABv4 documentation:

"This function provides a safe path when image authentication has failed
and all possible boot paths have been exhausted. It is intended for use by
post-ROM boot stage components, via the ROM Vector Table."

Once invoked the part will drop down to its BootROM USB recovery mode.
Should it be the case that the part is in secure boot mode - only an
appropriately signed binary will be accepted by the ROM and subsequently
executed.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 5c13aff..a0cb19d 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -140,6 +140,7 @@ typedef void *hab_rvt_authenticate_image_t(uint8_t, 
ptrdiff_t,
void **, size_t *, hab_loader_callback_f_t);
 typedef enum hab_status hab_rvt_check_target_t(enum hab_target, const void *,
   size_t);
+typedef void hab_rvt_failsafe_t(void);
 typedef void hapi_clock_init_t(void);
 
 #define HAB_ENG_ANY0x00   /* Select first compatible engine */
@@ -170,6 +171,7 @@ typedef void hapi_clock_init_t(void);
 #define HAB_RVT_AUTHENTICATE_IMAGE (*(uint32_t *)(HAB_RVT_BASE + 0x10))
 #define HAB_RVT_REPORT_EVENT   (*(uint32_t *)(HAB_RVT_BASE + 0x20))
 #define HAB_RVT_REPORT_STATUS  (*(uint32_t *)(HAB_RVT_BASE + 0x24))
+#define HAB_RVT_FAILSAFE   (*(uint32_t *)(HAB_RVT_BASE + 0x28))
 
 #define HAB_RVT_REPORT_EVENT_NEW   (*(uint32_t *)0x00B8)
 #define HAB_RVT_REPORT_STATUS_NEW  (*(uint32_t *)0x00BC)
-- 
2.7.4

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


[U-Boot] [PATCH v5 17/24] arm: imx: hab: Print HAB event log only after calling ROM

2018-01-08 Thread Bryan O'Donoghue
The current flow of authenticate_image() will print the HAB event log even
if we reject an element of the IVT header before ever calling into the ROM.
This can be confusing.

This patch changes the flow of the code so that the HAB event log is only
printed out if we have called into the ROM and received some sort of status
code.

Signed-off-by: Bryan O'Donoghue 
Suggested-by: Cc: Breno Matheus Lima 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
---
 arch/arm/mach-imx/hab.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 079423a..3ae88a4 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -478,14 +478,14 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
 
if (hab_rvt_entry() != HAB_SUCCESS) {
puts("hab entry function fail\n");
-   goto hab_caam_clock_disable;
+   goto hab_exit_failure_print_status;
}
 
status = hab_rvt_check_target(HAB_TGT_MEMORY, (void *)ddr_start, bytes);
if (status != HAB_SUCCESS) {
printf("HAB check target 0x%08x-0x%08x fail\n",
   ddr_start, ddr_start + bytes);
-   goto hab_caam_clock_disable;
+   goto hab_exit_failure_print_status;
}
 #ifdef DEBUG
printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n", ivt_offset, ivt_addr);
@@ -543,12 +543,14 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
load_addr = 0;
}
 
-hab_caam_clock_disable:
-   hab_caam_clock_enable(0);
-
+hab_exit_failure_print_status:
 #if !defined(CONFIG_SPL_BUILD)
get_hab_status();
 #endif
+
+hab_caam_clock_disable:
+   hab_caam_clock_enable(0);
+
if (load_addr != 0)
result = 0;
 
-- 
2.7.4

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


Re: [U-Boot] [PATCH] armv8: ls1088aqds: Add IFC-NOR as boot source for LS1088

2018-01-08 Thread York Sun
On 01/01/2018 09:24 PM, Ashish Kumar wrote:
> IFC-NOR and QSPI-NOR pins are muxed on SoC,so they
> cannot be accessed simultaneously, but
> IFC-NOR can be accessed along with SD-BOOT.
> 
> ls1088aqds_sdcard_ifc_defconfig: is defconfig for
> SD as boot source and IFC-NOR to be used as flash,
> this will be used to write IFC-NOR image on IFC flash.
> QSPI and DSPI cannot be accessed in this defconfig.
> 
> IFC-NOR image is generated by ls1088aqds_defconfig.
> 
> Signed-off-by: Ashish Kumar 
> ---
> depends on: 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F853615%2F=02%7C01%7Cyork.sun%40nxp.com%7Cc53b3ec4db4d48e5130a08d551a1253d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636504674905515652=j2VD3l2%2BIb7iYk8yvn3TOrvT38pPT8ARRQjN0h%2FR5b0%3D=0
> 
> Tested on 2018.01-rc3
> 
> More accurate timing are used which where provided by 
> validation team
> 
> to switch to IFC-NOR use command for qspi prompt:
> i2c mw 66 0x60 0x12; i2c mw 66 50 00;i2c mw 66 10 21

Can you expand qixis command to do this? You should stop using i2c
command to switch any banks.
Please add instructions to board README file to describe the flash map,
and the qixis commands to switch between QSPI banks, and other booting
sources.

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


[U-Boot] [PATCH v5 05/24] arm: imx: hab: Move IVT_SIZE to hab.h

2018-01-08 Thread Bryan O'Donoghue
The size of the IVT header should be defined in hab.h move it there now.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 2 ++
 arch/arm/mach-imx/hab.c | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 1b7a5e4..3c19d2e 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -143,6 +143,8 @@ typedef void hapi_clock_init_t(void);
 #define HAB_CID_ROM 0 /**< ROM Caller ID */
 #define HAB_CID_UBOOT 1 /**< UBOOT Caller ID*/
 
+#define IVT_SIZE   0x20
+
 /* --- end of HAB API updates */
 
 int authenticate_image(uint32_t ddr_start, uint32_t image_size);
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index f878b7b..6367562 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -70,7 +70,6 @@
((hab_rvt_exit_t *)HAB_RVT_EXIT)\
 )
 
-#define IVT_SIZE   0x20
 #define ALIGN_SIZE 0x1000
 #define CSF_PAD_SIZE   0x2000
 #define MX6DQ_PU_IROM_MMU_EN_VAR   0x009024a8
-- 
2.7.4

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


[U-Boot] [PATCH v5 21/24] arm: imx: hab: Make imx_hab_is_enabled global

2018-01-08 Thread Bryan O'Donoghue
It will be helpful to boot commands to know if the HAB is enabled. Export
imx_hab_is_enabled() now to facilitate further work with this data-point in
a secure-boot context.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 1 +
 arch/arm/mach-imx/hab.c | 4 +---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 98bc1bd..5c13aff 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -187,5 +187,6 @@ typedef void hapi_clock_init_t(void);
 
 int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
   uint32_t ivt_offset);
+bool imx_hab_is_enabled(void);
 
 #endif
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index d917ac3..86b4018 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -96,8 +96,6 @@ static inline enum hab_status hab_rvt_check_target_new(enum 
hab_target target,
(is_soc_type(MXC_SOC_MX7ULP) ? 0x8000 : \
 (is_soc_type(MXC_SOC_MX7) ? 0x200 : 0x2))
 
-static bool imx_hab_is_enabled(void);
-
 static int ivt_header_error(const char *err_str, struct ivt_header *ivt_hdr)
 {
printf("%s magic=0x%x length=0x%02x version=0x%x\n", err_str,
@@ -419,7 +417,7 @@ U_BOOT_CMD(
 
 #endif /* !defined(CONFIG_SPL_BUILD) */
 
-static bool imx_hab_is_enabled(void)
+bool imx_hab_is_enabled(void)
 {
struct imx_sec_config_fuse_t *fuse =
(struct imx_sec_config_fuse_t *)_sec_config_fuse;
-- 
2.7.4

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


[U-Boot] [PATCH v5 18/24] arm: imx: hab: Make internal functions and data static

2018-01-08 Thread Bryan O'Donoghue
There is no need to export these functions and data structures externally.
Make them all static now.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 159 +---
 1 file changed, 84 insertions(+), 75 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 3ae88a4..ec85548 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -135,73 +135,81 @@ struct record {
bool any_rec_flag;
 };
 
-char *rsn_str[] = {"RSN = HAB_RSN_ANY (0x00)\n",
-  "RSN = HAB_ENG_FAIL (0x30)\n",
-  "RSN = HAB_INV_ADDRESS (0x22)\n",
-  "RSN = HAB_INV_ASSERTION (0x0C)\n",
-  "RSN = HAB_INV_CALL (0x28)\n",
-  "RSN = HAB_INV_CERTIFICATE (0x21)\n",
-  "RSN = HAB_INV_COMMAND (0x06)\n",
-  "RSN = HAB_INV_CSF (0x11)\n",
-  "RSN = HAB_INV_DCD (0x27)\n",
-  "RSN = HAB_INV_INDEX (0x0F)\n",
-  "RSN = HAB_INV_IVT (0x05)\n",
-  "RSN = HAB_INV_KEY (0x1D)\n",
-  "RSN = HAB_INV_RETURN (0x1E)\n",
-  "RSN = HAB_INV_SIGNATURE (0x18)\n",
-  "RSN = HAB_INV_SIZE (0x17)\n",
-  "RSN = HAB_MEM_FAIL (0x2E)\n",
-  "RSN = HAB_OVR_COUNT (0x2B)\n",
-  "RSN = HAB_OVR_STORAGE (0x2D)\n",
-  "RSN = HAB_UNS_ALGORITHM (0x12)\n",
-  "RSN = HAB_UNS_COMMAND (0x03)\n",
-  "RSN = HAB_UNS_ENGINE (0x0A)\n",
-  "RSN = HAB_UNS_ITEM (0x24)\n",
-  "RSN = HAB_UNS_KEY (0x1B)\n",
-  "RSN = HAB_UNS_PROTOCOL (0x14)\n",
-  "RSN = HAB_UNS_STATE (0x09)\n",
-  "RSN = INVALID\n",
-  NULL};
-
-char *sts_str[] = {"STS = HAB_SUCCESS (0xF0)\n",
-  "STS = HAB_FAILURE (0x33)\n",
-  "STS = HAB_WARNING (0x69)\n",
-  "STS = INVALID\n",
-  NULL};
-
-char *eng_str[] = {"ENG = HAB_ENG_ANY (0x00)\n",
-  "ENG = HAB_ENG_SCC (0x03)\n",
-  "ENG = HAB_ENG_RTIC (0x05)\n",
-  "ENG = HAB_ENG_SAHARA (0x06)\n",
-  "ENG = HAB_ENG_CSU (0x0A)\n",
-  "ENG = HAB_ENG_SRTC (0x0C)\n",
-  "ENG = HAB_ENG_DCP (0x1B)\n",
-  "ENG = HAB_ENG_CAAM (0x1D)\n",
-  "ENG = HAB_ENG_SNVS (0x1E)\n",
-  "ENG = HAB_ENG_OCOTP (0x21)\n",
-  "ENG = HAB_ENG_DTCP (0x22)\n",
-  "ENG = HAB_ENG_ROM (0x36)\n",
-  "ENG = HAB_ENG_HDCP (0x24)\n",
-  "ENG = HAB_ENG_RTL (0x77)\n",
-  "ENG = HAB_ENG_SW (0xFF)\n",
-  "ENG = INVALID\n",
-  NULL};
-
-char *ctx_str[] = {"CTX = HAB_CTX_ANY(0x00)\n",
-  "CTX = HAB_CTX_FAB (0xFF)\n",
-  "CTX = HAB_CTX_ENTRY (0xE1)\n",
-  "CTX = HAB_CTX_TARGET (0x33)\n",
-  "CTX = HAB_CTX_AUTHENTICATE (0x0A)\n",
-  "CTX = HAB_CTX_DCD (0xDD)\n",
-  "CTX = HAB_CTX_CSF (0xCF)\n",
-  "CTX = HAB_CTX_COMMAND (0xC0)\n",
-  "CTX = HAB_CTX_AUT_DAT (0xDB)\n",
-  "CTX = HAB_CTX_ASSERT (0xA0)\n",
-  "CTX = HAB_CTX_EXIT (0xEE)\n",
-  "CTX = INVALID\n",
-  NULL};
-
-uint8_t hab_statuses[5] = {
+static char *rsn_str[] = {
+ "RSN = HAB_RSN_ANY (0x00)\n",
+ "RSN = HAB_ENG_FAIL (0x30)\n",
+ "RSN = HAB_INV_ADDRESS 

[U-Boot] [PATCH v5 09/24] arm: imx: hab: Add IVT header verification

2018-01-08 Thread Bryan O'Donoghue
The IVT header contains a magic number, fixed length and one of two version
identifiers. Validate these settings before doing anything with a putative
IVT binary.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 2a40d06..998d253 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -80,6 +80,31 @@
 
 static bool is_hab_enabled(void);
 
+static int ivt_header_error(const char *err_str, struct ivt_header *ivt_hdr)
+{
+   printf("%s magic=0x%x length=0x%02x version=0x%x\n", err_str,
+  ivt_hdr->magic, ivt_hdr->length, ivt_hdr->version);
+
+   return 1;
+}
+
+static int verify_ivt_header(struct ivt_header *ivt_hdr)
+{
+   int result = 0;
+
+   if (ivt_hdr->magic != IVT_HEADER_MAGIC)
+   result = ivt_header_error("bad magic", ivt_hdr);
+
+   if (be16_to_cpu(ivt_hdr->length) != IVT_TOTAL_LENGTH)
+   result = ivt_header_error("bad length", ivt_hdr);
+
+   if (ivt_hdr->version != IVT_HEADER_V1 &&
+   ivt_hdr->version != IVT_HEADER_V2)
+   result = ivt_header_error("bad version", ivt_hdr);
+
+   return result;
+}
+
 #if !defined(CONFIG_SPL_BUILD)
 
 #define MAX_RECORD_BYTES (8*1024) /* 4 kbytes */
@@ -394,6 +419,8 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
hab_rvt_authenticate_image_t *hab_rvt_authenticate_image;
hab_rvt_entry_t *hab_rvt_entry;
hab_rvt_exit_t *hab_rvt_exit;
+   struct ivt *ivt;
+   struct ivt_header *ivt_hdr;
 
hab_rvt_authenticate_image = hab_rvt_authenticate_image_p;
hab_rvt_entry = hab_rvt_entry_p;
@@ -416,6 +443,13 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
 
/* Calculate IVT address header */
ivt_addr = ddr_start + ivt_offset;
+   ivt = (struct ivt *)ivt_addr;
+   ivt_hdr = >hdr;
+
+   /* Verify IVT header bugging out on error */
+   if (verify_ivt_header(ivt_hdr))
+   goto hab_caam_clock_disable;
+
start = ddr_start;
bytes = image_size;
 #ifdef DEBUG
@@ -435,8 +469,6 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
printf("\tivt_offset = 0x%x\n", ivt_offset);
printf("\tstart = 0x%08lx\n", start);
printf("\tbytes = 0x%x\n", bytes);
-#else
-   (void)ivt_addr;
 #endif
/*
 * If the MMU is enabled, we have to notify the ROM
-- 
2.7.4

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


[U-Boot] [PATCH v5 07/24] arm: imx: hab: Fix authenticate_image input parameters

2018-01-08 Thread Bryan O'Donoghue
u-boot command "hab_auth_img" tells a user that it takes

- addr - image hex address
- offset - hex offset of IVT in the image

but in fact the callback hab_auth_img makes to authenticate_image treats
the second 'offset' parameter as an image length.

Furthermore existing code requires the IVT header to be appended to the end
of the image which is not actually a requirement of HABv4.

This patch fixes this situation by

1: Adding a new parameter to hab_auth_img
   - addr   : image hex address
   - length : total length of the image
   - offset : offset of IVT from addr

2: Updates the existing call into authenticate_image() in
   arch/arm/mach-imx/spl.c:jump_to_image_no_args() to pass
   addr, length and IVT offset respectively.

This allows then hab_auth_img to actually operate the way it was specified
in the help text and should still allow existing code to work.

It has the added advantage that the IVT header doesn't have to be appended
to an image given to HAB - it can be prepended for example.

Note prepending the IVT is what u-boot will do when making an IVT for the
BootROM. It should be possible for u-boot properly authenticate images
made by mkimage via HAB.

This patch is the first step in making that happen subsequent patches will
focus on removing hard-coded offsets to the IVT, which again is not
mandated to live at the end of a .imx image.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h |  3 +-
 arch/arm/mach-imx/hab.c | 73 +++--
 arch/arm/mach-imx/spl.c | 35 +-
 3 files changed, 57 insertions(+), 54 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 91dda42..b2a8031 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -148,6 +148,7 @@ typedef void hapi_clock_init_t(void);
 
 /* --- end of HAB API updates */
 
-int authenticate_image(uint32_t ddr_start, uint32_t image_size);
+int authenticate_image(uint32_t ddr_start, uint32_t image_size,
+  uint32_t ivt_offset);
 
 #endif
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 039a017..2a40d06 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -78,37 +78,6 @@
(is_soc_type(MXC_SOC_MX7ULP) ? 0x8000 : \
 (is_soc_type(MXC_SOC_MX7) ? 0x200 : 0x2))
 
-/*
- * ++  0x0 (DDR_UIMAGE_START) -
- * |   Header   |  |
- * ++  0x40|
- * ||  |
- * ||  |
- * ||  |
- * ||  |
- * | Image Data |  |
- * .|  |
- * .|   > Stuff to be authenticated +
- * .|  ||
- * ||  ||
- * ||  ||
- * ++  ||
- * ||  ||
- * | Fill Data  |  ||
- * ||  ||
- * ++ Align to ALIGN_SIZE  ||
- * |IVT |  ||
- * ++ + IVT_SIZE  - |
- * ||   |
- * |  CSF DATA  | <-+
- * ||
- * ++
- * ||
- * | Fill Data  |
- * ||
- * ++ + CSF_PAD_SIZE
- */
-
 static bool is_hab_enabled(void);
 
 #if !defined(CONFIG_SPL_BUILD)
@@ -361,20 +330,22 @@ int do_hab_status(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 static int do_authenticate_image(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
 {
-   ulong   addr, ivt_offset;
+   ulong   addr, length, ivt_offset;
int rcode = 0;
 
-   if (argc < 3)
+   if (argc < 4)
return CMD_RET_USAGE;
 
addr = simple_strtoul(argv[1], NULL, 16);
-   ivt_offset = simple_strtoul(argv[2], NULL, 16);
+   length = simple_strtoul(argv[2], NULL, 16);
+  

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

2018-01-08 Thread Tom Rini
On Mon, Jan 08, 2018 at 05:54:38PM +0100, Stefano Babic wrote:
> Hi Tom,
> 
> some fixes, please pull from u-boot-imx, thanks !
> 
> The following changes since commit 1314bd1192b4c67d28bdae7eee639588e88090cd:
> 
>   boards: amlogic: khadas-vim: Typo fixup (2018-01-02 07:57:34 -0500)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to ca9d211e2c7801bc3e194d325ece0d3b583b32d2:
> 
>   mtd: nand: mxs_nand_spl: Remove nand size print (2018-01-08 17:37:12
> +0100)
> 
> 
> Christopher Spinrath (3):
>   ARM: imx: cm_fx6: env: use standard variables
>   ARM: imx: cm_fx6: env: support distro boot command
>   ARM: imx: cm_fx6: env: don't run boot scripts twice
> 
> Eran Matityahu (1):
>   imx: spl: Fix NAND bootmode detection
> 
> Eric Nelson (1):
>   mx6: Add board mx6memcal for use in validating DDR
> 
> Fabio Estevam (1):
>   mx6ull: Handle the CONFIG_MX6ULL cases correctly
> 
> Jagan Teki (2):
>   board: engicam: Fix to remove legacy board/icorem6_rqs
>   mtd: nand: mxs_nand_spl: Remove nand size print
> 
> Stefan Agner (3):
>   imx: move CONFIG_SYSCOUNTER_TIMER to Kconfig
>   imx: introduce CONFIG_GPT_TIMER
>   imx: initialize and use generic timer on i.MX 6UL/ULL

It's release day.  How many of these are release day candidate fixes?  I
know the MX6ULL thing is important, and the SPL bootmode thing looks so
too.  I do not know about the rest, are they?  Thanks!

-- 
Tom


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


[U-Boot] [PATCH v5 19/24] arm: imx: hab: Prefix authenticate_image with imx_hab

2018-01-08 Thread Bryan O'Donoghue
Tidy up the HAB namespace a bit by prefixing external functions with
imx_hab. All external facing functions past this point will be prefixed in
the same way to make the fact we are doing IMX HAB activities clear from
reading the code. authenticate_image() could mean anything
imx_hab_authenticate_image() is on the other hand very explicit.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 4 ++--
 arch/arm/mach-imx/hab.c | 6 +++---
 arch/arm/mach-imx/spl.c | 5 +++--
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 14e1220..98bc1bd 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -185,7 +185,7 @@ typedef void hapi_clock_init_t(void);
 
 /* --- end of HAB API updates */
 
-int authenticate_image(uint32_t ddr_start, uint32_t image_size,
-  uint32_t ivt_offset);
+int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
+  uint32_t ivt_offset);
 
 #endif
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index ec85548..7c2f828 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -392,7 +392,7 @@ static int do_authenticate_image(cmd_tbl_t *cmdtp, int 
flag, int argc,
length = simple_strtoul(argv[2], NULL, 16);
ivt_offset = simple_strtoul(argv[3], NULL, 16);
 
-   rcode = authenticate_image(addr, length, ivt_offset);
+   rcode = imx_hab_authenticate_image(addr, length, ivt_offset);
if (rcode == 0)
rcode = CMD_RET_SUCCESS;
else
@@ -435,8 +435,8 @@ static bool is_hab_enabled(void)
return (reg & IS_HAB_ENABLED_BIT) == IS_HAB_ENABLED_BIT;
 }
 
-int authenticate_image(uint32_t ddr_start, uint32_t image_size,
-  uint32_t ivt_offset)
+int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t image_size,
+  uint32_t ivt_offset)
 {
uint32_t load_addr = 0;
size_t bytes;
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index e5d0c35..a5478ce 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -196,8 +196,9 @@ __weak void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
/* HAB looks for the CSF at the end of the authenticated data therefore,
 * we need to subtract the size of the CSF from the actual filesize */
offset = spl_image->size - CONFIG_CSF_SIZE;
-   if (!authenticate_image(spl_image->load_addr,
-   offset + IVT_SIZE + CSF_PAD_SIZE, offset)) {
+   if (!imx_hab_authenticate_image(spl_image->load_addr,
+   offset + IVT_SIZE + CSF_PAD_SIZE,
+   offset)) {
image_entry();
} else {
puts("spl: ERROR:  image authentication unsuccessful\n");
-- 
2.7.4

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


[U-Boot] [PATCH v5 16/24] arm: imx: hab: Add a hab_rvt_check_target to image auth

2018-01-08 Thread Bryan O'Donoghue
Add a hab_rvt_check_target() step to authenticate_image() as a sanity
check for the target memory region authenticate_image() will run over,
prior to making the BootROM authentication callback itself.

This check is recommended by the HAB documentation so it makes sense to
adhere to the guidance and perform that check as directed.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 2a18ea2..079423a 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -437,12 +437,15 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
hab_rvt_authenticate_image_t *hab_rvt_authenticate_image;
hab_rvt_entry_t *hab_rvt_entry;
hab_rvt_exit_t *hab_rvt_exit;
+   hab_rvt_check_target_t *hab_rvt_check_target;
struct ivt *ivt;
struct ivt_header *ivt_hdr;
+   enum hab_status status;
 
hab_rvt_authenticate_image = hab_rvt_authenticate_image_p;
hab_rvt_entry = hab_rvt_entry_p;
hab_rvt_exit = hab_rvt_exit_p;
+   hab_rvt_check_target = hab_rvt_check_target_p;
 
if (!is_hab_enabled()) {
puts("hab fuse not enabled\n");
@@ -478,6 +481,12 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
goto hab_caam_clock_disable;
}
 
+   status = hab_rvt_check_target(HAB_TGT_MEMORY, (void *)ddr_start, bytes);
+   if (status != HAB_SUCCESS) {
+   printf("HAB check target 0x%08x-0x%08x fail\n",
+  ddr_start, ddr_start + bytes);
+   goto hab_caam_clock_disable;
+   }
 #ifdef DEBUG
printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n", ivt_offset, ivt_addr);
printf("ivt entry = 0x%08x, dcd = 0x%08x, csf = 0x%08x\n", ivt->entry,
-- 
2.7.4

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


[U-Boot] [PATCH v5 24/24] arm: imx: hab: Add hab_failsafe console command

2018-01-08 Thread Bryan O'Donoghue
hab_failsafe when called puts the part into BootROM recovery mode.
This will allow u-boot scripts to script the dropping down into recovery
mode.

=> hab_failsafe

Shows the i.MX7 appear as "hiddev0,hidraw5: USB HID v1.10 Device [Freescale
SemiConductor Inc  SP Blank ULT1] " in a Linux dmesg thus allowing download
of a new image via the BootROM USB download protocol routine.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index f39b320..c0e04fa 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -414,6 +414,22 @@ static int do_authenticate_image(cmd_tbl_t *cmdtp, int 
flag, int argc,
return rcode;
 }
 
+static int do_hab_failsafe(cmd_tbl_t *cmdtp, int flag, int argc,
+  char * const argv[])
+{
+   hab_rvt_failsafe_t *hab_rvt_failsafe;
+
+   if (argc != 1) {
+   cmd_usage(cmdtp);
+   return 1;
+   }
+
+   hab_rvt_failsafe = hab_rvt_failsafe_p;
+   hab_rvt_failsafe();
+
+   return 0;
+}
+
 U_BOOT_CMD(
hab_status, CONFIG_SYS_MAXARGS, 1, do_hab_status,
"display HAB status",
@@ -429,6 +445,11 @@ U_BOOT_CMD(
"ivt_offset - hex offset of IVT in the image"
  );
 
+U_BOOT_CMD(
+   hab_failsafe, CONFIG_SYS_MAXARGS, 1, do_hab_failsafe,
+   "run BootROM failsafe routine",
+   ""
+ );
 
 #endif /* !defined(CONFIG_SPL_BUILD) */
 
-- 
2.7.4

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


[U-Boot] [PATCH v5 23/24] arm: imx: hab: Implement hab_rvt_failsafe

2018-01-08 Thread Bryan O'Donoghue
This patch implements the basic callback hooks for
hab_rvt_check_failsafe for BootROM code using the older BootROM address
layout - in my test case the i.MX7. Code based on new BootROM callbacks
will just do nothing and there's definitely a TODO to implement that extra
functionality on the alternative BootROM API.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 86b4018..f39b320 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -70,6 +70,21 @@
((hab_rvt_exit_t *)HAB_RVT_EXIT)\
 )
 
+static inline void hab_rvt_failsafe_new(void)
+{
+}
+
+#define hab_rvt_failsafe_p \
+(  \
+   (is_mx6dqp()) ? \
+   ((hab_rvt_failsafe_t *)hab_rvt_failsafe_new) :  \
+   (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ?   \
+   ((hab_rvt_failsafe_t *)hab_rvt_failsafe_new) :  \
+   (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ?  \
+   ((hab_rvt_failsafe_t *)hab_rvt_failsafe_new) :  \
+   ((hab_rvt_failsafe_t *)HAB_RVT_FAILSAFE)\
+)
+
 static inline enum hab_status hab_rvt_check_target_new(enum hab_target target,
   const void *start,
   size_t bytes)
-- 
2.7.4

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


[U-Boot] [PATCH v5 15/24] arm: imx: hab: Implement hab_rvt_check_target

2018-01-08 Thread Bryan O'Donoghue
This patch implements the basic callback hooks for hab_rvt_check_target()
for BootROM code using the older BootROM address layout - in my test case
the i.MX7. Code based on new BootROM callbacks will just have HAB_SUCCESS
as a result code. Adding support for the new BootROM callbacks is a TODO.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 364bd6b..2a18ea2 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -70,6 +70,24 @@
((hab_rvt_exit_t *)HAB_RVT_EXIT)\
 )
 
+static inline enum hab_status hab_rvt_check_target_new(enum hab_target target,
+  const void *start,
+  size_t bytes)
+{
+   return HAB_SUCCESS;
+}
+
+#define hab_rvt_check_target_p \
+(  \
+   (is_mx6dqp()) ? \
+   ((hab_rvt_check_target_t *)hab_rvt_check_target_new) :  \
+   (is_mx6dq() && (soc_rev() >= CHIP_REV_1_5)) ?   \
+   ((hab_rvt_check_target_t *)hab_rvt_check_target_new) :  \
+   (is_mx6sdl() && (soc_rev() >= CHIP_REV_1_2)) ?  \
+   ((hab_rvt_check_target_t *)hab_rvt_check_target_new) :  \
+   ((hab_rvt_check_target_t *)HAB_RVT_CHECK_TARGET)\
+)
+
 #define ALIGN_SIZE 0x1000
 #define MX6DQ_PU_IROM_MMU_EN_VAR   0x009024a8
 #define MX6DLS_PU_IROM_MMU_EN_VAR  0x00901dd0
-- 
2.7.4

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


[U-Boot] [PATCH v5 13/24] arm: imx: hab: Print additional IVT elements during debug

2018-01-08 Thread Bryan O'Donoghue
This patch enables printout of the IVT entry, dcd and csf data fields.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 229c723..364bd6b 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -462,6 +462,8 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
 
 #ifdef DEBUG
printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n", ivt_offset, ivt_addr);
+   printf("ivt entry = 0x%08x, dcd = 0x%08x, csf = 0x%08x\n", ivt->entry,
+  ivt->dcd, ivt->csf);
puts("Dumping IVT\n");
print_buffer(ivt_addr, (void *)(ivt_addr), 4, 0x8, 0);
 
-- 
2.7.4

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


[U-Boot] [PATCH v5 20/24] arm: imx: hab: Rename is_hab_enabled imx_hab_is_enabled

2018-01-08 Thread Bryan O'Donoghue
Understanding if the HAB is enabled is something that we want to
interrogate and report on outside of the HAB layer. First step to that is
renaming the relevant function to match the previously introduced external
naming convention imx_hab_function()

The name imx_hab_is_hab_enabled() is a tautology. A more logical name is
imx_hab_is_enabled().

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 7c2f828..d917ac3 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -96,7 +96,7 @@ static inline enum hab_status hab_rvt_check_target_new(enum 
hab_target target,
(is_soc_type(MXC_SOC_MX7ULP) ? 0x8000 : \
 (is_soc_type(MXC_SOC_MX7) ? 0x200 : 0x2))
 
-static bool is_hab_enabled(void);
+static bool imx_hab_is_enabled(void);
 
 static int ivt_header_error(const char *err_str, struct ivt_header *ivt_hdr)
 {
@@ -334,7 +334,7 @@ static int get_hab_status(void)
hab_rvt_report_event = hab_rvt_report_event_p;
hab_rvt_report_status = hab_rvt_report_status_p;
 
-   if (is_hab_enabled())
+   if (imx_hab_is_enabled())
puts("\nSecure boot enabled\n");
else
puts("\nSecure boot disabled\n");
@@ -419,7 +419,7 @@ U_BOOT_CMD(
 
 #endif /* !defined(CONFIG_SPL_BUILD) */
 
-static bool is_hab_enabled(void)
+static bool imx_hab_is_enabled(void)
 {
struct imx_sec_config_fuse_t *fuse =
(struct imx_sec_config_fuse_t *)_sec_config_fuse;
@@ -456,7 +456,7 @@ int imx_hab_authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
hab_rvt_exit = hab_rvt_exit_p;
hab_rvt_check_target = hab_rvt_check_target_p;
 
-   if (!is_hab_enabled()) {
+   if (!imx_hab_is_enabled()) {
puts("hab fuse not enabled\n");
return result;
}
-- 
2.7.4

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


[U-Boot] [PATCH v5 14/24] arm: imx: hab: Define rvt_check_target()

2018-01-08 Thread Bryan O'Donoghue
The hab_rvt_check_target() callback according to the HABv4 documentation:

"This function reports whether or not a given target region is allowed for
 either peripheral configuration or image loading in memory. It is intended
 for use by post-ROM boot stage components, via the ROM Vector Table, in
 order to avoid configuring security-sensitive peripherals, or loading
 images over sensitive memory regions or outside recognized memory devices
 in the address map."

It is a useful function to support as a precursor to calling into
authenticate_image() to validate the target memory region is good.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 28cde38..14e1220 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -113,6 +113,12 @@ enum hab_context {
HAB_CTX_MAX
 };
 
+enum hab_target {
+   HAB_TGT_MEMORY  = 0x0f,
+   HAB_TGT_PERIPHERAL  = 0xf0,
+   HAB_TGT_ANY = 0x55,
+};
+
 struct imx_sec_config_fuse_t {
int bank;
int word;
@@ -132,6 +138,8 @@ typedef enum hab_status hab_rvt_entry_t(void);
 typedef enum hab_status hab_rvt_exit_t(void);
 typedef void *hab_rvt_authenticate_image_t(uint8_t, ptrdiff_t,
void **, size_t *, hab_loader_callback_f_t);
+typedef enum hab_status hab_rvt_check_target_t(enum hab_target, const void *,
+  size_t);
 typedef void hapi_clock_init_t(void);
 
 #define HAB_ENG_ANY0x00   /* Select first compatible engine */
@@ -158,6 +166,7 @@ typedef void hapi_clock_init_t(void);
 
 #define HAB_RVT_ENTRY  (*(uint32_t *)(HAB_RVT_BASE + 0x04))
 #define HAB_RVT_EXIT   (*(uint32_t *)(HAB_RVT_BASE + 0x08))
+#define HAB_RVT_CHECK_TARGET   (*(uint32_t *)(HAB_RVT_BASE + 0x0C))
 #define HAB_RVT_AUTHENTICATE_IMAGE (*(uint32_t *)(HAB_RVT_BASE + 0x10))
 #define HAB_RVT_REPORT_EVENT   (*(uint32_t *)(HAB_RVT_BASE + 0x20))
 #define HAB_RVT_REPORT_STATUS  (*(uint32_t *)(HAB_RVT_BASE + 0x24))
-- 
2.7.4

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


[U-Boot] [PATCH v5 12/24] arm: imx: hab: Print CSF based on IVT descriptor

2018-01-08 Thread Bryan O'Donoghue
The IVT gives the absolute address of the CSF. There is no requirement for
the CSF to be located adjacent to the IVT so lets use the address provided
in the IVT header instead of the hard-coded fixed CSF offset currently in
place.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index a8e3e79..229c723 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -466,8 +466,7 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
print_buffer(ivt_addr, (void *)(ivt_addr), 4, 0x8, 0);
 
puts("Dumping CSF Header\n");
-   print_buffer(ivt_addr + IVT_SIZE, (void *)(ivt_addr + IVT_SIZE), 4,
-0x10, 0);
+   print_buffer(ivt->csf, (void *)(ivt->csf), 4, 0x10, 0);
 
 #if  !defined(CONFIG_SPL_BUILD)
get_hab_status();
-- 
2.7.4

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


[U-Boot] [PATCH v5 06/24] arm: imx: hab: Move CSF_PAD_SIZE to hab.h

2018-01-08 Thread Bryan O'Donoghue
CSF_PAD_SIZE should be defined in hab.h, move it to that location now.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 1 +
 arch/arm/mach-imx/hab.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 3c19d2e..91dda42 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -144,6 +144,7 @@ typedef void hapi_clock_init_t(void);
 #define HAB_CID_UBOOT 1 /**< UBOOT Caller ID*/
 
 #define IVT_SIZE   0x20
+#define CSF_PAD_SIZE   0x2000
 
 /* --- end of HAB API updates */
 
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 6367562..039a017 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -71,7 +71,6 @@
 )
 
 #define ALIGN_SIZE 0x1000
-#define CSF_PAD_SIZE   0x2000
 #define MX6DQ_PU_IROM_MMU_EN_VAR   0x009024a8
 #define MX6DLS_PU_IROM_MMU_EN_VAR  0x00901dd0
 #define MX6SL_PU_IROM_MMU_EN_VAR   0x00900a18
-- 
2.7.4

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


[U-Boot] [PATCH v5 08/24] arm: imx: hab: Add IVT header definitions

2018-01-08 Thread Bryan O'Donoghue
The various i.MX BootROMs containing the High Assurance Boot (HAB) block
rely on a data structure called the Image Vector Table (IVT) to describe to
the BootROM where to locate various data-structures used by HAB during
authentication.

This patch adds a definition of the IVT header for use in later patches,
where we will break the current incorrect dependence on fixed offsets in
favour of an IVT described parsing of incoming binaries.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index b2a8031..28cde38 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -10,6 +10,34 @@
 
 #include 
 
+/*
+ * IVT header definitions
+ * Security Reference Manual for i.MX 7Dual and 7Solo Applications Processors,
+ * Rev. 0, 03/2017
+ * Section : 6.7.1.1
+ */
+#define IVT_HEADER_MAGIC   0xD1
+#define IVT_TOTAL_LENGTH   0x20
+#define IVT_HEADER_V1  0x40
+#define IVT_HEADER_V2  0x41
+
+struct ivt_header {
+   uint8_t magic;
+   uint16_tlength;
+   uint8_t version;
+} __attribute__((packed));
+
+struct ivt {
+   struct ivt_header hdr;  /* IVT header above */
+   uint32_t entry; /* Absolute address of first instruction */
+   uint32_t reserved1; /* Reserved should be zero */
+   uint32_t dcd;   /* Absolute address of the image DCD */
+   uint32_t boot;  /* Absolute address of the boot data */
+   uint32_t self;  /* Absolute address of the IVT */
+   uint32_t csf;   /* Absolute address of the CSF */
+   uint32_t reserved2; /* Reserved should be zero */
+};
+
 /*  start of HAB API updates */
 /* The following are taken from HAB4 SIS */
 
-- 
2.7.4

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


[U-Boot] [PATCH v5 10/24] arm: imx: hab: Verify IVT self matches calculated address

2018-01-08 Thread Bryan O'Donoghue
The IVT is a self-describing structure which contains a self field. The
self field is the absolute physical base address the IVT ought to be at in
memory. Use the IVT self field to validate the calculated ivt_addr bugging
out if the two values differ.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 998d253..39f8f2d 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -450,6 +450,13 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
if (verify_ivt_header(ivt_hdr))
goto hab_caam_clock_disable;
 
+   /* Verify IVT body */
+   if (ivt->self != ivt_addr) {
+   printf("ivt->self 0x%08x pointer is 0x%08x\n",
+  ivt->self, ivt_addr);
+   goto hab_caam_clock_disable;
+   }
+
start = ddr_start;
bytes = image_size;
 #ifdef DEBUG
-- 
2.7.4

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


[U-Boot] [PATCH v5 03/24] arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail

2018-01-08 Thread Bryan O'Donoghue
There is no need to call is_enabled() twice in authenticate_image - it does
nothing but add an additional layer of indentation.

We can check for is_enabled() at the start of the function and return the
result code directly.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 138 
 1 file changed, 69 insertions(+), 69 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 9fe6d43..6f86c02 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -428,91 +428,91 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size)
hab_rvt_entry = hab_rvt_entry_p;
hab_rvt_exit = hab_rvt_exit_p;
 
-   if (is_hab_enabled()) {
-   printf("\nAuthenticate image from DDR location 0x%x...\n",
-  ddr_start);
+   if (!is_hab_enabled()) {
+   puts("hab fuse not enabled\n");
+   return result;
+   }
 
-   hab_caam_clock_enable(1);
+   printf("\nAuthenticate image from DDR location 0x%x...\n",
+  ddr_start);
 
-   if (hab_rvt_entry() == HAB_SUCCESS) {
-   /* If not already aligned, Align to ALIGN_SIZE */
-   ivt_offset = (image_size + ALIGN_SIZE - 1) &
-   ~(ALIGN_SIZE - 1);
+   hab_caam_clock_enable(1);
 
-   start = ddr_start;
-   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
+   if (hab_rvt_entry() == HAB_SUCCESS) {
+   /* If not already aligned, Align to ALIGN_SIZE */
+   ivt_offset = (image_size + ALIGN_SIZE - 1) &
+   ~(ALIGN_SIZE - 1);
+
+   start = ddr_start;
+   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
 #ifdef DEBUG
-   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
-  ivt_offset, ddr_start + ivt_offset);
-   puts("Dumping IVT\n");
-   print_buffer(ddr_start + ivt_offset,
-(void *)(ddr_start + ivt_offset),
-4, 0x8, 0);
-
-   puts("Dumping CSF Header\n");
-   print_buffer(ddr_start + ivt_offset+IVT_SIZE,
-(void *)(ddr_start + ivt_offset+IVT_SIZE),
-4, 0x10, 0);
+   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
+  ivt_offset, ddr_start + ivt_offset);
+   puts("Dumping IVT\n");
+   print_buffer(ddr_start + ivt_offset,
+(void *)(ddr_start + ivt_offset),
+4, 0x8, 0);
+
+   puts("Dumping CSF Header\n");
+   print_buffer(ddr_start + ivt_offset + IVT_SIZE,
+(void *)(ddr_start + ivt_offset + IVT_SIZE),
+4, 0x10, 0);
 
 #if  !defined(CONFIG_SPL_BUILD)
-   get_hab_status();
+   get_hab_status();
 #endif
 
-   puts("\nCalling authenticate_image in ROM\n");
-   printf("\tivt_offset = 0x%x\n", ivt_offset);
-   printf("\tstart = 0x%08lx\n", start);
-   printf("\tbytes = 0x%x\n", bytes);
+   puts("\nCalling authenticate_image in ROM\n");
+   printf("\tivt_offset = 0x%x\n", ivt_offset);
+   printf("\tstart = 0x%08lx\n", start);
+   printf("\tbytes = 0x%x\n", bytes);
 #endif
-   /*
-* If the MMU is enabled, we have to notify the ROM
-* code, or it won't flush the caches when needed.
-* This is done, by setting the "pu_irom_mmu_enabled"
-* word to 1. You can find its address by looking in
-* the ROM map. This is critical for
-* authenticate_image(). If MMU is enabled, without
-* setting this bit, authentication will fail and may
-* crash.
-*/
-   /* Check MMU enabled */
-   if (is_soc_type(MXC_SOC_MX6) && get_cr() & CR_M) {
-   if (is_mx6dq()) {
-   /*
-* This won't work on Rev 1.0.0 of
-* i.MX6Q/D, since their ROM doesn't
-  

[U-Boot] [PATCH v5 11/24] arm: imx: hab: Only call ROM once headers are verified

2018-01-08 Thread Bryan O'Donoghue
Previous patches added IVT header verification steps. We shouldn't call
hab_rvt_entry() until we have done the basic header verification steps.

This patch changes the time we make the hab_rvt_entry() call so that it
only takes place if we are happy with the IVT header sanity checks.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 39f8f2d..a8e3e79 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -436,11 +436,6 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
 
hab_caam_clock_enable(1);
 
-   if (hab_rvt_entry() != HAB_SUCCESS) {
-   puts("hab entry function fail\n");
-   goto hab_caam_clock_disable;
-   }
-
/* Calculate IVT address header */
ivt_addr = ddr_start + ivt_offset;
ivt = (struct ivt *)ivt_addr;
@@ -459,6 +454,12 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
 
start = ddr_start;
bytes = image_size;
+
+   if (hab_rvt_entry() != HAB_SUCCESS) {
+   puts("hab entry function fail\n");
+   goto hab_caam_clock_disable;
+   }
+
 #ifdef DEBUG
printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n", ivt_offset, ivt_addr);
puts("Dumping IVT\n");
-- 
2.7.4

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


[U-Boot] [PATCH v5 02/24] arm: imx: hab: Fix authenticate_image result code

2018-01-08 Thread Bryan O'Donoghue
authenticate_image returns 1 for success and 0 for failure. That result
code is mapped directly to the result code for the command line function
hab_auth_img - which means when hab_auth_img succeeds it is returning
CMD_RET_FAILURE (1) instead of CMD_RET_SUCCESS (0).

This patch fixes this behaviour by making authenticate_image() return 0 for
success and 1 for failure. Both users of authenticate_image() as a result
have some minimal churn. The upshot is once done when hab_auth_img is
called from the command line we set $? in the standard way for scripting
functions to act on.

Fixes: 36c1ca4d46ef ("imx: Support i.MX6 High Assurance Boot
authentication")

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 9 ++---
 arch/arm/mach-imx/spl.c | 4 ++--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 09892a6..9fe6d43 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -373,7 +373,10 @@ static int do_authenticate_image(cmd_tbl_t *cmdtp, int 
flag, int argc,
ivt_offset = simple_strtoul(argv[2], NULL, 16);
 
rcode = authenticate_image(addr, ivt_offset);
-
+   if (rcode == 0)
+   rcode = CMD_RET_SUCCESS;
+   else
+   rcode = CMD_RET_FAILURE;
return rcode;
 }
 
@@ -415,7 +418,7 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size)
uint32_t load_addr = 0;
size_t bytes;
ptrdiff_t ivt_offset = 0;
-   int result = 0;
+   int result = 1;
ulong start;
hab_rvt_authenticate_image_t *hab_rvt_authenticate_image;
hab_rvt_entry_t *hab_rvt_entry;
@@ -510,7 +513,7 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size)
}
 
if ((!is_hab_enabled()) || (load_addr != 0))
-   result = 1;
+   result = 0;
 
return result;
 }
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index d0d1b73..6e930b3 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -163,8 +163,8 @@ __weak void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
 
/* HAB looks for the CSF at the end of the authenticated data therefore,
 * we need to subtract the size of the CSF from the actual filesize */
-   if (authenticate_image(spl_image->load_addr,
-  spl_image->size - CONFIG_CSF_SIZE)) {
+   if (!authenticate_image(spl_image->load_addr,
+   spl_image->size - CONFIG_CSF_SIZE)) {
image_entry();
} else {
puts("spl: ERROR:  image authentication unsuccessful\n");
-- 
2.7.4

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


[U-Boot] [PATCH v5 04/24] arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail

2018-01-08 Thread Bryan O'Donoghue
The current code disjoins an entire block of code on hab_entry pass/fail
resulting in a large chunk of authenticate_image being offset to the right.

Fix this by checking hab_entry() pass/failure and exiting the function
directly if in an error state.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 118 
 1 file changed, 60 insertions(+), 58 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 6f86c02..f878b7b 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -438,75 +438,77 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size)
 
hab_caam_clock_enable(1);
 
-   if (hab_rvt_entry() == HAB_SUCCESS) {
-   /* If not already aligned, Align to ALIGN_SIZE */
-   ivt_offset = (image_size + ALIGN_SIZE - 1) &
-   ~(ALIGN_SIZE - 1);
+   if (hab_rvt_entry() != HAB_SUCCESS) {
+   puts("hab entry function fail\n");
+   goto hab_caam_clock_disable;
+   }
 
-   start = ddr_start;
-   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
+   /* If not already aligned, Align to ALIGN_SIZE */
+   ivt_offset = (image_size + ALIGN_SIZE - 1) &
+   ~(ALIGN_SIZE - 1);
+
+   start = ddr_start;
+   bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
 #ifdef DEBUG
-   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
-  ivt_offset, ddr_start + ivt_offset);
-   puts("Dumping IVT\n");
-   print_buffer(ddr_start + ivt_offset,
-(void *)(ddr_start + ivt_offset),
-4, 0x8, 0);
-
-   puts("Dumping CSF Header\n");
-   print_buffer(ddr_start + ivt_offset + IVT_SIZE,
-(void *)(ddr_start + ivt_offset + IVT_SIZE),
-4, 0x10, 0);
+   printf("\nivt_offset = 0x%x, ivt addr = 0x%x\n",
+  ivt_offset, ddr_start + ivt_offset);
+   puts("Dumping IVT\n");
+   print_buffer(ddr_start + ivt_offset,
+(void *)(ddr_start + ivt_offset),
+4, 0x8, 0);
+
+   puts("Dumping CSF Header\n");
+   print_buffer(ddr_start + ivt_offset + IVT_SIZE,
+(void *)(ddr_start + ivt_offset + IVT_SIZE),
+4, 0x10, 0);
 
 #if  !defined(CONFIG_SPL_BUILD)
-   get_hab_status();
+   get_hab_status();
 #endif
 
-   puts("\nCalling authenticate_image in ROM\n");
-   printf("\tivt_offset = 0x%x\n", ivt_offset);
-   printf("\tstart = 0x%08lx\n", start);
-   printf("\tbytes = 0x%x\n", bytes);
+   puts("\nCalling authenticate_image in ROM\n");
+   printf("\tivt_offset = 0x%x\n", ivt_offset);
+   printf("\tstart = 0x%08lx\n", start);
+   printf("\tbytes = 0x%x\n", bytes);
 #endif
-   /*
-* If the MMU is enabled, we have to notify the ROM
-* code, or it won't flush the caches when needed.
-* This is done, by setting the "pu_irom_mmu_enabled"
-* word to 1. You can find its address by looking in
-* the ROM map. This is critical for
-* authenticate_image(). If MMU is enabled, without
-* setting this bit, authentication will fail and may
-* crash.
-*/
-   /* Check MMU enabled */
-   if (is_soc_type(MXC_SOC_MX6) && get_cr() & CR_M) {
-   if (is_mx6dq()) {
-   /*
-* This won't work on Rev 1.0.0 of
-* i.MX6Q/D, since their ROM doesn't
-* do cache flushes. don't think any
-* exist, so we ignore them.
-*/
-   if (!is_mx6dqp())
-   writel(1, MX6DQ_PU_IROM_MMU_EN_VAR);
-   } else if (is_mx6sdl()) {
-   writel(1, MX6DLS_PU_IROM_MMU_EN_VAR);
-   } else if (is_mx6sl()) {
-   writel(1, MX6SL_PU_IROM_MMU_EN_VAR);
-   }
+   /*
+* If the MMU is enabled, we have to notify the ROM
+* code, or it won't flush the caches when needed.
+* This is done, by setting the "pu_irom_mmu_enabled"
+* word to 1. You can find its address by looking in
+* the ROM map. 

[U-Boot] [PATCH v5 01/24] arm: imx: hab: Make authenticate_image return int

2018-01-08 Thread Bryan O'Donoghue
Both usages of authenticate_image treat the result code as a simple binary.
The command line usage of authenticate_image directly returns the result
code of authenticate_image as a success/failure code.

Right now when calling hab_auth_img and test the result code in a shell a
passing hab_auth_img will appear to the shell as a fail.

The first step in fixing this behaviour is to fix-up the result code return
by authenticate_image() itself, subsequent patches fix the interpretation
of authenticate_image so that zero will return CMD_RET_SUCCESS and non-zero
will return CMD_RET_FAILURE.

The first step is fixing the return type in authenticate_image() so do that
now.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/include/asm/mach-imx/hab.h | 2 +-
 arch/arm/mach-imx/hab.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index e0ff459..1b7a5e4 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -145,6 +145,6 @@ typedef void hapi_clock_init_t(void);
 
 /* --- end of HAB API updates */
 
-uint32_t authenticate_image(uint32_t ddr_start, uint32_t image_size);
+int authenticate_image(uint32_t ddr_start, uint32_t image_size);
 
 #endif
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 02c7ae4..09892a6 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -410,7 +410,7 @@ static bool is_hab_enabled(void)
return (reg & IS_HAB_ENABLED_BIT) == IS_HAB_ENABLED_BIT;
 }
 
-uint32_t authenticate_image(uint32_t ddr_start, uint32_t image_size)
+int authenticate_image(uint32_t ddr_start, uint32_t image_size)
 {
uint32_t load_addr = 0;
size_t bytes;
-- 
2.7.4

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


[U-Boot] [PATCH v5 00/24] Fix and extend i.MX HAB layer

2018-01-08 Thread Bryan O'Donoghue
v5:
- Drop dcache disable across HAB call.
  We can't replicate this error on the current codebase and the available
  images. We'll have to wait for the error to crop up again before pushing
  that patch any further.

v4:
- No change mixed extra patches @ v3 unnoticed with previous
  git-send

v3:
- Only call into ROM if headers are verified. - Bryan

- Print HAB event log if and only if a call was made to HAB
  and a meaningful status code has been obtained. - Breno

v2:
- Fix compilation warnings and errors in SPL highlighted by 
  Breno Matheus Lima

- Add CC: Breno Matheus Lima  to all patches

v1:
This patchset updates the i.MX HAB layer in u-boot to fix a list of
identified issues and then to add and extend existing functionality.

The first block of patches 0001-0006 deal with fixing existing code,

- Fixes indentation
- Fixes the treatment of input parameters to hab_auth_image.

The second block of patches 0007-0013 are about tidying up the HAB code

- Remove reliance on hard-coding to specific offsets
- IVT header drives locating CSF
- Continue to support existing boards

Patches 0014 onwards extend out the HAB functionality.

- hab_rvt_check_target is a recommended check in the NXP documents to
  perform prior to hab_rvt_authenticate_image
- hab_rvt_failsafe is a useful function to set the board into BootROM
  USB recovery mode.


Bryan O'Donoghue (24):
  arm: imx: hab: Make authenticate_image return int
  arm: imx: hab: Fix authenticate_image result code
  arm: imx: hab: Optimise flow of authenticate_image on is_enabled fail
  arm: imx: hab: Optimise flow of authenticate_image on hab_entry fail
  arm: imx: hab: Move IVT_SIZE to hab.h
  arm: imx: hab: Move CSF_PAD_SIZE to hab.h
  arm: imx: hab: Fix authenticate_image input parameters
  arm: imx: hab: Add IVT header definitions
  arm: imx: hab: Add IVT header verification
  arm: imx: hab: Verify IVT self matches calculated address
  arm: imx: hab: Only call ROM once headers are verified
  arm: imx: hab: Print CSF based on IVT descriptor
  arm: imx: hab: Print additional IVT elements during debug
  arm: imx: hab: Define rvt_check_target()
  arm: imx: hab: Implement hab_rvt_check_target
  arm: imx: hab: Add a hab_rvt_check_target to image auth
  arm: imx: hab: Print HAB event log only after calling ROM
  arm: imx: hab: Make internal functions and data static
  arm: imx: hab: Prefix authenticate_image with imx_hab
  arm: imx: hab: Rename is_hab_enabled imx_hab_is_enabled
  arm: imx: hab: Make imx_hab_is_enabled global
  arm: imx: hab: Define rvt_failsafe()
  arm: imx: hab: Implement hab_rvt_failsafe
  arm: imx: hab: Add hab_failsafe console command

 arch/arm/include/asm/mach-imx/hab.h |  46 +++-
 arch/arm/mach-imx/hab.c | 461 +---
 arch/arm/mach-imx/spl.c |  38 ++-
 3 files changed, 354 insertions(+), 191 deletions(-)

-- 
2.7.4

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


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

2018-01-08 Thread Stefano Babic
Hi Tom,

some fixes, please pull from u-boot-imx, thanks !

The following changes since commit 1314bd1192b4c67d28bdae7eee639588e88090cd:

  boards: amlogic: khadas-vim: Typo fixup (2018-01-02 07:57:34 -0500)

are available in the git repository at:

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

for you to fetch changes up to ca9d211e2c7801bc3e194d325ece0d3b583b32d2:

  mtd: nand: mxs_nand_spl: Remove nand size print (2018-01-08 17:37:12
+0100)


Christopher Spinrath (3):
  ARM: imx: cm_fx6: env: use standard variables
  ARM: imx: cm_fx6: env: support distro boot command
  ARM: imx: cm_fx6: env: don't run boot scripts twice

Eran Matityahu (1):
  imx: spl: Fix NAND bootmode detection

Eric Nelson (1):
  mx6: Add board mx6memcal for use in validating DDR

Fabio Estevam (1):
  mx6ull: Handle the CONFIG_MX6ULL cases correctly

Jagan Teki (2):
  board: engicam: Fix to remove legacy board/icorem6_rqs
  mtd: nand: mxs_nand_spl: Remove nand size print

Stefan Agner (3):
  imx: move CONFIG_SYSCOUNTER_TIMER to Kconfig
  imx: introduce CONFIG_GPT_TIMER
  imx: initialize and use generic timer on i.MX 6UL/ULL

 arch/arm/include/asm/arch-mx6/imx-regs.h   |  24 +++--
 arch/arm/include/asm/arch-mx6/mx6-ddr.h|   2 +-
 arch/arm/include/asm/arch-mx6/mx6ul-ddr.h  |   2 +-
 arch/arm/include/asm/mach-imx/iomux-v3.h   |   4 +-
 arch/arm/include/asm/mach-imx/regs-lcdif.h |  19 ++--
 arch/arm/include/asm/mach-imx/sys_proto.h  |   3 +-
 arch/arm/mach-imx/Kconfig  |   6 ++
 arch/arm/mach-imx/Makefile |   5 +-
 arch/arm/mach-imx/mx5/Kconfig  |   1 +
 arch/arm/mach-imx/mx6/Kconfig  |  14 ++-
 arch/arm/mach-imx/mx6/ddr.c|   2 +-
 arch/arm/mach-imx/mx7/Kconfig  |   1 +
 arch/arm/mach-imx/spl.c|   2 +-
 board/engicam/common/board.c   |   2 +-
 board/engicam/icorem6_rqs/icorem6_rqs.c|  48 -
 board/freescale/mx6memcal/Kconfig  | 235

 board/freescale/mx6memcal/MAINTAINERS  |   7 ++
 board/freescale/mx6memcal/Makefile |  13 +++
 board/freescale/mx6memcal/README   |  49 ++
 board/freescale/mx6memcal/mx6memcal.c  |  32 ++
 board/freescale/mx6memcal/spl.c| 456
+
 configs/cm_fx6_defconfig   |   2 +
 configs/mx6memcal_defconfig|  33 +++
 drivers/gpio/mxc_gpio.c|   4 +-
 drivers/mtd/nand/mxs_nand_spl.c|   2 -
 include/configs/cm_fx6.h   |  80 ---
 include/configs/imx6_spl.h |   3 +-
 include/configs/mx6_common.h   |  10 +-
 include/configs/mx6memcal.h|  59 +++
 include/configs/mx7_common.h   |   1 -
 scripts/config_whitelist.txt   |   2 +-
 31 files changed, 1001 insertions(+), 122 deletions(-)
 delete mode 100644 board/engicam/icorem6_rqs/icorem6_rqs.c
 create mode 100644 board/freescale/mx6memcal/Kconfig
 create mode 100644 board/freescale/mx6memcal/MAINTAINERS
 create mode 100644 board/freescale/mx6memcal/Makefile
 create mode 100644 board/freescale/mx6memcal/README
 create mode 100644 board/freescale/mx6memcal/mx6memcal.c
 create mode 100644 board/freescale/mx6memcal/spl.c
 create mode 100644 configs/mx6memcal_defconfig
 create mode 100644 include/configs/mx6memcal.h



-- 
=
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] Making lack-of DM conversion noisy warning

2018-01-08 Thread Simon Glass
Hi Tom,

We set a deadline of 2018.05 to have boards moved over to CONFIG_BLK. That
is a pretty good proxy for conversion.

Some ideas:

1. Add to the release announcement email
2. We could create a patch to remind people when they build a board without
CONFIG_BLK.
3. We could create a list of which boards need to be converted, like the
config_whitelist.txt

Regards,
Simon


On 8 January 2018 at 07:57, Tom Rini  wrote:

> Hey all,
>
> So, my calendar alarm went off today to remind me that we need to make
> the lack of DM conversion more noisy, in order to encourage the
> remaining conversions to happen.
>
> But, off the top of my head, I'm not quite sure of the best way to
> implement that, anyone have an idea?  Thanks!
>
> --
> Tom
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: zynq: Remove ZC770_ config option

2018-01-08 Thread Masahiro Yamada
2018-01-09 0:59 GMT+09:00 Michal Simek :
> This option is obsolete and it is no longer valid.
>
> Signed-off-by: Michal Simek 
> ---

I agree, although
an equivalent patch has been delegated to you for some months.
http://patchwork.ozlabs.org/patch/841993/


The only difference is I did not touch config_whitelist.
It was intentional since I know Tom periodically syncs it anyway.


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


Re: [U-Boot] Please pull u-boot-x86

2018-01-08 Thread Tom Rini
On Mon, Jan 08, 2018 at 05:01:24PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> The following changes since commit ca833ca9579b29c5667ea2fa7a9d3f89f1599a94:
> 
>   Merge git://git.denx.de/u-boot-rockchip (2018-01-03 12:27:12 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to 5d8c4ebd95e23a606a40a73920b8d7d096a91d37:
> 
>   x86: tangier: Add Bluetooth to ACPI table (2018-01-08 16:52:25 +0800)
> 

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 v3] crypto/fsl: fix BLOB encapsulation and decapsulation

2018-01-08 Thread Tom Rini
On Sun, Jan 07, 2018 at 08:26:29PM +0100, Clemens Gruber wrote:

> The blob_encap and blob_decap functions were not flushing the dcache
> before passing data to CAAM/DMA and not invalidating the dcache when
> getting data back.
> Therefore, blob encapsulation and decapsulation failed with errors like
> the following due to data cache incoherency:
> "4006: DECO: desc idx 0: Invalid KEY command"
> 
> To ensure coherency, we require the key_mod, src and dst buffers to be
> aligned to the cache line size and flush/invalidate the memory regions.
> The same requirements apply to the job descriptor.
> 
> Tested on an i.MX6Q board.
> 
> Reviewed-by: Sumit Garg 
> Signed-off-by: Clemens Gruber 

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


[U-Boot] [PATCH] arm: zynq: Remove ZC770_ config option

2018-01-08 Thread Michal Simek
This option is obsolete and it is no longer valid.

Signed-off-by: Michal Simek 
---

 configs/zynq_zc770_xm010_defconfig | 1 -
 configs/zynq_zc770_xm011_defconfig | 1 -
 configs/zynq_zc770_xm012_defconfig | 1 -
 configs/zynq_zc770_xm013_defconfig | 1 -
 scripts/config_whitelist.txt   | 4 
 5 files changed, 8 deletions(-)

diff --git a/configs/zynq_zc770_xm010_defconfig 
b/configs/zynq_zc770_xm010_defconfig
index 897ca91e5606..2b8fb3c9214a 100644
--- a/configs/zynq_zc770_xm010_defconfig
+++ b/configs/zynq_zc770_xm010_defconfig
@@ -7,7 +7,6 @@ CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
-CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM010"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
diff --git a/configs/zynq_zc770_xm011_defconfig 
b/configs/zynq_zc770_xm011_defconfig
index 2b8a12ee6906..52ad66a38f61 100644
--- a/configs/zynq_zc770_xm011_defconfig
+++ b/configs/zynq_zc770_xm011_defconfig
@@ -7,7 +7,6 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm011"
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
-CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM011"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
diff --git a/configs/zynq_zc770_xm012_defconfig 
b/configs/zynq_zc770_xm012_defconfig
index d53fe94db36b..a8338f5c2d82 100644
--- a/configs/zynq_zc770_xm012_defconfig
+++ b/configs/zynq_zc770_xm012_defconfig
@@ -7,7 +7,6 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm012"
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
-CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM012"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
diff --git a/configs/zynq_zc770_xm013_defconfig 
b/configs/zynq_zc770_xm013_defconfig
index e6445f735c57..01e2cfe04fb2 100644
--- a/configs/zynq_zc770_xm013_defconfig
+++ b/configs/zynq_zc770_xm013_defconfig
@@ -7,7 +7,6 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm013"
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
-CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM013"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 43a4ff08928d..c1f1a0085768 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -5058,10 +5058,6 @@ CONFIG_YAFFS_UNICODE
 CONFIG_YAFFS_UTIL
 CONFIG_YAFFS_WINCE
 CONFIG_YELLOW_LED
-CONFIG_ZC770_XM010
-CONFIG_ZC770_XM011
-CONFIG_ZC770_XM012
-CONFIG_ZC770_XM013
 CONFIG_ZLIB
 CONFIG_ZLT
 CONFIG_ZM7300
-- 
1.9.1

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


Re: [U-Boot] [U-Boot, v2, 16/18] clk: rockchip: Add rk322x gamc clock support

2018-01-08 Thread Dr. Philipp Tomsich
David,

As discussed last week (off-list), I implemented infrastructure-support for the
'assigned-clocks', 'assigned-clock-parents' and 'assigned-clock-rates’ 
properties
in the DTS … and validated on the RK3399.

For my work-in-progress tree, see the ‘assigned-clocks-wip’ branch at:
https://github.com/ptomsich/u-boot-rockchip/tree/assigned-clocks-wip

If this is sufficient to solve our clocking-issue on GMAC let me know. I plan to
have some additional time to finish this up for submission around the end of
the week.

@Jakob: This is the change I mentioned this morning that provides infrastructure
to allow setting PLLs via the DTS.  These changes are also on our internal GIT
in the ‘assigned-clocks-wip’ branch (which I manually mirror onto GitHub, so I
can test via Travis-CI).

Comments are welcome,
Phil.

> On 4 Jan 2018, at 14:22, David.Wu  wrote:
> 
> Hi Philipp,
> 
> Could i just make the clock-driver respond to the requested frequency? I.e. 
> 50MHz will most likely always come from the internal sources
> so when 50Mhz for rmii gets requested you just assume that we will use the 
> internal source. And the 125MHz, we assume that we will use the 
> externalsource.
> 
> 在 2017/12/21 19:21, David.Wu 写道:
>> Hi Philipp,
>> 在 2017/11/26 22:50, Philipp Tomsich 写道:
>>> 
>>> On Thu, 9 Nov 2017, David Wu wrote:
>>> 
 Assuming mac_clk is fed by an external clock, set clk_rmii_src
 clock select control register from IO for rgmii interface.
 
 Signed-off-by: David Wu 
 Acked-by: Philipp Tomsich 
>>> 
>>> Reviewed-by: Philipp Tomsich 
>>> 
>>> See below for requested changes.
>>> 
 ---
 
 Changes in v2:
 - New patch
 
 drivers/clk/rockchip/clk_rk322x.c | 13 +
 1 file changed, 13 insertions(+)
 
 diff --git a/drivers/clk/rockchip/clk_rk322x.c 
 b/drivers/clk/rockchip/clk_rk322x.c
 index e87267d..5fd27cd 100644
 --- a/drivers/clk/rockchip/clk_rk322x.c
 +++ b/drivers/clk/rockchip/clk_rk322x.c
 @@ -239,6 +239,16 @@ static ulong rockchip_mmc_get_clk(struct rk322x_cru 
 *cru, uint clk_general_rate,
 return DIV_TO_RATE(src_rate, div) / 2;
 }
 
 +static int rk322x_mac_set_clk(struct rk322x_cru *cru,
 +  int periph, uint freq)
 +{
 +/* Assuming mac_clk is fed by an external clock */
 +rk_clrsetreg(>cru_clksel_con[5], BIT(5),
 + BIT(5));
>>> 
>>> Please use a symbolic constant for BIT(5).
>>> 
>>> If this is the input/output selection for the MAC clk and covered by 
>>> 'clock_in_out = "input";' in the DTS, then the DTS should be consulted 
>>> before assuming a specific setting here.
>>> 
>> Yes, I think so, but not do it now;
>> If it is "input", then actually do not need to set clk rate, as long as the 
>> direction of setting clk, clk rate rely on external clock input may 
>> originate from PHY.
>> If it is "output", then also need to set clk rate.
>> There has been the interface of setting clock rate currently, but not set 
>> the direction. Can we in the GMAC driver directly set cru registers of 
>> mac_clk direction through the dts property of "clk_in_out", otherwise need 
>> clk framework to provide a set of directional interface like setting the 
>> parent of mac_clk.
 +
 +return 0;
 +}
 +
 static ulong rockchip_mmc_set_clk(struct rk322x_cru *cru, uint 
 clk_general_rate,
   int periph, uint freq)
 {
 @@ -352,6 +362,9 @@ static ulong rk322x_clk_set_rate(struct clk *clk, 
 ulong rate)
 case CLK_DDR:
 new_rate = rk322x_ddr_set_clk(priv->cru, rate);
 break;
 +case SCLK_MAC:
 +new_rate = rk322x_mac_set_clk(priv->cru, clk->id, rate);
 +break;
 default:
 return -ENOENT;
 }
 
>>> 
>>> 
>>> 
> 

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


Re: [U-Boot] [PATCH v3 1/1] vsprintf.c: add EFI device path printing

2018-01-08 Thread Heinrich Schuchardt



On 01/08/2018 04:52 AM, Simon Glass wrote:

On 26 December 2017 at 03:07, Heinrich Schuchardt  wrote:

For debugging efi_loader we need the capability to print EFI
device paths. With this patch we can write:

 debug("device path: %pD", dp);

A possible output would be

 device path: /MemoryMapped(0x0,0x3ff93a82,0x3ff93a82)

This enhancement is not available when building without EFI support
and neither in the SPL nor in the API example.

Cc: Wolfgang Denk 
Cc: Simon Glass 
Suggested-by: Rob Clark 
Signed-off-by: Heinrich Schuchardt 
---
I propose Alex picks up this patch for the EFI tree.

v3:
 Return -ENOMEM if out of memory.
 Avoid missing dependency error when building the SPL of the
 API example.
v2:
 Panic if out of memory.
 Wolfgang suggested not to silently ignore an out of memory
 situation.
---
  examples/api/Makefile |  3 +++
  lib/vsprintf.c| 47 +--
  2 files changed, 44 insertions(+), 6 deletions(-)


Can you please add a test for this? It could go in the print unit
tests, perhaps?

Regards,
Simon


test/print_ut.c is only compiled with CONFIG_SANDBOX.

It seems your patches to enable EFI_LOADER in the sandbox did not make 
it into v2018.01. Are you still working on these? Do you have a repo 
with a working copy?


Best regards

Heinrich

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


[U-Boot] Making lack-of DM conversion noisy warning

2018-01-08 Thread Tom Rini
Hey all,

So, my calendar alarm went off today to remind me that we need to make
the lack of DM conversion more noisy, in order to encourage the
remaining conversions to happen.

But, off the top of my head, I'm not quite sure of the best way to
implement that, anyone have an idea?  Thanks!

-- 
Tom


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


[U-Boot] [PATCH 3/4] serial: ns16550: add definitions for register mdr1

2018-01-08 Thread Matthijs van Duin
Signed-off-by: Matthijs van Duin 
---
 drivers/serial/ns16550.c | 10 +-
 include/ns16550.h| 14 ++
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 5ac2469b5760..41eb098c847e 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -166,7 +166,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
 == UART_LSR_THRE) {
if (baud_divisor != -1)
NS16550_setbrg(com_port, baud_divisor);
-   serial_out(0, _port->mdr1);
+   serial_out(UART_MDR1_16X, _port->mdr1);
}
 #endif
 
@@ -175,7 +175,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
 
serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
 #ifdef CONFIG_NS16550_OMAP
-   serial_out(0x7, _port->mdr1);   /* mode select reset TL16C750*/
+   serial_out(UART_MDR1_DISABLE, _port->mdr1);
 #endif
serial_out(UART_MCRVAL, _port->mcr);
serial_out(ns16550_getfcr(com_port), _port->fcr);
@@ -183,7 +183,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
NS16550_setbrg(com_port, baud_divisor);
 #ifdef CONFIG_NS16550_OMAP
/* /16 is proper to hit 115200 with 48MHz */
-   serial_out(0, _port->mdr1);
+   serial_out(UART_MDR1_16X, _port->mdr1);
 #endif
 #ifdef CONFIG_NS16550_C6X
serial_out(UART_REG_VAL_PWREMU_MGMT_UART_ENABLE, _port->pwr_mgmt);
@@ -289,7 +289,7 @@ static inline void _debug_uart_init(void)
baud_divisor = ns16550_calc_divisor(com_port, CONFIG_DEBUG_UART_CLOCK,
CONFIG_BAUDRATE);
serial_dout(_port->ier, CONFIG_SYS_NS16550_IER);
-   serial_dout(_port->mdr1, 0x7);
+   serial_dout(_port->mdr1, UART_MDR1_DISABLE);
serial_dout(_port->mcr, UART_MCRVAL);
serial_dout(_port->fcr, UART_FCR_DEFVAL);
 
@@ -297,7 +297,7 @@ static inline void _debug_uart_init(void)
serial_dout(_port->dll, baud_divisor & 0xff);
serial_dout(_port->dlm, (baud_divisor >> 8) & 0xff);
serial_dout(_port->lcr, UART_LCRVAL);
-   serial_dout(_port->mdr1, 0x0);
+   serial_dout(_port->mdr1, UART_MDR1_16X);
 }
 
 static inline void _debug_uart_putc(int ch)
diff --git a/include/ns16550.h b/include/ns16550.h
index 4a87ab9c8e71..540337258c1e 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -208,6 +208,20 @@ typedef struct NS16550 *NS16550_t;
 /* useful defaults for LCR */
 #define UART_LCR_8N1   0x03
 
+/*
+ * These are the definitions for Mode Definition Register 1
+ */
+#if defined(CONFIG_NS16550_C6X)
+#define UART_MDR1_16X  0x00/* 16x oversampling (default) */
+#define UART_MDR1_13X  0x01/* 13x oversampling */
+#elif defined(CONFIG_NS16550_OMAP)
+#define UART_MDR1_16X  0x00/* 16x oversampling */
+#define UART_MDR1_16X_AUTOBAUD 0x02/* 16x oversampling, auto-baud */
+#define UART_MDR1_13X  0x03/* 13x oversampling */
+#define UART_MDR1_DISABLE  0x07/* disable uart (default) */
+/* other values/bits are for infrared modes */
+#endif
+
 void NS16550_init(NS16550_t com_port, int baud_divisor);
 void NS16550_putc(NS16550_t com_port, char c);
 char NS16550_getc(NS16550_t com_port);
-- 
2.11.0

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


[U-Boot] [PATCH 4/4] serial: ns16550: use 13x oversampling when available

2018-01-08 Thread Matthijs van Duin
This allows much higher baudrates in the standard series to be used, up
to 32 * 115200 = 3686400 bps with 0.16% deviation.

Signed-off-by: Matthijs van Duin 
---
 drivers/serial/ns16550.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 41eb098c847e..a131d1658bd4 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -140,7 +140,11 @@ static u32 ns16550_getfcr(NS16550_t port)
 
 int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
 {
+#ifdef UART_MDR1_13X
+   const unsigned int mode_x_div = 13;
+#else
const unsigned int mode_x_div = 16;
+#endif
 
return DIV_ROUND_CLOSEST(clock, mode_x_div * baudrate);
 }
@@ -181,9 +185,9 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(ns16550_getfcr(com_port), _port->fcr);
if (baud_divisor != -1)
NS16550_setbrg(com_port, baud_divisor);
-#ifdef CONFIG_NS16550_OMAP
-   /* /16 is proper to hit 115200 with 48MHz */
-   serial_out(UART_MDR1_16X, _port->mdr1);
+#ifdef UART_MDR1_13X
+   /* /13 is proper to hit 115200*{1,2,4,8,16,32} with 48MHz */
+   serial_out(UART_MDR1_13X, _port->mdr1);
 #endif
 #ifdef CONFIG_NS16550_C6X
serial_out(UART_REG_VAL_PWREMU_MGMT_UART_ENABLE, _port->pwr_mgmt);
@@ -297,7 +301,7 @@ static inline void _debug_uart_init(void)
serial_dout(_port->dll, baud_divisor & 0xff);
serial_dout(_port->dlm, (baud_divisor >> 8) & 0xff);
serial_dout(_port->lcr, UART_LCRVAL);
-   serial_dout(_port->mdr1, UART_MDR1_16X);
+   serial_dout(_port->mdr1, UART_MDR1_13X);
 }
 
 static inline void _debug_uart_putc(int ch)
-- 
2.11.0

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


[U-Boot] [PATCH 1/4] serial: ns16550: da8xx (freon/primus) is not omap-like

2018-01-08 Thread Matthijs van Duin
These are SoCs in the lineage of TI C6x DSPs, and as such have the same
uart as TI Keystone SoCs.

Signed-off-by: Matthijs van Duin 
---
 drivers/serial/ns16550.c | 8 
 include/ns16550.h| 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index c702304e79bd..9cec58c887c8 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,7 +36,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif
 #endif /* !CONFIG_DM_SERIAL */
 
-#if defined(CONFIG_SOC_KEYSTONE)
+#if defined(CONFIG_SOC_KEYSTONE) || defined(CONFIG_SOC_DA8XX)
 #define UART_REG_VAL_PWREMU_MGMT_UART_DISABLE   0
 #define UART_REG_VAL_PWREMU_MGMT_UART_ENABLE ((1 << 14) | (1 << 13) | (1 << 0))
 #undef UART_MCRVAL
@@ -181,12 +181,12 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(ns16550_getfcr(com_port), _port->fcr);
if (baud_divisor != -1)
NS16550_setbrg(com_port, baud_divisor);
-#if defined(CONFIG_ARCH_OMAP2PLUS) || defined(CONFIG_SOC_DA8XX)
+#if defined(CONFIG_ARCH_OMAP2PLUS)
/* /16 is proper to hit 115200 with 48MHz */
serial_out(0, _port->mdr1);
 #endif
-#if defined(CONFIG_SOC_KEYSTONE)
-   serial_out(UART_REG_VAL_PWREMU_MGMT_UART_ENABLE, _port->regC);
+#if defined(CONFIG_SOC_KEYSTONE) || defined(CONFIG_SOC_DA8XX)
+   serial_out(UART_REG_VAL_PWREMU_MGMT_UART_ENABLE, _port->pwr_mgmt);
 #endif
 }
 
diff --git a/include/ns16550.h b/include/ns16550.h
index 5fcbcd2e74e3..a988d297e144 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -71,7 +71,7 @@ struct NS16550 {
UART_REG(lsr);  /* 5 */
UART_REG(msr);  /* 6 */
UART_REG(spr);  /* 7 */
-#ifdef CONFIG_SOC_DA8XX
+#if defined(CONFIG_SOC_KEYSTONE) || defined(CONFIG_SOC_DA8XX)
UART_REG(reg8); /* 8 */
UART_REG(reg9); /* 9 */
UART_REG(revid1);   /* A */
-- 
2.11.0

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


[U-Boot] [PATCH 2/4] serial: ns16550: centralize identification of uart variants

2018-01-08 Thread Matthijs van Duin
Signed-off-by: Matthijs van Duin 
---
 drivers/serial/ns16550.c |  8 
 include/ns16550.h| 11 +--
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 9cec58c887c8..5ac2469b5760 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -36,7 +36,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif
 #endif /* !CONFIG_DM_SERIAL */
 
-#if defined(CONFIG_SOC_KEYSTONE) || defined(CONFIG_SOC_DA8XX)
+#ifdef CONFIG_NS16550_C6X
 #define UART_REG_VAL_PWREMU_MGMT_UART_DISABLE   0
 #define UART_REG_VAL_PWREMU_MGMT_UART_ENABLE ((1 << 14) | (1 << 13) | (1 << 0))
 #undef UART_MCRVAL
@@ -174,18 +174,18 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
;
 
serial_out(CONFIG_SYS_NS16550_IER, _port->ier);
-#if defined(CONFIG_ARCH_OMAP2PLUS)
+#ifdef CONFIG_NS16550_OMAP
serial_out(0x7, _port->mdr1);   /* mode select reset TL16C750*/
 #endif
serial_out(UART_MCRVAL, _port->mcr);
serial_out(ns16550_getfcr(com_port), _port->fcr);
if (baud_divisor != -1)
NS16550_setbrg(com_port, baud_divisor);
-#if defined(CONFIG_ARCH_OMAP2PLUS)
+#ifdef CONFIG_NS16550_OMAP
/* /16 is proper to hit 115200 with 48MHz */
serial_out(0, _port->mdr1);
 #endif
-#if defined(CONFIG_SOC_KEYSTONE) || defined(CONFIG_SOC_DA8XX)
+#ifdef CONFIG_NS16550_C6X
serial_out(UART_REG_VAL_PWREMU_MGMT_UART_ENABLE, _port->pwr_mgmt);
 #endif
 }
diff --git a/include/ns16550.h b/include/ns16550.h
index a988d297e144..4a87ab9c8e71 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -45,6 +45,13 @@
unsigned char postpad_##x[-CONFIG_SYS_NS16550_REG_SIZE - 1];
 #endif
 
+/* Identify major NS16550 variants */
+#if defined(CONFIG_SOC_KEYSTONE) || defined(CONFIG_SOC_DA8XX)
+#define CONFIG_NS16550_C6X 1
+#elif defined(CONFIG_ARCH_OMAP2PLUS)
+#define CONFIG_NS16550_OMAP 1
+#endif
+
 /**
  * struct ns16550_platdata - information about a NS16550 port
  *
@@ -71,14 +78,14 @@ struct NS16550 {
UART_REG(lsr);  /* 5 */
UART_REG(msr);  /* 6 */
UART_REG(spr);  /* 7 */
-#if defined(CONFIG_SOC_KEYSTONE) || defined(CONFIG_SOC_DA8XX)
+#if defined(CONFIG_NS16550_C6X)
UART_REG(reg8); /* 8 */
UART_REG(reg9); /* 9 */
UART_REG(revid1);   /* A */
UART_REG(revid2);   /* B */
UART_REG(pwr_mgmt); /* C */
UART_REG(mdr1); /* D */
-#else
+#elif defined(CONFIG_NS16550_OMAP)
UART_REG(mdr1); /* 8 */
UART_REG(reg9); /* 9 */
UART_REG(regA); /* A */
-- 
2.11.0

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


[U-Boot] [PATCH 0/4] serial: ns16550: cleanups and 13x oversampling

2018-01-08 Thread Matthijs van Duin
This is a small patch set we've been using internally for a while now,
and I figured it may be useful for mainline.

It originated from the desire of running the linux console at a higher
bitrate, and therefore also the u-boot console for consistency's sake.

When using 16x oversampling and an 48 MHz reference clock, the standard
rate 115200 requires a /26 divider, which also means that the only
higher standard rate available is 230400 (/13 divider).  In contrast, if
13x oversampling is used then the divider for 115200 is /32, which
yields a much greater range of standard rates to be used.

This patch set consists of three cleanup patches related to TI OMAP and
TI C6x style uarts, and finally one patch that configures 13x
oversampling on both of them.

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


Re: [U-Boot] [PATCH 2/2] sysboot: Call bootm booti bootz then go on label_boot

2018-01-08 Thread Emmanuel Vadot
On Sun, 7 Jan 2018 21:39:01 -0700
Simon Glass  wrote:

> Hi Emmanuel,
> 
> On 2 January 2018 at 14:27, Emmanuel Vadot  wrote:
> > As do_bootm/do_booti/do_bootz will not return if the boot succeded, always
> > call them if enable by the config.
> > Also add a fallback to go if the binary is a raw one.
> 
> Do we not know which type of binary it is? 

 For which case ?

> It seems like we should have some error checking here.

 Each bootX function check the header/magic/etc ...
 What kind of error checking do you want to add ?

> >
> > Signed-off-by: Emmanuel Vadot 
> > ---
> >  cmd/pxe.c | 12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/cmd/pxe.c b/cmd/pxe.c
> > index 7043ad11fd..0ca6a964bc 100644
> > --- a/cmd/pxe.c
> > +++ b/cmd/pxe.c
> > @@ -796,12 +796,14 @@ static int label_boot(cmd_tbl_t *cmdtp, struct 
> > pxe_label *label)
> > do_bootm(cmdtp, 0, bootm_argc, bootm_argv);
> >  #ifdef CONFIG_CMD_BOOTI
> > /* Try booting an AArch64 Linux kernel image */
> > -   else
> > -   do_booti(cmdtp, 0, bootm_argc, bootm_argv);
> > -#elif defined(CONFIG_CMD_BOOTZ)
> > +   do_booti(cmdtp, 0, bootm_argc, bootm_argv);
> > +#endif
> > +#if defined(CONFIG_CMD_BOOTZ)
> > /* Try booting a Image */
> > -   else
> > -   do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
> > +   do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
> > +#endif
> > +#if defined(CONFIG_CMD_GO)
> > +   do_go(cmdtp, 0, bootm_argc, bootm_argv);
> >  #endif
> > unmap_sysmem(buf);
> > return 1;
> > --
> > 2.15.1
> >
> 
> Regards,
> Simon


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


[U-Boot] RFE : CONFIG_OF_LIBFDT_OVERLAY=y in configs/orangepi_one_defconfig

2018-01-08 Thread Ken Harris
Can you enable the "fdt apply" command on the "Orange Pi One" u-boot :



diff --git a/configs/orangepi_one_defconfig b/configs/orangepi_one_defconfig
index 36feab204c..edc6f549dc 100644
--- a/configs/orangepi_one_defconfig
+++ b/configs/orangepi_one_defconfig
@@ -15,3 +15,6 @@ CONFIG_SPL=y
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_OF_LIBFDT=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] cmd: go: Make do_go available to outside boot.c

2018-01-08 Thread Emmanuel Vadot

 Hello Simon,

On Sun, 7 Jan 2018 21:38:29 -0700
Simon Glass  wrote:

> Hi Emmanuel,
> 
> On 2 January 2018 at 14:27, Emmanuel Vadot  wrote:
> > Some commands (like sysboot) might want to call go as they can encounter
> > a raw binary.
> > Make do_go callable for everyone.
> >
> > Signed-off-by: Emmanuel Vadot 
> > ---
> >  cmd/boot.c| 2 +-
> >  include/command.h | 4 
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> Can we instead move the code out of do_go() into another function
> which accepts C arguments, and then call that from do_go()?

 Sorry I do not understand what you mean.

> >
> > diff --git a/cmd/boot.c b/cmd/boot.c
> > index 72f2cf362d..5691c5f883 100644
> > --- a/cmd/boot.c
> > +++ b/cmd/boot.c
> > @@ -22,7 +22,7 @@ unsigned long do_go_exec(ulong (*entry)(int, char * const 
> > []), int argc,
> > return entry (argc, argv);
> >  }
> >
> > -static int do_go(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> > +int do_go(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> >  {
> > ulong   addr, rc;
> > int rcode = 0;
> > diff --git a/include/command.h b/include/command.h
> > index 767cabb3df..377e2eadd4 100644
> > --- a/include/command.h
> > +++ b/include/command.h
> > @@ -105,6 +105,10 @@ extern int do_bootz(cmd_tbl_t *cmdtp, int flag, int 
> > argc, char * const argv[]);
> >
> >  extern int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[]);
> >
> > +#ifdef CONFIG_CMD_GO
> > +extern int do_go(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[]);
> > +#endif
> > +
> >  extern int common_diskboot(cmd_tbl_t *cmdtp, const char *intf, int argc,
> >char *const argv[]);
> >
> > --
> > 2.15.1
> >
> 
> Regards,
> Simon


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


Re: [U-Boot] "fdt" commands in extlinux.conf ?

2018-01-08 Thread Ken Harris
On Sun, Jan 7, 2018 at 6:39 PM, Peter Robinson  wrote:
> On Sun, Jan 7, 2018 at 4:04 AM, Ken Harris  wrote:

>> The crux is a fdt command in u-boot :
>>
>> fdt set d_can1 status okay
>>
>> Is there a way to do this in extlinux.conf ?

> You could probably load an overlay and save the environment?

FYI, this is not an overlay (fdt apply), but just a "fdt set" command
: the d_can1 section is already in am335x-boneblack.dtb (but with
status = "disabled")

>> I didn't see a way (in uboot 2017.09), so I wrote a uEnv.txt script
>> (see attached).
>>
>> That's a bit verbose and duplicates a bunch of stuff already in uboot

> Dealing with this better in Fedora is on my todo list to get to eventually.

Thanks, but as the uEnv.txt script shows, this can be handled in
u-boot and Fedora will react to those changes.

>> It there a simpler way to state "fdt" commands ?

It seems to me there should be some new fields in extlinux.conf to
state u-boot "fdt" commands, such as "fdt set" and "fdt apply"

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


Re: [U-Boot] [BUG] x86: incorrect dram definition in dram_init_banksize().

2018-01-08 Thread Alexander Graf


On 08.01.18 12:31, Heinrich Schuchardt wrote:
> On 01/06/2018 11:51 PM, Heinrich Schuchardt wrote:
>> Function efi_add_known_memory uses the configured DRAM banks
>> (gd->bd->bi_dram) to define the memory that an EFI application may use.
>>
>> For qemu-x86_defconfig this will result in the first 1 MB of physical
>> memory being available. Here we find the BIOS, interrupt vectors and the
>> VGA memory (0xA-0xB).
>>
>> As a result grubia32.efi writes unknowingly to the video memory.
>>
>> For reference:
>> In function install_e820_map() we block
>> [ISA_START_ADDRESS, ISA_END_ADDRESS[.
>>
>> The problem seems to stem from file arch/x86/cpu/qemu/dram.c, function
>> dram_init_banksize():
>>
>> gd->bd->bi_dram[0].start = 0;
>> gd->bd->bi_dram[0].size = gd->ram_size;
>>
>> Probably exluding [ISA_START_ADDRESS, ISA_END_ADDRESS[ is not sufficient
>> as this does not protect interrupt vectors.
>>
>> Could you, please, provide reasonable values.
>>
>> Maybe a better idea would be to define reserved memory like the ones
>> that we find in the device trees, e.g.
>>
>> reserved-memory {
>> #address-cells = <2>;
>> #size-cells = <2>;
>> ranges;
>>
>> /* 16 MiB reserved for Hardware ROM Firmware */
>> hwrom_reserved: hwrom@0 {
>> reg = <0x0 0x0 0x0 0x100>;
>> no-map;
>> };
>>
>> But U-Boot does not yet support the concept of reserved memory.
> 
> This is how memory is reserved in arch/arm/mach-meson/board.c:
> 
> static void meson_board_add_reserved_memory(void *fdt, u64 start, u64 size)
> {
>int ret;
> 
>ret = fdt_add_mem_rsv(fdt, start, size);
>if (ret)
>printf("Could not reserve zone @ 0x%llx\n", start);
> 
>if (IS_ENABLED(CONFIG_EFI_LOADER)) {
>efi_add_memory_map(start,
>   ALIGN(size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT,
>   EFI_RESERVED_MEMORY_TYPE, false);
>}
> }
> 
> Similar code can be found in:
> arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> board/raspberrypi/rpi/rpi.c
> 
> Maybe we can generalize this.

Yes, I think we need to make memory reservation in dt integrate better
with efi_loader. A good number of people are used to just reserve random
ranges in their DT and expect Linux not to make use of them - which then
breaks with EFI.

What really should happen is that bootefi at the stage when it detects a
working fdt passed in, goes through that fdt's memory reservations and
declares all of them as reserved regions in the efi memory map as well.
That way we coherently mirror all reservations into EFI land.

I originally didn't want to do that because the device tree reservations
might be for different firmware versions, but I'd much rather have a
working device with a few kb less RAM than one where 2 cores end up
fighting over pieces of RAM ;).

As for x86, I suppose we need to explicitly mark some regions as
reserved in the board file, as that doesn't really use DT?


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


Re: [U-Boot] [PATCH v3] mx6ull: Handle the CONFIG_MX6ULL cases correctly

2018-01-08 Thread Stefano Babic
On 08/01/2018 12:35, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Thu, Jan 4, 2018 at 1:30 PM, Stefano Babic  wrote:
>> On 03/01/2018 15:33, Fabio Estevam wrote:
>>> Since commit 051ba9e082f7 ("Kconfig: mx6ull: Deselect MX6UL from
>>> CONFIG_MX6ULL") CONFIG_MX6ULL does not select CONFIG_MX6UL anymore, so
>>> take this into consideration in all the checks for CONFIG_MX6UL.
>>>
>>> This fixes a boot regression.
>>>
>>> Reported-by: Stefan Agner 
>>> Signed-off-by: Fabio Estevam 
>>> Reviewed-by: Stefan Agner 
>>> Tested-by: Breno Lima 
>>> Tested-by: Peng Fan 
>>> ---
>>
>> Applied to u-boot-imx, master, thanks !
> 
> Do you plan to submit a pull request for Tom to pick this one up?
> 

Yes, I have to pick up some other pacthes (Stefan's for example) and
then I will send my PR.


> It fixes a boot regression on mx6ull, so just wanted to make sure we
> don't miss it for the final 2018.01 release.
> 

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


Re: [U-Boot] [PATCH v3] mx6ull: Handle the CONFIG_MX6ULL cases correctly

2018-01-08 Thread Fabio Estevam
Hi Stefano,

On Thu, Jan 4, 2018 at 1:30 PM, Stefano Babic  wrote:
> On 03/01/2018 15:33, Fabio Estevam wrote:
>> Since commit 051ba9e082f7 ("Kconfig: mx6ull: Deselect MX6UL from
>> CONFIG_MX6ULL") CONFIG_MX6ULL does not select CONFIG_MX6UL anymore, so
>> take this into consideration in all the checks for CONFIG_MX6UL.
>>
>> This fixes a boot regression.
>>
>> Reported-by: Stefan Agner 
>> Signed-off-by: Fabio Estevam 
>> Reviewed-by: Stefan Agner 
>> Tested-by: Breno Lima 
>> Tested-by: Peng Fan 
>> ---
>
> Applied to u-boot-imx, master, thanks !

Do you plan to submit a pull request for Tom to pick this one up?

It fixes a boot regression on mx6ull, so just wanted to make sure we
don't miss it for the final 2018.01 release.

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


Re: [U-Boot] [BUG] x86: incorrect dram definition in dram_init_banksize().

2018-01-08 Thread Heinrich Schuchardt
On 01/06/2018 11:51 PM, Heinrich Schuchardt wrote:
> Function efi_add_known_memory uses the configured DRAM banks
> (gd->bd->bi_dram) to define the memory that an EFI application may use.
> 
> For qemu-x86_defconfig this will result in the first 1 MB of physical
> memory being available. Here we find the BIOS, interrupt vectors and the
> VGA memory (0xA-0xB).
> 
> As a result grubia32.efi writes unknowingly to the video memory.
> 
> For reference:
> In function install_e820_map() we block
> [ISA_START_ADDRESS, ISA_END_ADDRESS[.
> 
> The problem seems to stem from file arch/x86/cpu/qemu/dram.c, function
> dram_init_banksize():
> 
> gd->bd->bi_dram[0].start = 0;
> gd->bd->bi_dram[0].size = gd->ram_size;
> 
> Probably exluding [ISA_START_ADDRESS, ISA_END_ADDRESS[ is not sufficient
> as this does not protect interrupt vectors.
> 
> Could you, please, provide reasonable values.
> 
> Maybe a better idea would be to define reserved memory like the ones
> that we find in the device trees, e.g.
> 
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> 
> /* 16 MiB reserved for Hardware ROM Firmware */
> hwrom_reserved: hwrom@0 {
> reg = <0x0 0x0 0x0 0x100>;
> no-map;
> };
> 
> But U-Boot does not yet support the concept of reserved memory.

This is how memory is reserved in arch/arm/mach-meson/board.c:

static void meson_board_add_reserved_memory(void *fdt, u64 start, u64 size)
{
   int ret;

   ret = fdt_add_mem_rsv(fdt, start, size);
   if (ret)
   printf("Could not reserve zone @ 0x%llx\n", start);

   if (IS_ENABLED(CONFIG_EFI_LOADER)) {
   efi_add_memory_map(start,
  ALIGN(size, EFI_PAGE_SIZE) >> EFI_PAGE_SHIFT,
  EFI_RESERVED_MEMORY_TYPE, false);
   }
}

Similar code can be found in:
arch/arm/cpu/armv8/fsl-layerscape/fdt.c
board/raspberrypi/rpi/rpi.c

Maybe we can generalize this.

> 
> Best regards
> 
> Heinrich
> 

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


  1   2   >