Re: [U-Boot] [PATCH] arm,imx6: fix PAD_CTL_SPEED_LOW constant

2018-04-16 Thread Heiko Schocher

Hello Mark,

Am 16.04.2018 um 18:11 schrieb Mark Jonas:

For most i.MX6 processors the PAD_CTL_SPEED_LOW constant is the same.
Only the i.MX6 SoloLite is an exemption. So far the code did not
consider that. Additionally, for a few i.MX6 processors the code used
the wrong value for the constant.

This patch fixes the PAD_CTL_SPEED_LOW constant for:
  - i.MX6 Solo [1]
  - i.MX6 DualLite [1]
  - i.MX6 Dual [2]
  - i.MX6 Quad [2]
  - i.MX6 DualPlus [3]
  - i.MX6 QuadPlus [3]

Before, it was already correct for:
  - i.MX6 SoloLite [4]
  - i.MX6 SoloX [5]
  - i.MX6 UtraLite [6]
  - i.MX6 ULL [7]

[1] https://www.nxp.com/docs/en/reference-manual/IMX6SDLRM.pdf
[2] https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf
[3] https://www.nxp.com/docs/en/reference-manual/iMX6DQPRM.pdf
[4] https://www.nxp.com/docs/en/reference-manual/IMX6SLRM.pdf
[5] https://www.nxp.com/docs/en/reference-manual/IMX6SXRM.pdf
[6] https://www.nxp.com/docs/en/reference-manual/IMX6ULRM.pdf
[7] https://www.nxp.com/docs/en/reference-manual/IMX6ULLRM.pdf

Signed-off-by: Mark Jonas 
---
  arch/arm/include/asm/mach-imx/iomux-v3.h | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


Good catch, thanks!

Reviewed-by: Heiko Schocher 

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


Re: [U-Boot] [PATCH 03/12] libfdt: Safer access to strings section

2018-04-16 Thread Masahiro Yamada
2018-04-14 23:42 GMT+09:00 Warner Losh :
> On Fri, Apr 13, 2018 at 9:43 PM, David Gibson 
> wrote:
>
>> On Fri, Apr 13, 2018 at 12:53:19PM -0400, Tom Rini wrote:
>> > On Thu, Apr 12, 2018 at 02:39:19PM +1000, David Gibson wrote:
>> > > On Tue, Apr 10, 2018 at 10:42:45AM -0400, Simon Glass wrote:
>> > > > +U-Boot, Tom, Masahiro
>> > > >
>> > > > Hi David,
>> > > >
>> > > > On 10 April 2018 at 01:22, David Gibson 
>> wrote:
>> > > > > On Wed, Apr 04, 2018 at 01:21:10AM +0800, Simon Glass wrote:
>> > > > >> Hi David,
>> > > > >>
>> > > > >> On 3 April 2018 at 23:02, David Gibson <
>> da...@gibson.dropbear.id.au> wrote:
>> > > > >> >
>> > > > >> > On Fri, Mar 30, 2018 at 04:42:21PM +0800, Simon Glass wrote:
>> > > > >> > > Hi David,
>> > > > >> > >
>> > > > >> > > On 26 March 2018 at 07:25, David Gibson <
>> da...@gibson.dropbear.id.au> wrote:
>> > > > >> > > > fdt_string() is used to retrieve strings from a DT blob's
>> strings section.
>> > > > >> > > > It's rarely used directly, but is widely used internally.
>> > > > >> > > >
>> > > > >> > > > However, it doesn't do any bounds checking, which means in
>> the case of a
>> > > > >> > > > corrupted blob it could access bad memory, which libfdt is
>> supposed to
>> > > > >> > > > avoid.
>> > > > >> > > >
>> > > > >> > > > This write a safe alternative to fdt_string,
>> fdt_get_string().  It checks
>> > > > >> > > > both that the given offset is within the string section and
>> that the string
>> > > > >> > > > it points to is properly \0 terminated within the section.
>> It also returns
>> > > > >> > > > the string's length as a convenience (since it needs to
>> determine to do the
>> > > > >> > > > checks anyway).
>> > > > >> > > >
>> > > > >> > > > fdt_string() is rewritten in terms of fdt_get_string() for
>> compatibility.
>> > > > >> > > >
>> > > > >> > > > Most of the diff here is actually testing infrastructure.
>> > > > >> > > >
>> > > > >> > > > Signed-off-by: David Gibson 
>> > > > >> > > > ---
>> > > > >> > > >  libfdt/fdt_ro.c  | 61
>> +++--
>> > > > >> > > >  libfdt/libfdt.h  | 18 ++-
>> > > > >> > > >  libfdt/version.lds   |  2 +-
>> > > > >> > > >  tests/.gitignore |  1 +
>> > > > >> > > >  tests/Makefile.tests |  2 +-
>> > > > >> > > >  tests/run_tests.sh   |  1 +
>> > > > >> > > >  tests/testdata.h |  1 +
>> > > > >> > > >  tests/testutils.c| 11 +--
>> > > > >> > > >  tests/trees.S| 26 
>> > > > >> > > >  tests/truncated_string.c | 79
>> 
>> > > > >> > > >  10 files changed, 193 insertions(+), 9 deletions(-)
>> > > > >> > > >  create mode 100644 tests/truncated_string.c
>> > > > >> > >
>> > > > >> > > Similar code-size quesiton here. It looks like a lot of
>> checking code.
>> > > > >> > > Can we have an option to remove it?
>> > > > >> >
>> > > > >> > Again, I'm disinclined without a concrete example of a
>> problem.  Fwiw
>> > > > >> > the code size change is +276 bytes on my setup.
>> > > > >>
>> > > > >> That might not sound like a lot, but the overhead of DT in U-Boot
>> is
>> > > > >> about 3KB, so this adds nearly 10%.
>> > > > >
>> > > > > Hm.  And how much is it compared to the whole U-Boot blob?
>> > > > >
>> > > > >> The specific problem is that when U-Boot SPL gets too big boards
>> don't
>> > > > >> boot. Because we take the upstream libfdt this will affect U-Boot.
>> > > > >>
>> > > > >> Do you have any thoughts on how we could avoid this size increase?
>> > > > >
>> > > > > So, again, I'm very disinclined to prioritize size over memory
>> safety
>> > > > > without a *concrete* example.  i.e. "We hit this specific problem
>> with
>> > > > > size on this specific board that we were really using" rather than
>> > > > > just "it might be a problem".
>> > > > >
>> > > > > IMO, thinking of it in terms of the "increase" is the wrong way
>> > > > > arond.  If size is really a problem for you, you want to consider
>> how
>> > > > > you can reduce it in any way, not just rolling back the most recent
>> > > > > changes.  The most obvious one to me would be to try
>> > > > > -ffunction-sections to exclude any functions that aren't actually
>> used
>> > > > > by u-boot (if this is helpful and the compiler's an issue, I'd be
>> > > > > willing to consider splitting up libfdt into a bunch more C files).
>> > > >
>> > > > Actually U-Boot does use that option. Believe me, a lot of work has
>> > > > gone into making this small. There is constant pressure to
>> > > > reduce/retain the size in SPL so that we can stay below limits. E.g.
>> > > > firefly-rk3288 has a 30KB limit for SPL. Current problems are the
>> > > > 64-bit Allwinner parts which are right up against the limit at
>> > > > present.
>> > > >
>> > > > Also, Masahiro recently did some work to make U-Boot's version 

[U-Boot] [ANN] U-Boot v2018.05-rc2 released

2018-04-16 Thread Tom Rini
Hey all,

It's release day and v2018.05-rc2 is out.  I think I've got my queue
cleaned up since vacation, and I think most custodians have cleared
theirs out as well.  I am hopeful that we'll just be taking in fixes and
Kconfig migrations until the release at this point.

Things look on track for -rc3 on the 30th and then release on May 7th.
Thanks all!

-- 
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] [U-Boot, 1/1] env: mmc/fat/ext4: undefined reference to `mmc_initialize'

2018-04-16 Thread Tom Rini
On Sat, Apr 14, 2018 at 03:41:00PM +0200, Heinrich Schuchardt wrote:

> For CONFIG_ENV_FAT_INTERFACE != 'mmc' a link error
> env/fat.c:93: undefined reference to `mmc_initialize'
> occurs if CONFIG_MMC_SUPPORT is not enabled.
> 
> Fixes: 26862b4a40c3 ("env: mmc/fat/ext4: make sure that the MMC sub-system
> is initialized before using it")
> Signed-off-by: Heinrich Schuchardt 

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] doc: Update git-mailrc entry for lukma (lu...@denx.de)

2018-04-16 Thread Tom Rini
On Sun, Apr 15, 2018 at 09:50:11PM +0200, Lukasz Majewski wrote:

> Signed-off-by: Lukasz Majewski 

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] [U-Boot, v2] env: Relocate env drivers if manual reloc is required

2018-04-16 Thread Tom Rini
On Fri, Apr 13, 2018 at 07:57:21AM +0200, Michal Simek wrote:

> From: Siva Durga Prasad Paladugu 
> 
> Relocate env drivers if manual relocation is enabled. This
> patch fixes the issue of u-boot hang incase if env is
> present in any of the flash devices.
> 
> Signed-off-by: Siva Durga Prasad Paladugu 
> Signed-off-by: Michal Simek 
> Reviewed-by: Simon Glass 

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] serial: Remove duplicated line in Makefile

2018-04-16 Thread Tom Rini
On Mon, Apr 16, 2018 at 10:35:08AM +0200, Patrice Chotard wrote:

> The line "-obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o"
> is found twice in Makefile.
> 
> Fixes: ae74de0dfd45 ("serial: stm32: Rename serial_stm32x7.c to 
> serial_stm32.c"
> 
> Signed-off-by: Patrice Chotard 
> Acked-by: Vikas Manocha 
> Reviewed-by: Simon Glass 

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] [U-Boot, v2] Kconfig: Enlarge default SYS_MALLOC_F_LEN for AM33XX

2018-04-16 Thread Tom Rini
On Thu, Apr 12, 2018 at 06:09:58PM +0200, Sjoerd Simons wrote:

> Since commit 8e14ba7bd524 ("gpio: omap_gpio: Add DM_FLAG_PRE_RELOC
> flag") omap GPIO gets bound before relocation.  Unfortunately due to
> this, on at least the beaglebone black, the pre-relocation memory pool
> gets exhausted before probing the serial port. This then causes u-boot
> to panic as CONFIG_REQUIRE_SERIAL_CONSOLE is set...
> 
> Resolve this by resizing the default size of the pre-relocation malloc
> pool for AM335X platforms.
> 
> Signed-off-by: Sjoerd Simons 

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] part: Disable CONFIG_SPL_ISO_PARTITION by default

2018-04-16 Thread Tom Rini
On Thu, Apr 12, 2018 at 09:58:44AM +0200, Alexander Graf wrote:

> We enabled CONFIG_ISO_PARTITION by default for distro boot, so that U-Boot
> could load distro images that usually get shipped as iso images. These images
> usually come with a board agnostic boot environment.
> 
> However, there is very little point in having ISO support enabled (for anyone
> really) in SPL, as the whole idea of SPL is to load U-Boot proper which again
> is board specific. So the fact that we enable ISO support in U-Boot proper 
> does
> not mean at all that we want ISO support in U-Boot SPL.
> 
> Hence, let's remove the Kconfig dependency. Along the way, let's also clean up
> all those default configs that disabled SPL ISO support.
> 
> Signed-off-by: Alexander Graf 

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 1/3] common: Let board decide if env should be loaded

2018-04-16 Thread Marek Vasut
On 04/16/2018 10:44 PM, Marek Vasut wrote:
> Add board_should_load_env() hook which lets board code decide whether
> environment should be loaded. This is useful when restoring the board
> over ie. JTAG where the environment may interfere and where it may be
> desired to ignore the environment present on the board.
> 
> The return value of board_should_load_env() is:
>0- do not load environment
>1- load environment
> -EAGAIN - default behavior
> 
> Signed-off-by: Marek Vasut 
> Cc: Nobuhiro Iwamatsu 
> Cc: Tom Rini 

Please ignore, there's a better way to do this.

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


[U-Boot] [PATCH 2/2] ARM: rmobile: Ignore U-Boot env when started via JTAG on Porter

2018-04-16 Thread Marek Vasut
When U-Boot is started via JTAG, ignore the installed environment
as it may interfere with the recovery of the board.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 board/renesas/porter/porter.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/board/renesas/porter/porter.c b/board/renesas/porter/porter.c
index acd4f91d59..eb66bc903e 100644
--- a/board/renesas/porter/porter.c
+++ b/board/renesas/porter/porter.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -136,3 +137,18 @@ void reset_cpu(ulong addr)
if (ret)
hang();
 }
+
+enum env_location env_get_location(enum env_operation op, int prio)
+{
+   const u32 load_magic = 0xb33fc0de;
+
+   /* Block environment access if loaded using JTAG */
+   if ((readl(CONFIG_SPL_TEXT_BASE + 0x24) == load_magic) &&
+   (op != ENVOP_INIT))
+   return ENVL_UNKNOWN;
+
+   if (prio)
+   return ENVL_UNKNOWN;
+
+   return ENVL_SPI_FLASH;
+}
-- 
2.16.2

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


[U-Boot] [PATCH 1/2] ARM: rmobile: Ignore U-Boot env when started via JTAG on Stout

2018-04-16 Thread Marek Vasut
When U-Boot is started via JTAG, ignore the installed environment
as it may interfere with the recovery of the board.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 board/renesas/stout/stout.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/board/renesas/stout/stout.c b/board/renesas/stout/stout.c
index d7e81292a0..192ee66a38 100644
--- a/board/renesas/stout/stout.c
+++ b/board/renesas/stout/stout.c
@@ -128,3 +128,18 @@ int board_phy_config(struct phy_device *phydev)
 const struct rmobile_sysinfo sysinfo = {
CONFIG_ARCH_RMOBILE_BOARD_STRING
 };
+
+enum env_location env_get_location(enum env_operation op, int prio)
+{
+   const u32 load_magic = 0xb33fc0de;
+
+   /* Block environment access if loaded using JTAG */
+   if ((readl(CONFIG_SPL_TEXT_BASE + 0x24) == load_magic) &&
+   (op != ENVOP_INIT))
+   return ENVL_UNKNOWN;
+
+   if (prio)
+   return ENVL_UNKNOWN;
+
+   return ENVL_SPI_FLASH;
+}
-- 
2.16.2

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


Re: [U-Boot] Please pull u-boot-x86 (take 2)

2018-04-16 Thread Tom Rini
On Mon, Apr 16, 2018 at 11:01:25PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This includes some fixes and enhancements to VxWorks booting support,
> as well as some mods to x86 I/O functions.
> 
> The following changes since commit ebca902aeb3af3eaedd2787928184ad84a86b98f:
> 
>   Merge git://git.denx.de/u-boot-imx (2018-04-15 08:43:50 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to d5032392babd3a8bd027ccb79072ee7b05299b67:
> 
>   x86: Rename coreboot-x86 to coreboot (2018-04-16 22:38:53 +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


[U-Boot] [PATCH 3/3] ARM: rmobile: Ignore U-Boot env when started via JTAG on Stout

2018-04-16 Thread Marek Vasut
When U-Boot is started via JTAG, ignore the installed environment
as it may interfere with the recovery of the board.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
Cc: Tom Rini 
---
 board/renesas/stout/stout.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/board/renesas/stout/stout.c b/board/renesas/stout/stout.c
index d7e81292a0..16f4837502 100644
--- a/board/renesas/stout/stout.c
+++ b/board/renesas/stout/stout.c
@@ -128,3 +128,13 @@ int board_phy_config(struct phy_device *phydev)
 const struct rmobile_sysinfo sysinfo = {
CONFIG_ARCH_RMOBILE_BOARD_STRING
 };
+
+int board_should_load_env(void)
+{
+   const u32 load_magic = 0xb33fc0de;
+
+   if (readl(CONFIG_SPL_TEXT_BASE + 0x24) == load_magic)
+   return 0;
+
+   return -EAGAIN;
+}
-- 
2.16.2

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


[U-Boot] [PATCH 2/3] ARM: rmobile: Ignore U-Boot env when started via JTAG on Porter

2018-04-16 Thread Marek Vasut
When U-Boot is started via JTAG, ignore the installed environment
as it may interfere with the recovery of the board.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
Cc: Tom Rini 
---
 board/renesas/porter/porter.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/board/renesas/porter/porter.c b/board/renesas/porter/porter.c
index acd4f91d59..052e1abe08 100644
--- a/board/renesas/porter/porter.c
+++ b/board/renesas/porter/porter.c
@@ -136,3 +136,13 @@ void reset_cpu(ulong addr)
if (ret)
hang();
 }
+
+int board_should_load_env(void)
+{
+   const u32 load_magic = 0xb33fc0de;
+
+   if (readl(CONFIG_SPL_TEXT_BASE + 0x24) == load_magic)
+   return 0;
+
+   return -EAGAIN;
+}
-- 
2.16.2

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


[U-Boot] [PATCH 1/3] common: Let board decide if env should be loaded

2018-04-16 Thread Marek Vasut
Add board_should_load_env() hook which lets board code decide whether
environment should be loaded. This is useful when restoring the board
over ie. JTAG where the environment may interfere and where it may be
desired to ignore the environment present on the board.

The return value of board_should_load_env() is:
   0- do not load environment
   1- load environment
-EAGAIN - default behavior

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
Cc: Tom Rini 
---
 common/board_r.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/common/board_r.c b/common/board_r.c
index 0f4479a58b..8b68140b57 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -438,8 +438,17 @@ static int initr_mmc(void)
  *
  * @return 0 if environment should not be loaded, !=0 if it is ok to load
  */
+__weak int board_should_load_env(void)
+{
+   return -EAGAIN;
+}
+
 static int should_load_env(void)
 {
+   int ret = board_should_load_env();
+
+   if (ret >= 0)
+   return ret;
 #ifdef CONFIG_OF_CONTROL
return fdtdec_get_config_int(gd->fdt_blob, "load-environment", 1);
 #elif defined CONFIG_DELAY_ENVIRONMENT
-- 
2.16.2

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


Re: [U-Boot] [PATCHv1 14/14] reset: remove request and free functions

2018-04-16 Thread Dinh Nguyen


On 04/16/2018 01:51 PM, Stephen Warren wrote:
> On 04/16/2018 12:43 PM, Simon Glass wrote:
>> +Stephen for comment
>>
>> Hi Dinh,
>>
>> On 14 April 2018 at 12:51, Dinh Nguyen  wrote:
>>> The request and free reset functions are not really used for any useful
>>> purpose but for debugging. We can safely remove them.
>>
>> The API is set to line up with clocks. I think in general we do want
>> to be able to request and free these devices, just as we do for GPIOs.
>> What is the goal of removing these methods?
> 
> Many of the request methods do in fact do something; they check the
> validity of the reset ID so that check doesn't need to be duplicated
> everywhere. Even ignoring that, any resource management API should have
> explicit request/free APIs so that lifetime can be tracked if needed.

Agreed, that the checks were in some of the request functions, but the
majority did not do any checks, just a debug() statement. All of the
platforms that did the checks, I just moved them to reset_assert and
reset_deassert.

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


Re: [U-Boot] [PATCHv1 14/14] reset: remove request and free functions

2018-04-16 Thread Dinh Nguyen


On 04/16/2018 01:43 PM, Simon Glass wrote:
> +Stephen for comment
> 
> Hi Dinh,
> 
> On 14 April 2018 at 12:51, Dinh Nguyen  wrote:
>> The request and free reset functions are not really used for any useful
>> purpose but for debugging. We can safely remove them.
> 
> The API is set to line up with clocks. I think in general we do want
> to be able to request and free these devices, just as we do for GPIOs.
> What is the goal of removing these methods?
> 

It was a suggestion from Marek. I just didn't see any useful code
implemented in any of the request/free functions.

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


Re: [U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

2018-04-16 Thread Michael Nazzareno Trimarchi
Hi

On Mon, Apr 16, 2018 at 9:55 PM, Maxime Ripard
 wrote:
> On Fri, Apr 06, 2018 at 07:54:47AM +0200, Maxime Ripard wrote:
>> Hi Jaehoon,
>>
>> On Wed, Mar 21, 2018 at 12:18:58PM +0100, Maxime Ripard wrote:
>> > From: Philipp Tomsich 
>> >
>> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
>> > read 10MB from a fast eMMC device due to excessive delays in polling
>> > loops.
>> >
>> > This commit restructures the main polling loops to use get_timer(...)
>> > to determine whether a (millisecond) timeout has expired.  We choose
>> > not to use the wait_bit function, as we don't need interruptability
>> > with ctrl-c and have at least one case where two bits (one for an
>> > error condition and another one for completion) need to be read and
>> > using wait_bit would have not added to the clarity.
>> >
>> > The observed speedup in testing on a A31 is greater than 10x (e.g. a
>> > 10MB write decreases from 9.302s to 0.884s).
>> >
>> > Signed-off-by: Philipp Tomsich 
>> > Signed-off-by: Maxime Ripard 
>>
>> Any chance we can merge this for the next release?
>
> Ping?
>

Just curios but what is the result if %s/udelay(1000)/udelay(1)/g in the driver

Michael

> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 4/5] arm: ti: boot: Add dtbo partition for Android boot

2018-04-16 Thread Sam Protsenko
New Android boot scheme looks like this [1], and it involves adding new
partition for storing Device Tree Overlays. This patch adds dtbo
partition. While at it, let's revise Android partition table a bit.

List of changes:
 - rename "misc" to "hole" (not used for anything, just a guard hole)
 - rename "reserved" to "uenv" (because it hold U-Boot environment)
 - rename "environment" to "dtb" (because it actually holds .dtb file)
 - move "dtb" after "uenv" (so that changes of dtb size won't affect
   "uenv" offset)
 - make "hole" size twice as bigger (to keep "uenv" offset the same,
   because "dtb" was moved after "uenv")
 - add "dtbo" partition (after "dtb", to not affect "uenv" offset)
 - while at it, increase "boot" partition size up to 20 MiB; that's
   needed because while playing with some additional drivers built-in
   and different compression techniques, and also for HS signing, we
   have seen the boot partition size reach close to border and
   sometimes reach over the limit of 10 MiB

Now eMMC layout looks like this:

offset   content size  partition
(KiB)(KiB)

===

0   ++
| MBR/GPT header |   128   -
128 ++
| MLO|   256   xloader
384 ++
| u-boot.img |   1792  bootloader
2176++
|  hole  |   256   hole
2432++
| U-Boot environment |   256   uenv
| (+ redundant)  |
2688++
| dtb files  |   1024  dtb
3712++
| dtbo files |   1024  dtbo
4736++
  Android partitions remaining *

===

"hole" partition is needed just to keep U-Boot environment at 2432 KiB
offset, because:
 - this offset is used in DFU_ALT_INFO_EMMC:

   "u-env.raw raw 0x1300 0x200;"
   0x1300 = 4864 sectors = 2432 KiB

 - which in turn relies on CONFIG_ENV_OFFSET:

   CONFIG_ENV_OFFSET = 0x26 = 2432 KiB

We are using "hole" partition instead of specifying "start" property to
"uenv" partition, because this way it's easier to maintain change of
preceding partitions.

Also fix Android boot commands appropriately.

[1] https://source.android.com/devices/architecture/dto/partitions

Signed-off-by: Sam Protsenko 
---
 include/environment/ti/boot.h | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h
index 4f3d748b5c..f2d91f5298 100644
--- a/include/environment/ti/boot.h
+++ b/include/environment/ti/boot.h
@@ -26,13 +26,14 @@
"uuid_disk=${uuid_gpt_disk};" \
"name=xloader,start=128K,size=256K,uuid=${uuid_gpt_xloader};" \
"name=bootloader,size=1792K,uuid=${uuid_gpt_bootloader};" \
-   "name=environment,size=128K,uuid=${uuid_gpt_environment};" \
-   "name=misc,size=128K,uuid=${uuid_gpt_misc};" \
-   "name=reserved,size=256K,uuid=${uuid_gpt_reserved};" \
+   "name=hole,size=256K,uuid=${uuid_gpt_hole};" \
+   "name=uenv,size=256K,uuid=${uuid_gpt_uenv};" \
+   "name=dtb,size=1M,uuid=${uuid_gpt_dtb};" \
+   "name=dtbo,size=1M,uuid=${uuid_gpt_dtbo};" \
"name=efs,size=16M,uuid=${uuid_gpt_efs};" \
"name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
"name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
-   "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
+   "name=boot,size=20M,uuid=${uuid_gpt_boot};" \
"name=system,size=768M,uuid=${uuid_gpt_system};" \
"name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
"name=cache,size=256M,uuid=${uuid_gpt_cache};" \
@@ -66,8 +67,8 @@
"setenv machid fe6; " \
"mmc dev $mmcdev; " \
"mmc rescan; " \
-   "part start mmc ${mmcdev} environment fdt_start; " \
-   "part size mmc ${mmcdev} environment fdt_size; " \
+   "part start mmc ${mmcdev} dtb fdt_start; " \
+   "part size mmc ${mmcdev} dtb fdt_size; " \
"part start mmc ${mmcdev} boot boot_start; " \
"part size mmc ${mmcdev} boot boot_size; " \
"mmc read ${fdtaddr} ${fdt_start} ${fdt_size}; " \
-- 
2.17.0

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


[U-Boot] [PATCH 5/5] arm: ti: boot: Implement Android boot using DT image format

2018-04-16 Thread Sam Protsenko
Make sure we can boot Android on TI boards using scheme described in
Android documentation [1]. For this do next:
 1. Enable "dtimg" command. We will need it to boot the Android using
new DTB/DTBO image format.
 2. Add fdt overlay support. We will need that to be able to apply fdt
overlays to dtb file.
 3. Provide new Android boot commands. In case we don't know what board
it is, let's provide fallback mechanism:
 - use just dtb[0] from dtb.img
 - don't apply any dtbo files on top of it
 - but still that dtb file must be packed into Android DT image

To use new boot scheme, user has to do next:

1. Prepare dtb.img and dtbo.img images, generated with mkdtimg tool (can
   be found in Android sources, see prebuilts/misc/linux-x86/libufdt).
   Example:

   $ ./mkdtimg create dtb.img\
  am57xx-beagle-x15.dtb  --id=0  \
  am57xx-beagle-x15-revc.dtb --id=1

   $ ./mkdtimg create dtbo.img \
  am57xx-evm-common.dtbo --id=0  \
  mt9t111.dtbo   --id=1  \
  ov10635.dtbo   --id=2  \
  am57xx-evm.dtbo--id=3  \
  am57xx-evm-reva3.dtbo  --id=4

   Current boot commands rely on that specific order of dtb/dtbo files.
   Also, be sure to compile .dtb files with -@ dtc flag, so that
   overlays can be applied to dtb files.

2. Flash new U-Boot, set new environment and format eMMC:

   $ fastboot flash xloader MLO
   $ fastboot flash bootloader u-boot.img

   => env default -f -a
   => setenv partitions $partitions_android
   => env save
   => fastboot 1

   $ fastboot oem format

3. Flash dtb.img, dtbo.img:

   $ fastboot flash dtb dtb.img
   $ fastboot flash dtbo dtbo.img

4. Flash Android images:

   $ fastboot flash boot boot.img
   $ fastboot flash cache cache.img
   $ fastboot flash recovery recovery.img
   $ fastboot flash system system.img
   $ fastboot flash userdata userdata.img
   $ fastboot flash vendor vendor.img

For more detailed instructions, see [2].

[1] https://source.android.com/devices/architecture/dto/partitions
[2] https://wiki.linaro.org/Boards/BeagleBoard-X15

Signed-off-by: Sam Protsenko 
---
 board/ti/common/Kconfig   |  1 +
 configs/am57xx_evm_defconfig  |  1 +
 configs/am57xx_hs_evm_defconfig   |  1 +
 configs/dra7xx_evm_defconfig  |  1 +
 configs/dra7xx_hs_evm_defconfig   |  1 +
 include/configs/ti_armv7_common.h |  1 +
 include/environment/ti/boot.h | 40 +--
 7 files changed, 39 insertions(+), 7 deletions(-)

diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index c21eb8c2d2..f5bd9160b3 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -21,6 +21,7 @@ config TI_COMMON_CMD_OPTIONS
imply CRC32_VERIFY if ARCH_KEYSTONE
imply CMD_DFU if USB_GADGET_DOWNLOAD
imply CMD_DHCP
+   imply CMD_DTIMG
imply CMD_EEPROM
imply CMD_EXT2
imply CMD_EXT4
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index 6b11b3476c..7198542d9e 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -78,3 +78,4 @@ CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0451
 CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index ca9742f118..e4948d549b 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -81,3 +81,4 @@ CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0451
 CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index e17135c8f6..4ce687fbda 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -96,3 +96,4 @@ CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0451
 CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 606f99938c..6546daa080 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -95,3 +95,4 @@ CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0451
 CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/include/configs/ti_armv7_common.h 
b/include/configs/ti_armv7_common.h
index 4771e74940..4340b5188f 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -43,6 +43,7 @@
"loadaddr=0x8200\0" \
"kernel_addr_r=0x8200\0" \
"fdtaddr=0x8800\0" \
+   "dtboaddr=0x8900\0" \
"fdt_addr_r=0x8800\0" \
   

[U-Boot] [PATCH 1/5] common: Add support for Android DT image

2018-04-16 Thread Sam Protsenko
Android documentation recommends new image format for storing DTB/DTBO
files: [1]. To support that format, two things should be done:

1. Add dt_table.h file from Android (BSD-3 relicensed version): [2].
   This header defines structures and constants that we need to work
   with that DT image format.

   Changes:
- re-licensed from Apache to BSD-3
- removed functions declarations
- change the coding style to kernel (make checkpatch happy)

2. Add helper functions for Android DTB/DTBO format. In
   image-android-dt.* files you can find helper functions to work with
   Android DT image format, such us routines for:
- printing the dump of image structure
- getting the address and size of desired dtb/dtbo file

[1] https://source.android.com/devices/architecture/dto/partitions
[2] 
https://android.googlesource.com/platform/system/libufdt/+/58a7582180f477032cd6c74f8d9afad0038e74c3/utils/src/dt_table.h

Signed-off-by: Sam Protsenko 
---
 common/image-android-dt.c  | 134 +
 include/dt_table.h |  46 +
 include/image-android-dt.h |  18 +
 3 files changed, 198 insertions(+)
 create mode 100644 common/image-android-dt.c
 create mode 100644 include/dt_table.h
 create mode 100644 include/image-android-dt.h

diff --git a/common/image-android-dt.c b/common/image-android-dt.c
new file mode 100644
index 00..f218db06bb
--- /dev/null
+++ b/common/image-android-dt.c
@@ -0,0 +1,134 @@
+/*
+ * (C) Copyright 2018 Linaro Ltd.
+ * Sam Protsenko 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * Check if image header is correct.
+ *
+ * @param hdr Address to image header
+ * @return true if header is correct or false if header is incorrect
+ */
+bool android_dt_check_header(const struct dt_table_header *hdr)
+{
+   return fdt32_to_cpu(hdr->magic) == DT_TABLE_MAGIC;
+}
+
+/**
+ * Get the address of FDT (dtb or dtbo) in memory by its index in image.
+ *
+ * @param hdr Address to image header
+ * @param index Index of desired FDT in image (starting from 0)
+ * @param[out] addr If not null, will contain address to specified FDT
+ * @param[out] size If not NULL, will contain size of specified FDT
+ *
+ * @return true on success or false on error
+ */
+bool android_dt_get_fdt_by_index(const struct dt_table_header *hdr,
+u32 index, ulong *addr, u32 *size)
+{
+   const struct dt_table_entry *e;
+   u32 entry_count = fdt32_to_cpu(hdr->dt_entry_count);
+   u32 entries_offset = fdt32_to_cpu(hdr->dt_entries_offset);
+   u32 entry_size = fdt32_to_cpu(hdr->dt_entry_size);
+   u32 dt_offset, dt_size;
+
+   if (index > entry_count) {
+   printf("Error: index > dt_entry_count (%u > %u)\n", index,
+  entry_count);
+   return false;
+   }
+
+   e = (const struct dt_table_entry *)((ulong)hdr + entries_offset
+   + index * entry_size);
+   dt_offset = fdt32_to_cpu(e->dt_offset);
+   dt_size = fdt32_to_cpu(e->dt_size);
+
+   if (addr)
+   *addr = ((ulong)hdr + dt_offset);
+   if (size)
+   *size = dt_size;
+
+   return true;
+}
+
+#if !defined(CONFIG_SPL_BUILD)
+static void android_dt_print_fdt_info(const struct fdt_header *fdt)
+{
+   u32 fdt_size;
+   int root_node_off;
+   const char *compatible = NULL;
+
+   fdt_size = fdt_totalsize(fdt);
+   root_node_off = fdt_path_offset(fdt, "/");
+   if (root_node_off < 0) {
+   printf("Error: Root node not found\n");
+   } else {
+   compatible = fdt_getprop(fdt, root_node_off, "compatible",
+NULL);
+   }
+
+   printf("   (FDT)size = %d\n", fdt_size);
+   printf(" (FDT)compatible = %s\n",
+  compatible ? compatible : "(unknown)");
+}
+
+/**
+ * Print information about DT image structure.
+ *
+ * @param hdr Address to image header
+ */
+void android_dt_print_contents(const struct dt_table_header *hdr)
+{
+   u32 i;
+   u32 entry_count = fdt32_to_cpu(hdr->dt_entry_count);
+   u32 entries_offset = fdt32_to_cpu(hdr->dt_entries_offset);
+   u32 entry_size = fdt32_to_cpu(hdr->dt_entry_size);
+
+   /* Print image header info */
+   printf("dt_table_header:\n");
+   printf("   magic = %08x\n", fdt32_to_cpu(hdr->magic));
+   printf("  total_size = %d\n", fdt32_to_cpu(hdr->total_size));
+   printf(" header_size = %d\n", fdt32_to_cpu(hdr->header_size));
+   printf("   dt_entry_size = %d\n", entry_size);
+   printf("  dt_entry_count = %d\n", entry_count);
+   printf("   dt_entries_offset = %d\n", entries_offset);
+   printf("   page_size = %d\n", fdt32_to_cpu(hdr->page_size));
+   printf(" reserved[0] = %08x\n", 

[U-Boot] [PATCH 2/5] cmd: Add dtimg command

2018-04-16 Thread Sam Protsenko
dtimg command allows user to work with Android DTB/DTBO image format.
Such as, getting the address of desired DTB/DTBO file, printing the dump
of the image in U-Boot shell, etc.

This command is needed to provide Android boot with new Android DT image
format further.

Signed-off-by: Sam Protsenko 
---
 cmd/Kconfig |   8 +++
 cmd/Makefile|   1 +
 cmd/dtimg.c | 142 
 common/Makefile |   4 ++
 4 files changed, 155 insertions(+)
 create mode 100644 cmd/dtimg.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index bc1d2f31c0..68f3cc7b48 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -256,6 +256,14 @@ config CMD_BOOTMENU
help
  Add an ANSI terminal boot menu command.
 
+config CMD_DTIMG
+   bool "dtimg"
+   help
+ Android DTB/DTBO image manipulation commands. Read dtb/dtbo files from
+ image into RAM, dump image structure information, etc. Those dtb/dtbo
+ files should be merged in one dtb further, which needs to be passed to
+ the kernel, as part of a boot process.
+
 config CMD_ELF
bool "bootelf, bootvx"
default y
diff --git a/cmd/Makefile b/cmd/Makefile
index c4269ac8ac..1cc2e74e9e 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -43,6 +43,7 @@ ifdef CONFIG_POST
 obj-$(CONFIG_CMD_DIAG) += diag.o
 endif
 obj-$(CONFIG_CMD_DISPLAY) += display.o
+obj-$(CONFIG_CMD_DTIMG) += dtimg.o
 obj-$(CONFIG_CMD_ECHO) += echo.o
 obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
 obj-$(CONFIG_CMD_EEPROM) += eeprom.o
diff --git a/cmd/dtimg.c b/cmd/dtimg.c
new file mode 100644
index 00..0b046402fe
--- /dev/null
+++ b/cmd/dtimg.c
@@ -0,0 +1,142 @@
+/*
+ * (C) Copyright 2018 Linaro Ltd.
+ * Sam Protsenko 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+enum cmd_dtimg_info {
+   CMD_DTIMG_START = 0,
+   CMD_DTIMG_SIZE,
+};
+
+static int do_dtimg_dump(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+   char *endp;
+   void *hdr;
+
+   if (argc != 2)
+   return CMD_RET_USAGE;
+
+   hdr = (void *)simple_strtoul(argv[1], , 16);
+   if (*endp != '\0') {
+   printf("Error: Wrong image address\n");
+   return CMD_RET_FAILURE;
+   }
+
+   if (!android_dt_check_header(hdr)) {
+   printf("Error: DT image header is incorrect\n");
+   return CMD_RET_FAILURE;
+   }
+
+   android_dt_print_contents(hdr);
+
+   return CMD_RET_SUCCESS;
+}
+
+static int dtimg_get_fdt(int argc, char * const argv[], enum cmd_dtimg_info 
cmd)
+{
+   void *hdr;
+   u32 index;
+   char *endp;
+   ulong addr;
+   u32 size;
+   char buf[512] = { 0 };
+
+   if (argc != 4)
+   return CMD_RET_USAGE;
+
+   hdr = (void *)simple_strtoul(argv[1], , 16);
+   if (*endp != '\0') {
+   printf("Error: Wrong image address\n");
+   return CMD_RET_FAILURE;
+   }
+
+   if (!android_dt_check_header(hdr)) {
+   printf("Error: DT image header is incorrect\n");
+   return CMD_RET_FAILURE;
+   }
+
+   index = simple_strtoul(argv[2], , 0);
+   if (*endp != '\0') {
+   printf("Error: Wrong index\n");
+   return CMD_RET_FAILURE;
+   }
+
+   if (!android_dt_get_fdt_by_index(hdr, index, , ))
+   return CMD_RET_FAILURE;
+
+   switch (cmd) {
+   case CMD_DTIMG_START:
+   snprintf(buf, sizeof(buf), "%p", (void *)addr);
+   break;
+   case CMD_DTIMG_SIZE:
+   snprintf(buf, sizeof(buf), "%x", size);
+   break;
+   default:
+   printf("Error: Unknown cmd_dtimg_info value: %d\n", cmd);
+   return CMD_RET_FAILURE;
+   }
+
+   env_set(argv[3], buf);
+
+   return CMD_RET_SUCCESS;
+}
+
+static int do_dtimg_start(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+   return dtimg_get_fdt(argc, argv, CMD_DTIMG_START);
+}
+
+static int do_dtimg_size(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+   return dtimg_get_fdt(argc, argv, CMD_DTIMG_SIZE);
+}
+
+static cmd_tbl_t cmd_dtimg_sub[] = {
+   U_BOOT_CMD_MKENT(dump, 2, 0, do_dtimg_dump, "", ""),
+   U_BOOT_CMD_MKENT(start, 4, 0, do_dtimg_start, "", ""),
+   U_BOOT_CMD_MKENT(size, 4, 0, do_dtimg_size, "", ""),
+};
+
+static int do_dtimg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   cmd_tbl_t *cp;
+
+   cp = find_cmd_tbl(argv[1], cmd_dtimg_sub, ARRAY_SIZE(cmd_dtimg_sub));
+
+   /* Strip off leading 'dtimg' command argument */
+   argc--;
+   argv++;
+
+   if (!cp || argc > cp->maxargs)
+   return CMD_RET_USAGE;
+   if (flag == CMD_FLAG_REPEAT && !cp->repeatable)
+   return CMD_RET_SUCCESS;
+
+  

[U-Boot] [PATCH 3/5] arm: ti: boot: Extract PARTS_DEFAULT to boot.h

2018-04-16 Thread Sam Protsenko
Eliminate code duplication: the same PARTS_DEFAULT was defined in
am57xx_evm.h and in dra7xx_evm.h. Extract it to environment/boot.h and
use in all OMAP5-based boards.

Signed-off-by: Sam Protsenko 
---
 include/configs/am57xx_evm.h   | 25 -
 include/configs/cl-som-am57x.h |  2 ++
 include/configs/cm_t54.h   |  2 ++
 include/configs/dra7xx_evm.h   | 25 -
 include/environment/ti/boot.h  | 27 +--
 5 files changed, 29 insertions(+), 52 deletions(-)

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

[U-Boot] [PATCH 0/5] Use Android DT image format for TI boards

2018-04-16 Thread Sam Protsenko
Android documentation recommends using new image format for storing dtb
and dtbo files: [1]. Using that format, we can pack several dtb files to
dtb.img, and also pack several dtbo files to dtbo.img. Then those images
should be flashed to eMMC partitions, called "dtb" and "dtbo"
respectively.

This patch series introduces support for mentioned Android DT image
format, adds "dtimg" command to deal with that image format from U-Boot
shell, and provides new Android boot scheme to TI boards (AM57x and DRA7
boards). So with this patch series we will have next procedure for
Android boot:
 1. Read next images from eMMC partitions to RAM:
- boot.img
- dtb.img
- dtbo.img
 2. Take addresses of desired dtb/dtbo files from that images (for
current board)
 3. Apply dtbo overlays to main dtb, if needed
 4. Boot the kernel from Android boot image, using resulting dtb

It was tested on X15 and AM57x EVM boards.

[1] https://source.android.com/devices/architecture/dto/partitions

Sam Protsenko (5):
  common: Add support for Android DT image
  cmd: Add dtimg command
  arm: ti: boot: Extract PARTS_DEFAULT to boot.h
  arm: ti: boot: Add dtbo partition for Android boot
  arm: ti: boot: Implement Android boot using DT image format

 board/ti/common/Kconfig   |   1 +
 cmd/Kconfig   |   8 ++
 cmd/Makefile  |   1 +
 cmd/dtimg.c   | 142 ++
 common/Makefile   |   4 +
 common/image-android-dt.c | 134 
 configs/am57xx_evm_defconfig  |   1 +
 configs/am57xx_hs_evm_defconfig   |   1 +
 configs/dra7xx_evm_defconfig  |   1 +
 configs/dra7xx_hs_evm_defconfig   |   1 +
 include/configs/am57xx_evm.h  |  25 --
 include/configs/cl-som-am57x.h|   2 +
 include/configs/cm_t54.h  |   2 +
 include/configs/dra7xx_evm.h  |  25 --
 include/configs/ti_armv7_common.h |   1 +
 include/dt_table.h|  46 ++
 include/environment/ti/boot.h |  68 --
 include/image-android-dt.h|  18 
 18 files changed, 422 insertions(+), 59 deletions(-)
 create mode 100644 cmd/dtimg.c
 create mode 100644 common/image-android-dt.c
 create mode 100644 include/dt_table.h
 create mode 100644 include/image-android-dt.h

-- 
2.17.0

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


Re: [U-Boot] [PATCH v3 00/17] warp7: Enable automated OPTEE/HAB boot flow

2018-04-16 Thread Fabio Estevam
On Fri, Apr 13, 2018 at 12:31 PM, Bryan O'Donoghue
 wrote:

> Bryan O'Donoghue (17):
>   imximage: Specify default IVT offset in IMX image
>   warp7: hab: Add a CSF location definition
>   warp7: hab: Set environment variable indicating HAB enable
>   warp7: defconfig: Enable OPTEE for WaRP7
>   warp7: Allocate specific region of memory to OPTEE
>   warp7: Print out the OPTEE DRAM region
>   warp7: Specify CONFIG_OPTEE_LOAD_ADDR
>   warp7: defconfig: Enable CONFIG_SECURE_BOOT
>   warp7: defconfig: Enable CONFIG_BOOTM_TEE
>   warp7: Make CONFIG_SYS_FDT_ADDR a define
>   warp7: Add Kconfig WARP7_ROOT_PART
>   warp7: select uuid partition based on rootpart
>   warp7: Define the name of a signed boot-script file
>   warp7: add warp7_auth_or_fail
>   warp7: hab: Set environment variable indicating IVT offset
>   warp7: defconfig: Enable CMD_SETEXPR
>   warp7: Add support for automated secure boot.scr verification

For the series:

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


Re: [U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

2018-04-16 Thread Maxime Ripard
On Fri, Apr 06, 2018 at 07:54:47AM +0200, Maxime Ripard wrote:
> Hi Jaehoon,
> 
> On Wed, Mar 21, 2018 at 12:18:58PM +0100, Maxime Ripard wrote:
> > From: Philipp Tomsich 
> > 
> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
> > read 10MB from a fast eMMC device due to excessive delays in polling
> > loops.
> > 
> > This commit restructures the main polling loops to use get_timer(...)
> > to determine whether a (millisecond) timeout has expired.  We choose
> > not to use the wait_bit function, as we don't need interruptability
> > with ctrl-c and have at least one case where two bits (one for an
> > error condition and another one for completion) need to be read and
> > using wait_bit would have not added to the clarity.
> > 
> > The observed speedup in testing on a A31 is greater than 10x (e.g. a
> > 10MB write decreases from 9.302s to 0.884s).
> > 
> > Signed-off-by: Philipp Tomsich 
> > Signed-off-by: Maxime Ripard 
> 
> Any chance we can merge this for the next release?

Ping?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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: rmobile: Disable SDHI on R8A77970 V3M Eagle

2018-04-16 Thread Marek Vasut
The SDHI is not routed to a slot on the Eagle, so disable it.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 configs/r8a77970_eagle_defconfig | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/configs/r8a77970_eagle_defconfig b/configs/r8a77970_eagle_defconfig
index 5301fca21d..7a0e0e5127 100644
--- a/configs/r8a77970_eagle_defconfig
+++ b/configs/r8a77970_eagle_defconfig
@@ -19,7 +19,6 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_DFU=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
-CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
@@ -35,6 +34,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_REGMAP=y
 CONFIG_SYSCON=y
+CONFIG_BLK=y
 CONFIG_CLK=y
 CONFIG_CLK_RENESAS=y
 CONFIG_DFU_TFTP=y
@@ -44,11 +44,7 @@ CONFIG_DM_GPIO=y
 CONFIG_RCAR_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_RCAR_IIC=y
-CONFIG_DM_MMC=y
-CONFIG_MMC_IO_VOLTAGE=y
-CONFIG_MMC_UHS_SUPPORT=y
-CONFIG_MMC_HS200_SUPPORT=y
-CONFIG_RENESAS_SDHI=y
+# CONFIG_MMC is not set
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
-- 
2.16.2

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


Re: [U-Boot] [PATCH] fit: skip signature verification if board request

2018-04-16 Thread Simon Glass
Hi Jun,

On 13 April 2018 at 04:05, Jun Nie  wrote:
> 2018-04-13 1:24 GMT+08:00 Simon Glass :
>> Hi,
>>
>> On 11 April 2018 at 09:13, Jun Nie  wrote:
>>> It may be unnecessary to check signature on unlocked board.
>>> Get the hint from platform specific code to support secure boot
>>> and non-secure boot with the same binary, so that boot is not
>>> blocked if board is not locked and has no key for signature
>>> verification.
>>>
>>> Signed-off-by: Jun Nie 
>>> ---
>>
>> Instead of a weak function can you please add a parameter to this
>> function (perhaps a flags word?) and a add test for this case to the
>> test?
>>
>> Regards,
>> Simon
>
> Sure, I can add a parameter to the function. But not sure what's the
> usage of it in your mind. Maybe "int flag" is enough for you?

Yes a flag is fine if you define an enum in the header file for that
function. You will likely need to pass the flag around a few other
functions.
>
> Do you mean add implementation of this function for a specific platform
> for "add test"?

See test/py/tests/test_vboot.py which you should be able to modify for
your case.

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


Re: [U-Boot] [PATCHv1 14/14] reset: remove request and free functions

2018-04-16 Thread Stephen Warren

On 04/16/2018 12:43 PM, Simon Glass wrote:

+Stephen for comment

Hi Dinh,

On 14 April 2018 at 12:51, Dinh Nguyen  wrote:

The request and free reset functions are not really used for any useful
purpose but for debugging. We can safely remove them.


The API is set to line up with clocks. I think in general we do want
to be able to request and free these devices, just as we do for GPIOs.
What is the goal of removing these methods?


Many of the request methods do in fact do something; they check the 
validity of the reset ID so that check doesn't need to be duplicated 
everywhere. Even ignoring that, any resource management API should have 
explicit request/free APIs so that lifetime can be tracked if needed.

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


Re: [U-Boot] [PATCHv1 14/14] reset: remove request and free functions

2018-04-16 Thread Simon Glass
+Stephen for comment

Hi Dinh,

On 14 April 2018 at 12:51, Dinh Nguyen  wrote:
> The request and free reset functions are not really used for any useful
> purpose but for debugging. We can safely remove them.

The API is set to line up with clocks. I think in general we do want
to be able to request and free these devices, just as we do for GPIOs.
What is the goal of removing these methods?

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


Re: [U-Boot] [PATCH v3 00/17] warp7: Enable automated OPTEE/HAB boot flow

2018-04-16 Thread Breno Matheus Lima
Hi Bryan,

2018-04-13 12:31 GMT-03:00 Bryan O'Donoghue :
> https://git.linaro.org/landing-teams/working/mbl/u-boot.git/log/?h=linaro-mbl%2bbod
>
> v3:
> - Reword commit message of patch #16 - Breno
>
> - This patchset now relies on five in-flight patch-sets the first four of
>   which should be applied first
>
> 1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
>Already has a Reviewed-by from Fabio
>
> 2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
>Has a Reviewed-by: from Breno
>
> 3. [PATCH v3 0/2] WaRP7 unify secure and non-secure defconfigs
>
> 4. Pierre-Jean's generic load patches
>
>[U-Boot] [PATCH v3 1/2] warp7: include/configs: use generic fs commands
>in CONFIG_EXTRA_ENV_SETTINGS
>
>[U-Boot] [PATCH v3 2/2] warp7: configs: enable CONFIG_CMD_FS_GENERIC
>
> 5. [PATCH] bootm: Align cache flush begin address
>This last patch can be applied in any order
>
> v2:
> - Ensure warp7_defconfig boots existing yocto with this change plus the
>   automated HAB layer being added here following on from "[PATCH v3 0/2]
>   WaRP7 unify secure and non-secure defconfigs"
>
> - Fix reference to partition #1 versus partition #2 in select uuidpart
>   patch
>
> - Rebase on top of Pierre-Jean Texier generic load patches
>
> - Drop my patch which did the same thing as Pierre-Jean's patch via
>   ${loadcmd}
>
> - Update example boot.scr from v1 to reflect use of generic 'load' command
>
> - This patchset now relies on four in-flight patch-sets which all have the
>   relevant Reviewed-by tags from the board Maintainer Fabio.
>
> 1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
>Already has a Reviewed-by from Fabio
>
> 2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
>Has a Reviewed-by: from Breno
>
> 3. [PATCH v3 0/2] WaRP7 unify secure and non-secure defconfigs
>
> 4. Pierre-Jean's generic load patches
>
>[U-Boot] [PATCH v3 1/2] warp7: include/configs: use generic fs commands
>in CONFIG_EXTRA_ENV_SETTINGS
>
>[U-Boot] [PATCH v3 2/2] warp7: configs: enable CONFIG_CMD_FS_GENERIC
>
> v1:
> This series enables an automated HAB verified secure boot which chain-loads
> via OPTEE see `git show 5cf3251..c225e7c` for details.
>
> This set depends on three in-flight patchsets
>
> 1. [PATCH v3 0/3] NXP WaARP7 set serial# from OTP fuses for USB iSerial
>Already has a Reviewed-by from Fabio
>
> 2. [PATCH v3 0/2] imx: hab: Add helper functions for scripted HAB auth
>Has a Reviewed-by: from Breno
>
> 3. [PATCH] configs: warp7: Fix CAAM on boot with tip-of-tree
>
> I'm trying not to make this cover email too long. So - once this set is
> applied it is possible to boot from the BootROM using HAB to verify
>
> - u-boot
> - boot.scr
> - Kernel
> - DTB
>
> Chainload via OPTEE and boot up to Linux. If there is a HAB failure at any
> stage of the process we force-drop down to the USB HID failover mode, from
> which we can send up a recovery image to unblock.
>
> I've run the WaRP7 default u-boot and this new version on NXP's reference
> yocto image and verified that that yocto image boots with both versions of
> the WaRP7 -> warp7_defconfig and warp7_secure_defconfig.
>
> http://freescale.github.io/#download -> BoardsWaRPboard community - WaRP -
> Wearable Reference PlatformFSL Community BSP 2.3fsl-image-multimediawayland
>
> In addition the modifications targeting warp7_secure_defconfig mean it is
> possible to chain-load via OPTEE using scripted HAB to verify images prior
> to exiting the u-boot domain.
>
> Here is an example of the scripting we are doing which shows further reuse
> of shell functions introduced in previous patches.
>
>  Example secure-boot boot.scr.imx-signed 
>
> # This section is responsbile for loading a signed Linux kernel
> setenv image_signed zImage.imx-signed
> if test ${hab_enabled} -eq 1; then
> setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}
> load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr} ${image_signed}
> run warp7_auth_or_fail
> else
> run loadimage;
> fi
>
> # This section is responsbile for loading a signed FDT image
> setenv fdt_file_signed imx7s-warp.dtb.imx-signed
> if test ${hab_enabled} -eq 1; then
> setexpr hab_ivt_addr ${fdt_addr} - ${ivt_offset}
> load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr}
> ${fdt_file_signed}
> run warp7_auth_or_fail
> else
> run loadfdt;
> fi
>
> # Boot from rootfs1 by default
> setenv mmcpart 3
>
> # But if the rootfs2 file exists in partition 2, boot from rootfs2
> ext4size mmc 0:2 rootfs2 && setenv mmcpart 5
>
> # This section is responsbile for loading a signed OPTEE image
> setenv optee_file /lib/firmware/uTee.optee
> setenv optee_file_signed /lib/firmware/uTee.optee.imx-signed
> setenv loadoptee "load mmc ${mmcdev}:${mmcpart} ${optee_addr}
> ${optee_file}"
> if test ${hab_enabled} -eq 1; then
> setexpr hab_ivt_addr ${optee_addr} 

Re: [U-Boot] [PATCH] serial: Remove duplicated line in Makefile

2018-04-16 Thread Simon Glass
On 16 April 2018 at 02:35, Patrice Chotard  wrote:
> The line "-obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o"
> is found twice in Makefile.
>
> Fixes: ae74de0dfd45 ("serial: stm32: Rename serial_stm32x7.c to 
> serial_stm32.c"
>
> Signed-off-by: Patrice Chotard 
> ---
>
>  drivers/serial/Makefile | 1 -
>  1 file changed, 1 deletion(-)
>

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


Re: [U-Boot] [PATCH v2] bootm: Align cache flush begin address

2018-04-16 Thread Simon Glass
On 15 April 2018 at 04:48, Bryan O'Donoghue  wrote:
> commit b4d956f6bc0f ("bootm: Align cache flush end address correctly")
> aligns the end address of the cache flush operation to a cache-line size to
> ensure lower-layers in the code accept the range provided and flush.
>
> A similar action should be taken for the begin address of a cache flush
> operation. The load address may not be aligned to a cache-line boundary, so
> ensure the passed address is aligned.
>
> Signed-off-by: Bryan O'Donoghue 
> Reported-by: Breno Matheus Lima 
> Suggested-by: Tom Rini 
> Cc: Simon Glass 
> ---
>  common/bootm.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

I feel that using an unaligned start address should probably be an
error. Why would that be useful?

Apart from that:

Reviewed-by: Simon Glass 

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


Re: [U-Boot] [PATCH v2] bootm: Align cache flush begin address

2018-04-16 Thread Breno Matheus Lima
Hi Bryan,

2018-04-15 7:48 GMT-03:00 Bryan O'Donoghue :
> commit b4d956f6bc0f ("bootm: Align cache flush end address correctly")
> aligns the end address of the cache flush operation to a cache-line size to
> ensure lower-layers in the code accept the range provided and flush.
>
> A similar action should be taken for the begin address of a cache flush
> operation. The load address may not be aligned to a cache-line boundary, so
> ensure the passed address is aligned.
>
> Signed-off-by: Bryan O'Donoghue 
> Reported-by: Breno Matheus Lima 
> Suggested-by: Tom Rini 
> Cc: Simon Glass 

Thanks for the fix, I'm not seeing the issue anymore.

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


Re: [U-Boot] [PATCH] serial: Remove duplicated line in Makefile

2018-04-16 Thread Vikas Manocha
Hi,

On 04/16/2018 01:35 AM, Patrice Chotard wrote:
> The line "-obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o"
> is found twice in Makefile.
> 
> Fixes: ae74de0dfd45 ("serial: stm32: Rename serial_stm32x7.c to 
> serial_stm32.c"
> 
> Signed-off-by: Patrice Chotard 

Acked-by: Vikas Manocha 

Cheers,
Vikas

> ---
> 
>  drivers/serial/Makefile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
> index 6937ef962868..16609edf4b5a 100644
> --- a/drivers/serial/Makefile
> +++ b/drivers/serial/Makefile
> @@ -60,7 +60,6 @@ obj-$(CONFIG_UNIPHIER_SERIAL) += serial_uniphier.o
>  obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o
>  obj-$(CONFIG_STI_ASC_SERIAL) += serial_sti_asc.o
>  obj-$(CONFIG_PIC32_SERIAL) += serial_pic32.o
> -obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o
>  obj-$(CONFIG_BCM283X_MU_SERIAL) += serial_bcm283x_mu.o
>  obj-$(CONFIG_BCM283X_PL011_SERIAL) += serial_bcm283x_pl011.o
>  obj-$(CONFIG_MSM_SERIAL) += serial_msm.o
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Please pull u-boot-cfi-flash/master

2018-04-16 Thread Tom Rini
On Mon, Apr 16, 2018 at 01:25:58PM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull this one CFI related patch from Mario.
> 
> Thanks,
> Stefan
> 
> The following changes since commit ebca902aeb3af3eaedd2787928184ad84a86b98f:
> 
>   Merge git://git.denx.de/u-boot-imx (2018-04-15 08:43:50 -0400)
> 
> are available in the Git repository at:
> 
>   git://www.denx.de/git/u-boot-cfi-flash.git 
> 
> for you to fetch changes up to 8bfeb33c463296af38432c3dbfb976f45545e381:
> 
>   mtd: cfi_flash: Make live-tree compatible (2018-04-16 09:55:59 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v2 1/3] arm: psci: save context id for cpu_on PSCI command

2018-04-16 Thread Stephen Warren

On 04/16/2018 02:13 AM, Patrick Delaunay wrote:

Save and use the 3rd parameter of PSCI CPU_ON request: context_id.

The context_id parameter is only meaningful to the caller.
U-Boot PSCI preserves a copy of the value passed in this parameter.
Following wakeup from a  powerdown state, U-BOOT PSCI places
this value in R0 when it first enters the OS.

NB: this context id is not (yet?) used by Linux but it is mandatory
 to be PSCI compliant.

update armv7 psci functions:
- psci_save_target_pc(): keep for backward compatibility with
   current platform (only save PC and force context id to 0)
   => should be removed when all platform migrate to the new API

- psci_save(): new API to use by ARMv7 platform with PSCI,
   save pc (= entry_point_address) and context_id


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


Re: [U-Boot] [PATCH 3/6] tegra: psci: save context id in cpu_on command

2018-04-16 Thread Stephen Warren

On 04/16/2018 02:15 AM, Patrick Delaunay wrote:

Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)


So this function doesn't actually exist since it's added in a different 
patch series that isn't mentioned as a dependency. Luckily I managed to 
find it in the list archives I have, and assuming the dependency is 
applied first,


Reviewed-by: Stephen Warren 


diff --git a/arch/arm/mach-tegra/psci.S b/arch/arm/mach-tegra/psci.S



@@ -90,7 +90,8 @@ ENTRY(psci_cpu_on)
mov r4, r1
mov r0, r1
mov r1, r2
-   bl  psci_save_target_pc @ store target PC
+   mov r2, r3
+   bl  psci_save   @ store target PC and context id
mov r1, r4


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


Re: [U-Boot] [Feature] Android Fastboot over Ethernet

2018-04-16 Thread Stanislas BERTRAND
Hi Alex,


Thanks for the links, this helps a lot.

Stan


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


[U-Boot] [PATCH] arm,imx6: fix PAD_CTL_SPEED_LOW constant

2018-04-16 Thread Mark Jonas
For most i.MX6 processors the PAD_CTL_SPEED_LOW constant is the same.
Only the i.MX6 SoloLite is an exemption. So far the code did not
consider that. Additionally, for a few i.MX6 processors the code used
the wrong value for the constant.

This patch fixes the PAD_CTL_SPEED_LOW constant for:
 - i.MX6 Solo [1]
 - i.MX6 DualLite [1]
 - i.MX6 Dual [2]
 - i.MX6 Quad [2]
 - i.MX6 DualPlus [3]
 - i.MX6 QuadPlus [3]

Before, it was already correct for:
 - i.MX6 SoloLite [4]
 - i.MX6 SoloX [5]
 - i.MX6 UtraLite [6]
 - i.MX6 ULL [7]

[1] https://www.nxp.com/docs/en/reference-manual/IMX6SDLRM.pdf
[2] https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf
[3] https://www.nxp.com/docs/en/reference-manual/iMX6DQPRM.pdf
[4] https://www.nxp.com/docs/en/reference-manual/IMX6SLRM.pdf
[5] https://www.nxp.com/docs/en/reference-manual/IMX6SXRM.pdf
[6] https://www.nxp.com/docs/en/reference-manual/IMX6ULRM.pdf
[7] https://www.nxp.com/docs/en/reference-manual/IMX6ULLRM.pdf

Signed-off-by: Mark Jonas 
---
 arch/arm/include/asm/mach-imx/iomux-v3.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/iomux-v3.h 
b/arch/arm/include/asm/mach-imx/iomux-v3.h
index 0c0ccf44..09094c9 100644
--- a/arch/arm/include/asm/mach-imx/iomux-v3.h
+++ b/arch/arm/include/asm/mach-imx/iomux-v3.h
@@ -147,10 +147,10 @@ typedef u64 iomux_v3_cfg_t;
 
 #define PAD_CTL_ODE(1 << 11)
 
-#if defined(CONFIG_MX6SX) || defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)
-#define PAD_CTL_SPEED_LOW  (0 << 6)
-#else
+#if defined(CONFIG_MX6SL)
 #define PAD_CTL_SPEED_LOW  (1 << 6)
+#else
+#define PAD_CTL_SPEED_LOW  (0 << 6)
 #endif
 #define PAD_CTL_SPEED_MED  (2 << 6)
 #define PAD_CTL_SPEED_HIGH (3 << 6)
-- 
2.7.4

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


Re: [U-Boot] [PATCH v2] mmc: mv_sdhci: zero out sdhci_host structure

2018-04-16 Thread Stefan Roese

On 16.04.2018 16:08, Matt Pelland wrote:

The mv_sdhci driver was not zeroing the sdhci_host structure it
allocates causing random access violations in parts of the mmc core
where the "ops" member pointers are checked and called if not NULL.

Signed-off-by: Matt Pelland 
---
  drivers/mmc/mv_sdhci.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
index 69aa87babe..0ed0d38c90 100644
--- a/drivers/mmc/mv_sdhci.c
+++ b/drivers/mmc/mv_sdhci.c
@@ -68,7 +68,7 @@ static char *MVSDH_NAME = "mv_sdh";
  int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks)
  {
struct sdhci_host *host = NULL;
-   host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
+   host = calloc(1, sizeof(*host));
if (!host) {
printf("sdh_host malloc fail!\n");
return -ENOMEM;



Looks good, so:

Reviewed-by: Stefan Roese 

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


[U-Boot] Please pull u-boot-x86 (take 2)

2018-04-16 Thread Bin Meng
Hi Tom,

This includes some fixes and enhancements to VxWorks booting support,
as well as some mods to x86 I/O functions.

The following changes since commit ebca902aeb3af3eaedd2787928184ad84a86b98f:

  Merge git://git.denx.de/u-boot-imx (2018-04-15 08:43:50 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-x86.git

for you to fetch changes up to d5032392babd3a8bd027ccb79072ee7b05299b67:

  x86: Rename coreboot-x86 to coreboot (2018-04-16 22:38:53 +0800)


Bin Meng (18):
  doc: vxworks: Minor update for clarity
  bootvx: x86: Prepare e820 related stuff from the given kernel
memory base address
  bootvx: x86: Explicitly clear the bootloader image size
  vxworks: x86: Rename e820info to e820_info
  x86: Use 'unsigned int' in install_e820_map() functions
  x86: Rename e820entry to e820_entry
  elf: Clean up the ELF header file
  elf: Add ELF64 related structure defines
  elf: Add a very simple ELF64 loader
  bios: vesa: Guard setting vesa mode with CONFIG_FRAMEBUFFER_SET_VESA_MODE
  video: vesa: Change default FRAMEBUFFER_VESA_MODE
  x86: Change default FRAMEBUFFER_VESA_MODE of some boards
  pci: video: Only print out when everything is OK
  bootvx: x86: Make VxWorks EFI console driver happy
  bootvx: Refactor the bootline copy codes a little bit
  bootvx: Exit if bootline address is not specified
  bootvx: x86: Assign bootaddr based on kernel memory base
  doc: vxworks: Update x86 specific instructions

Ivan Gorinov (1):
  x86: Add 64-bit memory-mapped I/O functions

Lukasz Majewski (1):
  x86: Update the io.h file to use {out|in}_{be|le}X macros

Simon Glass (1):
  x86: Rename coreboot-x86 to coreboot

 arch/x86/cpu/coreboot/sdram.c  |   7 ++-
 arch/x86/cpu/qemu/e820.c   |   3 +-
 arch/x86/cpu/tangier/sdram.c   |   6 +-
 arch/x86/include/asm/bootparam.h   |   2 +-
 arch/x86/include/asm/e820.h|   5 +-
 arch/x86/include/asm/io.h  |  38 +++--
 arch/x86/lib/bios.c|   4 ++
 arch/x86/lib/coreboot_table.c  |   2 +-
 arch/x86/lib/e820.c|   4 +-
 arch/x86/lib/fsp/fsp_dram.c|   5 +-
 board/coreboot/coreboot/MAINTAINERS|   2 +-
 cmd/elf.c  | 231
+++
 configs/bayleybay_defconfig|   2 +-
 configs/{coreboot-x86_defconfig => coreboot_defconfig} |   0
 configs/minnowmax_defconfig|   2 +-
 configs/qemu-x86_64_defconfig  |   2 +-
 configs/qemu-x86_defconfig |   2 +-
 configs/qemu-x86_efi_payload32_defconfig   |   2 +-
 configs/qemu-x86_efi_payload64_defconfig   |   2 +-
 doc/README.vxworks |  51 ++---
 doc/README.x86 |   2 +-
 drivers/bios_emulator/atibios.c|   4 ++
 drivers/pci/pci_rom.c  |   4 +-
 drivers/video/Kconfig  |   2 +-
 include/elf.h  | 327
+++---
 include/vxworks.h  |  52 +++--
 26 files changed, 465 insertions(+), 298 deletions(-)
 rename configs/{coreboot-x86_defconfig => coreboot_defconfig} (100%)

Regards,
Bin
___
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-04-16 Thread Bin Meng
Hi Tom,

On Mon, Apr 16, 2018 at 8:31 PM, Tom Rini  wrote:
> On Mon, Apr 16, 2018 at 05:17:30PM +0800, Bin Meng wrote:
>
>> Hi Tom,
>>
>> This includes some fixes and enhancements to VxWorks booting support,
>> as well as some mods to x86 I/O functions.
>>
>> The following changes since commit ebca902aeb3af3eaedd2787928184ad84a86b98f:
>>
>>   Merge git://git.denx.de/u-boot-imx (2018-04-15 08:43:50 -0400)
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-x86.git
>>
>> for you to fetch changes up to 699b8a1386255252293d743a0b196232641167f3:
>>
>>   x86: Rename coreboot-x86 to coreboot (2018-04-16 16:54:51 +0800)
>>
>
> NAK.  This breaks most non-x86 as follows:
>m68k:  +   M5485BFE
> +(M5485BFE) ../cmd/elf.c: In function ?do_bootvx?:
> +(M5485BFE) ../cmd/elf.c:346:15: error: ?base? undeclared (first use in this 
> function)
> +(M5485BFE) bootaddr = base + X86_BOOT_LINE_OFFSET;
> +(M5485BFE)^~~~
> +(M5485BFE) ../cmd/elf.c:346:15: note: each undeclared identifier is reported 
> only once for each function it appears in
> +(M5485BFE) make[2]: *** [cmd/elf.o] Error 1
> +(M5485BFE) make[1]: *** [cmd] Error 2
> +(M5485BFE) make: *** [sub-make] Error 2

Sorry about this. I will send v2 pull request.

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


[U-Boot] [PATCH v2] mmc: mv_sdhci: zero out sdhci_host structure

2018-04-16 Thread Matt Pelland
The mv_sdhci driver was not zeroing the sdhci_host structure it
allocates causing random access violations in parts of the mmc core
where the "ops" member pointers are checked and called if not NULL.

Signed-off-by: Matt Pelland 
---
 drivers/mmc/mv_sdhci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
index 69aa87babe..0ed0d38c90 100644
--- a/drivers/mmc/mv_sdhci.c
+++ b/drivers/mmc/mv_sdhci.c
@@ -68,7 +68,7 @@ static char *MVSDH_NAME = "mv_sdh";
 int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks)
 {
struct sdhci_host *host = NULL;
-   host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
+   host = calloc(1, sizeof(*host));
if (!host) {
printf("sdh_host malloc fail!\n");
return -ENOMEM;
-- 
2.14.3

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


Re: [U-Boot] [PATCH v5 1/2] SPI Flash: add support of sst26wf* flash ICs protection ops

2018-04-16 Thread Eugeniy Paltsev
Hi Jagan!

Any comments?

On Tue, 2018-04-10 at 14:40 +0300, Eugeniy Paltsev wrote:
> sst26wf flash series block protection implementation differs
> from other SST series, so add specific implementation
> flash_lock/flash_unlock/flash_is_locked functions for sst26wf
> flash ICs.
> 
> Signed-off-by: Eugeniy Paltsev 
> ---
> Changes v4->v5:
>  * Return EACCES when flash is locked instead of custom define (SF_LOCKED)
>  * Add SST26_CTL_* prefix to sst27 lock ops enum.
>  * Move all sst26 code inside of existing CONFIG_SPI_FLASH_SST #ifdef.
> 
> Changes v3->v4:
>  * Make sst26_process_bpr() and sst26_lock_ctl() functions static.
> 
> Changes v2->v3:
>  * Move SST26 command defenition to sf_internal.h
>  * Merge sst26_set_bpr, sst26_clear_bpr and sst26_check_bpr functions
>into single sst26_process_bpr function.
>  * Use SF_UNLOCKED/SF_LOCKED instead of magic numbers in
>sst26_lock_ctl()
> 
> Changes v1->v2:
>  * Use generic defines from linux/sizes.h instead of custom ones.
> 
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
[snip]
-- 
 Eugeniy Paltsev
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH V5 2/2] imx6: sabrelite: update defconfig to use distro defaults

2018-04-16 Thread Guillaume GARDET
Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots on 
sabrelite board.

Signed-off-by: Guillaume GARDET 
Cc: Troy Kisky 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Gary Bisson 

---
 configs/mx6qsabrelite_defconfig | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 7499704058..fee33cfff1 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -3,15 +3,15 @@ CONFIG_ARCH_MX6=y
 CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_TARGET_NITROGEN6X=y
 CONFIG_CMD_HDMIDETECT=y
+CONFIG_DISTRO_DEFAULTS=y
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE"
 CONFIG_BOOTDELAY=3
+# CONFIG_USE_BOOTCOMMAND is not set
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-CONFIG_SUPPORT_RAW_INITRD=y
+CONFIG_ARCH_MISC_INIT=y
 CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
 CONFIG_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x1200
-CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_SYS_ALT_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
@@ -22,17 +22,12 @@ CONFIG_CMD_SATA=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
-- 
2.13.6

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


[U-Boot] [PATCH V5 1/2] imx6: Convert sabrelite and nitrogen6x boards to distro boot support

2018-04-16 Thread Guillaume GARDET
Boot tested on sabrelite board.

Signed-off-by: Guillaume GARDET 
Cc: Troy Kisky 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Gary Bisson 

---
 include/configs/nitrogen6x.h | 179 +++
 1 file changed, 43 insertions(+), 136 deletions(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 7d2cf0bd8c..0d0be2a955 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -80,161 +80,68 @@
 
 #define CONFIG_PREBOOT ""
 
-#ifdef CONFIG_CMD_SATA
-#define CONFIG_DRIVE_SATA "sata "
+#ifdef CONFIG_CMD_MMC
+#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1)
 #else
-#define CONFIG_DRIVE_SATA
+#define DISTRO_BOOT_DEV_MMC(func)
 #endif
 
-#ifdef CONFIG_CMD_MMC
-#define CONFIG_DRIVE_MMC "mmc "
+#ifdef CONFIG_CMD_SATA
+#define DISTRO_BOOT_DEV_SATA(func) func(SATA, sata, 0)
 #else
-#define CONFIG_DRIVE_MMC
+#define DISTRO_BOOT_DEV_SATA(func)
 #endif
 
 #ifdef CONFIG_USB_STORAGE
-#define CONFIG_DRIVE_USB "usb "
+#define DISTRO_BOOT_DEV_USB(func) func(USB, usb, 0)
 #else
-#define CONFIG_DRIVE_USB
+#define DISTRO_BOOT_DEV_USB(func)
+#endif
+
+#ifdef CONFIG_CMD_PXE
+#define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na)
+#else
+#define DISTRO_BOOT_DEV_PXE(func)
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na)
+#else
+#define DISTRO_BOOT_DEV_DHCP(func)
 #endif
 
-#define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC CONFIG_DRIVE_USB
-#define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
 
 #if defined(CONFIG_SABRELITE)
+#define FDTFILE "fdtfile=imx6q-sabrelite.dtb\0"
+#else
+/* FIXME: nitrogen6x covers multiple configs. Define fdtfile for each 
supported config. */
+#define FDTFILE
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+   DISTRO_BOOT_DEV_MMC(func) \
+   DISTRO_BOOT_DEV_SATA(func) \
+   DISTRO_BOOT_DEV_USB(func) \
+   DISTRO_BOOT_DEV_PXE(func) \
+   DISTRO_BOOT_DEV_DHCP(func)
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
-   "fdt_addr=0x1800\0" \
-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   FDTFILE \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs; " \
-   "if test ${ip_dyn} = yes; then " \
-   "setenv get_cmd dhcp; " \
-   "else " \
-   "setenv get_cmd tftp; " \
-   "fi; " \
-   "${get_cmd} ${uimage}; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   

[U-Boot] [PATCH V5 0/2] Update sabrelite and nitrogen6x boards to use distro boot support

2018-04-16 Thread Guillaume GARDET
This patch serie updates sabrelite and nitrogen6x boards to use distro boot 
support.
Sabrelite has been boot tested with boot.scr script and EFI/Grub2 on mmc0 and 
mmc1 slots.
Nitrogen6* boards have been build tested only.

Currently, only the Sabrelite has fdtfile defined.

Signed-off-by: Guillaume GARDET 
Cc: Troy Kisky 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Gary Bisson 

Changes in V5:
  * remove obsolete code from include/configs/nitrogen6x.h
  
Changes in V4:
  * Remove imx6 soc definition
  * Change comment on not defined fdtfile (no more fallback)

Changes in V3:
  * Add imx6 soc definition
  * Also update nitrogen6x config, not only sabrelite
  * Split mx6qsabrelite_defconfig update to a separate patch
Changes in V2:
  * add mx6qsabrelite_defconfig update



Guillaume GARDET (2):
  imx6: Convert sabrelite and nitrogen6x boards to distro boot support
  imx6: sabrelite: update defconfig to use distro defaults

 configs/mx6qsabrelite_defconfig |  15 ++--
 include/configs/nitrogen6x.h| 179 ++--
 2 files changed, 48 insertions(+), 146 deletions(-)

-- 
2.13.6

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


Re: [U-Boot] [PATCH 0/6] Android A/B Bootloader support

2018-04-16 Thread Alex Deymo
Hi Stanislas,
This work is in use in Android Things preview U-Boot bootloader for the
raspberry pi. The code is available in
https://android.googlesource.com/platform/external/u-boot/+/android-o-mr1-iot-preview-7
. If I remember correctly, these patches are a cleanup of that code, but
they are a bit old now and would require some rebasing and testing to build
against the latest U-Boot. Would there be interest to integrate these
patches into U-Boot here? I don't think we have changed anything since.
Thanks,
deymo.





2018-04-13 2:57 GMT+02:00 Stanislas BERTRAND :

> Hi Alex,
>
> The Android A/B bootloader patch series looks good.
>
> How far along are you to have this work integrated ?
>
> Regards,
> Stan
>
> On 04/02/2017 04:49 PM, Alex Deymo wrote:
> >* An "Android Bootloader" has a lot of requirements about how it should
> *>* behave which Android partners must implement. In particular, the new
> *>* A/B updates [1] added more requirements and flows to the bootloader
> *>* which are not common, on top of the existing flows.
> *>>* For example, a few uncommon requirements include:
> *>* * Lookup in the BCB (boot control block) whether a "recovery" message
> *>*is stored. This is used by the recovery environment when applying a
> *>*multi-stage update in the legacy update model (recovery reboots to
> *>*recovery again) and for interrumpted factory-reset (a reboot during
> *>*the factory reset should continue to reboot into factory reset until
> *>*it is done).
> *>* * A new "repair" mode. In the A/B model, when none of the slots is
> *>*bootable, the device would boot into repair mode, which is often the
> *>*same as "bootloader" mode (fastboot).
> *>* * Recovery as root: In newer version of AOSP, it is possible to mount
> *>*the system image as / without an initramfs, which then frees up the
> *>*initramfs in the "boot" partition to hold the "recovery" initramfs.
> *>*This is the default for new devices and required for the A/B setup.
> *>>* This patchset updates the Android-related headers and introduces new
> *>* commands to boot a recent Android build. This work is based on the
> *>* bootloader used in the Raspberry Pi in Android Things and extensively
> *>* tested there.
> *>>* [1] https://source.android.com/devices/tech/ota/ab_updates.html 
> 
> *>>>* Alex Deymo (6):
> *>*image: Update include/android_image.h
> *>*image: Implement a function to load Android Images.
> *>*cmd: Add 'load_android' command to load Android images.
> *>*disk: Return the partition number in part_get_info_by_name()
> *>*Initial support for the Android Bootloader flow
> *>*cmd: Add "boot_android" command.
> *>>*   README   |  25 ++-
> *>*   cmd/Kconfig  |  19 ++
> *>*   cmd/Makefile |   2 +
> *>*   cmd/boot_android.c   | 126 +
> *>*   cmd/load_android.c   |  56 ++
> *>*   common/Kconfig   |  19 ++
> *>*   common/Makefile  |   1 +
> *>*   common/android_bootloader.c  | 350 
> +++
> *>*   common/fb_mmc.c  |   6 +-
> *>*   common/image-android.c   |  60 ++
> *>*   disk/part.c  |   2 +-
> *>*   include/android_bootloader.h |  48 +
> *>*   include/android_bootloader_message.h | 174 +
> *>*   include/android_image.h  |  24 ++-
> *>*   include/image.h  |  19 ++
> *>*   include/part.h   |   3 +-
> *>*   16 files changed, 920 insertions(+), 14 deletions(-)
> *>*   create mode 100644 cmd/boot_android.c
> *>*   create mode 100644 cmd/load_android.c
> *>*   create mode 100644 common/android_bootloader.c
> *>*   create mode 100644 include/android_bootloader.h
> *>*   create mode 100644 include/android_bootloader_message.h
> *>
>
>
>
___
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-04-16 Thread Tom Rini
On Mon, Apr 16, 2018 at 05:17:30PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This includes some fixes and enhancements to VxWorks booting support,
> as well as some mods to x86 I/O functions.
> 
> The following changes since commit ebca902aeb3af3eaedd2787928184ad84a86b98f:
> 
>   Merge git://git.denx.de/u-boot-imx (2018-04-15 08:43:50 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to 699b8a1386255252293d743a0b196232641167f3:
> 
>   x86: Rename coreboot-x86 to coreboot (2018-04-16 16:54:51 +0800)
> 

NAK.  This breaks most non-x86 as follows:
   m68k:  +   M5485BFE
+(M5485BFE) ../cmd/elf.c: In function ?do_bootvx?:
+(M5485BFE) ../cmd/elf.c:346:15: error: ?base? undeclared (first use in this 
function)
+(M5485BFE) bootaddr = base + X86_BOOT_LINE_OFFSET;
+(M5485BFE)^~~~
+(M5485BFE) ../cmd/elf.c:346:15: note: each undeclared identifier is reported 
only once for each function it appears in
+(M5485BFE) make[2]: *** [cmd/elf.o] Error 1
+(M5485BFE) make[1]: *** [cmd] Error 2
+(M5485BFE) make: *** [sub-make] Error 2

-- 
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] u-boot 2018 SPI SPL

2018-04-16 Thread Fabio Estevam
Hi Mehmet,

On Mon, Apr 16, 2018 at 8:36 AM, Mehmet Ali İPİN
 wrote:

> U-Boot SPL 2018.05-rc1 (Apr 16 2018 - 00:31:02 -0700)
> SPL: Unsupported Boot Device!

You need to debug why you are getting this message when booting from SPI.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] u-boot 2018 SPI SPL

2018-04-16 Thread Mehmet Ali İPİN
Dear Fabio,

Thank you for your helps..

I applied the procedure which is explained in board/congatec/cgtqmx6eval/README 
document.
Upgraded u-boot to 1018.05-rc1, 
but as you will see below, I received same message;

I will compare my config/header files with congatec's, but I don't know which 
parameters/definitions (should be /should not be) used; There fore I will 
appreciate any help if you could..

Thanks and best regards.


=> setenv ipaddr 10.4.50.5
=> setenv serverip 10.4.50.50
=> ping 10.4.50.50
Using FEC device
host 10.4.50.50 is alive
=>  sf probe 0
SF: Detected M45PE16 with page size 256 Bytes, erase size 64 KiB, total 2 MiB
=> tftp 0x1200 SPL
Using FEC device
TFTP from server 10.4.50.50; our IP address is 10.4.50.5
Filename 'SPL'.
Load address: 0x1200
Loading: 
 3.2 MiB/s
done
Bytes transferred = 56320 (dc00 hex)
=> sf erase 0x0 0x1
SF: 65536 bytes @ 0x0 Erased: OK
=> sf write 0x1200 0x400 0x1
device 0 offset 0x400, size 0x1
SF: 65536 bytes @ 0x400 Written: OK
=> tftp 0x1200 u-boot.img
Using FEC device
TFTP from server 10.4.50.50; our IP address is 10.4.50.5
Filename 'u-boot.img'.
Load address: 0x1200
Loading: 
 5.7 MiB/s
done
Bytes transferred = 349576 (55588 hex)
=> sf erase 0x1 0x7
SF: 458752 bytes @ 0x1 Erased: OK
=> sf write 0x1200 0x1 0x7
device 0 offset 0x1, size 0x7
SF: 458752 bytes @ 0x1 Written: OK
=>

U-Boot SPL 2018.05-rc1 (Apr 16 2018 - 00:31:02 -0700)
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###


On Fri, Apr 13, 2018 at 10:13 AM, Mehmet Ali İPİN  
wrote:
>
> Dear Fabio,
>
>
> I received the following message
>
> U-Boot SPL 2018.01 (Jan 17 2018 - 05:49:34)

Please use mainline 2018.03 or 2018.05-rc1 instead.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Please pull u-boot-cfi-flash/master

2018-04-16 Thread Stefan Roese
Hi Tom,

please pull this one CFI related patch from Mario.

Thanks,
Stefan

The following changes since commit ebca902aeb3af3eaedd2787928184ad84a86b98f:

  Merge git://git.denx.de/u-boot-imx (2018-04-15 08:43:50 -0400)

are available in the Git repository at:

  git://www.denx.de/git/u-boot-cfi-flash.git 

for you to fetch changes up to 8bfeb33c463296af38432c3dbfb976f45545e381:

  mtd: cfi_flash: Make live-tree compatible (2018-04-16 09:55:59 +0200)


Mario Six (1):
  mtd: cfi_flash: Make live-tree compatible

 drivers/mtd/cfi_flash.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [Feature] Android Fastboot over Ethernet

2018-04-16 Thread Lukasz Majewski
Hi Alex,

> Hi all,
> 
> Android Things on rpi supports fastboot over udp since most rpis don't
> expose a suitable USB port for fastboor over USB. It also uses the A/B
> booting mechanism similar to Pixel phones.
> 
> The U-Boot code for the latest Android Things preview is in AOSP:
> https://android.googlesource.com/platform/external/u-boot/+/android-o-mr1-iot-preview-7
> 
> In particular, the fastboot over UDP support was added by
> https://android.googlesource.com/platform/external/u-boot/+/018e7c25c7c0260a6d021c84521eab808657c1a8
> and subsequent commits. "git log android-o-mr1-iot-preview-7 --not
> v2017.07 --oneline --no-merges" should give you a cleaner list what
> was added on top of 2017.07.
> 
> I believe most of those patches (or cleaned up versions) were shared
> in this list at the time.

I would say that I would be more than happy to see patches adding this
feature to u-boot's fastboot.

> 
> Best regards,
> deymo.
> 
> 
> 2018-04-04 9:20 GMT+02:00 Lukasz Majewski :
> 
> > Hi Stanislas,
> >  
> > > Has there been any development to support Android Fastboot
> > > Ethernet feature in U-Boot ?
> > >
> > > https://android.googlesource.com/platform/system/core/+/  
> > android-7.1.2_r36/fastboot/fastboot_protocol.txt  
> > >
> > >
> > > The target board has not USB device port available to flash the
> > > on-board eMMC.  
> >
> > I'm not aware of any such effort.
> >
> > However, if you want to flash eMMC via ETH, then maybe you can look
> > into DFU TFTP feature.
> >
> > Please read: ./doc/README.dfutftp
> >  
> > >
> > > Flashing the eMMC via U-Boot shell commands would be very much
> > > slower and limited.
> > >
> > >
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > https://lists.denx.de/listinfo/u-boot  
> >
> >
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > w...@denx.de
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> >
> >  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


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


Re: [U-Boot] [PATCH] mtd: cfi_flash: Make live-tree compatible

2018-04-16 Thread Stefan Roese

On 28.03.2018 14:38, Mario Six wrote:

Make the cfi_flash driver compatible with a live device tree.

Signed-off-by: Mario Six 
---
  drivers/mtd/cfi_flash.c | 21 +++--
  1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index da44e6184e..e5509fe353 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -2461,27 +2461,28 @@ unsigned long flash_init(void)
  #ifdef CONFIG_CFI_FLASH /* for driver model */
  static int cfi_flash_probe(struct udevice *dev)
  {
-   void *blob = (void *)gd->fdt_blob;
-   int node = dev_of_offset(dev);
const fdt32_t *cell;
-   phys_addr_t addr;
-   int parent, addrc, sizec;
+   int addrc, sizec;
int len, idx;
  
-	parent = fdt_parent_offset(blob, node);

-   fdt_support_default_count_cells(blob, parent, , );
-   /* decode regs, there may be multiple reg tuples. */
-   cell = fdt_getprop(blob, node, "reg", );
+   addrc = dev_read_addr_cells(dev);
+   sizec = dev_read_size_cells(dev);
+
+   /* decode regs; there may be multiple reg tuples. */
+   cell = dev_read_prop(dev, "reg", );
if (!cell)
return -ENOENT;
idx = 0;
len /= sizeof(fdt32_t);
while (idx < len) {
-   addr = fdt_translate_address((void *)blob,
-node, cell + idx);
+   phys_addr_t addr;
+
+   addr = dev_translate_address(dev, cell + idx);
+
flash_info[cfi_flash_num_flash_banks].dev = dev;
flash_info[cfi_flash_num_flash_banks].base = addr;
cfi_flash_num_flash_banks++;
+
idx += addrc + sizec;
}
gd->bd->bi_flashstart = flash_info[0].base;



Thanks. Looks good, so:

Applied to u-boot-cfi-flash/master.

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


Re: [U-Boot] Re-introducing support for OLD hardware

2018-04-16 Thread Lukasz Majewski
On Thu, 12 Apr 2018 09:04:20 +0200
Jason Mitchell  wrote:

> Good day all
> 
> I am currently faced with a task of having to run new software on
> ageing hardware. We have currently about 1000 units in the field of a
> machine that runs Windows CE using the Samsung S3C6410.
> 
> Because these are considerable assets its not a simple case of
> replacing them with new, more modern hardware.
> 
> The goal is to be able to get these existing boards to run Ubuntu so
> that we can run GoLang applications, so we need the GUI with just a
> relatively recent browser.
> 
> The board in question is a near perfect clone of the SMDK6410, which
> was supported fully in U-boot in the past, indeed I can select
> SMDK6410 and compile a working U-boot using 1.3.4 sources
> 
> After much effort I managed to get a tailored (tailored as in having
> changed the memory configuration to match the hardware) U-boot V1.3.4
> compiled and running for this chip, the problem now, obviously we
> have a fairly recent Linux kernel compiled and it won't boot because
> the Device Tree Blob doesn't exist on such an old version of U-boot.
> 
> So my questions are:
> 
> - Has anyone perhaps created a branch or fork of the current or nearly
> current version of U-boot and patched in this support. I see a lot of
> Chinese websites where they seem to have done this but the language
> barrier is a big problem. Also a lot of dead links are another
> problem.
> 
> - If there isn't something out there, would it be possible to run
> through the steps with me to add support for this CPU again. I don't
> mind doing the work, the main issue is I have no clue how U-boot
> actually works internally.
> 
> I have FULL JTAG access to this board, with a perfectly functional
> OpenOCD setup. This is how we are able to program versions of U-boot
> into the FLASH.
> 
> Hoping someone can assist

If this helps - I do have some code (including OpenOCD
restoration/debricking files) to add support for smdk6410 based on
v2013.04 u-boot.

As fair as I remember this code was booting till prompt, but was NOT in
a shape allowing mainlining.

Unfortunately, I don't have smdk6410 dev board anymore, so I cannot
help with testing/tunning the HW.

> 
> Kindest Regards,
> Jason Mitchell
> Software Developer
> Spark ATM Systems (PTY) LTD
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


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


[U-Boot] nand write isn't working with u-boot

2018-04-16 Thread Mr. goldenstreet
hey,
My board is arria v.
my u-boot version is 01/2017 but i checked it on 11/2017 as well.
i'm trying to write to the nand and for some reason this doesn't work.
my output is:

# nand write 0x0 0 10
nand write: device 0 offset 0x0, size 0x10
nand write to offset 0 failed -5
0 bytes written: ERROR
#

i tried to debug it but i didnt understand what is the reason, from my
searches i suspect it has something to do with timeout but i'm not sure at
all.

thanks.



--
Sent from: http://u-boot.10912.n7.nabble.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [Feature] Android Fastboot over Ethernet

2018-04-16 Thread Alex Deymo
Hi all,

Android Things on rpi supports fastboot over udp since most rpis don't
expose a suitable USB port for fastboor over USB. It also uses the A/B
booting mechanism similar to Pixel phones.

The U-Boot code for the latest Android Things preview is in AOSP:
https://android.googlesource.com/platform/external/u-boot/+/android-o-mr1-iot-preview-7

In particular, the fastboot over UDP support was added by
https://android.googlesource.com/platform/external/u-boot/+/018e7c25c7c0260a6d021c84521eab808657c1a8
and subsequent commits. "git log android-o-mr1-iot-preview-7 --not v2017.07
--oneline --no-merges" should give you a cleaner list what was added on top
of 2017.07.

I believe most of those patches (or cleaned up versions) were shared in
this list at the time.

Best regards,
deymo.


2018-04-04 9:20 GMT+02:00 Lukasz Majewski :

> Hi Stanislas,
>
> > Has there been any development to support Android Fastboot Ethernet
> > feature in U-Boot ?
> >
> > https://android.googlesource.com/platform/system/core/+/
> android-7.1.2_r36/fastboot/fastboot_protocol.txt
> >
> >
> > The target board has not USB device port available to flash the
> > on-board eMMC.
>
> I'm not aware of any such effort.
>
> However, if you want to flash eMMC via ETH, then maybe you can look
> into DFU TFTP feature.
>
> Please read: ./doc/README.dfutftp
>
> >
> > Flashing the eMMC via U-Boot shell commands would be very much slower
> > and limited.
> >
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>
> ___
> 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] x86: Rename coreboot-x86 to coreboot

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 5:51 PM, Bin Meng  wrote:
> On Fri, Apr 13, 2018 at 4:04 AM, Simon Glass  wrote:
>> We only use coreboot as a target on x86 platforms, since on ARM platforms
>> U-Boot always runs as the primary boot loader. Rename the coreboot-x86
>> platform to reflect this.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>>  board/coreboot/coreboot/MAINTAINERS| 2 +-
>>  configs/{coreboot-x86_defconfig => coreboot_defconfig} | 0
>>  doc/README.x86 | 2 +-
>>  3 files changed, 2 insertions(+), 2 deletions(-)
>>  rename configs/{coreboot-x86_defconfig => coreboot_defconfig} (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 v2 14/18] bootvx: x86: Make VxWorks EFI console driver happy

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 12:42 AM, Simon Glass  wrote:
> On 11 April 2018 at 23:02, Bin Meng  wrote:
>> When booting from EFI BIOS, VxWorks bootloader stores the EFI GOP
>> framebuffer info at a pre-defined offset @ 0x6100. When VxWorks
>> kernel boots up, its EFI console driver tries to find such a block
>> and if the signature matches, the framebuffer information will be
>> used to initialize the driver.
>>
>> However it is not necessary to prepare an EFI environment for
>> VxWorks's EFI console driver to function (eg: EFI loader in
>> U-Boot). If U-Boot has already initialized the graphics card and
>> set it to a VESA mode that is compatible with EFI GOP, we can
>> simply prepare such a block for VxWorks.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>> Changes in v2: None
>>
>>  cmd/elf.c | 19 +++
>>  include/vxworks.h | 26 ++
>>  2 files changed, 45 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 v2 10/18] bios: vesa: Guard setting vesa mode with CONFIG_FRAMEBUFFER_SET_VESA_MODE

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 12:42 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 April 2018 at 23:02, Bin Meng  wrote:
>> If CONFIG_FRAMEBUFFER_SET_VESA_MODE is not set, don't switch
>> graphics card to VESA mode. This applies to both native mode
>> and emulator mode of running the VGA BIOS.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/lib/bios.c | 4 
>>  drivers/bios_emulator/atibios.c | 4 
>>  2 files changed, 8 insertions(+)
>
> Could this use if() instead of #ifdef ?
>
> 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 18/18] doc: vxworks: Update x86 specific instructions

2018-04-16 Thread Bin Meng
On Thu, Apr 12, 2018 at 1:02 PM, Bin Meng  wrote:
> This updates the doc of booting VxWorks, like loading an x64 kernel,
> and how to make VxWorks graphics console driver work.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - update the graphics console driver information
>
>  doc/README.vxworks | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 17/18] bootvx: x86: Assign bootaddr based on kernel memory base

2018-04-16 Thread Bin Meng
On Thu, Apr 12, 2018 at 1:02 PM, Bin Meng  wrote:
> On VxWorks x86 its bootline address is at a pre-defined offset @
> 0x1200. If 'bootaddr' is not passed via environment variable, we
> assign its value based on the kernel memory base address.
>
> Signed-off-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  cmd/elf.c | 91 
> +--
>  include/vxworks.h |  3 ++
>  2 files changed, 51 insertions(+), 43 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 07/18] elf: Clean up the ELF header file

2018-04-16 Thread Bin Meng
On Thu, Apr 12, 2018 at 3:29 PM, Christian Gmeiner
 wrote:
> 2018-04-12 7:02 GMT+02:00 Bin Meng :
>> Fix various style violations in elf.h
>> - use correct comment format if the comment fits in just one line
>> - remove the ending period for the one-line comment
>> - use tab for the indention instead of space
>> - put the opening brace at the same line of a typedef/union
>> - remove  in a 'typedef struct' for consistency
>>
>> Signed-off-by: Bin Meng 
>
> Reviewed-by: Christian Gmeiner 
>
>> ---
>>
>> Changes in v2: None
>>
>>  include/elf.h | 284 
>> --
>>  1 file changed, 138 insertions(+), 146 deletions(-)
>>

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


Re: [U-Boot] [PATCH v2 13/18] pci: video: Only print out when everything is OK

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 12:42 AM, Simon Glass  wrote:
> On 11 April 2018 at 23:02, Bin Meng  wrote:
>> If video initialization fails, the "Video:" output message will be
>> mixed with the next console log. Change to print out such message
>> only when everything is OK, which improves the boot log readability.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>> Changes in v2: None
>>
>>  drivers/pci/pci_rom.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> 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 11/18] video: vesa: Change default FRAMEBUFFER_VESA_MODE

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 12:42 AM, Simon Glass  wrote:
> On 11 April 2018 at 23:02, Bin Meng  wrote:
>> This changes the default FRAMEBUFFER_VESA_MODE to use 32-bit pixel
>> format for better VxWorks compatibility.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>> Changes in v2: None
>>
>>  drivers/video/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 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 04/18] vxworks: x86: Rename e820info to e820_info

2018-04-16 Thread Bin Meng
On Thu, Apr 12, 2018 at 3:26 PM, Christian Gmeiner
 wrote:
> 2018-04-12 7:02 GMT+02:00 Bin Meng :
>> This changes 'struct e820info' to 'struct e820_info' to conform
>> with the coding style.
>>
>> Signed-off-by: Bin Meng 
>
> Reviewed-by: Christian Gmeiner 
>

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


Re: [U-Boot] [PATCH v2 12/18] x86: Change default FRAMEBUFFER_VESA_MODE of some boards

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 12:42 AM, Simon Glass  wrote:
> On 11 April 2018 at 23:02, Bin Meng  wrote:
>> This changes some boards' default FRAMEBUFFER_VESA_MODE to use 32-bit
>> pixel format for better VxWorks compatibility.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>> Changes in v2: None
>>
>>  configs/bayleybay_defconfig  | 2 +-
>>  configs/minnowmax_defconfig  | 2 +-
>>  configs/qemu-x86_64_defconfig| 2 +-
>>  configs/qemu-x86_defconfig   | 2 +-
>>  configs/qemu-x86_efi_payload32_defconfig | 2 +-
>>  configs/qemu-x86_efi_payload64_defconfig | 2 +-
>>  6 files changed, 6 insertions(+), 6 deletions(-)
>
> 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 16/18] bootvx: Exit if bootline address is not specified

2018-04-16 Thread Bin Meng
On Thu, Apr 12, 2018 at 1:02 PM, Bin Meng  wrote:
> Exit the 'bootvx' command if bootline address is not specified.
>
> Signed-off-by: Bin Meng 
> ---
>
> Changes in v2: None
>
>  cmd/elf.c | 109 
> ++
>  1 file changed, 53 insertions(+), 56 deletions(-)
>

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


Re: [U-Boot] [PATCH v2 15/18] bootvx: Refactor the bootline copy codes a little bit

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 12:42 AM, Simon Glass  wrote:
> On 11 April 2018 at 23:02, Bin Meng  wrote:
>> There is a small duplication in do_bootvx() that does the bootline
>> copy. Refactor this a little bit to make it simpler.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>> Changes in v2: None
>>
>>  cmd/elf.c | 15 +--
>>  1 file changed, 5 insertions(+), 10 deletions(-)
>
> 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 05/18] x86: Use 'unsigned int' in install_e820_map() functions

2018-04-16 Thread Bin Meng
On Thu, Apr 12, 2018 at 3:27 PM, Christian Gmeiner
 wrote:
> 2018-04-12 7:02 GMT+02:00 Bin Meng :
>> This fixes the following checkpatch warning:
>>
>>   warning: Prefer 'unsigned int' to bare use of 'unsigned'
>>
>> Signed-off-by: Bin Meng 
>
> Reviewed-by: Christian Gmeiner 
>
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/cpu/coreboot/sdram.c | 7 ---
>>  arch/x86/cpu/qemu/e820.c  | 3 ++-
>>  arch/x86/cpu/tangier/sdram.c  | 6 --
>>  arch/x86/include/asm/e820.h   | 3 ++-
>>  arch/x86/lib/e820.c   | 4 ++--
>>  arch/x86/lib/fsp/fsp_dram.c   | 5 +++--
>>  6 files changed, 17 insertions(+), 11 deletions(-)
>>

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


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

2018-04-16 Thread Bin Meng
Hi Tom,

This includes some fixes and enhancements to VxWorks booting support,
as well as some mods to x86 I/O functions.

The following changes since commit ebca902aeb3af3eaedd2787928184ad84a86b98f:

  Merge git://git.denx.de/u-boot-imx (2018-04-15 08:43:50 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-x86.git

for you to fetch changes up to 699b8a1386255252293d743a0b196232641167f3:

  x86: Rename coreboot-x86 to coreboot (2018-04-16 16:54:51 +0800)


Bin Meng (18):
  doc: vxworks: Minor update for clarity
  bootvx: x86: Prepare e820 related stuff from the given kernel
memory base address
  bootvx: x86: Explicitly clear the bootloader image size
  vxworks: x86: Rename e820info to e820_info
  x86: Use 'unsigned int' in install_e820_map() functions
  x86: Rename e820entry to e820_entry
  elf: Clean up the ELF header file
  elf: Add ELF64 related structure defines
  elf: Add a very simple ELF64 loader
  bios: vesa: Guard setting vesa mode with CONFIG_FRAMEBUFFER_SET_VESA_MODE
  video: vesa: Change default FRAMEBUFFER_VESA_MODE
  x86: Change default FRAMEBUFFER_VESA_MODE of some boards
  pci: video: Only print out when everything is OK
  bootvx: x86: Make VxWorks EFI console driver happy
  bootvx: Refactor the bootline copy codes a little bit
  bootvx: Exit if bootline address is not specified
  bootvx: x86: Assign bootaddr based on kernel memory base
  doc: vxworks: Update x86 specific instructions

Ivan Gorinov (1):
  x86: Add 64-bit memory-mapped I/O functions

Lukasz Majewski (1):
  x86: Update the io.h file to use {out|in}_{be|le}X macros

Simon Glass (1):
  x86: Rename coreboot-x86 to coreboot

 arch/x86/cpu/coreboot/sdram.c  |   7 ++-
 arch/x86/cpu/qemu/e820.c   |   3 +-
 arch/x86/cpu/tangier/sdram.c   |   6 +-
 arch/x86/include/asm/bootparam.h   |   2 +-
 arch/x86/include/asm/e820.h|   5 +-
 arch/x86/include/asm/io.h  |  38 +++--
 arch/x86/lib/bios.c|   4 ++
 arch/x86/lib/coreboot_table.c  |   2 +-
 arch/x86/lib/e820.c|   4 +-
 arch/x86/lib/fsp/fsp_dram.c|   5 +-
 board/coreboot/coreboot/MAINTAINERS|   2 +-
 cmd/elf.c  | 233
+++
 configs/bayleybay_defconfig|   2 +-
 configs/{coreboot-x86_defconfig => coreboot_defconfig} |   0
 configs/minnowmax_defconfig|   2 +-
 configs/qemu-x86_64_defconfig  |   2 +-
 configs/qemu-x86_defconfig |   2 +-
 configs/qemu-x86_efi_payload32_defconfig   |   2 +-
 configs/qemu-x86_efi_payload64_defconfig   |   2 +-
 doc/README.vxworks |  51 ++---
 doc/README.x86 |   2 +-
 drivers/bios_emulator/atibios.c|   4 ++
 drivers/pci/pci_rom.c  |   4 +-
 drivers/video/Kconfig  |   2 +-
 include/elf.h  | 327
+++---
 include/vxworks.h  |  52 +++--
 26 files changed, 466 insertions(+), 299 deletions(-)
 rename configs/{coreboot-x86_defconfig => coreboot_defconfig} (100%)

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


Re: [U-Boot] [PATCH v2 08/18] elf: Add ELF64 related structure defines

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 12:41 AM, Simon Glass  wrote:
> On 11 April 2018 at 23:02, Bin Meng  wrote:
>> This adds ELF header, program header and section header structure
>> defines for the 64-bit ELF image.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>> Changes in v2: None
>>
>>  include/elf.h | 43 +++
>>  1 file changed, 43 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 v2 09/18] elf: Add a very simple ELF64 loader

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 12:42 AM, Simon Glass  wrote:
> On 11 April 2018 at 23:02, Bin Meng  wrote:
>> This adds a very simple ELF64 loader via program headers, similar
>> to load_elf_image_phdr() that we already have.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> Changes in v2:
>> - update the ELF32 and ELF64 loader comments
>>
>>  cmd/elf.c | 44 +++-
>>  1 file changed, 43 insertions(+), 1 deletion(-)
>
> 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 03/18] bootvx: x86: Explicitly clear the bootloader image size

2018-04-16 Thread Bin Meng
On Fri, Apr 13, 2018 at 12:41 AM, Simon Glass  wrote:
> On 11 April 2018 at 23:02, Bin Meng  wrote:
>> VxWorks bootloader stores its size at a pre-defined offset @ 0x5004.
>> Later when VxWorks kernel boots up and system memory information is
>> retrieved from the E820 table, the bootloader size will be subtracted
>> from the total system memory size to calculate the size of available
>> memory for the OS.
>>
>> Explicitly clear the bootloader image size otherwise if memory
>> at this offset happens to contain some garbage data, the final
>> available memory size for the kernel is insane.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>> Changes in v2: None
>>
>>  cmd/elf.c | 7 +++
>>  include/vxworks.h | 9 +
>>  2 files changed, 16 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 v2 06/18] x86: Rename e820entry to e820_entry

2018-04-16 Thread Bin Meng
On Thu, Apr 12, 2018 at 3:28 PM, Christian Gmeiner
 wrote:
> 2018-04-12 7:02 GMT+02:00 Bin Meng :
>> This changes 'struct e820entry' to 'struct e820_entry' to conform
>> with the coding style.
>>
>> Signed-off-by: Bin Meng 
>
> Reviewed-by: Christian Gmeiner 
>
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/cpu/coreboot/sdram.c| 2 +-
>>  arch/x86/cpu/qemu/e820.c | 2 +-
>>  arch/x86/cpu/tangier/sdram.c | 4 ++--
>>  arch/x86/include/asm/bootparam.h | 2 +-
>>  arch/x86/include/asm/e820.h  | 4 ++--
>>  arch/x86/lib/coreboot_table.c| 2 +-
>>  arch/x86/lib/e820.c  | 2 +-
>>  arch/x86/lib/fsp/fsp_dram.c  | 2 +-
>>  cmd/elf.c| 6 +++---
>>  9 files changed, 13 insertions(+), 13 deletions(-)
>>

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


Re: [U-Boot] [PATCH v2 02/18] bootvx: x86: Prepare e820 related stuff from the given kernel memory base address

2018-04-16 Thread Bin Meng
On Thu, Apr 12, 2018 at 3:25 PM, Christian Gmeiner
 wrote:
> 2018-04-12 7:02 GMT+02:00 Bin Meng :
>> At present two environment variables 'e820data'/'e820info' are required
>> to boot a VxWorks x86 kernel, but this is superfluous. The offset of
>> these two tables are actually at a fixed offset from the kernel memory
>> base address and we can provide the kernel memory base address to U-Boot
>> via only one variable 'vx_phys_mem_base'.
>>
>> Note as it name indicates, the physical address should be provided.
>>
>> Signed-off-by: Bin Meng 
>
> Reviewed-by: Christian Gmeiner 
>
>> ---
>>
>> Changes in v2: None
>>
>>  cmd/elf.c  | 20 +++-
>>  doc/README.vxworks | 18 +++---
>>  include/vxworks.h  | 12 +---
>>  3 files changed, 23 insertions(+), 27 deletions(-)
>>

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


Re: [U-Boot] [PATCH v2 01/18] doc: vxworks: Minor update for clarity

2018-04-16 Thread Bin Meng
On Thu, Apr 12, 2018 at 1:02 PM, Bin Meng  wrote:
> This corrects a typo and updates several places for clarity.
>
> Signed-off-by: Bin Meng 
> Reviewed-by: Christian Gmeiner 
> ---
>
> Changes in v2: None
>
>  doc/README.vxworks | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

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


[U-Boot] [PATCH] serial: Remove duplicated line in Makefile

2018-04-16 Thread Patrice Chotard
The line "-obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o"
is found twice in Makefile.

Fixes: ae74de0dfd45 ("serial: stm32: Rename serial_stm32x7.c to serial_stm32.c"

Signed-off-by: Patrice Chotard 
---

 drivers/serial/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 6937ef962868..16609edf4b5a 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -60,7 +60,6 @@ obj-$(CONFIG_UNIPHIER_SERIAL) += serial_uniphier.o
 obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o
 obj-$(CONFIG_STI_ASC_SERIAL) += serial_sti_asc.o
 obj-$(CONFIG_PIC32_SERIAL) += serial_pic32.o
-obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o
 obj-$(CONFIG_BCM283X_MU_SERIAL) += serial_bcm283x_mu.o
 obj-$(CONFIG_BCM283X_PL011_SERIAL) += serial_bcm283x_pl011.o
 obj-$(CONFIG_MSM_SERIAL) += serial_msm.o
-- 
1.9.1

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


[U-Boot] [PATCH 3/6] tegra: psci: save context id in cpu_on command

2018-04-16 Thread Patrick Delaunay
Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-tegra/psci.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/psci.S b/arch/arm/mach-tegra/psci.S
index 645d08f..448df83 100644
--- a/arch/arm/mach-tegra/psci.S
+++ b/arch/arm/mach-tegra/psci.S
@@ -90,7 +90,8 @@ ENTRY(psci_cpu_on)
mov r4, r1
mov r0, r1
mov r1, r2
-   bl  psci_save_target_pc @ store target PC
+   mov r2, r3
+   bl  psci_save   @ store target PC and context id
mov r1, r4
 
ldr r6, =TEGRA_RESET_EXCEPTION_VECTOR
-- 
2.7.4

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


[U-Boot] [PATCH 2/6] imx7: psci: save context id in cpu_on command

2018-04-16 Thread Patrick Delaunay
Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-imx/mx7/psci.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/mx7/psci.S b/arch/arm/mach-imx/mx7/psci.S
index bc2cd8a..7ee2dd7 100644
--- a/arch/arm/mach-imx/mx7/psci.S
+++ b/arch/arm/mach-imx/mx7/psci.S
@@ -24,7 +24,8 @@ psci_cpu_on:
mov r5, r1
mov r0, r1
mov r1, r2
-   bl  psci_save_target_pc
+   mov r2, r3
+   bl  psci_save
 
mov r0, r4
mov r1, r5
-- 
2.7.4

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


[U-Boot] [PATCH 4/6] uniphier: psci: save context id in cpu_on command

2018-04-16 Thread Patrick Delaunay
Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)

Signed-off-by: Patrick Delaunay 
---

 arch/arm/mach-uniphier/arm32/psci.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-uniphier/arm32/psci.c 
b/arch/arm/mach-uniphier/arm32/psci.c
index efe7419..af33cd4 100644
--- a/arch/arm/mach-uniphier/arm32/psci.c
+++ b/arch/arm/mach-uniphier/arm32/psci.c
@@ -131,7 +131,8 @@ void psci_arch_init(void)
 
 u32 uniphier_psci_holding_pen_release __secure_data = 0x;
 
-int __secure psci_cpu_on(u32 function_id, u32 cpuid, u32 entry_point)
+int __secure psci_cpu_on(u32 function_id, u32 cpuid, u32 entry_point,
+u32 context_id)
 {
u32 cpu = cpuid & 0xff;
 
@@ -139,9 +140,11 @@ int __secure psci_cpu_on(u32 function_id, u32 cpuid, u32 
entry_point)
debug_puth(cpuid);
debug_puts(", entry_point=");
debug_puth(entry_point);
+   debug_puts(", context_id=");
+   debug_puth(context_id);
debug_puts("\n");
 
-   psci_save_target_pc(cpu, entry_point);
+   psci_save(cpu, entry_point, context_id);
 
/* We assume D-cache is off, so do not call flush_dcache() here */
uniphier_psci_holding_pen_release = cpu;
-- 
2.7.4

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


[U-Boot] [PATCH 5/6] sunxi: psci: save context id in cpu_on command

2018-04-16 Thread Patrick Delaunay
Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)

Signed-off-by: Patrick Delaunay 
---

 arch/arm/cpu/armv7/sunxi/psci.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 18da9cb..11b21fe 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -243,14 +243,15 @@ out:
cp15_write_scr(scr);
 }
 
-int __secure psci_cpu_on(u32 __always_unused unused, u32 mpidr, u32 pc)
+int __secure psci_cpu_on(u32 __always_unused unused, u32 mpidr, u32 pc,
+u32 context_id)
 {
struct sunxi_cpucfg_reg *cpucfg =
(struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
u32 cpu = (mpidr & 0x3);
 
-   /* store target PC */
-   psci_save_target_pc(cpu, pc);
+   /* store target PC and context id */
+   psci_save(cpu, pc, context_id);
 
/* Set secondary core power on PC */
sunxi_set_entry_address(_cpu_entry);
-- 
2.7.4

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


[U-Boot] [PATCH 1/6] ls102xa: psci: save context id in cpu_on command

2018-04-16 Thread Patrick Delaunay
Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)


Signed-off-by: Patrick Delaunay 
---

 arch/arm/cpu/armv7/ls102xa/psci.S | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S 
b/arch/arm/cpu/armv7/ls102xa/psci.S
index e1dc5f3..a355c88 100644
--- a/arch/arm/cpu/armv7/ls102xa/psci.S
+++ b/arch/arm/cpu/armv7/ls102xa/psci.S
@@ -125,7 +125,8 @@ psci_cpu_on:
 
mov r0, r4
mov r1, r2
-   bl  psci_save_target_pc
+   mov r2, r3
+   bl  psci_save
mov r1, r4
 
@ Get DCFG base address
-- 
2.7.4

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


[U-Boot] [PATCH 6/6] psci: arm: remove armv7 function psci_save_target_pc

2018-04-16 Thread Patrick Delaunay
This function is no more used, and replaced by psci_save
which save also context id as requested by PSCI requirements.

Even if the context id is not used by Linux, it should be saved
and restored in r0 when the CPU_ON is performed.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/cpu/armv7/psci-common.c | 7 ---
 arch/arm/include/asm/psci.h  | 3 +--
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm/cpu/armv7/psci-common.c b/arch/arm/cpu/armv7/psci-common.c
index 73f986b..a328b2b 100644
--- a/arch/arm/cpu/armv7/psci-common.c
+++ b/arch/arm/cpu/armv7/psci-common.c
@@ -27,13 +27,6 @@
 static u32 psci_target_pc[CONFIG_ARMV7_PSCI_NR_CPUS] __secure_data = { 0 };
 static u32 psci_context_id[CONFIG_ARMV7_PSCI_NR_CPUS] __secure_data = { 0 };
 
-void __secure psci_save_target_pc(int cpu, u32 pc)
-{
-   psci_target_pc[cpu] = pc;
-   psci_context_id[cpu] = 0;
-   dsb();
-}
-
 void __secure psci_save(int cpu, u32 pc, u32 context_id)
 {
psci_target_pc[cpu] = pc;
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index b415241..95f18e8 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -93,10 +93,9 @@
 #ifndef __ASSEMBLY__
 #include 
 
-/* These 4 helper functions assume cpu < CONFIG_ARMV7_PSCI_NR_CPUS */
+/* These 3 helper functions assume cpu < CONFIG_ARMV7_PSCI_NR_CPUS */
 u32 psci_get_target_pc(int cpu);
 u32 psci_get_context_id(int cpu);
-void psci_save_target_pc(int cpu, u32 pc);
 void psci_save(int cpu, u32 pc, u32 context_id);
 
 void psci_cpu_entry(void);
-- 
2.7.4

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


[U-Boot] [PATCH v2 3/3] arm: stm32mp1: add PSCI support

2018-04-16 Thread Patrick Delaunay
Add PSCI v1.0 support for Linux and manage PSCI state
for each CPU (affinity 0 level) with all mandatory functions:
- PSCI_VERSION
- CPU_SUSPEND
- CPU_OFF
- CPU_ON
- AFFINITY_INFO
- SYSTEM_OFF
- SYSTEM_RESET
- PSCI_FEATURES
and 1 optional to avoid Linux warning
- MIGRATE_INFO_TYPE

Signed-off-by: Patrick Delaunay 
Reviewed-by: CITOOLS 
---
it is the v2 for http://patchwork.ozlabs.org/patch/888210

Linux boot and cpu1 hoot-plug is OK

[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.0 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: Trusted OS migration not required
.
[0.153066] smp: Bringing up secondary CPUs ...
[0.203301] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[0.203467] smp: Brought up 1 node, 2 CPUs
[0.213500] SMP: Total of 2 processors activated (96.00 BogoMIPS).

root@stm32mp1:~# echo 0 > /sys/devices/system/cpu/cpu1/online
[   76.498342] Retrying again to check for CPU kill
[   76.501500] CPU1 killed.
root@stm32mp1:~# cat /sys/devices/system/cpu/online
0
root@stm32mp1:~# echo 1 > /sys/devices/system/cpu/cpu1/online
root@stm32mp1:~# cat /sys/devices/system/cpu/online
0-1

Changes in v2:
- major update after Mark Rutland review
- add missing mandatory functions (AFFINITY_INFO, SYSTEM_OFF)
- add optional MIGRATE_INFO_TYPE for avoid Linux warning
- manage PSCI states transition
- save and use context_id for CPU_ON
- manage errors for all function

 arch/arm/mach-stm32mp/Kconfig  |   3 +
 arch/arm/mach-stm32mp/Makefile |   1 +
 arch/arm/mach-stm32mp/include/mach/stm32.h |   5 +
 arch/arm/mach-stm32mp/psci.c   | 181 +
 include/configs/stm32mp1.h |   5 +
 5 files changed, 195 insertions(+)
 create mode 100644 arch/arm/mach-stm32mp/psci.c

diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index 8c755f8..503bce1 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -23,7 +23,10 @@ config SYS_SOC
 
 config TARGET_STM32MP1
bool "Support stm32mp1xx"
+   select ARCH_SUPPORT_PSCI
select CPU_V7
+   select CPU_V7_HAS_NONSEC
+   select CPU_V7_HAS_VIRT
select PINCTRL_STM32
select STM32_RESET
help
diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
index 4620869..9aac2da 100644
--- a/arch/arm/mach-stm32mp/Makefile
+++ b/arch/arm/mach-stm32mp/Makefile
@@ -8,3 +8,4 @@ obj-y += cpu.o
 obj-y += dram_init.o
 
 obj-$(CONFIG_SPL_BUILD) += spl.o
+obj-$(CONFIG_ARMV7_PSCI) += psci.o
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index ffbe0b1..dd6f030 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -24,4 +24,9 @@
 #define STM32_DDR_BASE 0xC000
 #define STM32_DDR_SIZE SZ_1G
 
+/* TAMP registers */
+#define TAMP_BACKUP_REGISTER(x)(STM32_TAMP_BASE + 0x100 + 4 * 
x)
+#define TAMP_BACKUP_MAGIC_NUMBER   TAMP_BACKUP_REGISTER(4)
+#define TAMP_BACKUP_BRANCH_ADDRESS TAMP_BACKUP_REGISTER(5)
+
 #endif /* _MACH_STM32_H_ */
diff --git a/arch/arm/mach-stm32mp/psci.c b/arch/arm/mach-stm32mp/psci.c
new file mode 100644
index 000..b31c13e
--- /dev/null
+++ b/arch/arm/mach-stm32mp/psci.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BOOT_API_A7_CORE0_MAGIC_NUMBER 0xCA7FACE0
+#define BOOT_API_A7_CORE1_MAGIC_NUMBER 0xCA7FACE1
+
+#define MPIDR_AFF0 GENMASK(7, 0)
+
+#define RCC_MP_GRSTCSETR   (STM32_RCC_BASE + 0x0404)
+#define RCC_MP_GRSTCSETR_MPUP1RST  BIT(5)
+#define RCC_MP_GRSTCSETR_MPUP0RST  BIT(4)
+#define RCC_MP_GRSTCSETR_MPSYSRST  BIT(0)
+
+#define STM32MP1_PSCI_NR_CPUS  2
+#if STM32MP1_PSCI_NR_CPUS > CONFIG_ARMV7_PSCI_NR_CPUS
+#error "invalid value for CONFIG_ARMV7_PSCI_NR_CPUS"
+#endif
+
+u8 psci_state[STM32MP1_PSCI_NR_CPUS] __secure_data = {
+PSCI_AFFINITY_LEVEL_ON,
+PSCI_AFFINITY_LEVEL_OFF};
+
+void __secure psci_set_state(int cpu, u8 state)
+{
+   psci_state[cpu] = state;
+   dsb();
+   isb();
+}
+
+static u32 __secure stm32mp_get_gicd_base_address(void)
+{
+   u32 periphbase;
+
+   /* get the GIC base address from the CBAR register */
+   asm("mrc p15, 4, %0, c15, c0, 0\n" : "=r" (periphbase));
+
+   return (periphbase & CBAR_MASK) + GIC_DIST_OFFSET;
+}
+
+static void __secure stm32mp_smp_kick_all_cpus(void)
+{
+   u32 gic_dist_addr;
+
+   gic_dist_addr = stm32mp_get_gicd_base_address();
+
+   /* kick all CPUs (except this one) by writing to GICD_SGIR */
+   

[U-Boot] [PATCH v2 1/3] arm: psci: save context id for cpu_on PSCI command

2018-04-16 Thread Patrick Delaunay
Save and use the 3rd parameter of PSCI CPU_ON request: context_id.

The context_id parameter is only meaningful to the caller.
U-Boot PSCI preserves a copy of the value passed in this parameter.
Following wakeup from a  powerdown state, U-BOOT PSCI places
this value in R0 when it first enters the OS.

NB: this context id is not (yet?) used by Linux but it is mandatory
to be PSCI compliant.

update armv7 psci functions:
- psci_save_target_pc(): keep for backward compatibility with
  current platform (only save PC and force context id to 0)
  => should be removed when all platform migrate to the new API

- psci_save(): new API to use by ARMv7 platform with PSCI,
  save pc (= entry_point_address) and context_id

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 arch/arm/cpu/armv7/psci-common.c | 14 ++
 arch/arm/cpu/armv7/psci.S|  4 
 arch/arm/include/asm/psci.h  |  4 +++-
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/psci-common.c b/arch/arm/cpu/armv7/psci-common.c
index 8cb4107..73f986b 100644
--- a/arch/arm/cpu/armv7/psci-common.c
+++ b/arch/arm/cpu/armv7/psci-common.c
@@ -25,10 +25,19 @@
 #include 
 
 static u32 psci_target_pc[CONFIG_ARMV7_PSCI_NR_CPUS] __secure_data = { 0 };
+static u32 psci_context_id[CONFIG_ARMV7_PSCI_NR_CPUS] __secure_data = { 0 };
 
 void __secure psci_save_target_pc(int cpu, u32 pc)
 {
psci_target_pc[cpu] = pc;
+   psci_context_id[cpu] = 0;
+   dsb();
+}
+
+void __secure psci_save(int cpu, u32 pc, u32 context_id)
+{
+   psci_target_pc[cpu] = pc;
+   psci_context_id[cpu] = context_id;
dsb();
 }
 
@@ -37,3 +46,8 @@ u32 __secure psci_get_target_pc(int cpu)
return psci_target_pc[cpu];
 }
 
+u32 __secure psci_get_context_id(int cpu)
+{
+   return psci_context_id[cpu];
+}
+
diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
index 95b962d..35fd955 100644
--- a/arch/arm/cpu/armv7/psci.S
+++ b/arch/arm/cpu/armv7/psci.S
@@ -327,6 +327,10 @@ ENTRY(psci_cpu_entry)
bl  _nonsec_init
 
bl  psci_get_cpu_id @ CPU ID => r0
+   mov r2, r0  @ CPU ID => r2
+   bl  psci_get_context_id @ context id => r0
+   mov r1, r0  @ context id => r1
+   mov r0, r2  @ CPU ID => r0
bl  psci_get_target_pc  @ target PC => r0
b   _do_nonsec_entry
 ENDPROC(psci_cpu_entry)
diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
index ac8b00d..b415241 100644
--- a/arch/arm/include/asm/psci.h
+++ b/arch/arm/include/asm/psci.h
@@ -93,9 +93,11 @@
 #ifndef __ASSEMBLY__
 #include 
 
-/* These 2 helper functions assume cpu < CONFIG_ARMV7_PSCI_NR_CPUS */
+/* These 4 helper functions assume cpu < CONFIG_ARMV7_PSCI_NR_CPUS */
 u32 psci_get_target_pc(int cpu);
+u32 psci_get_context_id(int cpu);
 void psci_save_target_pc(int cpu, u32 pc);
+void psci_save(int cpu, u32 pc, u32 context_id);
 
 void psci_cpu_entry(void);
 u32 psci_get_cpu_id(void);
-- 
2.7.4

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


[U-Boot] [PATCH v2 2/3] arm: psci: add a weak function psci_arch_cpu_entry

2018-04-16 Thread Patrick Delaunay
The added function psci_arch_cpu_entry() is called
during psci_cpu_entry() and can be used by arch to handle
PSCI state transition from ON_PENDING to ON.

The default weak function is empty: not behavior change.

Signed-off-by: Patrick Delaunay 
---

Changes in v2: None

 arch/arm/cpu/armv7/psci.S | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
index 35fd955..08b5088 100644
--- a/arch/arm/cpu/armv7/psci.S
+++ b/arch/arm/cpu/armv7/psci.S
@@ -321,11 +321,18 @@ ENTRY(psci_arch_init)
 ENDPROC(psci_arch_init)
 .weak psci_arch_init
 
+ENTRY(psci_arch_cpu_entry)
+   mov pc, lr
+ENDPROC(psci_arch_cpu_entry)
+.weak psci_arch_cpu_entry
+
 ENTRY(psci_cpu_entry)
bl  psci_enable_smp
 
bl  _nonsec_init
 
+   bl  psci_arch_cpu_entry
+
bl  psci_get_cpu_id @ CPU ID => r0
mov r2, r0  @ CPU ID => r2
bl  psci_get_context_id @ context id => r0
-- 
2.7.4

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


Re: [U-Boot] [PATCH] mmc: mv_sdhci: zero out sdhci_host structure

2018-04-16 Thread Stefan Roese

On 12.04.2018 12:24, Stefan Roese wrote:

Hi Matt,

On 27.03.2018 19:53, Matt Pelland wrote:

The mv_sdhci driver was not zeroing the sdhci_host structure it
allocates causing random access violations in parts of the mmc core
where the "ops" member pointers are checked and called if not NULL.

Signed-off-by: Matt Pelland 
---
  drivers/mmc/mv_sdhci.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
index 69aa87babe..afc03f75a0 100644
--- a/drivers/mmc/mv_sdhci.c
+++ b/drivers/mmc/mv_sdhci.c
@@ -74,6 +74,8 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, 
u32 min_clk, u32 quirks)

  return -ENOMEM;
  }
+    memset(host, 0, sizeof(struct sdhci_host));
+
  host->name = MVSDH_NAME;
  host->ioaddr = (void *)regbase;
  host->quirks = quirks;



Thanks for finding this. But please use calloc() instead of malloc() and
the memset can be dropped.


Any chance for a respin of v2 with calloc() soon (for the upcoming
release)?

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


Re: [U-Boot] [PATCH V4 1/2] imx6: Convert sabrelite and nitrogen6x boards to distro boot support

2018-04-16 Thread Gary Bisson
Hi Guillaume,

On Thu, Apr 12, 2018 at 03:28:21PM +0200, Guillaume GARDET wrote:
> Boot tested on sabrelite board.
> 
> Signed-off-by: Guillaume GARDET 
> Cc: Troy Kisky 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> Cc: Gary Bisson 
> 
> ---
>  include/configs/nitrogen6x.h | 180 
> +--
>  1 file changed, 54 insertions(+), 126 deletions(-)
> 
> diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
> index 7d2cf0bd8c..f6dce6c069 100644
> --- a/include/configs/nitrogen6x.h
> +++ b/include/configs/nitrogen6x.h
> @@ -101,140 +101,68 @@
>  #define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC 
> CONFIG_DRIVE_USB
>  #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC

Many of the macros above this line are obsolete with that patch, please
remove.

@@ -80,27 +80,6 @@

 #define CONFIG_PREBOOT ""

-#ifdef CONFIG_CMD_SATA
-#define CONFIG_DRIVE_SATA "sata "
-#else
-#define CONFIG_DRIVE_SATA
-#endif
-
-#ifdef CONFIG_CMD_MMC
-#define CONFIG_DRIVE_MMC "mmc "
-#else
-#define CONFIG_DRIVE_MMC
-#endif
-
-#ifdef CONFIG_USB_STORAGE
-#define CONFIG_DRIVE_USB "usb "
-#else
-#define CONFIG_DRIVE_USB
-#endif
-
-#define CONFIG_DRIVE_TYPES CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC CONFIG_DRIVE_USB
-#define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
-
 #ifdef CONFIG_CMD_MMC

> +#ifdef CONFIG_CMD_MMC
> +#define DISTRO_BOOT_DEV_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1)
> +#else
> +#define DISTRO_BOOT_DEV_MMC(func)
> +#endif
> +
> +#ifdef CONFIG_CMD_SATA
> +#define DISTRO_BOOT_DEV_SATA(func) func(SATA, sata, 0)
> +#else
> +#define DISTRO_BOOT_DEV_SATA(func)
> +#endif
> +
> +#ifdef CONFIG_USB_STORAGE
> +#define DISTRO_BOOT_DEV_USB(func) func(USB, usb, 0)
> +#else
> +#define DISTRO_BOOT_DEV_USB(func)
> +#endif
> +
> +#ifdef CONFIG_CMD_PXE
> +#define DISTRO_BOOT_DEV_PXE(func) func(PXE, pxe, na)
> +#else
> +#define DISTRO_BOOT_DEV_PXE(func)
> +#endif
> +
> +#ifdef CONFIG_CMD_DHCP
> +#define DISTRO_BOOT_DEV_DHCP(func) func(DHCP, dhcp, na)
> +#else
> +#define DISTRO_BOOT_DEV_DHCP(func)
> +#endif
> +
> +
>  #if defined(CONFIG_SABRELITE)
> +#define FDTFILE "fdtfile=imx6q-sabrelite.dtb\0"
> +#else
> +/* FIXME: nitrogen6x covers multiple configs. Define fdtfile for each 
> supported config. */
> +#define FDTFILE
> +#endif
> +
> +#define BOOT_TARGET_DEVICES(func) \
> + DISTRO_BOOT_DEV_MMC(func) \
> + DISTRO_BOOT_DEV_SATA(func) \
> + DISTRO_BOOT_DEV_USB(func) \
> + DISTRO_BOOT_DEV_PXE(func) \
> + DISTRO_BOOT_DEV_DHCP(func)
> +
> +#include 
> +
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> - "script=boot.scr\0" \
> - "uimage=uImage\0" \
>   "console=ttymxc1\0" \
>   "fdt_high=0x\0" \
>   "initrd_high=0x\0" \
> - "fdt_file=imx6q-sabrelite.dtb\0" \
> - "fdt_addr=0x1800\0" \
> - "boot_fdt=try\0" \
> + "fdt_addr_r=0x1800\0" \
> + FDTFILE \
> + "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
> + "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
> + "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
> + "ramdisk_addr_r=0x1300\0" \
> + "ramdiskaddr=0x1300\0" \
>   "ip_dyn=yes\0" \
>   "usb_pgood_delay=2000\0" \
> - "mmcdevs=0 1\0" \
> - "mmcpart=1\0" \
> - "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
> - "mmcargs=setenv bootargs console=${console},${baudrate} " \
> - "root=${mmcroot}\0" \
> - "loadbootscript=" \
> - "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
> - "bootscript=echo Running bootscript from mmc ...; " \
> - "source\0" \
> - "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
> - "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
> - "mmcboot=echo Booting from mmc ...; " \
> - "run mmcargs; " \
> - "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
> - "if run loadfdt; then " \
> - "bootm ${loadaddr} - ${fdt_addr}; " \
> - "else " \
> - "if test ${boot_fdt} = try; then " \
> - "bootm; " \
> - "else " \
> - "echo WARN: Cannot load the DT; " \
> - "fi; " \
> - "fi; " \
> - "else " \
> - "bootm; " \
> - "fi;\0" \
> - "netargs=setenv bootargs console=${console},${baudrate} " \
> - "root=/dev/nfs " \
> - "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
> - "netboot=echo Booting from net ...; " \
> - "run netargs; " \
> - "if test ${ip_dyn} = yes; then " \
> - "setenv get_cmd dhcp; " \
> -   

[U-Boot] [PATCH v2 4/8] efi_loader: fix AppendDevicePath

2018-04-16 Thread Heinrich Schuchardt
The logic of the AppendDevicePath service of the
EFI_DEVICE_PATH_UTILITIES_PROTOCOL is incorrectly implemented:

* if both paths are NULL an end node has to be returned
* if both paths are not NULL the end node of the second device path has to
  be kept

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 lib/efi_loader/efi_device_path.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 801c1558e5..531a754427 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -263,7 +263,10 @@ struct efi_device_path *efi_dp_append(const struct 
efi_device_path *dp1,
 {
struct efi_device_path *ret;
 
-   if (!dp1) {
+   if (!dp1 && !dp2) {
+   /* return an end node */
+   ret = efi_dp_dup();
+   } else if (!dp1) {
ret = efi_dp_dup(dp2);
} else if (!dp2) {
ret = efi_dp_dup(dp1);
@@ -275,8 +278,8 @@ struct efi_device_path *efi_dp_append(const struct 
efi_device_path *dp1,
if (!p)
return NULL;
memcpy(p, dp1, sz1);
-   memcpy(p + sz1, dp2, sz2);
-   memcpy(p + sz1 + sz2, , sizeof(END));
+   /* the end node of the second device path has to be retained */
+   memcpy(p + sz1, dp2, sz2 + sizeof(END));
ret = p;
}
 
-- 
2.17.0

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


Re: [U-Boot] Re-introducing support for OLD hardware

2018-04-16 Thread Jason Mitchell
Hi there
Thanks for the advice.

The DTP append work-around sounds like a horrible hack that might come to
bite me later, so I am going to rather go with re-introducing SMDK6410 back
into the U-boot and maintain it.
The benefits are then of course that we will be retrofitting something
modern in the field, as opposed to a loader that is 7 years old.

I will clone the current mainline and start investigating how to best
approach this.

Thanks and Regards,
Jason Mitchell

On 12 April 2018 at 16:01, Tom Rini  wrote:

> On Thu, Apr 12, 2018 at 09:04:20AM +0200, Jason Mitchell wrote:
> > Good day all
> >
> > I am currently faced with a task of having to run new software on ageing
> > hardware. We have currently about 1000 units in the field of a machine
> that
> > runs Windows CE using the Samsung S3C6410.
> >
> > Because these are considerable assets its not a simple case of replacing
> > them with new, more modern hardware.
> >
> > The goal is to be able to get these existing boards to run Ubuntu so that
> > we can run GoLang applications, so we need the GUI with just a relatively
> > recent browser.
> >
> > The board in question is a near perfect clone of the SMDK6410, which was
> > supported fully in U-boot in the past, indeed I can select SMDK6410 and
> > compile a working U-boot using 1.3.4 sources
> >
> > After much effort I managed to get a tailored (tailored as in having
> > changed the memory configuration to match the hardware) U-boot V1.3.4
> > compiled and running for this chip, the problem now, obviously we have a
> > fairly recent Linux kernel compiled and it won't boot because the Device
> > Tree Blob doesn't exist on such an old version of U-boot.
> >
> > So my questions are:
> >
> > - Has anyone perhaps created a branch or fork of the current or nearly
> > current version of U-boot and patched in this support. I see a lot of
> > Chinese websites where they seem to have done this but the language
> barrier
> > is a big problem. Also a lot of dead links are another problem.
> >
> > - If there isn't something out there, would it be possible to run through
> > the steps with me to add support for this CPU again. I don't mind doing
> the
> > work, the main issue is I have no clue how U-boot actually works
> internally.
> >
> > I have FULL JTAG access to this board, with a perfectly functional
> OpenOCD
> > setup. This is how we are able to program versions of U-boot into the
> FLASH.
>
> There's two options:
> 1) You can re-introduce support for the SMDK6410 into mainline U-Boot
> and be an active maintainer of it.  It was removed due to lack of active
> maintainers.
>
> 2) You can, for Linux, use the "appended DTB" work-around to boot a
> modern kernel from an old bootloader.
>
> --
> Tom
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 3/8] efi_loader: implement CreateDeviceNode

2018-04-16 Thread Heinrich Schuchardt
Implement the CreateDeviceNode service of the device path utility protocol.

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 include/efi_loader.h   |  5 -
 lib/efi_loader/efi_device_path.c   | 15 +++
 lib/efi_loader/efi_device_path_utilities.c | 17 -
 3 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 17f9d3d1ef..0358bcb1d7 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -330,7 +330,10 @@ struct efi_device_path *efi_dp_append(const struct 
efi_device_path *dp1,
  const struct efi_device_path *dp2);
 struct efi_device_path *efi_dp_append_node(const struct efi_device_path *dp,
   const struct efi_device_path *node);
-
+/* Create a device path node of given type, sub-type, length */
+struct efi_device_path *efi_dp_create_device_node(const u8 type,
+ const u8 sub_type,
+ const u16 length);
 
 struct efi_device_path *efi_dp_from_dev(struct udevice *dev);
 struct efi_device_path *efi_dp_from_part(struct blk_desc *desc, int part);
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index ab28b2fd25..801c1558e5 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -315,6 +315,21 @@ struct efi_device_path *efi_dp_append_node(const struct 
efi_device_path *dp,
return ret;
 }
 
+struct efi_device_path *efi_dp_create_device_node(const u8 type,
+ const u8 sub_type,
+ const u16 length)
+{
+   struct efi_device_path *ret;
+
+   ret = dp_alloc(length);
+   if (!ret)
+   return ret;
+   ret->type = type;
+   ret->sub_type = sub_type;
+   ret->length = length;
+   return ret;
+}
+
 #ifdef CONFIG_DM
 /* size of device-path not including END node for device and all parents
  * up to the root device.
diff --git a/lib/efi_loader/efi_device_path_utilities.c 
b/lib/efi_loader/efi_device_path_utilities.c
index bc9731..e73188b242 100644
--- a/lib/efi_loader/efi_device_path_utilities.c
+++ b/lib/efi_loader/efi_device_path_utilities.c
@@ -70,11 +70,26 @@ static bool EFIAPI is_device_path_multi_instance(
return EFI_EXIT(false);
 }
 
+/*
+ * Create device node.
+ *
+ * This function implements the CreateDeviceNode service of the device path
+ * utilities protocol.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification
+ * for details.
+ *
+ * @node_type  node type
+ * @node_sub_type  node sub type
+ * @node_lengthnode length
+ * @return device path node
+ */
 static struct efi_device_path * EFIAPI create_device_node(
uint8_t node_type, uint8_t node_sub_type, uint16_t node_length)
 {
EFI_ENTRY("%u, %u, %u", node_type, node_sub_type, node_length);
-   return EFI_EXIT(NULL);
+   return EFI_EXIT(efi_dp_create_device_node(node_type, node_sub_type,
+   node_length));
 }
 
 const struct efi_device_path_utilities_protocol efi_device_path_utilities = {
-- 
2.17.0

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


[U-Boot] [PATCH v2 6/8] efi_loader: correcty determine total device path length

2018-04-16 Thread Heinrich Schuchardt
Device paths may consist of multiple instances. Up to now we have only
considered the size of the first instance. For the services of the
EFI_DEVICE_PATH_UTILITIES_PROTOCOL in most cases the total length of the
device path is relevant.

So let's rename efi_dp_size() to efi_dp_instance_size() and create a new
function efi_dp_size() that calculates the total device path length.

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 include/efi_loader.h |  5 -
 lib/efi_loader/efi_boottime.c|  4 ++--
 lib/efi_loader/efi_device_path.c | 34 +++-
 3 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 0358bcb1d7..1298b5e160 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -324,7 +324,10 @@ int efi_dp_match(const struct efi_device_path *a,
 const struct efi_device_path *b);
 struct efi_object *efi_dp_find_obj(struct efi_device_path *dp,
   struct efi_device_path **rem);
-unsigned efi_dp_size(const struct efi_device_path *dp);
+/* get size of the first device path instance excluding end node */
+efi_uintn_t efi_dp_instance_size(const struct efi_device_path *dp);
+/* size of multi-instance device path excluding end node */
+efi_uintn_t efi_dp_size(const struct efi_device_path *dp);
 struct efi_device_path *efi_dp_dup(const struct efi_device_path *dp);
 struct efi_device_path *efi_dp_append(const struct efi_device_path *dp1,
  const struct efi_device_path *dp2);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 7a9449f59c..1cfdabf6eb 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2219,7 +2219,7 @@ static efi_status_t EFIAPI efi_locate_device_path(
}
 
/* Find end of device path */
-   len = efi_dp_size(*device_path);
+   len = efi_dp_instance_size(*device_path);
 
/* Get all handles implementing the protocol */
ret = EFI_CALL(efi_locate_handle_buffer(BY_PROTOCOL, protocol, NULL,
@@ -2234,7 +2234,7 @@ static efi_status_t EFIAPI efi_locate_device_path(
if (ret != EFI_SUCCESS)
continue;
dp = (struct efi_device_path *)handler->protocol_interface;
-   len_dp = efi_dp_size(dp);
+   len_dp = efi_dp_instance_size(dp);
/*
 * This handle can only be a better fit
 * if its device path length is longer than the best fit and
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 46d3fea732..09c3ec4273 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -149,7 +149,7 @@ static struct efi_object *find_obj(struct efi_device_path 
*dp, bool short_path,
   struct efi_device_path **rem)
 {
struct efi_object *efiobj;
-   unsigned int dp_size = efi_dp_size(dp);
+   efi_uintn_t dp_size = efi_dp_instance_size(dp);
 
list_for_each_entry(efiobj, _obj_list, link) {
struct efi_handler *handler;
@@ -170,11 +170,12 @@ static struct efi_object *find_obj(struct efi_device_path 
*dp, bool short_path,
 * the caller.
 */
*rem = ((void *)dp) +
-   efi_dp_size(obj_dp);
+   efi_dp_instance_size(obj_dp);
return efiobj;
} else {
/* Only return on exact matches */
-   if (efi_dp_size(obj_dp) == dp_size)
+   if (efi_dp_instance_size(obj_dp) ==
+   dp_size)
return efiobj;
}
}
@@ -229,10 +230,10 @@ const struct efi_device_path *efi_dp_last_node(const 
struct efi_device_path *dp)
return ret;
 }
 
-/* return size not including End node: */
-unsigned efi_dp_size(const struct efi_device_path *dp)
+/* get size of the first device path instance excluding end node */
+efi_uintn_t efi_dp_instance_size(const struct efi_device_path *dp)
 {
-   unsigned sz = 0;
+   efi_uintn_t sz = 0;
 
if (!dp || dp->type == DEVICE_PATH_TYPE_END)
return 0;
@@ -244,10 +245,25 @@ unsigned efi_dp_size(const struct efi_device_path *dp)
return sz;
 }
 
+/* get size of multi-instance device path excluding end node */
+efi_uintn_t efi_dp_size(const struct efi_device_path *dp)
+{
+   const struct efi_device_path *p = dp;
+
+   if (!p)
+   return 0;
+   while (p->type != DEVICE_PATH_TYPE_END ||

[U-Boot] [PATCH v2 5/8] efi_loader: correctly determine length of empty device path

2018-04-16 Thread Heinrich Schuchardt
efi_dp_size() is meant to return the device path length without the end
node.

The length of a device path containing only an end node was incorrectly
reported as 4.

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 lib/efi_loader/efi_device_path.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 531a754427..46d3fea732 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -234,6 +234,8 @@ unsigned efi_dp_size(const struct efi_device_path *dp)
 {
unsigned sz = 0;
 
+   if (!dp || dp->type == DEVICE_PATH_TYPE_END)
+   return 0;
while (dp) {
sz += dp->length;
dp = efi_dp_next(dp);
-- 
2.17.0

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


[U-Boot] [PATCH v2 8/8] efi_selftest: test EFI_DEVICE_PATH_UTILITIES_PROTOCOL

2018-04-16 Thread Heinrich Schuchardt
Provide unit tests for the EFI_DEVICE_PATH_UTILITIES_PROTOCOL.

Signed-off-by: Heinrich Schuchardt 
---
v2
add more comments, rename a variable
---
 lib/efi_selftest/Makefile |   1 +
 .../efi_selftest_devicepath_util.c| 286 ++
 2 files changed, 287 insertions(+)
 create mode 100644 lib/efi_selftest/efi_selftest_devicepath_util.c

diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 2ca58cebe4..ddc2b87317 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -18,6 +18,7 @@ efi_selftest_bitblt.o \
 efi_selftest_controllers.o \
 efi_selftest_console.o \
 efi_selftest_devicepath.o \
+efi_selftest_devicepath_util.o \
 efi_selftest_events.o \
 efi_selftest_event_groups.o \
 efi_selftest_exitbootservices.o \
diff --git a/lib/efi_selftest/efi_selftest_devicepath_util.c 
b/lib/efi_selftest/efi_selftest_devicepath_util.c
new file mode 100644
index 00..2b5384f21b
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_devicepath_util.c
@@ -0,0 +1,286 @@
+/*
+ * efi_selftest_devicepath_util
+ *
+ * Copyright (c) 2018 Heinrich Schuchardt 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ *
+ * This unit test checks the device path utilities protocol.
+ */
+
+#include 
+
+static struct efi_boot_services *boottime;
+
+static efi_guid_t guid_device_path_utilities_protocol =
+   EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID;
+
+struct efi_device_path_utilities_protocol *dpu;
+
+/*
+ * Setup unit test.
+ *
+ * Locate the device path utilities protocol.
+ *
+ * @handle:handle of the loaded image
+ * @systable:  system table
+ */
+static int setup(const efi_handle_t img_handle,
+const struct efi_system_table *systable)
+{
+   int ret;
+
+   boottime = systable->boottime;
+
+   ret = boottime->locate_protocol(_device_path_utilities_protocol,
+   NULL, (void **));
+   if (ret != EFI_SUCCESS) {
+   dpu = NULL;
+   efi_st_error(
+   "Device path to text protocol is not available.\n");
+   return EFI_ST_FAILURE;
+   }
+
+   return EFI_ST_SUCCESS;
+}
+
+/*
+ * Create a device path consisting of a single media device node followed by an
+ * end node.
+ *
+ * @length:length of the media device node
+ * @dp:device path
+ * @return:status code
+ */
+static int create_single_node_device_path(unsigned int length,
+ struct efi_device_path **dp)
+{
+   struct efi_device_path *node;
+   efi_uintn_t len;
+   int ret;
+
+   node = dpu->create_device_node(DEVICE_PATH_TYPE_MEDIA_DEVICE,
+  DEVICE_PATH_SUB_TYPE_FILE_PATH, length);
+   if (!node) {
+   efi_st_error("CreateDeviceNode failed\n");
+   return EFI_ST_FAILURE;
+   }
+   *dp = dpu->append_device_node(NULL, node);
+   if (!*dp) {
+   efi_st_error("AppendDeviceNode failed\n");
+   return EFI_ST_FAILURE;
+   }
+   ret = boottime->free_pool(node);
+   if (ret != EFI_ST_SUCCESS) {
+   efi_st_error("FreePool failed\n");
+   return EFI_ST_FAILURE;
+   }
+   len = dpu->get_device_path_size(*dp);
+   if (len != length + 4) {
+   efi_st_error("Wrong device path length %u, expected %u\n",
+(unsigned int)len, length);
+   return EFI_ST_FAILURE;
+   }
+   return EFI_ST_SUCCESS;
+}
+
+/*
+ * Execute unit test.
+ *
+ * In the test device paths are created, copied, and concatenated. The device
+ * path length is used as a measure of success.
+ */
+static int execute(void)
+{
+   struct efi_device_path *dp1;
+   struct efi_device_path *dp2;
+   struct efi_device_path *dp3;
+
+   efi_uintn_t len;
+   int ret;
+
+   /* IsDevicePathMultiInstance(NULL) */
+   if (dpu->is_device_path_multi_instance(NULL)) {
+   efi_st_error("IsDevicePathMultiInstance(NULL) returned true\n");
+   return EFI_ST_FAILURE;
+   }
+   /* GetDevicePathSize(NULL) */
+   len = dpu->get_device_path_size(NULL);
+   if (len) {
+   efi_st_error("Wrong device path length %u, expected 0\n",
+(unsigned int)len);
+   return EFI_ST_FAILURE;
+   }
+   /* DuplicateDevicePath(NULL) */
+   dp1 = dpu->duplicate_device_path(NULL);
+   if (dp1) {
+   efi_st_error("DuplicateDevicePath(NULL) failed\n");
+   return EFI_ST_FAILURE;
+   }
+   /* AppendDevicePath(NULL, NULL) */
+   dp1 = dpu->append_device_path(NULL, NULL);
+   if (!dp1) {
+   efi_st_error("AppendDevicePath(NULL, NULL) failed\n");
+   return EFI_ST_FAILURE;
+   }
+   len = dpu->get_device_path_size(dp1);
+   if (len != 4) {
+ 

[U-Boot] [PATCH v2 7/8] efi_loader: complete EFI_DEVICE_PATH_UTILITIES_PROTOCOL

2018-04-16 Thread Heinrich Schuchardt
The missing services of the EFI_DEVICE_PATH_UTILITIES_PROTOCOL are
implemented.

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 include/efi_api.h  |   1 +
 include/efi_loader.h   |   9 ++
 lib/efi_loader/efi_device_path.c   |  64 
 lib/efi_loader/efi_device_path_utilities.c | 116 +++--
 4 files changed, 180 insertions(+), 10 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index ae93061160..64c27e494b 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -343,6 +343,7 @@ struct efi_loaded_image {
 0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b )
 
 #define DEVICE_PATH_TYPE_END   0x7f
+#  define DEVICE_PATH_SUB_TYPE_INSTANCE_END0x01
 #  define DEVICE_PATH_SUB_TYPE_END 0xff
 
 struct efi_device_path {
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 1298b5e160..8d21ba74b1 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -337,6 +337,15 @@ struct efi_device_path *efi_dp_append_node(const struct 
efi_device_path *dp,
 struct efi_device_path *efi_dp_create_device_node(const u8 type,
  const u8 sub_type,
  const u16 length);
+/* Append device path instance */
+struct efi_device_path *efi_dp_append_instance(
+   const struct efi_device_path *dp,
+   const struct efi_device_path *dpi);
+/* Get next device path instance */
+struct efi_device_path *efi_dp_get_next_instance(struct efi_device_path **dp,
+efi_uintn_t *size);
+/* Check if a device path contains muliple instances */
+bool efi_dp_is_multi_instance(const struct efi_device_path *dp);
 
 struct efi_device_path *efi_dp_from_dev(struct udevice *dev);
 struct efi_device_path *efi_dp_from_part(struct blk_desc *desc, int part);
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 09c3ec4273..2861982883 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -351,6 +351,70 @@ struct efi_device_path *efi_dp_create_device_node(const u8 
type,
return ret;
 }
 
+struct efi_device_path *efi_dp_append_instance(
+   const struct efi_device_path *dp,
+   const struct efi_device_path *dpi)
+{
+   size_t sz, szi;
+   struct efi_device_path *p, *ret;
+
+   if (!dpi)
+   return NULL;
+   if (!dp)
+   return efi_dp_dup(dpi);
+   sz = efi_dp_size(dp);
+   szi = efi_dp_instance_size(dpi);
+   p = dp_alloc(sz + szi + 2 * sizeof(END));
+   if (!p)
+   return NULL;
+   ret = p;
+   memcpy(p, dp, sz + sizeof(END));
+   p = (void *)p + sz;
+   p->sub_type = DEVICE_PATH_SUB_TYPE_INSTANCE_END;
+   p = (void *)p + sizeof(END);
+   memcpy(p, dpi, szi);
+   p = (void *)p + szi;
+   memcpy(p, , sizeof(END));
+   return ret;
+}
+
+struct efi_device_path *efi_dp_get_next_instance(struct efi_device_path **dp,
+efi_uintn_t *size)
+{
+   size_t sz;
+   struct efi_device_path *p;
+
+   if (size)
+   *size = 0;
+   if (!dp || !*dp)
+   return NULL;
+   p = *dp;
+   sz = efi_dp_instance_size(*dp);
+   p = dp_alloc(sz + sizeof(END));
+   if (!p)
+   return NULL;
+   memcpy(p, *dp, sz + sizeof(END));
+   *dp = (void *)*dp + sz;
+   if ((*dp)->sub_type == DEVICE_PATH_SUB_TYPE_INSTANCE_END)
+   *dp = (void *)*dp + sizeof(END);
+   else
+   *dp = NULL;
+   if (size)
+   *size = sz + sizeof(END);
+   return p;
+}
+
+bool efi_dp_is_multi_instance(const struct efi_device_path *dp)
+{
+   const struct efi_device_path *p = dp;
+
+   if (!p)
+   return false;
+   while (p->type != DEVICE_PATH_TYPE_END)
+   p = (void *)p + p->length;
+   return p->sub_type == DEVICE_PATH_SUB_TYPE_INSTANCE_END;
+}
+
 #ifdef CONFIG_DM
 /* size of device-path not including END node for device and all parents
  * up to the root device.
diff --git a/lib/efi_loader/efi_device_path_utilities.c 
b/lib/efi_loader/efi_device_path_utilities.c
index e73188b242..0ada2111db 100644
--- a/lib/efi_loader/efi_device_path_utilities.c
+++ b/lib/efi_loader/efi_device_path_utilities.c
@@ -12,62 +12,158 @@
 const efi_guid_t efi_guid_device_path_utilities_protocol =
EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID;
 
+/*
+ * Get size of a device path.
+ *
+ * This function implements the GetDevicePathSize service of the device path
+ * utilities protocol. The device path length includes the end of path tag
+ * which may be an instance end.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification
+ * for details.
+ *
+ * @device_path   

[U-Boot] [PATCH v2 1/8] efi_selftest: do not execute test if setup failed

2018-04-16 Thread Heinrich Schuchardt
Executing a test after failed setup may lead to unexpected behavior like
an illegal memory access. So after a setup failure we should skip to
teardown.

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 include/efi_selftest.h  |  2 ++
 lib/efi_selftest/efi_selftest.c | 14 +++---
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/include/efi_selftest.h b/include/efi_selftest.h
index 08dd8e43ad..c23bc24bed 100644
--- a/include/efi_selftest.h
+++ b/include/efi_selftest.h
@@ -114,6 +114,7 @@ u16 efi_st_get_key(void);
  * @setup: set up the unit test
  * @teardown:  tear down the unit test
  * @execute:   execute the unit test
+ * @setup_ok:  setup was successful (set at runtime)
  * @on_request:test is only executed on request
  */
 struct efi_unit_test {
@@ -123,6 +124,7 @@ struct efi_unit_test {
 const struct efi_system_table *systable);
int (*execute)(void);
int (*teardown)(void);
+   int setup_ok;
bool on_request;
 };
 
diff --git a/lib/efi_selftest/efi_selftest.c b/lib/efi_selftest/efi_selftest.c
index fc5ef254a1..fd4fee726f 100644
--- a/lib/efi_selftest/efi_selftest.c
+++ b/lib/efi_selftest/efi_selftest.c
@@ -77,20 +77,20 @@ void efi_st_exit_boot_services(void)
  */
 static int setup(struct efi_unit_test *test, unsigned int *failures)
 {
-   int ret;
-
-   if (!test->setup)
+   if (!test->setup) {
+   test->setup_ok = EFI_ST_SUCCESS;
return EFI_ST_SUCCESS;
+   }
efi_st_printc(EFI_LIGHTBLUE, "\nSetting up '%s'\n", test->name);
-   ret = test->setup(handle, systable);
-   if (ret != EFI_ST_SUCCESS) {
+   test->setup_ok = test->setup(handle, systable);
+   if (test->setup_ok != EFI_ST_SUCCESS) {
efi_st_error("Setting up '%s' failed\n", test->name);
++*failures;
} else {
efi_st_printc(EFI_LIGHTGREEN,
  "Setting up '%s' succeeded\n", test->name);
}
-   return ret;
+   return test->setup_ok;
 }
 
 /*
@@ -200,7 +200,7 @@ void efi_st_do_tests(const u16 *testname, unsigned int 
phase,
continue;
if (steps & EFI_ST_SETUP)
setup(test, failures);
-   if (steps & EFI_ST_EXECUTE)
+   if (steps & EFI_ST_EXECUTE && test->setup_ok == EFI_ST_SUCCESS)
execute(test, failures);
if (steps & EFI_ST_TEARDOWN)
teardown(test, failures);
-- 
2.17.0

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


[U-Boot] [PATCH v2 2/8] efi_selftest: fix typo in efi_selftest_devicepath.c

2018-04-16 Thread Heinrich Schuchardt
%s/provice/provide/

Signed-off-by: Heinrich Schuchardt 
---
v2
no change
---
 lib/efi_selftest/efi_selftest_devicepath.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_selftest/efi_selftest_devicepath.c 
b/lib/efi_selftest/efi_selftest_devicepath.c
index 92940c7ab6..da68102eb2 100644
--- a/lib/efi_selftest/efi_selftest_devicepath.c
+++ b/lib/efi_selftest/efi_selftest_devicepath.c
@@ -52,7 +52,7 @@ struct efi_device_path_to_text_protocol *device_path_to_text;
  * Setup unit test.
  *
  * Create three handles. Install a new protocol on two of them and
- * provice device paths.
+ * provide device paths.
  *
  * handle1
  *   guid interface
-- 
2.17.0

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


  1   2   >