[PATCH] arm64: zynqmp: Do not clear reset reason

2021-02-08 Thread Michal Simek
There is no need to clear reset reason register because it is protected by
PMUFW already which is reported when verbose log is enabled as:
pm_core.c@733 APU> No write permission to 0xFF5E0220

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index a216eeb35f15..6babc0ebce3e 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -496,11 +496,7 @@ static int reset_reason(void)
 
env_set("reset_reason", reason);
 
-   ret = zynqmp_mmio_write((ulong)_base->reset_reason, ~0, ~0);
-   if (ret)
-   return -EINVAL;
-
-   return ret;
+   return 0;
 }
 
 static int set_fdtfile(void)
-- 
2.30.0



Re: [PATCH] efi_loader: don't load beyond VirtualSize

2021-02-08 Thread Heinrich Schuchardt

On 2/9/21 7:48 AM, Heinrich Schuchardt wrote:

Am 9. Februar 2021 07:19:48 MEZ schrieb Asherah Connor :

PE section table entries' SizeOfRawData must be a multiple of
FileAlignment, and thus may be rounded up and larger than their
VirtualSize.

We should not load beyond the VirtualSize, which is "the total size of
the section when loaded into memory" -- we may clobber real data at the
target in some other section, since we load sections in reverse order
and sections are usually laid out sequentially.


Thank you for reporting and addressing the issue.

Is this patch related to an observed problem or is it resulting from code 
review?

Should we load in forward order?



Signed-off-by: Asherah Connor 
CC: Heinrich Schuchardt 
---
lib/efi_loader/efi_image_loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index d4dd9e9433..f53ef367ec 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -843,7 +843,7 @@ efi_status_t efi_load_pe(struct
efi_loaded_image_obj *handle,
   sec->Misc.VirtualSize);
memcpy(efi_reloc + sec->VirtualAddress,
   efi + sec->PointerToRawData,
-  sec->SizeOfRawData);
+  min(sec->Misc.VirtualSize, sec->SizeOfRawData));
}


If SizeOfRawData must be >= VirtualSize, why do we have to consider both fields?


The PE-COFF spec [1] says:

SizeOfRawData

The size of the section (for object files) or the size of the
initialized data on disk (for image files). For executable images, this
must be a multiple of FileAlignment from the optional header. If this is
less than VirtualSize, the remainder of the section is zero-filled.
Because the SizeOfRawData field is rounded but the VirtualSize field is
not, it is possible for SizeOfRawData to be greater than VirtualSize as
well. When a section contains only uninitialized data, this field should
be zero.

So SizeOfRawData can be both smaller and greater then VirtualSize.

We zero the memory before copying the data. This covers the case
SizeOfRawData < VirtualSize.

Reviewed-by: Heinrich Schuchardt 

[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format



Best regards

Heinrich




/* Run through relocations */






RE: [PATCH 07/13] arm: aspeed: Disable ATAGs support

2021-02-08 Thread ChiaWei Wang
Hi Tom,

I have tested this patch with Aspeed SDK as well as the U-Boot mainline 
codebase on AST2500/AST2600 EVBs.
Both AST2500/AST2600 can boot to kernel normally. Thanks.

Chiawei

Tested-by: Chia-Wei Wang 

> -Original Message-
> From: Tom Rini 
> Sent: Thursday, February 4, 2021 10:24 AM
> To: u-boot@lists.denx.de
> Cc: Ryan Chen ; ChiaWei Wang
> ; BMC-SW 
> Subject: [PATCH 07/13] arm: aspeed: Disable ATAGs support
> 
> This platform never had to support an ATAGs-based Linux kernel, so remove
> the support for it.
> 
> Cc: Ryan Chen 
> Cc: Chia-Wei Wang 
> Cc: Aspeed BMC SW team 
> Signed-off-by: Tom Rini 
> ---
> I'm assuming, please correct me if I'm wrong.
> ---
>  include/configs/aspeed-common.h | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/include/configs/aspeed-common.h
> b/include/configs/aspeed-common.h index df0f5d2e76f7..8d666c6ed415
> 100644
> --- a/include/configs/aspeed-common.h
> +++ b/include/configs/aspeed-common.h
> @@ -12,11 +12,6 @@
> 
>  #include 
> 
> -/* Misc CPU related */
> -#define CONFIG_CMDLINE_TAG
> -#define CONFIG_SETUP_MEMORY_TAGS
> -#define CONFIG_INITRD_TAG
> -
>  #define CONFIG_SYS_SDRAM_BASEASPEED_DRAM_BASE
> 
>  #ifdef CONFIG_PRE_CON_BUF_SZ
> --
> 2.17.1



Re: [PATCH v4] fastboot: add UUU command UCmd and ACmd support

2021-02-08 Thread Heiko Schocher
Hello Patrick,

On 08.02.21 17:56, Patrick DELAUNAY wrote:
> Hi Heiko,
> 
> 
> On 2/8/21 12:38 PM, Heiko Schocher wrote:
>> add support for the UUU commands ACmd and UCmd.
>>
>> Enable them through the Kconfig option
>> CONFIG_FASTBOOT_UUU_SUPPORT
>>
>> base was commit in NXP kernel
>> 9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot support")
>>
>> and ported it to current mainline. Tested this patch
>> on imx6ul based board.
>>
>> Signed-off-by: Heiko Schocher 
>> ---
>>
>> azure build was fine:
>> https://dev.azure.com/hs0298/hs/_build/results?buildId=59=results
>>
>> Changes in v4:
>> - fixed missing parts from Sean Anderson patches
>>    lost while rebased to tree from lukasz
>>
>> Changes in v3:
>> - rebased to https://github.com/lmajewski/u-boot-dfu/commits/testing
>>    as Lukasz mentioned.
>>
>> Changes in v2:
>> - remove unused FSL_FASTBOOT option
>> - add comment from Roman:
>>    do not enable this option per default
>>    add Kconfig comment that enabling this option may
>>    introduce a security issue.
>>
>>   doc/android/fastboot-protocol.rst |  5 +++
>>   doc/android/fastboot.rst  |  2 +
>>   drivers/fastboot/Kconfig  |  9 +
>>   drivers/fastboot/fb_command.c | 62 +++
>>   drivers/usb/gadget/f_fastboot.c   | 17 +
>>   include/fastboot.h    |  7 
>>   6 files changed, 102 insertions(+)
>>
> (...)
>> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
>> index 41fc8d7904d..960e73089e0 100644
>> --- a/drivers/fastboot/fb_command.c
>> +++ b/drivers/fastboot/fb_command.c
> (...)
>> +
>> +static char g_a_cmd_buff[64];
>> +
>> +void fastboot_acmd_complete(void)
>> +{
>> +    run_command(g_a_cmd_buff, 0);
>> +}
>> +
>> +/**
>> + * run_acmd() - Execute the ACmd command
>> + *
>> + * @cmd_parameter: Pointer to command parameter
>> + * @response: Pointer to fastboot response buffer
>> + */
>> +static void run_acmd(char *cmd_parameter, char *response)
>> +{
>> +    if (!cmd_parameter) {
>> +    pr_err("missing slot suffix\n");
>> +    fastboot_fail("missing command", response);
>> +    return;
>> +    }
>> +
>> +    strcpy(g_a_cmd_buff, cmd_parameter);
> 
> 
> to avoid overflow:
> 
> 
> + strncpy (g_a_cmd_buff, cmd_parameter, sizeof(g_a_cmd_buff));
> 
> 
> or check strlen(cmd_parameter) ?
> 
> 
> + if (check strlen(cmd_parameter) > sizeof(g_a_cmd_buff)) {
> 
> +    pr_err("too long command\n");
> 
> +    fastboot_fail("too long command", response);
> +    return;
> +    }

Yes, good catch, thanks! I send a v5 with checking the length
and error message

>> +    fastboot_okay(NULL, response);
>> +}
>> +#endif
>> +
>>   /**
>>    * reboot_bootloader() - Sets reboot bootloader flag.
>>    *
>> diff --git a/drivers/usb/gadget/f_fastboot.c 
>> b/drivers/usb/gadget/f_fastboot.c
>> index 950cc119495..8ba55aab9f8 100644
>> --- a/drivers/usb/gadget/f_fastboot.c
>> +++ b/drivers/usb/gadget/f_fastboot.c
>> @@ -494,6 +494,18 @@ static void do_bootm_on_complete(struct usb_ep *ep, 
>> struct usb_request *req)
>>   do_exit_on_complete(ep, req);
>>   }
>>   
> (...)
> 
> Anyway, except this remark.
> 
> Acked-by: Patrick Delaunay 

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


Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-08 Thread Chris Packham

On 9/02/21 3:07 pm, Marek Behun wrote:
> On Tue, 9 Feb 2021 01:08:54 +
> Chris Packham  wrote:
>
>> On 9/02/21 1:16 pm, Chris Packham wrote:
>>> On 9/02/21 9:18 am, Marek Behun wrote:
 On Mon, 8 Feb 2021 20:11:06 +
 Chris Packham  wrote:
   
> Hi Marek,
>
> Do you have this in a repo I can pull from? I've got a couple of boards
> I can give this a spin on.
 https://gitlab.nic.cz/turris/turris-omnia-uboot/
 branch v2021.04-rc-mv-ddr-14.0.0

 also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that
 one contains one more commit that is needed for Omnia with Samsung DDR
 chips.
>>> I've tested the dm-88f6820-amc board. Training completed without
>>> issue, as does memtester running from Linux.
>>>
>>> Hit a bit of a snag on the x530 because the changes pushed it over the
>>> SPL size (it was already pretty close). I'll look to see if there's
>>> anything I can drop out or maybe bump the SPL size (I never did get a
>>> clear answer from Marvell as to what the size limit actually is).
>> I can temporarily work around the size issue by disabling watchdog
>> support in SPL (I really don't want that to be the long term solution).
>>
>> But then I encounter an odd problem. When I "reset" the board gets
>> through the DDR training but never makes it to u-boot proper, but if I
>> power cycle it boots through to the u-boot prompt. This doesn't happen
>> on the db-88f6820-amc board. One difference between the x530 and the amc
>> board is that the x530 has ECC so maybe something is going into the
>> weeds if ECC has already been enabled by a previous boot.
>>
> Could you bisect which commit causes this?
Seems to be the last one (ddr: marvell: a38x: fix SPLIT_OUT_MIX state 
decision) not entirely sure what the problem is. So I guess you can 
consider the upstream update good, the fix SPLIT_OUT_MIX not so much it 
happens to be the thing that causes the issue and the straw that tips 
the build size over the limit.

Re: [PATCH] efi_loader: don't load beyond VirtualSize

2021-02-08 Thread Heinrich Schuchardt
Am 9. Februar 2021 07:19:48 MEZ schrieb Asherah Connor :
>PE section table entries' SizeOfRawData must be a multiple of
>FileAlignment, and thus may be rounded up and larger than their
>VirtualSize.
>
>We should not load beyond the VirtualSize, which is "the total size of
>the section when loaded into memory" -- we may clobber real data at the
>target in some other section, since we load sections in reverse order
>and sections are usually laid out sequentially.

Thank you for reporting and addressing the issue.

Is this patch related to an observed problem or is it resulting from code 
review?

Should we load in forward order?

>
>Signed-off-by: Asherah Connor 
>CC: Heinrich Schuchardt 
>---
> lib/efi_loader/efi_image_loader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/lib/efi_loader/efi_image_loader.c
>b/lib/efi_loader/efi_image_loader.c
>index d4dd9e9433..f53ef367ec 100644
>--- a/lib/efi_loader/efi_image_loader.c
>+++ b/lib/efi_loader/efi_image_loader.c
>@@ -843,7 +843,7 @@ efi_status_t efi_load_pe(struct
>efi_loaded_image_obj *handle,
>  sec->Misc.VirtualSize);
>   memcpy(efi_reloc + sec->VirtualAddress,
>  efi + sec->PointerToRawData,
>- sec->SizeOfRawData);
>+ min(sec->Misc.VirtualSize, sec->SizeOfRawData));
>   }

If SizeOfRawData must be >= VirtualSize, why do we have to consider both fields?

Best regards

Heinrich


> 
>   /* Run through relocations */



Re: [PATCH 1/1] sandbox: allow cross-compiling sandbox

2021-02-08 Thread Heinrich Schuchardt
Am 9. Februar 2021 06:30:31 MEZ schrieb AKASHI Takahiro 
:
>On Mon, Feb 08, 2021 at 09:29:43PM -0700, Simon Glass wrote:
>> Hi Heinrich,
>> 
>> On Mon, 8 Feb 2021 at 15:06, Heinrich Schuchardt 
>wrote:
>> >
>> > UEFI test files like helloworld.efi require an architecture
>specific
>> > PE-COFF header.
>> 
>> architecture-specific
>> 
>> >
>> > For non-sandbox the PE-COFF header is chosen by the target
>architecture.
>> > For the sandbox we use the host architecture. This is not helpful
>for cross
>> > compiling. Allow specifying the target architecture of the sandbox
>via
>> > environment variable MK_ARCH, e.g.
>> 
>> What exactly is the target arch? Is the the one that sandbox is
>> running on, or something else?
>> 
>> >
>> > make sandbox_defconfig NO_SDL=1
>> > CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make
>> >
>> > Signed-off-by: Heinrich Schuchardt 
>> > ---
>> >  Makefile |  2 +-
>> >  doc/arch/sandbox.rst | 14 ++
>> >  2 files changed, 15 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/Makefile b/Makefile
>> > index 23dd11f723..286e5148ae 100644
>> > --- a/Makefile
>> > +++ b/Makefile
>> > @@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR)
>> >
>> >  # Determine host architecture
>> >  include include/host_arch.h
>> > -MK_ARCH="${shell uname -m}"
>> > +MK_ARCH?="${shell uname -m}"
>> >  unexport HOST_ARCH
>> >  ifeq ("x86_64", $(MK_ARCH))
>> >export HOST_ARCH=$(HOST_ARCH_X86_64)
>> > diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst
>> > index 60ee1e0741..0dd9edc8cb 100644
>> > --- a/doc/arch/sandbox.rst
>> > +++ b/doc/arch/sandbox.rst
>> > @@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts.
>> >
>> >  Note that standalone/API support is not available at present.
>> >
>> > +Cross compiling
>> > +---
>> > +
>> > +When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y
>the target
>> > +architecture must be specified using the MK_ARCH environment
>variable using one
>> > +of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64,
>e.g.
>> 
>> OK, but what is the target architecture? I'm just not sure from your
>> comments what this actually means.
>
>I'm not quite sure if it is very useful to be able to cross-compile
>the sandbox application. But any way, it is not very convenient

Building the sandbox on ARMv7 is broken due to patch introduced in 2020. We get 
loads of warnings when building for 32bit.

We should integrate building the sandbox for different architectures into 
Gitlab CI.

>to always enforce users to explicitly specify "target" architecture.
>How about trying the following first?
>$(CC) -v | grep "Target: " | sed -e 's/-*$//'
>
>It will give us a hint about the architecture.
>("--print-multiarch" shows a similar triple, but this option won't
>work for some pre-built gcc, like aarch64 gcc from Arm.)

Did you check clang?

Is the output format specified? Will this be stable for compiler versions to 
come? Given the --print-multiarch failure probably not.

When compiling Linux you also have to supply CROSS_COMPILER and ARCH.

For me it is anyway a Gitlab CI thing. Nothing a user would typically use.

Best regards

Heinrich


>
>> Does MK mean make?
>
>I prefer another name for clarity.
>
>-Takahiro Akashi
>
>> 
>> > +
>> > +.. code-block:: bash
>> > +
>> > +NO_SDL=1 make sandbox_defconfig
>> > +CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make
>> > +
>> > +NO_SDL=1 was chosen in the example to remove the dependency on the
>SDL library.
>> > +The graphical console will not be available.
>> >
>> >  Prerequisites
>> >  -
>> > --
>> > 2.30.0
>> >
>> 
>> Regards,
>> Simon



Re: [PATCH 1/1] sandbox: allow cross-compiling sandbox

2021-02-08 Thread Heinrich Schuchardt
Am 9. Februar 2021 05:29:43 MEZ schrieb Simon Glass :
>Hi Heinrich,
>
>On Mon, 8 Feb 2021 at 15:06, Heinrich Schuchardt 
>wrote:
>>
>> UEFI test files like helloworld.efi require an architecture specific
>> PE-COFF header.
>
>architecture-specific
>
>>
>> For non-sandbox the PE-COFF header is chosen by the target
>architecture.
>> For the sandbox we use the host architecture. This is not helpful for
>cross
>> compiling. Allow specifying the target architecture of the sandbox
>via
>> environment variable MK_ARCH, e.g.
>
>What exactly is the target arch? Is the the one that sandbox is
>running on, or something else?

It is the architecture that the binary can be run on



>
>>
>> make sandbox_defconfig NO_SDL=1
>> CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  Makefile |  2 +-
>>  doc/arch/sandbox.rst | 14 ++
>>  2 files changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 23dd11f723..286e5148ae 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR)
>>
>>  # Determine host architecture
>>  include include/host_arch.h
>> -MK_ARCH="${shell uname -m}"
>> +MK_ARCH?="${shell uname -m}"
>>  unexport HOST_ARCH
>>  ifeq ("x86_64", $(MK_ARCH))
>>export HOST_ARCH=$(HOST_ARCH_X86_64)
>> diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst
>> index 60ee1e0741..0dd9edc8cb 100644
>> --- a/doc/arch/sandbox.rst
>> +++ b/doc/arch/sandbox.rst
>> @@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts.
>>
>>  Note that standalone/API support is not available at present.
>>
>> +Cross compiling
>> +---
>> +
>> +When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y the
>target
>> +architecture must be specified using the MK_ARCH environment
>variable using one
>> +of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64, e.g.
>
>OK, but what is the target architecture? I'm just not sure from your
>comments what this actually means.

See above.

>
>Does MK mean make?

What name do you suggest?

Best regards

Heinrich

>
>> +
>> +.. code-block:: bash
>> +
>> +NO_SDL=1 make sandbox_defconfig
>> +CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make
>> +
>> +NO_SDL=1 was chosen in the example to remove the dependency on the
>SDL library.
>> +The graphical console will not be available.
>>
>>  Prerequisites
>>  -
>> --
>> 2.30.0
>>
>
>Regards,
>Simon



Re: [PATCH v4 5/9] mtd: spi-nor-core: Add the ->ready() hook

2021-02-08 Thread Takahiro Kuwano
Hi Pratyush,

Thank you for the feedback. I will address this in v5.

On 1/30/2021 3:49 AM, Pratyush Yadav wrote:
> Hi,
> 
> On 28/01/21 01:36PM, tkuw584...@gmail.com wrote:
>> From: Takahiro Kuwano 
>>
>> For dual/quad die package devices from Spansion/Cypress, the device's
>> status needs to be checked by reading status registers in all dies, by
>> using Read Any Register command. To support this, a Flash specific hook
>> that can overwrite the legacy status check is needed.
>>
>> The spansion_sr_ready() reads status register 1 by Read Any Register
>> commnad. This function is called from Flash specific hook with die address
>> and dummy cycles.
>>
>> Signed-off-by: Takahiro Kuwano 
>> ---
>>  drivers/mtd/spi/spi-nor-core.c | 32 
>>  include/linux/mtd/spi-nor.h|  4 +++-
>>  2 files changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
>> index 624e730524..1c0ba5abf9 100644
>> --- a/drivers/mtd/spi/spi-nor-core.c
>> +++ b/drivers/mtd/spi/spi-nor-core.c
>> @@ -522,6 +522,35 @@ static int set_4byte(struct spi_nor *nor, const struct 
>> flash_info *info,
>>  }
>>  }
>>  
>> +#ifdef CONFIG_SPI_FLASH_SPANSION
>> +/*
>> + * Read status register 1 by using Read Any Register command to support 
>> multi
>> + * die package parts.
>> + */
>> +static int spansion_sr_ready(struct spi_nor *nor, u32 addr_base, u8 dummy)
>> +{
>> +u32 reg_addr = addr_base + SPINOR_REG_ADDR_STR1V;
>> +u8 sr;
>> +int ret;
>> +
>> +ret = spansion_read_any_reg(nor, reg_addr, dummy, );
>> +if (ret < 0)
>> +return ret;
>> +
>> +if (sr & (SR_E_ERR | SR_P_ERR)) {
>> +if (sr & SR_E_ERR)
>> +dev_dbg(nor->dev, "Erase Error occurred\n");
>> +else
>> +dev_dbg(nor->dev, "Programming Error occurred\n");
>> +
>> +nor->write_reg(nor, SPINOR_OP_CLSR, NULL, 0);
>> +return -EIO;
>> +}
>> +
>> +return !(sr & SR_WIP);
>> +}
>> +#endif
>> +
> 
> Do not add this function in this patch. Just add the hook here. Add it 
> in the patch that actually uses it.
> 
>>  static int spi_nor_sr_ready(struct spi_nor *nor)
>>  {
>>  int sr = read_sr(nor);
>> @@ -570,6 +599,9 @@ static int spi_nor_ready(struct spi_nor *nor)
>>  {
>>  int sr, fsr;
>>  
>> +if (nor->ready)
>> +return nor->ready(nor);
>> +
> 
> Move the code below in a separate function and call it something like 
> spi_nor_default_ready(). Then call that function from here.
> 
>>  sr = spi_nor_sr_ready(nor);
>>  if (sr < 0)
>>  return sr;
>> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
>> index e31073eb24..25234177de 100644
>> --- a/include/linux/mtd/spi-nor.h
>> +++ b/include/linux/mtd/spi-nor.h
>> @@ -434,8 +434,9 @@ struct flash_info;
>>   * @flash_lock: [FLASH-SPECIFIC] lock a region of the SPI NOR
>>   * @flash_unlock:   [FLASH-SPECIFIC] unlock a region of the SPI NOR
>>   * @flash_is_locked:[FLASH-SPECIFIC] check if a region of the SPI 
>> NOR is
>> - * @quad_enable:[FLASH-SPECIFIC] enables SPI NOR quad mode
>>   *  completely locked
>> + * @quad_enable:[FLASH-SPECIFIC] enables SPI NOR quad mode
>> + * @ready:  [FLASH-SPECIFIC] check if the flash is ready
>>   * @priv:   the private data
>>   */
>>  struct spi_nor {
>> @@ -481,6 +482,7 @@ struct spi_nor {
>>  int (*flash_unlock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
>>  int (*flash_is_locked)(struct spi_nor *nor, loff_t ofs, uint64_t len);
>>  int (*quad_enable)(struct spi_nor *nor);
>> +int (*ready)(struct spi_nor *nor);
>>  
>>  void *priv;
>>  /* Compatibility for spi_flash, remove once sf layer is merged with mtd */
>> -- 
>> 2.25.1
>>
> 

Best Regards,
Takahiro


Re: [PATCH v4 4/9] mtd: spi-nor-core: Add support for volatile QE bit

2021-02-08 Thread Takahiro Kuwano
Hi Pratyush,

On 1/30/2021 3:40 AM, Pratyush Yadav wrote:
> Hi,
> 
> On 28/01/21 01:36PM, tkuw584...@gmail.com wrote:
>> From: Takahiro Kuwano 
>>
>> Some of Spansion/Cypress chips support volatile version of configuration
>> registers and it is recommended to update volatile registers in the field
>> application due to a risk of the non-volatile registers corruption by
>> power interrupt. This patch adds a function to set Quad Enable bit in CFR1
>> volatile.
>>
>> Signed-off-by: Takahiro Kuwano 
>> ---
>>  drivers/mtd/spi/spi-nor-core.c | 53 ++
>>  1 file changed, 53 insertions(+)
>>
>> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
>> index 2803536ed5..624e730524 100644
>> --- a/drivers/mtd/spi/spi-nor-core.c
>> +++ b/drivers/mtd/spi/spi-nor-core.c
>> @@ -1576,6 +1576,59 @@ static int spansion_read_cr_quad_enable(struct 
>> spi_nor *nor)
>>  return 0;
>>  }
>>  
>> +/**
>> + * spansion_quad_enable_volatile() - enable Quad I/O mode in volatile 
>> register.
>> + * @nor:pointer to a 'struct spi_nor'
>> + * @addr_base:  base address of register (can be >0 in multi-die parts)
>> + * @dummy:  number of dummy cycles for register read
>> + *
>> + * It is recommended to update volatile registers in the field application 
>> due
>> + * to a risk of the non-volatile registers corruption by power interrupt. 
>> This
>> + * function sets Quad Enable bit in CFR1 volatile.
>> + *
>> + * Return: 0 on success, -errno otherwise.
>> + */
>> +static int spansion_quad_enable_volatile(struct spi_nor *nor, u32 addr_base,
>> + u8 dummy)
>> +{
>> +u32 addr = addr_base | SPINOR_REG_ADDR_CFR1V;
> 
> Why do you OR the register offset with the base? Shouldn't you be adding 
> to it?
> 
I missed it during review... I will fix.


>> +
>> +u8 cr;
>> +int ret;
>> +
>> +/* Check current Quad Enable bit value. */
>> +ret = spansion_read_any_reg(nor, addr, dummy, );
>> +if (ret < 0) {
>> +dev_dbg(nor->dev,
>> +"error while reading configuration register\n");
>> +return -EINVAL;
>> +}
>> +
>> +if (cr & CR_QUAD_EN_SPAN)
>> +return 0;
>> +
>> +cr |= CR_QUAD_EN_SPAN;
>> +
>> +write_enable(nor);
>> +
>> +ret = spansion_write_any_reg(nor, addr, cr);
>> +
>> +if (ret < 0) {
>> +dev_dbg(nor->dev,
>> +"error while writing configuration register\n");
>> +return -EINVAL;
>> +}
>> +
>> +/* Read back and check it. */
>> +ret = spansion_read_any_reg(nor, addr, dummy, );
>> +if (ret || !(cr & CR_QUAD_EN_SPAN)) {
>> +dev_dbg(nor->dev, "Spansion Quad bit not set\n");
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
>> +
> 
> Rest of the patch LGTM.
> 
>>  #if CONFIG_IS_ENABLED(SPI_FLASH_SFDP_SUPPORT)
>>  /**
>>   * spansion_no_read_cr_quad_enable() - set QE bit in Configuration Register.
>> -- 
>> 2.25.1
>>
> 

Best Regards,
Takahiro


Re: [PATCH v4 3/9] mtd: spi-nor-core: Add support for Read/Write Any Register

2021-02-08 Thread Takahiro Kuwano



On 1/30/2021 3:17 AM, Pratyush Yadav wrote:
> On 28/01/21 01:36PM, tkuw584...@gmail.com wrote:
>> From: Takahiro Kuwano 
>>
>> Some of Spansion/Cypress chips support Read/Write Any Register commands.
>> These commands are mainly used to write volatile registers and access to
>> the registers in second and subsequent die for multi-die package parts.
>>
>> The Read Any Register instruction (65h) is followed by register address
>> and dummy cycles, then the selected register byte is returned.
>>
>> The Write Any Register instruction (71h) is followed by register address
>> and register byte to write.
>>
>> Signed-off-by: Takahiro Kuwano 
>> ---
>>  drivers/mtd/spi/spi-nor-core.c | 25 +
>>  include/linux/mtd/spi-nor.h|  4 
>>  2 files changed, 29 insertions(+)
>>
>> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
>> index 34c15f1561..2803536ed5 100644
>> --- a/drivers/mtd/spi/spi-nor-core.c
>> +++ b/drivers/mtd/spi/spi-nor-core.c
>> @@ -211,6 +211,31 @@ static int spi_nor_write_reg(struct spi_nor *nor, u8 
>> opcode, u8 *buf, int len)
>>  return spi_nor_read_write_reg(nor, , buf);
>>  }
>>  
>> +#ifdef CONFIG_SPI_FLASH_SPANSION
>> +static int spansion_read_any_reg(struct spi_nor *nor, u32 addr, u8 dummy,
>> + u8 *val)
>> +{
>> +struct spi_mem_op op =
>> +SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDAR, 1),
>> +   SPI_MEM_OP_ADDR(nor->addr_width, addr, 1),
>> +   SPI_MEM_OP_DUMMY(dummy / 8, 1),
>> +   SPI_MEM_OP_DATA_IN(1, NULL, 1));
>> +
>> +return spi_nor_read_write_reg(nor, , val);
>> +}
>> +
>> +static int spansion_write_any_reg(struct spi_nor *nor, u32 addr, u8 val)
>> +{
>> +struct spi_mem_op op =
>> +SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WRAR, 1),
>> +   SPI_MEM_OP_ADDR(nor->addr_width, addr, 1),
>> +   SPI_MEM_OP_NO_DUMMY,
>> +   SPI_MEM_OP_DATA_OUT(1, NULL, 1));
>> +
>> +return spi_nor_read_write_reg(nor, , );
>> +}
>> +#endif
>> +
>>  static ssize_t spi_nor_read_data(struct spi_nor *nor, loff_t from, size_t 
>> len,
>>   u_char *buf)
>>  {
>> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
>> index 89e7a4fdcd..e31073eb24 100644
>> --- a/include/linux/mtd/spi-nor.h
>> +++ b/include/linux/mtd/spi-nor.h
>> @@ -121,6 +121,10 @@
>>  #define SPINOR_OP_BRWR  0x17/* Bank register write */
>>  #define SPINOR_OP_BRRD  0x16/* Bank register read */
>>  #define SPINOR_OP_CLSR  0x30/* Clear status register 1 */
>> +#define SPINOR_OP_RDAR  0x65/* Read any register */
>> +#define SPINOR_OP_WRAR  0x71/* Write any register */
>> +#define SPINOR_REG_ADDR_STR1V   0x0080
>> +#define SPINOR_REG_ADDR_CFR1V   0x0082
> 
> These two defines are not used by this patch. Remove them from this one 
> and add them to the one that actually uses them for the first time.
> 
I will fix it, thank you.

> With this fixed,
> 
> Reviewed-by: Pratyush Yadav 
> 
>>  
>>  /* Used for Micron flashes only. */
>>  #define SPINOR_OP_RD_EVCR  0x65/* Read EVCR register */
>> -- 
>> 2.25.1
>>
> 

Best Regards,
Takahiro


Re: [PATCH v4 2/9] mtd: spi-nor-ids: Add Cypress s25hl-t/s25hs-t

2021-02-08 Thread Takahiro Kuwano
Hi Pratyush,

On 1/30/2021 3:08 AM, Pratyush Yadav wrote:
> On 28/01/21 01:36PM, tkuw584...@gmail.com wrote:
>> From: Takahiro Kuwano 
>>
>> The S25HL-T/S25HS-T family is the Cypress Semper Flash with Quad SPI.
>> The datasheets can be found in the following links.
>>
>> https://www.cypress.com/file/424146/download (256Mb/512Mb/1Gb, single die)
>> https://www.cypress.com/file/499246/download (2Gb/4Gb, dual/quad die)
>>
>> Tested 512Mb/1Gb/2Gb parts on Xilinx Zynq-7000 FPGA board.
> 
> Why not test the 256 Mb and 4 Gb parts as well? They might work 
> perfectly well but adding support for untested hardware sounds wrong to 
> me.

The 256Mb and 4Gb parts are not yet officially sampled, although they are
described in the datasheet. They should work like other tested ones, but
as you commented, only tested devices should be added. I will remove 256Mb
and 4Gb in v5.

>  
>> Signed-off-by: Takahiro Kuwano 
>> ---
>>  drivers/mtd/spi/spi-nor-ids.c | 36 +++
>>  1 file changed, 36 insertions(+)
>>
>> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
>> index 5bd5dd3003..b78d13e980 100644
>> --- a/drivers/mtd/spi/spi-nor-ids.c
>> +++ b/drivers/mtd/spi/spi-nor-ids.c
>> @@ -217,6 +217,42 @@ const struct flash_info spi_nor_ids[] = {
>>  { INFO("s25fl208k",  0x014014,  0,  64 * 1024,  16, SECT_4K | 
>> SPI_NOR_DUAL_READ) },
>>  { INFO("s25fl064l",  0x016017,  0,  64 * 1024, 128, SECT_4K | 
>> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>>  { INFO("s25fl128l",  0x016018,  0,  64 * 1024, 256, SECT_4K | 
>> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
>> +
>> +/* S25HL/HS-T (Semper Flash with Quad SPI) Family has overlaid 4KB
> 
> Nitpick: Please leave first line of multi-line comments blank like so:
> 
> /*
>  * S25HL/HS-T (Semper Flash with Quad SPI) Family has overlaid 4KB
>  * ...
>  */
> 

I will fix it.

>> + * sectors at top and/or bottom, depending on the device configuration.
>> + * To support this, an erase hook makes overlaid sectors appear as
>> + * uniform sectors.
>> + */
>> +{ INFO6("s25hl256t",  0x342a19, 0x0f0390, 256 * 1024, 128,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
>> +{ INFO6("s25hl512t",  0x342a1a, 0x0f0390, 256 * 1024, 256,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
>> +{ INFO6("s25hl01gt",  0x342a1b, 0x0f0390, 256 * 1024, 512,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
>> +{ INFO6("s25hl02gt",  0x342a1c, 0x0f0090, 256 * 1024, 1024,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
>> +{ INFO6("s25hl04gt",  0x342a1d, 0x0f0090, 256 * 1024, 2048,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
>> +{ INFO6("s25hs256t",  0x342b19, 0x0f0390, 256 * 1024, 128,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
>> +{ INFO6("s25hs512t",  0x342b1a, 0x0f0390, 256 * 1024, 256,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
>> +{ INFO6("s25hs01gt",  0x342b1b, 0x0f0390, 256 * 1024, 512,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
>> +{ INFO6("s25hs02gt",  0x342b1c, 0x0f0090, 256 * 1024, 1024,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
>> +{ INFO6("s25hs04gt",  0x342b1d, 0x0f0090, 256 * 1024, 2048,
>> +SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES |
>> +USE_CLSR) },
> 
> The datasheets you have linked do not specify a mapping between device 
> ID and part number. So I can't verify that you are using the correct IDs 
> here. But I'll trust you to get them right :-)
> 

Thank you :-)

> With the above comment addressed and 256 Mb and 4 Gb parts tested, 
> please add
> 
> Reviewed-by: Pratyush Yadav 
> 
>>  #endif
>>  #ifdef CONFIG_SPI_FLASH_SST /* SST */
>>  /* SST -- large erase sizes are "overlays", "sectors" are 4K */
>> -- 
>> 2.25.1
>>
> 

Best Regards,
Takahiro


Re: [PATCH 1/1] sandbox: allow cross-compiling sandbox

2021-02-08 Thread AKASHI Takahiro
On Mon, Feb 08, 2021 at 09:29:43PM -0700, Simon Glass wrote:
> Hi Heinrich,
> 
> On Mon, 8 Feb 2021 at 15:06, Heinrich Schuchardt  wrote:
> >
> > UEFI test files like helloworld.efi require an architecture specific
> > PE-COFF header.
> 
> architecture-specific
> 
> >
> > For non-sandbox the PE-COFF header is chosen by the target architecture.
> > For the sandbox we use the host architecture. This is not helpful for cross
> > compiling. Allow specifying the target architecture of the sandbox via
> > environment variable MK_ARCH, e.g.
> 
> What exactly is the target arch? Is the the one that sandbox is
> running on, or something else?
> 
> >
> > make sandbox_defconfig NO_SDL=1
> > CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make
> >
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >  Makefile |  2 +-
> >  doc/arch/sandbox.rst | 14 ++
> >  2 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 23dd11f723..286e5148ae 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR)
> >
> >  # Determine host architecture
> >  include include/host_arch.h
> > -MK_ARCH="${shell uname -m}"
> > +MK_ARCH?="${shell uname -m}"
> >  unexport HOST_ARCH
> >  ifeq ("x86_64", $(MK_ARCH))
> >export HOST_ARCH=$(HOST_ARCH_X86_64)
> > diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst
> > index 60ee1e0741..0dd9edc8cb 100644
> > --- a/doc/arch/sandbox.rst
> > +++ b/doc/arch/sandbox.rst
> > @@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts.
> >
> >  Note that standalone/API support is not available at present.
> >
> > +Cross compiling
> > +---
> > +
> > +When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y the target
> > +architecture must be specified using the MK_ARCH environment variable 
> > using one
> > +of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64, e.g.
> 
> OK, but what is the target architecture? I'm just not sure from your
> comments what this actually means.

I'm not quite sure if it is very useful to be able to cross-compile
the sandbox application. But any way, it is not very convenient
to always enforce users to explicitly specify "target" architecture.
How about trying the following first?
$(CC) -v | grep "Target: " | sed -e 's/-*$//'

It will give us a hint about the architecture.
("--print-multiarch" shows a similar triple, but this option won't
work for some pre-built gcc, like aarch64 gcc from Arm.)

> Does MK mean make?

I prefer another name for clarity.

-Takahiro Akashi

> 
> > +
> > +.. code-block:: bash
> > +
> > +NO_SDL=1 make sandbox_defconfig
> > +CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make
> > +
> > +NO_SDL=1 was chosen in the example to remove the dependency on the SDL 
> > library.
> > +The graphical console will not be available.
> >
> >  Prerequisites
> >  -
> > --
> > 2.30.0
> >
> 
> Regards,
> Simon


[PATCH v1 1/1] drivers: mmc: iproc_sdhci: enable HS200 mode

2021-02-08 Thread Rayagonda Kokatanur
From: Bharat Gooty 

Add tuning functionality which is needed for HS200 mode.
For HS200, program the correct needed 1.8 voltage

Signed-off-by: Bharat Gooty 
Signed-off-by: Rayagonda Kokatanur 
---
 drivers/mmc/iproc_sdhci.c | 88 +++
 1 file changed, 79 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/iproc_sdhci.c b/drivers/mmc/iproc_sdhci.c
index f931e4b3c1..360ea01e21 100644
--- a/drivers/mmc/iproc_sdhci.c
+++ b/drivers/mmc/iproc_sdhci.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include "mmc_private.h"
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -139,17 +140,87 @@ static void sdhci_iproc_writeb(struct sdhci_host *host, 
u8 val, int reg)
 
 static int sdhci_iproc_set_ios_post(struct sdhci_host *host)
 {
-   u32 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+   struct mmc *mmc = (struct mmc *)host->mmc;
+   u32 ctrl;
 
-   /* Reset UHS mode bits */
-   ctrl &= ~SDHCI_CTRL_UHS_MASK;
+   if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
+   ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+   ctrl |= SDHCI_CTRL_VDD_180;
+   sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
+   }
 
-   if (host->mmc->ddr_mode)
-   ctrl |= UHS_DDR50_BUS_SPEED;
+   sdhci_set_uhs_timing(host);
+   return 0;
+}
 
+static void sdhci_start_tuning(struct sdhci_host *host)
+{
+   u32 ctrl;
+
+   ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+   ctrl |= SDHCI_CTRL_EXEC_TUNING;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
-   return 0;
+   sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE);
+   sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE);
+}
+
+static void sdhci_end_tuning(struct sdhci_host *host)
+{
+   /* Enable only interrupts served by the SD controller */
+   sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK,
+SDHCI_INT_ENABLE);
+   /* Mask all sdhci interrupt sources */
+   sdhci_writel(host, 0x0, SDHCI_SIGNAL_ENABLE);
+}
+
+static int sdhci_iproc_execute_tuning(struct mmc *mmc, u8 opcode)
+{
+#define MAX_TUNING_LOOP40
+   struct mmc_cmd cmd;
+   u32 ctrl;
+   u32 blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 64);
+   struct sdhci_host *host = dev_get_priv(mmc->dev);
+   char tuning_loop_counter = MAX_TUNING_LOOP;
+   int ret = 0;
+
+   sdhci_start_tuning(host);
+
+   cmd.cmdidx = opcode;
+   cmd.resp_type = MMC_RSP_R1;
+   cmd.cmdarg = 0;
+
+   if (opcode == MMC_CMD_SEND_TUNING_BLOCK_HS200 && mmc->bus_width == 8)
+   blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 128);
+
+   sdhci_writew(host, blocksize, SDHCI_BLOCK_SIZE);
+   sdhci_writew(host, 1, SDHCI_BLOCK_COUNT);
+   sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
+
+   do {
+   mmc_send_cmd(mmc, , NULL);
+   if (opcode == MMC_CMD_SEND_TUNING_BLOCK)
+   udelay(1);
+
+   ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+
+   if (tuning_loop_counter-- == 0)
+   break;
+
+   } while (ctrl & SDHCI_CTRL_EXEC_TUNING);
+
+   if (tuning_loop_counter < 0 || (!(ctrl & SDHCI_CTRL_TUNED_CLK))) {
+   ctrl &= ~(SDHCI_CTRL_TUNED_CLK | SDHCI_CTRL_EXEC_TUNING);
+   sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL2);
+   printf("%s:Tuning failed, opcode = 0x%02x\n", __func__, opcode);
+   ret = -EIO;
+   }
+
+   udelay(1);
+
+   sdhci_end_tuning(host);
+
+   return ret;
 }
 
 static struct sdhci_ops sdhci_platform_ops = {
@@ -162,6 +233,7 @@ static struct sdhci_ops sdhci_platform_ops = {
.write_b = sdhci_iproc_writeb,
 #endif
.set_ios_post = sdhci_iproc_set_ios_post,
+   .platform_execute_tuning = sdhci_iproc_execute_tuning,
 };
 
 struct iproc_sdhci_plat {
@@ -189,9 +261,7 @@ static int iproc_sdhci_probe(struct udevice *dev)
 
host->name = dev->name;
host->ioaddr = dev_read_addr_ptr(dev);
-   host->voltages = MMC_VDD_165_195 |
-MMC_VDD_32_33 | MMC_VDD_33_34;
-   host->quirks = SDHCI_QUIRK_BROKEN_VOLTAGE | SDHCI_QUIRK_BROKEN_R1B;
+   host->quirks = SDHCI_QUIRK_BROKEN_R1B;
host->host_caps = MMC_MODE_DDR_52MHz;
host->index = fdtdec_get_uint(gd->fdt_blob, node, "index", 0);
host->ops = _platform_ops;
-- 
2.17.1



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PATCH u-boot-dm + u-boot-spi 1/6] dm: add non-translating version of ofnode_get_addr_size_index

2021-02-08 Thread Simon Glass
Hi Marek,

On Mon, 8 Feb 2021 at 19:49, Marek Behún  wrote:
>
> Add functions ofnode_get_addr_size_index_notrans(), which is a
> non-translating version of ofnode_get_addr_size_index().
>
> Some addresses are not meant to be translated, for example those of MTD
> fixed-partitions.
>
> Signed-off-by: Marek Behún 
> Cc: Dario Binacchi 
> Cc: Simon Glass 
> ---
>  drivers/core/ofnode.c | 19 ---
>  include/dm/ofnode.h   | 17 +
>  2 files changed, 33 insertions(+), 3 deletions(-)

Please add a test for this in test/dm/ofnode.c

Regards,
Simon


Re: [PATCH 1/1] sandbox: allow cross-compiling sandbox

2021-02-08 Thread Simon Glass
Hi Heinrich,

On Mon, 8 Feb 2021 at 15:06, Heinrich Schuchardt  wrote:
>
> UEFI test files like helloworld.efi require an architecture specific
> PE-COFF header.

architecture-specific

>
> For non-sandbox the PE-COFF header is chosen by the target architecture.
> For the sandbox we use the host architecture. This is not helpful for cross
> compiling. Allow specifying the target architecture of the sandbox via
> environment variable MK_ARCH, e.g.

What exactly is the target arch? Is the the one that sandbox is
running on, or something else?

>
> make sandbox_defconfig NO_SDL=1
> CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  Makefile |  2 +-
>  doc/arch/sandbox.rst | 14 ++
>  2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 23dd11f723..286e5148ae 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR)
>
>  # Determine host architecture
>  include include/host_arch.h
> -MK_ARCH="${shell uname -m}"
> +MK_ARCH?="${shell uname -m}"
>  unexport HOST_ARCH
>  ifeq ("x86_64", $(MK_ARCH))
>export HOST_ARCH=$(HOST_ARCH_X86_64)
> diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst
> index 60ee1e0741..0dd9edc8cb 100644
> --- a/doc/arch/sandbox.rst
> +++ b/doc/arch/sandbox.rst
> @@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts.
>
>  Note that standalone/API support is not available at present.
>
> +Cross compiling
> +---
> +
> +When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y the target
> +architecture must be specified using the MK_ARCH environment variable using 
> one
> +of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64, e.g.

OK, but what is the target architecture? I'm just not sure from your
comments what this actually means.

Does MK mean make?

> +
> +.. code-block:: bash
> +
> +NO_SDL=1 make sandbox_defconfig
> +CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make
> +
> +NO_SDL=1 was chosen in the example to remove the dependency on the SDL 
> library.
> +The graphical console will not be available.
>
>  Prerequisites
>  -
> --
> 2.30.0
>

Regards,
Simon


Re: Contributor meeting notes 19-Jan-21

2021-02-08 Thread Simon Glass
Hi Stefano.

On Thu, 28 Jan 2021 at 02:24, Stefano Babic  wrote:
>
> Hi Simon,
>
> On 27.01.21 22:31, Simon Glass wrote:
> > Hi Stefano,
> >
> > Thank you for the offer!
> >
> > What are the advantages of hosting the meeting on a private server?
>
> No, I do not see any special advantage - I will just be happy (as Marek)
> if we can nuse a FOSS project as Jitsi for communication. IMHO it is ok
> to use the public server provided by jitsi.

OK well we tried a jitsi call last week and it seemed to work fine.

Regards,
Simon


Re: [PATCH v4 10/16] dm: gpio: Add a way to update flags

2021-02-08 Thread Simon Glass
Hi Patrick,

On Mon, 8 Feb 2021 at 10:33, Patrick DELAUNAY
 wrote:
>
> Hi Simon,
>
> 2 minor remarks,
>
> On 2/5/21 5:22 AM, Simon Glass wrote:
> > It is convenient to be able to adjust some of the flags for a GPIO while
> > leaving others alone. Add a function for this.
> >
> > Update dm_gpio_set_dir_flags() to make use of this.
> >
> > Also update dm_gpio_set_value() to use this also, since this allows the
> > open-drain / open-source features to be implemented directly in the
> > driver, rather than using the uclass workaround.
> >
> > Update the sandbox tests accordingly. This involves a lot of changes to
> > dm_test_gpio_opendrain_opensource() since we no-longer have the direciion
> > being reported differently depending on the open drain/open source flags.
> >
> > Also update the STM32 drivers to let the uclass handle the active low/high
> > logic.
> >
> > Drop the GPIOD_FLAGS_OUTPUT() macro which is no-longer used.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v4:
> > - Update dm_gpio_set_dir_flags() to clear direction flags first
> >
> > Changes in v3:
> > - Incorporate GPIOD_FLAGS_OUTPUT() changes from Patrick Delaunay
> >
> >   drivers/gpio/gpio-uclass.c  |  75 ++
> >   drivers/gpio/stm32_gpio.c   |   3 +-
> >   drivers/pinctrl/pinctrl-stmfx.c |   5 +-
> >   include/asm-generic/gpio.h  |  31 ++--
> >   test/dm/gpio.c  | 132 
> >   5 files changed, 203 insertions(+), 43 deletions(-)
>
> (...)
>
> > diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c
> > index c2d7046c0dd..125c237551c 100644
> > --- a/drivers/gpio/stm32_gpio.c
> > +++ b/drivers/gpio/stm32_gpio.c
> > @@ -203,12 +203,13 @@ static int stm32_gpio_set_flags(struct udevice *dev, 
> > unsigned int offset,
> >   return idx;
> >
> >   if (flags & GPIOD_IS_OUT) {
> > - int value = GPIOD_FLAGS_OUTPUT(flags);
> > + bool value = flags & GPIOD_IS_OUT_ACTIVE;
>
> here the bool variable valeu can be 0 or GPIOD_IS_OUT_ACTIVE = BIT(4),
> so it should have
>
> + bool value = !!(flags & GPIOD_IS_OUT_ACTIVE);
>
> or
>
> + int value = flags & GPIOD_IS_OUT_ACTIVE;
>
> PS: not functional impact as
>
> #define BSRR_BIT(gpio_pin, value)BIT((gpio_pin) + (value ? 0 : 16))
>
> >
> >   if (flags & GPIOD_OPEN_DRAIN)
> >   stm32_gpio_set_otype(regs, idx, STM32_GPIO_OTYPE_OD);
> >   else
> >   stm32_gpio_set_otype(regs, idx, STM32_GPIO_OTYPE_PP);
> > +
> >   stm32_gpio_set_moder(regs, idx, STM32_GPIO_MODE_OUT);
> >   writel(BSRR_BIT(idx, value), >bsrr);
> >
> > diff --git a/drivers/pinctrl/pinctrl-stmfx.c 
> > b/drivers/pinctrl/pinctrl-stmfx.c
> > index 8ddbc3dc281..711b1a5d8c4 100644
> > --- a/drivers/pinctrl/pinctrl-stmfx.c
> > +++ b/drivers/pinctrl/pinctrl-stmfx.c
> > @@ -169,6 +169,8 @@ static int stmfx_gpio_set_flags(struct udevice *dev, 
> > unsigned int offset,
> >   int ret = -ENOTSUPP;
> >
> >   if (flags & GPIOD_IS_OUT) {
> > + bool value = flags & GPIOD_IS_OUT_ACTIVE;
> > +
>
>
> same here
>
> +   int value = flags & GPIOD_IS_OUT_ACTIVE;
> or
> +   bool value = !!(flags & GPIOD_IS_OUT_ACTIVE);

The bool type should do this automatically. I tested this and it seems
to do the right thing.


>
>
> But no impact
>
>
> >   if (flags & GPIOD_OPEN_SOURCE)
> >   return -ENOTSUPP;
> >   if (flags & GPIOD_OPEN_DRAIN)
> > @@ -177,8 +179,7 @@ static int stmfx_gpio_set_flags(struct udevice *dev, 
> > unsigned int offset,
> >   ret = stmfx_conf_set_type(dev, offset, 1);
> >   if (ret)
> >   return ret;
> > - ret = stmfx_gpio_direction_output(dev, offset,
> > -   GPIOD_FLAGS_OUTPUT(flags));
> > + ret = stmfx_gpio_direction_output(dev, offset, value);
> >   } else if (flags & GPIOD_IS_IN) {
> >   ret = stmfx_gpio_direction_input(dev, offset);
> >   if (ret)
>
>
> (...)
>
>
> With the 2 remarks
>
> Reviewed-by: Patrick Delaunay 
> Tested-by: Patrick Delaunay 
>

Regards,
SImon


Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver

2021-02-08 Thread Simon Glass
Hi Heinrich,

On Mon, 8 Feb 2021 at 15:18, Heinrich Schuchardt  wrote:
>
> On 2/8/21 6:56 PM, Heinrich Schuchardt wrote:
> > On 2/8/21 6:08 PM, Simon Glass wrote:
> >> HI Marek,
> >>
> >> On Mon, 8 Feb 2021 at 09:10, Marek Szyprowski
> >>  wrote:
> >>>
> >>> Hi Simon,
> >>>
> >>> On 06.02.2021 17:21, Simon Glass wrote:
>  On Thu, 4 Feb 2021 at 03:36, Marek Szyprowski
>   wrote:
> > ...
> > Could you give me a bit more hints or point where to start? I've tried
> > to build sandbox, but it fails for v2021.01 release (I've did make
> > sandbox_defconfig && make all). I assume I would need to add adc and
> > adc-keys devices to some sandbox dts and some code triggering and
> > checking the key values, but that's all I know now.
>  Well you do need to be able to build sandbox or you will get
>  nowhere...what error did you get? Once we understand what went wrong
>  we can update the docs. Maybe it is missing a dependency.
> >>>
> >>> $ gcc --version
> >>> gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
> >>> Copyright (C) 2017 Free Software Foundation, Inc.
> >>> This is free software; see the source for copying conditions. There
> >>> is NO
> >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> >>> PURPOSE.
> >>>
> >>> $ git checkout v2021.01
> >>>
> >>> $ make sandbox_defconfig
> >>> #
> >>> # configuration written to .config
> >>> #
> >>>
> >>> $ make
> >>> scripts/kconfig/conf  --syncconfig Kconfig
> >>> CFG u-boot.cfg
> >>> GEN include/autoconf.mk
> >>> GEN include/autoconf.mk.dep
> >>> CFGCHK  u-boot.cfg
> >>> UPD include/generated/timestamp_autogenerated.h
> >>> HOSTCC  tools/mkenvimage.o
> >>> HOSTLD  tools/mkenvimage
> >>> HOSTCC  tools/fit_image.o
> >>> HOSTCC  tools/image-host.o
> >>> HOSTCC  tools/dumpimage.o
> >>> HOSTLD  tools/dumpimage
> >>> HOSTCC  tools/mkimage.o
> >>> HOSTLD  tools/mkimage
> >>> HOSTLD  tools/fit_info
> >>> HOSTLD  tools/fit_check_sign
> >>>
> >>> ...
> >>>
> >>> CC  arch/sandbox/cpu/cpu.o
> >>> In file included from include/common.h:26:0,
> >>>from arch/sandbox/cpu/cpu.c:6:
> >>> include/asm/global_data.h:112:58: warning: call-clobbered register used
> >>> for global register variable
> >>>#define DECLARE_GLOBAL_DATA_PTR  register volatile gd_t *gd asm
> >>> ("r9")
> >>> ^
> >>> include/dm/of.h:86:1: note: in expansion of macro
> >>> ‘DECLARE_GLOBAL_DATA_PTR’
> >>>DECLARE_GLOBAL_DATA_PTR;
> >>
> >> This is pretty mysterious. Are you sure you are using an x86_64 machine?
> >
> > r9 relates to ARMv7.
> >
> > You have to unset CROSS_COMPILE when you build the sandbox.
> >
> > The sandbox runs fine on aarch64.
> >
> > There are a bunch of errors currently when building on 32bit
> > architectures. Simon has a lot of patches pending.
>
> Hello Simon,
>
> it was your patch
>
> 091401131085 ("command: Remove the cmd_tbl_t typedef") 2020-05-10
>
> that broke building the sandbox on ARMv7.

Oh dear.

>
> Once your 32bit corrections are merged we should try to add
> cross-compiling the sandbox for aarch64 and armv7 to Gitlab CI.

Yes, what we don't test doesn't work :-)

Regards,
Simon


[PATCH v9] Add support for stack-protector

2021-02-08 Thread Joel Peshkin
Add support for stack protector for UBOOT, SPL, and TPL
as well as new pytest for stackprotector

Signed-off-by: Joel Peshkin 
---
Cc: Simon Glass 
Cc: Heinrich Schuchardt 

Changes for v9:
   - Fix pytest script post-test reboot
Changes for v8:
   - Fix commit message
   - Force canary to UL type
Changes for v7:
   - Fix commit message
   - add __builtin_extract_return_addr() calls
Changes for v6:
   - Fix commit message
Changes for v5:
   - Rebase
Changes for v4:
   - Exclude EFI from stackprotector
   - Cleanups of extra includes and declaration
Changes for v3:
   - Move test command to cmd/
   - Update Kconfig names and depends
   - clean up default canary initialization
Changes for v2:
   - Add test command and corresponding config
   - Fixed incorrect description in Kconfig
   - Add unit test
---
 MAINTAINERS  |  7 +++
 Makefile |  5 +
 cmd/Kconfig  | 10 ++
 cmd/Makefile |  1 +
 cmd/stackprot_test.c | 21 +
 common/Kconfig   | 17 +
 common/Makefile  |  2 ++
 common/stackprot.c   | 19 +++
 configs/sandbox_defconfig| 14 +++---
 scripts/Makefile.spl |  6 ++
 test/py/tests/test_stackprotector.py | 15 +++
 11 files changed, 110 insertions(+), 7 deletions(-)
 create mode 100644 cmd/stackprot_test.c
 create mode 100644 common/stackprot.c
 create mode 100644 test/py/tests/test_stackprotector.py

diff --git a/MAINTAINERS b/MAINTAINERS
index 26dd254..d3971e8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1024,6 +1024,13 @@ F:   include/sqfs.h
 F: cmd/sqfs.c
 F: test/py/tests/test_fs/test_squashfs/
 
+STACKPROTECTOR
+M: Joel Peshkin 
+S: Maintained
+F: common/stackprot.c
+F: cmd/stackprot_test.c
+F: test/py/tests/test_stackprotector.py
+
 TARGET_BCMNS3
 M: Bharat Gooty 
 M: Rayagonda Kokatanur 
diff --git a/Makefile b/Makefile
index 902a976..65c5cb8 100644
--- a/Makefile
+++ b/Makefile
@@ -677,7 +677,12 @@ else
 KBUILD_CFLAGS  += -O2
 endif
 
+ifeq ($(CONFIG_STACKPROTECTOR),y)
+KBUILD_CFLAGS += $(call cc-option,-fstack-protector-strong)
+CFLAGS_EFI += $(call cc-option,-fno-stack-protector)
+else
 KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
+endif
 KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks)
 
 # disable stringop warnings in gcc 8+
diff --git a/cmd/Kconfig b/cmd/Kconfig
index da86a94..054b2f3 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2280,6 +2280,16 @@ config CMD_AVB
avb read_part_hex - read data from partition and output to stdout
avb write_part - write data to partition
avb verify - run full verification chain
+
+config CMD_STACKPROTECTOR_TEST
+   bool "Test command for stack protector"
+   depends on STACKPROTECTOR
+   default n
+   help
+ Enable stackprot_test command
+ The stackprot_test command will force a stack overrun to test
+ the stack smashing detection mechanisms.
+
 endmenu
 
 config CMD_UBI
diff --git a/cmd/Makefile b/cmd/Makefile
index 5b3400a..1d7afea 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_CMD_SPI) += spi.o
 obj-$(CONFIG_CMD_STRINGS) += strings.o
 obj-$(CONFIG_CMD_SMC) += smccc.o
 obj-$(CONFIG_CMD_SYSBOOT) += sysboot.o pxe_utils.o
+obj-$(CONFIG_CMD_STACKPROTECTOR_TEST) += stackprot_test.o
 obj-$(CONFIG_CMD_TERMINAL) += terminal.o
 obj-$(CONFIG_CMD_TIME) += time.o
 obj-$(CONFIG_CMD_TIMER) += timer.o
diff --git a/cmd/stackprot_test.c b/cmd/stackprot_test.c
new file mode 100644
index 000..6ad287e
--- /dev/null
+++ b/cmd/stackprot_test.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Copyright 2021 Broadcom
+ */
+
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int do_test_stackprot_fail(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+   char a[128];
+
+   memset(a, 0xa5, 512);
+   return 0;
+}
+
+U_BOOT_CMD(stackprot_test, 1, 1, do_test_stackprot_fail,
+  "test stack protector fail", "");
diff --git a/common/Kconfig b/common/Kconfig
index 2bce8c9..6a94045 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -595,6 +595,23 @@ config TPL_HASH
  and the algorithms it supports are defined in common/hash.c. See
  also CMD_HASH for command-line access.
 
+config STACKPROTECTOR
+   bool "Stack Protector buffer overflow detection"
+   default n
+   help
+ Enable stack smash detection through compiler's stack-protector
+ canary logic
+
+config SPL_STACKPROTECTOR
+   bool "Stack Protector buffer overflow detection for SPL"
+   depends on STACKPROTECTOR && SPL
+   default n
+
+config TPL_STACKPROTECTOR
+   bool "Stack Protector buffer overflow detection for TPL"
+   

Re: [PATCH 5/6] usb: xhci-dwc3: Add support for clocks/resets

2021-02-08 Thread Samuel Holland
On 2/8/21 7:42 PM, Andre Przywara wrote:
> On Sun,  7 Feb 2021 23:57:23 -0600
> Samuel Holland  wrote:
> 
> (CC:ing Simon and Kever)
> 
>> Some platforms, like the Allwinner H6, do not have a separate glue layer
>> around the dwc3. Instead, they rely on the clocks/resets/phys referenced
>> from the dwc3 DT node itself. Add support for enabling the clocks/resets
>> referenced from the dwc3 DT node.
>>
>> Signed-off-by: Samuel Holland 
> 
> That looks alright on a first glance, but have you checked how this
> interacts with and relates to dwc3-of-simple.c?
> This seems to do similar things?

Yes, they do the same thing, but with a different DT binding.
dwc3-of-simple binds to, and expects the clocks/resets to be in, the DT
node _containing_ the snps,dwc3 node. The xhci-dwc3 driver binds to the
snps,dwc3 node itself. This is why other platforms were not affected by
the change

I don't think there's any way to attach two drivers to the same DT node
at the same time, so we cannot take advantage of the dwc3-of-simple code
without rearranging the device tree.

Interestingly, Linux has supported the H6 in its version of
dwc3-of-simple since commit e362098f0e12 ("usb: dwc3: of-simple: Add
compatible for Allwinner H6 platform"). But the device tree ended up not
using a glue layer node or this compatible.

Maybe a better forward is to modify the device tree to be more similar
to most other platforms? On the other hand, as you found, Hisilicon and
Unipher platforms use the same binding as Allwinner. It's unfortunate
that there are two distinct but equally "correct" ways to represent the
same hardware.

Cheers,
Samuel


[PATCH u-boot-dm + u-boot-spi 5/6] mtd: remove mtd_probe function

2021-02-08 Thread Marek Behún
The device_probe() function does the same thing as mtd_probe() and
mtd_probe() is only used in mtd_probe_uclass_mtd_devs(), where the
probing can be made simpler by using uclass_foreach_dev_probe macro.

Signed-off-by: Marek Behún 
Cc: Jagan Teki 
Cc: Priyanka Jain 
Cc: Simon Glass 
Cc: Heiko Schocher 
Cc: Jagan Teki 
---
 drivers/mtd/mtd-uclass.c | 15 ---
 drivers/mtd/mtd_uboot.c  |  9 +++--
 include/mtd.h|  1 -
 3 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/mtd-uclass.c b/drivers/mtd/mtd-uclass.c
index 9f5f672ba3..4ab84de553 100644
--- a/drivers/mtd/mtd-uclass.c
+++ b/drivers/mtd/mtd-uclass.c
@@ -9,21 +9,6 @@
 #include 
 #include 
 
-/**
- * mtd_probe - Probe the device @dev if not already done
- *
- * @dev: U-Boot device to probe
- *
- * @return 0 on success, an error otherwise.
- */
-int mtd_probe(struct udevice *dev)
-{
-   if (device_active(dev))
-   return 0;
-
-   return device_probe(dev);
-}
-
 /*
  * Implement a MTD uclass which should include most flash drivers.
  * The uclass private is pointed to mtd_info.
diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c
index 7fb72eb1f4..865e9ae4cb 100644
--- a/drivers/mtd/mtd_uboot.c
+++ b/drivers/mtd/mtd_uboot.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -105,13 +106,9 @@ int mtd_search_alternate_name(const char *mtdname, char 
*altname,
 static void mtd_probe_uclass_mtd_devs(void)
 {
struct udevice *dev;
-   int idx = 0;
 
-   /* Probe devices with DM compliant drivers */
-   while (!uclass_find_device(UCLASS_MTD, idx, ) && dev) {
-   mtd_probe(dev);
-   idx++;
-   }
+   uclass_foreach_dev_probe(UCLASS_MTD, dev)
+   ;
 }
 #else
 static void mtd_probe_uclass_mtd_devs(void) { }
diff --git a/include/mtd.h b/include/mtd.h
index b0f8693386..b569331edb 100644
--- a/include/mtd.h
+++ b/include/mtd.h
@@ -8,7 +8,6 @@
 
 #include 
 
-int mtd_probe(struct udevice *dev);
 int mtd_probe_devices(void);
 
 void board_mtdparts_default(const char **mtdids, const char **mtdparts);
-- 
2.26.2



[PATCH u-boot-dm + u-boot-spi 4/6] mtd: spi-nor: fill-in mtd->dev member

2021-02-08 Thread Marek Behún
Fill in mtd->dev member with nor->dev.

This can be used by MTD OF partition parser.

Signed-off-by: Marek Behún 
Cc: Jagan Teki 
Cc: Priyanka Jain 
Cc: Simon Glass 
Cc: Heiko Schocher 
Cc: Jagan Teki 
---
 drivers/mtd/spi/sf_mtd.c   | 1 +
 drivers/mtd/spi/spi-nor-core.c | 1 +
 drivers/mtd/spi/spi-nor-tiny.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
index 94854fbfc4..04de868080 100644
--- a/drivers/mtd/spi/sf_mtd.c
+++ b/drivers/mtd/spi/sf_mtd.c
@@ -125,6 +125,7 @@ int spi_flash_mtd_register(struct spi_flash *flash)
 
sf_mtd_info.size = flash->size;
sf_mtd_info.priv = flash;
+   sf_mtd_info.dev = flash->dev;
 
/* Only uniform flash devices for now */
sf_mtd_info.numeraseregions = 0;
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index ef426dac02..57b7fa3b37 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2532,6 +2532,7 @@ int spi_nor_scan(struct spi_nor *nor)
 
if (!mtd->name)
mtd->name = info->name;
+   mtd->dev = nor->dev;
mtd->priv = nor;
mtd->type = MTD_NORFLASH;
mtd->writesize = 1;
diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c
index 07c8c7b82b..80cc091469 100644
--- a/drivers/mtd/spi/spi-nor-tiny.c
+++ b/drivers/mtd/spi/spi-nor-tiny.c
@@ -751,6 +751,7 @@ int spi_nor_scan(struct spi_nor *nor)
return ret;
 
mtd->name = "spi-flash";
+   mtd->dev = nor->dev;
mtd->priv = nor;
mtd->type = MTD_NORFLASH;
mtd->writesize = 1;
-- 
2.26.2



[PATCH u-boot-dm + u-boot-spi 6/6] mtd: probe SPI NOR devices in mtd_probe_devices()

2021-02-08 Thread Marek Behún
In order for `mtd list` U-Boot command to list SPI NOR devices without
the need to run `sf probe` before, we have to probe SPI NOR devices in
mtd_probe_devices().

Signed-off-by: Marek Behún 
Cc: Jagan Teki 
Cc: Priyanka Jain 
Cc: Simon Glass 
Cc: Heiko Schocher 
Cc: Jagan Teki 
---
 drivers/mtd/mtd_uboot.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c
index 865e9ae4cb..5dc3a3351b 100644
--- a/drivers/mtd/mtd_uboot.c
+++ b/drivers/mtd/mtd_uboot.c
@@ -114,6 +114,18 @@ static void mtd_probe_uclass_mtd_devs(void)
 static void mtd_probe_uclass_mtd_devs(void) { }
 #endif
 
+#if IS_ENABLED(CONFIG_DM_SPI_FLASH) && IS_ENABLED(CONFIG_SPI_FLASH_MTD)
+static void mtd_probe_uclass_spi_nor_devs(void)
+{
+   struct udevice *dev;
+
+   uclass_foreach_dev_probe(UCLASS_SPI_FLASH, dev)
+   ;
+}
+#else
+static void mtd_probe_uclass_spi_nor_devs(void) { }
+#endif
+
 #if defined(CONFIG_MTD_PARTITIONS)
 
 #define MTDPARTS_MAXLEN 512
@@ -309,6 +321,7 @@ int mtd_probe_devices(void)
struct mtd_info *mtd;
 
mtd_probe_uclass_mtd_devs();
+   mtd_probe_uclass_spi_nor_devs();
 
/*
 * Check if mtdparts/mtdids changed, if the MTD dev list was updated
-- 
2.26.2



[PATCH u-boot-dm + u-boot-spi 2/6] mtd: add support for parsing partitions defined in OF

2021-02-08 Thread Marek Behún
Add support for parsing partitions defined in device-trees via the
`partitions` node with `fixed-partitions` compatible.

The `mtdparts`/`mtdids` mechanism takes precedence. If some partitions
are defined for a MTD device via this mechanism, the code won't register
partitions for that MTD device from OF, even if they are defined.

Signed-off-by: Marek Behún 
Cc: Simon Glass 
Cc: Heiko Schocher 
Cc: Jagan Teki 
---
 drivers/mtd/mtd_uboot.c | 106 +++-
 drivers/mtd/mtdpart.c   |  60 +++
 include/linux/mtd/mtd.h |   9 
 3 files changed, 131 insertions(+), 44 deletions(-)

diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c
index 9360d4ed17..7fb72eb1f4 100644
--- a/drivers/mtd/mtd_uboot.c
+++ b/drivers/mtd/mtd_uboot.c
@@ -197,53 +197,11 @@ static void mtd_del_all_parts(void)
} while (ret > 0);
 }
 
-int mtd_probe_devices(void)
+static int parse_mtdparts(const char *mtdparts, const char *mtdids)
 {
-   static char *old_mtdparts;
-   static char *old_mtdids;
-   const char *mtdparts = get_mtdparts();
-   const char *mtdids = get_mtdids();
-   const char *mtdparts_next = mtdparts;
+   const char *mtdparts_next;
struct mtd_info *mtd;
 
-   mtd_probe_uclass_mtd_devs();
-
-   /*
-* Check if mtdparts/mtdids changed, if the MTD dev list was updated
-* or if our previous attempt to delete existing partititions failed.
-* In any of these cases we want to update the partitions, otherwise,
-* everything is up-to-date and we can return 0 directly.
-*/
-   if ((!mtdparts && !old_mtdparts && !mtdids && !old_mtdids) ||
-   (mtdparts && old_mtdparts && mtdids && old_mtdids &&
-!mtd_dev_list_updated() && !mtd_del_all_parts_failed &&
-!strcmp(mtdparts, old_mtdparts) &&
-!strcmp(mtdids, old_mtdids)))
-   return 0;
-
-   /* Update the local copy of mtdparts */
-   free(old_mtdparts);
-   free(old_mtdids);
-   old_mtdparts = strdup(mtdparts);
-   old_mtdids = strdup(mtdids);
-
-   /*
-* Remove all old parts. Note that partition removal can fail in case
-* one of the partition is still being used by an MTD user, so this
-* does not guarantee that all old partitions are gone.
-*/
-   mtd_del_all_parts();
-
-   /*
-* Call mtd_dev_list_updated() to clear updates generated by our own
-* parts removal loop.
-*/
-   mtd_dev_list_updated();
-
-   /* If either mtdparts or mtdids is empty, then exit */
-   if (!mtdparts || !mtdids)
-   return 0;
-
/* Start the parsing by ignoring the extra 'mtdparts=' prefix, if any */
if (!strncmp(mtdparts, "mtdparts=", sizeof("mtdparts=") - 1))
mtdparts += 9;
@@ -342,6 +300,66 @@ int mtd_probe_devices(void)
put_mtd_device(mtd);
}
 
+   return 0;
+}
+
+int mtd_probe_devices(void)
+{
+   static char *old_mtdparts;
+   static char *old_mtdids;
+   const char *mtdparts = get_mtdparts();
+   const char *mtdids = get_mtdids();
+   struct mtd_info *mtd;
+
+   mtd_probe_uclass_mtd_devs();
+
+   /*
+* Check if mtdparts/mtdids changed, if the MTD dev list was updated
+* or if our previous attempt to delete existing partititions failed.
+* In any of these cases we want to update the partitions, otherwise,
+* everything is up-to-date and we can return 0 directly.
+*/
+   if ((!mtdparts && !old_mtdparts && !mtdids && !old_mtdids) ||
+   (mtdparts && old_mtdparts && mtdids && old_mtdids &&
+!mtd_dev_list_updated() && !mtd_del_all_parts_failed &&
+!strcmp(mtdparts, old_mtdparts) &&
+!strcmp(mtdids, old_mtdids)))
+   return 0;
+
+   /* Update the local copy of mtdparts */
+   free(old_mtdparts);
+   free(old_mtdids);
+   old_mtdparts = strdup(mtdparts);
+   old_mtdids = strdup(mtdids);
+
+   /*
+* Remove all old parts. Note that partition removal can fail in case
+* one of the partition is still being used by an MTD user, so this
+* does not guarantee that all old partitions are gone.
+*/
+   mtd_del_all_parts();
+
+   /*
+* Call mtd_dev_list_updated() to clear updates generated by our own
+* parts removal loop.
+*/
+   mtd_dev_list_updated();
+
+   /* If both mtdparts and mtdids are non-empty, parse */
+   if (mtdparts && mtdids) {
+   if (parse_mtdparts(mtdparts, mtdids) < 0)
+   printf("Failed parsing MTD partitions from 
mtdparts!\n");
+   }
+
+   /* Fallback to OF partitions */
+   mtd_for_each_device(mtd) {
+   if (list_empty(>partitions)) {
+   if (add_mtd_partitions_of(mtd) < 0)
+   printf("Failed parsing 

[PATCH u-boot-dm + u-boot-spi 3/6] mtd: spi-nor: allow registering multiple MTDs when DM is enabled

2021-02-08 Thread Marek Behún
Currently when the SPI_FLASH_MTD config option is enabled, only one SPI
can be registered as MTD at any time - it is the last one probed (since
with old non-DM model only one SPI NOR could be probed at any time).

When DM is enabled, allow for registering multiple SPI NORs as MTDs by
utilizing the nor->mtd structure, which is filled in by spi_nor_scan
anyway, instead of filling a separate struct mtd_info.

Signed-off-by: Marek Behún 
Cc: Jagan Teki 
Cc: Priyanka Jain 
Cc: Simon Glass 
Cc: Heiko Schocher 
Cc: Jagan Teki 
---
 drivers/mtd/spi/sf_internal.h |  4 ++--
 drivers/mtd/spi/sf_mtd.c  | 18 +-
 drivers/mtd/spi/sf_probe.c|  6 --
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 9ceff0e7c1..865955124c 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -77,14 +77,14 @@ extern const struct flash_info spi_nor_ids[];
 
 #if CONFIG_IS_ENABLED(SPI_FLASH_MTD)
 int spi_flash_mtd_register(struct spi_flash *flash);
-void spi_flash_mtd_unregister(void);
+void spi_flash_mtd_unregister(struct spi_flash *flash);
 #else
 static inline int spi_flash_mtd_register(struct spi_flash *flash)
 {
return 0;
 }
 
-static inline void spi_flash_mtd_unregister(void)
+static inline void spi_flash_mtd_unregister(struct spi_flash *flash)
 {
 }
 #endif
diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
index 987fac2501..94854fbfc4 100644
--- a/drivers/mtd/spi/sf_mtd.c
+++ b/drivers/mtd/spi/sf_mtd.c
@@ -10,6 +10,20 @@
 #include 
 #include 
 
+#if CONFIG_IS_ENABLED(DM_SPI_FLASH)
+
+int spi_flash_mtd_register(struct spi_flash *flash)
+{
+   return add_mtd_device(>mtd);
+}
+
+void spi_flash_mtd_unregister(struct spi_flash *flash)
+{
+   del_mtd_device(>mtd);
+}
+
+#else /* !CONFIG_IS_ENABLED(DM_SPI_FLASH) */
+
 static struct mtd_info sf_mtd_info;
 static bool sf_mtd_registered;
 static char sf_mtd_name[8];
@@ -123,7 +137,7 @@ int spi_flash_mtd_register(struct spi_flash *flash)
return ret;
 }
 
-void spi_flash_mtd_unregister(void)
+void spi_flash_mtd_unregister(struct spi_flash *flash)
 {
int ret;
 
@@ -146,3 +160,5 @@ void spi_flash_mtd_unregister(void)
printf("Failed to unregister MTD %s and the spi_flash object is going 
away: you're in deep trouble!",
   sf_mtd_info.name);
 }
+
+#endif /* !CONFIG_IS_ENABLED(DM_SPI_FLASH) */
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 6c87434867..3bf2ecd51a 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -84,7 +84,7 @@ struct spi_flash *spi_flash_probe(unsigned int busnum, 
unsigned int cs,
 void spi_flash_free(struct spi_flash *flash)
 {
if (CONFIG_IS_ENABLED(SPI_FLASH_MTD))
-   spi_flash_mtd_unregister();
+   spi_flash_mtd_unregister(flash);
 
spi_free_slave(flash->spi);
free(flash);
@@ -143,8 +143,10 @@ int spi_flash_std_probe(struct udevice *dev)
 
 static int spi_flash_std_remove(struct udevice *dev)
 {
+   struct spi_flash *flash = dev_get_uclass_priv(dev);
+
if (CONFIG_IS_ENABLED(SPI_FLASH_MTD))
-   spi_flash_mtd_unregister();
+   spi_flash_mtd_unregister(flash);
 
return 0;
 }
-- 
2.26.2



[PATCH u-boot-dm + u-boot-spi 1/6] dm: add non-translating version of ofnode_get_addr_size_index

2021-02-08 Thread Marek Behún
Add functions ofnode_get_addr_size_index_notrans(), which is a
non-translating version of ofnode_get_addr_size_index().

Some addresses are not meant to be translated, for example those of MTD
fixed-partitions.

Signed-off-by: Marek Behún 
Cc: Dario Binacchi 
Cc: Simon Glass 
---
 drivers/core/ofnode.c | 19 ---
 include/dm/ofnode.h   | 17 +
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 7a5f4c0a73..88266e2641 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -298,7 +298,8 @@ ofnode ofnode_get_by_phandle(uint phandle)
return node;
 }
 
-fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, fdt_size_t *size)
+static fdt_addr_t __ofnode_get_addr_size_index(ofnode node, int index,
+  fdt_size_t *size, bool translate)
 {
int na, ns;
 
@@ -316,7 +317,7 @@ fdt_addr_t ofnode_get_addr_size_index(ofnode node, int 
index, fdt_size_t *size)
 
ns = of_n_size_cells(ofnode_to_np(node));
 
-   if (IS_ENABLED(CONFIG_OF_TRANSLATE) &&
+   if (translate && IS_ENABLED(CONFIG_OF_TRANSLATE) &&
(ns > 0 || gd_size_cells_0())) {
return of_translate_address(ofnode_to_np(node), 
prop_val);
} else {
@@ -328,12 +329,24 @@ fdt_addr_t ofnode_get_addr_size_index(ofnode node, int 
index, fdt_size_t *size)
ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
return fdtdec_get_addr_size_fixed(gd->fdt_blob,
  ofnode_to_offset(node), "reg",
- index, na, ns, size, true);
+ index, na, ns, size,
+ translate);
}
 
return FDT_ADDR_T_NONE;
 }
 
+fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, fdt_size_t *size)
+{
+   return __ofnode_get_addr_size_index(node, index, size, true);
+}
+
+fdt_addr_t ofnode_get_addr_size_index_notrans(ofnode node, int index,
+ fdt_size_t *size)
+{
+   return __ofnode_get_addr_size_index(node, index, size, false);
+}
+
 fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
 {
fdt_size_t size;
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 5b088650d3..6ab6fc5586 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -487,6 +487,23 @@ int ofnode_read_size(ofnode node, const char *propname);
 phys_addr_t ofnode_get_addr_size_index(ofnode node, int index,
   fdt_size_t *size);
 
+/**
+ * ofnode_get_addr_size_index_notrans() - get an address/size from a node
+ *   based on index, without address
+ *   translation
+ *
+ * This reads the register address/size from a node based on index.
+ * The resulting address is not translated. Useful for example for on-disk
+ * addresses.
+ *
+ * @node: node to read from
+ * @index: Index of address to read (0 for first)
+ * @size: Pointer to size of the address
+ * @return address, or FDT_ADDR_T_NONE if not present or invalid
+ */
+phys_addr_t ofnode_get_addr_size_index_notrans(ofnode node, int index,
+  fdt_size_t *size);
+
 /**
  * ofnode_get_addr_index() - get an address from a node
  *
-- 
2.26.2



[PATCH u-boot-dm + u-boot-spi 0/6] Support SPI NORs and OF partitions in `mtd list`

2021-02-08 Thread Marek Behún
Hello,

this patchset adds support for U-Boot to parse MTD partitions from
device-tree, and also improves support for SPI NOR access via the `mtd`
command.

Marek

Cc: Tom Rini 
Cc: Dario Binacchi 
Cc: Jagan Teki 
Cc: Priyanka Jain 
Cc: Simon Glass 
Cc: Heiko Schocher 
Cc: Jagan Teki 

Marek Behún (6):
  dm: add non-translating version of ofnode_get_addr_size_index
  mtd: add support for parsing partitions defined in OF
  mtd: spi-nor: allow registering multiple MTDs when DM is enabled
  mtd: spi-nor: fill-in mtd->dev member
  mtd: remove mtd_probe function
  mtd: probe SPI NOR devices in mtd_probe_devices()

 drivers/core/ofnode.c  |  19 -
 drivers/mtd/mtd-uclass.c   |  15 
 drivers/mtd/mtd_uboot.c| 128 -
 drivers/mtd/mtdpart.c  |  60 
 drivers/mtd/spi/sf_internal.h  |   4 +-
 drivers/mtd/spi/sf_mtd.c   |  19 -
 drivers/mtd/spi/sf_probe.c |   6 +-
 drivers/mtd/spi/spi-nor-core.c |   1 +
 drivers/mtd/spi/spi-nor-tiny.c |   1 +
 include/dm/ofnode.h|  17 +
 include/linux/mtd/mtd.h|   9 +++
 include/mtd.h  |   1 -
 12 files changed, 206 insertions(+), 74 deletions(-)

-- 
2.26.2



[PATCH u-boot-marvell] ARM: dts: armada-385-turris-omnia: rename node in -u-boot.dtsi file

2021-02-08 Thread Marek Behún
The SPI NOR flash node name in main device tree for Turris Omnia is
called `spi-nor@0`.

Rename node spi-flash@0 in Turris Omnia's -u-boot.dtsi file to spi-nor@0
so that U-Boot does not try to probe the same SPI NOR device multiple
times.

Signed-off-by: Marek Behún 
Cc: Stefan Roese 
---
 arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi 
b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
index 1b46797583..af0655daaa 100644
--- a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
+++ b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
@@ -41,10 +41,7 @@
  {
u-boot,dm-pre-reloc;
 
-   spi-flash@0 {
-   compatible = "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <4000>;
+   spi-nor@0 {
u-boot,dm-pre-reloc;
};
 };
-- 
2.26.2



Re: [PATCH 4/6] usb: xhci-pci: Move reset logic out of XHCI core

2021-02-08 Thread Samuel Holland
On 2/8/21 8:27 PM, Samuel Holland wrote:
> On 2/8/21 5:43 AM, Marek Vasut wrote:
>> On 2/8/21 6:57 AM, Samuel Holland wrote:
>>> Resetting an XHCI controller inside xhci_register undoes any register
>>> setup performed by the platform driver. And at least on the Allwinner
>>> H6, resetting the XHCI controller also resets the PHY, which prevents
>>> the controller from working. That means the controller must be taken out
>>> of reset before initializing the PHY, which must be done before calling
>>> xhci_register.
>>>
>>> The logic in the XHCI core was added to support the Raspberry Pi 4
>>> (although this was not mentioned in the commit log!), which uses the
>>> xhci-pci platform driver. Move the reset logic to the platform driver,
>>> where it belongs, and where it cannot interfere with other platform
>>> drivers.
>>
>> Are there any other XHCI drivers using the XHCI core code which might
>> stop resetting correctly due to this patch ?
> 
> Since commit 0b80371b350e was merged, the only new call to xhci_register
> is in USB_MTU3. Neither the binding for "mediatek,mtu3" nor any device
> tree node containing that compatible string has a "resets" property. And
> there have been no calls to reset_(de)assert since then, either. So I do

...no calls to reset_(de)assert *removed from any driver* since then...

> not see any other drivers that would be likely to break.
> 
> Samuel
> 



Re: [PATCH 4/6] usb: xhci-pci: Move reset logic out of XHCI core

2021-02-08 Thread Samuel Holland
On 2/8/21 5:43 AM, Marek Vasut wrote:
> On 2/8/21 6:57 AM, Samuel Holland wrote:
>> Resetting an XHCI controller inside xhci_register undoes any register
>> setup performed by the platform driver. And at least on the Allwinner
>> H6, resetting the XHCI controller also resets the PHY, which prevents
>> the controller from working. That means the controller must be taken out
>> of reset before initializing the PHY, which must be done before calling
>> xhci_register.
>>
>> The logic in the XHCI core was added to support the Raspberry Pi 4
>> (although this was not mentioned in the commit log!), which uses the
>> xhci-pci platform driver. Move the reset logic to the platform driver,
>> where it belongs, and where it cannot interfere with other platform
>> drivers.
> 
> Are there any other XHCI drivers using the XHCI core code which might
> stop resetting correctly due to this patch ?

Since commit 0b80371b350e was merged, the only new call to xhci_register
is in USB_MTU3. Neither the binding for "mediatek,mtu3" nor any device
tree node containing that compatible string has a "resets" property. And
there have been no calls to reset_(de)assert since then, either. So I do
not see any other drivers that would be likely to break.

Samuel


Re: [PATCH v2 2/3] board: freescale: undef CONFIG_SPL_DM_I2C for SPL

2021-02-08 Thread Tom Rini
On Tue, Feb 09, 2021 at 01:37:54AM +0200, Igor Opaniuk wrote:

> From: Igor Opaniuk 
> 
> Replace CONFIG_DM_I2C undefs with CONFIG_SPL_DM_I2C for the SPL build
> case. This should be moved to appropriate board defconfigs
> in the future.
> 
> Signed-off-by: Igor Opaniuk 
> ---
> 
> (no changes since v1)
> 
>  include/configs/T104xRDB.h   | 2 +-
>  include/configs/imx8mp_evk.h | 2 +-
>  include/configs/ls1021atwr.h | 2 +-
>  include/configs/ls1046a_common.h | 2 +-
>  include/configs/phycore_imx8mp.h | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h
> index aee00a86cf..f4d0aec42b 100644
> --- a/include/configs/T104xRDB.h
> +++ b/include/configs/T104xRDB.h
> @@ -30,7 +30,7 @@
>  #define CONFIG_SPL_SKIP_RELOCATE
>  #define CONFIG_SPL_COMMON_INIT_DDR
>  #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE
> -#undef CONFIG_DM_I2C
> +#undef CONFIG_SPL_DM_I2C
>  #endif
>  #define RESET_VECTOR_OFFSET  0x27FFC
>  #define BOOT_PAGE_OFFSET 0x27000
> diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h
> index 4850b1b934..33c5759b46 100644
> --- a/include/configs/imx8mp_evk.h
> +++ b/include/configs/imx8mp_evk.h
> @@ -37,7 +37,7 @@
>  #define CONFIG_POWER_I2C
>  #define CONFIG_POWER_PCA9450
>  
> -#undef CONFIG_DM_I2C
> +#undef CONFIG_SPL_DM_I2C
>  #define CONFIG_SYS_I2C
>  
>  #endif
> diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
> index 3e85bb3850..f2bf35ffa5 100644
> --- a/include/configs/ls1021atwr.h
> +++ b/include/configs/ls1021atwr.h
> @@ -435,7 +435,7 @@
>  
>  #ifdef CONFIG_SPL_BUILD
>  #define CONFIG_SYS_MONITOR_BASE CONFIG_SPL_TEXT_BASE
> -#undef CONFIG_DM_I2C
> +#undef CONFIG_SPL_DM_I2C
>  #else
>  #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE/* start of monitor 
> */
>  #endif
> diff --git a/include/configs/ls1046a_common.h 
> b/include/configs/ls1046a_common.h
> index d44a7f105e..b5bbb636da 100644
> --- a/include/configs/ls1046a_common.h
> +++ b/include/configs/ls1046a_common.h
> @@ -16,7 +16,7 @@
>  #define SPL_NO_QSPI
>  #define SPL_NO_USB
>  #define SPL_NO_SATA
> -#undef CONFIG_DM_I2C
> +#undef CONFIG_SPL_DM_I2C
>  #endif
>  #if defined(CONFIG_SPL_BUILD) && \
>   (defined(CONFIG_NAND_BOOT) || defined(CONFIG_QSPI_BOOT))
> diff --git a/include/configs/phycore_imx8mp.h 
> b/include/configs/phycore_imx8mp.h
> index 889dd36e6e..dcd320f746 100644
> --- a/include/configs/phycore_imx8mp.h
> +++ b/include/configs/phycore_imx8mp.h
> @@ -33,7 +33,7 @@
>  #define CONFIG_POWER_I2C
>  #define CONFIG_POWER_PCA9450
>  
> -#undef CONFIG_DM_I2C
> +#undef CONFIG_SPL_DM_I2C
>  #define CONFIG_SYS_I2C
>  
>  #endif

This is somewhere between "doesn't actually work" and "works by chance".
Since you're adding the symbol to Kconfig, keep it disabled on these
boards in the defconfig please.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-08 Thread Chris Packham
On 9/02/21 3:07 pm, Marek Behun wrote:
> On Tue, 9 Feb 2021 01:08:54 +
> Chris Packham  wrote:
>
>> On 9/02/21 1:16 pm, Chris Packham wrote:
>>> On 9/02/21 9:18 am, Marek Behun wrote:
 On Mon, 8 Feb 2021 20:11:06 +
 Chris Packham  wrote:
   
> Hi Marek,
>
> Do you have this in a repo I can pull from? I've got a couple of boards
> I can give this a spin on.
 https://gitlab.nic.cz/turris/turris-omnia-uboot/
 branch v2021.04-rc-mv-ddr-14.0.0

 also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that
 one contains one more commit that is needed for Omnia with Samsung DDR
 chips.
>>> I've tested the dm-88f6820-amc board. Training completed without
>>> issue, as does memtester running from Linux.
>>>
>>> Hit a bit of a snag on the x530 because the changes pushed it over the
>>> SPL size (it was already pretty close). I'll look to see if there's
>>> anything I can drop out or maybe bump the SPL size (I never did get a
>>> clear answer from Marvell as to what the size limit actually is).
>> I can temporarily work around the size issue by disabling watchdog
>> support in SPL (I really don't want that to be the long term solution).
>>
>> But then I encounter an odd problem. When I "reset" the board gets
>> through the DDR training but never makes it to u-boot proper, but if I
>> power cycle it boots through to the u-boot prompt. This doesn't happen
>> on the db-88f6820-amc board. One difference between the x530 and the amc
>> board is that the x530 has ECC so maybe something is going into the
>> weeds if ECC has already been enabled by a previous boot.
>>
> Could you bisect which commit causes this?
I'll give it a try. I've kind of done my dash for u-boot stuff for today 
but I'll try and get to it later tonight.

Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-08 Thread Marek Behun
On Tue, 9 Feb 2021 01:08:54 +
Chris Packham  wrote:

> On 9/02/21 1:16 pm, Chris Packham wrote:
> > On 9/02/21 9:18 am, Marek Behun wrote:  
> >> On Mon, 8 Feb 2021 20:11:06 +
> >> Chris Packham  wrote:
> >>  
> >>> Hi Marek,
> >>>
> >>> Do you have this in a repo I can pull from? I've got a couple of boards
> >>> I can give this a spin on.  
> >> https://gitlab.nic.cz/turris/turris-omnia-uboot/
> >> branch v2021.04-rc-mv-ddr-14.0.0
> >>
> >> also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that
> >> one contains one more commit that is needed for Omnia with Samsung DDR
> >> chips.  
> >
> > I've tested the dm-88f6820-amc board. Training completed without 
> > issue, as does memtester running from Linux.
> >
> > Hit a bit of a snag on the x530 because the changes pushed it over the 
> > SPL size (it was already pretty close). I'll look to see if there's 
> > anything I can drop out or maybe bump the SPL size (I never did get a 
> > clear answer from Marvell as to what the size limit actually is).  
> 
> I can temporarily work around the size issue by disabling watchdog 
> support in SPL (I really don't want that to be the long term solution).
> 
> But then I encounter an odd problem. When I "reset" the board gets 
> through the DDR training but never makes it to u-boot proper, but if I 
> power cycle it boots through to the u-boot prompt. This doesn't happen 
> on the db-88f6820-amc board. One difference between the x530 and the amc 
> board is that the x530 has ECC so maybe something is going into the 
> weeds if ECC has already been enabled by a previous boot.
> 

Could you bisect which commit causes this?

Marek


Re: [PATCH 0/6] Allwinner H6 USB3 support

2021-02-08 Thread Andre Przywara
On Sun,  7 Feb 2021 23:57:18 -0600
Samuel Holland  wrote:

Hi Samuel,

> This series adds clock, PHY, and XHCI driver support for the USB3
> controller found in the Allwinner H6 SoC. Below is a log showing it
> functioning on the Orange Pi 3.

Many thanks for sharing this! The lack of USB 3.0 support annoyed me
for a while (not so much for SuperSpeed, but more for another usable USB
port). I had some patches myself, but stopped with some hacks after I
realised the resets properties blunder.
So many thanks for finding a much better solution for this! There might
be still some discussion around this, but at least we have something in
a working and non-hackish state.

I commented on the individual patches!

Cheers,
Andre

> U-Boot 2021.04-rc1-00068-g6b8f4e0d060 (Jan 01 1970 - 00:00:00 +) 
> Allwinner Technology
> 
> CPU:   Allwinner H6 (SUN50I)
> Model: OrangePi 3
> DRAM:  2 GiB
> MMC:   mmc@402: 0, mmc@4021000: 2, mmc@4022000: 1
> Loading Environment from FAT... Unable to use mmc 1:0... In:serial@500
> Out:   serial@500
> Err:   serial@500
> Net:   No ethernet found.
> starting USB...
> Bus usb@5101000: USB EHCI 1.00
> Bus usb@5101400: USB OHCI 1.0
> Bus usb@520: Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> Bus usb@5311000: USB EHCI 1.00
> Bus usb@5311400: USB OHCI 1.0
> scanning bus usb@5101000 for devices... 1 USB Device(s) found
> scanning bus usb@5101400 for devices... 1 USB Device(s) found
> scanning bus usb@520 for devices... 4 USB Device(s) found
> scanning bus usb@5311000 for devices... 1 USB Device(s) found
> scanning bus usb@5311400 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0 
> => usb tree  
> USB device tree:
>   1  Hub (480 Mb/s, 0mA)
>  u-boot EHCI Host Controller 
>
>   1  Hub (12 Mb/s, 0mA)
>   U-Boot Root Hub 
>
>   1  Hub (5 Gb/s, 0mA)
>   |  U-Boot XHCI Host Controller 
>   |
>   +-2  Hub (5 Gb/s, 0mA)
>   | |  GenesysLogic USB3.1 Hub 
>   | |
>   | +-4  Mass Storage (5 Gb/s, 224mA)
>   |071044991D8D6A81
>   |
>   +-3  Hub (480 Mb/s, 100mA)
>GenesysLogic USB2.1 Hub 
>  
>   1  Hub (480 Mb/s, 0mA)
>  u-boot EHCI Host Controller 
>
>   1  Hub (12 Mb/s, 0mA)
>   U-Boot Root Hub 
> 
> Samuel Holland (6):
>   clk: sunxi: Add a dummy clock driver for the RTC
>   clk: sunxi: h6: Add XHCI clocks
>   phy: sun50i-usb3: Add a driver for the H6 USB3 PHY
>   usb: xhci-pci: Move reset logic out of XHCI core
>   usb: xhci-dwc3: Add support for clocks/resets
>   configs: Enable USB3 on Allwinner H6 boards
> 
>  configs/orangepi_3_defconfig|   5 +
>  configs/pine_h64_defconfig  |   5 +
>  drivers/clk/sunxi/Makefile  |   2 +
>  drivers/clk/sunxi/clk_h6.c  |   2 +
>  drivers/clk/sunxi/clk_sun6i_rtc.c   |  35 +
>  drivers/phy/allwinner/Kconfig   |   8 ++
>  drivers/phy/allwinner/Makefile  |   1 +
>  drivers/phy/allwinner/phy-sun50i-usb3.c | 171 
>  drivers/usb/host/xhci-dwc3.c|  56 
>  drivers/usb/host/xhci-mem.c |   2 -
>  drivers/usb/host/xhci-pci.c |  38 +-
>  drivers/usb/host/xhci.c |  35 -
>  include/usb/xhci.h  |   2 -
>  13 files changed, 321 insertions(+), 41 deletions(-)
>  create mode 100644 drivers/clk/sunxi/clk_sun6i_rtc.c
>  create mode 100644 drivers/phy/allwinner/phy-sun50i-usb3.c
> 



Re: [PATCH 6/6] configs: Enable USB3 on Allwinner H6 boards

2021-02-08 Thread Andre Przywara
On Sun,  7 Feb 2021 23:57:24 -0600
Samuel Holland  wrote:

Hi,

(CC:ing Maxime and Chen-Yu)

> Pine H64 and Orange Pi 3 both provide a USB3 type A port.
> Enable it in U-Boot.
> 
> Signed-off-by: Samuel Holland 

That looks good to me, but the Pine H64 does not enable the USB
3.0 controller in its .dts file.
I just added status = "okay"; to the dwc3 and PHY nodes and it
worked, though.

Does anyone know a reason this is not enabled in the mainline DT (which
we just synced)?

Cheers,
Andre

> ---
>  configs/orangepi_3_defconfig | 5 +
>  configs/pine_h64_defconfig   | 5 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/configs/orangepi_3_defconfig b/configs/orangepi_3_defconfig
> index 82b9815205e..eb25bd9f504 100644
> --- a/configs/orangepi_3_defconfig
> +++ b/configs/orangepi_3_defconfig
> @@ -8,5 +8,10 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>  CONFIG_BLUETOOTH_DT_DEVICE_FIXUP="brcm,bcm4345c5"
>  CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-orangepi-3"
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> +CONFIG_PHY_SUN50I_USB3=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_DWC3=y
> +# CONFIG_USB_DWC3_GADGET is not set
> diff --git a/configs/pine_h64_defconfig b/configs/pine_h64_defconfig
> index 2fa66f38343..0095fb222e6 100644
> --- a/configs/pine_h64_defconfig
> +++ b/configs/pine_h64_defconfig
> @@ -12,5 +12,10 @@ CONFIG_SPL_SPI_SUNXI=y
>  CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-pine-h64"
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>  CONFIG_SUN8I_EMAC=y
> +CONFIG_PHY_SUN50I_USB3=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_DWC3=y
> +# CONFIG_USB_DWC3_GADGET is not set



Re: [PATCH 5/6] usb: xhci-dwc3: Add support for clocks/resets

2021-02-08 Thread Andre Przywara
On Sun,  7 Feb 2021 23:57:23 -0600
Samuel Holland  wrote:

(CC:ing Simon and Kever)

> Some platforms, like the Allwinner H6, do not have a separate glue layer
> around the dwc3. Instead, they rely on the clocks/resets/phys referenced
> from the dwc3 DT node itself. Add support for enabling the clocks/resets
> referenced from the dwc3 DT node.
> 
> Signed-off-by: Samuel Holland 

That looks alright on a first glance, but have you checked how this
interacts with and relates to dwc3-of-simple.c?
This seems to do similar things?

Cheers,
Andre

> ---
>  drivers/usb/host/xhci-dwc3.c | 56 
>  1 file changed, 56 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
> index 3e0ae80cece..5b12d1358e4 100644
> --- a/drivers/usb/host/xhci-dwc3.c
> +++ b/drivers/usb/host/xhci-dwc3.c
> @@ -7,10 +7,12 @@
>   * Author: Ramneek Mehresh
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -21,7 +23,9 @@
>  #include 
>  
>  struct xhci_dwc3_plat {
> + struct clk_bulk clks;
>   struct phy_bulk phys;
> + struct reset_ctl_bulk resets;
>  };
>  
>  void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
> @@ -111,6 +115,46 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val)
>  }
>  
>  #if CONFIG_IS_ENABLED(DM_USB)
> +static int xhci_dwc3_reset_init(struct udevice *dev,
> + struct xhci_dwc3_plat *plat)
> +{
> + int ret;
> +
> + ret = reset_get_bulk(dev, >resets);
> + if (ret == -ENOTSUPP || ret == -ENOENT)
> + return 0;
> + else if (ret)
> + return ret;
> +
> + ret = reset_deassert_bulk(>resets);
> + if (ret) {
> + reset_release_bulk(>resets);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int xhci_dwc3_clk_init(struct udevice *dev,
> +   struct xhci_dwc3_plat *plat)
> +{
> + int ret;
> +
> + ret = clk_get_bulk(dev, >clks);
> + if (ret == -ENOSYS || ret == -ENOENT)
> + return 0;
> + if (ret)
> + return ret;
> +
> + ret = clk_enable_bulk(>clks);
> + if (ret) {
> + clk_release_bulk(>clks);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static int xhci_dwc3_probe(struct udevice *dev)
>  {
>   struct xhci_hcor *hcor;
> @@ -122,6 +166,14 @@ static int xhci_dwc3_probe(struct udevice *dev)
>   u32 reg;
>   int ret;
>  
> + ret = xhci_dwc3_reset_init(dev, plat);
> + if (ret)
> + return ret;
> +
> + ret = xhci_dwc3_clk_init(dev, plat);
> + if (ret)
> + return ret;
> +
>   hccr = (struct xhci_hccr *)((uintptr_t)dev_remap_addr(dev));
>   hcor = (struct xhci_hcor *)((uintptr_t)hccr +
>   HC_LENGTH(xhci_readl(&(hccr)->cr_capbase)));
> @@ -171,6 +223,10 @@ static int xhci_dwc3_remove(struct udevice *dev)
>  
>   dwc3_shutdown_phy(dev, >phys);
>  
> + clk_release_bulk(>clks);
> +
> + reset_release_bulk(>resets);
> +
>   return xhci_deregister(dev);
>  }
>  



Re: [PATCH 4/6] usb: xhci-pci: Move reset logic out of XHCI core

2021-02-08 Thread Andre Przywara
On Mon, 8 Feb 2021 12:43:52 +0100
Marek Vasut  wrote:

(CC:ing Masahiro, Manni and Kever)

> On 2/8/21 6:57 AM, Samuel Holland wrote:
> > Resetting an XHCI controller inside xhci_register undoes any register
> > setup performed by the platform driver. And at least on the Allwinner
> > H6, resetting the XHCI controller also resets the PHY, which prevents
> > the controller from working. That means the controller must be taken out
> > of reset before initializing the PHY, which must be done before calling
> > xhci_register.
> > 
> > The logic in the XHCI core was added to support the Raspberry Pi 4
> > (although this was not mentioned in the commit log!), which uses the
> > xhci-pci platform driver. Move the reset logic to the platform driver,
> > where it belongs, and where it cannot interfere with other platform
> > drivers.  
> 
> Are there any other XHCI drivers using the XHCI core code which might 
> stop resetting correctly due to this patch ?

That's a fair point. I grep'ed all .dts[i] files in both the kernel and
U-Boot for snps,dwc3 users, and there various Uniphier .dtsi files that
have resets properties, also the Hisilicon 3660 (HiKey960).
The HiKey doesn't seem to enable DWC3 in its defconfig, and from what I
can see the Uniphier boards have hardcoded reset deasserts in their
glue driver?
Masahiro, Manni, Kever, can you confirm that your boards still work,
after this whole series? I put a branch here for testing:
https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi.git test-usb3-h6

As an added bonus, it would be interesting to see if USB 3.0 still
works just after this patch. If not, we might need to squash the next
patch into this one.

Many thanks!
Andre


Re: [PATCH 3/6] phy: sun50i-usb3: Add a driver for the H6 USB3 PHY

2021-02-08 Thread Andre Przywara
On Sun,  7 Feb 2021 23:57:21 -0600
Samuel Holland  wrote:

Hi,

> This driver is needed for XHCI to work on the Allwinner H6 SoC. The
> driver is copied from Linux v5.10.
> 
> Signed-off-by: Samuel Holland 

Compared against the Linux driver, also against the version I made
myself a few months ago (in which I spotted two bugs now ;-)

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  drivers/phy/allwinner/Kconfig   |   8 ++
>  drivers/phy/allwinner/Makefile  |   1 +
>  drivers/phy/allwinner/phy-sun50i-usb3.c | 171 
>  3 files changed, 180 insertions(+)
>  create mode 100644 drivers/phy/allwinner/phy-sun50i-usb3.c
> 
> diff --git a/drivers/phy/allwinner/Kconfig b/drivers/phy/allwinner/Kconfig
> index dba3bae61c4..6bfb79cbcad 100644
> --- a/drivers/phy/allwinner/Kconfig
> +++ b/drivers/phy/allwinner/Kconfig
> @@ -11,3 +11,11 @@ config PHY_SUN4I_USB
>  
> This driver controls the entire USB PHY block, both the USB OTG
> parts, as well as the 2 regular USB 2 host PHYs.
> +
> +config PHY_SUN50I_USB3
> + bool "Allwinner sun50i USB3 PHY driver"
> + depends on ARCH_SUNXI
> + select PHY
> + help
> +   Enable this to support the USB3 transceiver that is part of
> +   Allwinner sun50i SoCs.
> diff --git a/drivers/phy/allwinner/Makefile b/drivers/phy/allwinner/Makefile
> index e709fca643c..f2b60ce1a64 100644
> --- a/drivers/phy/allwinner/Makefile
> +++ b/drivers/phy/allwinner/Makefile
> @@ -4,3 +4,4 @@
>  #
>  
>  obj-$(CONFIG_PHY_SUN4I_USB)  += phy-sun4i-usb.o
> +obj-$(CONFIG_PHY_SUN50I_USB3)+= phy-sun50i-usb3.o
> diff --git a/drivers/phy/allwinner/phy-sun50i-usb3.c 
> b/drivers/phy/allwinner/phy-sun50i-usb3.c
> new file mode 100644
> index 000..e5a3d2d92ea
> --- /dev/null
> +++ b/drivers/phy/allwinner/phy-sun50i-usb3.c
> @@ -0,0 +1,171 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Allwinner sun50i(H6) USB 3.0 phy driver
> + *
> + * Copyright (C) 2020 Samuel Holland 
> + *
> + * Based on the Linux driver, which is:
> + *
> + * Copyright (C) 2017 Icenowy Zheng 
> + *
> + * Based on phy-sun9i-usb.c, which is:
> + *
> + * Copyright (C) 2014-2015 Chen-Yu Tsai 
> + *
> + * Based on code from Allwinner BSP, which is:
> + *
> + * Copyright (c) 2010-2015 Allwinner Technology Co., Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Interface Status and Control Registers */
> +#define SUNXI_ISCR   0x00
> +#define SUNXI_PIPE_CLOCK_CONTROL 0x14
> +#define SUNXI_PHY_TUNE_LOW   0x18
> +#define SUNXI_PHY_TUNE_HIGH  0x1c
> +#define SUNXI_PHY_EXTERNAL_CONTROL   0x20
> +
> +/* USB2.0 Interface Status and Control Register */
> +#define SUNXI_ISCR_FORCE_VBUS(3 << 12)
> +
> +/* PIPE Clock Control Register */
> +#define SUNXI_PCC_PIPE_CLK_OPEN  (1 << 6)
> +
> +/* PHY External Control Register */
> +#define SUNXI_PEC_EXTERN_VBUS(3 << 1)
> +#define SUNXI_PEC_SSC_EN (1 << 24)
> +#define SUNXI_PEC_REF_SSP_EN (1 << 26)
> +
> +/* PHY Tune High Register */
> +#define SUNXI_TX_DEEMPH_3P5DB(n) ((n) << 19)
> +#define SUNXI_TX_DEEMPH_3P5DB_MASK   GENMASK(24, 19)
> +#define SUNXI_TX_DEEMPH_6DB(n)   ((n) << 13)
> +#define SUNXI_TX_DEEMPH_6GB_MASK GENMASK(18, 13)
> +#define SUNXI_TX_SWING_FULL(n)   ((n) << 6)
> +#define SUNXI_TX_SWING_FULL_MASK GENMASK(12, 6)
> +#define SUNXI_LOS_BIAS(n)((n) << 3)
> +#define SUNXI_LOS_BIAS_MASK  GENMASK(5, 3)
> +#define SUNXI_TXVBOOSTLVL(n) ((n) << 0)
> +#define SUNXI_TXVBOOSTLVL_MASK   GENMASK(2, 0)
> +
> +struct sun50i_usb3_phy_priv {
> + void __iomem *regs;
> + struct reset_ctl reset;
> + struct clk clk;
> +};
> +
> +static void sun50i_usb3_phy_open(struct sun50i_usb3_phy_priv *phy)
> +{
> + u32 val;
> +
> + val = readl(phy->regs + SUNXI_PHY_EXTERNAL_CONTROL);
> + val |= SUNXI_PEC_EXTERN_VBUS;
> + val |= SUNXI_PEC_SSC_EN | SUNXI_PEC_REF_SSP_EN;
> + writel(val, phy->regs + SUNXI_PHY_EXTERNAL_CONTROL);
> +
> + val = readl(phy->regs + SUNXI_PIPE_CLOCK_CONTROL);
> + val |= SUNXI_PCC_PIPE_CLK_OPEN;
> + writel(val, phy->regs + SUNXI_PIPE_CLOCK_CONTROL);
> +
> + val = readl(phy->regs + SUNXI_ISCR);
> + val |= SUNXI_ISCR_FORCE_VBUS;
> + writel(val, phy->regs + SUNXI_ISCR);
> +
> + /*
> +  * All the magic numbers written to the PHY_TUNE_{LOW_HIGH}
> +  * registers are directly taken from the BSP USB3 driver from
> +  * Allwiner.
> +  */
> + writel(0x0047fc87, phy->regs + SUNXI_PHY_TUNE_LOW);
> +
> + val = readl(phy->regs + SUNXI_PHY_TUNE_HIGH);
> + val &= ~(SUNXI_TXVBOOSTLVL_MASK | SUNXI_LOS_BIAS_MASK |
> +  SUNXI_TX_SWING_FULL_MASK | SUNXI_TX_DEEMPH_6GB_MASK |
> +  SUNXI_TX_DEEMPH_3P5DB_MASK);
> + val |= SUNXI_TXVBOOSTLVL(0x7);
> + val |= 

Re: [PATCH 2/6] clk: sunxi: h6: Add XHCI clocks

2021-02-08 Thread Andre Przywara
On Sun,  7 Feb 2021 23:57:20 -0600
Samuel Holland  wrote:

> The XHCI controller has its own clock and reset. Add them.
> 
> Signed-off-by: Samuel Holland 

Checked against the manual:
Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  drivers/clk/sunxi/clk_h6.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/clk/sunxi/clk_h6.c b/drivers/clk/sunxi/clk_h6.c
> index ac8656fe895..df93d96b3b0 100644
> --- a/drivers/clk/sunxi/clk_h6.c
> +++ b/drivers/clk/sunxi/clk_h6.c
> @@ -43,6 +43,7 @@ static struct ccu_clk_gate h6_gates[] = {
>   [CLK_BUS_OHCI0] = GATE(0xa8c, BIT(0)),
>   [CLK_BUS_OHCI3] = GATE(0xa8c, BIT(3)),
>   [CLK_BUS_EHCI0] = GATE(0xa8c, BIT(4)),
> + [CLK_BUS_XHCI]  = GATE(0xa8c, BIT(5)),
>   [CLK_BUS_EHCI3] = GATE(0xa8c, BIT(7)),
>   [CLK_BUS_OTG]   = GATE(0xa8c, BIT(8)),
>  };
> @@ -71,6 +72,7 @@ static struct ccu_reset h6_resets[] = {
>   [RST_BUS_OHCI0] = RESET(0xa8c, BIT(16)),
>   [RST_BUS_OHCI3] = RESET(0xa8c, BIT(19)),
>   [RST_BUS_EHCI0] = RESET(0xa8c, BIT(20)),
> + [RST_BUS_XHCI]  = RESET(0xa8c, BIT(21)),
>   [RST_BUS_EHCI3] = RESET(0xa8c, BIT(23)),
>   [RST_BUS_OTG]   = RESET(0xa8c, BIT(24)),
>  };



Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-08 Thread Chris Packham

On 9/02/21 1:16 pm, Chris Packham wrote:
> On 9/02/21 9:18 am, Marek Behun wrote:
>> On Mon, 8 Feb 2021 20:11:06 +
>> Chris Packham  wrote:
>>
>>> Hi Marek,
>>>
>>> Do you have this in a repo I can pull from? I've got a couple of boards
>>> I can give this a spin on.
>> https://gitlab.nic.cz/turris/turris-omnia-uboot/
>> branch v2021.04-rc-mv-ddr-14.0.0
>>
>> also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that
>> one contains one more commit that is needed for Omnia with Samsung DDR
>> chips.
>
> I've tested the dm-88f6820-amc board. Training completed without 
> issue, as does memtester running from Linux.
>
> Hit a bit of a snag on the x530 because the changes pushed it over the 
> SPL size (it was already pretty close). I'll look to see if there's 
> anything I can drop out or maybe bump the SPL size (I never did get a 
> clear answer from Marvell as to what the size limit actually is).

I can temporarily work around the size issue by disabling watchdog 
support in SPL (I really don't want that to be the long term solution).

But then I encounter an odd problem. When I "reset" the board gets 
through the DDR training but never makes it to u-boot proper, but if I 
power cycle it boots through to the u-boot prompt. This doesn't happen 
on the db-88f6820-amc board. One difference between the x530 and the amc 
board is that the x530 has ECC so maybe something is going into the 
weeds if ECC has already been enabled by a previous boot.



Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-08 Thread Chris Packham
On 9/02/21 9:18 am, Marek Behun wrote:
> On Mon, 8 Feb 2021 20:11:06 +
> Chris Packham  wrote:
>
>> Hi Marek,
>>
>> Do you have this in a repo I can pull from? I've got a couple of boards
>> I can give this a spin on.
> https://gitlab.nic.cz/turris/turris-omnia-uboot/
> branch v2021.04-rc-mv-ddr-14.0.0
>
> also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that
> one contains one more commit that is needed for Omnia with Samsung DDR
> chips.

I've tested the dm-88f6820-amc board. Training completed without issue, 
as does memtester running from Linux.

Hit a bit of a snag on the x530 because the changes pushed it over the 
SPL size (it was already pretty close). I'll look to see if there's 
anything I can drop out or maybe bump the SPL size (I never did get a 
clear answer from Marvell as to what the size limit actually is).

[PATCH v2 3/3] dm: i2c: use CONFIG_IS_ENABLED macro for DM_I2C/DM_I2C_GPIO

2021-02-08 Thread Igor Opaniuk
From: Igor Opaniuk 

Use CONFIG_IS_ENABLED() macro, which provides more convenient
way to check $(SPL)DM_I2C/$(SPL)DM_I2C_GPIO configs
for both SPL and U-Boot proper.

CONFIG_IS_ENABLED(DM_I2C) expands to:
- 1 if CONFIG_SPL_BUILD is undefined and CONFIG_DM_I2C is set to 'y',
- 1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_DM_I2C is set to 'y',
- 0 otherwise.

All occurences were replaced automatically using these bash cmds:
$ find . -type f -exec sed -i
 's/ifndef CONFIG_DM_I2C/if !CONFIG_IS_ENABLED(DM_I2C)/g' {} +
$ find . -type f -exec sed -i
's/ifdef CONFIG_DM_I2C/if CONFIG_IS_ENABLED(DM_I2C)/g' {} +
$ find . -type f -exec sed -i
's/defined(CONFIG_DM_I2C)/CONFIG_IS_ENABLED(DM_I2C)/g' {} +
$ find . -type f -exec sed -i
's/ifndef CONFIG_DM_I2C_GPIO/if !CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
$ find . -type f -exec sed -i
's/ifdef CONFIG_DM_I2C_GPIO/if CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
$ find . -type f -exec sed -i
's/defined(CONFIG_DM_I2C_GPIO)/CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +

Reviewed-by: Heiko Schocher 
Reviewed-by: Simon Glass 
Signed-off-by: Igor Opaniuk 

---

Changes v2:
- R-b tags applied

 .../include/asm/arch-fsl-layerscape/config.h  |  2 +-
 arch/arm/include/asm/arch-lpc32xx/i2c.h   |  2 +-
 arch/arm/include/asm/mach-imx/mxc_i2c.h   |  2 +-
 arch/arm/include/asm/omap_i2c.h   |  2 +-
 arch/arm/mach-imx/i2c-mxv7.c  |  2 +-
 arch/arm/mach-keystone/ddr3_spd.c |  2 +-
 arch/arm/mach-kirkwood/include/mach/config.h  |  2 +-
 arch/arm/mach-omap2/am33xx/board.c|  2 +-
 arch/arm/mach-omap2/am33xx/clk_synthesizer.c  |  6 +-
 arch/arm/mach-omap2/boot-common.c |  2 +-
 arch/arm/mach-omap2/clocks-common.c   |  2 +-
 arch/arm/mach-sunxi/board.c   |  2 +-
 arch/powerpc/include/asm/fsl_i2c.h|  2 +-
 board/freescale/common/dcu_sii9022a.c |  2 +-
 board/freescale/common/diu_ch7301.c   |  2 +-
 board/freescale/common/emc2305.c  |  4 +-
 board/freescale/common/qixis.c|  4 +-
 board/freescale/common/sys_eeprom.c   | 20 ++--
 board/freescale/common/vid.c  | 24 ++---
 board/freescale/common/vsc3316_3308.c | 10 +-
 board/freescale/ls1012aqds/ls1012aqds.c   |  2 +-
 board/freescale/ls1012ardb/eth.c  |  2 +-
 board/freescale/ls1012ardb/ls1012ardb.c   | 12 +--
 board/freescale/ls1021aqds/dcu.c  |  6 +-
 board/freescale/ls1021aqds/ls1021aqds.c   |  2 +-
 board/freescale/ls1021atwr/ls1021atwr.c   |  2 +-
 board/freescale/ls1028a/ls1028a.c |  2 +-
 board/freescale/ls1043aqds/ls1043aqds.c   |  4 +-
 board/freescale/ls1046afrwy/ls1046afrwy.c |  2 +-
 board/freescale/ls1046aqds/ls1046aqds.c   |  2 +-
 board/freescale/ls1088a/eth_ls1088aqds.c  | 16 +--
 board/freescale/ls1088a/ls1088a.c | 60 ++--
 board/freescale/ls2080aqds/eth.c  | 14 +--
 board/freescale/ls2080aqds/ls2080aqds.c   |  4 +-
 board/freescale/ls2080ardb/ls2080ardb.c   |  2 +-
 board/freescale/lx2160a/lx2160a.c |  2 +-
 board/freescale/p1010rdb/p1010rdb.c   |  8 +-
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c   |  2 +-
 board/freescale/t102xrdb/t102xrdb.c   |  2 +-
 board/freescale/t208xqds/t208xqds.c   |  2 +-
 board/friendlyarm/nanopi2/onewire.c   |  6 +-
 board/keymile/common/ivm.c|  2 +-
 board/samsung/common/misc.c   |  2 +-
 board/samsung/trats/trats.c   | 10 +-
 board/samsung/trats2/trats2.c | 10 +-
 board/sunxi/board.c   |  2 +-
 board/ti/am335x/board.c   |  8 +-
 board/ti/am335x/mux.c |  2 +-
 board/ti/am43xx/board.c   | 12 +--
 board/ti/common/board_detect.c|  4 +-
 board/ti/ks2_evm/board_k2g.c  |  2 +-
 board/wandboard/wandboard.c   |  4 +-
 cmd/eeprom.c  |  6 +-
 cmd/i2c.c | 98 +--
 doc/driver-model/i2c-howto.rst|  2 +-
 drivers/ddr/fsl/main.c|  8 +-
 drivers/i2c/davinci_i2c.c |  4 +-
 drivers/i2c/designware_i2c.c  |  4 +-
 drivers/i2c/fsl_i2c.c |  6 +-
 drivers/i2c/ihs_i2c.c | 42 
 drivers/i2c/lpc32xx_i2c.c |  4 +-
 drivers/i2c/mv_i2c.c  |  2 +-
 drivers/i2c/mvtwsi.c  | 16 +--
 drivers/i2c/mxc_i2c.c |  4 +-
 drivers/i2c/omap24xx_i2c.c|  2 +-
 drivers/power/palmas.c|  2 +-
 drivers/power/pmic/pmic_tps62362.c|  6 +-
 drivers/power/pmic/pmic_tps65217.c| 14 +--
 drivers/power/pmic/pmic_tps65218.c|  4 +-
 

[PATCH v2 0/3] Allow disabling driver model for I2C in SPL

2021-02-08 Thread Igor Opaniuk
From: Igor Opaniuk 

At present if U-Boot proper uses driver model for I2C, then SPL has to
also. While this is desirable, it places a significant barrier to moving
to driver model in some cases. For example, with a space-constrained SPL
it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves
adjusting some drivers.

This patch introduces a separate Kconfig symbols for enabling DM_I2C and
DM_I2C_GPIO support in SPL.

This will also help to get away from dirty workarounds to
achieve non-DM I2C support for SPL, which is currently used in some
board header files like:

ifdef CONFIG_SPL_BUILD
undef CONFIG_DM_I2C
endif

All occurences were replaced automatically using these bash cmds:
$ find . -type f -exec sed -i
 's/ifndef CONFIG_DM_I2C/if !CONFIG_IS_ENABLED(DM_I2C)/g' {} +
$ find . -type f -exec sed -i
's/ifdef CONFIG_DM_I2C/if CONFIG_IS_ENABLED(DM_I2C)/g' {} +
$ find . -type f -exec sed -i
's/defined(CONFIG_DM_I2C)/CONFIG_IS_ENABLED(DM_I2C)/g' {} +
$ find . -type f -exec sed -i
's/ifndef CONFIG_DM_I2C_GPIO/if !CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
$ find . -type f -exec sed -i
's/ifdef CONFIG_DM_I2C_GPIO/if CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
$ find . -type f -exec sed -i
's/defined(CONFIG_DM_I2C_GPIO)/CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +

Azure CI results:
https://dev.azure.com/igoropaniuk/u-boot/_build/results?buildId=5=results

Changes in v2:
- Applied R-b tags from Simon and Heiko
- Added additional patches that replace CONFIG_DM_I2C undefs with
CONFIG_SPL_DM_I2C for SPL build case (this should be moved to board
defconfigs by board maintainers)


Igor Opaniuk (3):
  dm: i2c: allow disabling driver model in SPL
  board: freescale: undef CONFIG_SPL_DM_I2C for SPL
  dm: i2c: use CONFIG_IS_ENABLED macro for DM_I2C/DM_I2C_GPIO

 .../include/asm/arch-fsl-layerscape/config.h  |  2 +-
 arch/arm/include/asm/arch-lpc32xx/i2c.h   |  2 +-
 arch/arm/include/asm/mach-imx/mxc_i2c.h   |  2 +-
 arch/arm/include/asm/omap_i2c.h   |  2 +-
 arch/arm/mach-imx/i2c-mxv7.c  |  2 +-
 arch/arm/mach-keystone/ddr3_spd.c |  2 +-
 arch/arm/mach-kirkwood/include/mach/config.h  |  2 +-
 arch/arm/mach-omap2/am33xx/board.c|  2 +-
 arch/arm/mach-omap2/am33xx/clk_synthesizer.c  |  6 +-
 arch/arm/mach-omap2/boot-common.c |  2 +-
 arch/arm/mach-omap2/clocks-common.c   |  2 +-
 arch/arm/mach-sunxi/board.c   |  2 +-
 arch/powerpc/include/asm/fsl_i2c.h|  2 +-
 board/freescale/common/dcu_sii9022a.c |  2 +-
 board/freescale/common/diu_ch7301.c   |  2 +-
 board/freescale/common/emc2305.c  |  4 +-
 board/freescale/common/qixis.c|  4 +-
 board/freescale/common/sys_eeprom.c   | 20 ++--
 board/freescale/common/vid.c  | 24 ++---
 board/freescale/common/vsc3316_3308.c | 10 +-
 board/freescale/ls1012aqds/ls1012aqds.c   |  2 +-
 board/freescale/ls1012ardb/eth.c  |  2 +-
 board/freescale/ls1012ardb/ls1012ardb.c   | 12 +--
 board/freescale/ls1021aqds/dcu.c  |  6 +-
 board/freescale/ls1021aqds/ls1021aqds.c   |  2 +-
 board/freescale/ls1021atwr/ls1021atwr.c   |  2 +-
 board/freescale/ls1028a/ls1028a.c |  2 +-
 board/freescale/ls1043aqds/ls1043aqds.c   |  4 +-
 board/freescale/ls1046afrwy/ls1046afrwy.c |  2 +-
 board/freescale/ls1046aqds/ls1046aqds.c   |  2 +-
 board/freescale/ls1088a/eth_ls1088aqds.c  | 16 +--
 board/freescale/ls1088a/ls1088a.c | 60 ++--
 board/freescale/ls2080aqds/eth.c  | 14 +--
 board/freescale/ls2080aqds/ls2080aqds.c   |  4 +-
 board/freescale/ls2080ardb/ls2080ardb.c   |  2 +-
 board/freescale/lx2160a/lx2160a.c |  2 +-
 board/freescale/p1010rdb/p1010rdb.c   |  8 +-
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c   |  2 +-
 board/freescale/t102xrdb/t102xrdb.c   |  2 +-
 board/freescale/t208xqds/t208xqds.c   |  2 +-
 board/friendlyarm/nanopi2/onewire.c   |  6 +-
 board/keymile/common/ivm.c|  2 +-
 board/samsung/common/misc.c   |  2 +-
 board/samsung/trats/trats.c   | 10 +-
 board/samsung/trats2/trats2.c | 10 +-
 board/sunxi/board.c   |  2 +-
 board/ti/am335x/board.c   |  8 +-
 board/ti/am335x/mux.c |  2 +-
 board/ti/am43xx/board.c   | 12 +--
 board/ti/common/board_detect.c|  4 +-
 board/ti/ks2_evm/board_k2g.c  |  2 +-
 board/wandboard/wandboard.c   |  4 +-
 cmd/eeprom.c  |  6 +-
 cmd/i2c.c | 98 +--
 doc/driver-model/i2c-howto.rst|  2 +-
 drivers/ddr/fsl/main.c|  8 +-
 drivers/i2c/Kconfig   | 21 
 drivers/i2c/Makefile   

Re: [PATCH v4 16/16] gpio: Add a way to read 3-way strapping pins

2021-02-08 Thread Simon Glass
Hi Patrick,

On Mon, 8 Feb 2021 at 11:13, Patrick DELAUNAY
 wrote:
>
> Hi Simon,
>
> On 2/5/21 5:22 AM, Simon Glass wrote:
> > Using the internal vs. external pull resistors it is possible to get
> > 27 different combinations from 3 strapping pins. Add an implementation
> > of this.
> >
> > This involves updating the sandbox GPIO driver to model external and
> > (weaker) internal pull resistors. The get_value() method now takes account
> > of what is driving a pin:
> >
> > sandbox: GPIOD_EXT_DRIVEN - in which case GPIO_EXT_HIGH provides the
> >value
> > outside source - in which case GPIO_EXT_PULL_UP/DOWN indicates the
> >external state and we work the final state using those flags and
> >the internal GPIOD_PULL_UP/DOWN flags
> >
> > Of course the outside source does not really exist in sandbox. We are just
> > modelling it for test purpose.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > (no changes since v3)
> >
> > Changes in v3:
> > - Use bits 28, 29 for the new flags
> > - Assert that count parameter is within range
> > - Redo digit logic to be easier to understand
> > - Update function comment to explain the meaning of the digits
> > - Fix 'compare' typo
> >
> >   arch/sandbox/include/asm/gpio.h |  5 +-
> >   drivers/gpio/gpio-uclass.c  | 81 +++
> >   drivers/gpio/sandbox.c  | 13 +++--
> >   include/asm-generic/gpio.h  | 40 ++
> >   test/dm/gpio.c  | 98 +
> >   5 files changed, 232 insertions(+), 5 deletions(-)
> >
> (...)
> > diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
> > index 700098446b5..d008fdd2224 100644
> > --- a/drivers/gpio/sandbox.c
> > +++ b/drivers/gpio/sandbox.c
> > @@ -19,7 +19,6 @@
> >   #include 
> >   #include 
> >
> > -
> >   struct gpio_state {
> >   const char *label;  /* label given by requester */
> >   ulong flags;/* flags (GPIOD_...) */
> > @@ -81,10 +80,16 @@ int sandbox_gpio_get_value(struct udevice *dev, 
> > unsigned offset)
> >   if (get_gpio_flag(dev, offset, GPIOD_IS_OUT))
> >   debug("sandbox_gpio: get_value on output gpio %u\n", offset);
> >
> > - if (state->flags & GPIOD_EXT_DRIVEN)
> > + if (state->flags & GPIOD_EXT_DRIVEN) {
> >   val = state->flags & GPIOD_EXT_HIGH;
>
> bool here, not int
>
> + val = !!(state->flags & GPIOD_EXT_HIGH);
>
>
> > - else
> > - val = false;
> > + } else {
> > + if (state->flags & GPIOD_EXT_PULL_UP)
> > + val = true;
> > + else if (state->flags & GPIOD_EXT_PULL_DOWN)
> > + val = false;
> > + else
> > + val = state->flags & GPIOD_PULL_UP;
>
> bool also
>
> + val = !!(state->flags & GPIOD_PULL_UP );
>
>
> > + }
> >
> >   return val;
> >   }
>
>
> (...)
>
> Just to be sure that the sandbox gpio value is 0 or 1
>
> with the current code, sandbox_gpio_get_value can return GPIOD_EXT_HIGH
> or GPIOD_PULL_UP, and it is strange (even if result in int).

I think that is a hack to work around not having a 'bool' type, but we
do have one in U-Boot, so I feel it is better to use it, instead using
!!

See the 'bool val;' in that function.

>
>
> with these 2 changes, you can add my  Reviewed-by

Regards,
Simon


[PATCH v2 1/3] dm: i2c: allow disabling driver model in SPL

2021-02-08 Thread Igor Opaniuk
From: Igor Opaniuk 

At present if U-Boot proper uses driver model for I2C, then SPL has to
also. While this is desirable, it places a significant barrier to moving
to driver model in some cases. For example, with a space-constrained SPL
it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves
adjusting some drivers.

This patch introduces a separate Kconfig symbols for enabling DM_I2C and
DM_I2C_GPIO support in SPL.

This will also help to get away from dirty workarounds to
achieve non-DM I2C support for SPL, which is currently used in some
board header files like:

ifdef CONFIG_SPL_BUILD
undef CONFIG_DM_I2C
endif

Reviewed-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Signed-off-by: Igor Opaniuk 
---

Changes v2:
- R-b tags applied

 drivers/i2c/Kconfig   | 21 +
 drivers/i2c/Makefile  |  4 ++--
 drivers/misc/Makefile |  2 +-
 3 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 403602fddf..5fce14122d 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -14,6 +14,17 @@ config DM_I2C
  device (bus child) info is kept as parent plat. The interface
  is defined in include/i2c.h.
 
+config SPL_DM_I2C
+   bool "Enable Driver Model for I2C drivers in SPL"
+   depends on SPL_DM && DM_I2C
+   default y
+   help
+ Enable driver model for I2C. The I2C uclass interface: probe, read,
+ write and speed, is implemented with the bus drivers operations,
+ which provide methods for bus setting and data transfer. Each chip
+ device (bus child) info is kept as parent platdata. The interface
+ is defined in include/i2c.h.
+
 config I2C_CROS_EC_TUNNEL
tristate "Chrome OS EC tunnel I2C bus"
depends on CROS_EC
@@ -61,6 +72,16 @@ config DM_I2C_GPIO
  bindings are supported.
  Binding info: doc/device-tree-bindings/i2c/i2c-gpio.txt
 
+config SPL_DM_I2C_GPIO
+   bool "Enable Driver Model for software emulated I2C bus driver in SPL"
+   depends on SPL_DM && DM_I2C_GPIO && SPL_DM_GPIO && SPL_GPIO_SUPPORT
+   default y
+   help
+ Enable the i2c bus driver emulation by using the GPIOs. The bus GPIO
+ configuration is given by the device tree. Kernel-style device tree
+ bindings are supported.
+ Binding info: doc/device-tree-bindings/i2c/i2c-gpio.txt
+
 config SYS_I2C_AT91
bool "Atmel I2C driver"
depends on DM_I2C && ARCH_AT91
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 29aab0f9e3..acd27ac29d 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -2,9 +2,9 @@
 #
 # (C) Copyright 2000-2007
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-obj-$(CONFIG_DM_I2C) += i2c-uclass.o
+obj-$(CONFIG_$(SPL_)DM_I2C) += i2c-uclass.o
 ifdef CONFIG_ACPIGEN
-obj-$(CONFIG_DM_I2C) += acpi_i2c.o
+obj-$(CONFIG_$(SPL_)DM_I2C) += acpi_i2c.o
 endif
 obj-$(CONFIG_$(SPL_)DM_I2C_GPIO) += i2c-gpio.o
 obj-$(CONFIG_$(SPL_)I2C_CROS_EC_TUNNEL) += cros_ec_tunnel.o
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d737203704..1a49396007 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_SANDBOX) += p2sb_sandbox.o p2sb_emul.o
 obj-$(CONFIG_SANDBOX) += swap_case.o
 endif
 
-ifdef CONFIG_DM_I2C
+ifdef CONFIG_$(SPL_)DM_I2C
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_SANDBOX) += i2c_eeprom_emul.o
 endif
-- 
2.25.1



[PATCH v2 2/3] board: freescale: undef CONFIG_SPL_DM_I2C for SPL

2021-02-08 Thread Igor Opaniuk
From: Igor Opaniuk 

Replace CONFIG_DM_I2C undefs with CONFIG_SPL_DM_I2C for the SPL build
case. This should be moved to appropriate board defconfigs
in the future.

Signed-off-by: Igor Opaniuk 
---

(no changes since v1)

 include/configs/T104xRDB.h   | 2 +-
 include/configs/imx8mp_evk.h | 2 +-
 include/configs/ls1021atwr.h | 2 +-
 include/configs/ls1046a_common.h | 2 +-
 include/configs/phycore_imx8mp.h | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h
index aee00a86cf..f4d0aec42b 100644
--- a/include/configs/T104xRDB.h
+++ b/include/configs/T104xRDB.h
@@ -30,7 +30,7 @@
 #define CONFIG_SPL_SKIP_RELOCATE
 #define CONFIG_SPL_COMMON_INIT_DDR
 #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE
-#undef CONFIG_DM_I2C
+#undef CONFIG_SPL_DM_I2C
 #endif
 #define RESET_VECTOR_OFFSET0x27FFC
 #define BOOT_PAGE_OFFSET   0x27000
diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h
index 4850b1b934..33c5759b46 100644
--- a/include/configs/imx8mp_evk.h
+++ b/include/configs/imx8mp_evk.h
@@ -37,7 +37,7 @@
 #define CONFIG_POWER_I2C
 #define CONFIG_POWER_PCA9450
 
-#undef CONFIG_DM_I2C
+#undef CONFIG_SPL_DM_I2C
 #define CONFIG_SYS_I2C
 
 #endif
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 3e85bb3850..f2bf35ffa5 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -435,7 +435,7 @@
 
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_SYS_MONITOR_BASE CONFIG_SPL_TEXT_BASE
-#undef CONFIG_DM_I2C
+#undef CONFIG_SPL_DM_I2C
 #else
 #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE/* start of monitor */
 #endif
diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index d44a7f105e..b5bbb636da 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -16,7 +16,7 @@
 #define SPL_NO_QSPI
 #define SPL_NO_USB
 #define SPL_NO_SATA
-#undef CONFIG_DM_I2C
+#undef CONFIG_SPL_DM_I2C
 #endif
 #if defined(CONFIG_SPL_BUILD) && \
(defined(CONFIG_NAND_BOOT) || defined(CONFIG_QSPI_BOOT))
diff --git a/include/configs/phycore_imx8mp.h b/include/configs/phycore_imx8mp.h
index 889dd36e6e..dcd320f746 100644
--- a/include/configs/phycore_imx8mp.h
+++ b/include/configs/phycore_imx8mp.h
@@ -33,7 +33,7 @@
 #define CONFIG_POWER_I2C
 #define CONFIG_POWER_PCA9450
 
-#undef CONFIG_DM_I2C
+#undef CONFIG_SPL_DM_I2C
 #define CONFIG_SYS_I2C
 
 #endif
-- 
2.25.1



Re: [RFC PATCH v2 1/2] optee: obtain emmc rpmb info from dt

2021-02-08 Thread Igor Opaniuk
Hi Patrick,

On Mon, Feb 8, 2021 at 5:06 PM Patrick DELAUNAY
 wrote:
>
> Hi Igor,
>
> On 1/24/21 10:39 AM, Igor Opaniuk wrote:
> > From: Igor Opaniuk 
> >
> > Add support for rpmb-dev property in optee node.
> > Prioritize that provided eMMC info from DT for RPMB operations over
> > the one provided by OP-TEE OS core in RPC calls.
> >
> > Signed-off-by: Igor Opaniuk 
> > ---
> >
> > Changes in v2:
> > - Return NULL instead of ERR_PTR(-ENXIO) in get_rpmb_dev in case there
> >is no rpmb-dev property or somemithing went wrong
> >
> >   drivers/tee/optee/core.c  | 33 +
> >   drivers/tee/optee/optee_private.h |  2 +-
> >   drivers/tee/optee/rpmb.c  | 60 ++-
> >   3 files changed, 70 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > index b898c32edc..828ab9b00a 100644
> > --- a/drivers/tee/optee/core.c
> > +++ b/drivers/tee/optee/core.c
> > @@ -12,6 +12,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >
> >   #include "optee_smc.h"
> >   #include "optee_msg.h"
> > @@ -607,14 +608,46 @@ static optee_invoke_fn *get_invoke_func(struct 
> > udevice *dev)
> >   return ERR_PTR(-EINVAL);
> >   }
> >
> > +static struct mmc *get_rpmb_dev(struct udevice *dev)
> > +{
> > + struct udevice *mmc_dev;
> > + const fdt32_t *phandle_p;
> > + u32 phandle;
> > + int ret = 0;
> > +
> > + debug("optee: looking for rpmb device in DT.\n");
> > +
> > + phandle_p  = ofnode_get_property(dev_ofnode(dev),
> > +  "rpmb-dev", NULL);
> > + if (!phandle_p) {
> > + debug("optee: missing \"rpmb-dev\" property\n");
> > + return NULL;
> > + }
> > +
> > + phandle = fdt32_to_cpu(*phandle_p);
> > +
> > + ret = uclass_get_device_by_phandle_id(UCLASS_MMC, phandle, _dev);
> > + if (ret) {
> > + printf("optee: invalid phandle value in \"rpmb-dev\".\n");
> > + return NULL;
> > + }
> > +
> > + debug("optee: using phandle %d from \"rpmd-dev\" property.\n",
> > +   phandle);
> > + return mmc_get_mmc_dev(mmc_dev);
> > +}
> > +
> >   static int optee_of_to_plat(struct udevice *dev)
> >   {
> >   struct optee_pdata *pdata = dev_get_plat(dev);
> > + struct optee_private *priv = dev_get_priv(dev);
> >
> >   pdata->invoke_fn = get_invoke_func(dev);
> >   if (IS_ERR(pdata->invoke_fn))
> >   return PTR_ERR(pdata->invoke_fn);
> >
>
> Normally optee_of_to_plat should initialized only the platdata and not the 
> private date
> (initialized during probe or driver execution)

To be honest that was my initial intention to do that way,
but that would have required a complete overhaul of all functions in
optee/rpmb.c,
so I just tried to find a "golden mean" between the approach you described
and something less intrusive.

>
> And no need to initialize rpmb_mmcif CONFIG_CMD_OPTEE_RPMBI is not activated,
Yeah, will fix that.

>
> I proposed:
>
> struct optee_pdata {
>  optee_invoke_fn *invoke_fn;
>  struct mmc *rpmb_mmc;
> };
>
> + if (IS_ENABLED(CONFIG_CMD_OPTEE_RPMBI))
>
> +pdata->rpmb_mmc = get_rpmb_dev(dev);
>
> > + priv->rpmb_mmc = get_rpmb_dev(dev);
> > +
> >   return 0;
> >   }
> >
> > diff --git a/drivers/tee/optee/optee_private.h 
> > b/drivers/tee/optee/optee_private.h
> > index 1f07a27ee4..8e5a280622 100644
> > --- a/drivers/tee/optee/optee_private.h
> > +++ b/drivers/tee/optee/optee_private.h
> > @@ -19,8 +19,8 @@
> >*/
> >   struct optee_private {
> >   struct mmc *rpmb_mmc;
> > - int rpmb_dev_id;
> >   int rpmb_original_part;
> > + bool rpmb_inited;
> >   };
> >
> >   struct optee_msg_arg;
> > diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> > index 0804fc963c..0137c44be1 100644
> > --- a/drivers/tee/optee/rpmb.c
> > +++ b/drivers/tee/optee/rpmb.c
> > @@ -45,55 +45,67 @@ static void release_mmc(struct optee_private *priv)
> >   {
> >   int rc;
> >
> > - if (!priv->rpmb_mmc)
> > + if (!priv->rpmb_mmc || !priv->rpmb_inited)
> >   return;
> >
> > - rc = blk_select_hwpart_devnum(IF_TYPE_MMC, priv->rpmb_dev_id,
> > -   priv->rpmb_original_part);
> > + rc = mmc_switch_part(priv->rpmb_mmc, priv->rpmb_original_part);
> >   if (rc)
> >   debug("%s: blk_select_hwpart_devnum() failed: %d\n",
> > __func__, rc);
> >
> > - priv->rpmb_mmc = NULL;
> > + priv->rpmb_inited = false;
> > +}
> > +
> > +static int check_mmc(struct mmc *mmc)
> > +{
> > + if (!mmc) {
> > + debug("Cannot find RPMB device\n");
> > + return -ENODEV;
> > + }
> > + if (!(mmc->version & MMC_VERSION_MMC)) {
> > + debug("Device id is not an eMMC device\n");
> > + return -ENODEV;
> > + }
> > + if (mmc->version < MMC_VERSION_4_41) {
> > + debug("RPMB is 

Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it

2021-02-08 Thread Pali Rohár
On Monday 08 February 2021 23:45:37 Marek Vasut wrote:
> On 2/8/21 11:34 PM, Pali Rohár wrote:
> > On Monday 08 February 2021 23:21:38 Pali Rohár wrote:
> > > On Monday 08 February 2021 23:15:33 Lukasz Majewski wrote:
> > > > Hi Pali,
> > > > 
> > > > >  Resended v2 patch series with fixed commit messages
> > > > > 
> > > > > This patch series fix usbtty code (serial console via USB peripheral
> > > > > mode), fix underlying musb peripheral code, fix compilation of
> > > > > CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to
> > > > > decrease size of U-Boot binary and finally enable usbtty serial
> > > > > console for Nokia RX-51.
> > > > > 
> > > > > With this patch series debugging of Nokia RX-51 can be done also via
> > > > > USB serial console.
> > > > > 
> > > > > It fixes also stability of musb code and allows usage of file
> > > > > transfers via Kermit protocol on Nokia RX-51. Kermit file transfer
> > > > > via U-Boot loadb command is stable on Nokia N900 and gives about
> > > > > 52kB/s transfer rate.
> > > > > 
> > > > > On computer this serial console is accessible via /dev/ttyACM0 device.
> > > > > 
> > > > 
> > > > I've integrated your patchset and now it turns out that the u-boot size
> > > > is too big:
> > > > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results
> > > > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d
> > > 
> > > Ah :-(
> > > In November when I sent these patches, U-Boot binary was smaller.
> > > 
> > > > The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing
> > > > 
> > > > Have you experienced similar issues?
> > > 
> > > Yes, memory for U-Boot is limited. It is needed to decrease size of
> > > U-Boot binary and then it will work.
> > > 
> > > I will try to look at it later and find some dead code which can be
> > > commented or removed to decrease binary size...
> > 
> > Just a quick test, could you try to add
> > 
> > CONFIG_OPTIMIZE_INLINING=y
> > 
> > into configs/nokia_rx51_defconfig file, if it helps?
> 
> Surely you can try build-testing the patches yourself ? :-)

They are working fine on my two testes machines. I do not have this
problem which Lukasz described. Otherwise I would not send patches to
mailing list for upstream. Also I have tested CONFIG_OPTIMIZE_INLINING
and it decreased size of u-boot binary on my machine.

But I already figured out that "working on my machine" does not mean
that it would also on other machines... In past I hit compiler bugs
which caused that on my machine gcc compiled code correctly but on other
machine with older (buggy) gcc code was compiled incorrectly and result
of computation was incorrect.

That is why I'm asking if people who triggered mentioned issue can check
if proposed fix helps.

Btw, if I understood correctly without CONFIG_OPTIMIZE_INLINING U-Boot
redefine "inline" to "always inline". And with CONFIG_OPTIMIZE_INLINING
"inline" is "inline". From past I know that gcc is very smart and can
decide that it is better to ignore inlining some functions for -Os size
optimizations.


Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it

2021-02-08 Thread Marek Vasut

On 2/8/21 11:34 PM, Pali Rohár wrote:

On Monday 08 February 2021 23:21:38 Pali Rohár wrote:

On Monday 08 February 2021 23:15:33 Lukasz Majewski wrote:

Hi Pali,


 Resended v2 patch series with fixed commit messages

This patch series fix usbtty code (serial console via USB peripheral
mode), fix underlying musb peripheral code, fix compilation of
CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to
decrease size of U-Boot binary and finally enable usbtty serial
console for Nokia RX-51.

With this patch series debugging of Nokia RX-51 can be done also via
USB serial console.

It fixes also stability of musb code and allows usage of file
transfers via Kermit protocol on Nokia RX-51. Kermit file transfer
via U-Boot loadb command is stable on Nokia N900 and gives about
52kB/s transfer rate.

On computer this serial console is accessible via /dev/ttyACM0 device.



I've integrated your patchset and now it turns out that the u-boot size
is too big:
https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results
https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d


Ah :-(
In November when I sent these patches, U-Boot binary was smaller.


The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing

Have you experienced similar issues?


Yes, memory for U-Boot is limited. It is needed to decrease size of
U-Boot binary and then it will work.

I will try to look at it later and find some dead code which can be
commented or removed to decrease binary size...


Just a quick test, could you try to add

CONFIG_OPTIMIZE_INLINING=y

into configs/nokia_rx51_defconfig file, if it helps?


Surely you can try build-testing the patches yourself ? :-)


Re: [PATCH 4/4] timer: imx-gpt: Add basic timer support for i.MX SoCs family

2021-02-08 Thread Giulio Benetti

Hi Jesse,

this patch should have been squashed with patch 1/4 as already suggested.

On 2/8/21 1:24 AM, Jesse Taube wrote:

Signed-off-by: Jesse Taube 
Cc: Stefano Babic 
Cc: Giulio Benetti 
Cc: Jesse Taube 

This timer driver is using GPT Timer (General Purpose Timer) available
on almost all i.MX SoCs family. Add code to enable timer. Add code get a 
defualt prescaler.
Add defines for register masks.
---
  drivers/timer/imx-gpt-timer.c | 50 +--
  1 file changed, 36 insertions(+), 14 deletions(-)

diff --git a/drivers/timer/imx-gpt-timer.c b/drivers/timer/imx-gpt-timer.c
index c4e8c12a42..ed6487af97 100644
--- a/drivers/timer/imx-gpt-timer.c
+++ b/drivers/timer/imx-gpt-timer.c
@@ -13,8 +13,29 @@
  
  #include 
  
-#define GPT_CR_SWR	0x8000

+#define GPT_CR_SWR 0x8000
+#define GPT_CR_CLKSRC  0x01C0
+#define GPT_CR_EN_24M  0x4000
+#define GPT_CR_EN  0x0001
+#define GPT_PR_PRESCALER   0x0FFF
+#define GPT_PR_PRESCALER24M0xF000
  
+

+


Please avoid one whiteline


+#define NO_CLOCK   (0)
+#define IPG_CLK(1<<6)
+#define IPG_CLK_HF (2<<6)
+#define IPG_EXT(3<<6)
+#define IPG_CLK_32K(4<<6)
+#define IPG_CLK_24M(5<<6)
+
+


ditto


+/*
+ipg_clk ipg_clk_root Peripheral clock
+ipg_clk_32k ckil_sync_clk_root Low-frequency reference clock (32 kHz)
+ipg_clk_highfreq perclk_clk_root High-frequency reference clock
+ipg_clk_s ipg_clk_root Peripheral access clock
+*/
  struct imx_gpt_timer_regs {
u32 cr;
u32 pr;
@@ -32,14 +53,12 @@ struct imx_gpt_timer_priv {
struct imx_gpt_timer_regs *base;
  };
  
-static int imx_gpt_timer_get_count(struct udevice *dev, u64 *count)

+static u64 imx_gpt_timer_get_count(struct udevice *dev)
  {
struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
struct imx_gpt_timer_regs *regs = priv->base;
  
-	*count = readl(>cnt);

-
-   return 0;
+   return readl(>cnt);
  }
  
  static int imx_gpt_timer_probe(struct udevice *dev)

@@ -50,7 +69,7 @@ static int imx_gpt_timer_probe(struct udevice *dev)
struct clk clk;
fdt_addr_t addr;
u32 prescaler;
-   u32 rate, pr;
+   u32 rate;
int ret;
  
  	addr = dev_read_addr(dev);

@@ -84,16 +103,20 @@ static int imx_gpt_timer_probe(struct udevice *dev)
  
  	/* Get timer clock rate */

rate = clk_get_rate();
+   if((int)rate <= 0){
+   debug("Could not get clock rate, setting to default 
value...\n");
+   rate = 105600UL;
+   }


Here I don't agree, having a timer ticking at 1ms(1Khz) doesn't justify
having a parent clock of 1Ghz. What I've thought here was using 24M
crystal directly. But obviously this is determined by clk_get_rate().

So IMHO I would keep 24M only as source and only if needed I would make 
it different. Using only that reference you make this driver accepting 
only a 24M clock, but to begin it's enough for me. Most of i.MX* SoC 
setup exactly timer using 24M source clock.


Also using ipg clock implies that clock drivers supports it, but it 
doesn't so this driver shouldn't work as is.


Best regards
--
Giulio Benetti
Benetti Engineering sas

  
  	/* we set timer prescaler to obtain a 1MHz timer counter frequency */

-// pr = (rate / CONFIG_SYS_HZ_CLOCK) - 1;
-   writel(pr, >pr);
-
+   prescaler = (rate / CONFIG_SYS_HZ_CLOCK) - 1;
+   writel(GPT_PR_PRESCALER, >pr);   
/* Set timer frequency to 1MHz */
-   uc_priv->clock_rate = rate / prescaler;
-
+   uc_priv->clock_rate = CONFIG_SYS_HZ_CLOCK;
+   clrbits_le32(>cr,GPT_CR_CLKSRC);
+   setbits_le32(>cr, IPG_CLK);
/* start timer */
-// setbits_le32(>cr1, CR1_CEN);
+   setbits_le32(>cr, GPT_CR_EN);
  
  	return 0;

  }
@@ -111,8 +134,7 @@ U_BOOT_DRIVER(imx_gpt_timer) = {
.name = "imx_gpt_timer",
.id = UCLASS_TIMER,
.of_match = imx_gpt_timer_ids,
-   .priv_auto_alloc_size = sizeof(struct imx_gpt_timer_priv),
+   .priv_auto = sizeof(struct imx_gpt_timer_priv),
.probe = imx_gpt_timer_probe,
.ops = _gpt_timer_ops,
  };
-






Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it

2021-02-08 Thread Pali Rohár
On Monday 08 February 2021 23:21:38 Pali Rohár wrote:
> On Monday 08 February 2021 23:15:33 Lukasz Majewski wrote:
> > Hi Pali,
> > 
> > > Resended v2 patch series with fixed commit messages
> > > 
> > > This patch series fix usbtty code (serial console via USB peripheral
> > > mode), fix underlying musb peripheral code, fix compilation of
> > > CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to
> > > decrease size of U-Boot binary and finally enable usbtty serial
> > > console for Nokia RX-51.
> > > 
> > > With this patch series debugging of Nokia RX-51 can be done also via
> > > USB serial console.
> > > 
> > > It fixes also stability of musb code and allows usage of file
> > > transfers via Kermit protocol on Nokia RX-51. Kermit file transfer
> > > via U-Boot loadb command is stable on Nokia N900 and gives about
> > > 52kB/s transfer rate.
> > > 
> > > On computer this serial console is accessible via /dev/ttyACM0 device.
> > > 
> > 
> > I've integrated your patchset and now it turns out that the u-boot size
> > is too big:
> > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results
> > https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d
> 
> Ah :-(
> In November when I sent these patches, U-Boot binary was smaller.
> 
> > The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing
> > 
> > Have you experienced similar issues?
> 
> Yes, memory for U-Boot is limited. It is needed to decrease size of
> U-Boot binary and then it will work.
> 
> I will try to look at it later and find some dead code which can be
> commented or removed to decrease binary size...

Just a quick test, could you try to add

CONFIG_OPTIMIZE_INLINING=y

into configs/nokia_rx51_defconfig file, if it helps?

> If you have an idea what increased U-Boot side it could help.
> 
> > > Pali Rohár (16):
> > >   serial: usbtty: Fix puts function
> > >   serial: usbtty: Send urb data in correct order
> > >   usb: musb: Fix compilation of gadget code
> > >   usb: musb: Always clear the data toggle bit when configuring ep
> > >   usb: musb: Fix configuring FIFO for endpoints
> > >   usb: musb: Read value of PERI_RXCSR to 16bit variable
> > >   usb: musb: Fix transmission of bigger buffers
> > >   usb: musb: Fix receiving of bigger buffers
> > >   usb: musb: Fix handling interrupts for EP0 and SET ADDRESS commmand
> > >   usb: musb: Ensure that we set musb dynamic FIFO buffer for every
> > > endpoint
> > >   usb: gadget: Use dbg_ep0() macro instead of serial_printf()
> > >   arm: omap3: Compile lowlevel_init() function only when it is used
> > >   arm: omap3: Compile s_init() function only when it is used
> > >   Nokia RX-51: Remove function set_muxconf_regs()
> > >   Nokia RX-51: Move content of rx51.h to rx51.c
> > >   Nokia RX-51: Enable usbtty serial console by default
> > > 
> > >  Makefile  |   1 +
> > >  arch/arm/mach-omap2/omap3/board.c |   3 +
> > >  arch/arm/mach-omap2/omap3/lowlevel_init.S |   6 +-
> > >  board/nokia/rx51/rx51.c   |  28 +-
> > >  board/nokia/rx51/rx51.h   | 377
> > > -- configs/nokia_rx51_defconfig  |
> > > 7 +- doc/README.nokia_rx51 |  15 +-
> > >  drivers/serial/usbtty.c   |  16 +-
> > >  drivers/usb/gadget/ep0.c  |  16 +-
> > >  drivers/usb/musb/musb_core.c  |  12 +-
> > >  drivers/usb/musb/musb_udc.c   |  61 ++--
> > >  include/configs/nokia_rx51.h  |  21 +-
> > >  12 files changed, 82 insertions(+), 481 deletions(-)
> > >  delete mode 100644 board/nokia/rx51/rx51.h
> > > 
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
> 
> 


Re: [PATCH 1/2] efi: Add ESRT to the EFI system table

2021-02-08 Thread Heinrich Schuchardt

On 2/8/21 11:18 PM, Heinrich Schuchardt wrote:

On 2/8/21 1:52 PM, Jose Marinho wrote:

The ESRT is initialised during efi_init_objlist after
efi_initialize_system_table().

The ESRT is initially created with size for 50 FW image entries.
The ESRT is resized when it runs out of space. Every resize adds 50
additional entries.
The ESRT is populated from information provided by FMP instances only.

Signed-off-by: Jose Marinho



 one limitation is, if any FMP instance is installed and then
uninstalled during the same boottime flow, the ESRT entries will not be
removed
 this limitation is because I cannot find a proper UEFI way to
hook to a FMP protocol uninstall.
 register an event with RegisterProtocolNotify().
 EFI_CALL(efi_register_protocol_notify(...)) after exporting the
function in /include/efi_loader
 The event can be created with efi_create_event().



RegisterProtocolNotifiy() only tells you that a protocol is newly
installed, or reinstalled.

If you open the protocol with EFI_OPEN_PROTOCOL_BY_DRIVER, than
EFI_BOOT_SERVICES.UninstallProtocolInterface() will call
EFI_BOOT_SERVICES.DisconnectController() for the driver which will end
up in calling the Stop() function of the driver binding protocol.

Instead of using RegisterProtocolNotifiy() it would be better if the FMP
driver would call ConnectController() after installing its protocol.

This project is gone to show you all delights of EFI driver development.

Best regards

Heinrich


Re: [PATCH 3/4] imxrt1050 dtsi gpt1 node

2021-02-08 Thread Giulio Benetti

Subject should be:
ARM: dts: imxrt1050: add gpt1 node

Please try to:
# git log arch/arm/dts/imxrt1050.dtsi
this is to see the form already used to begin commit.
In general, try to imitate what others do in commited patches.

Best regards
--
Giulio Benetti
Benetti Engineering sas

On 2/8/21 1:24 AM, Jesse Taube wrote:

Signed-off-by: Jesse Taube 
Cc: Stefano Babic 
Cc: Giulio Benetti 
Cc: Jesse Taube 
---
  arch/arm/dts/imxrt1050.dtsi | 8 
  1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/imxrt1050.dtsi b/arch/arm/dts/imxrt1050.dtsi
index a9281001e5..47a1d24973 100644
--- a/arch/arm/dts/imxrt1050.dtsi
+++ b/arch/arm/dts/imxrt1050.dtsi
@@ -154,5 +154,13 @@
clock-names = "per";
status = "disabled";
};
+
+   gpt1: gpt1@401ec000 {
+   compatible = "fsl,imxrt-gpt";
+   reg = <0x401ec000 0x4000>;
+   interrupts = <100>;
+   clocks = < IMXRT1050_CLK_PIT_GPT>;
+   status = "disabled";
+   };
};
  };



Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it

2021-02-08 Thread Pali Rohár
On Monday 08 February 2021 23:15:33 Lukasz Majewski wrote:
> Hi Pali,
> 
> > Resended v2 patch series with fixed commit messages
> > 
> > This patch series fix usbtty code (serial console via USB peripheral
> > mode), fix underlying musb peripheral code, fix compilation of
> > CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to
> > decrease size of U-Boot binary and finally enable usbtty serial
> > console for Nokia RX-51.
> > 
> > With this patch series debugging of Nokia RX-51 can be done also via
> > USB serial console.
> > 
> > It fixes also stability of musb code and allows usage of file
> > transfers via Kermit protocol on Nokia RX-51. Kermit file transfer
> > via U-Boot loadb command is stable on Nokia N900 and gives about
> > 52kB/s transfer rate.
> > 
> > On computer this serial console is accessible via /dev/ttyACM0 device.
> > 
> 
> I've integrated your patchset and now it turns out that the u-boot size
> is too big:
> https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results
> https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d

Ah :-(
In November when I sent these patches, U-Boot binary was smaller.

> The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing
> 
> Have you experienced similar issues?

Yes, memory for U-Boot is limited. It is needed to decrease size of
U-Boot binary and then it will work.

I will try to look at it later and find some dead code which can be
commented or removed to decrease binary size...

If you have an idea what increased U-Boot side it could help.

> > Pali Rohár (16):
> >   serial: usbtty: Fix puts function
> >   serial: usbtty: Send urb data in correct order
> >   usb: musb: Fix compilation of gadget code
> >   usb: musb: Always clear the data toggle bit when configuring ep
> >   usb: musb: Fix configuring FIFO for endpoints
> >   usb: musb: Read value of PERI_RXCSR to 16bit variable
> >   usb: musb: Fix transmission of bigger buffers
> >   usb: musb: Fix receiving of bigger buffers
> >   usb: musb: Fix handling interrupts for EP0 and SET ADDRESS commmand
> >   usb: musb: Ensure that we set musb dynamic FIFO buffer for every
> > endpoint
> >   usb: gadget: Use dbg_ep0() macro instead of serial_printf()
> >   arm: omap3: Compile lowlevel_init() function only when it is used
> >   arm: omap3: Compile s_init() function only when it is used
> >   Nokia RX-51: Remove function set_muxconf_regs()
> >   Nokia RX-51: Move content of rx51.h to rx51.c
> >   Nokia RX-51: Enable usbtty serial console by default
> > 
> >  Makefile  |   1 +
> >  arch/arm/mach-omap2/omap3/board.c |   3 +
> >  arch/arm/mach-omap2/omap3/lowlevel_init.S |   6 +-
> >  board/nokia/rx51/rx51.c   |  28 +-
> >  board/nokia/rx51/rx51.h   | 377
> > -- configs/nokia_rx51_defconfig  |
> > 7 +- doc/README.nokia_rx51 |  15 +-
> >  drivers/serial/usbtty.c   |  16 +-
> >  drivers/usb/gadget/ep0.c  |  16 +-
> >  drivers/usb/musb/musb_core.c  |  12 +-
> >  drivers/usb/musb/musb_udc.c   |  61 ++--
> >  include/configs/nokia_rx51.h  |  21 +-
> >  12 files changed, 82 insertions(+), 481 deletions(-)
> >  delete mode 100644 board/nokia/rx51/rx51.h
> > 
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de




Re: [PATCH 1/4] timer: imx-gpt: Add timer support for i.MX SoCs family

2021-02-08 Thread Giulio Benetti

Hi Jesse,

On 2/8/21 1:24 AM, Jesse Taube wrote:

This timer driver is using GPT Timer (General Purpose Timer) available
on almost all i.MX SoCs family.

Signed-off-by: Giulio Benetti 
Cc: Stefano Babic 
Cc: Giulio Benetti 
Cc: Jesse Taube 


All these ^^^ Cc in commit log are useless in this case, they are useful 
only in the case people are not listed when calling get_maintainers.pl
or because you specifically need them to be in Cc. Your name/e-mail 
should be present as SoB and not as Cc because you're sending the patch, 
so add Signed-off-by instead of Cc for you entry and in case you did 
some modification write it like:


Signed-off-by: Giulio Benetti 
Signed-off-by: Jesse Taube 
[Jesse: changed this, set this to etc.]

This way authorship is kept, but you write what you have done on this patch.


---
  drivers/timer/Kconfig |   7 ++
  drivers/timer/Makefile|   1 +
  drivers/timer/imx-gpt-timer.c | 118 ++
  3 files changed, 126 insertions(+)
  create mode 100644 drivers/timer/imx-gpt-timer.c

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 80743a2551..ee81dfa776 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -227,4 +227,11 @@ config MCHP_PIT64B_TIMER
  Select this to enable support for Microchip 64-bit periodic
  interval timer.
  
+config IMX_GPT_TIMER

+   bool "NXP i.MX GPT timer support"
+   depends on TIMER
+   help
+ Select this to enable support for the timer found on
+ NXP i.MX devices.
+
  endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index eb5c48cc6c..e214ba7268 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_STM32_TIMER) += stm32_timer.o
  obj-$(CONFIG_X86_TSC_TIMER)   += tsc_timer.o
  obj-$(CONFIG_MTK_TIMER)   += mtk_timer.o
  obj-$(CONFIG_MCHP_PIT64B_TIMER)   += mchp-pit64b-timer.o
+obj-$(CONFIG_IMX_GPT_TIMER)+= imx-gpt-timer.o
diff --git a/drivers/timer/imx-gpt-timer.c b/drivers/timer/imx-gpt-timer.c
new file mode 100644
index 00..c4e8c12a42
--- /dev/null
+++ b/drivers/timer/imx-gpt-timer.c
@@ -0,0 +1,118 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020
+ * Author(s): Giulio Benetti 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define GPT_CR_SWR 0x8000
+
+struct imx_gpt_timer_regs {
+   u32 cr;
+   u32 pr;
+   u32 sr;
+   u32 ir;
+   u32 ocr1;
+   u32 ocr2;
+   u32 ocr3;
+   u32 icr1;
+   u32 icr2;
+   u32 cnt;
+};
+
+struct imx_gpt_timer_priv {
+   struct imx_gpt_timer_regs *base;
+};
+
+static int imx_gpt_timer_get_count(struct udevice *dev, u64 *count)
+{
+   struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+   struct imx_gpt_timer_regs *regs = priv->base;
+
+   *count = readl(>cnt);
+
+   return 0;
+}
+
+static int imx_gpt_timer_probe(struct udevice *dev)
+{
+   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+   struct imx_gpt_timer_regs *regs;
+   struct clk clk;
+   fdt_addr_t addr;
+   u32 prescaler;
+   u32 rate, pr;
+   int ret;
+
+   addr = dev_read_addr(dev);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   priv->base = (struct imx_gpt_timer_regs *)addr;
+
+   /* TODO: Retrieve clock-source */


This is something that prevents driver from working so a patch like this 
should not be accepted.



+
+   /* TODO: Retrieve prescaler */


ditto


+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0)
+   return ret;
+
+   ret = clk_enable();
+   if (ret) {
+   dev_err(dev, "failed to enable clock\n");
+   return ret;
+   }
+
+   regs = priv->base;
+
+   /* Reset the timer */
+   setbits_le32(>cr, GPT_CR_SWR);
+
+   /* Wait for timer to finish reset */
+   while(readl(>cr) & GPT_CR_SWR)
+   ;
+
+   /* Get timer clock rate */
+   rate = clk_get_rate();
+
+   /* we set timer prescaler to obtain a 1MHz timer counter frequency */
+// pr = (rate / CONFIG_SYS_HZ_CLOCK) - 1;


This ^^^ was another TODO: I've put there, ditto.
Also take care to never leave commented code.


+   writel(pr, >pr);
+
+   /* Set timer frequency to 1MHz */
+   uc_priv->clock_rate = rate / prescaler;
+
+   /* start timer */
+// setbits_le32(>cr1, CR1_CEN);


ditto


+
+   return 0;
+}
+
+static const struct timer_ops imx_gpt_timer_ops = {
+   .get_count = imx_gpt_timer_get_count,
+};
+
+static const struct udevice_id imx_gpt_timer_ids[] = {
+   { .compatible = "fsl,imxrt-gpt" },
+   {}
+};
+
+U_BOOT_DRIVER(imx_gpt_timer) = {
+   .name = "imx_gpt_timer",
+   .id = UCLASS_TIMER,
+   .of_match = imx_gpt_timer_ids,
+   .priv_auto_alloc_size = sizeof(struct 

Re: [PATCH 1/2] efi: Add ESRT to the EFI system table

2021-02-08 Thread Heinrich Schuchardt

On 2/8/21 1:52 PM, Jose Marinho wrote:

The ESRT is initialised during efi_init_objlist after
efi_initialize_system_table().

The ESRT is initially created with size for 50 FW image entries.
The ESRT is resized when it runs out of space. Every resize adds 50
additional entries.
The ESRT is populated from information provided by FMP instances only.

Signed-off-by: Jose Marinho



 one limitation is, if any FMP instance is installed and then
uninstalled during the same boottime flow, the ESRT entries will not be
removed
 this limitation is because I cannot find a proper UEFI way to
hook to a FMP protocol uninstall.
 register an event with RegisterProtocolNotify().
 EFI_CALL(efi_register_protocol_notify(...)) after exporting the
function in /include/efi_loader
 The event can be created with efi_create_event().


Re: [RESEND v2 PATCH 00/16] Nokia RX-51: Fix USB TTY console and enable it

2021-02-08 Thread Lukasz Majewski
Hi Pali,

> Resended v2 patch series with fixed commit messages
> 
> This patch series fix usbtty code (serial console via USB peripheral
> mode), fix underlying musb peripheral code, fix compilation of
> CONFIG_USB_DEVICE (used by usbtty), remove unused Nokia RX-51 code to
> decrease size of U-Boot binary and finally enable usbtty serial
> console for Nokia RX-51.
> 
> With this patch series debugging of Nokia RX-51 can be done also via
> USB serial console.
> 
> It fixes also stability of musb code and allows usage of file
> transfers via Kermit protocol on Nokia RX-51. Kermit file transfer
> via U-Boot loadb command is stable on Nokia N900 and gives about
> 52kB/s transfer rate.
> 
> On computer this serial console is accessible via /dev/ttyACM0 device.
> 

I've integrated your patchset and now it turns out that the u-boot size
is too big:
https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=results
https://dev.azure.com/lukma633/U-Boot/_build/results?buildId=24=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67=f9a6b761-daa3-500f-4840-65a939c5040d

The branch is https://github.com/lmajewski/u-boot-dfu/tree/testing

Have you experienced similar issues?

> Pali Rohár (16):
>   serial: usbtty: Fix puts function
>   serial: usbtty: Send urb data in correct order
>   usb: musb: Fix compilation of gadget code
>   usb: musb: Always clear the data toggle bit when configuring ep
>   usb: musb: Fix configuring FIFO for endpoints
>   usb: musb: Read value of PERI_RXCSR to 16bit variable
>   usb: musb: Fix transmission of bigger buffers
>   usb: musb: Fix receiving of bigger buffers
>   usb: musb: Fix handling interrupts for EP0 and SET ADDRESS commmand
>   usb: musb: Ensure that we set musb dynamic FIFO buffer for every
> endpoint
>   usb: gadget: Use dbg_ep0() macro instead of serial_printf()
>   arm: omap3: Compile lowlevel_init() function only when it is used
>   arm: omap3: Compile s_init() function only when it is used
>   Nokia RX-51: Remove function set_muxconf_regs()
>   Nokia RX-51: Move content of rx51.h to rx51.c
>   Nokia RX-51: Enable usbtty serial console by default
> 
>  Makefile  |   1 +
>  arch/arm/mach-omap2/omap3/board.c |   3 +
>  arch/arm/mach-omap2/omap3/lowlevel_init.S |   6 +-
>  board/nokia/rx51/rx51.c   |  28 +-
>  board/nokia/rx51/rx51.h   | 377
> -- configs/nokia_rx51_defconfig  |
> 7 +- doc/README.nokia_rx51 |  15 +-
>  drivers/serial/usbtty.c   |  16 +-
>  drivers/usb/gadget/ep0.c  |  16 +-
>  drivers/usb/musb/musb_core.c  |  12 +-
>  drivers/usb/musb/musb_udc.c   |  61 ++--
>  include/configs/nokia_rx51.h  |  21 +-
>  12 files changed, 82 insertions(+), 481 deletions(-)
>  delete mode 100644 board/nokia/rx51/rx51.h
> 




Best regards,

Lukasz Majewski

--

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


pgpfOBJ3SyXsQ.pgp
Description: OpenPGP digital signature


Re: [PATCH 0/3] timer: imx-gpt: Add timer support for i.MX SoCs family

2021-02-08 Thread Giulio Benetti

Hi Jesse,

first of all thank you for helping me with this porting :-)

On 2/8/21 1:24 AM, Jesse Taube wrote:

Add basic driver support for the IMX General Purpose Timer (GPT) available
on almost all i.MX SoCs family.

Giulio Benetti (3):
   timer: imx-gpt: Add timer support for i.MX SoCs family
   dt-bindings: clock: imxrt1050: add PIT GPT clock
   imxrt1050 dtsi gpt1 node

Jesse Taube (1):
   timer: imx-gpt: Add basic timer support for i.MX SoCs family



Cover letter subject indicates [PATCH 0/3] as you're sending cover 
letter plus 3 patches but actually you're sending 4.


You should retry to:
# git format-patch -s -M -o outgoing -4 --cover-letter

and then:
# cd outgoing
edit cover-letter(patch-)
# cd ..
# ./scripts/get_maintainers.pl outgoing/*
# git send-mail --to "..." --cc "u-boot..." outgoing/*.patch

This way works, obviously you have to substitute "Names " on 
--to --cc


Best regards
--
Giulio Benetti
Benetti Engineering sas


Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver

2021-02-08 Thread Heinrich Schuchardt

On 2/8/21 6:56 PM, Heinrich Schuchardt wrote:

On 2/8/21 6:08 PM, Simon Glass wrote:

HI Marek,

On Mon, 8 Feb 2021 at 09:10, Marek Szyprowski
 wrote:


Hi Simon,

On 06.02.2021 17:21, Simon Glass wrote:

On Thu, 4 Feb 2021 at 03:36, Marek Szyprowski
 wrote:

...
Could you give me a bit more hints or point where to start? I've tried
to build sandbox, but it fails for v2021.01 release (I've did make
sandbox_defconfig && make all). I assume I would need to add adc and
adc-keys devices to some sandbox dts and some code triggering and
checking the key values, but that's all I know now.

Well you do need to be able to build sandbox or you will get
nowhere...what error did you get? Once we understand what went wrong
we can update the docs. Maybe it is missing a dependency.


$ gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

$ git checkout v2021.01

$ make sandbox_defconfig
#
# configuration written to .config
#

$ make
scripts/kconfig/conf  --syncconfig Kconfig
    CFG u-boot.cfg
    GEN include/autoconf.mk
    GEN include/autoconf.mk.dep
    CFGCHK  u-boot.cfg
    UPD include/generated/timestamp_autogenerated.h
    HOSTCC  tools/mkenvimage.o
    HOSTLD  tools/mkenvimage
    HOSTCC  tools/fit_image.o
    HOSTCC  tools/image-host.o
    HOSTCC  tools/dumpimage.o
    HOSTLD  tools/dumpimage
    HOSTCC  tools/mkimage.o
    HOSTLD  tools/mkimage
    HOSTLD  tools/fit_info
    HOSTLD  tools/fit_check_sign

...

    CC  arch/sandbox/cpu/cpu.o
In file included from include/common.h:26:0,
   from arch/sandbox/cpu/cpu.c:6:
include/asm/global_data.h:112:58: warning: call-clobbered register used
for global register variable
   #define DECLARE_GLOBAL_DATA_PTR  register volatile gd_t *gd asm
("r9")
    ^
include/dm/of.h:86:1: note: in expansion of macro
‘DECLARE_GLOBAL_DATA_PTR’
   DECLARE_GLOBAL_DATA_PTR;


This is pretty mysterious. Are you sure you are using an x86_64 machine?


r9 relates to ARMv7.

You have to unset CROSS_COMPILE when you build the sandbox.

The sandbox runs fine on aarch64.

There are a bunch of errors currently when building on 32bit
architectures. Simon has a lot of patches pending.


Hello Simon,

it was your patch

091401131085 ("command: Remove the cmd_tbl_t typedef") 2020-05-10

that broke building the sandbox on ARMv7.

Once your 32bit corrections are merged we should try to add
cross-compiling the sandbox for aarch64 and armv7 to Gitlab CI.

Best regards

Heinrich


Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-08 Thread Marek Behun
Stefan,

these patches should probably have a different From: - i.e. the
original authors should be preserved (from the first Signed-off-by
tags), for example:

  motib 
  Baruch Siach 
  heaterC 

But some of these are not full names, so I don't know whether I should
resend this or not.

What do you think?

Marek


[PATCH 1/1] sandbox: allow cross-compiling sandbox

2021-02-08 Thread Heinrich Schuchardt
UEFI test files like helloworld.efi require an architecture specific
PE-COFF header.

For non-sandbox the PE-COFF header is chosen by the target architecture.
For the sandbox we use the host architecture. This is not helpful for cross
compiling. Allow specifying the target architecture of the sandbox via
environment variable MK_ARCH, e.g.

make sandbox_defconfig NO_SDL=1
CROSS_COMPILE=aarch64-linux-gnu- NO_SDL=1 MK_ARCH=aarch64 make

Signed-off-by: Heinrich Schuchardt 
---
 Makefile |  2 +-
 doc/arch/sandbox.rst | 14 ++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 23dd11f723..286e5148ae 100644
--- a/Makefile
+++ b/Makefile
@@ -19,7 +19,7 @@ MAKEFLAGS += -rR --include-dir=$(CURDIR)

 # Determine host architecture
 include include/host_arch.h
-MK_ARCH="${shell uname -m}"
+MK_ARCH?="${shell uname -m}"
 unexport HOST_ARCH
 ifeq ("x86_64", $(MK_ARCH))
   export HOST_ARCH=$(HOST_ARCH_X86_64)
diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst
index 60ee1e0741..0dd9edc8cb 100644
--- a/doc/arch/sandbox.rst
+++ b/doc/arch/sandbox.rst
@@ -33,6 +33,20 @@ integers can only be built on 64-bit hosts.

 Note that standalone/API support is not available at present.

+Cross compiling
+---
+
+When cross compiling the U-Boot sandbox with CONFIG_EFI_LOADER=y the target
+architecture must be specified using the MK_ARCH environment variable using one
+of the values aarch64, armv7l, i386, riscv32, riscv64, x86_64, e.g.
+
+.. code-block:: bash
+
+NO_SDL=1 make sandbox_defconfig
+CROSS_COMPILE=aarch64-linux-gnu- MK_ARCH=aarch64 NO_SDL=1 make
+
+NO_SDL=1 was chosen in the example to remove the dependency on the SDL library.
+The graphical console will not be available.

 Prerequisites
 -
--
2.30.0



Re: [PATCH 3/4] arm: mvebu: turris_mox: Enable CONFIG_USB_XHCI_PCI

2021-02-08 Thread Marek Behun
Reviewed-by: Marek Behún 


Re: [PATCH 4/4] arm: mvebu: turris_mox: Enable NVMe support

2021-02-08 Thread Marek Behun
Reviewed-by: Marek Behún 


Re: [PATCH 2/4] arm: mvebu: turris_mox: Enable CONFIG_PCI_PNP

2021-02-08 Thread Marek Behun
Reviewed-by: Marek Behún 


Re: [PATCH 1/4] arm: a37xx: pci: Set Max Payload Size and Max Read Request Size to 512 bytes

2021-02-08 Thread Marek Behun
Reviewed-by: Marek Behún 


[PATCH u-boot-marvell 4/5] pci: pci_mvebu: refactor validation of addresses for config access

2021-02-08 Thread Marek Behún
Refactor validation of bdf parameter in mvebu_pcie_read/write_config
functions.

We can simplify the code by putting the validation into separate
function.

Also there are always only two devices visible on local bus:
* on slot configured by function mvebu_pcie_set_local_dev_nr()
  (by default this register is set to 0) there is a
  "Marvell Memory controller", which isn't useful in root complex
  mode,
* on all other slots the real PCIe card connected to the PCIe slot.

We can simplify the code even more by simply allowing access only to
the real PCIe card.

Signed-off-by: Marek Behún 
Cc: Stefan Roese 
Cc: Phil Sutter 
Cc: Mario Six 
Cc: Baruch Siach 
---
 drivers/pci/pci_mvebu.c | 59 ++---
 1 file changed, 31 insertions(+), 28 deletions(-)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 4ad73512a6..2d923b7d8d 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -78,7 +78,8 @@ struct mvebu_pcie {
u32 lane;
int devfn;
u32 lane_mask;
-   pci_dev_t dev;
+   int first_busno;
+   int local_dev;
char name[16];
unsigned int mem_target;
unsigned int mem_attr;
@@ -143,27 +144,36 @@ static inline struct mvebu_pcie *hose_to_pcie(struct 
pci_controller *hose)
return container_of(hose, struct mvebu_pcie, hose);
 }
 
+static int mvebu_pcie_valid_addr(struct mvebu_pcie *pcie, pci_dev_t bdf)
+{
+   /*
+* There are two devices visible on local bus:
+*   * on slot configured by function mvebu_pcie_set_local_dev_nr()
+* (by default this register is set to 0) there is a
+* "Marvell Memory controller", which isn't useful in root complex
+* mode,
+*   * on all other slots the real PCIe card connected to the PCIe slot.
+*
+* We therefore allow access only to the real PCIe card.
+*/
+   if (PCI_BUS(bdf) == pcie->first_busno &&
+   PCI_DEV(bdf) != !pcie->local_dev)
+   return 0;
+
+   return 1;
+}
+
 static int mvebu_pcie_read_config(const struct udevice *bus, pci_dev_t bdf,
  uint offset, ulong *valuep,
  enum pci_size_t size)
 {
struct mvebu_pcie *pcie = dev_get_plat(bus);
-   int local_bus = PCI_BUS(pcie->dev);
-   int local_dev = PCI_DEV(pcie->dev);
u32 data;
 
-   debug("PCIE CFG read:  loc_bus=%d loc_dev=%d (b,d,f)=(%2d,%2d,%2d) ",
- local_bus, local_dev, PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf));
+   debug("PCIE CFG read: (b,d,f)=(%2d,%2d,%2d) ",
+ PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf));
 
-   /* Don't access the local host controller via this API */
-   if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) == local_dev) {
-   debug("- skipping host controller\n");
-   *valuep = pci_get_ff(size);
-   return 0;
-   }
-
-   /* If local dev is 0, the first other dev can only be 1 */
-   if (PCI_BUS(bdf) == local_bus && local_dev == 0 && PCI_DEV(bdf) != 1) {
+   if (!mvebu_pcie_valid_addr(pcie, bdf)) {
debug("- out of range\n");
*valuep = pci_get_ff(size);
return 0;
@@ -185,22 +195,13 @@ static int mvebu_pcie_write_config(struct udevice *bus, 
pci_dev_t bdf,
   enum pci_size_t size)
 {
struct mvebu_pcie *pcie = dev_get_plat(bus);
-   int local_bus = PCI_BUS(pcie->dev);
-   int local_dev = PCI_DEV(pcie->dev);
u32 data;
 
-   debug("PCIE CFG write: loc_bus=%d loc_dev=%d (b,d,f)=(%2d,%2d,%2d) ",
- local_bus, local_dev, PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf));
+   debug("PCIE CFG write: (b,d,f)=(%2d,%2d,%2d) ",
+ PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf));
debug("(addr,size,val)=(0x%04x, %d, 0x%08lx)\n", offset, size, value);
 
-   /* Don't access the local host controller via this API */
-   if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) == local_dev) {
-   debug("- skipping host controller\n");
-   return 0;
-   }
-
-   /* If local dev is 0, the first other dev can only be 1 */
-   if (PCI_BUS(bdf) == local_bus && local_dev == 0 && PCI_DEV(bdf) != 1) {
+   if (!mvebu_pcie_valid_addr(pcie, bdf)) {
debug("- out of range\n");
return 0;
}
@@ -286,9 +287,11 @@ static int mvebu_pcie_probe(struct udevice *dev)
  readl(pcie->base), mvebu_pcie_get_local_bus_nr(pcie),
  mvebu_pcie_get_local_dev_nr(pcie));
 
+   pcie->first_busno = bus;
+   pcie->local_dev = 0;
+
mvebu_pcie_set_local_bus_nr(pcie, bus);
-   mvebu_pcie_set_local_dev_nr(pcie, 0);
-   pcie->dev = PCI_BDF(bus, 0, 0);
+   mvebu_pcie_set_local_dev_nr(pcie, pcie->local_dev);
 
pcie->mem.start = (u32)mvebu_pcie_membase;
pcie->mem.end = pcie->mem.start + 

[PATCH u-boot-marvell 3/5] pci: pci_mvebu: debug rd/wr config as other drivers do

2021-02-08 Thread Marek Behún
Other drivers (aardvark, intel_fpga) print "(addr,size,val)" when
debugging is enabled. Print size for pci_mvebu as well.

Signed-off-by: Marek Behún 
Cc: Stefan Roese 
Cc: Phil Sutter 
Cc: Mario Six 
Cc: Baruch Siach 
---
 drivers/pci/pci_mvebu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index abc6e9e6e0..4ad73512a6 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -174,7 +174,7 @@ static int mvebu_pcie_read_config(const struct udevice 
*bus, pci_dev_t bdf,
 
/* read data */
data = readl(pcie->base + PCIE_CONF_DATA_OFF);
-   debug("(addr,val)=(0x%04x, 0x%08x)\n", offset, data);
+   debug("(addr,size,val)=(0x%04x, %d, 0x%08x)\n", offset, size, data);
*valuep = pci_conv_32_to_size(data, offset, size);
 
return 0;
@@ -191,7 +191,7 @@ static int mvebu_pcie_write_config(struct udevice *bus, 
pci_dev_t bdf,
 
debug("PCIE CFG write: loc_bus=%d loc_dev=%d (b,d,f)=(%2d,%2d,%2d) ",
  local_bus, local_dev, PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf));
-   debug("(addr,val)=(0x%04x, 0x%08lx)\n", offset, value);
+   debug("(addr,size,val)=(0x%04x, %d, 0x%08lx)\n", offset, size, value);
 
/* Don't access the local host controller via this API */
if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) == local_dev) {
-- 
2.26.2



[PATCH u-boot-marvell 2/5] pci: pci_mvebu: cosmetic fix

2021-02-08 Thread Marek Behún
Write bdf address in a same way in mvebu_pcie_read/write_config.

Signed-off-by: Marek Behún 
Cc: Stefan Roese 
Cc: Phil Sutter 
Cc: Mario Six 
Cc: Baruch Siach 
---
 drivers/pci/pci_mvebu.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 5c55a76d0e..abc6e9e6e0 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -150,7 +150,6 @@ static int mvebu_pcie_read_config(const struct udevice 
*bus, pci_dev_t bdf,
struct mvebu_pcie *pcie = dev_get_plat(bus);
int local_bus = PCI_BUS(pcie->dev);
int local_dev = PCI_DEV(pcie->dev);
-   u32 reg;
u32 data;
 
debug("PCIE CFG read:  loc_bus=%d loc_dev=%d (b,d,f)=(%2d,%2d,%2d) ",
@@ -171,8 +170,9 @@ static int mvebu_pcie_read_config(const struct udevice 
*bus, pci_dev_t bdf,
}
 
/* write address */
-   reg = PCIE_CONF_ADDR(bdf, offset);
-   writel(reg, pcie->base + PCIE_CONF_ADDR_OFF);
+   writel(PCIE_CONF_ADDR(bdf, offset), pcie->base + PCIE_CONF_ADDR_OFF);
+
+   /* read data */
data = readl(pcie->base + PCIE_CONF_DATA_OFF);
debug("(addr,val)=(0x%04x, 0x%08x)\n", offset, data);
*valuep = pci_conv_32_to_size(data, offset, size);
@@ -205,7 +205,10 @@ static int mvebu_pcie_write_config(struct udevice *bus, 
pci_dev_t bdf,
return 0;
}
 
+   /* write address */
writel(PCIE_CONF_ADDR(bdf, offset), pcie->base + PCIE_CONF_ADDR_OFF);
+
+   /* write data */
data = pci_conv_size_to_32(0, value, offset, size);
writel(data, pcie->base + PCIE_CONF_DATA_OFF);
 
-- 
2.26.2



[PATCH u-boot-marvell 5/5] pci: pci_mvebu: set local dev to number 1

2021-02-08 Thread Marek Behún
Linux displays the real PCIe card connected to a mvebu PCIe slot as
device 0, not 1. This is done by setting local dev number to 1, so that
the local "Marvell Memory controller" device is on address 1.

Let's do it also in U-Boot.

With this commit the pci command in U-Boot prints something like:
  => pci
  Scanning PCI devices on bus 0
  BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
  _
  00.00.00   0x168c 0x003c Network controller  0x80

Signed-off-by: Marek Behún 
Cc: Stefan Roese 
Cc: Phil Sutter 
Cc: Mario Six 
Cc: Baruch Siach 
---
 drivers/pci/pci_mvebu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 2d923b7d8d..11b590617d 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -288,7 +288,7 @@ static int mvebu_pcie_probe(struct udevice *dev)
  mvebu_pcie_get_local_dev_nr(pcie));
 
pcie->first_busno = bus;
-   pcie->local_dev = 0;
+   pcie->local_dev = 1;
 
mvebu_pcie_set_local_bus_nr(pcie, bus);
mvebu_pcie_set_local_dev_nr(pcie, pcie->local_dev);
-- 
2.26.2



[PATCH u-boot-marvell 1/5] pci: pci_mvebu: use dev_seq instead of static variable

2021-02-08 Thread Marek Behún
PCI uclass maps PCI bus numbers to the seq member of struct udevice.
Use dev_seq(dev) as the bus number in mvebu_pcie_probe instead of an
incrementing a static variable.

Signed-off-by: Marek Behún 
Cc: Stefan Roese 
Cc: Phil Sutter 
Cc: Mario Six 
Cc: Baruch Siach 
---
 drivers/pci/pci_mvebu.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index 3ab03e3675..5c55a76d0e 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -272,7 +272,7 @@ static int mvebu_pcie_probe(struct udevice *dev)
struct mvebu_pcie *pcie = dev_get_plat(dev);
struct udevice *ctlr = pci_get_controller(dev);
struct pci_controller *hose = dev_get_uclass_priv(ctlr);
-   static int bus;
+   int bus = dev_seq(dev);
u32 reg;
 
debug("%s: PCIe %d.%d - up, base %08x\n", __func__,
@@ -335,8 +335,6 @@ static int mvebu_pcie_probe(struct udevice *dev)
writel(SOC_REGS_PHY_BASE, pcie->base + PCIE_BAR_LO_OFF(0));
writel(0, pcie->base + PCIE_BAR_HI_OFF(0));
 
-   bus++;
-
return 0;
 }
 
-- 
2.26.2



[PATCH u-boot-marvell 0/5] pci_mvebu changes

2021-02-08 Thread Marek Behún
Hi Stefan,

this patchset continues to address the issue you tried to solve with
commit "pci: pci_mvebu: Disable config access to PCI host bridge ports".

Some code refactoring is done here so that the code looks more sane and
the underlying information is documenter.

The last patch changes the local device (which presents itself as a
"Memory controller" to device number 1, so that the pci command in
U-Boot lists the real PCIe card as device 0, as Linux does.

Marek

Marek Behún (5):
  pci: pci_mvebu: use dev_seq instead of static variable
  pci: pci_mvebu: cosmetic fix
  pci: pci_mvebu: debug rd/wr config as other drivers do
  pci: pci_mvebu: refactor validation of addresses for config access
  pci: pci_mvebu: set local dev to number 1

 drivers/pci/pci_mvebu.c | 76 ++---
 1 file changed, 40 insertions(+), 36 deletions(-)

-- 
2.26.2



Re: [PATCH 3/5] arm: stm32mp: Implement support for TZC 400 controller

2021-02-08 Thread Alex G.

On 2/7/21 8:37 AM, Simon Glass wrote:

Hi Alexandru,

On Thu, 4 Feb 2021 at 12:56, Alexandru Gagniuc  wrote:


The purpose of this change is to allow configuring TrustZone (TZC)
memory permissions. For example, OP-TEE expects TZC regions to be
configured in a very particular way. The API presented here is
intended to allow exactly that.

UCLASS support is not implemented, because it would not be too useful.
Changing TZC permissions needs to be done with care, so as not to cut
off access to memory we are currently using. One place where we can
use this is at the end of SPL, right before jumping to OP-TEE.

Signed-off-by: Alexandru Gagniuc 
---
  arch/arm/mach-stm32mp/Makefile   |   1 +
  arch/arm/mach-stm32mp/include/mach/tzc.h |  33 ++
  arch/arm/mach-stm32mp/tzc400.c   | 135 +++
  3 files changed, 169 insertions(+)
  create mode 100644 arch/arm/mach-stm32mp/include/mach/tzc.h
  create mode 100644 arch/arm/mach-stm32mp/tzc400.c


If this is an API you should add comments to the header file structs
and functions.

Is this API specific to just this chip?


I've designed and validated this to set up stm32mp for starting up 
OP-TEE. It's a narrow use case. I can't speak for other chips.


Alex


Re: Please pull u-boot-marvell/master

2021-02-08 Thread Tom Rini
On Mon, Feb 08, 2021 at 12:41:45PM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the 2nd batch of Marvell MVEBU related patches. Here the
> summary log:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: pull request of u-boot-fsl-qoriq for v2021.04

2021-02-08 Thread Tom Rini
On Mon, Feb 08, 2021 at 11:10:09AM +, Priyanka Jain wrote:

> Dear Tom,
> 
> Please find my pull-request for u-boot-fsl-qoriq/master 
> https://github.com/u-boot/u-boot/pull/52/checks
> 
> Summary
> Layerscape: Enable gpio
> Bug fixes & updates related to dspi, qspi, pciep, SVR mask,
> stream-id, env variables, mdio for LAyerscape Platforms
> Add SATA, network variant 1, 2 support on sl28
> powerpc: T1042: drop CONFIG_VIDEO, Add kmcent2 board supporrt, keymile
> Bug fixes and updates for keymile, Kontron
> 
> Thanks
> Priyanka

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] u-boot-sh/master

2021-02-08 Thread Tom Rini
On Sun, Feb 07, 2021 at 09:41:32PM +0100, Marek Vasut wrote:

> The following changes since commit 3936fd998668846f77468d8f6a662e906920969c:
> 
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2021-02-06
> 09:45:58 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to 0099dfd5e53703ff94677ec3490134ae436fc8f1:
> 
>   ARM: rmobile: Add Beacon EmbeddedWorks RZG2H Dev Kit (2021-02-07 21:12:57
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] u-boot-usb/master

2021-02-08 Thread Tom Rini
On Sun, Feb 07, 2021 at 09:10:43PM +0100, Marek Vasut wrote:

> The following changes since commit 8308a28af821d6498186b3dd7463db9874cd2daf:
> 
>   Merge tag 'ti-v2021.04-rc2' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-ti (2021-02-05 09:39:31
> -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to adb5daf0905a190375e46d59f1244b13c3cdc640:
> 
>   fastboot: reinit partition after storing GPT or MBR (2021-02-07 19:22:55
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision

2021-02-08 Thread Marek Behun
On Mon, 8 Feb 2021 20:14:26 +
Chris Packham  wrote:

> On 9/02/21 8:15 am, Marek Behun wrote:
> > This patch is needed on some Turris Omnia boards with Samsung DDR chips,
> > otherwise DDR training fails in ~60% of cases.
> >
> > Marvell send us this patch for testing, I have updated it a little.
> >
> > Please test this on other A38x boards.
> >
> > If it doesn't break anything on other boards, we can apply it and send
> > it to mv-ddr-marvell upstream.  
> They gave us the same patch. I was hoping their SoC team would get it 
> into mv-ddr-marvell (or even their vendor USP) but obviously they're 
> still sitting on it. I know it improved matters for some of our boards 
> but it didn't totally fix them we still had yield problems when we 
> ramped up production.

There is a bug in the version they sent us:

in file ddr3_training_ip_engine.c there is a line added:
   if ((bit_bit_mask[sybphy_id] & (1 << bit_id)) == 1)

try chaning it to
   if (bit_bit_mask[sybphy_id] & (1 << bit_id))

This is fixed in the version I sent to mailing list


Re: [PATCH 2/3] cmd: SCP03: enable and provision command

2021-02-08 Thread Jorge Ramirez-Ortiz, Foundries
On 08/02/21, Simon Glass wrote:
> Hi Jorge,
> 
> On Sun, 7 Feb 2021 at 11:11, Jorge Ramirez-Ortiz, Foundries
>  wrote:
> >
> > On 07/02/21, Simon Glass wrote:
> > > Hi Jorge,
> > >
> > > On Sat, 6 Feb 2021 at 16:05, Jorge Ramirez-Ortiz  
> > > wrote:
> > > >
> > > > Enable and provision the SCP03 keys on a TEE controlled secured elemt
> > > > from the U-Boot shell.
> > > >
> > > > Signed-off-by: Jorge Ramirez-Ortiz 
> > > > ---
> > > >  cmd/Kconfig  |  9 
> > > >  cmd/Makefile |  3 +++
> > > >  cmd/scp03.c  | 64 
> > > >  3 files changed, 76 insertions(+)
> > > >  create mode 100644 cmd/scp03.c
> > >
> > > Can we have a test for this please? See mem_search.c for an example.
> >
> > you mean other than what I posted already (the sandbox test using the
> > TEE emulator)?
> >
> > I am not really sure what else can it do: this command sends a request
> > to a TEE and waits to a response (and both are emulated on the sandbox).
> 
> It should just be a few lines of code to test the basics. E.g.:
> 
> https://github.com/u-boot/u-boot/blob/3936fd998668846f77468d8f6a662e906920969c/test/cmd/test_echo.c#L42

ah ok I see what you mean.
I'll have a look

> 
> Regards,
> Simon


Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-08 Thread Marek Behun
On Mon, 8 Feb 2021 20:11:06 +
Chris Packham  wrote:

> Hi Marek,
> 
> Do you have this in a repo I can pull from? I've got a couple of boards 
> I can give this a spin on.

https://gitlab.nic.cz/turris/turris-omnia-uboot/
branch v2021.04-rc-mv-ddr-14.0.0

also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that
one contains one more commit that is needed for Omnia with Samsung DDR
chips.

Marek


Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision

2021-02-08 Thread Chris Packham
On 9/02/21 8:15 am, Marek Behun wrote:
> This patch is needed on some Turris Omnia boards with Samsung DDR chips,
> otherwise DDR training fails in ~60% of cases.
>
> Marvell send us this patch for testing, I have updated it a little.
>
> Please test this on other A38x boards.
>
> If it doesn't break anything on other boards, we can apply it and send
> it to mv-ddr-marvell upstream.
They gave us the same patch. I was hoping their SoC team would get it 
into mv-ddr-marvell (or even their vendor USP) but obviously they're 
still sitting on it. I know it improved matters for some of our boards 
but it didn't totally fix them we still had yield problems when we 
ramped up production.


Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-08 Thread Chris Packham
Hi Marek,

On 9/02/21 7:34 am, Marek Behún wrote:
> This syncs drivers/ddr/marvell/a38x/ with the mv-ddr-devel branch
> of https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git.
>
> There are some commits regarding DDR3 on top of version 14.0.0 in the
> mv-ddr-marvell repository (from Chris Packham), but these changes
> already are in U-Boot.
Do you have this in a repo I can pull from? I've got a couple of boards 
I can give this a spin on.
> Marek
>
> Marek Behún (18):
>ddr: marvell: a38x: fix write leveling suplementary algo
>ddr: marvell: a38x: import header change from upstream
>ddr: marvell: a38x: add ddr32 support
>ddr: marvell: a38x: add ddr 32bit ECC support
>ddr: marvell: a38x: import header change from upstream
>ddr: marvell: a38x: fix 32bit
>ddr: marvell: a38x: fix memory size calculation using 32bit bus width
>ddr: marvell: a38x: import header change from upstream
>ddr: marvell: a38x: allow board specific ODT configuration
>ddr: marvell: a38x: add 16Gbit memory devices support
>ddr: marvell: a38x: add support for twin-die combined memory device
>ddr: marvell: a38x: disable WL phase correction stage in case of
>  bus_width=16bit
>ddr: marvell: a38x: import header change from upstream
>ddr: marvell: a38x: fix memory cs size function
>ddr: marvell: a38x: import code change from upstream
>ddr: marvell: a38x: enum mv_ddr_twin_die: change order
>ddr: marvell: a38x: bump version to 14.0.0
>ddr: marvell: a38x: fix comment in conditional macro
>
>   board/CZ.NIC/turris_omnia/turris_omnia.c  |  2 ++
>   board/Marvell/db-88f6820-amc/db-88f6820-amc.c |  1 +
>   board/Marvell/db-88f6820-gp/db-88f6820-gp.c   |  1 +
>   board/alliedtelesis/x530/x530.c   |  1 +
>   board/gdsys/a38x/controlcenterdc.c|  1 +
>   board/kobol/helios4/helios4.c |  1 +
>   board/solidrun/clearfog/clearfog.c|  1 +
>   drivers/ddr/marvell/a38x/ddr3_init.c  |  5 
>   drivers/ddr/marvell/a38x/ddr3_training.c  |  5 +++-
>   drivers/ddr/marvell/a38x/ddr3_training_db.c   |  3 +++
>   .../ddr/marvell/a38x/ddr3_training_ip_def.h   |  2 ++
>   .../marvell/a38x/ddr3_training_ip_engine.c|  5 +++-
>   drivers/ddr/marvell/a38x/ddr_topology_def.h   | 23 ++-
>   .../ddr/marvell/a38x/mv_ddr_build_message.c   |  2 +-
>   drivers/ddr/marvell/a38x/mv_ddr_plat.c|  9 ++--
>   drivers/ddr/marvell/a38x/mv_ddr_topology.c| 14 ---
>   drivers/ddr/marvell/a38x/mv_ddr_topology.h|  2 ++
>   drivers/ddr/marvell/a38x/xor.c|  6 ++---
>   18 files changed, 72 insertions(+), 12 deletions(-)
>

Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision

2021-02-08 Thread Marek Behun
This patch is needed on some Turris Omnia boards with Samsung DDR chips,
otherwise DDR training fails in ~60% of cases.

Marvell send us this patch for testing, I have updated it a little.

Please test this on other A38x boards.

If it doesn't break anything on other boards, we can apply it and send
it to mv-ddr-marvell upstream.

Marek


[PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision

2021-02-08 Thread Marek Behún
From: motib 

In each pattern cycle the bus state can be changed.
In order to avoid it, we need to switch back to the same bus state on
each pattern cycle.

Signed-off-by: motib 

Fixed code style, removed commented code, switched to use DEBUG macros
instead of printf.

Signed-off-by: Marek Behún 
---
 .../a38x/ddr3_training_centralization.c   | 25 +++
 .../marvell/a38x/ddr3_training_ip_engine.c|  8 --
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c 
b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
index 648b37ef6f..a92760681e 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
@@ -24,6 +24,8 @@ u8 
bus_start_window[NUM_OF_CENTRAL_TYPES][MAX_INTERFACE_NUM][MAX_BUS_NUM];
 u8 centralization_state[MAX_INTERFACE_NUM][MAX_BUS_NUM];
 static u8 ddr3_tip_special_rx_run_once_flag;
 
+extern u8 byte_status[MAX_INTERFACE_NUM][MAX_BUS_NUM];
+
 static int ddr3_tip_centralization(u32 dev_num, u32 mode);
 
 /*
@@ -110,6 +112,7 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode)
(max_win_size - 1) + cons_tap;
bus_start_window[mode][if_id][bus_id] = 0;
centralization_result[if_id][bus_id] = 0;
+   byte_status[if_id][bus_id] = BYTE_NOT_DEFINED;
}
}
 
@@ -166,6 +169,12 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode)
  result[search_dir_id][7]));
}
 
+   DEBUG_CENTRALIZATION_ENGINE
+   (DEBUG_LEVEL_TRACE,
+("byte_status[%d][%d] = 0x%x\n",
+if_id,
+bus_id,
+byte_status[if_id][bus_id]));
for (bit_id = 0; bit_id < BUS_WIDTH_IN_BITS;
 bit_id++) {
/* check if this code is valid for 2 
edge, probably not :( */
@@ -174,11 +183,27 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode)
   [HWS_LOW2HIGH]
   [bit_id],
   EDGE_1);
+   if ((byte_status[if_id][bus_id] & 
BYTE_SPLIT_OUT_MIX) ||
+   (byte_status[if_id][bus_id] & 
BYTE_HOMOGENEOUS_SPLIT_OUT)) {
+   if (cur_start_win[bit_id] >= 64)
+   cur_start_win[bit_id] 
-= 64;
+   else
+   cur_start_win[bit_id] = 
0;
+   DEBUG_CENTRALIZATION_ENGINE
+   (DEBUG_LEVEL_TRACE,
+
("--\n"));
+   }
cur_end_win[bit_id] =
GET_TAP_RESULT(result
   [HWS_HIGH2LOW]
   [bit_id],
   EDGE_1);
+   if (cur_end_win[bit_id] >= 64 && 
(byte_status[if_id][bus_id] & BYTE_SPLIT_OUT_MIX)) {
+   cur_end_win[bit_id] -= 64;
+   DEBUG_CENTRALIZATION_ENGINE
+   (DEBUG_LEVEL_TRACE,
+
("++\n"));
+   }
/* window length */
current_window[bit_id] =
cur_end_win[bit_id] -
diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c 
b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
index 5fd9a052fa..3d1fa1e74e 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
@@ -1174,7 +1174,6 @@ int ddr3_tip_ip_training_wrapper(u32 dev_num, enum 
hws_access_type access_type,
 
/* zero the data base */
bit_bit_mask[sybphy_id] = 0;
-   byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED;
for (bit_id = 0; bit_id < 

Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0

2021-02-08 Thread Marek Behun
btw tested on Turris Omnia


[PATCH u-boot-marvell 16/18] ddr: marvell: a38x: enum mv_ddr_twin_die: change order

2021-02-08 Thread Marek Behún
commit 56db5d1464b44df10a02b99e615ebd6f6a35c428 upstream.

@pali suggested this change
In commit 6285efb ("mv_ddr: add support for twin-die combined memory
device") was added support for twin-die combined memory device and
default value for explicitly uninitialized structure members is zero, s
also twin_die_combined is initialized to zero. Which means COMBINED
value.
As prior this commit there was no support for twin-die combined memory
device, default value for twin_die_combined should be NOT_COMBINED. This
change change order of enum mv_ddr_twin_die to ensure that NOT_COMBINED
has value zero.

Signed-off-by: heaterC 
Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/ddr_topology_def.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h 
b/drivers/ddr/marvell/a38x/ddr_topology_def.h
index 2cca5676a0..7f2317edfa 100644
--- a/drivers/ddr/marvell/a38x/ddr_topology_def.h
+++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h
@@ -15,8 +15,8 @@
 #define MV_DDR_MAX_IFACE_NUM   1
 
 enum mv_ddr_twin_die {
-   COMBINED,
NOT_COMBINED,
+   COMBINED,
 };
 
 struct bus_params {
-- 
2.26.2



[PATCH u-boot-marvell 17/18] ddr: marvell: a38x: bump version to 14.0.0

2021-02-08 Thread Marek Behún
Bump version of a38x DDR3 trianing to version 14.0.0 to reflect the
version in the mv-ddr-devel branch of upstream repository
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git.

There is a new version numbering system, where after 18.12.0 came
1.0.0, 2.0.0, and so on until 14.0.0. So 14.0.0 is newer than 18.12.0.

Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/mv_ddr_build_message.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/mv_ddr_build_message.c 
b/drivers/ddr/marvell/a38x/mv_ddr_build_message.c
index cc6234fd40..a2bb8a96a6 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_build_message.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_build_message.c
@@ -1,3 +1,3 @@
 // SPDX-License-Identifier: GPL-2.0
 const char mv_ddr_build_message[] = "";
-const char mv_ddr_version_string[] = "mv_ddr: mv_ddr-armada-18.09.2";
+const char mv_ddr_version_string[] = "mv_ddr: 14.0.0";
-- 
2.26.2



[PATCH u-boot-marvell 18/18] ddr: marvell: a38x: fix comment in conditional macro

2021-02-08 Thread Marek Behún
The code was processed with unifdef utility to omit portions not
relevant to A38x and DDR3. This removes usage of many macros, including
A70X0, A80X0 and A3900. It seems that the unifdef utility did not remove
the macros from #else comment.

Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/ddr3_training.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training.c 
b/drivers/ddr/marvell/a38x/ddr3_training.c
index 0358f6287a..2b3af23202 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training.c
@@ -219,7 +219,7 @@ static int ddr3_tip_pad_inv(void)
   DDR_PHY_CONTROL,
   PHY_CTRL_PHY_REG,
   data, data);
-#else /* !CONFIG_ARMADA_38X && !CONFIG_ARMADA_39X && !A70X0 && !A80X0 && 
!A3900 */
+#else /* !CONFIG_ARMADA_38X && !CONFIG_ARMADA_39X */
 #pragma message "unknown platform to configure ddr clock swap"
 #endif
}
-- 
2.26.2



[PATCH u-boot-marvell 15/18] ddr: marvell: a38x: import code change from upstream

2021-02-08 Thread Marek Behún
commit 2bdd12dd68b1f8e27a03a3443ae49a09a14c18e4 upstream.

The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes code in ddr3_training.c.

Import this change to remain consistent with upstream.

Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/ddr3_training.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training.c 
b/drivers/ddr/marvell/a38x/ddr3_training.c
index 34cc170910..0358f6287a 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training.c
@@ -143,6 +143,7 @@ static struct reg_data odpg_default_value[] = {
{0x15a4, 0x0, MASK_ALL_BITS},
{0x15a8, 0x0, MASK_ALL_BITS},
{0x15ac, 0x0, MASK_ALL_BITS},
+   {0x1600, 0x0, MASK_ALL_BITS},
{0x1604, 0x0, MASK_ALL_BITS},
{0x1608, 0x0, MASK_ALL_BITS},
{0x160c, 0x0, MASK_ALL_BITS},
@@ -1569,6 +1570,8 @@ int ddr3_tip_freq_set(u32 dev_num, enum hws_access_type 
access_type,
val = ((cl_mask_table[cl_value] & 0x1) << 2) |
((cl_mask_table[cl_value] & 0xe) << 3);
 
+   cs_mask[0] = 0xc;
+
CHECK_STATUS(ddr3_tip_write_mrs_cmd(dev_num, cs_mask, MR_CMD0,
val, (0x7 << 4) | (0x1 << 2)));
 
-- 
2.26.2



[PATCH u-boot-marvell 14/18] ddr: marvell: a38x: fix memory cs size function

2021-02-08 Thread Marek Behún
commit c8b301463d508c807a33f7b7eaea98bbda4aa35e upstream.

The funtion returnd cs size in byte instead of MB, that cause
calculation error since the caller was expected to get u32 and when he
got above 4G it refers it as 0.
The fix was to get the cs memory size from function as in MB and then
multiply it by 1MB.

Signed-off-by: Moti Buskila 
Reviewed-by: Kostya Porotchkin 
Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/mv_ddr_plat.c | 9 +++--
 drivers/ddr/marvell/a38x/xor.c | 6 +++---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c 
b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
index 72f0df..0d1df189e8 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
@@ -4,6 +4,7 @@
  */
 
 #include "ddr3_init.h"
+#include "mv_ddr_common.h"
 #include "mv_ddr_training_db.h"
 #include "mv_ddr_regs.h"
 #include "mv_ddr_sys_env_lib.h"
@@ -1016,7 +1017,7 @@ int ddr3_calc_mem_cs_size(u32 cs, uint64_t *cs_size)
return MV_BAD_VALUE;
}
 
-   *cs_size = cs_mem_size << 20; /* write cs size in bytes */
+   *cs_size = cs_mem_size;
 
return MV_OK;
 }
@@ -1025,9 +1026,11 @@ static int ddr3_fast_path_dynamic_cs_size_config(u32 
cs_ena)
 {
u32 reg, cs;
uint64_t mem_total_size = 0;
+   uint64_t cs_mem_size_mb = 0;
uint64_t cs_mem_size = 0;
uint64_t mem_total_size_c, cs_mem_size_c;
 
+
 #ifdef DEVICE_MAX_DRAM_ADDRESS_SIZE
u32 physical_mem_size;
u32 max_mem_size = DEVICE_MAX_DRAM_ADDRESS_SIZE;
@@ -1038,8 +1041,9 @@ static int ddr3_fast_path_dynamic_cs_size_config(u32 
cs_ena)
for (cs = 0; cs < MAX_CS_NUM; cs++) {
if (cs_ena & (1 << cs)) {
/* get CS size */
-   if (ddr3_calc_mem_cs_size(cs, _mem_size) != MV_OK)
+   if (ddr3_calc_mem_cs_size(cs, _mem_size_mb) != MV_OK)
return MV_FAIL;
+   cs_mem_size = cs_mem_size_mb * _1M;
 
 #ifdef DEVICE_MAX_DRAM_ADDRESS_SIZE
/*
@@ -1088,6 +1092,7 @@ static int ddr3_fast_path_dynamic_cs_size_config(u32 
cs_ena)
 */
mem_total_size_c = (mem_total_size >> 16) & 
0x;
cs_mem_size_c = (cs_mem_size >> 16) & 0x;
+
/* if the sum less than 2 G - calculate the value */
if (mem_total_size_c + cs_mem_size_c < 0x1)
mem_total_size += cs_mem_size;
diff --git a/drivers/ddr/marvell/a38x/xor.c b/drivers/ddr/marvell/a38x/xor.c
index 5fb9e216d3..98fb39eaf0 100644
--- a/drivers/ddr/marvell/a38x/xor.c
+++ b/drivers/ddr/marvell/a38x/xor.c
@@ -340,7 +340,7 @@ void ddr3_new_tip_ecc_scrub(void)
 {
u32 cs_c, max_cs;
u32 cs_ena = 0;
-   uint64_t total_mem_size, cs_mem_size = 0;
+   uint64_t total_mem_size, cs_mem_size_mb = 0, cs_mem_size = 0;
 
printf("DDR Training Sequence - Start scrubbing\n");
max_cs = mv_ddr_cs_num_get();
@@ -349,9 +349,9 @@ void ddr3_new_tip_ecc_scrub(void)
 
 #if defined(CONFIG_ARMADA_38X) || defined(CONFIG_ARMADA_39X)
/* all chip-selects are of same size */
-   ddr3_calc_mem_cs_size(0, _mem_size);
+   ddr3_calc_mem_cs_size(0, _mem_size_mb);
 #endif
-
+   cs_mem_size = cs_mem_size_mb * _1M;
mv_sys_xor_init(max_cs, cs_ena, cs_mem_size, 0);
total_mem_size = max_cs * cs_mem_size;
mv_xor_mem_init(0, 0, total_mem_size, 0xdeadbeef, 0xdeadbeef);
-- 
2.26.2



[PATCH u-boot-marvell 11/18] ddr: marvell: a38x: add support for twin-die combined memory device

2021-02-08 Thread Marek Behún
commit 6285efb8a118940877522c4c07bd7c64569b4f5f upstream.

the twin-die combined memory device should be treatened as X8
device and not as X16 one

Signed-off-by: Moti Buskila 
Reviewed-by: Kostya Porotchkin 

The default value for twin_die_combined is set to NOT_COMBINED for all
boards, as this was default behaviour prior this change.

Signed-off-by: Marek Behún 
---
 board/CZ.NIC/turris_omnia/turris_omnia.c  |  2 ++
 board/Marvell/db-88f6820-amc/db-88f6820-amc.c |  1 +
 board/Marvell/db-88f6820-gp/db-88f6820-gp.c   |  1 +
 board/alliedtelesis/x530/x530.c   |  1 +
 board/gdsys/a38x/controlcenterdc.c|  1 +
 board/kobol/helios4/helios4.c |  1 +
 board/solidrun/clearfog/clearfog.c|  1 +
 drivers/ddr/marvell/a38x/ddr_topology_def.h   | 12 
 drivers/ddr/marvell/a38x/mv_ddr_topology.c|  6 +-
 9 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 2da878d364..78b125edfe 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -285,6 +285,7 @@ static struct mv_ddr_topology_map board_topology_map_1g = {
MV_DDR_TIM_2T} },   /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+   NOT_COMBINED,   /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
 };
@@ -307,6 +308,7 @@ static struct mv_ddr_topology_map board_topology_map_2g = {
MV_DDR_TIM_2T} },   /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+   NOT_COMBINED,   /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
 };
diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c 
b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
index 9cd9ea2c06..acc8a5ec6d 100644
--- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
+++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
@@ -72,6 +72,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_DEFAULT} },  /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+   NOT_COMBINED,   /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
 };
diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c 
b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
index 2bdd55329d..a1d0104526 100644
--- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
+++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
@@ -93,6 +93,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_DEFAULT} },  /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+   NOT_COMBINED,   /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
 };
diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
index c7438aeaf1..6caba24196 100644
--- a/board/alliedtelesis/x530/x530.c
+++ b/board/alliedtelesis/x530/x530.c
@@ -67,6 +67,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_2T} },   /* timing */
BUS_MASK_32BIT_ECC, /* subphys mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+   NOT_COMBINED,   /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0},/* timing parameters */
{ {0} },/* electrical configuration */
diff --git a/board/gdsys/a38x/controlcenterdc.c 
b/board/gdsys/a38x/controlcenterdc.c
index a2287f9deb..66a0d769ce 100644
--- a/board/gdsys/a38x/controlcenterdc.c
+++ b/board/gdsys/a38x/controlcenterdc.c
@@ -70,6 +70,7 @@ static struct mv_ddr_topology_map ddr_topology_map = {
MV_DDR_TIM_DEFAULT} },  /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+   NOT_COMBINED,   /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
 
diff --git a/board/kobol/helios4/helios4.c b/board/kobol/helios4/helios4.c
index 17d2489415..5007194a52 100644
--- a/board/kobol/helios4/helios4.c

[PATCH u-boot-marvell 12/18] ddr: marvell: a38x: disable WL phase correction stage in case of bus_width=16bit

2021-02-08 Thread Marek Behún
commit 20c89a28548cdab11f88d2ec8936344af0686a1e upstream.

WL phase correcion stage is failing while using bus_width of 16bit, not
to be fix this stage is un-necessary when working with bus_width of 16
bit.

Signed-off-by: Moti Buskila 
Reviewed-by: Kostya Porotchkin 
Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/ddr3_training_db.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training_db.c 
b/drivers/ddr/marvell/a38x/ddr3_training_db.c
index b2f11a8399..6aa7b6069e 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_db.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_db.c
@@ -833,6 +833,9 @@ u32 pattern_table_get_word(u32 dev_num, enum hws_pattern 
type, u8 index)
pattern = pattern_table_get_isi_word16(index);
break;
default:
+   if (((int)type == 29) || ((int)type == 30))
+   break;
+
printf("error: %s: unsupported pattern type [%d] 
found\n",
   __func__, (int)type);
pattern = 0;
-- 
2.26.2



[PATCH u-boot-marvell 13/18] ddr: marvell: a38x: import header change from upstream

2021-02-08 Thread Marek Behún
commit d653b305d0b3da9727c49124683f1a6d95d5c9a5 upstream.

The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes header ddr_topology_def.h.

Import this header change to remain consistent with upstream.

Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/ddr_topology_def.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h 
b/drivers/ddr/marvell/a38x/ddr_topology_def.h
index 461f091472..2cca5676a0 100644
--- a/drivers/ddr/marvell/a38x/ddr_topology_def.h
+++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h
@@ -52,9 +52,6 @@ struct if_params {
/* The DDR frequency for each interfaces */
enum mv_ddr_freq memory_freq;
 
-/* ddr twin-die */
-   enum mv_ddr_twin_die twin_die_combined;
-
/*
 * delay CAS Write Latency
 * - 0 for using default value (jedec suggested)
-- 
2.26.2



[PATCH u-boot-marvell 10/18] ddr: marvell: a38x: add 16Gbit memory devices support

2021-02-08 Thread Marek Behún
commit 994509eb4fe6771d92cd06314c37895098ac48fa upstream.

Signed-off-by: Moti Buskila 
Reviewed-by: Kostya Porotchkin 
Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/ddr3_training_ip_def.h | 2 ++
 drivers/ddr/marvell/a38x/mv_ddr_topology.c  | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h 
b/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h
index 2a68669f36..8765df7cfb 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h
+++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h
@@ -80,6 +80,8 @@
 #define ADDR_SIZE_2GB  0x1000
 #define ADDR_SIZE_4GB  0x2000
 #define ADDR_SIZE_8GB  0x4000
+#define ADDR_SIZE_16GB 0x8000
+
 
 enum hws_edge_compare {
EDGE_PF,
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c 
b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
index 31711fdd49..c4c3ab72b2 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
@@ -248,7 +248,8 @@ static unsigned int mem_size[] = {
ADDR_SIZE_1GB,
ADDR_SIZE_2GB,
ADDR_SIZE_4GB,
-   ADDR_SIZE_8GB
+   ADDR_SIZE_8GB,
+   ADDR_SIZE_16GB
/* TODO: add capacity up to 256GB */
 };
 
-- 
2.26.2



[PATCH u-boot-marvell 07/18] ddr: marvell: a38x: fix memory size calculation using 32bit bus width

2021-02-08 Thread Marek Behún
commit ab9240402a70cc02496683971779e75eff410ab4 upstream.

- function mv_ddr_spd_die_capacity_user_get() has a bug,
  since it insert a user memory enum to it,
  instead of SPD memory enum (which are different)
- fix: remove mv_ddr_spd_die_capacity_user_get() function.
- memory size with 64 and 32 bit already calculated correctly
  at mv_ddr_mem_sz_per_cs_get() function

Signed-off-by: motib 
Reviewed-by: Stefan Chulski 
Reviewed-by: Alex Leibovich 
Reviewed-by: Kostya Porotchkin 
Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/mv_ddr_spd.c  | 5 -
 drivers/ddr/marvell/a38x/mv_ddr_spd.h  | 1 -
 drivers/ddr/marvell/a38x/mv_ddr_topology.c | 4 
 3 files changed, 10 deletions(-)

diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.c 
b/drivers/ddr/marvell/a38x/mv_ddr_spd.c
index cb90d30a6a..04dbfe94d6 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_spd.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.c
@@ -217,11 +217,6 @@ enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union 
mv_ddr_spd_data *spd_
return ret_val;
 }
 
-void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum 
mv_ddr_die_capacity capacity)
-{
-   spd_data->byte_fields.byte_4.bit_fields.die_capacity = capacity;
-}
-
 unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data)
 {
unsigned char mem_mirror = 
spd_data->byte_fields.byte_131.bit_fields.rank_1_mapping;
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.h 
b/drivers/ddr/marvell/a38x/mv_ddr_spd.h
index ee35377af5..b4bfef3103 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_spd.h
+++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.h
@@ -277,7 +277,6 @@ union mv_ddr_spd_data {
 int mv_ddr_spd_timing_calc(union mv_ddr_spd_data *spd_data, unsigned int 
timing_data[]);
 enum mv_ddr_dev_width mv_ddr_spd_dev_width_get(union mv_ddr_spd_data 
*spd_data);
 enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union mv_ddr_spd_data 
*spd_data);
-void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum 
mv_ddr_die_capacity capacity);
 unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data);
 unsigned char mv_ddr_spd_cs_bit_mask_get(union mv_ddr_spd_data *spd_data);
 unsigned char mv_ddr_spd_dev_type_get(union mv_ddr_spd_data *spd_data);
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c 
b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
index 3feb65ea46..31711fdd49 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
@@ -74,10 +74,6 @@ int mv_ddr_topology_map_update(void)
/* update device width in topology map */
iface_params->bus_width = 
mv_ddr_spd_dev_width_get(>spd_data);
 
-   /* overwrite SPD configuration, with what the user set */
-   if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK)
-   mv_ddr_spd_die_capacity_user_get(>spd_data, 
tm->interface_params[0].memory_size);
-
/* update die capacity in topology map */
iface_params->memory_size = 
mv_ddr_spd_die_capacity_get(>spd_data);
 
-- 
2.26.2



[PATCH u-boot-marvell 08/18] ddr: marvell: a38x: import header change from upstream

2021-02-08 Thread Marek Behún
commit 3908e20c6c520339e9bddb566823ae5e065d5218 upstream.

The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes header ddr_topology_def.h.

Import this header change to remain consistent with upstream.

Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/ddr_topology_def.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h 
b/drivers/ddr/marvell/a38x/ddr_topology_def.h
index c55e3b57e4..342c2cf451 100644
--- a/drivers/ddr/marvell/a38x/ddr_topology_def.h
+++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h
@@ -152,6 +152,11 @@ enum mv_ddr_validation {
MV_DDR_MEMORY_CHECK
 };
 
+enum mv_ddr_sscg {
+   SSCG_EN,
+   SSCG_DIS,
+};
+
 struct mv_ddr_iface {
/* base addr of ap ddr interface belongs to */
unsigned int ap_base;
@@ -180,6 +185,9 @@ struct mv_ddr_iface {
/* ddr interface validation mode */
enum mv_ddr_validation validation;
 
+   /* ddr interface validation mode */
+   enum mv_ddr_sscg sscg;
+
/* ddr interface topology map */
struct mv_ddr_topology_map tm;
 };
-- 
2.26.2



[PATCH u-boot-marvell 09/18] ddr: marvell: a38x: allow board specific ODT configuration

2021-02-08 Thread Marek Behún
commit 2d3b9437cf38c06c4330e0de07f29476197f5e04 upstream.

The ODT enable heuristic based on active chip-selects is not always
correct. Some board might use two chip-selects, but have only one ODT
line connected. Allow board specific mv_ddr_topology_map to directly set
the ODT configuration register value.

Signed-off-by: Baruch Siach 
Reviewed-by: Moti Buskila 
Reviewed-by: Nadav Haklai 
Reviewed-by: Kostya Porotchkin 
Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/ddr3_init.c| 5 +
 drivers/ddr/marvell/a38x/ddr_topology_def.h | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/drivers/ddr/marvell/a38x/ddr3_init.c 
b/drivers/ddr/marvell/a38x/ddr3_init.c
index a971cc155a..7488770268 100644
--- a/drivers/ddr/marvell/a38x/ddr3_init.c
+++ b/drivers/ddr/marvell/a38x/ddr3_init.c
@@ -104,6 +104,7 @@ int ddr3_init(void)
 static int mv_ddr_training_params_set(u8 dev_num)
 {
struct tune_train_params params;
+   struct mv_ddr_topology_map *tm = mv_ddr_topology_map_get();
int status;
u32 cs_num;
int ck_delay;
@@ -136,6 +137,10 @@ static int mv_ddr_training_params_set(u8 dev_num)
if (ck_delay > 0)
params.ck_delay = ck_delay;
 
+   /* Use platform specific override ODT value */
+   if (tm->odt_config)
+   params.g_odt_config = tm->odt_config;
+
status = ddr3_tip_tune_training_params(dev_num, );
if (MV_OK != status) {
printf("%s Training Sequence - FAILED\n", ddr_type);
diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h 
b/drivers/ddr/marvell/a38x/ddr_topology_def.h
index 342c2cf451..3991fec272 100644
--- a/drivers/ddr/marvell/a38x/ddr_topology_def.h
+++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h
@@ -125,6 +125,9 @@ struct mv_ddr_topology_map {
/* electrical parameters */
unsigned int electrical_data[MV_DDR_EDATA_LAST];
 
+   /* ODT configuration */
+   u32 odt_config;
+
/* Clock enable mask */
u32 clk_enable;
 
-- 
2.26.2



[PATCH u-boot-marvell 06/18] ddr: marvell: a38x: fix 32bit

2021-02-08 Thread Marek Behún
commit 0b5adedd4ced9b8f528faad1957d4d69e95759ef upstream.

Signed-off-by: motib 
Reviewed-by: Alex Leibovich 
Reviewed-by: Kostya Porotchkin 
Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/mv_ddr_topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c 
b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
index 0cbe8d3d1e..3feb65ea46 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
@@ -149,7 +149,7 @@ unsigned short mv_ddr_bus_bit_mask_get(void)
 
if (tm->cfg_src == MV_DDR_CFG_SPD) {
if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK)
-   tm->spd_data.byte_fields.byte_13.all_bits = 
MV_DDR_PRI_BUS_WIDTH_32;
+   
tm->spd_data.byte_fields.byte_13.bit_fields.primary_bus_width = 
MV_DDR_PRI_BUS_WIDTH_32;
 
enum mv_ddr_pri_bus_width pri_bus_width = 
mv_ddr_spd_pri_bus_width_get(>spd_data);
enum mv_ddr_bus_width_ext bus_width_ext = 
mv_ddr_spd_bus_width_ext_get(>spd_data);
-- 
2.26.2



[PATCH u-boot-marvell 04/18] ddr: marvell: a38x: add ddr 32bit ECC support

2021-02-08 Thread Marek Behún
commit 61a8910998d7b553e80f600ebe8147a8b98f0945 upstream.

Required changes made for 32bit ddr support.
An update is made to the topology map, according to
bus_act_mask, set in the dram_port.c

Signed-off-by: Alex Leibovich 
Reviewed-by: Kostya Porotchkin 
Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/mv_ddr_spd.c  | 5 +
 drivers/ddr/marvell/a38x/mv_ddr_spd.h  | 1 +
 drivers/ddr/marvell/a38x/mv_ddr_topology.c | 6 +-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.c 
b/drivers/ddr/marvell/a38x/mv_ddr_spd.c
index 04dbfe94d6..cb90d30a6a 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_spd.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.c
@@ -217,6 +217,11 @@ enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union 
mv_ddr_spd_data *spd_
return ret_val;
 }
 
+void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum 
mv_ddr_die_capacity capacity)
+{
+   spd_data->byte_fields.byte_4.bit_fields.die_capacity = capacity;
+}
+
 unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data)
 {
unsigned char mem_mirror = 
spd_data->byte_fields.byte_131.bit_fields.rank_1_mapping;
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.h 
b/drivers/ddr/marvell/a38x/mv_ddr_spd.h
index b4bfef3103..ee35377af5 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_spd.h
+++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.h
@@ -277,6 +277,7 @@ union mv_ddr_spd_data {
 int mv_ddr_spd_timing_calc(union mv_ddr_spd_data *spd_data, unsigned int 
timing_data[]);
 enum mv_ddr_dev_width mv_ddr_spd_dev_width_get(union mv_ddr_spd_data 
*spd_data);
 enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union mv_ddr_spd_data 
*spd_data);
+void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum 
mv_ddr_die_capacity capacity);
 unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data);
 unsigned char mv_ddr_spd_cs_bit_mask_get(union mv_ddr_spd_data *spd_data);
 unsigned char mv_ddr_spd_dev_type_get(union mv_ddr_spd_data *spd_data);
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c 
b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
index f2cd7c0ef3..0cbe8d3d1e 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
@@ -74,6 +74,10 @@ int mv_ddr_topology_map_update(void)
/* update device width in topology map */
iface_params->bus_width = 
mv_ddr_spd_dev_width_get(>spd_data);
 
+   /* overwrite SPD configuration, with what the user set */
+   if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK)
+   mv_ddr_spd_die_capacity_user_get(>spd_data, 
tm->interface_params[0].memory_size);
+
/* update die capacity in topology map */
iface_params->memory_size = 
mv_ddr_spd_die_capacity_get(>spd_data);
 
@@ -144,7 +148,7 @@ unsigned short mv_ddr_bus_bit_mask_get(void)
unsigned int octets_per_if_num = ddr3_tip_dev_attr_get(0, 
MV_ATTR_OCTET_PER_INTERFACE);
 
if (tm->cfg_src == MV_DDR_CFG_SPD) {
-   if (tm->bus_act_mask == BUS_MASK_32BIT)
+   if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK)
tm->spd_data.byte_fields.byte_13.all_bits = 
MV_DDR_PRI_BUS_WIDTH_32;
 
enum mv_ddr_pri_bus_width pri_bus_width = 
mv_ddr_spd_pri_bus_width_get(>spd_data);
-- 
2.26.2



[PATCH u-boot-marvell 05/18] ddr: marvell: a38x: import header change from upstream

2021-02-08 Thread Marek Behún
commit 6c705ebc0d70f67ed7cae83ad1978c3305ef25be upstream.

The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes header mv_ddr_topology.h.

Import this header change to remain consistent with upstream.

Signed-off-by: Marek Behún 
---
 drivers/ddr/marvell/a38x/mv_ddr_topology.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.h 
b/drivers/ddr/marvell/a38x/mv_ddr_topology.h
index 4fca47689f..1cb69ad085 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.h
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.h
@@ -179,7 +179,9 @@ enum mv_ddr_dic_evalue {
 
 /* phy electrical configuration values */
 enum mv_ddr_ohm_evalue {
+   MV_DDR_OHM_20 = 20,/*relevant for Synopsys C/A Drive strength only*/
MV_DDR_OHM_30 = 30,
+   MV_DDR_OHM_40 = 40,/*relevant for Synopsys C/A Drive strength only*/
MV_DDR_OHM_48 = 48,
MV_DDR_OHM_60 = 60,
MV_DDR_OHM_80 = 80,
-- 
2.26.2



  1   2   >