Re: [PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()

2020-12-21 Thread Miquel Raynal
Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
17:17:56 +0100:

> Hi Miquel
> 
> Le 21/12/2020 à 16:49, Miquel Raynal a écrit :
> > Hi Richard,
> > 
> > Richard Genoud  wrote on Mon, 21 Dec 2020
> > 16:40:51 +0100:
> >   
> >> Hi Miquel,
> >>
> >> Le 21/12/2020 à 16:29, Miquel Raynal a écrit :  
> >>> Hi Richard,
> >>>
> >>> Richard Genoud  wrote on Mon, 21 Dec 2020
> >>> 16:26:00 +0100:  
> >>> Le 21/12/2020 à 16:14, Miquel Raynal a écrit :  
> > Hi Richard,
> >
> > Richard Genoud  wrote on Mon, 21 Dec 2020
> > 16:06:37 +0100:  
> >  Hi Miquel,  
> >>
> >> Le 18/12/2020 à 19:50, Miquel Raynal a écrit :  
> >>> Hi Richard,
> >>>
> >>> Richard Genoud  wrote on Fri, 18 Dec 2020
> >>> 15:24:40 +0100:  
> >>>   token_count may be != 0 and token_list not yet allocated 
> >>> when the out  
>  code is reached  
> >>>
> >>> Wouldn't it be better to initialize token_count than adding an
> >>> (obscure) indentation level?  
> >> Well, token_count is initialized :
> >> token_count = sqfs_count_tokens(filename);
> >>
> >> But token_list is not yet populated. It is some lines bellow:
> >> token_list = malloc(token_count * sizeof(char *));
> >>
> >>
> >> But I could use something like that, maybe it's clearer :
> >>for (j = 0; (token_list != NULL) && (j < token_count); j++)
> >>free(token_list[j]);  
> >
> > I had a look at the code, the error path is clearly not correctly
> > organized.
> >
> > I think the right approach would be to have real labels like,
> > free_token_list, free_this, free_that and for each of them only do the
> > right cleanup. Doing so should fix the issue.  
> 
>  So you're suggesting to revert this ?
>  commit ea1b1651c6a8 ("fs/squashfs: sqfs_opendir: simplify error 
>  handling")  
> >>>
> >>> Yes (our e-mails crossed each other), I think it's best to have a well
> >>> organized error path. Of course this error path is maybe faulty, in
> >>> this case it must be fixed. But I personally prefer the revert + fix
> >>> approach.  
> >>>>>  
> >> But I really don't see why it's obscure to test a pointer before 
> >> dereference.  
> > 
> > Testing a pointer before dereference is not obscure.
> > 
> > Testing a pointer in an error path because the error path is common to
> > all 10 different possible failure cases and might free the content of an
> > array that has not been allocated yet: this is obscure.
> >   
> >> Maybe I should I've wrote :
> >>  if (token_list != NULL)
> >>  for (j = 0; j < token_count; j++)
> >>  free(token_list[j]);
> >>
> >> Does it looks better ?  
> > 
> > Not really :)  
> 
> Ok, so if you insist, I send the revert correcting the coverity issue.
> 
> But in this case, the error management won't be coherent with the rest of the 
> file.
> (And I *really* don't want to revert to the old error handling for every 
> single function.)

Well, I was against taking this direction from the beginning, now we
are at a point where the error path must be fixed because you need to
take extra precautions that you would have avoided by keeping the well
organized labels.

Thanks,
Miquèl


Re: [PATCH 1/1] x86: typo segement

2020-12-21 Thread Bin Meng
On Tue, Dec 22, 2020 at 2:53 PM Heinrich Schuchardt  wrote:
>
> %s/segement/segment/
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/x86/cpu/i386/cpu.c | 2 +-
>  arch/x86/cpu/start.S| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


Please pull u-boot-x86

2020-12-21 Thread Bin Meng
Hi Tom,

This PR includes the following changes for v2021.01 release:

- Update Intel Edison doc information about xFSTK
- Move and rename fsp_types.h file to signatures.h

Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=304=results

The following changes since commit c15f44acf9d473f4682bfdc63b8aebd313492b15:

  Prepare v2021.01-rc4 (2020-12-21 15:03:24 -0500)

are available in the git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-x86

for you to fetch changes up to 6ef1b7508740dfce9b30f172839b385361e8bd50:

  fsp: Move and rename fsp_types.h file (2020-12-22 10:19:40 +0800)


Andy Shevchenko (1):
  doc: edison: Update information about xFSTK

Sughosh Ganu (1):
  fsp: Move and rename fsp_types.h file

 arch/x86/include/asm/fsp/fsp_support.h   |  3 ++-
 doc/board/intel/edison.rst   | 49
+
 arch/x86/include/asm/fsp/fsp_types.h => include/signatures.h |  6 +++---
 3 files changed, 34 insertions(+), 24 deletions(-)
 rename arch/x86/include/asm/fsp/fsp_types.h => include/signatures.h (95%)

Regards,
Bin


[PATCH 1/1] x86: typo segement

2020-12-21 Thread Heinrich Schuchardt
%s/segement/segment/

Signed-off-by: Heinrich Schuchardt 
---
 arch/x86/cpu/i386/cpu.c | 2 +-
 arch/x86/cpu/start.S| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
index 7517b756f4..6fa0f4d32b 100644
--- a/arch/x86/cpu/i386/cpu.c
+++ b/arch/x86/cpu/i386/cpu.c
@@ -175,7 +175,7 @@ void arch_setup_gd(gd_t *new_gd)
  * Per Intel FSP external architecture specification, before calling any FSP
  * APIs, we need make sure the system is in flat 32-bit mode and both the code
  * and data selectors should have full 4GB access range. Here we reuse the one
- * we used in arch/x86/cpu/start16.S, and reload the segement registers.
+ * we used in arch/x86/cpu/start16.S, and reload the segment registers.
  */
 void setup_fsp_gdt(void)
 {
diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index 3b6ed37bc0..3d0d95295f 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
@@ -77,7 +77,7 @@ _start:
lgdtgdt_ptr2
 #endif

-   /* Load the segement registers to match the GDT loaded in start16.S */
+   /* Load the segment registers to match the GDT loaded in start16.S */
movl$(X86_GDT_ENTRY_32BIT_DS * X86_GDT_ENTRY_SIZE), %eax
movw%ax, %fs
movw%ax, %ds
--
2.29.2



[PATCH v2 2/2] riscv: timer: Add support for an early timer

2020-12-21 Thread Pragnesh Patel
Added support for timer_early_get_count() and timer_early_get_rate()
This is mostly useful in tracing.

Signed-off-by: Pragnesh Patel 
---

Changes in v2:
- make u-boot compile for qemu (include/configs/qemu-riscv.h)

 drivers/timer/andes_plmt_timer.c   | 21 -
 drivers/timer/riscv_timer.c| 21 -
 drivers/timer/sifive_clint_timer.c | 21 -
 include/configs/ax25-ae350.h   |  5 +
 include/configs/qemu-riscv.h   |  5 +
 include/configs/sifive-fu540.h |  5 +
 6 files changed, 75 insertions(+), 3 deletions(-)

diff --git a/drivers/timer/andes_plmt_timer.c b/drivers/timer/andes_plmt_timer.c
index cec86718c7..74b795c97a 100644
--- a/drivers/timer/andes_plmt_timer.c
+++ b/drivers/timer/andes_plmt_timer.c
@@ -17,11 +17,30 @@
 /* mtime register */
 #define MTIME_REG(base)((ulong)(base))
 
-static u64 andes_plmt_get_count(struct udevice *dev)
+static u64 notrace andes_plmt_get_count(struct udevice *dev)
 {
return readq((void __iomem *)MTIME_REG(dev->priv));
 }
 
+#if CONFIG_IS_ENABLED(RISCV_MMODE)
+/**
+ * timer_early_get_rate() - Get the timer rate before driver model
+ */
+unsigned long notrace timer_early_get_rate(void)
+{
+   return RISCV_MMODE_TIMER_FREQ;
+}
+
+/**
+ * timer_early_get_count() - Get the timer count before driver model
+ *
+ */
+u64 notrace timer_early_get_count(void)
+{
+   return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE));
+}
+#endif
+
 static const struct timer_ops andes_plmt_ops = {
.get_count = andes_plmt_get_count,
 };
diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
index 21ae184057..a0f71ca897 100644
--- a/drivers/timer/riscv_timer.c
+++ b/drivers/timer/riscv_timer.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 
-static u64 riscv_timer_get_count(struct udevice *dev)
+static u64 notrace riscv_timer_get_count(struct udevice *dev)
 {
__maybe_unused u32 hi, lo;
 
@@ -31,6 +31,25 @@ static u64 riscv_timer_get_count(struct udevice *dev)
return ((u64)hi << 32) | lo;
 }
 
+#if CONFIG_IS_ENABLED(RISCV_SMODE)
+/**
+ * timer_early_get_rate() - Get the timer rate before driver model
+ */
+unsigned long notrace timer_early_get_rate(void)
+{
+   return RISCV_SMODE_TIMER_FREQ;
+}
+
+/**
+ * timer_early_get_count() - Get the timer count before driver model
+ *
+ */
+u64 notrace timer_early_get_count(void)
+{
+   return riscv_timer_get_count(NULL);
+}
+#endif
+
 static int riscv_timer_probe(struct udevice *dev)
 {
struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
diff --git a/drivers/timer/sifive_clint_timer.c 
b/drivers/timer/sifive_clint_timer.c
index 00ce0f08d6..9ae05a0e7e 100644
--- a/drivers/timer/sifive_clint_timer.c
+++ b/drivers/timer/sifive_clint_timer.c
@@ -14,11 +14,30 @@
 /* mtime register */
 #define MTIME_REG(base)((ulong)(base) + 0xbff8)
 
-static u64 sifive_clint_get_count(struct udevice *dev)
+static u64 notrace sifive_clint_get_count(struct udevice *dev)
 {
return readq((void __iomem *)MTIME_REG(dev->priv));
 }
 
+#if CONFIG_IS_ENABLED(RISCV_MMODE)
+/**
+ * timer_early_get_rate() - Get the timer rate before driver model
+ */
+unsigned long notrace timer_early_get_rate(void)
+{
+   return RISCV_MMODE_TIMER_FREQ;
+}
+
+/**
+ * timer_early_get_count() - Get the timer count before driver model
+ *
+ */
+u64 notrace timer_early_get_count(void)
+{
+   return readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE));
+}
+#endif
+
 static const struct timer_ops sifive_clint_ops = {
.get_count = sifive_clint_get_count,
 };
diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
index b2606e794d..bd9c371f83 100644
--- a/include/configs/ax25-ae350.h
+++ b/include/configs/ax25-ae350.h
@@ -17,6 +17,11 @@
 #endif
 #endif
 
+#define RISCV_MMODE_TIMERBASE   0xe600
+#define RISCV_MMODE_TIMER_FREQ  6000
+
+#define RISCV_SMODE_TIMER_FREQ  6000
+
 /*
  * CPU and Board Configuration Options
  */
diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
index a2f33587c2..5291de83f8 100644
--- a/include/configs/qemu-riscv.h
+++ b/include/configs/qemu-riscv.h
@@ -29,6 +29,11 @@
 
 #define CONFIG_STANDALONE_LOAD_ADDR0x8020
 
+#define RISCV_MMODE_TIMERBASE  0x200
+#define RISCV_MMODE_TIMER_FREQ 100
+
+#define RISCV_SMODE_TIMER_FREQ 100
+
 /* Environment options */
 
 #ifndef CONFIG_SPL_BUILD
diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h
index c1c79db147..0d69d1c548 100644
--- a/include/configs/sifive-fu540.h
+++ b/include/configs/sifive-fu540.h
@@ -36,6 +36,11 @@
 
 #define CONFIG_STANDALONE_LOAD_ADDR0x8020
 
+#define RISCV_MMODE_TIMERBASE  0x200
+#define RISCV_MMODE_TIMER_FREQ 100
+
+#define RISCV_SMODE_TIMER_FREQ 100
+
 /* Environment options */
 
 #ifndef CONFIG_SPL_BUILD
-- 

[PATCH v2 1/2] trace: select TIMER_EARLY to avoid infinite recursion

2020-12-21 Thread Pragnesh Patel
When tracing functions is enabled this adds calls to
__cyg_profile_func_enter() and __cyg_profile_func_exit() to the traced
functions.

__cyg_profile_func_enter() and __cyg_profile_func_exit() invoke
timer_get_us() to record the entry and exit time.

initr_dm() will make gd->dm_root = NULL and gd->timer = NULL, so
timer_get_us() -> get_ticks() -> dm_timer_init() will lead to an
indefinite recursion.

So select TIMER_EARLY when tracing got enabled.

Signed-off-by: Pragnesh Patel 
---

Changes in v2:
- new patch

 lib/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index 7673d2e4e0..671386963a 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -210,6 +210,7 @@ config BITREVERSE
 config TRACE
bool "Support for tracing of function calls and timing"
imply CMD_TRACE
+   select TIMER_EARLY
help
  Enables function tracing within U-Boot. This allows recording of call
  traces including timing information. The command can write data to
-- 
2.17.1



Re: [PATCH v2 14/14] qemu: arm64: Add documentation for capsule update

2020-12-21 Thread Sughosh Ganu
On Mon, 21 Dec 2020 at 23:21, Heinrich Schuchardt 
wrote:

> On 12/21/20 6:12 PM, Sughosh Ganu wrote:
> > On Mon, 21 Dec 2020 at 18:28, Heinrich Schuchardt 
> > wrote:
> >
> >> On 12/21/20 12:43 PM, Sughosh Ganu wrote:
> >>> Add documentation highlighting the steps for using the uefi capsule
> >>> update feature for updating the u-boot firmware image.
> >>>
> >>> Signed-off-by: Sughosh Ganu 
> >>> ---
> >>>
> >>> Changes since V1:
> >>> * Change the documentation to reflect the usage of overlays for
> >>> embedding the public key certs at runtime
> >>> * Fix the build for 'make htmldocs'
> >>>
> >>>doc/board/emulation/qemu-arm.rst | 188
> +++
> >>
> >> Why do you put the information into doc/board/emulation/qemu-arm.rst?
> >>
> >> Isn't the same applicable to RISC-V QEMU?
> >>
> >
> > Where do you want me to put it. Currently, I do not see any common
> document
> > for qemu which can be shared between qemu-arm and qemu risc-v. Or do you
> > think a new document should be created under doc/board/emulation/
> > directory. Moreover, my series is adding support for capsule update
> feature
> > on the qemu arm64 platform, and i have only tested this feature on the
> qemu
> > arm64 platform. If someone wants to extend this on the qemu
> > risc-v platform, that work i think needs to be done separately, with
> > whatever changes that may be needed to get capsule updates working on
> qemu
> > risc-v. If you so prefer, I can move the changes made for mtdparts and
> > dfu(patches 4/14 and 5/14) under a common directory under
> board/emulation.
>
>
> I have started putting the documentation for shell commands into
> doc/usage. This is where a description of efidebug could be placed.
>
> Equally I think we should put the documentation of tools like
> mkeficapsule under doc/usage.
>
> The description on the usage of the UEFI firmware protocol would fit
> into doc/uefi/uefi.rst.
>
> When it comes to things that are really QEMU specific
> doc/board/emulation/ is the right folder.
>

Ok. I will create a Qemu specific file for capsule updates under the
doc/board/emulation/ directory.


>
> See more comments below.
>
> >
> > -sughosh
> >
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>1 file changed, 188 insertions(+)
> >>>
> >>> diff --git a/doc/board/emulation/qemu-arm.rst
> >> b/doc/board/emulation/qemu-arm.rst
> >>> index 8d7fda10f1..11d91811b3 100644
> >>> --- a/doc/board/emulation/qemu-arm.rst
> >>> +++ b/doc/board/emulation/qemu-arm.rst
> >>> @@ -90,3 +90,191 @@ The debug UART on the ARM virt board uses these
> >> settings::
> >>>CONFIG_DEBUG_UART_PL010=y
> >>>CONFIG_DEBUG_UART_BASE=0x900
> >>>CONFIG_DEBUG_UART_CLOCK=0
> >>> +
> >>> +Enabling Uefi Capsule Update feature
> >>> +
> >>> +
> >>> +Support has been added for the uefi capsule update feature which
> >>> +enables updating the u-boot image using the uefi firmware management
>
> %s/uefi/UEFI/
>
> >>> +protocol (fmp). The capsules are not passed to the firmware through
> >>> +the UpdateCapsule runtime service. Instead, capsule-on-disk
> >>> +functionality is used for fetching the capsule from the EFI System
> >>> +Partition (ESP).
>
> According to the UEFI spec the relevant directory is \EFI\UpdateCapsule.
> I think you should mentions this path.
>
> >>> +
> >>> +Currently, support has been added for updating the u-boot binary as a
>
> %s/u-boot/U-Boot/g
>
> >>> +raw image when the platform is booted in non-secure mode, i.e with
>
> %s/i.e/i.e./
>
> >>> +CONFIG_TFABOOT disabled. For this configuration, the qemu platform
>
> %s/qemu/QEMU/
>
> >>> +needs to be booted with 'secure=off'. The u-boot binary placed on the
>
> U-Boot
>
> >>> +first bank of the Nor Flash at offset 0x0. The u-boot environment is
>
> %s/Nor Flash/NOR flash/
>
> U-Boot
>
> >>> +placed on the second Nor Flash bank at offset 0x400.
>
> NOR flash
>
> >>> +
> >>> +The capsule update feature is enabled with the following configs::
>
> %s/configs/configuration settings/
>
> >>> +
> >>> +CONFIG_MTD=y
> >>> +CONFIG_FLASH_CFI_MTD=y
> >>> +CONFIG_CMD_MTDPARTS=y
> >>> +CONFIG_CMD_DFU=y
> >>> +CONFIG_DFU_MTD=y
> >>> +CONFIG_PCI_INIT_R=y
> >>> +CONFIG_EFI_CAPSULE_ON_DISK=y
> >>> +CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
> >>> +CONFIG_EFI_CAPSULE_FIRMWARE=y
> >>> +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> >>> +CONFIG_EFI_CAPSULE_FMP_HEADER=y
> >>> +
> >>> +In addition, the following config needs to be disabled::
> >>> +
> >>> +CONFIG_TFABOOT
> >>> +
> >>> +The capsule file can be generated by using the GenerateCapsule.py
> >>> +script in edk2::
>
> EDK II
>
> >>> +
> >>> +$ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \
> >>> + --fw-version  --lsv  --guid \
> >>> +e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose
> --update-image-index
> >> \
> >>> + --verbose 
> >>> +
> >>> +As per the uefi specification, the capsule file 

RE: [PATCH] imx8mp_evk: Increase CONFIG_SYS_MALLOC_F_LEN

2020-12-21 Thread Peng Fan
> Subject: [PATCH] imx8mp_evk: Increase CONFIG_SYS_MALLOC_F_LEN
> 
> When booting imx8mp-evk the following allocation error message is seen:
> 
> U-Boot 2021.01-rc3-00200-ge668bec96a5f (Dec 21 2020 - 14:36:42 -0300)
> 
> alloc space exhausted
> 
> Fix it by increasing CONFIG_SYS_MALLOC_F_LEN to 0x1 like it is done on
> other i.MX8MM/8MN boards.
> 
> Reported-by: Andrey Zhizhikin 
> Signed-off-by: Fabio Estevam 

Reviewed-by: Peng Fan 

I think it might be the DM clk exhausted the space, we need find a way to
improve that.

Thanks,
Peng.

> ---
>  configs/imx8mp_evk_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig
> index cd5724e811ab..c34a10c2d906 100644
> --- a/configs/imx8mp_evk_defconfig
> +++ b/configs/imx8mp_evk_defconfig
> @@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x4020
> CONFIG_SPL_GPIO_SUPPORT=y  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> CONFIG_SPL_LIBGENERIC_SUPPORT=y
> -CONFIG_SYS_MALLOC_F_LEN=0x8000
> +CONFIG_SYS_MALLOC_F_LEN=0x1
>  CONFIG_ENV_SIZE=0x1000
>  CONFIG_ENV_OFFSET=0x40
>  CONFIG_SYS_I2C_MXC_I2C1=y
> --
> 2.17.1



[PATCH v4] cmd: Add a pwm command

2020-12-21 Thread Pragnesh Patel
Add the command "pwm" for controlling the pwm channels. This
command provides pwm invert/config/enable/disable functionalities
via PWM uclass drivers

Signed-off-by: Pragnesh Patel 
Reviewed-by: Simon Glass 
---

Changes in v4:
- Add ut_assertok() for every run_command()

Changes in v3:
- Replace goto with return
- Print return value for error
- Change the assert condition for success

Changes in v2:
- Add test for pwm command

 README|   1 +
 cmd/Kconfig   |   6 ++
 cmd/Makefile  |   1 +
 cmd/pwm.c | 117 ++
 configs/sandbox_defconfig |   1 +
 test/cmd/Makefile |   1 +
 test/cmd/pwm.c|  47 +++
 7 files changed, 174 insertions(+)
 create mode 100644 cmd/pwm.c
 create mode 100644 test/cmd/pwm.c

diff --git a/README b/README
index cb49aa15da..dab291e0d0 100644
--- a/README
+++ b/README
@@ -3160,6 +3160,7 @@ i2c   - I2C sub-system
 sspi   - SPI utility commands
 base   - print or set address offset
 printenv- print environment variables
+pwm- control pwm channels
 setenv - set environment variables
 saveenv - save environment variables to persistent storage
 protect - enable or disable FLASH write protection
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 1595de999b..0d085108f4 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -918,6 +918,12 @@ config CMD_GPIO
help
  GPIO support.
 
+config CMD_PWM
+   bool "pwm"
+   depends on DM_PWM
+   help
+ Control PWM channels, this allows invert/config/enable/disable PWM 
channels.
+
 config CMD_GPT
bool "GPT (GUID Partition Table) command"
select EFI_PARTITION
diff --git a/cmd/Makefile b/cmd/Makefile
index dd86675bf2..75df3c136c 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -120,6 +120,7 @@ endif
 obj-$(CONFIG_CMD_PINMUX) += pinmux.o
 obj-$(CONFIG_CMD_PMC) += pmc.o
 obj-$(CONFIG_CMD_PSTORE) += pstore.o
+obj-$(CONFIG_CMD_PWM) += pwm.o
 obj-$(CONFIG_CMD_PXE) += pxe.o pxe_utils.o
 obj-$(CONFIG_CMD_WOL) += wol.o
 obj-$(CONFIG_CMD_QFW) += qfw.o
diff --git a/cmd/pwm.c b/cmd/pwm.c
new file mode 100644
index 00..5849fc57b6
--- /dev/null
+++ b/cmd/pwm.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Control PWM channels
+ *
+ * Copyright (c) 2020 SiFive, Inc
+ * author: Pragnesh Patel 
+ */
+
+#include 
+#include 
+#include 
+
+enum pwm_cmd {
+   PWM_SET_INVERT,
+   PWM_SET_CONFIG,
+   PWM_SET_ENABLE,
+   PWM_SET_DISABLE,
+};
+
+static int do_pwm(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   const char *str_cmd, *str_channel = NULL, *str_enable = NULL;
+   const char *str_pwm = NULL, *str_period = NULL, *str_duty = NULL;
+   enum pwm_cmd sub_cmd;
+   struct udevice *dev;
+   u32 channel, pwm_enable, pwm_dev, period_ns = 0, duty_ns = 0;
+   int ret;
+
+   if (argc < 4)
+   return CMD_RET_USAGE;
+
+   str_cmd = argv[1];
+   argc -= 2;
+   argv += 2;
+
+   if (argc > 0) {
+   str_pwm = *argv;
+   argc--;
+   argv++;
+   }
+
+   if (!str_pwm)
+   return CMD_RET_USAGE;
+
+   switch (*str_cmd) {
+   case 'i':
+   sub_cmd = PWM_SET_INVERT;
+   break;
+   case 'c':
+   sub_cmd = PWM_SET_CONFIG;
+   break;
+   case 'e':
+   sub_cmd = PWM_SET_ENABLE;
+   break;
+   case 'd':
+   sub_cmd = PWM_SET_DISABLE;
+   break;
+   default:
+   return CMD_RET_USAGE;
+   }
+
+   pwm_dev = simple_strtoul(str_pwm, NULL, 10);
+   ret = uclass_get_device(UCLASS_PWM, pwm_dev, );
+   if (ret) {
+   printf("pwm: '%s' not found\n", str_pwm);
+   return cmd_process_error(cmdtp, ret);
+   }
+
+   if (argc > 0) {
+   str_channel = *argv;
+   channel = simple_strtoul(str_channel, NULL, 10);
+   argc--;
+   argv++;
+   } else {
+   return CMD_RET_USAGE;
+   }
+
+   if (sub_cmd == PWM_SET_INVERT && argc > 0) {
+   str_enable = *argv;
+   pwm_enable = simple_strtoul(str_enable, NULL, 10);
+   ret = pwm_set_invert(dev, channel, pwm_enable);
+   } else if (sub_cmd == PWM_SET_CONFIG && argc == 2) {
+   str_period = *argv;
+   argc--;
+   argv++;
+   period_ns = simple_strtoul(str_period, NULL, 10);
+
+   if (argc > 0) {
+   str_duty = *argv;
+   duty_ns = simple_strtoul(str_duty, NULL, 10);
+   }
+
+   ret = pwm_set_config(dev, channel, period_ns, duty_ns);
+   } else if (sub_cmd == PWM_SET_ENABLE) {
+   ret = pwm_set_enable(dev, channel, 1);
+   } else if (sub_cmd == PWM_SET_DISABLE) {
+   ret = 

test_efi_selftest occasionally fails on qemu-x86?

2020-12-21 Thread Bin Meng
Hi,

Please check the log:
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=302=logs=cf9e8018-ed89-5c32-5567-a8524d857521=4197aefe-2a0c-53e5-5744-78f78ce6022b

Re-run the pipeline with the same commit, the tests pass.
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=304=logs=cf9e8018-ed89-5c32-5567-a8524d857521=4197aefe-2a0c-53e5-5744-78f78ce6022b

There might be some instability on qemu-x86 with efi_selftest. Any ideas?

Regards,
Bin


Re: [PATCH] sysboot: add zboot support to boot x86 image

2020-12-21 Thread Bin Meng
Hi Kory,

On Fri, Dec 11, 2020 at 1:49 AM Kory Maincent  wrote:
>

Please put some commit message here.

> Signed-off-by: Kory Maincent 
> ---
>  cmd/pxe_utils.c   | 4 
>  include/command.h | 2 ++
>  2 files changed, 6 insertions(+)
>
> diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
> index 53af04d7dc..deaedcf347 100644
> --- a/cmd/pxe_utils.c
> +++ b/cmd/pxe_utils.c
> @@ -548,6 +548,10 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label 
> *label)
> /* Try booting a Image */
> else
> do_bootz(cmdtp, 0, bootm_argc, bootm_argv);
> +#elif defined(CONFIG_CMD_ZBOOT)
> +   /* Try booting an x86_64 Image */

What about x86?

> +   else
> +   do_zboot(cmdtp, 0, bootm_argc, bootm_argv);
>  #endif
> unmap_sysmem(buf);
>
> diff --git a/include/command.h b/include/command.h
> index d1063774ce..57fe65000b 100644
> --- a/include/command.h
> +++ b/include/command.h
> @@ -133,6 +133,8 @@ extern int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[]);
>
>  extern int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[]);
>
> +extern int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[]);
> +
>  extern int common_diskboot(cmd_tbl_t *cmdtp, const char *intf, int argc,
>char *const argv[]);
>

Regards,
Bin


Re: [PATCH v2] fsp: Move and rename fsp_types.h file

2020-12-21 Thread Bin Meng
On Mon, Dec 14, 2020 at 2:23 PM Sughosh Ganu  wrote:
>
> The fsp_types.h header file contains macros for building signatures of
> different widths. These signature macros are architecture agnostic,
> and can be used in all places which use signatures in a data
> structure. Move and rename the fsp_types.h under the common include
> header.
>
> Signed-off-by: Sughosh Ganu 
> ---
>
> Changes since v1:
> Handled review comments from Simon Glass
>
> Build tested for cougarcanyon2 board which builds the
> relevant fsp code.
>
>  arch/x86/include/asm/fsp/fsp_support.h  | 3 ++-
>  .../x86/include/asm/fsp/fsp_types.h => include/signatures.h | 6 +++---
>  2 files changed, 5 insertions(+), 4 deletions(-)
>  rename arch/x86/include/asm/fsp/fsp_types.h => include/signatures.h (95%)
>

applied to u-boot-x86, thanks!


Re: [PATCH] fsp: Move and rename fsp_types.h file

2020-12-21 Thread Bin Meng
On Fri, Dec 11, 2020 at 6:06 PM Sughosh Ganu  wrote:
>
> The fsp_types.h header file contains macros for building signatures of
> different widths. These signature macros are architecture agnostic,
> and can be used in all places which use signatures in a data
> structure. Move and rename the fsp_types.h under the common include
> header.
>
> Signed-off-by: Sughosh Ganu 
> ---
>
> Build tested for cougarcanyon2 board which builds the
> relevant fsp code.
>
>  arch/x86/include/asm/fsp/fsp_support.h  | 3 ++-
>  .../asm/fsp/fsp_types.h => include/signature_types.h| 6 +++---
>  2 files changed, 5 insertions(+), 4 deletions(-)
>  rename arch/x86/include/asm/fsp/fsp_types.h => include/signature_types.h 
> (94%)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1] doc: edison: Update information about xFSTK

2020-12-21 Thread Bin Meng
On Fri, Nov 27, 2020 at 11:46 PM Andy Shevchenko
 wrote:
>
> xFSTK sources got a new home under Edison Firmware Group on GitHub [1].
> Update Intel Edison documentation accordingly.
>
> While here, fix couple of typos.
>
> [1]: https://github.com/edison-fw
>
> Signed-off-by: Andy Shevchenko 
> ---
>  doc/board/intel/edison.rst | 32 +---
>  1 file changed, 21 insertions(+), 11 deletions(-)
>

applied to u-boot-x86, thanks!


RE: [PATCH v2] imx: ahab: allow to bypass confirmation for ahab_close cmd

2020-12-21 Thread Peng Fan
> Subject: [PATCH v2] imx: ahab: allow to bypass confirmation for ahab_close
> cmd
> 
> Calling ahab_close cmd force the user to interact for confirmation.
> 
> This is not user-friendly when using this cmd during factory process.
> 
> Allow the user to pass '-y' option to bypass this confirmation.
> 
> Signed-off-by: Clément Péron 

Reviewed-by: Peng Fan 

> ---
> v2:
>   - Fix commit log
> 
> ---
>  arch/arm/mach-imx/imx8/ahab.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/imx8/ahab.c
> b/arch/arm/mach-imx/imx8/ahab.c index cf3c7d762a74..b0865c2330a2
> 100644
> --- a/arch/arm/mach-imx/imx8/ahab.c
> +++ b/arch/arm/mach-imx/imx8/ahab.c
> @@ -301,10 +301,11 @@ static int confirm_close(void)  static int
> do_ahab_close(cmd_tbl_t *cmdtp, int flag, int argc,
>char * const argv[])
>  {
> + int confirmed = argc >= 2 && !strcmp(argv[1], "-y");
>   int err;
>   u16 lc;
> 
> - if (!confirm_close())
> + if (!confirmed && !confirm_close())
>   return -EACCES;
> 
>   err = sc_seco_chip_info(-1, , NULL, NULL, NULL);
> --
> 2.25.1



RE: imx8mp_evk: boot error "alloc space exhausted"

2020-12-21 Thread Peng Fan
> Subject: Re: imx8mp_evk: boot error "alloc space exhausted"
> 
> On Mon, Dec 21, 2020 at 11:19 AM Fabio Estevam 
> wrote:
> 
> > I have also tried using the ATF version imx_5.4.70_2.3.0 and the DDR
> > firmware from the firmware-5.10 package, but still does not boot for
> > me:
> >
> > U-Boot SPL 2021.01-rc3-00200-ge668bec96a5f-dirty (Dec 21 2020 -
> > 11:13:56 -0300) Normal Boot
> > WDT:   Started with servicing (60s timeout)
> > Trying to boot from BOOTROM
> > image offset 0x8000, pagesize 0x200, ivt offset 0x0
> >
> > It would be great to have this fixed for the upcoming 2021.01 release.
> 
> Ok, I re-built U-Boot using the instructions from
> doc/board/freescale/imx8mp_evk.rst and now it boots fine.
> 
> I will submit a patch increasing CONFIG_SYS_MALLOC_F_LEN as reported by
> Andrey.

Ah. There must be something exhausted the heap. We use too large malloc f area
now.

Regards,
Peng.

> 
> Thanks


RE: [PATCH] doc: board: freescale: advise to use newer atf and firmware

2020-12-21 Thread Peng Fan
> Subject: [PATCH] doc: board: freescale: advise to use newer atf and firmware
> 
> Update branch and version information of ATF and DDR firmware files to point
> to latest releases provided by NXP.
> 
> This is especially critical for imx8mp evk, as the ATF support for that SoC is
> only available in latest releases.
> 
> Align all SoCs from imx8m family to use identical revisions of ATF and DDR
> firmware.
> 
> Signed-off-by: Andrey Zhizhikin 

Thanks for the effort.

Reviewed-by: Peng Fan 

> ---
>  doc/board/freescale/imx8mm_evk.rst | 10 +-
> doc/board/freescale/imx8mn_evk.rst | 10 +-
> doc/board/freescale/imx8mp_evk.rst | 16 
> doc/board/freescale/imx8mq_evk.rst | 12 ++--
>  4 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/doc/board/freescale/imx8mm_evk.rst
> b/doc/board/freescale/imx8mm_evk.rst
> index f75190227c..a9ccdb7850 100644
> --- a/doc/board/freescale/imx8mm_evk.rst
> +++ b/doc/board/freescale/imx8mm_evk.rst
> @@ -18,7 +18,7 @@ Get and Build the ARM Trusted firmware
> 
>  Note: builddir is U-Boot build directory (source directory for in-tree 
> builds)
> Get ATF from:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource
> .codeaurora.org%2Fexternal%2Fimx%2Fimx-atfdata=04%7C01%7Cpen
> g.fan%40nxp.com%7C17ea116c2ca44f3ee06008d89fa6bf7d%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637434885818043019%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000sdata=JB5DHy0ymYFYB3JN4J%2FWS3
> WNBtwIIi7Zj0uNgu793fc%3Dreserved=0
> -branch: imx_4.19.35_1.0.0
> +branch: imx_5.4.47_2.2.0
> 
>  .. code-block:: bash
> 
> @@ -30,10 +30,10 @@ Get the ddr firmware
> 
>  .. code-block:: bash
> 
> -   $ wget
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2Ffirmware-imx-8.0.bin
> mp;data=04%7C01%7Cpeng.fan%40nxp.com%7C17ea116c2ca44f3ee06008d
> 89fa6bf7d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6374348
> 85818043019%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TsZF
> LW7w5c2tOeaB9kK5RC5V9%2BvvTfMTI7fidA1kH%2Bc%3Dreserved=0
> -   $ chmod +x firmware-imx-8.0.bin
> -   $ ./firmware-imx-8.0
> -   $ cp firmware-imx-8.0/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
> +   $ wget
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2Ffirmware-imx-8.9.bin
> mp;data=04%7C01%7Cpeng.fan%40nxp.com%7C17ea116c2ca44f3ee06008d
> 89fa6bf7d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6374348
> 85818043019%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5vP4
> 2YnY58cCWV5cIc3X8eQJ%2F%2FACKikIrRxPXjaweSQ%3Dreserved=0
> +   $ chmod +x firmware-imx-8.9.bin
> +   $ ./firmware-imx-8.9
> +   $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
> 
>  Build U-Boot
>  
> diff --git a/doc/board/freescale/imx8mn_evk.rst
> b/doc/board/freescale/imx8mn_evk.rst
> index c3e92cecee..375e0bb761 100644
> --- a/doc/board/freescale/imx8mn_evk.rst
> +++ b/doc/board/freescale/imx8mn_evk.rst
> @@ -18,7 +18,7 @@ Get and Build the ARM Trusted firmware
> 
>  Note: srctree is U-Boot source directory  Get ATF from:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource
> .codeaurora.org%2Fexternal%2Fimx%2Fimx-atfdata=04%7C01%7Cpen
> g.fan%40nxp.com%7C17ea116c2ca44f3ee06008d89fa6bf7d%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C637434885818043019%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000sdata=JB5DHy0ymYFYB3JN4J%2FWS3
> WNBtwIIi7Zj0uNgu793fc%3Dreserved=0
> -branch: imx_4.19.35_1.1.0
> +branch: imx_5.4.47_2.2.0
> 
>  .. code-block:: bash
> 
> @@ -30,10 +30,10 @@ Get the ddr firmware
> 
>  .. code-block:: bash
> 
> -   $ wget
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2Ffirmware-imx-8.5.bin
> mp;data=04%7C01%7Cpeng.fan%40nxp.com%7C17ea116c2ca44f3ee06008d
> 89fa6bf7d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6374348
> 85818043019%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=2fTO
> 1XnVhcrXUIjNnP%2Bblgx7BB%2FuqUECFZjZeaPg9Xo%3Dreserved=0
> -   $ chmod +x firmware-imx-8.5.bin
> -   $ ./firmware-imx-8.5
> -   $ cp firmware-imx-8.5/firmware/ddr/synopsys/ddr4*.bin $(srctree)
> +   $ wget
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2Ffirmware-imx-8.9.bin
> mp;data=04%7C01%7Cpeng.fan%40nxp.com%7C17ea116c2ca44f3ee06008d
> 89fa6bf7d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6374348
> 85818043019%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5vP4
> 2YnY58cCWV5cIc3X8eQJ%2F%2FACKikIrRxPXjaweSQ%3Dreserved=0
> +   $ chmod +x 

Re: [PATCH] drivers: mmc: support secure erase.

2020-12-21 Thread Jaehoon Chung
Hi,

CC'd Peng (mmc maintainer).

On 12/18/20 10:21 PM, dennis wrote:
> According to the JEDEC Standard, eMMC v4.4 cards can supoort secure erase.
> the first bit in ext_csd[EXT_CSD_SEC_FEATURE_SUPPORT] - EXT_CSD_SEC_ER_EN
> is used to check if secure erase supoort by the device.

%s/supoort/supports/

Anyway, i don't know what

> 
> Signed-off-by: dennis 
> ---
>  drivers/mmc/Kconfig |  8 
>  drivers/mmc/mmc.c   |  4 
>  drivers/mmc/mmc_write.c | 16 +---
>  include/mmc.h   |  5 -
>  4 files changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 14d7913986..6105cbe960 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -18,6 +18,14 @@ config MMC_WRITE
>   help
> Enable write access to MMC and SD Cards
>  
> +config MMC_SECURE_ERASE
> + bool "Enable secure erase for eMMC"
> + depends on MMC_WRITE
> + default n
> + help
> +   This option replace the default erase with secure erase in eMMC v4.4
> +   and above cards.
> +
>  config MMC_BROKEN_CD
>   bool "Poll for broken card detection case"
>   help
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index a6394bcf30..56b17070e7 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2272,6 +2272,10 @@ static int mmc_startup_v4(struct mmc *mmc)
>   if ((capacity >> 20) > 2 * 1024)
>   mmc->capacity_user = capacity;
>   }
> +#if CONFIG_IS_ENABLED(MMC_SECURE_ERASE)
> + if (mmc->version >= MMC_VERSION_4_4 && IS_MMC(mmc))

if (IS_ENABLED())?

> + mmc->sec_feature_support = ext_csd[EXT_CSD_SEC_FEATURE_SUPPORT];
> +#endif
>  
>   if (mmc->version >= MMC_VERSION_4_5)
>   mmc->gen_cmd6_time = ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
> diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
> index 6a4453ca02..0b720ccf7e 100644
> --- a/drivers/mmc/mmc_write.c
> +++ b/drivers/mmc/mmc_write.c
> @@ -15,7 +15,7 @@
>  #include 
>  #include "mmc_private.h"
>  
> -static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
> +static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt, uint 
> arg)
>  {
>   struct mmc_cmd cmd;
>   ulong end;
> @@ -52,7 +52,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start, 
> lbaint_t blkcnt)
>   goto err_out;
>  
>   cmd.cmdidx = MMC_CMD_ERASE;
> - cmd.cmdarg = MMC_ERASE_ARG;
> + cmd.cmdarg = arg;
>   cmd.resp_type = MMC_RSP_R1b;
>  
>   err = mmc_send_cmd(mmc, , NULL);
> @@ -81,6 +81,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t 
> start, lbaint_t blkcnt)
>   struct mmc *mmc = find_mmc_device(dev_num);
>   lbaint_t blk = 0, blk_r = 0;
>   int timeout_ms = 1000;
> + uint arg = MMC_ERASE_ARG;
>  
>   if (!mmc)
>   return -1;
> @@ -105,6 +106,15 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t 
> start, lbaint_t blkcnt)
>  ((start + blkcnt + mmc->erase_grp_size)
>  & ~(mmc->erase_grp_size - 1)) - 1);
>  
> +#if CONFIG_IS_ENABLED(MMC_SECURE_ERASE)
> + if (!(mmc->sec_feature_support & EXT_CSD_SEC_ER_EN)) {

ditto. if (IS_ENABLED()) instead of #if.
And i don't know why doesn't check this in mmc_erase_t().
Then it doesn't need to pass arg as argument.

> + printf("secure erase not supported on device\n"
> +"perform insecure erase\n");
> + } else {
> + arg = MMC_SECURE_ERASE_ARG;
> + }
> +#endif
> +
>   while (blk < blkcnt) {
>   if (IS_SD(mmc) && mmc->ssr.au) {
>   blk_r = ((blkcnt - blk) > mmc->ssr.au) ?
> @@ -113,7 +123,7 @@ ulong mmc_berase(struct blk_desc *block_dev, lbaint_t 
> start, lbaint_t blkcnt)
>   blk_r = ((blkcnt - blk) > mmc->erase_grp_size) ?
>   mmc->erase_grp_size : (blkcnt - blk);
>   }
> - err = mmc_erase_t(mmc, start + blk, blk_r);
> + err = mmc_erase_t(mmc, start + blk, blk_r, arg);
>   if (err)
>   break;
>  
> diff --git a/include/mmc.h b/include/mmc.h
> index 1d377e0281..bfdc712bdd 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -80,7 +80,6 @@ struct bd_info;
>  #define MMC_MODE_1BITBIT(28)
>  #define MMC_MODE_SPI BIT(27)
>  
> -

Not need to touch this.

>  #define SD_DATA_4BIT 0x0004
>  
>  #define IS_SD(x) ((x)->version & SD_VERSION_SD)
> @@ -240,6 +239,7 @@ static inline bool mmc_is_tuning_cmd(uint cmdidx)
>  #define EXT_CSD_HC_WP_GRP_SIZE   221 /* RO */
>  #define EXT_CSD_HC_ERASE_GRP_SIZE224 /* RO */
>  #define EXT_CSD_BOOT_MULT226 /* RO */
> +#define EXT_CSD_SEC_FEATURE_SUPPORT 231 /* RO */
>  #define EXT_CSD_GENERIC_CMD6_TIME   248 /* RO */
>  #define EXT_CSD_BKOPS_SUPPORT502 /* RO */
>  
> @@ -247,6 

Re: [PATCH] power: pmic: add driver for Monolithic Power mp5416

2020-12-21 Thread Jaehoon Chung
Hi,

On 12/22/20 1:19 AM, Tim Harvey wrote:
> This adds basic register access and child regulator binding
> for the Monolithic MP5416 Power Management IC which integrates
> four DC/DC switching converters and five LDO regulators.

Do you have a plan to send patches about using this pmic?
Because your patch doesn't have any defconfig to enable.

I think that if you have a plan, send entire patchset with this patch.
Without any use-case, this patch will be deadcode.
(or if i missed some patches, let me know, plz)

Best Regards,
Jaehoon Chung

> 
> Signed-off-by: Tim Harvey 
> ---
>  drivers/power/pmic/Kconfig  | 15 +++
>  drivers/power/pmic/Makefile |  1 +
>  drivers/power/pmic/mp5416.c | 98 
> +
>  include/power/mp5416.h  | 41 +++
>  4 files changed, 155 insertions(+)
>  create mode 100644 drivers/power/pmic/mp5416.c
>  create mode 100644 include/power/mp5416.h
> 
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index a62aa38..13a9cb0 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -91,6 +91,21 @@ config DM_PMIC_FAN53555
> The driver implements read/write operations for use with the FAN53555
> regulator driver and binds the regulator driver to its node.
>  
> +config DM_PMIC_MP5416
> + bool "Enable Driver Model for PMIC MP5416"
> + depends on DM_PMIC
> + help
> +   This config enables implementation of driver-model pmic uclass 
> features
> +   for PMIC MP5416. The driver implements read/write operations.
> +
> +config SPL_DM_PMIC_MP5416
> + bool "Enable Driver Model for PMIC MP5416 in SPL stage"
> + depends on DM_PMIC
> + help
> +   This config enables implementation of driver-model pmic uclass
> +   features for PMIC MP5416. The driver implements read/write
> +   operations.
> +
>  config DM_PMIC_PCA9450
>   bool "Enable Driver Model for PMIC PCA9450"
>   depends on DM_PMIC
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 9cd6c37..2b2a6dd 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
>  obj-$(CONFIG_DM_PMIC_MAX8998) += max8998.o
>  obj-$(CONFIG_DM_PMIC_MC34708) += mc34708.o
>  obj-$(CONFIG_$(SPL_)DM_PMIC_BD71837) += bd71837.o
> +obj-$(CONFIG_$(SPL_)DM_PMIC_MP5416) += mp5416.o
>  obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
>  obj-$(CONFIG_$(SPL_)DM_PMIC_PCA9450) += pca9450.o
>  obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
> diff --git a/drivers/power/pmic/mp5416.c b/drivers/power/pmic/mp5416.c
> new file mode 100644
> index 000..458c4df
> --- /dev/null
> +++ b/drivers/power/pmic/mp5416.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier:  GPL-2.0+
> +/*
> + * Copyright 2020 Gateworks Corporation
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static const struct pmic_child_info pmic_children_info[] = {
> + /* buck */
> + { .prefix = "b", .driver = MP6416_REGULATOR_DRIVER },
> + /* ldo */
> + { .prefix = "l", .driver = MP6416_REGULATOR_DRIVER },
> + { },
> +};
> +
> +static int mp5416_reg_count(struct udevice *dev)
> +{
> + return MP5416_NUM_OF_REGS - 1;
> +}
> +
> +static int mp5416_write(struct udevice *dev, uint reg, const uint8_t *buff,
> + int len)
> +{
> + if (dm_i2c_write(dev, reg, buff, len)) {
> + pr_err("write error to device: %p register: %#x!", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int mp5416_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
> +{
> + if (dm_i2c_read(dev, reg, buff, len)) {
> + pr_err("read error from device: %p register: %#x!", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int mp5416_bind(struct udevice *dev)
> +{
> + int children;
> + ofnode regulators_node;
> +
> + debug("%s %s\n", __func__, dev->name);
> + regulators_node = dev_read_subnode(dev, "regulators");
> + if (!ofnode_valid(regulators_node)) {
> + debug("%s: %s regulators subnode not found!\n", __func__,
> +   dev->name);
> + return -ENXIO;
> + }
> +
> + debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
> +
> + children = pmic_bind_children(dev, regulators_node, pmic_children_info);
> + if (!children)
> + debug("%s: %s - no child found\n", __func__, dev->name);
> +
> + /* Always return success for this device */
> + return 0;
> +}
> +
> +static int mp5416_probe(struct udevice *dev)
> +{
> + debug("%s %s\n", __func__, dev->name);
> +
> + return 0;
> +}
> +
> +static struct dm_pmic_ops mp5416_ops = {
> + .reg_count = mp5416_reg_count,
> + .read = mp5416_read,
> + .write = 

Re: [PATCH 2/8] spl: fit: Factor out FIT parsing and use a context struct

2020-12-21 Thread Alex G.




On 12/21/20 2:23 PM, Simon Glass wrote:

Hi Alex,

On Mon, 21 Dec 2020 at 12:28, Alex G.  wrote:


On 12/18/20 8:28 PM, Simon Glass wrote:

Hi Alexandru,

On Tue, 15 Dec 2020 at 17:09, Alexandru Gagniuc  wrote:


The logical steps in spl_load_simple_fit() are difficult to follow.
I think the long comments, ifdefs, and ungodly number of variables
seriously affect the readability. In particular, it violates section 6
of the coding style, paragraphs (3), and (4).

The purpose of this patch is to improve the situation by
- Factoring out initialization and parsing to separate functions
- Reduce the number of variables by using a context structure
This change introduces no functional changes.

Signed-off-by: Alexandru Gagniuc 
---
   common/spl/spl_fit.c | 87 ++--
   1 file changed, 60 insertions(+), 27 deletions(-)


This certainly looks a lot better although your email address does not
inspire confidence...


Don't worry. It doesn't bite.


Do you think you could look at creating a sandbox SPL test for this?
It should be possible to write it in C, set up a bit of data, call
your function and check the results.


I can look at it. I can't promise anything though, since this is the
first time I heard of the sandbox. Maybe doc knows more.


Yes, see doc/arch/sandbox.rst

test/dm/Makefile shows that only one test file is enabled for SPL, but
you can add more. Let me know if you need pointers.

These aliases might help, if you build into /tmp/b/ :

# Run a pytest on sandbox
# $1: Name of test to run (optional, else run all)

function pyt {
test/py/test.py -B sandbox --build-dir /tmp/b/sandbox ${1:+"-k $1"}
}

# Run a pytest on sandbox_spl
# $1: Name of test to run  (optional, else run all SPL tests)
function pytspl {
local run=$1

[[ -z "$run" ]] && run=spl
test/py/test.py -B sandbox_spl --build-dir /tmp/b/sandbox_spl -k $run
}


You're thinking way ahead of where I am. I know how to build a board, 
but I've never used the test infrastructure. After some fumbling, I 
figured I'd try sandbox_spl:


$ test/py/test.py -B sandbox_spl --bd sandbox_spl --build

As you can imagine, it kept complaining about SDL. I've never used 
environment variables with Kbuild, so using NO_SPL=1 seems unnatural. 
But then why would we need SDL for testing an SPL build anyway? 'swig' 
was missing too, but that was an easy fix.


Second try:

$ NO_SDL=1 test/py/test.py -B sandbox_spl --bd sandbox_spl \
--build

Went a bit better, but " 29 failed, 502 passed, 212 skipped". Is this 
normal?


What I seem to be missing is how to connect this python to calling 
spl_load_simple_fit(). In the real world, I'd build u-boot and feed it a 
FIT image -- boots, okay.


Alex


Regards,
Simon



Alex



diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 1b4a7f6b15..a6f85b6f9d 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -26,6 +26,12 @@ DECLARE_GLOBAL_DATA_PTR;
   #define CONFIG_SYS_BOOTM_LEN   (64 << 20)
   #endif

+struct spl_fit_info {
+   const void *fit;
+   size_t ext_data_offset;
+   int images_node;
+};


struct comments



Regards,
Simon



Re: [PATCH] imx8mp_evk: Increase CONFIG_SYS_MALLOC_F_LEN

2020-12-21 Thread Fabio Estevam
Hi Andrey,

On Mon, Dec 21, 2020 at 7:04 PM ZHIZHIKIN Andrey
 wrote:

> It would be really great to get a review from Peng here, as his commit 
> 28fff3fa1c
> ("imx: imx8mp_evk: fix boot issue") changed exactly this option from 0x1 
> to 0x8000.

Yes, agreed.

Peng,

Please let us know if you are happy with this change.

> I've tested my local build with your patch and it boots OK, hence I cannot 
> seem to find a
> reasoning why the early malloc area size has been halved with above commit.

> Tested-by: Andrey Zhizhikin 

Thanks for reporting and testing it.


Re: [PATCH] doc: board: freescale: advise to use newer atf and firmware

2020-12-21 Thread Fabio Estevam
Hi Tom,

On Mon, Dec 21, 2020 at 6:40 PM Tom Rini  wrote:

> Is this something that should get pulled in for v2021.01?  It kinda
> sounds like yes.  Should I take this directly if so?

Yes, it would be nice to have this pulled in for v2021.01.

Thanks


RE: [PATCH] imx8mp_evk: Increase CONFIG_SYS_MALLOC_F_LEN

2020-12-21 Thread ZHIZHIKIN Andrey
Hello Fabio,

> -Original Message-
> From: Fabio Estevam 
> Sent: Monday, December 21, 2020 7:41 PM
> To: sba...@denx.de
> Cc: peng@nxp.com; u-boot@lists.denx.de; ZHIZHIKIN Andrey
> ; uboot-...@nxp.com; Fabio Estevam
> 
> Subject: [PATCH] imx8mp_evk: Increase CONFIG_SYS_MALLOC_F_LEN
> 
> 
> When booting imx8mp-evk the following allocation error message is seen:
> 
> U-Boot 2021.01-rc3-00200-ge668bec96a5f (Dec 21 2020 - 14:36:42 -0300)
> 
> alloc space exhausted
> 
> Fix it by increasing CONFIG_SYS_MALLOC_F_LEN to 0x1 like it is done on
> other i.MX8MM/8MN boards.

It would be really great to get a review from Peng here, as his commit 
28fff3fa1c
("imx: imx8mp_evk: fix boot issue") changed exactly this option from 0x1 to 
0x8000.

I've tested my local build with your patch and it boots OK, hence I cannot seem 
to find a
reasoning why the early malloc area size has been halved with above commit.

> 
> Reported-by: Andrey Zhizhikin 
> Signed-off-by: Fabio Estevam 
> ---
>  configs/imx8mp_evk_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig
> index cd5724e811ab..c34a10c2d906 100644
> --- a/configs/imx8mp_evk_defconfig
> +++ b/configs/imx8mp_evk_defconfig
> @@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x4020
> CONFIG_SPL_GPIO_SUPPORT=y  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> CONFIG_SPL_LIBGENERIC_SUPPORT=y
> -CONFIG_SYS_MALLOC_F_LEN=0x8000
> +CONFIG_SYS_MALLOC_F_LEN=0x1
>  CONFIG_ENV_SIZE=0x1000
>  CONFIG_ENV_OFFSET=0x40
>  CONFIG_SYS_I2C_MXC_I2C1=y
> --
> 2.17.1

Tested-by: Andrey Zhizhikin 



RE: [PATCH] doc: board: freescale: advise to use newer atf and firmware

2020-12-21 Thread ZHIZHIKIN Andrey
Hello Tom,

> -Original Message-
> From: Tom Rini 
> Sent: Monday, December 21, 2020 10:41 PM
> To: Fabio Estevam ; Stefano Babic 
> Cc: ZHIZHIKIN Andrey ; U-Boot-Denx
> ; Peng Fan 
> Subject: Re: [PATCH] doc: board: freescale: advise to use newer atf and 
> firmware
> 
> On Mon, Dec 21, 2020 at 06:31:08PM -0300, Fabio Estevam wrote:
> > Hi Andrey,
> >
> > On Sun, Dec 13, 2020 at 5:36 PM Andrey Zhizhikin
> >  wrote:
> > >
> > > Update branch and version information of ATF and DDR firmware files
> > > to point to latest releases provided by NXP.
> > >
> > > This is especially critical for imx8mp evk, as the ATF support for
> > > that SoC is only available in latest releases.
> > >
> > > Align all SoCs from imx8m family to use identical revisions of ATF
> > > and DDR firmware.
> > >
> > > Signed-off-by: Andrey Zhizhikin
> > > 
> >
> > Reviewed-by: Fabio Estevam 
> 
> Is this something that should get pulled in for v2021.01?  It kinda sounds 
> like yes.
> Should I take this directly if so?

I'd suggest this docs update to be taken, as the combination of ATF and DDR 
firmware
recorded there is known to be working for those i.MX8M derivatives.

I've also realized that there is a newer version of ATF available from NXP on 
codeaurora,
but according to the last mail from Fabio - it is not bootable, and I haven't 
tried it
myself yet.

I guess for the upcoming 2021.01 this documentation update would be quite 
helpful,
as there has been few reports on the list that people tried to use outdated 
instructions
and were not able to produce a boot container for i.MX8M Nano and Plus SOCs due 
to
a newer version of ATF was required.

> 
> --
> Tom

-- andrey


Re: [PATCH] doc: board: freescale: advise to use newer atf and firmware

2020-12-21 Thread Tom Rini
On Mon, Dec 21, 2020 at 06:31:08PM -0300, Fabio Estevam wrote:
> Hi Andrey,
> 
> On Sun, Dec 13, 2020 at 5:36 PM Andrey Zhizhikin
>  wrote:
> >
> > Update branch and version information of ATF and DDR firmware files to
> > point to latest releases provided by NXP.
> >
> > This is especially critical for imx8mp evk, as the ATF support for that
> > SoC is only available in latest releases.
> >
> > Align all SoCs from imx8m family to use identical revisions of ATF and
> > DDR firmware.
> >
> > Signed-off-by: Andrey Zhizhikin 
> 
> Reviewed-by: Fabio Estevam 

Is this something that should get pulled in for v2021.01?  It kinda
sounds like yes.  Should I take this directly if so?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 0/6] video: remove VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME

2020-12-21 Thread Tom Rini
On Sun, Dec 20, 2020 at 10:14:06PM +0100, Anatolij Gustschin wrote:
> On Tue, 8 Dec 2020 11:16:30 -0500
> Tom Rini tr...@konsulko.com wrote:
> ...   
> > > => open point: which acceptable target to remove this feature ? v2022.01 
> > > ?  
> > 
> > This sounds like a good plan and reasonable date to me.  Anatolij?
> 
> I have no objection, this target date is okay for me.

Can you please make up the patch for noting this, etc?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] doc: board: freescale: advise to use newer atf and firmware

2020-12-21 Thread Fabio Estevam
Hi Andrey,

On Sun, Dec 13, 2020 at 5:36 PM Andrey Zhizhikin
 wrote:
>
> Update branch and version information of ATF and DDR firmware files to
> point to latest releases provided by NXP.
>
> This is especially critical for imx8mp evk, as the ATF support for that
> SoC is only available in latest releases.
>
> Align all SoCs from imx8m family to use identical revisions of ATF and
> DDR firmware.
>
> Signed-off-by: Andrey Zhizhikin 

Reviewed-by: Fabio Estevam 


Re: [PATCH 2/8] spl: fit: Factor out FIT parsing and use a context struct

2020-12-21 Thread Simon Glass
Hi Alex,

On Mon, 21 Dec 2020 at 12:28, Alex G.  wrote:
>
> On 12/18/20 8:28 PM, Simon Glass wrote:
> > Hi Alexandru,
> >
> > On Tue, 15 Dec 2020 at 17:09, Alexandru Gagniuc  
> > wrote:
> >>
> >> The logical steps in spl_load_simple_fit() are difficult to follow.
> >> I think the long comments, ifdefs, and ungodly number of variables
> >> seriously affect the readability. In particular, it violates section 6
> >> of the coding style, paragraphs (3), and (4).
> >>
> >> The purpose of this patch is to improve the situation by
> >>- Factoring out initialization and parsing to separate functions
> >>- Reduce the number of variables by using a context structure
> >> This change introduces no functional changes.
> >>
> >> Signed-off-by: Alexandru Gagniuc 
> >> ---
> >>   common/spl/spl_fit.c | 87 ++--
> >>   1 file changed, 60 insertions(+), 27 deletions(-)
> >
> > This certainly looks a lot better although your email address does not
> > inspire confidence...
>
> Don't worry. It doesn't bite.
>
> > Do you think you could look at creating a sandbox SPL test for this?
> > It should be possible to write it in C, set up a bit of data, call
> > your function and check the results.
>
> I can look at it. I can't promise anything though, since this is the
> first time I heard of the sandbox. Maybe doc knows more.

Yes, see doc/arch/sandbox.rst

test/dm/Makefile shows that only one test file is enabled for SPL, but
you can add more. Let me know if you need pointers.

These aliases might help, if you build into /tmp/b/ :

# Run a pytest on sandbox
# $1: Name of test to run (optional, else run all)

function pyt {
test/py/test.py -B sandbox --build-dir /tmp/b/sandbox ${1:+"-k $1"}
}

# Run a pytest on sandbox_spl
# $1: Name of test to run  (optional, else run all SPL tests)
function pytspl {
local run=$1

[[ -z "$run" ]] && run=spl
test/py/test.py -B sandbox_spl --build-dir /tmp/b/sandbox_spl -k $run
}

Regards,
Simon

>
> Alex
>
> >>
> >> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> >> index 1b4a7f6b15..a6f85b6f9d 100644
> >> --- a/common/spl/spl_fit.c
> >> +++ b/common/spl/spl_fit.c
> >> @@ -26,6 +26,12 @@ DECLARE_GLOBAL_DATA_PTR;
> >>   #define CONFIG_SYS_BOOTM_LEN   (64 << 20)
> >>   #endif
> >>
> >> +struct spl_fit_info {
> >> +   const void *fit;
> >> +   size_t ext_data_offset;
> >> +   int images_node;
> >> +};
> >
> > struct comments
> >

Regards,
Simon


Re: [PATCH v3 11/12] mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys()

2020-12-21 Thread Simon Glass
Hi Nicolas,

On Mon, 21 Dec 2020 at 12:52, Nicolas Saenz Julienne
 wrote:
>
> On Mon, 2020-12-21 at 09:47 -0700, Simon Glass wrote:
> > Hi Nicolas,
> >
> > On Mon, 21 Dec 2020 at 07:23, Nicolas Saenz Julienne
> >  wrote:
> > >
> > > On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> > > > On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
> > > >  wrote:
> > > > >
> > > > > This will allow us to use DM variants of phys_to_bus()/bus_to_phys()
> > > > > when relevant.
> > > > >
> > > > > Signed-off-by: Nicolas Saenz Julienne 
> > > > > ---
> > > > >  drivers/mmc/sdhci.c |  7 ---
> > > > >  include/mmc.h   | 10 ++
> > > > >  2 files changed, 14 insertions(+), 3 deletions(-)
> > > >
> > > > Reviewed-by: Simon Glass 
> > > >
> > > >
> > > > >
> > > > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > > > > index 0628934312..2086d7cdb1 100644
> > > > > --- a/drivers/mmc/sdhci.c
> > > > > +++ b/drivers/mmc/sdhci.c
> > > > > @@ -19,7 +19,6 @@
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > -#include 
> > > > >
> > > > >  static void sdhci_reset(struct sdhci_host *host, u8 mask)
> > > > >  {
> > > > > @@ -103,7 +102,8 @@ static void sdhci_prepare_dma(struct sdhci_host 
> > > > > *host, struct mmc_data *data,
> > > > >   mmc_get_dma_dir(data));
> > > > >
> > > > > if (host->flags & USE_SDMA) {
> > > > > -   sdhci_writel(host, 
> > > > > phys_to_bus((ulong)host->start_addr),
> > > > > +   sdhci_writel(host,
> > > > > +mmc_phys_to_bus(host->mmc, 
> > > > > (ulong)host->start_addr),
> > > > > SDHCI_DMA_ADDRESS);
> > > > > }
> > > > >  #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
> > > > > @@ -162,7 +162,8 @@ static int sdhci_transfer_data(struct sdhci_host 
> > > > > *host, struct mmc_data *data)
> > > > > start_addr &=
> > > > > ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
> > > > > start_addr += 
> > > > > SDHCI_DEFAULT_BOUNDARY_SIZE;
> > > > > -   sdhci_writel(host, 
> > > > > phys_to_bus((ulong)start_addr),
> > > > > +   sdhci_writel(host,
> > > > > +
> > > > > mmc_phys_to_bus(host->mmc, (ulong)start_addr),
> > > > >  SDHCI_DMA_ADDRESS);
> > > > > }
> > > > > }
> > > > > diff --git a/include/mmc.h b/include/mmc.h
> > > > > index 1d377e0281..5fe1ef1dfc 100644
> > > > > --- a/include/mmc.h
> > > > > +++ b/include/mmc.h
> > > > > @@ -15,6 +15,7 @@
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > +#include 
> > > > >
> > > > >  struct bd_info;
> > > > >
> > > > > @@ -977,4 +978,13 @@ static inline enum dma_data_direction 
> > > > > mmc_get_dma_dir(struct mmc_data *data)
> > > > > return data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : 
> > > > > DMA_FROM_DEVICE;
> > > > >  }
> > > > >
> > > > > +static inline dma_addr_t mmc_phys_to_bus(struct mmc *mmc, 
> > > > > phys_addr_t addr)
> > > > > +{
> > > > > +#if CONFIG_IS_ENABLED(DM_DMA)
> > > >
> > > > if() ?
> > >
> > > Noted.
> > >
> > > > Also makes me wonder if dev_phys_to_bus() should call phys_to_bus() if
> > > > DM_DMA is not enabled?
> > >
> > > I'd still need some sort per-subsystem macro to cater for !DM 
> > > configurations
> > > where the device pointer isn't defined in the controller struct. Which IMO
> > > isn't much of an enhancement to this approach.
> >
> > We don't need to worry about non-DM for new features. In fact we don't
> > generally accept code that adds new features to non-DM code. It is
> > deprecated and slated for removal, so it just prolongs the migration.
>
> Understood, so let's not call the plain phys_to_bus() and assume a 1:1 address
> translation on non DM_DMA users (for both mmc and xhci). I'd say it's pretty
> safe to do anyway, as it seems phys2bus.h was introduced specially for the RPi
> family.

That sounds right to me.

>
> There still are some rogue users of the non dev dependent phys_to_bus() API in
> RPi platform code. I'll try to clean that up in a subsequent series.

OK ta.

Regards,
Simon


Re: [PATCH 7/8] spl: fit: Replace #ifdef blocks with more readable constructs

2020-12-21 Thread Simon Glass
Hi Alex,

On Mon, 21 Dec 2020 at 10:43, Alex G.  wrote:
>
>
>
> On 12/18/20 8:29 PM, Simon Glass wrote:
> > On Tue, 15 Dec 2020 at 17:10, Alexandru Gagniuc  
> > wrote:
> >>
> >> Use the IS_ENABLED() macro to control code flow, instead of the
> >> caveman approach of sprinkling #ifdefs. Code size is not affected, as
> >> the linker garbage-collects unused functions. However, readability is
> >> improved significantly.
> >>
> >> Signed-off-by: Alexandru Gagniuc 
> >> ---
> >>   common/spl/spl_fit.c | 53 
> >>   1 file changed, 24 insertions(+), 29 deletions(-)
> >
> > I am trying to imagine stick drawings with #ifdefs
> >
> #ifdef
>   #if #if
> #if #if
> #if #if
>
>   #if #if
> #endif
>#if#if#if
>  #if  #if  #if
>#if#if#if
>  #if  #if  #if
> #ifdef
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #endif
> #ifdef
>  #if   #if
>#if   #if
>  #if   #if
>#if   #if
>   #endif  #endif
>

So you are an artist and an engineer.

Regards,
Simon


[ANN] U-Boot v2021.01-rc4 released

2020-12-21 Thread Tom Rini
Hey all,

Alright, I've gotten well off schedule.  I think the take away for me
really is that it's better to mid-week and get back on schedule than try
and change the Mondays I release on.  So here's -rc4, and I hope this is
very close to what the final release will be, oon January 11th.  I will
do another, final, -rc on January 4th.

The only big change here is that I have dropped Travis-CI support as
they are reducing the amount of monthly build time FOSS projects get,
and that's just not going to work for U-Boot.  I do appreciate all of
the cycles we've gotten over the years.

In terms of a changelog, 
git log --merges v2021.01-rc3..v2021.01-rc4
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

Thanks all!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] i2c: mxc_i2c: improve error message readability

2020-12-21 Thread Fabio Estevam
On Mon, Dec 21, 2020 at 5:19 PM  wrote:
>
> From: Marc Ferland 
>
> Use 0x%2lx to print the i2c bus base address in hexadecimal format
> instead of printing as an integer.
>
> Signed-off-by: Marc Ferland 
> ---
> Changes for v2:
>- Add commit message

Reviewed-by: Fabio Estevam 


u-boot support Android header v3 schedule

2020-12-21 Thread 楊邵軒
Hi Master
 Could you share the release schedule which support Android header v3
in u-boot GPL code?
Thanks.

Regards
Hank Yang


不含病毒。www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


[PATCH v2] i2c: mxc_i2c: improve error message readability

2020-12-21 Thread ferlandm
From: Marc Ferland 

Use 0x%2lx to print the i2c bus base address in hexadecimal format
instead of printing as an integer.

Signed-off-by: Marc Ferland 
---
Changes for v2:
   - Add commit message

 drivers/i2c/mxc_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 7609594bd0..d486dab043 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -954,7 +954,7 @@ static int mxc_i2c_probe(struct udevice *bus)
!dm_gpio_is_valid(_bus->scl_gpio) ||
ret || ret2) {
dev_err(bus,
-   "i2c bus %d at %lu, fail to request scl/sda 
gpio\n",
+   "i2c bus %d at 0x%2lx, fail to request scl/sda 
gpio\n",
bus->seq, i2c_bus->base);
return -EINVAL;
}
-- 
2.25.1



[PATCH] net: fix ping in netconsole

2020-12-21 Thread Yang Liu
Should not init eth device when doing ping in netconsole.

Signed-off-by: Yang Liu 
Cc: Joe Hershberger 
---
 net/net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/net.c b/net/net.c
index ad7e3b3cf8..b58f3062b2 100644
--- a/net/net.c
+++ b/net/net.c
@@ -412,7 +412,7 @@ int net_loop(enum proto_t protocol)
 
bootstage_mark_name(BOOTSTAGE_ID_ETH_START, "eth_start");
net_init();
-   if (eth_is_on_demand_init() || protocol != NETCONS) {
+   if (eth_is_on_demand_init()) {
eth_halt();
eth_set_current();
ret = eth_init();
-- 
2.25.4



Re: [PATCH v3 11/12] mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys()

2020-12-21 Thread Nicolas Saenz Julienne
On Mon, 2020-12-21 at 09:47 -0700, Simon Glass wrote:
> Hi Nicolas,
> 
> On Mon, 21 Dec 2020 at 07:23, Nicolas Saenz Julienne
>  wrote:
> > 
> > On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> > > On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
> > >  wrote:
> > > > 
> > > > This will allow us to use DM variants of phys_to_bus()/bus_to_phys()
> > > > when relevant.
> > > > 
> > > > Signed-off-by: Nicolas Saenz Julienne 
> > > > ---
> > > >  drivers/mmc/sdhci.c |  7 ---
> > > >  include/mmc.h   | 10 ++
> > > >  2 files changed, 14 insertions(+), 3 deletions(-)
> > > 
> > > Reviewed-by: Simon Glass 
> > > 
> > > 
> > > > 
> > > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > > > index 0628934312..2086d7cdb1 100644
> > > > --- a/drivers/mmc/sdhci.c
> > > > +++ b/drivers/mmc/sdhci.c
> > > > @@ -19,7 +19,6 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > -#include 
> > > > 
> > > >  static void sdhci_reset(struct sdhci_host *host, u8 mask)
> > > >  {
> > > > @@ -103,7 +102,8 @@ static void sdhci_prepare_dma(struct sdhci_host 
> > > > *host, struct mmc_data *data,
> > > >   mmc_get_dma_dir(data));
> > > > 
> > > > if (host->flags & USE_SDMA) {
> > > > -   sdhci_writel(host, phys_to_bus((ulong)host->start_addr),
> > > > +   sdhci_writel(host,
> > > > +mmc_phys_to_bus(host->mmc, 
> > > > (ulong)host->start_addr),
> > > > SDHCI_DMA_ADDRESS);
> > > > }
> > > >  #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
> > > > @@ -162,7 +162,8 @@ static int sdhci_transfer_data(struct sdhci_host 
> > > > *host, struct mmc_data *data)
> > > > start_addr &=
> > > > ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
> > > > start_addr += 
> > > > SDHCI_DEFAULT_BOUNDARY_SIZE;
> > > > -   sdhci_writel(host, 
> > > > phys_to_bus((ulong)start_addr),
> > > > +   sdhci_writel(host,
> > > > +mmc_phys_to_bus(host->mmc, 
> > > > (ulong)start_addr),
> > > >  SDHCI_DMA_ADDRESS);
> > > > }
> > > > }
> > > > diff --git a/include/mmc.h b/include/mmc.h
> > > > index 1d377e0281..5fe1ef1dfc 100644
> > > > --- a/include/mmc.h
> > > > +++ b/include/mmc.h
> > > > @@ -15,6 +15,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > 
> > > >  struct bd_info;
> > > > 
> > > > @@ -977,4 +978,13 @@ static inline enum dma_data_direction 
> > > > mmc_get_dma_dir(struct mmc_data *data)
> > > > return data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : 
> > > > DMA_FROM_DEVICE;
> > > >  }
> > > > 
> > > > +static inline dma_addr_t mmc_phys_to_bus(struct mmc *mmc, phys_addr_t 
> > > > addr)
> > > > +{
> > > > +#if CONFIG_IS_ENABLED(DM_DMA)
> > > 
> > > if() ?
> > 
> > Noted.
> > 
> > > Also makes me wonder if dev_phys_to_bus() should call phys_to_bus() if
> > > DM_DMA is not enabled?
> > 
> > I'd still need some sort per-subsystem macro to cater for !DM configurations
> > where the device pointer isn't defined in the controller struct. Which IMO
> > isn't much of an enhancement to this approach.
> 
> We don't need to worry about non-DM for new features. In fact we don't
> generally accept code that adds new features to non-DM code. It is
> deprecated and slated for removal, so it just prolongs the migration.

Understood, so let's not call the plain phys_to_bus() and assume a 1:1 address
translation on non DM_DMA users (for both mmc and xhci). I'd say it's pretty
safe to do anyway, as it seems phys2bus.h was introduced specially for the RPi
family.

There still are some rogue users of the non dev dependent phys_to_bus() API in
RPi platform code. I'll try to clean that up in a subsequent series.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part


Re: [PATCH 2/8] spl: fit: Factor out FIT parsing and use a context struct

2020-12-21 Thread Alex G.

On 12/18/20 8:28 PM, Simon Glass wrote:

Hi Alexandru,

On Tue, 15 Dec 2020 at 17:09, Alexandru Gagniuc  wrote:


The logical steps in spl_load_simple_fit() are difficult to follow.
I think the long comments, ifdefs, and ungodly number of variables
seriously affect the readability. In particular, it violates section 6
of the coding style, paragraphs (3), and (4).

The purpose of this patch is to improve the situation by
   - Factoring out initialization and parsing to separate functions
   - Reduce the number of variables by using a context structure
This change introduces no functional changes.

Signed-off-by: Alexandru Gagniuc 
---
  common/spl/spl_fit.c | 87 ++--
  1 file changed, 60 insertions(+), 27 deletions(-)


This certainly looks a lot better although your email address does not
inspire confidence...


Don't worry. It doesn't bite.


Do you think you could look at creating a sandbox SPL test for this?
It should be possible to write it in C, set up a bit of data, call
your function and check the results.


I can look at it. I can't promise anything though, since this is the 
first time I heard of the sandbox. Maybe doc knows more.


Alex



diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 1b4a7f6b15..a6f85b6f9d 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -26,6 +26,12 @@ DECLARE_GLOBAL_DATA_PTR;
  #define CONFIG_SYS_BOOTM_LEN   (64 << 20)
  #endif

+struct spl_fit_info {
+   const void *fit;
+   size_t ext_data_offset;
+   int images_node;
+};


struct comments



[PATCH] imx8mp_evk: Increase CONFIG_SYS_MALLOC_F_LEN

2020-12-21 Thread Fabio Estevam
When booting imx8mp-evk the following allocation error
message is seen:

U-Boot 2021.01-rc3-00200-ge668bec96a5f (Dec 21 2020 - 14:36:42 -0300)

alloc space exhausted

Fix it by increasing CONFIG_SYS_MALLOC_F_LEN to 0x1 like it
is done on other i.MX8MM/8MN boards.

Reported-by: Andrey Zhizhikin 
Signed-off-by: Fabio Estevam 
---
 configs/imx8mp_evk_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig
index cd5724e811ab..c34a10c2d906 100644
--- a/configs/imx8mp_evk_defconfig
+++ b/configs/imx8mp_evk_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x4020
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SYS_MALLOC_F_LEN=0x1
 CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0x40
 CONFIG_SYS_I2C_MXC_I2C1=y
-- 
2.17.1



Re: imx8mp_evk: boot error "alloc space exhausted"

2020-12-21 Thread Fabio Estevam
On Mon, Dec 21, 2020 at 11:19 AM Fabio Estevam  wrote:

> I have also tried using the ATF version imx_5.4.70_2.3.0 and the DDR
> firmware from the firmware-5.10 package, but still does not boot for
> me:
>
> U-Boot SPL 2021.01-rc3-00200-ge668bec96a5f-dirty (Dec 21 2020 - 11:13:56 
> -0300)
> Normal Boot
> WDT:   Started with servicing (60s timeout)
> Trying to boot from BOOTROM
> image offset 0x8000, pagesize 0x200, ivt offset 0x0
>
> It would be great to have this fixed for the upcoming 2021.01 release.

Ok, I re-built U-Boot using the instructions from
doc/board/freescale/imx8mp_evk.rst and now it boots fine.

I will submit a patch increasing CONFIG_SYS_MALLOC_F_LEN as reported by Andrey.

Thanks


[PATCH] drivers: tee: i2c trampoline driver

2020-12-21 Thread Jorge Ramirez-Ortiz
This commit gives the secure world access to the I2C bus so it can
communicate with I2C slaves (tipically those would be secure elements
like the NXP SE050).

Tested on imx8mmevk.

Signed-off-by: Jorge Ramirez-Ortiz 
---
 drivers/tee/optee/Makefile   |  1 +
 drivers/tee/optee/i2c.c  | 88 
 drivers/tee/optee/optee_msg.h| 22 ++
 drivers/tee/optee/optee_msg_supplicant.h |  5 ++
 drivers/tee/optee/optee_private.h| 12 
 drivers/tee/optee/supplicant.c   |  3 +
 6 files changed, 131 insertions(+)
 create mode 100644 drivers/tee/optee/i2c.c

diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
index 928d3f8002..068c6e7aa1 100644
--- a/drivers/tee/optee/Makefile
+++ b/drivers/tee/optee/Makefile
@@ -2,4 +2,5 @@
 
 obj-y += core.o
 obj-y += supplicant.o
+obj-$(CONFIG_DM_I2C) += i2c.o
 obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c
new file mode 100644
index 00..2ebbf1ff7c
--- /dev/null
+++ b/drivers/tee/optee/i2c.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: BSD-2-Clause
+/*
+ * Copyright (c) 2020 Foundries.io Ltd
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "optee_msg.h"
+#include "optee_private.h"
+
+static struct {
+   struct udevice *dev;
+   int chip;
+   int bus;
+} xfer;
+
+void optee_suppl_cmd_i2c_transfer(struct udevice *dev,
+ struct optee_msg_arg *arg)
+{
+   const uint64_t attr[] = {
+   OPTEE_MSG_ATTR_TYPE_VALUE_INPUT,
+   OPTEE_MSG_ATTR_TYPE_VALUE_INPUT,
+   OPTEE_MSG_ATTR_TYPE_RMEM_INOUT,
+   OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT,
+   };
+   struct udevice *chip_dev = NULL;
+   struct tee_shm *shm = NULL;
+   uint8_t *buf = NULL;
+   size_t len = 0;
+   int chip = -1;
+   int bus = -1;
+   int ret = -1;
+
+   if (arg->num_params != ARRAY_SIZE(attr) ||
+   arg->params[0].attr != attr[0] ||
+   arg->params[1].attr != attr[1] ||
+   arg->params[2].attr != attr[2] ||
+   arg->params[3].attr != attr[3]) {
+   arg->ret = TEE_ERROR_BAD_PARAMETERS;
+   return;
+   }
+
+   len = arg->params[2].u.tmem.size;
+   shm = (struct tee_shm *)(unsigned long)arg->params[2].u.tmem.shm_ref;
+   buf = shm->addr;
+   if (!buf || !len)
+   goto bad;
+
+   bus = (int)arg->params[0].u.value.b;
+   chip = (int)arg->params[0].u.value.c;
+
+   if (!xfer.dev || xfer.chip != chip || xfer.bus != bus) {
+   if (i2c_get_chip_for_busnum(bus, chip, 0, _dev))
+   goto bad;
+
+   xfer.dev = chip_dev;
+   xfer.chip = chip;
+   xfer.bus = bus;
+   }
+
+   if (arg->params[1].u.value.a & OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT)
+   if (i2c_set_chip_flags(xfer.dev, DM_I2C_CHIP_10BIT))
+   goto bad;
+
+   switch (arg->params[0].u.value.a) {
+   case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
+   ret = dm_i2c_read(xfer.dev, 0, buf, len);
+   break;
+   case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
+   ret = dm_i2c_write(xfer.dev, 0, buf, len);
+   break;
+   default:
+   goto bad;
+   }
+
+   if (ret) {
+   arg->ret = TEE_ERROR_COMMUNICATION;
+   } else {
+   arg->params[3].u.value.a = len;
+   arg->ret = TEE_SUCCESS;
+   }
+
+   return;
+bad:
+   arg->ret = TEE_ERROR_BAD_PARAMETERS;
+}
diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
index 24c60960fc..7cedb59a82 100644
--- a/drivers/tee/optee/optee_msg.h
+++ b/drivers/tee/optee/optee_msg.h
@@ -422,4 +422,26 @@ struct optee_msg_arg {
  */
 #define OPTEE_MSG_RPC_CMD_SHM_FREE 7
 
+/*
+ * Access a device on an i2c bus
+ *
+ * [in]  param[0].u.value.amode: RD(0), WR(1)
+ * [in]  param[0].u.value.bi2c adapter
+ * [in]  param[0].u.value.ci2c chip
+ *
+ * [in]  param[1].u.value.ai2c control flags
+ * [in]  param[1].u.value.bi2c retry (optional)
+ *
+ * [in/out] memref[2]  buffer to exchange the transfer data
+ * with the secure world
+ *
+ * [out]  param[3].u.value.a   bytes transferred by the driver
+ */
+#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER 21
+/* I2C master transfer modes */
+#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD 0
+#define OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR 1
+/* I2C master control flags */
+#define OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT  BIT(0)
+
 #endif /* _OPTEE_MSG_H */
diff --git a/drivers/tee/optee/optee_msg_supplicant.h 
b/drivers/tee/optee/optee_msg_supplicant.h
index a0fb8063c8..963cfd4782 100644
--- a/drivers/tee/optee/optee_msg_supplicant.h
+++ b/drivers/tee/optee/optee_msg_supplicant.h
@@ -147,6 +147,11 @@
 

Re: [PATCH v2 14/14] qemu: arm64: Add documentation for capsule update

2020-12-21 Thread Heinrich Schuchardt

On 12/21/20 6:12 PM, Sughosh Ganu wrote:

On Mon, 21 Dec 2020 at 18:28, Heinrich Schuchardt 
wrote:


On 12/21/20 12:43 PM, Sughosh Ganu wrote:

Add documentation highlighting the steps for using the uefi capsule
update feature for updating the u-boot firmware image.

Signed-off-by: Sughosh Ganu 
---

Changes since V1:
* Change the documentation to reflect the usage of overlays for
embedding the public key certs at runtime
* Fix the build for 'make htmldocs'

   doc/board/emulation/qemu-arm.rst | 188 +++


Why do you put the information into doc/board/emulation/qemu-arm.rst?

Isn't the same applicable to RISC-V QEMU?



Where do you want me to put it. Currently, I do not see any common document
for qemu which can be shared between qemu-arm and qemu risc-v. Or do you
think a new document should be created under doc/board/emulation/
directory. Moreover, my series is adding support for capsule update feature
on the qemu arm64 platform, and i have only tested this feature on the qemu
arm64 platform. If someone wants to extend this on the qemu
risc-v platform, that work i think needs to be done separately, with
whatever changes that may be needed to get capsule updates working on qemu
risc-v. If you so prefer, I can move the changes made for mtdparts and
dfu(patches 4/14 and 5/14) under a common directory under board/emulation.



I have started putting the documentation for shell commands into
doc/usage. This is where a description of efidebug could be placed.

Equally I think we should put the documentation of tools like
mkeficapsule under doc/usage.

The description on the usage of the UEFI firmware protocol would fit
into doc/uefi/uefi.rst.

When it comes to things that are really QEMU specific
doc/board/emulation/ is the right folder.

See more comments below.



-sughosh




Best regards

Heinrich


   1 file changed, 188 insertions(+)

diff --git a/doc/board/emulation/qemu-arm.rst

b/doc/board/emulation/qemu-arm.rst

index 8d7fda10f1..11d91811b3 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -90,3 +90,191 @@ The debug UART on the ARM virt board uses these

settings::

   CONFIG_DEBUG_UART_PL010=y
   CONFIG_DEBUG_UART_BASE=0x900
   CONFIG_DEBUG_UART_CLOCK=0
+
+Enabling Uefi Capsule Update feature
+
+
+Support has been added for the uefi capsule update feature which
+enables updating the u-boot image using the uefi firmware management


%s/uefi/UEFI/


+protocol (fmp). The capsules are not passed to the firmware through
+the UpdateCapsule runtime service. Instead, capsule-on-disk
+functionality is used for fetching the capsule from the EFI System
+Partition (ESP).


According to the UEFI spec the relevant directory is \EFI\UpdateCapsule.
I think you should mentions this path.


+
+Currently, support has been added for updating the u-boot binary as a


%s/u-boot/U-Boot/g


+raw image when the platform is booted in non-secure mode, i.e with


%s/i.e/i.e./


+CONFIG_TFABOOT disabled. For this configuration, the qemu platform


%s/qemu/QEMU/


+needs to be booted with 'secure=off'. The u-boot binary placed on the


U-Boot


+first bank of the Nor Flash at offset 0x0. The u-boot environment is


%s/Nor Flash/NOR flash/

U-Boot


+placed on the second Nor Flash bank at offset 0x400.


NOR flash


+
+The capsule update feature is enabled with the following configs::


%s/configs/configuration settings/


+
+CONFIG_MTD=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_DFU=y
+CONFIG_DFU_MTD=y
+CONFIG_PCI_INIT_R=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
+CONFIG_EFI_CAPSULE_FIRMWARE=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_EFI_CAPSULE_FMP_HEADER=y
+
+In addition, the following config needs to be disabled::
+
+CONFIG_TFABOOT
+
+The capsule file can be generated by using the GenerateCapsule.py
+script in edk2::


EDK II


+
+$ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \
+ --fw-version  --lsv  --guid \
+e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose --update-image-index

\

+ --verbose 
+
+As per the uefi specification, the capsule file needs to be placed on


UEFI


+the EFI System Partition, under the EFI/UpdateCapsule/ directory. The


\EFI\UpdateCapsule\ (see UEFI specification)


+EFI System Partition can be a virtio-blk-device.
+
+Before initiating the firmware update, the efi variables BootNext,


%s/efi/UEFI/


+Boot and OsIndications need to be set. The Boot variable needs
+to be pointing to the EFI System Partition which contains the capsule
+file. The BootNext, Boot and OsIndications variables can be set


Shouldn't OsIndications bit 2 be set by default when EFI capsule support
is enabled? How about bit 3 (EFI_OS_INDICATIONS_FMP_CAPSULE_SUPPORTED)?


+using the following commands::
+
+=> efidebug boot add 0 Boot virtio 0:1 
+=> 

Re: [PATCH 7/8] spl: fit: Replace #ifdef blocks with more readable constructs

2020-12-21 Thread Alex G.




On 12/18/20 8:29 PM, Simon Glass wrote:

On Tue, 15 Dec 2020 at 17:10, Alexandru Gagniuc  wrote:


Use the IS_ENABLED() macro to control code flow, instead of the
caveman approach of sprinkling #ifdefs. Code size is not affected, as
the linker garbage-collects unused functions. However, readability is
improved significantly.

Signed-off-by: Alexandru Gagniuc 
---
  common/spl/spl_fit.c | 53 
  1 file changed, 24 insertions(+), 29 deletions(-)


I am trying to imagine stick drawings with #ifdefs


   #ifdef
 #if #if
   #if #if
   #if #if 


 #if #if
   #endif
  #if#if#if
#if  #if  #if
  #if#if#if
#if  #if  #if
   #ifdef
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #endif
   #ifdef
#if   #if
  #if   #if
#if   #if
  #if   #if
 #endif  #endif



Reviewed-by: Simon Glass 



Re: [PATCH v2 4/7] IOMUX: Preserve console list if realloc() fails

2020-12-21 Thread Simon Glass
Hi Andy,

On Mon, 21 Dec 2020 at 10:16, Andy Shevchenko
 wrote:
>
> On Mon, Dec 21, 2020 at 09:47:03AM -0700, Simon Glass wrote:
> > On Mon, 21 Dec 2020 at 05:00, Andy Shevchenko
> >  wrote:
> > > On Fri, Dec 18, 2020 at 07:29:19PM -0700, Simon Glass wrote:
> > > > On Wed, 16 Dec 2020 at 16:16, Andy Shevchenko
> > > >  wrote:
> > > > >
> > > > > It's realloc() 101 to avoid `foo = realloc(foo, ...);` call
> > > > > due to getting a memory leak.
> > > >
> > > > Hmm I don't think I knew that...
> > >
> > > When you use the same variable for the source and destination in case of 
> > > NULL
> > > the source gone.
> > >
> > > It's okay to have
> > >
> > > foo = bar;
> > > bar = realloc(bar, ...);
> > > if (bar == NULL)
> > > ...do something with foo if needed...
> >
> > Here is man malloc on this point:
> >
> > If ptr is NULL, then  the  call  is  equivalent  to  mal‐
> >loc(size), for all values of size; if size is equal to zero, and ptr 
> > is
> >not NULL, then the call is equivalent  to  free(ptr).
>
> But it's about another case.
> I'm talking about realloc() to fail.
>
> foo = realloc(foo, ...);
>
> will effectively leak memory if foo is not saved previously somewhere.
> And this is the case here.
>
> For instance [1] is telling about the same:
>   "Of course if you will write
>
> p = realloc(p, 2 * sizeof(int));
>
>   ... if the function was unable to reallocate memory. In this case a memory
>   leak will occur provided that initial value of the pointer p was not equal
>   to NULL."
>
> Really, it's 101 of realloc() usage.

Oh I missed that it failed...OK

>
> [1]: 
> https://stackoverflow.com/questions/57498538/does-realloc-mutate-its-arguments

Regards,
Simon


[PATCH v2] imx: ahab: allow to bypass confirmation for ahab_close cmd

2020-12-21 Thread Clément Péron
Calling ahab_close cmd force the user to interact for confirmation.

This is not user-friendly when using this cmd during factory process.

Allow the user to pass '-y' option to bypass this confirmation.

Signed-off-by: Clément Péron 
---
v2:
  - Fix commit log

---
 arch/arm/mach-imx/imx8/ahab.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/imx8/ahab.c b/arch/arm/mach-imx/imx8/ahab.c
index cf3c7d762a74..b0865c2330a2 100644
--- a/arch/arm/mach-imx/imx8/ahab.c
+++ b/arch/arm/mach-imx/imx8/ahab.c
@@ -301,10 +301,11 @@ static int confirm_close(void)
 static int do_ahab_close(cmd_tbl_t *cmdtp, int flag, int argc,
 char * const argv[])
 {
+   int confirmed = argc >= 2 && !strcmp(argv[1], "-y");
int err;
u16 lc;
 
-   if (!confirm_close())
+   if (!confirmed && !confirm_close())
return -EACCES;
 
err = sc_seco_chip_info(-1, , NULL, NULL, NULL);
-- 
2.25.1



[PATCH] imx: ahab: allow to bypass confirmation for ahab_close cmd

2020-12-21 Thread Clément Péron
Calling ahab_close cmd for the user to interact for confirmation.

This is not friendly usable when using this cmd during factory process.

Allow the user to pass '-y' option to bypass this confirmation.

Signed-off-by: Clément Péron 
---
 arch/arm/mach-imx/imx8/ahab.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/imx8/ahab.c b/arch/arm/mach-imx/imx8/ahab.c
index cf3c7d762a74..b0865c2330a2 100644
--- a/arch/arm/mach-imx/imx8/ahab.c
+++ b/arch/arm/mach-imx/imx8/ahab.c
@@ -301,10 +301,11 @@ static int confirm_close(void)
 static int do_ahab_close(cmd_tbl_t *cmdtp, int flag, int argc,
 char * const argv[])
 {
+   int confirmed = argc >= 2 && !strcmp(argv[1], "-y");
int err;
u16 lc;
 
-   if (!confirm_close())
+   if (!confirmed && !confirm_close())
return -EACCES;
 
err = sc_seco_chip_info(-1, , NULL, NULL, NULL);
-- 
2.25.1



Re: [PATCH v2 02/14] qemu: arm: Initialise virtio in board_late_init

2020-12-21 Thread Sughosh Ganu
On Mon, 21 Dec 2020 at 18:21, Heinrich Schuchardt 
wrote:

> On 12/21/20 1:19 PM, Heinrich Schuchardt wrote:
> > On 12/21/20 12:43 PM, Sughosh Ganu wrote:
> >> On the qemu arm platform, the virtio devices are initialised in
> >> board_init, which gets called before the initr_pci. With this, the
> >> virtio block devices on the pci bus are not initialised. Move the
> >> initialisation of virtio devices to board_late_init which gets called
> >> after the call to initr_pci.
> >>
> >> Signed-off-by: Sughosh Ganu 
> >
> > With which commands can I see the difference before and after the patch?
>

Without this patch, i am required to run a 'virtio scan' on the command
line to access my efi system partition which is a block device on the pci
bus. Do you see any issue with moving the virtio_init in board_late_init?


>
> The 'rng' command now works without calling 'virtio scan' beforehand.


> >
> > Best regards
> >
> > Heinrich
> >
> >> ---
> >>
> >> Changes since V1:
> >> * The earlier patch was adding a call to pci_init in board_init. Moved
> >>the virtio_init call to board_late_init
> >>
> >>   board/emulation/qemu-arm/qemu-arm.c | 5 +
> >>   configs/qemu_arm64_defconfig| 1 +
> >>   2 files changed, 6 insertions(+)
> >>
> >> diff --git a/board/emulation/qemu-arm/qemu-arm.c
> >> b/board/emulation/qemu-arm/qemu-arm.c
> >> index f18f2ed7da..aa68bef469 100644
> >> --- a/board/emulation/qemu-arm/qemu-arm.c
> >> +++ b/board/emulation/qemu-arm/qemu-arm.c
> >> @@ -64,6 +64,11 @@ struct mm_region *mem_map = qemu_arm64_mem_map;
> >>   #endif
> >>
> >>   int board_init(void)
> >> +{
> >> +return 0;
> >> +}
> >> +
> >> +int board_late_init(void)
>
> Why don't you change board/emulation/qemu-riscv/qemu-riscv.c too? I can
> see no reason why you want to treat RISC-V differently.
>

Like I mentioned in my other mail, I am testing the capsule update feature
only on the qemu arm64 platform. I can make this change, but I think this
should be done by someone who is actually a user of the qemu risc-v
platform.


> What about x86 and MIPS? Why is virtio_init() not called on those
> architectures?
>

I have no idea about this :-)


> >>   {
> >>   /*
> >>* Make sure virtio bus is enumerated so that peripherals
> >> diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
> >> index f6e586627a..5c855fa08c 100644
> >> --- a/configs/qemu_arm64_defconfig
> >> +++ b/configs/qemu_arm64_defconfig
> >> @@ -14,6 +14,7 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
> >>   CONFIG_USE_PREBOOT=y
> >>   # CONFIG_DISPLAY_CPUINFO is not set
> >>   # CONFIG_DISPLAY_BOARDINFO is not set
> >> +CONFIG_BOARD_LATE_INIT=y
>
>
> The C code change concerns both arm64 and arm. So on all ARM QEMU boards
> except qemu_arm64_defconfig you don't call virtio_init() at all once
> this patch is applied. This cannot be correct!
>

You are right. I should be adding this in the qemu arm platform flavour as
well along with the arm64 variant. Will fix.


>
> Probably you want to change arch/Kconfig instead:
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index e8f9a9e1b7..1c66743ab6 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -24,6 +24,7 @@ config ARM
>  bool "ARM architecture"
>  select CREATE_ARCH_SYMLINK
>  select HAVE_PRIVATE_LIBGCC if !ARM64
> +   select BOARD_LATE_INIT
>  select SUPPORT_OF_CONTROL
>

Will check this out. Thanks.

-sughosh


Re: [PATCH v2 4/7] IOMUX: Preserve console list if realloc() fails

2020-12-21 Thread Andy Shevchenko
On Mon, Dec 21, 2020 at 09:47:03AM -0700, Simon Glass wrote:
> On Mon, 21 Dec 2020 at 05:00, Andy Shevchenko
>  wrote:
> > On Fri, Dec 18, 2020 at 07:29:19PM -0700, Simon Glass wrote:
> > > On Wed, 16 Dec 2020 at 16:16, Andy Shevchenko
> > >  wrote:
> > > >
> > > > It's realloc() 101 to avoid `foo = realloc(foo, ...);` call
> > > > due to getting a memory leak.
> > >
> > > Hmm I don't think I knew that...
> >
> > When you use the same variable for the source and destination in case of 
> > NULL
> > the source gone.
> >
> > It's okay to have
> >
> > foo = bar;
> > bar = realloc(bar, ...);
> > if (bar == NULL)
> > ...do something with foo if needed...
> 
> Here is man malloc on this point:
> 
> If ptr is NULL, then  the  call  is  equivalent  to  mal‐
>loc(size), for all values of size; if size is equal to zero, and ptr is
>not NULL, then the call is equivalent  to  free(ptr).

But it's about another case.
I'm talking about realloc() to fail.

foo = realloc(foo, ...);

will effectively leak memory if foo is not saved previously somewhere.
And this is the case here.

For instance [1] is telling about the same:
  "Of course if you will write

p = realloc(p, 2 * sizeof(int));

  ... if the function was unable to reallocate memory. In this case a memory
  leak will occur provided that initial value of the pointer p was not equal
  to NULL."

Really, it's 101 of realloc() usage.

[1]: 
https://stackoverflow.com/questions/57498538/does-realloc-mutate-its-arguments

-- 
With Best Regards,
Andy Shevchenko




Re: [PATCH v2 14/14] qemu: arm64: Add documentation for capsule update

2020-12-21 Thread Sughosh Ganu
On Mon, 21 Dec 2020 at 18:28, Heinrich Schuchardt 
wrote:

> On 12/21/20 12:43 PM, Sughosh Ganu wrote:
> > Add documentation highlighting the steps for using the uefi capsule
> > update feature for updating the u-boot firmware image.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> >
> > Changes since V1:
> > * Change the documentation to reflect the usage of overlays for
> >embedding the public key certs at runtime
> > * Fix the build for 'make htmldocs'
> >
> >   doc/board/emulation/qemu-arm.rst | 188 +++
>
> Why do you put the information into doc/board/emulation/qemu-arm.rst?
>
> Isn't the same applicable to RISC-V QEMU?
>

Where do you want me to put it. Currently, I do not see any common document
for qemu which can be shared between qemu-arm and qemu risc-v. Or do you
think a new document should be created under doc/board/emulation/
directory. Moreover, my series is adding support for capsule update feature
on the qemu arm64 platform, and i have only tested this feature on the qemu
arm64 platform. If someone wants to extend this on the qemu
risc-v platform, that work i think needs to be done separately, with
whatever changes that may be needed to get capsule updates working on qemu
risc-v. If you so prefer, I can move the changes made for mtdparts and
dfu(patches 4/14 and 5/14) under a common directory under board/emulation.

-sughosh


>
> Best regards
>
> Heinrich
>
> >   1 file changed, 188 insertions(+)
> >
> > diff --git a/doc/board/emulation/qemu-arm.rst
> b/doc/board/emulation/qemu-arm.rst
> > index 8d7fda10f1..11d91811b3 100644
> > --- a/doc/board/emulation/qemu-arm.rst
> > +++ b/doc/board/emulation/qemu-arm.rst
> > @@ -90,3 +90,191 @@ The debug UART on the ARM virt board uses these
> settings::
> >   CONFIG_DEBUG_UART_PL010=y
> >   CONFIG_DEBUG_UART_BASE=0x900
> >   CONFIG_DEBUG_UART_CLOCK=0
> > +
> > +Enabling Uefi Capsule Update feature
> > +
> > +
> > +Support has been added for the uefi capsule update feature which
> > +enables updating the u-boot image using the uefi firmware management
> > +protocol (fmp). The capsules are not passed to the firmware through
> > +the UpdateCapsule runtime service. Instead, capsule-on-disk
> > +functionality is used for fetching the capsule from the EFI System
> > +Partition (ESP).
> > +
> > +Currently, support has been added for updating the u-boot binary as a
> > +raw image when the platform is booted in non-secure mode, i.e with
> > +CONFIG_TFABOOT disabled. For this configuration, the qemu platform
> > +needs to be booted with 'secure=off'. The u-boot binary placed on the
> > +first bank of the Nor Flash at offset 0x0. The u-boot environment is
> > +placed on the second Nor Flash bank at offset 0x400.
> > +
> > +The capsule update feature is enabled with the following configs::
> > +
> > +CONFIG_MTD=y
> > +CONFIG_FLASH_CFI_MTD=y
> > +CONFIG_CMD_MTDPARTS=y
> > +CONFIG_CMD_DFU=y
> > +CONFIG_DFU_MTD=y
> > +CONFIG_PCI_INIT_R=y
> > +CONFIG_EFI_CAPSULE_ON_DISK=y
> > +CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
> > +CONFIG_EFI_CAPSULE_FIRMWARE=y
> > +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> > +CONFIG_EFI_CAPSULE_FMP_HEADER=y
> > +
> > +In addition, the following config needs to be disabled::
> > +
> > +CONFIG_TFABOOT
> > +
> > +The capsule file can be generated by using the GenerateCapsule.py
> > +script in edk2::
> > +
> > +$ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \
> > + --fw-version  --lsv  --guid \
> > +e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose --update-image-index
> \
> > + --verbose 
> > +
> > +As per the uefi specification, the capsule file needs to be placed on
> > +the EFI System Partition, under the EFI/UpdateCapsule/ directory. The
> > +EFI System Partition can be a virtio-blk-device.
> > +
> > +Before initiating the firmware update, the efi variables BootNext,
> > +Boot and OsIndications need to be set. The Boot variable needs
> > +to be pointing to the EFI System Partition which contains the capsule
> > +file. The BootNext, Boot and OsIndications variables can be set
> > +using the following commands::
> > +
> > +=> efidebug boot add 0 Boot virtio 0:1 
> > +=> efidebug boot next 0
> > +=> setenv -e -nv -bs -rt -v OsIndications =0x04
> > +=> saveenv
> > +
> > +Finally, the capsule update can be initiated with the following
> > +command::
> > +
> > +=> efidebug capsule disk-update
> > +
> > +The updated u-boot image will be booted on subsequent boot.
> > +
> > +Enabling Capsule Authentication
> > +^^^
> > +
> > +The uefi specification defines a way of authenticating the capsule to
> > +be updated by verifying the capsule signature. The capsule signature
> > +is computed and prepended to the capsule payload at the time of
> > +capsule generation. This signature is then verified by using the
> > +public key stored as part 

[v5 18/18] configs: socfpga: Add defconfig for Agilex and Stratix 10 with ATF support

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

Booting Agilex and Stratix 10 with ATF support.

SPL now loads ATF (BL31), U-Boot proper and DTB from FIT
image. The new boot flow with ATF support is as follow:

SPL -> ATF (BL31) -> U-Boot proper -> OS (Linux)

U-Boot proper now starts at 0x20 (CONFIG_SYS_TEXT_BASE).
ATF will occupy the address range starting from 0x1000.

Signed-off-by: Chee Hong Ang 
Signed-off-by: Siew Chin Lim 
---
 ...ilex_defconfig => socfpga_agilex_atf_defconfig} | 22 
 ...0_defconfig => socfpga_stratix10_atf_defconfig} | 24 +-
 2 files changed, 28 insertions(+), 18 deletions(-)
 copy configs/{socfpga_agilex_defconfig => socfpga_agilex_atf_defconfig} (80%)
 copy configs/{socfpga_stratix10_defconfig => socfpga_stratix10_atf_defconfig} 
(80%)

diff --git a/configs/socfpga_agilex_defconfig 
b/configs/socfpga_agilex_atf_defconfig
similarity index 80%
copy from configs/socfpga_agilex_defconfig
copy to configs/socfpga_agilex_atf_defconfig
index 230d3c2ce5..ad87a8098f 100644
--- a/configs/socfpga_agilex_defconfig
+++ b/configs/socfpga_agilex_atf_defconfig
@@ -1,25 +1,29 @@
 CONFIG_ARM=y
+CONFIG_ARM_SMCCC=y
+CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds"
 CONFIG_ARCH_SOCFPGA=y
-CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_TEXT_BASE=0x20
 CONFIG_SYS_MALLOC_F_LEN=0x2000
-CONFIG_NR_DRAM_BANKS=2
-CONFIG_SYS_MEMTEST_START=0x
-CONFIG_SYS_MEMTEST_END=0x3fe0
 CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0x200
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x3c0
 CONFIG_DM_GPIO=y
-CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_NR_DRAM_BANKS=2
 CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y
 CONFIG_IDENT_STRING="socfpga_agilex"
 CONFIG_SPL_FS_FAT=y
-# CONFIG_PSCI_RESET is not set
-CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex_socdk"
+CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="SOCFPGA_AGILEX # "
 CONFIG_CMD_MEMTEST=y
@@ -35,6 +39,7 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex_socdk"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
@@ -44,6 +49,7 @@ CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_DW=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
+CONFIG_MTD=y
 CONFIG_SF_DEFAULT_MODE=0x2003
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
diff --git a/configs/socfpga_stratix10_defconfig 
b/configs/socfpga_stratix10_atf_defconfig
similarity index 80%
copy from configs/socfpga_stratix10_defconfig
copy to configs/socfpga_stratix10_atf_defconfig
index 3df44bb88d..1005ba979e 100644
--- a/configs/socfpga_stratix10_defconfig
+++ b/configs/socfpga_stratix10_atf_defconfig
@@ -1,26 +1,28 @@
 CONFIG_ARM=y
+CONFIG_ARM_SMCCC=y
+CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds"
 CONFIG_ARCH_SOCFPGA=y
-CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_TEXT_BASE=0x20
 CONFIG_SYS_MALLOC_F_LEN=0x2000
-CONFIG_NR_DRAM_BANKS=2
-CONFIG_SYS_MEMTEST_START=0x
-CONFIG_SYS_MEMTEST_END=0x3fe0
 CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0x200
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x3C0
 CONFIG_DM_GPIO=y
-CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_NR_DRAM_BANKS=2
 CONFIG_TARGET_SOCFPGA_STRATIX10_SOCDK=y
 CONFIG_IDENT_STRING="socfpga_stratix10"
 CONFIG_SPL_FS_FAT=y
-# CONFIG_PSCI_RESET is not set
-CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk"
-CONFIG_OPTIMIZE_INLINING=y
-CONFIG_SPL_OPTIMIZE_INLINING=y
+CONFIG_SPL_TEXT_BASE=0xFFE0
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
 CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # "
 CONFIG_CMD_MEMTEST=y
@@ -37,11 +39,13 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_ALTERA_SDRAM=y
+CONFIG_FPGA_INTEL_PR=y
 CONFIG_DWAPB_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_DW=y
-- 
2.13.0



[v5 17/18] arm: socfpga: soc64: Enable FIT image generation using binman

2020-12-21 Thread Siew Chin Lim
Enable BINMAN when using Arm-Trusted-Firmware (ATF) to
generate FIT images.

Signed-off-by: Siew Chin Lim 

---
v4
---
Adjust BINMAN sequence in code, sorted by alphabetical order.

v5
---
Revert all changes in Makefile for BINMAN:
(1) Remove target "fit-itb", directly use binman command to generate fit
(2) Do not skip binman for ARCH_SOCFPGA in default Makefile flow.
Use "blob-ext" entry instead of "blob" in binman node in device tree,
binman will report warning instead of error in default Makefile flow.
So, it wouldn't fail the default compilation process.
---
 arch/arm/mach-socfpga/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 01f5a1fc41..4d4ff16337 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -33,6 +33,7 @@ config TARGET_SOCFPGA_AGILEX
bool
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
+   select BINMAN if SPL_ATF
select CLK
select FPGA_INTEL_SDM_MAILBOX
select NCORE_CACHE
@@ -78,6 +79,7 @@ config TARGET_SOCFPGA_STRATIX10
bool
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
+   select BINMAN if SPL_ATF
select FPGA_INTEL_SDM_MAILBOX
 
 choice
-- 
2.13.0



[v5 16/18] arm: socfpga: dts: soc64: Add binman node of FIT image with ATF support

2020-12-21 Thread Siew Chin Lim
Add binman node to device tree to generate the FIT image for u-boot
(u-boot.itb) and OS kernel (kernel.itb).

u-boot.itb contains arm trusted firmware (ATF), u-boot proper and
u-boot device tree for ATF u-boot flow.

kernel.itb contains Linux Image and Linux device tree.

Signed-off-by: Siew Chin Lim 

---
v5
---
Change 'blob' to 'blob-ext' entry in binman dts node for all input files.
The input files (u-boot proper, Linux image files) that required to
build FIT images may not yet ready during u-boot compilation.
By using 'blob-ext', binman will report warning instead of error
during u-boot compilation when the input files doesn't exist.
It wouldn't fail the u-boot compilation. Then, user can prepare the
input files later, and use binman command to generate the FIT images.
---
 arch/arm/dts/socfpga_agilex-u-boot.dtsi  |   4 +-
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi   | 120 +++
 arch/arm/dts/socfpga_stratix10-u-boot.dtsi   |   8 ++
 arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi |   4 +-
 4 files changed, 134 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
 create mode 100644 arch/arm/dts/socfpga_stratix10-u-boot.dtsi

diff --git a/arch/arm/dts/socfpga_agilex-u-boot.dtsi 
b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
index f0528a9ad9..08f7cf7f7a 100644
--- a/arch/arm/dts/socfpga_agilex-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
@@ -2,9 +2,11 @@
 /*
  * U-Boot additions
  *
- * Copyright (C) 2019 Intel Corporation 
+ * Copyright (C) 2019-2020 Intel Corporation 
  */
 
+#include "socfpga_soc64_fit-u-boot.dtsi"
+
 /{
memory {
#address-cells = <2>;
diff --git a/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi 
b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
new file mode 100644
index 00..cf365590a8
--- /dev/null
+++ b/arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (C) 2020 Intel Corporation 
+ */
+
+#if defined(CONFIG_FIT)
+
+/ {
+   binman: binman {
+   multiple-images;
+   };
+};
+
+ {
+   u-boot {
+   filename = "u-boot.itb";
+   fit {
+   fit,external-offset = ;
+   description = "FIT with firmware and bootloader";
+   #address-cells = <1>;
+
+   images {
+   uboot {
+   description = "U-Boot SoC64";
+   type = "standalone";
+   os = "U-Boot";
+   arch = "arm64";
+   compression = "none";
+   load = <0x0020>;
+
+   uboot_blob: blob-ext {
+   filename = "u-boot-nodtb.bin";
+   };
+   };
+
+   atf {
+   description = "ARM Trusted Firmware";
+   type = "firmware";
+   os = "arm-trusted-firmware";
+   arch = "arm64";
+   compression = "none";
+   load = <0x1000>;
+   entry = <0x1000>;
+
+   atf_blob: blob-ext {
+   filename = "bl31.bin";
+   };
+   };
+
+   fdt {
+   description = "U-Boot SoC64 flat 
device-tree";
+   type = "flat_dt";
+   compression = "none";
+
+   uboot_fdt_blob: blob-ext {
+   filename = "u-boot.dtb";
+   };
+   };
+   };
+
+   configurations {
+   default = "conf";
+   conf {
+   description = "Intel SoC64 FPGA";
+   firmware = "atf";
+   loadables = "uboot";
+   fdt = "fdt";
+   };
+   };
+   };
+   };
+
+   kernel {
+   filename = "kernel.itb";
+   fit {
+   description = "FIT with Linux kernel image and FDT 
blob";
+   #address-cells = <1>;
+
+   images {
+ 

[v5 15/18] arm: socfpga: soc64: Skip handoff data access in SSBL

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

SPL already setup the Clock Manager with the handoff data
from OCRAM. When the Clock Manager's driver get probed again
in SSBL, it shall skip the handoff data access in OCRAM.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/wrap_pll_config_s10.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-socfpga/wrap_pll_config_s10.c 
b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
index 3da85791a1..049c5711a8 100644
--- a/arch/arm/mach-socfpga/wrap_pll_config_s10.c
+++ b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
@@ -12,6 +12,7 @@
 
 const struct cm_config * const cm_get_default_config(void)
 {
+#ifdef CONFIG_SPL_BUILD
struct cm_config *cm_handoff_cfg = (struct cm_config *)
(S10_HANDOFF_CLOCK + S10_HANDOFF_OFFSET_DATA);
u32 *conversion = (u32 *)cm_handoff_cfg;
@@ -26,7 +27,7 @@ const struct cm_config * const cm_get_default_config(void)
} else if (handoff_clk == S10_HANDOFF_MAGIC_CLOCK) {
return cm_handoff_cfg;
}
-
+#endif
return NULL;
 }
 
-- 
2.13.0



[v5 14/18] arm: socfpga: soc64: SSBL shall not setup stack on OCRAM

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

Since SSBL is running in DRAM, it shall setup the stack in DRAM
instead of OCRAM which is occupied by SPL and handoff data.

Signed-off-by: Chee Hong Ang 
---
 include/configs/socfpga_soc64_common.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index 990f879b07..fdcd7d3e9a 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -40,9 +40,14 @@
  */
 #define CONFIG_SYS_INIT_RAM_ADDR   0xFFE0
 #define CONFIG_SYS_INIT_RAM_SIZE   0x4
+#ifdef CONFIG_SPL_BUILD
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR  \
+ CONFIG_SYS_INIT_RAM_SIZE \
- S10_HANDOFF_SIZE)
+#else
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE \
+   + 0x10)
+#endif
 #define CONFIG_SYS_INIT_SP_OFFSET  (CONFIG_SYS_INIT_SP_ADDR)
 #define CONFIG_SYS_MALLOC_LEN  (5 * 1024 * 1024)
 
-- 
2.13.0



[v5 13/18] arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to mbox_reset_cold()

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

mbox_reset_cold() will invoke ATF's PSCI service when running in
non-secure mode (EL2).

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/mailbox_s10.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-socfpga/mailbox_s10.c 
b/arch/arm/mach-socfpga/mailbox_s10.c
index 18d44924e6..429444f069 100644
--- a/arch/arm/mach-socfpga/mailbox_s10.c
+++ b/arch/arm/mach-socfpga/mailbox_s10.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -398,6 +399,9 @@ error:
 
 int mbox_reset_cold(void)
 {
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+   psci_system_reset();
+#else
int ret;
 
ret = mbox_send_cmd(MBOX_ID_UBOOT, MBOX_REBOOT_HPS, MBOX_CMD_DIRECT,
@@ -406,6 +410,7 @@ int mbox_reset_cold(void)
/* mailbox sent failure, wait for watchdog to kick in */
hang();
}
+#endif
return 0;
 }
 
-- 
2.13.0



[v5 12/18] arm: socfpga: soc64: Add ATF support for FPGA reconfig driver

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

In non-secure mode (EL2), FPGA reconfiguration driver calls the
SMC/PSCI services provided by ATF to configure the FPGA.

Signed-off-by: Chee Hong Ang 
---
 drivers/fpga/intel_sdm_mb.c | 139 
 1 file changed, 139 insertions(+)

diff --git a/drivers/fpga/intel_sdm_mb.c b/drivers/fpga/intel_sdm_mb.c
index 9a1dc2c0c8..f5fd9a14c2 100644
--- a/drivers/fpga/intel_sdm_mb.c
+++ b/drivers/fpga/intel_sdm_mb.c
@@ -8,11 +8,149 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #define RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS   6
 #define RECONFIG_STATUS_INTERVAL_DELAY_US  100
 
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+
+#define BITSTREAM_CHUNK_SIZE   0x0
+#define RECONFIG_STATUS_POLL_RETRY_MAX 100
+
+/*
+ * Polling the FPGA configuration status.
+ * Return 0 for success, non-zero for error.
+ */
+static int reconfig_status_polling_resp(void)
+{
+   int ret;
+   unsigned long start = get_timer(0);
+
+   while (1) {
+   ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE, NULL, 0,
+NULL, 0);
+
+   if (!ret)
+   return 0;   /* configuration success */
+
+   if (ret != INTEL_SIP_SMC_STATUS_BUSY)
+   return ret;
+
+   if (get_timer(start) > RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS)
+   return -ETIMEDOUT;  /* time out */
+
+   puts(".");
+   udelay(RECONFIG_STATUS_INTERVAL_DELAY_US);
+   WATCHDOG_RESET();
+   }
+
+   return -ETIMEDOUT;
+}
+
+static int send_bitstream(const void *rbf_data, size_t rbf_size)
+{
+   int i;
+   u64 res_buf[3];
+   u64 args[2];
+   u32 xfer_count = 0;
+   int ret, wr_ret = 0, retry = 0;
+   size_t buf_size = (rbf_size > BITSTREAM_CHUNK_SIZE) ?
+   BITSTREAM_CHUNK_SIZE : rbf_size;
+
+   while (rbf_size || xfer_count) {
+   if (!wr_ret && rbf_size) {
+   args[0] = (u64)rbf_data;
+   args[1] = buf_size;
+   wr_ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_WRITE,
+   args, 2, NULL, 0);
+
+   debug("wr_ret = %d, rbf_data = %p, buf_size = %08lx\n",
+ wr_ret, rbf_data, buf_size);
+
+   if (wr_ret)
+   continue;
+
+   rbf_size -= buf_size;
+   rbf_data += buf_size;
+
+   if (buf_size >= rbf_size)
+   buf_size = rbf_size;
+
+   xfer_count++;
+   puts(".");
+   } else {
+   ret = invoke_smc(
+   INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE,
+   NULL, 0, res_buf, ARRAY_SIZE(res_buf));
+   if (!ret) {
+   for (i = 0; i < ARRAY_SIZE(res_buf); i++) {
+   if (!res_buf[i])
+   break;
+   xfer_count--;
+   wr_ret = 0;
+   retry = 0;
+   }
+   } else if (ret !=
+  INTEL_SIP_SMC_STATUS_BUSY)
+   return ret;
+   else if (!xfer_count)
+   return INTEL_SIP_SMC_STATUS_ERROR;
+
+   if (++retry >= RECONFIG_STATUS_POLL_RETRY_MAX)
+   return -ETIMEDOUT;
+
+   udelay(2);
+   }
+   WATCHDOG_RESET();
+   }
+
+   return 0;
+}
+
+/*
+ * This is the interface used by FPGA driver.
+ * Return 0 for success, non-zero for error.
+ */
+int intel_sdm_mb_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size)
+{
+   int ret;
+   u64 arg = 1;
+
+   debug("Invoking FPGA_CONFIG_START...\n");
+
+   ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_START, , 1, NULL, 0);
+
+   if (ret) {
+   puts("Failure in RECONFIG mailbox command!\n");
+   return ret;
+   }
+
+   ret = send_bitstream(rbf_data, rbf_size);
+   if (ret) {
+   puts("Error sending bitstream!\n");
+   return ret;
+   }
+
+   /* Make sure we don't send MBOX_RECONFIG_STATUS too fast */
+   udelay(RECONFIG_STATUS_INTERVAL_DELAY_US);
+
+   debug("Polling with MBOX_RECONFIG_STATUS...\n");
+   ret = reconfig_status_polling_resp();
+   if (ret) {
+   puts("FPGA reconfiguration failed!");
+   return ret;
+   }
+
+   puts("FPGA 

[v5 11/18] arm: socfpga: soc64: Add ATF support for Reset Manager driver

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

In non-secure mode (EL2), Reset Manager driver calls the
SMC/PSCI service provided by ATF to enable/disable the
SOCFPGA bridges.

Signed-off-by: Chee Hong Ang 
Signed-off-by: Siew Chin Lim 
---
 arch/arm/mach-socfpga/reset_manager_s10.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/mach-socfpga/reset_manager_s10.c 
b/arch/arm/mach-socfpga/reset_manager_s10.c
index 3746e6a60c..af8f2c0873 100644
--- a/arch/arm/mach-socfpga/reset_manager_s10.c
+++ b/arch/arm/mach-socfpga/reset_manager_s10.c
@@ -5,11 +5,14 @@
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -55,6 +58,15 @@ void socfpga_per_reset_all(void)
 
 void socfpga_bridges_reset(int enable)
 {
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+   u64 arg = enable;
+
+   int ret = invoke_smc(INTEL_SIP_SMC_HPS_SET_BRIDGES, , 1, NULL, 0);
+   if (ret) {
+   printf("SMC call failed with error %d in %s.\n", ret, __func__);
+   return;
+   }
+#else
u32 reg;
 
if (enable) {
@@ -101,6 +113,7 @@ void socfpga_bridges_reset(int enable)
/* Disable NOC timeout */
writel(0, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_TIMEOUT);
}
+#endif
 }
 
 /*
-- 
2.13.0



[v5 09/18] mmc: dwmmc: socfpga: Add ATF support for MMC driver

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

In non-secure mode (EL2), MMC driver calls the SMC/PSCI services
provided by ATF to set SDMMC's DRVSEL and SMPLSEL.

Signed-off-by: Chee Hong Ang 
Signed-off-by: Siew Chin Lim 

---
v5
---
Call secure register access helper function to write the secure register.
Return error if fail to write the secure register.
---
 drivers/mmc/socfpga_dw_mmc.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index 0a2845bcc2..7a485b492d 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -13,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,10 +60,22 @@ static int socfpga_dwmci_clksel(struct dwmci_host *host)
 
debug("%s: drvsel %d smplsel %d\n", __func__,
  priv->drvsel, priv->smplsel);
+
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+   int ret;
+
+   ret = socfpga_secure_reg_write32(SOCFPGA_SECURE_REG_SYSMGR_SOC64_SDMMC,
+sdmmc_mask);
+   if (ret) {
+   printf("DWMMC: Failed to set clksel via SMC call");
+   return ret;
+   }
+#else
writel(sdmmc_mask, socfpga_get_sysmgr_addr() + SYSMGR_SDMMC);
 
debug("%s: SYSMGR_SDMMCGRP_CTRL_REG = 0x%x\n", __func__,
readl(socfpga_get_sysmgr_addr() + SYSMGR_SDMMC));
+#endif
 
/* Enable SDMMC clock */
setbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
-- 
2.13.0



[v5 10/18] net: designware: socfpga: Add ATF support for MAC driver

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

In non-secure mode (EL2), MAC driver calls the SMC/PSCI services
provided by ATF to setup the PHY interface.

Signed-off-by: Chee Hong Ang 
Signed-off-by: Siew Chin Lim 

---
v5
---
Call secure register access helper function to write the secure register.
Return error if fail to write the PHY related secure register.
---
 drivers/net/dwmac_socfpga.c | 38 --
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/net/dwmac_socfpga.c b/drivers/net/dwmac_socfpga.c
index e93561dffa..8efb88c8fb 100644
--- a/drivers/net/dwmac_socfpga.c
+++ b/drivers/net/dwmac_socfpga.c
@@ -6,6 +6,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -17,8 +19,6 @@
 #include 
 #include 
 
-#include 
-
 struct dwmac_socfpga_platdata {
struct dw_eth_pdata dw_eth_pdata;
void*phy_intf;
@@ -64,6 +64,33 @@ static int dwmac_socfpga_ofdata_to_platdata(struct udevice 
*dev)
return designware_eth_ofdata_to_platdata(dev);
 }
 
+static int dwmac_socfpga_do_setphy(struct udevice *dev, u32 modereg)
+{
+   struct dwmac_socfpga_platdata *pdata = dev_get_platdata(dev);
+   u32 modemask = SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << pdata->reg_shift;
+
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+   u32 val = (readl(pdata->phy_intf) & ~modemask) |
+ (modereg << pdata->reg_shift);
+
+   u32 index = ((u64)pdata->phy_intf - socfpga_get_sysmgr_addr() -
+SYSMGR_SOC64_EMAC0) >> 2;
+
+   u32 id = SOCFPGA_SECURE_REG_SYSMGR_SOC64_EMAC0 + index;
+
+   int ret = socfpga_secure_reg_write32(id, val);
+   if (ret) {
+   dev_err(dev, "Failed to set PHY register via SMC call\n");
+   return ret;
+   }
+#else
+   clrsetbits_le32(pdata->phy_intf, modemask,
+   modereg << pdata->reg_shift);
+#endif
+
+   return 0;
+}
+
 static int dwmac_socfpga_probe(struct udevice *dev)
 {
struct dwmac_socfpga_platdata *pdata = dev_get_platdata(dev);
@@ -71,7 +98,6 @@ static int dwmac_socfpga_probe(struct udevice *dev)
struct reset_ctl_bulk reset_bulk;
int ret;
u32 modereg;
-   u32 modemask;
 
switch (edata->phy_interface) {
case PHY_INTERFACE_MODE_MII:
@@ -97,9 +123,9 @@ static int dwmac_socfpga_probe(struct udevice *dev)
 
reset_assert_bulk(_bulk);
 
-   modemask = SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << pdata->reg_shift;
-   clrsetbits_le32(pdata->phy_intf, modemask,
-   modereg << pdata->reg_shift);
+   ret = dwmac_socfpga_do_setphy(dev, modereg);
+   if (ret)
+   return ret;
 
reset_release_bulk(_bulk);
 
-- 
2.13.0



[v5 07/18] arm: socfpga: Add secure register access helper functions for SoC 64bits

2020-12-21 Thread Siew Chin Lim
These secure register access functions allow U-Boot proper running
at EL2 (non-secure) to access System Manager's secure registers
by calling the ATF's PSCI runtime services (EL3/secure).

Signed-off-by: Siew Chin Lim 

---
v5
---
Return error code instead of hang the system if fail to access
the secure register.
---
 arch/arm/mach-socfpga/Makefile |  1 +
 .../mach-socfpga/include/mach/secure_reg_helper.h  | 19 +
 arch/arm/mach-socfpga/secure_reg_helper.c  | 97 ++
 3 files changed, 117 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
 create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 0b05283a7a..82b681d870 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -73,6 +73,7 @@ obj-y += firewall.o
 obj-y  += spl_agilex.o
 endif
 else
+obj-$(CONFIG_SPL_ATF) += secure_reg_helper.o
 obj-$(CONFIG_SPL_ATF) += smc_api.o
 endif
 
diff --git a/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h 
b/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
new file mode 100644
index 00..d5a11122c7
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2020 Intel Corporation 
+ *
+ */
+
+#ifndef_SECURE_REG_HELPER_H_
+#define_SECURE_REG_HELPER_H_
+
+#define SOCFPGA_SECURE_REG_SYSMGR_SOC64_SDMMC 1
+#define SOCFPGA_SECURE_REG_SYSMGR_SOC64_EMAC0 2
+#define SOCFPGA_SECURE_REG_SYSMGR_SOC64_EMAC1 3
+#define SOCFPGA_SECURE_REG_SYSMGR_SOC64_EMAC2 4
+
+int socfpga_secure_reg_read32(u32 id, u32 *val);
+int socfpga_secure_reg_write32(u32 id, u32 val);
+int socfpga_secure_reg_update32(u32 id, u32 mask, u32 val);
+
+#endif /* _SECURE_REG_HELPER_H_ */
diff --git a/arch/arm/mach-socfpga/secure_reg_helper.c 
b/arch/arm/mach-socfpga/secure_reg_helper.c
new file mode 100644
index 00..d9be45cc97
--- /dev/null
+++ b/arch/arm/mach-socfpga/secure_reg_helper.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Intel Corporation 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int socfpga_secure_convert_reg_id_to_addr(u32 id, phys_addr_t *reg_addr)
+{
+   switch (id) {
+   case SOCFPGA_SECURE_REG_SYSMGR_SOC64_SDMMC:
+   *reg_addr = socfpga_get_sysmgr_addr() + SYSMGR_SOC64_SDMMC;
+   break;
+   case SOCFPGA_SECURE_REG_SYSMGR_SOC64_EMAC0:
+   *reg_addr = socfpga_get_sysmgr_addr() + SYSMGR_SOC64_EMAC0;
+   break;
+   case SOCFPGA_SECURE_REG_SYSMGR_SOC64_EMAC1:
+   *reg_addr = socfpga_get_sysmgr_addr() + SYSMGR_SOC64_EMAC1;
+   break;
+   case SOCFPGA_SECURE_REG_SYSMGR_SOC64_EMAC2:
+   *reg_addr = socfpga_get_sysmgr_addr() + SYSMGR_SOC64_EMAC2;
+   break;
+   default:
+   return -EADDRNOTAVAIL;
+   }
+   return 0;
+}
+
+int socfpga_secure_reg_read32(u32 id, u32 *val)
+{
+   int ret;
+   u64 ret_arg;
+   u64 args[1];
+
+   phys_addr_t reg_addr;
+   ret = socfpga_secure_convert_reg_id_to_addr(id, _addr);
+   if (ret)
+   return ret;
+
+   args[0] = (u64)reg_addr;
+   ret = invoke_smc(INTEL_SIP_SMC_REG_READ, args, 1, _arg, 1);
+   if (ret)
+   return ret;
+
+   *val = (u32)ret_arg;
+
+   return 0;
+}
+
+int socfpga_secure_reg_write32(u32 id, u32 val)
+{
+   int ret;
+   u64 args[2];
+
+   phys_addr_t reg_addr;
+   ret = socfpga_secure_convert_reg_id_to_addr(id, _addr);
+   if (ret)
+   return ret;
+
+   args[0] = (u64)reg_addr;
+   args[1] = val;
+   ret = invoke_smc(INTEL_SIP_SMC_REG_WRITE, args, 2, NULL, 0);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+int socfpga_secure_reg_update32(u32 id, u32 mask, u32 val)
+{
+   int ret;
+   u64 args[3];
+
+   phys_addr_t reg_addr;
+   ret = socfpga_secure_convert_reg_id_to_addr(id, _addr);
+   if (ret)
+   return ret;
+
+   args[0] = (u64)reg_addr;
+   args[1] = mask;
+   args[2] = val;
+   ret = invoke_smc(INTEL_SIP_SMC_REG_UPDATE, args, 3, NULL, 0);
+   if (ret)
+   return ret;
+
+   return 0;
+}
-- 
2.13.0



[v5 08/18] mmc: dwmmc: Change designware MMC 'clksel' callback function to return status

2020-12-21 Thread Siew Chin Lim
Change 'clksel' callback function to allow the code to return a
status.

This patch is a preparation for enabling Arm-Trusted-Firmware (ATF)
in Intel SoC FPGA. This patch does not change functionality.

When using Arm-Trusted-Firmware (ATF) in Intel SoC FPGA, the MMC clock
related register is secure register which is required to be written
via SMC/PCSI call. It is possible that U-Boot fail to write the
register if there is unexpected error between U-Boot and ATF.
As a result, there maybe signal integrity on MMC connection due to
clock. So, the code should reports error to user when 'clksel' fail.

Signed-off-by: Siew Chin Lim 
---
 drivers/mmc/ca_dw_mmc.c  | 4 +++-
 drivers/mmc/dw_mmc.c | 9 +++--
 drivers/mmc/exynos_dw_mmc.c  | 4 +++-
 drivers/mmc/nexell_dw_mmc.c  | 4 +++-
 drivers/mmc/socfpga_dw_mmc.c | 4 +++-
 include/dwmmc.h  | 2 +-
 6 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/ca_dw_mmc.c b/drivers/mmc/ca_dw_mmc.c
index 198c41f451..d0cf1b7248 100644
--- a/drivers/mmc/ca_dw_mmc.c
+++ b/drivers/mmc/ca_dw_mmc.c
@@ -40,7 +40,7 @@ struct ca_dwmmc_priv_data {
u8 ds;
 };
 
-static void ca_dwmci_clksel(struct dwmci_host *host)
+static int ca_dwmci_clksel(struct dwmci_host *host)
 {
struct ca_dwmmc_priv_data *priv = host->priv;
u32 val = readl(priv->sd_dll_reg);
@@ -52,6 +52,8 @@ static void ca_dwmci_clksel(struct dwmci_host *host)
val |= SD_CLK_SEL_100MHZ;
 
writel(val, priv->sd_dll_reg);
+
+   return 0;
 }
 
 static void ca_dwmci_board_init(struct dwmci_host *host)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 7702f4be3f..7c8a312fa7 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -496,8 +496,13 @@ static int dwmci_set_ios(struct mmc *mmc)
 
dwmci_writel(host, DWMCI_UHS_REG, regs);
 
-   if (host->clksel)
-   host->clksel(host);
+   if (host->clksel) {
+   int ret;
+
+   ret = host->clksel(host);
+   if (ret)
+   return ret;
+   }
 
 #if CONFIG_IS_ENABLED(DM_REGULATOR)
if (mmc->vqmmc_supply) {
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index 435ccac594..7a25dac841 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -44,7 +44,7 @@ struct dwmci_exynos_priv_data {
  * Function used as callback function to initialise the
  * CLKSEL register for every mmc channel.
  */
-static void exynos_dwmci_clksel(struct dwmci_host *host)
+static int exynos_dwmci_clksel(struct dwmci_host *host)
 {
 #ifdef CONFIG_DM_MMC
struct dwmci_exynos_priv_data *priv =
@@ -53,6 +53,8 @@ static void exynos_dwmci_clksel(struct dwmci_host *host)
struct dwmci_exynos_priv_data *priv = host->priv;
 #endif
dwmci_writel(host, DWMCI_CLKSEL, priv->sdr_timing);
+
+   return 0;
 }
 
 unsigned int exynos_dwmci_get_clk(struct dwmci_host *host, uint freq)
diff --git a/drivers/mmc/nexell_dw_mmc.c b/drivers/mmc/nexell_dw_mmc.c
index 0462759444..fe00189fe1 100644
--- a/drivers/mmc/nexell_dw_mmc.c
+++ b/drivers/mmc/nexell_dw_mmc.c
@@ -51,7 +51,7 @@ struct nexell_dwmmc_priv {
 
 struct clk *clk_get(const char *id);
 
-static void nx_dw_mmc_clksel(struct dwmci_host *host)
+static int nx_dw_mmc_clksel(struct dwmci_host *host)
 {
/* host->priv is pointer to "struct udevice" */
struct nexell_dwmmc_priv *priv = dev_get_priv(host->priv);
@@ -65,6 +65,8 @@ static void nx_dw_mmc_clksel(struct dwmci_host *host)
  DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(3);
 
dwmci_writel(host, DWMCI_CLKSEL, val);
+
+   return 0;
 }
 
 static void nx_dw_mmc_reset(int ch)
diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index 0022f943bd..0a2845bcc2 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -46,7 +46,7 @@ static void socfpga_dwmci_reset(struct udevice *dev)
reset_deassert_bulk(_bulk);
 }
 
-static void socfpga_dwmci_clksel(struct dwmci_host *host)
+static int socfpga_dwmci_clksel(struct dwmci_host *host)
 {
struct dwmci_socfpga_priv_data *priv = host->priv;
u32 sdmmc_mask = ((priv->smplsel & 0x7) << SYSMGR_SDMMC_SMPLSEL_SHIFT) |
@@ -66,6 +66,8 @@ static void socfpga_dwmci_clksel(struct dwmci_host *host)
/* Enable SDMMC clock */
setbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
 CLKMGR_PERPLLGRP_EN_SDMMCCLK_MASK);
+
+   return 0;
 }
 
 static int socfpga_dwmmc_get_clk_rate(struct udevice *dev)
diff --git a/include/dwmmc.h b/include/dwmmc.h
index d8a8355a0a..f8aeda7697 100644
--- a/include/dwmmc.h
+++ b/include/dwmmc.h
@@ -174,7 +174,7 @@ struct dwmci_host {
struct mmc *mmc;
void *priv;
 
-   void (*clksel)(struct dwmci_host *host);
+   int (*clksel)(struct dwmci_host *host);
void (*board_init)(struct dwmci_host *host);
 
/**
-- 
2.13.0



[v5 06/18] arm: socfpga: soc64: Define SMC function identifiers for PSCI SiP services

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

This header file defines the Secure Monitor Call (SMC) message
protocol for ATF (BL31) PSCI runtime services. It includes all
the PSCI SiP function identifiers for the secure runtime services
provided by ATF. The secure runtime services include System Manager's
registers access, 2nd phase bitstream FPGA reconfiguration, Remote
System Update (RSU) and etc.

Signed-off-by: Chee Hong Ang 
Signed-off-by: Siew Chin Lim 
---
 include/linux/intel-smc.h | 573 ++
 1 file changed, 573 insertions(+)
 create mode 100644 include/linux/intel-smc.h

diff --git a/include/linux/intel-smc.h b/include/linux/intel-smc.h
new file mode 100644
index 00..cacb410691
--- /dev/null
+++ b/include/linux/intel-smc.h
@@ -0,0 +1,573 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2017-2018, Intel Corporation
+ */
+
+#ifndef __INTEL_SMC_H
+#define __INTEL_SMC_H
+
+#include 
+#include 
+
+/*
+ * This file defines the Secure Monitor Call (SMC) message protocol used for
+ * service layer driver in normal world (EL1) to communicate with secure
+ * monitor software in Secure Monitor Exception Level 3 (EL3).
+ *
+ * This file is shared with secure firmware (FW) which is out of u-boot tree.
+ *
+ * An ARM SMC instruction takes a function identifier and up to 6 64-bit
+ * register values as arguments, and can return up to 4 64-bit register
+ * values. The operation of the secure monitor is determined by the parameter
+ * values passed in through registers.
+
+ * EL1 and EL3 communicates pointer as physical address rather than the
+ * virtual address.
+ */
+
+/*
+ * Functions specified by ARM SMC Calling convention:
+ *
+ * FAST call executes atomic operations, returns when the requested operation
+ * has completed.
+ * STD call starts a operation which can be preempted by a non-secure
+ * interrupt. The call can return before the requested operation has
+ * completed.
+ *
+ * a0..a7 is used as register names in the descriptions below, on arm32
+ * that translates to r0..r7 and on arm64 to w0..w7.
+ */
+
+#define INTEL_SIP_SMC_STD_CALL_VAL(func_num) \
+   ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_64, \
+   ARM_SMCCC_OWNER_SIP, (func_num))
+
+#define INTEL_SIP_SMC_FAST_CALL_VAL(func_num) \
+   ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \
+   ARM_SMCCC_OWNER_SIP, (func_num))
+
+/*
+ * Return values in INTEL_SIP_SMC_* call
+ *
+ * INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION:
+ * Secure monitor software doesn't recognize the request.
+ *
+ * INTEL_SIP_SMC_STATUS_OK:
+ * SMC call completed successfully,
+ * In case of FPGA configuration write operation, it means secure monitor
+ * software can accept the next chunk of FPGA configuration data.
+ *
+ * INTEL_SIP_SMC_STATUS_BUSY:
+ * In case of FPGA configuration write operation, it means secure monitor
+ * software is still processing previous data & can't accept the next chunk
+ * of data. Service driver needs to issue
+ * INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE call to query the
+ * completed block(s).
+ *
+ * INTEL_SIP_SMC_STATUS_ERROR:
+ * There is error during the SMC call process.
+ *
+ * INTEL_SIP_SMC_REG_ERROR:
+ * There is error during a read or write operation of the protected
+ * registers.
+ */
+#define INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION  0x
+#define INTEL_SIP_SMC_STATUS_OK0x0
+#define INTEL_SIP_SMC_STATUS_BUSY  0x1
+#define INTEL_SIP_SMC_STATUS_REJECTED  0x2
+#define INTEL_SIP_SMC_STATUS_ERROR 0x4
+#define INTEL_SIP_SMC_REG_ERROR0x5
+#define INTEL_SIP_SMC_RSU_ERROR0x7
+
+/*
+ * Request INTEL_SIP_SMC_FPGA_CONFIG_START
+ *
+ * Sync call used by service driver at EL1 to request the FPGA in EL3 to
+ * be prepare to receive a new configuration.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_FPGA_CONFIG_START.
+ * a1: flag for full or partial configuration
+ *0 full reconfiguration.
+ *1 partial reconfiguration.
+ * a2-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK, or INTEL_SIP_SMC_STATUS_ERROR.
+ * a1-3: not used.
+ */
+#define INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START 1
+#define INTEL_SIP_SMC_FPGA_CONFIG_START \
+   INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START)
+
+/*
+ * Request INTEL_SIP_SMC_FPGA_CONFIG_WRITE
+ *
+ * Async call used by service driver at EL1 to provide FPGA configuration data
+ * to secure world.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_FPGA_CONFIG_WRITE.
+ * a1: 64bit physical address of the configuration data memory block
+ * a2: Size of configuration data block.
+ * a3-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_STATUS_BUSY,
+ * INTEL_SIP_SMC_STATUS_REJECTED or INTEL_SIP_SMC_STATUS_ERROR.
+ * a1: 64bit physical address of 1st completed memory block if any completed
+ * block, 

[v5 05/18] arm: socfpga: soc64: Add SMC helper function for Intel SOCFPGA (64bits)

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

invoke_smc() allow U-Boot proper running in non-secure mode (EL2)
to invoke SMC call to ATF's PSCI runtime services such as
System Manager's registers access, 2nd phase bitstream FPGA
reconfiguration, Remote System Update (RSU) and etc.

smc_send_mailbox() is a send mailbox command helper function which invokes
the ATF's PSCI runtime service (function ID: INTEL_SIP_SMC_MBOX_SEND_CMD)
to send mailbox messages to Secure Device Manager (SDM).

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/Makefile   |  2 +
 arch/arm/mach-socfpga/include/mach/smc_api.h | 13 +++
 arch/arm/mach-socfpga/smc_api.c  | 56 
 3 files changed, 71 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/include/mach/smc_api.h
 create mode 100644 arch/arm/mach-socfpga/smc_api.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index c63162a5c6..0b05283a7a 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -72,6 +72,8 @@ ifdef CONFIG_TARGET_SOCFPGA_AGILEX
 obj-y  += firewall.o
 obj-y  += spl_agilex.o
 endif
+else
+obj-$(CONFIG_SPL_ATF) += smc_api.o
 endif
 
 ifdef CONFIG_TARGET_SOCFPGA_GEN5
diff --git a/arch/arm/mach-socfpga/include/mach/smc_api.h 
b/arch/arm/mach-socfpga/include/mach/smc_api.h
new file mode 100644
index 00..bbefdd8dd9
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/smc_api.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2020 Intel Corporation
+ */
+
+#ifndef _SMC_API_H_
+#define _SMC_API_H_
+
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len);
+int smc_send_mailbox(u32 cmd, u32 len, u32 *arg, u8 urgent, u32 *resp_buf_len,
+u32 *resp_buf);
+
+#endif /* _SMC_API_H_ */
diff --git a/arch/arm/mach-socfpga/smc_api.c b/arch/arm/mach-socfpga/smc_api.c
new file mode 100644
index 00..085daba162
--- /dev/null
+++ b/arch/arm/mach-socfpga/smc_api.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Intel Corporation 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len)
+{
+   struct pt_regs regs;
+
+   memset(, 0, sizeof(regs));
+   regs.regs[0] = func_id;
+
+   if (args)
+   memcpy([1], args, arg_len * sizeof(*args));
+
+   smc_call();
+
+   if (ret_arg)
+   memcpy(ret_arg, [1], ret_len * sizeof(*ret_arg));
+
+   return regs.regs[0];
+}
+
+int smc_send_mailbox(u32 cmd, u32 len, u32 *arg, u8 urgent, u32 *resp_buf_len,
+u32 *resp_buf)
+{
+   int ret;
+   u64 args[6];
+   u64 resp[3];
+
+   args[0] = cmd;
+   args[1] = (u64)arg;
+   args[2] = len;
+   args[3] = urgent;
+   args[4] = (u64)resp_buf;
+   if (resp_buf_len)
+   args[5] = *resp_buf_len;
+   else
+   args[5] = 0;
+
+   ret = invoke_smc(INTEL_SIP_SMC_MBOX_SEND_CMD, args, ARRAY_SIZE(args),
+resp, ARRAY_SIZE(resp));
+
+   if (ret == INTEL_SIP_SMC_STATUS_OK && resp_buf && resp_buf_len) {
+   if (!resp[0])
+   *resp_buf_len = resp[1];
+   }
+
+   return (int)resp[0];
+}
-- 
2.13.0



[v5 04/18] arm: socfpga: Disable "spin-table" method for booting Linux

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

Standard PSCI function "CPU_ON" provided by ATF is now used
by Linux kernel to bring up the secondary CPUs to enable SMP
booting in Linux on SoC 64bits platform.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 26f2cf8e47..01f5a1fc41 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -33,7 +33,6 @@ config TARGET_SOCFPGA_AGILEX
bool
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
-   select ARMV8_SPIN_TABLE
select CLK
select FPGA_INTEL_SDM_MAILBOX
select NCORE_CACHE
@@ -79,7 +78,6 @@ config TARGET_SOCFPGA_STRATIX10
bool
select ARMV8_MULTIENTRY
select ARMV8_SET_SMPEN
-   select ARMV8_SPIN_TABLE
select FPGA_INTEL_SDM_MAILBOX
 
 choice
-- 
2.13.0



[v5 03/18] arm: socfpga: soc64: Override 'lowlevel_init' to support ATF

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

Override 'lowlevel_init' to make sure secondary CPUs trapped
in ATF instead of SPL. After ATF is initialized, it will signal
the secondary CPUs to jump from SPL to ATF waiting to be 'activated'
by Linux OS via PSCI call.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/Makefile |  2 ++
 .../arm/mach-socfpga/lowlevel_init_soc64.S | 41 --
 2 files changed, 17 insertions(+), 26 deletions(-)
 copy board/cortina/presidio-asic/lowlevel_init.S => 
arch/arm/mach-socfpga/lowlevel_init_soc64.S (66%)

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 418f543b20..c63162a5c6 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -29,6 +29,7 @@ endif
 
 ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
 obj-y  += clock_manager_s10.o
+obj-y  += lowlevel_init_soc64.o
 obj-y  += mailbox_s10.o
 obj-y  += misc_s10.o
 obj-y  += mmu-arm64_s10.o
@@ -41,6 +42,7 @@ endif
 
 ifdef CONFIG_TARGET_SOCFPGA_AGILEX
 obj-y  += clock_manager_agilex.o
+obj-y  += lowlevel_init_soc64.o
 obj-y  += mailbox_s10.o
 obj-y  += misc_s10.o
 obj-y  += mmu-arm64_s10.o
diff --git a/board/cortina/presidio-asic/lowlevel_init.S 
b/arch/arm/mach-socfpga/lowlevel_init_soc64.S
similarity index 66%
copy from board/cortina/presidio-asic/lowlevel_init.S
copy to arch/arm/mach-socfpga/lowlevel_init_soc64.S
index 4450a5df79..612ea8a037 100644
--- a/board/cortina/presidio-asic/lowlevel_init.S
+++ b/arch/arm/mach-socfpga/lowlevel_init_soc64.S
@@ -1,43 +1,31 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Copyright (C) 2020 Cortina-Access
+ * Copyright (C) 2020 Intel Corporation. All rights reserved
  *
+ * SPDX-License-Identifier:GPL-2.0
  */
 
-
 #include 
 #include 
 #include 
 #include 
-#include 
 
-   .globl lowlevel_init
-lowlevel_init:
+ENTRY(lowlevel_init)
mov x29, lr /* Save LR */
 
-#if defined(CONFIG_SOC_CA7774)
-   /* Enable SMPEN in CPUECTLR */
-   mrs x0, s3_1_c15_c2_1
-   tst x0, #0x40
-b.neskip_smp_setup
-   orr x0, x0, #0x40
-   msr s3_1_c15_c2_1, x0
-skip_smp_setup:
-#endif
-
-#if defined(CONFIG_SOC_CA8277B)
-   /* Enable CPU Timer */
-   ldr x0, =CONFIG_SYS_TIMER_BASE
-   mov x1, #1
-   str w1, [x0]
-#endif
-
 #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3)
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+wait_for_atf:
+   ldr x4, =CPU_RELEASE_ADDR
+   ldr x5, [x4]
+   cbz x5, slave_wait_atf
+   br  x5
+slave_wait_atf:
+   branch_if_slave x0, wait_for_atf
+#else
branch_if_slave x0, 1f
-#ifndef CONFIG_TARGET_VENUS
+#endif
ldr x0, =GICD_BASE
bl  gic_init_secure
-#endif
 1:
 #if defined(CONFIG_GICV3)
ldr x0, =GICR_BASE
@@ -54,7 +42,7 @@ skip_smp_setup:
 
/*
 * Slave should wait for master clearing spin table.
-* This sync prevent salves observing incorrect
+* This sync prevent slaves observing incorrect
 * value of spin table and jumping to wrong place.
 */
 #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3)
@@ -85,3 +73,4 @@ lowlevel_in_el1:
 2:
mov lr, x29 /* Restore LR */
ret
+ENDPROC(lowlevel_init)
-- 
2.13.0



[v5 02/18] arm: socfpga: soc64: Load FIT image with ATF support

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

Instead of loading u-boot proper image (u-boot.img), SPL
now loads FIT image (u-boot.itb) which includes u-boot
proper, ATF and u-boot proper's DTB.

For OS, u-boot now loads FIT images (kernel.itb) which
includes Linux Image and Linux's DTB.

Signed-off-by: Chee Hong Ang 
Signed-off-by: Siew Chin Lim 
---
 include/configs/socfpga_soc64_common.h | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index fb5e2e8aaf..990f879b07 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -78,12 +78,20 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
  * CONFIG_BOOTARGS goes into the environment value "bootargs".
  * Do note the value will override also the chosen node in FDT blob.
  */
+
+#ifdef CONFIG_FIT
+#define CONFIG_BOOTFILE "kernel.itb"
+#define CONFIG_BOOTCOMMAND "run fatscript; run mmcfitload;run 
linux_qspi_enable;" \
+  "run mmcfitboot"
+#else
+#define CONFIG_BOOTFILE "Image"
 #define CONFIG_BOOTCOMMAND "run fatscript; run mmcload;run linux_qspi_enable;" 
\
   "run mmcboot"
+#endif
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
-   "bootfile=Image\0" \
+   "bootfile=" CONFIG_BOOTFILE "\0" \
"fdt_addr=800\0" \
"fdtimage=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
"mmcroot=/dev/mmcblk0p2\0" \
@@ -93,6 +101,11 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
"mmcload=mmc rescan;" \
"load mmc 0:1 ${loadaddr} ${bootfile};" \
"load mmc 0:1 ${fdt_addr} ${fdtimage}\0" \
+   "mmcfitboot=setenv bootargs " CONFIG_BOOTARGS \
+   " root=${mmcroot} rw rootwait;" \
+   "bootm ${loadaddr}\0" \
+   "mmcfitload=mmc rescan;" \
+   "load mmc 0:1 ${loadaddr} ${bootfile}\0" \
"linux_qspi_enable=if sf probe; then " \
"echo Enabling QSPI at Linux DTB...;" \
"fdt addr ${fdt_addr}; fdt resize;" \
@@ -193,6 +206,10 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
- CONFIG_SYS_SPL_MALLOC_SIZE)
 
 /* SPL SDMMC boot support */
+#ifdef CONFIG_SPL_LOAD_FIT
+#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.itb"
+#else
 #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"
+#endif
 
 #endif /* __CONFIG_SOCFPGA_SOC64_COMMON_H__ */
-- 
2.13.0



[v5 01/18] arm: socfpga: Add function for checking description from FIT image

2020-12-21 Thread Siew Chin Lim
From: Chee Hong Ang 

Add board_fit_config_name_match() for matching board name with
device tree files in FIT image. This will ensure correct DTB
file is loaded for different board type. Currently, we are not
supporting multiple device tree files in FIT image therefore this
function basically do nothing for now.
Users are allowed to override this 'weak' function in their
specific board implementation.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/board.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index 340abf9305..7993c27646 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 #include 
 
@@ -87,3 +87,13 @@ int g_dnl_board_usb_cable_connected(void)
return 1;
 }
 #endif
+
+#ifdef CONFIG_SPL_BUILD
+__weak int board_fit_config_name_match(const char *name)
+{
+   /* Just empty function now - can't decide what to choose */
+   debug("%s: %s\n", __func__, name);
+
+   return 0;
+}
+#endif
-- 
2.13.0



[v5 00/18] Enable ARM Trusted Firmware for U-Boot

2020-12-21 Thread Siew Chin Lim
This is the 5th version of patchset to enable ARM Trusted Firmware
for U-Boot for Intel Stratix10 and Agilex platform.

New U-boot flow with ARM Trusted Firmware (ATF) support:
SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)

SPL loads the u-boot.itb which consist of:
1) u-boot-nodtb.bin (U-Boot Proper image)
2) u-boot.dtb (U-Boot Proper DTB)
3) bl31.bin (ATF-BL31 image)


Patch status:
Have changes: Patch 7, 8, 9, 10, 16, 17
Other patches unchanged.

Detail changelog can find in commit message.

v4->v5:

Patch 7:
-  Change secure register access helper functions to return
   error code instead of hang the system if fail to access
   the secure register.

Patch 8:
-  Change designware MMC driver 'clksel' callback function to
   return the status. This patch is a preparation for enabling
   Arm-Trusted-Firmware (ATF) in Intel SoC FPGA.
   This patch does not change functionality.

Patch 9:
-  Report error if secure register access helper function failed
   to write SDMMC's DRVSEL and SMPLSEL via SMC call.

Patch 10:
-  Report error if secure register access helper function failed
   to write PHY register via SMC call.

patch 16:
-  Change 'blob' to 'blob-ext' entry in binman dts node for all
   input files.

patch 17:
-  Revert all changes about BINMAN in Makefile.


History:

[v1]: 
https://patchwork.ozlabs.org/project/uboot/cover/20200817043431.28718-1-chee.hong@intel.com/
[v2]: 
https://patchwork.ozlabs.org/project/uboot/cover/20201001091614.184612-1-elly.siew.chin@intel.com/
[v3]: 
https://patchwork.ozlabs.org/project/uboot/cover/20201015122955.10259-1-elly.siew.chin@intel.com/
[v4]: 
https://patchwork.ozlabs.org/project/uboot/cover/20201218032853.46839-1-elly.siew.chin@intel.com/


These patchsets have dependency on:
arm: socfpga: soc64: Add timeout waiting for NOC idle ACK
https://lists.denx.de/pipermail/u-boot/2020-August/423029.html

Rename Stratix10 FPGA driver and support Agilex
https://lists.denx.de/pipermail/u-boot/2020-August/422798.html

SoCFPGA mailbox driver fixes and enhancements
https://lists.denx.de/pipermail/u-boot/2020-August/423140.html

arm: socfpga: soc64: Initialize timer in SPL only
https://lists.denx.de/pipermail/u-boot/2020-July/419692.html

arm: socfpga: soc64: Remove PHY interface setup from misc arch init
https://lists.denx.de/pipermail/u-boot/2020-July/419690.html

Enable sysreset support for SoCFPGA SoC64 platforms
https://lists.denx.de/pipermail/u-boot/2020-August/422509.html

arm: socfpga: soc64: Disable CONFIG_PSCI_RESET
https://lists.denx.de/pipermail/u-boot/2020-August/423373.html
*** BLURB HERE ***

Chee Hong Ang (14):
  arm: socfpga: Add function for checking description from FIT image
  arm: socfpga: soc64: Load FIT image with ATF support
  arm: socfpga: soc64: Override 'lowlevel_init' to support ATF
  arm: socfpga: Disable "spin-table" method for booting Linux
  arm: socfpga: soc64: Add SMC helper function for Intel SOCFPGA
(64bits)
  arm: socfpga: soc64: Define SMC function identifiers for PSCI SiP
services
  mmc: dwmmc: socfpga: Add ATF support for MMC driver
  net: designware: socfpga: Add ATF support for MAC driver
  arm: socfpga: soc64: Add ATF support for Reset Manager driver
  arm: socfpga: soc64: Add ATF support for FPGA reconfig driver
  arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to
mbox_reset_cold()
  arm: socfpga: soc64: SSBL shall not setup stack on OCRAM
  arm: socfpga: soc64: Skip handoff data access in SSBL
  configs: socfpga: Add defconfig for Agilex and Stratix 10 with ATF
support

Siew Chin Lim (4):
  arm: socfpga: Add secure register access helper functions for SoC
64bits
  mmc: dwmmc: Change designware MMC 'clksel' callback function to return
status
  arm: socfpga: dts: soc64: Add binman node of FIT image with ATF
support
  arm: socfpga: soc64: Enable FIT image generation using binman

 arch/arm/dts/socfpga_agilex-u-boot.dtsi|   4 +-
 arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 120 +
 arch/arm/dts/socfpga_stratix10-u-boot.dtsi |   8 +
 arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi   |   4 +-
 arch/arm/mach-socfpga/Kconfig  |   4 +-
 arch/arm/mach-socfpga/Makefile |   5 +
 arch/arm/mach-socfpga/board.c  |  12 +-
 .../mach-socfpga/include/mach/secure_reg_helper.h  |  19 +
 arch/arm/mach-socfpga/include/mach/smc_api.h   |  13 +
 arch/arm/mach-socfpga/lowlevel_init_soc64.S|  76 +++
 arch/arm/mach-socfpga/mailbox_s10.c|   5 +
 arch/arm/mach-socfpga/reset_manager_s10.c  |  13 +
 arch/arm/mach-socfpga/secure_reg_helper.c  |  97 
 arch/arm/mach-socfpga/smc_api.c|  56 ++
 arch/arm/mach-socfpga/wrap_pll_config_s10.c|   3 +-
 configs/socfpga_agilex_atf_defconfig   |  72 +++
 configs/socfpga_stratix10_atf_defconfig|  74 +++
 drivers/fpga/intel_sdm_mb.c| 

Re: [PATCH v3 04/12] dm: Introduce xxx_get_dma_range()

2020-12-21 Thread Simon Glass
Hi Nicolas,

On Mon, 21 Dec 2020 at 06:03, Nicolas Saenz Julienne
 wrote:
>
> Hi Simon, thanks for the review.
>
> On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> > Hi Nicolas,
> >
> > On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
> >  wrote:
> > >
> > > Add the following functions to get a specific device's DMA ranges:
> > >  - dev_get_dma_range()
> > >  - ofnode_get_dma_range()
> > >  - of_get_dma_range()
> > >  - fdt_get_dma_range()
> > > They are specially useful in oder to be able validate a physical address
> > > space range into a bus's and to convert addresses from and to address
> > > spaces.
> > >
> > > Signed-off-by: Nicolas Saenz Julienne 
> > >
> > > ---
> > > Changes since v2:
> > >  - Return ENOENT instead of ENODEV
> > >  - Refcount OF nodes
> > >
> > > Changes since v1:
> > >  - Fix wrong arguments in of_get_dma_range()'s call to 
> > > of_translate_dma_address()
> > >  - Fix build in SPL/TPL and no LIBFDT supprt
> > >  - Add missing declaration in 'core/read.c'
> > >  - Address Matthias' comments
> > >
> > >  common/fdt_support.c   | 73 +++
> > >  drivers/core/of_addr.c | 78 ++
> > >  drivers/core/ofnode.c  |  9 +
> > >  drivers/core/read.c|  6 
> > >  include/dm/of_addr.h   | 17 +
> > >  include/dm/ofnode.h| 16 +
> > >  include/dm/read.h  | 21 
> > >  include/fdt_support.h  | 14 
> > >  8 files changed, 234 insertions(+)
> >
> > Reviewed-by: Simon Glass 
> >
> > I don't suppose it is worth writing a version that uses the ofnode API
> > and thus reduce code size? Probably not since if livetree is enabled,
> > I doubt we would ever call the flattree one. Also it is nice to have
> > the same livetree code as Linux, where possible.
>
> As far as the logic is concerned we'd be able to mimic what linux does so it
> shouldn't be a problem.
>
> But I'd be forced to port low level DT code to ofnode. Notably 
> 'of_match_bus()'
> and 'struct of_bus', which IMO have no place in ofnode: it seems to me that
> ofnode is an abstraction geared towards simplifying DT consumers. This 
> wouldn't
> provide much benefit to them, with the downside of divering from upstream
> Linux's implementation.

Yes that sounds right to me, thanks.

Regards,
Simon


Re: [PATCH v3 2/9] console: Keep ->start() and ->stop() balanced

2020-12-21 Thread Simon Glass
On Mon, 21 Dec 2020 at 05:30, Andy Shevchenko
 wrote:
>
> There is no need to call ->start() for already started device. All the same,
> there is no need to call ->stop() for devices still in use.
>
> For now enforce this only for IOMUX case.
>
> Cc: Simon Glass 
> Signed-off-by: Andy Shevchenko 
> ---
> v3: renamed new function and added a documentation for it
>  common/console.c | 37 +
>  1 file changed, 37 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH v3 4/9] console: rename search_device() to console_search_dev()

2020-12-21 Thread Simon Glass
On Mon, 21 Dec 2020 at 05:30, Andy Shevchenko
 wrote:
>
> Rename search_device() to console_search_dev() since it's in console.h.
>
> Suggested-by: Simon Glass 
> Signed-off-by: Andy Shevchenko 
> ---
> v3: new patch
>  common/console.c  | 18 +-
>  common/iomux.c|  4 ++--
>  common/stdio.c|  4 ++--
>  include/console.h |  2 +-
>  4 files changed, 14 insertions(+), 14 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v3 09/12] dm: test: Add test case for dev_phys_to_bus()/dev_bus_to_phys()

2020-12-21 Thread Simon Glass
Hi Nicolas,

On Mon, 21 Dec 2020 at 06:47, Nicolas Saenz Julienne
 wrote:
>
> On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> > On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
> >  wrote:
> > >
> > > By reusing DT nodes already available in sandbox's test DT introduce a
> > > test to validate dev_phys_to_bus()/dev_bus_to_phys().
> > >
> > > Signed-off-by: Nicolas Saenz Julienne 
> > > ---
> > >  test/dm/Makefile   |  1 +
> > >  test/dm/phys2bus.c | 36 
> > >  2 files changed, 37 insertions(+)
> > >  create mode 100644 test/dm/phys2bus.c
> >
> > Reviewed-by: Simon Glass 
> >
> > comment below
> >
> > >
> > > diff --git a/test/dm/Makefile b/test/dm/Makefile
> > > index 5c52d8b6ea..ac86abaa88 100644
> > > --- a/test/dm/Makefile
> > > +++ b/test/dm/Makefile
> > > @@ -16,6 +16,7 @@ obj-$(CONFIG_UT_DM) += test-uclass.o
> > >
> > >  obj-$(CONFIG_UT_DM) += core.o
> > >  obj-$(CONFIG_UT_DM) += read.o
> > > +obj-$(CONFIG_UT_DM) += phys2bus.o
> > >  ifneq ($(CONFIG_SANDBOX),)
> > >  obj-$(CONFIG_ACPIGEN) += acpi.o
> > >  obj-$(CONFIG_ACPIGEN) += acpigen.o
> > > diff --git a/test/dm/phys2bus.c b/test/dm/phys2bus.c
> > > new file mode 100644
> > > index 00..06a045c168
> > > --- /dev/null
> > > +++ b/test/dm/phys2bus.c
> > > @@ -0,0 +1,36 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (c) 2020 Nicolas Saenz Julienne 
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +static int dm_test_phys_to_bus(struct unit_test_state *uts)
> > > +{
> > > +   struct udevice *dev;
> > > +   ofnode node;
> > > +
> > > +   node = ofnode_path("/mmio-bus@0");
> > > +   ut_assert(ofnode_valid(node));
> > > +   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_BUS, node, 
> > > ));
> > > +   /* In this case it should be transparent, no dma-ranges in parent 
> > > bus */
> > > +   ut_asserteq_ptr((void*)0xfULL, (void*)dev_phys_to_bus(dev, 
> > > 0xf));
> >
> > ut_asserteq_addr() might be better here? Not sure.
>
> That function uses map_to_sysmem() under the hood, which AFAIR didn't play 
> well
> with these addresses.

Well it might be worth checking that again. This is a nop on
everything but sandbox[1]. With sandbox we actually want to print the
address as an address, not a pointer, since the address makes sense
(it is in U-Boot's memory map) but the pointer is whatever the OS
assigned the U-Boot executable.

Regards,
Simon

[1] I see Risc-V uses it to map SDRAM which seems like a bug


Re: [PATCH v3 11/12] mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys()

2020-12-21 Thread Simon Glass
Hi Nicolas,

On Mon, 21 Dec 2020 at 07:23, Nicolas Saenz Julienne
 wrote:
>
> On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> > On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
> >  wrote:
> > >
> > > This will allow us to use DM variants of phys_to_bus()/bus_to_phys()
> > > when relevant.
> > >
> > > Signed-off-by: Nicolas Saenz Julienne 
> > > ---
> > >  drivers/mmc/sdhci.c |  7 ---
> > >  include/mmc.h   | 10 ++
> > >  2 files changed, 14 insertions(+), 3 deletions(-)
> >
> > Reviewed-by: Simon Glass 
> >
> >
> > >
> > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > > index 0628934312..2086d7cdb1 100644
> > > --- a/drivers/mmc/sdhci.c
> > > +++ b/drivers/mmc/sdhci.c
> > > @@ -19,7 +19,6 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > -#include 
> > >
> > >  static void sdhci_reset(struct sdhci_host *host, u8 mask)
> > >  {
> > > @@ -103,7 +102,8 @@ static void sdhci_prepare_dma(struct sdhci_host 
> > > *host, struct mmc_data *data,
> > >   mmc_get_dma_dir(data));
> > >
> > > if (host->flags & USE_SDMA) {
> > > -   sdhci_writel(host, phys_to_bus((ulong)host->start_addr),
> > > +   sdhci_writel(host,
> > > +mmc_phys_to_bus(host->mmc, 
> > > (ulong)host->start_addr),
> > > SDHCI_DMA_ADDRESS);
> > > }
> > >  #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
> > > @@ -162,7 +162,8 @@ static int sdhci_transfer_data(struct sdhci_host 
> > > *host, struct mmc_data *data)
> > > start_addr &=
> > > ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
> > > start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
> > > -   sdhci_writel(host, 
> > > phys_to_bus((ulong)start_addr),
> > > +   sdhci_writel(host,
> > > +mmc_phys_to_bus(host->mmc, 
> > > (ulong)start_addr),
> > >  SDHCI_DMA_ADDRESS);
> > > }
> > > }
> > > diff --git a/include/mmc.h b/include/mmc.h
> > > index 1d377e0281..5fe1ef1dfc 100644
> > > --- a/include/mmc.h
> > > +++ b/include/mmc.h
> > > @@ -15,6 +15,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  struct bd_info;
> > >
> > > @@ -977,4 +978,13 @@ static inline enum dma_data_direction 
> > > mmc_get_dma_dir(struct mmc_data *data)
> > > return data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : 
> > > DMA_FROM_DEVICE;
> > >  }
> > >
> > > +static inline dma_addr_t mmc_phys_to_bus(struct mmc *mmc, phys_addr_t 
> > > addr)
> > > +{
> > > +#if CONFIG_IS_ENABLED(DM_DMA)
> >
> > if() ?
>
> Noted.
>
> > Also makes me wonder if dev_phys_to_bus() should call phys_to_bus() if
> > DM_DMA is not enabled?
>
> I'd still need some sort per-subsystem macro to cater for !DM configurations
> where the device pointer isn't defined in the controller struct. Which IMO
> isn't much of an enhancement to this approach.

We don't need to worry about non-DM for new features. In fact we don't
generally accept code that adds new features to non-DM code. It is
deprecated and slated for removal, so it just prolongs the migration.

>
> What I'd like to have is some sort of subsystem independent way of doing
> 'controller->dev' regardless of CONFIG_DM (falling back to NULL when not
> enabled). The easy way would be defining the variable regardless of CONFIG_DM,
> but I guess that isn't ideal WRT image sizes.

Well, see above!

Regards,
Simon


Re: [PATCH v2 5/7] IOMUX: Refactor iomux_doenv() in order to increase readability

2020-12-21 Thread Simon Glass
Hi Andy,

On Mon, 21 Dec 2020 at 05:03, Andy Shevchenko
 wrote:
>
> On Fri, Dec 18, 2020 at 07:29:21PM -0700, Simon Glass wrote:
> > On Wed, 16 Dec 2020 at 16:16, Andy Shevchenko
> >  wrote:
> > >
> > > Refactor iomux_doenv() a bit in order to increase readability.
> > > There is no change in code generation on x86.
>
> ...
>
> > Reviewed-by: Simon Glass 
>
> Thanks!
>
> ...
>
> > event better:
> >
> > if (temp)
>
> I didn't get this. Can you elaborate what exactly you had in mind?
> Because...
>
> > > +   temp = strchr(temp, ',');
> > > +   if (temp == NULL)
>
> ...here is a new code.

It would help if I wrote it for the new code. I just mean:

if (temp == NULL)

is better written in U-Boot as

if (!temp)


>
> > > +   break;
> > > +
> > > +   temp++;
>
>
> Since you gave Rb tag I'll leave as is for now.

Yes that's fine.

Regards,
Simon


Re: [PATCH v2 4/7] IOMUX: Preserve console list if realloc() fails

2020-12-21 Thread Simon Glass
Hi Andy,

On Mon, 21 Dec 2020 at 05:00, Andy Shevchenko
 wrote:
>
> On Fri, Dec 18, 2020 at 07:29:19PM -0700, Simon Glass wrote:
> > On Wed, 16 Dec 2020 at 16:16, Andy Shevchenko
> >  wrote:
> > >
> > > It's realloc() 101 to avoid `foo = realloc(foo, ...);` call
> > > due to getting a memory leak.
> >
> > Hmm I don't think I knew that...
>
> When you use the same variable for the source and destination in case of NULL
> the source gone.
>
> It's okay to have
>
> foo = bar;
> bar = realloc(bar, ...);
> if (bar == NULL)
> ...do something with foo if needed...

Here is man malloc on this point:

If ptr is NULL, then  the  call  is  equivalent  to  mal‐
   loc(size), for all values of size; if size is equal to zero, and ptr is
   not NULL, then the call is equivalent  to  free(ptr).

>
> But it seems it's not the case here.
>
> > Reviewed-by: Simon Glass 
>
> Thanks!

Regards,
Simon


Re: [PATCH 4/6] button: add a simple ADC-based button driver

2020-12-21 Thread Simon Glass
Hi Marek,

On Mon, 21 Dec 2020 at 02:34, Marek Szyprowski  wrote:
>
> Hi Simon,
>
> On 19.12.2020 03:28, Simon Glass wrote:
> > On Mon, 14 Dec 2020 at 04:25, Marek Szyprowski  
> > wrote:
> >> Add a simple ADC-based button driver. This driver binds to the 'adc-keys'
> >> device tree node.

I think it is best to copy it exactly as is.

Regards,
Simon


> >>
> >> Signed-off-by: Marek Szyprowski 
> >> Change-Id: I6da7101eff3ce53766d899f49f5839d728d52fb3
> >> ---
> >>   drivers/button/Kconfig  |   8 +++
> >>   drivers/button/Makefile |   1 +
> >>   drivers/button/button-adc.c | 117 
> >>   3 files changed, 126 insertions(+)
> >>   create mode 100644 drivers/button/button-adc.c
> >>
> >> diff --git a/drivers/button/Kconfig b/drivers/button/Kconfig
> >> index 6b3ec7e55de..283367f2bd3 100644
> >> --- a/drivers/button/Kconfig
> >> +++ b/drivers/button/Kconfig
> >> @@ -9,6 +9,14 @@ config BUTTON
> >>can provide access to board-specific buttons. Use of the device 
> >> tree
> >>for configuration is encouraged.
> >>
> >> +config BUTTON_ADC
> >> +   bool "Button adc"
> >> +   depends on BUTTON
> >> +   help
> >> + Enable support for buttons which are connected to ADC lines. The 
> >> ADC
> >> + driver must use driver model. Buttons are configured using the 
> >> device
> >> + tree.
> >> +
> >>   config BUTTON_GPIO
> >>  bool "Button gpio"
> >>  depends on BUTTON
> >> diff --git a/drivers/button/Makefile b/drivers/button/Makefile
> >> index fcc10ebe8db..bbd18af1494 100644
> >> --- a/drivers/button/Makefile
> >> +++ b/drivers/button/Makefile
> >> @@ -3,4 +3,5 @@
> >>   # Copyright (C) 2020 Philippe Reynes 
> >>
> >>   obj-$(CONFIG_BUTTON) += button-uclass.o
> >> +obj-$(CONFIG_BUTTON_ADC) += button-adc.o
> >>   obj-$(CONFIG_BUTTON_GPIO) += button-gpio.o
> >> diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
> >> new file mode 100644
> >> index 000..086c676c02a
> >> --- /dev/null
> >> +++ b/drivers/button/button-adc.c
> >> @@ -0,0 +1,117 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (C) 2020 Samsung Electronics Co., Ltd.
> >> + * http://www.samsung.com
> >> + * Author: Marek Szyprowski 
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> > Please check header order
> >
> > https://protect2.fireeye.com/v1/url?k=0827922c-57bcaba3-08261963-0cc47a31307c-c2add94742a708a4=1=e6ddd072-23a6-4591-9ca7-8d41aa498536=https%3A%2F%2Fwww.denx.de%2Fwiki%2FU-Boot%2FCodingStyle
> >
> >> +
> >> +struct button_adc_priv {
> >> +   struct udevice *adc;
> >> +   int channel;
> > comments
> >
> >> +};
> >> +
> >> +static enum button_state_t button_adc_get_state(struct udevice *dev)
> >> +{
> >> +   struct button_adc_priv *priv = dev_get_priv(dev);
> >> +   unsigned int val, mask;
> >> +   int ret;
> >> +
> >> +   ret = adc_start_channel(priv->adc, priv->channel);
> >> +   if (ret)
> >> +   return ret;
> >> +
> >> +   ret = adc_channel_data(priv->adc, priv->channel, );
> >> +   if (ret)
> >> +   return ret;
> >> +
> >> +   ret = adc_data_mask(priv->adc, );
> >> +   if (ret)
> >> +   return ret;
> >> +
> >> +   /* getting state is simplified a bit */
> >> +   if (ret == 0)
> >> +   return (val < mask / 2) ? BUTTON_ON : BUTTON_OFF;
> >> +
> >> +   return ret;
> >> +}
> >> +
> >> +static int button_adc_probe(struct udevice *dev)
> >> +{
> >> +   struct button_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
> >> +   struct button_adc_priv *priv = dev_get_priv(dev);
> >> +   struct ofnode_phandle_args args;
> >> +   int ret;
> >> +
> >> +   /* Ignore the top-level button node */
> >> +   if (!uc_plat->label)
> >> +   return 0;
> >> +
> >> +   ret = dev_read_phandle_with_args(dev->parent, "io-channels",
> >> +"#io-channel-cells", 0, 0, );
> >> +   if (ret)
> >> +   return ret;
> >> +
> >> +   ret = uclass_get_device_by_name(UCLASS_ADC, 
> >> ofnode_get_name(args.node),
> >> +   >adc);
> > How about uclass_get_device_by_ofnode() ?
> >
> >> +   if (ret)
> >> +   return ret;
> >> +
> >> +   priv->channel = args.args[0];
> >> +
> >> +   return ret;
> >> +}
> >> +
> >> +static int button_adc_bind(struct udevice *parent)
> >> +{
> >> +   struct udevice *dev;
> >> +   ofnode node;
> >> +   int ret;
> >> +
> >> +   dev_for_each_subnode(node, parent) {
> >> +   struct button_uc_plat *uc_plat;
> >> +   const char *label;
> >> +
> >> +   label = ofnode_read_string(node, "label");
> >> +   if (!label) {
> >> +   debug("%s: node %s has no label\n", __func__,
> 

[PATCH] power: pmic: add driver for Monolithic Power mp5416

2020-12-21 Thread Tim Harvey
This adds basic register access and child regulator binding
for the Monolithic MP5416 Power Management IC which integrates
four DC/DC switching converters and five LDO regulators.

Signed-off-by: Tim Harvey 
---
 drivers/power/pmic/Kconfig  | 15 +++
 drivers/power/pmic/Makefile |  1 +
 drivers/power/pmic/mp5416.c | 98 +
 include/power/mp5416.h  | 41 +++
 4 files changed, 155 insertions(+)
 create mode 100644 drivers/power/pmic/mp5416.c
 create mode 100644 include/power/mp5416.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index a62aa38..13a9cb0 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -91,6 +91,21 @@ config DM_PMIC_FAN53555
  The driver implements read/write operations for use with the FAN53555
  regulator driver and binds the regulator driver to its node.
 
+config DM_PMIC_MP5416
+   bool "Enable Driver Model for PMIC MP5416"
+   depends on DM_PMIC
+   help
+ This config enables implementation of driver-model pmic uclass 
features
+ for PMIC MP5416. The driver implements read/write operations.
+
+config SPL_DM_PMIC_MP5416
+   bool "Enable Driver Model for PMIC MP5416 in SPL stage"
+   depends on DM_PMIC
+   help
+ This config enables implementation of driver-model pmic uclass
+ features for PMIC MP5416. The driver implements read/write
+ operations.
+
 config DM_PMIC_PCA9450
bool "Enable Driver Model for PMIC PCA9450"
depends on DM_PMIC
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 9cd6c37..2b2a6dd 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
 obj-$(CONFIG_DM_PMIC_MAX8998) += max8998.o
 obj-$(CONFIG_DM_PMIC_MC34708) += mc34708.o
 obj-$(CONFIG_$(SPL_)DM_PMIC_BD71837) += bd71837.o
+obj-$(CONFIG_$(SPL_)DM_PMIC_MP5416) += mp5416.o
 obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
 obj-$(CONFIG_$(SPL_)DM_PMIC_PCA9450) += pca9450.o
 obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
diff --git a/drivers/power/pmic/mp5416.c b/drivers/power/pmic/mp5416.c
new file mode 100644
index 000..458c4df
--- /dev/null
+++ b/drivers/power/pmic/mp5416.c
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier:  GPL-2.0+
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct pmic_child_info pmic_children_info[] = {
+   /* buck */
+   { .prefix = "b", .driver = MP6416_REGULATOR_DRIVER },
+   /* ldo */
+   { .prefix = "l", .driver = MP6416_REGULATOR_DRIVER },
+   { },
+};
+
+static int mp5416_reg_count(struct udevice *dev)
+{
+   return MP5416_NUM_OF_REGS - 1;
+}
+
+static int mp5416_write(struct udevice *dev, uint reg, const uint8_t *buff,
+   int len)
+{
+   if (dm_i2c_write(dev, reg, buff, len)) {
+   pr_err("write error to device: %p register: %#x!", dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int mp5416_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   if (dm_i2c_read(dev, reg, buff, len)) {
+   pr_err("read error from device: %p register: %#x!", dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int mp5416_bind(struct udevice *dev)
+{
+   int children;
+   ofnode regulators_node;
+
+   debug("%s %s\n", __func__, dev->name);
+   regulators_node = dev_read_subnode(dev, "regulators");
+   if (!ofnode_valid(regulators_node)) {
+   debug("%s: %s regulators subnode not found!\n", __func__,
+ dev->name);
+   return -ENXIO;
+   }
+
+   debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
+
+   children = pmic_bind_children(dev, regulators_node, pmic_children_info);
+   if (!children)
+   debug("%s: %s - no child found\n", __func__, dev->name);
+
+   /* Always return success for this device */
+   return 0;
+}
+
+static int mp5416_probe(struct udevice *dev)
+{
+   debug("%s %s\n", __func__, dev->name);
+
+   return 0;
+}
+
+static struct dm_pmic_ops mp5416_ops = {
+   .reg_count = mp5416_reg_count,
+   .read = mp5416_read,
+   .write = mp5416_write,
+};
+
+static const struct udevice_id mp5416_ids[] = {
+   { .compatible = "mps,mp5416", },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_mp5416) = {
+   .name = "mp5416 pmic",
+   .id = UCLASS_PMIC,
+   .of_match = mp5416_ids,
+   .bind = mp5416_bind,
+   .probe = mp5416_probe,
+   .ops = _ops,
+};
diff --git a/include/power/mp5416.h b/include/power/mp5416.h
new file mode 100644
index 000..dc096fe
--- /dev/null
+++ b/include/power/mp5416.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */

Re: [PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()

2020-12-21 Thread Richard Genoud

Hi Miquel

Le 21/12/2020 à 16:49, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
16:40:51 +0100:


Hi Miquel,

Le 21/12/2020 à 16:29, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
16:26:00 +0100:
   

Le 21/12/2020 à 16:14, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
16:06:37 +0100:
 Hi Miquel,


Le 18/12/2020 à 19:50, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Fri, 18 Dec 2020
15:24:40 +0100:
  token_count may be != 0 and token_list not yet allocated when the out

code is reached


Wouldn't it be better to initialize token_count than adding an
(obscure) indentation level?

Well, token_count is initialized :
token_count = sqfs_count_tokens(filename);

But token_list is not yet populated. It is some lines bellow:
token_list = malloc(token_count * sizeof(char *));


But I could use something like that, maybe it's clearer :
for (j = 0; (token_list != NULL) && (j < token_count); j++)
free(token_list[j]);


I had a look at the code, the error path is clearly not correctly
organized.

I think the right approach would be to have real labels like,
free_token_list, free_this, free_that and for each of them only do the
right cleanup. Doing so should fix the issue.


So you're suggesting to revert this ?
commit ea1b1651c6a8 ("fs/squashfs: sqfs_opendir: simplify error handling")


Yes (our e-mails crossed each other), I think it's best to have a well
organized error path. Of course this error path is maybe faulty, in
this case it must be fixed. But I personally prefer the revert + fix
approach.
   


But I really don't see why it's obscure to test a pointer before dereference.


Testing a pointer before dereference is not obscure.

Testing a pointer in an error path because the error path is common to
all 10 different possible failure cases and might free the content of an
array that has not been allocated yet: this is obscure.


Maybe I should I've wrote :
 if (token_list != NULL)
 for (j = 0; j < token_count; j++)
 free(token_list[j]);

Does it looks better ?


Not really :)


Ok, so if you insist, I send the revert correcting the coverity issue.

But in this case, the error management won't be coherent with the rest of the 
file.
(And I *really* don't want to revert to the old error handling for every single 
function.)


Richard.


Re: [PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()

2020-12-21 Thread Miquel Raynal
Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
16:40:51 +0100:

> Hi Miquel,
> 
> Le 21/12/2020 à 16:29, Miquel Raynal a écrit :
> > Hi Richard,
> > 
> > Richard Genoud  wrote on Mon, 21 Dec 2020
> > 16:26:00 +0100:
> >   
> >> Le 21/12/2020 à 16:14, Miquel Raynal a écrit :  
> >>> Hi Richard,
> >>>
> >>> Richard Genoud  wrote on Mon, 21 Dec 2020
> >>> 16:06:37 +0100:  
> >>> Hi Miquel,  
> 
>  Le 18/12/2020 à 19:50, Miquel Raynal a écrit :  
> > Hi Richard,
> >
> > Richard Genoud  wrote on Fri, 18 Dec 2020
> > 15:24:40 +0100:  
> >  token_count may be != 0 and token_list not yet allocated when 
> > the out  
> >> code is reached  
> >
> > Wouldn't it be better to initialize token_count than adding an
> > (obscure) indentation level?  
>  Well, token_count is initialized :
>  token_count = sqfs_count_tokens(filename);
> 
>  But token_list is not yet populated. It is some lines bellow:
>  token_list = malloc(token_count * sizeof(char *));
> 
> 
>  But I could use something like that, maybe it's clearer :
>   for (j = 0; (token_list != NULL) && (j < token_count); j++)
>   free(token_list[j]);  
> >>>
> >>> I had a look at the code, the error path is clearly not correctly
> >>> organized.
> >>>
> >>> I think the right approach would be to have real labels like,
> >>> free_token_list, free_this, free_that and for each of them only do the
> >>> right cleanup. Doing so should fix the issue.  
> >>
> >> So you're suggesting to revert this ?
> >> commit ea1b1651c6a8 ("fs/squashfs: sqfs_opendir: simplify error handling") 
> >>  
> > 
> > Yes (our e-mails crossed each other), I think it's best to have a well
> > organized error path. Of course this error path is maybe faulty, in
> > this case it must be fixed. But I personally prefer the revert + fix
> > approach.
> >   
> 
> But I really don't see why it's obscure to test a pointer before dereference.

Testing a pointer before dereference is not obscure.

Testing a pointer in an error path because the error path is common to
all 10 different possible failure cases and might free the content of an
array that has not been allocated yet: this is obscure.

> Maybe I should I've wrote :
> if (token_list != NULL)
> for (j = 0; j < token_count; j++)
> free(token_list[j]);
> 
> Does it looks better ?

Not really :)


Thanks,
Miquèl


Re: [PATCH 2/3] dts: am654-base-board-uboot: Set USB0 dr_mode to host

2020-12-21 Thread Aswath Govindraju
On 21/12/20 8:42 pm, Lokesh Vutla wrote:
> 
> 
> On 20/11/20 9:18 pm, Aswath Govindraju wrote:
>> USB3SS0 controller is to be used as a host in U-boot. Fix it by changing
>> the dr_mode to host.
>>
>> Signed-off-by: Aswath Govindraju 
> 
> Won't it break dfu support or is it used in different controller?
> 
It is used in a different controller. The port on the base board is used
for dfu and and the port on the overlay board is used for host mode.

Thanks,
Aswath

> 
>> ---
>>  arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
>> b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
>> index d75d1b1c285a..bd2f334c2b50 100644
>> --- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
>> +++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
>> @@ -270,7 +270,7 @@
>>   {
>>  pinctrl-names = "default";
>>  pinctrl-0 = <_pins_default>;
>> -dr_mode = "peripheral";
>> +dr_mode = "host";
>>  u-boot,dm-spl;
>>  };
>>  
>>



Re: [PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()

2020-12-21 Thread Richard Genoud

Hi Miquel,

Le 21/12/2020 à 16:29, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
16:26:00 +0100:


Le 21/12/2020 à 16:14, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
16:06:37 +0100:
   

Hi Miquel,

Le 18/12/2020 à 19:50, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Fri, 18 Dec 2020
15:24:40 +0100:
 token_count may be != 0 and token_list not yet allocated when the out

code is reached


Wouldn't it be better to initialize token_count than adding an
(obscure) indentation level?

Well, token_count is initialized :
token_count = sqfs_count_tokens(filename);

But token_list is not yet populated. It is some lines bellow:
token_list = malloc(token_count * sizeof(char *));


But I could use something like that, maybe it's clearer :
for (j = 0; (token_list != NULL) && (j < token_count); j++)
free(token_list[j]);


I had a look at the code, the error path is clearly not correctly
organized.

I think the right approach would be to have real labels like,
free_token_list, free_this, free_that and for each of them only do the
right cleanup. Doing so should fix the issue.


So you're suggesting to revert this ?
commit ea1b1651c6a8 ("fs/squashfs: sqfs_opendir: simplify error handling")


Yes (our e-mails crossed each other), I think it's best to have a well
organized error path. Of course this error path is maybe faulty, in
this case it must be fixed. But I personally prefer the revert + fix
approach.



But I really don't see why it's obscure to test a pointer before dereference.
Maybe I should I've wrote :
   if (token_list != NULL)
   for (j = 0; j < token_count; j++)
   free(token_list[j]);

Does it looks better ?


Thanks,
Miquèl


Thanks!


Re: [PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()

2020-12-21 Thread Miquel Raynal
Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
16:26:00 +0100:

> Le 21/12/2020 à 16:14, Miquel Raynal a écrit :
> > Hi Richard,
> > 
> > Richard Genoud  wrote on Mon, 21 Dec 2020
> > 16:06:37 +0100:
> >   
> >> Hi Miquel,
> >>
> >> Le 18/12/2020 à 19:50, Miquel Raynal a écrit :  
> >>> Hi Richard,
> >>>
> >>> Richard Genoud  wrote on Fri, 18 Dec 2020
> >>> 15:24:40 +0100:  
> >>> token_count may be != 0 and token_list not yet allocated when the 
> >>> out  
>  code is reached  
> >>>
> >>> Wouldn't it be better to initialize token_count than adding an
> >>> (obscure) indentation level?  
> >> Well, token_count is initialized :
> >> token_count = sqfs_count_tokens(filename);
> >>
> >> But token_list is not yet populated. It is some lines bellow:
> >> token_list = malloc(token_count * sizeof(char *));
> >>
> >>
> >> But I could use something like that, maybe it's clearer :
> >>for (j = 0; (token_list != NULL) && (j < token_count); j++)
> >>free(token_list[j]);  
> > 
> > I had a look at the code, the error path is clearly not correctly
> > organized.
> > 
> > I think the right approach would be to have real labels like,
> > free_token_list, free_this, free_that and for each of them only do the
> > right cleanup. Doing so should fix the issue.  
> 
> So you're suggesting to revert this ?
> commit ea1b1651c6a8 ("fs/squashfs: sqfs_opendir: simplify error handling")

Yes (our e-mails crossed each other), I think it's best to have a well
organized error path. Of course this error path is maybe faulty, in
this case it must be fixed. But I personally prefer the revert + fix
approach.

Thanks,
Miquèl


Re: [PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()

2020-12-21 Thread Miquel Raynal


Miquel Raynal  wrote on Mon, 21 Dec 2020
16:14:19 +0100:

> Hi Richard,
> 
> Richard Genoud  wrote on Mon, 21 Dec 2020
> 16:06:37 +0100:
> 
> > Hi Miquel,
> > 
> > Le 18/12/2020 à 19:50, Miquel Raynal a écrit :  
> > > Hi Richard,
> > > 
> > > Richard Genoud  wrote on Fri, 18 Dec 2020
> > > 15:24:40 +0100:
> > > 
> > >> token_count may be != 0 and token_list not yet allocated when the out
> > >> code is reached
> > > 
> > > Wouldn't it be better to initialize token_count than adding an
> > > (obscure) indentation level?
> > Well, token_count is initialized :
> > token_count = sqfs_count_tokens(filename);
> > 
> > But token_list is not yet populated. It is some lines bellow:
> > token_list = malloc(token_count * sizeof(char *));
> > 
> > 
> > But I could use something like that, maybe it's clearer :
> > for (j = 0; (token_list != NULL) && (j < token_count); j++)
> > free(token_list[j]);  
> 
> I had a look at the code, the error path is clearly not correctly
> organized.
> 
> I think the right approach would be to have real labels like,
> free_token_list, free_this, free_that and for each of them only do the
> right cleanup. Doing so should fix the issue.

Actually I remember now: I disliked your proposal of changing all
named labels to a single (and quite unclear) "goto out". This is an
example of why single labels should not be used IMHO.

Thanks,
Miquèl


Re: [PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()

2020-12-21 Thread Richard Genoud

Le 21/12/2020 à 16:14, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
16:06:37 +0100:


Hi Miquel,

Le 18/12/2020 à 19:50, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Fri, 18 Dec 2020
15:24:40 +0100:
   

token_count may be != 0 and token_list not yet allocated when the out
code is reached


Wouldn't it be better to initialize token_count than adding an
(obscure) indentation level?

Well, token_count is initialized :
token_count = sqfs_count_tokens(filename);

But token_list is not yet populated. It is some lines bellow:
token_list = malloc(token_count * sizeof(char *));


But I could use something like that, maybe it's clearer :
for (j = 0; (token_list != NULL) && (j < token_count); j++)
free(token_list[j]);


I had a look at the code, the error path is clearly not correctly
organized.

I think the right approach would be to have real labels like,
free_token_list, free_this, free_that and for each of them only do the
right cleanup. Doing so should fix the issue.


So you're suggesting to revert this ?
commit ea1b1651c6a8 ("fs/squashfs: sqfs_opendir: simplify error handling")



Thanks,
Miquèl



Re: [PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()

2020-12-21 Thread Miquel Raynal
Hi Richard,

Richard Genoud  wrote on Mon, 21 Dec 2020
16:06:37 +0100:

> Hi Miquel,
> 
> Le 18/12/2020 à 19:50, Miquel Raynal a écrit :
> > Hi Richard,
> > 
> > Richard Genoud  wrote on Fri, 18 Dec 2020
> > 15:24:40 +0100:
> >   
> >> token_count may be != 0 and token_list not yet allocated when the out
> >> code is reached  
> > 
> > Wouldn't it be better to initialize token_count than adding an
> > (obscure) indentation level?  
> Well, token_count is initialized :
> token_count = sqfs_count_tokens(filename);
> 
> But token_list is not yet populated. It is some lines bellow:
> token_list = malloc(token_count * sizeof(char *));
> 
> 
> But I could use something like that, maybe it's clearer :
>   for (j = 0; (token_list != NULL) && (j < token_count); j++)
>   free(token_list[j]);

I had a look at the code, the error path is clearly not correctly
organized.

I think the right approach would be to have real labels like,
free_token_list, free_this, free_that and for each of them only do the
right cleanup. Doing so should fix the issue.

Thanks,
Miquèl


Re: [PATCH 2/3] dts: am654-base-board-uboot: Set USB0 dr_mode to host

2020-12-21 Thread Lokesh Vutla



On 20/11/20 9:18 pm, Aswath Govindraju wrote:
> USB3SS0 controller is to be used as a host in U-boot. Fix it by changing
> the dr_mode to host.
> 
> Signed-off-by: Aswath Govindraju 

Won't it break dfu support or is it used in different controller?

Thanks and regards,
Lokesh

> ---
>  arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
> b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> index d75d1b1c285a..bd2f334c2b50 100644
> --- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> @@ -270,7 +270,7 @@
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins_default>;
> - dr_mode = "peripheral";
> + dr_mode = "host";
>   u-boot,dm-spl;
>  };
>  
> 


Re: [PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()

2020-12-21 Thread Richard Genoud

Hi Miquel,

Le 18/12/2020 à 19:50, Miquel Raynal a écrit :

Hi Richard,

Richard Genoud  wrote on Fri, 18 Dec 2020
15:24:40 +0100:


token_count may be != 0 and token_list not yet allocated when the out
code is reached


Wouldn't it be better to initialize token_count than adding an
(obscure) indentation level?

Well, token_count is initialized :
token_count = sqfs_count_tokens(filename);

But token_list is not yet populated. It is some lines bellow:
token_list = malloc(token_count * sizeof(char *));


But I could use something like that, maybe it's clearer :
for (j = 0; (token_list != NULL) && (j < token_count); j++)
free(token_list[j]);





Reported-by: Coverity CID 313547
Fixes: ea1b1651c6a8 ("fs/squashfs: sqfs_opendir: simplify error handling")
Signed-off-by: Richard Genoud 
---
  fs/squashfs/sqfs.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 608a2bb454c..c47046b76e5 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -949,8 +949,9 @@ int sqfs_opendir(const char *filename, struct fs_dir_stream 
**dirsp)
*dirsp = (struct fs_dir_stream *)dirs;
  
  out:

-   for (j = 0; j < token_count; j++)
-   free(token_list[j]);
+   if (token_list)
+   for (j = 0; j < token_count; j++)
+   free(token_list[j]);
free(token_list);
free(pos_list);
free(path);


Thanks,
Miquèl


Thanks
Richard.


Re: [linux-sunxi] [PATCH] sunxi: Add arm64 FEL support

2020-12-21 Thread Priit Laes
On Thu, Nov 19, 2020 at 10:54:42AM +, Andre Przywara wrote:
> So far we did not support the BootROM based FEL USB debug mode on the
> 64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but the
> SPL runs in AArch64.
> Returning back to AArch32 was not working as expected, since the RMR
> reset into 32-bit mode always starts execution in the BootROM, but not
> in the FEL routine.
> 
> After some debug and research and with help via IRC, the CPU hotplug
> mechanism emerged as a solution: If a certain R_CPUCFG register contains
> some magic, the BootROM will immediately branch to an address stored in
> some other register. This works well for our purposes.
> 
> Enable the FEL feature by providing early AArch32 code to first save the
> FEL state, *before* initially entering AArch64.
> If we eventually determine that we should return to FEL, we reset back
> into AArch32, and use the CPU hotplug mechanism to run some small
> AArch32 code snippet that restores the initially saved FEL state.
> 
> That allows the normal AArch64 SPL build to be loaded via the sunxi-fel
> tool, with it returning into FEL mode, so that other payloads can be
> transferred via FEL as well.
> 
> Tested on A64, H5 and H6.

For A64 (on Olimex A64-Olinuxino):
Tested-by: Priit Laes 

Also writing down the command to run as it was not that obvious:

$ sunxi-fel spl sunxi-spl.bin \
write 0x4a00 u-boot.bin \
write 0x44000 bl31.bin \
write 0x5 scp.bin \
reset64 0x44000

> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/cpu/armv8/Makefile |  2 +
>  arch/arm/cpu/armv8/fel_utils.S  | 78 +
>  arch/arm/include/asm/arch-sunxi/boot0.h | 14 +
>  include/configs/sunxi-common.h  |  2 -
>  4 files changed, 94 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/cpu/armv8/fel_utils.S
> 
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index 93d26f98568..f7b4a5ee46c 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -27,6 +27,8 @@ obj-$(CONFIG_ARM_SMCCC) += smccc-call.o
>  
>  ifndef CONFIG_SPL_BUILD
>  obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o spin_table_v8.o
> +else
> +obj-$(CONFIG_ARCH_SUNXI) += fel_utils.o
>  endif
>  obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o 
> sec_firmware_asm.o
>  
> diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
> new file mode 100644
> index 000..334fdef7fa0
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/fel_utils.S
> @@ -0,0 +1,78 @@
> +/*
> + * Utility functions for FEL mode, when running SPL in AArch64.
> + *
> + * Copyright (c) 2017 Arm Ltd.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * We don't overwrite save_boot_params() here, to save the FEL state upon
> + * entry, since this would run *after* the RMR reset, which clobbers that
> + * state.
> + * Instead we store the state _very_ early in the boot0 hook, *before*
> + * resetting to AArch64.
> + */
> +
> +/*
> + * The FEL routines in BROM run in AArch32.
> + * Reset back into 32-bit mode here and restore the saved FEL state
> + * afterwards.
> + * Resetting back into AArch32/EL3 using the RMR always enters the BROM,
> + * but we can use the CPU hotplug mechanism to branch back to our code
> + * immediately.
> + */
> +ENTRY(return_to_fel)
> + /*
> +  * the RMR reset will clear all registers, so save the arguments
> +  * (LR and SP) in the fel_stash structure, which we read anyways later
> +  */
> + adr x2, fel_stash
> + str w0, [x2]
> + str w1, [x2, #4]
> +
> + adr x1, fel_stash_addr  // to find the fel_stash address in AA32
> + str w2, [x1]
> +
> + ldr x0, =0xfa50392f // CPU hotplug magic
> +#ifndef CONFIG_MACH_SUN50I_H6
> + ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU hotplug base
> + str w0, [x2, #0x8]
> +#else
> + ldr x2, =(SUNXI_RTC_BASE + 0x1b8)   // BOOT_CPU_HP_FLAG_REG
> + str w0, [x2], #0x4
> +#endif
> + adr x0, back_in_32
> + str w0, [x2]
> +
> + dsb sy
> + isb sy
> + mov x0, #2  // RMR reset into AArch32
> + dsb sy
> + msr RMR_EL3, x0
> + isb sy
> +1:   wfi
> + b   1b
> +
> +/* AArch32 code to restore the state from fel_stash and return back to FEL. 
> */
> +back_in_32:
> + .word   0xe59f0028  // ldr  r0, [pc, #40]   ; load fel_stash address
> + .word   0xe5901008  // ldr  r1, [r0, #8]
> + .word   0xe129f001  // msr  CPSR_fc, r1
> + .word   0xf57ff06f  // isb
> + .word   0xe590d000  // ldr  sp, [r0]
> + .word   0xe590e004  // ldr  lr, [r0, #4]
> + .word   0xe5901010  // ldr  r1, [r0, #16]
> + .word   0xee0c1f10  // mcr  15, 0, r1, cr12, cr0, {0} ; VBAR
> + .word   

Re: [PATCH v3 11/12] mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys()

2020-12-21 Thread Nicolas Saenz Julienne
On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
>  wrote:
> > 
> > This will allow us to use DM variants of phys_to_bus()/bus_to_phys()
> > when relevant.
> > 
> > Signed-off-by: Nicolas Saenz Julienne 
> > ---
> >  drivers/mmc/sdhci.c |  7 ---
> >  include/mmc.h   | 10 ++
> >  2 files changed, 14 insertions(+), 3 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> 
> > 
> > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > index 0628934312..2086d7cdb1 100644
> > --- a/drivers/mmc/sdhci.c
> > +++ b/drivers/mmc/sdhci.c
> > @@ -19,7 +19,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > 
> >  static void sdhci_reset(struct sdhci_host *host, u8 mask)
> >  {
> > @@ -103,7 +102,8 @@ static void sdhci_prepare_dma(struct sdhci_host *host, 
> > struct mmc_data *data,
> >   mmc_get_dma_dir(data));
> > 
> > if (host->flags & USE_SDMA) {
> > -   sdhci_writel(host, phys_to_bus((ulong)host->start_addr),
> > +   sdhci_writel(host,
> > +mmc_phys_to_bus(host->mmc, 
> > (ulong)host->start_addr),
> > SDHCI_DMA_ADDRESS);
> > }
> >  #if CONFIG_IS_ENABLED(MMC_SDHCI_ADMA)
> > @@ -162,7 +162,8 @@ static int sdhci_transfer_data(struct sdhci_host *host, 
> > struct mmc_data *data)
> > start_addr &=
> > ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
> > start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
> > -   sdhci_writel(host, 
> > phys_to_bus((ulong)start_addr),
> > +   sdhci_writel(host,
> > +mmc_phys_to_bus(host->mmc, 
> > (ulong)start_addr),
> >  SDHCI_DMA_ADDRESS);
> > }
> > }
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 1d377e0281..5fe1ef1dfc 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -15,6 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > 
> >  struct bd_info;
> > 
> > @@ -977,4 +978,13 @@ static inline enum dma_data_direction 
> > mmc_get_dma_dir(struct mmc_data *data)
> > return data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : 
> > DMA_FROM_DEVICE;
> >  }
> > 
> > +static inline dma_addr_t mmc_phys_to_bus(struct mmc *mmc, phys_addr_t addr)
> > +{
> > +#if CONFIG_IS_ENABLED(DM_DMA)
> 
> if() ?

Noted.

> Also makes me wonder if dev_phys_to_bus() should call phys_to_bus() if
> DM_DMA is not enabled?

I'd still need some sort per-subsystem macro to cater for !DM configurations
where the device pointer isn't defined in the controller struct. Which IMO
isn't much of an enhancement to this approach.

What I'd like to have is some sort of subsystem independent way of doing
'controller->dev' regardless of CONFIG_DM (falling back to NULL when not
enabled). The easy way would be defining the variable regardless of CONFIG_DM,
but I guess that isn't ideal WRT image sizes.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part


Re: imx8mp_evk: boot error "alloc space exhausted"

2020-12-21 Thread Fabio Estevam
Hi Andrey and Peng,

On Thu, Dec 17, 2020 at 9:51 AM ZHIZHIKIN Andrey
 wrote:
>
> Hello Peng,
>
> Just a gentle ping here: can you take a look at the failure reported below?
>
> I've also added Alice Guo since there was some work done om imx8mp_evk board,
> and uboot-imx list here.
>
> Thanks a lot!

I have also tried using the ATF version imx_5.4.70_2.3.0 and the DDR
firmware from the firmware-5.10 package, but still does not boot for
me:

U-Boot SPL 2021.01-rc3-00200-ge668bec96a5f-dirty (Dec 21 2020 - 11:13:56 -0300)
Normal Boot
WDT:   Started with servicing (60s timeout)
Trying to boot from BOOTROM
image offset 0x8000, pagesize 0x200, ivt offset 0x0

It would be great to have this fixed for the upcoming 2021.01 release.

Thanks


Re: [BUG]odroid-c2 does not hotplug usb-devices

2020-12-21 Thread Anand Moon
Hi Martin,

On Sun, 20 Dec 2020 at 20:04, Martin Blumenstingl
 wrote:
>
> Hi Anand,
>
> On Sun, Dec 20, 2020 at 2:46 PM Anand Moon  wrote:
> [...]
> > > On Sat, Dec 19, 2020 at 8:53 PM Anand Moon  wrote:
> > > [...]
> > > > I was also looking into this issue so I made some changes in the
> > > > phy driver to resolve the issue. Plz share your thoughts on the changes 
> > > > below.
> > > first I have some questions :-)
> > > 1. do you see the same problem that Otto sees? this means: a) USB
> > > hotplug works as long as at least one device is plugged in at boot b)
> > > (if I understand Otto correctly then) it breaks once all USB devices
> > > have been removed
> >
> > On C1/C2 issue is when single usb hdd is connected to board it will
> > not get detected.
> > unless you connect another usb keyboard or wireless dongle to the board.
> >
> > *USB hot plug only works if two ore more usb devices are connected.*
> I am not sure if that's really the same issue as described by Otto
>
OK.
> [...]
> > > > amoon@ThinkPad-T440s:~/mainline/linux-aml-5.y-devel$ git diff
> > > > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > > > b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > > > index 7c029f552a23..363dd2ac17e6 100644
> > > > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > > > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > > > @@ -20,6 +20,7 @@ usb0_phy: phy@c000 {
> > > > #phy-cells = <0>;
> > > > reg = <0x0 0xc000 0x0 0x20>;
> > > > resets = < RESET_USB_OTG>;
> > > > +   reset-names = "phy-reset";
> > > > clocks = < CLKID_USB>, < CLKID_USB0>;
> > > > clock-names = "usb_general", "usb";
> > > > status = "disabled";
> > > > @@ -30,6 +31,7 @@ usb1_phy: phy@c020 {
> > > > #phy-cells = <0>;
> > > > reg = <0x0 0xc020 0x0 0x20>;
> > > > resets = < RESET_USB_OTG>;
> > > > +   reset-names = "phy-reset";
> > > > clocks = < CLKID_USB>, < CLKID_USB1>;
> > > > clock-names = "usb_general", "usb";
> > > > status = "disabled";
> > > I don't see why the above two changes are needed
> > > see my comment about of_reset_control_get_shared below
> > >
> >
> > Yep I borrowed this logic from rockchip usb phy controller.
> > but I missed the action on reset.
> >
> > err = devm_add_action_or_reset(base->dev, rockchip_usb_phy_action,  rk_phy);
> > if (err)
> > return err;
> (assuming that your comment relates to the of_reset_control_get_shared
> call below)
> I checked rockchip_usb_phy_action and it's not calling reset_control_put 
> either
> this looks strange to me and I would say that there's a memory leak.
>
Ok, I will try to check this, my approach was just to get the reset code
to get trigger, but is seem that it is not getting triggered,

> [...]
> > > >  static const struct phy_ops phy_meson8b_usb2_ops = {
> > > > .power_on   = phy_meson8b_usb2_power_on,
> > > > .power_off  = phy_meson8b_usb2_power_off,
> > > > +   .reset  = phy_meson8b_usb2_reset,
> > > > .owner  = THIS_MODULE,
> > > >  };
> > > I tested this on my Odroid-C1: phy_meson8b_usb2_reset is never called
> > > after checking the dwc2 code this is expected: only in one very
> > > specific case the dwc2 driver calls phy_reset
> > > can you please find out how phy_meson8b_usb2_reset is called in your 
> > > kernel?
> > >
> >
> > Yep, Its not getting called on my board, l might be missing some thing.
> are you sure that your patch fixes USB hotplug for you?
>
> the new reset callback is a no-op because it's not called
> the code below (of_reset_control_get_shared) only fetches the same
> reset line that we are already using
> so I am not sure what changed behavior you are seeing - can you please
> explain this in more detail?

I am looking into the phy-meson-gxl-usb2.c and I will try to model these changes
and see if it works on my boards.

Thanks
-Anand

>
> > > > @@ -271,6 +277,10 @@ static int phy_meson8b_usb2_probe(struct
> > > > platform_device *pdev)
> > > > return -EINVAL;
> > > > }
> > > >
> > > > +   priv->reset = of_reset_control_get_shared(pdev->dev.of_node,
> > > > "phy-reset");
> > > this causes a memory-leak upon driver removal
> > > also a few lines above we are already getting the reset line, so why
> > > is this needed?
> >
> > I had a feeling that USB_OTG reset will be shared between both the phy
> > controller.
> indeed, the USB_OTG reset is shared
>
> > Odroid C2 reset controller have additional RESET_USB_DDR_[0,3] reset,
> > but Odroid C1 dose not have this feature.
> have you found where the patched Amlogic kernel/u-boot use these reset lines?
> if they need to be managed by us then we probably have a bug, 

Re: [PATCH v3 10/12] xhci: translate virtual addresses into the bus's address space

2020-12-21 Thread Nicolas Saenz Julienne
On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> Hi Nicolas,
> 
> On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
>  wrote:
> > 
> > So far we've been content with passing physical addresses when
> > configuring memory addresses into XHCI controllers, but not all
> > platforms have buses with transparent mappings. Specifically the
> > Raspberry Pi 4 might introduce an offset to memory accesses incoming
> > from its PCIe port.
> > 
> > Introduce xhci_virt_to_bus() and xhci_bus_to_virt() to cater with these
> > limitations, and make sure we don't break non DM users.
> > 
> > Signed-off-by: Nicolas Saenz Julienne 
> > ---
> >  drivers/usb/host/xhci-mem.c  | 45 +++-
> >  drivers/usb/host/xhci-ring.c | 11 +
> >  drivers/usb/host/xhci.c  |  4 ++--
> >  include/usb/xhci.h   | 22 +-
> >  4 files changed, 54 insertions(+), 28 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> nits below
> 
> [..]
> 
> > diff --git a/include/usb/xhci.h b/include/usb/xhci.h
> > index e1d382369a..b87210b9ba 100644
> > --- a/include/usb/xhci.h
> > +++ b/include/usb/xhci.h
> > @@ -16,6 +16,7 @@
> >  #ifndef HOST_XHCI_H_
> >  #define HOST_XHCI_H_
> > 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1250,7 +1251,8 @@ int xhci_check_maxpacket(struct usb_device *udev);
> >  void xhci_flush_cache(uintptr_t addr, u32 type_len);
> >  void xhci_inval_cache(uintptr_t addr, u32 type_len);
> >  void xhci_cleanup(struct xhci_ctrl *ctrl);
> > -struct xhci_ring *xhci_ring_alloc(unsigned int num_segs, bool link_trbs);
> > +struct xhci_ring *xhci_ring_alloc(struct xhci_ctrl *ctrl, unsigned int 
> > num_segs,
> > + bool link_trbs);
> 
> Can you please add a comment while you are here?

The comment is in the xhci-mem.c. Should I move it here?

> >  int xhci_alloc_virt_device(struct xhci_ctrl *ctrl, unsigned int slot_id);
> >  int xhci_mem_init(struct xhci_ctrl *ctrl, struct xhci_hccr *hccr,
> >   struct xhci_hcor *hcor);
> > @@ -1278,4 +1280,22 @@ extern struct dm_usb_ops xhci_usb_ops;
> > 
> >  struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
> > 
> > +static inline dma_addr_t xhci_virt_to_bus(struct xhci_ctrl *ctrl, void 
> > *addr)
> > +{
> > +#if CONFIG_IS_ENABLED(DM_DMA)
> 
> Can this use if() ?

Yes, will do.

> > +   return dev_phys_to_bus(ctrl->dev, virt_to_phys(addr));
> > +#else
> > +   return phys_to_bus(virt_to_phys(addr));
> > +#endif
> > +}
> > +
> > +static inline void *xhci_bus_to_virt(struct xhci_ctrl *ctrl, dma_addr_t 
> > addr)
> > +{
> > +#if CONFIG_IS_ENABLED(DM_DMA)
> > +   return phys_to_virt(dev_bus_to_phys(ctrl->dev, addr));
> > +#else
> > +   return phys_to_virt(bus_to_phys(addr));
> > +#endif
> > +}
> > +
> >  #endif /* HOST_XHCI_H_ */
> > --
> > 2.29.2
> > 
> 
> Regards,
> Simon





signature.asc
Description: This is a digitally signed message part


Re: [PATCH v3 09/12] dm: test: Add test case for dev_phys_to_bus()/dev_bus_to_phys()

2020-12-21 Thread Nicolas Saenz Julienne
On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
>  wrote:
> > 
> > By reusing DT nodes already available in sandbox's test DT introduce a
> > test to validate dev_phys_to_bus()/dev_bus_to_phys().
> > 
> > Signed-off-by: Nicolas Saenz Julienne 
> > ---
> >  test/dm/Makefile   |  1 +
> >  test/dm/phys2bus.c | 36 
> >  2 files changed, 37 insertions(+)
> >  create mode 100644 test/dm/phys2bus.c
> 
> Reviewed-by: Simon Glass 
> 
> comment below
> 
> > 
> > diff --git a/test/dm/Makefile b/test/dm/Makefile
> > index 5c52d8b6ea..ac86abaa88 100644
> > --- a/test/dm/Makefile
> > +++ b/test/dm/Makefile
> > @@ -16,6 +16,7 @@ obj-$(CONFIG_UT_DM) += test-uclass.o
> > 
> >  obj-$(CONFIG_UT_DM) += core.o
> >  obj-$(CONFIG_UT_DM) += read.o
> > +obj-$(CONFIG_UT_DM) += phys2bus.o
> >  ifneq ($(CONFIG_SANDBOX),)
> >  obj-$(CONFIG_ACPIGEN) += acpi.o
> >  obj-$(CONFIG_ACPIGEN) += acpigen.o
> > diff --git a/test/dm/phys2bus.c b/test/dm/phys2bus.c
> > new file mode 100644
> > index 00..06a045c168
> > --- /dev/null
> > +++ b/test/dm/phys2bus.c
> > @@ -0,0 +1,36 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2020 Nicolas Saenz Julienne 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static int dm_test_phys_to_bus(struct unit_test_state *uts)
> > +{
> > +   struct udevice *dev;
> > +   ofnode node;
> > +
> > +   node = ofnode_path("/mmio-bus@0");
> > +   ut_assert(ofnode_valid(node));
> > +   ut_assert(!uclass_get_device_by_ofnode(UCLASS_TEST_BUS, node, 
> > ));
> > +   /* In this case it should be transparent, no dma-ranges in parent 
> > bus */
> > +   ut_asserteq_ptr((void*)0xfULL, (void*)dev_phys_to_bus(dev, 
> > 0xf));
> 
> ut_asserteq_addr() might be better here? Not sure.

That function uses map_to_sysmem() under the hood, which AFAIR didn't play well
with these addresses.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part


Re: [PATCH] doc: Add basic information about running CI tests

2020-12-21 Thread Tom Rini
On Mon, Dec 21, 2020 at 11:17:39AM +0900, AKASHI Takahiro wrote:
> On Fri, Dec 18, 2020 at 07:44:42PM -0500, Tom Rini wrote:
> > On Fri, Dec 18, 2020 at 06:34:10PM -0500, Sean Anderson wrote:
> > > On 12/18/20 5:14 PM, Tom Rini wrote:
> > > > Start out by documenting general expectations on when CI is run, how
> > > > anyone can run Azure pipelines, and how GitLab CI pipelines can be run.
> > > 
> > > Should travis be documented as well?
> > 
> > Travis is being dropped as travis-ci.org is ending and travis-ci.com
> > offers too small of a number of build minutes for free to be useful to
> > us.
> 
> It would make little sense to run the whole set of test cases on Travis,
> but I have used Travis until recently in order to run a small set of test
> scenario, for example, limiting the scope to
>   buildman catch-all AArch64
>   test/py sandbox
>   test/py qemu-x86_64
> by modifying .travis.yml.
> 
> Since going through the all test paths is a time-consuming task any way,
> it always makes sense for me to run some critical tests first locally
> (without revealing those activities in public).

Yes, but you can do that for Azure/GitLab too.  I'll expand on that in
v2, along with your other feedback.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 07/12] dm: test: Add test case for dev->dma_offset

2020-12-21 Thread Nicolas Saenz Julienne
On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
>  wrote:
> > 
> > Add test to validate dev->dma_offset is properly set on devices.
> > 
> > Signed-off-by: Nicolas Saenz Julienne 
> > ---
> >  arch/sandbox/dts/test.dts  |  4 
> >  configs/sandbox64_defconfig|  1 +
> >  configs/sandbox_defconfig  |  1 +
> >  configs/sandbox_flattree_defconfig |  1 +
> >  configs/sandbox_spl_defconfig  |  1 +
> >  test/dm/core.c | 30 ++
> >  6 files changed, 38 insertions(+)
> 
> Reviewed-by: Simon Glass 
> 
> We normally use ut_assertok() instead of ut_assert(!xxx), since 0 means OK.

Will fix this across all tests.



signature.asc
Description: This is a digitally signed message part


Re: [PATCH v3 04/12] dm: Introduce xxx_get_dma_range()

2020-12-21 Thread Nicolas Saenz Julienne
Hi Simon, thanks for the review.

On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> Hi Nicolas,
> 
> On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
>  wrote:
> > 
> > Add the following functions to get a specific device's DMA ranges:
> >  - dev_get_dma_range()
> >  - ofnode_get_dma_range()
> >  - of_get_dma_range()
> >  - fdt_get_dma_range()
> > They are specially useful in oder to be able validate a physical address
> > space range into a bus's and to convert addresses from and to address
> > spaces.
> > 
> > Signed-off-by: Nicolas Saenz Julienne 
> > 
> > ---
> > Changes since v2:
> >  - Return ENOENT instead of ENODEV
> >  - Refcount OF nodes
> > 
> > Changes since v1:
> >  - Fix wrong arguments in of_get_dma_range()'s call to 
> > of_translate_dma_address()
> >  - Fix build in SPL/TPL and no LIBFDT supprt
> >  - Add missing declaration in 'core/read.c'
> >  - Address Matthias' comments
> > 
> >  common/fdt_support.c   | 73 +++
> >  drivers/core/of_addr.c | 78 ++
> >  drivers/core/ofnode.c  |  9 +
> >  drivers/core/read.c|  6 
> >  include/dm/of_addr.h   | 17 +
> >  include/dm/ofnode.h| 16 +
> >  include/dm/read.h  | 21 
> >  include/fdt_support.h  | 14 
> >  8 files changed, 234 insertions(+)
> 
> Reviewed-by: Simon Glass 
> 
> I don't suppose it is worth writing a version that uses the ofnode API
> and thus reduce code size? Probably not since if livetree is enabled,
> I doubt we would ever call the flattree one. Also it is nice to have
> the same livetree code as Linux, where possible.

As far as the logic is concerned we'd be able to mimic what linux does so it
shouldn't be a problem.

But I'd be forced to port low level DT code to ofnode. Notably 'of_match_bus()'
and 'struct of_bus', which IMO have no place in ofnode: it seems to me that
ofnode is an abstraction geared towards simplifying DT consumers. This wouldn't
provide much benefit to them, with the downside of divering from upstream
Linux's implementation.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part


Re: [PATCH v2 14/14] qemu: arm64: Add documentation for capsule update

2020-12-21 Thread Heinrich Schuchardt

On 12/21/20 12:43 PM, Sughosh Ganu wrote:

Add documentation highlighting the steps for using the uefi capsule
update feature for updating the u-boot firmware image.

Signed-off-by: Sughosh Ganu 
---

Changes since V1:
* Change the documentation to reflect the usage of overlays for
   embedding the public key certs at runtime
* Fix the build for 'make htmldocs'

  doc/board/emulation/qemu-arm.rst | 188 +++


Why do you put the information into doc/board/emulation/qemu-arm.rst?

Isn't the same applicable to RISC-V QEMU?

Best regards

Heinrich


  1 file changed, 188 insertions(+)

diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 8d7fda10f1..11d91811b3 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -90,3 +90,191 @@ The debug UART on the ARM virt board uses these settings::
  CONFIG_DEBUG_UART_PL010=y
  CONFIG_DEBUG_UART_BASE=0x900
  CONFIG_DEBUG_UART_CLOCK=0
+
+Enabling Uefi Capsule Update feature
+
+
+Support has been added for the uefi capsule update feature which
+enables updating the u-boot image using the uefi firmware management
+protocol (fmp). The capsules are not passed to the firmware through
+the UpdateCapsule runtime service. Instead, capsule-on-disk
+functionality is used for fetching the capsule from the EFI System
+Partition (ESP).
+
+Currently, support has been added for updating the u-boot binary as a
+raw image when the platform is booted in non-secure mode, i.e with
+CONFIG_TFABOOT disabled. For this configuration, the qemu platform
+needs to be booted with 'secure=off'. The u-boot binary placed on the
+first bank of the Nor Flash at offset 0x0. The u-boot environment is
+placed on the second Nor Flash bank at offset 0x400.
+
+The capsule update feature is enabled with the following configs::
+
+CONFIG_MTD=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_DFU=y
+CONFIG_DFU_MTD=y
+CONFIG_PCI_INIT_R=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
+CONFIG_EFI_CAPSULE_FIRMWARE=y
+CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_EFI_CAPSULE_FMP_HEADER=y
+
+In addition, the following config needs to be disabled::
+
+CONFIG_TFABOOT
+
+The capsule file can be generated by using the GenerateCapsule.py
+script in edk2::
+
+$ ./BaseTools/BinWrappers/PosixLike/GenerateCapsule -e -o \
+ --fw-version  --lsv  --guid \
+e2bb9c06-70e9-4b14-97a3-5a7913176e3f --verbose --update-image-index \
+ --verbose 
+
+As per the uefi specification, the capsule file needs to be placed on
+the EFI System Partition, under the EFI/UpdateCapsule/ directory. The
+EFI System Partition can be a virtio-blk-device.
+
+Before initiating the firmware update, the efi variables BootNext,
+Boot and OsIndications need to be set. The Boot variable needs
+to be pointing to the EFI System Partition which contains the capsule
+file. The BootNext, Boot and OsIndications variables can be set
+using the following commands::
+
+=> efidebug boot add 0 Boot virtio 0:1 
+=> efidebug boot next 0
+=> setenv -e -nv -bs -rt -v OsIndications =0x04
+=> saveenv
+
+Finally, the capsule update can be initiated with the following
+command::
+
+=> efidebug capsule disk-update
+
+The updated u-boot image will be booted on subsequent boot.
+
+Enabling Capsule Authentication
+^^^
+
+The uefi specification defines a way of authenticating the capsule to
+be updated by verifying the capsule signature. The capsule signature
+is computed and prepended to the capsule payload at the time of
+capsule generation. This signature is then verified by using the
+public key stored as part of the X509 certificate. This certificate is
+in the form of an efi signature list (esl) file, which is embedded as
+part of the platform's device tree blob using the mkeficapsule
+utility.
+
+On the qemu virt platforms, the device-tree is generated on the fly
+based on the devices configured. This device tree is then passed on to
+the various software components booting on the platform, including
+u-boot. Therefore, on the qemu virt platform, the signatute is
+embedded on an overlay. This overlay is then applied at runtime to the
+base platform device-tree. Steps needed for embedding the esl file in
+the overlay are highlighted below.
+
+The capsule authentication feature can be enabled through the
+following config, in addition to the configs listed above for capsule
+update::
+
+CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+
+The public and private keys used for the signing process are generated
+and used by the steps highlighted below::
+
+1. Install utility commands on your host
+   * openssl
+   * efitools
+
+2. Create signing keys and certificate files on your host
+
+$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=CRT/ \
+

Re: [PATCH v2 03/14] crypto: Fix the logic to calculate hash with authattributes set

2020-12-21 Thread Heinrich Schuchardt

On 12/21/20 12:43 PM, Sughosh Ganu wrote:

RFC 2315 Section 9.3 describes the message digesting process. The
digest calculated depends on whether the authenticated attributes are
present. In case of a scenario where the authenticated attributes are
present, the message digest that gets signed and is part of the pkcs7
message is computed from the auth attributes rather than the contents
field.

Check if the auth attributes are present, and if set, use the auth
attributes to compute the hash that would be compared with the
encrypted hash on the pkcs7 message.

Signed-off-by: Sughosh Ganu 


Hello Takahiro,

as you provided the lib/crypto/pkcs7_verify.c file could you, please,
review this patch.

Best regards

Heinrich


---

Changes since V1: None

  lib/crypto/pkcs7_verify.c | 37 ++---
  1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/lib/crypto/pkcs7_verify.c b/lib/crypto/pkcs7_verify.c
index 320ba49f79..58683ef614 100644
--- a/lib/crypto/pkcs7_verify.c
+++ b/lib/crypto/pkcs7_verify.c
@@ -50,8 +50,15 @@ static int pkcs7_digest(struct pkcs7_message *pkcs7,
struct image_region regions[2];
int ret = 0;

-   /* The digest was calculated already. */
-   if (sig->digest)
+   /*
+* [RFC2315 9.3]
+* If the authenticated attributes are present,
+* the message-digest is calculated on the
+* attributes present in the
+* authenticatedAttributes field and not just
+* the contents field
+*/
+   if (!sinfo->authattrs && sig->digest)
return 0;

if (!sinfo->sig->hash_algo)
@@ -63,17 +70,25 @@ static int pkcs7_digest(struct pkcs7_message *pkcs7,
else
return -ENOPKG;

-   sig->digest = calloc(1, sig->digest_size);
-   if (!sig->digest) {
-   pr_warn("Sig %u: Out of memory\n", sinfo->index);
-   return -ENOMEM;
-   }
+   /*
+* Calculate the hash only if the data is present.
+* In case of authenticated variable and capsule,
+* the hash has already been calculated on the
+* efi_image_regions and populated
+*/
+   if (pkcs7->data) {
+   sig->digest = calloc(1, sig->digest_size);
+   if (!sig->digest) {
+   pr_warn("Sig %u: Out of memory\n", sinfo->index);
+   return -ENOMEM;
+   }

-   regions[0].data = pkcs7->data;
-   regions[0].size = pkcs7->data_len;
+   regions[0].data = pkcs7->data;
+   regions[0].size = pkcs7->data_len;

-   /* Digest the message [RFC2315 9.3] */
-   hash_calculate(sinfo->sig->hash_algo, regions, 1, sig->digest);
+   /* Digest the message [RFC2315 9.3] */
+   hash_calculate(sinfo->sig->hash_algo, regions, 1, sig->digest);
+   }

/* However, if there are authenticated attributes, there must be a
 * message digest attribute amongst them which corresponds to the





Re: [PATCH v2 02/14] qemu: arm: Initialise virtio in board_late_init

2020-12-21 Thread Heinrich Schuchardt

On 12/21/20 1:19 PM, Heinrich Schuchardt wrote:

On 12/21/20 12:43 PM, Sughosh Ganu wrote:

On the qemu arm platform, the virtio devices are initialised in
board_init, which gets called before the initr_pci. With this, the
virtio block devices on the pci bus are not initialised. Move the
initialisation of virtio devices to board_late_init which gets called
after the call to initr_pci.

Signed-off-by: Sughosh Ganu 


With which commands can I see the difference before and after the patch?


The 'rng' command now works without calling 'virtio scan' beforehand.



Best regards

Heinrich


---

Changes since V1:
* The earlier patch was adding a call to pci_init in board_init. Moved
   the virtio_init call to board_late_init

  board/emulation/qemu-arm/qemu-arm.c | 5 +
  configs/qemu_arm64_defconfig    | 1 +
  2 files changed, 6 insertions(+)

diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
index f18f2ed7da..aa68bef469 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -64,6 +64,11 @@ struct mm_region *mem_map = qemu_arm64_mem_map;
  #endif

  int board_init(void)
+{
+    return 0;
+}
+
+int board_late_init(void)


Why don't you change board/emulation/qemu-riscv/qemu-riscv.c too? I can
see no reason why you want to treat RISC-V differently.

What about x86 and MIPS? Why is virtio_init() not called on those
architectures?


  {
  /*
   * Make sure virtio bus is enumerated so that peripherals
diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index f6e586627a..5c855fa08c 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -14,6 +14,7 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
  CONFIG_USE_PREBOOT=y
  # CONFIG_DISPLAY_CPUINFO is not set
  # CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_LATE_INIT=y



The C code change concerns both arm64 and arm. So on all ARM QEMU boards
except qemu_arm64_defconfig you don't call virtio_init() at all once
this patch is applied. This cannot be correct!

Probably you want to change arch/Kconfig instead:

diff --git a/arch/Kconfig b/arch/Kconfig
index e8f9a9e1b7..1c66743ab6 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -24,6 +24,7 @@ config ARM
bool "ARM architecture"
select CREATE_ARCH_SYMLINK
select HAVE_PRIVATE_LIBGCC if !ARM64
+   select BOARD_LATE_INIT
select SUPPORT_OF_CONTROL

Best regards

Heinrich



  CONFIG_PCI_INIT_R=y
  CONFIG_CMD_BOOTEFI_SELFTEST=y
  CONFIG_CMD_NVEDIT_EFI=y







Re: [PATCH v2] doc: edison: Update information about xFSTK

2020-12-21 Thread Bin Meng
Hi Andy,

On Mon, Dec 21, 2020 at 8:32 PM Andy Shevchenko
 wrote:
>
> On Mon, Nov 30, 2020 at 01:12:24PM -0700, Simon Glass wrote:
> > On Fri, 27 Nov 2020 at 08:59, Andy Shevchenko
> >  wrote:
> > >
> > > xFSTK sources got a new home under Edison Firmware Group on GitHub [1].
> > > Update Intel Edison documentation accordingly.
> > >
> > > While here, fix couple of typos.
> > >
> > > [1]: https://github.com/edison-fw
> > >
> > > Signed-off-by: Andy Shevchenko 
> > > ---
> > > v2: more fixes to have nice looking PDF
> > >  doc/board/intel/edison.rst | 49 ++
> > >  1 file changed, 29 insertions(+), 20 deletions(-)
> >
> > Reviewed-by: Simon Glass 
>
> Thanks!
>
> Can we get this applied to the upcoming release?

Sure, somehow this was not assigned to me hence I missed it in the last PR.

Regards,
Bin


Re: [PATCH v2] doc: edison: Update information about xFSTK

2020-12-21 Thread Andy Shevchenko
On Mon, Nov 30, 2020 at 01:12:24PM -0700, Simon Glass wrote:
> On Fri, 27 Nov 2020 at 08:59, Andy Shevchenko
>  wrote:
> >
> > xFSTK sources got a new home under Edison Firmware Group on GitHub [1].
> > Update Intel Edison documentation accordingly.
> >
> > While here, fix couple of typos.
> >
> > [1]: https://github.com/edison-fw
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> > v2: more fixes to have nice looking PDF
> >  doc/board/intel/edison.rst | 49 ++
> >  1 file changed, 29 insertions(+), 20 deletions(-)
> 
> Reviewed-by: Simon Glass 

Thanks!

Can we get this applied to the upcoming release?


-- 
With Best Regards,
Andy Shevchenko




  1   2   >