date:20180214

On Wed, 14 Feb 2018 03:25:58 +0200
Tuomas Tynkkynen  wrote:

> Hi,
> 
> On Tue, 13 Feb 2018 23:01:13 +0100
> Lukasz Majewski  wrote:
> 
> > This commit fixes several issues:
> > 
> > - After moving env related code to ./env directory the env_common.o
> > file is no longer present in the system (has been replaced with
> > built-in.o).
> > 
> > - Use ${OBJCOPY} if available, fallback to system default's objcopy
> > if not present.
> > 
> > - Extend the script to accept different build directory than
> > current one. It is extremely handy with OE usage, where source code
> > is separated from build.
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> > 
> >  scripts/get_default_envs.sh | 19 ++-
> >  1 file changed, 14 insertions(+), 5 deletions(-)
> > 
> > diff --git a/scripts/get_default_envs.sh
> > b/scripts/get_default_envs.sh index 7955db60e5..bbb6d0a6ef 100755
> > --- a/scripts/get_default_envs.sh
> > +++ b/scripts/get_default_envs.sh
> > @@ -6,16 +6,24 @@
> >  #
> >  
> >  # This file extracts default envs from built u-boot
> > -# usage: get_default_envs.sh > u-boot-env-default.txt
> > +# usage: get_default_envs.sh [build dir] > u-boot-env-default.txt
> >  set -ue
> >  
> > -ENV_OBJ_FILE="env_common.o"
> > +: "${OBJCOPY:=objcopy}"  
> 
> Maybe "${CROSS_COMPILE}objcopy" would be a better default as that's
> what the build system uses.

Unfortunately not with OE builds. In OE, the OBJCOPY is set to arm
specific objcopy.

With fallback (objcopy) from your local machine - it depends if it
supports multi arch or not.

A side note:

I do use this script with /tools/mkenvimage to generate default main
and redundant envs.


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


pgp2jh2E4jqzx.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 8/8] Migrate generic bootcount to Kconfig

Hi Alex,

> On Tue, Feb 13, 2018 at 2:41 PM, Lukasz Majewski 
> wrote:
> > Hi Alex,
> >  
> >> On Mon, Feb 12, 2018 at 8:48 AM, Lukasz Majewski 
> >> wrote:  
> >> > Hi Alex,
> >> >  
> >> >> On Sun, Feb 11, 2018 at 9:44 PM, Lukasz Majewski 
> >> >> wrote:  
> >> >> > On Sun, 11 Feb 2018 21:04:46 +
> >> >> > Alex Kiernan  wrote:
> >> >> >  
> >> >> >>
> >> >> >> That said, squashing in that change doesn't obviously break
> >> >> >> anything for me, and is probably a step in the right
> >> >> >> direction.
> >> >> >>
> >> >> >> I'll see what Travis thinks.
> >> >> >>  
> >> >> >
> >> >> > We will probably receive build breaks...  
> >> >>
> >> >> Yup... https://travis-ci.org/akiernan/u-boot/jobs/340344489
> >> >>
> >> >> Just tried again on one of those failures (x600) with the the
> >> >> default removed and just set the on board that uses CONFIG_EXT,
> >> >> but that then fails at config time.  
> >> >
> >> > Ok. I see
> >> >  
> >> >>
> >> >> TBH I'd actually like to take it out of Kconfig (which I
> >> >> realise is the wrong direction) as it just feels fundamentally
> >> >> wrong the way it is.  
> >> >
> >> > To finish moving SYS_BOOTCOUNT_ADDR to Kconfig we would need to
> >> > add its definition to each eligible ./configs/_defconfig
> >> > file.
> >> >
> >> > Then we would have the previous behaviour preserved.
> >> >  
> >> >> I don't know what the U-Boot approach configuration like this
> >> >> is... struggling to find prior art.  
> >> >
> >> > Let's ask Tom for his opinion as he did much such work before.
> >> >  
> >>
> >> Thoughts:
> >>
> >> - Do nothing, leave CONFIG_SYS_BOOTCOUNT_ADDR as a purely
> >> CONFIG_EXT piece of Kconfig
> >> - Rename CONFIG_SYS_BOOTCOUNT_ADDR to something like
> >> CONFIG_SYS_BOOTCOUNT_ADDR_EXT for just CONFIG_EXT
> >> - Remove CONFIG_SYS_BOOTCOUNT_ADDR from Kconfig altogether (and
> >> rename to say SYS_BOOTCOUNT_ADDR)
> >> - Pick through every config building defaults - okay for some
> >> boards, but lots have it defined based on other memory offsets
> >>
> >> I think the only real options are the last two.  
> >
> > I would go for third option - Remove the SYS_BOOTCOUNT_ADDR from
> > Kconfig (also for EXT).
> >  
> 
> I agree.
> 
> >>
> >> Whatever we do, I think CONFIG_SYS_BOOTCOUNT_ADDR wants splitting
> >> into at least two:
> >>
> >> - I2C - an offset from an I2C base for the bootcounter  
> >   - RAM/SoC memory - location of special register to store
> > bootcounter  
> >> - Others - an actual address used for storing the bootcounter  
> >
> >
> >  
> >>
> >> I'm struggling to see why EXT is the way it is - AFAICS the
> >> location it uses to access/return the bootcounter is basically
> >> local to the two functions in bootcount_ext and could just be a
> >> local variable. 
> >
> > Maybe we can replace it with local, static variable then?
> >
> >
> > As said above - I would remove the (wrongly?) used BOOTCOUNT_ADDR in
> > Kconfig.
> >  
> 
> Just removing SYS_BOOTCOUNT_ADDR from Kconfig and putting the default
> back into bootcount_ext seems like the simplest correct change. I'll
> add that onto the series and throw it at Travis.

Great. I'm looking forward for next verison of the code - as I do have
some code to be put on top of it.

Thanks for help.

> 
> > Then, for next merge window we can play around with moving
> > CONFIG_SYS_BOOTCOUNT_ADDR per boards if needed.
> >
> > I just do have a feeling that -rc2 is too late for it
> >
> > Also, wrong SYS_BOOTCOUNT_ADDR will not be caught in build testing
> > and may cause boards to silency break.
> >  
> 
> Yeah...
> 



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


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

[U-Boot] [PATCH v2] script: Make the get_default_envs.sh script working with newest u-boot

This commit fixes several issues:

- After moving env related code to ./env directory the env_common.o file
is no longer present in the system (has been replaced with built-in.o).

- Use ${OBJCOPY} if available, fallback to system default's objcopy if not
present.

- Extend the script to accept different build directory than current one.
It is extremely handy with OE usage, where source code is separated from
build.

Signed-off-by: Lukasz Majewski 
Tested-by: Alex Kiernan 
---

Changes in v2:
- Update comment information

 scripts/get_default_envs.sh | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
index 7955db60e5..3e532d12c4 100755
--- a/scripts/get_default_envs.sh
+++ b/scripts/get_default_envs.sh
@@ -6,16 +6,24 @@
 #
 
 # This file extracts default envs from built u-boot
-# usage: get_default_envs.sh > u-boot-env-default.txt
+# usage: get_default_envs.sh [build dir] > u-boot-env-default.txt
 set -ue
 
-ENV_OBJ_FILE="env_common.o"
+: "${OBJCOPY:=objcopy}"
+
+ENV_OBJ_FILE="built-in.o"
 ENV_OBJ_FILE_COPY="copy_${ENV_OBJ_FILE}"
 
 echoerr() { echo "$@" 1>&2; }
 
-path=$(readlink -f $0)
-env_obj_file_path=$(find ${path%/scripts*} -not -path "*/spl/*" \
+if [ "$#" -eq 1 ]; then
+path=${1}
+else
+path=$(readlink -f $0)
+path=${path%/scripts*}
+fi
+
+env_obj_file_path=$(find ${path} -path "*/env/*" -not -path "*/spl/*" \
 -name "${ENV_OBJ_FILE}")
 [ -z "${env_obj_file_path}" ] && \
 { echoerr "File '${ENV_OBJ_FILE}' not found!"; exit 1; }
@@ -23,8 +31,9 @@ env_obj_file_path=$(find ${path%/scripts*} -not -path 
"*/spl/*" \
 cp ${env_obj_file_path} ${ENV_OBJ_FILE_COPY}
 
 # NOTE: objcopy saves its output to file passed in
-# (copy_env_common.o in this case)
-objcopy -O binary -j ".rodata.default_environment" ${ENV_OBJ_FILE_COPY}
+# (copy_${ENV_OBJ_FILE} in this case)
+
+${OBJCOPY} -O binary -j ".rodata.default_environment" ${ENV_OBJ_FILE_COPY}
 
 # Replace default '\0' with '\n' and sort entries
 tr '\0' '\n' < ${ENV_OBJ_FILE_COPY} | sort -u
-- 
2.11.0

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

Re: [U-Boot] [PATCH] script: Make the get_default_envs.sh script working with newest u-boot

2018-02-14 Thread Tuomas Tynkkynen

On Wed, 14 Feb 2018 09:50:17 +0100
Lukasz Majewski  wrote:

> On Wed, 14 Feb 2018 03:25:58 +0200
> Tuomas Tynkkynen  wrote:
> 
> > Hi,
> > 
> > On Tue, 13 Feb 2018 23:01:13 +0100
> > Lukasz Majewski  wrote:
> > 
> > > This commit fixes several issues:
> > > 
> > > - After moving env related code to ./env directory the env_common.o
> > > file is no longer present in the system (has been replaced with
> > > built-in.o).
> > > 
> > > - Use ${OBJCOPY} if available, fallback to system default's objcopy
> > > if not present.
> > > 
> > > - Extend the script to accept different build directory than
> > > current one. It is extremely handy with OE usage, where source code
> > > is separated from build.
> > > 
> > > Signed-off-by: Lukasz Majewski 
> > > ---
> > > 
> > >  scripts/get_default_envs.sh | 19 ++-
> > >  1 file changed, 14 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/scripts/get_default_envs.sh
> > > b/scripts/get_default_envs.sh index 7955db60e5..bbb6d0a6ef 100755
> > > --- a/scripts/get_default_envs.sh
> > > +++ b/scripts/get_default_envs.sh
> > > @@ -6,16 +6,24 @@
> > >  #
> > >  
> > >  # This file extracts default envs from built u-boot
> > > -# usage: get_default_envs.sh > u-boot-env-default.txt
> > > +# usage: get_default_envs.sh [build dir] > u-boot-env-default.txt
> > >  set -ue
> > >  
> > > -ENV_OBJ_FILE="env_common.o"
> > > +: "${OBJCOPY:=objcopy}"  
> > 
> > Maybe "${CROSS_COMPILE}objcopy" would be a better default as that's
> > what the build system uses.
> 
> Unfortunately not with OE builds. In OE, the OBJCOPY is set to arm
> specific objcopy.
> 
> With fallback (objcopy) from your local machine - it depends if it
> supports multi arch or not.

No, I meant that instead of having a fallback of "objcopy", have a 
fallback of "${CROSS_COMPILE}objcopy". I.e. squashing this change:

diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
index 3e532d12c4..184cc19ab7 100755
--- a/scripts/get_default_envs.sh
+++ b/scripts/get_default_envs.sh
@@ -9,7 +9,7 @@
 # usage: get_default_envs.sh [build dir] > u-boot-env-default.txt
 set -ue
 
-: "${OBJCOPY:=objcopy}"
+: "${OBJCOPY:=${CROSS_COMPILE:-}objcopy}"
 
 ENV_OBJ_FILE="built-in.o"
 ENV_OBJ_FILE_COPY="copy_${ENV_OBJ_FILE}"

That way the script works out-of-the-box for people who do the usual

export CROSS_COMPILE=aarch64-linux-gnu- (or whatever)

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

[U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

board_usb_init()/_cleanup() should be in board files and don't have
a place in the xhci-omap driver. Weak versions for
board_usb_init()/_cleanup() already exist in common/usb.c
(for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).

Signed-off-by: Faiz Abbas 
---
Since 1a9a5f7 ("fix double weak board_usb_init functions") the
board_usb_init()/_cleanup() a prefix omap_xhci_* was added to the board
files and in omap-xhci.c because there was a duplicate implementation
in common/usb.c. However, this broke the gadget mode path which uses the
same board_usb_init/cleanup() in the board specific files.

I think a better way would be to just remove the functions from xhci-omap
like in this patch. Any issues with this?

 board/ti/am43xx/board.c  |  4 ++--
 board/ti/am57xx/board.c  |  4 ++--
 board/ti/dra7xx/evm.c|  4 ++--
 drivers/usb/host/xhci-omap.c | 22 --
 4 files changed, 6 insertions(+), 28 deletions(-)

diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 06082f1..6286af4 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -744,7 +744,7 @@ int usb_gadget_handle_interrupts(int index)
 #endif /* CONFIG_USB_DWC3 */
 
 #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
-int omap_xhci_board_usb_init(int index, enum usb_init_type init)
+int board_usb_init(int index, enum usb_init_type init)
 {
enable_usb_clocks(index);
 #ifdef CONFIG_USB_DWC3
@@ -775,7 +775,7 @@ int omap_xhci_board_usb_init(int index, enum usb_init_type 
init)
return 0;
 }
 
-int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
+int board_usb_cleanup(int index, enum usb_init_type init)
 {
 #ifdef CONFIG_USB_DWC3
switch (index) {
diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 1128784..c3f60f6 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -867,7 +867,7 @@ int usb_gadget_handle_interrupts(int index)
 #endif /* CONFIG_USB_DWC3 */
 
 #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
-int omap_xhci_board_usb_init(int index, enum usb_init_type init)
+int board_usb_init(int index, enum usb_init_type init)
 {
enable_usb_clocks(index);
switch (index) {
@@ -901,7 +901,7 @@ int omap_xhci_board_usb_init(int index, enum usb_init_type 
init)
return 0;
 }
 
-int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
+int board_usb_cleanup(int index, enum usb_init_type init)
 {
 #ifdef CONFIG_USB_DWC3
switch (index) {
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 6ecf971..519475e 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -907,7 +907,7 @@ static struct ti_usb_phy_device usb_phy2_device = {
.index = 1,
 };
 
-int omap_xhci_board_usb_init(int index, enum usb_init_type init)
+int board_usb_init(int index, enum usb_init_type init)
 {
enable_usb_clocks(index);
switch (index) {
@@ -944,7 +944,7 @@ int omap_xhci_board_usb_init(int index, enum usb_init_type 
init)
return 0;
 }
 
-int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
+int board_usb_cleanup(int index, enum usb_init_type init)
 {
switch (index) {
case 0:
diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
index d6c5744..b814500 100644
--- a/drivers/usb/host/xhci-omap.c
+++ b/drivers/usb/host/xhci-omap.c
@@ -27,28 +27,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static struct omap_xhci omap;
 
-__weak int omap_xhci_board_usb_init(int index, enum usb_init_type init)
-{
-   enable_usb_clocks(index);
-   return 0;
-}
-
-int board_usb_init(int index, enum usb_init_type init)
-{
-   return omap_xhci_board_usb_init(index, init);
-}
-
-__weak int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
-{
-   disable_usb_clocks(index);
-   return 0;
-}
-
-int board_usb_cleanup(int index, enum usb_init_type init)
-{
-   return omap_xhci_board_usb_cleanup(index, init);
-}
-
 static int omap_xhci_core_init(struct omap_xhci *omap)
 {
int ret = 0;
-- 
2.7.4

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

Re: [U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

2018-02-14 Thread Marek Vasut

On 02/14/2018 11:10 AM, Faiz Abbas wrote:
> board_usb_init()/_cleanup() should be in board files and don't have
> a place in the xhci-omap driver. Weak versions for
> board_usb_init()/_cleanup() already exist in common/usb.c
> (for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Marek Vasut 

I'd like some TBs from the people using those boards.

> ---
> Since 1a9a5f7 ("fix double weak board_usb_init functions") the
> board_usb_init()/_cleanup() a prefix omap_xhci_* was added to the board
> files and in omap-xhci.c because there was a duplicate implementation
> in common/usb.c. However, this broke the gadget mode path which uses the
> same board_usb_init/cleanup() in the board specific files.
> 
> I think a better way would be to just remove the functions from xhci-omap
> like in this patch. Any issues with this?
> 
>  board/ti/am43xx/board.c  |  4 ++--
>  board/ti/am57xx/board.c  |  4 ++--
>  board/ti/dra7xx/evm.c|  4 ++--
>  drivers/usb/host/xhci-omap.c | 22 --
>  4 files changed, 6 insertions(+), 28 deletions(-)
> 
> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> index 06082f1..6286af4 100644
> --- a/board/ti/am43xx/board.c
> +++ b/board/ti/am43xx/board.c
> @@ -744,7 +744,7 @@ int usb_gadget_handle_interrupts(int index)
>  #endif /* CONFIG_USB_DWC3 */
>  
>  #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
> -int omap_xhci_board_usb_init(int index, enum usb_init_type init)
> +int board_usb_init(int index, enum usb_init_type init)
>  {
>   enable_usb_clocks(index);
>  #ifdef CONFIG_USB_DWC3
> @@ -775,7 +775,7 @@ int omap_xhci_board_usb_init(int index, enum 
> usb_init_type init)
>   return 0;
>  }
>  
> -int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
> +int board_usb_cleanup(int index, enum usb_init_type init)
>  {
>  #ifdef CONFIG_USB_DWC3
>   switch (index) {
> diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
> index 1128784..c3f60f6 100644
> --- a/board/ti/am57xx/board.c
> +++ b/board/ti/am57xx/board.c
> @@ -867,7 +867,7 @@ int usb_gadget_handle_interrupts(int index)
>  #endif /* CONFIG_USB_DWC3 */
>  
>  #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
> -int omap_xhci_board_usb_init(int index, enum usb_init_type init)
> +int board_usb_init(int index, enum usb_init_type init)
>  {
>   enable_usb_clocks(index);
>   switch (index) {
> @@ -901,7 +901,7 @@ int omap_xhci_board_usb_init(int index, enum 
> usb_init_type init)
>   return 0;
>  }
>  
> -int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
> +int board_usb_cleanup(int index, enum usb_init_type init)
>  {
>  #ifdef CONFIG_USB_DWC3
>   switch (index) {
> diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
> index 6ecf971..519475e 100644
> --- a/board/ti/dra7xx/evm.c
> +++ b/board/ti/dra7xx/evm.c
> @@ -907,7 +907,7 @@ static struct ti_usb_phy_device usb_phy2_device = {
>   .index = 1,
>  };
>  
> -int omap_xhci_board_usb_init(int index, enum usb_init_type init)
> +int board_usb_init(int index, enum usb_init_type init)
>  {
>   enable_usb_clocks(index);
>   switch (index) {
> @@ -944,7 +944,7 @@ int omap_xhci_board_usb_init(int index, enum 
> usb_init_type init)
>   return 0;
>  }
>  
> -int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
> +int board_usb_cleanup(int index, enum usb_init_type init)
>  {
>   switch (index) {
>   case 0:
> diff --git a/drivers/usb/host/xhci-omap.c b/drivers/usb/host/xhci-omap.c
> index d6c5744..b814500 100644
> --- a/drivers/usb/host/xhci-omap.c
> +++ b/drivers/usb/host/xhci-omap.c
> @@ -27,28 +27,6 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  static struct omap_xhci omap;
>  
> -__weak int omap_xhci_board_usb_init(int index, enum usb_init_type init)
> -{
> - enable_usb_clocks(index);
> - return 0;
> -}
> -
> -int board_usb_init(int index, enum usb_init_type init)
> -{
> - return omap_xhci_board_usb_init(index, init);
> -}
> -
> -__weak int omap_xhci_board_usb_cleanup(int index, enum usb_init_type init)
> -{
> - disable_usb_clocks(index);
> - return 0;
> -}
> -
> -int board_usb_cleanup(int index, enum usb_init_type init)
> -{
> - return omap_xhci_board_usb_cleanup(index, init);
> -}
> -
>  static int omap_xhci_core_init(struct omap_xhci *omap)
>  {
>   int ret = 0;
> 


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

Re: [U-Boot] [PATCH] script: Make the get_default_envs.sh script working with newest u-boot

Hi Tuomas,

> On Wed, 14 Feb 2018 09:50:17 +0100
> Lukasz Majewski  wrote:
> 
> > On Wed, 14 Feb 2018 03:25:58 +0200
> > Tuomas Tynkkynen  wrote:
> >   
> > > Hi,
> > > 
> > > On Tue, 13 Feb 2018 23:01:13 +0100
> > > Lukasz Majewski  wrote:
> > >   
> > > > This commit fixes several issues:
> > > > 
> > > > - After moving env related code to ./env directory the
> > > > env_common.o file is no longer present in the system (has been
> > > > replaced with built-in.o).
> > > > 
> > > > - Use ${OBJCOPY} if available, fallback to system default's
> > > > objcopy if not present.
> > > > 
> > > > - Extend the script to accept different build directory than
> > > > current one. It is extremely handy with OE usage, where source
> > > > code is separated from build.
> > > > 
> > > > Signed-off-by: Lukasz Majewski 
> > > > ---
> > > > 
> > > >  scripts/get_default_envs.sh | 19 ++-
> > > >  1 file changed, 14 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/scripts/get_default_envs.sh
> > > > b/scripts/get_default_envs.sh index 7955db60e5..bbb6d0a6ef
> > > > 100755 --- a/scripts/get_default_envs.sh
> > > > +++ b/scripts/get_default_envs.sh
> > > > @@ -6,16 +6,24 @@
> > > >  #
> > > >  
> > > >  # This file extracts default envs from built u-boot
> > > > -# usage: get_default_envs.sh > u-boot-env-default.txt
> > > > +# usage: get_default_envs.sh [build dir] >
> > > > u-boot-env-default.txt set -ue
> > > >  
> > > > -ENV_OBJ_FILE="env_common.o"
> > > > +: "${OBJCOPY:=objcopy}"
> > > 
> > > Maybe "${CROSS_COMPILE}objcopy" would be a better default as
> > > that's what the build system uses.  
> > 
> > Unfortunately not with OE builds. In OE, the OBJCOPY is set to arm
> > specific objcopy.
> > 
> > With fallback (objcopy) from your local machine - it depends if it
> > supports multi arch or not.  
> 
> No, I meant that instead of having a fallback of "objcopy", have a 
> fallback of "${CROSS_COMPILE}objcopy". I.e. squashing this change:
> 
> diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
> index 3e532d12c4..184cc19ab7 100755
> --- a/scripts/get_default_envs.sh
> +++ b/scripts/get_default_envs.sh
> @@ -9,7 +9,7 @@
>  # usage: get_default_envs.sh [build dir] > u-boot-env-default.txt
>  set -ue
>  
> -: "${OBJCOPY:=objcopy}"
> +: "${OBJCOPY:=${CROSS_COMPILE:-}objcopy}"

Yes, you are obviously right. I've misunderstood you, sorry.

I will prepare v3 immediately.

Thanks.

>  
>  ENV_OBJ_FILE="built-in.o"
>  ENV_OBJ_FILE_COPY="copy_${ENV_OBJ_FILE}"
> 
> That way the script works out-of-the-box for people who do the usual
> 
> export CROSS_COMPILE=aarch64-linux-gnu- (or whatever)
> 
> when building 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


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

[U-Boot] [PATCH v3] script: Make the get_default_envs.sh script working with newest u-boot

This commit fixes several issues:

- After moving env related code to ./env directory the env_common.o file
is no longer present in the system (has been replaced with built-in.o).

- Use ${OBJCOPY} if available, fallback to system default's objcopy if not
present.

- Extend the script to accept different build directory than current one.
It is extremely handy with OE usage, where source code is separated from
build.

Signed-off-by: Lukasz Majewski 
Tested-by: Alex Kiernan 
---

Changes in v3:
- Extend the objcopy to use CROSS_COMPILE if defined

Changes in v2:
- Update comment information

 scripts/get_default_envs.sh | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
index 7955db60e5..184cc19ab7 100755
--- a/scripts/get_default_envs.sh
+++ b/scripts/get_default_envs.sh
@@ -6,16 +6,24 @@
 #
 
 # This file extracts default envs from built u-boot
-# usage: get_default_envs.sh > u-boot-env-default.txt
+# usage: get_default_envs.sh [build dir] > u-boot-env-default.txt
 set -ue
 
-ENV_OBJ_FILE="env_common.o"
+: "${OBJCOPY:=${CROSS_COMPILE:-}objcopy}"
+
+ENV_OBJ_FILE="built-in.o"
 ENV_OBJ_FILE_COPY="copy_${ENV_OBJ_FILE}"
 
 echoerr() { echo "$@" 1>&2; }
 
-path=$(readlink -f $0)
-env_obj_file_path=$(find ${path%/scripts*} -not -path "*/spl/*" \
+if [ "$#" -eq 1 ]; then
+path=${1}
+else
+path=$(readlink -f $0)
+path=${path%/scripts*}
+fi
+
+env_obj_file_path=$(find ${path} -path "*/env/*" -not -path "*/spl/*" \
 -name "${ENV_OBJ_FILE}")
 [ -z "${env_obj_file_path}" ] && \
 { echoerr "File '${ENV_OBJ_FILE}' not found!"; exit 1; }
@@ -23,8 +31,9 @@ env_obj_file_path=$(find ${path%/scripts*} -not -path 
"*/spl/*" \
 cp ${env_obj_file_path} ${ENV_OBJ_FILE_COPY}
 
 # NOTE: objcopy saves its output to file passed in
-# (copy_env_common.o in this case)
-objcopy -O binary -j ".rodata.default_environment" ${ENV_OBJ_FILE_COPY}
+# (copy_${ENV_OBJ_FILE} in this case)
+
+${OBJCOPY} -O binary -j ".rodata.default_environment" ${ENV_OBJ_FILE_COPY}
 
 # Replace default '\0' with '\n' and sort entries
 tr '\0' '\n' < ${ENV_OBJ_FILE_COPY} | sort -u
-- 
2.11.0

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

Re: [U-Boot] rk3288: broken boot

On Wed, Feb 14, 2018 at 5:38 AM, Dr. Philipp Tomsich
 wrote:
> Jagan,
>
>> On 13 Feb 2018, at 13:20, Jagan Teki  wrote:
>>
>> On Tue, Feb 13, 2018 at 5:29 PM, Dr. Philipp Tomsich
>>  wrote:
>>> I verified the build for evb-rk3288_defconfig and everything looks fine:
>>>
>>> spl/u-boot-spl.bin: file format binary
>>>
>>>
>>> Disassembly of section .data:
>>>
>>>  <.data>:
>>>   0:   eaffb   0x4 <— this is the extra branch 
>>> inserted (to be overwritten by mkimage)
>>>   4:   ea16b   0x64
>>
>> I saw this on SPL, but I'm using TPL where I'm using mkimage to tp binary
>>
>>>...
>>>  20:   ea0fb   0x64
>>>  24:   e59ff014ldr pc, [pc, #20]   ; 0x40
>>>  28:   e59ff014ldr pc, [pc, #20]   ; 0x44
>>>  2c:   e59ff014ldr pc, [pc, #20]   ; 0x48
>>>  30:   e59ff014ldr pc, [pc, #20]   ; 0x4c
>>>  34:   e59ff014ldr pc, [pc, #20]   ; 0x50
>>>  38:   e59ff014ldr pc, [pc, #20]   ; 0x54
>>>  3c:   e59ff014ldr pc, [pc, #20]   ; 0x58
>>
>> I can see the difference of size by 8 bytes with spl/u-boot-spl-dtb.bin
>>
>> with tparams->header_size = RK_SPL_HDR_START + 4; (working scenario)
>> $ ls -l spl/u-boot-spl-dtb.bin
>> -rw-r--r-- 1 root root 37571
>>
>> normal build have
>> $ ls -l spl/u-boot-spl-dtb.bin
>> -rw-r--r-- 1 root root 37563
>
> In order to find the issue, I’d recommend to look at both the ELF file
> and the binary for your TPL stage. Disassembling the binary will show
> whether the extra branch is indeed added as the first instruction and
> if the second instruction is a branch to the reset entry-point.

This is what I found with mkimage tpl, the extra 0xeaff branch
inserted start with 0x820 in case of working, but branch insertion did
4 bytes prior to 0x820 [1]

https://paste.ubuntu.com/p/BbZrvJhqJD/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rk3288: broken boot

2018-02-14 Thread Dr. Philipp Tomsich


> On 14 Feb 2018, at 11:47, Jagan Teki  wrote:
> 
> On Wed, Feb 14, 2018 at 5:38 AM, Dr. Philipp Tomsich
>  > wrote:
>> Jagan,
>> 
>>> On 13 Feb 2018, at 13:20, Jagan Teki  wrote:
>>> 
>>> On Tue, Feb 13, 2018 at 5:29 PM, Dr. Philipp Tomsich
>>>  wrote:
 I verified the build for evb-rk3288_defconfig and everything looks fine:
 
 spl/u-boot-spl.bin: file format binary
 
 
 Disassembly of section .data:
 
  <.data>:
  0:   eaffb   0x4 <— this is the extra branch 
 inserted (to be overwritten by mkimage)
  4:   ea16b   0x64
>>> 
>>> I saw this on SPL, but I'm using TPL where I'm using mkimage to tp binary
>>> 
   ...
 20:   ea0fb   0x64
 24:   e59ff014ldr pc, [pc, #20]   ; 0x40
 28:   e59ff014ldr pc, [pc, #20]   ; 0x44
 2c:   e59ff014ldr pc, [pc, #20]   ; 0x48
 30:   e59ff014ldr pc, [pc, #20]   ; 0x4c
 34:   e59ff014ldr pc, [pc, #20]   ; 0x50
 38:   e59ff014ldr pc, [pc, #20]   ; 0x54
 3c:   e59ff014ldr pc, [pc, #20]   ; 0x58
>>> 
>>> I can see the difference of size by 8 bytes with spl/u-boot-spl-dtb.bin
>>> 
>>> with tparams->header_size = RK_SPL_HDR_START + 4; (working scenario)
>>> $ ls -l spl/u-boot-spl-dtb.bin
>>> -rw-r--r-- 1 root root 37571
>>> 
>>> normal build have
>>> $ ls -l spl/u-boot-spl-dtb.bin
>>> -rw-r--r-- 1 root root 37563
>> 
>> In order to find the issue, I’d recommend to look at both the ELF file
>> and the binary for your TPL stage. Disassembling the binary will show
>> whether the extra branch is indeed added as the first instruction and
>> if the second instruction is a branch to the reset entry-point.
> 
> This is what I found with mkimage tpl, the extra 0xeaff branch
> inserted start with 0x820 in case of working, but branch insertion did
> 4 bytes prior to 0x820 [1]
> 
> https://paste.ubuntu.com/p/BbZrvJhqJD/ 
> 
This output looks very wrong (even the one that works for you).

There shouldn’t be all the 0-bytes at the beginning and the ea16 (‘b 0x64’)
should be at offset 4 (i.e. 0x804); the 0xeaff should have been at offset 0 
(and
been overwritten with the ‘RK32’ at 0x800).

Apparently the tpl/u-boot-tpl.bin you feed into mkimage is already wrong: you
should check your ld-script, the ELF-file and the objcopy.  This looks as if 
some
part of the process is adding 7 words of padding.  The assembly injected from
the boot0 header needs to be at the start of the binary… if it is not, then 
something
has gone wrong before.

Thanks,
Philipp.

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

Re: [U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

Hi,

On Wednesday 14 February 2018 03:46 PM, Marek Vasut wrote:
> On 02/14/2018 11:10 AM, Faiz Abbas wrote:
>> board_usb_init()/_cleanup() should be in board files and don't have
>> a place in the xhci-omap driver. Weak versions for
>> board_usb_init()/_cleanup() already exist in common/usb.c
>> (for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).
>>
>> Signed-off-by: Faiz Abbas 
> 
> Reviewed-by: Marek Vasut 
> 
> I'd like some TBs from the people using those boards.

I have tested this for dra7xx, am43xx and am57xx.

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

Re: [U-Boot] [PATCH] drivers/ddr/fsl: Dual-license DDR driver

2018-02-14 Thread Stefan Roese


On 13.02.2018 17:30, York Sun wrote:

On 02/13/2018 04:49 AM, Wolfgang Denk wrote:

Dear York,

In message 

 you wrote:


Nobody said anything. Some addresses bounced. And most changes made out
people outside Freescale/NXP are minor changes, except twice the files
were moved during U-Boot structure change. What options do I have?


Ask all people who contributed to that code for their explicit
permission.  Legally it is a huge difference between actively
confirming approval and not reacting at all.




All,

If you haven't responded, please give your explicit approval to change
Freescale DDR driver to dual-license so it can be re-used by other
project(s) with BSD license. Here is the list I compiled from the git
history. All commits made by Freescale/NXP employees are removed from
this list.


00caae6 - Simon Glass, s...@chromium.org, 6 months ago : env: Rename
getenv/_f() to env_get()
457e51c - Simon Glass, s...@chromium.org, 9 months ago : common: arm:
freescale: layerscape: Move header files out of common.h
6e2941d - Simon Glass, s...@chromium.org, 9 months ago : common:
freescale: Move arch-specific declarations
3c476d8 - Tom Rini, tr...@konsulko.com, 10 months ago : Merge
git://git.denx.de/u-boot-fsl-qoriq
0e0de24 - xypron.g...@gmx.de, xypron.g...@gmx.de, 10 months ago : ddr:
fsl: incorrect logical constraint in populate_memctl_options
97fbf26 - Thomas Schaefer, thomas.schae...@kontron.com, 11 months ago :
drivers: ddr: fsl: fix unused-const-variable warnings
f1683aa - Simon Glass, s...@chromium.org, 10 months ago : board_f: Rename
initdram() to dram_init()
3eace37 - Simon Glass, s...@chromium.org, 10 months ago : arm: freescale:
Rename initdram() to fsl_initdram()
088454c - Simon Glass, s...@chromium.org, 11 months ago : board_f: Drop
return value from initdram()
cbe7706 - Tom Rini, tr...@konsulko.com, 1 year, 5 months ago : Merge
git://git.denx.de/u-boot-fsl-qoriq
a4ca379 - Masahiro Yamada, yamada.masah...@socionext.com, 1 year, 5
months ago : drivers: squash lines for immediate return
62a3b7d - Robert P. J. Day, rpj...@crashcourse.ca, 1 year, 7 months ago
: Various, unrelated tree-wide typo fixes.
dd8d8da - Alexander Merkle, alexander.mer...@lauterbach.com, 1 year, 11
months ago : Fix typo choosen in comments and printf logs
5b8031c - Tom Rini, tr...@konsulko.com, 2 years, 1 month ago : Add more
SPDX-License-Identifier tags
da58dec - Tom Rini, tr...@konsulko.com, 2 years, 3 months ago : Various
Makefiles: Add SPDX-License-Identifier tags
e368c20 - Joakim Tjernlund, joakim.tjernl...@transmode.se, 2 years, 4
months ago : drivers/ddr/fsl_ddr: Make SR_IE configurable
d7c865b - Curt Brune, c...@cumulusnetworks.com, 3 years ago :
MPC8541/MPC8555: Enable SS_EN in DDR_SDRAM_CLK_CNLT register
b414119 - Masahiro Yamada, yamad...@jp.panasonic.com, 3 years, 3 months
ago : linux/kernel.h: sync min, max, min3, max3 macros with Linux
e1bf824 - Simon Glass, s...@chromium.org, 3 years, 10 months ago : Add
cli_ prefix to readline functions
18d6653 - Simon Glass, s...@chromium.org, 3 years, 10 months ago : move
CLI prototypes to cli.h and add comments
06c1411 - Masahiro Yamada, yamad...@jp.panasonic.com, 4 years, 4 months
ago : powerpc: convert makefiles to Kbuild style
7e157b0 - Valentin Longchamp, valentin.longch...@keymile.com, 4 years, 4
months ago : mpc8xxx: set x2 DDR3 refresh rate if SPD config requires it
0778bbe - Valentin Longchamp, valentin.longch...@keymile.com, 4 years, 4
months ago : mpc8xxx: call i2c_set_bus_num in __get_spd
2f848f9 - Shruti Kanetkar, shr...@freescale.com, 4 years, 6 months ago :
powerpc: Use print_size() where appropriate
1a45966 - Wolfgang Denk, w...@denx.de, 4 years, 7 months ago : Add
GPL-2.0+ SPDX-License-Identifier to source files
5b93394 - Anatolij Gustschin, ag...@denx.de, 5 years ago : mpc8xxx: fix
DDR init value to use CONFIG_MEM_INIT_VALUE
411e150 - Kumar Gala, ga...@kernel.crashing.org, 6 years ago :
arch/powerpc/cpu/mpc8xxx/ddr/interactive.c: Fix GCC 4.6 build warning
2f3a71f - Ira W. Snyder, i...@ovro.caltech.edu, 6 years ago : mpc8xxx:
update module_type values from JEDEC DDR3 SPD Specification
dea7f88 - Kumar Gala, ga...@kernel.crashing.org, 6 years ago :
arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c: Fix GCC 4.6 build warning
667bc17 - Kumar Gala, ga...@kernel.crashing.org, 6 years ago :
arch/powerpc/cpu/mpc8xxx/ddr/options.c: Fix GCC 4.6 build warning
cd84b1f - Marek Vasut, marek.va...@gmail.com, 6 years ago : GCC4.6:
Squash warnings in ddr[123]_dimm_params.c
a287963 - Kyle Moffett, kyle.d.moff...@boeing.com, 7 years ago :
fsl-ddr: Fix mixed-case macro names
c2a63f4 - Kumar Gala, ga...@kernel.crashing.org, 7 years ago :
powerpc/8xxx: Fix typo for address hashing message
c7fd27c - Kyle Moffett, kyle.d.moff...@boeing.com, 7 years ago :
mpc8xxx: DDR2/DDR3: Clean up DIMM-type switch statements
e820a13 - Kyle Moffett, kyle.d.moff...@boeing.com, 7 years ago :
fsl_ddr: Don't use full 64-bit divides on 32-bit PowerPC
c39f44d - Kumar Gala, ga...@kernel.crashing.org, 7 years ago :

Re: [U-Boot] [PATCH] drivers/ddr/fsl: Dual-license DDR driver

2018-02-14 Thread Thomas Schaefer

Hi York,

I was not aware that my small warning fix really made it up to mainstream code. 
Anyway I approve that license change.

Best regards,
Thomas

-Ursprüngliche Nachricht-
Von: York Sun [mailto:york@nxp.com] 
Gesendet: Dienstag, 13. Februar 2018 17:06
An: Wolfgang Denk
Cc: Marek Vasut; u-boot@lists.denx.de; Simon Glass; Tom Rini; Heinrich 
Schuchardt; Thomas Schaefer; Masahiro Yamada; Robert P . J . Day; 
alexander.mer...@lauterbach.com; Joakim Tjernlund; Curt Brune; Valentin 
Longchamp; Anatolij Gustschin; Ira W . Snyder; Kyle Moffett; Sebastien Carlier; 
Stefan Roese; Peter Tyser; Paul Gortmaker; Jean-Christophe PLAGNIOL-VILLARD; 
Shaohui Xie; Ashish Kumar; Rajesh Bhagat; Prabhakar Kushwaha
Betreff: Re: [PATCH] drivers/ddr/fsl: Dual-license DDR driver

On 02/13/2018 04:49 AM, Wolfgang Denk wrote:
> Dear York,
> 
> In message 
> 
>  you wrote:
>>
>> Nobody said anything. Some addresses bounced. And most changes made 
>> out people outside Freescale/NXP are minor changes, except twice the 
>> files were moved during U-Boot structure change. What options do I have?
> 
> Ask all people who contributed to that code for their explicit 
> permission.  Legally it is a huge difference between actively 
> confirming approval and not reacting at all.
> 

All people (except Freescale and NXP employees) contributed to this code are in 
the CC list. Please give your explicit approval for this license change. Thanks.

York


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

Re: [U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

2018-02-14 Thread Bin Meng

On Wed, Feb 14, 2018 at 6:10 PM, Faiz Abbas  wrote:
> board_usb_init()/_cleanup() should be in board files and don't have
> a place in the xhci-omap driver. Weak versions for
> board_usb_init()/_cleanup() already exist in common/usb.c
> (for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).
>
> Signed-off-by: Faiz Abbas 
> ---
> Since 1a9a5f7 ("fix double weak board_usb_init functions") the
> board_usb_init()/_cleanup() a prefix omap_xhci_* was added to the board
> files and in omap-xhci.c because there was a duplicate implementation
> in common/usb.c. However, this broke the gadget mode path which uses the
> same board_usb_init/cleanup() in the board specific files.
>
> I think a better way would be to just remove the functions from xhci-omap
> like in this patch. Any issues with this?
>
>  board/ti/am43xx/board.c  |  4 ++--
>  board/ti/am57xx/board.c  |  4 ++--
>  board/ti/dra7xx/evm.c|  4 ++--
>  drivers/usb/host/xhci-omap.c | 22 --
>  4 files changed, 6 insertions(+), 28 deletions(-)
>

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

Re: [U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

2018-02-14 Thread Marek Vasut

On 02/14/2018 12:20 PM, Faiz Abbas wrote:
> Hi,
> 
> On Wednesday 14 February 2018 03:46 PM, Marek Vasut wrote:
>> On 02/14/2018 11:10 AM, Faiz Abbas wrote:
>>> board_usb_init()/_cleanup() should be in board files and don't have
>>> a place in the xhci-omap driver. Weak versions for
>>> board_usb_init()/_cleanup() already exist in common/usb.c
>>> (for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).
>>>
>>> Signed-off-by: Faiz Abbas 
>>
>> Reviewed-by: Marek Vasut 
>>
>> I'd like some TBs from the people using those boards.
> 
> I have tested this for dra7xx, am43xx and am57xx.

So why is it marked RFC ?

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

Re: [U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

Hi,

On Wednesday 14 February 2018 06:53 PM, Marek Vasut wrote:
> On 02/14/2018 12:20 PM, Faiz Abbas wrote:
>> Hi,
>>
>> On Wednesday 14 February 2018 03:46 PM, Marek Vasut wrote:
>>> On 02/14/2018 11:10 AM, Faiz Abbas wrote:
 board_usb_init()/_cleanup() should be in board files and don't have
 a place in the xhci-omap driver. Weak versions for
 board_usb_init()/_cleanup() already exist in common/usb.c
 (for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).

 Signed-off-by: Faiz Abbas 
>>>
>>> Reviewed-by: Marek Vasut 
>>>
>>> I'd like some TBs from the people using those boards.
>>
>> I have tested this for dra7xx, am43xx and am57xx.
> 
> So why is it marked RFC ?
> 

Because I was unclear why Uri Mashiach did not do this in 1a9a5f7 ("fix
double weak board_usb_init functions").

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

[U-Boot] [PATCH] dfu: Limit dfu_mmc to non-SPL case

Since 82b9dc63 ("Only build cli_readline.o for CMDLINE on non-SPL"),
cli_simple.c is only being built for non-SPL case. However, dfu_mmc
requires cli_simple.c to build and dfu fails to build for SPL when
CONFIG_HUSH_PARSER is disabled.

Therefore, limit dfu_mmc to non-SPL case only.

Signed-off-by: Faiz Abbas 
---
 drivers/dfu/Makefile | 2 ++
 drivers/dfu/dfu.c| 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index 61f2b71..5628734 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -6,7 +6,9 @@
 #
 
 obj-$(CONFIG_USB_FUNCTION_DFU) += dfu.o
+ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_DFU_MMC) += dfu_mmc.o
+endif
 obj-$(CONFIG_DFU_NAND) += dfu_nand.o
 obj-$(CONFIG_DFU_RAM) += dfu_ram.o
 obj-$(CONFIG_DFU_SF) += dfu_sf.o
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 2c22b62..a16e10e 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -398,8 +398,10 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char 
*s, int alt,
 
/* Specific for mmc device */
if (strcmp(interface, "mmc") == 0) {
+#ifndef CONFIG_SPL_BUILD
if (dfu_fill_entity_mmc(dfu, devstr, s))
return -1;
+#endif
} else if (strcmp(interface, "nand") == 0) {
if (dfu_fill_entity_nand(dfu, devstr, s))
return -1;
-- 
2.7.4

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

Re: [U-Boot] [PATCH] dfu: Limit dfu_mmc to non-SPL case

On Wed, Feb 14, 2018 at 07:59:46PM +0530, Faiz Abbas wrote:

> Since 82b9dc63 ("Only build cli_readline.o for CMDLINE on non-SPL"),
> cli_simple.c is only being built for non-SPL case. However, dfu_mmc
> requires cli_simple.c to build and dfu fails to build for SPL when
> CONFIG_HUSH_PARSER is disabled.
> 
> Therefore, limit dfu_mmc to non-SPL case only.
> 
> Signed-off-by: Faiz Abbas 
> ---
>  drivers/dfu/Makefile | 2 ++
>  drivers/dfu/dfu.c| 2 ++
>  2 files changed, 4 insertions(+)

Does DFU for MMC make sense inside of SPL?  If so, you should follow
82b9dc63 and CONFIG_FSL_DDR_INTERACTIVE and bring back in cli_simple.o
(and cli_readline.o, if needed) for CONFIG_SPL_DFU_MMC or so.  If not,
we should more cleanly and clearly block out all non-DFU RAM cases for
SPL.  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] dfu: Limit dfu_mmc to non-SPL case

Hi,

On Wednesday 14 February 2018 08:04 PM, Tom Rini wrote:
> On Wed, Feb 14, 2018 at 07:59:46PM +0530, Faiz Abbas wrote:
> 
>> Since 82b9dc63 ("Only build cli_readline.o for CMDLINE on non-SPL"),
>> cli_simple.c is only being built for non-SPL case. However, dfu_mmc
>> requires cli_simple.c to build and dfu fails to build for SPL when
>> CONFIG_HUSH_PARSER is disabled.
>>
>> Therefore, limit dfu_mmc to non-SPL case only.
>>
>> Signed-off-by: Faiz Abbas 
>> ---
>>  drivers/dfu/Makefile | 2 ++
>>  drivers/dfu/dfu.c| 2 ++
>>  2 files changed, 4 insertions(+)
> 
> Does DFU for MMC make sense inside of SPL? 

No.

If so, you should follow
> 82b9dc63 and CONFIG_FSL_DDR_INTERACTIVE and bring back in cli_simple.o
> (and cli_readline.o, if needed) for CONFIG_SPL_DFU_MMC or so.  If not,
> we should more cleanly and clearly block out all non-DFU RAM cases for
> SPL.  Thanks!

Do you mean non-RAM DFU cases? Block out everything but RAM?


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

Re: [U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

2018-02-14 Thread Marek Vasut

On 02/14/2018 03:14 PM, Faiz Abbas wrote:
> Hi,
> 
> On Wednesday 14 February 2018 06:53 PM, Marek Vasut wrote:
>> On 02/14/2018 12:20 PM, Faiz Abbas wrote:
>>> Hi,
>>>
>>> On Wednesday 14 February 2018 03:46 PM, Marek Vasut wrote:
 On 02/14/2018 11:10 AM, Faiz Abbas wrote:
> board_usb_init()/_cleanup() should be in board files and don't have
> a place in the xhci-omap driver. Weak versions for
> board_usb_init()/_cleanup() already exist in common/usb.c
> (for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).
>
> Signed-off-by: Faiz Abbas 

 Reviewed-by: Marek Vasut 

 I'd like some TBs from the people using those boards.
>>>
>>> I have tested this for dra7xx, am43xx and am57xx.
>>
>> So why is it marked RFC ?
>>
> 
> Because I was unclear why Uri Mashiach did not do this in 1a9a5f7 ("fix
> double weak board_usb_init functions").

OK, submit it as a normal patch with my RB.

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

Re: [U-Boot] U-Boot

2018-02-14 Thread Mariano Coromac

H it displays the following:
  Class   Probed   Name

 root[ + ]root_driver
 simple_bus  [   ]`-- ahb
 mmc [   ]|-- sdio-host@a000
 blk [   ]|   `-- sdio-h...@a000.blk
 mmc [   ]|-- sdio-host@b000
 blk [   ]|   `-- sdio-h...@b000.blk
 simple_bus  [   ]`-- apb
 simple_bus  [   ]|-- pmc@f0014000
 clk [   ]|   |-- mainck
 clk [   ]|   |-- pllack@0
 clk [   ]|   |-- utmick
 clk [   ]|   |-- masterck
 clk [   ]|   |-- h32mxck
 misc[   ]|   |-- periph32ck
 clk [   ]|   |   |-- pioA_clk@18
 clk [   ]|   |   |-- uart0_clk@24
 clk [   ]|   |   |-- uart1_clk@25
 clk [   ]|   |   |-- uart2_clk@26
 clk [   ]|   |   `-- spi0_clk@33
 misc[   ]|   |-- periph64ck
 clk [   ]|   |   |-- sdmmc0_hclk@31
 clk [   ]|   |   |-- sdmmc1_hclk@32
 clk [   ]|   |   |-- qspi0_clk@52
 clk [   ]|   |   `-- qspi1_clk@53
 misc[   ]|   `-- gck
 clk [   ]|   |-- sdmmc0_gclk@31
 clk [   ]|   `-- sdmmc1_gclk@32
 spi [   ]|-- spi@f800
 serial  [   ]|-- serial@f8038200
 gpio[   ]`-- gpio@fc038000
 pinctrl [   ]`-- pinctrl
 pinconfig   [   ]|-- sdmmc0_cmd_dat_default
 pinconfig   [   ]|-- sdmmc0_ck_cd_default
 pinconfig   [   ]|-- sdmmc1_cmd_dat_default
 pinconfig   [   ]|-- sdmmc1_ck_cd_default
 pinconfig   [   ]|-- spi0_default
 pinconfig   [   ]`-- serial0_default
bind node serial@f8038200
   - attempt to match compatible string 'atmel,at91sam9260-usart'
   - found match at 'serial_atmel'
No serial driver found
resetting ...

stdout is declared like this: stdout-path = &serial0;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 2/2] mmc: fix bug in mmc_startup_v4()

2018-02-14 Thread Sam Protsenko

On 9 February 2018 at 13:09, Jean-Jacques Hiblot  wrote:
> The correspondence between mmc versions as used in u-boot and the version
> numbers reported in register EXT_CSD_REV is wrong for versions above and
> including MMC_VERSION_4_41. All those versions were shifted by one:
> real 4.5 hardware appeared to be MMC_VERSION_5_0.
>
> Fix this by adding the missing version in the correspondence table.
>
> Reported-by: eil Eilmsteiner Heribert 
> Signed-off-by: Jean-Jacques Hiblot 
>
> ---
>
>  drivers/mmc/mmc.c | 1 +
>  include/mmc.h | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 31614dd..99e2a75 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1950,6 +1950,7 @@ static int mmc_startup_v4(struct mmc *mmc)
> MMC_VERSION_4_1,
> MMC_VERSION_4_2,
> MMC_VERSION_4_3,
> +   MMC_VERSION_4_4,
> MMC_VERSION_4_41,
> MMC_VERSION_4_5,
> MMC_VERSION_5_0,
> diff --git a/include/mmc.h b/include/mmc.h
> index a46eaed..86f885b 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -54,6 +54,7 @@
>  #define MMC_VERSION_4_1MAKE_MMC_VERSION(4, 1, 0)
>  #define MMC_VERSION_4_2MAKE_MMC_VERSION(4, 2, 0)
>  #define MMC_VERSION_4_3MAKE_MMC_VERSION(4, 3, 0)
> +#define MMC_VERSION_4_4MAKE_MMC_VERSION(4, 4, 0)
>  #define MMC_VERSION_4_41   MAKE_MMC_VERSION(4, 4, 1)
>  #define MMC_VERSION_4_5MAKE_MMC_VERSION(4, 5, 0)
>  #define MMC_VERSION_5_0MAKE_MMC_VERSION(5, 0, 0)
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

Reviewed-by: Sam Protsenko 

This patch fixes eMMC on AM57x EVM / X15 boards, which was broken in
58a6fb7b0496 ("mmc: reworked version lookup in mmc_startup_v4")
commit.

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

Re: [U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

2018-02-14 Thread Uri Mashiach


Hi,
Sorry for the late response.

On 02/14/2018 04:19 PM, Marek Vasut wrote:

On 02/14/2018 03:14 PM, Faiz Abbas wrote:

Hi,

On Wednesday 14 February 2018 06:53 PM, Marek Vasut wrote:

On 02/14/2018 12:20 PM, Faiz Abbas wrote:

Hi,

On Wednesday 14 February 2018 03:46 PM, Marek Vasut wrote:

On 02/14/2018 11:10 AM, Faiz Abbas wrote:

board_usb_init()/_cleanup() should be in board files and don't have
a place in the xhci-omap driver. Weak versions for
board_usb_init()/_cleanup() already exist in common/usb.c
(for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).

Signed-off-by: Faiz Abbas 


Reviewed-by: Marek Vasut 

I'd like some TBs from the people using those boards.


I have tested this for dra7xx, am43xx and am57xx.


So why is it marked RFC ?



Because I was unclear why Uri Mashiach did not do this in 1a9a5f7 ("fix
double weak board_usb_init functions").


OK, submit it as a normal patch with my RB.



As mentioned in 1a9a5f7, the functions omap_xhci_board_usb_init() and 
omap_xhci_board_usb_cleanup() are called for the boards with the 
CONFIG_USB_XHCI_OMAP definition.


The weak implementation of the functions omap_xhci_board_usb_init()
executed enable_usb_clocks().
The weak implementation of the function omap_xhci_board_usb_cleanup() 
executed the function disable_usb_clocks().


For the boards compulab/cl-som-am57x and compulab/cm_t43:
* CONFIG_USB_XHCI_OMAP is defined
* omap_xhci_board_usb_init is not implemented, relying on the weak 
implementation.
* omap_xhci_board_usb_cleanup is not defined, relying on the weak 
implementation.


The fix is missing the implementation of board_usb_init and 
board_usb_cleanup in the compulab/cl-som-am57x and compulab/cm_t43.
The implementation should include the content of the deleted weak 
functions omap_xhci_board_usb_init() and omap_xhci_board_usb_cleanup().


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

Re: [U-Boot] [PATCH] dfu: Limit dfu_mmc to non-SPL case

On Wed, Feb 14, 2018 at 08:15:15PM +0530, Faiz Abbas wrote:
> Hi,
> 
> On Wednesday 14 February 2018 08:04 PM, Tom Rini wrote:
> > On Wed, Feb 14, 2018 at 07:59:46PM +0530, Faiz Abbas wrote:
> > 
> >> Since 82b9dc63 ("Only build cli_readline.o for CMDLINE on non-SPL"),
> >> cli_simple.c is only being built for non-SPL case. However, dfu_mmc
> >> requires cli_simple.c to build and dfu fails to build for SPL when
> >> CONFIG_HUSH_PARSER is disabled.
> >>
> >> Therefore, limit dfu_mmc to non-SPL case only.
> >>
> >> Signed-off-by: Faiz Abbas 
> >> ---
> >>  drivers/dfu/Makefile | 2 ++
> >>  drivers/dfu/dfu.c| 2 ++
> >>  2 files changed, 4 insertions(+)
> > 
> > Does DFU for MMC make sense inside of SPL? 
> 
> No.
> 
> If so, you should follow
> > 82b9dc63 and CONFIG_FSL_DDR_INTERACTIVE and bring back in cli_simple.o
> > (and cli_readline.o, if needed) for CONFIG_SPL_DFU_MMC or so.  If not,
> > we should more cleanly and clearly block out all non-DFU RAM cases for
> > SPL.  Thanks!
> 
> Do you mean non-RAM DFU cases? Block out everything but RAM?

Based on looking at what's in Kconfig at least, yes, only SPL+DFU RAM is
what's possible now.  So we should make the code more clearly show that.
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] dfu: Limit dfu_mmc to non-SPL case

Hi Faiz,

> Hi,
> 
> On Wednesday 14 February 2018 08:04 PM, Tom Rini wrote:
> > On Wed, Feb 14, 2018 at 07:59:46PM +0530, Faiz Abbas wrote:
> >   
> >> Since 82b9dc63 ("Only build cli_readline.o for CMDLINE on
> >> non-SPL"), cli_simple.c is only being built for non-SPL case.
> >> However, dfu_mmc requires cli_simple.c to build and dfu fails to
> >> build for SPL when CONFIG_HUSH_PARSER is disabled.
> >>
> >> Therefore, limit dfu_mmc to non-SPL case only.
> >>
> >> Signed-off-by: Faiz Abbas 
> >> ---
> >>  drivers/dfu/Makefile | 2 ++
> >>  drivers/dfu/dfu.c| 2 ++
> >>  2 files changed, 4 insertions(+)  
> > 
> > Does DFU for MMC make sense inside of SPL?   
> 
> No.
> 
> If so, you should follow
> > 82b9dc63 and CONFIG_FSL_DDR_INTERACTIVE and bring back in
> > cli_simple.o (and cli_readline.o, if needed) for CONFIG_SPL_DFU_MMC
> > or so.  If not, we should more cleanly and clearly block out all
> > non-DFU RAM cases for SPL.  Thanks!  
> 
> Do you mean non-RAM DFU cases? Block out everything but RAM?

I think yes - only TI is using DFU RAM to download u-boot to configured
DDRAM and execute it from there.

So I agree with Tom, other gargets and DFU parts shall _not_ be enabled
for SPL (as it consumes a lot of space).

> 
> 
> Thanks,
> Faiz


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


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

Re: [U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

Hi Uri,

On Wednesday 14 February 2018 08:56 PM, Uri Mashiach wrote:
> Hi,
> Sorry for the late response.
> 
> On 02/14/2018 04:19 PM, Marek Vasut wrote:
>> On 02/14/2018 03:14 PM, Faiz Abbas wrote:
>>> Hi,
>>>
>>> On Wednesday 14 February 2018 06:53 PM, Marek Vasut wrote:
 On 02/14/2018 12:20 PM, Faiz Abbas wrote:
> Hi,
>
> On Wednesday 14 February 2018 03:46 PM, Marek Vasut wrote:
>> On 02/14/2018 11:10 AM, Faiz Abbas wrote:
>>> board_usb_init()/_cleanup() should be in board files and don't have
>>> a place in the xhci-omap driver. Weak versions for
>>> board_usb_init()/_cleanup() already exist in common/usb.c
>>> (for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).
>>>
>>> Signed-off-by: Faiz Abbas 
>>
>> Reviewed-by: Marek Vasut 
>>
>> I'd like some TBs from the people using those boards.
>
> I have tested this for dra7xx, am43xx and am57xx.

 So why is it marked RFC ?

>>>
>>> Because I was unclear why Uri Mashiach did not do this in 1a9a5f7 ("fix
>>> double weak board_usb_init functions").
>>
>> OK, submit it as a normal patch with my RB.
>>
> 
> As mentioned in 1a9a5f7, the functions omap_xhci_board_usb_init() and
> omap_xhci_board_usb_cleanup() are called for the boards with the
> CONFIG_USB_XHCI_OMAP definition.
> 
> The weak implementation of the functions omap_xhci_board_usb_init()
> executed enable_usb_clocks().
> The weak implementation of the function omap_xhci_board_usb_cleanup()
> executed the function disable_usb_clocks().
> 
> For the boards compulab/cl-som-am57x and compulab/cm_t43:
> * CONFIG_USB_XHCI_OMAP is defined
> * omap_xhci_board_usb_init is not implemented, relying on the weak
> implementation.
> * omap_xhci_board_usb_cleanup is not defined, relying on the weak
> implementation.
> 
> The fix is missing the implementation of board_usb_init and
> board_usb_cleanup in the compulab/cl-som-am57x and compulab/cm_t43.
> The implementation should include the content of the deleted weak
> functions omap_xhci_board_usb_init() and omap_xhci_board_usb_cleanup().
> 

Thanks for clarifying. Shouldn't that be implemented in the board files?
I can add board_usb_init and board_usb_cleanup for those platforms in
v2. Can you help me test this on those platforms?

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

[U-Boot] [PATCH 1/2] rockchip: rk3288: Add TPL_LDSCRIPT

Due to size limitations in SPL by adding falcon mode,
rk3288 support TPL. In order to not overlap SPL_TEXT_BASE
add TPL_TEXT_BASE with u-boot-tpl.lds that intern call
u-boot-spl.lds with proper TEXT_BASE values.

Signed-off-by: Jagan Teki 
---
 arch/arm/mach-rockchip/Kconfig   |  7 +++
 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds | 10 ++
 2 files changed, 17 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 1e5a7bb..d9218da 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -72,6 +72,13 @@ config ROCKCHIP_RK3288
  and video codec support. Peripherals include Gigabit Ethernet,
  USB2 host and OTG, SDIO, I2S, UARTs, SPI, I2C and PWMs.
 
+if ROCKCHIP_RK3288
+
+config TPL_LDSCRIPT
+   default "arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds"
+
+endif
+
 config ROCKCHIP_RK3328
bool "Support Rockchip RK3328"
select ARM64
diff --git a/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds 
b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
new file mode 100644
index 000..c7a6092
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds
@@ -0,0 +1,10 @@
+/*
+ * Copyright (C) 2018 Jagan Teki 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#undef CONFIG_SPL_TEXT_BASE
+#define CONFIG_SPL_TEXT_BASE   CONFIG_TPL_TEXT_BASE
+
+#include "../../cpu/u-boot-spl.lds"
-- 
2.7.4

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

[U-Boot] [PATCH 2/2] rockchip: rk3288: Fix TPL_TEXT_BASE

rockchip boot0 add 4 bytes data (0xeaff) at beginning
of executable(0x800) in order to make generic and compatible
boot0 for all platforms and the resulting executable will be
input to mkimage and the output of mkimage with initial
4 bytes will overwritten by 'spl_hdr'

Since the TPL_TEXT_BASE in rk3288 is 0xff704004 which is improper
align to branch-to-next-instruction-word, so the resulting 4 bytes
are written at ff704020 of executable instead of beginning ff704000

Hexdump with overlaped bytes:
-
000        
010        eaff

So, fix this improper TEXT_BASE which is wrong even before
and update it to 0xff704000 so-that the boot0 will add
4 bytes at beginning.

Disassembly:
---
with 0xff704020 TEXT_BASE:

ff704004 <__image_copy_start>:
b 1f /* if overwritten, entry-address is at the next word */
ff704020:   eaffb   ff704024 <__image_copy_start+0x20>

with 0xff704000 TEXT_BASE:

ff704000 <__image_copy_start>:
b 1f /* if overwritten, entry-address is at the next word */
ff704000:   eaffb   ff704004 <__image_copy_start+0x4>

This patch will also move TPL_TEXT_BASE into kconfig.

Signed-off-by: Jagan Teki 
---
 arch/arm/mach-rockchip/Kconfig | 3 +++
 configs/vyasa-rk3288_defconfig | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index d9218da..0adaed4 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -77,6 +77,9 @@ if ROCKCHIP_RK3288
 config TPL_LDSCRIPT
default "arch/arm/mach-rockchip/rk3288/u-boot-tpl.lds"
 
+config TPL_TEXT_BASE
+   default 0xff704000
+
 endif
 
 config ROCKCHIP_RK3328
diff --git a/configs/vyasa-rk3288_defconfig b/configs/vyasa-rk3288_defconfig
index 1a8a9a8..4c76041 100644
--- a/configs/vyasa-rk3288_defconfig
+++ b/configs/vyasa-rk3288_defconfig
@@ -5,7 +5,6 @@ CONFIG_ARCH_ROCKCHIP=y
 CONFIG_SYS_TEXT_BASE=0x0010
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_ROCKCHIP_RK3288=y
-CONFIG_TPL_TEXT_BASE=0xff704004
 CONFIG_TARGET_VYASA_RK3288=y
 CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3288-vyasa"
-- 
2.7.4

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

[U-Boot] [PATCH v2 0/9] rockchip: rk3288-vyasa: dts fixes/additions

Series add new dts nodes like gmac, usb, io_domains and fixed existing
regulator, pmic stuff as per schematic. 

Changes for v2:
- Collect Acked-by and Reviewed-by tags from Philipp
- Add eMMC boot support
- Add missing commit message
- Remove RK_GPIO8 macro to sync with Linux

Jagan Teki (9):
  ARM: dts: rockchip: Sync rk3288-vyasa dts from Linux
  ARM: dts: rockchip: rk3288-vyasa: Remove vdd_log from rk808, DCDC_REG1
  ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC
  ARM: dts: rockchip: Add regulators for rk3288-vyasa
  ARM: dts: rockchip: Add gmac support for rk3288-vyasa board
  rockchip: rk3288-vyasa: defconfig: Enable gmac support
  ARM: dts: rockchip: Add usb host for rk3288-vyasa
  ARM: dts: rockchip: Add usb otg for rk3288-vyasa
  rk3288: vyasa: Add eMMC boot support

 arch/arm/dts/rk3288-vyasa-u-boot.dtsi |  33 
 arch/arm/dts/rk3288-vyasa.dts | 303 +++---
 board/amarula/vyasa-rk3288/MAINTAINERS|   2 +
 board/amarula/vyasa-rk3288/vyasa-rk3288.c |   7 +
 configs/vyasa-rk3288_defconfig|   3 +
 5 files changed, 277 insertions(+), 71 deletions(-)
 create mode 100644 arch/arm/dts/rk3288-vyasa-u-boot.dtsi

-- 
2.7.4

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

[U-Boot] [PATCH v2 4/9] ARM: dts: rockchip: Add regulators for rk3288-vyasa

Add supporting regulators for rk3288-vyasa board, dc12_vbat is
parent regulatorand followed regulators as are child regulators.
regulator naming conversion followed as per schematic for better
readability and easy for identification.

Signed-off-by: Jagan Teki 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---
 arch/arm/dts/rk3288-vyasa.dts | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index aff3cd4..f56e10c 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -56,13 +56,53 @@
device_type = "memory";
};
 
+   dc12_vbat: dc12-vbat {
+   compatible = "regulator-fixed";
+   regulator-name = "dc12_vbat";
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   vboot_3v3: vboot-3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vboot_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <&dc12_vbat>;
+   };
+
vcc_sys: vsys-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
+   regulator-min-microvolt = <370>;
+   regulator-max-microvolt = <370>;
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <&dc12_vbat>;
+   };
+
+   vboot_5v: vboot-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "vboot_sv";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-always-on;
regulator-boot-on;
+   vin-supply = <&dc12_vbat>;
+   };
+
+   v3g_3v3: v3g-3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "v3g_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <&dc12_vbat>;
};
 };
 
-- 
2.7.4

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

[U-Boot] [PATCH v2 1/9] ARM: dts: rockchip: Sync rk3288-vyasa dts from Linux

Sync rk3288-vyasa board dts from Linux for proper updates and maintenance
- rk3288-vyasa.dts: Similar to Linux dts
- rk3288-vyasa-u-boot.dtsi: u-boot dts changes

Also updated MAINTAINERS for these dts files.

Signed-off-by: Jagan Teki 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---
 arch/arm/dts/rk3288-vyasa-u-boot.dtsi  |  29 +++
 arch/arm/dts/rk3288-vyasa.dts  | 134 ++---
 board/amarula/vyasa-rk3288/MAINTAINERS |   2 +
 3 files changed, 105 insertions(+), 60 deletions(-)
 create mode 100644 arch/arm/dts/rk3288-vyasa-u-boot.dtsi

diff --git a/arch/arm/dts/rk3288-vyasa-u-boot.dtsi 
b/arch/arm/dts/rk3288-vyasa-u-boot.dtsi
new file mode 100644
index 000..b3a56e9
--- /dev/null
+++ b/arch/arm/dts/rk3288-vyasa-u-boot.dtsi
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+&dmc {
+   rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
+   0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
+   0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
+   0x1 0x7 0x7 0x4 0xc 0x43 0x100 0x0
+   0x5 0x0>;
+   rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
+   0xa60 0x40 0x10 0x0>;
+   /* Add a dummy value to cause of-platdata think this is bytes */
+   rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
+};
+
+&sdmmc {
+   u-boot,dm-pre-reloc;
+};
+
+&uart2 {
+   u-boot,dm-pre-reloc;
+};
+
+&pinctrl {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index 93a9c5e..932311c 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -52,8 +52,8 @@
};
 
memory {
+   reg = <0x0 0x0 0x0 0x8000>;
device_type = "memory";
-   reg = <0 0x8000>;
};
 
vcc_sd: sdmmc-regulator {
@@ -78,22 +78,20 @@
};
 };
 
-&dmc {
-   rockchip,pctl-timing = <0x29a 0xc8 0x1f8 0x42 0x4e 0x4 0xea 0xa
-   0x5 0x0 0xa 0x7 0x19 0x24 0xa 0x7
-   0x5 0xa 0x5 0x200 0x5 0x10 0x40 0x0
-   0x1 0x7 0x7 0x4 0xc 0x43 0x100 0x0
-   0x5 0x0>;
-   rockchip,phy-timing = <0x48f9aab4 0xea0910 0x1002c200
-   0xa60 0x40 0x10 0x0>;
-   /* Add a dummy value to cause of-platdata think this is bytes */
-   rockchip,sdram-params = <0x30B25564 0x627 3 66600 3 9 1>;
-};
-
 &cpu0 {
cpu0-supply = <&vdd_cpu>;
 };
 
+&gpu {
+   mali-supply = <&vdd_gpu>;
+   status = "okay";
+};
+
+&hdmi {
+   ddc-i2c-bus = <&i2c2>;
+   status = "okay";
+};
+
 &i2c0 {
clock-frequency = <40>;
status = "okay";
@@ -103,12 +101,12 @@
reg = <0x1b>;
interrupt-parent = <&gpio0>;
interrupts = ;
+   #clock-cells = <1>;
+   clock-output-names = "xin32k", "rk808-clkout2";
pinctrl-names = "default";
pinctrl-0 = <&pmic_int &global_pwroff>;
-   wakeup-source;
rockchip,system-power-controller;
-   #clock-cells = <1>;
-   clock-output-names = "xin32k", "rk808-clkout2";
+   wakeup-source;
 
vcc1-supply = <&vcc_sys>;
vcc2-supply = <&vcc_sys>;
@@ -124,22 +122,22 @@
 
regulators {
vdd_cpu: vdd_log: DCDC_REG1 {
-   regulator-always-on;
-   regulator-boot-on;
+   regulator-name = "vdd_log";
regulator-min-microvolt = <75>;
regulator-max-microvolt = <135>;
-   regulator-name = "vdd_log";
+   regulator-always-on;
+   regulator-boot-on;
regulator-state-mem {
regulator-off-in-suspend;
};
};
 
vdd_gpu: DCDC_REG2 {
-   regulator-always-on;
-   regulator-boot-on;
+   regulator-name = "vdd_gpu";
regulator-min-microvolt = <85>;
regulator-max-microvolt = <125>;
-   regulator-name = "vdd_gpu";
+   regulator-always-on;
+   regulator-boot-on;
regulator-state-mem {
regulator-on-in-suspend;
regulator-suspend-microvolt = <100>;
@@ -147,20 +145,20 @@
};
 
vcc_ddr: DCDC_REG3 {
+   regulator-name = "vcc_ddr";

[U-Boot] [PATCH v2 3/9] ARM: dts: rockchip: rk3288-vyasa: Use vmmc-supply from PMIC

rk808, SWITCH_REG1 has configured for sdmmc regulator as vcc_sd,
so use the same by renaming vcc33_sd to vcc_sd(as per schematic)
and drop explicit regulator definition from root.

Signed-off-by: Jagan Teki 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---
 arch/arm/dts/rk3288-vyasa.dts | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index 6a74eb4..aff3cd4 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -56,18 +56,6 @@
device_type = "memory";
};
 
-   vcc_sd: sdmmc-regulator {
-   compatible = "regulator-fixed";
-   gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&sdmmc_pwr>;
-   regulator-name = "vcc_sd";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   startup-delay-us = <10>;
-   vin-supply = <&vcc_io>;
-   };
-
vcc_sys: vsys-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
@@ -260,8 +248,8 @@
};
};
 
-   vcc33_sd: SWITCH_REG1 {
-   regulator-name = "vcc33_sd";
+   vcc_sd: SWITCH_REG1 {
+   regulator-name = "vcc_sd";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-always-on;
@@ -332,10 +320,4 @@
rockchip,pins = ;
};
};
-
-   sdmmc {
-   sdmmc_pwr: sdmmc-pwr {
-   rockchip,pins = <7 11 RK_FUNC_GPIO &pcfg_pull_none>;
-   };
-   };
 };
-- 
2.7.4

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

[U-Boot] [PATCH v2 2/9] ARM: dts: rockchip: rk3288-vyasa: Remove vdd_log from rk808, DCDC_REG1

vdd_log, never used on DCDC_REG1 of rk808 from latest schematic so
remove the same and update the regulator-name as 'vdd_arm' to sync
with existing rk3288 board dts files.

Signed-off-by: Jagan Teki 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---
 arch/arm/dts/rk3288-vyasa.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index 932311c..6a74eb4 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -121,8 +121,8 @@
vcc12-supply = <&vcc_io>;
 
regulators {
-   vdd_cpu: vdd_log: DCDC_REG1 {
-   regulator-name = "vdd_log";
+   vdd_cpu: DCDC_REG1 {
+   regulator-name = "vdd_arm";
regulator-min-microvolt = <75>;
regulator-max-microvolt = <135>;
regulator-always-on;
-- 
2.7.4

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

[U-Boot] [PATCH v2 6/9] rockchip: rk3288-vyasa: defconfig: Enable gmac support

Enable gmac support for rk3288-vyasa board.

Signed-off-by: Jagan Teki 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---
 configs/vyasa-rk3288_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/vyasa-rk3288_defconfig b/configs/vyasa-rk3288_defconfig
index 4c76041..24a955a 100644
--- a/configs/vyasa-rk3288_defconfig
+++ b/configs/vyasa-rk3288_defconfig
@@ -45,6 +45,9 @@ CONFIG_LED=y
 CONFIG_LED_GPIO=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 # CONFIG_SPL_PINCTRL_FULL is not set
-- 
2.7.4

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

[U-Boot] [PATCH v2 5/9] ARM: dts: rockchip: Add gmac support for rk3288-vyasa board

Sync gmac dts node from Linux.

Signed-off-by: Jagan Teki 
Acked-by: Philipp Tomsich 
Signed-off-by: Jagan Teki 
---
 arch/arm/dts/rk3288-vyasa.dts | 41 +
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index f56e10c..47fdd91 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -104,12 +104,35 @@
regulator-boot-on;
vin-supply = <&dc12_vbat>;
};
+
+   ext_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <12500>;
+   clock-output-names = "ext_gmac";
+   };
 };
 
 &cpu0 {
cpu0-supply = <&vdd_cpu>;
 };
 
+&gmac {
+   assigned-clocks = <&cru SCLK_MAC>;
+   assigned-clock-parents = <&ext_gmac>;
+   clock_in_out = "input";
+   pinctrl-names = "default";
+   pinctrl-0 = <&rgmii_pins>, <&phy_rst>, <&phy_pmeb>, <&phy_int>;
+   phy-supply = <&vcc_lan>;
+   phy-mode = "rgmii";
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 100>;
+   snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
+   tx_delay = <0x30>;
+   rx_delay = <0x10>;
+   status = "okay";
+};
+
 &gpu {
mali-supply = <&vdd_gpu>;
status = "okay";
@@ -355,6 +378,24 @@
 };
 
 &pinctrl {
+   pcfg_output_high: pcfg-output-high {
+   output-high;
+   };
+
+   gmac {
+   phy_int: phy-int {
+   rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+   };
+
+   phy_pmeb: phy-pmeb {
+   rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
+   };
+
+   phy_rst: phy-rst {
+   rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO 
&pcfg_output_high>;
+   };
+   };
+
pmic {
pmic_int: pmic-int {
rockchip,pins = ;
-- 
2.7.4

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

[U-Boot] [PATCH v2 8/9] ARM: dts: rockchip: Add usb otg for rk3288-vyasa

Add usb otg support for rk3288-vyasa, board support usb1 otg
power through otg_vbus_drv and naming conversion followed
as per schematic.

Signed-off-by: Jagan Teki 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---
 arch/arm/dts/rk3288-vyasa.dts | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index fe680e2..70c433f 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -115,6 +115,20 @@
vin-supply = <&vcc_io>;
};
 
+   vusb1_5v: vusb1-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "vusb1_5v";
+   enable-active-high;
+   gpio = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>; /* OTG_VBUS_DRV */
+   pinctrl-names = "default";
+   pinctrl-0 = <&otg_vbus_drv>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <&vsus_5v>;
+   };
+
vusb2_5v: vusb2-5v {
compatible = "regulator-fixed";
regulator-name = "vusb2_5v";
@@ -395,6 +409,10 @@
status = "okay";
 };
 
+&usb_otg {
+   status = "okay";
+};
+
 &vopb {
status = "okay";
 };
@@ -449,4 +467,11 @@
rockchip,pins = <8 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
+
+   usb_otg {
+   otg_vbus_drv: otg-vbus-drv {
+   rockchip,pins = ;
+
+   };
+   };
 };
-- 
2.7.4

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

[U-Boot] [PATCH v2 7/9] ARM: dts: rockchip: Add usb host for rk3288-vyasa

Add usb host support for rk3288-vyasa, board support hub power
through phy_pwr_en and usb2 host power through usb2_pwr_en and
naming conversion followed as per schematic.

Signed-off-by: Jagan Teki 
Acked-by: Philipp Tomsich 
Reviewed-by: Philipp Tomsich 
---
 arch/arm/dts/rk3288-vyasa.dts | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index 47fdd91..fe680e2 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -105,6 +105,30 @@
vin-supply = <&dc12_vbat>;
};
 
+   vsus_5v: vsus-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "vsus_5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <&vcc_io>;
+   };
+
+   vusb2_5v: vusb2-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "vusb2_5v";
+   enable-active-high;
+   gpio = <&gpio8 RK_PB1 GPIO_ACTIVE_HIGH>; /* USB2_PWR_EN */
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb2_pwr_en>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <&vsus_5v>;
+   };
+
ext_gmac: external-gmac-clock {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -357,6 +381,20 @@
status = "okay";
 };
 
+&usbphy {
+   status = "okay";
+};
+
+&usb_host0_ehci {
+   status = "okay";
+};
+
+&usb_host1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&phy_pwr_en>;
+   status = "okay";
+};
+
 &vopb {
status = "okay";
 };
@@ -401,4 +439,14 @@
rockchip,pins = ;
};
};
+
+   usb_host {
+   phy_pwr_en: phy-pwr-en {
+   rockchip,pins = ;
+   };
+
+   usb2_pwr_en: usb2-pwr-en {
+   rockchip,pins = <8 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
+   };
 };
-- 
2.7.4

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

[U-Boot] [PATCH v2 9/9] rk3288: vyasa: Add eMMC boot support

RK3288 Vyasa has eMMC boot support, with JP4 open.

Signed-off-by: Jagan Teki 
---
Note:
Linux patch for this support is in ML.

 arch/arm/dts/rk3288-vyasa-u-boot.dtsi |  4 
 arch/arm/dts/rk3288-vyasa.dts | 11 +++
 board/amarula/vyasa-rk3288/vyasa-rk3288.c |  7 +++
 3 files changed, 22 insertions(+)

diff --git a/arch/arm/dts/rk3288-vyasa-u-boot.dtsi 
b/arch/arm/dts/rk3288-vyasa-u-boot.dtsi
index b3a56e9..6017ca2 100644
--- a/arch/arm/dts/rk3288-vyasa-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-vyasa-u-boot.dtsi
@@ -20,6 +20,10 @@
u-boot,dm-pre-reloc;
 };
 
+&emmc {
+   u-boot,dm-pre-reloc;
+};
+
 &uart2 {
u-boot,dm-pre-reloc;
 };
diff --git a/arch/arm/dts/rk3288-vyasa.dts b/arch/arm/dts/rk3288-vyasa.dts
index 70c433f..850aa25 100644
--- a/arch/arm/dts/rk3288-vyasa.dts
+++ b/arch/arm/dts/rk3288-vyasa.dts
@@ -155,6 +155,17 @@
cpu0-supply = <&vdd_cpu>;
 };
 
+&emmc {
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   disable-wp;
+   non-removable;
+   pinctrl-names = "default";
+   pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;
+   vmmc-supply = <&vcc_io>;
+   status = "okay";
+};
+
 &gmac {
assigned-clocks = <&cru SCLK_MAC>;
assigned-clock-parents = <&ext_gmac>;
diff --git a/board/amarula/vyasa-rk3288/vyasa-rk3288.c 
b/board/amarula/vyasa-rk3288/vyasa-rk3288.c
index 7985671..82f8c4e 100644
--- a/board/amarula/vyasa-rk3288/vyasa-rk3288.c
+++ b/board/amarula/vyasa-rk3288/vyasa-rk3288.c
@@ -9,6 +9,13 @@
 #ifndef CONFIG_TPL_BUILD
 #include 
 
+void board_boot_order(u32 *spl_boot_list)
+{
+   /* eMMC prior to sdcard. */
+   spl_boot_list[0] = BOOT_DEVICE_MMC2;
+   spl_boot_list[1] = BOOT_DEVICE_MMC1;
+}
+
 int spl_start_uboot(void)
 {
 /* break into full u-boot on 'c' */
-- 
2.7.4

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

Re: [U-Boot] [PATCH 8/8] Migrate generic bootcount to Kconfig

2018-02-14 Thread Alex Kiernan

On Wed, Feb 14, 2018 at 8:53 AM, Lukasz Majewski  wrote:
>> >> Whatever we do, I think CONFIG_SYS_BOOTCOUNT_ADDR wants splitting
>> >> into at least two:
>> >>
>> >> - I2C - an offset from an I2C base for the bootcounter
>> >   - RAM/SoC memory - location of special register to store
>> > bootcounter
>> >> - Others - an actual address used for storing the bootcounter
>> >
>> >
>> >
>> >>
>> >> I'm struggling to see why EXT is the way it is - AFAICS the
>> >> location it uses to access/return the bootcounter is basically
>> >> local to the two functions in bootcount_ext and could just be a
>> >> local variable.
>> >
>> > Maybe we can replace it with local, static variable then?
>> >
>> >
>> > As said above - I would remove the (wrongly?) used BOOTCOUNT_ADDR in
>> > Kconfig.
>> >
>>
>> Just removing SYS_BOOTCOUNT_ADDR from Kconfig and putting the default
>> back into bootcount_ext seems like the simplest correct change. I'll
>> add that onto the series and throw it at Travis.
>
> Great. I'm looking forward for next verison of the code - as I do have
> some code to be put on top of it.
>

So the super-trivial approach doesn't work, because
CONFIG_SYS_BOOTCOUNT_ADDR isn't in the whitelist anymore
(7af2e3648f3f6d726f6476745c2eec5de709a702) and I think the only reason
it was getting through before is because scripts/check-config.sh
doesn't parse conditionals in Kconfig so thought it was allowed :(

I expect reintroducing CONFIG_SYS_BOOTCOUNT_ADDR to
config_whitelist.txt would "fix" the problem, but that's not going to
make it in.

Which I think means I have to do the work to migrate it out of CONFIG_
land properly.

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

Re: [U-Boot] [RFC] usb: host: xhci-omap: Remove redundant board_usb_init and board_usb_cleanup functions

2018-02-14 Thread Uri Mashiach


Hi Faiz,

On 02/14/2018 05:47 PM, Faiz Abbas wrote:

Hi Uri,

On Wednesday 14 February 2018 08:56 PM, Uri Mashiach wrote:

Hi,
Sorry for the late response.

On 02/14/2018 04:19 PM, Marek Vasut wrote:

On 02/14/2018 03:14 PM, Faiz Abbas wrote:

Hi,

On Wednesday 14 February 2018 06:53 PM, Marek Vasut wrote:

On 02/14/2018 12:20 PM, Faiz Abbas wrote:

Hi,

On Wednesday 14 February 2018 03:46 PM, Marek Vasut wrote:

On 02/14/2018 11:10 AM, Faiz Abbas wrote:

board_usb_init()/_cleanup() should be in board files and don't have
a place in the xhci-omap driver. Weak versions for
board_usb_init()/_cleanup() already exist in common/usb.c
(for host mode) and drivers/usb/gadget/g_dnl.c (for gadget mode).

Signed-off-by: Faiz Abbas 


Reviewed-by: Marek Vasut 

I'd like some TBs from the people using those boards.


I have tested this for dra7xx, am43xx and am57xx.


So why is it marked RFC ?



Because I was unclear why Uri Mashiach did not do this in 1a9a5f7 ("fix
double weak board_usb_init functions").


OK, submit it as a normal patch with my RB.



As mentioned in 1a9a5f7, the functions omap_xhci_board_usb_init() and
omap_xhci_board_usb_cleanup() are called for the boards with the
CONFIG_USB_XHCI_OMAP definition.

The weak implementation of the functions omap_xhci_board_usb_init()
executed enable_usb_clocks().
The weak implementation of the function omap_xhci_board_usb_cleanup()
executed the function disable_usb_clocks().

For the boards compulab/cl-som-am57x and compulab/cm_t43:
* CONFIG_USB_XHCI_OMAP is defined
* omap_xhci_board_usb_init is not implemented, relying on the weak
implementation.
* omap_xhci_board_usb_cleanup is not defined, relying on the weak
implementation.

The fix is missing the implementation of board_usb_init and
board_usb_cleanup in the compulab/cl-som-am57x and compulab/cm_t43.
The implementation should include the content of the deleted weak
functions omap_xhci_board_usb_init() and omap_xhci_board_usb_cleanup().



Thanks for clarifying. Shouldn't that be implemented in the board files?


Yes


I can add board_usb_init and board_usb_cleanup for those platforms in
v2. Can you help me test this on those platforms?


Yes



Thanks,
Faiz



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

Re: [U-Boot] [U-Boot,1/8] spi: Migrate CONFIG_SH_SPI to Kconfig

On Wed, Feb 07, 2018 at 02:42:16AM +0200, Tuomas Tynkkynen wrote:

> Signed-off-by: Tuomas Tynkkynen 

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,2/8] spi: Migrate CONFIG_SH_QSPI to Kconfig

On Wed, Feb 07, 2018 at 02:42:17AM +0200, Tuomas Tynkkynen wrote:

> Signed-off-by: Tuomas Tynkkynen 

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,4/8] spi: Migrate CONFIG_MXC_SPI to Kconfig

On Wed, Feb 07, 2018 at 02:42:19AM +0200, Tuomas Tynkkynen wrote:

> Signed-off-by: Tuomas Tynkkynen 

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] ARM: image: indent with tab instead of 4 spaces

On Tue, Feb 13, 2018 at 11:32:15AM +0900, Masahiro Yamada wrote:

> Commit 6808ef9ac2a6 ("move booti_setup to arch/arm/lig/image.c")
> not only moved the code, but also replaced a tab with 4 spaces
> to break the Linux coding style.
> 
> Restore tab indentation.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Bin Chen 

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, 1/3] .travis.yml: download xtensa prebuilt toolchain

On Wed, Feb 07, 2018 at 03:30:01PM -0800, Max Filippov wrote:

> xtensa toolchains are core-specific, so give full toolchain name and
> download corresponding prebuilt toolchain from the github release.
> 
> Signed-off-by: Max Filippov 

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,3/8] spi: Migrate CONFIG_MXS_SPI to Kconfig

On Wed, Feb 07, 2018 at 02:42:18AM +0200, Tuomas Tynkkynen wrote:

> Signed-off-by: Tuomas Tynkkynen 

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,8/8] spi: Migrate CONFIG_CF_SPI to Kconfig

On Wed, Feb 07, 2018 at 02:42:23AM +0200, Tuomas Tynkkynen wrote:

> Signed-off-by: Tuomas Tynkkynen 

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, 1/1, for, v2018.03] efi_driver: comment struct efi_driver_ops

On Mon, Feb 12, 2018 at 12:55:28PM +0100, Heinrich Schuchardt wrote:

> Provide description for struct efi_driver_ops.
> 
> 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] SystemACE: Remove

On Mon, Feb 12, 2018 at 09:51:33AM -0500, Tom Rini wrote:

> This driver is no longer used on any supported platform in U-Boot and
> there is no interest in maintaining it further from people that have
> used it historically.
> 
> Cc: Simon Glass 
> Cc: Michal Simek 
> c: Alexey Brodkin 
> Signed-off-by: Tom Rini 
> Acked-by: Michal Simek 

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, 5/8] spi: Migrate CONFIG_MPC8XXX_SPI to Kconfig

On Wed, Feb 07, 2018 at 02:42:20AM +0200, Tuomas Tynkkynen wrote:

> Signed-off-by: Tuomas Tynkkynen 

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, 7/8] spi: Migrate CONFIG_KIRKWOOD_SPI to Kconfig

On Wed, Feb 07, 2018 at 02:42:22AM +0200, Tuomas Tynkkynen wrote:

> Signed-off-by: Tuomas Tynkkynen 

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,1/1] dm: core: fix typo in comment (device.h)

On Mon, Feb 12, 2018 at 12:38:36PM +0100, Heinrich Schuchardt wrote:

> %s/Indentiies/Identifies/g
> 
> 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] arm: update Kconfig help for ENABLE_ARM_SOC_BOOT0_HOOK

On Tue, Feb 13, 2018 at 01:18:00PM +0100, Simon Goldschmidt wrote:

> When this config is enabled,  is included,
> but the Kconfig help says this should be a define
> (ARM_SOC_BOOT0_HOOK).
> 
> The code for this in arch/arm/lib/vectors.s was changed on
> 01/02/2017 with commit ce62e57fc571 ("ARM: boot0 hook: remove macro,
> include whole header file").
> 
> Signed-off-by: Simon Goldschmidt 

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,2/3] xtfpga: enable hush parser

On Wed, Feb 07, 2018 at 03:30:02PM -0800, Max Filippov wrote:

> Remove CONFIG_BOOT_RETRY_TIME as it doesn't do much good and enable
> CONFIG_HUSH_PARSER in xtfpga_defconfig.
> 
> Signed-off-by: Max Filippov 

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, 6/8] spi: Migrate CONFIG_LPC32XX_SSP to Kconfig

On Wed, Feb 07, 2018 at 02:42:21AM +0200, Tuomas Tynkkynen wrote:

> Signed-off-by: Tuomas Tynkkynen 

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, 3/3] .travis.yml: test xtensa xtfpga board in QEMU

On Wed, Feb 07, 2018 at 03:30:03PM -0800, Max Filippov wrote:

> This allows running tests on emulated KC705 board with DC233C xtensa
> core. It expects to find conf.xtfpga_qemu in the uboot-test-hooks.
> 
> Signed-off-by: Max Filippov 

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, 2/2] fix spelling of 'functions' in 2 places (was 'funtcions')

On Tue, Feb 13, 2018 at 01:18:27PM +0100, Simon Goldschmidt wrote:

> Signed-off-by: Simon Goldschmidt 

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] cmd: booti: fix invalid image address in debug message

On Tue, Feb 13, 2018 at 12:10:02PM +0900, Masahiro Yamada wrote:

> With commit 6808ef9ac2a6 ("move booti_setup to arch/arm/lig/image.c"),
> images->ep has not been set at this point.
> 
> Fixes: 6808ef9ac2a6 ("move booti_setup to arch/arm/lig/image.c")
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Bin Chen 

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] dm: pcie: designware: add correct ATU handling

2018-02-14 Thread igall

From: Igal Liberman 

Currently, ATU (address translation unit) implementation doesn't
support translate addresses > 32 bits.

This patch allows to configure ATU correctly for different
memory accesses (memory, configuration and IO).
The same approach is used in Linux Kernel.

Signed-off-by: Igal Liberman 
---
 drivers/pci/pcie_dw_mvebu.c | 91 +
 1 file changed, 58 insertions(+), 33 deletions(-)

diff --git a/drivers/pci/pcie_dw_mvebu.c b/drivers/pci/pcie_dw_mvebu.c
index a198855..a0032b7 100644
--- a/drivers/pci/pcie_dw_mvebu.c
+++ b/drivers/pci/pcie_dw_mvebu.c
@@ -111,6 +111,10 @@ struct pcie_dw_mvebu {
void *cfg_base;
fdt_size_t cfg_size;
int first_busno;
+
+   /* IO and MEM PCI regions */
+   struct pci_region io;
+   struct pci_region mem;
 };
 
 static int pcie_dw_get_link_speed(const void *regs_base)
@@ -126,6 +130,34 @@ static int pcie_dw_get_link_width(const void *regs_base)
 }
 
 /**
+ * pcie_dw_prog_outbound_atu() - Configure ATU for outbound accesses
+ *
+ * @pcie: Pointer to the PCI controller state
+ * @index: ATU region index
+ * @type: ATU accsess type
+ * @cpu_addr: the physical address for the translation entry
+ * @pci_addr: the pcie bus address for the translation entry
+ * @size: the size of the translation entry
+ */
+static void pcie_dw_prog_outbound_atu(struct pcie_dw_mvebu *pcie, int index,
+ int type, u64 cpu_addr, u64 pci_addr,
+ u32 size)
+{
+   writel(PCIE_ATU_REGION_OUTBOUND | index,
+  pcie->ctrl_base + PCIE_ATU_VIEWPORT);
+   writel(lower_32_bits(cpu_addr), pcie->ctrl_base + PCIE_ATU_LOWER_BASE);
+   writel(upper_32_bits(cpu_addr), pcie->ctrl_base + PCIE_ATU_UPPER_BASE);
+   writel(lower_32_bits(cpu_addr + size - 1),
+  pcie->ctrl_base + PCIE_ATU_LIMIT);
+   writel(lower_32_bits(pci_addr),
+  pcie->ctrl_base + PCIE_ATU_LOWER_TARGET);
+   writel(upper_32_bits(pci_addr),
+  pcie->ctrl_base + PCIE_ATU_UPPER_TARGET);
+   writel(type, pcie->ctrl_base + PCIE_ATU_CR1);
+   writel(PCIE_ATU_ENABLE, pcie->ctrl_base + PCIE_ATU_CR2);
+}
+
+/**
  * set_cfg_address() - Configure the PCIe controller config space access
  *
  * @pcie: Pointer to the PCI controller state
@@ -143,27 +175,29 @@ static uintptr_t set_cfg_address(struct pcie_dw_mvebu 
*pcie,
 pci_dev_t d, uint where)
 {
uintptr_t va_address;
+   u32 atu_type;
 
/*
 * Region #0 is used for Outbound CFG space access.
 * Direction = Outbound
 * Region Index = 0
 */
-   writel(0, pcie->ctrl_base + PCIE_ATU_VIEWPORT);
 
if (PCI_BUS(d) == (pcie->first_busno + 1))
/* For local bus, change TLP Type field to 4. */
-   writel(PCIE_ATU_TYPE_CFG0, pcie->ctrl_base + PCIE_ATU_CR1);
+   atu_type = PCIE_ATU_TYPE_CFG0;
else
/* Otherwise, change TLP Type field to 5. */
-   writel(PCIE_ATU_TYPE_CFG1, pcie->ctrl_base + PCIE_ATU_CR1);
+   atu_type = PCIE_ATU_TYPE_CFG1;
 
if (PCI_BUS(d) == pcie->first_busno) {
/* Accessing root port configuration space. */
va_address = (uintptr_t)pcie->ctrl_base;
} else {
d = PCI_MASK_BUS(d) | (PCI_BUS(d) - pcie->first_busno);
-   writel(d << 8, pcie->ctrl_base + PCIE_ATU_LOWER_TARGET);
+   pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,
+ atu_type, (u64)pcie->cfg_base,
+ d << 8, pcie->cfg_size);
va_address = (uintptr_t)pcie->cfg_base;
}
 
@@ -231,6 +265,10 @@ static int pcie_dw_mvebu_read_config(struct udevice *bus, 
pci_dev_t bdf,
debug("(addr,val)=(0x%04x, 0x%08lx)\n", offset, value);
*valuep = pci_conv_32_to_size(value, offset, size);
 
+   pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,
+ PCIE_ATU_TYPE_IO, pcie->io.phys_start,
+ pcie->io.bus_start, pcie->io.size);
+
return 0;
 }
 
@@ -272,6 +310,10 @@ static int pcie_dw_mvebu_write_config(struct udevice *bus, 
pci_dev_t bdf,
value = pci_conv_size_to_32(old, value, offset, size);
writel(value, va_address);
 
+   pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,
+ PCIE_ATU_TYPE_IO, pcie->io.phys_start,
+ pcie->io.bus_start, pcie->io.size);
+
return 0;
 }
 
@@ -388,34 +430,6 @@ static int pcie_dw_mvebu_pcie_link_up(const void 
*regs_base, u32 cap_speed)
 }
 
 /**
- * pcie_dw_regions_setup() - iATU region setup
- *
- * @pcie: Pointer to the PCI controller state
- *
- * Configure the iATU regions in the PCIe controller for outbound access.
- */
-static void pcie_dw_regi

[U-Boot] [PATCH 3/3] defconfig: k2x_hs_evm: Re-enable TI_SECURE_DEVICE in HS K2x parts

2018-02-14 Thread Andrew F. Davis

These got removed in config re-syncs due to a Kconfig bug. Add these
back here.

Signed-off-by: Andrew F. Davis 
---
 configs/k2e_hs_evm_defconfig  | 2 ++
 configs/k2g_hs_evm_defconfig  | 2 ++
 configs/k2hk_hs_evm_defconfig | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig
index 266fb8abdc..44ed07e7f9 100644
--- a/configs/k2e_hs_evm_defconfig
+++ b/configs/k2e_hs_evm_defconfig
@@ -1,9 +1,11 @@
 CONFIG_ARM=y
 CONFIG_ARCH_KEYSTONE=y
+CONFIG_TI_SECURE_DEVICE=y
 CONFIG_SYS_TEXT_BASE=0xC60
 CONFIG_TI_COMMON_CMD_OPTIONS=y
 CONFIG_TARGET_K2E_EVM=y
 CONFIG_DEFAULT_DEVICE_TREE="keystone-k2e-evm"
+CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
diff --git a/configs/k2g_hs_evm_defconfig b/configs/k2g_hs_evm_defconfig
index 5acc04be6f..ea1a61efa5 100644
--- a/configs/k2g_hs_evm_defconfig
+++ b/configs/k2g_hs_evm_defconfig
@@ -1,9 +1,11 @@
 CONFIG_ARM=y
 CONFIG_ARCH_KEYSTONE=y
+CONFIG_TI_SECURE_DEVICE=y
 CONFIG_SYS_TEXT_BASE=0xC60
 CONFIG_TI_COMMON_CMD_OPTIONS=y
 CONFIG_TARGET_K2G_EVM=y
 CONFIG_DEFAULT_DEVICE_TREE="keystone-k2g-evm"
+CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
diff --git a/configs/k2hk_hs_evm_defconfig b/configs/k2hk_hs_evm_defconfig
index 931a20c8e7..0a39da55f5 100644
--- a/configs/k2hk_hs_evm_defconfig
+++ b/configs/k2hk_hs_evm_defconfig
@@ -1,9 +1,11 @@
 CONFIG_ARM=y
 CONFIG_ARCH_KEYSTONE=y
+CONFIG_TI_SECURE_DEVICE=y
 CONFIG_SYS_TEXT_BASE=0xC60
 CONFIG_TI_COMMON_CMD_OPTIONS=y
 CONFIG_TARGET_K2HK_EVM=y
 CONFIG_DEFAULT_DEVICE_TREE="keystone-k2hk-evm"
+CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.16.1

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

[U-Boot] [PATCH 1/3] ARM: Kconfig: Move TI_SECURE_DEVICE to a common area

2018-02-14 Thread Andrew F. Davis

TI_SECURE_DEVICE is used by both OMAP2+ and Keystone2 family devices,
and so when ARCH_OMAP2PLUS was used to gate off the OMAP2+ Kconfig
Keystone2 family devices lost this config option.

Move this option out of mach-omap2 Kconfig to a spot accessible by both
families. We picked arch/arm/Kconfig over the TI specific board/ti/
location as this option is not specific to our boards but rather our
architecture.

Plus at some point this option can be changed to just
SECURE_DEVICE, as having secure parts is not exclusive to TI and
so other vendors can interpret this option as needed by their device
configurations.

Fixes: a93fbf4a7892 ("ARM: omap2+: rename config to ARCH_OMAP2PLUS and 
consolidate Kconfig")
Signed-off-by: Andrew F. Davis 
---
 arch/arm/Kconfig| 10 ++
 arch/arm/mach-omap2/Kconfig | 10 --
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7b618d6881..466c7502d5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1189,6 +1189,16 @@ config ARCH_ASPEED
 
 endchoice
 
+config TI_SECURE_DEVICE
+   bool "HS Device Type Support"
+   depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS
+   help
+ If a high secure (HS) device type is being used, this config
+ must be set. This option impacts various aspects of the
+ build system (to create signed boot images that can be
+ authenticated) and the code. See the doc/README.ti-secure
+ file for further details.
+
 source "arch/arm/mach-aspeed/Kconfig"
 
 source "arch/arm/mach-at91/Kconfig"
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index abd1aa7fe1..62c25c4044 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -133,16 +133,6 @@ config SYS_MPUCLK
help
  Defines the MPU clock speed (in MHz).
 
-config TI_SECURE_DEVICE
-   bool "HS Device Type Support"
-   depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE
-   help
- If a high secure (HS) device type is being used, this config
- must be set. This option impacts various aspects of the
- build system (to create signed boot images that can be
- authenticated) and the code. See the doc/README.ti-secure
- file for further details.
-
 config TI_SECURE_EMIF_REGION_START
hex "Reserved EMIF region start address"
depends on TI_SECURE_DEVICE
-- 
2.16.1

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

[U-Boot] [PATCH 2/3] env: Fix missed getenv_ulong to env_get_ulong conversion

2018-02-14 Thread Andrew F. Davis

This seems to have been missed, possibly due to the inability to
enable TI_SECURE_DEVICE on Keystone2 devices previously.

Fixes: bfebc8c965e4 ("env: Rename getenv_hex(), getenv_yesno(), getenv_ulong()")
Signed-off-by: Andrew F. Davis 
---
 board/ti/ks2_evm/board_k2g.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 88df419b10..b9575a8e46 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -376,7 +376,7 @@ int get_num_eth_ports(void)
 #ifdef CONFIG_TI_SECURE_DEVICE
 void board_pmmc_image_process(ulong pmmc_image, size_t pmmc_size)
 {
-   int id = getenv_ulong("dev_pmmc", 10, 0);
+   int id = env_get_ulong("dev_pmmc", 10, 0);
int ret;
 
if (!rproc_is_initialized())
-- 
2.16.1

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

[U-Boot] [PATCH v2 1/1] fs: fat: avoid superfluous conversion calling set_cluster

Parameter size of function set_cluster is of type unsigned long. It makes
no sense to convert actsize to int before passing it to set_cluster as
size. Let's use loff_t as type of parameter size to avoid any conversion.

Signed-off-by: Heinrich Schuchardt 
---
v2
change type of parameter size
---
 fs/fat/fat_write.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 2b753df2820..270b2908acd 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -494,8 +494,7 @@ static __u32 determine_fatent(fsdata *mydata, __u32 entry)
  * Return 0 on success, -1 otherwise.
  */
 static int
-set_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
-unsigned long size)
+set_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, loff_t size)
 {
__u32 idx = 0;
__u32 startsect;
@@ -679,7 +678,7 @@ set_contents(fsdata *mydata, dir_entry *dentptr, __u8 
*buffer,
 
/* set remaining bytes */
actsize = filesize;
-   if (set_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
+   if (set_cluster(mydata, curclust, buffer, actsize) != 0) {
debug("error: writing cluster\n");
return -1;
}
@@ -696,7 +695,7 @@ set_contents(fsdata *mydata, dir_entry *dentptr, __u8 
*buffer,
 
return 0;
 getit:
-   if (set_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
+   if (set_cluster(mydata, curclust, buffer, actsize) != 0) {
debug("error: writing cluster\n");
return -1;
}
-- 
2.11.0

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

[U-Boot] [PATCH v2 1/1] fs: fat: avoid useless conversion when calling get_cluster

Parameter size of function get_cluster() is of type unsigned long. It makes
no sense to convert actsize to int before passing it to get_cluster as
size. Let't use t_off as type of parameter to avoid any type conversion.

Signed-off-by: Heinrich Schuchardt 
---
v2
change type of parameter size
---
 fs/fat/fat.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index dd7888cd6d4..cf4580b63df 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -244,7 +244,7 @@ static __u32 get_fatent(fsdata *mydata, __u32 entry)
  * Return 0 on success, -1 otherwise.
  */
 static int
-get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, unsigned long size)
+get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer, loff_t size)
 {
__u32 idx = 0;
__u32 startsect;
@@ -353,7 +353,7 @@ static int get_contents(fsdata *mydata, dir_entry *dentptr, 
loff_t pos,
if (pos) {
actsize = min(filesize, (loff_t)bytesperclust);
if (get_cluster(mydata, curclust, get_contents_vfatname_block,
-   (int)actsize) != 0) {
+   actsize) != 0) {
printf("Error reading cluster\n");
return -1;
}
@@ -393,14 +393,14 @@ static int get_contents(fsdata *mydata, dir_entry 
*dentptr, loff_t pos,
 
/* get remaining bytes */
actsize = filesize;
-   if (get_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
+   if (get_cluster(mydata, curclust, buffer, actsize) != 0) {
printf("Error reading cluster\n");
return -1;
}
*gotsize += actsize;
return 0;
 getit:
-   if (get_cluster(mydata, curclust, buffer, (int)actsize) != 0) {
+   if (get_cluster(mydata, curclust, buffer, actsize) != 0) {
printf("Error reading cluster\n");
return -1;
}
-- 
2.11.0

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

Re: [U-Boot] U-Boot

2018-02-14 Thread Mariano Coromac

I think I found the root problem for this. I am using a flexcom uart. The
ones that are defined in sama5d2.dtsi are normal uarts, one can use those
definitions alongside the drivers to use uart0 to uart4.
I found a definition to use flexcom, here:
https://github.com/linux4sam/linux-at91/blob/master/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
The problem I see is that I need a driver also and atmel did not provide
one. Or at least I'm not seeing it because I have search for it around the
entire project.

Could you confirm if my assumptions are correct? Because I see that the
flexcom clocks are defined and makes me wonder if the problem is something
else.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 8/8] Migrate generic bootcount to Kconfig

Hi Alex,

> On Wed, Feb 14, 2018 at 8:53 AM, Lukasz Majewski 
> wrote:
> >> >> Whatever we do, I think CONFIG_SYS_BOOTCOUNT_ADDR wants
> >> >> splitting into at least two:
> >> >>
> >> >> - I2C - an offset from an I2C base for the bootcounter  
> >> >   - RAM/SoC memory - location of special register to store
> >> > bootcounter  
> >> >> - Others - an actual address used for storing the bootcounter  
> >> >
> >> >
> >> >  
> >> >>
> >> >> I'm struggling to see why EXT is the way it is - AFAICS the
> >> >> location it uses to access/return the bootcounter is basically
> >> >> local to the two functions in bootcount_ext and could just be a
> >> >> local variable.  
> >> >
> >> > Maybe we can replace it with local, static variable then?
> >> >
> >> >
> >> > As said above - I would remove the (wrongly?) used
> >> > BOOTCOUNT_ADDR in Kconfig.
> >> >  
> >>
> >> Just removing SYS_BOOTCOUNT_ADDR from Kconfig and putting the
> >> default back into bootcount_ext seems like the simplest correct
> >> change. I'll add that onto the series and throw it at Travis.  
> >
> > Great. I'm looking forward for next verison of the code - as I do
> > have some code to be put on top of it.
> >  
> 
> So the super-trivial approach doesn't work, because
> CONFIG_SYS_BOOTCOUNT_ADDR isn't in the whitelist anymore
> (7af2e3648f3f6d726f6476745c2eec5de709a702) and I think the only reason
> it was getting through before is because scripts/check-config.sh
> doesn't parse conditionals in Kconfig so thought it was allowed :(
> 
> I expect reintroducing CONFIG_SYS_BOOTCOUNT_ADDR to
> config_whitelist.txt would "fix" the problem, but that's not going to
> make it in.
> 
> Which I think means I have to do the work to migrate it out of CONFIG_
> land properly.
> 

Ok. I see.


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


pgpQoaIkSrP11.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] configs: Migrate CONFIG_SYS_TEXT_BASE

2018-02-14 Thread Adam Ford

On Mon, Feb 12, 2018 at 6:01 PM, Tom Rini  wrote:
> On Tue, Feb 06, 2018 at 03:15:58PM -0600, Adam Ford wrote:
>> On Sat, Feb 3, 2018 at 11:10 AM, Tom Rini  wrote:
>> > On the NIOS2 and Xtensa architectures, we do not have
>> > CONFIG_SYS_TEXT_BASE set.  This is a strict migration of the current
>> > values into the defconfig and removing them from the headers.
>> >
>> > I did not attempt to add more default values in and for now will leave
>> > that to maintainers.
>> >
>> > Signed-off-by: Tom Rini 
>> > ---
>> > What I wonder about, at this point, would be how hard it would be to add
>> > imply FOO hex/int/str/etc value to the imply keyword.  I don't want to
>> > see 100 lines worth of default 0xX if Y || Z for CONFIG_SYS_TEXT_BASE as
>> > that will be unmaintainable.
>> > ---
>>
>> [snip]
>>
>> >   new boards should not use this option.
>> >
>> >  config SYS_TEXT_BASE
>> > -   depends on ARC || X86 || ARCH_UNIPHIER || ARCH_ZYNQMP || \
>> > -   (M68K && !TARGET_ASTRO_MCF5373L) || MICROBLAZE || MIPS || \
>> > -   ARCH_ZYNQ || ARCH_KEYSTONE || ARCH_OMAP2PLUS
>> > +   depends on !NIOS2 && !XTENSA
>> > depends on !EFI_APP
>> > +   default 0x8080 if ARCH_OMAP2PLUS
>> > hex "Text Base"
>> > help
>> > - TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
>> > + The address in memory that U-Boot will be running from, 
>> > initially.
>> >
>> > -   default 0x8080 if ARCH_OMAP2PLUS
>> >
>>
>> I have a question.  I don't think anything is wrong, but
>> doc/SPL/README.omap3 shows two different options for
>> CONFIG_SYS_TEXT_BASE and neither of them are 0x8080
>>
>> Option 1 (SPL only):
>> 0x8010: CONFIG_SYS_TEXT_BASE of U-Boot
>>
>> Option 2 (SPL or X-Loader):
>> 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot
>>
>> I'm sure it's probably been this way for a while, but when reviewing
>> the omap3_logic board (am/dm37), I noticed it's currenly using
>> 0x8080, but I am not sure how the rest of the memory map from the
>> readme applies.  Does this README file need to be updated or deleted?
>> Will we have any memory conflicts or overlap?
>
> So, good question.  And I think it's partly due to the docs being out of
> date.  The docs are correct, for the time.  This is best now explained
> in include/configs/ti_armv7_common.h:
> /*
>  * Place the image at the start of the ROM defined image space (per
>  * CONFIG_SPL_TEXT_BASE and we limit our size to the ROM-defined
>  * downloaded image area minus 1KiB for scratch space.  We initalize DRAM as
>  * soon as we can so that we can place stack, malloc and BSS there.  We load
>  * U-Boot itself into memory at 0x8080 for legacy reasons (to not conflict
>  * with older SPLs).  We have our BSS be placed 2MiB after this, to allow for
>  * the default Linux kernel address of 0x80008000 to work with most sized
>  * kernels, in the Falcon Mode case.  We have the SPL malloc pool at the end
>  * of the BSS area.  We suggest that the stack be placed at 32MiB after the
>  * start of DRAM to allow room for all of the above (handled in Kconfig).
>  */
>

If we're migrating this would it make sense to remove this content
from the include/configs/ti_armv7_common.h and place it into the
README file instead of what is currently there?  I can do that if you
think it makes the most sense.  I just don't like 'wrong' info and I
was burned before, and if the description is in two places, it can
also add to the confusion.

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

[U-Boot] Please fix ls1046ardb

2018-02-14 Thread York Sun

Mingkai,

LS1046ARDB is broken for both QSPI and SD. For QSPI, I cannot use
environmental variables. For SD boot, it fails when trying to init SD
card. Partial log is

Initializing DDRusing SPD
WARNING: Calling __hwconfig without a buffer and before environment is ready
WARNING: Calling __hwconfig without a buffer and before environment is ready
WARNING: Calling __hwconfig without a buffer and before environment is ready
WARNING: Calling __hwconfig without a buffer and before environment is ready
Trying to boot from MMC1
unable to select a mode
mmc_init: -524, time 51
spl: mmc init failed with error: -524
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Please investigate.

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

Re: [U-Boot] [U-Boot, RFC] Kconfig: cmd: Make networking command dependent on NET

On Tue, Feb 06, 2018 at 01:26:52PM +0100, Michal Simek wrote:

> Enable networking command only when NET is enabled.
> And remove selecting NET for CMD_NET
> 
> Signed-off-by: Michal Simek 

I tried taking this, but as-is, now we have a big problem due to
"everyone" getting NET selected here.  Making NET default y fixes _most_
things except for the following boards that blow up related to EFI
loader:
   aarch64:  +   thunderx_88xx
   arm:  +   at91sam9rlek_mmc warp zynq_zc770_xm011_x16 mx23evk 
bcm23550_w1d s5pc210_univer
sal cairo topic_miamilite omap3_pandora topic_miami origen bcm28155_ap 
tricorder zynq_zc770_xm0
11 tricorder_flash s5p_goni trats aspenite at91sam9rlek_nandflash trats2 
at91sam9rlek_dataflash

At this point, I'm going to defer this back to you.  I think the concept
of the patch is right but it needs a bit more work.  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

2018-02-14 Thread Mariano Coromac

Forget it guys, I just realized what was wrong.
reg = <0xf8038200 0x200>;
Before it was
reg = <0xf8038200 0x100>;
So if anyone else (that wants to use the flexcom uart) asks you about this
now there's another thing you can point to.
If I encounter another problem or something I'll get back to you.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] dfu: Fix up the Kconfig mess

Hi Marek,

> Clean up the screaming mess of configuration options that DFU is.
> It was impossible to configure DFU such that TFTP is enabled and
> USB is not, this patch fixes that and assures that DFU TFTP and
> DFU USB can be enabled separatelly and that the correct pieces
> of code are compiled in.
> 
> Signed-off-by: Marek Vasut 
> Cc: Lukasz Majewski 
> ---
>  cmd/Kconfig  |  3 ++-
>  cmd/dfu.c| 18 +-
>  common/Makefile  |  6 --
>  drivers/dfu/Kconfig  | 13 -
>  drivers/dfu/Makefile |  2 +-
>  5 files changed, 32 insertions(+), 10 deletions(-)
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 7368b6df52..1ef4c31202 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -582,7 +582,8 @@ config CMD_DEMO
>  
>  config CMD_DFU
>   bool "dfu"
> - select USB_FUNCTION_DFU
> + imply USB_FUNCTION_DFU if USB_GADGET
  ^^^- This name is OK. It is the same as other
  "gadget" names - like USB_FUNCTION_SDP,
  USB_FUNCTION_THOR, etc.

> + imply TFTP_FUNCTION_DFU if NET
  ^^ - this name is a bit misleading
Why we cannot select CONFIG_DFU_TFTP here directly and drop
this config?
 
>   help
> Enables the command "dfu" which is used to have U-Boot
> create a DFU class device via USB. This command requires that the
> "dfu_alt_info" diff --git a/cmd/dfu.c b/cmd/dfu.c
> index 04291f6c08..76b89ca5ed 100644
> --- a/cmd/dfu.c
> +++ b/cmd/dfu.c
> @@ -25,12 +25,14 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) if (argc < 4)
>   return CMD_RET_USAGE;
>  
> +#ifdef CONFIG_USB_FUNCTION_DFU
>   char *usb_controller = argv[1];
> +#endif
>   char *interface = argv[2];
>   char *devstring = argv[3];
>  
> - int ret;
> -#ifdef CONFIG_DFU_TFTP
> + int ret = 0;
> +#ifdef CONFIG_TFTP_FUNCTION_DFU
>   unsigned long addr = 0;
>   if (!strcmp(argv[1], "tftp")) {
>   if (argc == 5)
> @@ -39,7 +41,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) return update_tftp(addr, interface,
> devstring); }
>  #endif
> -
> +#ifdef CONFIG_USB_FUNCTION_DFU
>   ret = dfu_init_env_entities(interface, devstring);
>   if (ret)
>   goto done;
> @@ -56,18 +58,24 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) 
>  done:
>   dfu_free_entities();
> +#endif

Please exclude relevant pieces of code for TFTP and for USB in a
separate static functions:

#ifdef CONFIG_USB_FUNCTION_DFU
dfu_usb() {

}
#else
dfu_usb() {return 0};
#fi

#ifdef CONFIG_DFU_TFTP
dfu_tftp() {

}
#else
dfu_tftp() {return 0};
#fi


do_dfu () {
...
ret = dfu_usb();
ret = dfu_tftp();

}

>   return ret;
>  }
>  
>  U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
>   "Device Firmware Upgrade",
> +#ifdef CONFIG_USB_FUNCTION_DFU
>   "   [list]\n"
>   "  - device firmware upgrade via \n"
>   "on device , attached to interface\n"
>   "\n"
>   "[list] - list available alt settings\n"
> -#ifdef CONFIG_DFU_TFTP
> - "dfu tftp   []\n"
> +#endif
> +#ifdef CONFIG_TFTP_FUNCTION_DFU
> +#ifdef CONFIG_USB_FUNCTION_DFU
> + "dfu "
> +#endif
> + "tftp   []\n"
>   "  - device firmware upgrade via TFTP\n"
>   "on device , attached to interface\n"
>   "\n"

Please simply use (in a way similar to ./cmd/mmc.c) :

#ifdef CONFIG_USB_FUNCTION_DFU
"   [list]\n"
"  - device firmware upgrade via \n"
"on device , attached to interface\n"
"\n"
"[list] - list available alt settings\n"
#endif
#ifdef CONFIG_DFU_TFTP
"dfu tftp   []\n"
"  - device firmware upgrade via TFTP\n"
"on device , attached to interface\n"
"\n"
"[] - address where FIT image has been stored\n"
#endif


> diff --git a/common/Makefile b/common/Makefile
> index c7bde239c1..cdd0ab19d8 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -66,7 +66,9 @@ endif # !CONFIG_SPL_BUILD
>  obj-$(CONFIG_$(SPL_TPL_)BOOTSTAGE) += bootstage.o
>  
>  ifdef CONFIG_SPL_BUILD
> -obj-$(CONFIG_SPL_DFU_SUPPORT) += dfu.o
> +ifdef CONFIG_SPL_DFU_SUPPORT
> +obj-$(CONFIG_USB_FUNCTION_DFU) += dfu.o
> +endif

This shall be left as it is - Faiz is going to clean up this.
http://patchwork.ozlabs.org/patch/873372/

And side question - the CONFIG_SPL_DFU_SUPPORT shall be orthogonal
to other DFU settings (as it is for SPL).

Does your board require DFU support in SPL ?

>  obj-$(CONFIG_SPL_DFU_SUPPORT) += cli_hush.o
>  obj-$(CONFIG_SPL_HASH_SUPPORT) += hash.o
>  obj-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o
> @@ -128,7 +130,7 @@ endif
>  
>  obj-y += cli.o
>  obj-$(CONFIG_FSL_DDR_INTERACTIVE) += cli_simple.o cli_readline.o
> -obj-$(CONFIG_CMD_DFU) += dfu.o
> +obj-$(CONFIG_USB_FUNCTION_DFU) += dfu

Re: [U-Boot] Please fix ls1046ardb

2018-02-14 Thread Jonathan Gray

On Wed, Feb 14, 2018 at 07:25:53PM +, York Sun wrote:
> Mingkai,
> 
> LS1046ARDB is broken for both QSPI and SD. For QSPI, I cannot use
> environmental variables. For SD boot, it fails when trying to init SD
> card. Partial log is
> 
> Initializing DDRusing SPD
> WARNING: Calling __hwconfig without a buffer and before environment is ready
> WARNING: Calling __hwconfig without a buffer and before environment is ready
> WARNING: Calling __hwconfig without a buffer and before environment is ready
> WARNING: Calling __hwconfig without a buffer and before environment is ready
> Trying to boot from MMC1
> unable to select a mode
> mmc_init: -524, time 51
> spl: mmc init failed with error: -524
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> 
> Please investigate.
> 
> York

This reminds me of the problem I ran into with qemu vexpress-a15.
https://lists.denx.de/pipermail/u-boot/2018-February/319965.html
https://patchwork.ozlabs.org/patch/871324/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Please fix ls1046ardb

2018-02-14 Thread York Sun

On 02/14/2018 04:30 PM, Jonathan Gray wrote:
> On Wed, Feb 14, 2018 at 07:25:53PM +, York Sun wrote:
>> Mingkai,
>>
>> LS1046ARDB is broken for both QSPI and SD. For QSPI, I cannot use
>> environmental variables. For SD boot, it fails when trying to init SD
>> card. Partial log is
>>
>> Initializing DDRusing SPD
>> WARNING: Calling __hwconfig without a buffer and before environment is ready
>> WARNING: Calling __hwconfig without a buffer and before environment is ready
>> WARNING: Calling __hwconfig without a buffer and before environment is ready
>> WARNING: Calling __hwconfig without a buffer and before environment is ready
>> Trying to boot from MMC1
>> unable to select a mode
>> mmc_init: -524, time 51
>> spl: mmc init failed with error: -524
>> SPL: failed to boot from all boot devices
>> ### ERROR ### Please RESET the board ###
>>
>> Please investigate.
>>
>> York
> 
> This reminds me of the problem I ran into with qemu vexpress-a15.

Thanks for the quick note. I tried the patch in your second link (i.e.
patch 871324), but it didn't fix my problem.

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

[U-Boot] How to test new bootloaders on Jetson TX1?

2018-02-14 Thread Andreas Färber

Hello,

I would like to test the latest version of U-Boot on the Jetson TX1.

Unfortunately U-Boot is lacking a README that would explain how to do that:

http://git.denx.de/?p=u-boot.git;a=tree;f=board/nvidia/p2371-2180;h=097fb9aaec8abd522b7b8382e5c4169f5ea8f691;hb=HEAD

I understand that the Jetson TK1's Python based
https://github.com/NVIDIA/tegra-uboot-flasher-scripts
have never been updated for Tegra X1.

That leaves L4T Jetson TX1 Driver Package, latest version being R28.1.0.

Here's what I have tried:

$ sudo ./flash.sh p2371-2180-devkit mmcblk0p1

On openSUSE Leap 42.3 this keeps failing the first time:

copying
bctfile(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/bootloader/t210ref/BCT/P2180_A00_LP4_DSC_204Mhz.cfg)...
done.
copying
bootloader(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/bootloader/t210ref/cboot.bin)...
done.
populating kernel to rootfs... done.
populating initrd to rootfs... done.
populating extlinux.conf.emmc to rootfs... done.
populating
/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/kernel/dtb/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
to rootfs... done.
done.
Making Boot image... done.
copying
bcffile(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/bootloader/t210ref/cfg/board_config_p2597-devkit.xml)...
done.
Existing
sosfile(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/bootloader/nvtboot_recovery.bin)
reused.
copying
tegraboot(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/bootloader/t210ref/nvtboot.bin)...
done.
Existing
bpffile(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/bootloader/bpmp.bin)
reused.
copying
wb0boot(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/bootloader/t210ref/warmboot.bin)...
done.
Existing
tosfile(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/bootloader/tos.img)
reused.
Existing
eksfile(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/bootloader/eks.img)
reused.
copying
dtbfile(/home/andreas/MCU/ARM/JetsonTX1/Linux_for_Tegra/kernel/dtb/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb)...
done.
Making system.img...
/dev/loop0 is not block device. Terminating..

I have managed to work around that by running sudo losetup -f once.

That gets me to a:

U-Boot 2016.07-g0ce7ca2 (Jul 20 2017 - 00:37:03 -0700)

(where our efiboot command doesn't quite work yet)

https://elinux.org/Jetson/TX1_Upstream_Kernel

claims: "The distributed tarball contains a pre-built U-Boot and kernel,
but these may be replaced with any images you wish to flash, by
replacing the distributed images in the directory tree."
and "To flash only the primary bootloader and U-Boot: ./flash.sh -k EBT
p2371-2180 mmcblk0p1"

Apparently that's not true anymore (R23.1.1 armhf vs. R28.1.0 aarch64):
Operation succeeds, but U-Boot is still the old one.

Possible cause: The EBT partition gets a cboot.bin, not u-boot-dtb.bin.

If I repeat without -k EBT and with the openSUSE OBS builds of U-Boot
v2018.01 then again flashing appears to succeed, but boot gets stuck at:

[0003.260] Starting Bpmp FW
[0003.263] BPMP-FW Carveout: Base = 0xff2c and Size = 0x4

(short of showing the U-Boot banner)

Also, ATF shows up as:

NOTICE: BL31: v1.2(release):cc5fd7c
NOTICE: BL31: Built : 00:37:02, Jul 20 2017

(which is most certainly lacking Jan 2018 Spectre mitigations for CA57)

Security Bulletin
http://nvidia.custhelp.com/app/answers/detail/a_id/4616
announces an R28.2 for later this month, but with t210 in mainline ATF I
would really like to use my own patched ATF build already.

https://github.com/ARM-software/arm-trusted-firmware/blob/6f62574767546b11199142b1b577a86571051c40/docs/plat/nvidia-tegra.rst
doesn't explain how to get the t210 bl31.bin onto a board either.

https://elinux.org/Jetson_TX1 links to multiple App Notes on a
non-reachable Nvidia FTP server. I found that replacing ftp with http,
they can still be reached (dated 2015), but
http://download.nvidia.com/tegra-public-appnotes/t210-nvtboot-flow.html
isn't too helpful either, other than giving a rough overview.

Colleagues have succeeded in loading a U-Boot via RCM into RAM and
executing from there, but I figure that won't quite work for ATF.
And it's no permanent solution anyway.

So could someone please comment on how to perform a minimally-invasive
update of the individual Open Source firmware components for Jetson TX1?

Thanks,
Andreas

--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] usb: gadget: sdp: add missing line breaks

Cosmetic change.

Signed-off-by: Andre Heider 
---
 cmd/usb_gadget_sdp.c   |  4 ++--
 common/spl/spl_sdp.c   |  4 ++--
 drivers/usb/gadget/f_sdp.c | 14 +++---
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/cmd/usb_gadget_sdp.c b/cmd/usb_gadget_sdp.c
index ae4d73c125..97d00ec545 100644
--- a/cmd/usb_gadget_sdp.c
+++ b/cmd/usb_gadget_sdp.c
@@ -28,13 +28,13 @@ static int do_sdp(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
ret = sdp_init(controller_index);
if (ret) {
-   pr_err("SDP init failed: %d", ret);
+   pr_err("SDP init failed: %d\n", ret);
goto exit;
}
 
/* This command typically does not return but jumps to an image */
sdp_handle(controller_index);
-   pr_err("SDP ended");
+   pr_err("SDP ended\n");
 
 exit:
g_dnl_unregister();
diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
index 333d518f4d..0c4603a3db 100644
--- a/common/spl/spl_sdp.c
+++ b/common/spl/spl_sdp.c
@@ -24,13 +24,13 @@ static int spl_sdp_load_image(struct spl_image_info 
*spl_image,
 
ret = sdp_init(controller_index);
if (ret) {
-   pr_err("SDP init failed: %d", ret);
+   pr_err("SDP init failed: %d\n", ret);
return -ENODEV;
}
 
/* This command typically does not return but jumps to an image */
sdp_handle(controller_index);
-   pr_err("SDP ended");
+   pr_err("SDP ended\n");
 
return -EINVAL;
 }
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index dd7b9cddb1..6da0530095 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -238,12 +238,12 @@ static void sdp_rx_command_complete(struct usb_ep *ep, 
struct usb_request *req)
u8 report = data[0];
 
if (status != 0) {
-   pr_err("Status: %d", status);
+   pr_err("Status: %d\n", status);
return;
}
 
if (report != 1) {
-   pr_err("Unexpected report %d", report);
+   pr_err("Unexpected report %d\n", report);
return;
}
 
@@ -323,12 +323,12 @@ static void sdp_rx_data_complete(struct usb_ep *ep, 
struct usb_request *req)
int datalen = req->length - 1;
 
if (status != 0) {
-   pr_err("Status: %d", status);
+   pr_err("Status: %d\n", status);
return;
}
 
if (report != 2) {
-   pr_err("Unexpected report %d", report);
+   pr_err("Unexpected report %d\n", report);
return;
}
 
@@ -361,7 +361,7 @@ static void sdp_rx_data_complete(struct usb_ep *ep, struct 
usb_request *req)
sdp->state = SDP_STATE_TX_SEC_CONF;
break;
default:
-   pr_err("Invalid state: %d", sdp->state);
+   pr_err("Invalid state: %d\n", sdp->state);
}
 }
 
@@ -371,7 +371,7 @@ static void sdp_tx_complete(struct usb_ep *ep, struct 
usb_request *req)
int status = req->status;
 
if (status != 0) {
-   pr_err("Status: %d", status);
+   pr_err("Status: %d\n", status);
return;
}
 
@@ -394,7 +394,7 @@ static void sdp_tx_complete(struct usb_ep *ep, struct 
usb_request *req)
sdp->state = SDP_STATE_IDLE;
break;
default:
-   pr_err("Wrong State: %d", sdp->state);
+   pr_err("Wrong State: %d\n", sdp->state);
sdp->state = SDP_STATE_IDLE;
break;
}
-- 
2.16.1

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

[U-Boot] [PATCH 2/2] usb: gadget: sdp: fix pointer casts for 64bit archs

The SDP protocol contains multiple 32bit pointers. Add a helper function
to get a valid pointer from these values and use it.

Signed-off-by: Andre Heider 
---
 drivers/usb/gadget/f_sdp.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index 6da0530095..43c5cfbb77 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -230,6 +230,11 @@ static struct usb_gadget_strings *sdp_generic_strings[] = {
NULL,
 };
 
+static inline void *sdp_ptr(u32 val)
+{
+   return (void *)(uintptr_t)val;
+}
+
 static void sdp_rx_command_complete(struct usb_ep *ep, struct usb_request *req)
 {
struct f_sdp *sdp = req->context;
@@ -344,7 +349,7 @@ static void sdp_rx_data_complete(struct usb_ep *ep, struct 
usb_request *req)
}
 
if (sdp->state == SDP_STATE_RX_FILE_DATA) {
-   memcpy((void *)sdp->dnl_address, req->buf + 1, datalen);
+   memcpy(sdp_ptr(sdp->dnl_address), req->buf + 1, datalen);
sdp->dnl_address += datalen;
}
 
@@ -622,7 +627,7 @@ static u32 sdp_jump_imxheader(void *address)
}
 
printf("Jumping to 0x%08x\n", headerv2->entry);
-   entry = (void *)headerv2->entry;
+   entry = sdp_ptr(headerv2->entry);
entry();
 
/* The image probably never returns hence we won't reach that point */
@@ -665,7 +670,7 @@ static void sdp_handle_in_ep(void)
if (datalen > 64)
datalen = 64;
 
-   memcpy(&data[1], (void *)sdp_func->dnl_address, datalen);
+   memcpy(&data[1], sdp_ptr(sdp_func->dnl_address), datalen);
sdp_func->in_req->length = 65;
 
sdp_func->dnl_bytes_remaining -= datalen;
@@ -676,7 +681,7 @@ static void sdp_handle_in_ep(void)
break;
case SDP_STATE_JUMP:
printf("Jumping to header at 0x%08x\n", sdp_func->jmp_address);
-   status = sdp_jump_imxheader((void *)sdp_func->jmp_address);
+   status = sdp_jump_imxheader(sdp_ptr(sdp_func->jmp_address));
 
/* If imx header fails, try some U-Boot specific headers */
if (status) {
-- 
2.16.1

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

Re: [U-Boot] [PATCH 1/3] ARM: Kconfig: Move TI_SECURE_DEVICE to a common area

2018-02-14 Thread Lokesh Vutla



On Wednesday 14 February 2018 11:23 PM, Andrew F. Davis wrote:
> TI_SECURE_DEVICE is used by both OMAP2+ and Keystone2 family devices,
> and so when ARCH_OMAP2PLUS was used to gate off the OMAP2+ Kconfig
> Keystone2 family devices lost this config option.
> 
> Move this option out of mach-omap2 Kconfig to a spot accessible by both
> families. We picked arch/arm/Kconfig over the TI specific board/ti/
> location as this option is not specific to our boards but rather our
> architecture.
> 
> Plus at some point this option can be changed to just
> SECURE_DEVICE, as having secure parts is not exclusive to TI and
> so other vendors can interpret this option as needed by their device
> configurations.
> 
> Fixes: a93fbf4a7892 ("ARM: omap2+: rename config to ARCH_OMAP2PLUS and 
> consolidate Kconfig")
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> ---
>  arch/arm/Kconfig| 10 ++
>  arch/arm/mach-omap2/Kconfig | 10 --
>  2 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 7b618d6881..466c7502d5 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1189,6 +1189,16 @@ config ARCH_ASPEED
>  
>  endchoice
>  
> +config TI_SECURE_DEVICE
> + bool "HS Device Type Support"
> + depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS
> + help
> +   If a high secure (HS) device type is being used, this config
> +   must be set. This option impacts various aspects of the
> +   build system (to create signed boot images that can be
> +   authenticated) and the code. See the doc/README.ti-secure
> +   file for further details.
> +
>  source "arch/arm/mach-aspeed/Kconfig"
>  
>  source "arch/arm/mach-at91/Kconfig"
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index abd1aa7fe1..62c25c4044 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -133,16 +133,6 @@ config SYS_MPUCLK
>   help
> Defines the MPU clock speed (in MHz).
>  
> -config TI_SECURE_DEVICE
> - bool "HS Device Type Support"
> - depends on OMAP54XX || AM43XX || AM33XX || ARCH_KEYSTONE
> - help
> -   If a high secure (HS) device type is being used, this config
> -   must be set. This option impacts various aspects of the
> -   build system (to create signed boot images that can be
> -   authenticated) and the code. See the doc/README.ti-secure
> -   file for further details.
> -
>  config TI_SECURE_EMIF_REGION_START
>   hex "Reserved EMIF region start address"
>   depends on TI_SECURE_DEVICE
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] defconfig: k2x_hs_evm: Re-enable TI_SECURE_DEVICE in HS K2x parts

2018-02-14 Thread Lokesh Vutla



On Wednesday 14 February 2018 11:23 PM, Andrew F. Davis wrote:
> These got removed in config re-syncs due to a Kconfig bug. Add these
> back here.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> ---
>  configs/k2e_hs_evm_defconfig  | 2 ++
>  configs/k2g_hs_evm_defconfig  | 2 ++
>  configs/k2hk_hs_evm_defconfig | 2 ++
>  3 files changed, 6 insertions(+)
> 
> diff --git a/configs/k2e_hs_evm_defconfig b/configs/k2e_hs_evm_defconfig
> index 266fb8abdc..44ed07e7f9 100644
> --- a/configs/k2e_hs_evm_defconfig
> +++ b/configs/k2e_hs_evm_defconfig
> @@ -1,9 +1,11 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_KEYSTONE=y
> +CONFIG_TI_SECURE_DEVICE=y
>  CONFIG_SYS_TEXT_BASE=0xC60
>  CONFIG_TI_COMMON_CMD_OPTIONS=y
>  CONFIG_TARGET_K2E_EVM=y
>  CONFIG_DEFAULT_DEVICE_TREE="keystone-k2e-evm"
> +CONFIG_FIT_IMAGE_POST_PROCESS=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
>  CONFIG_VERSION_VARIABLE=y
> diff --git a/configs/k2g_hs_evm_defconfig b/configs/k2g_hs_evm_defconfig
> index 5acc04be6f..ea1a61efa5 100644
> --- a/configs/k2g_hs_evm_defconfig
> +++ b/configs/k2g_hs_evm_defconfig
> @@ -1,9 +1,11 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_KEYSTONE=y
> +CONFIG_TI_SECURE_DEVICE=y
>  CONFIG_SYS_TEXT_BASE=0xC60
>  CONFIG_TI_COMMON_CMD_OPTIONS=y
>  CONFIG_TARGET_K2G_EVM=y
>  CONFIG_DEFAULT_DEVICE_TREE="keystone-k2g-evm"
> +CONFIG_FIT_IMAGE_POST_PROCESS=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
>  CONFIG_VERSION_VARIABLE=y
> diff --git a/configs/k2hk_hs_evm_defconfig b/configs/k2hk_hs_evm_defconfig
> index 931a20c8e7..0a39da55f5 100644
> --- a/configs/k2hk_hs_evm_defconfig
> +++ b/configs/k2hk_hs_evm_defconfig
> @@ -1,9 +1,11 @@
>  CONFIG_ARM=y
>  CONFIG_ARCH_KEYSTONE=y
> +CONFIG_TI_SECURE_DEVICE=y
>  CONFIG_SYS_TEXT_BASE=0xC60
>  CONFIG_TI_COMMON_CMD_OPTIONS=y
>  CONFIG_TARGET_K2HK_EVM=y
>  CONFIG_DEFAULT_DEVICE_TREE="keystone-k2hk-evm"
> +CONFIG_FIT_IMAGE_POST_PROCESS=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
>  CONFIG_VERSION_VARIABLE=y
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] env: Fix missed getenv_ulong to env_get_ulong conversion

2018-02-14 Thread Lokesh Vutla



On Wednesday 14 February 2018 11:23 PM, Andrew F. Davis wrote:
> This seems to have been missed, possibly due to the inability to
> enable TI_SECURE_DEVICE on Keystone2 devices previously.
> 
> Fixes: bfebc8c965e4 ("env: Rename getenv_hex(), getenv_yesno(), 
> getenv_ulong()")
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> ---
>  board/ti/ks2_evm/board_k2g.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
> index 88df419b10..b9575a8e46 100644
> --- a/board/ti/ks2_evm/board_k2g.c
> +++ b/board/ti/ks2_evm/board_k2g.c
> @@ -376,7 +376,7 @@ int get_num_eth_ports(void)
>  #ifdef CONFIG_TI_SECURE_DEVICE
>  void board_pmmc_image_process(ulong pmmc_image, size_t pmmc_size)
>  {
> - int id = getenv_ulong("dev_pmmc", 10, 0);
> + int id = env_get_ulong("dev_pmmc", 10, 0);
>   int ret;
>  
>   if (!rproc_is_initialized())
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/3] cmd: cbfs: fix reading the end_of_rom pointer for 64bit archs

The cast breaks the pointer on 64bit archs, so lets get rid of it.

Signed-off-by: Andre Heider 
---
 cmd/cbfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/cbfs.c b/cmd/cbfs.c
index 799ba01fcc..736f8c4527 100644
--- a/cmd/cbfs.c
+++ b/cmd/cbfs.c
@@ -22,7 +22,7 @@ static int do_cbfs_init(cmd_tbl_t *cmdtp, int flag, int argc,
return 0;
}
if (argc == 2) {
-   end_of_rom = (int)simple_strtoul(argv[1], &ep, 16);
+   end_of_rom = simple_strtoul(argv[1], &ep, 16);
if (*ep) {
puts("\n** Invalid end of ROM **\n");
return 1;
-- 
2.16.1

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

[U-Boot] [PATCH 2/3] fs: cbfs: fix locating the cbfs header

The value at the end of the rom is not a pointer, it is an offset
relative to the end of rom.

Signed-off-by: Andre Heider 
---
 fs/cbfs/cbfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/cbfs/cbfs.c b/fs/cbfs/cbfs.c
index 6e1107d751..46da8f134f 100644
--- a/fs/cbfs/cbfs.c
+++ b/fs/cbfs/cbfs.c
@@ -168,9 +168,9 @@ static int file_cbfs_load_header(uintptr_t end_of_rom,
 struct cbfs_header *header)
 {
struct cbfs_header *header_in_rom;
+   int32_t offset = *(u32 *)(end_of_rom - 3);
 
-   header_in_rom = (struct cbfs_header *)(uintptr_t)
-   *(u32 *)(end_of_rom - 3);
+   header_in_rom = (struct cbfs_header *)(end_of_rom + offset + 1);
swap_header(header, header_in_rom);
 
if (header->magic != good_magic || header->offset >
-- 
2.16.1

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

[U-Boot] [PATCH 3/3] cbfs: add support for cbfs header components

This fixes walking the cbfs file list because the bound checks do not
apply to header components.

Output of coreboot's cbfstool:
Name   Offset Type   Size   Comp
cbfs master header 0x0cbfs header32 none
fallback/romstage  0x80   stage   21344 none
fallback/ramstage  0x5440 stage   36848 none
config 0xe480 raw   310 none
revision   0xe600 raw   575 none
fallback/bl31  0xe880 payload 15931 none
fallback/payload   0x12700payload205449 none
(empty)0x44a00null   111768 none
header pointer 0x5fec0cbfs header 4 none

Output of u-boot's cbfsls:
 size  type  name
--
   32   cbfs header  cbfs master header
21344 stage  fallback/romstage
36848 stage  fallback/ramstage
  310   raw  config
  575   raw  revision
15931   payload  fallback/bl31
   205449   payload  fallback/payload
   111768  null  (empty)
4   cbfs header  header pointer

Signed-off-by: Andre Heider 
---
 cmd/cbfs.c |  3 +++
 fs/cbfs/cbfs.c | 10 ++
 include/cbfs.h |  1 +
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/cmd/cbfs.c b/cmd/cbfs.c
index 736f8c4527..f5ad04c45a 100644
--- a/cmd/cbfs.c
+++ b/cmd/cbfs.c
@@ -113,6 +113,9 @@ static int do_cbfs_ls(cmd_tbl_t *cmdtp, int flag, int argc,
printf(" %8d", file_cbfs_size(file));
 
switch (type) {
+   case CBFS_COMPONENT_CBFSHEADER:
+   type_name = "cbfs header";
+   break;
case CBFS_TYPE_STAGE:
type_name = "stage";
break;
diff --git a/fs/cbfs/cbfs.c b/fs/cbfs/cbfs.c
index 46da8f134f..389f60702b 100644
--- a/fs/cbfs/cbfs.c
+++ b/fs/cbfs/cbfs.c
@@ -97,10 +97,12 @@ static int file_cbfs_next_file(u8 *start, u32 size, u32 
align,
}
 
swap_file_header(&header, fileHeader);
-   if (header.offset < sizeof(struct cbfs_fileheader) ||
-   header.offset > header.len) {
-   file_cbfs_result = CBFS_BAD_FILE;
-   return -1;
+   if (header.type != CBFS_COMPONENT_CBFSHEADER) {
+   if (header.offset < sizeof(struct cbfs_fileheader) ||
+   header.offset > header.len) {
+   file_cbfs_result = CBFS_BAD_FILE;
+   return -1;
+   }
}
newNode->next = NULL;
newNode->type = header.type;
diff --git a/include/cbfs.h b/include/cbfs.h
index f50280107b..d5d9d8ce97 100644
--- a/include/cbfs.h
+++ b/include/cbfs.h
@@ -19,6 +19,7 @@ enum cbfs_result {
 };
 
 enum cbfs_filetype {
+   CBFS_COMPONENT_CBFSHEADER = 0x02,
CBFS_TYPE_STAGE = 0x10,
CBFS_TYPE_PAYLOAD = 0x20,
CBFS_TYPE_OPTIONROM = 0x30,
-- 
2.16.1

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

[U-Boot] [PATCH v2 00/11] efi_loader: error handling cmd/bootefi.c

This patch series is focused on providing error checking during the
initialization of the EFI subsystem.

If any of the registrations routines fails bootefi is not executed.
As currently the registration attempt cannot be unroled any further
bootefi call will fail.

Passing a devicetree to bootefi selftest is enabled and a unit test is
supplied.

Heinrich Schuchardt (11):
  efi_loader: efi_smbios_register should have a return value
  efi_loader: return efi_status_t from efi_gop_register
  efi_loader: return efi_status_t from efi_net_register
  efi_loader: consistently return efi_status_t efi_watchdog_register
  efi_loader: simplify calling efi_init_obj_list
  efi_loader: exit status for efi_reset_system_init
  efi_loader: efi_get_time_init should return status code
  efi_loader: do_bootefi_exec should always return an EFI status code
  efi_loader: check initialization of EFI subsystem is successful
  efi_loader: support device tree for bootefi selftest
  efi_selftest: check installation of the device tree

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c |   4 +-
 arch/arm/mach-bcm283x/reset.c   |   4 +-
 cmd/bootefi.c   | 184 +++
 include/efi_loader.h|  23 ++--
 lib/efi_loader/efi_boottime.c   |   2 +
 lib/efi_loader/efi_gop.c|  34 --
 lib/efi_loader/efi_net.c|  24 ++--
 lib/efi_loader/efi_runtime.c|  18 ++-
 lib/efi_loader/efi_smbios.c |  23 ++--
 lib/efi_loader/efi_watchdog.c   |   4 +-
 lib/efi_selftest/Makefile   |   1 +
 lib/efi_selftest/efi_selftest_fdt.c | 188 
 test/py/tests/test_efi_selftest.py  |  14 +++
 13 files changed, 404 insertions(+), 119 deletions(-)
 create mode 100644 lib/efi_selftest/efi_selftest_fdt.c

-- 
2.15.1

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

[U-Boot] [PATCH v2 01/11] efi_loader: efi_smbios_register should have a return value

Errors may occur inside efi_smbios_register().

- Return a status code.
- Remove unused variables.
- Use constants where applicable.

Suggested-by: Simon Glass 
Signed-off-by: Heinrich Schuchardt 
---
v2
remove a change in unrelated code
resent with this patch series
---
 include/efi_loader.h|  2 +-
 lib/efi_loader/efi_smbios.c | 23 +++
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 07730c3f394..72c83fd5033 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -185,7 +185,7 @@ int efi_net_register(void);
 /* Called by bootefi to make the watchdog available */
 int efi_watchdog_register(void);
 /* Called by bootefi to make SMBIOS tables available */
-void efi_smbios_register(void);
+efi_status_t efi_smbios_register(void);
 
 struct efi_simple_file_system_protocol *
 efi_fs_from_path(struct efi_device_path *fp);
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index ac412e7362a..62e96979021 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -13,20 +13,27 @@
 
 static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
 
-void efi_smbios_register(void)
+/*
+ * Install the SMBIOS table as a configuration table.
+ *
+ * @return status code
+ */
+efi_status_t efi_smbios_register(void)
 {
/* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
-   uint64_t dmi = 0x;
-   /* Reserve 4kb for SMBIOS */
-   uint64_t pages = 1;
-   int memtype = EFI_RUNTIME_SERVICES_DATA;
+   u64 dmi = U32_MAX;
+   efi_status_t ret;
 
-   if (efi_allocate_pages(1, memtype, pages, &dmi) != EFI_SUCCESS)
-   return;
+   /* Reserve 4kiB page for SMBIOS */
+   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
+EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
+   if (ret != EFI_SUCCESS)
+   return ret;
 
/* Generate SMBIOS tables */
write_smbios_table(dmi);
 
/* And expose them to our EFI payload */
-   efi_install_configuration_table(&smbios_guid, (void*)(uintptr_t)dmi);
+   return efi_install_configuration_table(&smbios_guid,
+  (void *)(uintptr_t)dmi);
 }
-- 
2.15.1

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

[U-Boot] [PATCH v2 04/11] efi_loader: consistently return efi_status_t efi_watchdog_register

efi_watchdog_register() should always return a status code and not
a boolean value.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 include/efi_loader.h  | 2 +-
 lib/efi_loader/efi_watchdog.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index dd6ffdc4843..08e6c6fb9c6 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -183,7 +183,7 @@ efi_status_t efi_gop_register(void);
 /* Called by bootefi to make the network interface available */
 efi_status_t efi_net_register(void);
 /* Called by bootefi to make the watchdog available */
-int efi_watchdog_register(void);
+efi_status_t efi_watchdog_register(void);
 /* Called by bootefi to make SMBIOS tables available */
 efi_status_t efi_smbios_register(void);
 
diff --git a/lib/efi_loader/efi_watchdog.c b/lib/efi_loader/efi_watchdog.c
index 35a45dedf84..b1c35a8e29d 100644
--- a/lib/efi_loader/efi_watchdog.c
+++ b/lib/efi_loader/efi_watchdog.c
@@ -59,7 +59,7 @@ efi_status_t efi_set_watchdog(unsigned long timeout)
  *
  * This function is called by efi_init_obj_list()
  */
-int efi_watchdog_register(void)
+efi_status_t efi_watchdog_register(void)
 {
efi_status_t r;
 
@@ -85,5 +85,5 @@ int efi_watchdog_register(void)
printf("ERROR: Failed to set watchdog timer\n");
return r;
}
-   return 0;
+   return EFI_SUCCESS;
 }
-- 
2.15.1

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

[U-Boot] [PATCH v2 11/11] efi_selftest: check installation of the device tree

The unit test checks if a device tree is installed. It requires that the
'compatible' property of the root node exists. If available it prints the
'serial-number' property.

The serial-number property is derived from the environment variable
'serial#'. This can be used to check if the image_setup_libfdt() function
is executed.

A Python test is supplied. It sets a value for serial# and checks that the
selftest shows this as serial-number.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 lib/efi_selftest/Makefile   |   1 +
 lib/efi_selftest/efi_selftest_fdt.c | 188 
 test/py/tests/test_efi_selftest.py  |  14 +++
 3 files changed, 203 insertions(+)
 create mode 100644 lib/efi_selftest/efi_selftest_fdt.c

diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index c4bdbdf6c05..88c44840d52 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -19,6 +19,7 @@ efi_selftest_console.o \
 efi_selftest_devicepath.o \
 efi_selftest_events.o \
 efi_selftest_exitbootservices.o \
+efi_selftest_fdt.o \
 efi_selftest_gop.o \
 efi_selftest_manageprotocols.o \
 efi_selftest_snp.o \
diff --git a/lib/efi_selftest/efi_selftest_fdt.c 
b/lib/efi_selftest/efi_selftest_fdt.c
new file mode 100644
index 000..24db0dcf7d5
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_fdt.c
@@ -0,0 +1,188 @@
+/*
+ * efi_selftest_pos
+ *
+ * Copyright (c) 2018 Heinrich Schuchardt 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ *
+ * Test the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.
+ *
+ * The following services are tested:
+ * OutputString, TestString, SetAttribute.
+ */
+
+#include 
+#include 
+
+static struct efi_boot_services *boottime;
+static const char *fdt;
+
+/* This should be sufficent for */
+#define BUFFERSIZE 0x10
+
+static efi_guid_t fdt_guid = EFI_FDT_GUID;
+
+/*
+ * Convert FDT value to host endianness.
+ *
+ * @valFDT value
+ * @return converted value
+ */
+static uint32_t f2h(fdt32_t val)
+{
+   char *buf = (char *)&val;
+   char i;
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+   /* Swap the bytes */
+   i = buf[0]; buf[0] = buf[3]; buf[3] = i;
+   i = buf[1]; buf[1] = buf[2]; buf[2] = i;
+#endif
+   return *(uint32_t *)buf;
+}
+
+/*
+ * Return the value of a property of the FDT root node.
+ *
+ * @name   name of the property
+ * @return value of the property
+ */
+static char *get_property(const u16 *property)
+{
+   struct fdt_header *header = (struct fdt_header *)fdt;
+   const fdt32_t *pos;
+   const char *strings;
+
+   if (!header)
+   return NULL;
+
+   if (f2h(header->magic) != FDT_MAGIC) {
+   printf("Wrong magic\n");
+   return NULL;
+   }
+
+   pos = (fdt32_t *)(fdt + f2h(header->off_dt_struct));
+   strings = fdt + f2h(header->off_dt_strings);
+
+   for (;;) {
+   switch (f2h(pos[0])) {
+   case FDT_BEGIN_NODE: {
+   char *c = (char *)&pos[1];
+   size_t i;
+
+   for (i = 0; c[i]; ++i)
+   ;
+   pos = &pos[2 + (i >> 2)];
+   break;
+   }
+   case FDT_PROP: {
+   struct fdt_property *prop = (struct fdt_property *)pos;
+   const char *label = &strings[f2h(prop->nameoff)];
+   efi_status_t ret;
+
+   /* Check if this is the property to be returned */
+   if (!efi_st_strcmp_16_8(property, label)) {
+   char *str;
+   efi_uintn_t len = f2h(prop->len);
+
+   if (!len)
+   return NULL;
+   /*
+* The string might not be 0 terminated.
+* It is safer to make a copy.
+*/
+   ret = boottime->allocate_pool(
+   EFI_LOADER_DATA, len + 1,
+   (void **)&str);
+   if (ret != EFI_SUCCESS) {
+   efi_st_printf("AllocatePool failed\n");
+   return NULL;
+   }
+   boottime->copy_mem(str, &pos[3], len);
+   str[len] = 0;
+
+   return str;
+   }
+
+   pos = &pos[3 + ((f2h(prop->len) + 3) >> 2)];
+   break;
+   }
+   case FDT_NOP:
+   pos = &pos[1];
+   break;
+   default:
+   return NULL;
+   }
+   }
+}
+
+/*
+ * Setup unit test.
+ *
+

[U-Boot] [PATCH v2 02/11] efi_loader: return efi_status_t from efi_gop_register

All initialization routines should return a status code instead of
a boolean.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 include/efi_loader.h |  2 +-
 lib/efi_loader/efi_gop.c | 34 ++
 2 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 72c83fd5033..779b8bde2e3 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -179,7 +179,7 @@ int efi_disk_create_partitions(efi_handle_t parent, struct 
blk_desc *desc,
   const char *if_typename, int diskid,
   const char *pdevname);
 /* Called by bootefi to make GOP (graphical) interface available */
-int efi_gop_register(void);
+efi_status_t efi_gop_register(void);
 /* Called by bootefi to make the network interface available */
 int efi_net_register(void);
 /* Called by bootefi to make the watchdog available */
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 3caddd5f844..91b0b6a064b 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -125,8 +125,13 @@ efi_status_t EFIAPI gop_blt(struct efi_gop *this, void 
*buffer,
return EFI_EXIT(EFI_SUCCESS);
 }
 
-/* This gets called from do_bootefi_exec(). */
-int efi_gop_register(void)
+/*
+ * Install graphical output protocol.
+ *
+ * If no supported video device exists this is not considered as an
+ * error.
+ */
+efi_status_t efi_gop_register(void)
 {
struct efi_gop_obj *gopobj;
u32 bpix, col, row;
@@ -136,12 +141,15 @@ int efi_gop_register(void)
 
 #ifdef CONFIG_DM_VIDEO
struct udevice *vdev;
+   struct video_priv *priv;
 
/* We only support a single video output device for now */
-   if (uclass_first_device(UCLASS_VIDEO, &vdev) || !vdev)
-   return -1;
+   if (uclass_first_device(UCLASS_VIDEO, &vdev) || !vdev) {
+   printf("WARNING: No video device\n");
+   return EFI_SUCCESS;
+   }
 
-   struct video_priv *priv = dev_get_uclass_priv(vdev);
+   priv = dev_get_uclass_priv(vdev);
bpix = priv->bpix;
col = video_get_xsize(vdev);
row = video_get_ysize(vdev);
@@ -170,13 +178,14 @@ int efi_gop_register(void)
break;
default:
/* So far, we only work in 16 or 32 bit mode */
-   return -1;
+   printf("WARNING: Unsupported video mode\n");
+   return EFI_SUCCESS;
}
 
gopobj = calloc(1, sizeof(*gopobj));
if (!gopobj) {
printf("ERROR: Out of memory\n");
-   return 1;
+   return EFI_OUT_OF_RESOURCES;
}
 
/* Hook up to the device list */
@@ -186,8 +195,8 @@ int efi_gop_register(void)
ret = efi_add_protocol(gopobj->parent.handle, &efi_gop_guid,
   &gopobj->ops);
if (ret != EFI_SUCCESS) {
-   printf("ERROR: Out of memory\n");
-   return 1;
+   printf("ERROR: Failure adding gop protocol\n");
+   return ret;
}
gopobj->ops.query_mode = gop_query_mode;
gopobj->ops.set_mode = gop_set_mode;
@@ -199,10 +208,11 @@ int efi_gop_register(void)
gopobj->mode.info_size = sizeof(gopobj->info);
 
 #ifdef CONFIG_DM_VIDEO
-   if (bpix == VIDEO_BPP32) {
+   if (bpix == VIDEO_BPP32)
 #else
-   if (bpix == LCD_COLOR32) {
+   if (bpix == LCD_COLOR32)
 #endif
+   {
/* With 32bit color space we can directly expose the fb */
gopobj->mode.fb_base = fb_base;
gopobj->mode.fb_size = fb_size;
@@ -217,5 +227,5 @@ int efi_gop_register(void)
gopobj->bpix = bpix;
gopobj->fb = fb;
 
-   return 0;
+   return EFI_SUCCESS;
 }
-- 
2.15.1

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

[U-Boot] [PATCH v2 05/11] efi_loader: simplify calling efi_init_obj_list

efi_init_obj_list() should be executed only once.

Rather than having the caller check this variable and the callee set it,
move all access to the variable inside the function. This reduces the
logic needed to call efi_init_obj_list().

Suggested-by: Simon Glass 
Signed-off-by: Heinrich Schuchardt 
---
v2
no change, patch resent
---
 cmd/bootefi.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 2106ed9c8c8..dff86cf9f9a 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -22,7 +22,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static uint8_t efi_obj_list_initalized;
+static u8 efi_obj_list_initialized;
 
 static struct efi_device_path *bootefi_image_path;
 static struct efi_device_path *bootefi_device_path;
@@ -30,7 +30,10 @@ static struct efi_device_path *bootefi_device_path;
 /* Initialize and populate EFI object list */
 static void efi_init_obj_list(void)
 {
-   efi_obj_list_initalized = 1;
+   /* Initialize once only */
+   if (efi_obj_list_initialized)
+   return;
+   efi_obj_list_initialized = 1;
 
/* Initialize EFI driver uclass */
efi_driver_init();
@@ -184,8 +187,7 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
}
 
/* Initialize and populate EFI object list */
-   if (!efi_obj_list_initalized)
-   efi_init_obj_list();
+   efi_init_obj_list();
 
efi_setup_loaded_image(&loaded_image_info, &loaded_image_info_obj,
   device_path, image_path);
@@ -284,8 +286,7 @@ static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)
efi_status_t r;
 
/* Initialize and populate EFI object list */
-   if (!efi_obj_list_initalized)
-   efi_init_obj_list();
+   efi_init_obj_list();
 
/*
 * gd lives in a fixed register which may get clobbered while we execute
@@ -350,8 +351,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 */
efi_save_gd();
/* Initialize and populate EFI object list */
-   if (!efi_obj_list_initalized)
-   efi_init_obj_list();
+   efi_init_obj_list();
/* Transfer environment variable efi_selftest as load options */
set_load_options(&loaded_image_info, "efi_selftest");
/* Execute the test */
-- 
2.15.1

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

[U-Boot] [PATCH v2 07/11] efi_loader: efi_get_time_init should return status code

All EFI initialization functions should return a status code.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 include/efi_loader.h | 2 +-
 lib/efi_loader/efi_runtime.c | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 199077d295d..85a47ca2f5e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -361,7 +361,7 @@ efi_status_t efi_reset_system_init(void);
 efi_status_t __efi_runtime EFIAPI efi_get_time(
struct efi_time *time,
struct efi_time_cap *capabilities);
-void efi_get_time_init(void);
+efi_status_t efi_get_time_init(void);
 
 #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
 /*
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 85f85711ddc..c59d161c8fe 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -147,8 +147,9 @@ efi_status_t __weak __efi_runtime EFIAPI efi_get_time(
return EFI_DEVICE_ERROR;
 }
 
-void __weak efi_get_time_init(void)
+efi_status_t __weak efi_get_time_init(void)
 {
+   return EFI_SUCCESS;
 }
 
 struct efi_runtime_detach_list_struct {
-- 
2.15.1

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

[U-Boot] [PATCH v2 06/11] efi_loader: exit status for efi_reset_system_init

efi_reset_system_init provides the architecture or board specific
initialization of the EFI subsystem. Errors should be caught and
signalled by a return code.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c |  4 ++--
 arch/arm/mach-bcm283x/reset.c   |  4 ++--
 include/efi_loader.h| 11 ---
 lib/efi_loader/efi_runtime.c| 15 ---
 4 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 70a60709357..702c6b69565 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -654,9 +654,9 @@ void __efi_runtime EFIAPI efi_reset_system(
while (1) { }
 }
 
-void efi_reset_system_init(void)
+efi_status_t efi_reset_system_init(void)
 {
-   efi_add_runtime_mmio(&rstcr, sizeof(*rstcr));
+   return efi_add_runtime_mmio(&rstcr, sizeof(*rstcr));
 }
 
 #endif
diff --git a/arch/arm/mach-bcm283x/reset.c b/arch/arm/mach-bcm283x/reset.c
index b62cb8a51ee..5b83fdf43d6 100644
--- a/arch/arm/mach-bcm283x/reset.c
+++ b/arch/arm/mach-bcm283x/reset.c
@@ -82,9 +82,9 @@ void __efi_runtime EFIAPI efi_reset_system(
while (1) { }
 }
 
-void efi_reset_system_init(void)
+efi_status_t efi_reset_system_init(void)
 {
-   efi_add_runtime_mmio(&wdog_regs, sizeof(*wdog_regs));
+   return efi_add_runtime_mmio(&wdog_regs, sizeof(*wdog_regs));
 }
 
 #endif
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 08e6c6fb9c6..199077d295d 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -346,7 +346,7 @@ static inline int guidcmp(const efi_guid_t *g1, const 
efi_guid_t *g2)
 
 /* Call this with mmio_ptr as the _pointer_ to a pointer to an MMIO region
  * to make it available at runtime */
-void efi_add_runtime_mmio(void *mmio_ptr, u64 len);
+efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len);
 
 /* Boards may provide the functions below to implement RTS functionality */
 
@@ -354,7 +354,9 @@ void __efi_runtime EFIAPI efi_reset_system(
enum efi_reset_type reset_type,
efi_status_t reset_status,
unsigned long data_size, void *reset_data);
-void efi_reset_system_init(void);
+
+/* Architecture specific initialization of the EFI subsystem */
+efi_status_t efi_reset_system_init(void);
 
 efi_status_t __efi_runtime EFIAPI efi_get_time(
struct efi_time *time,
@@ -388,7 +390,10 @@ void *efi_bootmgr_load(struct efi_device_path 
**device_path,
 /* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
 #define __efi_runtime_data
 #define __efi_runtime
-static inline void efi_add_runtime_mmio(void *mmio_ptr, u64 len) { }
+static inline efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len)
+{
+   return EFI_SUCCESS;
+}
 
 /* No loader configured, stub out EFI_ENTRY */
 static inline void efi_restore_gd(void) { }
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index ccb4fc6141b..85f85711ddc 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -134,8 +134,9 @@ void __weak __efi_runtime EFIAPI efi_reset_system(
while (1) { }
 }
 
-void __weak efi_reset_system_init(void)
+efi_status_t __weak efi_reset_system_init(void)
 {
+   return EFI_SUCCESS;
 }
 
 efi_status_t __weak __efi_runtime EFIAPI efi_get_time(
@@ -332,18 +333,26 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
return EFI_EXIT(EFI_INVALID_PARAMETER);
 }
 
-void efi_add_runtime_mmio(void *mmio_ptr, u64 len)
+efi_status_t efi_add_runtime_mmio(void *mmio_ptr, u64 len)
 {
struct efi_runtime_mmio_list *newmmio;
+   efi_status_t ret;
 
u64 pages = (len + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
-   efi_add_memory_map(*(uintptr_t *)mmio_ptr, pages, EFI_MMAP_IO, false);
+   ret = efi_add_memory_map(*(uintptr_t *)mmio_ptr, pages, EFI_MMAP_IO,
+false);
+   if (ret != EFI_SUCCESS)
+   return ret;
 
newmmio = calloc(1, sizeof(*newmmio));
+   if (!newmmio)
+   return EFI_OUT_OF_RESOURCES;
newmmio->ptr = mmio_ptr;
newmmio->paddr = *(uintptr_t *)mmio_ptr;
newmmio->len = len;
list_add_tail(&newmmio->link, &efi_runtime_mmio);
+
+   return ret;
 }
 
 /*
-- 
2.15.1

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

[U-Boot] [PATCH v2 10/11] efi_loader: support device tree for bootefi selftest

The second argument of the bootefi command should always be usable to
specify a device tree. This was missing for bootefi selftest and
bootefi hello.

Proper error handling is added.

Signed-off-by: Heinrich Schuchardt 
---
v2
new patch
---
 cmd/bootefi.c | 109 --
 include/efi_loader.h  |   2 +
 lib/efi_loader/efi_boottime.c |   2 +
 3 files changed, 67 insertions(+), 46 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3df1d3fbd07..357543b7750 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -178,11 +178,49 @@ static efi_status_t efi_run_in_el2(EFIAPI efi_status_t 
(*entry)(
 }
 #endif
 
+static efi_status_t efi_install_fdt(void *fdt)
+{
+   bootm_headers_t img = { 0 };
+   ulong fdt_pages, fdt_size, fdt_start, fdt_end;
+   efi_status_t ret;
+
+   if (fdt_check_header(fdt)) {
+   printf("ERROR: invalid device tree\n");
+   return EFI_INVALID_PARAMETER;
+   }
+
+   /* Prepare fdt for payload */
+   fdt = copy_fdt(fdt);
+   if (!fdt)
+   return EFI_OUT_OF_RESOURCES;
+
+   if (image_setup_libfdt(&img, fdt, 0, NULL)) {
+   printf("ERROR: failed to process device tree\n");
+   return EFI_LOAD_ERROR;
+   }
+
+   /* Link to it in the efi tables */
+   ret = efi_install_configuration_table(&efi_guid_fdt, fdt);
+   if (ret != EFI_SUCCESS)
+   return EFI_OUT_OF_RESOURCES;
+
+   /* And reserve the space in the memory map */
+   fdt_start = ((ulong)fdt) & ~EFI_PAGE_MASK;
+   fdt_end = ((ulong)fdt) + fdt_totalsize(fdt);
+   fdt_size = (fdt_end - fdt_start) + EFI_PAGE_MASK;
+   fdt_pages = fdt_size >> EFI_PAGE_SHIFT;
+   /* Give a bootloader the chance to modify the device tree */
+   fdt_pages += 2;
+   ret = efi_add_memory_map(fdt_start, fdt_pages,
+EFI_BOOT_SERVICES_DATA, true);
+   return ret;
+}
+
 /*
  * Load an EFI payload into a newly allocated piece of memory, register all
  * EFI objects it would want to access and jump to it.
  */
-static efi_status_t do_bootefi_exec(void *efi, void *fdt,
+static efi_status_t do_bootefi_exec(void *efi,
struct efi_device_path *device_path,
struct efi_device_path *image_path)
 {
@@ -193,9 +231,6 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
 
EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
 struct efi_system_table *st);
-   ulong fdt_pages, fdt_size, fdt_start, fdt_end;
-   const efi_guid_t fdt_guid = EFI_FDT_GUID;
-   bootm_headers_t img = { 0 };
 
/*
 * Special case for efi payload not loaded from disk, such as
@@ -220,32 +255,6 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
 */
efi_save_gd();
 
-   if (fdt && !fdt_check_header(fdt)) {
-   /* Prepare fdt for payload */
-   fdt = copy_fdt(fdt);
-
-   if (image_setup_libfdt(&img, fdt, 0, NULL)) {
-   printf("ERROR: Failed to process device tree\n");
-   return -EINVAL;
-   }
-
-   /* Link to it in the efi tables */
-   efi_install_configuration_table(&fdt_guid, fdt);
-
-   /* And reserve the space in the memory map */
-   fdt_start = ((ulong)fdt) & ~EFI_PAGE_MASK;
-   fdt_end = ((ulong)fdt) + fdt_totalsize(fdt);
-   fdt_size = (fdt_end - fdt_start) + EFI_PAGE_MASK;
-   fdt_pages = fdt_size >> EFI_PAGE_SHIFT;
-   /* Give a bootloader the chance to modify the device tree */
-   fdt_pages += 2;
-   efi_add_memory_map(fdt_start, fdt_pages,
-  EFI_BOOT_SERVICES_DATA, true);
-   } else {
-   printf("WARNING: Invalid device tree, expect boot to fail\n");
-   efi_install_configuration_table(&fdt_guid, NULL);
-   }
-
/* Transfer environment variable bootargs as load options */
set_load_options(&loaded_image_info, "bootargs");
/* Load the EFI payload */
@@ -301,7 +310,7 @@ exit:
return ret;
 }
 
-static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)
+static int do_bootefi_bootmgr_exec(void)
 {
struct efi_device_path *device_path, *file_path;
void *addr;
@@ -318,7 +327,7 @@ static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)
return 1;
 
printf("## Starting EFI application at %p ...\n", addr);
-   r = do_bootefi_exec(addr, (void *)fdt_addr, device_path, file_path);
+   r = do_bootefi_exec(addr, device_path, file_path);
printf("## Application terminated, r = %lu\n",
   r & ~EFI_ERROR_MASK);
 
@@ -331,9 +340,10 @@ static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)
 /* Interpreter comman

[U-Boot] [PATCH v2 08/11] efi_loader: do_bootefi_exec should always return an EFI status code

The return type of do_bootefi_exec() is efi_status_t. So in case
of an error we should always return an EFI status code.

Signed-off-by: Heinrich Schuchardt 
---
v2
no change, patch resent
---
 cmd/bootefi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index dff86cf9f9a..7d4100ceeb9 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -164,7 +164,7 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
struct efi_loaded_image loaded_image_info = {};
struct efi_object loaded_image_info_obj = {};
struct efi_device_path *memdp = NULL;
-   ulong ret;
+   efi_status_t ret;
 
EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
 struct efi_system_table *st);
@@ -229,7 +229,7 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
/* Load the EFI payload */
entry = efi_load_pe(efi, &loaded_image_info);
if (!entry) {
-   ret = -ENOENT;
+   ret = EFI_LOAD_ERROR;
goto exit;
}
 
-- 
2.15.1

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

[U-Boot] [PATCH v2 09/11] efi_loader: check initialization of EFI subsystem is successful

Up to now errors in the initialization of the EFI subsystems was not
checked.

If any initialization fails, leave the bootefi command.

We do not retry initialization because this would require to undo all prior
initalization steps.

Suggested-by: Simon Glass 
Signed-off-by: Heinrich Schuchardt 
---
v2
no change, patch resent
---
 cmd/bootefi.c | 67 +--
 1 file changed, 47 insertions(+), 20 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 7d4100ceeb9..3df1d3fbd07 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -22,40 +22,65 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static u8 efi_obj_list_initialized;
+#define OBJ_LIST_NOT_INITIALIZED 1
+
+static efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
 
 static struct efi_device_path *bootefi_image_path;
 static struct efi_device_path *bootefi_device_path;
 
 /* Initialize and populate EFI object list */
-static void efi_init_obj_list(void)
+efi_status_t efi_init_obj_list(void)
 {
+   efi_status_t ret = EFI_SUCCESS;
+
/* Initialize once only */
-   if (efi_obj_list_initialized)
-   return;
-   efi_obj_list_initialized = 1;
+   if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
+   return efi_obj_list_initialized;
 
/* Initialize EFI driver uclass */
-   efi_driver_init();
+   ret = efi_driver_init();
+   if (ret != EFI_SUCCESS)
+   goto out;
 
-   efi_console_register();
+   ret = efi_console_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #ifdef CONFIG_PARTITIONS
-   efi_disk_register();
+   ret = efi_disk_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #endif
 #if defined(CONFIG_LCD) || defined(CONFIG_DM_VIDEO)
-   efi_gop_register();
+   ret = efi_gop_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #endif
 #ifdef CONFIG_NET
-   efi_net_register();
+   ret = efi_net_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #endif
 #ifdef CONFIG_GENERATE_SMBIOS_TABLE
-   efi_smbios_register();
+   ret = efi_smbios_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 #endif
-   efi_watchdog_register();
+   ret = efi_watchdog_register();
+   if (ret != EFI_SUCCESS)
+   goto out;
 
/* Initialize EFI runtime services */
-   efi_reset_system_init();
-   efi_get_time_init();
+   ret = efi_reset_system_init();
+   if (ret != EFI_SUCCESS)
+   goto out;
+   ret = efi_get_time_init();
+   if (ret != EFI_SUCCESS)
+   goto out;
+
+out:
+   efi_obj_list_initialized = ret;
+   return ret;
 }
 
 /*
@@ -186,9 +211,6 @@ static efi_status_t do_bootefi_exec(void *efi, void *fdt,
assert(device_path && image_path);
}
 
-   /* Initialize and populate EFI object list */
-   efi_init_obj_list();
-
efi_setup_loaded_image(&loaded_image_info, &loaded_image_info_obj,
   device_path, image_path);
 
@@ -285,9 +307,6 @@ static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)
void *addr;
efi_status_t r;
 
-   /* Initialize and populate EFI object list */
-   efi_init_obj_list();
-
/*
 * gd lives in a fixed register which may get clobbered while we execute
 * the payload. So save it here and restore it on every callback entry
@@ -316,6 +335,14 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
unsigned long addr, fdt_addr = 0;
efi_status_t r;
 
+   /* Initialize EFI drivers */
+   r = efi_init_obj_list();
+   if (r != EFI_SUCCESS) {
+   printf("Error: Cannot set up EFI drivers, r = %lu\n",
+  r & ~EFI_ERROR_MASK);
+   return CMD_RET_FAILURE;
+   }
+
if (argc < 2)
return CMD_RET_USAGE;
 #ifdef CONFIG_CMD_BOOTEFI_HELLO
-- 
2.15.1

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

[U-Boot] [PATCH v2 03/11] efi_loader: return efi_status_t from efi_net_register