Re: [GIT PULL] TI changes for v2020.07-rc2

[Vignesh Raghavendra]

On 11/05/20 11:53 pm, Tom Rini wrote:
> On Mon, May 11, 2020 at 06:12:59PM +0530, Lokesh Vutla wrote:
> 
>> Hi Tom,
>>  Please find the pull request for v2020.07-rc2 containing TI specific 
>> changes.
>>
>> Travis-CI build: 
>> https://travis-ci.org/github/lokeshvutla/u-boot/builds/685502396
>>
>> Thanks and regards,
>> Lokesh
>>
>> The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d:
>>
>>   Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400)
>>
>> are available in the Git repository at:
>>
>>   https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.07-rc2
>>
>> for you to fetch changes up to 42e05704d8c0e84e8d0eb0bb52253adaa7c9eb86:
>>
>>   Nokia RX-51: Update README.nokia_rx51 (2020-05-11 10:16:49 +0530)
>>
> 
> Applied to u-boot/master, thanks!
> 
> Please note that both before and after this change, I don't have
> ethernet working on the am65x_evm_a53 here.
> 

Works for me with latest tip and v2019.12b sysfw:

https://pastebin.ubuntu.com/p/QPKMHpdXCQ/

What version of SYSFW was used? Could you please share the full log and
what exactly fails with etherent? Does basic ping work?

Regards
Vignesh

RE: [PATCH] configs: ls1046a: Define ENV_ADDR value

[Priyanka Jain (OSS)]

>-Original Message-
>From: U-Boot  On Behalf Of Kuldeep Singh
>Sent: Tuesday, February 11, 2020 3:09 PM
>To: u-boot@lists.denx.de
>Subject: [PATCH] configs: ls1046a: Define ENV_ADDR value
>
>CONFIG_ENV_ADDR helps in picking environment from flash before DDR init.
>Define value 0x4030 in QSPI defconfig for LS1046ARDB as value is already
>defined in TFA.
Do you mean the value same as already defined?
If yes, can you please reword the description

Also why we need to defined in both TFA and u-boot ? Are both trying to read 
env?
>
>Correct ENV_ADDR and ENV_SECT_SIZE value for LS1046AQDS as per
>defconfig.
Do you mean in defconfigs? If yes, please reword?
>
>Signed-off-by: Kuldeep Singh 
>---
> configs/ls1046aqds_qspi_defconfig | 3 ++-  configs/ls1046aqds_tfa_defconfig
>| 4 ++--  configs/ls1046ardb_qspi_defconfig | 1 +
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/configs/ls1046aqds_qspi_defconfig
>b/configs/ls1046aqds_qspi_defconfig
>index 22904a0..1f28ad5 100644
>--- a/configs/ls1046aqds_qspi_defconfig
>+++ b/configs/ls1046aqds_qspi_defconfig
>@@ -2,7 +2,7 @@ CONFIG_ARM=y
> CONFIG_TARGET_LS1046AQDS=y
> CONFIG_SYS_TEXT_BASE=0x4010
> CONFIG_ENV_SIZE=0x2000
>-CONFIG_ENV_SECT_SIZE=0x1
>+CONFIG_ENV_SECT_SIZE=0x4
> CONFIG_ENV_OFFSET=0x30
> CONFIG_FSL_LS_PPA=y
> CONFIG_NR_DRAM_BANKS=2
>@@ -31,6 +31,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=155.spi-
>0:2m(uboot),14m(free)"
> CONFIG_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-qds-duart"
> CONFIG_ENV_IS_IN_SPI_FLASH=y
>+CONFIG_ENV_ADDR=0x4030
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_DM=y
> CONFIG_SATA_CEVA=y
>diff --git a/configs/ls1046aqds_tfa_defconfig
>b/configs/ls1046aqds_tfa_defconfig
>index df85533..18e3993 100644
>--- a/configs/ls1046aqds_tfa_defconfig
>+++ b/configs/ls1046aqds_tfa_defconfig
>@@ -3,7 +3,7 @@ CONFIG_TARGET_LS1046AQDS=y  CONFIG_TFABOOT=y
> CONFIG_SYS_TEXT_BASE=0x8200
> CONFIG_ENV_SIZE=0x2000
>-CONFIG_ENV_SECT_SIZE=0x2
>+CONFIG_ENV_SECT_SIZE=0x4
> CONFIG_ENV_OFFSET=0x50
> CONFIG_NR_DRAM_BANKS=2
> CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
>@@ -39,7 +39,7 @@ CONFIG_ENV_IS_IN_NAND=y
>CONFIG_ENV_IS_IN_SPI_FLASH=y  CONFIG_USE_ENV_SPI_BUS=y
> CONFIG_ENV_SPI_BUS=0
>-CONFIG_ENV_ADDR=0x6050
>+CONFIG_ENV_ADDR=0x4050
> CONFIG_DM=y
> CONFIG_SATA_CEVA=y
> CONFIG_FSL_CAAM=y
>diff --git a/configs/ls1046ardb_qspi_defconfig
>b/configs/ls1046ardb_qspi_defconfig
>index d5e0f02..d836421 100644
>--- a/configs/ls1046ardb_qspi_defconfig
>+++ b/configs/ls1046ardb_qspi_defconfig
>@@ -28,6 +28,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=155.spi-
>0:1m(rcw),15m(u-boot),48m(kernel.i
> CONFIG_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-rdb"
> CONFIG_ENV_IS_IN_SPI_FLASH=y
>+CONFIG_ENV_ADDR=0x4030
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> CONFIG_DM=y
> CONFIG_SATA_CEVA=y
>--
>2.7.4

Regards
Priyanka

Re: [PATCH 1/5 v2] efi_loader: Add headers for EDK2 StandAloneMM communication

[Ilias Apalodimas]

> 
> %s/SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE/SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE./
> 
> > + * @size:   vendor GUID

[...]

> > + * @name_size:  size of the name of the variable
> > + * @name:   variable name
> > + *
> > + * Defined in EDK2 as SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE
> 
> %s/SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE/SMM_VARIABLE_COMMUNICATE_GET_NEXT_VARIABLE_NAME./
> 
> Too much copy and paste ;)
> 
> > + */
> > + * @attr:attributes to query storage for

[...]

> > + *
> > + * Defined in EDK2 as SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE
> 
> %s/SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE/SMM_VARIABLE_COMMUNICATE_QUERY_VARIABLE_INFO./
> 
> I hope I caught all comment errors. Please, recheck.
> 

There were 3-4 more c/p trainwrecks in there. I'll post a v3 once you are done
with your testing.

Thanks
/Ilias

Re: [PATCH 1/5 v2] efi_loader: Add headers for EDK2 StandAloneMM communication

[Ilias Apalodimas]

Hi Heinrich

On Mon, May 11, 2020 at 09:39:51PM +0200, Heinrich Schuchardt wrote:
> On 5/11/20 8:13 PM, Ilias Apalodimas wrote:
> > +

[...] 

> > +/*
> > + * Interface to the pseudo TA, which provides a communication channel with
> 
> U-Boot developers might not know the OP-TEE terms. So I would tend to
> avoid abbreviations at least in the first reference.
> 
> %s/pseudo TA/Pseudo Trusted Application/
> 
> > + * the StandaloneMM Secure Partition (StMM) running at S-EL0
> 
> What does MM stand for? Management Mode?
> 

Yes 

> > + */
> > +
> > +#define PTA_STMM_CMDID_COMMUNICATE 0
> > +
> > +   0x9c, 0xc0, 0x2d, 0x72, 0xcd, 0xd9, 0x98, 0xa7 } }

[...]

> > +
> > +#define EFI_MM_VARIABLE_GUID \
> > + *
> > + * Defined in EDK2 as SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE
> 
> %s/SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE/SMM_VARIABLE_COMMUNICATE_GET_NEXT_VARIABLE_NAME./
> 
> Too much copy and paste ;)
> 

Indeed! Thanks for cathcing those

> > + */
> > +struct smm_variable_getnext {
> > +   efi_guid_t  guid;
> > +   efi_uintn_t name_size;
> > +   u16 name[];
> > +};
> > +
> > +#define MM_VARIABLE_GET_NEXT_HEADER_SIZE \
> > +   (sizeof(struct smm_variable_getnext))
> > +
> > +/**
> > + * struct smm_variable_query_info - Used to communicate with StMM for
> > + *  QueryVariableInfo.
> > + *
> > + * @max_variable_storage:max available storage
> > + * @remaining_variable_storage:  remaining available storage
> > + * @max_variable_size:   max variable supported size
> > + * @attr:attributes to query storage for
> > + *
> > + * Defined in EDK2 as SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE
> 
> %s/SMM_VARIABLE_COMMUNICATE_GET_PAYLOAD_SIZE/SMM_VARIABLE_COMMUNICATE_QUERY_VARIABLE_INFO./
> 
> I hope I caught all comment errors. Please, recheck.

Ok will do

> 
> Otherwise:
> Reviewed-by: Heinrich Schuchardt 
> 

Thanks!
/Ilias

Re: [PATCH 3/5 v2] cmd: efidebug: Add support for querying UEFI variable storage

[Ilias Apalodimas]

On Mon, May 11, 2020 at 08:54:04PM +0200, Heinrich Schuchardt wrote:
> On 5/11/20 8:14 PM, Ilias Apalodimas wrote:
> > With the previous patches that use OP-TEE and StandAloneMM for UEFI
> > variable storage we've added functionality for efi_query_variable_info.
> > So let's add the relevant command to efidebug and retrieve information
> > about the container used to store UEFI variables
> >
> > Signed-off-by: Ilias Apalodimas 
> 
> For now attributes (e.g. EFI_VARIABLE_NON_VOLATILE) cannot be passed to
> the 'efidebug query' sub-command instead a fixed value is used. We can
> add attributes on the command line later.

Good point, I'll add it on the commit message for v3

> 
> > ---
> >  cmd/efidebug.c | 44 +++-
> >  1 file changed, 43 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> > index d8a76d78a388..a3980772c934 100644
> > --- a/cmd/efidebug.c
> > +++ b/cmd/efidebug.c
> > @@ -1160,6 +1160,44 @@ static int do_efi_test(cmd_tbl_t *cmdtp, int flag,
> > return cp->cmd(cmdtp, flag, argc, argv);
> >  }
> >
> > +/**
> > + * do_efi_query_info() - QueryVariableInfo EFI service
> > + *
> > + * @cmdtp: Command table
> > + * @flag:  Command flag
> > + * @argc:  Number of arguments
> > + * @argv:  Argument array
> > + * Return: CMD_RET_SUCCESS on success,
> > + * CMD_RET_USAGE or CMD_RET_FAILURE on failure
> > + *
> > + * Implement efidebug "test" sub-command.
> > + */
> > +
> > +static int do_efi_query_info(cmd_tbl_t *cmdtp, int flag,
> > +int argc, char * const argv[])
> > +{
> > +   efi_status_t ret;
> > +   u32 attr = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > +   EFI_VARIABLE_RUNTIME_ACCESS |
> > +   EFI_VARIABLE_NON_VOLATILE;
> 
> As we do not support variables at runtime currently shouldn't we remove
> EFI_VARIABLE_RUNTIME_ACCESS from the default value? I could do that when
> merging.

We can still add variables marked as runtime in U-Boot's cmd line although we
don't support those in Linux. So I'd keep that flag on the defaults.

> 
> Otherwise:
> 
> Reviewed-by: Heinrich Schuchardt 
> 

Regards
/Ilias

Re: mmc: zynq_sdhci: transfer fails with 8-bit data bus

[Michal Simek]

On 11. 05. 20 16:06, Benedikt Grassl wrote:
> Hi,
> 
> with commit 942b5fc0 the 8-bit data bus seems to work fine in U-Boot.
> However, I have one situation where I get transfer errors lateron in
> Linux. At the moment I suspect that this is rather a problem of the
> Linux driver, but I would like to make sure here first.
> My ZynqMP has an eMMC flash connected to SD0 and an SD-card to SD1. When
> I boot the device from SD-card and load a kernel ITB (tested both 4.14
> and 5.4), I immediately get errors when writing to the eMMC flash in
> Linux:
> 
>  print_req_error: I/O error, dev mmcblk0, sector 2048
>  Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write
>  mmc0: Got data interrupt 0x0002 even though no data operation was in 
> progress.
>  mmc0: sdhci:  SDHCI REGISTER DUMP ===
>  mmc0: sdhci: Sys addr:  0x0400 | Version:  0x1002
>  mmc0: sdhci: Blk size:  0x7200 | Blk cnt:  0x0400
>  mmc0: sdhci: Argument:  0x | Trn mode: 0x0033
>  mmc0: sdhci: Present:   0x1ff7 | Host ctl: 0x003d
>  mmc0: sdhci: Power: 0x000f | Blk gap:  0x0080
>  mmc0: sdhci: Wake-up:   0x | Clock:0x0007
>  mmc0: sdhci: Timeout:   0x0006 | Int stat: 0x
>  mmc0: sdhci: Int enab:  0x02ff000b | Sig enab: 0x02ff000b
>  mmc0: sdhci: AC12 err:  0x | Slot int: 0x
>  mmc0: sdhci: Caps:  0x75ecc881 | Caps_1:   0x2007
>  mmc0: sdhci: Cmd:   0x0c1a | Max curr: 0x
>  mmc0: sdhci: Resp[0]:   0x0b00 | Resp[1]:  0x36475026
>  mmc0: sdhci: Resp[2]:   0x49533031 | Resp[3]:  0x0900
>  mmc0: sdhci: Host ctl2: 0x008b
>  mmc0: sdhci: ADMA Err:  0x | ADMA Ptr: 0x
>  mmc0: sdhci: 
> 
> Interestingly, I can work-around this by just typing "mmc info" in the
> U-Boot console. As soon as some interaction with mmc0 happens in U-Boot
> , this problem disappears (i.e. anything that relies on the mmc layer
> to issue transfers to the eMMC flash).
> This did not happen before, when only a 4-bit data bus was supported.
> Also the latest commit e44c2bc on the Xilinx U-boot git repository does
> not solve this problem.

Yes we found that 1.8v dt property requires partial revert of your patch
because logic in u-boot code is problematic and needs to be fixed.

> From my understanding, the Linux driver should be independent of the
> initialization done in U-Boot, right?
> Does anyone have an idea or a comment to this? Did I miss anything?

yes both should be independent. I have no idea what it is wrong in this
case but definitely something to look at.

Thanks,
Michal

Re: [PATCH v2 00/35] dm: Add programmatic generation of ACPI tables (part B)

[Bin Meng]

Hi Wolfgang, Andy,

On Mon, May 11, 2020 at 4:34 AM Simon Glass  wrote:
>
> NOTE: I have resent this as v1 to avoid confusion
>
> This is split from the original series in an attempt to get things applied
> in chunks.
>
> This part includes:
> - writing basic ACPI code for integers, strings, names, packages
> - writing descriptors for GPIO, I2C, interrupts, SPI
> - writing code to enable/disable ACPI peripherals via GPIOs
> - writing SSDT and DSDT tables
> - additional ways to determine ACPI device names
>
> Much of this code is taken from coreboot and I have tried to avoid
> changing the original code for no reason. Changes include:
> - splitting the acpi_dp functions into their own file
> - adding tests
> - adding (lots of) comments
> - using a context pointer instead of global variables
> - tidying up some code where couldn't resist (e.g. acpigen_emit_namestring())
>
> Changes in v2:
> - Fix memset of I2C descriptor
> - Fix memset of SPI descriptor
>
> Changes in v1:
> - Capitalise ACPI_OPS_PTR
> - Split into more patches for review
> - Add tests
> - Rebase on top of common.h series
> - Fix 'the an' typo
> - Move header definitions into this patch
> - Update sandbox driver slightly for testing
> - Switch parameter order of _acpi_fill_ssdt() and make it static
> - Fix 'sentinal' and 'METHOD_FILL_SDDT' typos
> - Correct the commit subject
> - Generalise the ACPI function recursion with acpi_recurse_method()
> - Generalise the ACPI function recursion with acpi_recurse_method()
> - Use OEM_TABLE_ID instead of ACPI_TABLE_CREATOR
> - Update ACPI_DSTATUS enum
> - Drop writing of coreboot tables
> - Generalise the ACPI function recursion with acpi_recurse_method()
> - Use acpi,ddn instead of acpi,desc
> - Rename to acpi_device_infer_name()
> - Update newly created sandbox tests
>

Since you were involved a lot in the discussion in the part A series,
would you please let me know if you get some time to review this?

Regards,
Bin

Re: [PATCH 1/1] tools: mkimage: use /* fallthrough */ as needed

[Punit Agrawal]

Heinrich Schuchardt  writes:

> GCC recognizes /* fallthrough */ if -Wimplicit-fallthrough=3 is enabled.
> Let's use it consistently.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  tools/mkimage.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index 336376f8d0..5689e5d75f 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -211,7 +211,7 @@ static void process_args(int argc, char **argv)
>   case 'f':
>   datafile = optarg;
>   params.auto_its = !strcmp(datafile, "auto");
> - /* no break */
> + /* fallthrough */
>   case 'F':
>   /*
>* The flattened image tree (FIT) format
> --
> 2.26.2

Looks good. Fwiw,

Reviewed-by: Punit Agrawal 

Thanks.

Re: [PATCH 6/8] net: dwc_eth_qos: Split eqos_start() to get link speed

[David Wu]

Hi Patrice,

在 2020/5/11 下午8:48, Patrice CHOTARD 写道:

Hi David

On 5/9/20 8:42 AM, David Wu wrote:

Hi Patrice,

在 2020/4/30 下午11:33, Patrice CHOTARD 写道:

Can you explain why you are splitting this function in 2 parts and calling 
these parts sequentially ?


For rockchip, need to obtain the current link speed to configure the tx clocks, 
(for example, in rgmii mode, 1000M link: 125M, 100M link: 25M, 10M link is 2.5M 
rate) and then enable gmac. So after the adjust_link(), before the start gamc, 
this intermediate stage needs to configure the clock according to the current 
link speed.



Please, add these informations in the commit message


I will add it at the next version, Thanks.



Thanks

Patrice

Re: Coreboot tests in gitlab?

[Bin Meng]

Hi Simon,

On Tue, May 12, 2020 at 9:41 AM Simon Glass  wrote:
>
> Hi Bin,
>
> What do you think about having a test in gitlab etc. that boots U-Boot from 
> coreboot using qemu? It might be handy as a sanity check. Do you think it 
> would be hard?

Yes, I think that's possible.

Regards,
Bin

Re: [PATCH] usb: max3420: add the gadget driver

[Jassi Brar]

Hi Marek, Hi Lukasz,

On Sat, Apr 11, 2020 at 10:42 PM Jassi Brar  wrote:
>
> On Sat, Apr 11, 2020 at 9:31 PM Marek Vasut  wrote:
> >
> > On 4/12/20 2:04 AM, Heinrich Schuchardt wrote:
> > > Am April 11, 2020 11:47:06 PM UTC schrieb Jassi Brar 
> > > :
> > >> On Sun, Mar 29, 2020 at 7:47 PM  wrote:
> > >>>
> > >>> From: Jassi Brar 
> > >>>
> > >>> MAX3420 implements FullSpeed USB Device over SPI.
> > >>> Another version MAX3421, also implements USB Host mode.
> > >>> This driver should be good for the device mode of max3421 as well.
> > >>>
> > >> A polite reminder please
> > >
> > > We have scripts/get_maintainer.pl to identify to whom patches should be 
> > > addressed. The USB maintainer is Marek.
> >
> > USB gadget maintainer is Lukasz, so CC him.
> >
> He is already.  Infact only he was CCed originally, but after two
> weeks that started to seem like too short a cc list :)
> Maybe the patchset needs to bake a little more still. I will wait.
>
Ping ...  if you want anything changed, I'll be happy to do it.

thanks.

Coreboot tests in gitlab?

[Simon Glass]

Hi Bin,

What do you think about having a test in gitlab etc. that boots U-Boot from
coreboot using qemu? It might be handy as a sanity check. Do you think it
would be hard?

Regards,
SImon

RE: [PATCH 1/2] imx: imx8mp_evk: fix boot issue

[Peng Fan]

> Subject: RE: [PATCH 1/2] imx: imx8mp_evk: fix boot issue
> 
> > Subject: Re: [PATCH 1/2] imx: imx8mp_evk: fix boot issue
> >
> > Hi Peng,
> >
> > On Mon, May 11, 2020 at 2:55 AM Peng Fan  wrote:
> > >
> > > The u-boot-spl.bin pad with ddr firmware conflicts with the
> > > CONFIG_MALLOC_F_ADDR area, the ddr firmware will be overwritten by
> > > malloc in SPL stage and cause ddr initialization not able to finish.
> > > So update the related addresses to fix the issue.
> > >
> > > Reported-by: Fabio Estevam 
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  include/configs/imx8mp_evk.h | 8 
> > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/include/configs/imx8mp_evk.h
> > > b/include/configs/imx8mp_evk.h index 80e5738961..b90a4f6932 100644
> > > --- a/include/configs/imx8mp_evk.h
> > > +++ b/include/configs/imx8mp_evk.h
> > > @@ -23,15 +23,15 @@
> > >  #ifdef CONFIG_SPL_BUILD
> > >  /*#define CONFIG_ENABLE_DDR_TRAINING_DEBUG*/
> > >  #define CONFIG_SPL_LDSCRIPT
> > "arch/arm/cpu/armv8/u-boot-spl.lds"
> > > -#define CONFIG_SPL_STACK   0x99
> > > -#define CONFIG_SPL_BSS_START_ADDR  0x0095e000
> > > -#define CONFIG_SPL_BSS_MAX_SIZE0x2000  /* 8 KB */
> > > +#define CONFIG_SPL_STACK   0x98fc00
> >
> > On imx6/imx7 we have this kind of SPL information placed in the SoC
> > related header files:
> >
> > include/configs/imx6_spl.h
> > include/configs/imx7_spl.h
> >
> > We should do the same here instead of repeating these SPL settings in
> > every board header file.
> 
> ok. Fix in next version.

After a thought, i.MX8MQ/MM/MN/MP have different OCRAM sizes,
and ATF locates in different places. So I would keep current code as is.

Thanks,
Peng.

> 
> Thanks,
> Peng.
> 
> >
> > Thanks

[PATCH V2 1/7] driver: ddr: imx: skip ddr_ss_gpr config on imx8mn

[Peng Fan]

From: Jacky Bai 

There is no DDR_SS_GPR0 exits on i.MX8MN, so skip setting
this register on i.MX8MN.

Signed-off-by: Jacky Bai 
Signed-off-by: Peng Fan 
---
 drivers/ddr/imx/imx8m/ddr_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/imx/imx8m/ddr_init.c b/drivers/ddr/imx/imx8m/ddr_init.c
index af8c1427d2..ba5ae05035 100644
--- a/drivers/ddr/imx/imx8m/ddr_init.c
+++ b/drivers/ddr/imx/imx8m/ddr_init.c
@@ -73,7 +73,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
 
/* if ddr type is LPDDR4, do it */
tmp = reg32_read(DDRC_MSTR(0));
-   if (tmp & (0x1 << 5))
+   if (tmp & (0x1 << 5) && !is_imx8mn())
reg32_write(DDRC_DDR_SS_GPR0, 0x01); /* LPDDR4 mode */
 
/* determine the initial boot frequency */
-- 
2.16.4

[PATCH V2 2/7] driver: ddr: imx: correct the pwrctl setting of selfref_en on imx8m

[Peng Fan]

From: Jacky Bai 

The 'selfref_en' should be bit'0', so correct the setting to
enable the auto self-refresh.

Reviewed-by: Jian Li 
Reviewed-by: Ye Li 
Signed-off-by: Jacky Bai 
Signed-off-by: Peng Fan 
---
 drivers/ddr/imx/imx8m/ddr_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/imx/imx8m/ddr_init.c b/drivers/ddr/imx/imx8m/ddr_init.c
index ba5ae05035..06b4341b11 100644
--- a/drivers/ddr/imx/imx8m/ddr_init.c
+++ b/drivers/ddr/imx/imx8m/ddr_init.c
@@ -162,7 +162,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
/* Step26: Set back register in Step4 to the original values if desired 
*/
reg32_write(DDRC_RFSHCTL3(0), 0x000);
/* enable selfref_en by default */
-   setbits_le32(DDRC_PWRCTL(0), 0x1 << 3);
+   setbits_le32(DDRC_PWRCTL(0), 0x1);
 
/* enable port 0 */
reg32_write(DDRC_PCTRL_0(0), 0x0001);
-- 
2.16.4

[PATCH V2 3/7] drivers: ddr: imx8mp: Add inline ECC feature support

[Peng Fan]

From: Sherry Sun 

the DRAM Controller in i.MX8MP will support a feature called "Inline ECC".
This is supported for all 3 supported DRAM technologies (LPDDR4, DDR4 and
DDR3L). When this feature is enabled by software, the DRAM Controller
reserves 12.5% of DRAM capacity for ECC information, and presents only
the non-ECC portion (lower 87.5% of the installed capacity of DRAM) to
the rest of the SoC.
The DRAM memory can be divided into 8 regions so that if a use case only
requires ECC protection on a subset of memory, then only that subset of
memory need support inline ECC. If this occurs, then there is no
performance penalty accessing the non-ECC-protected memory (no need to
access ECC for this portion of the memory map). This is all configured
with the DRAM Controller.

Signed-off-by: Sherry Sun 
Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/ddr.h |  7 
 drivers/ddr/imx/imx8m/Kconfig |  7 
 drivers/ddr/imx/imx8m/ddr_init.c  | 72 +++
 3 files changed, 86 insertions(+)

diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h 
b/arch/arm/include/asm/arch-imx8m/ddr.h
index 7a2a2d8edc..04c9c962cf 100644
--- a/arch/arm/include/asm/arch-imx8m/ddr.h
+++ b/arch/arm/include/asm/arch-imx8m/ddr.h
@@ -529,6 +529,8 @@ enum msg_response {
 #define DDRC_SBRWDATA0(X)(DDRC_IPS_BASE_ADDR(X) + 0xf2c)
 #define DDRC_SBRWDATA1(X)(DDRC_IPS_BASE_ADDR(X) + 0xf30)
 #define DDRC_PDCH(X) (DDRC_IPS_BASE_ADDR(X) + 0xf34)
+#define DDRC_SBRSTART0(X)(DDRC_IPS_BASE_ADDR(X) + 0xf38)
+#define DDRC_SBRRANGE0(X)(DDRC_IPS_BASE_ADDR(X) + 0xf40)
 
 #define DDRC_FREQ1_DERATEEN(X) (DDRC_IPS_BASE_ADDR(X) + 0x2020)
 #define DDRC_FREQ1_DERATEINT(X)(DDRC_IPS_BASE_ADDR(X) + 0x2024)
@@ -708,6 +710,11 @@ int ddr_cfg_phy(struct dram_timing_info *timing_info);
 void load_lpddr4_phy_pie(void);
 void ddrphy_trained_csr_save(struct dram_cfg_param *param, unsigned int num);
 void dram_config_save(struct dram_timing_info *info, unsigned long base);
+void board_dram_ecc_scrub(void);
+void ddrc_inline_ecc_scrub(unsigned int start_address,
+  unsigned int range_address);
+void ddrc_inline_ecc_scrub_end(unsigned int start_address,
+  unsigned int range_address);
 
 /* utils function for ddr phy training */
 int wait_ddrphy_training_complete(void);
diff --git a/drivers/ddr/imx/imx8m/Kconfig b/drivers/ddr/imx/imx8m/Kconfig
index 5bf61eb258..a5f5524fbe 100644
--- a/drivers/ddr/imx/imx8m/Kconfig
+++ b/drivers/ddr/imx/imx8m/Kconfig
@@ -29,4 +29,11 @@ config SAVED_DRAM_TIMING_BASE
  info into memory for low power use. OCRAM_S is used for this
  purpose on i.MX8MM.
default 0x18
+
+config IMX8M_DRAM_INLINE_ECC
+   bool "imx8mp inline ECC"
+   depends on IMX8MP && IMX8M_LPDDR4
+   help
+ Select this config if you want to use inline ecc feature for
+ imx8mp-evk board.
 endmenu
diff --git a/drivers/ddr/imx/imx8m/ddr_init.c b/drivers/ddr/imx/imx8m/ddr_init.c
index 06b4341b11..f573a778d9 100644
--- a/drivers/ddr/imx/imx8m/ddr_init.c
+++ b/drivers/ddr/imx/imx8m/ddr_init.c
@@ -20,6 +20,76 @@ void ddr_cfg_umctl2(struct dram_cfg_param *ddrc_cfg, int num)
}
 }
 
+#ifdef CONFIG_IMX8M_DRAM_INLINE_ECC
+void ddrc_inline_ecc_scrub(unsigned int start_address,
+  unsigned int range_address)
+{
+   unsigned int tmp;
+
+   /* Step1: Enable quasi-dynamic programming */
+   reg32_write(DDRC_SWCTL(0), 0x);
+   /* Step2: Set ECCCFG1.ecc_parity_region_lock to 1 */
+   reg32setbit(DDRC_ECCCFG1(0), 0x4);
+   /* Step3: Block the AXI ports from taking the transaction */
+   reg32_write(DDRC_PCTRL_0(0), 0x0);
+   /* Step4: Set scrub start address */
+   reg32_write(DDRC_SBRSTART0(0), start_address);
+   /* Step5: Set scrub range address */
+   reg32_write(DDRC_SBRRANGE0(0), range_address);
+   /* Step6: Set scrub_mode to write */
+   reg32_write(DDRC_SBRCTL(0), 0x0014);
+   /* Step7: Set the desired pattern through SBRWDATA0 registers */
+   reg32_write(DDRC_SBRWDATA0(0), 0x55aa55aa);
+   /* Step8: Enable the SBR by programming SBRCTL.scrub_en=1 */
+   reg32setbit(DDRC_SBRCTL(0), 0x0);
+   /* Step9: Poll SBRSTAT.scrub_done=1 */
+   tmp = reg32_read(DDRC_SBRSTAT(0));
+   while (tmp != 0x0002)
+   tmp = reg32_read(DDRC_SBRSTAT(0)) & 0x2;
+   /* Step10: Poll SBRSTAT.scrub_busy=0 */
+   tmp = reg32_read(DDRC_SBRSTAT(0));
+   while (tmp != 0x0)
+   tmp = reg32_read(DDRC_SBRSTAT(0)) & 0x1;
+   /* Step11: Disable SBR by programming SBRCTL.scrub_en=0 */
+   clrbits_le32(DDRC_SBRCTL(0), 0x1);
+   /* Step12: Prepare for normal scrub operation(Read) and set 
scrub_interval*/
+   reg32_write(DDRC_SBRCTL(0), 0x100);
+   /* Step13: Enable the SBR by programming SBRCTL.scrub_en=1 */
+   

[PATCH V2 0/7] imx: drivers: ddr: ddr driver update

[Peng Fan]

V2:
 Drop patch to print dram rate
 remove board ddr ecc part from patch enabling inline ecc feature

This is to upstream NXP vendor tree ddr driver related fix and update

Jacky Bai (2):
  driver: ddr: imx: skip ddr_ss_gpr config on imx8mn
  driver: ddr: imx: correct the pwrctl setting of selfref_en on imx8m

Jian Li (3):
  imx8mp: enable rd_port_urgent
  imx8mp: DDR performance tunning
  imx8mp: Disables use of MR4 TUF flag (MR4[7]) bit

Oliver Chen (1):
  drivers: ddr: imx Workaround for i.MX8M DDRPHY rank to rank issue

Sherry Sun (1):
  drivers: ddr: imx8mp: Add inline ECC feature support

 arch/arm/include/asm/arch-imx8m/ddr.h  |  10 ++
 board/freescale/imx8mp_evk/lpddr4_timing.c |   5 +-
 drivers/ddr/imx/imx8m/Kconfig  |   7 ++
 drivers/ddr/imx/imx8m/ddr_init.c   |  79 +-
 drivers/ddr/imx/imx8m/ddrphy_train.c   |   7 ++
 drivers/ddr/imx/imx8m/ddrphy_utils.c   | 164 +
 6 files changed, 268 insertions(+), 4 deletions(-)

-- 
2.16.4

Re: [PATCH v7 19/22] sifive: dts: fu540: Enable L2 Cache in U-Boot

[Bin Meng]

Hi Pragnesh,

On Mon, May 11, 2020 at 6:35 PM Pragnesh Patel
 wrote:
>
> >-Original Message-
> >From: Bin Meng 
> >Sent: 11 May 2020 15:41
> >To: Pragnesh Patel 
> >Cc: Jagan Teki ; U-Boot-Denx  >b...@lists.denx.de>; Atish Patra ; Palmer Dabbelt
> >; Paul Walmsley ;
> >Troy Benjegerdes ; Anup Patel
> >; Sagar Kadam ; Rick Chen
> >
> >Subject: Re: [PATCH v7 19/22] sifive: dts: fu540: Enable L2 Cache in U-Boot
> >
> >[External Email] Do not click links or attachments unless you recognize the
> >sender and know the content is safe
> >
> >Hi Pragnesh,
> >
> >On Mon, May 11, 2020 at 5:55 PM Pragnesh Patel
> > wrote:
> >>
> >> >-Original Message-
> >> >From: Bin Meng 
> >> >Sent: 11 May 2020 15:17
> >> >To: Pragnesh Patel 
> >> >Cc: Jagan Teki ; U-Boot-Denx  >> >b...@lists.denx.de>; Atish Patra ; Palmer
> >> >Dabbelt ; Paul Walmsley
> >> >; Troy Benjegerdes
> >> >; Anup Patel ; Sagar
> >> >Kadam ; Rick Chen 
> >> >Subject: Re: [PATCH v7 19/22] sifive: dts: fu540: Enable L2 Cache in
> >> >U-Boot
> >> >
> >> >[External Email] Do not click links or attachments unless you
> >> >recognize the sender and know the content is safe
> >> >
> >> >Hi Pragnesh,
> >> >
> >> >On Mon, May 11, 2020 at 5:34 PM Pragnesh Patel
> >> > wrote:
> >> >>
> >> >> >-Original Message-
> >> >> >From: Jagan Teki 
> >> >> >Sent: 11 May 2020 14:35
> >> >> >To: Bin Meng 
> >> >> >Cc: Pragnesh Patel ; U-Boot-Denx  >> >> >b...@lists.denx.de>; Atish Patra ; Palmer
> >> >> >Dabbelt ; Paul Walmsley
> >> >> >; Troy Benjegerdes
> >> >> >; Anup Patel ;
> >> >> >Sagar Kadam ; Rick Chen
> >> >> >
> >> >> >Subject: Re: [PATCH v7 19/22] sifive: dts: fu540: Enable L2 Cache
> >> >> >in U-Boot
> >> >> >
> >> >> >[External Email] Do not click links or attachments unless you
> >> >> >recognize the sender and know the content is safe
> >> >> >
> >> >> >Hi Bin,
> >> >> >
> >> >> >On Mon, May 11, 2020 at 2:30 PM Bin Meng 
> >> >wrote:
> >> >> >>
> >> >> >> Hi Jagan,
> >> >> >>
> >> >> >> On Mon, May 11, 2020 at 4:48 PM Jagan Teki
> >> >> > wrote:
> >> >> >> >
> >> >> >> > On Mon, May 11, 2020 at 1:15 PM Pragnesh Patel
> >> >> >> >  wrote:
> >> >> >> > >
> >> >> >> > > >-Original Message-
> >> >> >> > > >From: Jagan Teki 
> >> >> >> > > >Sent: 11 May 2020 12:56
> >> >> >> > > >To: Pragnesh Patel 
> >> >> >> > > >Cc: U-Boot-Denx ; Atish Patra
> >> >> >> > > >; Palmer Dabbelt
> >> >> >;
> >> >> >> > > >Bin Meng ; Paul Walmsley
> >> >> >> > > >; Troy Benjegerdes
> >> >> >> > > >; Anup Patel
> >> >> >> > > >; Sagar Kadam
> >;
> >> >> >> > > >Rick Chen 
> >> >> >> > > >Subject: Re: [PATCH v7 19/22] sifive: dts: fu540: Enable L2
> >> >> >> > > >Cache in U-Boot
> >> >> >> > > >
> >> >> >> > > >[External Email] Do not click links or attachments unless
> >> >> >> > > >you recognize the sender and know the content is safe
> >> >> >> > > >
> >> >> >> > > >On Mon, May 11, 2020 at 12:37 PM Pragnesh Patel
> >> >> >> > > > wrote:
> >> >> >> > > >>
> >> >> >> > > >> >-Original Message-
> >> >> >> > > >> >From: Jagan Teki 
> >> >> >> > > >> >Sent: 11 May 2020 12:25
> >> >> >> > > >> >To: Pragnesh Patel 
> >> >> >> > > >> >Cc: U-Boot-Denx ; Atish Patra
> >> >> >> > > >> >; Palmer Dabbelt
> >> >> >> > > >> >;
> >> >> >> > > >Bin
> >> >> >> > > >> >Meng ; Paul Walmsley
> >> >> >> > > >;
> >> >> >> > > >> >Troy Benjegerdes ; Anup
> >> >> >> > > >> >Patel ; Sagar Kadam
> >> >;
> >> >> >> > > >> >Rick
> >> >> >> > > >Chen
> >> >> >> > > >> >
> >> >> >> > > >> >Subject: Re: [PATCH v7 19/22] sifive: dts: fu540: Enable
> >> >> >> > > >> >L2 Cache in U-Boot
> >> >> >> > > >> >
> >> >> >> > > >> >[External Email] Do not click links or attachments
> >> >> >> > > >> >unless you recognize the sender and know the content is
> >> >> >> > > >> >safe
> >> >> >> > > >> >
> >> >> >> > > >> >On Mon, May 11, 2020 at 11:35 AM Pragnesh Patel
> >> >> >> > > >> > wrote:
> >> >> >> > > >> >>
> >> >> >> > > >> >> >-Original Message-
> >> >> >> > > >> >> >From: Jagan Teki 
> >> >> >> > > >> >> >Sent: 10 May 2020 15:02
> >> >> >> > > >> >> >To: Pragnesh Patel 
> >> >> >> > > >> >> >Cc: U-Boot-Denx ; Atish Patra
> >> >> >> > > >> >> >; Palmer Dabbelt
> >> >> >> > > >;
> >> >> >> > > >> >Bin
> >> >> >> > > >> >> >Meng ; Paul Walmsley
> >> >> >> > > >> >;
> >> >> >> > > >> >> >Troy Benjegerdes ; Anup
> >> >> >> > > >> >> >Patel ; Sagar Kadam
> >> >> >;
> >> >> >> > > >> >> >Rick
> >> >> >> > > >> >Chen
> >> >> >> > > >> >> >
> >> >> >> > > >> >> >Subject: Re: [PATCH v7 19/22] sifive: dts: fu540:
> >> >> >> > > >> >> >Enable
> >> >> >> > > >> >> >L2 Cache in U-Boot
> >> >> >> > > >> >> >
> >> >> >> > > >> >> >[External Email] Do not click links or attachments
> >> >> >> > > >> >> >unless you recognize the sender and know the content
> >> >> >> > > >> >> >is safe
> >> >> >> > > >> >> >
> >> >> >> > > >> >> >On Sun, May 3, 2020 at 12:57 PM Pragnesh Patel
> >> >> >> > > >> >> > wrote:
> >> >> >> > > >> >> >>
> >> >> >> > > >> >> >> Hi jagan,
> >> >> >> > > >> >> >>
> >> 

Re: [PATCH v4 12/16] usb: dwc3: add make compatible for rockchip platform

[Frank Wang]

Hi Marek,

On 2020/5/11 17:48, Marek Vasut wrote:

On 5/11/20 9:57 AM, Frank Wang wrote:
[...]


@@ -394,6 +407,12 @@ static int dwc3_glue_probe(struct udevice *dev)
if (ret)
return ret;
  
+	if (glue->resets.count < 1) {

This condition is only true if count == 0 ?
What's the purpose of this test ?


For previous dts of the Linux kernel, the reset phandles were in 
dwc3-glue nodes, however, they are moved recently into dwc3 that is a 
child node of dwc3-glue.


So the above codes is to make compatible.



+   ret = dwc3_glue_reset_init(child, glue);
+   if (ret)
+   return ret;
+   }
+
while (child) {
enum usb_dr_mode dr_mode;
  

[...]




BR,
Frank

RE: [PATCH 1/2] imx: imx8mp_evk: fix boot issue

[Peng Fan]

> Subject: Re: [PATCH 1/2] imx: imx8mp_evk: fix boot issue
> 
> Hi Peng,
> 
> On Mon, May 11, 2020 at 2:55 AM Peng Fan  wrote:
> >
> > The u-boot-spl.bin pad with ddr firmware conflicts with the
> > CONFIG_MALLOC_F_ADDR area, the ddr firmware will be overwritten by
> > malloc in SPL stage and cause ddr initialization not able to finish.
> > So update the related addresses to fix the issue.
> >
> > Reported-by: Fabio Estevam 
> > Signed-off-by: Peng Fan 
> > ---
> >  include/configs/imx8mp_evk.h | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/configs/imx8mp_evk.h
> > b/include/configs/imx8mp_evk.h index 80e5738961..b90a4f6932 100644
> > --- a/include/configs/imx8mp_evk.h
> > +++ b/include/configs/imx8mp_evk.h
> > @@ -23,15 +23,15 @@
> >  #ifdef CONFIG_SPL_BUILD
> >  /*#define CONFIG_ENABLE_DDR_TRAINING_DEBUG*/
> >  #define CONFIG_SPL_LDSCRIPT
> "arch/arm/cpu/armv8/u-boot-spl.lds"
> > -#define CONFIG_SPL_STACK   0x99
> > -#define CONFIG_SPL_BSS_START_ADDR  0x0095e000
> > -#define CONFIG_SPL_BSS_MAX_SIZE0x2000  /* 8 KB */
> > +#define CONFIG_SPL_STACK   0x98fc00
> 
> On imx6/imx7 we have this kind of SPL information placed in the SoC related
> header files:
> 
> include/configs/imx6_spl.h
> include/configs/imx7_spl.h
> 
> We should do the same here instead of repeating these SPL settings in every
> board header file.

ok. Fix in next version.

Thanks,
Peng.

> 
> Thanks

RE: [PATCH 3/8] imx8mp: ddr: Add inline ECC feature support

[Peng Fan]

> Subject: Re: [PATCH 3/8] imx8mp: ddr: Add inline ECC feature support
> 
> Hi Peng,
> 
> On Mon, May 11, 2020 at 6:30 AM Peng Fan  wrote:
> >
> > From: Sherry Sun 
> >
> > Add inline ECC support for lpddr4 on imx8mp-evk. And add a config
> > which can enable/disable inline ECC feature for lpddr4 on imx8mp-evk
> board.
> 
> Please elaborate more on this inline ECC feature: when and why does it need
> to be selected, for example.

ok.

> 
> > --- a/board/freescale/imx8mp_evk/lpddr4_timing.c
> > +++ b/board/freescale/imx8mp_evk/lpddr4_timing.c
> > @@ -14,6 +14,9 @@ struct dram_cfg_param ddr_ddrc_cfg[] = {
> > { 0x3d400020, 0x323 },
> > { 0x3d400024, 0x1e84800 },
> > { 0x3d400064, 0x7a0118 },
> > +#ifdef CONFIG_IMX8M_DRAM_INLINE_ECC
> 
> I see no user for this symbol at the moment.
> 
> It is usually better to introduce the symbol when there is a real user for it.

This is the the just the driver part. To enable this feature, we need a 
dedicated
defconfig. The defconfig part will be posted in other patches.

Thanks,
Peng.

Re: [PATCH v4 0/5] TI Ethernet PHY changes

[Dan Murphy]

Bump to the series

On 5/4/20 4:14 PM, Dan Murphy wrote:

Hello

The addition of the DP83867 driver to uboot was done in a generic way that
made it a bit difficult to bring in new PHY drivers.  The difficulty came in the
config flags and the phy_init function.  The change is to make the flags and
init for the DP83867 more specific to the DP83867 device to make way to add
more TI PHYs to uBoot.

In addition the DP8382X PHY is a generic PHY driver that does not need any
special handling to establish a link.  Customers have requested that at the very
least there be a way to know if the PHY attached is the PHY that is connected
as "Generic PHY" is not really descriptive.  These patches adds the
registrations for TI Generic PHYs to associcate a TI PHY ID with a PHY name.

Porting PHY helper routines to set and clear bits to facilitate easier side
porting of ethernet kernel drivers to uBoot.

Also fixed and added missing or kernel doc documentation in the phy.h file.

Dan

Dan Murphy (5):
   net: phy: Add missing kernel doc to phy functions
   net: phy: Fix kernel doc issues in phy.h
   net: phy: Add helper routines to set and clear bits
   net: phy: Add support for TI PHY init
   net: phy: Add DP8382x phy registration to TI PHY init

  configs/am65x_evm_a53_defconfig  |   2 +-
  configs/am65x_hs_evm_a53_defconfig   |   2 +-
  configs/dra7xx_evm_defconfig |   2 +-
  configs/dra7xx_hs_evm_defconfig  |   2 +-
  configs/dra7xx_hs_evm_usb_defconfig  |   2 +-
  configs/j721e_evm_a72_defconfig  |   2 +-
  configs/j721e_hs_evm_a72_defconfig   |   2 +-
  configs/k2g_evm_defconfig|   2 +-
  configs/xilinx_versal_virt_defconfig |   2 +-
  configs/xilinx_zynqmp_virt_defconfig |   2 +-
  drivers/net/phy/Kconfig  |  15 
  drivers/net/phy/Makefile |   3 +-
  drivers/net/phy/dp83867.c|   3 +-
  drivers/net/phy/ti_phy_init.c| 101 
  drivers/net/phy/ti_phy_init.h|  15 
  include/phy.h| 112 ---
  16 files changed, 246 insertions(+), 23 deletions(-)
  create mode 100644 drivers/net/phy/ti_phy_init.c
  create mode 100644 drivers/net/phy/ti_phy_init.h

RE: [PATCH 4/8] drivers: ddr: imx8m: add print for DRAM rate

[Peng Fan]

> Subject: Re: [PATCH 4/8] drivers: ddr: imx8m: add print for DRAM rate
> 
> On 11.05.20 11:53, Peng Fan wrote:
> > From: Ye Li 
> >
> > Enable print to show the DRAM rate of current setting and training
> > result.
> >
> > Reviewed-by: Peng Fan 
> > Signed-off-by: Ye Li 
> > Signed-off-by:  Peng Fan 
> > ---
> 
> This changes the boottime, too. The printf() are really useful only for
> debugging, IMHO it is better to let it as it is. If something is going wrong, 
> one
> set DEBUG to get the output.

ok. I'll drop this patch from the patchset.

Thanks,
Peng.

> 
> Regards,
> Stefano
> 
> >  drivers/ddr/imx/imx8m/ddr_init.c | 7 ---
> >  drivers/ddr/imx/imx8m/ddrphy_utils.c | 2 +-
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/ddr/imx/imx8m/ddr_init.c
> > b/drivers/ddr/imx/imx8m/ddr_init.c
> > index f573a778d9..a1d2d21692 100644
> > --- a/drivers/ddr/imx/imx8m/ddr_init.c
> > +++ b/drivers/ddr/imx/imx8m/ddr_init.c
> > @@ -95,7 +95,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
> > unsigned int tmp, initial_drate, target_freq;
> > int ret;
> >
> > -   debug("DDRINFO: start DRAM init\n");
> > +   printf("DDRINFO: start DRAM init\n");
> >
> > /* Step1: Follow the power up procedure */
> > if (is_imx8mq()) {
> > @@ -118,6 +118,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
> >
> > initial_drate = dram_timing->fsp_msg[0].drate;
> > /* default to the frequency point 0 clock */
> > +   printf("DDRINFO: DRAM rate %dMTS\n", initial_drate);
> 
> 
> 
> > ddrphy_init_set_dfi_clk(initial_drate);
> >
> > /* D-aasert the presetn */
> > @@ -184,7 +185,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
> > tmp = reg32_read(DDRPHY_CalBusy(0));
> > } while ((tmp & 0x1));
> >
> > -   debug("DDRINFO:ddrphy calibration done\n");
> > +   printf("DDRINFO:ddrphy calibration done\n");
> >
> > /* Step15: Set SWCTL.sw_done to 0 */
> > reg32_write(DDRC_SWCTL(0), 0x); @@ -236,7 +237,7 @@ int
> > ddr_init(struct dram_timing_info *dram_timing)
> >
> > /* enable port 0 */
> > reg32_write(DDRC_PCTRL_0(0), 0x0001);
> > -   debug("DDRINFO: ddrmix config done\n");
> > +   printf("DDRINFO: ddrmix config done\n");
> >
> > board_dram_ecc_scrub();
> >
> > diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c
> > b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> > index 9ac7ca923c..9d2378d7dd 100644
> > --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c
> > +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> > @@ -97,7 +97,7 @@ int wait_ddrphy_training_complete(void)
> > debug("Training PASS\n");
> > return 0;
> > } else if (mail == 0xff) {
> > -   debug("Training FAILED\n");
> > +   printf("Training FAILED\n");
> > return -1;
> > }
> > }
> >
> 
> 
> --
> ==
> ===
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> ==
> ===

Re: [PATCH 3/8] imx8mp: ddr: Add inline ECC feature support

[Fabio Estevam]

Hi Peng,

On Mon, May 11, 2020 at 6:30 AM Peng Fan  wrote:
>
> From: Sherry Sun 
>
> Add inline ECC support for lpddr4 on imx8mp-evk. And add a config which
> can enable/disable inline ECC feature for lpddr4 on imx8mp-evk board.

Please elaborate more on this inline ECC feature: when and why does it
need to be selected, for example.

> --- a/board/freescale/imx8mp_evk/lpddr4_timing.c
> +++ b/board/freescale/imx8mp_evk/lpddr4_timing.c
> @@ -14,6 +14,9 @@ struct dram_cfg_param ddr_ddrc_cfg[] = {
> { 0x3d400020, 0x323 },
> { 0x3d400024, 0x1e84800 },
> { 0x3d400064, 0x7a0118 },
> +#ifdef CONFIG_IMX8M_DRAM_INLINE_ECC

I see no user for this symbol at the moment.

It is usually better to introduce the symbol when there is a real user for it.

[ANN] U-Boot v2020.07-rc2 released

[Tom Rini]

Hey all,

It's release day and I've tagged v2020.07-rc2.  At this point out we
should be seeing stabilization, clean-up and localized new features.

Once again, for a changelog, 
git log --merges v2020.07-rc1..v2020.07-rc2
and as always, I ask for more details in the PRs people send me so I can
put them in the merge commit.

I'm planning to follow the every-other-week RC schedule and release on
July 6th.  I'm also thinking about opening -next again on June 8th as
that will give us a bit more time to focus on stability and regression
fixing.  Thanks all!

-- 
Tom

signature.asc
Description: PGP signature

Re: Pull request for UEFI sub-system for efi-2020-07-rc2-4

[Tom Rini]

On Mon, May 11, 2020 at 05:25:16PM +0200, Heinrich Schuchardt wrote:

> The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d:
> 
>   Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2020-07-rc2-4
> 
> for you to fetch changes up to bdb15776f6d93a1fe7902346db06a2a9fd43381e:
> 
>   cmd: efidebug: fix -Werror=type-limits warning (2020-05-10 00:01:12 +0200)
> 
> No problems were reported by Gitlab CI and Travis:
> https://travis-ci.org/github/xypron2/u-boot/builds/685166920
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/3170
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 21/22] Use __ASSEMBLY__ as the assembly macros

[Tom Rini]

On Mon, May 11, 2020 at 02:28:54PM -0600, Simon Glass wrote:
> Hi Masahiro,
> 
> On Sun, 10 May 2020 at 22:57, Masahiro Yamada  wrote:
> >
> > On Mon, May 11, 2020 at 2:43 AM Simon Glass  wrote:
> > >
> > > Some places use __ASSEMBLER__ instead which does not work since the
> > > Makefile does not define it. Fix them.
> > >
> > > Signed-off-by: Simon Glass 
> >
> >
> > I think we decided to not do this in v2, didn't we?
> >
> > http://patchwork.ozlabs.org/project/uboot/patch/20200409201506.133129-6-...@chromium.org/
> 
> I must have misunderstood that thread. I think we should be consistent
> in U-Boot as to which one we use. It makes it much harder to check
> things when there are multiple options.

So, we should generally use __ASSMEBLY__ which is what U-Boot and Linux
kernel have used for forever.  I do see a handful of __ASSEMBLER__ in
Linux now.  That said:

> > >  include/atf_common.h   | 2 +-

atf_common.h comes from another project, so this is just going to
introduce sync-noise and unlikely to matter for the binman use-case?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] kbuild: add -Werror=implicit-function-declaration

[Tom Rini]

On Mon, May 11, 2020 at 02:28:48PM -0600, Simon Glass wrote:
> Hi,
> 
> On Sun, 10 May 2020 at 20:14, Marek Vasut  wrote:
> >
> > On 5/11/20 3:59 AM, Masahiro Yamada wrote:
> > > Hi Simon,
> > >
> > > On Mon, May 11, 2020 at 5:37 AM Simon Glass  wrote:
> > >>
> > >> Hi Masahiro,
> > >>
> > >> On Sat, 9 May 2020 at 05:00, Masahiro Yamada  
> > >> wrote:
> > >>>
> > >>> On Sat, May 9, 2020 at 3:16 AM Tom Rini  wrote:
> > 
> >  On Thu, May 07, 2020 at 09:16:40PM -0600, Simon Glass wrote:
> > > Hi Masahiro,
> > >
> > > On Thu, 7 May 2020 at 19:54, Masahiro Yamada  
> > > wrote:
> > >>
> > >> On Fri, May 8, 2020 at 10:39 AM Simon Glass  
> > >> wrote:
> > >>>
> > >>> Hi Masahiro,
> > >>>
> > >>> On Thu, 7 May 2020 at 06:21, Masahiro Yamada
> > >>>  wrote:
> > 
> >  Add -Werror=implicit-function-declaration as Linux does.
> > 
> >  If you do not check the prototype, it may go wrong run-time.
> >  It is better to break the build, and require to include correct
> >  headers.
> > 
> >  Signed-off-by: Masahiro Yamada 
> >  ---
> > 
> >   Makefile | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> NAK
> > >>>
> > >>> We already get a warning in this situation. This makes it painful 
> > >>> for
> > >>> development since things that should be warnings end up being 
> > >>> errors.
> > >>> So your build fails when really it should work well enough to do a
> > >>> test run with your new code. I don't think it has any benefit on 
> > >>> code
> > >>> quality since we already detect warnings in gitlab, etc.
> > >>>
> > >>> U-Boot is set up so that warnings are reported and are easy to spot 
> > >>> if
> > >>> you use 'make -s' (i.e. not buried in the output).
> > >>>
> > >>> Regards,
> > >>> Simon
> > >>
> > >>
> > >>
> > >> Linux added this flag in 2007.
> > >>
> > >> The intention seems to break the build earlier
> > >> when a non-existing function is used.
> > >>
> > >> I have not seen compliant about this flag in Linux.
> > >> What does it make different for U-Boot ?
> > >
> > > Well that commit message is quite misleading. The author is presumably
> > > ignoring the warnings that come out in the compile phase. For me they
> > > come up loud and clear. I don't know why it takes half an hour to get
> > > to the link stage. My average incremental build time is under 4
> > > seconds including the link.
> > >
> > > Finally, the warning does not tell you anything about whether the
> > > function doesn't exist. It just tells you you have left out a header
> > > file.
> > >
> > > I know how much of a pain this is, because coreboot does this. It does
> > > it partly because there is so much build output that the warnings are
> > > invisible unless they actually halt the build. Even then you have to
> > > search for what went wrong.
> > 
> >  I'm not immediately sure of the right answer here.  Part of the problem
> >  is that even with 'make -s' U-Boot can be horribly noisy due to device
> >  tree warnings.  I assume Yamada-san ran in to a problem and was
> >  expecting the build to have failed but instead was chasing down a
> >  run-time debug until finding this.
> > >>>
> > >>>
> > >>> I did not run into a problem.
> > >>>
> > >>> When I was replacing  with some lighter headers,
> > >>> I missed some warnings ( but I noticed them after all).
> > >>>
> > >>> In Linux, if I miss to include a header, it fails to build.
> > >>> In U-Boot, it does not.
> > >>>
> > >>> Personally, I like to align with Linux policy,
> > >>> but if you are not comfortable with this patch,
> > >>> please feel free to ignore it.
> > >>
> > >> I really don't understand the point of warnings if we are just going
> > >> to turn them into errors.
> > >>
> > >> How about adding an option to tell U-Boot to use -Werror, etc.? Then
> > >> those that what it can enable it.
> > >
> > >
> > > OK.  We can do it with
> > >
> > >
> > > make KCFLAGS=-Werror
> >
> > I've had a few of these failures due to implicit fn declaration, so I'd
> > be all for adding the error by default. And if things error out and you
> > are too lazy to spot the error, use make -k ; make -k and the error will
> > be right there at the end.
> 
> So are you ignoring the warning? Is it because there are so many
> device-tree warnings? Should we figure out how to silence those
> things?

I keep wondering how many device tree warnings would get fixed with a
re-sync of Linux.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 11/22] common: Drop init.h from common header

[Simon Glass]

Hi Masahiro,

On Mon, 11 May 2020 at 01:05, Masahiro Yamada  wrote:
>
> On Mon, May 11, 2020 at 3:44 PM Masahiro Yamada  wrote:
> >
> > Simon,
> >
> > On Mon, May 11, 2020 at 7:58 AM Simon Glass  wrote:
> > >
> > > Move this uncommon header out of the common header.
> > >
> > > Signed-off-by: Simon Glass 
> >
> >
> > Why are you adding  to
> > arch/arm/mach-uniphier/cpu-info.c,
> > which does not include 
> > in the first place?
> >
> >
> > This seems a wrong conversion.
> >
> > For uniphier, NACK.
>
>
>
> Hmm, are you fixing -Wmissing-prototypes,
> which is displayed with W=1 builds.

I wonder how bad it would be if we enabled that option?

>
> If so, adding  to arch/arm/mach-uniphier/cpu-info.c
> makes sense although it is unclear from commit log.
>
>
> But, I still do not understand why you are adding  to
> arch/arm/mach-uniphier/dram/umc-pxs2.c
>
> It looks fine to me as-is.

Yes it is not needed - the dram_init() is throwing things off.

However given the scale of this series this seems like a small problem.

Regards,
Simon

Re: [PATCH v3 21/22] Use __ASSEMBLY__ as the assembly macros

[Simon Glass]

Hi Masahiro,

On Sun, 10 May 2020 at 22:57, Masahiro Yamada  wrote:
>
> On Mon, May 11, 2020 at 2:43 AM Simon Glass  wrote:
> >
> > Some places use __ASSEMBLER__ instead which does not work since the
> > Makefile does not define it. Fix them.
> >
> > Signed-off-by: Simon Glass 
>
>
> I think we decided to not do this in v2, didn't we?
>
> http://patchwork.ozlabs.org/project/uboot/patch/20200409201506.133129-6-...@chromium.org/

I must have misunderstood that thread. I think we should be consistent
in U-Boot as to which one we use. It makes it much harder to check
things when there are multiple options.

Regards,
Simon



>
>
> > ---
> >
> > Changes in v3: None
> > Changes in v2:
> > - Add new patch to fix occurances of __ASSEMBLER__
> >
> >  arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 2 +-
> >  arch/arm/include/asm/arch-mx27/regs-rtc.h  | 2 +-
> >  arch/arm/include/asm/arch-mx5/imx-regs.h   | 2 +-
> >  arch/arm/include/asm/arch-mx6/imx-regs.h   | 2 +-
> >  arch/arm/include/asm/arch-mx7/imx-regs.h   | 2 +-
> >  arch/arm/include/asm/arch-s32v234/imx-regs.h   | 2 +-
> >  arch/arm/include/asm/arch-vf610/imx-regs.h | 2 +-
> >  arch/arm/mach-socfpga/include/mach/clock_manager.h | 2 +-
> >  arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h | 4 ++--
> >  arch/arm/mach-socfpga/include/mach/clock_manager_gen5.h| 4 ++--
> >  arch/arm/mach-socfpga/include/mach/sdram_arria10.h | 2 +-
> >  arch/arm/mach-stm32mp/include/mach/stm32.h | 2 +-
> >  arch/x86/include/asm/mtrr.h| 2 +-
> >  arch/x86/include/asm/sipi.h| 4 ++--
> >  include/atf_common.h   | 2 +-
> >  include/elf.h  | 4 ++--
> >  16 files changed, 20 insertions(+), 20 deletions(-)
> >

Re: Calling i2c set speed twice for i2c_mux_bus

[Simon Glass]

Hi,

On Mon, 11 May 2020 at 08:37, Heiko Schocher  wrote:
>
> Hello Michal,
>
> Am 11.05.2020 um 15:36 schrieb Michal Simek:
> > On 07. 05. 20 12:02, Heiko Schocher wrote:
> >> Hello Michal,
> >>
> >> Am 07.05.2020 um 10:18 schrieb Michal Simek:
> >>> On 06. 05. 20 16:47, Simon Glass wrote:
>  Hi Michal,
> 
>  On Tue, 5 May 2020 at 21:43, Simon Glass  wrote:
> >
> > Hi Michal,
> >
> > On Tue, 5 May 2020 at 02:26, Michal Simek 
> > wrote:
> >>
> >> On 15. 04. 20 8:40, Michal Simek wrote:
> >>> On 10. 04. 20 10:49, Heiko Schocher wrote:
>  Hello Michal,
> 
>  Am 10.04.2020 um 08:46 schrieb Michal Simek:
> > Hi Heiko,
> >
> > On 10. 04. 20 7:11, Heiko Schocher wrote:
> >> Hello Michal,
> >>
> >> Am 09.04.2020 um 16:03 schrieb Michal Simek:
> >>> Hi Heiko and Simon,
> >>>
> >>> I have find out one bug in i2c class. I am using zcu104 revC
> >>> board
> >>> which
> >>> has dts in mainline where i2c1 has i2c mux with some channels.
> >>> In DT clock-frequency = <40>; is specified and it is read in
> >>> i2c_post_probe(). But i2c_mux_bus_drv is also UCLASS_I2C which
> >>> means
> >>> that post probe is called for it too. And because clock-frequency
> >>> property is not there default 100k is used.
> >>>
> >>> I think that is bug and should be fixed.
> >>> Heiko: Are you aware about this issue?
> >>
> >> No :-(
> >>
> >> The question is, is this a bug?
> >
> > I have never seen clock-frequency property in i2c mux bus node.
> > Also I
> > have looked at linux dt binding docs and nothing like that is
> > specified
> > there. From quick look also pca954x driver is not reading it.
> 
>  Indeed.
> 
> >> Should a i2c bus behind a mux not be able to set his own speed?
> >
> > Not sure if that make sense but Linux will likely ignore it. I
> > am not
> > saying it doesn't make sense but I haven't seen this feature.
> 
>  Ok.
> 
> >> But may as a feature (or bugfix?) if "clock-frequency" is not
> >> there,
> >> use the speed of the parent bus...?
> >
> > I was thinking about this too.
> > just c quick implementation would look like this. Because it is
> > i2c->i2c_mux->i2c. But maybe there is a better way how to do it.
> >
> > diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
> > index 2aa3efe8aaa0..982c467deba3 100644
> > --- a/drivers/i2c/i2c-uclass.c
> > +++ b/drivers/i2c/i2c-uclass.c
> > @@ -640,9 +640,21 @@ static int i2c_post_probe(struct udevice *dev)
> > {
> > #if CONFIG_IS_ENABLED(OF_CONTROL) &&
> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> >struct dm_i2c_bus *i2c = dev_get_uclass_priv(dev);
> > +   int parent_speed = I2C_SPEED_STANDARD_RATE;
> > +
> > +   if (dev->parent &&
> > +   device_get_uclass_id(dev->parent) == UCLASS_I2C_MUX &&
> > +   dev->parent->parent &&
> > +   device_get_uclass_id(dev->parent->parent) ==
> > UCLASS_I2C) {
> > +   struct dm_i2c_bus *i2c_parent;
> > +
> > +   i2c_parent =
> > dev_get_uclass_priv(dev->parent->parent);
> > +   parent_speed = i2c_parent->speed_hz;
> > +   /* Not sure if make sense to check that
> > parent_speed is
> > not 0 */
> 
>  I think this check is not needed.
> 
> > +   }
> >
> >i2c->speed_hz = dev_read_u32_default(dev,
> > "clock-frequency",
> > -
> > I2C_SPEED_STANDARD_RATE);
> > +parent_speed);
> 
>  Wow, a big if ... may this is clearer (not compile tested)?
> 
>  udevice *parent = dev_get_parent(dev);
> 
>  if (parent && device_get_uclass_id(parent) == UCLASS_I2C_MUX) {
>    udevice *parent2 = dev_get_parent(parent);
>    if (parent2 && device_get_uclass_id(parent2) == UCLASS_I2C) {
>    struct dm_i2c_bus *i2cp = dev_get_uclass_priv(parent2);
> 
>    parent_speed = i2cp->speed_hz;
>    }
>  }
> 
>  but Simon has a deeper DM knowledge, may there is a better approach.
> >>>
> >>> Simon: any comment on this one?
> >>
> >> Simon: Can you please comment this?
> >>
> >
> > OK will take a look.
> 
>  I wonder if i2c-mux-uclass.c should define a new uclass for muxed I2C
>  buses, something like 

Re: [PATCH] kbuild: add -Werror=implicit-function-declaration

[Simon Glass]

Hi,

On Sun, 10 May 2020 at 20:14, Marek Vasut  wrote:
>
> On 5/11/20 3:59 AM, Masahiro Yamada wrote:
> > Hi Simon,
> >
> > On Mon, May 11, 2020 at 5:37 AM Simon Glass  wrote:
> >>
> >> Hi Masahiro,
> >>
> >> On Sat, 9 May 2020 at 05:00, Masahiro Yamada  wrote:
> >>>
> >>> On Sat, May 9, 2020 at 3:16 AM Tom Rini  wrote:
> 
>  On Thu, May 07, 2020 at 09:16:40PM -0600, Simon Glass wrote:
> > Hi Masahiro,
> >
> > On Thu, 7 May 2020 at 19:54, Masahiro Yamada  
> > wrote:
> >>
> >> On Fri, May 8, 2020 at 10:39 AM Simon Glass  wrote:
> >>>
> >>> Hi Masahiro,
> >>>
> >>> On Thu, 7 May 2020 at 06:21, Masahiro Yamada
> >>>  wrote:
> 
>  Add -Werror=implicit-function-declaration as Linux does.
> 
>  If you do not check the prototype, it may go wrong run-time.
>  It is better to break the build, and require to include correct
>  headers.
> 
>  Signed-off-by: Masahiro Yamada 
>  ---
> 
>   Makefile | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> NAK
> >>>
> >>> We already get a warning in this situation. This makes it painful for
> >>> development since things that should be warnings end up being errors.
> >>> So your build fails when really it should work well enough to do a
> >>> test run with your new code. I don't think it has any benefit on code
> >>> quality since we already detect warnings in gitlab, etc.
> >>>
> >>> U-Boot is set up so that warnings are reported and are easy to spot if
> >>> you use 'make -s' (i.e. not buried in the output).
> >>>
> >>> Regards,
> >>> Simon
> >>
> >>
> >>
> >> Linux added this flag in 2007.
> >>
> >> The intention seems to break the build earlier
> >> when a non-existing function is used.
> >>
> >> I have not seen compliant about this flag in Linux.
> >> What does it make different for U-Boot ?
> >
> > Well that commit message is quite misleading. The author is presumably
> > ignoring the warnings that come out in the compile phase. For me they
> > come up loud and clear. I don't know why it takes half an hour to get
> > to the link stage. My average incremental build time is under 4
> > seconds including the link.
> >
> > Finally, the warning does not tell you anything about whether the
> > function doesn't exist. It just tells you you have left out a header
> > file.
> >
> > I know how much of a pain this is, because coreboot does this. It does
> > it partly because there is so much build output that the warnings are
> > invisible unless they actually halt the build. Even then you have to
> > search for what went wrong.
> 
>  I'm not immediately sure of the right answer here.  Part of the problem
>  is that even with 'make -s' U-Boot can be horribly noisy due to device
>  tree warnings.  I assume Yamada-san ran in to a problem and was
>  expecting the build to have failed but instead was chasing down a
>  run-time debug until finding this.
> >>>
> >>>
> >>> I did not run into a problem.
> >>>
> >>> When I was replacing  with some lighter headers,
> >>> I missed some warnings ( but I noticed them after all).
> >>>
> >>> In Linux, if I miss to include a header, it fails to build.
> >>> In U-Boot, it does not.
> >>>
> >>> Personally, I like to align with Linux policy,
> >>> but if you are not comfortable with this patch,
> >>> please feel free to ignore it.
> >>
> >> I really don't understand the point of warnings if we are just going
> >> to turn them into errors.
> >>
> >> How about adding an option to tell U-Boot to use -Werror, etc.? Then
> >> those that what it can enable it.
> >
> >
> > OK.  We can do it with
> >
> >
> > make KCFLAGS=-Werror
>
> I've had a few of these failures due to implicit fn declaration, so I'd
> be all for adding the error by default. And if things error out and you
> are too lazy to spot the error, use make -k ; make -k and the error will
> be right there at the end.

So are you ignoring the warning? Is it because there are so many
device-tree warnings? Should we figure out how to silence those
things?

>
> So I'm fine with this patch as-is.

Perhaps you can use Masahiro's option above?

Regards,
Simon

Re: [PATCH v2 2/4] regmap: Allow providing read/write callbacks through struct regmap_config

[Simon Glass]

Hi Pratyush,

On Mon, 11 May 2020 at 06:00, Yadav, Pratyush  wrote:
>
> Hi Simon,
>
> On 07/05/20 07:36PM, Simon Glass wrote:
> > >
> > > If there a way to use DM w/o DT changes, we can definitely explore that...
> >
> > You can certainly do that. Just device_bind() a driver that implements
> > your access mechanism. So long as the driver uses the same access
> > mechanism no matter what hardware it is running on, that makes sense.
> > But from what you say above, that might not be true, so you would end
> > up setting the platform data of the regmap driver from its parent.
> > That's not terrible, but not ideal.
> >
> > Given the simple access you need above, I think you could just add
> > that as another option in the regmap, perhaps turning endianness into
> > some flags?
>
> I tried doing it without custom regmap accessors. The rough patch below
> is what I came up with. Does it look any better than custom accessors?

This looks OK. Should use a local variable instead of (*mapp)->
though. Also please add docs.


- SImon

>
> PS: I can probably play around with regmap ranges instead of using
> 'base_offset', but it gets the job done minimally so I think it is good
> enough for a proof-of-concept.
>
>  -- 8< --
> Subject: [RFC PATCH] regmap: allow specifying base offset and register shift 
> and
>  access size
>
> To accommodate more complex access patterns that are needed in the
> Cadence Sierra PHY driver (which will be added as a follow-up),
> introduce 'base_offset' and 'reg_offset_shift', two values that can be
> used to adjust the final regmap read/write address.
>
> 'base_offset' is an extra offset on the regmap base discovered from the
> device tree. This is useful when some regmaps of a device need to access
> memory at one offset, and some at another.
>
> 'reg_offset_shift' will shift the register offset left before access.
>
> 'size' can be used to specify the width of reads (1/2/4/8 bytes). If 0,
> defaults to 4 bytes to maintain backward compatibility.
>
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/core/regmap.c | 16 
>  include/regmap.h  | 27 ++-
>  2 files changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index 41293e5af0..9bce719b45 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -38,6 +38,7 @@ static struct regmap *regmap_alloc(int count)
> map = malloc(sizeof(*map) + sizeof(map->ranges[0]) * count);
> if (!map)
> return NULL;
> +   memset(map, 0, sizeof(*map));
> map->range_count = count;
>
> return map;
> @@ -258,6 +259,10 @@ struct regmap *devm_regmap_init(struct udevice *dev,
> if (rc)
> return ERR_PTR(rc);
>
> +   (*mapp)->base_offset = config->base_offset;
> +   (*mapp)->reg_offset_shift = config->reg_offset_shift;
> +   (*mapp)->size = config->size;
> +
> devres_add(dev, mapp);
> return *mapp;
>  }
> @@ -343,7 +348,9 @@ int regmap_raw_read_range(struct regmap *map, uint 
> range_num, uint offset,
> }
> range = >ranges[range_num];
>
> -   ptr = map_physmem(range->start + offset, val_len, MAP_NOCACHE);
> +   offset <<= map->reg_offset_shift;
> +
> +   ptr = map_physmem(range->start + map->base_offset + offset, val_len, 
> MAP_NOCACHE);
>
> if (offset + val_len > range->size) {
> debug("%s: offset/size combination invalid\n", __func__);
> @@ -380,7 +387,7 @@ int regmap_raw_read(struct regmap *map, uint offset, void 
> *valp, size_t val_len)
>
>  int regmap_read(struct regmap *map, uint offset, uint *valp)
>  {
> -   return regmap_raw_read(map, offset, valp, REGMAP_SIZE_32);
> +   return regmap_raw_read(map, offset, valp, map->size ? map->size : 
> REGMAP_SIZE_32);
>  }
>
>  static inline void __write_8(u8 *addr, const u8 *val,
> @@ -452,7 +459,8 @@ int regmap_raw_write_range(struct regmap *map, uint 
> range_num, uint offset,
> }
> range = >ranges[range_num];
>
> -   ptr = map_physmem(range->start + offset, val_len, MAP_NOCACHE);
> +   offset <<= map->reg_offset_shift;
> +   ptr = map_physmem(range->start + map->base_offset + offset, val_len, 
> MAP_NOCACHE);
>
> if (offset + val_len > range->size) {
> debug("%s: offset/size combination invalid\n", __func__);
> @@ -490,7 +498,7 @@ int regmap_raw_write(struct regmap *map, uint offset, 
> const void *val,
>
>  int regmap_write(struct regmap *map, uint offset, uint val)
>  {
> -   return regmap_raw_write(map, offset, , REGMAP_SIZE_32);
> +   return regmap_raw_write(map, offset, , map->size ? map->size : 
> REGMAP_SIZE_32);
>  }
>
>  int regmap_update_bits(struct regmap *map, uint offset, uint mask, uint val)
> diff --git a/include/regmap.h b/include/regmap.h
> index 2edbf9359a..4adb04f7e3 100644
> --- a/include/regmap.h
> +++ b/include/regmap.h
> @@ -74,16 +74,41 @@ struct regmap_range {

Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)

[Matthias Brugger]

On 11/05/2020 21:44, Tom Rini wrote:
> On Fri, May 08, 2020 at 11:26:36PM +0200, Matthias Brugger wrote:
>> Adding Tom as he is the arm maintainer.
>>
>> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>>> From: Marek Szyprowski 
>>>
>>> Create a non-cacheable mapping for the 0x6 physical memory region,
>>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>>> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
>>> 32bit mode, this region is mapped at 0xff80 CPU virtual address.
>>>
>>> Signed-off-by: Marek Szyprowski 
>>> Signed-off-by: Sylwester Nawrocki 
>>> ---
>>> Changes since v1:
>>>  - none.
>>> ---
>>>  arch/arm/mach-bcm283x/Kconfig |  1 +
>>>  arch/arm/mach-bcm283x/include/mach/base.h |  7 +
>>>  arch/arm/mach-bcm283x/init.c  | 52 
>>> +++
>>>  3 files changed, 60 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
>>> index 00419bf..bcb7f1d 100644
>>> --- a/arch/arm/mach-bcm283x/Kconfig
>>> +++ b/arch/arm/mach-bcm283x/Kconfig
>>> @@ -36,6 +36,7 @@ config BCM2711_32B
>>> select BCM2711
>>> select ARMV7_LPAE
>>> select CPU_V7A
>>> +   select PHYS_64BIT
>>>  
>>>  config BCM2711_64B
>>> bool "Broadcom BCM2711 SoC 64-bit support"
>>> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h 
>>> b/arch/arm/mach-bcm283x/include/mach/base.h
>>> index c4ae398..1d10dc9 100644
>>> --- a/arch/arm/mach-bcm283x/include/mach/base.h
>>> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
>>> @@ -6,6 +6,13 @@
>>>  #ifndef _BCM283x_BASE_H_
>>>  #define _BCM283x_BASE_H_
>>>  
>>> +#include 
>>> +
>>>  extern unsigned long rpi_bcm283x_base;
>>>  
>>> +#ifdef CONFIG_ARMV7_LPAE
>>> +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
>>> +#define phys_to_virt(x) rpi4_phys_to_virt(x)
>>> +#endif
>>> +
>>>  #endif
>>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>>> index 6a748da..5d0d160 100644
>>> --- a/arch/arm/mach-bcm283x/init.c
>>> +++ b/arch/arm/mach-bcm283x/init.c
>>> @@ -145,6 +145,58 @@ int mach_cpu_init(void)
>>>  }
>>>  
>>>  #ifdef CONFIG_ARMV7_LPAE
>>> +
>>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT   0xff80UL
>>> +
>>> +void *rpi4_phys_to_virt(phys_addr_t paddr)
>>> +{
>>> +   if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
>>> +   paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
>>> +   BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
>>> +   return (void *)(unsigned long)paddr;
>>
>> I think for this cases we have addrmap_phys_to_virt() which up to now is only
>> used by powerpc.
>>
>>> +}
>>> +
>>> +static void set_section_phys(unsigned int section, phys_addr_t phys,
>>> +enum dcache_option option)
>>> +{
>>> +   u64 *page_table = (u64 *)gd->arch.tlb_addr;
>>> +   /* Need to set the access flag to not fault */
>>> +   u64 value = TTB_SECT_AP | TTB_SECT_AF;
>>> +
>>> +   /* Add the page offset */
>>> +   value |= (phys);
>>> +
>>> +   /* Add caching bits */
>>> +   value |= option;
>>> +
>>> +   /* Set PTE */
>>> +   page_table[section] = value;
>>> +}
>>> +
>>> +static void rpi4_create_pcie_xhci_mapping(void)
>>> +{
>>> +   unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
>>> +   phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
>>> +   unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
>>> +
>>> +   while (size) {
>>> +   set_section_phys(sect, phys_addr, DCACHE_OFF);
>>> +   sect++;
>>> +   phys_addr += MMU_SECTION_SIZE;
>>> +   size -= MMU_SECTION_SIZE;
>>> +   }
>>> +}
>>
>> I wonder if we can't do all this in the pcie driver probe function. Maybe we 
>> can
>> create a new function like mmu_set_region_dcache_behaviour_phys which allows 
>> us
>> to update a mapping that's not 1:1.
>>
>> Tom what do you think?
> 
> I think a harder look at how PowerPC handled this situation is in order,
> and then following / extending that path is in order.
> 

Thanks Tom for the feedback.
Sylwester, I propose to split the series in two. One for adding the driver to
64-bit U-Boot and another one to add support for rpi_4_32b_defconfig. This way
we could get the driver merged for 2020.07 for sure, while 32-bit parts could
take more cycles to be ready. What do you think?

Regards,
Matthias

Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)

[Tom Rini]

On Fri, May 08, 2020 at 11:26:36PM +0200, Matthias Brugger wrote:
> Adding Tom as he is the arm maintainer.
> 
> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
> > From: Marek Szyprowski 
> > 
> > Create a non-cacheable mapping for the 0x6 physical memory region,
> > where MMIO registers for the PCIe XHCI controller are instantiated by the
> > PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
> > 32bit mode, this region is mapped at 0xff80 CPU virtual address.
> > 
> > Signed-off-by: Marek Szyprowski 
> > Signed-off-by: Sylwester Nawrocki 
> > ---
> > Changes since v1:
> >  - none.
> > ---
> >  arch/arm/mach-bcm283x/Kconfig |  1 +
> >  arch/arm/mach-bcm283x/include/mach/base.h |  7 +
> >  arch/arm/mach-bcm283x/init.c  | 52 
> > +++
> >  3 files changed, 60 insertions(+)
> > 
> > diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
> > index 00419bf..bcb7f1d 100644
> > --- a/arch/arm/mach-bcm283x/Kconfig
> > +++ b/arch/arm/mach-bcm283x/Kconfig
> > @@ -36,6 +36,7 @@ config BCM2711_32B
> > select BCM2711
> > select ARMV7_LPAE
> > select CPU_V7A
> > +   select PHYS_64BIT
> >  
> >  config BCM2711_64B
> > bool "Broadcom BCM2711 SoC 64-bit support"
> > diff --git a/arch/arm/mach-bcm283x/include/mach/base.h 
> > b/arch/arm/mach-bcm283x/include/mach/base.h
> > index c4ae398..1d10dc9 100644
> > --- a/arch/arm/mach-bcm283x/include/mach/base.h
> > +++ b/arch/arm/mach-bcm283x/include/mach/base.h
> > @@ -6,6 +6,13 @@
> >  #ifndef _BCM283x_BASE_H_
> >  #define _BCM283x_BASE_H_
> >  
> > +#include 
> > +
> >  extern unsigned long rpi_bcm283x_base;
> >  
> > +#ifdef CONFIG_ARMV7_LPAE
> > +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
> > +#define phys_to_virt(x) rpi4_phys_to_virt(x)
> > +#endif
> > +
> >  #endif
> > diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> > index 6a748da..5d0d160 100644
> > --- a/arch/arm/mach-bcm283x/init.c
> > +++ b/arch/arm/mach-bcm283x/init.c
> > @@ -145,6 +145,58 @@ int mach_cpu_init(void)
> >  }
> >  
> >  #ifdef CONFIG_ARMV7_LPAE
> > +
> > +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT   0xff80UL
> > +
> > +void *rpi4_phys_to_virt(phys_addr_t paddr)
> > +{
> > +   if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
> > +   paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
> > +   BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
> > +   return (void *)(unsigned long)paddr;
> 
> I think for this cases we have addrmap_phys_to_virt() which up to now is only
> used by powerpc.
> 
> > +}
> > +
> > +static void set_section_phys(unsigned int section, phys_addr_t phys,
> > +enum dcache_option option)
> > +{
> > +   u64 *page_table = (u64 *)gd->arch.tlb_addr;
> > +   /* Need to set the access flag to not fault */
> > +   u64 value = TTB_SECT_AP | TTB_SECT_AF;
> > +
> > +   /* Add the page offset */
> > +   value |= (phys);
> > +
> > +   /* Add caching bits */
> > +   value |= option;
> > +
> > +   /* Set PTE */
> > +   page_table[section] = value;
> > +}
> > +
> > +static void rpi4_create_pcie_xhci_mapping(void)
> > +{
> > +   unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
> > +   phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
> > +   unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
> > +
> > +   while (size) {
> > +   set_section_phys(sect, phys_addr, DCACHE_OFF);
> > +   sect++;
> > +   phys_addr += MMU_SECTION_SIZE;
> > +   size -= MMU_SECTION_SIZE;
> > +   }
> > +}
> 
> I wonder if we can't do all this in the pcie driver probe function. Maybe we 
> can
> create a new function like mmu_set_region_dcache_behaviour_phys which allows 
> us
> to update a mapping that's not 1:1.
> 
> Tom what do you think?

I think a harder look at how PowerPC handled this situation is in order,
and then following / extending that path is in order.

-- 
Tom


signature.asc
Description: PGP signature

[RFC] am65x_evm_r5: Disable serial output

[Tom Rini]

Given limitations on the current implementation of our test framework,
having both am65x_evm_r5 and am65x_evm_a53 have serial output on the
same port confuses the tests.  If we disable serial output in r5 and
disable the SPL tests as well, we can run the rest of the testsuite on
am65x_evm_a53.

Cc: Lokesh Vutla 
Signed-off-by: Tom Rini 
---
For practical reasons this depends on
http://patchwork.ozlabs.org/project/uboot/patch/20200507230810.21476-1-sam...@sholland.org/
to build.  Since this also removes YMODEM support, I assume it breaks a
functional use case, so I'm not sure this is best.  Stephen Warren
suggested a rework to the pytest framework that I haven't had a chance
to try and do yet.
---
 configs/am65x_evm_r5_defconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index 4fc199e80911..2c61bee4b8bc 100644
--- a/configs/am65x_evm_r5_defconfig
+++ b/configs/am65x_evm_r5_defconfig
@@ -11,7 +11,6 @@ CONFIG_ENV_SIZE=0x2
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x8
 CONFIG_DM_GPIO=y
 CONFIG_SPL_MMC_SUPPORT=y
-CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
 CONFIG_SPL_STACK_R_ADDR=0x8200
 CONFIG_NR_DRAM_BANKS=2
@@ -41,7 +40,6 @@ CONFIG_SPL_REMOTEPROC=y
 # CONFIG_SPL_SPI_FLASH_TINY is not set
 CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
-CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_ASKENV=y
-- 
2.17.1

Re: [PATCH 1/5 v2] efi_loader: Add headers for EDK2 StandAloneMM communication

[Heinrich Schuchardt]

On 5/11/20 8:13 PM, Ilias Apalodimas wrote:
> From: Sughosh Ganu 
>
> In Arm devices OP-TEE has the ability to run StandAloneMM (from EDK2)
> in a separate partition and handle UEFI variables.
> A following patch introduces this functionality.
>
> Add the headers needed for OP-TEE <--> StandAloneMM communication
>
> Signed-off-by: Sughosh Ganu 
> Signed-off-by: Ilias Apalodimas 
> ---
>  include/mm_communication.h | 207 +
>  1 file changed, 207 insertions(+)
>  create mode 100644 include/mm_communication.h
>
> diff --git a/include/mm_communication.h b/include/mm_communication.h
> new file mode 100644
> index ..b9bfbe4cf0a1
> --- /dev/null
> +++ b/include/mm_communication.h
> @@ -0,0 +1,207 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + *  Headers for EFI variable service via StandAloneMM, EDK2 application 
> running
> + *  in OP-TEE
> + *
> + *  Copyright (c) 2017, Intel Corporation. All rights reserved.
> + *  Copyright (C) 2020 Linaro Ltd. 
> + *  Copyright (C) 2020 Linaro Ltd. 
> + */
> +
> +#ifndef _MM_VARIABLE_H_
> +#define _MM_VARIABLE_H_
> +
> +#include 
> +
> +/*
> + * Interface to the pseudo TA, which provides a communication channel with

U-Boot developers might not know the OP-TEE terms. So I would tend to
avoid abbreviations at least in the first reference.

%s/pseudo TA/Pseudo Trusted Application/

> + * the StandaloneMM Secure Partition (StMM) running at S-EL0

What does MM stand for? Management Mode?

> + */
> +
> +#define PTA_STMM_CMDID_COMMUNICATE 0
> +
> +/* OP-TEE is using big endian GUIDs while UEFI uses little endian ones */
> +#define PTA_STMM_UUID { 0xed32d533, 0x99e6, 0x4209, {\
> + 0x9c, 0xc0, 0x2d, 0x72, 0xcd, 0xd9, 0x98, 0xa7 } }
> +
> +#define EFI_MM_VARIABLE_GUID \
> + EFI_GUID(0xed32d533, 0x99e6, 0x4209, \
> +  0x9c, 0xc0, 0x2d, 0x72, 0xcd, 0xd9, 0x98, 0xa7)
> +
> +/* Defined in EDK2 MdePkg/Include/Protocol/MmCommunication.h */
> +
> +/**
> + * struct efi_mm_communicate_header - Header used for SMM variable 
> communication
> +
> + * @header_guid:  header use for disambiguation of content
> + * @message_len:  length of the message. Does not include the size of the
> + *header
> + * @data: payload of the message
> + *
> + * Defined in EDK2 as EFI_MM_COMMUNICATE_HEADER
> + * To avoid confusion in interpreting frames, the communication buffer should
> + * always begin with efi_mm_communicate_header

%s/efi_mm_communicate_header/efi_mm_communicate_header./

> + */
> +struct efi_mm_communicate_header {
> + efi_guid_t header_guid;
> + size_t message_len;
> + u8 data[];
> +};
> +
> +#define MM_COMMUNICATE_HEADER_SIZE \
> + (sizeof(struct efi_mm_communicate_header))
> +
> +/* Defined in EDK2 ArmPkg/Include/IndustryStandard/ArmStdSmc.h */
> +
> +/* MM return error codes */
> +#define ARM_SMC_MM_RET_SUCCESS  0
> +#define ARM_SMC_MM_RET_NOT_SUPPORTED   -1
> +#define ARM_SMC_MM_RET_INVALID_PARAMS  -2
> +#define ARM_SMC_MM_RET_DENIED  -3
> +#define ARM_SMC_MM_RET_NO_MEMORY   -4
> +
> +/* Defined in EDK2 MdeModulePkg/Include/Guid/SmmVariableCommon.h */
> +
> +#define SMM_VARIABLE_FUNCTION_GET_VARIABLE  1
> +/*
> + * The payload for this function is
> + * SMM_VARIABLE_COMMUNICATE_GET_NEXT_VARIABLE_NAME.
> + */
> +#define SMM_VARIABLE_FUNCTION_GET_NEXT_VARIABLE_NAME  2
> +/*
> + * The payload for this function is SMM_VARIABLE_COMMUNICATE_ACCESS_VARIABLE.
> + */
> +#define SMM_VARIABLE_FUNCTION_SET_VARIABLE  3
> +/*
> + * The payload for this function is
> + * SMM_VARIABLE_COMMUNICATE_QUERY_VARIABLE_INFO.
> + */
> +#define SMM_VARIABLE_FUNCTION_QUERY_VARIABLE_INFO  4
> +/*
> + * It is a notify event, no extra payload for this function.
> + */
> +#define SMM_VARIABLE_FUNCTION_READY_TO_BOOT  5
> +/*
> + * It is a notify event, no extra payload for this function.
> + */
> +#define SMM_VARIABLE_FUNCTION_EXIT_BOOT_SERVICE  6
> +/*
> + * The payload for this function is VARIABLE_INFO_ENTRY.
> + * The GUID in EFI_SMM_COMMUNICATE_HEADER is gEfiSmmVariableProtocolGuid.
> + */
> +#define SMM_VARIABLE_FUNCTION_GET_STATISTICS  7
> +/*
> + * The payload for this function is SMM_VARIABLE_COMMUNICATE_LOCK_VARIABLE
> + */
> +#define SMM_VARIABLE_FUNCTION_LOCK_VARIABLE   8
> +
> +#define SMM_VARIABLE_FUNCTION_VAR_CHECK_VARIABLE_PROPERTY_SET  9
> +
> +#define SMM_VARIABLE_FUNCTION_VAR_CHECK_VARIABLE_PROPERTY_GET  10
> +
> +#define SMM_VARIABLE_FUNCTION_GET_PAYLOAD_SIZE  11
> +/*
> + * The payload for this function is
> + * SMM_VARIABLE_COMMUNICATE_RUNTIME_VARIABLE_CACHE_CONTEXT
> + */
> +#define SMM_VARIABLE_FUNCTION_INIT_RUNTIME_VARIABLE_CACHE_CONTEXT 12
> +
> +#define SMM_VARIABLE_FUNCTION_SYNC_RUNTIME_CACHE  13
> +/*
> + * The payload for this function is
> + * SMM_VARIABLE_COMMUNICATE_GET_RUNTIME_CACHE_INFO
> + */
> +#define SMM_VARIABLE_FUNCTION_GET_RUNTIME_CACHE_INFO  14
> +
> +/**
> + * struct 

Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data

[Tom Rini]

On Sun, May 10, 2020 at 09:24:19PM +0200, Marek Vasut wrote:
> On 5/8/20 9:21 PM, Tom Rini wrote:
> > On Fri, May 08, 2020 at 09:00:02PM +0200, Marek Vasut wrote:
> >> On 5/8/20 8:47 PM, Tom Rini wrote:
> >>> On Fri, May 08, 2020 at 03:37:01AM +0200, Marek Vasut wrote:
>  On 5/7/20 10:46 PM, Samuel Holland wrote:
> > On 5/6/20 12:02 PM, trini at konsulko.com (Tom Rini) wrote:
> >> I'm not sure that it is.  Can we easily/safely memmove the data to 
> >> be
> >> aligned?  Is that really a better option in this case than ensuring
> >> alignment within the file?
> >
> > Can't we use the new mkimage -B option to enforce the alignment IFF 
> > and
> > only IFF it is required ? 
> 
>  Perhaps.  But..
> 
> > Then we can enforce it separately for 32bit
> > and 64bit platforms to 4 and 8 bytes respectively even.
> 
>  It's 8 bytes for both.  It's possible that Linux doesn't hard fail if
>  you only do 4 byte alignment but the documented requirement is 8, for
>  arm32.
> >>>
> >>> With Linux you usually need to move the kernel anyway, no ? It's 2 MiB
> >>> for arm64 for example.
> >>
> >> For arm64 you have to move it to where text_offset says it needs to be.
> >> For arm32 the common (always, practically?) case is you're firing off
> >> the zImage which does what's needed.  But..
> >>
> >>> And what you usually parse in-place would be the DT then.
> >>
> >> Yes, the practical case is that it's a DT and that needs 8 byte
> >> alignment.  And we should just get back to aligning that correctly.
> >> Going back to the v1 thread, it turns out the answer to "why do we even
> >> have this padding?" is "we need the DT to be aligned".
> >
> > This change broke SPL booting for me on MACH_SUN50I as well. One thing 
> > that I
> > haven't seen brought up yet is that SPL FIT code assumes exactly a 
> > 4-byte
> > alignment of external data after the FIT. In spl_load_simple_fit():
> >
> >  /*
> >   * For FIT with external data, figure out where the external images
> >   * start. This is the base for the data-offset properties in each
> >   * image.
> >   */
> >  size = fdt_totalsize(fit);
> >  size = (size + 3) & ~3;
> >  size = board_spl_fit_size_align(size);
> >  base_offset = (size + 3) & ~3;
> 
>  Somehow this doesn't match the 8-byte alignment Tom was suggesting.
>  And that only leads me to believe that we can either make assumptions
>  about alignment, which would very likely fail one way or the other OR we
>  can say that for SPL as a special case, we enforce some alignment.
> >>>
> >>> It's likely the case that on arm32 as there's no natural alignment
> >>> problem, even tho the kernel says 8 byte, 4 byte doesn't lead to failure
> >>> and is rarely if ever given 4-but-not-8-byte-aligned addresses of the
> >>> DTB.  Which is why we should probably move the alignment here to 8 bytes
> >>> instead of 4.
> >>>
>  But that in turn fails for fitImage with embedded data, where the
>  embedded data are always aligned to 4 bytes, because that's how DTC
>  aligns properties.
> >>>
> >>> I think the answer is that the use-case you're talking about is simply
> >>> going to require data to be relocated.
> >>
> >> I have a feeling that no matter how much you try to pad when generating
> >> fitImage from U-Boot, there will always be a case where that will fail.
> >> I listed at least two:
> >> - fitImage with embedded data, 4byte alignment due to DTC
> >> - Older fitImages, 4byte alignment, fails on arm64
> >> - Someone can generate signed fitImage with older mkimage => fail
> >>
> >> So that relocation logic or at least warning or something should be in
> >> there, no matter what.
> > 
> > There's two distinct areas here, and they keep being conflated.
> > 
> > The case of SPL and a FIT image for U-Boot+DTB.  We've always aligned
> > this to 4 bytes and it's worked.  I think if someone looked at the ARM
> > ARM for aarch64 you could reason out that "4-but-not-8-byte aligned
> > pointers are slow but work" as why this wasn't a hard fail on aarch64.
> 
> But we had hard-fault on arm64, see
> [PATCH] lib: rsa: Fix unaligned 64-bit fdt accesses

You're mixing the issues again.  That's an example of "device tree
properties are only 4 byte aligned" and we can't do what we were doing.
I'm not even sure reverting e8c2d25845c7 would have helped in that case.
It's also not the case we're talking about with respect to padding the
start of embedded data.

> > We should adjust our current alignment up to cover that and move on.
> 
> Adjust it to what, 8 bytes ? Or 16 in case RV128 happens ? Or what ?

8 bytes is the defined requirement for everything today that defines a
required _start_ alignment.

> You will fail here either way, since if you build the 

Re: Setting up test.py for a platform with 2 U-Boots?

[Tom Rini]

On Thu, May 07, 2020 at 05:17:15PM -0600, Stephen Warren wrote:
> On 5/7/20 12:48 PM, Tom Rini wrote:
> > Hey,
> > 
> > So I'm trying to enable our test.py framework on am65x_evm_r5 +
> > am65x_evm_a53.  The short version is this platform has an R5 core that
> > sets things up and fires off the A53 cores.  So there's two U-Boots and
> > the console log looks like this (I used SOURCE_DATE_EPOCH to give both
> > binaries the same timestamp):
> ...
> > And that's even with:
> > env__spl_skipped = True
> > in u_boot_boardenv_am65x_evm_a53_na.py for the platform.  Any ideas on what 
> > to
> > do here?  I even tried turning off serial support in the R5 side of things, 
> > but
> > it still failed.  Thanks!
> 
> It's odd that disabling serial support on the R5 didn't fix this; are
> you sure that patch actually prevented the serial output from appearing,
> and the board still booted without issue?

So, I thought I had disabled serial in r5 case but I guess I hadn't
really.  I got it going now with a combination of disabling serial there
AND telling pytest to not do the SPL test.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] tools: ftdgrep: use /* fallthrough */ as needed

[Heinrich Schuchardt]

On 5/11/20 8:40 PM, Tom Rini wrote:
> On Sun, May 10, 2020 at 10:12:07PM +0900, Masahiro Yamada wrote:
>> On Sun, May 10, 2020 at 12:12 AM Heinrich Schuchardt  
>> wrote:
>>>
>>> GCC recognizes /* fallthrough */ if -Wimplicit-fallthrough=3 is enabled.
>>
>> FYI.
>>
>> Linux decided to not use /* fallthrough */ any more
>> because Clang does not recognize it.
>>
>> __attribute__((__fallthrough__)) is supported
>> by both Clang and recent GCC.
In fact Linux has a define:

include/linux/compiler_attributes.h:200:# define fallthrough
__attribute__((__fallthrough__))

And in the code you would use

case foo:
fallthrough;
case bar:

But the Linux kernel still has a lot of lines with

/* fallthrough */

Documentation/process/deprecated.rst:


As there have been a long list of flaws `due to missing "break"
statements `_, we no
longer allow implicit fall-through. In order to identify intentional
fall-through cases, we have adopted a pseudo-keyword macro "fallthrough"
which expands to gcc's extension `__attribute__((__fallthrough__))
`_. (When
the C17/C18  `[[fallthrough]]` syntax is more commonly supported by C
compilers, static analyzers, and IDEs, we can switch to using that
syntax for the macro pseudo-keyword.)


Using the attribute is not standard C and not any better than using the
comment. The real target is the C17 syntax.

>>
>>
>> Linux is now doing treewide conversion
>> from /* fallthrough */ to 'fallthrough;'.
>>
>> See include/linux/compiler_attributes.h in Linux.
>>
>> I do not know if U-Boot wants to align with it.
>> (up to Tom ?)
>
> A re-sync on the compiler headers again and making use of this sounds
> like a good idea, yes.
>

We should enable -Wimplicit-fallthrough like the kernel does. This
defaults to -Wimplicit-fallthrough=3 and is happy with both the comment
as well as with the attribute.

@Tom:
Will you update the compiler headers within this release cycle?
Otherwise we should take the patch as is to get us closer to the
-Wimplicit-fallthrough target.

Best regards

Heinrich

Re: [PATCH v3 7/9] rockchip: dts: rk3328: Sync device tree files from Linux

[Kurt Miller]

On Mon, 2020-04-27 at 14:52 +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai 
> 
> This syncs rk3328 device tree files from the Linux kernel next-20200324.
> The last commit to touch these files is:
> 
> b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")
> 
> Additional changes not yet in the Linux kernel include:
> 
> arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf 
> node
> arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
> arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"
> 
> Changes include:
> 
>   - conversion of raw pin numbers to macros
>   - removal of deprecated RK_FUNC_* macros
>   - update of device tree binding headers
>   - new devices
>   - device tree cleanups
>   - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot
> 
> This includes a re-ordering of the USB device nodes compared to upstream
> Linux, moving the dwc2 OTG controller after the EHCI/OHCI nodes. This is
> currently required as otherwise the dwc2 controller would not be able to
> detect devices in some cases. This may be due to lack of USB PHY support
> in U-boot.

Hi Chen-Yu,

Thank you for syncing rk3328 device tree files. On the rock64 with
v2020.04 one USB 2.0 port was working (the lower one). Building 
master now with this merged, no USB ports are working. No power
appears to be enabled on them and USB devices are not recognized.

Do you have any suggestions for me to try to get them enabled again?

Thanks,
-Kurt

> 
> Signed-off-by: Chen-Yu Tsai 
> ---
> Changes since v2:
>   - Dropped reviewed-by
>   - Moved dwc2 OTG device node after EHCI/OHCI to make dwc2 work again
> Changes since v1:
>   - Added Kever's reviewed-by
> ---
>  arch/arm/dts/rk3328-evb-u-boot.dtsi |5 +
>  arch/arm/dts/rk3328-evb.dts |  196 ++--
>  arch/arm/dts/rk3328-rock64.dts  |  132 ++-
>  arch/arm/dts/rk3328.dtsi| 1414 +--
>  4 files changed, 1166 insertions(+), 581 deletions(-)
> 
> diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
> b/arch/arm/dts/rk3328-evb-u-boot.dtsi
> index 8ba53cf8f44b..4bfa0c2330ba 100644
> --- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
> @@ -40,6 +40,11 @@
>   status = "okay";
>  };
>  
> + {
> + /* Integrated PHY unsupported by U-boot */
> + status = "broken";
> +};
> +
>  _host0_xhci {
>   vbus-supply = <_host_xhci>;
>   status = "okay";
> diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
> index 97bef37cf610..6abc6f4a86cf 100644
> --- a/arch/arm/dts/rk3328-evb.dts
> +++ b/arch/arm/dts/rk3328-evb.dts
> @@ -1,6 +1,6 @@
> -// SPDX-License-Identifier: GPL-2.0+
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>  /*
> - * (C) Copyright 2016 Rockchip Electronics Co., Ltd
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
>   */
>  
>  /dts-v1/;
> @@ -11,24 +11,51 @@
>   compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
>  
>   chosen {
> - stdout-path = 
> + stdout-path = "serial2:150n8";
>   };
>  
> - vcc3v3_sdmmc: sdmmc-pwren {
> + dc_12v: dc-12v {
>   compatible = "regulator-fixed";
> - regulator-name = "vcc3v3";
> - gpio = < 30 GPIO_ACTIVE_LOW>;
> + regulator-name = "dc_12v";
>   regulator-always-on;
>   regulator-boot-on;
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <_enable_h>;
> +
> + /*
> +  * On the module itself this is one of these (depending
> +  * on the actual card populated):
> +  * - SDIO_RESET_L_WL_REG_ON
> +  * - PDN (power down when low)
> +  */
> + reset-gpios = < 18 GPIO_ACTIVE_LOW>;
> + };
> +
> + vcc_sd: sdmmc-regulator {
> + compatible = "regulator-fixed";
> + gpio = < 30 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio>;
> + regulator-name = "vcc_sd";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + vin-supply = <_io>;
>   };
>  
> - vcc5v0_otg: vcc5v0-otg-drv {
> + vcc_sys: vcc-sys {
>   compatible = "regulator-fixed";
> - enable-active-high;
> - regulator-name = "vcc5v0_otg";
> - gpio = < 27 GPIO_ACTIVE_HIGH>;
> + regulator-name = "vcc_sys";
> + regulator-always-on;
> + regulator-boot-on;
>   regulator-min-microvolt = <500>;
>   regulator-max-microvolt = <500>;
> + vin-supply = <_12v>;
>   };
>  
>   vcc_phy: 

Re: [PATCH 3/5 v2] cmd: efidebug: Add support for querying UEFI variable storage

[Heinrich Schuchardt]

On 5/11/20 8:14 PM, Ilias Apalodimas wrote:
> With the previous patches that use OP-TEE and StandAloneMM for UEFI
> variable storage we've added functionality for efi_query_variable_info.
> So let's add the relevant command to efidebug and retrieve information
> about the container used to store UEFI variables
>
> Signed-off-by: Ilias Apalodimas 

For now attributes (e.g. EFI_VARIABLE_NON_VOLATILE) cannot be passed to
the 'efidebug query' sub-command instead a fixed value is used. We can
add attributes on the command line later.

> ---
>  cmd/efidebug.c | 44 +++-
>  1 file changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index d8a76d78a388..a3980772c934 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -1160,6 +1160,44 @@ static int do_efi_test(cmd_tbl_t *cmdtp, int flag,
>   return cp->cmd(cmdtp, flag, argc, argv);
>  }
>
> +/**
> + * do_efi_query_info() - QueryVariableInfo EFI service
> + *
> + * @cmdtp:   Command table
> + * @flag:Command flag
> + * @argc:Number of arguments
> + * @argv:Argument array
> + * Return:   CMD_RET_SUCCESS on success,
> + *   CMD_RET_USAGE or CMD_RET_FAILURE on failure
> + *
> + * Implement efidebug "test" sub-command.
> + */
> +
> +static int do_efi_query_info(cmd_tbl_t *cmdtp, int flag,
> +  int argc, char * const argv[])
> +{
> + efi_status_t ret;
> + u32 attr = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> + EFI_VARIABLE_RUNTIME_ACCESS |
> + EFI_VARIABLE_NON_VOLATILE;

As we do not support variables at runtime currently shouldn't we remove
EFI_VARIABLE_RUNTIME_ACCESS from the default value? I could do that when
merging.

Otherwise:

Reviewed-by: Heinrich Schuchardt 


> + u64 max_variable_storage_size;
> + u64 remain_variable_storage_size;
> + u64 max_variable_size;
> +
> + ret = EFI_CALL(efi_query_variable_info(attr,
> +_variable_storage_size,
> +_variable_storage_size,
> +_variable_size));
> + if (ret != EFI_SUCCESS)
> + return CMD_RET_FAILURE;
> +
> + printf("Max storage size %llu\n", max_variable_storage_size);
> + printf("Remaining storage size %llu\n", remain_variable_storage_size);
> + printf("Max variable size %llu\n", max_variable_size);
> +
> + return CMD_RET_SUCCESS;
> +}
> +
>  static cmd_tbl_t cmd_efidebug_sub[] = {
>   U_BOOT_CMD_MKENT(boot, CONFIG_SYS_MAXARGS, 1, do_efi_boot_opt, "", ""),
>   U_BOOT_CMD_MKENT(devices, CONFIG_SYS_MAXARGS, 1, do_efi_show_devices,
> @@ -1176,6 +1214,8 @@ static cmd_tbl_t cmd_efidebug_sub[] = {
>"", ""),
>   U_BOOT_CMD_MKENT(test, CONFIG_SYS_MAXARGS, 1, do_efi_test,
>"", ""),
> + U_BOOT_CMD_MKENT(query, CONFIG_SYS_MAXARGS, 1, do_efi_query_info,
> +  "", ""),
>  };
>
>  /**
> @@ -1247,7 +1287,9 @@ static char efidebug_help_text[] =
>   "efidebug tables\n"
>   "  - show UEFI configuration tables\n"
>   "efidebug test bootmgr\n"
> - "  - run simple bootmgr for test\n";
> + "  - run simple bootmgr for test\n"
> + "efidebug query\n"
> + "  - show size of UEFI variables store\n";
>  #endif
>
>  U_BOOT_CMD(
>

Re: [PATCH 1/1] tools: ftdgrep: use /* fallthrough */ as needed

[Tom Rini]

On Sun, May 10, 2020 at 10:12:07PM +0900, Masahiro Yamada wrote:
> On Sun, May 10, 2020 at 12:12 AM Heinrich Schuchardt  
> wrote:
> >
> > GCC recognizes /* fallthrough */ if -Wimplicit-fallthrough=3 is enabled.
> 
> FYI.
> 
> Linux decided to not use /* fallthrough */ any more
> because Clang does not recognize it.
> 
> __attribute__((__fallthrough__)) is supported
> by both Clang and recent GCC.
> 
> 
> Linux is now doing treewide conversion
> from /* fallthrough */ to 'fallthrough;'.
> 
> See include/linux/compiler_attributes.h in Linux.
> 
> I do not know if U-Boot wants to align with it.
> (up to Tom ?)

A re-sync on the compiler headers again and making use of this sounds
like a good idea, yes.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 4/5 v2] MAINTAINERS: Add maintainer for EFI variables via OP-TEE

[Heinrich Schuchardt]

On 5/11/20 8:14 PM, Ilias Apalodimas wrote:
> Add myself as maintainer for the OP-TEE related UEFI variable storage
> and add the headers file on the existing EFI list
>
> Signed-off-by: Ilias Apalodimas 

Reviewed-by: Heinrich Schuchardt 

> ---
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ec59ce8b8802..0c38890be09c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -635,6 +635,12 @@ F:   cmd/efidebug.c
>  F:   cmd/nvedit_efi.c
>  F:   tools/file2include.c
>
> +EFI VARIABLES VIA OP-TEE
> +M:   Ilias Apalodimas 
> +S:   Maintained
> +F:   lib/efi_loader/efi_variable_tee.c
> +F:   include/mm_communication.h
> +
>  ENVIRONMENT
>  M:   Joe Hershberger 
>  R:   Wolfgang Denk 
>

Re: [PATCH 5/5 v2] doc: uefi.rst: Add OP-TEE variable storage config options

[Heinrich Schuchardt]

On 5/11/20 8:14 PM, Ilias Apalodimas wrote:
> If OP-TEE is compiled with an EDK2 application running in secure world
> it can process and store UEFI variables in an RPMB.
> Add documentation for the config options enabling this
>
> Signed-off-by: Ilias Apalodimas 

Reviewed-by: Heinrich Schuchardt 

> ---
>  doc/uefi/uefi.rst | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
> index 4fda00d68721..03d6fd0c6aa8 100644
> --- a/doc/uefi/uefi.rst
> +++ b/doc/uefi/uefi.rst
> @@ -188,6 +188,23 @@ on the sandbox
>  cd 
>  pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox
>
> +Using OP-TEE for EFI variables
> +~~
> +
> +Instead of implementing UEFI variable services inside U-Boot they can
> +also be provided in the secure world by a module for OP-TEE[1]. The
> +interface between U-Boot and OP-TEE for variable services is enabled by
> +CONFIG_EFI_MM_COMM_TEE=y.
> +
> +Tianocore EDK II's standalone management mode driver for variables can
> +be linked to OP-TEE for this purpose. This module uses the Replay
> +Protected Memory Block (RPMB) of an eMMC device for persisting
> +non-volatile variables. When calling the variable services via the
> +OP-TEE API U-Boot's OP-TEE supplicant relays calls to the RPMB driver
> +which has to be enabled via CONFIG_SUPPORT_EMMC_RPMB=y.
> +
> +[1] https://optee.readthedocs.io/ - OP-TEE documentation
> +
>  Executing the boot manager
>  ~~
>
>

Re: [GIT PULL] TI changes for v2020.07-rc2

[Tom Rini]

On Mon, May 11, 2020 at 06:12:59PM +0530, Lokesh Vutla wrote:

> Hi Tom,
>   Please find the pull request for v2020.07-rc2 containing TI specific 
> changes.
> 
> Travis-CI build: 
> https://travis-ci.org/github/lokeshvutla/u-boot/builds/685502396
> 
> Thanks and regards,
> Lokesh
> 
> The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d:
> 
>   Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.07-rc2
> 
> for you to fetch changes up to 42e05704d8c0e84e8d0eb0bb52253adaa7c9eb86:
> 
>   Nokia RX-51: Update README.nokia_rx51 (2020-05-11 10:16:49 +0530)
> 

Applied to u-boot/master, thanks!

Please note that both before and after this change, I don't have
ethernet working on the am65x_evm_a53 here.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 2/5 v2] efi_loader: Implement EFI variable handling via OP-TEE

[Ilias Apalodimas]

In OP-TEE we can run EDK2's StandAloneMM on a secure partition.
StandAloneMM is responsible for the UEFI variable support. In
combination with OP-TEE and it's U-Boot supplicant, variables are
authenticated/validated in secure world and stored on an RPMB partition.

So let's add a new config option in U-Boot implementing the necessary
calls to OP-TEE for the variable management.

Signed-off-by: Ilias Apalodimas 
Signed-off-by: Pipat Methavanitpong 
Signed-off-by: Sughosh Ganu 
---
 lib/efi_loader/Kconfig|   9 +
 lib/efi_loader/Makefile   |   4 +
 lib/efi_loader/efi_variable_tee.c | 643 ++
 3 files changed, 656 insertions(+)
 create mode 100644 lib/efi_loader/efi_variable_tee.c

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 1cfa24ffcf72..e385cd0b9dae 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -164,4 +164,13 @@ config EFI_SECURE_BOOT
  it is signed with a trusted key. To do that, you need to install,
  at least, PK, KEK and db.
 
+config EFI_MM_COMM_TEE
+   bool "UEFI variables storage service via OP-TEE"
+   depends on SUPPORT_EMMC_RPMB
+   default n
+   help
+ If OP-TEE is present and running StandAloneMM dispatch all UEFI 
variable
+ related operations to that. The application will verify, authenticate 
and
+ store the variables on an RPMB
+
 endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index eff3c25ec301..dba652121eab 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -34,7 +34,11 @@ obj-y += efi_root_node.o
 obj-y += efi_runtime.o
 obj-y += efi_setup.o
 obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += efi_unicode_collation.o
+ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
+obj-y += efi_variable_tee.o
+else
 obj-y += efi_variable.o
+endif
 obj-y += efi_watchdog.o
 obj-$(CONFIG_LCD) += efi_gop.o
 obj-$(CONFIG_DM_VIDEO) += efi_gop.o
diff --git a/lib/efi_loader/efi_variable_tee.c 
b/lib/efi_loader/efi_variable_tee.c
new file mode 100644
index ..f8857bb81e72
--- /dev/null
+++ b/lib/efi_loader/efi_variable_tee.c
@@ -0,0 +1,643 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  EFI variable service via OP-TEE
+ *
+ *  Copyright (C) 2019 Linaro Ltd. 
+ *  Copyright (C) 2019 Linaro Ltd. 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static efi_uintn_t max_buffer_size;/* comm + var + func + data */
+static efi_uintn_t max_payload_size;   /* func + data */
+
+struct mm_connection {
+   struct udevice *tee;
+   u32 session;
+};
+
+/**
+ * get_connection() - Retrieve OP-TEE session for a specific UUID.
+ *
+ * @conn:   session buffer to fill
+ * Return:  status code
+ */
+static int get_connection(struct mm_connection *conn)
+{
+   static const struct tee_optee_ta_uuid uuid = PTA_STMM_UUID;
+   struct udevice *tee = NULL;
+   struct tee_open_session_arg arg;
+   int rc;
+
+   tee = tee_find_device(tee, NULL, NULL, NULL);
+   if (!tee)
+   return -ENODEV;
+
+   memset(, 0, sizeof(arg));
+   tee_optee_ta_uuid_to_octets(arg.uuid, );
+   rc = tee_open_session(tee, , 0, NULL);
+   if (!rc) {
+   conn->tee = tee;
+   conn->session = arg.session;
+   }
+
+   return rc;
+}
+
+/**
+ * optee_mm_communicate() - Pass a buffer to StandaloneMM running in OP-TEE
+ *
+ * @comm_buf:  locally allocted communcation buffer
+ * @dsize: buffer size
+ * Return: status code
+ */
+static efi_status_t optee_mm_communicate(void *comm_buf, ulong dsize)
+{
+   ulong buf_size;
+   efi_status_t ret;
+   struct efi_mm_communicate_header *mm_hdr;
+   struct mm_connection conn = { NULL, 0 };
+   struct tee_invoke_arg arg;
+   struct tee_param param[2];
+   struct tee_shm *shm = NULL;
+   int rc;
+
+   if (!comm_buf)
+   return EFI_INVALID_PARAMETER;
+
+   mm_hdr = (struct efi_mm_communicate_header *)comm_buf;
+   buf_size = mm_hdr->message_len + sizeof(efi_guid_t) + sizeof(size_t);
+
+   if (dsize != buf_size)
+   return EFI_INVALID_PARAMETER;
+
+   rc = get_connection();
+   if (rc) {
+   log_err("Unable to open OP-TEE session (err=%d)\n", rc);
+   return EFI_UNSUPPORTED;
+   }
+
+   if (tee_shm_register(conn.tee, comm_buf, buf_size, 0, )) {
+   log_err("Unable to register shared memory\n");
+   return EFI_UNSUPPORTED;
+   }
+
+   memset(, 0, sizeof(arg));
+   arg.func = PTA_STMM_CMDID_COMMUNICATE;
+   arg.session = conn.session;
+
+   memset(param, 0, sizeof(param));
+   param[0].attr = TEE_PARAM_ATTR_TYPE_MEMREF_INOUT;
+   param[0].u.memref.size = buf_size;
+   param[0].u.memref.shm = shm;
+   param[1].attr = TEE_PARAM_ATTR_TYPE_VALUE_OUTPUT;
+
+   rc = tee_invoke_func(conn.tee, , 2, param);
+   if (rc)
+

[PATCH 3/5 v2] cmd: efidebug: Add support for querying UEFI variable storage

[Ilias Apalodimas]

With the previous patches that use OP-TEE and StandAloneMM for UEFI
variable storage we've added functionality for efi_query_variable_info.
So let's add the relevant command to efidebug and retrieve information
about the container used to store UEFI variables

Signed-off-by: Ilias Apalodimas 
---
 cmd/efidebug.c | 44 +++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index d8a76d78a388..a3980772c934 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -1160,6 +1160,44 @@ static int do_efi_test(cmd_tbl_t *cmdtp, int flag,
return cp->cmd(cmdtp, flag, argc, argv);
 }
 
+/**
+ * do_efi_query_info() - QueryVariableInfo EFI service
+ *
+ * @cmdtp: Command table
+ * @flag:  Command flag
+ * @argc:  Number of arguments
+ * @argv:  Argument array
+ * Return: CMD_RET_SUCCESS on success,
+ * CMD_RET_USAGE or CMD_RET_FAILURE on failure
+ *
+ * Implement efidebug "test" sub-command.
+ */
+
+static int do_efi_query_info(cmd_tbl_t *cmdtp, int flag,
+int argc, char * const argv[])
+{
+   efi_status_t ret;
+   u32 attr = EFI_VARIABLE_BOOTSERVICE_ACCESS |
+   EFI_VARIABLE_RUNTIME_ACCESS |
+   EFI_VARIABLE_NON_VOLATILE;
+   u64 max_variable_storage_size;
+   u64 remain_variable_storage_size;
+   u64 max_variable_size;
+
+   ret = EFI_CALL(efi_query_variable_info(attr,
+  _variable_storage_size,
+  _variable_storage_size,
+  _variable_size));
+   if (ret != EFI_SUCCESS)
+   return CMD_RET_FAILURE;
+
+   printf("Max storage size %llu\n", max_variable_storage_size);
+   printf("Remaining storage size %llu\n", remain_variable_storage_size);
+   printf("Max variable size %llu\n", max_variable_size);
+
+   return CMD_RET_SUCCESS;
+}
+
 static cmd_tbl_t cmd_efidebug_sub[] = {
U_BOOT_CMD_MKENT(boot, CONFIG_SYS_MAXARGS, 1, do_efi_boot_opt, "", ""),
U_BOOT_CMD_MKENT(devices, CONFIG_SYS_MAXARGS, 1, do_efi_show_devices,
@@ -1176,6 +1214,8 @@ static cmd_tbl_t cmd_efidebug_sub[] = {
 "", ""),
U_BOOT_CMD_MKENT(test, CONFIG_SYS_MAXARGS, 1, do_efi_test,
 "", ""),
+   U_BOOT_CMD_MKENT(query, CONFIG_SYS_MAXARGS, 1, do_efi_query_info,
+"", ""),
 };
 
 /**
@@ -1247,7 +1287,9 @@ static char efidebug_help_text[] =
"efidebug tables\n"
"  - show UEFI configuration tables\n"
"efidebug test bootmgr\n"
-   "  - run simple bootmgr for test\n";
+   "  - run simple bootmgr for test\n"
+   "efidebug query\n"
+   "  - show size of UEFI variables store\n";
 #endif
 
 U_BOOT_CMD(
-- 
2.26.2

[PATCH 4/5 v2] MAINTAINERS: Add maintainer for EFI variables via OP-TEE

[Ilias Apalodimas]

Add myself as maintainer for the OP-TEE related UEFI variable storage
and add the headers file on the existing EFI list

Signed-off-by: Ilias Apalodimas 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ec59ce8b8802..0c38890be09c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -635,6 +635,12 @@ F: cmd/efidebug.c
 F: cmd/nvedit_efi.c
 F: tools/file2include.c
 
+EFI VARIABLES VIA OP-TEE
+M: Ilias Apalodimas 
+S: Maintained
+F: lib/efi_loader/efi_variable_tee.c
+F: include/mm_communication.h
+
 ENVIRONMENT
 M: Joe Hershberger 
 R: Wolfgang Denk 
-- 
2.26.2

[PATCH 5/5 v2] doc: uefi.rst: Add OP-TEE variable storage config options

[Ilias Apalodimas]

If OP-TEE is compiled with an EDK2 application running in secure world
it can process and store UEFI variables in an RPMB.
Add documentation for the config options enabling this

Signed-off-by: Ilias Apalodimas 
---
 doc/uefi/uefi.rst | 17 +
 1 file changed, 17 insertions(+)

diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
index 4fda00d68721..03d6fd0c6aa8 100644
--- a/doc/uefi/uefi.rst
+++ b/doc/uefi/uefi.rst
@@ -188,6 +188,23 @@ on the sandbox
 cd 
 pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox
 
+Using OP-TEE for EFI variables
+~~
+
+Instead of implementing UEFI variable services inside U-Boot they can
+also be provided in the secure world by a module for OP-TEE[1]. The
+interface between U-Boot and OP-TEE for variable services is enabled by
+CONFIG_EFI_MM_COMM_TEE=y.
+
+Tianocore EDK II's standalone management mode driver for variables can
+be linked to OP-TEE for this purpose. This module uses the Replay
+Protected Memory Block (RPMB) of an eMMC device for persisting
+non-volatile variables. When calling the variable services via the
+OP-TEE API U-Boot's OP-TEE supplicant relays calls to the RPMB driver
+which has to be enabled via CONFIG_SUPPORT_EMMC_RPMB=y.
+
+[1] https://optee.readthedocs.io/ - OP-TEE documentation
+
 Executing the boot manager
 ~~
 
-- 
2.26.2

[PATCH 1/5 v2] efi_loader: Add headers for EDK2 StandAloneMM communication

[Ilias Apalodimas]

From: Sughosh Ganu 

In Arm devices OP-TEE has the ability to run StandAloneMM (from EDK2)
in a separate partition and handle UEFI variables.
A following patch introduces this functionality.

Add the headers needed for OP-TEE <--> StandAloneMM communication

Signed-off-by: Sughosh Ganu 
Signed-off-by: Ilias Apalodimas 
---
 include/mm_communication.h | 207 +
 1 file changed, 207 insertions(+)
 create mode 100644 include/mm_communication.h

diff --git a/include/mm_communication.h b/include/mm_communication.h
new file mode 100644
index ..b9bfbe4cf0a1
--- /dev/null
+++ b/include/mm_communication.h
@@ -0,0 +1,207 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ *  Headers for EFI variable service via StandAloneMM, EDK2 application running
+ *  in OP-TEE
+ *
+ *  Copyright (c) 2017, Intel Corporation. All rights reserved.
+ *  Copyright (C) 2020 Linaro Ltd. 
+ *  Copyright (C) 2020 Linaro Ltd. 
+ */
+
+#ifndef _MM_VARIABLE_H_
+#define _MM_VARIABLE_H_
+
+#include 
+
+/*
+ * Interface to the pseudo TA, which provides a communication channel with
+ * the StandaloneMM Secure Partition (StMM) running at S-EL0
+ */
+
+#define PTA_STMM_CMDID_COMMUNICATE 0
+
+/* OP-TEE is using big endian GUIDs while UEFI uses little endian ones */
+#define PTA_STMM_UUID { 0xed32d533, 0x99e6, 0x4209, {\
+   0x9c, 0xc0, 0x2d, 0x72, 0xcd, 0xd9, 0x98, 0xa7 } }
+
+#define EFI_MM_VARIABLE_GUID \
+   EFI_GUID(0xed32d533, 0x99e6, 0x4209, \
+0x9c, 0xc0, 0x2d, 0x72, 0xcd, 0xd9, 0x98, 0xa7)
+
+/* Defined in EDK2 MdePkg/Include/Protocol/MmCommunication.h */
+
+/**
+ * struct efi_mm_communicate_header - Header used for SMM variable 
communication
+
+ * @header_guid:  header use for disambiguation of content
+ * @message_len:  length of the message. Does not include the size of the
+ *header
+ * @data: payload of the message
+ *
+ * Defined in EDK2 as EFI_MM_COMMUNICATE_HEADER
+ * To avoid confusion in interpreting frames, the communication buffer should
+ * always begin with efi_mm_communicate_header
+ */
+struct efi_mm_communicate_header {
+   efi_guid_t header_guid;
+   size_t message_len;
+   u8 data[];
+};
+
+#define MM_COMMUNICATE_HEADER_SIZE \
+   (sizeof(struct efi_mm_communicate_header))
+
+/* Defined in EDK2 ArmPkg/Include/IndustryStandard/ArmStdSmc.h */
+
+/* MM return error codes */
+#define ARM_SMC_MM_RET_SUCCESS  0
+#define ARM_SMC_MM_RET_NOT_SUPPORTED   -1
+#define ARM_SMC_MM_RET_INVALID_PARAMS  -2
+#define ARM_SMC_MM_RET_DENIED  -3
+#define ARM_SMC_MM_RET_NO_MEMORY   -4
+
+/* Defined in EDK2 MdeModulePkg/Include/Guid/SmmVariableCommon.h */
+
+#define SMM_VARIABLE_FUNCTION_GET_VARIABLE  1
+/*
+ * The payload for this function is
+ * SMM_VARIABLE_COMMUNICATE_GET_NEXT_VARIABLE_NAME.
+ */
+#define SMM_VARIABLE_FUNCTION_GET_NEXT_VARIABLE_NAME  2
+/*
+ * The payload for this function is SMM_VARIABLE_COMMUNICATE_ACCESS_VARIABLE.
+ */
+#define SMM_VARIABLE_FUNCTION_SET_VARIABLE  3
+/*
+ * The payload for this function is
+ * SMM_VARIABLE_COMMUNICATE_QUERY_VARIABLE_INFO.
+ */
+#define SMM_VARIABLE_FUNCTION_QUERY_VARIABLE_INFO  4
+/*
+ * It is a notify event, no extra payload for this function.
+ */
+#define SMM_VARIABLE_FUNCTION_READY_TO_BOOT  5
+/*
+ * It is a notify event, no extra payload for this function.
+ */
+#define SMM_VARIABLE_FUNCTION_EXIT_BOOT_SERVICE  6
+/*
+ * The payload for this function is VARIABLE_INFO_ENTRY.
+ * The GUID in EFI_SMM_COMMUNICATE_HEADER is gEfiSmmVariableProtocolGuid.
+ */
+#define SMM_VARIABLE_FUNCTION_GET_STATISTICS  7
+/*
+ * The payload for this function is SMM_VARIABLE_COMMUNICATE_LOCK_VARIABLE
+ */
+#define SMM_VARIABLE_FUNCTION_LOCK_VARIABLE   8
+
+#define SMM_VARIABLE_FUNCTION_VAR_CHECK_VARIABLE_PROPERTY_SET  9
+
+#define SMM_VARIABLE_FUNCTION_VAR_CHECK_VARIABLE_PROPERTY_GET  10
+
+#define SMM_VARIABLE_FUNCTION_GET_PAYLOAD_SIZE  11
+/*
+ * The payload for this function is
+ * SMM_VARIABLE_COMMUNICATE_RUNTIME_VARIABLE_CACHE_CONTEXT
+ */
+#define SMM_VARIABLE_FUNCTION_INIT_RUNTIME_VARIABLE_CACHE_CONTEXT 12
+
+#define SMM_VARIABLE_FUNCTION_SYNC_RUNTIME_CACHE  13
+/*
+ * The payload for this function is
+ * SMM_VARIABLE_COMMUNICATE_GET_RUNTIME_CACHE_INFO
+ */
+#define SMM_VARIABLE_FUNCTION_GET_RUNTIME_CACHE_INFO  14
+
+/**
+ * struct smm_variable_communicate_header - Used for SMM variable communication
+
+ * @function: function to call in Smm.
+ * @ret_status:   return status
+ * @data: payload
+ *
+ * Defined in EDK2 as SMM_VARIABLE_COMMUNICATE_HEADER
+ */
+struct smm_variable_communicate_header {
+   efi_uintn_t  function;
+   efi_status_t ret_status;
+   u8   data[];
+};
+
+#define MM_VARIABLE_COMMUNICATE_SIZE \
+   (sizeof(struct smm_variable_communicate_header))
+
+/**
+ * struct smm_variable_access - Used to communicate with StMM by
+ *  SetVariable and 

[PATCH 0/6 v2] EFI variable support via OP-TEE

[Ilias Apalodimas]

Hi!

This is the v2 of the patchset adding EFI variable support via OP-TEE
originally posted here [1]

Changes since v1:
* patch #2: 
   - Fix Copyright issues
   - Merge the include files in mm_communication.h
   - Rename some variables and follow EDK2 naming
   - Added proper documentation on struct definitions
   - Add missing defines (unused but good to have there)
   - Use flexible array members on structs and replace data[1] with data[]
* patch #3: 
   - Adjust efi_variable_tee.c to header file changes and fix typos
* patch #4: 
   - Remove EFI_HANDLE_WIDTH on printing
   - Rephrase 'efidebug query' help message
* patch #5
   - Move mm_communication.h maintenership
* patch #6
   - Heinrich's suggestion, on the help file, was a lot cleaner and easier
 to understand.  Using it as-is

[1] https://lists.denx.de/pipermail/u-boot/2020-May/410772.html


Ilias Apalodimas (4):
  efi_loader: Implement EFI variable handling via OP-TEE
  cmd: efidebug: Add support for querying UEFI variable storage
  MAINTAINERS: Add maintainer for EFI variables via OP-TEE
  doc: uefi.rst: Add OP-TEE variable storage config options

Sughosh Ganu (1):
  efi_loader: Add headers for EDK2 StandAloneMM communication

 MAINTAINERS   |   6 +
 cmd/efidebug.c|  44 +-
 doc/uefi/uefi.rst |  17 +
 include/mm_communication.h| 207 ++
 lib/efi_loader/Kconfig|   9 +
 lib/efi_loader/Makefile   |   4 +
 lib/efi_loader/efi_variable_tee.c | 643 ++
 7 files changed, 929 insertions(+), 1 deletion(-)
 create mode 100644 include/mm_communication.h
 create mode 100644 lib/efi_loader/efi_variable_tee.c

-- 
2.26.2

Re: [PATCH v2 2/2] env/sf.c: honour CONFIG_SPL_SAVEENV

[Tom Rini]

On Mon, May 11, 2020 at 08:49:38AM +0200, Rasmus Villemoes wrote:
> On 09/05/2020 22.54, Tom Rini wrote:
> > On Sat, May 09, 2020 at 08:56:46PM +0200, Rasmus Villemoes wrote:
> >> On 09/05/2020 00.59, Tom Rini wrote:
> >>> On Fri, Mar 27, 2020 at 12:02:00AM +0100, Rasmus Villemoes wrote:
> >>>
> >>>
> >>> Applied to u-boot/master, thanks!
> >>>
> >>
> >> Eh, thanks, but you already applied v1 consisting of 5 patches. v1 1/5
> >> corresponded to v2 1/2, while v1 5/5 corresponded to v2 2/2 - v1 3/5 and
> >> 4/5 were left out of v2. v1 2/5 was a helper macro I decided wasn't that
> >> much of a helper (but it's still needed since v1 3/5 and v1 4/5 were
> >> applied).
> >>
> >> This doesn't mean anything needs fixing up - I'm guessing you rebased
> >> the two patches, git saw that v2 1/2 was already applied, and then
> >> either you or git saw that most of v2 2/2 was already applied, so the
> >> only thing commit 6d3524c2ad does is to replace ENV_SAVE_PTR with its
> >> definition.
> > 
> > :headdesk:
> > 
> > So, 'git am' went through and applied what could be applied and I didn't
> > see a "skipping" message.  But at this point, are there any changes that
> > need to still come in?  Thanks!
> 
> No, I think the code should all work. The history is a bit misleading as
> commit 6d3524c2ad doesn't have any functional change, it was all already
> done by the v1 patch which is applied as 9e3c94d11. But there's not much
> to be done about that, I guess. One could revert 6d3524c2ad without any
> damage and use the commit message to explain things, but I don't know if
> that's worth the churn. If you think it is, let me know and I'll try to
> draft a revert commit log which you can then edit to taste.

I guess we should just leave it be then for now, thanks and sorry for
the confusion.

-- 
Tom


signature.asc
Description: PGP signature

Re: [GIT PULL] Pull request: u-boot-imx u-boot-imx-20200511

[Tom Rini]

On Mon, May 11, 2020 at 12:29:37PM +0200, Stefano Babic wrote:

> Hi Tom,
> 
> please pull these i.MX's changes for 2020.07, thanks !
> 
> The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d:
> 
>   Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
> tags/u-boot-imx-20200511
> 
> for you to fetch changes up to d52a03b130565e6b01dcbe656ebeb611d5ee1aa1:
> 
>   imx8: cpu: check resource owned after sid fail (2020-05-10 20:55:21 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Pull request for UEFI sub-system for efi-2020-07-rc2-4

[Heinrich Schuchardt]

The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d:

  Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2020-07-rc2-4

for you to fetch changes up to bdb15776f6d93a1fe7902346db06a2a9fd43381e:

  cmd: efidebug: fix -Werror=type-limits warning (2020-05-10 00:01:12 +0200)

No problems were reported by Gitlab CI and Travis:
https://travis-ci.org/github/xypron2/u-boot/builds/685166920
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/3170


Pull request for UEFI sub-system for efi-2020-07-rc2-4

This pull request comprises:
* bug fixes
* documentation fixes
* a new function to determine u16 string sizes and its unit test


AKASHI Takahiro (4):
  efi_loader: image_loader: fix a Coverity check against array access
  efi_loader: variable: check a return value of uuid__str_to_bin()
  cmd: efidebug: fix a wrong handling of arguments
  cmd: efidebug: add a comment against Coverity check (300329)

Heinrich Schuchardt (5):
  efi_selftest: add unit test functions to HTML documentation
  test: unit test for u16_strsize()
  lib: charset: correct function descriptions
  doc: add Unicode functions to API description
  cmd: efidebug: fix -Werror=type-limits warning

Sughosh Ganu (1):
  charset: Add support for calculating bytes occupied by a u16 string

 cmd/efidebug.c|   9 +++-
 doc/api/efi.rst   |   9 
 doc/api/index.rst |   1 +
 doc/api/unicode.rst   |   7 +++
 include/charset.h |  49 -
 include/efi_selftest.h| 110
+-
 lib/charset.c |   5 ++
 lib/efi_loader/efi_image_loader.c |   6 +--
 lib/efi_loader/efi_variable.c |   5 +-
 test/unicode_ut.c |  10 
 10 files changed, 154 insertions(+), 57 deletions(-)
 create mode 100644 doc/api/unicode.rst

Re: [PATCH 5/5] verdin-imx8mm: Select the watchdog driver

[Igor Opaniuk]

Hi Fabio,

On Mon, May 11, 2020, 17:02 Fabio Estevam  wrote:

> Currently watchdog driver is not selected, which causes system to reboot
> after staying 60s in the U-Boot prompt.
>
> Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be
> properly serviced.
>
> Signed-off-by: Fabio Estevam 
> ---
>  configs/verdin-imx8mm_defconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/configs/verdin-imx8mm_defconfig
> b/configs/verdin-imx8mm_defconfig
> index c68b299a95..f5b6e03251 100644
> --- a/configs/verdin-imx8mm_defconfig
> +++ b/configs/verdin-imx8mm_defconfig
> @@ -99,5 +99,4 @@ CONFIG_SPL_SYSRESET=y
>  CONFIG_SYSRESET_PSCI=y
>  CONFIG_SYSRESET_WATCHDOG=y
>  CONFIG_DM_THERMAL=y
> -# CONFIG_WATCHDOG is not set
>  CONFIG_IMX_WATCHDOG=y
> --
> 2.17.1
>

Acked-by: Igor Opaniuk 

Thanks!

>

Re: [PATCH 4/8] drivers: ddr: imx8m: add print for DRAM rate

[Stefano Babic]

On 11.05.20 11:53, Peng Fan wrote:
> From: Ye Li 
> 
> Enable print to show the DRAM rate of current setting and training
> result.
> 
> Reviewed-by: Peng Fan 
> Signed-off-by: Ye Li 
> Signed-off-by:  Peng Fan 
> ---

This changes the boottime, too. The printf() are really useful only for
debugging, IMHO it is better to let it as it is. If something is going
wrong, one set DEBUG to get the output.

Regards,
Stefano

>  drivers/ddr/imx/imx8m/ddr_init.c | 7 ---
>  drivers/ddr/imx/imx8m/ddrphy_utils.c | 2 +-
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/ddr/imx/imx8m/ddr_init.c 
> b/drivers/ddr/imx/imx8m/ddr_init.c
> index f573a778d9..a1d2d21692 100644
> --- a/drivers/ddr/imx/imx8m/ddr_init.c
> +++ b/drivers/ddr/imx/imx8m/ddr_init.c
> @@ -95,7 +95,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
>   unsigned int tmp, initial_drate, target_freq;
>   int ret;
>  
> - debug("DDRINFO: start DRAM init\n");
> + printf("DDRINFO: start DRAM init\n");
>  
>   /* Step1: Follow the power up procedure */
>   if (is_imx8mq()) {
> @@ -118,6 +118,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
>  
>   initial_drate = dram_timing->fsp_msg[0].drate;
>   /* default to the frequency point 0 clock */
> + printf("DDRINFO: DRAM rate %dMTS\n", initial_drate);



>   ddrphy_init_set_dfi_clk(initial_drate);
>  
>   /* D-aasert the presetn */
> @@ -184,7 +185,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
>   tmp = reg32_read(DDRPHY_CalBusy(0));
>   } while ((tmp & 0x1));
>  
> - debug("DDRINFO:ddrphy calibration done\n");
> + printf("DDRINFO:ddrphy calibration done\n");
>  
>   /* Step15: Set SWCTL.sw_done to 0 */
>   reg32_write(DDRC_SWCTL(0), 0x);
> @@ -236,7 +237,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
>  
>   /* enable port 0 */
>   reg32_write(DDRC_PCTRL_0(0), 0x0001);
> - debug("DDRINFO: ddrmix config done\n");
> + printf("DDRINFO: ddrmix config done\n");
>  
>   board_dram_ecc_scrub();
>  
> diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c 
> b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> index 9ac7ca923c..9d2378d7dd 100644
> --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c
> +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> @@ -97,7 +97,7 @@ int wait_ddrphy_training_complete(void)
>   debug("Training PASS\n");
>   return 0;
>   } else if (mail == 0xff) {
> - debug("Training FAILED\n");
> + printf("Training FAILED\n");
>   return -1;
>   }
>   }
> 


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

Re: Calling i2c set speed twice for i2c_mux_bus

[Heiko Schocher]

Hello Michal,

Am 11.05.2020 um 15:36 schrieb Michal Simek:

On 07. 05. 20 12:02, Heiko Schocher wrote:

Hello Michal,

Am 07.05.2020 um 10:18 schrieb Michal Simek:

On 06. 05. 20 16:47, Simon Glass wrote:

Hi Michal,

On Tue, 5 May 2020 at 21:43, Simon Glass  wrote:


Hi Michal,

On Tue, 5 May 2020 at 02:26, Michal Simek 
wrote:


On 15. 04. 20 8:40, Michal Simek wrote:

On 10. 04. 20 10:49, Heiko Schocher wrote:

Hello Michal,

Am 10.04.2020 um 08:46 schrieb Michal Simek:

Hi Heiko,

On 10. 04. 20 7:11, Heiko Schocher wrote:

Hello Michal,

Am 09.04.2020 um 16:03 schrieb Michal Simek:

Hi Heiko and Simon,

I have find out one bug in i2c class. I am using zcu104 revC
board
which
has dts in mainline where i2c1 has i2c mux with some channels.
In DT clock-frequency = <40>; is specified and it is read in
i2c_post_probe(). But i2c_mux_bus_drv is also UCLASS_I2C which
means
that post probe is called for it too. And because clock-frequency
property is not there default 100k is used.

I think that is bug and should be fixed.
Heiko: Are you aware about this issue?


No :-(

The question is, is this a bug?


I have never seen clock-frequency property in i2c mux bus node.
Also I
have looked at linux dt binding docs and nothing like that is
specified
there. From quick look also pca954x driver is not reading it.


Indeed.


Should a i2c bus behind a mux not be able to set his own speed?


Not sure if that make sense but Linux will likely ignore it. I
am not
saying it doesn't make sense but I haven't seen this feature.


Ok.


But may as a feature (or bugfix?) if "clock-frequency" is not
there,
use the speed of the parent bus...?


I was thinking about this too.
just c quick implementation would look like this. Because it is
i2c->i2c_mux->i2c. But maybe there is a better way how to do it.

diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index 2aa3efe8aaa0..982c467deba3 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -640,9 +640,21 @@ static int i2c_post_probe(struct udevice *dev)
    {
    #if CONFIG_IS_ENABLED(OF_CONTROL) &&
!CONFIG_IS_ENABLED(OF_PLATDATA)
   struct dm_i2c_bus *i2c = dev_get_uclass_priv(dev);
+   int parent_speed = I2C_SPEED_STANDARD_RATE;
+
+   if (dev->parent &&
+   device_get_uclass_id(dev->parent) == UCLASS_I2C_MUX &&
+   dev->parent->parent &&
+   device_get_uclass_id(dev->parent->parent) ==
UCLASS_I2C) {
+   struct dm_i2c_bus *i2c_parent;
+
+   i2c_parent =
dev_get_uclass_priv(dev->parent->parent);
+   parent_speed = i2c_parent->speed_hz;
+   /* Not sure if make sense to check that
parent_speed is
not 0 */


I think this check is not needed.


+   }

   i2c->speed_hz = dev_read_u32_default(dev,
"clock-frequency",
-
I2C_SPEED_STANDARD_RATE);
+    parent_speed);


Wow, a big if ... may this is clearer (not compile tested)?

udevice *parent = dev_get_parent(dev);

if (parent && device_get_uclass_id(parent) == UCLASS_I2C_MUX) {
  udevice *parent2 = dev_get_parent(parent);
  if (parent2 && device_get_uclass_id(parent2) == UCLASS_I2C) {
  struct dm_i2c_bus *i2cp = dev_get_uclass_priv(parent2);

  parent_speed = i2cp->speed_hz;
  }
}

but Simon has a deeper DM knowledge, may there is a better approach.


Simon: any comment on this one?


Simon: Can you please comment this?



OK will take a look.


I wonder if i2c-mux-uclass.c should define a new uclass for muxed I2C
buses, something like UCLASS_I2C_MUXED_BUS? Then you can define the
behaviour correctly in i2c-mux-uclass.c.

An I2C controller is not the same as a muxed bus and perhaps we should
be explicitly about the differences. It probably just needs changes to
the mux uclass.


Definitely there need to be some changes in connection to i2c muxes. I
am aware also about bad behavior when you detect devices.
Just look at log below and you will see that devices on base i2c bus are
copied also to subbus (especially listing i2c-mux again looks weird).


Yes, this look like we need here a seperate uclass to handle this
correct...


Are you going to invest to your time to create?


Unfortunately I have no time to look into this soon, and I must search
for a hardware to test...

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 4/8] drivers: ddr: imx8m: add print for DRAM rate

[Adam Ford]

On Mon, May 11, 2020 at 9:13 AM Fabio Estevam  wrote:
>
> Hi Peng,
>
> On Mon, May 11, 2020 at 6:30 AM Peng Fan  wrote:
> >
> > From: Ye Li 
> >
> > Enable print to show the DRAM rate of current setting and training
> > result.

I am not a fan of this.

> >
> > Reviewed-by: Peng Fan 
> > Signed-off-by: Ye Li 
> > Signed-off-by:  Peng Fan 
>
> This is basically a revert from:
>
> commit 0d3bc81391ac031758affdb0811bc9c8b905978c
> Author: Fabio Estevam 
> Date:   Wed Dec 11 17:37:09 2019 -0300
>
> imx8m: ddr_init: Move ddr_init() messages to debug level
>
> Currently inside ddr_init() there is a mix of printf() and debug()
> level messages.
>
> Since this type of information is useful for debug purposes,
> convert all of them to debug level for consistency.
>
> Signed-off-by: Fabio Estevam 
> Reviewed-by: Peng Fan 
>
> In the normal boot cases I don't think these messages are helpful.

I would agree.  As a user, I don't think most people will want to know
this, and it creates a bunch of chatter.  For people who want it,
enable the debug.

>
> > diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c 
> > b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> > index 9ac7ca923c..9d2378d7dd 100644
> > --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c
> > +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> > @@ -97,7 +97,7 @@ int wait_ddrphy_training_complete(void)
> > debug("Training PASS\n");
> > return 0;
> > } else if (mail == 0xff) {
> > -   debug("Training FAILED\n");
> > +   printf("Training FAILED\n");
>
> This one is an error message, so I agree that it is useful to have it printed.
I would agree here.

adam

Re: Status i.MX U-Boot patches

[Fabio Estevam]

Hi Stefano,

On Mon, May 11, 2020 at 6:27 AM Stefano Babic  wrote:
>
> Sorry, forgotten ML...
>
> Hi Fabio, Peng,
>
> I have thought about how to handle Peng's last series and I came to the
> decision to merge them as soon as possible, letting some more time for
> fixes if required. Most patches are orthogonal, and this helps to let
> them in. I merged the two series for NAND, too, with the hope that
> someone can retest nandbcb on MX6(UL), too.
>
> My list contains:
> - imx8qm/qxp update series, and IMX_BOOTAUX patch
> - NAND i.MX update and nandbcb series
> - uclass
> series(http://patchwork.ozlabs.org/user/todo/uboot/?series=174311) -
> aloo should be taken at 5/8, because of conflicts I had to solve (IMHO
> it is ok, but polease test again)
> - thermal series
> - with the chance, I merged two additional board form Marek and Adam.
>
> Status is on my -next, but I am going to push it to -master, too. I plan
> then to merge just fixes for 2020.07, if there will be new features they
> will flow into -next.

Sounds good. Thanks

Re: [PATCH 1/2] imx: imx8mp_evk: fix boot issue

[Fabio Estevam]

Hi Peng,

On Mon, May 11, 2020 at 2:55 AM Peng Fan  wrote:
>
> The u-boot-spl.bin pad with ddr firmware conflicts with the
> CONFIG_MALLOC_F_ADDR area, the ddr firmware will be overwritten
> by malloc in SPL stage and cause ddr initialization not able
> to finish. So update the related addresses to fix the issue.
>
> Reported-by: Fabio Estevam 
> Signed-off-by: Peng Fan 
> ---
>  include/configs/imx8mp_evk.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h
> index 80e5738961..b90a4f6932 100644
> --- a/include/configs/imx8mp_evk.h
> +++ b/include/configs/imx8mp_evk.h
> @@ -23,15 +23,15 @@
>  #ifdef CONFIG_SPL_BUILD
>  /*#define CONFIG_ENABLE_DDR_TRAINING_DEBUG*/
>  #define CONFIG_SPL_LDSCRIPT"arch/arm/cpu/armv8/u-boot-spl.lds"
> -#define CONFIG_SPL_STACK   0x99
> -#define CONFIG_SPL_BSS_START_ADDR  0x0095e000
> -#define CONFIG_SPL_BSS_MAX_SIZE0x2000  /* 8 KB */
> +#define CONFIG_SPL_STACK   0x98fc00

On imx6/imx7 we have this kind of SPL information placed in the SoC
related header files:

include/configs/imx6_spl.h
include/configs/imx7_spl.h

We should do the same here instead of repeating these SPL settings in
every board header file.

Thanks

Re: [PATCH 3/5] imx8mm_beacon: Select the watchdog driver

[Adam Ford]

On Mon, May 11, 2020 at 8:59 AM Fabio Estevam  wrote:
>
> Currently watchdog driver is not selected, which causes system to reboot
> after staying 60s in the U-Boot prompt.
>
> Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be
> properly serviced.
>
Thanks for doing that!

Reviewed-by: Adam Ford 

> Signed-off-by: Fabio Estevam 
> ---
>  configs/imx8mm_beacon_defconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig
> index b935d72360..a518963f48 100644
> --- a/configs/imx8mm_beacon_defconfig
> +++ b/configs/imx8mm_beacon_defconfig
> @@ -100,5 +100,4 @@ CONFIG_SPL_SYSRESET=y
>  CONFIG_SYSRESET_PSCI=y
>  CONFIG_SYSRESET_WATCHDOG=y
>  CONFIG_DM_THERMAL=y
> -# CONFIG_WATCHDOG is not set
>  CONFIG_IMX_WATCHDOG=y
> --
> 2.17.1
>

Re: [PATCH 4/8] drivers: ddr: imx8m: add print for DRAM rate

[Fabio Estevam]

Hi Peng,

On Mon, May 11, 2020 at 6:30 AM Peng Fan  wrote:
>
> From: Ye Li 
>
> Enable print to show the DRAM rate of current setting and training
> result.
>
> Reviewed-by: Peng Fan 
> Signed-off-by: Ye Li 
> Signed-off-by:  Peng Fan 

This is basically a revert from:

commit 0d3bc81391ac031758affdb0811bc9c8b905978c
Author: Fabio Estevam 
Date:   Wed Dec 11 17:37:09 2019 -0300

imx8m: ddr_init: Move ddr_init() messages to debug level

Currently inside ddr_init() there is a mix of printf() and debug()
level messages.

Since this type of information is useful for debug purposes,
convert all of them to debug level for consistency.

Signed-off-by: Fabio Estevam 
Reviewed-by: Peng Fan 

In the normal boot cases I don't think these messages are helpful.

> diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c 
> b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> index 9ac7ca923c..9d2378d7dd 100644
> --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c
> +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> @@ -97,7 +97,7 @@ int wait_ddrphy_training_complete(void)
> debug("Training PASS\n");
> return 0;
> } else if (mail == 0xff) {
> -   debug("Training FAILED\n");
> +   printf("Training FAILED\n");

This one is an error message, so I agree that it is useful to have it printed.

FW: mmc: zynq_sdhci: transfer fails with 8-bit data bus

[Benedikt Grassl]

Hi,

with commit 942b5fc0 the 8-bit data bus seems to work fine in U-Boot.
However, I have one situation where I get transfer errors lateron in Linux. At 
the moment I suspect that this is rather a problem of the Linux driver, but I 
would like to make sure here first.
My ZynqMP has an eMMC flash connected to SD0 and an SD-card to SD1. When I boot 
the device from SD-card and load a kernel ITB (tested both 4.14 and 5.4), I 
immediately get errors when writing to the eMMC flash in
Linux:

 print_req_error: I/O error, dev mmcblk0, sector 2048  Buffer I/O error on dev 
mmcblk0p1, logical block 0, lost sync page write
 mmc0: Got data interrupt 0x0002 even though no data operation was in 
progress.
 mmc0: sdhci:  SDHCI REGISTER DUMP ===
 mmc0: sdhci: Sys addr:  0x0400 | Version:  0x1002
 mmc0: sdhci: Blk size:  0x7200 | Blk cnt:  0x0400
 mmc0: sdhci: Argument:  0x | Trn mode: 0x0033
 mmc0: sdhci: Present:   0x1ff7 | Host ctl: 0x003d
 mmc0: sdhci: Power: 0x000f | Blk gap:  0x0080
 mmc0: sdhci: Wake-up:   0x | Clock:0x0007
 mmc0: sdhci: Timeout:   0x0006 | Int stat: 0x
 mmc0: sdhci: Int enab:  0x02ff000b | Sig enab: 0x02ff000b
 mmc0: sdhci: AC12 err:  0x | Slot int: 0x
 mmc0: sdhci: Caps:  0x75ecc881 | Caps_1:   0x2007
 mmc0: sdhci: Cmd:   0x0c1a | Max curr: 0x
 mmc0: sdhci: Resp[0]:   0x0b00 | Resp[1]:  0x36475026
 mmc0: sdhci: Resp[2]:   0x49533031 | Resp[3]:  0x0900
 mmc0: sdhci: Host ctl2: 0x008b
 mmc0: sdhci: ADMA Err:  0x | ADMA Ptr: 0x
 mmc0: sdhci: 

Interestingly, I can work-around this by just typing "mmc info" in the U-Boot 
console. As soon as some interaction with mmc0 happens in U-Boot , this problem 
disappears (i.e. anything that relies on the mmc layer to issue transfers to 
the eMMC flash).
This did not happen before, when only a 4-bit data bus was supported.
Also the latest commit e44c2bc on the Xilinx U-boot git repository does not 
solve this problem.
>From my understanding, the Linux driver should be independent of the 
>initialization done in U-Boot, right?
Does anyone have an idea or a comment to this? Did I miss anything?

Thanks,
Benedikt

Re: [Uboot-stm32] [PATCH] ARM: dts: stm32mp1: DT alignment with Linux 5.7-rc2

[Patrice CHOTARD]

Hi Patrick

On 4/30/20 3:52 PM, Patrick Delaunay wrote:
> DT alignment with Linux 5.7-rc2, including the kernel commits
>
> 431c89e6f323 ARM: dts: stm32: use correct vqmmc regu for eMMC on stm32mp1 
> ED1/EV1 boards
> 79e965053872 ARM: dts: stm32: add disable-wp property for SD-card on STM32MP1 
> boards
> 877db62ea516 ARM: dts: stm32: add cd-gpios properties for SD-cards on 
> STM32MP1 boards
> 7519e95ba5f8 ARM: dts: stm32: Do clean up in stmpic nodes on stm32mp15 boards
> f68e2dbc591a ARM: dts: stm32: Rename stmfx joystick pins on stm32mp157c-ev1
> d6210da4f8bf ARM: dts: stm32: add cpu clock-frequency property on stm32mp15x
> b65b6fc56925 ARM: dts: stm32: add wakeup-source in all I2C nodes of 
> stm32mp157c
> 1c1cf5996cfb ARM: dts: stm32: add i2c4 sleep pinctrl on stm32mp157c-ed1
> bef15fc0fad9 ARM: dts: stm32: add i2c2/i2c5 sleep pinctrl on stm32mp157c-ev1
> b7fc0a87b9ac ARM: dts: stm32: add i2c4 sleep pinctrl on stm32mp15xx-dkx
> a5e557655285 ARM: dts: stm32: set i2c4 bus freq to 400KHz on stm32mp15 DK 
> boards
> 8bc631b650a6 ARM: dts: stm32: set i2c4 bus freq to 400KHz on stm32mp157c-ed1
> fccd6a577bb3 ARM: dts: stm32: Correct stmfx node name on stm32mp157c-ev1 board
> cc775a83db65 ARM: dts: stm32: add resets property on all DMA nodes on 
> stm32mp151
> c5fae093511b ARM: dts: stm32: enable USB OTG Dual Role on stm32mp157c-ev1
> 9879e2165758 ARM: dts: stm32: add USB OTG pinctrl to stm32mp15
> 82ac8a81f985 ARM: dts: stm32: add USB OTG full support on stm32mp151
> 8714b26e2863 ARM: dts: stm32: remove useless properties in 
> stm32mp157a-avenger96 stmpic node
> a7959919709e ARM: dts: stm32: Add UART8 pins A pinmux entry on stm32mp1
> 4d7c53a684da ARM: dts: stm32: Add USART3 pins A pinmux entry on stm32mp1
> 80ab128332ee ARM: dts: stm32: Add SAI2A pins B pinmux entry on stm32mp1
> ab7f98c0c546 ARM: dts: stm32: Add Ethernet0 RMII pins A pinmux entry on 
> stm32mp1
>
> Signed-off-by: Patrick Delaunay 
> ---
> Hi,
>
> Dependency with correction of GPIO support in SPL:
>
> [v2,09/12] gpio: stm32: support gpio ops in SPL
> http://patchwork.ozlabs.org/project/uboot/patch/20200422142834.v2.9.I355ddbc804eba6047ea147d830be57a5b9c4a87e@changeid/
>
> Patrick
>
>
>  arch/arm/dts/stm32mp15-pinctrl.dtsi | 92 +
>  arch/arm/dts/stm32mp151.dtsi| 13 +++-
>  arch/arm/dts/stm32mp153.dtsi|  1 +
>  arch/arm/dts/stm32mp157c-ed1.dts| 12 ++--
>  arch/arm/dts/stm32mp157c-ev1.dts| 13 ++--
>  arch/arm/dts/stm32mp15xx-dhcom.dtsi |  3 +-
>  arch/arm/dts/stm32mp15xx-dhcor.dtsi |  8 ---
>  arch/arm/dts/stm32mp15xx-dkx.dtsi   | 10 ++--
>  8 files changed, 126 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi 
> b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> index 29acdc4afd..8d00391978 100644
> --- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> @@ -213,6 +213,40 @@
>   };
>   };
>  
> + ethernet0_rmii_pins_a: rmii-0 {
> + pins1 {
> + pinmux = , /* 
> ETH1_RMII_TXD0 */
> +  , /* 
> ETH1_RMII_TXD1 */
> +  , /* 
> ETH1_RMII_TX_EN */
> +  ,   /* 
> ETH1_RMII_REF_CLK */
> +  ,  /* ETH1_MDIO */
> +  ;  /* ETH1_MDC */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <2>;
> + };
> + pins2 {
> + pinmux = ,  /* 
> ETH1_RMII_RXD0 */
> +  ,  /* 
> ETH1_RMII_RXD1 */
> +  ;  /* 
> ETH1_RMII_CRS_DV */
> + bias-disable;
> + };
> + };
> +
> + ethernet0_rmii_pins_sleep_a: rmii-sleep-0 {
> + pins1 {
> + pinmux = , /* 
> ETH1_RMII_TXD0 */
> +  , /* 
> ETH1_RMII_TXD1 */
> +  , /* 
> ETH1_RMII_TX_EN */
> +  ,  /* ETH1_MDIO 
> */
> +  ,  /* ETH1_MDC */
> +  ,  /* 
> ETH1_RMII_RXD0 */
> +  ,  /* 
> ETH1_RMII_RXD1 */
> +  ,  /* 
> ETH1_RMII_REF_CLK */
> +  ;  /* 
> ETH1_RMII_CRS_DV */
> + };
> + };
> +
>   fmc_pins_a: fmc-0 {
>   pins1 {
>   pinmux = , /* FMC_NOE */
> @@ -736,6 +770,25 @@
>   };
>   };
>  
> + sai2a_pins_b: sai2a-2 {
> + pins1 {
> + pinmux = ,  /* SAI2_SD_A */
> +  ,  /* SAI2_FS_A */
> +  ; /* SAI2_SCK_A */
> + slew-rate = <0>;
> + drive-push-pull;
> + bias-disable;
> + };
> + };
> +
> + sai2a_sleep_pins_b: sai2a-sleep-3 {
> + pins {
> +  

Re: [PATCH] mmc: stm32_sdmmc2: change the displayed config name

[Patrice CHOTARD]

On 4/30/20 9:52 AM, Patrick Delaunay wrote:
> Change the mmc displayed name in U-Boot for stm32_sdmmc2 driver to
> “STM32 SD/MMC”.
>
> This stm32_sdmmc2 driver is for version 2 of the ST HW IP SDMMC but the
> displayed name "STM32 SDMMC2" is confusing for user, between the
> instance of SDMMC and the device identifier of MMC.
>
> For example on EV1 board, we have:
>
> STM32MP1> mmc list
>  STM32 SDMMC2: 0 (SD)
>  STM32 SDMMC2: 1 (eMMC)
>
> Changed to more clear:
>
> STM32MP1> mmc list
>  STM32 SD/MMC: 0 (SD)
>  STM32 SD/MMC: 1 (eMMC)
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  drivers/mmc/stm32_sdmmc2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
> index 6f3b2ad653..fa6fc94ad9 100644
> --- a/drivers/mmc/stm32_sdmmc2.c
> +++ b/drivers/mmc/stm32_sdmmc2.c
> @@ -674,7 +674,7 @@ static int stm32_sdmmc2_probe(struct udevice *dev)
>   cfg->f_max = dev_read_u32_default(dev, "max-frequency", 5200);
>   cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
>   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
> - cfg->name = "STM32 SDMMC2";
> + cfg->name = "STM32 SD/MMC";
>  
>   cfg->host_caps = 0;
>   if (cfg->f_max > 2500)

Reviewed-by: Patrice Chotard 

Thanks

Patrice

[PATCH 4/5] imx8mp_evk: Select the watchdog driver

[Fabio Estevam]

Currently watchdog driver is not selected, which causes system to reboot
after staying 60s in the U-Boot prompt.

Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
properly serviced.

Signed-off-by: Fabio Estevam 
---
 configs/imx8mp_evk_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/imx8mp_evk_defconfig b/configs/imx8mp_evk_defconfig
index 44b2935f69..0693658365 100644
--- a/configs/imx8mp_evk_defconfig
+++ b/configs/imx8mp_evk_defconfig
@@ -82,5 +82,4 @@ CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_PSCI=y
 CONFIG_SYSRESET_WATCHDOG=y
-# CONFIG_WATCHDOG is not set
 CONFIG_IMX_WATCHDOG=y
-- 
2.17.1

[PATCH 5/5] verdin-imx8mm: Select the watchdog driver

[Fabio Estevam]

Currently watchdog driver is not selected, which causes system to reboot
after staying 60s in the U-Boot prompt.

Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
properly serviced.

Signed-off-by: Fabio Estevam 
---
 configs/verdin-imx8mm_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/verdin-imx8mm_defconfig b/configs/verdin-imx8mm_defconfig
index c68b299a95..f5b6e03251 100644
--- a/configs/verdin-imx8mm_defconfig
+++ b/configs/verdin-imx8mm_defconfig
@@ -99,5 +99,4 @@ CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_PSCI=y
 CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
-# CONFIG_WATCHDOG is not set
 CONFIG_IMX_WATCHDOG=y
-- 
2.17.1

Re: [PATCH] clk: stm32mp1: fix CK_MPU calculation

[Patrice CHOTARD]

On 4/24/20 3:47 PM, Patrick Delaunay wrote:
> From: Lionel Debieve 
>
> When the CK_MPU used PLL1_MPUDIV, the current rate is
> wrong. The clock must use stm32mp1_mpu_div as a shift
> value. Fix the check value used to enter PLL_MPUDIV.
>
> Signed-off-by: Lionel Debieve 
> Signed-off-by: Patrick Delaunay 
> ---
>
>  drivers/clk/clk_stm32mp1.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
> index 50df8425bf..0d0ea43fd2 100644
> --- a/drivers/clk/clk_stm32mp1.c
> +++ b/drivers/clk/clk_stm32mp1.c
> @@ -954,10 +954,11 @@ static ulong stm32mp1_clk_get(struct stm32mp1_clk_priv 
> *priv, int p)
>   case RCC_MPCKSELR_PLL:
>   case RCC_MPCKSELR_PLL_MPUDIV:
>   clock = stm32mp1_read_pll_freq(priv, _PLL1, _DIV_P);
> - if (p == RCC_MPCKSELR_PLL_MPUDIV) {
> + if ((reg & RCC_SELR_SRC_MASK) ==
> + RCC_MPCKSELR_PLL_MPUDIV) {
>   reg = readl(priv->base + RCC_MPCKDIVR);
> - clock /= stm32mp1_mpu_div[reg &
> -   RCC_MPUDIV_MASK];
> + clock >>= stm32mp1_mpu_div[reg &
> + RCC_MPUDIV_MASK];
>   }
>   break;
>   }
>
> Reviewed-by: Patrice Chotard 
>
> Thanks
>
> Patrice
>

[PATCH 1/5] imx8mm_evk: Select the watchdog driver

[Fabio Estevam]

Currently the watchdog driver is not selected, which causes the following
warnings in both SPL and U-Boot proper:

U-Boot SPL 2020.07-rc1-00387-g67887903af (May 07 2020 - 23:49:27 -0300)
Normal Boot
WDT:   Started without servicing (60s timeout)
Trying to boot from MMC1


U-Boot 2020.07-rc1-00387-g67887903af (May 07 2020 - 23:49:27 -0300)

CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
Reset cause: POR
Model: FSL i.MX8MM EVK board
DRAM:  2 GiB
WDT:   Started without servicing (60s timeout)


System reboots after staying 60s in the U-Boot prompt.

Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
properly serviced.

Suggested-by: Marek Vasut 
Signed-off-by: Fabio Estevam 
---
 configs/imx8mm_evk_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
index 9a72f46f27..e7abf6b07c 100644
--- a/configs/imx8mm_evk_defconfig
+++ b/configs/imx8mm_evk_defconfig
@@ -85,5 +85,4 @@ CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_PSCI=y
 CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
-# CONFIG_WATCHDOG is not set
 CONFIG_IMX_WATCHDOG=y
-- 
2.17.1

[PATCH 2/5] imx8mn_ddr4_evk: Select the watchdog driver

[Fabio Estevam]

Currently watchdog driver is not selected, which causes system to reboot
after staying 60s in the U-Boot prompt.

Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
properly serviced.

Signed-off-by: Fabio Estevam 
---
 configs/imx8mn_ddr4_evk_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/imx8mn_ddr4_evk_defconfig 
b/configs/imx8mn_ddr4_evk_defconfig
index bc6014d73a..7fd443f37e 100644
--- a/configs/imx8mn_ddr4_evk_defconfig
+++ b/configs/imx8mn_ddr4_evk_defconfig
@@ -79,5 +79,4 @@ CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_PSCI=y
 CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
-# CONFIG_WATCHDOG is not set
 CONFIG_IMX_WATCHDOG=y
-- 
2.17.1

[PATCH 3/5] imx8mm_beacon: Select the watchdog driver

[Fabio Estevam]

Currently watchdog driver is not selected, which causes system to reboot
after staying 60s in the U-Boot prompt.

Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
properly serviced.

Signed-off-by: Fabio Estevam 
---
 configs/imx8mm_beacon_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig
index b935d72360..a518963f48 100644
--- a/configs/imx8mm_beacon_defconfig
+++ b/configs/imx8mm_beacon_defconfig
@@ -100,5 +100,4 @@ CONFIG_SPL_SYSRESET=y
 CONFIG_SYSRESET_PSCI=y
 CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_DM_THERMAL=y
-# CONFIG_WATCHDOG is not set
 CONFIG_IMX_WATCHDOG=y
-- 
2.17.1

Re: [PATCH v2 02/12] arm: stm32mp: spl: update error management in board_init_f

[Patrice CHOTARD]

On 4/22/20 2:29 PM, Patrick Delaunay wrote:
> Call hang when an error is detected for probe of any driver
> needed for console or DDR init: clk, reset and pincontrol
>
> NB: previous behavior with a return in board_init_f() was not correct;
> DDR is not initialized and SPL execution can't continue
>
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2:
> - simplify patch after Wolfgang review, as console init alway failed when
>   drivers can't probe (remove printf after preloader_console_init call)
>
>  arch/arm/mach-stm32mp/spl.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
> index ca4231cd0d..445c5a231c 100644
> --- a/arch/arm/mach-stm32mp/spl.c
> +++ b/arch/arm/mach-stm32mp/spl.c
> @@ -92,19 +92,19 @@ void board_init_f(ulong dummy)
>   ret = uclass_get_device(UCLASS_CLK, 0, );
>   if (ret) {
>   debug("Clock init failed: %d\n", ret);
> - return;
> + hang();
>   }
>  
>   ret = uclass_get_device(UCLASS_RESET, 0, );
>   if (ret) {
>   debug("Reset init failed: %d\n", ret);
> - return;
> + hang();
>   }
>  
>   ret = uclass_get_device(UCLASS_PINCTRL, 0, );
>   if (ret) {
>   debug("%s: Cannot find pinctrl device\n", __func__);
> - return;
> + hang();
>   }
>  
>   /* enable console uart printing */

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [Uboot-stm32] [PATCH v2 04/12] board: stm32mp1: update management of boot-led

[Patrice CHOTARD]

On 4/22/20 2:29 PM, Patrick Delaunay wrote:
> Force boot-led ON and no more rely on default-state.
> This patch avoid device-tree modification for U-Boot.
>
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2:
> - use CONFIG_IS_ENABLED(LED) everywhere
>
>  arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi |  4 ---
>  arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi |  4 ---
>  board/st/stm32mp1/stm32mp1.c | 33 
>  3 files changed, 16 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> index 5844d41c53..c52abeb1e7 100644
> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> @@ -27,10 +27,6 @@
>   default-state = "off";
>   status = "okay";
>   };
> -
> - blue {
> - default-state = "on";
> - };
>   };
>  };
>  
> diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> index ed2f024be9..84af7fa47b 100644
> --- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> @@ -28,10 +28,6 @@
>   default-state = "off";
>   status = "okay";
>   };
> -
> - blue {
> - default-state = "on";
> - };
>   };
>  };
>  
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index d85a57cee2..6a3e2e64bf 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -260,7 +260,6 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev, 
> const char *name)
>  
>  #endif /* CONFIG_USB_GADGET */
>  
> -#ifdef CONFIG_LED
>  static int get_led(struct udevice **dev, char *led_string)
>  {
>   char *led_name;
> @@ -286,6 +285,9 @@ static int setup_led(enum led_state_t cmd)
>   struct udevice *dev;
>   int ret;
>  
> + if (!CONFIG_IS_ENABLED(LED))
> + return 0;
> +
>   ret = get_led(, "u-boot,boot-led");
>   if (ret)
>   return ret;
> @@ -293,32 +295,29 @@ static int setup_led(enum led_state_t cmd)
>   ret = led_set_state(dev, cmd);
>   return ret;
>  }
> -#endif
>  
>  static void __maybe_unused led_error_blink(u32 nb_blink)
>  {
> -#ifdef CONFIG_LED
>   int ret;
>   struct udevice *led;
>   u32 i;
> -#endif
>  
>   if (!nb_blink)
>   return;
>  
> -#ifdef CONFIG_LED
> - ret = get_led(, "u-boot,error-led");
> - if (!ret) {
> - /* make u-boot,error-led blinking */
> - /* if U32_MAX and 125ms interval, for 17.02 years */
> - for (i = 0; i < 2 * nb_blink; i++) {
> - led_set_state(led, LEDST_TOGGLE);
> - mdelay(125);
> - WATCHDOG_RESET();
> + if (CONFIG_IS_ENABLED(LED)) {
> + ret = get_led(, "u-boot,error-led");
> + if (!ret) {
> + /* make u-boot,error-led blinking */
> + /* if U32_MAX and 125ms interval, for 17.02 years */
> + for (i = 0; i < 2 * nb_blink; i++) {
> + led_set_state(led, LEDST_TOGGLE);
> + mdelay(125);
> + WATCHDOG_RESET();
> + }
> + led_set_state(led, LEDST_ON);
>   }
> - led_set_state(led, LEDST_ON);
>   }
> -#endif
>  
>   /* infinite: the boot process must be stopped */
>   if (nb_blink == U32_MAX)
> @@ -651,6 +650,8 @@ int board_init(void)
>   if (CONFIG_IS_ENABLED(LED))
>   led_default_state();
>  
> + setup_led(LEDST_ON);
> +
>   return 0;
>  }
>  
> @@ -705,9 +706,7 @@ int board_late_init(void)
>  
>  void board_quiesce_devices(void)
>  {
> -#ifdef CONFIG_LED
>   setup_led(LEDST_OFF);
> -#endif
>  }
>  
>  /* eth init function : weak called in eqos driver */

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [Uboot-stm32] [PATCH v2 07/12] board: stm32mp1: remove bootdelay configuration for usb or serial boot

[Patrice CHOTARD]

On 4/22/20 2:29 PM, Patrick Delaunay wrote:
> It is not allowed to change the user setting of bootdelay, so
> remove the check of the boot-source to disable it dynamically
> in board_late_init()
>
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2:
> - remove bootdelay configuration after Wolfgang's comment on dropped patch
>   [11/16] board: stm32mp1: check env_get result in board_late_init
>
>  board/st/stm32mp1/stm32mp1.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 280c5b7ae4..687d605e29 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -692,7 +692,6 @@ int board_init(void)
>  
>  int board_late_init(void)
>  {
> - char *boot_device;
>  #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>   const void *fdt_compat;
>   int fdt_compat_len;
> @@ -740,11 +739,6 @@ int board_late_init(void)
>   board_check_usb_power();
>  #endif /* CONFIG_ADC */
>  
> - /* Check the boot-source to disable bootdelay */
> - boot_device = env_get("boot_device");
> - if (!strcmp(boot_device, "serial") || !strcmp(boot_device, "usb"))
> - env_set("bootdelay", "0");
> -
>   return 0;
>  }
>  
>
> Reviewed-by: Patrice Chotard 
>
> Thanks
>
> Patrice
>

Re: [Uboot-stm32] [PATCH 9/9] ARM: dts: stm32mp1: use OPP information for PLL1 settings in SPL

[Patrice CHOTARD]

Hi Patrick

On 4/21/20 5:11 PM, Patrick Delaunay wrote:
> This patch allows to switch the CPU frequency to 800MHz on the
> ST Microelectronics board (DK1/DK2 and EV1) when it supported by the HW
> (for STM32MP15xD and STM32MP15xF).
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/dts/stm32mp15-u-boot.dtsi   | 10 ++
>  arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi |  9 -
>  arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi |  9 -
>  3 files changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15-u-boot.dtsi 
> b/arch/arm/dts/stm32mp15-u-boot.dtsi
> index e0b1223de8..497c1a01ec 100644
> --- a/arch/arm/dts/stm32mp15-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15-u-boot.dtsi
> @@ -63,6 +63,16 @@
>   u-boot,dm-pre-reloc;
>  };
>  
> +_opp_table {
> + u-boot,dm-spl;
> + opp-65000 {
> + u-boot,dm-spl;
> + };
> + opp-8 {
> + u-boot,dm-spl;
> + };
> +};
> +
>   {
>   u-boot,dm-pre-reloc;
>  };
> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> index 5844d41c53..97d5ea43c3 100644
> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> @@ -122,15 +122,6 @@
>   CLK_LPTIM45_LSE
>   >;
>  
> - /* VCO = 1300.0 MHz => P = 650 (CPU) */
> - pll1: st,pll@0 {
> - compatible = "st,stm32mp1-pll";
> - reg = <0>;
> - cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> - frac = < 0x800 >;
> - u-boot,dm-pre-reloc;
> - };
> -
>   /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
>   pll2: st,pll@1 {
>   compatible = "st,stm32mp1-pll";
> diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> index ed2f024be9..9f9aa4ac65 100644
> --- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> @@ -119,15 +119,6 @@
>   CLK_LPTIM45_LSE
>   >;
>  
> - /* VCO = 1300.0 MHz => P = 650 (CPU) */
> - pll1: st,pll@0 {
> - compatible = "st,stm32mp1-pll";
> - reg = <0>;
> - cfg = < 2 80 0 0 0 PQR(1,0,0) >;
> - frac = < 0x800 >;
> - u-boot,dm-pre-reloc;
> - };
> -
>   /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
>   pll2: st,pll@1 {
>   compatible = "st,stm32mp1-pll";

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 7/9] board: st: stpmic1: add function stmpic_buck1_set

[Patrice CHOTARD]

Hi Patrick

On 4/21/20 5:11 PM, Patrick Delaunay wrote:
> Add a function stmpic_buck1_set to configure buck1 voltage
> in SPL as regulator framework is not available.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  board/st/common/stpmic1.c | 24 
>  board/st/common/stpmic1.h |  6 ++
>  2 files changed, 30 insertions(+)
>  create mode 100644 board/st/common/stpmic1.h
>
> diff --git a/board/st/common/stpmic1.c b/board/st/common/stpmic1.c
> index ca10a2246b..a912242ad9 100644
> --- a/board/st/common/stpmic1.c
> +++ b/board/st/common/stpmic1.c
> @@ -9,6 +9,30 @@
>  #include 
>  #include 
>  
> +int stmpic_buck1_set(u32 voltage_mv)
> +{
> + struct udevice *dev;
> + int ret;
> + u32 value;
> +
> + ret = uclass_get_device_by_driver(UCLASS_PMIC,
> +   DM_GET_DRIVER(pmic_stpmic1), );
> + if (ret)
> + return ret;
> +
> + /* VDDCORE= STMPCI1 BUCK1 ramp=+25mV, 5 => 725mV, 36 => 1500mV */
> + value = ((voltage_mv - 725) / 25) + 5;
> + if (value < 5)
> + value = 5;
> + if (value > 36)
> + value = 36;
> +
> + return pmic_clrsetbits(dev,
> +STPMIC1_BUCKX_MAIN_CR(STPMIC1_BUCK1),
> +STPMIC1_BUCK_VOUT_MASK,
> +STPMIC1_BUCK_VOUT(value));
> +}
> +
>  int board_ddr_power_init(enum ddr_type ddr_type)
>  {
>   struct udevice *dev;
> diff --git a/board/st/common/stpmic1.h b/board/st/common/stpmic1.h
> new file mode 100644
> index 00..a020dddbe0
> --- /dev/null
> +++ b/board/st/common/stpmic1.h
> @@ -0,0 +1,6 @@
> +/* SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause */
> +/*
> + * Copyright (C) 2020, STMicroelectronics - All Rights Reserved
> + */
> +
> +int stmpic_buck1_set(u32 voltage_mv);


Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 8/9] board: stm32mp1: update vddcore in SPL

[Patrice CHOTARD]

Hi Patrick

On 4/21/20 5:11 PM, Patrick Delaunay wrote:
> For board using STPMIC1, the vddcore is provided by BUCK1 of STMPIC1
> and need to be updated for 800MHz support and only after the clock
> tree initialization.
>
> The VDDCORE voltage value in provide by clock driver, saved in global
> variable  opp_voltage_mv and udpated SPL in board_early_init_f().
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  board/st/stm32mp1/spl.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/board/st/stm32mp1/spl.c b/board/st/stm32mp1/spl.c
> index e65ff288ea..616fb1d6f2 100644
> --- a/board/st/stm32mp1/spl.c
> +++ b/board/st/stm32mp1/spl.c
> @@ -12,6 +12,26 @@
>  #include 
>  #include 
>  #include 
> +#include "../common/stpmic1.h"
> +
> +/* board early initialisation in board_f: need to use global variable */
> +#if defined(CONFIG_PMIC_STPMIC1) && defined(CONFIG_SPL_POWER_SUPPORT)
> +static u32 opp_voltage_mv __section(".data");
> +
> +void board_vddcore_init(u32 voltage_mv)
> +{
> + opp_voltage_mv = voltage_mv;
> +}
> +#endif
> +
> +int board_early_init_f(void)
> +{
> +#if defined(CONFIG_PMIC_STPMIC1) && defined(CONFIG_SPL_POWER_SUPPORT)
> + stmpic_buck1_set(opp_voltage_mv);
> +#endif
> +
> + return 0;
> +}
>  
>  void spl_board_init(void)
>  {

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [PATCH 6/9] arm: stm32mp: add weak function to save vddcore

[Patrice CHOTARD]

Hi Patrick

On 4/21/20 5:11 PM, Patrick Delaunay wrote:
> Add a weak functions to save the vddcore voltage value provided
> in the OPP node when the clock tree is initialized.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/include/mach/sys_proto.h | 3 +++
>  drivers/clk/clk_stm32mp1.c | 5 +
>  2 files changed, 8 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/include/mach/sys_proto.h 
> b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
> index 1617126bea..55193b5c2d 100644
> --- a/arch/arm/mach-stm32mp/include/mach/sys_proto.h
> +++ b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
> @@ -43,3 +43,6 @@ void get_soc_name(char name[SOC_NAME_SIZE]);
>  u32 get_bootmode(void);
>  
>  int setup_mac_address(void);
> +
> +/* board power management : configure vddcore according OPP */
> +void board_vddcore_init(u32 voltage_mv);
> diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
> index baacc1abb5..5fccc03ba7 100644
> --- a/drivers/clk/clk_stm32mp1.c
> +++ b/drivers/clk/clk_stm32mp1.c
> @@ -1225,6 +1225,10 @@ bool stm32mp1_supports_opp(u32 opp_id, u32 cpu_type)
>   }
>  }
>  
> +__weak void board_vddcore_init(u32 voltage_mv)
> +{
> +}
> +
>  /*
>   * gets OPP parameters (frequency in KHz and voltage in mV) from
>   * an OPP table subnode. Platform HW support capabilities are also checked.
> @@ -1302,6 +1306,7 @@ int stm32mp1_get_max_opp_freq(struct stm32mp1_clk_priv 
> *priv, u64 *freq_hz)
>   return -FDT_ERR_NOTFOUND;
>  
>   *freq_hz = (u64)1000U * freq;
> + board_vddcore_init(voltage);
>  
>   return 0;
>  }

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [PATCH 4/9] stm32mp1: clk: configure pll1 with OPP

[Patrice CHOTARD]

Hi Patrick

On 4/21/20 5:11 PM, Patrick Delaunay wrote:
> The PLL1 node (st,pll1) is optional in device tree, the max supported
> frequency define in OPP node is used when the node is absent.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  .../clock/st,stm32mp1.txt |   4 +
>  drivers/clk/clk_stm32mp1.c| 290 --
>  2 files changed, 266 insertions(+), 28 deletions(-)
>
> diff --git a/doc/device-tree-bindings/clock/st,stm32mp1.txt 
> b/doc/device-tree-bindings/clock/st,stm32mp1.txt
> index a3d427911d..4d4136d2fc 100644
> --- a/doc/device-tree-bindings/clock/st,stm32mp1.txt
> +++ b/doc/device-tree-bindings/clock/st,stm32mp1.txt
> @@ -87,6 +87,10 @@ Optional Properties:
>are listed with associated reg 0 to 3.
>PLLx is off when the associated node is absent or deactivated.
>  
> +  For PLL1, when the node is absent, the frequency of the OPP node is used
> +  to compute the PLL setting (see compatible "operating-points-v2" in
> +  opp/opp.txt for details).
> +
>Here are the available properties for each PLL node:
>  - compatible: should be "st,stm32mp1-pll"
>  
> diff --git a/drivers/clk/clk_stm32mp1.c b/drivers/clk/clk_stm32mp1.c
> index 50df8425bf..baacc1abb5 100644
> --- a/drivers/clk/clk_stm32mp1.c
> +++ b/drivers/clk/clk_stm32mp1.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -641,8 +642,18 @@ static const struct stm32mp1_clk_sel 
> stm32mp1_clk_sel[_PARENT_SEL_NB] = {
>  };
>  
>  #ifdef STM32MP1_CLOCK_TREE_INIT
> +
>  /* define characteristic of PLL according type */
> +#define DIVM_MIN 0
> +#define DIVM_MAX 63
>  #define DIVN_MIN 24
> +#define DIVP_MIN 0
> +#define DIVP_MAX 127
> +#define FRAC_MAX 8192
> +
> +#define PLL1600_VCO_MIN  8
> +#define PLL1600_VCO_MAX  16
> +
>  static const struct stm32mp1_pll stm32mp1_pll[PLL_TYPE_NB] = {
>   [PLL_800] = {
>   .refclk_min = 4,
> @@ -1186,6 +1197,208 @@ static ulong stm32mp1_clk_get_rate(struct clk *clk)
>  }
>  
>  #ifdef STM32MP1_CLOCK_TREE_INIT
> +
> +bool stm32mp1_supports_opp(u32 opp_id, u32 cpu_type)
> +{
> + unsigned int id;
> +
> + switch (opp_id) {
> + case 1:
> + case 2:
> + id = opp_id;
> + break;
> + default:
> + id = 1; /* default value */
> + break;
> + }
> +
> + switch (cpu_type) {
> + case CPU_STM32MP157Fxx:
> + case CPU_STM32MP157Dxx:
> + case CPU_STM32MP153Fxx:
> + case CPU_STM32MP153Dxx:
> + case CPU_STM32MP151Fxx:
> + case CPU_STM32MP151Dxx:
> + return true;
> + default:
> + return id == 1;
> + }
> +}
> +
> +/*
> + * gets OPP parameters (frequency in KHz and voltage in mV) from
> + * an OPP table subnode. Platform HW support capabilities are also checked.
> + * Returns 0 on success and a negative FDT error code on failure.
> + */
> +static int stm32mp1_get_opp(u32 cpu_type, ofnode subnode,
> + u32 *freq_khz, u32 *voltage_mv)
> +{
> + u32 opp_hw;
> + u64 read_freq_64;
> + u32 read_voltage_32;
> +
> + *freq_khz = 0;
> + *voltage_mv = 0;
> +
> + opp_hw = ofnode_read_u32_default(subnode, "opp-supported-hw", 0);
> + if (opp_hw)
> + if (!stm32mp1_supports_opp(opp_hw, cpu_type))
> + return -FDT_ERR_BADVALUE;
> +
> + read_freq_64 = ofnode_read_u64_default(subnode, "opp-hz", 0) /
> +1000ULL;
> + read_voltage_32 = ofnode_read_u32_default(subnode, "opp-microvolt", 0) /
> +   1000U;
> +
> + if (!read_voltage_32 || !read_freq_64)
> + return -FDT_ERR_NOTFOUND;
> +
> + /* Frequency value expressed in KHz must fit on 32 bits */
> + if (read_freq_64 > U32_MAX)
> + return -FDT_ERR_BADVALUE;
> +
> + /* Millivolt value must fit on 16 bits */
> + if (read_voltage_32 > U16_MAX)
> + return -FDT_ERR_BADVALUE;
> +
> + *freq_khz = (u32)read_freq_64;
> + *voltage_mv = read_voltage_32;
> +
> + return 0;
> +}
> +
> +/*
> + * parses OPP table in DT and finds the parameters for the
> + * highest frequency supported by the HW platform.
> + * Returns 0 on success and a negative FDT error code on failure.
> + */
> +int stm32mp1_get_max_opp_freq(struct stm32mp1_clk_priv *priv, u64 *freq_hz)
> +{
> + ofnode node, subnode;
> + int ret;
> + u32 freq = 0U, voltage = 0U;
> + u32 cpu_type = get_cpu_type();
> +
> + node = ofnode_by_compatible(ofnode_null(), "operating-points-v2");
> + if (!ofnode_valid(node))
> + return -FDT_ERR_NOTFOUND;
> +
> + ofnode_for_each_subnode(subnode, node) {
> + unsigned int read_freq;
> + unsigned int read_voltage;
> +
> + ret = stm32mp1_get_opp(cpu_type, subnode,
> +_freq, _voltage);
> + if (ret)
> +   

Re: [PATCH 5/9] ARM: stm32: Add board_early_init_f() to SPL

[Patrice CHOTARD]

Hi Patrick

On 4/21/20 5:11 PM, Patrick Delaunay wrote:
> From: Marek Vasut 
>
> Add weak implementation of board_early_init_f() hook into the
> STM32MP1 SPL. This can be used to read out e.g. configuration
> straps before initializing the DRAM.
>
> Signed-off-by: Marek Vasut 
> Cc: Manivannan Sadhasivam 
> Cc: Patrick Delaunay 
> Cc: Patrice Chotard 
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/mach-stm32mp/spl.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
> index ca4231cd0d..cd14d1065e 100644
> --- a/arch/arm/mach-stm32mp/spl.c
> +++ b/arch/arm/mach-stm32mp/spl.c
> @@ -76,6 +76,11 @@ void spl_display_print(void)
>  }
>  #endif
>  
> +__weak int board_early_init_f(void)
> +{
> + return 0;
> +}
> +
>  void board_init_f(ulong dummy)
>  {
>   struct udevice *dev;
> @@ -110,6 +115,12 @@ void board_init_f(ulong dummy)
>   /* enable console uart printing */
>   preloader_console_init();
>  
> + ret = board_early_init_f();
> + if (ret) {
> + debug("board_early_init_f() failed: %d\n", ret);
> + hang();
> + }
> +
>   ret = uclass_get_device(UCLASS_RAM, 0, );
>   if (ret) {
>   printf("DRAM init failed: %d\n", ret);

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [Uboot-stm32] [PATCH 3/9] board: st: create common file stpmic1.c

[Patrice CHOTARD]

Hi Patrick

On 4/21/20 5:11 PM, Patrick Delaunay wrote:
> Move function board_ddr_power_init() in a new file stpmic1 in
> board/st/common to avoid duplicated code in each board using
> stpmic1
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  board/dhelectronics/dh_stm32mp1/Makefile |   2 +-
>  board/st/common/Makefile |   1 +
>  board/st/common/stpmic1.c| 162 +++
>  board/st/stm32mp1/board.c| 158 --
>  4 files changed, 164 insertions(+), 159 deletions(-)
>  create mode 100644 board/st/common/stpmic1.c
>
> diff --git a/board/dhelectronics/dh_stm32mp1/Makefile 
> b/board/dhelectronics/dh_stm32mp1/Makefile
> index b42c4e4c04..04586c0a28 100644
> --- a/board/dhelectronics/dh_stm32mp1/Makefile
> +++ b/board/dhelectronics/dh_stm32mp1/Makefile
> @@ -7,4 +7,4 @@ ifdef CONFIG_SPL_BUILD
>  obj-y += ../../st/stm32mp1/spl.o
>  endif
>  
> -obj-y += ../../st/stm32mp1/board.o board.o
> +obj-y += ../../st/common/stpmic1.o board.o
> diff --git a/board/st/common/Makefile b/board/st/common/Makefile
> index 8553606b90..78bc0307f7 100644
> --- a/board/st/common/Makefile
> +++ b/board/st/common/Makefile
> @@ -4,3 +4,4 @@
>  #
>  
>  obj-$(CONFIG_CMD_STBOARD) += cmd_stboard.o
> +obj-$(CONFIG_PMIC_STPMIC1) += stpmic1.o
> diff --git a/board/st/common/stpmic1.c b/board/st/common/stpmic1.c
> new file mode 100644
> index 00..ca10a2246b
> --- /dev/null
> +++ b/board/st/common/stpmic1.c
> @@ -0,0 +1,162 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +/*
> + * Copyright (C) 2020, STMicroelectronics - All Rights Reserved
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int board_ddr_power_init(enum ddr_type ddr_type)
> +{
> + struct udevice *dev;
> + bool buck3_at_180v = false;
> + int ret;
> + u32 buck2;
> +
> + ret = uclass_get_device_by_driver(UCLASS_PMIC,
> +   DM_GET_DRIVER(pmic_stpmic1), );
> + if (ret)
> + /* No PMIC on board */
> + return 0;
> +
> + switch (ddr_type) {
> + case STM32MP_DDR3:
> + /* VTT = Set LDO3 to sync mode */
> + ret = pmic_reg_read(dev, STPMIC1_LDOX_MAIN_CR(STPMIC1_LDO3));
> + if (ret < 0)
> + return ret;
> +
> + ret &= ~STPMIC1_LDO3_MODE;
> + ret &= ~STPMIC1_LDO12356_VOUT_MASK;
> + ret |= STPMIC1_LDO_VOUT(STPMIC1_LDO3_DDR_SEL);
> +
> + ret = pmic_reg_write(dev, STPMIC1_LDOX_MAIN_CR(STPMIC1_LDO3),
> +  ret);
> + if (ret < 0)
> + return ret;
> +
> + /* VDD_DDR = Set BUCK2 to 1.35V */
> + ret = pmic_clrsetbits(dev,
> +   STPMIC1_BUCKX_MAIN_CR(STPMIC1_BUCK2),
> +   STPMIC1_BUCK_VOUT_MASK,
> +   STPMIC1_BUCK2_135V);
> + if (ret < 0)
> + return ret;
> +
> + /* Enable VDD_DDR = BUCK2 */
> + ret = pmic_clrsetbits(dev,
> +   STPMIC1_BUCKX_MAIN_CR(STPMIC1_BUCK2),
> +   STPMIC1_BUCK_ENA, STPMIC1_BUCK_ENA);
> + if (ret < 0)
> + return ret;
> +
> + mdelay(STPMIC1_DEFAULT_START_UP_DELAY_MS);
> +
> + /* Enable VREF */
> + ret = pmic_clrsetbits(dev, STPMIC1_REFDDR_MAIN_CR,
> +   STPMIC1_VREF_ENA, STPMIC1_VREF_ENA);
> + if (ret < 0)
> + return ret;
> +
> + mdelay(STPMIC1_DEFAULT_START_UP_DELAY_MS);
> +
> + /* Enable VTT = LDO3 */
> + ret = pmic_clrsetbits(dev,
> +   STPMIC1_LDOX_MAIN_CR(STPMIC1_LDO3),
> +   STPMIC1_LDO_ENA, STPMIC1_LDO_ENA);
> + if (ret < 0)
> + return ret;
> +
> + mdelay(STPMIC1_DEFAULT_START_UP_DELAY_MS);
> +
> + break;
> +
> + case STM32MP_LPDDR2_16:
> + case STM32MP_LPDDR2_32:
> + case STM32MP_LPDDR3_16:
> + case STM32MP_LPDDR3_32:
> + /*
> +  * configure VDD_DDR1 = LDO3
> +  * Set LDO3 to 1.8V
> +  * + bypass mode if BUCK3 = 1.8V
> +  * + normal mode if BUCK3 != 1.8V
> +  */
> + ret = pmic_reg_read(dev,
> + STPMIC1_BUCKX_MAIN_CR(STPMIC1_BUCK3));
> + if (ret < 0)
> + return ret;
> +
> + if ((ret & STPMIC1_BUCK3_180V) == STPMIC1_BUCK3_180V)
> + buck3_at_180v = true;
> +
> + ret = pmic_reg_read(dev, STPMIC1_LDOX_MAIN_CR(STPMIC1_LDO3));
> + if (ret < 0)
> + return ret;
> +
> + ret &= ~STPMIC1_LDO3_MODE;
> + ret &= 

Re: [Uboot-stm32] [PATCH 2/9] ARM: dts: stm32: add cpufreq support on stm32mp15x

[Patrice CHOTARD]

Hi Patrick

On 4/21/20 5:11 PM, Patrick Delaunay wrote:
> This commit adds cpufreq support on stm32mp15x SOC. STM32 cpufreq uses
> operating points V2 bindings (no legacy). Nvmem cells have to be used to
> know the chip version and then which OPPs are available. Note that STM32
> cpufreq driver is mainly based on "cpufreq-dt" driver.
>
> Signed-off-by: Patrick Delaunay 
> ---
>
>  arch/arm/dts/stm32mp151.dtsi  | 21 +
>  arch/arm/dts/stm32mp157c-ed1.dts  |  8 
>  arch/arm/dts/stm32mp15xx-dkx.dtsi |  8 
>  3 files changed, 37 insertions(+)
>
> diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
> index f185639a46..1d465c3064 100644
> --- a/arch/arm/dts/stm32mp151.dtsi
> +++ b/arch/arm/dts/stm32mp151.dtsi
> @@ -19,6 +19,24 @@
>   compatible = "arm,cortex-a7";
>   device_type = "cpu";
>   reg = <0>;
> + operating-points-v2 = <_opp_table>;
> + nvmem-cells = <_number_otp>;
> + nvmem-cell-names = "part_number";
> + };
> + };
> +
> + cpu0_opp_table: cpu0-opp-table {
> + compatible = "operating-points-v2";
> + opp-shared;
> + opp-65000 {
> + opp-hz = /bits/ 64 <65000>;
> + opp-microvolt = <120>;
> + opp-supported-hw = <0x1>;
> + };
> + opp-8 {
> + opp-hz = /bits/ 64 <8>;
> + opp-microvolt = <135>;
> + opp-supported-hw = <0x2>;
>   };
>   };
>  
> @@ -1512,6 +1530,9 @@
>   reg = <0x5c005000 0x400>;
>   #address-cells = <1>;
>   #size-cells = <1>;
> + part_number_otp: part_number_otp@4 {
> + reg = <0x4 0x1>;
> + };
>   ts_cal1: calib@5c {
>   reg = <0x5c 0x2>;
>   };
> diff --git a/arch/arm/dts/stm32mp157c-ed1.dts 
> b/arch/arm/dts/stm32mp157c-ed1.dts
> index 54af7c97b3..7215eb4768 100644
> --- a/arch/arm/dts/stm32mp157c-ed1.dts
> +++ b/arch/arm/dts/stm32mp157c-ed1.dts
> @@ -107,6 +107,14 @@
>   };
>  };
>  
> +{
> + cpu-supply = <>;
> +};
> +
> +{
> + cpu-supply = <>;
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_ch1_pins_a _ch2_pins_a>;
> diff --git a/arch/arm/dts/stm32mp15xx-dkx.dtsi 
> b/arch/arm/dts/stm32mp15xx-dkx.dtsi
> index 42d3f0cb2d..861280afe8 100644
> --- a/arch/arm/dts/stm32mp15xx-dkx.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dkx.dtsi
> @@ -116,6 +116,14 @@
>   status = "okay";
>  };
>  
> +{
> + cpu-supply = <>;
> +};
> +
> +{
> + cpu-supply = <>;
> +};
> +
>   {
>   status = "okay";
>   pinctrl-0 = <_rgmii_pins_a>;

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: [PATCH 1/9] arm: stm32mp: spl: add bsec driver in SPL

[Patrice CHOTARD]

Hi Patrick

On 4/21/20 5:11 PM, Patrick Delaunay wrote:
> Add the bsec driver in SPL, as it is needed by SOC part number detection
> to found the supported OPP.
>
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> I already sent in unrelated serie
>
> http://patchwork.ozlabs.org/patch/1264829/
>
> Patrick
>
>
>  arch/arm/dts/stm32mp15-u-boot.dtsi |  2 +-
>  arch/arm/mach-stm32mp/Makefile |  2 +-
>  arch/arm/mach-stm32mp/bsec.c   | 11 ++-
>  3 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15-u-boot.dtsi 
> b/arch/arm/dts/stm32mp15-u-boot.dtsi
> index 8f9535a4db..e0b1223de8 100644
> --- a/arch/arm/dts/stm32mp15-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15-u-boot.dtsi
> @@ -40,7 +40,7 @@
>  };
>  
>   {
> - u-boot,dm-pre-proper;
> + u-boot,dm-pre-reloc;
>  };
>  
>  _csi {
> diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
> index eee39c27c3..f29d6f795f 100644
> --- a/arch/arm/mach-stm32mp/Makefile
> +++ b/arch/arm/mach-stm32mp/Makefile
> @@ -6,11 +6,11 @@
>  obj-y += cpu.o
>  obj-y += dram_init.o
>  obj-y += syscon.o
> +obj-y += bsec.o
>  
>  ifdef CONFIG_SPL_BUILD
>  obj-y += spl.o
>  else
> -obj-y += bsec.o
>  obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o
>  obj-$(CONFIG_ARMV7_PSCI) += psci.o
>  endif
> diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
> index 0d5850b4a9..98a950c640 100644
> --- a/arch/arm/mach-stm32mp/bsec.c
> +++ b/arch/arm/mach-stm32mp/bsec.c
> @@ -473,20 +473,23 @@ static int stm32mp_bsec_ofdata_to_platdata(struct 
> udevice *dev)
>   return 0;
>  }
>  
> -#ifndef CONFIG_TFABOOT
>  static int stm32mp_bsec_probe(struct udevice *dev)
>  {
> +#if !defined(CONFIG_TFABOOT) && !defined(CONFIG_SPL_BUILD)
>   int otp;
>   struct stm32mp_bsec_platdata *plat = dev_get_platdata(dev);
>  
> - /* update unlocked shadow for OTP cleared by the rom code */
> + /*
> +  * update unlocked shadow for OTP cleared by the rom code
> +  * only executed in U-Boot proper when TF-A is not used
> +  */
>   for (otp = 57; otp <= BSEC_OTP_MAX_VALUE; otp++)
>   if (!bsec_read_SR_lock(plat->base, otp))
>   bsec_shadow_register(plat->base, otp);
> +#endif
>  
>   return 0;
>  }
> -#endif
>  
>  static const struct udevice_id stm32mp_bsec_ids[] = {
>   { .compatible = "st,stm32mp15-bsec" },
> @@ -500,7 +503,5 @@ U_BOOT_DRIVER(stm32mp_bsec) = {
>   .ofdata_to_platdata = stm32mp_bsec_ofdata_to_platdata,
>   .platdata_auto_alloc_size = sizeof(struct stm32mp_bsec_platdata),
>   .ops = _bsec_ops,
> -#ifndef CONFIG_TFABOOT
>   .probe = stm32mp_bsec_probe,
> -#endif
>  };

Reviewed-by: Patrice Chotard 

Thanks

Patrice

Re: Pull request v2: u-boot-spi/master

[Tom Rini]

On Mon, May 11, 2020 at 01:37:21AM +0530, Jagan Teki wrote:

> Hi Tom, 
> 
> Summary:
> - zap lpc32xx_ssp driver (Jagan)
> - rename of phy nodev call (Jagan)
> - iopoll with sleep_us (Jagan)
> - MX25R6435F flash (Ye Li)
> 
> Changes for v2:
> - rebase to master
> 
> thanks,
> Jagan.
> 
> The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d:
> 
>   Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-spi master
> 
> for you to fetch changes up to 8af1caa23728ef689d095eec1ec4e6f1d46f50e4:
> 
>   sf: Add Macronix MX25R6435F SPI NOR flash to flash parameters array 
> (2020-05-11 01:30:49 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PING][PATCH] Optionally: Set the serial# environment variable on the i.MX7.

[Stefano Babic]

Hi Mark,

patch was hidden in the flood of other patches and I am unsure if this
belongs to i.MX:

On 19.02.20 22:01, Mark G wrote:
> Enabling this new option allows the kernel to obtain the unique ID of
> the CPU when not using ATAGS.
> 
> Signed-off-by: Mark G 
> ---
> diff --git a/arch/arm/include/asm/bootm.h b/arch/arm/include/asm/bootm.h
> index a2131ca07c..64ceb36ed8 100644
> --- a/arch/arm/include/asm/bootm.h
> +++ b/arch/arm/include/asm/bootm.h
> @@ -39,7 +39,7 @@ extern void udc_disconnect(void);
>  #endif
> 
>  struct tag_serialnr;
> -#ifdef CONFIG_SERIAL_TAG
> +#if defined(CONFIG_SERIAL_TAG) || defined(CONFIG_SET_SERIAL_ENV)
>   #define BOOTM_ENABLE_SERIAL_TAG    1
>  void get_board_serial(struct tag_serialnr *serialnr);
>  #else
> diff --git a/arch/arm/mach-imx/mx7/Kconfig b/arch/arm/mach-imx/mx7/Kconfig
> index 286d36589d..4cf14d43c0 100644
> --- a/arch/arm/mach-imx/mx7/Kconfig
> +++ b/arch/arm/mach-imx/mx7/Kconfig
> @@ -71,6 +71,13 @@ config TARGET_COLIBRI_IMX7
> 
>  endchoice
> 
> +config SET_SERIAL_ENV
> +    bool "Set serial number variable from the OCOTP"
> +    help
> +  Selecting this option will populate the serial# environment
> +  variable with a unique identifier from the i.MX7 CPU. The
> +  Linux kernel will use this as the serial number of the machine.
> +

I do not see the need of *another* CONFIG_ option. To make this
available, CONFIG_SERIAL_TAG should also be on, else you cannot call
get_board_serial() to get the serial from OCOTP. It think SET_SERIAL_ENV
is quite superflous.

>  config SYS_SOC
>  default "mx7"
> 
> diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
> index 4aafeed188..208400a4a7 100644
> --- a/arch/arm/mach-imx/mx7/soc.c
> +++ b/arch/arm/mach-imx/mx7/soc.c
> @@ -344,11 +344,24 @@ int arch_misc_init(void)
>  sec_init();
>  #endif
> 
> +#ifdef CONFIG_SET_SERIAL_ENV
> +    {
> +    struct tag_serialnr serialnr;
> +    char serialbuf[sizeof(serialnr) * 2 + 8];
> +
> +    get_board_serial();
> +    snprintf(serialbuf, sizeof(serialbuf),
> + "%08lx%08lx",
> + (ulong)serialnr.high, (ulong)serialnr.low);
> +    env_set("serial#", serialbuf);
> +    }

If this should be done global, local solution should be moved too. I
mean the warp board doing exactly this in board code.

So which is the idea of this ? To move warp code and making global, or
what ?

Regards,
Stefano Babic

> +#endif
> +
>  return 0;
>  }
>  #endif
> 
> -#ifdef CONFIG_SERIAL_TAG
> +#if defined(CONFIG_SERIAL_TAG) || defined(CONFIG_SET_SERIAL_ENV)
>  /*
>   * OCOTP_TESTER
>   * i.MX 7Solo Applications Processor Reference Manual, Rev. 0.1, 08/2016


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

Re: Calling i2c set speed twice for i2c_mux_bus

[Michal Simek]

On 07. 05. 20 12:02, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 07.05.2020 um 10:18 schrieb Michal Simek:
>> On 06. 05. 20 16:47, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Tue, 5 May 2020 at 21:43, Simon Glass  wrote:

 Hi Michal,

 On Tue, 5 May 2020 at 02:26, Michal Simek 
 wrote:
>
> On 15. 04. 20 8:40, Michal Simek wrote:
>> On 10. 04. 20 10:49, Heiko Schocher wrote:
>>> Hello Michal,
>>>
>>> Am 10.04.2020 um 08:46 schrieb Michal Simek:
 Hi Heiko,

 On 10. 04. 20 7:11, Heiko Schocher wrote:
> Hello Michal,
>
> Am 09.04.2020 um 16:03 schrieb Michal Simek:
>> Hi Heiko and Simon,
>>
>> I have find out one bug in i2c class. I am using zcu104 revC
>> board
>> which
>> has dts in mainline where i2c1 has i2c mux with some channels.
>> In DT clock-frequency = <40>; is specified and it is read in
>> i2c_post_probe(). But i2c_mux_bus_drv is also UCLASS_I2C which
>> means
>> that post probe is called for it too. And because clock-frequency
>> property is not there default 100k is used.
>>
>> I think that is bug and should be fixed.
>> Heiko: Are you aware about this issue?
>
> No :-(
>
> The question is, is this a bug?

 I have never seen clock-frequency property in i2c mux bus node.
 Also I
 have looked at linux dt binding docs and nothing like that is
 specified
 there. From quick look also pca954x driver is not reading it.
>>>
>>> Indeed.
>>>
> Should a i2c bus behind a mux not be able to set his own speed?

 Not sure if that make sense but Linux will likely ignore it. I
 am not
 saying it doesn't make sense but I haven't seen this feature.
>>>
>>> Ok.
>>>
> But may as a feature (or bugfix?) if "clock-frequency" is not
> there,
> use the speed of the parent bus...?

 I was thinking about this too.
 just c quick implementation would look like this. Because it is
 i2c->i2c_mux->i2c. But maybe there is a better way how to do it.

 diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
 index 2aa3efe8aaa0..982c467deba3 100644
 --- a/drivers/i2c/i2c-uclass.c
 +++ b/drivers/i2c/i2c-uclass.c
 @@ -640,9 +640,21 @@ static int i2c_post_probe(struct udevice *dev)
    {
    #if CONFIG_IS_ENABLED(OF_CONTROL) &&
 !CONFIG_IS_ENABLED(OF_PLATDATA)
   struct dm_i2c_bus *i2c = dev_get_uclass_priv(dev);
 +   int parent_speed = I2C_SPEED_STANDARD_RATE;
 +
 +   if (dev->parent &&
 +   device_get_uclass_id(dev->parent) == UCLASS_I2C_MUX &&
 +   dev->parent->parent &&
 +   device_get_uclass_id(dev->parent->parent) ==
 UCLASS_I2C) {
 +   struct dm_i2c_bus *i2c_parent;
 +
 +   i2c_parent =
 dev_get_uclass_priv(dev->parent->parent);
 +   parent_speed = i2c_parent->speed_hz;
 +   /* Not sure if make sense to check that
 parent_speed is
 not 0 */
>>>
>>> I think this check is not needed.
>>>
 +   }

   i2c->speed_hz = dev_read_u32_default(dev,
 "clock-frequency",
 -   
 I2C_SPEED_STANDARD_RATE);
 +    parent_speed);
>>>
>>> Wow, a big if ... may this is clearer (not compile tested)?
>>>
>>> udevice *parent = dev_get_parent(dev);
>>>
>>> if (parent && device_get_uclass_id(parent) == UCLASS_I2C_MUX) {
>>>  udevice *parent2 = dev_get_parent(parent);
>>>  if (parent2 && device_get_uclass_id(parent2) == UCLASS_I2C) {
>>>  struct dm_i2c_bus *i2cp = dev_get_uclass_priv(parent2);
>>>
>>>  parent_speed = i2cp->speed_hz;
>>>  }
>>> }
>>>
>>> but Simon has a deeper DM knowledge, may there is a better approach.
>>
>> Simon: any comment on this one?
>
> Simon: Can you please comment this?
>

 OK will take a look.
>>>
>>> I wonder if i2c-mux-uclass.c should define a new uclass for muxed I2C
>>> buses, something like UCLASS_I2C_MUXED_BUS? Then you can define the
>>> behaviour correctly in i2c-mux-uclass.c.
>>>
>>> An I2C controller is not the same as a muxed bus and perhaps we should
>>> be explicitly about the differences. It probably just needs changes to
>>> the mux uclass.
>>
>> Definitely there need to be some changes in connection to i2c muxes. I
>> am aware also about bad behavior when you detect devices.
>> Just look at log below and you will see that devices on base i2c bus 

[PATCH 2/2] spi: add support for all spi modes with soft spi

[Johannes Holland]

The spi bitbanging driver did not implement all spi modes properly. Add
code to support all spi modes, honoring soft_spi_set_mode() and
defaulting to spi mode 0. Previously, CPHA was implemented inversely
(defaulting to CPHA=1) and CPOL=1 was hardcoded.

Signed-off-by: Johannes Holland 
---
 drivers/spi/soft_spi.c | 48 --
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/soft_spi.c b/drivers/spi/soft_spi.c
index b80f810bd1..08b6c53315 100644
--- a/drivers/spi/soft_spi.c
+++ b/drivers/spi/soft_spi.c
@@ -58,10 +58,12 @@ static int soft_spi_sda(struct udevice *dev, int bit)
 static int soft_spi_cs_activate(struct udevice *dev)
 {
struct udevice *bus = dev_get_parent(dev);
+   struct soft_spi_priv *priv = dev_get_priv(bus);
struct soft_spi_platdata *plat = dev_get_platdata(bus);
+   int cidle = !!(priv->mode & SPI_CPOL);
 
dm_gpio_set_value(>cs, 0);
-   dm_gpio_set_value(>sclk, 0);
+   dm_gpio_set_value(>sclk, cidle); /* to idle */
dm_gpio_set_value(>cs, 1);
 
return 0;
@@ -79,11 +81,14 @@ static int soft_spi_cs_deactivate(struct udevice *dev)
 
 static int soft_spi_claim_bus(struct udevice *dev)
 {
+   struct udevice *bus = dev_get_parent(dev);
+   struct soft_spi_priv *priv = dev_get_priv(bus);
+   int cidle = !!(priv->mode & SPI_CPOL);
/*
 * Make sure the SPI clock is in idle state as defined for
 * this slave.
 */
-   return soft_spi_scl(dev, 0);
+   return soft_spi_scl(dev, cidle);
 }
 
 static int soft_spi_release_bus(struct udevice *dev)
@@ -114,7 +119,8 @@ static int soft_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
uchar   tmpdout = 0;
const u8*txd = dout;
u8  *rxd = din;
-   int cpha = priv->mode & SPI_CPHA;
+   int cpha = !!(priv->mode & SPI_CPHA);
+   int cidle = !!(priv->mode & SPI_CPOL);
unsigned intj;
 
debug("spi_xfer: slave %s:%s dout %08X din %08X bitlen %u\n",
@@ -140,22 +146,42 @@ static int soft_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
tmpdin  = 0;
}
 
-   if (!cpha)
-   soft_spi_scl(dev, 0);
+   /*
+* CPOL 0: idle is low (0), active is high (1)
+* CPOL 1: idle is high (1), active is low (0)
+*/
+
+   /*
+* drive bit
+*  CPHA 1: CLK from idle to active
+*/
+   if (cpha)
+   soft_spi_scl(dev, !cidle);
if ((plat->flags & SPI_MASTER_NO_TX) == 0)
soft_spi_sda(dev, !!(tmpdout & 0x80));
udelay(plat->spi_delay_us);
-   if (cpha)
-   soft_spi_scl(dev, 0);
+
+   /*
+* sample bit
+*  CPHA 0: CLK from idle to active
+*  CPHA 1: CLK from active to idle
+*/
+   if (!cpha)
+   soft_spi_scl(dev, !cidle);
else
-   soft_spi_scl(dev, 1);
+   soft_spi_scl(dev, cidle);
tmpdin  <<= 1;
if ((plat->flags & SPI_MASTER_NO_RX) == 0)
tmpdin  |= dm_gpio_get_value(>miso);
tmpdout <<= 1;
udelay(plat->spi_delay_us);
-   if (cpha)
-   soft_spi_scl(dev, 1);
+
+   /*
+* drive bit
+*  CPHA 0: CLK from active to idle
+*/
+   if (!cpha)
+   soft_spi_scl(dev, cidle);
}
/*
 * If the number of bits isn't a multiple of 8, shift the last
@@ -176,7 +202,7 @@ static int soft_spi_xfer(struct udevice *dev, unsigned int 
bitlen,
 
 static int soft_spi_set_speed(struct udevice *dev, unsigned int speed)
 {
-   /* Accept any speed */
+   /* Ignore any speed settings. Speed is implemented via "spi-delay-us" */
return 0;
 }
 
-- 
2.26.1

[PATCH 1/2] tpm: add #ifndef to fix redeclaration build errors

[Johannes Holland]

tpm_tis_spi.c directly includes tpm_tis.h and tpm-v2.h which both
define the same enums (see e.g. TPM_ACCESS_VALID). Add an #ifndef to
prevent redeclaration errors.

Signed-off-by: Johannes Holland 
---
 drivers/tpm/tpm_tis.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/tpm/tpm_tis.h b/drivers/tpm/tpm_tis.h
index 947585f8e3..2a160fe05c 100644
--- a/drivers/tpm/tpm_tis.h
+++ b/drivers/tpm/tpm_tis.h
@@ -104,6 +104,7 @@ struct tpm_cmd_t {
 /* Max number of iterations after i2c NAK */
 #define MAX_COUNT  3
 
+#ifndef __TPM_V2_H
 /*
  * Max number of iterations after i2c NAK for 'long' commands
  *
@@ -127,5 +128,6 @@ enum tis_status {
TPM_STS_DATA_AVAIL  = 0x10,
TPM_STS_DATA_EXPECT = 0x08,
 };
+#endif
 
 #endif
-- 
2.26.1

[PATCH 1/2] arm: dts: khadas-vim3: include meson-g12-common-u-boot.dtsi to enable HDMI output

[Neil Armstrong]

Include the common g12 u-boot tweaks to permit enabling video output tweaks
on Khadas VIM3 boards.

Signed-off-by: Neil Armstrong 
---
 arch/arm/dts/meson-khadas-vim3-u-boot.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi 
b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
index 81fd5be378..b5da4fdfc3 100644
--- a/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
+++ b/arch/arm/dts/meson-khadas-vim3-u-boot.dtsi
@@ -4,6 +4,8 @@
  * Author: Neil Armstrong 
  */
 
+#include "meson-g12-common-u-boot.dtsi"
+
 / {
aliases {
spi0 = 
-- 
2.22.0

[PATCH 2/2] configs: khadas-vim3: enable HDMI output

[Neil Armstrong]

Enable options to permit HDMI output on Khadas VIM3 & VIM3L boards.

Signed-off-by: Neil Armstrong 
---
 configs/khadas-vim3_defconfig  | 9 +
 configs/khadas-vim3l_defconfig | 4 
 2 files changed, 13 insertions(+)

diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig
index 692138eb11..4aeab0e35d 100644
--- a/configs/khadas-vim3_defconfig
+++ b/configs/khadas-vim3_defconfig
@@ -40,6 +40,8 @@ CONFIG_ETH_DESIGNWARE=y
 CONFIG_MESON_G12A_USB_PHY=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_MESON_G12A=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_EE_POWER_DOMAIN=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_RESET=y
@@ -55,6 +57,7 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
+CONFIG_USB_KEYBOARD=y
 # CONFIG_USB_DWC3_GADGET is not set
 CONFIG_USB_DWC3_MESON_G12A=y
 CONFIG_USB_GADGET=y
@@ -63,4 +66,10 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xfada
 CONFIG_USB_GADGET_DWC2_OTG=y
 CONFIG_USB_GADGET_DWC2_OTG_PHY_BUS_WIDTH_8=y
 CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
 CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/configs/khadas-vim3l_defconfig b/configs/khadas-vim3l_defconfig
index 28c20c0d6d..887885f329 100644
--- a/configs/khadas-vim3l_defconfig
+++ b/configs/khadas-vim3l_defconfig
@@ -57,6 +57,7 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
+CONFIG_USB_KEYBOARD=y
 # CONFIG_USB_DWC3_GADGET is not set
 CONFIG_USB_DWC3_MESON_G12A=y
 CONFIG_USB_GADGET=y
@@ -66,6 +67,9 @@ CONFIG_USB_GADGET_DWC2_OTG=y
 CONFIG_USB_GADGET_DWC2_OTG_PHY_BUS_WIDTH_8=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_DM_VIDEO=y
+# CONFIG_VIDEO_BPP8 is not set
+# CONFIG_VIDEO_BPP16 is not set
+CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_VIDEO_MESON=y
 CONFIG_VIDEO_DT_SIMPLEFB=y
 CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.22.0

Re: [PATCH v2 0/2] gpio: add gpio open-drain & open-source emulation

[Neil Armstrong]

On 05/05/2020 10:43, Neil Armstrong wrote:
> When a line is in open-drain or open-source mode, U-Boot doesn't handle it
> directly.
> 
> Let's add gpio open-drain & open-source emulation in gpio u-class to make
> it transparent to driver using a gpio line from DT.
> 
> Changes since v1:
> - fixed all open-drain/open source cases
> - updated dm gpio test
> 
> Neil Armstrong (2):
>   gpio: emulate open drain & open source in dm_gpio_set_value()
>   test: dm: update test for open-drain/open-source emulation in
> gpio-uclass
> 
>  arch/sandbox/dts/test.dts  |  4 +-
>  drivers/gpio/gpio-uclass.c | 15 +++
>  test/dm/gpio.c | 89 ++
>  3 files changed, 107 insertions(+), 1 deletion(-)
> 

Applying to u-boot-amlogic

Thanks for reviewing.

Neil

Re: [PATCH v4 12/16] usb: dwc3: add make compatible for rockchip platform

[Marek Vasut]

On 5/11/20 9:57 AM, Frank Wang wrote:
[...]

> @@ -394,6 +407,12 @@ static int dwc3_glue_probe(struct udevice *dev)
>   if (ret)
>   return ret;
>  
> + if (glue->resets.count < 1) {

This condition is only true if count == 0 ?
What's the purpose of this test ?

> + ret = dwc3_glue_reset_init(child, glue);
> + if (ret)
> + return ret;
> + }
> +
>   while (child) {
>   enum usb_dr_mode dr_mode;
>  

[...]

Re: [PATCH 2/2] odroid-c2: enable USB host controller

[Neil Armstrong]

Hi,
On 10/05/2020 16:08, Beniamino Galvani wrote:
> On Sun, Aug 18, 2019 at 03:42:55PM +0200, Beniamino Galvani wrote:
>> Enable the second USB controller, which is connected to a hub with 4
>> ports. The first controller is for the OTG port and is currently not
>> supported.
>>
>> Signed-off-by: Beniamino Galvani 
>> ---
>>  arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi | 8 
>>  configs/odroid-c2_defconfig  | 7 +++
>>  include/configs/meson64.h| 5 +
>>  3 files changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi 
>> b/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
>> index c35158d7e9..484b40504d 100644
>> --- a/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
>> +++ b/arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi
>> @@ -5,3 +5,11 @@
>>   */
>>  
>>  #include "meson-gx-u-boot.dtsi"
>> +
>> + {
>> +status = "disabled";
>> +};
>> +
>> + {
>> +hnp-srp-disable;
>> +};
>> diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
>> index 8849058d33..366ea125af 100644
>> --- a/configs/odroid-c2_defconfig
>> +++ b/configs/odroid-c2_defconfig
>> @@ -16,6 +16,7 @@ CONFIG_CMD_GPIO=y
>>  CONFIG_CMD_I2C=y
>>  # CONFIG_CMD_LOADS is not set
>>  CONFIG_CMD_MMC=y
>> +CONFIG_CMD_USB=y
>>  # CONFIG_CMD_SETEXPR is not set
>>  CONFIG_CMD_REGULATOR=y
>>  CONFIG_OF_CONTROL=y
>> @@ -29,13 +30,19 @@ CONFIG_MMC_MESON_GX=y
>>  CONFIG_PHY_REALTEK=y
>>  CONFIG_DM_ETH=y
>>  CONFIG_ETH_DESIGNWARE=y
>> +CONFIG_PHY=y
>> +CONFIG_MESON_GXBB_USB_PHY=y
>>  CONFIG_PINCTRL=y
>>  CONFIG_PINCTRL_MESON_GXBB=y
>>  CONFIG_DM_REGULATOR=y
>>  CONFIG_DM_REGULATOR_FIXED=y
>> +CONFIG_DM_REGULATOR_GPIO=y
>>  CONFIG_DM_RESET=y
>>  CONFIG_DEBUG_UART_MESON=y
>>  CONFIG_DEBUG_UART_ANNOUNCE=y
>>  CONFIG_DEBUG_UART_SKIP_INIT=y
>>  CONFIG_MESON_SERIAL=y
>> +CONFIG_USB=y
>> +CONFIG_DM_USB=y
>> +CONFIG_USB_DWC2=y
>>  CONFIG_OF_LIBFDT_OVERLAY=y
>> diff --git a/include/configs/meson64.h b/include/configs/meson64.h
>> index f8d3eee292..483a8f567c 100644
>> --- a/include/configs/meson64.h
>> +++ b/include/configs/meson64.h
>> @@ -16,6 +16,11 @@
>>  #define GICC_BASE   0xc4302000
>>  #endif
>>  
>> +/* USB */
>> +#if defined(CONFIG_MESON_GXBB)
>> +#define CONFIG_DWC2_UTMI_WIDTH  16
>> +#endif
> 
> Hi Neil,
> 
> I noticed this change to the bus width configuration isn't actually
> needed. The USB port works with or without it. The kernel driver
> doesn't set 16bit mode, so can you please remove these 4 lines from
> the commit before sending the pull request?
> 
> Thanks,
> Beniamino
> 

Thanks,

I altered the commit removing this.

Neil

Re: [PATCH 6/8] net: dwc_eth_qos: Split eqos_start() to get link speed

[Patrice CHOTARD]

Hi David

On 5/9/20 8:42 AM, David Wu wrote:
> Hi Patrice,
>
> 在 2020/4/30 下午11:33, Patrice CHOTARD 写道:
>> Can you explain why you are splitting this function in 2 parts and calling 
>> these parts sequentially ?
>
> For rockchip, need to obtain the current link speed to configure the tx 
> clocks, (for example, in rgmii mode, 1000M link: 125M, 100M link: 25M, 10M 
> link is 2.5M rate) and then enable gmac. So after the adjust_link(), before 
> the start gamc, this intermediate stage needs to configure the clock 
> according to the current link speed.
>
>
Please, add these informations in the commit message

Thanks

Patrice

Re: [PATCH 00/11] Fixes for Nokia RX-51

[Lokesh Vutla]

On 14/04/20 3:53 PM, Lokesh Vutla wrote:
> 
> 
> On 13/04/20 4:11 PM, Pali Rohár wrote:
>> On Wednesday 01 April 2020 00:35:07 Pali Rohár wrote:
>>> This patch series contain fixes for Nokia RX-51 board (aka N900).
>>> After these changes it is possible to run U-Boot in qemu emulator again.
>>> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
>>> problem.
>>>
>>> Pali Rohár (11):
>>>   Nokia RX-51: Update my email address
>>>   Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
>>>   Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
>>>   Nokia RX-51: Move code from defconfig back to C header file
>>>   Nokia RX-51: Revert back onenand defitions
>>>   Nokia RX-51: Remove PART* macros
>>>   Nokia RX-51: Remember setup_console_atag option
>>>   Nokia RX-51: Enable CONFIG_CONSOLE_MUX
>>>   Nokia RX-51: Disable some unused features to decrease size of u-boot
>>> binary
>>>   Nokia RX-51: Update README.nokia_rx51
>>>   Nokia RX-51: Add automated test for running RX-51 build in qemu
>>
>> Hello! Could you please review this patch series?
> 
> Series as such looks good to me. But as I see that thread, this series could 
> not
> boot on real hardware. Is that right?
> 
> Thanks and regards,
> Lokesh
> 

Except PATCH 11, series Merged into u-boot-ti.

Thanks and regards,
Lokesh

Re: [PATCH v2] video: omap: change include order

[Lokesh Vutla]

On 04/05/20 12:57 AM, Dario Binacchi wrote:
> Apply u-boot coding style on include files order as described by the
> wiki https://www.denx.de/wiki/U-Boot/CodingStyle.
> 
> Signed-off-by: Dario Binacchi 
> 
> ---
> 
> Changes in v2:
> - Add reference to code style wiki

Merged into u-boot-ti.

Thanks and regards,
Lokesh

Re: [PATCH] net: ethernet: ti: am65-cpsw-nuss: enable 10Mbps link speed in rgmii mode

[Lokesh Vutla]

On 20/04/20 4:40 PM, Murali Karicheri wrote:
> + Lokesh
> 
> On 04/17/2020 11:12 AM, Murali Karicheri wrote:
>> In RGMII mode the 10Mbps link speed is supported only when CPSW2G MAC SL is
>> configured for External Control ("in band") mode
>> CPSW_PN_MAC_CONTROL_REG.CTL_EN(18) = 1
>>
>> Hence update am65_cpsw_update_link() to follow documentation.
>>
>> Signed-off-by: Murali Karicheri 

Merged into u-boot-ti.

Thanks and regards,
Lokesh

Re: [PATCH] arm: K3: Increase default SYSFW image size allocation

[Lokesh Vutla]

On 01/05/20 12:42 AM, Andrew F. Davis wrote:
> The memory allocated to store the FIT image containing SYSFW and board
> configuration data is statically defined to the largest size expected.
> Some additions to the board configuration data has pushed us slightly
> over the current defined size on some HS devices, expand to 278000.
> 
> Signed-off-by: Andrew F. Davis 

Merged into u-boot-ti.

Thanks and regards,
Lokesh

[PATCH] imx8mp_evk: Add a README file

[Fabio Estevam]

Add a README file explaining the U-Boot build and SD card flash procedures.

Signed-off-by: Fabio Estevam 
---
 board/freescale/imx8mp_evk/README | 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 board/freescale/imx8mp_evk/README

diff --git a/board/freescale/imx8mp_evk/README 
b/board/freescale/imx8mp_evk/README
new file mode 100644
index 00..7dbf61fa94
--- /dev/null
+++ b/board/freescale/imx8mp_evk/README
@@ -0,0 +1,41 @@
+U-Boot for the NXP i.MX8MP EVK board
+
+Quick Start
+===
+- Build the ARM Trusted firmware binary
+- Get the firmware-imx package
+- Build U-Boot
+- Boot
+
+Get and Build the ARM Trusted firmware
+==
+Note: $(srctree) is the U-Boot source directory
+Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
+branch: imx_5.4.3_2.0.0
+$ make PLAT=imx8mp bl31
+$ sudo cp build/imx8mp/release/bl31.bin $(srctree)
+
+Get the ddr firmware
+
+$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.7.bin
+$ chmod +x firmware-imx-8.7.bin
+$ ./firmware-imx-8.7
+$ sudo cp 
firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin 
$(srctree)/lpddr4_pmu_train_1d_dmem.bin
+$ sudo cp 
firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin 
$(srctree)/lpddr4_pmu_train_1d_imem.bin
+$ sudo cp 
firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_201904.bin 
$(srctree)/lpddr4_pmu_train_2d_dmem.bin
+$ sudo cp 
firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin 
$(srctree)/lpddr4_pmu_train_2d_imem.bin
+
+Build U-Boot
+
+$ export CROSS_COMPILE=aarch64-poky-linux-
+$ make imx8mp_evk_defconfig
+$ export ATF_LOAD_ADDR=0x96
+$ make flash.bin
+
+Burn the flash.bin to the MicroSD card at offset 32KB
+$sudo dd if=flash.bin of=/dev/sd[x] bs=1K seek=32; sync
+
+Boot
+
+Set Boot switch to SD boot
+Use /dev/ttyUSB2 for U-Boot console
-- 
2.17.1