Re: [U-Boot] [PATCH 29/40] x86: Support TPL in Intel common code

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> Update the Makefie rules to ensure that the correct files are built when
> TPL is being used.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/intel_common/Makefile | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>

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

Re: [U-Boot] [PATCH 39/40] x86: Fix device-tree indentation

[Bin Meng]

On Wed, Jan 30, 2019 at 12:01 PM Simon Glass  wrote:
>
> With the use of a phandle we can outdent the device tree nodes a little.
> Fix this.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/dts/u-boot.dtsi | 147 +++
>  1 file changed, 73 insertions(+), 74 deletions(-)
>

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

Re: [U-Boot] [PATCH 28/40] x86: Add a sysreset driver for the Intel PCH

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> Intel SoCs support a fairly stardard reset mechanism which can support
> powering off the device. Add support for this and enable it by default on
> broadwell, which already has the necessary pm.h header file.
>
> This driver augments the standard x86 sysreset driver.
>

I think we need update the existing sysreset_x86 driver to support
SYSRESET_POWER_OFF, instead of creating a new driver to do such.

We can add a new PCH ioctl code to get the pmbase, and do the ACPI
power off in the sysreset_x86 driver.

> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/broadwell/Kconfig|   1 +
>  drivers/sysreset/Kconfig  |   9 ++
>  drivers/sysreset/Makefile |   1 +
>  drivers/sysreset/sysreset_intel_pch.c | 125 ++
>  4 files changed, 136 insertions(+)
>  create mode 100644 drivers/sysreset/sysreset_intel_pch.c
>

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

Re: [U-Boot] [PATCH 36/40] x86: samus: Update device tree for verified boot

[Bin Meng]

On Wed, Jan 30, 2019 at 12:01 PM Simon Glass  wrote:
>
> Add nvdata drivers for the TPM and RTC as used on samus. These are needed
> for Chromium OS verified boot on samus.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/dts/chromebook_samus.dts | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
>

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

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

[Bin Meng]

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

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> When the MRC cache fails to save it is useful to have some debugging info
> to indicate what when wrong. Add some more debug() calls.

what went wrong.

>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/lib/mrccache.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
>

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add an implementation of arch_cpu_init_f() so that the x86 SPL code builds
> and identifies the CPU.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/intel_common/Makefile   |  6 ++
>  arch/x86/cpu/intel_common/cpu_from_spl.c | 27 
>  2 files changed, 33 insertions(+)
>  create mode 100644 arch/x86/cpu/intel_common/cpu_from_spl.c
>

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

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

[Bin Meng]

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

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

Re: [U-Boot] [PATCH 33/40] x86: sysreset: Implement the get_last() method

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:01 PM Simon Glass  wrote:
>
> Add a default implementation of this method which always indicates that
> the last reset was a power-on reset. This is the most likely type of reset
> and without a PCH-specific driver we cannot determine any other type.
>

See my comments for patch [28/40]. We can return the correct reset
type based on whether PCH provided ioctl for pmbase address.

> Signed-off-by: Simon Glass 
> ---
>
>  drivers/sysreset/sysreset_x86.c | 6 ++
>  1 file changed, 6 insertions(+)
>

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

Re: [U-Boot] [PATCH 38/40] x86: Update device tree for Chromium OS verified boot

[Bin Meng]

On Wed, Jan 30, 2019 at 12:01 PM Simon Glass  wrote:
>
> The standard image generated by U-Boot on x86 is u-boot.rom. Add a
> separate image called image.bin for verified boot. This supports
> verification in TPL of which SPL/U-Boot to start, then jumping to the
> correct one, with SPL setting up the SDRAM and U-Boot proper providing
> the user interface if needed.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/dts/u-boot.dtsi | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
>

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

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

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> When a previous phase of U-Boot has run we need to adjust the init of
> subsequent states to avoid messing up the CPU state.
>
> Add a new version of the start logic for SPL, when it boots from TPL
> (start_from tpl.c) and a new version for U-Boot when it boots from SPL.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/Makefile | 12 ++
>  arch/x86/cpu/Makefile | 15 +++-
>  arch/x86/cpu/start_from_spl.S | 71 +++
>  arch/x86/cpu/start_from_tpl.S | 50 
>  4 files changed, 147 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/cpu/start_from_spl.S
>  create mode 100644 arch/x86/cpu/start_from_tpl.S
>
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index fec14847cc..9fd6cf2d3b 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -4,9 +4,21 @@ ifeq ($(CONFIG_EFI_APP),)
>  ifdef CONFIG_$(SPL_)X86_64
>  head-y := arch/x86/cpu/start64.o
>  else
> +ifeq ($(CONFIG_$(SPL_TPL_)X86_16BIT_INIT),y)
>  head-y := arch/x86/cpu/start.o
> +else
> +ifndef CONFIG_SPL
> +head-y := arch/x86/cpu/start.o
> +else
> +ifdef CONFIG_SPL_BUILD
> +head-y = arch/x86/cpu/start_from_tpl.o
> +else
> +head-y = arch/x86/cpu/start_from_spl.o
> +endif
> +endif
>  endif
>  endif
> +endif # EFI
>
>  head-$(CONFIG_$(SPL_)X86_16BIT_INIT) += arch/x86/cpu/start16.o
>  head-$(CONFIG_$(SPL_)X86_16BIT_INIT) += arch/x86/cpu/resetvec.o
> diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
> index 54668aab24..85fd5e616e 100644
> --- a/arch/x86/cpu/Makefile
> +++ b/arch/x86/cpu/Makefile
> @@ -9,9 +9,22 @@
>  ifeq ($(CONFIG_$(SPL_)X86_64),y)
>  extra-y= start64.o
>  else
> +ifeq ($(CONFIG_$(SPL_TPL_)X86_16BIT_INIT),y)
>  extra-y= start.o
> +else
> +ifndef CONFIG_SPL
> +extra-y= start.o
> +else
> +ifdef CONFIG_SPL_BUILD
> +extra-y= start_from_tpl.o
> +else
> +extra-y= start_from_spl.o
>  endif
> -extra-$(CONFIG_$(SPL_)X86_16BIT_INIT) += resetvec.o start16.o
> +endif
> +endif
> +endif
> +
> +extra-$(CONFIG_$(SPL_TPL_)X86_16BIT_INIT) += resetvec.o start16.o
>
>  obj-y  += cpu.o cpu_x86.o
>
> diff --git a/arch/x86/cpu/start_from_spl.S b/arch/x86/cpu/start_from_spl.S

Is it possible to consolidate start_from_spl.S and start_from_tpl.S
into one file, to save some duplicates?

> new file mode 100644
> index 00..4d4e5d0758
> --- /dev/null
> +++ b/arch/x86/cpu/start_from_spl.S
> @@ -0,0 +1,71 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * 32-bit x86 Startup Code when running from SPL
> + *
> + * Copyright 2018 Google, Inc
> + * Written by Simon Glass 
> + */
> +
> +#include 
> +
> +.section .text.start
> +.code32
> +.globl _start
> +.type _start, @function
> +_start:
> +   /* Set up memory using the existing stack */
> +   movl$(CONFIG_SYS_CAR_ADDR + CONFIG_SYS_CAR_SIZE - 4), %eax
> +#ifdef CONFIG_DCACHE_RAM_MRC_VAR_SIZE
> +   subl$CONFIG_DCACHE_RAM_MRC_VAR_SIZE, %eax
> +#endif
> +   /*
> +* We don't subject CONFIG_DCACHE_RAM_MRC_VAR_SIZE since memory is
> +* already set up. This has the happy side-effect of putting gd in a
> +* new place separate from SPL, so the memset() in
> +* board_init_f_init_reserve() does not cause any problems (otherwise
> +* it would zero out the gd and crash)
> +*/
> +   callboard_init_f_alloc_reserve
> +   mov %eax, %esp
> +
> +   callboard_init_f_init_reserve
> +
> +   xorl%eax, %eax
> +   callboard_init_f
> +   callboard_init_f_r
> +
> +   /* Should not return here */
> +   jmp .
> +
> +.globl board_init_f_r_trampoline
> +.type board_init_f_r_trampoline, @function
> +board_init_f_r_trampoline:
> +   /*
> +* SPL has been executed and SDRAM has been initialised, U-Boot code
> +* has been copied into RAM, BSS has been cleared and relocation
> +* adjustments have been made. It is now time to jump into the in-RAM
> +* copy of U-Boot
> +*
> +* %eax = Address of top of new stack
> +*/
> +
> +   /* Stack grows down from top of SDRAM */
> +   movl%eax, %esp
> +
> +   /* Re-enter U-Boot by calling board_init_f_r() */
> +   callboard_init_f_r
> +
> +die:
> +   hlt
> +   jmp die
> +   hlt
> +
> +   .align 4
> +_dt_ucode_base_size:
> +   /* These next two fields are filled in by binman */
> +.globl ucode_base
> +ucode_base:/* Declared in microcode.h */
> +   .long   0   /* microcode base */
> +.globl ucode_size
> +ucode_size:/* Declared in microcode.h */
> +   .long   0   /* microcode size */
> diff --git a/arch/x86/cpu/start_from_tpl.S b/arch/x86/cpu/start_from_tpl.S
> new file mode 100644
> index 00..e27f39eddf
> --- /dev/null
> +++ b/arch/x86/cpu/start_from_tpl.S
> @@ -0,0 +1,50 @@
> +/* SPDX-License-Identif

Re: [U-Boot] [PATCH 32/40] x86: Support PCI VGA ROM when TPL is used

[Bin Meng]

On Wed, Jan 30, 2019 at 12:01 PM Simon Glass  wrote:
>
> When TPL is in use, U-Boot proper should support initing the VGA ROM even
> though the 32-bit init portion is in SPL. Update the condition to handle
> this.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/pci/pci_rom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

Re: [U-Boot] [PATCH 35/40] x86: samus: Update device tree for SPL

[Bin Meng]

On Wed, Jan 30, 2019 at 12:01 PM Simon Glass  wrote:
>
> Add tags to allow required nodes to be present in SPL / TPL. Also enable
> the sysreset driver.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/dts/chromebook_samus.dts | 38 +++
>  1 file changed, 34 insertions(+), 4 deletions(-)
>

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

Re: [U-Boot] [PATCH 34/40] x86: Add documention on the samus flashmap

[Bin Meng]

On Wed, Jan 30, 2019 at 12:01 PM Simon Glass  wrote:
>
> There are quite a few variables which control where things appear in the
> final ROM image. Add a flashmap in the documentation to make this easier
> to figure out.
>
> Signed-off-by: Simon Glass 
> ---
>
>  doc/README.x86 | 14 ++
>  1 file changed, 14 insertions(+)
>

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

Re: [U-Boot] [PATCH 40/40] x86: samus: Add a target to boot through TPL

[Bin Meng]

On Wed, Jan 30, 2019 at 12:01 PM Simon Glass  wrote:
>
> Add a version of samus which supports booting from TPL to SPL and then
> to U-Boot. This allows TPL to select from an A or B SPL to support
> verified boot with field upgrade.
>
> Signed-off-by: Simon Glass 
> ---
>
>  board/google/Kconfig  |  8 +++
>  board/google/chromebook_samus/Kconfig | 14 +++-
>  board/google/chromebook_samus/MAINTAINERS |  7 ++
>  configs/chromebook_samus_tpl_defconfig| 80 +++
>  include/configs/chromebook_samus.h|  3 +
>  5 files changed, 110 insertions(+), 2 deletions(-)
>  create mode 100644 configs/chromebook_samus_tpl_defconfig
>

Generally it looks good

Reviewed-by: Bin Meng 

But I still need understand the boot sequence of SPL/TPL.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add an arch-specific handoff header so that we can use the HANDOFF feature
> on x86 devices.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/handoff.h | 15 +++
>  1 file changed, 15 insertions(+)
>  create mode 100644 arch/x86/include/asm/handoff.h
>

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

Re: [U-Boot] [PATCH 31/40] x86: Don't generate a bootstage report in SPL

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> This report is normally generated by U-Boot proper. Correct the condition
> here so that it respects the Kconfig options for bootstage.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/lib/bootm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

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

[Bin Meng]

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

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

Re: [U-Boot] [PATCH 26/40] x86: Add a simple TPL implementations

[Bin Meng]

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

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add debugging during SDRAM init so that problems are easier to
> diagnose.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/broadwell/sdram.c | 32 
>  1 file changed, 20 insertions(+), 12 deletions(-)
>

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

Re: [U-Boot] [PATCH 37/40] x86: Update device tree for TPL

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:01 PM Simon Glass  wrote:
>
> Add TPL binaries to the device x86 binman desciption. When enabled, TPL
> will start first, doing the 16-bit init, then jump to SPL and finally
> U-Boot proper.

I am confused by "TPL will start first". My understanding is that
"SPL" starts before "TPL".

>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/dts/u-boot.dtsi | 26 --
>  1 file changed, 24 insertions(+), 2 deletions(-)
>

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

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

[Bin Meng]

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

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

Re: [U-Boot] [PATCH 30/40] x86: Don't set up MTRRs in SPL

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> The MTRRs are normally set up in U-Boot proper, so avoid setting them up
> in SPL as well.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/lib/init_helpers.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> Allow broadwell to build for SPL and include the reference code.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/broadwell/Makefile | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>

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

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

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present SDRAM is always set up in U-Boot proper. Allow this to be done

I don't understand. I thought SDRAM was already set up in the U-Boot
SPL in the 64-bit build. The U-Boot proper needs a MMU table which
resides in RAM, so without RAM being initialized first there is no way
for U-Boot proper to run. Am I missing anything?

> in SPL instead so that U-Boot proper can be loaded into SDRAM and run
> from there. This allows U-Boot to be compressed to reduce space, since
> it is not necessary to run it directly from flash.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/broadwell/Makefile  |  2 +-
>  arch/x86/cpu/broadwell/northbridge.c | 93 
>  arch/x86/cpu/broadwell/sdram.c   | 93 
>  3 files changed, 94 insertions(+), 94 deletions(-)
>

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

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

[Bin Meng]

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

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

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

[Bin Meng]

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

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present only chromebook_link64 supports SPL. It is useful to eb able to
> support both TPL and SPL to implement verified boot on x86.
>
> Enable the options for both along with some suitable default options
> needed to boot through these phases.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/Kconfig | 30 ++
>  arch/x86/Kconfig |  1 -
>  2 files changed, 30 insertions(+), 1 deletion(-)
>

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present many of the functions in this file return -1 as an error
> number. which is -EPERM. Update the code to use real error numbers.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/mp_init.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> There is a typo in this header. Fix it.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/start64.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

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

[Bin Meng]

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

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

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

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> We use binman to build the x86 image now. Update a comment which still
> refers to ifdtool.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/intel_common/car.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

But we should apply the same change in arch/x86/lib/fsp/fsp_car.S too.

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> Add labels for these nodes so that board DT files can reference them.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/dts/reset.dtsi | 2 +-
>  arch/x86/dts/rtc.dtsi   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

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

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

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present only OF_SEPARATE is considered valid for building a device-tree
> file in SPL. However sandbox uses OF_HOSTFILE instead. Update the logic to
> handle this and make it easier to understand.
>
> Signed-off-by: Simon Glass 
> ---
>
>  scripts/Makefile.spl | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 1430d7d851..c9eea629dd 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -255,8 +255,20 @@ else
>  FINAL_DTB_CONTAINER = $(obj)/$(SPL_BIN).multidtb.fit
>  endif
>
> +# Build the .dtb file if:
> +#   - we are not using OF_PLATDATA
> +#   - we are using OF_CONTROL
> +#   - we have either OF_SEPARATE or OF_HOSTFILE

This is not 1:1 translation of the original logic.

The original logic was any two of the 3 macros:
$CONFIG_$(SPL_TPL_)OF_CONTROL, $CONFIG_OF_SEPARATE,
$CONFIG_$(SPL_TPL_)OF_PLATDATA, are defined. But here the new logic is
excluding $CONFIG_$(SPL_TPL_)OF_PLATDATA.

> +build_dtb :=
> +ifeq ($(CONFIG_$(SPL_TPL_)OF_PLATDATA),)
> +ifneq ($(CONFIG_$(SPL_TPL_)OF_CONTROL),)
> +ifeq ($(CONFIG_OF_SEPARATE)$(CONFIG_OF_HOSTFILE),y)
> +build_dtb := y
> +endif
> +endif
> +endif
>
> -ifeq 
> ($(CONFIG_$(SPL_TPL_)OF_CONTROL)$(CONFIG_OF_SEPARATE)$(CONFIG_$(SPL_TPL_)OF_PLATDATA),yy)
> +ifneq ($(build_dtb),)
>  $(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin \
> $(if $(CONFIG_SPL_SEPARATE_BSS),,$(obj)/$(SPL_BIN)-pad.bin) \
> $(FINAL_DTB_CONTAINER)  FORCE
> --

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

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

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> At present sections are always placed automatically. Even if an 'offset'
> property is provided it is ignored. Update the logic to support an offset
> for sections.
>
> Note: Needs a test updates
>
> Signed-off-by: Simon Glass 
> ---
>
>  tools/binman/bsection.py  | 5 +++--
>  tools/binman/etype/section.py | 3 ++-
>  2 files changed, 5 insertions(+), 3 deletions(-)
>

Reviewed-by: Bin Meng 

x86 is not using 'offset' in section so it should be fine. I think we
will need update tools/binman/README to document 'offset' too.

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> Update the condition to translate only if this is enabled for SPL.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/core/ofnode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> An important property is missing. Update the entry comment to include
> this.
>
> Signed-off-by: Simon Glass 
> ---
>
>  tools/binman/etype/vblock.py | 1 +
>  1 file changed, 1 insertion(+)
>

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

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

[Bin Meng]

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> It is not good practice to raise an exception in a constructor. In this
> case the 'text' entry may not actually be used, if -i is used to filter
> out the images that get built.
>
> Move the exception to where the data is actually used.
>
> Signed-off-by: Simon Glass 
> ---
>
>  tools/binman/etype/text.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

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

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

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> This message is not very important since it is simply indicating that the
> user's instructions are being followed. Only show it when the verbosity
> level is above the default.
>
> Signed-off-by: Simon Glass 
> ---
>
>  tools/binman/control.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/binman/control.py b/tools/binman/control.py
> index 3446e2e79c..b32e4e1996 100644
> --- a/tools/binman/control.py
> +++ b/tools/binman/control.py
> @@ -133,8 +133,8 @@ def Binman(options, args):
>  if name not in options.image:
>  del images[name]
>  skip.append(name)
> -if skip:
> -print 'Skipping images: %s\n' % ', '.join(skip)
> +if skip and options.verbosity >= 2:
> +print 'Skipping images: %s' % ', '.join(skip)

Is dropping '\n' intentional?

>
>  state.Prepare(images, dtb)
>
> --

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

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

[Bin Meng]

Hi Simon,

On Wed, Jan 30, 2019 at 12:00 PM Simon Glass  wrote:
>
> Device-tree rules require that aliases use a hyphen rather than a
> underscore. Update the uclass name to fit with this.
>

I don't understand the connection between the uclass name and the DT
aliases. Could you please provide more details?

> Signed-off-by: Simon Glass 
> ---
>

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

Re: [U-Boot] [PATCH v2 8/8] arm: socfpga: implement proper peripheral reset

[Simon Goldschmidt]

On Thu, Feb 21, 2019 at 10:56 PM Marek Vasut  wrote:
>
> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > This commit removes ad-hoc reset handling for peripheral resets from SPL
> > for socfpga gen5.
> >
> > This is done because as U-Boot drivers support reset handling by now.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > Changes in v2:
> > - removed Kconfig option OLD_SOCFPGA_KERNEL_COMPAT since compatibility
> >   now uses an environment variable
> >
> >  arch/arm/mach-socfpga/misc_gen5.c | 10 --
> >  arch/arm/mach-socfpga/spl_gen5.c  | 10 --
> >  2 files changed, 20 deletions(-)
> >
> > diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
> > b/arch/arm/mach-socfpga/misc_gen5.c
> > index 6e11ba6cb2..9865f5b5b1 100644
> > --- a/arch/arm/mach-socfpga/misc_gen5.c
> > +++ b/arch/arm/mach-socfpga/misc_gen5.c
> > @@ -201,16 +201,6 @@ int arch_early_init_r(void)
> >   /* Add device descriptor to FPGA device table */
> >   socfpga_fpga_add(&altera_fpga[0]);
> >
> > -#ifdef CONFIG_DESIGNWARE_SPI
> > - /* Get Designware SPI controller out of reset */
> > - socfpga_per_reset(SOCFPGA_RESET(SPIM0), 0);
> > - socfpga_per_reset(SOCFPGA_RESET(SPIM1), 0);
> > -#endif
> > -
> > -#ifdef CONFIG_NAND_DENALI
> > - socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
> > -#endif
> > -
> >   return 0;
> >  }
> >
> > diff --git a/arch/arm/mach-socfpga/spl_gen5.c 
> > b/arch/arm/mach-socfpga/spl_gen5.c
> > index 1bff8cbfcf..e1e65261eb 100644
> > --- a/arch/arm/mach-socfpga/spl_gen5.c
> > +++ b/arch/arm/mach-socfpga/spl_gen5.c
> > @@ -36,16 +36,12 @@ u32 spl_boot_device(void)
> >   return BOOT_DEVICE_RAM;
> >   case 0x2:   /* NAND Flash (1.8V) */
> >   case 0x3:   /* NAND Flash (3.0V) */
> > - socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
> >   return BOOT_DEVICE_NAND;
> >   case 0x4:   /* SD/MMC External Transceiver (1.8V) */
> >   case 0x5:   /* SD/MMC Internal Transceiver (3.0V) */
> > - socfpga_per_reset(SOCFPGA_RESET(SDMMC), 0);
> > - socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
> >   return BOOT_DEVICE_MMC1;
> >   case 0x6:   /* QSPI Flash (1.8V) */
> >   case 0x7:   /* QSPI Flash (3.0V) */
> > - socfpga_per_reset(SOCFPGA_RESET(QSPI), 0);
> >   return BOOT_DEVICE_SPI;
> >   default:
> >   printf("Invalid boot device (bsel=%08x)!\n", bsel);
> > @@ -99,9 +95,7 @@ void board_init_f(ulong dummy)
> >   socfpga_bridges_reset(1);
> >   }
> >
> > - socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
> >   socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0);
> > -
> >   timer_init();
> >
> >   debug("Reconfigure Clock Manager\n");
> > @@ -123,10 +117,6 @@ void board_init_f(ulong dummy)
> >   sysmgr_pinmux_init();
> >   sysmgr_config_warmrstcfgio(0);
> >
> > - /* De-assert reset for peripherals and bridges based on handoff */
> > - reset_deassert_peripherals_handoff();
> > - socfpga_bridges_reset(0);

I just saw that this line might have unwanted side effects in that it does
not write the enabled bridges bitmask to the 'iswgrp_handoff' registers.
So the 'bridge enable' command might not work.

This whole handoff thing looks somewhat broken to me anyway: the
original Altera U-Boot did it because it obeyed Quartus output, while we
now just always write a constant bitmask here (see socfpga_bridges_reset()).

Regards,
Simon

> > -
> >   debug("Unfreezing/Thaw all I/O banks\n");
> >   /* unfreeze / thaw all IO banks */
> >   sys_mgr_frzctrl_thaw_req();
> >
>
> Nice!
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/8] arm: socfpga: gen5: add reset & sdr node to SPL devicetrees

[Simon Goldschmidt]

On Thu, Feb 21, 2019 at 11:13 PM Marek Vasut  wrote:
>
> On 2/21/19 11:11 PM, Simon Goldschmidt wrote:
> >
> >
> > Am Do., 21. Feb. 2019, 23:05 hat Marek Vasut  > > geschrieben:
> >
> > On 2/21/19 11:03 PM, Simon Goldschmidt wrote:
> > >
> > >
> > > Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > 
> > > >> geschrieben:
> > >
> > > On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > > > The SPL for socfpga gen5 currently takes all peripherals out
> > of reset
> > > > unconditionally. To implement proper reset handling for
> > peripherals,
> > > > the reset node has to be provided with the SPL dts.
> > > >
> > > > In preparation to move the DDR driver to DM, the sdr node is
> > required
> > > > in SPL, too.
> > > >
> > > > This patch adds "u-boot,dm-pre-reloc" to U-Boot specific
> > dtsi addon
> > > > files so that the reset manager and SDR driver correctly
> > probe in SPL.
> > > >
> > > > Signed-off-by: Simon Goldschmidt
> >  > 
> > >  > >>
> > > > ---
> > > >
> > > > Changes in v2: None
> > > >
> > > >  arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi  | 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts | 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_de10_nano.dts| 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_de1_soc.dts  | 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_is1.dts  | 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi| 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi   | 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi | 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_sr1500.dts   | 8
> > 
> > > >  arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi  | 8
> > 
> > > >  11 files changed, 88 insertions(+)
> > > >
> > > > diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > > b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > > > index c44d1ee2fa..8aaec56285 100644
> > > > --- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > > > +++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > > > @@ -17,6 +17,14 @@
> > > >   };
> > > >  };
> > > >
> > > > +&rst {
> > > > + u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > +&sdr {
> > > > + u-boot,dm-pre-reloc;
> > > > +};
> > >
> > > What about some socfpga-common-u-boot.dtsi to avoid duplication ?
> > >
> > >
> > > Right. I tested with 'socfpga-u-boot.dtsi' but the hot included for
> > > gen10 as well.
> >
> > hot included ? I don't think I understand.
> >
> >
> > Argh. I'm writing from my mobile...
>
> It can wait till tomorrow ...
>
> > What I meant was that file got included by the automatism so I couldn't
> > use it.
> Errr, which file ? What automatism ? Really, wait till tomorrow with a
> reply, please.

Let me try again: I started this patch with trying to centralize the
"u-boot,dm-pre-reloc"
lines in one file named "socfpga-u-boot.dtsi" since it is valid for
all gen5 devices
and including it automatically would be OK.

However, the automatism to search for a "-u-boot.dtsi" file caught
that file also for
a10 and even s10 due to the lack of a more specific match.

In the end I dropped that idea and added it to all board dtsi files.

However, by using a name that doesn't match the automatism rules, I
can centralize
these settings. I'll do that for V3.

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

Re: [U-Boot] [PATCH v2 5/8] spi: cadence_qspi: add reset handling

[Simon Goldschmidt]

On Thu, Feb 21, 2019 at 11:14 PM Marek Vasut  wrote:
>
> On 2/21/19 11:04 PM, Simon Goldschmidt wrote:
> >
> >
> > Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > > geschrieben:
> >
> > On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > > This adds reset handling to the cadence qspi driver.
> > >
> > > For backwards compatibility, only a warning is printed when failing to
> > > get reset handles.
> > >
> > > Signed-off-by: Simon Goldschmidt  > >
> > > ---
> > >
> > > Changes in v2:
> > > - add .remove callback to release the resets
> > >
> > >  drivers/spi/cadence_qspi.c | 16 
> > >  drivers/spi/cadence_qspi.h |  4 
> > >  2 files changed, 20 insertions(+)
> > >
> > > diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> > > index 11fce9c4fe..3bfa0201c4 100644
> > > --- a/drivers/spi/cadence_qspi.c
> > > +++ b/drivers/spi/cadence_qspi.c
> > > @@ -8,6 +8,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include "cadence_qspi.h"
> > > @@ -154,10 +155,17 @@ static int cadence_spi_probe(struct udevice
> > *bus)
> > >  {
> > >   struct cadence_spi_platdata *plat = bus->platdata;
> > >   struct cadence_spi_priv *priv = dev_get_priv(bus);
> > > + int ret;
> > >
> > >   priv->regbase = plat->regbase;
> > >   priv->ahbbase = plat->ahbbase;
> > >
> > > + ret = reset_get_bulk(bus, &priv->resets);
> > > + if (ret)
> > > + dev_warn(bus, "Can't get reset: %d\n", ret);
> > > + else
> > > + reset_deassert_bulk(&priv->resets);
> > > +
> > >   if (!priv->qspi_is_init) {
> > >   cadence_qspi_apb_controller_init(plat);
> > >   priv->qspi_is_init = 1;
> > > @@ -166,6 +174,13 @@ static int cadence_spi_probe(struct udevice *bus)
> > >   return 0;
> > >  }
> > >
> > > +static int cadence_spi_remove(struct udevice *dev)
> > > +{
> > > + struct cadence_spi_priv *priv = dev_get_priv(dev);
> > > +
> > > + return reset_release_bulk(&priv->resets);
> > > +}
> > > +
> > >  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
> > >  {
> > >   struct cadence_spi_priv *priv = dev_get_priv(bus);
> > > @@ -342,4 +357,5 @@ U_BOOT_DRIVER(cadence_spi) = {
> > >   .platdata_auto_alloc_size = sizeof(struct cadence_spi_platdata),
> > >   .priv_auto_alloc_size = sizeof(struct cadence_spi_priv),
> > >   .probe = cadence_spi_probe,
> > > + .remove = cadence_spi_remove,
> >
> > .remove() only ever gets executed for drivers setting DM_FLAG_OS_PREPARE
> > flag. Fix this in the other drivers too.
> >
> >
> > Ehrm, I haven't checked, but is this common practice? Why doesn't it
> > always get called?
>
> That's how the code behaves. Probably to speed up booting the kernel on
> devices which don't need to be torn down.

What surprises me is that the OS_PREPARE flag is used only for one spi driver
and for 'mmc_blk' (but this is really new). Is it still the right
thing to do? How could
this be one of the first drivers releasing its reset before boot? :-)

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

Re: [U-Boot] [PATCH v2 6/8] reset: socfpga: add reset handling for old kernels

[Simon Goldschmidt]

On Thu, Feb 21, 2019 at 11:15 PM Marek Vasut  wrote:
>
> On 2/21/19 11:07 PM, Simon Goldschmidt wrote:
> >
> >
> > Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > > geschrieben:
> >
> > On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > > This adds code to take peripherals out of reset based on an
> > environment
> > > variable. This is in preparation for removing the code that does
> > this from
> > > SPL.
> > >
> > > However, some drivers even in current Linux cannot handle
> > peripheral reset,
> > > so until this works, we need a compatibility workaround.
> > >
> > > This workaround is implemented in the 'remove' callback of this reset
> > > driver, which is called on OS_PREPARE: it checks if the environment
> > > variable "socfpga_permodrst_ungate" - if it is set to 1, it
> > deasserts all
> > > peripheral resets, which is what the gen5 SPL did up to now.
> > >
> > > This is in preparation to clean up the SPL and implementing proper
> > reset
> > > handling for U-Boot.
> > >
> > > Signed-off-by: Simon Goldschmidt  > >
> > > ---
> > >
> > > Changes in v2:
> > > - moved from Kernel option "OLD_SOCFPGA_KERNEL_COMPAT" to environment
> > >   variable "socfpga_permodrst_ungate"
> > >
> > >  drivers/reset/reset-socfpga.c | 34 ++
> > >  1 file changed, 34 insertions(+)
> > >
> > > diff --git a/drivers/reset/reset-socfpga.c
> > b/drivers/reset/reset-socfpga.c
> > > index b2acfcd2ec..749f671e05 100644
> > > --- a/drivers/reset/reset-socfpga.c
> > > +++ b/drivers/reset/reset-socfpga.c
> > > @@ -89,6 +89,36 @@ static int socfpga_reset_probe(struct udevice *dev)
> > >   return 0;
> > >  }
> > >
> > > +#ifndef CONFIG_SPL_BUILD
> > > +/*
> > > + * This remove function is called before starting OS to deassert
> > peripheral
> > > + * resets for Kernels that don't support this.
> > > + *
> > > + * The reset driver checks the environment variable
> > "socfpga_permodrst_ungate"
> > > + * when it is removed. If this variable is '1', all peripherals
> > in 'permodrst'
> > > + * are taken out of reset before booting into the OS.
> > > + * This should be required for gen5 systems only that are running
> > Linux kernels
> > > + * without proper peripheral reset support for all drivers used.
> > > + */
> > > +static int socfpga_reset_remove(struct udevice *dev)
> > > +{
> > > + struct socfpga_reset_data *data = dev_get_priv(dev);
> > > + const char *env_str;
> > > + long val;
> > > +
> > > + env_str = env_get("socfpga_permodrst_ungate");
> > > + if (env_str) {
> > > + val = simple_strtol(env_str, NULL, 0);
> > > + if (val == 1) {
> > > + puts("Deasserting all peripheral resets\n");
> > > + writel(0, data->membase + 4);
> > > + }
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +#endif
> > > +
> > >  static const struct udevice_id socfpga_reset_match[] = {
> > >   { .compatible = "altr,rst-mgr" },
> > >   { /* sentinel */ },
> > > @@ -101,4 +131,8 @@ U_BOOT_DRIVER(socfpga_reset) = {
> > >   .probe = socfpga_reset_probe,
> > >   .priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
> > >   .ops = &socfpga_reset_ops,
> > > +#ifndef CONFIG_SPL_BUILD
> > > + .remove = socfpga_reset_remove,
> > > + .flags  = DM_FLAG_OS_PREPARE,
> > > +#endif
> > >  };
> >
> > Does this work if you use Falcon mode ? :)
> >
> >
> > Probably not, but would anyone be able to use falcon mode in socfpga
> > gen5 given the current SPL size? I think it didn't fit for,a last time I
> > checked.
>
> If you cut it down, why not ?
>
> > And if it fits in the future, we probably don't need this workaraound
> > any more...
> >
> > I did it like that since env_get() broke compilation of SPL. But if you
> > insist of making this work even for SPL, I'll check again.
>
> SPL can also check env, so some more conditionals need to be added.
> Should be a matter of some CONFIG_IS_ENABLED()

OK, I'll try that for V3.

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

Re: [U-Boot] [PATCH v2 7/8] arm: socfpga: gen5: deassert peripheral reset by default

[Simon Goldschmidt]

On Thu, Feb 21, 2019 at 11:17 PM Marek Vasut  wrote:
>
> On 2/21/19 11:09 PM, Simon Goldschmidt wrote:
> >
> >
> > Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > > geschrieben:
> >
> > On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > > To keep the current behaviour of taking all peripherals out of reset
> > > before booting the OS before removing that code from socfpga gen5 SPL,
> > > this enables the new behaviour by default for all gen5 boards by
> > adding
> > > the environment variable "socfpga_permodrst_ungate=1" to the default
> > > environment.
> > >
> > > This can be overridden in board config files or by saving an
> > environment
> > > without this variable enabled.
> > >
> > > Signed-off-by: Simon Goldschmidt  > >
> > > ---
> > >
> > > Changes in v2:
> > > - this patch is new in v2
> > >
> > >  include/configs/socfpga_common.h | 14 ++
> > >  1 file changed, 14 insertions(+)
> > >
> > > diff --git a/include/configs/socfpga_common.h
> > b/include/configs/socfpga_common.h
> > > index c9cbf8f5e3..2510c6fd7b 100644
> > > --- a/include/configs/socfpga_common.h
> > > +++ b/include/configs/socfpga_common.h
> > > @@ -321,6 +321,19 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> > >
> > >  #include 
> > >
> > > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > > +/*
> > > + * Handle compatibility for peripheral reset for Linux kernels
> > that haven't
> > > + * implemented peripheral reset for all drivers.
> > > + * Define this to "" disable this compatibility.
> > > + */
> > > +#ifndef SOCFPGA_PERMODRST_UNGATE
> > > +#define SOCFPGA_PERMODRST_UNGATE "socfpga_permodrst_ungate=1\0"
> > > +#endif
> > > +#else
> > > +#define SOCFPGA_PERMODRST_UNGATE ""
> > > +#endif
> >
> > Just add this socfpga_permodrst_ungate to the default end and drop all
> > those macros/Kconfig options.
> >
> >
> > But how would it then be overridden?
>
> User would setenv it to "" and saveenv ? I might be missing something
> obvious.

Of course. I meant how to override it for the default env. E.g. to test on
some boards.

But it's probably enough that CONFIG_EXTRA_ENV_SETTINGS is overridable.

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

[U-Boot] [PATCH] am57xx_evm_defconfig: Enable configs to support QSPI boot

[Vignesh R]

AM57xx IDK EVMs can boot out of QSPI. Enable configs to support QSPI
boot. Also enable configs for updating QSPI boot images over DFU.

Tested on AM572x IDK EVM.

Signed-off-by: Vignesh R 
---
 configs/am57xx_evm_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index 748682036e17..3f73f259751c 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -40,9 +40,13 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_DWC_AHCI=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
+CONFIG_DFU_SF=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x8200
 CONFIG_FASTBOOT_BUF_SIZE=0x2F00
-- 
2.20.1

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

Re: [U-Boot] [PATCH] configs: am57xx_evm: define CONFIG_SPL_LOAD_FIT_ADDRESS for SPL-DFU

[Vignesh R]

Hi Bin,

On 08/02/19 10:31 PM, Bin Liu wrote:
> Define CONFIG_SPL_LOAD_FIT_ADDRESS to enable SPL-DFU for am57x platform.
> 
> Signed-off-by: Bin Liu 
> ---

With this patch DFU args are no longer available at U-Boot prompt

>  include/configs/am57xx_evm.h | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
> index d61fdf9f7a36..70aa4250605b 100644
> --- a/include/configs/am57xx_evm.h
> +++ b/include/configs/am57xx_evm.h
> @@ -35,11 +35,22 @@
>  
>  #define CONFIG_SYS_OMAP_ABE_SYSCK
>  
> +#ifdef CONFIG_SPL_DFU


This should be CONFIG_IS_ENABLED(DFU) so that DFUARGS defined when
CONFIG_DFU=y in U-Boot.

> +#ifndef CONFIG_SPL_BUILD
>  #define DFUARGS \
>   "dfu_bufsiz=0x1\0" \
>   DFU_ALT_INFO_MMC \
>   DFU_ALT_INFO_EMMC \
>   DFU_ALT_INFO_RAM \
> + DFU_ALT_INFO_QSPI
> +#else
> +#undef CONFIG_CMD_BOOTD
> +#define CONFIG_SPL_LOAD_FIT_ADDRESS 0x8020
> +#define DFUARGS \
> + "dfu_bufsiz=0x1\0" \
> + DFU_ALT_INFO_RAM
> +#endif
> +#endif
>  
>  #include 
>  
> 

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

Re: [U-Boot] [PATCH v7 4/7] cmd: efidebug: add drivers command

[AKASHI Takahiro]

On Fri, Feb 22, 2019 at 04:01:52AM +0100, Heinrich Schuchardt wrote:
> On 2/22/19 1:05 AM, AKASHI Takahiro wrote:
> > On Thu, Feb 21, 2019 at 08:32:06PM +0100, Heinrich Schuchardt wrote:
> >> On 2/21/19 7:26 AM, AKASHI Takahiro wrote:
> >>> "drivers" command prints all the uefi drivers on the system.
> >>>
> >>> => efi drivers
> >>> Driver   Name Image Path
> >>>   
> >>> 7ef003d0
> >>>
> >>> Signed-off-by: AKASHI Takahiro 
> >>> ---
> >>>  cmd/efidebug.c | 95 +-
> >>>  1 file changed, 94 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> >>> index 72e0652fc3e4..04fc170867fc 100644
> >>> --- a/cmd/efidebug.c
> >>> +++ b/cmd/efidebug.c
> >>> @@ -89,6 +89,95 @@ static int do_efi_show_devices(cmd_tbl_t *cmdtp, int 
> >>> flag,
> >>>   return CMD_RET_SUCCESS;
> >>>  }
> >>>  
> >>> +/**
> >>> + * efi_get_driver_handle_info() - get information of UEFI driver
> >>> + *
> >>> + * @handle:  Handle of UEFI device
> >>> + * @driver_name: Driver name
> >>> + * @image_path:  Pointer to text of device path
> >>> + * Return:   0 on success, -1 on failure
> >>> + *
> >>> + * Currently return no useful information as all UEFI drivers are
> >>> + * built-in..
> >>> + */
> >>> +static int efi_get_driver_handle_info(efi_handle_t handle, u16 
> >>> **driver_name,
> >>> +   u16 **image_path)
> >>> +{
> >>> + struct efi_handler *handler;
> >>> + struct efi_loaded_image *image;
> >>> + efi_status_t ret;
> >>> +
> >>> + /*
> >>> +  * driver name
> >>> +  * TODO: support EFI_COMPONENT_NAME2_PROTOCOL
> >>> +  */
> >>> + *driver_name = NULL;
> >>> +
> >>> + /* image name */
> >>> + ret = efi_search_protocol(handle, &efi_guid_loaded_image, &handler);
> >>> + if (ret != EFI_SUCCESS) {
> >>> + *image_path = NULL;
> >>> + return 0;
> >>> + }
> >>> +
> >>> + image = handler->protocol_interface;
> >>> + *image_path = efi_dp_str(image->file_path);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>> +/**
> >>> + * do_efi_show_drivers() - show UEFI drivers
> >>> + *
> >>> + * @cmdtp:   Command table
> >>> + * @flag:Command flag
> >>> + * @argc:Number of arguments
> >>> + * @argv:Argument array
> >>> + * Return:   CMD_RET_SUCCESS on success, CMD_RET_RET_FAILURE on 
> >>> failure
> >>> + *
> >>> + * Implement efidebug "drivers" sub-command.
> >>> + * Show all UEFI drivers and their information.
> >>> + */
> >>> +static int do_efi_show_drivers(cmd_tbl_t *cmdtp, int flag,
> >>> +int argc, char * const argv[])
> >>> +{
> >>> + efi_handle_t *handles;
> >>> + efi_uintn_t num, i;
> >>> + u16 *driver_name, *image_path_text;
> >>> + efi_status_t ret;
> >>> +
> >>> + ret = EFI_CALL(BS->locate_handle_buffer(BY_PROTOCOL,
> >>> + &efi_guid_driver_binding_protocol, NULL,
> >>> + &num, &handles));
> >>
> >> nits:
> >>
> >> scripts/checkpatch.pl is complaining:
> >> Alignment should match open parenthesis
> >>
> >> Just will have to move 'BY_PROTOCOL' to the next line to get rid of it.
> > 
> > No,you can't.
> > Ending the line with '(' will cause another error.
> > Or dare you prefer such a style?
> 
> ret = EFI_CALL(BS->locate_handle_buffer
>   (BY_PROTOCOL,
>&efi_guid_driver_binding_protocol, NULL,
>&num, &handles));
> is what goes without warning.  

I have never seen such a coding style either in u-boot or kernel.
Even more, "(BY_PROTOCOL" and so on are not arguments of EFI_CALL,
but local_hander_buffer's.

> But I would not mind if you left the
> parenthesis on the line with the function name.

So this is the only option to be left although I don't like it.

-Takahiro Akashi

> 
> Regards
> 
> Heinrich
> 
> > 
> > -Takahiro Akashi
> > 
> > 
> >> Otherwise:
> >>
> >> Reviewed-by: Heinrich Schuchardt 
> >>
> >>> + if (ret != EFI_SUCCESS)
> >>> + return CMD_RET_FAILURE;
> >>> +
> >>> + if (!num)
> >>> + return CMD_RET_SUCCESS;
> >>> +
> >>> + printf("Driver%.*s Name Image Path\n",
> >>> +EFI_HANDLE_WIDTH - 6, spc);
> >>> + printf("%.*s  \n",
> >>> +EFI_HANDLE_WIDTH, sep);
> >>> + for (i = 0; i < num; i++) {
> >>> + if (!efi_get_driver_handle_info(handles[i], &driver_name,
> >>> + &image_path_text)) {
> >>> + if (image_path_text)
> >>> + printf("%p %-20ls %ls\n", handles[i],
> >>> +driver_name, image_path_text);
> >>> + else
> >>> + printf("%p %-20ls \n",
> >>> +handles[i], driver_name);
> >>> + EFI_CALL(BS->free_pool(driver_name));
> >>> +

Re: [U-Boot] SiFive FU540 U-Boot patches,

[Rick Chen]

Hi Anup

Anup Patel  於 2019年2月21日 週四 下午5:57寫道：

>
> On Thu, Feb 21, 2019 at 11:31 AM Bin Meng  wrote:
> >
> > On Thu, Feb 21, 2019 at 12:48 PM Anup Patel  wrote:
> > >
> > > Hi Rick,
> > >
> > > On Fri, Feb 15, 2019 at 10:19 AM Rick Chen  wrote:
> > > >
> > > > Hi Anup
> > > >
> > > > > > Hi All,
> > > > > >
> > > > > > Thanks for all the review comments so far.
> > > > > >
> > > > > > Is it possible to accept "[PATCH v7 00/15] SiFive FU540 Support" for
> > > > > > U-Boot-2019.04 ??
> > > > > >
> > > > > > Based on our discussion with various folks at FOSDEM19, lot of 
> > > > > > people want to
> > > > > > use U-Boot on Unleashed board. In general, it will be exciting to 
> > > > > > see U-Boot being
> > > > > > adopted as bootloader by various RISC-V HW vendors.
> > > >
> > > > I am still waiting for Simon's response about the two patchs
> > > > that he have comments.
> > >
> > > I have addressed Simon's patches and got Reviewed-by as well.
> > >
> > > I have posted "[PATCH v9 00/15] SiFive FU540 Support" which
> > > is based on U-Boot-2019.4-rc2.
> > >
> > > You can also find this patches in riscv_sifive_fu540_v9 branch of
> > > https://github.com/avpatel/u-boot.git
> >
> > Thanks for the support and hopefully we can get this one plus Lukas's
> > SMP series in the v2019.04 release.
>
> It will be awesome to have Lukas's SMP patches along with
> SiFive FU540 patches in v2019.04
>

OK
I will pull into u-boot-riscv and run Travis.
Then Send a PR to Tom.

Thanks for your efforts

B.R
Rick


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

Re: [U-Boot] [U-Boot, v3, 1/2] fs: fat: dynamically allocate memory for temporary buffer

[Chee, Tien Fong]

On Thu, 2019-02-21 at 22:22 -0500, Tom Rini wrote:
> On Thu, Feb 21, 2019 at 08:45:37AM +0100, Michal Simek wrote:
> > 
> > Hi Tom,
> > 
> > On 20. 02. 19 2:58, Tom Rini wrote:
> > > 
> > > On Mon, Feb 11, 2019 at 02:56:19PM +0800, tien.fong.c...@intel.co
> > > m wrote:
> > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Drop the statically allocated get_contents_vfatname_block and
> > > > dynamically allocate a buffer only if required. This saves
> > > > 64KiB of memory.
> > > > 
> > > > Signed-off-by: Stefan Agner 
> > > > Signed-off-by: Tien Fong Chee 
> > > Applied to u-boot/master, thanks!
> > please remove this patch (better both of them because they were in
> > series) because they are breaking at least ZynqMP SPL. It is also
> > too
> > late in cycle to create random fix.
> > 
> > You can't simply move 64KB from code to malloc without reflecting
> > this
> > by changing MALLOC space size.
> > 
> > Other boards with SPL fat could be also affected by this if they
> > don't
> > allocate big malloc space.
> I see from later in on the thread your specific problem is elsewhere.
> But to address the root question, we have fairly large malloc
> requirements in SPL when FAT is involved as there's a lot of other
> mallocs going on there.  It's indeed not impossible there's a board
> that
> was on-edge of it's 1MB pool, and now goes over, but that seems
> unlikely.  Thanks all!
I'm curious what's the actual problems you found? running out of
memory, no?

Increasing Malloc space size is definitely required for The patch[1/2],
but patch[2/2] would maximize the re-usable of memory, so in other
words, no change on Malloc space size required. Both patches would
share the same memory.

You might need to take a look these patches, they are part of vfat
optimization.
https://patchwork.ozlabs.org/patch/1029679/
https://patchwork.ozlabs.org/patch/1029681/
https://patchwork.ozlabs.org/patch/1029682/
https://patchwork.ozlabs.org/patch/1029683/
> 

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

Re: [U-Boot] [PATCH 3/3] am335x, guardian: Add support for the bosch guardian board

[Tom Rini]

On Thu, Feb 21, 2019 at 10:13:43AM +, Martyn Welch wrote:

> From: Sjoerd Simons 
> 
> Add support for the Bosch Guardian board.
> 
> CPU  : AM335X-GP rev 2.1
> Model: Bosch AM335x Guardian
> I2C:   ready
> DRAM:  256 MiB
> NAND:  512 MiB
> MMC:   OMAP SD/MMC: 0
> 
> Signed-off-by: Sjoerd Simons 
> Signed-off-by: Martyn Welch 
[snip]
> +/* SPL */
> +
> +/* Bootcount using the RTC block */
> +#define CONFIG_SYS_BOOTCOUNT_LE
> +
> +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_USB_ETHER)
> +/* Remove other SPL modes. */
> +/* disable host part of MUSB in SPL */
> +#undef CONFIG_MUSB_HOST
> +/* disable EFI partitions and partition UUID support */
> +#endif

There's some uplifting cleanup still to be done here.  Do you even have
SPL_USB_ETHER support?  But regardless CONFIG_MUSB_HOST isn't even a
symbol now.  Please drop this and then give the config.h file itself a
good hard read for other bits like this, or things that should be in the
defconfig file now, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/3] env: Don't check CONFIG_ENV_OFFSET_REDUND for SPL build

[Tom Rini]

On Thu, Feb 21, 2019 at 10:13:42AM +, Martyn Welch wrote:

> Currently CONFIG_ENV_OFFSET_REDUND is checked regardless of the type of
> build being performed, but this doesn't seem to be needed in SPL builds.
> 
> Don't check this configuration option for SPL builds.
> 
> Signed-off-by: Martyn Welch 
> ---
> 
>  env/nand.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/env/nand.c b/env/nand.c
> index 29eda66fad..d0b95f483d 100644
> --- a/env/nand.c
> +++ b/env/nand.c
> @@ -26,7 +26,7 @@
>  #if defined(CONFIG_CMD_SAVEENV) && defined(CONFIG_CMD_NAND) && \
>   !defined(CONFIG_SPL_BUILD)
>  #define CMD_SAVEENV
> -#elif defined(CONFIG_ENV_OFFSET_REDUND)
> +#elif defined(CONFIG_ENV_OFFSET_REDUND) && !defined(CONFIG_SPL_BUILD)
>  #error CONFIG_ENV_OFFSET_REDUND must have CONFIG_CMD_SAVEENV & 
> CONFIG_CMD_NAND
>  #endif

I'm confused.  If we have redundant env, and we have env in nand, we
need to know.  That said, I guess this is just a sanity check for build
time, and until we have ENV_OFFSET_REDUND (and others) move to Kconfig
we can't also delete those #error lines.  Am I at least right about
where/how you hit this problem?  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, v3, 1/2] fs: fat: dynamically allocate memory for temporary buffer

[Tom Rini]

On Thu, Feb 21, 2019 at 08:45:37AM +0100, Michal Simek wrote:
> Hi Tom,
> 
> On 20. 02. 19 2:58, Tom Rini wrote:
> > On Mon, Feb 11, 2019 at 02:56:19PM +0800, tien.fong.c...@intel.com wrote:
> > 
> >> From: Tien Fong Chee 
> >>
> >> Drop the statically allocated get_contents_vfatname_block and
> >> dynamically allocate a buffer only if required. This saves
> >> 64KiB of memory.
> >>
> >> Signed-off-by: Stefan Agner 
> >> Signed-off-by: Tien Fong Chee 
> > 
> > Applied to u-boot/master, thanks!
> 
> please remove this patch (better both of them because they were in
> series) because they are breaking at least ZynqMP SPL. It is also too
> late in cycle to create random fix.
> 
> You can't simply move 64KB from code to malloc without reflecting this
> by changing MALLOC space size.
> 
> Other boards with SPL fat could be also affected by this if they don't
> allocate big malloc space.

I see from later in on the thread your specific problem is elsewhere.
But to address the root question, we have fairly large malloc
requirements in SPL when FAT is involved as there's a lot of other
mallocs going on there.  It's indeed not impossible there's a board that
was on-edge of it's 1MB pool, and now goes over, but that seems
unlikely.  Thanks all!

-- 
Tom


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

Re: [U-Boot] [PATCH] arm: dts: exynos: Adjust whitespace around status property

[Simon Glass]

On Thu, 21 Feb 2019 at 09:32, Krzysztof Kozlowski  wrote:
>
> Just add spaces around '=' sign for clarity.
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/dts/exynos5422-odroidxu3.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)


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

Re: [U-Boot] [PATCH v7 4/7] cmd: efidebug: add drivers command

[Heinrich Schuchardt]

On 2/22/19 1:05 AM, AKASHI Takahiro wrote:
> On Thu, Feb 21, 2019 at 08:32:06PM +0100, Heinrich Schuchardt wrote:
>> On 2/21/19 7:26 AM, AKASHI Takahiro wrote:
>>> "drivers" command prints all the uefi drivers on the system.
>>>
>>> => efi drivers
>>> Driver   Name Image Path
>>>   
>>> 7ef003d0
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  cmd/efidebug.c | 95 +-
>>>  1 file changed, 94 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
>>> index 72e0652fc3e4..04fc170867fc 100644
>>> --- a/cmd/efidebug.c
>>> +++ b/cmd/efidebug.c
>>> @@ -89,6 +89,95 @@ static int do_efi_show_devices(cmd_tbl_t *cmdtp, int 
>>> flag,
>>> return CMD_RET_SUCCESS;
>>>  }
>>>  
>>> +/**
>>> + * efi_get_driver_handle_info() - get information of UEFI driver
>>> + *
>>> + * @handle:Handle of UEFI device
>>> + * @driver_name:   Driver name
>>> + * @image_path:Pointer to text of device path
>>> + * Return: 0 on success, -1 on failure
>>> + *
>>> + * Currently return no useful information as all UEFI drivers are
>>> + * built-in..
>>> + */
>>> +static int efi_get_driver_handle_info(efi_handle_t handle, u16 
>>> **driver_name,
>>> + u16 **image_path)
>>> +{
>>> +   struct efi_handler *handler;
>>> +   struct efi_loaded_image *image;
>>> +   efi_status_t ret;
>>> +
>>> +   /*
>>> +* driver name
>>> +* TODO: support EFI_COMPONENT_NAME2_PROTOCOL
>>> +*/
>>> +   *driver_name = NULL;
>>> +
>>> +   /* image name */
>>> +   ret = efi_search_protocol(handle, &efi_guid_loaded_image, &handler);
>>> +   if (ret != EFI_SUCCESS) {
>>> +   *image_path = NULL;
>>> +   return 0;
>>> +   }
>>> +
>>> +   image = handler->protocol_interface;
>>> +   *image_path = efi_dp_str(image->file_path);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +/**
>>> + * do_efi_show_drivers() - show UEFI drivers
>>> + *
>>> + * @cmdtp: Command table
>>> + * @flag:  Command flag
>>> + * @argc:  Number of arguments
>>> + * @argv:  Argument array
>>> + * Return: CMD_RET_SUCCESS on success, CMD_RET_RET_FAILURE on failure
>>> + *
>>> + * Implement efidebug "drivers" sub-command.
>>> + * Show all UEFI drivers and their information.
>>> + */
>>> +static int do_efi_show_drivers(cmd_tbl_t *cmdtp, int flag,
>>> +  int argc, char * const argv[])
>>> +{
>>> +   efi_handle_t *handles;
>>> +   efi_uintn_t num, i;
>>> +   u16 *driver_name, *image_path_text;
>>> +   efi_status_t ret;
>>> +
>>> +   ret = EFI_CALL(BS->locate_handle_buffer(BY_PROTOCOL,
>>> +   &efi_guid_driver_binding_protocol, NULL,
>>> +   &num, &handles));
>>
>> nits:
>>
>> scripts/checkpatch.pl is complaining:
>> Alignment should match open parenthesis
>>
>> Just will have to move 'BY_PROTOCOL' to the next line to get rid of it.
> 
> No,you can't.
> Ending the line with '(' will cause another error.
> Or dare you prefer such a style?

ret = EFI_CALL(BS->locate_handle_buffer
(BY_PROTOCOL,
 &efi_guid_driver_binding_protocol, NULL,
 &num, &handles));

is what goes without warning. But I would not mind if you left the
parenthesis on the line with the function name.

Regards

Heinrich

> 
> -Takahiro Akashi
> 
> 
>> Otherwise:
>>
>> Reviewed-by: Heinrich Schuchardt 
>>
>>> +   if (ret != EFI_SUCCESS)
>>> +   return CMD_RET_FAILURE;
>>> +
>>> +   if (!num)
>>> +   return CMD_RET_SUCCESS;
>>> +
>>> +   printf("Driver%.*s Name Image Path\n",
>>> +  EFI_HANDLE_WIDTH - 6, spc);
>>> +   printf("%.*s  \n",
>>> +  EFI_HANDLE_WIDTH, sep);
>>> +   for (i = 0; i < num; i++) {
>>> +   if (!efi_get_driver_handle_info(handles[i], &driver_name,
>>> +   &image_path_text)) {
>>> +   if (image_path_text)
>>> +   printf("%p %-20ls %ls\n", handles[i],
>>> +  driver_name, image_path_text);
>>> +   else
>>> +   printf("%p %-20ls \n",
>>> +  handles[i], driver_name);
>>> +   EFI_CALL(BS->free_pool(driver_name));
>>> +   EFI_CALL(BS->free_pool(image_path_text));
>>> +   }
>>> +   }
>>> +
>>> +   EFI_CALL(BS->free_pool(handles));
>>> +
>>> +   return CMD_RET_SUCCESS;
>>> +}
>>> +
>>>  /**
>>>   * do_efi_boot_add() - set UEFI boot option
>>>   *
>>> @@ -586,6 +675,8 @@ static cmd_tbl_t cmd_efidebug_sub[] = {
>>> U_BOOT_CMD_MKENT(boot, CONFIG_SYS_MAXARGS, 1, do_efi_boot_opt, "", ""),
>>> U_BOOT_CMD_MKENT(devices, CONFIG_SYS_MAXARGS, 1, do_efi_show_devices,
>>>  "", ""),
>>> +   U_BOOT_CMD_MKENT(driver

Re: [U-Boot] [PATCH v7 2/7] cmd: add efidebug command

[Heinrich Schuchardt]

On 2/22/19 2:04 AM, AKASHI Takahiro wrote:
> On Thu, Feb 21, 2019 at 08:24:21PM +0100, Heinrich Schuchardt wrote:
>> On 2/21/19 7:26 AM, AKASHI Takahiro wrote:
>>> Currently, there is no easy way to add or modify UEFI variables.
>>> In particular, bootmgr supports BootOrder/Boot variables, it is
>>> quite hard to define them as u-boot variables because they are represented
>>> in a complicated and encoded format.
>>>
>>> The new command, efidebug, helps address these issues and give us
>>> more friendly interfaces:
>>>  * efidebug boot add: add Boot variable
>>>  * efidebug boot rm: remove Boot variable
>>>  * efidebug boot dump: display all Boot variables
>>>  * efidebug boot next: set BootNext variable
>>>  * efidebug boot order: set/display a boot order (BootOrder)
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  MAINTAINERS|   1 +
>>>  cmd/Kconfig|  10 +
>>>  cmd/Makefile   |   1 +
>>>  cmd/efidebug.c | 578 +
>>>  4 files changed, 590 insertions(+)
>>>  create mode 100644 cmd/efidebug.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 0cce9db2660e..4fabb75eda37 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -471,6 +471,7 @@ F:  lib/efi*/
>>>  F: test/py/tests/test_efi*
>>>  F: test/unicode_ut.c
>>>  F: cmd/bootefi.c
>>> +F: cmd/efidebug.c
>>>  F: cmd/nvedit_efi.c
>>>  F: tools/file2include.c
>>>  
>>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>>> index ddcdee44538d..88b086b074be 100644
>>> --- a/cmd/Kconfig
>>> +++ b/cmd/Kconfig
>>> @@ -1407,6 +1407,16 @@ config CMD_DISPLAY
>>>   displayed on a simple board-specific display. Implement
>>>   display_putc() to use it.
>>>  
>>> +config CMD_EFIDEBUG
>>> +   bool "efidebug - display/configure UEFI environment"
>>> +   depends on EFI_LOADER
>>> +   default n
>>> +   help
>>> + Enable the 'efidebug' command which provides a subset of UEFI
>>> + shell utility with simplified functionality. It will be useful
>>> + particularly for managing boot parameters as  well as examining
>>> + various EFI status for debugging.
>>> +
>>>  config CMD_LED
>>> bool "led"
>>> default y if LED
>>> diff --git a/cmd/Makefile b/cmd/Makefile
>>> index b9ee51869d48..acb85f49fba8 100644
>>> --- a/cmd/Makefile
>>> +++ b/cmd/Makefile
>>> @@ -51,6 +51,7 @@ obj-$(CONFIG_CMD_ECHO) += echo.o
>>>  obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
>>>  obj-$(CONFIG_CMD_EEPROM) += eeprom.o
>>>  obj-$(CONFIG_EFI_STUB) += efi.o
>>> +obj-$(CONFIG_CMD_EFIDEBUG) += efidebug.o
>>>  obj-$(CONFIG_CMD_ELF) += elf.o
>>>  obj-$(CONFIG_HUSH_PARSER) += exit.o
>>>  obj-$(CONFIG_CMD_EXT4) += ext4.o
>>> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
>>> new file mode 100644
>>> index ..641ec98a4d32
>>> --- /dev/null
>>> +++ b/cmd/efidebug.c
>>> @@ -0,0 +1,578 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + *  UEFI Shell-like command
>>> + *
>>> + *  Copyright (c) 2018 AKASHI Takahiro, Linaro Limited
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/**
>>> + * do_efi_boot_add() - set UEFI boot option
>>> + *
>>> + * @cmdtp: Command table
>>> + * @flag:  Command flag
>>> + * @argc:  Number of arguments
>>> + * @argv:  Argument array
>>> + * Return: CMD_RET_SUCCESS on success,
>>> + * CMD_RET_USAGE or CMD_RET_RET_FAILURE on failure
>>> + *
>>> + * Implement efidebug "boot add" sub-command.
>>> + * Create or change UEFI boot option.
>>> + *   - boot add[:]  
>>> + */
>>> +static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
>>> +  int argc, char * const argv[])
>>> +{
>>> +   int id;
>>> +   char *endp;
>>> +   char var_name[9];
>>> +   u16 var_name16[9], *p;
>>> +   efi_guid_t guid;
>>> +   size_t label_len, label_len16;
>>> +   u16 *label;
>>> +   struct efi_device_path *device_path = NULL, *file_path = NULL;
>>> +   struct efi_load_option lo;
>>> +   void *data = NULL;
>>> +   efi_uintn_t size;
>>> +   int ret;
>>> +
>>> +   if (argc < 6 || argc > 7)
>>> +   return CMD_RET_USAGE;
>>> +
>>> +   id = (int)simple_strtoul(argv[1], &endp, 16);
>>> +   if (*endp != '\0' || id > 0x)
>>> +   return CMD_RET_FAILURE;
>>> +
>>> +   sprintf(var_name, "Boot%04X", id);
>>> +   p = var_name16;
>>> +   utf8_utf16_strncpy(&p, var_name, 9);
>>> +
>>> +   guid = efi_global_variable_guid;
>>> +
>>> +   /* attributes */
>>> +   lo.attributes = 0x1; /* always ACTIVE */
>>
>> I would prefer the usage of a constant.
>>
>> We should move the definitions from lib/efi_loader/efi_bootmgr.c to
>> efi_api.h:
> 
> Okay, but in efi_loader.h as struct efi_load_option is defined there.

struct efi_load_option is nothing that is defined in the UEFI spec but a
U-Boot specific structure (it is not the same as EFI_LOAD_OPTION).

The constants are defined in the UEFI spec.

To my understanding we are using efi_loader only for U-Boot specific
st

Re: [U-Boot] [PATCH v7 1/7] cmd: env: add "-e" option for handling UEFI variables

[Heinrich Schuchardt]

On 2/22/19 1:21 AM, AKASHI Takahiro wrote:
> On Thu, Feb 21, 2019 at 08:42:37PM +0100, Heinrich Schuchardt wrote:
>> On 2/21/19 7:26 AM, AKASHI Takahiro wrote:
>>> "env [print|set] -e" allows for handling uefi variables without
>>> knowing details about mapping to corresponding u-boot variables.
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  MAINTAINERS   |   1 +
>>>  cmd/Kconfig   |  10 ++
>>>  cmd/Makefile  |   1 +
>>>  cmd/nvedit.c  |  28 +++-
>>>  cmd/nvedit_efi.c  | 395 ++
>>>  include/command.h |   8 +
>>>  6 files changed, 442 insertions(+), 1 deletion(-)
>>>  create mode 100644 cmd/nvedit_efi.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index f1f8818d6ba8..0cce9db2660e 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -471,6 +471,7 @@ F:  lib/efi*/
>>>  F: test/py/tests/test_efi*
>>>  F: test/unicode_ut.c
>>>  F: cmd/bootefi.c
>>> +F: cmd/nvedit_efi.c
>>>  F: tools/file2include.c
>>>  
>>>  FPGA
>>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>>> index 3ea42e425611..ddcdee44538d 100644
>>> --- a/cmd/Kconfig
>>> +++ b/cmd/Kconfig
>>> @@ -420,6 +420,16 @@ config CMD_ENV_FLAGS
>>>   be deleted. This command shows the variables that have special
>>>   flags.
>>>  
>>> +config CMD_NVEDIT_EFI
>>> +   bool "env [set|print] -e - set/print UEFI variables"
>>> +   depends on EFI_LOADER
>>> +   default y
>>> +   imply HEXDUMP
>>> +   help
>>> + UEFI variables are encoded as some form of U-Boot variables.
>>> + If enabled, we are allowed to set/print UEFI variables using
>>> + "env" command with "-e" option without knowing details.
>>> +
>>>  endmenu
>>>  
>>>  menu "Memory commands"
>>> diff --git a/cmd/Makefile b/cmd/Makefile
>>> index a127a995394f..b9ee51869d48 100644
>>> --- a/cmd/Makefile
>>> +++ b/cmd/Makefile
>>> @@ -98,6 +98,7 @@ obj-$(CONFIG_CMD_MTD) += mtd.o
>>>  obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
>>>  obj-$(CONFIG_CMD_NAND) += nand.o
>>>  obj-$(CONFIG_CMD_NET) += net.o
>>> +obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
>>>  obj-$(CONFIG_CMD_ONENAND) += onenand.o
>>>  obj-$(CONFIG_CMD_OSD) += osd.o
>>>  obj-$(CONFIG_CMD_PART) += part.o
>>> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
>>> index ebaa16b75459..f798e5137d26 100644
>>> --- a/cmd/nvedit.c
>>> +++ b/cmd/nvedit.c
>>> @@ -119,6 +119,11 @@ static int do_env_print(cmd_tbl_t *cmdtp, int flag, 
>>> int argc,
>>> int rcode = 0;
>>> int env_flag = H_HIDE_DOT;
>>>  
>>> +#if defined(CONFIG_CMD_NVEDIT_EFI)
>>> +   if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
>>> +   return do_env_print_efi(cmdtp, flag, --argc, ++argv);
>>> +#endif
>>> +
>>> if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'a') {
>>> argc--;
>>> argv++;
>>> @@ -216,6 +221,12 @@ static int _do_env_set(int flag, int argc, char * 
>>> const argv[], int env_flag)
>>> ENTRY e, *ep;
>>>  
>>> debug("Initial value for argc=%d\n", argc);
>>> +
>>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_CMD_NVEDIT_EFI)
>>
>> In the Makefile you already have 'ifndef CONFIG_SPL_BUILD'.
> 
> No.
> Since nvedit.c is always compiled in, we need this protection.

You are right.

One day this nvedit.c should be split into two files. One with SPL
relevant functions and one for the rest. That would save us a lot of
ifdef's.

Regards

Heinrich

> 
>>> +   if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
>>> +   return do_env_set_efi(NULL, flag, --argc, ++argv);
>>> +#endif
>>> +
>>> while (argc > 1 && **(argv + 1) == '-') {
>>> char *arg = *++argv;
>>>  
>>> @@ -1263,11 +1274,17 @@ static char env_help_text[] =
>>> "env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import 
>>> environment\n"
>>>  #endif
>>> "env print [-a | name ...] - print environment\n"
>>> +#if defined(CONFIG_CMD_NVEDIT_EFI)
>>> +   "env print -e [name ...] - print UEFI environment\n"
>>> +#endif
>>>  #if defined(CONFIG_CMD_RUN)
>>> "env run var [...] - run commands in an environment variable\n"
>>>  #endif
>>>  #if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
>>> "env save - save environment\n"
>>> +#endif
>>> +#if defined(CONFIG_CMD_NVEDIT_EFI)
>>> +   "env set -e name [arg ...] - set UEFI variable; unset if 'arg' not 
>>> specified\n"
>>>  #endif
>>> "env set [-f] name [arg ...]\n";
>>>  #endif
>>> @@ -1295,6 +1312,10 @@ U_BOOT_CMD_COMPLETE(
>>> printenv, CONFIG_SYS_MAXARGS, 1,do_env_print,
>>> "print environment variables",
>>> "[-a]\n- print [all] values of all environment variables\n"
>>> +#if defined(CONFIG_CMD_NVEDIT_EFI)
>>> +   "printenv -e [name ...]\n"
>>> +   "- print UEFI variable 'name' or all the variables\n"
>>> +#endif
>>> "printenv name ...\n"
>>> "- print value of environment variable 'name'",
>>> var_complete
>>> @@ -1322,7 +1343,12 @@ U_BOOT_CMD_COMPLETE(
>>>  U_BOOT_CMD_COMPLETE(
>>> setenv, CONFIG_SYS_MAXARGS, 0,  do_env_set,

Re: [U-Boot] [PATCH v8 00/15] SiFive FU540 Support

[Bin Meng]

On Fri, Feb 22, 2019 at 8:12 AM Tom Rini  wrote:
>
> On Thu, Feb 21, 2019 at 04:03:41PM -0800, Palmer Dabbelt wrote:
> > On Thu, 21 Feb 2019 15:41:02 PST (-0800), tr...@konsulko.com wrote:
> > >On Wed, Feb 20, 2019 at 05:45:59AM +, Anup Patel wrote:
> > >
> > >>This patchset adds SiFive Freedom Unleashed (FU540) support
> > >>to RISC-V U-Boot.
> > >>
> > >>The patches are based upon latest U-Boot source tree
> > >>(git://git.denx.de/u-boot.git) at v2019.04-rc2 commit id
> > >>f14de0014c56093feecf42ca38b8ae5b3878f176
> > >>
> > >>All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> > >>MACB Ethernet work fine on actual SiFive Unleashed board and
> > >>QEMU sifive_u machine.
> > >
> > >Is the sifive_u QEMU machine in upstream QEMU?  If so, lets add it to
> > >the travis file and run tests.  Thanks!
> >
> > It's been upstream for a while, though we might deprecate it in the future
> > because the name is a bit ambiguous.  There's nothing better right now, so
> > it's probably a good bet to test against.
>
> Great!  Then we should model something based on
> - name: "test/py qemu-x86"
>   env:
> - TEST_PY_BD="qemu-x86"
>   TEST_PY_TEST_SPEC="not sleep"
>   QEMU_TARGET="i386-softmmu"
>   BUILDMAN="^qemu-x86$"
>   TOOLCHAIN="i386"
>   BUILD_ROM="yes"
>
> And an appropriate PR to https://github.com/swarren/uboot-test-hooks so
> that we can run the testsuite every time.
>

Yes, this has been on my todo list for a while when qemu-riscv was
initially supported.

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

Re: [U-Boot] [RFC 1/1] efi_loader: in situ relocation

[AKASHI Takahiro]

On Thu, Feb 21, 2019 at 07:55:46PM +0100, Heinrich Schuchardt wrote:
> On 2/21/19 11:21 AM, Alexander Graf wrote:
> > On 02/20/2019 07:12 PM, Heinrich Schuchardt wrote:
> >> On 2/18/19 1:52 AM, AKASHI Takahiro wrote:
> >>> Heinrich,
> >>>
> >>> On Sat, Feb 16, 2019 at 08:50:43PM +0100, Heinrich Schuchardt wrote:
>  All code and data sections of PE images are already in the correct
>  relative
>  location when loaded into memory. There is not need to copy them once
>  again.
> >>> While I'm not very familiar with how PE image is created (in EDK2),
> >> The relevant reference is the Microsoft Portable Executable and
> >> Common Object File Format Specification. The latest version as PDF that
> >> I found is revision 11, Jan 23rd, 2017. The citations are from that
> >> version. Later versions are available as HTML.
> >>
> >>> what I understand in Alex's code is
> >>> * All the code and data are located starting 0x0 (in virtual space)
> >> The header provides a field ImageBase. If you load the image at this
> >> address there is no need for relocation. I could not find any rule
> >> saying ImageBase has to be zero. It has be a multiple of 64 KiB. For
> >> Windows non-zero defaults are provided in the spec.
> >>
> >>> * Sections in PE image may not be sorted in ascending order
> >> The spec says: "The physical offset for section data is the same as the
> >> RVA". The relative virtual address is defined as "In an image file, the
> >> address of an item after it is loaded into memory, with the base address
> >> of the image file subtracted from it."
> >>
> >>> * There may be some gaps (more than one page) between sections,
> >>>    probably, due to alignment requirements or BSS
> >> Yes, due to alignment there may be some gap filling bytes.
> >>
> >>> Do you say that those assumptions are no longer correct?
> >> The most important sentence concerning relocations in the spec is:
> >>
> >> "If the image is loaded at its preferred base, ... the base relocations
> >> do not have to be applied."
> > 
> > Yes, but image loading also implies that we actually load the sections
> > to particular offsets with particular section alignment. You can have a
> > PE binary that aligns its sections in 32 byte granule, but expects the
> > sections to get loaded at 4kb alignment. In such a case, I don't see how
> > we can get away to not copy the image.
> > 
> 
> Thanks Alex and Takhiro for reviewing.
> 
> Reading the fine print in the spec I now saw that segment alignment is
> typically smaller than file alignment.
> 
> Strange that even the EFI shell would work with my patch in.
> 
> What we should be able to do is to release the buffer used for reading
> from file once we have done the relocation, so that after LoadImage we
> end up with only one memory area allocated for the image.

Finally, you've got my old patch ("efi_loader: set image_base and image_size
to correct values":
  https://lists.denx.de/pipermail/u-boot/2018-August/337708.html

-Takahiro Akashi

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

Re: [U-Boot] [PATCH v7 2/7] cmd: add efidebug command

[AKASHI Takahiro]

On Thu, Feb 21, 2019 at 08:24:21PM +0100, Heinrich Schuchardt wrote:
> On 2/21/19 7:26 AM, AKASHI Takahiro wrote:
> > Currently, there is no easy way to add or modify UEFI variables.
> > In particular, bootmgr supports BootOrder/Boot variables, it is
> > quite hard to define them as u-boot variables because they are represented
> > in a complicated and encoded format.
> > 
> > The new command, efidebug, helps address these issues and give us
> > more friendly interfaces:
> >  * efidebug boot add: add Boot variable
> >  * efidebug boot rm: remove Boot variable
> >  * efidebug boot dump: display all Boot variables
> >  * efidebug boot next: set BootNext variable
> >  * efidebug boot order: set/display a boot order (BootOrder)
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  MAINTAINERS|   1 +
> >  cmd/Kconfig|  10 +
> >  cmd/Makefile   |   1 +
> >  cmd/efidebug.c | 578 +
> >  4 files changed, 590 insertions(+)
> >  create mode 100644 cmd/efidebug.c
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0cce9db2660e..4fabb75eda37 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -471,6 +471,7 @@ F:  lib/efi*/
> >  F: test/py/tests/test_efi*
> >  F: test/unicode_ut.c
> >  F: cmd/bootefi.c
> > +F: cmd/efidebug.c
> >  F: cmd/nvedit_efi.c
> >  F: tools/file2include.c
> >  
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index ddcdee44538d..88b086b074be 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -1407,6 +1407,16 @@ config CMD_DISPLAY
> >   displayed on a simple board-specific display. Implement
> >   display_putc() to use it.
> >  
> > +config CMD_EFIDEBUG
> > +   bool "efidebug - display/configure UEFI environment"
> > +   depends on EFI_LOADER
> > +   default n
> > +   help
> > + Enable the 'efidebug' command which provides a subset of UEFI
> > + shell utility with simplified functionality. It will be useful
> > + particularly for managing boot parameters as  well as examining
> > + various EFI status for debugging.
> > +
> >  config CMD_LED
> > bool "led"
> > default y if LED
> > diff --git a/cmd/Makefile b/cmd/Makefile
> > index b9ee51869d48..acb85f49fba8 100644
> > --- a/cmd/Makefile
> > +++ b/cmd/Makefile
> > @@ -51,6 +51,7 @@ obj-$(CONFIG_CMD_ECHO) += echo.o
> >  obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
> >  obj-$(CONFIG_CMD_EEPROM) += eeprom.o
> >  obj-$(CONFIG_EFI_STUB) += efi.o
> > +obj-$(CONFIG_CMD_EFIDEBUG) += efidebug.o
> >  obj-$(CONFIG_CMD_ELF) += elf.o
> >  obj-$(CONFIG_HUSH_PARSER) += exit.o
> >  obj-$(CONFIG_CMD_EXT4) += ext4.o
> > diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> > new file mode 100644
> > index ..641ec98a4d32
> > --- /dev/null
> > +++ b/cmd/efidebug.c
> > @@ -0,0 +1,578 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + *  UEFI Shell-like command
> > + *
> > + *  Copyright (c) 2018 AKASHI Takahiro, Linaro Limited
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/**
> > + * do_efi_boot_add() - set UEFI boot option
> > + *
> > + * @cmdtp: Command table
> > + * @flag:  Command flag
> > + * @argc:  Number of arguments
> > + * @argv:  Argument array
> > + * Return: CMD_RET_SUCCESS on success,
> > + * CMD_RET_USAGE or CMD_RET_RET_FAILURE on failure
> > + *
> > + * Implement efidebug "boot add" sub-command.
> > + * Create or change UEFI boot option.
> > + *   - boot add[:]  
> > + */
> > +static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
> > +  int argc, char * const argv[])
> > +{
> > +   int id;
> > +   char *endp;
> > +   char var_name[9];
> > +   u16 var_name16[9], *p;
> > +   efi_guid_t guid;
> > +   size_t label_len, label_len16;
> > +   u16 *label;
> > +   struct efi_device_path *device_path = NULL, *file_path = NULL;
> > +   struct efi_load_option lo;
> > +   void *data = NULL;
> > +   efi_uintn_t size;
> > +   int ret;
> > +
> > +   if (argc < 6 || argc > 7)
> > +   return CMD_RET_USAGE;
> > +
> > +   id = (int)simple_strtoul(argv[1], &endp, 16);
> > +   if (*endp != '\0' || id > 0x)
> > +   return CMD_RET_FAILURE;
> > +
> > +   sprintf(var_name, "Boot%04X", id);
> > +   p = var_name16;
> > +   utf8_utf16_strncpy(&p, var_name, 9);
> > +
> > +   guid = efi_global_variable_guid;
> > +
> > +   /* attributes */
> > +   lo.attributes = 0x1; /* always ACTIVE */
> 
> I would prefer the usage of a constant.
> 
> We should move the definitions from lib/efi_loader/efi_bootmgr.c to
> efi_api.h:

Okay, but in efi_loader.h as struct efi_load_option is defined there.

> #define LOAD_OPTION_ACTIVE0x0001
> #define LOAD_OPTION_FORCE_RECONNECT   0x0002
> #define LOAD_OPTION_HIDDEN0x0008
> 
> And add the missing values:
> 
> #define LOAD_OPTION_CATEGORY  0x1F00
> #define LOAD_OPTION_CATEGORY_BOOT 0x
> #define LOAD_O

Re: [U-Boot] [PATCH v7 1/7] cmd: env: add "-e" option for handling UEFI variables

[AKASHI Takahiro]

On Thu, Feb 21, 2019 at 08:42:37PM +0100, Heinrich Schuchardt wrote:
> On 2/21/19 7:26 AM, AKASHI Takahiro wrote:
> > "env [print|set] -e" allows for handling uefi variables without
> > knowing details about mapping to corresponding u-boot variables.
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  MAINTAINERS   |   1 +
> >  cmd/Kconfig   |  10 ++
> >  cmd/Makefile  |   1 +
> >  cmd/nvedit.c  |  28 +++-
> >  cmd/nvedit_efi.c  | 395 ++
> >  include/command.h |   8 +
> >  6 files changed, 442 insertions(+), 1 deletion(-)
> >  create mode 100644 cmd/nvedit_efi.c
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index f1f8818d6ba8..0cce9db2660e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -471,6 +471,7 @@ F:  lib/efi*/
> >  F: test/py/tests/test_efi*
> >  F: test/unicode_ut.c
> >  F: cmd/bootefi.c
> > +F: cmd/nvedit_efi.c
> >  F: tools/file2include.c
> >  
> >  FPGA
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 3ea42e425611..ddcdee44538d 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -420,6 +420,16 @@ config CMD_ENV_FLAGS
> >   be deleted. This command shows the variables that have special
> >   flags.
> >  
> > +config CMD_NVEDIT_EFI
> > +   bool "env [set|print] -e - set/print UEFI variables"
> > +   depends on EFI_LOADER
> > +   default y
> > +   imply HEXDUMP
> > +   help
> > + UEFI variables are encoded as some form of U-Boot variables.
> > + If enabled, we are allowed to set/print UEFI variables using
> > + "env" command with "-e" option without knowing details.
> > +
> >  endmenu
> >  
> >  menu "Memory commands"
> > diff --git a/cmd/Makefile b/cmd/Makefile
> > index a127a995394f..b9ee51869d48 100644
> > --- a/cmd/Makefile
> > +++ b/cmd/Makefile
> > @@ -98,6 +98,7 @@ obj-$(CONFIG_CMD_MTD) += mtd.o
> >  obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
> >  obj-$(CONFIG_CMD_NAND) += nand.o
> >  obj-$(CONFIG_CMD_NET) += net.o
> > +obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
> >  obj-$(CONFIG_CMD_ONENAND) += onenand.o
> >  obj-$(CONFIG_CMD_OSD) += osd.o
> >  obj-$(CONFIG_CMD_PART) += part.o
> > diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> > index ebaa16b75459..f798e5137d26 100644
> > --- a/cmd/nvedit.c
> > +++ b/cmd/nvedit.c
> > @@ -119,6 +119,11 @@ static int do_env_print(cmd_tbl_t *cmdtp, int flag, 
> > int argc,
> > int rcode = 0;
> > int env_flag = H_HIDE_DOT;
> >  
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > +   if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
> > +   return do_env_print_efi(cmdtp, flag, --argc, ++argv);
> > +#endif
> > +
> > if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'a') {
> > argc--;
> > argv++;
> > @@ -216,6 +221,12 @@ static int _do_env_set(int flag, int argc, char * 
> > const argv[], int env_flag)
> > ENTRY e, *ep;
> >  
> > debug("Initial value for argc=%d\n", argc);
> > +
> > +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_CMD_NVEDIT_EFI)
> 
> In the Makefile you already have 'ifndef CONFIG_SPL_BUILD'.

No.
Since nvedit.c is always compiled in, we need this protection.

> > +   if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'e')
> > +   return do_env_set_efi(NULL, flag, --argc, ++argv);
> > +#endif
> > +
> > while (argc > 1 && **(argv + 1) == '-') {
> > char *arg = *++argv;
> >  
> > @@ -1263,11 +1274,17 @@ static char env_help_text[] =
> > "env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import 
> > environment\n"
> >  #endif
> > "env print [-a | name ...] - print environment\n"
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > +   "env print -e [name ...] - print UEFI environment\n"
> > +#endif
> >  #if defined(CONFIG_CMD_RUN)
> > "env run var [...] - run commands in an environment variable\n"
> >  #endif
> >  #if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
> > "env save - save environment\n"
> > +#endif
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > +   "env set -e name [arg ...] - set UEFI variable; unset if 'arg' not 
> > specified\n"
> >  #endif
> > "env set [-f] name [arg ...]\n";
> >  #endif
> > @@ -1295,6 +1312,10 @@ U_BOOT_CMD_COMPLETE(
> > printenv, CONFIG_SYS_MAXARGS, 1,do_env_print,
> > "print environment variables",
> > "[-a]\n- print [all] values of all environment variables\n"
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > +   "printenv -e [name ...]\n"
> > +   "- print UEFI variable 'name' or all the variables\n"
> > +#endif
> > "printenv name ...\n"
> > "- print value of environment variable 'name'",
> > var_complete
> > @@ -1322,7 +1343,12 @@ U_BOOT_CMD_COMPLETE(
> >  U_BOOT_CMD_COMPLETE(
> > setenv, CONFIG_SYS_MAXARGS, 0,  do_env_set,
> > "set environment variables",
> > -   "[-f] name value ...\n"
> > +#if defined(CONFIG_CMD_NVEDIT_EFI)
> > +   "-e name [value ...]\n"
> > +   "- set UEFI variable 'name' to 'value' ...'\n"
> > +   "- delete UEFI variable

Re: [U-Boot] [PATCH v8 00/15] SiFive FU540 Support

[Tom Rini]

On Thu, Feb 21, 2019 at 04:03:41PM -0800, Palmer Dabbelt wrote:
> On Thu, 21 Feb 2019 15:41:02 PST (-0800), tr...@konsulko.com wrote:
> >On Wed, Feb 20, 2019 at 05:45:59AM +, Anup Patel wrote:
> >
> >>This patchset adds SiFive Freedom Unleashed (FU540) support
> >>to RISC-V U-Boot.
> >>
> >>The patches are based upon latest U-Boot source tree
> >>(git://git.denx.de/u-boot.git) at v2019.04-rc2 commit id
> >>f14de0014c56093feecf42ca38b8ae5b3878f176
> >>
> >>All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> >>MACB Ethernet work fine on actual SiFive Unleashed board and
> >>QEMU sifive_u machine.
> >
> >Is the sifive_u QEMU machine in upstream QEMU?  If so, lets add it to
> >the travis file and run tests.  Thanks!
> 
> It's been upstream for a while, though we might deprecate it in the future
> because the name is a bit ambiguous.  There's nothing better right now, so
> it's probably a good bet to test against.

Great!  Then we should model something based on
- name: "test/py qemu-x86"
  env:
- TEST_PY_BD="qemu-x86"
  TEST_PY_TEST_SPEC="not sleep"
  QEMU_TARGET="i386-softmmu"
  BUILDMAN="^qemu-x86$"
  TOOLCHAIN="i386"
  BUILD_ROM="yes"

And an appropriate PR to https://github.com/swarren/uboot-test-hooks so
that we can run the testsuite every time.

-- 
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 v8 00/15] SiFive FU540 Support

[Palmer Dabbelt]

On Thu, 21 Feb 2019 15:41:02 PST (-0800), tr...@konsulko.com wrote:

On Wed, Feb 20, 2019 at 05:45:59AM +, Anup Patel wrote:


This patchset adds SiFive Freedom Unleashed (FU540) support
to RISC-V U-Boot.

The patches are based upon latest U-Boot source tree
(git://git.denx.de/u-boot.git) at v2019.04-rc2 commit id
f14de0014c56093feecf42ca38b8ae5b3878f176

All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
MACB Ethernet work fine on actual SiFive Unleashed board and
QEMU sifive_u machine.


Is the sifive_u QEMU machine in upstream QEMU?  If so, lets add it to
the travis file and run tests.  Thanks!


It's been upstream for a while, though we might deprecate it in the future 
because the name is a bit ambiguous.  There's nothing better right now, so it's 
probably a good bet to test against.

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

Re: [U-Boot] [PATCH v7 4/7] cmd: efidebug: add drivers command

[AKASHI Takahiro]

On Thu, Feb 21, 2019 at 08:32:06PM +0100, Heinrich Schuchardt wrote:
> On 2/21/19 7:26 AM, AKASHI Takahiro wrote:
> > "drivers" command prints all the uefi drivers on the system.
> > 
> > => efi drivers
> > Driver   Name Image Path
> >   
> > 7ef003d0
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  cmd/efidebug.c | 95 +-
> >  1 file changed, 94 insertions(+), 1 deletion(-)
> > 
> > diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> > index 72e0652fc3e4..04fc170867fc 100644
> > --- a/cmd/efidebug.c
> > +++ b/cmd/efidebug.c
> > @@ -89,6 +89,95 @@ static int do_efi_show_devices(cmd_tbl_t *cmdtp, int 
> > flag,
> > return CMD_RET_SUCCESS;
> >  }
> >  
> > +/**
> > + * efi_get_driver_handle_info() - get information of UEFI driver
> > + *
> > + * @handle:Handle of UEFI device
> > + * @driver_name:   Driver name
> > + * @image_path:Pointer to text of device path
> > + * Return: 0 on success, -1 on failure
> > + *
> > + * Currently return no useful information as all UEFI drivers are
> > + * built-in..
> > + */
> > +static int efi_get_driver_handle_info(efi_handle_t handle, u16 
> > **driver_name,
> > + u16 **image_path)
> > +{
> > +   struct efi_handler *handler;
> > +   struct efi_loaded_image *image;
> > +   efi_status_t ret;
> > +
> > +   /*
> > +* driver name
> > +* TODO: support EFI_COMPONENT_NAME2_PROTOCOL
> > +*/
> > +   *driver_name = NULL;
> > +
> > +   /* image name */
> > +   ret = efi_search_protocol(handle, &efi_guid_loaded_image, &handler);
> > +   if (ret != EFI_SUCCESS) {
> > +   *image_path = NULL;
> > +   return 0;
> > +   }
> > +
> > +   image = handler->protocol_interface;
> > +   *image_path = efi_dp_str(image->file_path);
> > +
> > +   return 0;
> > +}
> > +
> > +/**
> > + * do_efi_show_drivers() - show UEFI drivers
> > + *
> > + * @cmdtp: Command table
> > + * @flag:  Command flag
> > + * @argc:  Number of arguments
> > + * @argv:  Argument array
> > + * Return: CMD_RET_SUCCESS on success, CMD_RET_RET_FAILURE on failure
> > + *
> > + * Implement efidebug "drivers" sub-command.
> > + * Show all UEFI drivers and their information.
> > + */
> > +static int do_efi_show_drivers(cmd_tbl_t *cmdtp, int flag,
> > +  int argc, char * const argv[])
> > +{
> > +   efi_handle_t *handles;
> > +   efi_uintn_t num, i;
> > +   u16 *driver_name, *image_path_text;
> > +   efi_status_t ret;
> > +
> > +   ret = EFI_CALL(BS->locate_handle_buffer(BY_PROTOCOL,
> > +   &efi_guid_driver_binding_protocol, NULL,
> > +   &num, &handles));
> 
> nits:
> 
> scripts/checkpatch.pl is complaining:
> Alignment should match open parenthesis
> 
> Just will have to move 'BY_PROTOCOL' to the next line to get rid of it.

No,you can't.
Ending the line with '(' will cause another error.
Or dare you prefer such a style?

-Takahiro Akashi


> Otherwise:
> 
> Reviewed-by: Heinrich Schuchardt 
> 
> > +   if (ret != EFI_SUCCESS)
> > +   return CMD_RET_FAILURE;
> > +
> > +   if (!num)
> > +   return CMD_RET_SUCCESS;
> > +
> > +   printf("Driver%.*s Name Image Path\n",
> > +  EFI_HANDLE_WIDTH - 6, spc);
> > +   printf("%.*s  \n",
> > +  EFI_HANDLE_WIDTH, sep);
> > +   for (i = 0; i < num; i++) {
> > +   if (!efi_get_driver_handle_info(handles[i], &driver_name,
> > +   &image_path_text)) {
> > +   if (image_path_text)
> > +   printf("%p %-20ls %ls\n", handles[i],
> > +  driver_name, image_path_text);
> > +   else
> > +   printf("%p %-20ls \n",
> > +  handles[i], driver_name);
> > +   EFI_CALL(BS->free_pool(driver_name));
> > +   EFI_CALL(BS->free_pool(image_path_text));
> > +   }
> > +   }
> > +
> > +   EFI_CALL(BS->free_pool(handles));
> > +
> > +   return CMD_RET_SUCCESS;
> > +}
> > +
> >  /**
> >   * do_efi_boot_add() - set UEFI boot option
> >   *
> > @@ -586,6 +675,8 @@ static cmd_tbl_t cmd_efidebug_sub[] = {
> > U_BOOT_CMD_MKENT(boot, CONFIG_SYS_MAXARGS, 1, do_efi_boot_opt, "", ""),
> > U_BOOT_CMD_MKENT(devices, CONFIG_SYS_MAXARGS, 1, do_efi_show_devices,
> >  "", ""),
> > +   U_BOOT_CMD_MKENT(drivers, CONFIG_SYS_MAXARGS, 1, do_efi_show_drivers,
> > +"", ""),
> >  };
> >  
> >  /**
> > @@ -646,7 +737,9 @@ static char efidebug_help_text[] =
> > "  - set/show UEFI boot order\n"
> > "\n"
> > "efidebug devices\n"
> > -   "  - show uefi devices\n";
> > +   "  - show uefi devices\n"
> > +   "efidebug drivers\n"
> > +   "  - show uef

[U-Boot] ut dm pch sandbox test failures

[Stephen Warren]

With the latest push to u-boot.git master branch, I'm seeing the 
following failures running test/py on sandbox:


=> ut dm pch_base
Test: dm_test_pch_base: pch.c
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:20, 
dm_test_pch_base(): 0 == uclass_first_device_err(UCLASS_PCH, &dev): 
Expected 0, got -19

Test: dm_test_pch_base: pch.c (flat tree)
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:20, 
dm_test_pch_base(): 0 == uclass_first_device_err(UCLASS_PCH, &dev): 
Expected 0, got -19

Failures: 2

=> ut dm pch_ioctl
Test: dm_test_pch_ioctl: pch.c
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:44, 
dm_test_pch_ioctl(): 0 == uclass_first_device_err(UCLASS_PCH, &dev): 
Expected 0, got -19

Test: dm_test_pch_ioctl: pch.c (flat tree)
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:44, 
dm_test_pch_ioctl(): 0 == uclass_first_device_err(UCLASS_PCH, &dev): 
Expected 0, got -19

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

Re: [U-Boot] [PATCH v8 00/15] SiFive FU540 Support

[Tom Rini]

On Wed, Feb 20, 2019 at 05:45:59AM +, Anup Patel wrote:

> This patchset adds SiFive Freedom Unleashed (FU540) support
> to RISC-V U-Boot.
> 
> The patches are based upon latest U-Boot source tree
> (git://git.denx.de/u-boot.git) at v2019.04-rc2 commit id
> f14de0014c56093feecf42ca38b8ae5b3878f176
> 
> All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> MACB Ethernet work fine on actual SiFive Unleashed board and
> QEMU sifive_u machine.

Is the sifive_u QEMU machine in upstream QEMU?  If so, lets add it to
the travis file and run tests.  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] fs: ext4: cache extent data

[Tom Rini]

On Wed, Feb 20, 2019 at 02:37:39PM -0700, Stephen Warren wrote:
> On 1/30/19 12:58 PM, Stephen Warren wrote:
> >From: Stephen Warren 
> >
> >When a file contains extents, U-Boot currently reads extent-related data
> >for each block in the file, even if that data is located in the same
> >block each time. This significantly slows down loading of files that use
> >extents. Implement a very dumb cache to prevent repeatedly reading the
> >same block. Files with extents now load as fast as files without.
> >
> >Note: There are many cases where read_allocated_block() is called. This
> >patch only addresses one of those places; all others still read redundant
> >data in any case they did before. This is a minimal patch to fix the
> >load command; other cases aren't fixed.
> 
> Any thoughts here? Thanks.

Seems better than today, was planning to grab this and the symlink stuff
for the next release.  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] configs: dra7xx_evm: Remove ENV_IS_IN_FAT and SPL_ENV_*

[Tom Rini]

On Wed, Feb 20, 2019 at 01:33:50PM +0530, Faiz Abbas wrote:
> Hi Tom,
> 
> On 19/02/19 8:45 PM, Tom Rini wrote:
> > On Tue, Feb 19, 2019 at 08:25:29PM +0530, Faiz Abbas wrote:
> > 
> >> With U-boot supporting environment in multiple places, enable only
> >> ENV_IS_IN_EMMC in U-boot.
> >>
> >> Signed-off-by: Faiz Abbas 
> > 
> > Since we had previously and intentionally enabled FAT over raw MMC
> > location, why the switch back?  Thanks!
> > 
> 
> This commit added this:
> 
> commit fb69464eae1ec5aed2ee0e3a9e5533a31ad38bac
> Author: Maxime Ripard 
> Date:   Tue Jan 23 21:17:01 2018 +0100
> 
> env: Allow to build multiple environments in Kconfig
> 
> Now that we have everything in place in the code, let's allow to build
> multiple environments backend through Kconfig.
> 
> Reviewed-by: Andre Przywara 
> Reviewed-by: Lukasz Majewski 
> Reviewed-by: Simon Glass 
> Signed-off-by: Maxime Ripard 
> 
> 
> Looking at the the cover letter for that series
> (https://patchwork.ozlabs.org/cover/842057/) , it seems to be an attempt
> to combat the increasing size of U-boot by permanently moving the
> environment to FAT partition.

Well, not exactly.  It's about allowing more than one location to be
enabled.  For example, raw eMMC when that makes sense or FAT file when
that makes sense.  If Lokesh ack's the change (or passes MAINTAINER over
to someone else who acks), OK, we'll do this.  But there's intentional
reasons we've put it in a file in FAT before, even on this platform.
But maybe use cases have changed, and that's fine.

-- 
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 4/4] configs: ti_omap5_common: Add NAND environment settings

[Tom Rini]

On Wed, Feb 20, 2019 at 03:34:53PM +0530, Faiz Abbas wrote:

> Now that NAND is supported on DRA71x include various NAND environment
> settings
> 
> Signed-off-by: Faiz Abbas 
[snip]
> +#ifdef CONFIG_NAND
> +#define NANDARGS \
> + "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
> + "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> + "nandargs=setenv bootargs console=${console} " \
> + "${optargs} " \
> + "root=${nandroot} " \
> + "rootfstype=${nandrootfstype}\0" \
> + "nandroot=ubi0:rootfs rw ubi.mtd=NAND.file-system,2048\0" \
> + "nandrootfstype=ubifs rootwait=1\0" \
> + "nandboot=echo Booting from nand ...; " \
> + "run nandargs; " \
> + "nand read ${fdtaddr} NAND.u-boot-spl-os; " \
> + "nand read ${loadaddr} NAND.kernel; " \
> + "bootz ${loadaddr} - ${fdtaddr}\0"
> +#else
> +#define NANDARGS ""
> +#endif

This kind of stuff needs to fit into include/environment/ti/ somehow,
not added to, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/7] arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded

[Tom Rini]

On Thu, Feb 21, 2019 at 04:35:06PM -0600, Andrew F. Davis wrote:

> On HS devices the 512b region of reset isolated memory called
> MCU_PSRAM0 is firewalled by default. Until SYSFW is loaded we
> cannot use this memory. It is only used to store a single value
> left at the end of SRAM by ROM that will be needed later. Save
> that value to a global variable stored in the .data section.
> This section is used as .bss will be cleared between saving
> this value and using it.
> 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Andreas Dannenberg 
> Reviewed-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 6/7] k2g: config enable ti phy dp83867 for k2g

[Tom Rini]

On Thu, Feb 21, 2019 at 12:02:06PM -0500, Murali Karicheri wrote:

> Enable ti phy dp83867 for k2g
> 
> Signed-off-by: Murali Karicheri 

Reviewed-by: Tom Rini 

-- 
Tom


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

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

[Tom Rini]

On Wed, Feb 20, 2019 at 04:52:15PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This includes the following changes to x86:
> 
> - Add support for sound.
> 
> Albeit the big changeset, changes are pretty limited to x86 only and a
> few new sound drivers used by x86 so I think it would be good to have
> this in the next release.
> 
> The following changes since commit 97f9830849c64d60d0cf2fd69e87dfe4557d02a4:
> 
>   Merge branch '2019-02-19-master-imports' (2019-02-19 20:48:11 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to e2c901c99e2622005f98a9623c4b5339257bfad3:
> 
>   x86: Add sound support for samus (2019-02-20 15:27:11 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Pull request, u-boot-tegra/master

[Tom Rini]

On Wed, Feb 20, 2019 at 09:34:57AM -0700, Tom Warren wrote:

>  Tom,
> 
> Please pull u-boot-tegra/master into U-Boot/master. Thanks!
> 
> All Tegra builds are OK, and Stephen's automated test system reports that
> all tests pass.
> 
> NOTE: This PR should supersede the previous one, sent yesterday. Thanks.
> 
> The following changes since commit 97f9830849c64d60d0cf2fd69e87dfe4557d02a4:
> 
>   Merge branch '2019-02-19-master-imports' (2019-02-19 20:48:11 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-tegra.git master
> 
> for you to fetch changes up to a3c9021771608f5b514c75874fa0d8fbee2873d6:
> 
>   board: toradex: turn off lcd backlight before OS handover (2019-02-20
> 09:01:45 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Wed, Feb 20, 2019 at 07:31:00AM +, Prabhakar Kushwaha wrote:

> Hi Tom,
> 
> The following changes since commit f14de0014c56093feecf42ca38b8ae5b3878f176:
> 
>   Prepare v2019.04-rc2 (2019-02-18 21:36:39 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fsl-qoriq.git HEAD
> 
> for you to fetch changes up to b0d4a854751b1bee75fc04fac58561212f6b9c64:
> 
>   configs: ls1021a: enable sata configs for all ls1021a defconfigs 
> (2019-02-19 10:26:44 +0530)
> 
> 
> Travis build log is https://travis-ci.org/prabhukush/u-boot/builds/495272779
> 
> Major features of pull request
> - Support of NXP's LX2160RDB and LX2160QDS platform
> - Enable SATA DM model for NXP's ARM SoCs
> 
> 

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 v2 5/7] arm: mach-k3: Add secure device build support

[Andrew F. Davis]

K3 HS devices require signed binaries for boot, use the SECDEV tools
to sign the boot artifacts during build.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Tom Rini 
Reviewed-by: Andreas Dannenberg 
---
 MAINTAINERS   |  1 +
 arch/arm/mach-k3/config.mk| 25 ++
 arch/arm/mach-k3/config_secure.mk | 44 +++
 tools/k3_fit_atf.sh   |  8 --
 4 files changed, 76 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-k3/config_secure.mk

diff --git a/MAINTAINERS b/MAINTAINERS
index 5dd69562e0..bddfaf50c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -717,6 +717,7 @@ F:  arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
 F: arch/arm/mach-omap2/sec-common.c
 F: arch/arm/mach-omap2/config_secure.mk
 F: arch/arm/mach-k3/security.c
+F: arch/arm/mach-k3/config_secure.mk
 F: configs/am335x_hs_evm_defconfig
 F: configs/am335x_hs_evm_uart_defconfig
 F: configs/am43xx_hs_evm_defconfig
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index be00d79fb0..2d8f61f9db 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -36,6 +36,14 @@ cmd_gencert = cat $(srctree)/tools/k3_x509template.txt | sed 
$(SED_OPTS) > u-boo
 # If external key is not provided, generate key using openssl.
 ifeq ($(CONFIG_SYS_K3_KEY), "")
 KEY=u-boot-spl-eckey.pem
+# On HS use real key or warn if not available
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),)
+KEY=$(TI_SECURE_DEV_PKG)/keys/custMpk.pem
+else
+$(warning "WARNING: signing key not found. Random key will NOT work on HS 
hardware!")
+endif
+endif
 else
 KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY))
 endif
@@ -65,6 +73,15 @@ ALL-y+= tiboot3.bin
 endif
 
 ifdef CONFIG_ARM64
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+SPL_ITS := u-boot-spl-k3_HS.its
+$(SPL_ITS): FORCE
+   IS_HS=1 \
+   $(srctree)/tools/k3_fit_atf.sh \
+   $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@
+
+ALL-y  += tispl.bin_HS
+else
 SPL_ITS := u-boot-spl-k3.its
 $(SPL_ITS): FORCE
$(srctree)/tools/k3_fit_atf.sh \
@@ -72,7 +89,15 @@ $(SPL_ITS): FORCE
 
 ALL-y  += tispl.bin
 endif
+endif
+
+else
 
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y  += u-boot.img_HS
 else
 ALL-y  += u-boot.img
 endif
+endif
+
+include $(srctree)/arch/arm/mach-k3/config_secure.mk
diff --git a/arch/arm/mach-k3/config_secure.mk 
b/arch/arm/mach-k3/config_secure.mk
new file mode 100644
index 00..6d63c57665
--- /dev/null
+++ b/arch/arm/mach-k3/config_secure.mk
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) 2018 Texas Instruments, Incorporated - http://www.ti.com/
+#  Andrew F. Davis 
+
+quiet_cmd_k3secureimg = SECURE  $@
+ifneq ($(TI_SECURE_DEV_PKG),)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),)
+cmd_k3secureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
+   $< $@ \
+   $(if $(KBUILD_VERBOSE:1=), >/dev/null)
+else
+cmd_k3secureimg = echo "WARNING:" \
+   "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
+   "$@ was NOT secured!"; cp $< $@
+endif
+else
+cmd_k3secureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
+   "variable must be defined for TI secure devices." \
+   "$@ was NOT secured!"; cp $< $@
+endif
+
+%.dtb_HS: %.dtb FORCE
+   $(call if_changed,k3secureimg)
+
+$(obj)/u-boot-spl-nodtb.bin_HS: $(obj)/u-boot-spl-nodtb.bin FORCE
+   $(call if_changed,k3secureimg)
+
+tispl.bin_HS: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst 
%,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST))) $(SPL_ITS) FORCE
+   $(call if_changed,mkfitimage)
+
+MKIMAGEFLAGS_u-boot.img_HS = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
+   -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
+   -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
+   $(patsubst %,-b arch/$(ARCH)/dts/%.dtb_HS,$(subst ",,$(CONFIG_OF_LIST)))
+
+OF_LIST_TARGETS = $(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst 
",,$(CONFIG_OF_LIST)))
+$(OF_LIST_TARGETS): dtbs
+
+u-boot-nodtb.bin_HS: u-boot-nodtb.bin FORCE
+   $(call if_changed,k3secureimg)
+
+u-boot.img_HS: u-boot-nodtb.bin_HS u-boot.img $(patsubst 
%.dtb,%.dtb_HS,$(OF_LIST_TARGETS)) FORCE
+   $(call if_changed,mkimage)
diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
index 430b5ca616..4e9f69c087 100755
--- a/tools/k3_fit_atf.sh
+++ b/tools/k3_fit_atf.sh
@@ -21,6 +21,10 @@ if [ ! -f $TEE ]; then
TEE=/dev/null
 fi
 
+if [ ! -z "$IS_HS" ]; then
+   HS_APPEND=_HS
+fi
+
 cat << __HEADER_EOF
 /dts-v1/;
 
@@ -51,7 +55,7 @@ cat << __HEADER_EOF
};
spl {
description = "SPL (64-bit)";
-   data = /incbin/("spl/u-boot-spl-nodtb.bin");
+   data = /incbin/("spl/u-boot-spl-nodtb.bin$HS_APPEND");
type = "standalone";

[U-Boot] [PATCH v2 6/7] configs: Add a config for AM65x High Security EVM

[Andrew F. Davis]

Add new defconfig files for the AM65x High Security EVM.

This defconfigs are the same as for the non-secure part, except for:
CONFIG_TI_SECURE_DEVICE option set to 'y'
CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y'
CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y'

Signed-off-by: Andrew F. Davis 
Reviewed-by: Tom Rini 
Reviewed-by: Andreas Dannenberg 
---
 MAINTAINERS|  2 +
 configs/am65x_hs_evm_a53_defconfig | 74 
 configs/am65x_hs_evm_r5_defconfig  | 90 ++
 3 files changed, 166 insertions(+)
 create mode 100644 configs/am65x_hs_evm_a53_defconfig
 create mode 100644 configs/am65x_hs_evm_r5_defconfig

diff --git a/MAINTAINERS b/MAINTAINERS
index bddfaf50c8..4c0be61f28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -729,6 +729,8 @@ F:  configs/k2hk_hs_evm_defconfig
 F: configs/k2e_hs_evm_defconfig
 F: configs/k2g_hs_evm_defconfig
 F: configs/k2l_hs_evm_defconfig
+F: configs/am65x_hs_evm_r5_defconfig
+F: configs/am65x_hs_evm_a53_defconfig
 
 TQ GROUP
 #M:Martin Krause 
diff --git a/configs/am65x_hs_evm_a53_defconfig 
b/configs/am65x_hs_evm_a53_defconfig
new file mode 100644
index 00..b9b5a921af
--- /dev/null
+++ b/configs/am65x_hs_evm_a53_defconfig
@@ -0,0 +1,74 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SOC_K3_AM6=y
+CONFIG_TARGET_AM654_A53_EVM=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=2
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am654-base-board"
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_INTERFACE="mmc"
+CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_K3_ARASAN=y
+CONFIG_PINCTRL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_SPL_PINCTRL=y
+# CONFIG_SPL_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_K3=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
diff --git a/configs/am65x_hs_evm_r5_defconfig 
b/configs/am65x_hs_evm_r5_defconfig
new file mode 100644
index 00..1b9c138c03
--- /dev/null
+++ b/configs/am65x_hs_evm_r5_defconfig
@@ -0,0 +1,90 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SOC_K3_AM6=y
+CONFIG_TARGET_AM654_R5_EVM=y
+CONFIG_SPL_MMC_SUPPORT=y
+CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_USE_BOOTCOMMAND=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_ASKENV=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am654-r5-base-board"
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_INTERFACE="mmc"
+CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
+CONFIG_DM=y

[U-Boot] [PATCH v2 7/7] doc: Update info on using K3 secure devices

[Andrew F. Davis]

Signed-off-by: Andrew F. Davis 
Reviewed-by: Tom Rini 
Reviewed-by: Andreas Dannenberg 
---
 doc/README.ti-secure | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/doc/README.ti-secure b/doc/README.ti-secure
index 76950253ac..27c0eaa77f 100644
--- a/doc/README.ti-secure
+++ b/doc/README.ti-secure
@@ -138,7 +138,7 @@ Booting of U-Boot SPL

 
Invoking the script for Keystone2 Secure Devices
-   =
+   
 
create-boot-image.sh \
   
@@ -157,6 +157,18 @@ Booting of U-Boot SPL
boot from all media. Secure boot from SPI NOR flash is not
currently supported.
 
+   Invoking the script for K3 Secure Devices
+   =
+
+   The signing steps required to produce a bootable SPL image on secure
+   K3 TI devices are the same as those performed on non-secure devices.
+   The only difference is the key is not checked on non-secure devices so
+   a dummy key is used when building U-Boot for those devices. For secure
+   K3 TI devices simply use the real hardware key for your device. This
+   real key can be set with the Kconfig option "K3_KEY". The environment
+   variable TI_SECURE_DEV_PKG is also searched for real keys when the
+   build targets secure devices.
+
 Booting of Primary U-Boot (u-boot.img)
 ==
 
@@ -181,10 +193,8 @@ Booting of Primary U-Boot (u-boot.img)
is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which
must be enabled for the secure boot scheme to work. In order to allow
verifying proper operation of the secure boot chain in case of 
successful
-   authentication messages like "Authentication passed: CERT_U-BOOT-NOD" 
are
-   output by the SPL to the console for each blob that got extracted from 
the
-   FIT image. Note that the last part of this log message is the 
(truncated)
-   name of the signing certificate embedded into the blob that got 
processed.
+   authentication messages like "Authentication passed" are output by the
+   SPL to the console for each blob that got extracted from the FIT image.
 
The exact details of the how the images are secured is handled by the
SECDEV package. Within the SECDEV package exists a script to process
-- 
2.19.1

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

[U-Boot] [PATCH v2 3/7] firmware: ti_sci: Modify auth_boot TI-SCI API to match new version

[Andrew F. Davis]

SYSFW version 2019.01 introduces a slightly modified version of this API,
add support for it here.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Tom Rini 
Reviewed-by: Andreas Dannenberg 
---
 drivers/firmware/ti_sci.c  | 25 -
 drivers/firmware/ti_sci.h  |  9 +++--
 include/linux/soc/ti/ti_sci_protocol.h |  4 ++--
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 534a1e6497..406b2306a9 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1700,16 +1700,19 @@ static int ti_sci_cmd_set_proc_boot_ctrl(const struct 
ti_sci_handle *handle,
  * ti_sci_cmd_proc_auth_boot_image() - Command to authenticate and load the
  * image and then set the processor configuration flags.
  * @handle:Pointer to TI SCI handle
- * @proc_id:   Processor ID this request is for
- * @cert_addr: Memory address at which payload image certificate is located.
+ * @image_addr:Memory address at which payload image and certificate is
+ * located in memory, this is updated if the image data is
+ * moved during authentication.
+ * @image_size: This is updated with the final size of the image after
+ * authentication.
  *
  * Return: 0 if all went well, else returns appropriate error value.
  */
 static int ti_sci_cmd_proc_auth_boot_image(const struct ti_sci_handle *handle,
-  u8 proc_id, u64 cert_addr)
+  u64 *image_addr, u32 *image_size)
 {
struct ti_sci_msg_req_proc_auth_boot_image req;
-   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_msg_resp_proc_auth_boot_image *resp;
struct ti_sci_info *info;
struct ti_sci_xfer *xfer;
int ret = 0;
@@ -1729,9 +1732,8 @@ static int ti_sci_cmd_proc_auth_boot_image(const struct 
ti_sci_handle *handle,
dev_err(info->dev, "Message alloc failed(%d)\n", ret);
return ret;
}
-   req.processor_id = proc_id;
-   req.cert_addr_low = cert_addr & TISCI_ADDR_LOW_MASK;
-   req.cert_addr_high = (cert_addr & TISCI_ADDR_HIGH_MASK) >>
+   req.cert_addr_low = *image_addr & TISCI_ADDR_LOW_MASK;
+   req.cert_addr_high = (*image_addr & TISCI_ADDR_HIGH_MASK) >>
TISCI_ADDR_HIGH_SHIFT;
 
ret = ti_sci_do_xfer(info, xfer);
@@ -1740,10 +1742,15 @@ static int ti_sci_cmd_proc_auth_boot_image(const struct 
ti_sci_handle *handle,
return ret;
}
 
-   resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+   resp = (struct ti_sci_msg_resp_proc_auth_boot_image 
*)xfer->tx_message.buf;
 
if (!ti_sci_is_response_ack(resp))
-   ret = -ENODEV;
+   return -ENODEV;
+
+   *image_addr = (resp->image_addr_low & TISCI_ADDR_LOW_MASK) |
+   (((u64)resp->image_addr_high <<
+ TISCI_ADDR_HIGH_SHIFT) & TISCI_ADDR_HIGH_MASK);
+   *image_size = resp->image_size;
 
return ret;
 }
diff --git a/drivers/firmware/ti_sci.h b/drivers/firmware/ti_sci.h
index 3b1f637f04..24b97d5f2c 100644
--- a/drivers/firmware/ti_sci.h
+++ b/drivers/firmware/ti_sci.h
@@ -622,7 +622,6 @@ struct ti_sci_msg_req_set_proc_boot_ctrl {
 /**
  * struct ti_sci_msg_req_proc_auth_start_image - Authenticate and start image
  * @hdr:   Generic Header
- * @processor_id:  ID of processor
  * @cert_addr_low: Lower 32bit (Little Endian) of certificate
  * @cert_addr_high:Higher 32bit (Little Endian) of certificate
  *
@@ -631,11 +630,17 @@ struct ti_sci_msg_req_set_proc_boot_ctrl {
  */
 struct ti_sci_msg_req_proc_auth_boot_image {
struct ti_sci_msg_hdr hdr;
-   u8 processor_id;
u32 cert_addr_low;
u32 cert_addr_high;
 } __packed;
 
+struct ti_sci_msg_resp_proc_auth_boot_image {
+   struct ti_sci_msg_hdr hdr;
+   u32 image_addr_low;
+   u32 image_addr_high;
+   u32 image_size;
+} __packed;
+
 /**
  * struct ti_sci_msg_req_get_proc_boot_status - Get processor boot status
  * @hdr:   Generic Header
diff --git a/include/linux/soc/ti/ti_sci_protocol.h 
b/include/linux/soc/ti/ti_sci_protocol.h
index f3c5b72860..c3bfa57253 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -250,8 +250,8 @@ struct ti_sci_proc_ops {
 u64 bv, u32 cfg_set, u32 cfg_clr);
int (*set_proc_boot_ctrl)(const struct ti_sci_handle *handle, u8 pid,
  u32 ctrl_set, u32 ctrl_clr);
-   int (*proc_auth_boot_image)(const struct ti_sci_handle *handle, u8 pid,
-   u64 caddr);
+   int (*proc_auth_boot_image)(const struct ti_sci_handle *handle,
+   u64 *image_addr, u32 *image_size);
int (*get_proc_boot_status)(const s

[U-Boot] [PATCH v2 1/7] arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded

[Andrew F. Davis]

On HS devices the 512b region of reset isolated memory called
MCU_PSRAM0 is firewalled by default. Until SYSFW is loaded we
cannot use this memory. It is only used to store a single value
left at the end of SRAM by ROM that will be needed later. Save
that value to a global variable stored in the .data section.
This section is used as .bss will be cleared between saving
this value and using it.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Andreas Dannenberg 
Reviewed-by: Lokesh Vutla 
---
 arch/arm/mach-k3/am6_init.c  | 13 -
 arch/arm/mach-k3/include/mach/am6_hardware.h |  3 ---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index a5553190b4..2301061848 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -49,11 +49,16 @@ static void ctrl_mmr_unlock(void)
mmr_unlock(CTRL_MMR0_BASE, 7);
 }
 
+/*
+ * This uninitialized global variable would normal end up in the .bss section,
+ * but the .bss is cleared between writing and reading this variable, so move
+ * it to the .data section.
+ */
+u32 bootindex __attribute__((section(".data")));
+
 static void store_boot_index_from_rom(void)
 {
-   u32 *boot_index = (u32 *)K3_BOOT_PARAM_TABLE_INDEX_VAL;
-
-   *boot_index = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
+   bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
 }
 
 void board_init_f(ulong dummy)
@@ -94,7 +99,6 @@ u32 spl_boot_mode(const u32 boot_device)
 {
 #if defined(CONFIG_SUPPORT_EMMC_BOOT)
u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
-   u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL);
 
u32 bootmode = (devstat & CTRLMMR_MAIN_DEVSTAT_BOOTMODE_MASK) >>
CTRLMMR_MAIN_DEVSTAT_BOOTMODE_SHIFT;
@@ -170,7 +174,6 @@ static u32 __get_primary_bootmedia(u32 devstat)
 u32 spl_boot_device(void)
 {
u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
-   u32 bootindex = readl(K3_BOOT_PARAM_TABLE_INDEX_VAL);
 
if (bootindex == K3_PRIMARY_BOOTMODE)
return __get_primary_bootmedia(devstat);
diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h 
b/arch/arm/mach-k3/include/mach/am6_hardware.h
index b5244609af..3343233aa3 100644
--- a/arch/arm/mach-k3/include/mach/am6_hardware.h
+++ b/arch/arm/mach-k3/include/mach/am6_hardware.h
@@ -44,7 +44,4 @@
 #define CTRLMMR_LOCK_KICK1 0x0100c
 #define CTRLMMR_LOCK_KICK1_UNLOCK_VAL  0xd172bc5a
 
-/* MCU SCRATCHPAD usage */
-#define K3_BOOT_PARAM_TABLE_INDEX_VAL  CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE
-
 #endif /* __ASM_ARCH_AM6_HARDWARE_H */
-- 
2.19.1

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

[U-Boot] [PATCH v2 4/7] arm: mach-k3: Add secure device support

[Andrew F. Davis]

K3 devices have High Security (HS) variants along with the non-HS already
supported. Like the previous generation devices (OMAP/Keystone2) K3
supports boot chain-of-trust by authenticating and optionally decrypting
images as they are unpacked from FIT images. Add support for this here.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Tom Rini 
Reviewed-by: Andreas Dannenberg 
---
 MAINTAINERS |  1 +
 arch/arm/Kconfig|  2 +-
 arch/arm/mach-k3/Makefile   |  1 +
 arch/arm/mach-k3/security.c | 63 +
 4 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-k3/security.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f1f8818d6b..5dd69562e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -716,6 +716,7 @@ S:  Supported
 F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
 F: arch/arm/mach-omap2/sec-common.c
 F: arch/arm/mach-omap2/config_secure.mk
+F: arch/arm/mach-k3/security.c
 F: configs/am335x_hs_evm_defconfig
 F: configs/am335x_hs_evm_uart_defconfig
 F: configs/am43xx_hs_evm_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 455f06cfee..da397097e5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1417,7 +1417,7 @@ endchoice
 
 config TI_SECURE_DEVICE
bool "HS Device Type Support"
-   depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS
+   depends on ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
help
  If a high secure (HS) device type is being used, this config
  must be set. This option impacts various aspects of the
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index bd4ab361b2..0c3a4f7db1 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -6,4 +6,5 @@
 obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
 obj-$(CONFIG_ARM64) += arm64-mmu.o
 obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
+obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
 obj-y += common.o
diff --git a/arch/arm/mach-k3/security.c b/arch/arm/mach-k3/security.c
new file mode 100644
index 00..52f49bf01f
--- /dev/null
+++ b/arch/arm/mach-k3/security.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * K3: Security functions
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+   struct udevice *dev;
+   struct ti_sci_handle *ti_sci;
+   struct ti_sci_proc_ops *proc_ops;
+   u64 image_addr;
+   u32 image_size;
+   int ret;
+
+   /* Get handle to Device Management and Security Controller (SYSFW) */
+   ret = uclass_get_device_by_name(UCLASS_FIRMWARE, "dmsc", &dev);
+   if (ret) {
+   printf("Failed to get handle to SYSFW (%d)\n", ret);
+   hang();
+   }
+   ti_sci = (struct ti_sci_handle *)(ti_sci_get_handle_from_sysfw(dev));
+   proc_ops = &ti_sci->ops.proc_ops;
+
+   image_addr = (uintptr_t)*p_image;
+
+   debug("Authenticating image at address 0x%016llx\n", image_addr);
+
+   /* Authenticate image */
+   ret = proc_ops->proc_auth_boot_image(ti_sci, &image_addr, &image_size);
+   if (ret) {
+   printf("Authentication failed!\n");
+   hang();
+   }
+
+   /*
+* The image_size returned may be 0 when the authentication process has
+* moved the image. When this happens no further processing on the
+* image is needed or often even possible as it may have also been
+* placed behind a firewall when moved.
+*/
+   *p_size = image_size;
+
+   /*
+* Output notification of successful authentication to re-assure the
+* user that the secure code is being processed as expected. However
+* suppress any such log output in case of building for SPL and booting
+* via YMODEM. This is done to avoid disturbing the YMODEM serial
+* protocol transactions.
+*/
+   if (!(IS_ENABLED(CONFIG_SPL_BUILD) &&
+ IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) &&
+ spl_boot_device() == BOOT_DEVICE_UART))
+   printf("Authentication passed\n");
+}
-- 
2.19.1

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

[U-Boot] [PATCH v2 2/7] firmware: ti_sci: Add support for firewall management

[Andrew F. Davis]

TI-SCI message protocol provides support for controlling the firewall
configurations available in SoC.

Introduce support for the set of TI-SCI message protocol APIs that
provide us with this capability of controlling firewalls.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Tom Rini 
Reviewed-by: Andreas Dannenberg 
---
 drivers/firmware/ti_sci.c  | 177 +
 drivers/firmware/ti_sci.h  | 121 +
 include/linux/soc/ti/ti_sci_protocol.h |  64 +
 3 files changed, 362 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 9148126041..534a1e6497 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1803,6 +1803,178 @@ static int ti_sci_cmd_get_proc_boot_status(const struct 
ti_sci_handle *handle,
return ret;
 }
 
+/**
+ * ti_sci_cmd_set_fwl_region() - Request for configuring a firewall region
+ * @handle:pointer to TI SCI handle
+ * @region:region configuration parameters
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_set_fwl_region(const struct ti_sci_handle *handle,
+const struct ti_sci_msg_fwl_region *region)
+{
+   struct ti_sci_msg_fwl_set_firewall_region_req req;
+   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_FWL_SET,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+
+   req.fwl_id = region->fwl_id;
+   req.region = region->region;
+   req.n_permission_regs = region->n_permission_regs;
+   req.control = region->control;
+   req.permissions[0] = region->permissions[0];
+   req.permissions[1] = region->permissions[1];
+   req.permissions[2] = region->permissions[2];
+   req.start_address = region->start_address;
+   req.end_address = region->end_address;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_hdr *)xfer->tx_message.buf;
+
+   if (!ti_sci_is_response_ack(resp))
+   return -ENODEV;
+
+   return 0;
+}
+
+/**
+ * ti_sci_cmd_get_fwl_region() - Request for getting a firewall region
+ * @handle:pointer to TI SCI handle
+ * @region:region configuration parameters
+ *
+ * Return: 0 if all went well, else returns appropriate error value.
+ */
+static int ti_sci_cmd_get_fwl_region(const struct ti_sci_handle *handle,
+struct ti_sci_msg_fwl_region *region)
+{
+   struct ti_sci_msg_fwl_get_firewall_region_req req;
+   struct ti_sci_msg_fwl_get_firewall_region_resp *resp;
+   struct ti_sci_info *info;
+   struct ti_sci_xfer *xfer;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+
+   xfer = ti_sci_setup_one_xfer(info, TISCI_MSG_FWL_GET,
+TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+(u32 *)&req, sizeof(req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(info->dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+
+   req.fwl_id = region->fwl_id;
+   req.region = region->region;
+   req.n_permission_regs = region->n_permission_regs;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(info->dev, "Mbox send fail %d\n", ret);
+   return ret;
+   }
+
+   resp = (struct ti_sci_msg_fwl_get_firewall_region_resp 
*)xfer->tx_message.buf;
+
+   if (!ti_sci_is_response_ack(resp))
+   return -ENODEV;
+
+   region->fwl_id = resp->fwl_id;
+   region->region = resp->region;
+   region->n_permission_regs = resp->n_permission_regs;
+   region->control = resp->control;
+   region->permissions[0] = resp->permissions[0];
+   region->permissions[1] = resp->permissions[1];
+   region->permissions[2] = resp->permissions[2];
+   region->start_address = resp->start_address;
+   region->end_address = resp->end_address;
+
+   return 0;
+}
+
+/**
+ * ti_sci_cmd_change_fwl_owner() - Request for changing a firewall owner
+ * @handle:pointer to TI SCI handle
+ * @region:

[U-Boot] [PATCH v2 0/7] AM65x HS device support

[Andrew F. Davis]

Hello all,

This series brings up HS device support on the AM65x platform. Support
for HS on K3 family devices is a bit different than previous devices
but for the most part all that has been abstracted into the SECDEV
package, allowing for a rather straight forward implementation here.

Thanks,
Andrew

Changes from v1:
 - Commented on use of .data section
 - Use ti_sci_msg_hdr header directly when possible
 - Rebase and add Reviewed-bys
 - Will add makefile cleanup later as it also affects
   files unrelated to this series

Andrew F. Davis (7):
  arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loaded
  firmware: ti_sci: Add support for firewall management
  firmware: ti_sci: Modify auth_boot TI-SCI API to match new version
  arm: mach-k3: Add secure device support
  arm: mach-k3: Add secure device build support
  configs: Add a config for AM65x High Security EVM
  doc: Update info on using K3 secure devices

 MAINTAINERS  |   4 +
 arch/arm/Kconfig |   2 +-
 arch/arm/mach-k3/Makefile|   1 +
 arch/arm/mach-k3/am6_init.c  |  13 +-
 arch/arm/mach-k3/config.mk   |  25 +++
 arch/arm/mach-k3/config_secure.mk|  44 
 arch/arm/mach-k3/include/mach/am6_hardware.h |   3 -
 arch/arm/mach-k3/security.c  |  63 ++
 configs/am65x_hs_evm_a53_defconfig   |  74 +++
 configs/am65x_hs_evm_r5_defconfig|  90 +
 doc/README.ti-secure |  20 +-
 drivers/firmware/ti_sci.c| 202 ++-
 drivers/firmware/ti_sci.h| 130 +++-
 include/linux/soc/ti/ti_sci_protocol.h   |  68 ++-
 tools/k3_fit_atf.sh  |   8 +-
 15 files changed, 718 insertions(+), 29 deletions(-)
 create mode 100644 arch/arm/mach-k3/config_secure.mk
 create mode 100644 arch/arm/mach-k3/security.c
 create mode 100644 configs/am65x_hs_evm_a53_defconfig
 create mode 100644 configs/am65x_hs_evm_r5_defconfig

-- 
2.19.1

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

Re: [U-Boot] [PATCH v2 7/8] arm: socfpga: gen5: deassert peripheral reset by default

[Marek Vasut]

On 2/21/19 11:09 PM, Simon Goldschmidt wrote:
> 
> 
> Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > geschrieben:
> 
> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > To keep the current behaviour of taking all peripherals out of reset
> > before booting the OS before removing that code from socfpga gen5 SPL,
> > this enables the new behaviour by default for all gen5 boards by
> adding
> > the environment variable "socfpga_permodrst_ungate=1" to the default
> > environment.
> >
> > This can be overridden in board config files or by saving an
> environment
> > without this variable enabled.
> >
> > Signed-off-by: Simon Goldschmidt  >
> > ---
> >
> > Changes in v2:
> > - this patch is new in v2
> >
> >  include/configs/socfpga_common.h | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/include/configs/socfpga_common.h
> b/include/configs/socfpga_common.h
> > index c9cbf8f5e3..2510c6fd7b 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -321,6 +321,19 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> > 
> >  #include 
> > 
> > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > +/*
> > + * Handle compatibility for peripheral reset for Linux kernels
> that haven't
> > + * implemented peripheral reset for all drivers.
> > + * Define this to "" disable this compatibility.
> > + */
> > +#ifndef SOCFPGA_PERMODRST_UNGATE
> > +#define SOCFPGA_PERMODRST_UNGATE "socfpga_permodrst_ungate=1\0"
> > +#endif
> > +#else
> > +#define SOCFPGA_PERMODRST_UNGATE ""
> > +#endif
> 
> Just add this socfpga_permodrst_ungate to the default end and drop all
> those macros/Kconfig options.
> 
> 
> But how would it then be overridden?

User would setenv it to "" and saveenv ? I might be missing something
obvious.

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

Re: [U-Boot] [PATCH v2 6/8] reset: socfpga: add reset handling for old kernels

[Marek Vasut]

On 2/21/19 11:07 PM, Simon Goldschmidt wrote:
> 
> 
> Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > geschrieben:
> 
> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > This adds code to take peripherals out of reset based on an
> environment
> > variable. This is in preparation for removing the code that does
> this from
> > SPL.
> >
> > However, some drivers even in current Linux cannot handle
> peripheral reset,
> > so until this works, we need a compatibility workaround.
> >
> > This workaround is implemented in the 'remove' callback of this reset
> > driver, which is called on OS_PREPARE: it checks if the environment
> > variable "socfpga_permodrst_ungate" - if it is set to 1, it
> deasserts all
> > peripheral resets, which is what the gen5 SPL did up to now.
> >
> > This is in preparation to clean up the SPL and implementing proper
> reset
> > handling for U-Boot.
> >
> > Signed-off-by: Simon Goldschmidt  >
> > ---
> >
> > Changes in v2:
> > - moved from Kernel option "OLD_SOCFPGA_KERNEL_COMPAT" to environment
> >   variable "socfpga_permodrst_ungate"
> >
> >  drivers/reset/reset-socfpga.c | 34 ++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/reset/reset-socfpga.c
> b/drivers/reset/reset-socfpga.c
> > index b2acfcd2ec..749f671e05 100644
> > --- a/drivers/reset/reset-socfpga.c
> > +++ b/drivers/reset/reset-socfpga.c
> > @@ -89,6 +89,36 @@ static int socfpga_reset_probe(struct udevice *dev)
> >       return 0;
> >  }
> > 
> > +#ifndef CONFIG_SPL_BUILD
> > +/*
> > + * This remove function is called before starting OS to deassert
> peripheral
> > + * resets for Kernels that don't support this.
> > + *
> > + * The reset driver checks the environment variable
> "socfpga_permodrst_ungate"
> > + * when it is removed. If this variable is '1', all peripherals
> in 'permodrst'
> > + * are taken out of reset before booting into the OS.
> > + * This should be required for gen5 systems only that are running
> Linux kernels
> > + * without proper peripheral reset support for all drivers used.
> > + */
> > +static int socfpga_reset_remove(struct udevice *dev)
> > +{
> > +     struct socfpga_reset_data *data = dev_get_priv(dev);
> > +     const char *env_str;
> > +     long val;
> > +
> > +     env_str = env_get("socfpga_permodrst_ungate");
> > +     if (env_str) {
> > +             val = simple_strtol(env_str, NULL, 0);
> > +             if (val == 1) {
> > +                     puts("Deasserting all peripheral resets\n");
> > +                     writel(0, data->membase + 4);
> > +             }
> > +     }
> > +
> > +     return 0;
> > +}
> > +#endif
> > +
> >  static const struct udevice_id socfpga_reset_match[] = {
> >       { .compatible = "altr,rst-mgr" },
> >       { /* sentinel */ },
> > @@ -101,4 +131,8 @@ U_BOOT_DRIVER(socfpga_reset) = {
> >       .probe = socfpga_reset_probe,
> >       .priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
> >       .ops = &socfpga_reset_ops,
> > +#ifndef CONFIG_SPL_BUILD
> > +     .remove = socfpga_reset_remove,
> > +     .flags  = DM_FLAG_OS_PREPARE,
> > +#endif
> >  };
> 
> Does this work if you use Falcon mode ? :)
> 
> 
> Probably not, but would anyone be able to use falcon mode in socfpga
> gen5 given the current SPL size? I think it didn't fit for,a last time I
> checked.

If you cut it down, why not ?

> And if it fits in the future, we probably don't need this workaraound
> any more...
> 
> I did it like that since env_get() broke compilation of SPL. But if you
> insist of making this work even for SPL, I'll check again.

SPL can also check env, so some more conditionals need to be added.
Should be a matter of some CONFIG_IS_ENABLED()

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

Re: [U-Boot] [PATCH v2 2/8] arm: socfpga: gen5: add reset & sdr node to SPL devicetrees

[Marek Vasut]

On 2/21/19 11:11 PM, Simon Goldschmidt wrote:
> 
> 
> Am Do., 21. Feb. 2019, 23:05 hat Marek Vasut  > geschrieben:
> 
> On 2/21/19 11:03 PM, Simon Goldschmidt wrote:
> >
> >
> > Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  
> > >> geschrieben:
> >
> >     On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> >     > The SPL for socfpga gen5 currently takes all peripherals out
> of reset
> >     > unconditionally. To implement proper reset handling for
> peripherals,
> >     > the reset node has to be provided with the SPL dts.
> >     >
> >     > In preparation to move the DDR driver to DM, the sdr node is
> required
> >     > in SPL, too.
> >     >
> >     > This patch adds "u-boot,dm-pre-reloc" to U-Boot specific
> dtsi addon
> >     > files so that the reset manager and SDR driver correctly
> probe in SPL.
> >     >
> >     > Signed-off-by: Simon Goldschmidt
>  
> >      >>
> >     > ---
> >     >
> >     > Changes in v2: None
> >     >
> >     >  arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi          | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts             | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_de10_nano.dts            | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_de1_soc.dts              | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_is1.dts                  | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi        | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi       | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi     | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_sr1500.dts               | 8
> 
> >     >  arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi  | 8
> 
> >     >  11 files changed, 88 insertions(+)
> >     >
> >     > diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> >     b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> >     > index c44d1ee2fa..8aaec56285 100644
> >     > --- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> >     > +++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> >     > @@ -17,6 +17,14 @@
> >     >       };
> >     >  };
> >     > 
> >     > +&rst {
> >     > +     u-boot,dm-pre-reloc;
> >     > +};
> >     > +
> >     > +&sdr {
> >     > +     u-boot,dm-pre-reloc;
> >     > +};
> >
> >     What about some socfpga-common-u-boot.dtsi to avoid duplication ?
> >
> >
> > Right. I tested with 'socfpga-u-boot.dtsi' but the hot included for
> > gen10 as well.
> 
> hot included ? I don't think I understand.
> 
> 
> Argh. I'm writing from my mobile...

It can wait till tomorrow ...

> What I meant was that file got included by the automatism so I couldn't
> use it.
Errr, which file ? What automatism ? Really, wait till tomorrow with a
reply, please.

[...]

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

Re: [U-Boot] [PATCH v2 5/8] spi: cadence_qspi: add reset handling

[Marek Vasut]

On 2/21/19 11:04 PM, Simon Goldschmidt wrote:
> 
> 
> Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > geschrieben:
> 
> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > This adds reset handling to the cadence qspi driver.
> >
> > For backwards compatibility, only a warning is printed when failing to
> > get reset handles.
> >
> > Signed-off-by: Simon Goldschmidt  >
> > ---
> >
> > Changes in v2:
> > - add .remove callback to release the resets
> >
> >  drivers/spi/cadence_qspi.c | 16 
> >  drivers/spi/cadence_qspi.h |  4 
> >  2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> > index 11fce9c4fe..3bfa0201c4 100644
> > --- a/drivers/spi/cadence_qspi.c
> > +++ b/drivers/spi/cadence_qspi.c
> > @@ -8,6 +8,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include "cadence_qspi.h"
> > @@ -154,10 +155,17 @@ static int cadence_spi_probe(struct udevice
> *bus)
> >  {
> >       struct cadence_spi_platdata *plat = bus->platdata;
> >       struct cadence_spi_priv *priv = dev_get_priv(bus);
> > +     int ret;
> > 
> >       priv->regbase = plat->regbase;
> >       priv->ahbbase = plat->ahbbase;
> > 
> > +     ret = reset_get_bulk(bus, &priv->resets);
> > +     if (ret)
> > +             dev_warn(bus, "Can't get reset: %d\n", ret);
> > +     else
> > +             reset_deassert_bulk(&priv->resets);
> > +
> >       if (!priv->qspi_is_init) {
> >               cadence_qspi_apb_controller_init(plat);
> >               priv->qspi_is_init = 1;
> > @@ -166,6 +174,13 @@ static int cadence_spi_probe(struct udevice *bus)
> >       return 0;
> >  }
> > 
> > +static int cadence_spi_remove(struct udevice *dev)
> > +{
> > +     struct cadence_spi_priv *priv = dev_get_priv(dev);
> > +
> > +     return reset_release_bulk(&priv->resets);
> > +}
> > +
> >  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
> >  {
> >       struct cadence_spi_priv *priv = dev_get_priv(bus);
> > @@ -342,4 +357,5 @@ U_BOOT_DRIVER(cadence_spi) = {
> >       .platdata_auto_alloc_size = sizeof(struct cadence_spi_platdata),
> >       .priv_auto_alloc_size = sizeof(struct cadence_spi_priv),
> >       .probe = cadence_spi_probe,
> > +     .remove = cadence_spi_remove,
> 
> .remove() only ever gets executed for drivers setting DM_FLAG_OS_PREPARE
> flag. Fix this in the other drivers too.
> 
> 
> Ehrm, I haven't checked, but is this common practice? Why doesn't it
> always get called?

That's how the code behaves. Probably to speed up booting the kernel on
devices which don't need to be torn down.

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

Re: [U-Boot] [PATCH v2 2/8] arm: socfpga: gen5: add reset & sdr node to SPL devicetrees

[Simon Goldschmidt]

Am Do., 21. Feb. 2019, 23:05 hat Marek Vasut  geschrieben:

> On 2/21/19 11:03 PM, Simon Goldschmidt wrote:
> >
> >
> > Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > > geschrieben:
> >
> > On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > > The SPL for socfpga gen5 currently takes all peripherals out of
> reset
> > > unconditionally. To implement proper reset handling for
> peripherals,
> > > the reset node has to be provided with the SPL dts.
> > >
> > > In preparation to move the DDR driver to DM, the sdr node is
> required
> > > in SPL, too.
> > >
> > > This patch adds "u-boot,dm-pre-reloc" to U-Boot specific dtsi addon
> > > files so that the reset manager and SDR driver correctly probe in
> SPL.
> > >
> > > Signed-off-by: Simon Goldschmidt  > >
> > > ---
> > >
> > > Changes in v2: None
> > >
> > >  arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi  | 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts | 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_de10_nano.dts| 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_de1_soc.dts  | 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_is1.dts  | 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi| 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi   | 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi | 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_sr1500.dts   | 8
> 
> > >  arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi  | 8
> 
> > >  11 files changed, 88 insertions(+)
> > >
> > > diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > > index c44d1ee2fa..8aaec56285 100644
> > > --- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > > +++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > > @@ -17,6 +17,14 @@
> > >   };
> > >  };
> > >
> > > +&rst {
> > > + u-boot,dm-pre-reloc;
> > > +};
> > > +
> > > +&sdr {
> > > + u-boot,dm-pre-reloc;
> > > +};
> >
> > What about some socfpga-common-u-boot.dtsi to avoid duplication ?
> >
> >
> > Right. I tested with 'socfpga-u-boot.dtsi' but the hot included for
> > gen10 as well.
>
> hot included ? I don't think I understand.
>

Argh. I'm writing from my mobile...

What I meant was that file got included by the automatism so I couldn't use
it.

Regards,
Simon


> > But your suggested name should work fine I guess.
> >
> > Regards,
> > Simon
> >
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/8] arm: socfpga: gen5: deassert peripheral reset by default

[Simon Goldschmidt]

Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  geschrieben:

> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > To keep the current behaviour of taking all peripherals out of reset
> > before booting the OS before removing that code from socfpga gen5 SPL,
> > this enables the new behaviour by default for all gen5 boards by adding
> > the environment variable "socfpga_permodrst_ungate=1" to the default
> > environment.
> >
> > This can be overridden in board config files or by saving an environment
> > without this variable enabled.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > Changes in v2:
> > - this patch is new in v2
> >
> >  include/configs/socfpga_common.h | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/include/configs/socfpga_common.h
> b/include/configs/socfpga_common.h
> > index c9cbf8f5e3..2510c6fd7b 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -321,6 +321,19 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> >
> >  #include 
> >
> > +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > +/*
> > + * Handle compatibility for peripheral reset for Linux kernels that
> haven't
> > + * implemented peripheral reset for all drivers.
> > + * Define this to "" disable this compatibility.
> > + */
> > +#ifndef SOCFPGA_PERMODRST_UNGATE
> > +#define SOCFPGA_PERMODRST_UNGATE "socfpga_permodrst_ungate=1\0"
> > +#endif
> > +#else
> > +#define SOCFPGA_PERMODRST_UNGATE ""
> > +#endif
>
> Just add this socfpga_permodrst_ungate to the default end and drop all
> those macros/Kconfig options.
>

But how would it then be overridden?

I think it'd be better to call it socfpga_legacy_reset_compat or something.
>

Ok.

Regards,
Simon


> >  #ifndef CONFIG_EXTRA_ENV_SETTINGS
> >  #define CONFIG_EXTRA_ENV_SETTINGS \
> >   "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> > @@ -330,6 +343,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> >   "scriptaddr=0x0210\0" \
> >   "pxefile_addr_r=0x0220\0" \
> >   "ramdisk_addr_r=0x0230\0" \
> > + SOCFPGA_PERMODRST_UNGATE \
> >   BOOTENV
> >
> >  #endif
> >
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFT] configs: arndale: Use appropriate driver for Asix AX88760

[Lukasz Majewski]

On Thu, 21 Feb 2019 18:08:12 +0100
Krzysztof Kozlowski  wrote:

> Arndale board has an Asix AX88760 USB 2.0 Hub and Fast Ethernet combo.
> The appropriate driver for it is USB_ETHER_ASIX.
> 
> The mistake probably came from misinterpretation of commit
> e9954b867ce0 ("usb: eth: add ASIX AX88179 DRIVER") which was tested
> on RECS5250 COM module.  This module indeed has Exynos5250 and some
> similarities with Arndale 5250 board but the USB/Ethernet chip used
> there is apparently different.
> 
> Fixes: f58ad98a621c ("usb: net: migrate USB Ethernet adapters to
> Kconfig") Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Not tested.
> ---
>  configs/arndale_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/arndale_defconfig b/configs/arndale_defconfig
> index 24422645cbac..b1f20b915889 100644
> --- a/configs/arndale_defconfig
> +++ b/configs/arndale_defconfig
> @@ -41,4 +41,4 @@ CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_HOST_ETHER=y
> -CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_ASIX=y

Reviewed-by: Lukasz Majewski 


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-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpirxqwnNQYA.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 v2 6/8] reset: socfpga: add reset handling for old kernels

[Simon Goldschmidt]

Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  geschrieben:

> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > This adds code to take peripherals out of reset based on an environment
> > variable. This is in preparation for removing the code that does this
> from
> > SPL.
> >
> > However, some drivers even in current Linux cannot handle peripheral
> reset,
> > so until this works, we need a compatibility workaround.
> >
> > This workaround is implemented in the 'remove' callback of this reset
> > driver, which is called on OS_PREPARE: it checks if the environment
> > variable "socfpga_permodrst_ungate" - if it is set to 1, it deasserts all
> > peripheral resets, which is what the gen5 SPL did up to now.
> >
> > This is in preparation to clean up the SPL and implementing proper reset
> > handling for U-Boot.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > Changes in v2:
> > - moved from Kernel option "OLD_SOCFPGA_KERNEL_COMPAT" to environment
> >   variable "socfpga_permodrst_ungate"
> >
> >  drivers/reset/reset-socfpga.c | 34 ++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/reset/reset-socfpga.c
> b/drivers/reset/reset-socfpga.c
> > index b2acfcd2ec..749f671e05 100644
> > --- a/drivers/reset/reset-socfpga.c
> > +++ b/drivers/reset/reset-socfpga.c
> > @@ -89,6 +89,36 @@ static int socfpga_reset_probe(struct udevice *dev)
> >   return 0;
> >  }
> >
> > +#ifndef CONFIG_SPL_BUILD
> > +/*
> > + * This remove function is called before starting OS to deassert
> peripheral
> > + * resets for Kernels that don't support this.
> > + *
> > + * The reset driver checks the environment variable
> "socfpga_permodrst_ungate"
> > + * when it is removed. If this variable is '1', all peripherals in
> 'permodrst'
> > + * are taken out of reset before booting into the OS.
> > + * This should be required for gen5 systems only that are running Linux
> kernels
> > + * without proper peripheral reset support for all drivers used.
> > + */
> > +static int socfpga_reset_remove(struct udevice *dev)
> > +{
> > + struct socfpga_reset_data *data = dev_get_priv(dev);
> > + const char *env_str;
> > + long val;
> > +
> > + env_str = env_get("socfpga_permodrst_ungate");
> > + if (env_str) {
> > + val = simple_strtol(env_str, NULL, 0);
> > + if (val == 1) {
> > + puts("Deasserting all peripheral resets\n");
> > + writel(0, data->membase + 4);
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +#endif
> > +
> >  static const struct udevice_id socfpga_reset_match[] = {
> >   { .compatible = "altr,rst-mgr" },
> >   { /* sentinel */ },
> > @@ -101,4 +131,8 @@ U_BOOT_DRIVER(socfpga_reset) = {
> >   .probe = socfpga_reset_probe,
> >   .priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
> >   .ops = &socfpga_reset_ops,
> > +#ifndef CONFIG_SPL_BUILD
> > + .remove = socfpga_reset_remove,
> > + .flags  = DM_FLAG_OS_PREPARE,
> > +#endif
> >  };
>
> Does this work if you use Falcon mode ? :)
>

Probably not, but would anyone be able to use falcon mode in socfpga gen5
given the current SPL size? I think it didn't fit for,a last time I checked.

And if it fits in the future, we probably don't need this workaraound any
more...

I did it like that since env_get() broke compilation of SPL. But if you
insist of making this work even for SPL, I'll check again.

Regards,
Simon

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

Re: [U-Boot] [PATCH v2 2/8] arm: socfpga: gen5: add reset & sdr node to SPL devicetrees

[Marek Vasut]

On 2/21/19 11:03 PM, Simon Goldschmidt wrote:
> 
> 
> Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > geschrieben:
> 
> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > The SPL for socfpga gen5 currently takes all peripherals out of reset
> > unconditionally. To implement proper reset handling for peripherals,
> > the reset node has to be provided with the SPL dts.
> >
> > In preparation to move the DDR driver to DM, the sdr node is required
> > in SPL, too.
> >
> > This patch adds "u-boot,dm-pre-reloc" to U-Boot specific dtsi addon
> > files so that the reset manager and SDR driver correctly probe in SPL.
> >
> > Signed-off-by: Simon Goldschmidt  >
> > ---
> >
> > Changes in v2: None
> >
> >  arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi          | 8 
> >  arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts             | 8 
> >  arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 8 
> >  arch/arm/dts/socfpga_cyclone5_de10_nano.dts            | 8 
> >  arch/arm/dts/socfpga_cyclone5_de1_soc.dts              | 8 
> >  arch/arm/dts/socfpga_cyclone5_is1.dts                  | 8 
> >  arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi        | 8 
> >  arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi       | 8 
> >  arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi     | 8 
> >  arch/arm/dts/socfpga_cyclone5_sr1500.dts               | 8 
> >  arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi  | 8 
> >  11 files changed, 88 insertions(+)
> >
> > diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > index c44d1ee2fa..8aaec56285 100644
> > --- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > +++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > @@ -17,6 +17,14 @@
> >       };
> >  };
> > 
> > +&rst {
> > +     u-boot,dm-pre-reloc;
> > +};
> > +
> > +&sdr {
> > +     u-boot,dm-pre-reloc;
> > +};
> 
> What about some socfpga-common-u-boot.dtsi to avoid duplication ?
> 
> 
> Right. I tested with 'socfpga-u-boot.dtsi' but the hot included for
> gen10 as well.

hot included ? I don't think I understand.

> But your suggested name should work fine I guess.
> 
> Regards,
> Simon
> 


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

Re: [U-Boot] [PATCH v2 5/8] spi: cadence_qspi: add reset handling

[Simon Goldschmidt]

Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  geschrieben:

> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > This adds reset handling to the cadence qspi driver.
> >
> > For backwards compatibility, only a warning is printed when failing to
> > get reset handles.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > Changes in v2:
> > - add .remove callback to release the resets
> >
> >  drivers/spi/cadence_qspi.c | 16 
> >  drivers/spi/cadence_qspi.h |  4 
> >  2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> > index 11fce9c4fe..3bfa0201c4 100644
> > --- a/drivers/spi/cadence_qspi.c
> > +++ b/drivers/spi/cadence_qspi.c
> > @@ -8,6 +8,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include "cadence_qspi.h"
> > @@ -154,10 +155,17 @@ static int cadence_spi_probe(struct udevice *bus)
> >  {
> >   struct cadence_spi_platdata *plat = bus->platdata;
> >   struct cadence_spi_priv *priv = dev_get_priv(bus);
> > + int ret;
> >
> >   priv->regbase = plat->regbase;
> >   priv->ahbbase = plat->ahbbase;
> >
> > + ret = reset_get_bulk(bus, &priv->resets);
> > + if (ret)
> > + dev_warn(bus, "Can't get reset: %d\n", ret);
> > + else
> > + reset_deassert_bulk(&priv->resets);
> > +
> >   if (!priv->qspi_is_init) {
> >   cadence_qspi_apb_controller_init(plat);
> >   priv->qspi_is_init = 1;
> > @@ -166,6 +174,13 @@ static int cadence_spi_probe(struct udevice *bus)
> >   return 0;
> >  }
> >
> > +static int cadence_spi_remove(struct udevice *dev)
> > +{
> > + struct cadence_spi_priv *priv = dev_get_priv(dev);
> > +
> > + return reset_release_bulk(&priv->resets);
> > +}
> > +
> >  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
> >  {
> >   struct cadence_spi_priv *priv = dev_get_priv(bus);
> > @@ -342,4 +357,5 @@ U_BOOT_DRIVER(cadence_spi) = {
> >   .platdata_auto_alloc_size = sizeof(struct cadence_spi_platdata),
> >   .priv_auto_alloc_size = sizeof(struct cadence_spi_priv),
> >   .probe = cadence_spi_probe,
> > + .remove = cadence_spi_remove,
>
> .remove() only ever gets executed for drivers setting DM_FLAG_OS_PREPARE
> flag. Fix this in the other drivers too.
>

Ehrm, I haven't checked, but is this common practice? Why doesn't it always
get called?

Regards,
Simon

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

Re: [U-Boot] [PATCH v2 1/8] arm: socfpga: gen5: sync devicetrees to Linux

[Marek Vasut]

On 2/21/19 11:02 PM, Simon Goldschmidt wrote:
> 
> 
> Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  > geschrieben:
> 
> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > This is again a sync to linux-next + pending patches in Dinh's tree at
> > commit 1c909b2dfe6a ("ARM: dts: socfpga: update more missing reset
> > properties")'
> >
> > It adds missing peripheral reset properties to socfpga.dtsi and
> removes
> > U-Boot specific leftovers from socfpga_cyclone5_socrates.dts.
> >
> > Signed-off-by: Simon Goldschmidt  >
> > ---
> >
> > Changes in v2:
> > - cleanly merged Linux dts (moved change of SDR controller base
> address
> >   to a separate patch)
> >
> >  arch/arm/dts/socfpga.dtsi                  | 19 +--
> >  arch/arm/dts/socfpga_cyclone5_socrates.dts |  2 --
> >  2 files changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
> > index 2458d6707d..ec1966480f 100644
> > --- a/arch/arm/dts/socfpga.dtsi
> > +++ b/arch/arm/dts/socfpga.dtsi
> > @@ -84,6 +84,7 @@
> >                               #dma-requests = <32>;
> >                               clocks = <&l4_main_clk>;
> >                               clock-names = "apb_pclk";
> > +                             resets = <&rst DMA_RESET>;
> >                       };
> >               };
> > 
> > @@ -100,6 +101,7 @@
> >                       reg = <0xffc0 0x1000>;
> >                       interrupts = <0 131 4>, <0 132 4>, <0 133
> 4>, <0 134 4>;
> >                       clocks = <&can0_clk>;
> > +                     resets = <&rst CAN0_RESET>;
> >                       status = "disabled";
> >               };
> > 
> > @@ -108,6 +110,7 @@
> >                       reg = <0xffc01000 0x1000>;
> >                       interrupts = <0 135 4>, <0 136 4>, <0 137
> 4>, <0 138 4>;
> >                       clocks = <&can1_clk>;
> > +                     resets = <&rst CAN1_RESET>;
> >                       status = "disabled";
> >               };
> > 
> > @@ -585,6 +588,7 @@
> >                       compatible = "snps,dw-apb-gpio";
> >                       reg = <0xff708000 0x1000>;
> >                       clocks = <&l4_mp_clk>;
> > +                     resets = <&rst GPIO0_RESET>;
> >                       status = "disabled";
> > 
> >                       porta: gpio-controller@0 {
> > @@ -605,6 +609,7 @@
> >                       compatible = "snps,dw-apb-gpio";
> >                       reg = <0xff709000 0x1000>;
> >                       clocks = <&l4_mp_clk>;
> > +                     resets = <&rst GPIO1_RESET>;
> >                       status = "disabled";
> > 
> >                       portb: gpio-controller@0 {
> > @@ -625,6 +630,7 @@
> >                       compatible = "snps,dw-apb-gpio";
> >                       reg = <0xff70a000 0x1000>;
> >                       clocks = <&l4_mp_clk>;
> > +                     resets = <&rst GPIO2_RESET>;
> >                       status = "disabled";
> > 
> >                       portc: gpio-controller@0 {
> > @@ -735,6 +741,7 @@
> >                       #size-cells = <0>;
> >                       clocks = <&l4_mp_clk>, <&sdmmc_clk_divided>;
> >                       clock-names = "biu", "ciu";
> > +                     resets = <&rst SDMMC_RESET>;
> >                       status = "disabled";
> >               };
> > 
> > @@ -746,9 +753,9 @@
> >                             <0xffb8 0x1>;
> >                       reg-names = "nand_data", "denali_reg";
> >                       interrupts = <0x0 0x90 0x4>;
> > -                     dma-mask = <0x>;
> >                       clocks = <&nand_clk>, <&nand_x_clk>,
> <&nand_ecc_clk>;
> >                       clock-names = "nand", "nand_x", "ecc";
> > +                     resets = <&rst NAND_RESET>;
> >                       status = "disabled";
> >               };
> > 
> > @@ -759,7 +766,7 @@
> > 
> >               qspi: spi@ff705000 {
> >                       compatible = "cdns,qspi-nor";
> > -                        #address-cells = <1>;
> > +                     #address-cells = <1>;
> >                       #size-cells = <0>;
> >                       reg = <0xff705000 0x1000>,
> >                             <0xffa0 0x1000>;
> > @@ -768,6 +775,7 @@
> >                       cdns,fifo-width = <4>;
> >                       cdns,trigger-address = <0x>;
> >                       clocks = <&qspi_clk>;
> > +                     resets = <&rs

Re: [U-Boot] [PATCH v2 2/8] arm: socfpga: gen5: add reset & sdr node to SPL devicetrees

[Simon Goldschmidt]

Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  geschrieben:

> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > The SPL for socfpga gen5 currently takes all peripherals out of reset
> > unconditionally. To implement proper reset handling for peripherals,
> > the reset node has to be provided with the SPL dts.
> >
> > In preparation to move the DDR driver to DM, the sdr node is required
> > in SPL, too.
> >
> > This patch adds "u-boot,dm-pre-reloc" to U-Boot specific dtsi addon
> > files so that the reset manager and SDR driver correctly probe in SPL.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > Changes in v2: None
> >
> >  arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi  | 8 
> >  arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts | 8 
> >  arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 8 
> >  arch/arm/dts/socfpga_cyclone5_de10_nano.dts| 8 
> >  arch/arm/dts/socfpga_cyclone5_de1_soc.dts  | 8 
> >  arch/arm/dts/socfpga_cyclone5_is1.dts  | 8 
> >  arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi| 8 
> >  arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi   | 8 
> >  arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi | 8 
> >  arch/arm/dts/socfpga_cyclone5_sr1500.dts   | 8 
> >  arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi  | 8 
> >  11 files changed, 88 insertions(+)
> >
> > diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > index c44d1ee2fa..8aaec56285 100644
> > --- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > +++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > @@ -17,6 +17,14 @@
> >   };
> >  };
> >
> > +&rst {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > +&sdr {
> > + u-boot,dm-pre-reloc;
> > +};
>
> What about some socfpga-common-u-boot.dtsi to avoid duplication ?
>

Right. I tested with 'socfpga-u-boot.dtsi' but the hot included for gen10
as well. But your suggested name should work fine I guess.

Regards,
Simon

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

Re: [U-Boot] [PATCH v2 1/8] arm: socfpga: gen5: sync devicetrees to Linux

[Simon Goldschmidt]

Am Do., 21. Feb. 2019, 22:56 hat Marek Vasut  geschrieben:

> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> > This is again a sync to linux-next + pending patches in Dinh's tree at
> > commit 1c909b2dfe6a ("ARM: dts: socfpga: update more missing reset
> > properties")'
> >
> > It adds missing peripheral reset properties to socfpga.dtsi and removes
> > U-Boot specific leftovers from socfpga_cyclone5_socrates.dts.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > Changes in v2:
> > - cleanly merged Linux dts (moved change of SDR controller base address
> >   to a separate patch)
> >
> >  arch/arm/dts/socfpga.dtsi  | 19 +--
> >  arch/arm/dts/socfpga_cyclone5_socrates.dts |  2 --
> >  2 files changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
> > index 2458d6707d..ec1966480f 100644
> > --- a/arch/arm/dts/socfpga.dtsi
> > +++ b/arch/arm/dts/socfpga.dtsi
> > @@ -84,6 +84,7 @@
> >   #dma-requests = <32>;
> >   clocks = <&l4_main_clk>;
> >   clock-names = "apb_pclk";
> > + resets = <&rst DMA_RESET>;
> >   };
> >   };
> >
> > @@ -100,6 +101,7 @@
> >   reg = <0xffc0 0x1000>;
> >   interrupts = <0 131 4>, <0 132 4>, <0 133 4>, <0
> 134 4>;
> >   clocks = <&can0_clk>;
> > + resets = <&rst CAN0_RESET>;
> >   status = "disabled";
> >   };
> >
> > @@ -108,6 +110,7 @@
> >   reg = <0xffc01000 0x1000>;
> >   interrupts = <0 135 4>, <0 136 4>, <0 137 4>, <0
> 138 4>;
> >   clocks = <&can1_clk>;
> > + resets = <&rst CAN1_RESET>;
> >   status = "disabled";
> >   };
> >
> > @@ -585,6 +588,7 @@
> >   compatible = "snps,dw-apb-gpio";
> >   reg = <0xff708000 0x1000>;
> >   clocks = <&l4_mp_clk>;
> > + resets = <&rst GPIO0_RESET>;
> >   status = "disabled";
> >
> >   porta: gpio-controller@0 {
> > @@ -605,6 +609,7 @@
> >   compatible = "snps,dw-apb-gpio";
> >   reg = <0xff709000 0x1000>;
> >   clocks = <&l4_mp_clk>;
> > + resets = <&rst GPIO1_RESET>;
> >   status = "disabled";
> >
> >   portb: gpio-controller@0 {
> > @@ -625,6 +630,7 @@
> >   compatible = "snps,dw-apb-gpio";
> >   reg = <0xff70a000 0x1000>;
> >   clocks = <&l4_mp_clk>;
> > + resets = <&rst GPIO2_RESET>;
> >   status = "disabled";
> >
> >   portc: gpio-controller@0 {
> > @@ -735,6 +741,7 @@
> >   #size-cells = <0>;
> >   clocks = <&l4_mp_clk>, <&sdmmc_clk_divided>;
> >   clock-names = "biu", "ciu";
> > + resets = <&rst SDMMC_RESET>;
> >   status = "disabled";
> >   };
> >
> > @@ -746,9 +753,9 @@
> > <0xffb8 0x1>;
> >   reg-names = "nand_data", "denali_reg";
> >   interrupts = <0x0 0x90 0x4>;
> > - dma-mask = <0x>;
> >   clocks = <&nand_clk>, <&nand_x_clk>,
> <&nand_ecc_clk>;
> >   clock-names = "nand", "nand_x", "ecc";
> > + resets = <&rst NAND_RESET>;
> >   status = "disabled";
> >   };
> >
> > @@ -759,7 +766,7 @@
> >
> >   qspi: spi@ff705000 {
> >   compatible = "cdns,qspi-nor";
> > -#address-cells = <1>;
> > + #address-cells = <1>;
> >   #size-cells = <0>;
> >   reg = <0xff705000 0x1000>,
> > <0xffa0 0x1000>;
> > @@ -768,6 +775,7 @@
> >   cdns,fifo-width = <4>;
> >   cdns,trigger-address = <0x>;
> >   clocks = <&qspi_clk>;
> > + resets = <&rst QSPI_RESET>;
> >   status = "disabled";
> >   };
> >
> > @@ -786,6 +794,7 @@
> >   sdr: sdr@ffc25000 {
> >   compatible = "altr,sdr-ctl", "syscon";
> >   reg = <0xffc25000 0x1000>;
> > + resets = <&rst SDR_RESET>;
> >   };
> >
> >   sdramedac {
> > @@ -802,6 +811,7 @@
> >   interrupts = <0 154 4>;
> >   num-cs = <4>;
> >   clocks = <&spi_m_clk>;
> > + resets = <&

Re: [U-Boot] [PATCH v2 8/8] arm: socfpga: implement proper peripheral reset

[Marek Vasut]

On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> This commit removes ad-hoc reset handling for peripheral resets from SPL
> for socfpga gen5.
> 
> This is done because as U-Boot drivers support reset handling by now.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
> Changes in v2:
> - removed Kconfig option OLD_SOCFPGA_KERNEL_COMPAT since compatibility
>   now uses an environment variable
> 
>  arch/arm/mach-socfpga/misc_gen5.c | 10 --
>  arch/arm/mach-socfpga/spl_gen5.c  | 10 --
>  2 files changed, 20 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
> b/arch/arm/mach-socfpga/misc_gen5.c
> index 6e11ba6cb2..9865f5b5b1 100644
> --- a/arch/arm/mach-socfpga/misc_gen5.c
> +++ b/arch/arm/mach-socfpga/misc_gen5.c
> @@ -201,16 +201,6 @@ int arch_early_init_r(void)
>   /* Add device descriptor to FPGA device table */
>   socfpga_fpga_add(&altera_fpga[0]);
>  
> -#ifdef CONFIG_DESIGNWARE_SPI
> - /* Get Designware SPI controller out of reset */
> - socfpga_per_reset(SOCFPGA_RESET(SPIM0), 0);
> - socfpga_per_reset(SOCFPGA_RESET(SPIM1), 0);
> -#endif
> -
> -#ifdef CONFIG_NAND_DENALI
> - socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
> -#endif
> -
>   return 0;
>  }
>  
> diff --git a/arch/arm/mach-socfpga/spl_gen5.c 
> b/arch/arm/mach-socfpga/spl_gen5.c
> index 1bff8cbfcf..e1e65261eb 100644
> --- a/arch/arm/mach-socfpga/spl_gen5.c
> +++ b/arch/arm/mach-socfpga/spl_gen5.c
> @@ -36,16 +36,12 @@ u32 spl_boot_device(void)
>   return BOOT_DEVICE_RAM;
>   case 0x2:   /* NAND Flash (1.8V) */
>   case 0x3:   /* NAND Flash (3.0V) */
> - socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
>   return BOOT_DEVICE_NAND;
>   case 0x4:   /* SD/MMC External Transceiver (1.8V) */
>   case 0x5:   /* SD/MMC Internal Transceiver (3.0V) */
> - socfpga_per_reset(SOCFPGA_RESET(SDMMC), 0);
> - socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
>   return BOOT_DEVICE_MMC1;
>   case 0x6:   /* QSPI Flash (1.8V) */
>   case 0x7:   /* QSPI Flash (3.0V) */
> - socfpga_per_reset(SOCFPGA_RESET(QSPI), 0);
>   return BOOT_DEVICE_SPI;
>   default:
>   printf("Invalid boot device (bsel=%08x)!\n", bsel);
> @@ -99,9 +95,7 @@ void board_init_f(ulong dummy)
>   socfpga_bridges_reset(1);
>   }
>  
> - socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
>   socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0);
> -
>   timer_init();
>  
>   debug("Reconfigure Clock Manager\n");
> @@ -123,10 +117,6 @@ void board_init_f(ulong dummy)
>   sysmgr_pinmux_init();
>   sysmgr_config_warmrstcfgio(0);
>  
> - /* De-assert reset for peripherals and bridges based on handoff */
> - reset_deassert_peripherals_handoff();
> - socfpga_bridges_reset(0);
> -
>   debug("Unfreezing/Thaw all I/O banks\n");
>   /* unfreeze / thaw all IO banks */
>   sys_mgr_frzctrl_thaw_req();
> 

Nice!

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

Re: [U-Boot] [PATCH v2 5/8] spi: cadence_qspi: add reset handling

[Marek Vasut]

On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> This adds reset handling to the cadence qspi driver.
> 
> For backwards compatibility, only a warning is printed when failing to
> get reset handles.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
> Changes in v2:
> - add .remove callback to release the resets
> 
>  drivers/spi/cadence_qspi.c | 16 
>  drivers/spi/cadence_qspi.h |  4 
>  2 files changed, 20 insertions(+)
> 
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> index 11fce9c4fe..3bfa0201c4 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "cadence_qspi.h"
> @@ -154,10 +155,17 @@ static int cadence_spi_probe(struct udevice *bus)
>  {
>   struct cadence_spi_platdata *plat = bus->platdata;
>   struct cadence_spi_priv *priv = dev_get_priv(bus);
> + int ret;
>  
>   priv->regbase = plat->regbase;
>   priv->ahbbase = plat->ahbbase;
>  
> + ret = reset_get_bulk(bus, &priv->resets);
> + if (ret)
> + dev_warn(bus, "Can't get reset: %d\n", ret);
> + else
> + reset_deassert_bulk(&priv->resets);
> +
>   if (!priv->qspi_is_init) {
>   cadence_qspi_apb_controller_init(plat);
>   priv->qspi_is_init = 1;
> @@ -166,6 +174,13 @@ static int cadence_spi_probe(struct udevice *bus)
>   return 0;
>  }
>  
> +static int cadence_spi_remove(struct udevice *dev)
> +{
> + struct cadence_spi_priv *priv = dev_get_priv(dev);
> +
> + return reset_release_bulk(&priv->resets);
> +}
> +
>  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
>  {
>   struct cadence_spi_priv *priv = dev_get_priv(bus);
> @@ -342,4 +357,5 @@ U_BOOT_DRIVER(cadence_spi) = {
>   .platdata_auto_alloc_size = sizeof(struct cadence_spi_platdata),
>   .priv_auto_alloc_size = sizeof(struct cadence_spi_priv),
>   .probe = cadence_spi_probe,
> + .remove = cadence_spi_remove,

.remove() only ever gets executed for drivers setting DM_FLAG_OS_PREPARE
flag. Fix this in the other drivers too.

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

Re: [U-Boot] [PATCH v2 7/8] arm: socfpga: gen5: deassert peripheral reset by default

[Marek Vasut]

On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> To keep the current behaviour of taking all peripherals out of reset
> before booting the OS before removing that code from socfpga gen5 SPL,
> this enables the new behaviour by default for all gen5 boards by adding
> the environment variable "socfpga_permodrst_ungate=1" to the default
> environment.
> 
> This can be overridden in board config files or by saving an environment
> without this variable enabled.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
> Changes in v2:
> - this patch is new in v2
> 
>  include/configs/socfpga_common.h | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index c9cbf8f5e3..2510c6fd7b 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -321,6 +321,19 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>  
>  #include 
>  
> +#ifdef CONFIG_TARGET_SOCFPGA_GEN5
> +/*
> + * Handle compatibility for peripheral reset for Linux kernels that haven't
> + * implemented peripheral reset for all drivers.
> + * Define this to "" disable this compatibility.
> + */
> +#ifndef SOCFPGA_PERMODRST_UNGATE
> +#define SOCFPGA_PERMODRST_UNGATE "socfpga_permodrst_ungate=1\0"
> +#endif
> +#else
> +#define SOCFPGA_PERMODRST_UNGATE ""
> +#endif

Just add this socfpga_permodrst_ungate to the default end and drop all
those macros/Kconfig options.

I think it'd be better to call it socfpga_legacy_reset_compat or something.

>  #ifndef CONFIG_EXTRA_ENV_SETTINGS
>  #define CONFIG_EXTRA_ENV_SETTINGS \
>   "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> @@ -330,6 +343,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>   "scriptaddr=0x0210\0" \
>   "pxefile_addr_r=0x0220\0" \
>   "ramdisk_addr_r=0x0230\0" \
> + SOCFPGA_PERMODRST_UNGATE \
>   BOOTENV
>  
>  #endif
> 


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

Re: [U-Boot] [PATCH v2 6/8] reset: socfpga: add reset handling for old kernels

[Marek Vasut]

On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> This adds code to take peripherals out of reset based on an environment
> variable. This is in preparation for removing the code that does this from
> SPL.
> 
> However, some drivers even in current Linux cannot handle peripheral reset,
> so until this works, we need a compatibility workaround.
> 
> This workaround is implemented in the 'remove' callback of this reset
> driver, which is called on OS_PREPARE: it checks if the environment
> variable "socfpga_permodrst_ungate" - if it is set to 1, it deasserts all
> peripheral resets, which is what the gen5 SPL did up to now.
> 
> This is in preparation to clean up the SPL and implementing proper reset
> handling for U-Boot.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
> Changes in v2:
> - moved from Kernel option "OLD_SOCFPGA_KERNEL_COMPAT" to environment
>   variable "socfpga_permodrst_ungate"
> 
>  drivers/reset/reset-socfpga.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
> index b2acfcd2ec..749f671e05 100644
> --- a/drivers/reset/reset-socfpga.c
> +++ b/drivers/reset/reset-socfpga.c
> @@ -89,6 +89,36 @@ static int socfpga_reset_probe(struct udevice *dev)
>   return 0;
>  }
>  
> +#ifndef CONFIG_SPL_BUILD
> +/*
> + * This remove function is called before starting OS to deassert peripheral
> + * resets for Kernels that don't support this.
> + *
> + * The reset driver checks the environment variable 
> "socfpga_permodrst_ungate"
> + * when it is removed. If this variable is '1', all peripherals in 
> 'permodrst'
> + * are taken out of reset before booting into the OS.
> + * This should be required for gen5 systems only that are running Linux 
> kernels
> + * without proper peripheral reset support for all drivers used.
> + */
> +static int socfpga_reset_remove(struct udevice *dev)
> +{
> + struct socfpga_reset_data *data = dev_get_priv(dev);
> + const char *env_str;
> + long val;
> +
> + env_str = env_get("socfpga_permodrst_ungate");
> + if (env_str) {
> + val = simple_strtol(env_str, NULL, 0);
> + if (val == 1) {
> + puts("Deasserting all peripheral resets\n");
> + writel(0, data->membase + 4);
> + }
> + }
> +
> + return 0;
> +}
> +#endif
> +
>  static const struct udevice_id socfpga_reset_match[] = {
>   { .compatible = "altr,rst-mgr" },
>   { /* sentinel */ },
> @@ -101,4 +131,8 @@ U_BOOT_DRIVER(socfpga_reset) = {
>   .probe = socfpga_reset_probe,
>   .priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
>   .ops = &socfpga_reset_ops,
> +#ifndef CONFIG_SPL_BUILD
> + .remove = socfpga_reset_remove,
> + .flags  = DM_FLAG_OS_PREPARE,
> +#endif
>  };

Does this work if you use Falcon mode ? :)

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

Re: [U-Boot] [PATCH v2 2/8] arm: socfpga: gen5: add reset & sdr node to SPL devicetrees

[Marek Vasut]

On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
> The SPL for socfpga gen5 currently takes all peripherals out of reset
> unconditionally. To implement proper reset handling for peripherals,
> the reset node has to be provided with the SPL dts.
> 
> In preparation to move the DDR driver to DM, the sdr node is required
> in SPL, too.
> 
> This patch adds "u-boot,dm-pre-reloc" to U-Boot specific dtsi addon
> files so that the reset manager and SDR driver correctly probe in SPL.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi  | 8 
>  arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts | 8 
>  arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi | 8 
>  arch/arm/dts/socfpga_cyclone5_de10_nano.dts| 8 
>  arch/arm/dts/socfpga_cyclone5_de1_soc.dts  | 8 
>  arch/arm/dts/socfpga_cyclone5_is1.dts  | 8 
>  arch/arm/dts/socfpga_cyclone5_socdk-u-boot.dtsi| 8 
>  arch/arm/dts/socfpga_cyclone5_sockit-u-boot.dtsi   | 8 
>  arch/arm/dts/socfpga_cyclone5_socrates-u-boot.dtsi | 8 
>  arch/arm/dts/socfpga_cyclone5_sr1500.dts   | 8 
>  arch/arm/dts/socfpga_cyclone5_vining_fpga-u-boot.dtsi  | 8 
>  11 files changed, 88 insertions(+)
> 
> diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi 
> b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> index c44d1ee2fa..8aaec56285 100644
> --- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> +++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> @@ -17,6 +17,14 @@
>   };
>  };
>  
> +&rst {
> + u-boot,dm-pre-reloc;
> +};
> +
> +&sdr {
> + u-boot,dm-pre-reloc;
> +};

What about some socfpga-common-u-boot.dtsi to avoid duplication ?

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