Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Marek Vasut]

On 2/6/20 3:57 PM, Simon Goldschmidt wrote:
> On Thu, Feb 6, 2020 at 3:41 PM Nico Becker  wrote:
>>
>> Am 06.02.2020 um 14:00 schrieb Marek Vasut:
>>> On 2/6/20 1:57 PM, Nico Becker wrote:
 Am 06.02.2020 um 12:53 schrieb Marek Vasut:
> On 2/6/20 11:50 AM, Nico Becker wrote:
>> Hello,
>
> Hi,
>
>> after removing the function socfpga_sdram_apply_static_cfg() in
>> misc_gen5 we can not use the FPGA2SDRAM bridge.
>>
>> Without the apply static cfg the kernel crash every time,
>> if we try to write @ the fpga2sdram bridge. After an soft reset
>> everything is working.
>>
>> If we add the socfpga_sdram_apply_static_cfg() in the
>> u-boot source code, everything is fine.
>> Now we can use the fpga2sdram bridge after power on.
>>
>> Our setup:
>> - u-boot v2020.01
>> - load and write fpga firmware
>> - enable bridges
>> - boot linux
>>
>> I have found some information at
>> 
>>
>>
>> 
>
> Can you send a patch which fixes this for you, with Fixes: tag ?
> Then it would be clear what you changed.
>
> Thanks
>

 Hello,
 the code was removed @ commit c5f4b805.
>>>
>>> Did you read the commit message of that commit and what problem that was
>>> solving ? Clearly, reverting the commit isn't the way to go. We need to
>>> find a way to unbreak this for you, while not break other platforms.
>>>
 I attached my patch, sorry for the format, i am new in this.
>>>
>>> [...]
>>>
>> Hi,
>> yes i read the commit message.
>>
>> but i found no other option to enable the sdram bridges,
>> without crashes/hanging up linux, with the removed source code.
>>
>> i ve found some more information @intel
>> 
>>
>> Intel talk about an bridge_enable_handoff in my opionion
>> the cmd set the sram aply cfg
>>
>> /* add signle command to enable all bridges based on handoff */
>> setenv("bridge_enable_handoff",
>> "mw $fpgaintf ${fpgaintf_handoff}; "
>> "go $fpga2sdram_apply; "
>> "mw $fpga2sdram ${fpga2sdram_handoff}; "
>> "mw $axibridge ${axibridge_handoff}; "
>> "mw $l3remap ${l3remap_handoff} ");
>>
>> setenv_addr("fpga2sdram_apply", (void *)sdram_applycfg_uboot);
>>
>> /*
>>   * Relocate the sdram_applycfg_ocram function to OCRAM and call it
>>   */
>> ENTRY(sdram_applycfg_uboot)
>> PUSH{r4-r11, lr}/* save registers per AAPCS */
>>
>> ldr r1, =sdram_applycfg_ocram
>> ldr r2, =CONFIG_SYS_INIT_RAM_ADDR
>> mov r3, r2
>> ldmia   r1!, {r4 - r11}
>> stmia   r3!, {r4 - r11}
>> ldmia   r1!, {r4 - r11} /* copy more in case code added */
>> stmia   r3!, {r4 - r11} /* in the future */
>> ldmia   r1!, {r4 - r11} /* copy more in case code added */
>> stmia   r3!, {r4 - r11} /* in the future */
>> dsb
>> isb
>> blx r2  /* jump to OCRAM */
>> POP {r4-r11, pc}
>> ENDPROC(sdram_applycfg_uboot)
>>
>>
>> it could be an option to write the fpga firmware with u-boot,
>> and do a soft reset.
>> boot u-boot
>> check fpga configuration state
>> not configured write firmware reset
>> if configured boot linux
>>
>> i ll check howto to determine the fpga configuration state
>> and try this.
> 
> That doesn't look like a safe plan: what if you explicitly *want* a reboot
> and want to reconfigure the FPGA then to ensure it is in a well-known state?
> 
> Marek, what were the problems why this has been removed? Aside from "is
> confirmed to lead to a rare system hang when enabling bridges", the commit
> message stays rather vague.

That's exactly what the problem was. I didn't manage to get further
details from Altera on this.

> Maybe that "apply config" bit should only be written
> if explicitly configured so, but that would mean we need some kind of config
> options included/coming with the FPGA image we program.

Maybe the apply config should only be used if the F2S bridge is being used ?

> Oh, and by now I'm glad our own design connects to DDR via the main bus ;-)

Right.

-- 
Best regards,
Marek Vasut

Re: [PATCH] efi_loader: add some description about UEFI secure boot

[Ilias Apalodimas]

On Fri, Feb 07, 2020 at 02:14:37PM +0900, AKASHI Takahiro wrote:
> A small text in docs/uefi/uefi.rst was added to explain how we can
> configure and utilise UEFI secure boot feature on U-Boot.
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  doc/uefi/uefi.rst | 77 +++
>  1 file changed, 77 insertions(+)
> 
> diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
> index a8fd886d6b5e..98cd770aefe5 100644
> --- a/doc/uefi/uefi.rst
> +++ b/doc/uefi/uefi.rst
> @@ -97,6 +97,83 @@ Below you find the output of an example session starting 
> GRUB::
>  
>  See doc/uImage.FIT/howto.txt for an introduction to FIT images.
>  
> +Configuring UEFI secure boot
> +
> +
> +UEFI specification[1] defines a secure way of executing UEFI images
> +by verifying a signature (or message digest) of image with certificates.
> +This feature on U-Boot is enabled with::
> +
> +CONFIG_UEFI_SECURE_BOOT=y
> +
> +To make the boot sequence safe, you need to establish a chain of trust;
> +In UEFI secure boot, you can make it with the UEFI variables, "PK"
> +(Platform Key), "KEK" (Key Exchange Keys), "db" (white list database)
> +and "dbx" (black list database).
> +
> +There are many online documents that describe what UEFI secure boot is
> +and how it works. Please consult some of them for details.
> +
> +Here is a simple example that you can follow for your initial attempt
> +(Please note that the actual steps would absolutely depend on your system
> +and environment.):
> +
> +1. Install utility commands on your host
> +* openssl
> +* efitools
> +* sbsigntool
> +
> +2. Create signing keys and key database files on your host
> +for PK::
> +
> +$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_PK/ \
> +-keyout PK.key -out PK.crt -nodes -days 365
> +$ cert-to-efi-sig-list -g ----123456789abc \
> +PK.crt PK.esl;
> +$ sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth
> +
> +for KEK::
> +
> +$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_KEK/ \
> +-keyout KEK.key -out KEK.crt -nodes -days 365
> +$ cert-to-efi-sig-list -g ----123456789abc \
> +KEK.crt KEK.esl
> +$ sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth
> +
> +for db::
> +
> +$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db/ \
> +-keyout db.key -out db.crt -nodes -days 365
> +$ cert-to-efi-sig-list -g ----123456789abc \
> +db.crt db.esl
> +$ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth
> +
> +Copy \*.auth to media, say mmc, that is accessible from U-Boot.
> +
> +3. Sign an image with one key in "db" on your host::
> +
> +$ sbsign --key db.key --cert db.crt helloworld.efi
> +
> +4. Install keys on your board::
> +
> +==> fatload mmc 0:1  PK.auth
> +==> setenv -e -nv -bs -rt -at -i ,$filesize PK
> +==> fatload mmc 0:1  KEK.auth
> +==> setenv -e -nv -bs -rt -at -i ,$filesize KEK
> +==> fatload mmc 0:1  db.auth
> +==> setenv -e -nv -bs -rt -at -i ,$filesize db
> +
> +5. Set up boot parameters on your board::
> +
> +==> efidebug boot add 1 HELLO mmc 0:1 /helloworld.efi.signed ""
> +
> +Then your board runs that image from Boot manager (See below).
> +You can also try this sequence by running Pytest, test_efi_secboot,
> +on sandbox::
> +
> +$ cd 
> +$ pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox
> +
>  Executing the boot manager
>  ~~
>  
> -- 
> 2.24.0
> 

Acked-by: Ilias Apalodimas 

Re: dm, serial: problem with using ns16550 driver before relocation on mpc83xx

[Heiko Schocher]

Hi Simon,

removed Dirk from cc and added Mario Six

@Mario: Dirk is maintainer of the gazerbeam board:

https://gitlab.denx.de/u-boot/u-boot/blob/master/board/gdsys/mpc8308/MAINTAINERS#L2

but EMail get not delivered to his EMail address ... so I added
you to cc ... may you have a gazerbeam board? May you can try,
if current U-Boot mainline works (in special serial console) on it?

thanks!

Am 06.02.2020 um 18:46 schrieb Simon Glass:

Hi Heiko,

On Wed, 5 Feb 2020 at 22:19, Heiko Schocher  wrote:


Hello Simon,

Am 05.02.2020 um 18:59 schrieb Simon Glass:

Hi Heiko,

On Wed, 5 Feb 2020 at 02:04, Heiko Schocher  wrote:


Hello Bin, Simon,

I just porting the mpc83xx based kmcoge5ne board support DTS and got
problems using the serial ns16550 driver.

I need the serial driver before rolcation, so I enabled
"u-boot,dm-pre-reloc;" as usual in the device tree, but board does not
boot ...

I found the commit:

commit 4687919684e0e4390b9fc20d1809ecaa9dc3cb81
Author: Bin Meng 
Date:   Wed Oct 24 06:36:36 2018 -0700

   serial: Remove DM_FLAG_PRE_RELOC flag in various drivers

which added to the ns16550 serial driver:

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 04b604fa2c..1e6fc6c668 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -487,7 +487,9 @@ U_BOOT_DRIVER(ns16550_serial) = {
   .priv_auto_alloc_size = sizeof(struct NS16550),
   .probe = ns16550_serial_probe,
   .ops= _serial_ops,
+#if !CONFIG_IS_ENABLED(OF_CONTROL)
   .flags  = DM_FLAG_PRE_RELOC,
+#endif
};
#endif
#endif /* SERIAL_PRESENT */

So, as OF_CONTROL is defined for me, the flag "u-boot,dm-pre-reloc" seems
not working anymore ...

Adding this back:

hs@xmglap:u-boot-secu  [20200205-temp] $ git diff
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 9851663dc5..386ca9cffa 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -528,7 +528,7 @@ U_BOOT_DRIVER(ns16550_serial) = {
   .priv_auto_alloc_size = sizeof(struct NS16550),
   .probe = ns16550_serial_probe,
   .ops= _serial_ops,
-#if !CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
   .flags  = DM_FLAG_PRE_RELOC,
#endif
};

and board boots fine with the flag "u-boot,dm-pre-reloc" in DTS ...

May I do something wrong here? I found in mainline for example
the "arch/powerpc/dts/gdsys/gazerbeam-uboot.dtsi" board, which
has the exactly same dts settings than I have now.

@Dirk: Can you check, if this board boots with current mainline?

Shouldn;t be the logic, that in case OF_CONTROL is enabled and if
flag "u-boot,dm-pre-reloc" is set in DTS for the device, the device
should be bound before relocation, and we do not need to check, if
the driver sets DM_FLAG_PRE_RELOC ?

But may I miss here something ...

Any hints?


+Tom Rini

I found I needed this for rpi.

http://patchwork.ozlabs.org/patch/1202913/

But I still haven't gone back to figure out why Tom doesn't.


Hmm... I have added the "u-boot,dm-pre-reloc;" to the uart node.

Like it is for the gazerbeam board, see [1]

It works if "DM_FLAG_PRE_RELOC" is set the driver in flags... no
need for a gpio node before relocation like it is inabove patch.

I wonder if we need DM_FLAG_PRE_RELOC at all in a driver and
OF_CONTROL case. Shouldn't it be enough if the DTB node for the
driver contains the "u-boot,dm-pre-reloc;" property?


Well in the rpi case it is the pinctrl that needs that property. I
think you should dig into exactly what is going wrong on the board you
have. Then it should be possible to see what is missing and add it.


Ok, I try to find out more, thanks!

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

[PATCH] efi_loader: add some description about UEFI secure boot

[AKASHI Takahiro]

A small text in docs/uefi/uefi.rst was added to explain how we can
configure and utilise UEFI secure boot feature on U-Boot.

Signed-off-by: AKASHI Takahiro 
---
 doc/uefi/uefi.rst | 77 +++
 1 file changed, 77 insertions(+)

diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
index a8fd886d6b5e..98cd770aefe5 100644
--- a/doc/uefi/uefi.rst
+++ b/doc/uefi/uefi.rst
@@ -97,6 +97,83 @@ Below you find the output of an example session starting 
GRUB::
 
 See doc/uImage.FIT/howto.txt for an introduction to FIT images.
 
+Configuring UEFI secure boot
+
+
+UEFI specification[1] defines a secure way of executing UEFI images
+by verifying a signature (or message digest) of image with certificates.
+This feature on U-Boot is enabled with::
+
+CONFIG_UEFI_SECURE_BOOT=y
+
+To make the boot sequence safe, you need to establish a chain of trust;
+In UEFI secure boot, you can make it with the UEFI variables, "PK"
+(Platform Key), "KEK" (Key Exchange Keys), "db" (white list database)
+and "dbx" (black list database).
+
+There are many online documents that describe what UEFI secure boot is
+and how it works. Please consult some of them for details.
+
+Here is a simple example that you can follow for your initial attempt
+(Please note that the actual steps would absolutely depend on your system
+and environment.):
+
+1. Install utility commands on your host
+* openssl
+* efitools
+* sbsigntool
+
+2. Create signing keys and key database files on your host
+for PK::
+
+$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_PK/ \
+-keyout PK.key -out PK.crt -nodes -days 365
+$ cert-to-efi-sig-list -g ----123456789abc \
+PK.crt PK.esl;
+$ sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth
+
+for KEK::
+
+$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_KEK/ \
+-keyout KEK.key -out KEK.crt -nodes -days 365
+$ cert-to-efi-sig-list -g ----123456789abc \
+KEK.crt KEK.esl
+$ sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth
+
+for db::
+
+$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db/ \
+-keyout db.key -out db.crt -nodes -days 365
+$ cert-to-efi-sig-list -g ----123456789abc \
+db.crt db.esl
+$ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth
+
+Copy \*.auth to media, say mmc, that is accessible from U-Boot.
+
+3. Sign an image with one key in "db" on your host::
+
+$ sbsign --key db.key --cert db.crt helloworld.efi
+
+4. Install keys on your board::
+
+==> fatload mmc 0:1  PK.auth
+==> setenv -e -nv -bs -rt -at -i ,$filesize PK
+==> fatload mmc 0:1  KEK.auth
+==> setenv -e -nv -bs -rt -at -i ,$filesize KEK
+==> fatload mmc 0:1  db.auth
+==> setenv -e -nv -bs -rt -at -i ,$filesize db
+
+5. Set up boot parameters on your board::
+
+==> efidebug boot add 1 HELLO mmc 0:1 /helloworld.efi.signed ""
+
+Then your board runs that image from Boot manager (See below).
+You can also try this sequence by running Pytest, test_efi_secboot,
+on sandbox::
+
+$ cd 
+$ pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox
+
 Executing the boot manager
 ~~
 
-- 
2.24.0

[PATCH 2/2] configs: arm: ls1021aiot: enable CONFIG_DM_USB support

[Ran Wang]

Enable CONFIG_DM_USB to remove below compile warning:

= WARNING ==
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.


Signed-off-by: Ran Wang 
---
 configs/ls1021aiot_qspi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/ls1021aiot_qspi_defconfig 
b/configs/ls1021aiot_qspi_defconfig
index 8a3b796..2ae0cb0 100644
--- a/configs/ls1021aiot_qspi_defconfig
+++ b/configs/ls1021aiot_qspi_defconfig
@@ -43,6 +43,7 @@ CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
 CONFIG_FSL_QSPI=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_DM_I2C=y
-- 
2.7.4

[PATCH 1/2] configs: arm64: ls1012afrdm Enable CONFIG_BLK

[Ran Wang]

With DM_USB enabled, enable CONFIG_BLK to remove this
compile warning for ls1012afrdm based targets:

= WARNING ==
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.


Signed-off-by: Ran Wang 
---
 configs/ls1012afrdm_qspi_defconfig | 1 +
 configs/ls1012afrdm_tfa_defconfig  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/ls1012afrdm_qspi_defconfig 
b/configs/ls1012afrdm_qspi_defconfig
index e5196de..ee0e19c 100644
--- a/configs/ls1012afrdm_qspi_defconfig
+++ b/configs/ls1012afrdm_qspi_defconfig
@@ -55,3 +55,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_DM_I2C=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_RTC=y
+CONFIG_BLK=y
diff --git a/configs/ls1012afrdm_tfa_defconfig 
b/configs/ls1012afrdm_tfa_defconfig
index 4b55b0c..57bf0a6 100644
--- a/configs/ls1012afrdm_tfa_defconfig
+++ b/configs/ls1012afrdm_tfa_defconfig
@@ -55,3 +55,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_DM_I2C=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_RTC=y
+CONFIG_BLK=y
-- 
2.7.4

Re: Support UBI u-boot

[JH]

Hi Andy,

On 2/6/20, Andy Pont  wrote:
> JH wrote...
>
>
>>I added NAND and UBIFS support to my Yocto layer machine config file:
>>
>>UBOOT_CONFIG = "nand"
>>UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_config"
>>UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_nand_config"
>>UBOOT_CONFIG[nand] += "ubi"
>>UBOOT_CONFIG[nand] += "ubifs"
>>
>>But my u-boot.imx-nand still could not support ubi:
>>
>>=> ubi part rootfs
>>Unknown command 'ubi' - try ‘help’
> You need to start to read through the various sources to figure out for
> yourself what is going on!
>
> Starting from the bottom, in U-Boot 2017.03 all of the command sources
> are in the “cmd” directory. The “ubi …” command are all in ubi.c.
> Reading cmd/Makefile shows that file gets added into the build if
> CONFIG_CMD_UBI is enabled.

You are right, that CONFIG_CMD_UBI is not enabled, but I could not
find any conf or bb files I could change or enable CONFIG_CMD_UBI in
meta-freescale layer.

Desperately, I hacked to run "make menuconfig" at U-Boot 2017.03 build
directory, selected and enabled CONFIG_CMD_UBI and saved to .config
file in that build directory, but then to run bitbake to build u-boot
again, the .config was removed and replaced by an old one disabled
CONFIG_CMD_UBI again.

Other people recommended to build u-boot in a standalone environment
out of OE / Yocto build system. Since I have set up everything in OE /
Yocto environment, I thought it could be easier if I could modify one
line of u-boot config file in a recipe.

Any idea where is the recipe in meta-freescale to allow me to change /
enable CONFIG_CMD_UBI?

Am I the only one unable to change u-boot config file in OE / Yoctu
build? That makes me very sad :-(.


> The next place to look is whether or not that is set in your defconfig
> for U-Boot or overwritten somewhere in a recipe in your Yocto build
> environment.

Yeah, I'll been searched all day, could not find a recipe Yocto build
environment, I was told OE / Yocto does not have that stack and
mechanism to set and change u-boot config, is it true?

Thank you very much.

Kind regards,

- jh

Re: [PATCH] video: enable VIDEO_ANSI and all VIDEO_BBP options

[Tom Rini]

On Tue, Feb 04, 2020 at 10:43:06PM +0100, Anatolij Gustschin wrote:

> This partially reverts changes by commit 2cc393f32fd9
> ("video: make BPP and ANSI configs optional") since it
> caused issues with other boards (missing LCD console
> output on pinebook, x86 platform or sandbox). Enable
> all disabled options again and opt out of not supported
> color depth in board defconfigs.
> 
> Signed-off-by: Anatolij Gustschin 
> Reported-by: Vagrant Cascadian 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 00/17] x86: coral: Add support for Cr50

[Bin Meng]

Hi Simon,

On Fri, Feb 7, 2020 at 12:55 AM Simon Glass  wrote:
>
> Hi Bin,
>
> On Wed, 5 Feb 2020 at 23:22, Bin Meng  wrote:
> >
> > Hi Simon,
> >
> > On Wed, Feb 5, 2020 at 10:03 AM Simon Glass  wrote:
> > >
> > > This series adds a driver for the Cr50 security chip and enables it on
> > > coral. This supports the 'tpm' command.
> > >
> > > In order to make this work a few other changes are included:
> > > - Additional UCLASS_IRQ operations to support requesting and reading
> > >   interrupts, using the device tree
> > > - A driver for ACPI general-purpose events
> > >
> > > There are also a few small clean-ups to the recently landed Apollo Lake
> > > support.
> > >
> > > This series relies on this patch:
> > >
> > >http://patchwork.ozlabs.org/patch/1214541/
> > >
> >
> > This series does not apply on top of u-boot-x86/master:
> >
> > Applying: x86: apl: Use the clock driver
> > error: patch failed: arch/x86/cpu/apollolake/Kconfig:40
> > error: arch/x86/cpu/apollolake/Kconfig: patch does not apply
> > Patch failed at 0006 x86: apl: Use the clock driver
> >
> > I tried to apply it on top of an old commit and got no luck.
> >
> > Would you please rebase this series against u-boot-x86/master and resend?
>
> Yes, will do.
>
> Any thoughts on the ACPI series? I need to rebase that as well.

Which series? I do not find that in my patch queue.

Regards,
Bin

Re: [yocto] Support UBI u-boot

[JH]

Hi Gabriele,

On 2/6/20, Gabriele Zampieri  wrote:
> As far as I know uboot (usually virtual/bootloader) does not have a task to
> run menuconfig directly from bitbake.
> I usually have a local clone of uboot and I simply run `make [...]
> menuconfig|savedefconfig` , then I create a patch
> to add my defconfig (custom_defconfig) to configs/ and specify
> UBOOT_MACHINE = "custom_defconfig"

Are there any document to use cross compiler tools to build u-boot-imx
on Ubuntu 18 host machine? It seems that build environment will not be
the same as the Yocto build environment I am currently running on
Ubuntu 18 host.

Thank you Gabriele for great helps.

Kind regards,

- jh

Re: [PATCH v4 6/6] board: presidio-asic: Add basic G3 engr. development board support

[Alex Nemirovsky]

Hello Tom and Daniel,

This v4 of patch 6/6 in the series is the only one which yield feedback in the 
prior v3. All other are in “Reviewed-By” state. 
We hope that v4 sent out a week ago has addressed those issues.

Let us know if there is anything else holding up the series acceptance. 

BR
-AN

> On Jan 30, 2020, at 12:34 PM, Alex Nemirovsky 
>  wrote:
> 
> Add basic Presidio G3 engineering board support
> 
> Signed-off-by: Alex Nemirovsky 
> 
> ---
> 
> Changes in v4:
> - clean up presidio_asic.h per trini recommendations
> - use autogen savedefconfig instead of manual maintained file
> 
> Changes in v3:
> - fixed dts closing bracket indentation
> - presidio.h: remove deadcode from presidio.h
> - presidio.h: remove CA_REG_READ/CA_REG_WRITE wrapper macros
> - presidio.h: remove CA77xx define replace use CA common Kconfig
>  SoC selection instead
> - select SOC_CA7774 via board's Kconfig
> - select BIT64 via board's Kconfig instead of presidio.h
> 
> Changes in v2: None
> 
> arch/arm/Kconfig |   5 +
> arch/arm/dts/Makefile|   2 +
> arch/arm/dts/ca-presidio-engboard.dts|  69 ++
> arch/arm/mach-cortina/Makefile   |   5 +
> board/cortina/presidio-asic/Kconfig  |  18 
> board/cortina/presidio-asic/MAINTAINERS  |   6 ++
> board/cortina/presidio-asic/Makefile |   8 ++
> board/cortina/presidio-asic/lowlevel_init.S  |  87 +
> board/cortina/presidio-asic/presidio.c   | 134 +++
> configs/cortina_presidio-asic-base_defconfig |  29 ++
> include/configs/presidio_asic.h  |  75 +++
> 11 files changed, 438 insertions(+)
> create mode 100644 arch/arm/dts/ca-presidio-engboard.dts
> create mode 100644 arch/arm/mach-cortina/Makefile
> create mode 100644 board/cortina/presidio-asic/Kconfig
> create mode 100644 board/cortina/presidio-asic/MAINTAINERS
> create mode 100644 board/cortina/presidio-asic/Makefile
> create mode 100644 board/cortina/presidio-asic/lowlevel_init.S
> create mode 100644 board/cortina/presidio-asic/presidio.c
> create mode 100644 configs/cortina_presidio-asic-base_defconfig
> create mode 100644 include/configs/presidio_asic.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 36c9c2f..6d95cde 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1638,6 +1638,10 @@ config TARGET_DURIAN
> Support for durian platform.
> It has 2GB Sdram, uart and pcie.
> 
> +config TARGET_PRESIDIO_ASIC
> + bool "Support Cortina Presidio ASIC Platform"
> + select ARM64
> +
> endchoice
> 
> config ARCH_SUPPORT_TFABOOT
> @@ -1782,6 +1786,7 @@ source "board/Marvell/gplugd/Kconfig"
> source "board/armadeus/apf27/Kconfig"
> source "board/armltd/vexpress/Kconfig"
> source "board/armltd/vexpress64/Kconfig"
> +source "board/cortina/presidio-asic/Kconfig"
> source "board/broadcom/bcm23550_w1d/Kconfig"
> source "board/broadcom/bcm28155_ap/Kconfig"
> source "board/broadcom/bcm963158/Kconfig"
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 0127a91..81db1e6 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -849,6 +849,8 @@ dtb-$(CONFIG_TARGET_VEXPRESS_CA15_TC2) += 
> vexpress-v2p-ca15_a7.dtb
> 
> dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
> 
> +dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
> +
> targets += $(dtb-y)
> 
> # Add any required device tree compiler flags here
> diff --git a/arch/arm/dts/ca-presidio-engboard.dts 
> b/arch/arm/dts/ca-presidio-engboard.dts
> new file mode 100644
> index 000..c03dacc
> --- /dev/null
> +++ b/arch/arm/dts/ca-presidio-engboard.dts
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020, Cortina Access Inc.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +   #address-cells = <2>;
> +   #size-cells = <1>;
> +
> + mmc0: mmc@f440 {
> + compatible = "snps,dw-cortina";
> + reg = <0x0 0xf440 0x1000>;
> + bus-width = <4>;
> + io_ds = <0x77>;
> + fifo-mode;
> + sd_dll_ctrl = <0xf43200e8>;
> + io_drv_ctrl = <0xf432004c>;
> + };
> +
> + gpio0: gpio-controller@0xf4329280  {
> + compatible = "cortina,ca-gpio";
> + reg = <0x0 0xf4329280 0x24>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + status = "okay";
> + };
> + gpio1: gpio-controller@0xf43292a4  {
> + compatible = "cortina,ca-gpio";
> + reg = <0x0 0xf43292a4 0x24>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + status = "disabled";
> + };
> +
> + watchdog: watchdog@0xf432901c {
> + compatible = "cortina,ca-wdt";
> + reg = <0x0 0xf432901c 0x34>,
> +   <0x0 0xf4320020 0x04>;
> + status = "okay";
> + };
> +
> + uart0: serial@0xf4329148  {
> +

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Atish Patra]

On Thu, Feb 6, 2020 at 2:07 PM Ard Biesheuvel  wrote:
>
> On Thu, 6 Feb 2020 at 21:06, Atish Patra  wrote:
> >
> > On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf  wrote:
> > >
> > >
> > > On 06.02.20 19:28, Atish Patra wrote:
> > > > On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> > > >  wrote:
> > > >> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt  
> > > >> wrote:
> > > >>> RISC-V booting currently is based on a per boot stage lottery to 
> > > >>> determine
> > > >>> the active CPU. The Hart State Management (HSM) SBI extension replaces
> > > >>> this lottery by using a dedicated primary CPU.
> > > >>>
> > > >>> Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
> > > >>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
> > > >>>
> > > >>> In this scenario the id of the active hart has to be passed from boot 
> > > >>> stage
> > > >>> to boot stage. Using a UEFI variable would provide an easy 
> > > >>> implementation.
> > > >>>
> > > >>> This patch provides a weak function that is called at the end of the 
> > > >>> setup
> > > >>> of U-Boot's UEFI sub-system. By overriding this function architecture
> > > >>> specific UEFI variables or configuration tables can be created.
> > > >>>
> > > >>> Signed-off-by: Heinrich Schuchardt 
> > > >>> Reviewed-by: Atish Patra 
> > > >> OK, so I have a couple of questions:
> > > >>
> > > >> - does RISC-V use device tree? if so, why are you not passing the
> > > >> active hart via a property in the /chosen node?
> > > > Yes. RISC-V uses device tree. Technically, we can pass the active hart
> > > > by a DT property
> > > > but that means we have to modify the DT in OpenSBI (RISC-V specific
> > > > run time service provider).
> > > > We have been trying to avoid that if possible so that DT is not
> > > > bounced around. This also limits
> > > > U-Boot to have its own device tree.
> > >
> > >
> > > I don't understand how this is different from the UEFI variable scheme
> > > proposed here? If you want to create an SBI interface to propagate the
> > > active HART that U-Boot then uses to populate the /chosen property,
> > > that's probably fine as well.
> > >
> >
> > We don't want to create SBI interface to pass this information.
> >
> > > We already have hooks that allow you to modify the DT right before it
> > > gets delivered to the payload. Just add it there?
> > >
> >
> > Hmm. I guess it is true if the DT is loaded from MMC or network as well.
> > How about EDK2 ? If we go DT route, it also has to modify the DT to
> > pass the boot hart.
> >
> > As it requires DT modification in multiple projects, why not use efi
> > configuration tables as
> > suggested by Ard ?
> >
>
> Configuration tables are preferred over variables, but putting it in
> the DT makes even more sense, since in that case, nothing that runs in
> the UEFI context has to care about any of this.
>
> > > >
> > > >
> > > >> I'd assume the EFI stub would not care at all about this information, 
> > > >> and it would give
> > > >> you a Linux/RISC-V specific way to convey this information that is
> > > >> independent of EFI.
> > > > Yes. EFI stub doesn't care about this information. However, it needs
> > > > to save the information somewhere
> > > > so that it can pass to the real kernel after exiting boot time services.
> > >
> > >
> > > DT sounds like a pretty natural choice for that to me :).
> > >
>
> Indeed. DT has a /chosen node that is set aside for this purpose. It
> does depend on how early you need the value (i.e., before or after you
> can run C code), but since you are passing the DT address to the core
> kernel, it makes way more sense to drop any additional information
> that you need to pass in there.

We don't need boot hart id until real kernel boots and parse DT. So
that should be okay.
I just looked at the efi stub code once more and realized that it is
already parsing the DT to setup
uefi memory maps from /chosen node. Adding boot hart id to the chosen
node does seem much
cleaner to me :). Thanks for all the explanations.

I have not looked at EDK2 code. But I am assuming modifying the DT
just before jumping to the payload
won't be too hard for EDK2 as well.

Added Leif and Abner for the opinion.



--
Regards,
Atish

Re: FYI: Please pull u-boot-dm

[Stephen Warren]

On 2/6/20 2:55 PM, Simon Glass wrote:

Hi Tom,

This cannot be pulled yet since we need to update gitlab's docker
image to include SDL2. But gitlab seems to be having various problems
this week and today i won't work at all: ...


I see the following build error in u-boot-dm/master via Jenkins:


drivers/misc/p2sb_emul.c: In function ‘sandbox_p2sb_emul_map_physmem’:
drivers/misc/p2sb_emul.c:237:6: warning: ‘child’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
  ret = axi_read(child, offset, priv->regs, AXI_SIZE_32);
  ^
  CC  common

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Ard Biesheuvel]

On Thu, 6 Feb 2020 at 21:06, Atish Patra  wrote:
>
> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf  wrote:
> >
> >
> > On 06.02.20 19:28, Atish Patra wrote:
> > > On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> > >  wrote:
> > >> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt  
> > >> wrote:
> > >>> RISC-V booting currently is based on a per boot stage lottery to 
> > >>> determine
> > >>> the active CPU. The Hart State Management (HSM) SBI extension replaces
> > >>> this lottery by using a dedicated primary CPU.
> > >>>
> > >>> Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
> > >>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
> > >>>
> > >>> In this scenario the id of the active hart has to be passed from boot 
> > >>> stage
> > >>> to boot stage. Using a UEFI variable would provide an easy 
> > >>> implementation.
> > >>>
> > >>> This patch provides a weak function that is called at the end of the 
> > >>> setup
> > >>> of U-Boot's UEFI sub-system. By overriding this function architecture
> > >>> specific UEFI variables or configuration tables can be created.
> > >>>
> > >>> Signed-off-by: Heinrich Schuchardt 
> > >>> Reviewed-by: Atish Patra 
> > >> OK, so I have a couple of questions:
> > >>
> > >> - does RISC-V use device tree? if so, why are you not passing the
> > >> active hart via a property in the /chosen node?
> > > Yes. RISC-V uses device tree. Technically, we can pass the active hart
> > > by a DT property
> > > but that means we have to modify the DT in OpenSBI (RISC-V specific
> > > run time service provider).
> > > We have been trying to avoid that if possible so that DT is not
> > > bounced around. This also limits
> > > U-Boot to have its own device tree.
> >
> >
> > I don't understand how this is different from the UEFI variable scheme
> > proposed here? If you want to create an SBI interface to propagate the
> > active HART that U-Boot then uses to populate the /chosen property,
> > that's probably fine as well.
> >
>
> We don't want to create SBI interface to pass this information.
>
> > We already have hooks that allow you to modify the DT right before it
> > gets delivered to the payload. Just add it there?
> >
>
> Hmm. I guess it is true if the DT is loaded from MMC or network as well.
> How about EDK2 ? If we go DT route, it also has to modify the DT to
> pass the boot hart.
>
> As it requires DT modification in multiple projects, why not use efi
> configuration tables as
> suggested by Ard ?
>

Configuration tables are preferred over variables, but putting it in
the DT makes even more sense, since in that case, nothing that runs in
the UEFI context has to care about any of this.

> > >
> > >
> > >> I'd assume the EFI stub would not care at all about this information, 
> > >> and it would give
> > >> you a Linux/RISC-V specific way to convey this information that is
> > >> independent of EFI.
> > > Yes. EFI stub doesn't care about this information. However, it needs
> > > to save the information somewhere
> > > so that it can pass to the real kernel after exiting boot time services.
> >
> >
> > DT sounds like a pretty natural choice for that to me :).
> >

Indeed. DT has a /chosen node that is set aside for this purpose. It
does depend on how early you need the value (i.e., before or after you
can run C code), but since you are passing the DT address to the core
kernel, it makes way more sense to drop any additional information
that you need to pass in there.

Re: FYI: Please pull u-boot-dm

[Tom Rini]

On Thu, Feb 06, 2020 at 02:55:49PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> This cannot be pulled yet since we need to update gitlab's docker
> image to include SDL2. But gitlab seems to be having various problems
> this week and today i won't work at all:

I'll push those changes shortly then, thanks.

> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/2108

Looks like something is unhappy with your runner?

> Travis is happy.
> 
> So I am sending this just FYI for now. Once things settle down I can
> do a new version if needed.
> 
> 
> The following changes since commit f5cc89a82a9990ba9805ff5800c0872b891533ce:
> 
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq
> (2020-02-05 07:19:52 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git tags/dm-pull-6feb20

I'll take a look soon, thanks.

> 
> for you to fetch changes up to 21d651fb29cf268b1a5f64d080e3d352ee32c87f:
> 
>   sandbox: Complete migration away from os_malloc() (2020-02-05 21:48:23 
> -0700)
> 
> 
> sandbox conversion to SDL2
> TPM TEE driver
> Various minor sandbox video enhancements
> New driver model core utility functions
> 
> 
> Fabio Estevam (1):
>   doc: dm: debugging: Fix the steps for activating debug
> 
> Matthias Brugger (1):
>   buildman: Enable buildman on aarch64 hosts
> 
> Maxime Ripard (1):
>   dtc: add ability to make nodes conditional on them being referenced
> 
> Philippe Reynes (2):
>   tpm: add a helper to iterate on all tpm devices
>   cmd: tpm: add a subcommand device
> 
> Sean Anderson (2):
>   cli: Make the sandbox board_run_command the default
>   cmd: Add command to dump drivers and compatible strings
> 
> Simon Glass (53):
>   dm: core: Use const where possible in device.h
>   dm: pci: Update the PCI read_config() method to const dev *
>   dm: pci: Update a few more interfaces for const udevice *
>   dm: core: Use const device for the devfdt...() interface
>   dm: core: Use const device for the dev_read_...() interface
>   test: Add underscore prefix to macro parameters
>   dm: core: Update comment for ofnode_get_chosen_node()
>   dm: core: Rename ofnode_get_chosen_prop()
>   dm: core: Add ofnode_read_prop()
>   dm: core: Reimplement ofnode_read_size()
>   dm: core: Add ofnode_get_chosen_prop()
>   dm: core: Add a way to read platdata for all child devices
>   dm: core: Add a way to iterate through children, probing each
>   dm: core: Drop uclass_find_next_free_req_seq() conditions
>   bloblist: Add a new function to add or check size
>   bloblist: Tidy up a few comments and code-style nits
>   bloblist: Zero records when adding
>   sandbox: pmic: Correct i2c pmic emulator platdata method
>   console: Add a function to read a line of the output / eof
>   test: Enable console recording in tests
>   test: Add a way to check each line of console output
>   sandbox: Sort the help options
>   video: Support truetype fonts on a 32-bit display
>   video: sandbox: Enable all colour depths
>   mailbox: Rename free() to rfree()
>   power-domain: Rename free() to rfree()
>   reset: Rename free() to rfree()
>   gpio: Rename free() to rfree()
>   clk: Rename free() to rfree()
>   dma: Rename free() to rfree()
>   mtd: Rename free() to rfree()
>   sandbox: Rename 'free' variable
>   sandbox: Use a prefix for all allocation functions
>   exports: Add the malloc.h header
>   string: Allow arch override of strndup() also
>   sandbox: Rename strdup() functions
>   sandbox: Drop use of special os_malloc() where possible
>   sandbox: Drop os_realloc()
>   sandbox: Ensure that long-options array is terminated
>   sandbox: Add a new header for the system malloc()
>   sound: Add a new stop_play() method
>   sandbox: sound: Handle errors better in sound_beep()
>   sandbox: Add comments to the sdl struct
>   sandbox: sdl: Improve error handling
>   sandbox: sdl: Support waiting for audio to complete
>   gitlab: Disable SDL when building sandbox
>   sandbox: sdl: Move to use SDL2
>   sandbox: sdl: Add an option to double the screen size
>   sandbox: Support changing the LCD colour depth
>   dm: core: Require users of devres to include the header
>   dm: core: Create a new header file for 'compat' features
>   dm: core: Drop the inclusion of linux/compat.h in dm.h
>   sandbox: Complete migration away from os_malloc()
> 
> Thirupathaiah Annapureddy (2):
>   image: fdt: check "status" of "/reserved-memory" subnodes
>   tpm2: ftpm: A driver for firmware TPM running inside TEE
> 
>  .gitlab-ci.yml|   5 +-
>  .travis.yml   

FYI: Please pull u-boot-dm

[Simon Glass]

Hi Tom,

This cannot be pulled yet since we need to update gitlab's docker
image to include SDL2. But gitlab seems to be having various problems
this week and today i won't work at all:

https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/2108

Travis is happy.

So I am sending this just FYI for now. Once things settle down I can
do a new version if needed.


The following changes since commit f5cc89a82a9990ba9805ff5800c0872b891533ce:

  Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq
(2020-02-05 07:19:52 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git tags/dm-pull-6feb20

for you to fetch changes up to 21d651fb29cf268b1a5f64d080e3d352ee32c87f:

  sandbox: Complete migration away from os_malloc() (2020-02-05 21:48:23 -0700)


sandbox conversion to SDL2
TPM TEE driver
Various minor sandbox video enhancements
New driver model core utility functions


Fabio Estevam (1):
  doc: dm: debugging: Fix the steps for activating debug

Matthias Brugger (1):
  buildman: Enable buildman on aarch64 hosts

Maxime Ripard (1):
  dtc: add ability to make nodes conditional on them being referenced

Philippe Reynes (2):
  tpm: add a helper to iterate on all tpm devices
  cmd: tpm: add a subcommand device

Sean Anderson (2):
  cli: Make the sandbox board_run_command the default
  cmd: Add command to dump drivers and compatible strings

Simon Glass (53):
  dm: core: Use const where possible in device.h
  dm: pci: Update the PCI read_config() method to const dev *
  dm: pci: Update a few more interfaces for const udevice *
  dm: core: Use const device for the devfdt...() interface
  dm: core: Use const device for the dev_read_...() interface
  test: Add underscore prefix to macro parameters
  dm: core: Update comment for ofnode_get_chosen_node()
  dm: core: Rename ofnode_get_chosen_prop()
  dm: core: Add ofnode_read_prop()
  dm: core: Reimplement ofnode_read_size()
  dm: core: Add ofnode_get_chosen_prop()
  dm: core: Add a way to read platdata for all child devices
  dm: core: Add a way to iterate through children, probing each
  dm: core: Drop uclass_find_next_free_req_seq() conditions
  bloblist: Add a new function to add or check size
  bloblist: Tidy up a few comments and code-style nits
  bloblist: Zero records when adding
  sandbox: pmic: Correct i2c pmic emulator platdata method
  console: Add a function to read a line of the output / eof
  test: Enable console recording in tests
  test: Add a way to check each line of console output
  sandbox: Sort the help options
  video: Support truetype fonts on a 32-bit display
  video: sandbox: Enable all colour depths
  mailbox: Rename free() to rfree()
  power-domain: Rename free() to rfree()
  reset: Rename free() to rfree()
  gpio: Rename free() to rfree()
  clk: Rename free() to rfree()
  dma: Rename free() to rfree()
  mtd: Rename free() to rfree()
  sandbox: Rename 'free' variable
  sandbox: Use a prefix for all allocation functions
  exports: Add the malloc.h header
  string: Allow arch override of strndup() also
  sandbox: Rename strdup() functions
  sandbox: Drop use of special os_malloc() where possible
  sandbox: Drop os_realloc()
  sandbox: Ensure that long-options array is terminated
  sandbox: Add a new header for the system malloc()
  sound: Add a new stop_play() method
  sandbox: sound: Handle errors better in sound_beep()
  sandbox: Add comments to the sdl struct
  sandbox: sdl: Improve error handling
  sandbox: sdl: Support waiting for audio to complete
  gitlab: Disable SDL when building sandbox
  sandbox: sdl: Move to use SDL2
  sandbox: sdl: Add an option to double the screen size
  sandbox: Support changing the LCD colour depth
  dm: core: Require users of devres to include the header
  dm: core: Create a new header file for 'compat' features
  dm: core: Drop the inclusion of linux/compat.h in dm.h
  sandbox: Complete migration away from os_malloc()

Thirupathaiah Annapureddy (2):
  image: fdt: check "status" of "/reserved-memory" subnodes
  tpm2: ftpm: A driver for firmware TPM running inside TEE

 .gitlab-ci.yml|   5 +-
 .travis.yml   |   2 +-
 arch/arm/mach-aspeed/ast2500/clk_ast2500.c|   1 +
 arch/arm/mach-imx/cmd_nandbcb.c   |   2 +
 arch/arm/mach-imx/imx8/image.c|   1 +
 arch/arm/mach-meson/board-info.c  |   1 +
 arch/arm/mach-meson/sm.c  |   1 +
 arch/arm/mach-mvebu/mbus.c|   1 +
 arch/arm/mach-rockchip/px30/clk_px30.c

Re: [PATCH v3 10/12] riscv: Add K210 clock support

[Lukasz Majewski]

Hi Sean,

> Due to the large number of clocks, I decided to use the CCF. The
> overall structure is modeled after the imx code. A common pattern is
> to create a composite clock composed of several component clocks. For
> these component clocks, the clk_register_* functions are not used,
> since they will be registered as part of the composite clock. To
> create these component clocks, several helper k210_clk_comp_*
> functions are used. This functionality seems like it would be useful
> to other drivers also creating composite clocks, so perhaps some
> general versions should be created. I am not particularly attached to
> the naming convention, suggestions are welcome.
> 
> Signed-off-by: Sean Anderson 

Reviewed-by: Lukasz Majewski 

> ---
>   Changes for v3:
>   - Removed sysctl struct, replacing it with defines. This is to have
> the same interface to sysctl from C as from the device tree.
>   - Fixed clocks having the same id
>   - Fixed clocks not using the correct register/bits
>   - Aligned the defines in headers
>   Changes for v2:
>   - Add clk.o to obj-y
>   - Don't probe before relocation
> 
>  drivers/clk/kendryte/Kconfig|   2 +-
>  drivers/clk/kendryte/Makefile   |   2 +-
>  drivers/clk/kendryte/clk.c  | 390
>  drivers/clk/kendryte/clk.h  |
> 27 ++ include/dt-bindings/clock/k210-sysctl.h |  53 
>  include/dt-bindings/mfd/k210-sysctl.h   |  38 +++
>  6 files changed, 510 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/clk/kendryte/clk.c
>  create mode 100644 drivers/clk/kendryte/clk.h
>  create mode 100644 include/dt-bindings/clock/k210-sysctl.h
>  create mode 100644 include/dt-bindings/mfd/k210-sysctl.h
> 
> diff --git a/drivers/clk/kendryte/Kconfig
> b/drivers/clk/kendryte/Kconfig index 7b69c8afaf..073fca0781 100644
> --- a/drivers/clk/kendryte/Kconfig
> +++ b/drivers/clk/kendryte/Kconfig
> @@ -1,6 +1,6 @@
>  config CLK_K210
>   bool "Clock support for Kendryte K210"
> - depends on CLK && CLK_CCF
> + depends on CLK && CLK_CCF && CLK_COMPOSITE_CCF
>   help
> This enables support clock driver for Kendryte K210
> platforms. 
> diff --git a/drivers/clk/kendryte/Makefile
> b/drivers/clk/kendryte/Makefile index c56d93ea1c..d26bce954f 100644
> --- a/drivers/clk/kendryte/Makefile
> +++ b/drivers/clk/kendryte/Makefile
> @@ -1 +1 @@
> -obj-y += pll.o
> +obj-y += clk.o pll.o
> diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
> new file mode 100644
> index 00..aaa7420c84
> --- /dev/null
> +++ b/drivers/clk/kendryte/clk.c
> @@ -0,0 +1,390 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Sean Anderson 
> + */
> +#include "clk.h"
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pll.h"
> +
> +static ulong k210_clk_get_rate(struct clk *clk)
> +{
> + struct clk *c;
> + int err = clk_get_by_id(clk->id, );
> +
> + if (err)
> + return err;
> + return clk_get_rate(c);
> +}
> +
> +static ulong k210_clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> + struct clk *c;
> + int err = clk_get_by_id(clk->id, );
> +
> + if (err)
> + return err;
> + return clk_set_rate(c, rate);
> +}
> +
> +static int k210_clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + struct clk *c, *p;
> + int err = clk_get_by_id(clk->id, );
> +
> + if (err)
> + return err;
> + 
> + err = clk_get_by_id(parent->id, );
> + if (err)
> + return err;
> +
> + return clk_set_parent(c, p);
> +}
> +
> +static int k210_clk_endisable(struct clk *clk, bool enable)
> +{
> + struct clk *c;
> + int err = clk_get_by_id(clk->id, );
> +
> + if (err)
> + return err;
> + return enable ? clk_enable(c) : clk_disable(c);
> +}
> +
> +static int k210_clk_enable(struct clk *clk)
> +{
> + return k210_clk_endisable(clk, true);
> +}
> +
> +static int k210_clk_disable(struct clk *clk)
> +{
> + return k210_clk_endisable(clk, false);
> +}
> +
> +static const struct clk_ops k210_clk_ops = {
> + .set_rate = k210_clk_set_rate,
> + .get_rate = k210_clk_get_rate,
> + .set_parent = k210_clk_set_parent,
> + .enable = k210_clk_enable,
> + .disable = k210_clk_disable,
> +};
> +
> +/* The first clock is in0, which is filled in by k210_clk_probe */
> +static const char *generic_sels[] = { NULL, "pll0", };
> +static const char *aclk_sels[] = { "in0_half", "pll0_half", };
> +static const char *pll2_sels[] = { NULL, "pll0", "pll1", };
> +
> +static struct clk_divider *k210_clk_comp_div_flags(void __iomem
> *reg, u8 shift,
> +u8 width, u8
> flags) +{
> + struct clk_divider *div;
> +
> + div = kzalloc(sizeof(*div), GFP_KERNEL);
> + if (!div)
> + return div;
> + div->reg = reg;
> + div->shift = shift;
> + div->width = width;
> +   

Re: [PATCH v3 03/12] clk: Unconditionally recursively en-/dis-able clocks

[Lukasz Majewski]

Hi Sean,

> For clocks not in the CCF, their parents will not have UCLASS_CLK, so
> we just enable them as normal. The enable count is local to the
> struct clk, but this will never result in the actual en-/dis-able op
> being called (unless the same struct clk is enabled twice).
> 
> For clocks in the CCF, we always traverse up the tree when enabling.
> Previously, CCF clocks without id set would be skipped, stopping the
> traversal too early.
> 
> Signed-off-by: Sean Anderson 

Acked-by: Lukasz Majewski 

> ---
>   Changes for v3:
>   - New.
> 
>  drivers/clk/clk-uclass.c | 58
> +--- 1 file changed, 25
> insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 9aa8537004..87d101aab4 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -490,7 +490,6 @@ int clk_set_parent(struct clk *clk, struct clk
> *parent) int clk_enable(struct clk *clk)
>  {
>   const struct clk_ops *ops;
> - struct clk *clkp = NULL;
>   int ret;
>  
>   debug("%s(clk=%p)\n", __func__, clk);
> @@ -499,32 +498,28 @@ int clk_enable(struct clk *clk)
>   ops = clk_dev_ops(clk->dev);
>  
>   if (CONFIG_IS_ENABLED(CLK_CCF)) {
> - /* Take id 0 as a non-valid clk, such as dummy */
> - if (clk->id && !clk_get_by_id(clk->id, )) {
> - if (clkp->enable_count) {
> - clkp->enable_count++;
> - return 0;
> - }
> - if (clkp->dev->parent &&
> - device_get_uclass_id(clkp->dev) ==
> UCLASS_CLK) {
> - ret =
> clk_enable(dev_get_clk_ptr(clkp->dev->parent));
> - if (ret) {
> - printf("Enable %s failed\n",
> -
> clkp->dev->parent->name);
> - return ret;
> - }
> + if (clk->enable_count) {
> + clk->enable_count++;
> + return 0;
> + }
> + if (clk->dev->parent &&
> + device_get_uclass_id(clk->dev->parent) ==
> UCLASS_CLK) {
> + ret =
> clk_enable(dev_get_clk_ptr(clk->dev->parent));
> + if (ret) {
> + printf("Enable %s failed\n",
> +clk->dev->parent->name);
> + return ret;
>   }
>   }
>  
>   if (ops->enable) {
>   ret = ops->enable(clk);
>   if (ret) {
> - printf("Enable %s failed\n",
> clk->dev->name);
> + printf("Enable %s failed (error
> %d)\n", clk->dev->name, ret); return ret;
>   }
>   }
> - if (clkp)
> - clkp->enable_count++;
> + clk->enable_count++;
>   } else {
>   if (!ops->enable)
>   return -ENOSYS;
> @@ -550,7 +545,6 @@ int clk_enable_bulk(struct clk_bulk *bulk)
>  int clk_disable(struct clk *clk)
>  {
>   const struct clk_ops *ops;
> - struct clk *clkp = NULL;
>   int ret;
>  
>   debug("%s(clk=%p)\n", __func__, clk);
> @@ -559,29 +553,27 @@ int clk_disable(struct clk *clk)
>   ops = clk_dev_ops(clk->dev);
>  
>   if (CONFIG_IS_ENABLED(CLK_CCF)) {
> - if (clk->id && !clk_get_by_id(clk->id, )) {
> - if (clkp->enable_count == 0) {
> - printf("clk %s already disabled\n",
> -clkp->dev->name);
> - return 0;
> - }
> -
> - if (--clkp->enable_count > 0)
> - return 0;
> + if (clk->enable_count == 0) {
> + printf("clk %s already disabled\n",
> +clk->dev->name);
> + return 0;
>   }
>  
> + if (--clk->enable_count > 0)
> + return 0;
> +
>   if (ops->disable) {
>   ret = ops->disable(clk);
>   if (ret)
>   return ret;
>   }
>  
> - if (clkp && clkp->dev->parent &&
> - device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
> - ret =
> clk_disable(dev_get_clk_ptr(clkp->dev->parent));
> + if (clk->dev->parent &&
> + device_get_uclass_id(clk->dev) == UCLASS_CLK) {
> + ret =
> clk_disable(dev_get_clk_ptr(clk->dev->parent)); if (ret) {
> - printf("Disable %s failed\n",
> -clkp->dev->parent->name);
> + printf("Disable %s failed (error
> %d)\n",
> +   

Re: [PATCH v3 02/12] clk: Check that ops of composite clock components, exist before calling

[Lukasz Majewski]

Hi Sean,

> clk_composite_ops was shared between all devices in the composite
> clock driver. If one clock had a feature (such as supporting
> set_parent) which another clock did not, it could call a null pointer
> dereference.
> 
> This patch does three things
> 1. It adds null-pointer checks to all composite clock functions.
> 2. It makes clk_composite_ops const and sets its functions at
> compile-time. 3. It adds some basic sanity checks to num_parents.
> 
> The combined effect of these changes is that any of mux, rate, or
> gate can be NULL, and composite clocks will still function normally.
> Previously, at least mux had to exist, since clk_composite_get_parent
> was used to determine the parent for clk_register.
> 
> Signed-off-by: Sean Anderson 

Acked-by: Lukasz Majewski 

(Please commit clk related patches with this patch set)

> ---
>   Changes for v3:
>   - Don't return an error code where a no-op would be fine
> 
>  drivers/clk/clk-composite.c | 57
> +++-- 1 file changed, 35
> insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index d0f273d47f..5425f921ff 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -22,7 +22,10 @@ static u8 clk_composite_get_parent(struct clk *clk)
>   (struct clk *)dev_get_clk_ptr(clk->dev) : clk);
>   struct clk *mux = composite->mux;
>  
> - return clk_mux_get_parent(mux);
> + if (mux)
> + return clk_mux_get_parent(mux);
> + else
> + return 0;
>  }
>  
>  static int clk_composite_set_parent(struct clk *clk, struct clk
> *parent) @@ -32,7 +35,10 @@ static int
> clk_composite_set_parent(struct clk *clk, struct clk *parent) const
> struct clk_ops *mux_ops = composite->mux_ops; struct clk *mux =
> composite->mux; 
> - return mux_ops->set_parent(mux, parent);
> + if (mux && mux_ops)
> + return mux_ops->set_parent(mux, parent);
> + else
> + return -ENOSYS;
>  }
>  
>  static unsigned long clk_composite_recalc_rate(struct clk *clk)
> @@ -42,7 +48,10 @@ static unsigned long
> clk_composite_recalc_rate(struct clk *clk) const struct clk_ops
> *rate_ops = composite->rate_ops; struct clk *rate = composite->rate;
>  
> - return rate_ops->get_rate(rate);
> + if (rate && rate_ops)
> + return rate_ops->get_rate(rate);
> + else
> + return clk_get_parent_rate(clk);
>  }
>  
>  static ulong clk_composite_set_rate(struct clk *clk, unsigned long
> rate) @@ -52,7 +61,10 @@ static ulong clk_composite_set_rate(struct
> clk *clk, unsigned long rate) const struct clk_ops *rate_ops =
> composite->rate_ops; struct clk *clk_rate = composite->rate;
>  
> - return rate_ops->set_rate(clk_rate, rate);
> + if (rate && rate_ops)
> + return rate_ops->set_rate(clk_rate, rate);
> + else
> + return clk_get_rate(clk);
>  }
>  
>  static int clk_composite_enable(struct clk *clk)
> @@ -62,7 +74,10 @@ static int clk_composite_enable(struct clk *clk)
>   const struct clk_ops *gate_ops = composite->gate_ops;
>   struct clk *gate = composite->gate;
>  
> - return gate_ops->enable(gate);
> + if (gate && gate_ops)
> + return gate_ops->enable(gate);
> + else
> + return 0;
>  }
>  
>  static int clk_composite_disable(struct clk *clk)
> @@ -72,15 +87,12 @@ static int clk_composite_disable(struct clk *clk)
>   const struct clk_ops *gate_ops = composite->gate_ops;
>   struct clk *gate = composite->gate;
>  
> - gate_ops->disable(gate);
> -
> - return 0;
> + if (gate && gate_ops)
> + return gate_ops->disable(gate);
> + else
> + return 0;
>  }
>  
> -struct clk_ops clk_composite_ops = {
> - /* This will be set according to clk_register_composite */
> -};
> -
>  struct clk *clk_register_composite(struct device *dev, const char
> *name, const char * const *parent_names,
>  int num_parents, struct clk *mux,
> @@ -94,7 +106,9 @@ struct clk *clk_register_composite(struct device
> *dev, const char *name, struct clk *clk;
>   struct clk_composite *composite;
>   int ret;
> - struct clk_ops *composite_ops = _composite_ops;
> +
> + if (!num_parents || (num_parents != 1 && !mux))
> + return ERR_PTR(-EINVAL);
>  
>   composite = kzalloc(sizeof(*composite), GFP_KERNEL);
>   if (!composite)
> @@ -103,8 +117,6 @@ struct clk *clk_register_composite(struct device
> *dev, const char *name, if (mux && mux_ops) {
>   composite->mux = mux;
>   composite->mux_ops = mux_ops;
> - if (mux_ops->set_parent)
> - composite_ops->set_parent =
> clk_composite_set_parent; mux->data = (ulong)composite;
>   }
>  
> @@ -113,11 +125,6 @@ struct clk *clk_register_composite(struct device
> *dev, const char *name, clk = ERR_PTR(-EINVAL);
>   

Re: [PATCH v3 01/12] clk: Always use the supplied struct clk

[Lukasz Majewski]

Hi Sean,

> CCF clocks should always use the struct clock passed to their methods
> for extracting the driver-specific clock information struct.
> Previously, many functions would use the clk->dev->priv if the device
> was bound. This could cause problems with composite clocks. The
> individual clocks in a composite clock did not have the ->dev field
> filled in. This was fine, because the device-specific clock
> information would be used. However, since there was no ->dev, there
> was no way to get the parent clock. This caused the recalc_rate
> method of the CCF divider clock to fail. One option would be to use
> the clk->priv field to get the composite clock and from there get the
> appropriate parent device. However, this would tie the implementation
> to the composite clock. In general, different devices should not rely
> on the contents of ->priv from another device.
> 
> The simple solution to this problem is to just always use the
> supplied struct clock. The composite clock now fills in the ->dev
> pointer of its child clocks. This allows child clocks to make calls
> like clk_get_parent() without issue.
> 
> imx avoided the above problem by using a custom get_rate function
> with composite clocks.
> 
> Signed-off-by: Sean Anderson 

Thank you Sean for your CCF enhancement and updating the ccf.txt
documentation entry.

Acked-by: Lukasz Majewski 

I don't mind if RISC-V SoC maintainer pulls the whole series (including
CCF patches).

> ---
>   Changes for v3:
>   - Documented new assumptions in the CCF
>   - Wrapped docs to 80 columns
> 
>  doc/imx/clk/ccf.txt| 63
> +- drivers/clk/clk-composite.c|
> 8 + drivers/clk/clk-divider.c  |  6 ++--
>  drivers/clk/clk-fixed-factor.c |  3 +-
>  drivers/clk/clk-gate.c |  6 ++--
>  drivers/clk/clk-mux.c  | 12 +++
>  drivers/clk/imx/clk-gate2.c|  4 +--
>  7 files changed, 51 insertions(+), 51 deletions(-)
> 
> diff --git a/doc/imx/clk/ccf.txt b/doc/imx/clk/ccf.txt
> index 36b60dc438..e40ac360e8 100644
> --- a/doc/imx/clk/ccf.txt
> +++ b/doc/imx/clk/ccf.txt
> @@ -1,42 +1,37 @@
>  Introduction:
>  =
>  
> -This documentation entry describes the Common Clock Framework [CCF]
> -port from Linux kernel (v5.1.12) to U-Boot.
> +This documentation entry describes the Common Clock Framework [CCF]
> port from +Linux kernel (v5.1.12) to U-Boot.
>  
> -This code is supposed to bring CCF to IMX based devices (imx6q, imx7
> -imx8). Moreover, it also provides some common clock code, which would
> -allow easy porting of CCF Linux code to other platforms.
> +This code is supposed to bring CCF to IMX based devices (imx6q, imx7
> imx8). +Moreover, it also provides some common clock code, which
> would allow easy +porting of CCF Linux code to other platforms.
>  
>  Design decisions:
>  =
>  
> -* U-Boot's driver model [DM] for clk differs from Linux CCF. The most
> -  notably difference is the lack of support for hierarchical clocks
> and
> -  "clock as a manager driver" (single clock DTS node acts as a
> starting
> -  point for all other clocks).
> +* U-Boot's driver model [DM] for clk differs from Linux CCF. The
> most notably
> +  difference is the lack of support for hierarchical clocks and
> "clock as a
> +  manager driver" (single clock DTS node acts as a starting point
> for all other
> +  clocks).
>  
> -* The clk_get_rate() caches the previously read data if
> CLK_GET_RATE_NOCACHE
> -  is not set (no need for recursive access).
> +* The clk_get_rate() caches the previously read data if
> CLK_GET_RATE_NOCACHE is
> +  not set (no need for recursive access).
>  
> -* On purpose the "manager" clk driver (clk-imx6q.c) is not using
> large
> -  table to store pointers to clocks - e.g.
> clk[IMX6QDL_CLK_USDHC2_SEL] = 
> -  Instead we use udevice's linked list for the same class
> (UCLASS_CLK). +* On purpose the "manager" clk driver (clk-imx6q.c) is
> not using large table to
> +  store pointers to clocks - e.g. clk[IMX6QDL_CLK_USDHC2_SEL] = 
> Instead we
> +  use udevice's linked list for the same class (UCLASS_CLK).
>  
>Rationale:
>--
> -When porting the code as is from Linux, one would need ~1KiB of
> RAM to
> -store it. This is way too much if we do plan to use this driver
> in SPL.
> +When porting the code as is from Linux, one would need ~1KiB of
> RAM to store
> +it. This is way too much if we do plan to use this driver in SPL.
>  
>  * The "central" structure of this patch series is struct udevice and
> its uclass_priv field contains the struct clk pointer (to the
> originally created one).
>  
> -* Up till now U-Boot's driver model (DM) CLK operates on udevice
> (main
> -  access to clock is by udevice ops)
> -  In the CCF the access to struct clk (embodying pointer to *dev) is
> -  possible via dev_get_clk_ptr() (it is a wrapper on
> dev_get_uclass_priv()). -
>  * To keep things simple the struct udevice's uclass_priv pointer 

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Alexander Graf]

> Am 06.02.2020 um 22:06 schrieb Atish Patra :
> 
> On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf  wrote:
>> 
>> 
>>> On 06.02.20 19:28, Atish Patra wrote:
>>> On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
>>>  wrote:
 On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt  
 wrote:
> RISC-V booting currently is based on a per boot stage lottery to determine
> the active CPU. The Hart State Management (HSM) SBI extension replaces
> this lottery by using a dedicated primary CPU.
> 
> Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
> 
> In this scenario the id of the active hart has to be passed from boot 
> stage
> to boot stage. Using a UEFI variable would provide an easy implementation.
> 
> This patch provides a weak function that is called at the end of the setup
> of U-Boot's UEFI sub-system. By overriding this function architecture
> specific UEFI variables or configuration tables can be created.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Atish Patra 
 OK, so I have a couple of questions:
 
 - does RISC-V use device tree? if so, why are you not passing the
 active hart via a property in the /chosen node?
>>> Yes. RISC-V uses device tree. Technically, we can pass the active hart
>>> by a DT property
>>> but that means we have to modify the DT in OpenSBI (RISC-V specific
>>> run time service provider).
>>> We have been trying to avoid that if possible so that DT is not
>>> bounced around. This also limits
>>> U-Boot to have its own device tree.
>> 
>> 
>> I don't understand how this is different from the UEFI variable scheme
>> proposed here? If you want to create an SBI interface to propagate the
>> active HART that U-Boot then uses to populate the /chosen property,
>> that's probably fine as well.
>> 
> 
> We don't want to create SBI interface to pass this information.
> 
>> We already have hooks that allow you to modify the DT right before it
>> gets delivered to the payload. Just add it there?
>> 
> 
> Hmm. I guess it is true if the DT is loaded from MMC or network as well.
> How about EDK2 ? If we go DT route, it also has to modify the DT to
> pass the boot hart.
> 
> As it requires DT modification in multiple projects, why not use efi
> configuration tables as
> suggested by Ard ?

How is assembling a configuration table better than modifying a DT?

Alex

> 
>>> 
>>> 
 I'd assume the EFI stub would not care at all about this information, and 
 it would give
 you a Linux/RISC-V specific way to convey this information that is
 independent of EFI.
>>> Yes. EFI stub doesn't care about this information. However, it needs
>>> to save the information somewhere
>>> so that it can pass to the real kernel after exiting boot time services.
>> 
>> 
>> DT sounds like a pretty natural choice for that to me :).
>> 
>> 
>> Alex
>> 
>> 
> 
> 
> -- 
> Regards,
> Atish

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Atish Patra]

On Thu, Feb 6, 2020 at 12:10 PM Alexander Graf  wrote:
>
>
> On 06.02.20 19:28, Atish Patra wrote:
> > On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
> >  wrote:
> >> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt  
> >> wrote:
> >>> RISC-V booting currently is based on a per boot stage lottery to determine
> >>> the active CPU. The Hart State Management (HSM) SBI extension replaces
> >>> this lottery by using a dedicated primary CPU.
> >>>
> >>> Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
> >>> https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
> >>>
> >>> In this scenario the id of the active hart has to be passed from boot 
> >>> stage
> >>> to boot stage. Using a UEFI variable would provide an easy implementation.
> >>>
> >>> This patch provides a weak function that is called at the end of the setup
> >>> of U-Boot's UEFI sub-system. By overriding this function architecture
> >>> specific UEFI variables or configuration tables can be created.
> >>>
> >>> Signed-off-by: Heinrich Schuchardt 
> >>> Reviewed-by: Atish Patra 
> >> OK, so I have a couple of questions:
> >>
> >> - does RISC-V use device tree? if so, why are you not passing the
> >> active hart via a property in the /chosen node?
> > Yes. RISC-V uses device tree. Technically, we can pass the active hart
> > by a DT property
> > but that means we have to modify the DT in OpenSBI (RISC-V specific
> > run time service provider).
> > We have been trying to avoid that if possible so that DT is not
> > bounced around. This also limits
> > U-Boot to have its own device tree.
>
>
> I don't understand how this is different from the UEFI variable scheme
> proposed here? If you want to create an SBI interface to propagate the
> active HART that U-Boot then uses to populate the /chosen property,
> that's probably fine as well.
>

We don't want to create SBI interface to pass this information.

> We already have hooks that allow you to modify the DT right before it
> gets delivered to the payload. Just add it there?
>

Hmm. I guess it is true if the DT is loaded from MMC or network as well.
How about EDK2 ? If we go DT route, it also has to modify the DT to
pass the boot hart.

As it requires DT modification in multiple projects, why not use efi
configuration tables as
suggested by Ard ?

> >
> >
> >> I'd assume the EFI stub would not care at all about this information, and 
> >> it would give
> >> you a Linux/RISC-V specific way to convey this information that is
> >> independent of EFI.
> > Yes. EFI stub doesn't care about this information. However, it needs
> > to save the information somewhere
> > so that it can pass to the real kernel after exiting boot time services.
>
>
> DT sounds like a pretty natural choice for that to me :).
>
>
> Alex
>
>


-- 
Regards,
Atish

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Alexander Graf]

On 06.02.20 19:28, Atish Patra wrote:

On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
 wrote:

On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt  wrote:

RISC-V booting currently is based on a per boot stage lottery to determine
the active CPU. The Hart State Management (HSM) SBI extension replaces
this lottery by using a dedicated primary CPU.

Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc

In this scenario the id of the active hart has to be passed from boot stage
to boot stage. Using a UEFI variable would provide an easy implementation.

This patch provides a weak function that is called at the end of the setup
of U-Boot's UEFI sub-system. By overriding this function architecture
specific UEFI variables or configuration tables can be created.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Atish Patra 

OK, so I have a couple of questions:

- does RISC-V use device tree? if so, why are you not passing the
active hart via a property in the /chosen node?

Yes. RISC-V uses device tree. Technically, we can pass the active hart
by a DT property
but that means we have to modify the DT in OpenSBI (RISC-V specific
run time service provider).
We have been trying to avoid that if possible so that DT is not
bounced around. This also limits
U-Boot to have its own device tree.



I don't understand how this is different from the UEFI variable scheme 
proposed here? If you want to create an SBI interface to propagate the 
active HART that U-Boot then uses to populate the /chosen property, 
that's probably fine as well.


We already have hooks that allow you to modify the DT right before it 
gets delivered to the payload. Just add it there?







I'd assume the EFI stub would not care at all about this information, and it 
would give
you a Linux/RISC-V specific way to convey this information that is
independent of EFI.

Yes. EFI stub doesn't care about this information. However, it needs
to save the information somewhere
so that it can pass to the real kernel after exiting boot time services.



DT sounds like a pretty natural choice for that to me :).


Alex

Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup

[Atish Patra]

On Tue, Feb 4, 2020 at 11:43 PM Ard Biesheuvel
 wrote:
>
> On Wed, 5 Feb 2020 at 05:53, Heinrich Schuchardt  wrote:
> >
> > RISC-V booting currently is based on a per boot stage lottery to determine
> > the active CPU. The Hart State Management (HSM) SBI extension replaces
> > this lottery by using a dedicated primary CPU.
> >
> > Cf. Hart State Management Extension, Extension ID: 0x48534D (HSM)
> > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc
> >
> > In this scenario the id of the active hart has to be passed from boot stage
> > to boot stage. Using a UEFI variable would provide an easy implementation.
> >
> > This patch provides a weak function that is called at the end of the setup
> > of U-Boot's UEFI sub-system. By overriding this function architecture
> > specific UEFI variables or configuration tables can be created.
> >
> > Signed-off-by: Heinrich Schuchardt 
> > Reviewed-by: Atish Patra 
>
> OK, so I have a couple of questions:
>
> - does RISC-V use device tree? if so, why are you not passing the
> active hart via a property in the /chosen node?

Yes. RISC-V uses device tree. Technically, we can pass the active hart
by a DT property
but that means we have to modify the DT in OpenSBI (RISC-V specific
run time service provider).
We have been trying to avoid that if possible so that DT is not
bounced around. This also limits
U-Boot to have its own device tree.


> I'd assume the EFI stub would not care at all about this information, and it 
> would give
> you a Linux/RISC-V specific way to convey this information that is
> independent of EFI.

Yes. EFI stub doesn't care about this information. However, it needs
to save the information somewhere
so that it can pass to the real kernel after exiting boot time services.

> - using variables to pass information from firmware to OS only is
> overkill, and config tables are preferred, given that they only
> require access to the system table. If required, a RISC-V specific
> data structure containing boot parameters could be installed as a
> configuration table, and the address passed to the startup code in the
> kernel proper [rather than just a hart id], allowing you to put any
> piece of information you like in there.
>

Sounds good to me. I will experiment with configuration table and send
the EFI stub patch series.

> Config tables work fine with kexec, btw. It is up to the first OS to
> memblock_reserve() the table to guarantee that it is still there at
> kexec time, but this applies equally to all other data structures
> passed as config tables. Alternatively, in this case, you can
> stipulate that it is passed as AcpiReclaim [ignore the 'Acpi' in the
> name] which is intended for firmware tables (and we never reclaim it
> in linux)
>
> I'd also recommend that RISC-V adopt the same principle as ARM does
> when it comes to EFI: call SetVirtualAddressMap in the stub, so that
> the kernel proper always sees the same handover state, regardless of
> kexec. Additionally, you shouldn't ever modify the EFI memory map
> provided by the firmware, so that the kexec kernel sees the exact same
> version.
>

Sure. There is no kexec implementation available now. We will keep this in mind
while implementing it. Thanks!

>
>
>
> > ---
> > v2:
> > reference the Hart State Management Extension in the commit message
> > ---
> >  include/efi_loader.h   |  3 +++
> >  lib/efi_loader/efi_setup.c | 16 
> >  2 files changed, 19 insertions(+)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index d4c59b54c4..d87de85e83 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -116,6 +116,9 @@ extern efi_uintn_t efi_memory_map_key;
> >  extern struct efi_runtime_services efi_runtime_services;
> >  extern struct efi_system_table systab;
> >
> > +/* Architecture specific initialization of the UEFI system */
> > +efi_status_t efi_setup_arch_specific(void);
> > +
> >  extern struct efi_simple_text_output_protocol efi_con_out;
> >  extern struct efi_simple_text_input_protocol efi_con_in;
> >  extern struct efi_console_control_protocol efi_console_control;
> > diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> > index de7b616c6d..8469f0f43c 100644
> > --- a/lib/efi_loader/efi_setup.c
> > +++ b/lib/efi_loader/efi_setup.c
> > @@ -22,6 +22,17 @@ void __weak allow_unaligned(void)
> >  {
> >  }
> >
> > +/**
> > + * efi_setup_arch_specific() - architecture specific UEFI setup
> > + *
> > + * This routine can be used to define architecture specific variables
> > + * or configuration tables, e.g. HART id for RISC-V
> > + */
> > +efi_status_t __weak efi_setup_arch_specific(void)
> > +{
> > +   return EFI_SUCCESS;
> > +}
> > +
> >  /**
> >   * efi_init_platform_lang() - define supported languages
> >   *
> > @@ -179,6 +190,11 @@ efi_status_t efi_init_obj_list(void)
> > if (ret != EFI_SUCCESS)
> > goto out;
> >
> > +   /* Architecture specific setup */
> > 

RE: [U-Boot Patch v2 4/4] bdinfo: fu540: print fdt base address for debugging

[Sagar Kadam]

Hi Bin,

> -Original Message-
> From: Bin Meng 
> Sent: Tuesday, February 4, 2020 5:43 PM
> To: Sagar Kadam 
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
> 
> Subject: Re: [U-Boot Patch v2 4/4] bdinfo: fu540: print fdt base address for
> debugging
> 
> Hi Sagar,
> 
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
>  wrote:
> >
> > Add fdt->gd info to bdinfo so that it is useful for debugging and
> > easily use it with fdt util.
> 
> The commit title should be tagged with "riscv: bdinfo" as it is not
> fu540 specific.
>
Thanks for the Reviewed-by tag.
I will include the change in next series

BR,
Sagar

> >
> > Signed-off-by: Sagar Shrikant Kadam 
> > ---
> >  cmd/bdinfo.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c index d6a7175..96892b3 100644
> > --- a/cmd/bdinfo.c
> > +++ b/cmd/bdinfo.c
> > @@ -433,6 +433,7 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> > print_bi_dram(bd);
> > print_num("relocaddr", gd->relocaddr);
> > print_num("reloc off", gd->reloc_off);
> > +   print_num("fdt_blob", (ulong)gd->fdt_blob);
> > print_eth_ip_addr();
> > print_baudrate();
> >
> > --
> 
> Other than above,
> Reviewed-by: Bin Meng 
> 
> Regards,
> Bin

RE: [U-Boot Patch v2 3/4] dts: u-boot.dtsi: override flash tx-rx width

[Sagar Kadam]

Hello Bin,

> -Original Message-
> From: Bin Meng 
> Sent: Tuesday, February 4, 2020 5:43 PM
> To: Sagar Kadam 
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
> 
> Subject: Re: [U-Boot Patch v2 3/4] dts: u-boot.dtsi: override flash tx-rx 
> width
> 
> Hi Sagar,
> 
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
>  wrote:
> >
> > The hifive-unleashed-a00.dts has flash spi-tx/rx width set to 4-bit
> > mode. During sf probe, spi_nor_scan fails to read the JEDEC ID with
> > reg_proto set to SNOR_PROTO_1_1_1. Setting it to 1-bit mode as of now
> > will help read the JEDEC-ID and perform other flash operations.
> 
> So previously with Jagan's series that did not have these changes in this
> commit, the flash driver worked well. I wonder what real issue was fixed in
> this commit?
> 
Yes true, I had observed that flash device was working with Jagan's series 
you are indicating here. The flash device was getting probed at cs 2/4/6/8 etc..
but it couldn't get detected on CS0 which is actually connected on the board 
to the flash device. 
With the check of spi->num_cs done in patch 2 of this series or the one handled
in commit 7bacce524d48 ("dm: spi: Check cs number before accessing slaves") 
invalid chip select is taken care of and flash is not detected on wrong chip 
selects,
but spi transfer still fails as the sifive-spi driver set's the 
SIFIVE_SPI_FMT_PROTO_QUAD
mode based on device tree information. While reading Device ID in spi_nor_scan 
the
reg proto is set to 1_1_1 bit mode and this contradicts here in the driver due 
to which
spi_nor_scan fails, due to which one cannot use the flash. 
So for now I have added this override here to 1 bit mode so that users can use 
it. 
Maybe I will update the commit message to indicate that this is workaround for 
a bug
in SPI driver for FU540 which currently is not able to handle QUAD mode 
operation.
Please let me know your views here.

Thanks & BR,
Sagar 
> >
> > Signed-off-by: Sagar Shrikant Kadam 
> > ---
> >  arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > index d7a6413..dae9f87 100644
> > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > @@ -9,3 +9,11 @@
> > spi2 = 
> > };
> >  };
> > +
> > + {
> > +   flash@0 {
> > +   spi-tx-bus-width = <1>;
> > +   spi-rx-bus-width = <1>;
> > +   };
> > +};
> > +
> 
> Regards,
> Bin

RE: [U-Boot Patch v2 2/4] spi: fu540: add claim and release method to spi-sifive.c

[Sagar Kadam]

Hello Bin,

> -Original Message-
> From: Bin Meng 
> Sent: Tuesday, February 4, 2020 5:43 PM
> To: Sagar Kadam 
> Cc: U-Boot Mailing List ; Rick Chen
> ; Paul Walmsley ( Sifive) ;
> Jagan Teki ; Anup Patel
> 
> Subject: Re: [U-Boot Patch v2 2/4] spi: fu540: add claim and release method
> to spi-sifive.c
> 
> Hi Sagar,
> 
> On Wed, Jan 29, 2020 at 2:02 AM Sagar Shrikant Kadam
>  wrote:
> >
> > Add missing bus claim/release method to spi driver for HiFive
> > Unleashed, and handle num_cs generously so that it generates an error
> > if invalid cs number is passed to sf probe.
> 
> Is adding the claim/release method the fix to the weird "sf probe 0:2/4/6/8"
> issue?
> 
Please see below.
> >
> > Signed-off-by: Sagar Shrikant Kadam 
> > ---
> >  drivers/spi/spi-sifive.c | 36 
> >  1 file changed, 36 insertions(+)
> >
> > diff --git a/drivers/spi/spi-sifive.c b/drivers/spi/spi-sifive.c index
> > 969bd4b..f990ad6 100644
> > --- a/drivers/spi/spi-sifive.c
> > +++ b/drivers/spi/spi-sifive.c
> > @@ -186,6 +186,36 @@ static void sifive_spi_tx(struct sifive_spi *spi, const
> u8 *tx_ptr)
> > writel(tx_data, spi->regs + SIFIVE_SPI_REG_TXDATA);  }
> >
> > +static int sifive_spi_claim_bus(struct udevice *dev) {
> > +   int ret;
> > +   struct udevice *bus = dev->parent;
> > +   struct sifive_spi *spi = dev_get_priv(bus);
> > +   struct dm_spi_slave_platdata *slave =
> > +dev_get_parent_platdata(dev);
> > +
> > +   if (!(slave->cs < spi->num_cs)) {
> 
> slave->cs >= spi->num_cs
> 
> But there is already check added recently in the spi-uclass driver, see below:
> 
> commit 7bacce524d48594dae399f9ee9280ab105f6c8cf
> Author: Bin Meng 
> Date:   Mon Sep 9 06:00:02 2019 -0700
> 
> dm: spi: Check cs number before accessing slaves
> 
> Add chip select number check in spi_find_chip_select().
> 
> Signed-off-by: Bin Meng 
> Tested-by: Jagan Teki  # SoPine
> 
> Adding check in the sifive spi driver seems to unnecessary. Could you please
> confirm?
> 
Ahh!!. Thanks for the pointer Bin.
This V2 patch here is based on commit c05b38df477a("common: fix regression
on block cache init"), so didn't come across the patch you pointed out. 
So for now we can skip the check in sifive spi driver.

> > +   printf("Invalid cs number = %d\n", slave->cs);
> > +   return -EINVAL;
> > +   }
> > +
> > +   sifive_spi_prep_device(spi, slave);
> > +
> > +   ret = sifive_spi_set_cs(spi, slave);
> > +   if (ret)
> > +   return ret;
> > +
> > +   return 0;
> > +}
> > +
> > +static int sifive_spi_release_bus(struct udevice *dev) {
> > +   struct sifive_spi *spi = dev_get_priv(dev->parent);
> > +
> > +   sifive_spi_clear_cs(spi);
> > +
> > +   return 0;
> > +}
> 
> What was done in the sifive_spi_claim_bus / sifive_spi_release_bus seems to
> be already done in sifive_spi_xfer(). See flags testing against SPI_XFER_BEGIN
> and SPI_XFER_END.
> 
> Could you please explain a little bit on why adding these 2 fixes things?
> 
What I saw was that sf probe was detecting flash even at wrong chip select 
inputs,
Like sf probe 0:2/4/6/.. this indicated that a check to validate chip selects 
needs to be
there.  The gist of adding the claim function was to introduce this chip select 
check.
The code within SPI_XFER_BEGIN and END functions missed this check. 
Now that the commit your pointed 7bacce524d48 handles this, I think
we can drop this check as of now. 

> > +
> >  static int sifive_spi_xfer(struct udevice *dev, unsigned int bitlen,
> >const void *dout, void *din, unsigned long
> > flags)  { @@ -345,6 +375,10 @@ static int sifive_spi_probe(struct
> > udevice *bus)
> > /* init the sifive spi hw */
> > sifive_spi_init_hw(spi);
> >
> > +   /* Fetch number of chip selects from DT if present */
> > +   ret = dev_read_u32_default(bus, "num-cs", spi->num_cs);
> > +   spi->num_cs = ret;
> 
> spi->num_cs is already assigned a value in sifive_spi_init_hw(), Why
> do we override the value using DT's?
>
Yes, spi_init_hw does initialise the spi->num_cs by reading the register.
For QSPI0 and QSPI2 it is set to 1 (as per the cs_width). But for QSPI1 it is
set to 4. Consider a case where user wishes to populate only 1 chip select for 
QSPI1
then it can be done in respective -dts file and can be updated after 
sifive_spi_init_hw
is done. If the board device tree doesn't contain any such entry than above API 
will retain the
value of spi->num_cs populated in sifive_spi_init_hw().
So to summarize, we can drop claim/release addition from this patch and just 
keep the dev_read_u32_default function done above.
Please let me know your opinion here.
 
Thanks & BR,
Sagar

> > +
> > return 0;
> >  }
> >
> > @@ -353,6 +387,8 @@ static const struct dm_spi_ops sifive_spi_ops = {
> > .set_speed  = sifive_spi_set_speed,
> > .set_mode   = 

Re: dm, serial: problem with using ns16550 driver before relocation on mpc83xx

[Simon Glass]

Hi Heiko,

On Wed, 5 Feb 2020 at 22:19, Heiko Schocher  wrote:
>
> Hello Simon,
>
> Am 05.02.2020 um 18:59 schrieb Simon Glass:
> > Hi Heiko,
> >
> > On Wed, 5 Feb 2020 at 02:04, Heiko Schocher  wrote:
> >>
> >> Hello Bin, Simon,
> >>
> >> I just porting the mpc83xx based kmcoge5ne board support DTS and got
> >> problems using the serial ns16550 driver.
> >>
> >> I need the serial driver before rolcation, so I enabled
> >> "u-boot,dm-pre-reloc;" as usual in the device tree, but board does not
> >> boot ...
> >>
> >> I found the commit:
> >>
> >> commit 4687919684e0e4390b9fc20d1809ecaa9dc3cb81
> >> Author: Bin Meng 
> >> Date:   Wed Oct 24 06:36:36 2018 -0700
> >>
> >>   serial: Remove DM_FLAG_PRE_RELOC flag in various drivers
> >>
> >> which added to the ns16550 serial driver:
> >>
> >> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> >> index 04b604fa2c..1e6fc6c668 100644
> >> --- a/drivers/serial/ns16550.c
> >> +++ b/drivers/serial/ns16550.c
> >> @@ -487,7 +487,9 @@ U_BOOT_DRIVER(ns16550_serial) = {
> >>   .priv_auto_alloc_size = sizeof(struct NS16550),
> >>   .probe = ns16550_serial_probe,
> >>   .ops= _serial_ops,
> >> +#if !CONFIG_IS_ENABLED(OF_CONTROL)
> >>   .flags  = DM_FLAG_PRE_RELOC,
> >> +#endif
> >>};
> >>#endif
> >>#endif /* SERIAL_PRESENT */
> >>
> >> So, as OF_CONTROL is defined for me, the flag "u-boot,dm-pre-reloc" seems
> >> not working anymore ...
> >>
> >> Adding this back:
> >>
> >> hs@xmglap:u-boot-secu  [20200205-temp] $ git diff
> >> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> >> index 9851663dc5..386ca9cffa 100644
> >> --- a/drivers/serial/ns16550.c
> >> +++ b/drivers/serial/ns16550.c
> >> @@ -528,7 +528,7 @@ U_BOOT_DRIVER(ns16550_serial) = {
> >>   .priv_auto_alloc_size = sizeof(struct NS16550),
> >>   .probe = ns16550_serial_probe,
> >>   .ops= _serial_ops,
> >> -#if !CONFIG_IS_ENABLED(OF_CONTROL)
> >> +#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> >>   .flags  = DM_FLAG_PRE_RELOC,
> >>#endif
> >>};
> >>
> >> and board boots fine with the flag "u-boot,dm-pre-reloc" in DTS ...
> >>
> >> May I do something wrong here? I found in mainline for example
> >> the "arch/powerpc/dts/gdsys/gazerbeam-uboot.dtsi" board, which
> >> has the exactly same dts settings than I have now.
> >>
> >> @Dirk: Can you check, if this board boots with current mainline?
> >>
> >> Shouldn;t be the logic, that in case OF_CONTROL is enabled and if
> >> flag "u-boot,dm-pre-reloc" is set in DTS for the device, the device
> >> should be bound before relocation, and we do not need to check, if
> >> the driver sets DM_FLAG_PRE_RELOC ?
> >>
> >> But may I miss here something ...
> >>
> >> Any hints?
> >
> > +Tom Rini
> >
> > I found I needed this for rpi.
> >
> > http://patchwork.ozlabs.org/patch/1202913/
> >
> > But I still haven't gone back to figure out why Tom doesn't.
>
> Hmm... I have added the "u-boot,dm-pre-reloc;" to the uart node.
>
> Like it is for the gazerbeam board, see [1]
>
> It works if "DM_FLAG_PRE_RELOC" is set the driver in flags... no
> need for a gpio node before relocation like it is inabove patch.
>
> I wonder if we need DM_FLAG_PRE_RELOC at all in a driver and
> OF_CONTROL case. Shouldn't it be enough if the DTB node for the
> driver contains the "u-boot,dm-pre-reloc;" property?

Well in the rpi case it is the pinctrl that needs that property. I
think you should dig into exactly what is going wrong on the board you
have. Then it should be possible to see what is missing and add it.

Regards,
Simon

Re: [PATCH v3 1/2] menu: Add a function to set the default by matching the item data

[Simon Glass]

Hi Schrempf,

On Thu, 6 Feb 2020 at 02:09, Schrempf Frieder
 wrote:
>
> From: Frieder Schrempf 
>
> In order to make it possible to auto select a default entry by
> matching the data of the menu entries by an external matching
> function, we add some helpers and expose the
> menu_set_default_by_item_data_match() function.
>
> Signed-off-by: Frieder Schrempf 
> ---
> Changes in v3:
> * Add a full function comment to describe 
> menu_set_default_by_item_data_match().
>
> Changes in v2:
> * Keep the menu structs private and instead only expose one additional
>   function, that sets the default by calling an external matching
>   function on each entry.
> * Change the title and commit message to reflect the changes.
> ---
>  common/menu.c  | 54 ++
>  include/menu.h |  3 +++
>  2 files changed, 57 insertions(+)
>
> diff --git a/common/menu.c b/common/menu.c
> index 7b66d199a9..6110b2396c 100644
> --- a/common/menu.c
> +++ b/common/menu.c
> @@ -160,6 +160,60 @@ static inline struct menu_item *menu_item_by_key(struct 
> menu *m,
> return menu_items_iter(m, menu_item_key_match, item_key);
>  }
>
> +/*
> + * Find the first matching item, if any exists by calling a matching function
> + * on the items data field.
> + */
> +static inline struct menu_item *menu_item_by_matching_fn(struct menu *m,
> +   int match(void *, void *), void * extra)
> +{
> +   struct list_head *pos, *n;
> +   struct menu_item *item;
> +   int ret;
> +
> +   list_for_each_safe(pos, n, >items) {
> +   item = list_entry(pos, struct menu_item, list);
> +   if (item->key) {
> +   ret = match(item->data, extra);
> +   if (ret == 1)
> +   return item;
> +   }
> +   }
> +
> +   return NULL;
> +}
> +
> +/*
> + * menu_set_default_by_item_data_match() - sets a menu default option by 
> calling
> + * a matching function on each of the menu items data field.
> + *
> + * m - Points to a menu created by menu_create().
> + *
> + * match - Points to a function that is passed a pointer to the items data 
> field
> + * and a pointer to extra data to compare with. It should return 1 
> on a
> + * match.
> + *
> + * extra - Points to some data that is passed as a second parameter to the
> + * matching function.
> + *
> + * key - Points to a char array that will be set to hold the key of the 
> matched
> + *   menu item.
> + *
> + * Returns 0 if successful, or -ENOENT if no matching item was found.

Can you please update this to the correct comment style - e.g. see
cmd_process_error() in command.h for example. Also since this is an
exported function the comment should go in the header file.

Regards,
SImon

Re: [PATCH v3] cmd: Add command to dump drivers and compatible strings

[Simon Glass]

On Thu, 6 Feb 2020 at 10:03, Sean Anderson  wrote:
>
> This adds a subcommand to dm to dump out what drivers are installed, and their
> compatible strings. I have found this useful in ensuring that I have the 
> correct
> drivers compiled, and that I have put in the correct compatible strings.
>
> Signed-off-by: Sean Anderson 
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 
>
> ---
>
> Changes in v3:
> - Add python test
>
> Changes in v2:
> - Check if entry->of_match is NULL before accessing it
> - Remove trailing newline in help message
>
>  cmd/dm.c | 12 +++-
>  drivers/core/dump.c  | 20 
>  include/dm/util.h|  3 +++
>  test/py/tests/test_dm.py | 17 +
>  4 files changed, 51 insertions(+), 1 deletion(-)
>  create mode 100644 test/py/tests/test_dm.py

Reviewed-by: Simon Glass 

Re: [PATCH v3 2/2] pxe: Get default selection from board type if label matches

[Simon Glass]

Hi Schrempf,

On Thu, 6 Feb 2020 at 02:09, Schrempf Frieder
 wrote:
>
> From: Frieder Schrempf 
>
> In order to auto-select an option from the pxe boot menu, that
> matches the detected board, we check the board model string in the
> devicetree and set the default menu selection, if it matches the
> label of the menu entry and there is no default selection already
> set.
>
> This is useful in combination with SPL that loads a FIT image with
> U-Boot and multiple DTBs. SPL can detect the board and choose the
> matching configuration in the FIT by using
> board_fit_config_name_match().
>
> Signed-off-by: Frieder Schrempf 
> ---
> Changes in v3:
> * Get rid of #ifdef by using IS_ENABLED() in else branch.
>
> Changes in v2:
> * Don't use internal structs of menu, but instead call
>   menu_set_default_by_item_data_match() that does the iteration work.
> ---
>  cmd/pxe_utils.c | 46 ++
>  1 file changed, 46 insertions(+)
>
> diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
> index 53af04d7dc..253df468af 100644
> --- a/cmd/pxe_utils.c
> +++ b/cmd/pxe_utils.c
> @@ -1220,6 +1220,46 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp, 
> unsigned long menucfg)
> return cfg;
>  }
>
> +#ifdef CONFIG_OF_CONTROL

I think you need to remove this #ifdef, otherwise you'll get a build
error on boards without OF_CONTROL enabled.

> +int pxe_match_menu_label_with_str(void *data, void *str)
> +{
> +   struct pxe_label *label;
> +
> +   if (!data || !str)
> +   return 0;
> +
> +   label = (struct pxe_label *)data;
> +
> +   if (strcmp(label->name, str) == 0)
> +   return 1;
> +
> +   return 0;
> +}
> +
> +int pxe_runtime_select_menu_default(struct menu *m)
> +{
> +   DECLARE_GLOBAL_DATA_PTR;
> +   const char *model;
> +   char *key;
> +   int ret;
> +
> +   model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
> +
> +   if (!model)
> +   return 0;
> +
> +   ret = menu_set_default_by_item_data_match(m,
> +   pxe_match_menu_label_with_str, (void *)model, );
> +   if (ret)
> +   return ret;
> +
> +   printf("Menu entry %s fits detected board. " \
> +  "Use as default selection...\n", key);
> +
> +   return 0;
> +}
> +#endif
> +
>  /*
>   * Converts a pxe_menu struct into a menu struct for use with U-Boot's 
> generic
>   * menu code.
> @@ -1258,6 +1298,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu 
> *cfg)
> /*
>  * After we've created items for each label in the menu, set the
>  * menu's default label if one was specified.
> +* If OF_CONTROL is enabled and we don't have a default specified,
> +* we try to use an entry that matches the board/model name as 
> default.
>  */
> if (default_num) {
> err = menu_default_set(m, default_num);
> @@ -1269,6 +1311,10 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu 
> *cfg)
>
> printf("Missing default: %s\n", cfg->default_label);
> }
> +   } else if (IS_ENABLED(CONFIG_OF_CONTROL) &&
> +  pxe_runtime_select_menu_default(m)) {
> +   menu_destroy(m);
> +   return NULL;
> }
>
> return m;
> --
> 2.17.1

Regards,
Simon

[PATCH v3] cmd: Add command to dump drivers and compatible strings

[Sean Anderson]

This adds a subcommand to dm to dump out what drivers are installed, and their
compatible strings. I have found this useful in ensuring that I have the correct
drivers compiled, and that I have put in the correct compatible strings.

Signed-off-by: Sean Anderson 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 

---

Changes in v3:
- Add python test

Changes in v2:
- Check if entry->of_match is NULL before accessing it
- Remove trailing newline in help message

 cmd/dm.c | 12 +++-
 drivers/core/dump.c  | 20 
 include/dm/util.h|  3 +++
 test/py/tests/test_dm.py | 17 +
 4 files changed, 51 insertions(+), 1 deletion(-)
 create mode 100644 test/py/tests/test_dm.py

diff --git a/cmd/dm.c b/cmd/dm.c
index 7b271db0bb..7a90685f8b 100644
--- a/cmd/dm.c
+++ b/cmd/dm.c
@@ -40,10 +40,19 @@ static int do_dm_dump_devres(cmd_tbl_t *cmdtp, int flag, 
int argc,
return 0;
 }
 
+static int do_dm_dump_drivers(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+   dm_dump_drivers();
+
+   return 0;
+}
+
 static cmd_tbl_t test_commands[] = {
U_BOOT_CMD_MKENT(tree, 0, 1, do_dm_dump_all, "", ""),
U_BOOT_CMD_MKENT(uclass, 1, 1, do_dm_dump_uclass, "", ""),
U_BOOT_CMD_MKENT(devres, 1, 1, do_dm_dump_devres, "", ""),
+   U_BOOT_CMD_MKENT(drivers, 1, 1, do_dm_dump_drivers, "", ""),
 };
 
 static __maybe_unused void dm_reloc(void)
@@ -84,5 +93,6 @@ U_BOOT_CMD(
"Driver model low level access",
"tree  Dump driver model tree ('*' = activated)\n"
"dm uclassDump list of instances for each uclass\n"
-   "dm devresDump list of device resources for each device"
+   "dm devresDump list of device resources for each device\n"
+   "dm drivers   Dump list of drivers and their compatible strings"
 );
diff --git a/drivers/core/dump.c b/drivers/core/dump.c
index 4704049aee..b5046398d4 100644
--- a/drivers/core/dump.c
+++ b/drivers/core/dump.c
@@ -96,3 +96,23 @@ void dm_dump_uclass(void)
puts("\n");
}
 }
+
+void dm_dump_drivers(void)
+{
+   struct driver *d = ll_entry_start(struct driver, driver);
+   const int n_ents = ll_entry_count(struct driver, driver);
+   struct driver *entry;
+   const struct udevice_id *match;
+
+   puts("DriverCompatible\n");
+   puts("\n");
+   for (entry = d; entry < d + n_ents; entry++) {
+   for (match = entry->of_match;
+match && match->compatible; match++)
+   printf("%-20.20s  %s\n",
+  match == entry->of_match ? entry->name : "",
+  match->compatible);
+   if (match == entry->of_match)
+   printf("%-20.20s\n", entry->name);
+   }
+}
diff --git a/include/dm/util.h b/include/dm/util.h
index 348c2ace3c..0ccb3fbadf 100644
--- a/include/dm/util.h
+++ b/include/dm/util.h
@@ -39,6 +39,9 @@ static inline void dm_dump_devres(void)
 }
 #endif
 
+/* Dump out a list of drivers */
+void dm_dump_drivers(void);
+
 /**
  * Check if an of node should be or was bound before relocation.
  *
diff --git a/test/py/tests/test_dm.py b/test/py/tests/test_dm.py
new file mode 100644
index 00..f6fbf8ba4c
--- /dev/null
+++ b/test/py/tests/test_dm.py
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2020 Sean Anderson
+
+import pytest
+
+@pytest.mark.buildconfigspec('cmd_dm')
+def test_dm_drivers(u_boot_console):
+"""Test that each driver in `dm tree` is also listed in `dm drivers`."""
+response = u_boot_console.run_command('dm tree')
+driver_index = response.find('Driver')
+assert driver_index != -1
+drivers = (line[driver_index:].split()[0]
+   for line in response[:-1].split('\n')[2:])
+
+response = u_boot_console.run_command('dm drivers')
+for driver in drivers:
+assert driver in response
-- 
2.25.0

[PATCH v4 16/17] tpm: Add a driver for H1/Cr50

[Simon Glass]

H1 is a Google security chip present in recent Chromebooks, Pixel phones
and other devices. Cr50 is the name of the software that runs on H1 in
Chromebooks.

This chip is used to handle TPM-like functionality and also has quite a
few additional features.

Add a driver for this.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3:
- Fix 'devuce' typo
- s/@tpm/@dev/ in function comments
- Use log_debug() instead of debug()
- Fix 'consceivably' typo
- Rewrite comment for claim_locality()
- Shorten comment in cr50_i2c_wait_tpm_ready() to fit on one line

Changes in v2:
- Significant rewrite of cr50 init procedure
- Support use of interrupts

 drivers/tpm/Kconfig|  10 +
 drivers/tpm/Makefile   |   1 +
 drivers/tpm/cr50_i2c.c | 659 +
 3 files changed, 670 insertions(+)
 create mode 100644 drivers/tpm/cr50_i2c.c

diff --git a/drivers/tpm/Kconfig b/drivers/tpm/Kconfig
index 94629dffd2..555a76bb1e 100644
--- a/drivers/tpm/Kconfig
+++ b/drivers/tpm/Kconfig
@@ -127,6 +127,16 @@ config TPM_V2
 
 if TPM_V2
 
+config TPM2_CR50_I2C
+   bool "Enable support for Google cr50 TPM"
+   depends on DM_I2C
+   help
+ Cr50 is an implementation of a TPM on Google's H1 security chip.
+ This uses the same open-source firmware as the Chromium OS EC.
+ While Cr50 has other features, its primary role is as the root of
+ trust for a device, It operates like a TPM and can be used with
+ verified boot. Cr50 is used on recent Chromebooks (since 2017).
+
 config TPM2_TIS_SANDBOX
bool "Enable sandbox TPMv2.x driver"
depends on TPM_V2 && SANDBOX
diff --git a/drivers/tpm/Makefile b/drivers/tpm/Makefile
index 94c337b8ed..4c866b37c5 100644
--- a/drivers/tpm/Makefile
+++ b/drivers/tpm/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_TPM_TIS_SANDBOX) += tpm_tis_sandbox.o
 obj-$(CONFIG_TPM_ST33ZP24_I2C) += tpm_tis_st33zp24_i2c.o
 obj-$(CONFIG_TPM_ST33ZP24_SPI) += tpm_tis_st33zp24_spi.o
 
+obj-$(CONFIG_TPM2_CR50_I2C) += cr50_i2c.o
 obj-$(CONFIG_TPM2_TIS_SANDBOX) += tpm2_tis_sandbox.o
 obj-$(CONFIG_TPM2_TIS_SPI) += tpm2_tis_spi.o
diff --git a/drivers/tpm/cr50_i2c.c b/drivers/tpm/cr50_i2c.c
new file mode 100644
index 00..b904a7d426
--- /dev/null
+++ b/drivers/tpm/cr50_i2c.c
@@ -0,0 +1,659 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cr50 / H1 TPM support
+ *
+ * Copyright 2018 Google LLC
+ */
+
+#define LOG_CATEGORY UCLASS_TPM
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum {
+   TIMEOUT_INIT_MS = 3, /* Very long timeout for TPM init */
+   TIMEOUT_LONG_US = 2 * 1000 * 1000,
+   TIMEOUT_SHORT_US= 2 * 1000,
+   TIMEOUT_NO_IRQ_US   = 20 * 1000,
+   TIMEOUT_IRQ_US  = 100 * 1000,
+};
+
+enum {
+   CR50_DID_VID = 0x00281ae0L
+};
+
+enum {
+   CR50_MAX_BUF_SIZE = 63,
+};
+
+struct cr50_priv {
+   struct gpio_desc ready_gpio;
+   struct irq irq;
+   int locality;
+   uint vendor;
+   bool use_irq;
+};
+
+/* Wait for interrupt to indicate TPM is ready */
+static int cr50_i2c_wait_tpm_ready(struct udevice *dev)
+{
+   struct cr50_priv *priv = dev_get_priv(dev);
+   ulong timeout, base;
+   int i;
+
+   if (!priv->use_irq && !dm_gpio_is_valid(>ready_gpio)) {
+   /* Fixed delay if interrupt not supported */
+   udelay(TIMEOUT_NO_IRQ_US);
+   return 0;
+   }
+
+   base = timer_get_us();
+   timeout = base + TIMEOUT_IRQ_US;
+
+   i = 0;
+   while (priv->use_irq ? !irq_read_and_clear(>irq) :
+  !dm_gpio_get_value(>ready_gpio)) {
+   i++;
+   if ((int)(timer_get_us() - timeout) >= 0) {
+   log_warning("Timeout\n");
+   /* Use this instead of the -ETIMEDOUT used by i2c */
+   return -ETIME;
+   }
+   }
+   log_debug("i=%d\n", i);
+
+   return 0;
+}
+
+/* Clear pending interrupts */
+static void cr50_i2c_clear_tpm_irq(struct udevice *dev)
+{
+   struct cr50_priv *priv = dev_get_priv(dev);
+
+   if (priv->use_irq)
+   irq_read_and_clear(>irq);
+}
+
+/*
+ * cr50_i2c_read() - read from TPM register
+ *
+ * @dev: TPM chip information
+ * @addr: register address to read from
+ * @buffer: provided by caller
+ * @len: number of bytes to read
+ *
+ * 1) send register address byte 'addr' to the TPM
+ * 2) wait for TPM to indicate it is ready
+ * 3) read 'len' bytes of TPM response into the provided 'buffer'
+ *
+ * Return 0 on success. -ve on error
+ */
+static int cr50_i2c_read(struct udevice *dev, u8 addr, u8 *buffer,
+size_t len)
+{
+   int ret;
+
+   /* Clear interrupt before starting transaction */
+   cr50_i2c_clear_tpm_irq(dev);
+
+   /* Send the register address byte to the TPM */
+   ret = dm_i2c_write(dev, 0, , 1);
+   if 

[PATCH v4 17/17] x86: coral: Enable TPM

[Simon Glass]

Enable TPM2 so that we can use cr50.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4:
- Rebase on latest x86/master

Changes in v3: None
Changes in v2:
- Update the commit message
- Add new patches to handle requesting interrupts and interrupt state

 configs/chromebook_coral_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configs/chromebook_coral_defconfig 
b/configs/chromebook_coral_defconfig
index b156e837ee..a7b71d99a1 100644
--- a/configs/chromebook_coral_defconfig
+++ b/configs/chromebook_coral_defconfig
@@ -53,7 +53,6 @@ CONFIG_CMD_TIME=y
 CONFIG_CMD_SOUND=y
 CONFIG_CMD_BOOTSTAGE=y
 CONFIG_CMD_TPM=y
-CONFIG_CMD_TPM_TEST=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
@@ -90,6 +89,8 @@ CONFIG_SPI=y
 CONFIG_ICH_SPI=y
 CONFIG_TPL_SYSRESET=y
 CONFIG_TPM_TIS_LPC=y
+# CONFIG_TPM_V1 is not set
+CONFIG_TPM2_CR50_I2C=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_KEYBOARD=y
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 12/17] dm: irq: Add support for requesting interrupts

[Simon Glass]

At present driver model supports the IRQ uclass but there is no way to
request a particular interrupt for a driver.

Add a mechanism, similar to clock and reset, to read the interrupts
required by a device from the device tree and to request those interrupts.

U-Boot itself does not have interrupt-driven handlers, so just provide a
means to read and clear an interrupt. This can be useful to handle
peripherals which must use an interrupt to determine when data is
available, for example.

Bring over the basic binding file as well, from Linux v5.4. Note that the
older binding is not supported in U-Boot; the newer 'special form' must be
used.

Add a simple test of the new functionality.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/sandbox/dts/test.dts |   5 +-
 .../interrupt-controller/interrupts.txt   | 131 ++
 drivers/misc/irq-uclass.c | 116 
 drivers/misc/irq_sandbox.c|  41 ++
 include/irq.h | 115 +++
 test/dm/irq.c |  31 +
 6 files changed, 438 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/interrupt-controller/interrupts.txt

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index e529c54d8d..c228447431 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -93,6 +93,7 @@
<_b 9 0xc 3 2 1>;
int-value = <1234>;
uint-value = <(-1234)>;
+   interrupts-extended = < 3 0>;
};
 
junk {
@@ -357,8 +358,10 @@
vss-microvolts = <0>;
};
 
-   irq {
+   irq: irq {
compatible = "sandbox,irq";
+   interrupt-controller;
+   #interrupt-cells = <2>;
};
 
lcd {
diff --git a/doc/device-tree-bindings/interrupt-controller/interrupts.txt 
b/doc/device-tree-bindings/interrupt-controller/interrupts.txt
new file mode 100644
index 00..38a399a6b1
--- /dev/null
+++ b/doc/device-tree-bindings/interrupt-controller/interrupts.txt
@@ -0,0 +1,131 @@
+Specifying interrupt information for devices
+
+
+1) Interrupt client nodes
+-
+
+Nodes that describe devices which generate interrupts must contain an
+"interrupts" property, an "interrupts-extended" property, or both. If both are
+present, the latter should take precedence; the former may be provided simply
+for compatibility with software that does not recognize the latter. These
+properties contain a list of interrupt specifiers, one per output interrupt. 
The
+format of the interrupt specifier is determined by the interrupt controller to
+which the interrupts are routed; see section 2 below for details.
+
+  Example:
+   interrupt-parent = <>;
+   interrupts = <5 0>, <6 0>;
+
+The "interrupt-parent" property is used to specify the controller to which
+interrupts are routed and contains a single phandle referring to the interrupt
+controller node. This property is inherited, so it may be specified in an
+interrupt client node or in any of its parent nodes. Interrupts listed in the
+"interrupts" property are always in reference to the node's interrupt parent.
+
+The "interrupts-extended" property is a special form; useful when a node needs
+to reference multiple interrupt parents or a different interrupt parent than
+the inherited one. Each entry in this property contains both the parent phandle
+and the interrupt specifier.
+
+  Example:
+   interrupts-extended = < 5 1>, < 1 0>;
+
+(NOTE: only this 'special form' is supported in U-Boot)
+
+
+2) Interrupt controller nodes
+-
+
+A device is marked as an interrupt controller with the "interrupt-controller"
+property. This is a empty, boolean property. An additional "#interrupt-cells"
+property defines the number of cells needed to specify a single interrupt.
+
+It is the responsibility of the interrupt controller's binding to define the
+length and format of the interrupt specifier. The following two variants are
+commonly used:
+
+  a) one cell
+  ---
+  The #interrupt-cells property is set to 1 and the single cell defines the
+  index of the interrupt within the controller.
+
+  Example:
+
+   vic: intc@1014 {
+   compatible = "arm,versatile-vic";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0x1014 0x1000>;
+   };
+
+   sic: intc@10003000 {
+   compatible = "arm,versatile-sic";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0x10003000 0x1000>;
+   interrupt-parent = <>;
+   interrupts = <31>; /* Cascaded to vic */
+   };
+
+  b) two cells
+  
+ 

[PATCH v4 13/17] x86: Add support for ACPI general-purpose events

[Simon Glass]

ACPI GPEs are used to signal interrupts from peripherals that are accessed
via ACPI. In U-Boot these are modelled as interrupts using a separate
interrupt controller. Configuration is via the device tree.

Add a simple driver for this.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/x86/Kconfig  | 33 +++
 arch/x86/cpu/Makefile |  1 +
 arch/x86/cpu/acpi_gpe.c   | 85 +++
 .../interrupt-controller/intel,acpi-gpe.txt   | 30 +++
 4 files changed, 149 insertions(+)
 create mode 100644 arch/x86/cpu/acpi_gpe.c
 create mode 100644 
doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b3fbf306f7..c8eae24c07 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -923,4 +923,37 @@ config X86_OFFSET_SPL
depends on SPL && X86
default SPL_TEXT_BASE
 
+config ACPI_GPE
+   bool "Support ACPI general-purpose events"
+   help
+ Enable a driver for ACPI GPEs to allow peripherals to send interrupts
+ via ACPI to the OS. In U-Boot this is only used when U-Boot itself
+ needs access to these interrupts. This can happen when it uses a
+ peripheral that is set up to use GPEs and so cannot use the normal
+ GPIO mechanism for polling an input.
+
+ See https://queue.acm.org/blogposting.cfm?id=18977 for more info
+
+config SPL_ACPI_GPE
+   bool "Support ACPI general-purpose events in SPL"
+   help
+ Enable a driver for ACPI GPEs to allow peripherals to send interrupts
+ via ACPI to the OS. In U-Boot this is only used when U-Boot itself
+ needs access to these interrupts. This can happen when it uses a
+ peripheral that is set up to use GPEs and so cannot use the normal
+ GPIO mechanism for polling an input.
+
+ See https://queue.acm.org/blogposting.cfm?id=18977 for more info
+
+config TPL_ACPI_GPE
+   bool "Support ACPI general-purpose events in TPL"
+   help
+ Enable a driver for ACPI GPEs to allow peripherals to send interrupts
+ via ACPI to the OS. In U-Boot this is only used when U-Boot itself
+ needs access to these interrupts. This can happen when it uses a
+ peripheral that is set up to use GPEs and so cannot use the normal
+ GPIO mechanism for polling an input.
+
+ See https://queue.acm.org/blogposting.cfm?id=18977 for more info
+
 endmenu
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
index 5b40838e60..307267a8fb 100644
--- a/arch/x86/cpu/Makefile
+++ b/arch/x86/cpu/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_INTEL_QUEENSBAY) += queensbay/
 obj-$(CONFIG_INTEL_TANGIER) += tangier/
 obj-$(CONFIG_APIC) += lapic.o ioapic.o
 obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += irq.o
+obj-$(CONFIG_$(SPL_TPL_)ACPI_GPE) += acpi_gpe.o
 obj-$(CONFIG_QFW) += qfw_cpu.o
 ifndef CONFIG_$(SPL_)X86_64
 obj-$(CONFIG_SMP) += mp_init.o
diff --git a/arch/x86/cpu/acpi_gpe.c b/arch/x86/cpu/acpi_gpe.c
new file mode 100644
index 00..55005455c0
--- /dev/null
+++ b/arch/x86/cpu/acpi_gpe.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 Google, LLC
+ * Written by Simon Glass 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct acpi_gpe_priv - private driver information
+ *
+ * @acpi_base: Base I/O address of ACPI registers
+ */
+struct acpi_gpe_priv {
+   ulong acpi_base;
+};
+
+#define GPE0_STS(x)(0x20 + ((x) * 4))
+
+static int acpi_gpe_read_and_clear(struct irq *irq)
+{
+   struct acpi_gpe_priv *priv = dev_get_priv(irq->dev);
+   u32 mask, sts;
+   ulong start;
+   int ret = 0;
+   int bank;
+
+   bank = irq->id / 32;
+   mask = 1 << (irq->id % 32);
+
+   /* Wait up to 1ms for GPE status to clear */
+   start = get_timer(0);
+   do {
+   if (get_timer(start) > 1)
+   return ret;
+
+   sts = inl(priv->acpi_base + GPE0_STS(bank));
+   if (sts & mask) {
+   outl(mask, priv->acpi_base + GPE0_STS(bank));
+   ret = 1;
+   }
+   } while (sts & mask);
+
+   return ret;
+}
+
+static int acpi_gpe_ofdata_to_platdata(struct udevice *dev)
+{
+   struct acpi_gpe_priv *priv = dev_get_priv(dev);
+
+   priv->acpi_base = dev_read_addr(dev);
+   if (!priv->acpi_base || priv->acpi_base == FDT_ADDR_T_NONE)
+   return log_msg_ret("acpi_base", -EINVAL);
+
+   return 0;
+}
+
+static int acpi_gpe_of_xlate(struct irq *irq, struct ofnode_phandle_args *args)
+{
+   irq->id = args->args[0];
+
+   return 0;
+}
+
+static const struct irq_ops acpi_gpe_ops = {
+   .read_and_clear = acpi_gpe_read_and_clear,
+   .of_xlate   = acpi_gpe_of_xlate,
+};
+
+static const struct udevice_id 

[PATCH v4 15/17] tpm: Add more TPM2 definitions

[Simon Glass]

Add definitions for access and status.

Need to drop the mixed case.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 include/tpm-v2.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index ae00803f6d..d53d2e4023 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -161,6 +161,37 @@ enum tpm_index_attrs {
TPMA_NV_AUTHWRITE | TPMA_NV_POLICYWRITE,
 };
 
+enum {
+   TPM_ACCESS_VALID= 1 << 7,
+   TPM_ACCESS_ACTIVE_LOCALITY  = 1 << 5,
+   TPM_ACCESS_REQUEST_PENDING  = 1 << 2,
+   TPM_ACCESS_REQUEST_USE  = 1 << 1,
+   TPM_ACCESS_ESTABLISHMENT= 1 << 0,
+};
+
+enum {
+   TPM_STS_FAMILY_SHIFT= 26,
+   TPM_STS_FAMILY_MASK = 0x3 << TPM_STS_FAMILY_SHIFT,
+   TPM_STS_FAMILY_TPM2 = 1 << TPM_STS_FAMILY_SHIFT,
+   TPM_STS_RESE_TESTABLISMENT_BIT  = 1 << 25,
+   TPM_STS_COMMAND_CANCEL  = 1 << 24,
+   TPM_STS_BURST_COUNT_SHIFT   = 8,
+   TPM_STS_BURST_COUNT_MASK= 0x << TPM_STS_BURST_COUNT_SHIFT,
+   TPM_STS_VALID   = 1 << 7,
+   TPM_STS_COMMAND_READY   = 1 << 6,
+   TPM_STS_GO  = 1 << 5,
+   TPM_STS_DATA_AVAIL  = 1 << 4,
+   TPM_STS_DATA_EXPECT = 1 << 3,
+   TPM_STS_SELF_TEST_DONE  = 1 << 2,
+   TPM_STS_RESPONSE_RETRY  = 1 << 1,
+};
+
+enum {
+   TPM_CMD_COUNT_OFFSET= 2,
+   TPM_CMD_ORDINAL_OFFSET  = 6,
+   TPM_MAX_BUF_SIZE= 1260,
+};
+
 /**
  * Issue a TPM2_Startup command.
  *
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 10/17] x86: Give each driver an IRQ type

[Simon Glass]

Add an IRQ type to each driver and use irq_first_device_type() to find
and probe the correct one.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Move 'success' comment into previous patch

 arch/x86/cpu/apollolake/fsp_s.c  | 4 ++--
 arch/x86/cpu/i386/interrupt.c| 3 ++-
 arch/x86/cpu/intel_common/itss.c | 2 +-
 arch/x86/cpu/irq.c   | 3 ++-
 drivers/pinctrl/intel/pinctrl.c  | 2 +-
 5 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/cpu/apollolake/fsp_s.c b/arch/x86/cpu/apollolake/fsp_s.c
index f8fa4dec8f..b2d9130841 100644
--- a/arch/x86/cpu/apollolake/fsp_s.c
+++ b/arch/x86/cpu/apollolake/fsp_s.c
@@ -535,7 +535,7 @@ int arch_fsps_preinit(void)
struct udevice *itss;
int ret;
 
-   ret = uclass_first_device_err(UCLASS_IRQ, );
+   ret = irq_first_device_type(X86_IRQT_ITSS, );
if (ret)
return log_msg_ret("no itss", ret);
/*
@@ -576,7 +576,7 @@ int arch_fsp_init_r(void)
if (ret)
return ret;
 
-   ret = uclass_first_device_err(UCLASS_IRQ, );
+   ret = irq_first_device_type(X86_IRQT_ITSS, );
if (ret)
return log_msg_ret("no itss", ret);
/* Restore GPIO IRQ polarities back to previous settings */
diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
index 70edbe06e4..4c7e9ea215 100644
--- a/arch/x86/cpu/i386/interrupt.c
+++ b/arch/x86/cpu/i386/interrupt.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -264,7 +265,7 @@ int interrupt_init(void)
int ret;
 
/* Try to set up the interrupt router, but don't require one */
-   ret = uclass_first_device_err(UCLASS_IRQ, );
+   ret = irq_first_device_type(X86_IRQT_BASE, );
if (ret && ret != -ENODEV)
return ret;
 
diff --git a/arch/x86/cpu/intel_common/itss.c b/arch/x86/cpu/intel_common/itss.c
index 9df51adecc..33962cb9a0 100644
--- a/arch/x86/cpu/intel_common/itss.c
+++ b/arch/x86/cpu/intel_common/itss.c
@@ -199,7 +199,7 @@ static const struct irq_ops itss_ops = {
 };
 
 static const struct udevice_id itss_ids[] = {
-   { .compatible = "intel,itss"},
+   { .compatible = "intel,itss", .data = X86_IRQT_ITSS },
{ }
 };
 
diff --git a/arch/x86/cpu/irq.c b/arch/x86/cpu/irq.c
index ed9938f7f7..bafa031082 100644
--- a/arch/x86/cpu/irq.c
+++ b/arch/x86/cpu/irq.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -351,7 +352,7 @@ int irq_router_probe(struct udevice *dev)
 }
 
 static const struct udevice_id irq_router_ids[] = {
-   { .compatible = "intel,irq-router" },
+   { .compatible = "intel,irq-router", .data = X86_IRQT_BASE },
{ }
 };
 
diff --git a/drivers/pinctrl/intel/pinctrl.c b/drivers/pinctrl/intel/pinctrl.c
index 5bf5d8b0e2..f4cc55aa3b 100644
--- a/drivers/pinctrl/intel/pinctrl.c
+++ b/drivers/pinctrl/intel/pinctrl.c
@@ -613,7 +613,7 @@ int intel_pinctrl_ofdata_to_platdata(struct udevice *dev,
log_err("Cannot find community for pid %d\n", pplat->pid);
return -EDOM;
}
-   ret = uclass_first_device_err(UCLASS_IRQ, >itss);
+   ret = irq_first_device_type(X86_IRQT_ITSS, >itss);
if (ret)
return log_msg_ret("Cannot find ITSS", ret);
priv->comm = comm;
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 14/17] x86: coral: Add I2C and TPM device-tree definitions

[Simon Glass]

Add nodes to the device tree for Cr50 and other available I2C ports. Also
enable the ACPI interrupt driver.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Move intel-clock.h inclusion to the correct patch

 arch/x86/cpu/apollolake/Kconfig   |  1 +
 arch/x86/dts/chromebook_coral.dts | 88 +++
 2 files changed, 89 insertions(+)

diff --git a/arch/x86/cpu/apollolake/Kconfig b/arch/x86/cpu/apollolake/Kconfig
index 8a7481555e..942f11f566 100644
--- a/arch/x86/cpu/apollolake/Kconfig
+++ b/arch/x86/cpu/apollolake/Kconfig
@@ -44,6 +44,7 @@ config INTEL_APOLLOLAKE
imply CLK
imply CMD_CLK
imply CLK_INTEL
+   imply ACPI_GPE
 
 if INTEL_APOLLOLAKE
 
diff --git a/arch/x86/dts/chromebook_coral.dts 
b/arch/x86/dts/chromebook_coral.dts
index a4a9e949e6..44a4619a66 100644
--- a/arch/x86/dts/chromebook_coral.dts
+++ b/arch/x86/dts/chromebook_coral.dts
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Google Coral";
@@ -29,6 +30,14 @@
cros-ec0 = _ec;
fsp = _s;
spi0 = 
+   i2c0 = _0;
+   i2c1 = _1;
+   i2c2 = _2;
+   i2c3 = _3;
+   i2c4 = _4;
+   i2c5 = _5;
+   i2c6 = _6;
+   i2c7 = _7;
};
 
config {
@@ -80,6 +89,13 @@
 
};
 
+   acpi_gpe: general-purpose-events {
+   reg = ;
+   compatible = "intel,acpi-gpe";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
keyboard {
intel,duplicate-por;
};
@@ -248,6 +264,78 @@
};
};
 
+   i2c_0: i2c2@16,0 {
+   compatible = "intel,apl-i2c";
+   reg = <0x0200b010 0 0 0 0>;
+   clocks = < CLK_I2C>;
+   i2c-scl-rising-time-ns = <104>;
+   i2c-scl-falling-time-ns = <52>;
+   };
+
+   i2c_1: i2c2@16,1 {
+   compatible = "intel,apl-i2c";
+   reg = <0x0200b110 0 0 0 0>;
+   clocks = < CLK_I2C>;
+   status = "disabled";
+   };
+
+   i2c_2: i2c2@16,2 {
+   compatible = "intel,apl-i2c";
+   reg = <0x0200b210 0 0 0 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clock-frequency = <40>;
+   clocks = < CLK_I2C>;
+   i2c-scl-rising-time-ns = <57>;
+   i2c-scl-falling-time-ns = <28>;
+   tpm@50 {
+   reg = <0x50>;
+   compatible = "google,cr50";
+   u-boot,i2c-offset-len = <0>;
+   ready-gpio = <_n 28 GPIO_ACTIVE_LOW>;
+   interrupts-extended = <_gpe 0x3c 0>;
+   };
+   };
+
+   i2c_3: i2c2@16,3 {
+   compatible = "intel,apl-i2c";
+   reg = <0x0200b110 0 0 0 0>;
+   clocks = < CLK_I2C>;
+   i2c-scl-rising-time-ns = <76>;
+   i2c-scl-falling-time-ns = <164>;
+   };
+
+   i2c_4: i2c2@17,0 {
+   compatible = "intel,apl-i2c";
+   reg = <0x0200b110 0 0 0 0>;
+   clocks = < CLK_I2C>;
+   i2c-sda-hold-time-ns = <350>;
+   i2c-scl-rising-time-ns = <114>;
+   i2c-scl-falling-time-ns = <164>;
+   };
+
+   i2c_5: i2c2@17,1 {
+   compatible = "intel,apl-i2c";
+   reg = <0x0200b110 0 0 0 0>;
+   clocks = < CLK_I2C>;
+   i2c-scl-rising-time-ns = <76>;
+   i2c-scl-falling-time-ns = <164>;
+   };
+
+   i2c_6: i2c2@17,2 {
+   compatible = "intel,apl-i2c";
+   reg = <0x0200b110 0 0 0 0>;
+   clocks = < CLK_I2C>;
+   status = "disabled";
+   };
+
+   i2c_7: i2c2@17,3 {
+   compatible = "intel,apl-i2c";
+   reg = <0x0200b110 0 0 0 0>;
+   clocks = < CLK_I2C>;
+   status = "disabled";
+   };
+
serial: serial@18,2 {
reg = <0x0200c210 0 0 0 0>;
u-boot,dm-pre-reloc;
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 11/17] x86: itss: Add of-platdata support

[Simon Glass]

Allow this driver to be used in TPL by setting up the interrupt type
correctly.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/x86/cpu/intel_common/itss.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/cpu/intel_common/itss.c b/arch/x86/cpu/intel_common/itss.c
index 33962cb9a0..b6b57cc9a0 100644
--- a/arch/x86/cpu/intel_common/itss.c
+++ b/arch/x86/cpu/intel_common/itss.c
@@ -146,6 +146,15 @@ static int route_pmc_gpio_gpe(struct udevice *dev, uint 
pmc_gpe_num)
return -ENOENT;
 }
 
+static int itss_bind(struct udevice *dev)
+{
+   /* This is not set with of-platdata, so set it manually */
+   if (CONFIG_IS_ENABLED(OF_PLATDATA))
+   dev->driver_data = X86_IRQT_ITSS;
+
+   return 0;
+}
+
 static int itss_ofdata_to_platdata(struct udevice *dev)
 {
struct itss_priv *priv = dev_get_priv(dev);
@@ -208,6 +217,7 @@ U_BOOT_DRIVER(itss_drv) = {
.id = UCLASS_IRQ,
.of_match   = itss_ids,
.ops= _ops,
+   .bind   = itss_bind,
.ofdata_to_platdata = itss_ofdata_to_platdata,
.platdata_auto_alloc_size = sizeof(struct itss_platdata),
.priv_auto_alloc_size = sizeof(struct itss_priv),
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 07/17] x86: apl: Drop the I2C config in FSP-S

[Simon Glass]

This config is not actually used here and in U-Boot it seems better to set
this using the device tree for each individual controller. The monolithic
config of the FSP-S is only necessary if the FSP is actually configuring
something, but here it is not.

The FSP-S does enable/disable the various I2C ports. It might be nice to
handle this using the okay/disabled property of each port, but that can be
considered later.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/x86/cpu/apollolake/fsp_s.c | 58 -
 1 file changed, 58 deletions(-)

diff --git a/arch/x86/cpu/apollolake/fsp_s.c b/arch/x86/cpu/apollolake/fsp_s.c
index 9804227f80..f8fa4dec8f 100644
--- a/arch/x86/cpu/apollolake/fsp_s.c
+++ b/arch/x86/cpu/apollolake/fsp_s.c
@@ -24,7 +24,6 @@
 #define HIDE_BIT   BIT(0)
 
 #define INTEL_GSPI_MAX 3
-#define INTEL_I2C_DEV_MAX  8
 #define MAX_USB2_PORTS 8
 
 enum {
@@ -32,36 +31,6 @@ enum {
CHIPSET_LOCKDOWN_COREBOOT, /* coreboot handles locking */
 };
 
-enum i2c_speed {
-   I2C_SPEED_STANDARD  = 10,
-   I2C_SPEED_FAST  = 40,
-   I2C_SPEED_FAST_PLUS = 100,
-   I2C_SPEED_HIGH  = 340,
-   I2C_SPEED_FAST_ULTRA= 500,
-};
-
-/*
- * Timing values are in units of clock period, with the clock speed
- * provided by the SOC
- *
- * TODO(s...@chromium.org): Connect this up to the I2C driver
- */
-struct dw_i2c_speed_config {
-   enum i2c_speed speed;
-   /* SCL high and low period count */
-   u16 scl_lcnt;
-   u16 scl_hcnt;
-   /*
-* SDA hold time should be 300ns in standard and fast modes
-* and long enough for deterministic logic level change in
-* fast-plus and high speed modes.
-*
-*  [15:0] SDA TX Hold Time
-* [23:16] SDA RX Hold Time
-*/
-   u32 sda_hold;
-};
-
 /* Serial IRQ control. SERIRQ_QUIET is the default (0) */
 enum serirq_mode {
SERIRQ_QUIET,
@@ -69,32 +38,6 @@ enum serirq_mode {
SERIRQ_OFF,
 };
 
-/*
- * This I2C controller has support for 3 independent speed configs but can
- * support both FAST_PLUS and HIGH speeds through the same set of speed
- * config registers.  These are treated separately so the speed config values
- * can be provided via ACPI to the OS.
- */
-#define DW_I2C_SPEED_CONFIG_COUNT  4
-
-struct dw_i2c_bus_config {
-   /* Bus should be enabled in TPL with temporary base */
-   int early_init;
-   /* Bus speed in Hz, default is I2C_SPEED_FAST (400 KHz) */
-   enum i2c_speed speed;
-   /*
-* If rise_time_ns is non-zero the calculations for lcnt and hcnt
-* registers take into account the times of the bus. However, if
-* there is a match in speed_config those register values take
-* precedence
-*/
-   int rise_time_ns;
-   int fall_time_ns;
-   int data_hold_time_ns;
-   /* Specific bus speed configuration */
-   struct dw_i2c_speed_config speed_config[DW_I2C_SPEED_CONFIG_COUNT];
-};
-
 struct gspi_cfg {
/* Bus speed in MHz */
u32 speed_mhz;
@@ -110,7 +53,6 @@ struct gspi_cfg {
 struct soc_intel_common_config {
int chipset_lockdown;
struct gspi_cfg gspi[INTEL_GSPI_MAX];
-   struct dw_i2c_bus_config i2c[INTEL_I2C_DEV_MAX];
 };
 
 enum pnp_settings {
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 06/17] x86: apl: Use the clock driver

[Simon Glass]

Enable the Intel clock driver and modify coral's device tree to use it.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Move intel-clock.h inclusion to the correct patch

 arch/x86/cpu/apollolake/Kconfig   | 3 +++
 arch/x86/dts/chromebook_coral.dts | 5 +
 2 files changed, 8 insertions(+)

diff --git a/arch/x86/cpu/apollolake/Kconfig b/arch/x86/cpu/apollolake/Kconfig
index 145b8cbdf5..8a7481555e 100644
--- a/arch/x86/cpu/apollolake/Kconfig
+++ b/arch/x86/cpu/apollolake/Kconfig
@@ -41,6 +41,9 @@ config INTEL_APOLLOLAKE
imply SMP
imply HAVE_ITSS
imply HAVE_P2SB
+   imply CLK
+   imply CMD_CLK
+   imply CLK_INTEL
 
 if INTEL_APOLLOLAKE
 
diff --git a/arch/x86/dts/chromebook_coral.dts 
b/arch/x86/dts/chromebook_coral.dts
index a1820fa187..a4a9e949e6 100644
--- a/arch/x86/dts/chromebook_coral.dts
+++ b/arch/x86/dts/chromebook_coral.dts
@@ -39,6 +39,11 @@
stdout-path = 
};
 
+   clk: clock {
+   compatible = "intel,apl-clk";
+   #clock-cells = <1>;
+   };
+
cpus {
u-boot,dm-pre-reloc;
#address-cells = <1>;
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 05/17] x86: Add a clock driver for Intel devices

[Simon Glass]

So far we have avoided adding a clock driver for Intel devices. But the
Designware I2C driver needs a different clock (133MHz) on Intel devices
than on others (166MHz). Add a simple driver that provides this
information.

This driver can be expanded later as needed.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/clk/Kconfig | 10 ++
 drivers/clk/Makefile|  1 +
 drivers/clk/intel/Makefile  |  6 
 drivers/clk/intel/clk_intel.c   | 41 +
 include/dt-bindings/clock/intel-clock.h | 15 +
 5 files changed, 73 insertions(+)
 create mode 100644 drivers/clk/intel/Makefile
 create mode 100644 drivers/clk/intel/clk_intel.c
 create mode 100644 include/dt-bindings/clock/intel-clock.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 16d4237f89..1992d4a4b4 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -73,6 +73,16 @@ config CLK_COMPOSITE_CCF
  Enable this option if you want to (re-)use the Linux kernel's Common
  Clock Framework [CCF] composite code in U-Boot's clock driver.
 
+config CLK_INTEL
+   bool "Enable clock driver for Intel x86"
+   depends on CLK && X86
+   help
+ This provides very basic support for clocks on Intel SoCs. The driver
+ is barely used at present but could be expanded as needs arise.
+ Much clock configuration in U-Boot is either set up by the FSP, or
+ set up by U-Boot itself but only statically. Thus the driver does not
+ support changing clock rates, only querying them.
+
 config CLK_STM32F
bool "Enable clock driver support for STM32F family"
depends on CLK && (STM32F7 || STM32F4)
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 06131edb9f..e01783391d 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_CLK_MVEBU) += mvebu/
 obj-$(CONFIG_CLK_BCM6345) += clk_bcm6345.o
 obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
 obj-$(CONFIG_CLK_EXYNOS) += exynos/
+obj-$(CONFIG_$(SPL_TPL_)CLK_INTEL) += intel/
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
 obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
 obj-$(CONFIG_CLK_OWL) += owl/
diff --git a/drivers/clk/intel/Makefile b/drivers/clk/intel/Makefile
new file mode 100644
index 00..45e93d7024
--- /dev/null
+++ b/drivers/clk/intel/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright 2010 Google LLC
+#
+
+obj-y += clk_intel.o
diff --git a/drivers/clk/intel/clk_intel.c b/drivers/clk/intel/clk_intel.c
new file mode 100644
index 00..d2e15491a3
--- /dev/null
+++ b/drivers/clk/intel/clk_intel.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 Google LLC
+ * Written by Simon Glass 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static ulong intel_clk_get_rate(struct clk *clk)
+{
+   ulong rate;
+
+   switch (clk->id) {
+   case CLK_I2C:
+   /* Hard-coded to 133MHz on current platforms */
+   return 1;
+   default:
+   return -ENODEV;
+   }
+
+   return rate;
+}
+
+static struct clk_ops intel_clk_ops = {
+   .get_rate   = intel_clk_get_rate,
+};
+
+static const struct udevice_id intel_clk_ids[] = {
+   { .compatible = "intel,apl-clk" },
+   { }
+};
+
+U_BOOT_DRIVER(clk_intel) = {
+   .name   = "clk_intel",
+   .id = UCLASS_CLK,
+   .of_match   = intel_clk_ids,
+   .ops= _clk_ops,
+};
diff --git a/include/dt-bindings/clock/intel-clock.h 
b/include/dt-bindings/clock/intel-clock.h
new file mode 100644
index 00..e1edd3c71d
--- /dev/null
+++ b/include/dt-bindings/clock/intel-clock.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * This header provides constants for Intel clocks.
+ *
+ * The constants defined in this header are used in the device tree
+ *
+ * Copyright 2019 Google LLC
+ */
+
+#ifndef _DT_BINDINGS_CLK_INTEL_H
+#define _DT_BINDINGS_CLK_INTEL_H
+
+#define CLK_I2C1
+
+#endif
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 04/17] tegra: i2c: Change driver to use helper function

[Simon Glass]

Now that we have uclass_first_device_drvdata(), use it from the I2C driver
to reduce code duplication.

Signed-off-by: Simon Glass 
Reviewed-by: Heiko Schocher 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Add new patch to change tegra driver to use helper function

 drivers/i2c/tegra_i2c.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/i2c/tegra_i2c.c b/drivers/i2c/tegra_i2c.c
index 4be41ddbf0..142463ef44 100644
--- a/drivers/i2c/tegra_i2c.c
+++ b/drivers/i2c/tegra_i2c.c
@@ -499,18 +499,7 @@ static int tegra_i2c_xfer(struct udevice *bus, struct 
i2c_msg *msg,
 
 int tegra_i2c_get_dvc_bus(struct udevice **busp)
 {
-   struct udevice *bus;
-
-   for (uclass_first_device(UCLASS_I2C, );
-bus;
-uclass_next_device()) {
-   if (dev_get_driver_data(bus) == TYPE_DVC) {
-   *busp = bus;
-   return 0;
-   }
-   }
-
-   return -ENODEV;
+   return uclass_first_device_drvdata(UCLASS_I2C, TYPE_DVC, busp);
 }
 
 static const struct dm_i2c_ops tegra_i2c_ops = {
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 09/17] dm: irq: Add support for interrupt controller types

[Simon Glass]

There can be different types of interrupt controllers in a system and some
drivers may need to distinguish between these. In general this can be
handled using the device tree by adding the interrupt information to
device nodes.

However on x86 devices we have interrupt controllers which are not tied
to any particular device and not really used in U-Boot. These still need
to be inited, so a convenient method is to give each controller a type
and allow a particular controller type to be probed.

Add support for this in sandbox along with a test.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Move 'success' comment into this patch
- Update to use the new DM helper function

 arch/sandbox/include/asm/test.h |  4 
 drivers/misc/irq-uclass.c   | 15 ++-
 drivers/misc/irq_sandbox.c  |  2 +-
 include/irq.h   | 23 +++
 test/dm/irq.c   | 14 ++
 5 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
index 2421922c9e..7775794eaa 100644
--- a/arch/sandbox/include/asm/test.h
+++ b/arch/sandbox/include/asm/test.h
@@ -45,6 +45,10 @@
 #define PCI_EA_BAR2_MAGIC  0x72727272
 #define PCI_EA_BAR4_MAGIC  0x74747474
 
+enum {
+   SANDBOX_IRQN_PEND = 1,  /* Interrupt number for 'pending' test */
+};
+
 /* System controller driver data */
 enum {
SYSCON0 = 32,
diff --git a/drivers/misc/irq-uclass.c b/drivers/misc/irq-uclass.c
index d5182cf149..c52c813ff3 100644
--- a/drivers/misc/irq-uclass.c
+++ b/drivers/misc/irq-uclass.c
@@ -1,11 +1,13 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2015, Bin Meng 
+ * Copyright 2019 Google, LLC
+ * Written by Simon Glass 
  */
 
 #include 
 #include 
 #include 
+#include 
 
 int irq_route_pmc_gpio_gpe(struct udevice *dev, uint pmc_gpe_num)
 {
@@ -47,6 +49,17 @@ int irq_restore_polarities(struct udevice *dev)
return ops->restore_polarities(dev);
 }
 
+int irq_first_device_type(enum irq_dev_t type, struct udevice **devp)
+{
+   int ret;
+
+   ret = uclass_first_device_drvdata(UCLASS_IRQ, type, devp);
+   if (ret)
+   return log_msg_ret("find", ret);
+
+   return 0;
+}
+
 UCLASS_DRIVER(irq) = {
.id = UCLASS_IRQ,
.name   = "irq",
diff --git a/drivers/misc/irq_sandbox.c b/drivers/misc/irq_sandbox.c
index 6dda1a4c44..011022ac62 100644
--- a/drivers/misc/irq_sandbox.c
+++ b/drivers/misc/irq_sandbox.c
@@ -43,7 +43,7 @@ static const struct irq_ops sandbox_irq_ops = {
 };
 
 static const struct udevice_id sandbox_irq_ids[] = {
-   { .compatible = "sandbox,irq"},
+   { .compatible = "sandbox,irq", SANDBOX_IRQT_BASE },
{ }
 };
 
diff --git a/include/irq.h b/include/irq.h
index 01ded64f16..8b4e2ecfc0 100644
--- a/include/irq.h
+++ b/include/irq.h
@@ -8,6 +8,17 @@
 #ifndef __irq_H
 #define __irq_H
 
+/*
+ * Interrupt controller types available. You can find a particular one with
+ * irq_first_device_type()
+ */
+enum irq_dev_t {
+   X86_IRQT_BASE,  /* Base controller */
+   X86_IRQT_ITSS,  /* ITSS controller, e.g. on APL */
+   X86_IRQT_ACPI_GPE,  /* ACPI General-Purpose Events controller */
+   SANDBOX_IRQT_BASE,  /* Sandbox testing */
+};
+
 /**
  * struct irq_ops - Operations for the IRQ
  */
@@ -85,4 +96,16 @@ int irq_snapshot_polarities(struct udevice *dev);
  */
 int irq_restore_polarities(struct udevice *dev);
 
+/**
+ * irq_first_device_type() - Get a particular interrupt controller
+ *
+ * On success this returns an activated interrupt device.
+ *
+ * @type: Type to find
+ * @devp: Returns the device, if found
+ * @return 0 if OK, -ENODEV if not found, other -ve error if uclass failed to
+ * probe
+ */
+int irq_first_device_type(enum irq_dev_t type, struct udevice **devp);
+
 #endif
diff --git a/test/dm/irq.c b/test/dm/irq.c
index 726189c59f..0f23f108a7 100644
--- a/test/dm/irq.c
+++ b/test/dm/irq.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -30,3 +31,16 @@ static int dm_test_irq_base(struct unit_test_state *uts)
return 0;
 }
 DM_TEST(dm_test_irq_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test of irq_first_device_type() */
+static int dm_test_irq_type(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+
+   ut_assertok(irq_first_device_type(SANDBOX_IRQT_BASE, ));
+   ut_asserteq(-ENODEV, irq_first_device_type(X86_IRQT_BASE, ));
+
+   return 0;
+}
+DM_TEST(dm_test_irq_type, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 08/17] x86: coral: Update i2c and rtc status

[Simon Glass]

These are actually working correctly, so update the status.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 doc/board/google/chromebook_coral.rst | 2 --
 1 file changed, 2 deletions(-)

diff --git a/doc/board/google/chromebook_coral.rst 
b/doc/board/google/chromebook_coral.rst
index 5dc3c97c3d..d10e0c4954 100644
--- a/doc/board/google/chromebook_coral.rst
+++ b/doc/board/google/chromebook_coral.rst
@@ -213,9 +213,7 @@ To do
- left-side USB
- USB-C
- Cr50 (security chip: a basic driver is running but not included here)
-   - I2C (driver exists but not enabled in device tree)
- Sound (Intel I2S support exists, but need da7219 driver)
-   - RTC (driver exists but not enabled in device tree)
- Various minor features supported by LPC, etc.
 - Booting Chrome OS, e.g. with verified boot
 - Integrate with Chrome OS vboot
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 03/17] dm: core: Change syscon to use helper function

[Simon Glass]

Now that we have uclass_first_device_drvdata(), use it from syscon to
reduce code duplication.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Add new patch to change syscon to use helper function

 drivers/core/syscon-uclass.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/core/syscon-uclass.c b/drivers/core/syscon-uclass.c
index 5bb38e329c..b9ae82174e 100644
--- a/drivers/core/syscon-uclass.c
+++ b/drivers/core/syscon-uclass.c
@@ -128,22 +128,15 @@ struct regmap *syscon_regmap_lookup_by_phandle(struct 
udevice *dev,
 
 int syscon_get_by_driver_data(ulong driver_data, struct udevice **devp)
 {
-   struct udevice *dev;
-   struct uclass *uc;
int ret;
 
*devp = NULL;
-   ret = uclass_get(UCLASS_SYSCON, );
+
+   ret = uclass_first_device_drvdata(UCLASS_SYSCON, driver_data, devp);
if (ret)
-   return ret;
-   uclass_foreach_dev(dev, uc) {
-   if (dev->driver_data == driver_data) {
-   *devp = dev;
-   return device_probe(dev);
-   }
-   }
+   return log_msg_ret("find", ret);
 
-   return -ENODEV;
+   return 0;
 }
 
 struct regmap *syscon_get_regmap_by_driver_data(ulong driver_data)
-- 
2.25.0.341.g760bfbb309-goog

Re: [PATCH v3 00/17] x86: coral: Add support for Cr50

[Simon Glass]

Hi Bin,

On Wed, 5 Feb 2020 at 23:22, Bin Meng  wrote:
>
> Hi Simon,
>
> On Wed, Feb 5, 2020 at 10:03 AM Simon Glass  wrote:
> >
> > This series adds a driver for the Cr50 security chip and enables it on
> > coral. This supports the 'tpm' command.
> >
> > In order to make this work a few other changes are included:
> > - Additional UCLASS_IRQ operations to support requesting and reading
> >   interrupts, using the device tree
> > - A driver for ACPI general-purpose events
> >
> > There are also a few small clean-ups to the recently landed Apollo Lake
> > support.
> >
> > This series relies on this patch:
> >
> >http://patchwork.ozlabs.org/patch/1214541/
> >
>
> This series does not apply on top of u-boot-x86/master:
>
> Applying: x86: apl: Use the clock driver
> error: patch failed: arch/x86/cpu/apollolake/Kconfig:40
> error: arch/x86/cpu/apollolake/Kconfig: patch does not apply
> Patch failed at 0006 x86: apl: Use the clock driver
>
> I tried to apply it on top of an old commit and got no luck.
>
> Would you please rebase this series against u-boot-x86/master and resend?

Yes, will do.

Any thoughts on the ACPI series? I need to rebase that as well.

Regards,
Simon

[PATCH v4 02/17] dm: core: Add a function to find a device by drvdata

[Simon Glass]

It is sometimes useful to find a device in a uclass using only its driver
data. The driver data often indicates the 'subtype' of the device, e,g,
via its compatible string.

Add a function to handle this.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Add new patch to find a device by drvdata

 drivers/core/uclass.c | 17 +
 include/dm/test.h |  2 ++
 include/dm/uclass.h   | 14 ++
 test/dm/test-fdt.c| 21 +
 4 files changed, 54 insertions(+)

diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index c520ef113a..61192d8a9f 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -629,6 +629,23 @@ int uclass_next_device_check(struct udevice **devp)
return device_probe(*devp);
 }
 
+int uclass_first_device_drvdata(enum uclass_id id, ulong driver_data,
+   struct udevice **devp)
+{
+   struct udevice *dev;
+   struct uclass *uc;
+
+   uclass_id_foreach_dev(id, dev, uc) {
+   if (dev_get_driver_data(dev) == driver_data) {
+   *devp = dev;
+
+   return device_probe(dev);
+   }
+   }
+
+   return -ENODEV;
+}
+
 int uclass_bind_device(struct udevice *dev)
 {
struct uclass *uc;
diff --git a/include/dm/test.h b/include/dm/test.h
index 07385cd531..f0f36624ce 100644
--- a/include/dm/test.h
+++ b/include/dm/test.h
@@ -56,6 +56,8 @@ enum {
 enum {
DM_TEST_TYPE_FIRST = 0,
DM_TEST_TYPE_SECOND,
+
+   DM_TEST_TYPE_COUNT,
 };
 
 /* The number added to the ping total on each probe */
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index 74b8e2ecb5..70fca79b44 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -350,6 +350,20 @@ int uclass_first_device_check(enum uclass_id id, struct 
udevice **devp);
  */
 int uclass_next_device_check(struct udevice **devp);
 
+/**
+ * uclass_first_device_drvdata() - Find the first device with given driver data
+ *
+ * This searches through the devices for a particular uclass looking for one
+ * that has the given driver data.
+ *
+ * @id: Uclass ID to check
+ * @driver_data: Driver data to search for
+ * @devp: Returns pointer to the first matching device in that uclass, if found
+ * @return 0 if found, -ENODEV if not found, other -ve on error
+ */
+int uclass_first_device_drvdata(enum uclass_id id, ulong driver_data,
+   struct udevice **devp);
+
 /**
  * uclass_resolve_seq() - Resolve a device's sequence number
  *
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 8ea536c309..698ca0e7cf 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -893,3 +893,24 @@ static int dm_test_read_int(struct unit_test_state *uts)
return 0;
 }
 DM_TEST(dm_test_read_int, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test iteration through devices by drvdata */
+static int dm_test_uclass_drvdata(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+
+   ut_assertok(uclass_first_device_drvdata(UCLASS_TEST_FDT,
+   DM_TEST_TYPE_FIRST, ));
+   ut_asserteq_str("a-test", dev->name);
+
+   ut_assertok(uclass_first_device_drvdata(UCLASS_TEST_FDT,
+   DM_TEST_TYPE_SECOND, ));
+   ut_asserteq_str("d-test", dev->name);
+
+   ut_asserteq(-ENODEV, uclass_first_device_drvdata(UCLASS_TEST_FDT,
+DM_TEST_TYPE_COUNT,
+));
+
+   return 0;
+}
+DM_TEST(dm_test_uclass_drvdata, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 01/17] dm: core: Allow iterating devices without uclass_get()

[Simon Glass]

At present we have uclass_foreach_dev() which requires that uclass_get()
be called beforehand to find the uclass. This is good if we suspect that
that function might fail, but often we know that the uclass is available.

Add a new helper which does this uclass_get() automatically, so that only
the uclass ID is needed.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Add new patch to allow iterating devices without uclass_get()

 include/dm/uclass.h | 17 +
 test/dm/test-fdt.c  | 21 +
 2 files changed, 38 insertions(+)

diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index 484d166013..74b8e2ecb5 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -365,6 +365,23 @@ int uclass_next_device_check(struct udevice **devp);
  */
 int uclass_resolve_seq(struct udevice *dev);
 
+/**
+ * uclass_id_foreach_dev() - Helper function to iteration through devices
+ *
+ * This creates a for() loop which works through the available devices in
+ * a uclass ID in order from start to end.
+ *
+ * If for some reason the uclass cannot be found, this does nothing.
+ *
+ * @id: enum uclass_id ID to use
+ * @pos: struct udevice * to hold the current device. Set to NULL when there
+ * are no more devices.
+ * @uc: temporary uclass variable (struct udevice *)
+ */
+#define uclass_id_foreach_dev(id, pos, uc) \
+   if (!uclass_get(id, )) \
+   list_for_each_entry(pos, >dev_head, uclass_node)
+
 /**
  * uclass_foreach_dev() - Helper function to iteration through devices
  *
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index d59c449ce0..8ea536c309 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -448,6 +448,27 @@ static int dm_test_first_next_device(struct 
unit_test_state *uts)
 }
 DM_TEST(dm_test_first_next_device, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
 
+/* Test iteration through devices in a uclass */
+static int dm_test_uclass_foreach(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+   struct uclass *uc;
+   int count;
+
+   count = 0;
+   uclass_id_foreach_dev(UCLASS_TEST_FDT, dev, uc)
+   count++;
+   ut_asserteq(8, count);
+
+   count = 0;
+   uclass_foreach_dev(dev, uc)
+   count++;
+   ut_asserteq(8, count);
+
+   return 0;
+}
+DM_TEST(dm_test_uclass_foreach, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
 /**
  * check_devices() - Check return values and pointers
  *
-- 
2.25.0.341.g760bfbb309-goog

[PATCH v4 00/17] x86: coral: Add support for Cr50

[Simon Glass]

This series adds a driver for the Cr50 security chip and enables it on
coral. This supports the 'tpm' command.

In order to make this work a few other changes are included:
- Additional UCLASS_IRQ operations to support requesting and reading
  interrupts, using the device tree
- A driver for ACPI general-purpose events

There are also a few small clean-ups to the recently landed Apollo Lake
support.

This series relies on this patch:

   http://patchwork.ozlabs.org/patch/1214541/

Changes in v4:
- Rebase on latest x86/master

Changes in v3:
- Fix 'devuce' typo
- s/@tpm/@dev/ in function comments
- Use log_debug() instead of debug()
- Fix 'consceivably' typo
- Rewrite comment for claim_locality()
- Shorten comment in cr50_i2c_wait_tpm_ready() to fit on one line

Changes in v2:
- Add new patch to allow iterating devices without uclass_get()
- Add new patch to find a device by drvdata
- Add new patch to change syscon to use helper function
- Add new patch to change tegra driver to use helper function
- Move intel-clock.h inclusion to the correct patch
- Move 'success' comment into this patch
- Update to use the new DM helper function
- Move 'success' comment into previous patch
- Move intel-clock.h inclusion to the correct patch
- Significant rewrite of cr50 init procedure
- Support use of interrupts
- Update the commit message
- Add new patches to handle requesting interrupts and interrupt state

Simon Glass (17):
  dm: core: Allow iterating devices without uclass_get()
  dm: core: Add a function to find a device by drvdata
  dm: core: Change syscon to use helper function
  tegra: i2c: Change driver to use helper function
  x86: Add a clock driver for Intel devices
  x86: apl: Use the clock driver
  x86: apl: Drop the I2C config in FSP-S
  x86: coral: Update i2c and rtc status
  dm: irq: Add support for interrupt controller types
  x86: Give each driver an IRQ type
  x86: itss: Add of-platdata support
  dm: irq: Add support for requesting interrupts
  x86: Add support for ACPI general-purpose events
  x86: coral: Add I2C and TPM device-tree definitions
  tpm: Add more TPM2 definitions
  tpm: Add a driver for H1/Cr50
  x86: coral: Enable TPM

 arch/sandbox/dts/test.dts |   5 +-
 arch/sandbox/include/asm/test.h   |   4 +
 arch/x86/Kconfig  |  33 +
 arch/x86/cpu/Makefile |   1 +
 arch/x86/cpu/acpi_gpe.c   |  85 +++
 arch/x86/cpu/apollolake/Kconfig   |   4 +
 arch/x86/cpu/apollolake/fsp_s.c   |  62 +-
 arch/x86/cpu/i386/interrupt.c |   3 +-
 arch/x86/cpu/intel_common/itss.c  |  12 +-
 arch/x86/cpu/irq.c|   3 +-
 arch/x86/dts/chromebook_coral.dts |  93 +++
 configs/chromebook_coral_defconfig|   3 +-
 doc/board/google/chromebook_coral.rst |   2 -
 .../interrupt-controller/intel,acpi-gpe.txt   |  30 +
 .../interrupt-controller/interrupts.txt   | 131 
 drivers/clk/Kconfig   |  10 +
 drivers/clk/Makefile  |   1 +
 drivers/clk/intel/Makefile|   6 +
 drivers/clk/intel/clk_intel.c |  41 ++
 drivers/core/syscon-uclass.c  |  15 +-
 drivers/core/uclass.c |  17 +
 drivers/i2c/tegra_i2c.c   |  13 +-
 drivers/misc/irq-uclass.c | 131 +++-
 drivers/misc/irq_sandbox.c|  43 +-
 drivers/pinctrl/intel/pinctrl.c   |   2 +-
 drivers/tpm/Kconfig   |  10 +
 drivers/tpm/Makefile  |   1 +
 drivers/tpm/cr50_i2c.c| 659 ++
 include/dm/test.h |   2 +
 include/dm/uclass.h   |  31 +
 include/dt-bindings/clock/intel-clock.h   |  15 +
 include/irq.h | 138 
 include/tpm-v2.h  |  31 +
 test/dm/irq.c |  45 ++
 test/dm/test-fdt.c|  42 ++
 35 files changed, 1631 insertions(+), 93 deletions(-)
 create mode 100644 arch/x86/cpu/acpi_gpe.c
 create mode 100644 
doc/device-tree-bindings/interrupt-controller/intel,acpi-gpe.txt
 create mode 100644 doc/device-tree-bindings/interrupt-controller/interrupts.txt
 create mode 100644 drivers/clk/intel/Makefile
 create mode 100644 drivers/clk/intel/clk_intel.c
 create mode 100644 drivers/tpm/cr50_i2c.c
 create mode 100644 include/dt-bindings/clock/intel-clock.h

-- 
2.25.0.341.g760bfbb309-goog

[PATCH] test: aes: fix memleak

[Philippe Reynes]

In the first version, the result of malloc is checked
with ut_assertnonnull. But on a fail, this macro exit
the function, so previously malloc are not freed.

So to avoid a memleak, we don't use ut_assertnonnull,
but simply check the return of malloc. If one has failed,
we freed all the allocated memory and quit the function.

Reported-by: Coverity (CID: 284403)
Reported-by: Coverity (CID: 284404)
Reported-by: Coverity (CID: 284405)
Reported-by: Coverity (CID: 284406)
Reported-by: Coverity (CID: 284407)
Signed-off-by: Philippe Reynes 
---
 test/lib/test_aes.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/test/lib/test_aes.c b/test/lib/test_aes.c
index b7b4b77..fb8a0b1 100644
--- a/test/lib/test_aes.c
+++ b/test/lib/test_aes.c
@@ -88,17 +88,17 @@ static int _lib_test_aes_run(struct unit_test_state *uts, 
int key_len,
 
/* Allocate all the buffer */
key = malloc(key_len);
-   ut_assertnonnull(key);
key_exp = malloc(key_exp_len);
-   ut_assertnonnull(key_exp);
iv = malloc(AES_BLOCK_LENGTH);
-   ut_assertnonnull(iv);
nocipher = malloc(num_block * AES_BLOCK_LENGTH);
-   ut_assertnonnull(nocipher);
ciphered = malloc((num_block + 1) * AES_BLOCK_LENGTH);
-   ut_assertnonnull(ciphered);
uncipher = malloc((num_block + 1) * AES_BLOCK_LENGTH);
-   ut_assertnonnull(uncipher);
+
+   if (!key || !key_exp || !iv || !nocipher || !ciphered || !uncipher) {
+   printf("%s: can't allocate memory\n", __func__);
+   ret = -1;
+   goto out;
+   }
 
/* Initialize all buffer */
rand_buf(key, key_len);
@@ -127,6 +127,7 @@ static int _lib_test_aes_run(struct unit_test_state *uts, 
int key_len,
ret = -1;
};
 
+ out:
/* Free all the data */
free(key);
free(key_exp);
-- 
2.7.4

[PATCH] net: zynq: Free allocated buffers in case of error

[Michal Simek]

Driver probe function is called again and again in case of error.
Malloc space is getting full which is is reported by:
 Insufficient RAM for page table: 0x15000 > 0x14000.
 Please increase the size in get_page_table_size()
 ### ERROR ### Please RESET the board ###

The patch is freeing allocated buffers on error path to avoid panic.

Signed-off-by: Michal Simek 
---

 drivers/net/zynq_gem.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 879129653df3..745c65cf471c 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -659,8 +659,10 @@ static int zynq_gem_probe(struct udevice *dev)
 
/* Align bd_space to MMU_SECTION_SHIFT */
bd_space = memalign(1 << MMU_SECTION_SHIFT, BD_SPACE);
-   if (!bd_space)
-   return -ENOMEM;
+   if (!bd_space) {
+   ret = -ENOMEM;
+   goto err1;
+   }
 
mmu_set_region_dcache_behaviour((phys_addr_t)bd_space,
BD_SPACE, DCACHE_OFF);
@@ -672,7 +674,7 @@ static int zynq_gem_probe(struct udevice *dev)
ret = clk_get_by_name(dev, "tx_clk", >clk);
if (ret < 0) {
dev_err(dev, "failed to get clock\n");
-   return -EINVAL;
+   goto err1;
}
 
priv->bus = mdio_alloc();
@@ -682,9 +684,19 @@ static int zynq_gem_probe(struct udevice *dev)
 
ret = mdio_register_seq(priv->bus, dev->seq);
if (ret)
-   return ret;
+   goto err2;
 
-   return zynq_phy_init(dev);
+   ret = zynq_phy_init(dev);
+   if (ret)
+   goto err2;
+
+   return ret;
+
+err2:
+   free(priv->rxbuffers);
+err1:
+   free(priv->tx_bd);
+   return ret;
 }
 
 static int zynq_gem_remove(struct udevice *dev)
-- 
2.25.0

[PATCH] net: phy: dp83867: Clean force link good bit

[Michal Simek]

On Xilinx ZynqMP revA board initial value of PHYCR register is 0x5448 which
means FORCE_LINK_GOOD is already setup. Origin code was doing write but the
new code is doing read/modify/write and keep this bit untouched. That's why
ethernet stop to work.
The patch is cleaning this bit when PHYCR value is composed.

Tested on Xilinx zcu102-revA and zcu104-rev1.0 boards.

Fixes: 37d6265f2bfa ("net: phy: dp83867: refactor rgmii configuration")
Signed-off-by: Michal Simek 
---

 drivers/net/phy/dp83867.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index a43793cd4274..4d796e289c45 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -64,6 +64,7 @@
 #define DP83867_PHYCR_FIFO_DEPTH_SHIFT 14
 #define DP83867_PHYCR_FIFO_DEPTH_MASK  GENMASK(15, 14)
 #define DP83867_PHYCR_RESERVED_MASKBIT(11)
+#define DP83867_PHYCR_FORCE_LINK_GOOD  BIT(10)
 #define DP83867_MDI_CROSSOVER  5
 #define DP83867_MDI_CROSSOVER_MDIX 2
 #define DP83867_PHYCTRL_SGMIIEN0x0800
@@ -283,6 +284,9 @@ static int dp83867_config(struct phy_device *phydev)
val &= ~DP83867_PHYCR_FIFO_DEPTH_MASK;
val |= (dp83867->fifo_depth << DP83867_PHYCR_FIFO_DEPTH_SHIFT);
 
+   /* Do not force link good */
+   val &= ~DP83867_PHYCR_FORCE_LINK_GOOD;
+
/* The code below checks if "port mirroring" N/A MODE4 has been
 * enabled during power on bootstrap.
 *
-- 
2.25.0

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Simon Goldschmidt]

On Thu, Feb 6, 2020 at 3:41 PM Nico Becker  wrote:
>
> Am 06.02.2020 um 14:00 schrieb Marek Vasut:
> > On 2/6/20 1:57 PM, Nico Becker wrote:
> >> Am 06.02.2020 um 12:53 schrieb Marek Vasut:
> >>> On 2/6/20 11:50 AM, Nico Becker wrote:
>  Hello,
> >>>
> >>> Hi,
> >>>
>  after removing the function socfpga_sdram_apply_static_cfg() in
>  misc_gen5 we can not use the FPGA2SDRAM bridge.
> 
>  Without the apply static cfg the kernel crash every time,
>  if we try to write @ the fpga2sdram bridge. After an soft reset
>  everything is working.
> 
>  If we add the socfpga_sdram_apply_static_cfg() in the
>  u-boot source code, everything is fine.
>  Now we can use the fpga2sdram bridge after power on.
> 
>  Our setup:
>  - u-boot v2020.01
>  - load and write fpga firmware
>  - enable bridges
>  - boot linux
> 
>  I have found some information at
>  
> 
> 
>  
> >>>
> >>> Can you send a patch which fixes this for you, with Fixes: tag ?
> >>> Then it would be clear what you changed.
> >>>
> >>> Thanks
> >>>
> >>
> >> Hello,
> >> the code was removed @ commit c5f4b805.
> >
> > Did you read the commit message of that commit and what problem that was
> > solving ? Clearly, reverting the commit isn't the way to go. We need to
> > find a way to unbreak this for you, while not break other platforms.
> >
> >> I attached my patch, sorry for the format, i am new in this.
> >
> > [...]
> >
> Hi,
> yes i read the commit message.
>
> but i found no other option to enable the sdram bridges,
> without crashes/hanging up linux, with the removed source code.
>
> i ve found some more information @intel
> 
>
> Intel talk about an bridge_enable_handoff in my opionion
> the cmd set the sram aply cfg
>
> /* add signle command to enable all bridges based on handoff */
> setenv("bridge_enable_handoff",
> "mw $fpgaintf ${fpgaintf_handoff}; "
> "go $fpga2sdram_apply; "
> "mw $fpga2sdram ${fpga2sdram_handoff}; "
> "mw $axibridge ${axibridge_handoff}; "
> "mw $l3remap ${l3remap_handoff} ");
>
> setenv_addr("fpga2sdram_apply", (void *)sdram_applycfg_uboot);
>
> /*
>   * Relocate the sdram_applycfg_ocram function to OCRAM and call it
>   */
> ENTRY(sdram_applycfg_uboot)
> PUSH{r4-r11, lr}/* save registers per AAPCS */
>
> ldr r1, =sdram_applycfg_ocram
> ldr r2, =CONFIG_SYS_INIT_RAM_ADDR
> mov r3, r2
> ldmia   r1!, {r4 - r11}
> stmia   r3!, {r4 - r11}
> ldmia   r1!, {r4 - r11} /* copy more in case code added */
> stmia   r3!, {r4 - r11} /* in the future */
> ldmia   r1!, {r4 - r11} /* copy more in case code added */
> stmia   r3!, {r4 - r11} /* in the future */
> dsb
> isb
> blx r2  /* jump to OCRAM */
> POP {r4-r11, pc}
> ENDPROC(sdram_applycfg_uboot)
>
>
> it could be an option to write the fpga firmware with u-boot,
> and do a soft reset.
> boot u-boot
> check fpga configuration state
> not configured write firmware reset
> if configured boot linux
>
> i ll check howto to determine the fpga configuration state
> and try this.

That doesn't look like a safe plan: what if you explicitly *want* a reboot
and want to reconfigure the FPGA then to ensure it is in a well-known state?

Marek, what were the problems why this has been removed? Aside from "is
confirmed to lead to a rare system hang when enabling bridges", the commit
message stays rather vague. Maybe that "apply config" bit should only be written
if explicitly configured so, but that would mean we need some kind of config
options included/coming with the FPGA image we program.

Oh, and by now I'm glad our own design connects to DDR via the main bus ;-)

Regards,
Simon

[PATCH] tools: env: enable PIC for static library

[Martin Hundebøll]

External projects wanting to embed the static library needs it to be
position independent.

Signed-off-by: Martin Hundebøll 
---
 tools/env/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/env/Makefile b/tools/env/Makefile
index b627796e94..2444269de7 100644
--- a/tools/env/Makefile
+++ b/tools/env/Makefile
@@ -13,6 +13,7 @@ HOST_EXTRACFLAGS  = -I$(srctree)/tools \
$(patsubst -I%,-idirafter%, $(filter -I%, $(UBOOTINCLUDE))) \
-idirafter $(srctree)/tools/env \
-DUSE_HOSTCC \
+   -fPIC \
-DTEXT_BASE=$(TEXT_BASE)
 
 ifeq ($(MTD_VERSION),old)
-- 
2.25.0

[PATCH] tools: env: remove include of env.h

[Martin Hundebøll]

The header isn't used. Including it breaks compilation for external
users of the static library.

Signed-off-by: Martin Hundebøll 
---
 tools/env/fw_env.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/env/fw_env.h b/tools/env/fw_env.h
index b60fbfc8f8..78c803c944 100644
--- a/tools/env/fw_env.h
+++ b/tools/env/fw_env.h
@@ -4,7 +4,6 @@
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  */
 
-#include 
 #include 
 
 /*
-- 
2.25.0

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Nico Becker]

Am 06.02.2020 um 14:00 schrieb Marek Vasut:

On 2/6/20 1:57 PM, Nico Becker wrote:

Am 06.02.2020 um 12:53 schrieb Marek Vasut:

On 2/6/20 11:50 AM, Nico Becker wrote:

Hello,


Hi,


after removing the function socfpga_sdram_apply_static_cfg() in
misc_gen5 we can not use the FPGA2SDRAM bridge.

Without the apply static cfg the kernel crash every time,
if we try to write @ the fpga2sdram bridge. After an soft reset
everything is working.

If we add the socfpga_sdram_apply_static_cfg() in the
u-boot source code, everything is fine.
Now we can use the fpga2sdram bridge after power on.

Our setup:
- u-boot v2020.01
    - load and write fpga firmware
    - enable bridges
- boot linux

I have found some information at






Can you send a patch which fixes this for you, with Fixes: tag ?
Then it would be clear what you changed.

Thanks



Hello,
the code was removed @ commit c5f4b805.


Did you read the commit message of that commit and what problem that was
solving ? Clearly, reverting the commit isn't the way to go. We need to
find a way to unbreak this for you, while not break other platforms.


I attached my patch, sorry for the format, i am new in this.


[...]


Hi,
yes i read the commit message.

but i found no other option to enable the sdram bridges,
without crashes/hanging up linux, with the removed source code.

i ve found some more information @intel


Intel talk about an bridge_enable_handoff in my opionion
the cmd set the sram aply cfg

/* add signle command to enable all bridges based on handoff */
setenv("bridge_enable_handoff",
"mw $fpgaintf ${fpgaintf_handoff}; "
"go $fpga2sdram_apply; "
"mw $fpga2sdram ${fpga2sdram_handoff}; "
"mw $axibridge ${axibridge_handoff}; "
"mw $l3remap ${l3remap_handoff} ");

setenv_addr("fpga2sdram_apply", (void *)sdram_applycfg_uboot);

/*
 * Relocate the sdram_applycfg_ocram function to OCRAM and call it
 */
ENTRY(sdram_applycfg_uboot)
PUSH{r4-r11, lr}/* save registers per AAPCS */

ldr r1, =sdram_applycfg_ocram
ldr r2, =CONFIG_SYS_INIT_RAM_ADDR
mov r3, r2
ldmia   r1!, {r4 - r11}
stmia   r3!, {r4 - r11}
ldmia   r1!, {r4 - r11} /* copy more in case code added */
stmia   r3!, {r4 - r11} /* in the future */
ldmia   r1!, {r4 - r11} /* copy more in case code added */
stmia   r3!, {r4 - r11} /* in the future */
dsb
isb
blx r2  /* jump to OCRAM */
POP {r4-r11, pc}
ENDPROC(sdram_applycfg_uboot)


it could be an option to write the fpga firmware with u-boot,
and do a soft reset.
boot u-boot
check fpga configuration state
not configured write firmware reset
if configured boot linux

i ll check howto to determine the fpga configuration state
and try this.


Thanks

--
Nico Becker
ic-automation GmbH
Alexander-Diehl-Straße 2a
D-55130 Mainz

Tel:+49-(0)6131-62718-24
Fax:+49-(0)6131-62718-10
email:  n.bec...@ic-automation.de
Web:http://www.ic-automation.de

Geschäftsführer: Dr. Stefan Becker
HRB 7283, Amtsgericht Mainz

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Marek Vasut]

On 2/6/20 1:57 PM, Nico Becker wrote:
> Am 06.02.2020 um 12:53 schrieb Marek Vasut:
>> On 2/6/20 11:50 AM, Nico Becker wrote:
>>> Hello,
>>
>> Hi,
>>
>>> after removing the function socfpga_sdram_apply_static_cfg() in
>>> misc_gen5 we can not use the FPGA2SDRAM bridge.
>>>
>>> Without the apply static cfg the kernel crash every time,
>>> if we try to write @ the fpga2sdram bridge. After an soft reset
>>> everything is working.
>>>
>>> If we add the socfpga_sdram_apply_static_cfg() in the
>>> u-boot source code, everything is fine.
>>> Now we can use the fpga2sdram bridge after power on.
>>>
>>> Our setup:
>>> - u-boot v2020.01
>>>    - load and write fpga firmware
>>>    - enable bridges
>>> - boot linux
>>>
>>> I have found some information at
>>> 
>>>
>>>
>>> 
>>
>> Can you send a patch which fixes this for you, with Fixes: tag ?
>> Then it would be clear what you changed.
>>
>> Thanks
>>
> 
> Hello,
> the code was removed @ commit c5f4b805.

Did you read the commit message of that commit and what problem that was
solving ? Clearly, reverting the commit isn't the way to go. We need to
find a way to unbreak this for you, while not break other platforms.

> I attached my patch, sorry for the format, i am new in this.

[...]

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Nico Becker]

Am 06.02.2020 um 12:53 schrieb Marek Vasut:

On 2/6/20 11:50 AM, Nico Becker wrote:

Hello,


Hi,


after removing the function socfpga_sdram_apply_static_cfg() in
misc_gen5 we can not use the FPGA2SDRAM bridge.

Without the apply static cfg the kernel crash every time,
if we try to write @ the fpga2sdram bridge. After an soft reset
everything is working.

If we add the socfpga_sdram_apply_static_cfg() in the
u-boot source code, everything is fine.
Now we can use the fpga2sdram bridge after power on.

Our setup:
- u-boot v2020.01
   - load and write fpga firmware
   - enable bridges
- boot linux

I have found some information at





Can you send a patch which fixes this for you, with Fixes: tag ?
Then it would be clear what you changed.

Thanks



Hello,
the code was removed @ commit c5f4b805.

I attached my patch, sorry for the format, i am new in this.

Thanks a lot

---
 arch/arm/mach-socfpga/misc_gen5.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
b/arch/arm/mach-socfpga/misc_gen5.c

index 22042d0de0..19c6d24170 100644
--- a/arch/arm/mach-socfpga/misc_gen5.c
+++ b/arch/arm/mach-socfpga/misc_gen5.c
@@ -213,6 +213,35 @@ static struct socfpga_reset_manager 
*reset_manager_base =

 static struct socfpga_sdr_ctrl *sdr_ctrl =
(struct socfpga_sdr_ctrl *)SDR_CTRLGRP_ADDRESS;

+static void socfpga_sdram_apply_static_cfg(void)
+{
+   const u32 applymask = 0x8;
+   u32 val = readl(_ctrl->static_cfg) | applymask;
+
+   /*
+* SDRAM staticcfg register specific:
+* When applying the register setting, the CPU must not access
+* SDRAM. Luckily for us, we can abuse i-cache here to help us
+* circumvent the SDRAM access issue. The idea is to make sure
+* that the code is in one full i-cache line by branching past
+* it and back. Once it is in the i-cache, we execute the core
+* of the code and apply the register settings.
+*
+* The code below uses 7 instructions, while the Cortex-A9 has
+* 32-byte cachelines, thus the limit is 8 instructions total.
+*/
+   asm volatile(
+   ".align5   \n"
+   "  b   2f  \n"
+   "1:str %0, [%1]\n"
+   "  dsb \n"
+   "  isb \n"
+   "  b   3f  \n"
+   "2:b   1b  \n"
+   "3:nop \n"
+   : : "r"(val), "r"(_ctrl->static_cfg) : "memory", "cc");
+}
+
 void do_bridge_reset(int enable, unsigned int mask)
 {
int i;
@@ -227,6 +256,7 @@ void do_bridge_reset(int enable, unsigned int mask)
}

writel(iswgrp_handoff[2], _regs->fpgaintfgrp_module);
+   socfpga_sdram_apply_static_cfg();
writel(iswgrp_handoff[3], _ctrl->fpgaport_rst);
writel(iswgrp_handoff[0], _manager_base->brg_mod_reset);
writel(iswgrp_handoff[1], _regs->remap);
@@ -236,6 +266,7 @@ void do_bridge_reset(int enable, unsigned int mask)
} else {
writel(0, _regs->fpgaintfgrp_module);
writel(0, _ctrl->fpgaport_rst);
+   socfpga_sdram_apply_static_cfg();
writel(0x7, _manager_base->brg_mod_reset);
writel(1, _regs->remap);
}
--
2.20.1

Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Marek Vasut]

On 2/6/20 11:50 AM, Nico Becker wrote:
> Hello,

Hi,

> after removing the function socfpga_sdram_apply_static_cfg() in
> misc_gen5 we can not use the FPGA2SDRAM bridge.
> 
> Without the apply static cfg the kernel crash every time,
> if we try to write @ the fpga2sdram bridge. After an soft reset
> everything is working.
> 
> If we add the socfpga_sdram_apply_static_cfg() in the
> u-boot source code, everything is fine.
> Now we can use the fpga2sdram bridge after power on.
> 
> Our setup:
> - u-boot v2020.01
>   - load and write fpga firmware
>   - enable bridges
> - boot linux
> 
> I have found some information at
> 
> 
> 

Can you send a patch which fixes this for you, with Fixes: tag ?
Then it would be clear what you changed.

Thanks

Re: [PATCH 1/2] board: solidrun lx2160a-cex7: new board

[Baruch Siach]

Hi Priyanka,

On Thu, Jan 23, 2020 at 11:42:56AM +0200, Baruch Siach wrote:
> On Thu, Jan 23, 2020 at 09:25:29AM +, Priyanka Jain wrote:
> > >-Original Message-
> > >From: Baruch Siach 
> > >Sent: Wednesday, December 4, 2019 6:59 PM
> > >To: Priyanka Jain 
> > >Cc: u-boot@lists.denx.de; Rabeeh Khoury ; Jon
> > >Nettleton ; Baruch Siach 
> > >Subject: [PATCH 1/2] board: solidrun lx2160a-cex7: new board
> > >
> > >Add board level support code for the SolidRun LX2160A based COM-Express
> > >7 system.
> > >
> > >Signed-off-by: Baruch Siach 
> > >---
> > This patch has  below compilation warning. Kindly fix.
> >aarch64:  +   lx2160acex7_tfa
> > +board/solidrun/lx2160acex7/lx2160acex7.c: In function 'uart_get_clock':
> > +board/solidrun/lx2160acex7/lx2160acex7.c:50:18: error: implicit 
> > declaration of function 'get_serial_clock'; did you mean 'uart_get_clock'? 
> > [-Werror=implicit-function-declaration]
> > +  serial0.clock = get_serial_clock();
> > +  ^~~~
> > +  uart_get_clock
> > +cc1: all warnings being treated as errors
> > +make[2]: *** [board/solidrun/lx2160acex7/lx2160acex7.o] Error 1
> > +make[1]: *** [board/solidrun/lx2160acex7] Error 2
> > +make: *** [sub-make] Error 2
> 
> Thanks for your review.
> 
> This build error is because of commit d96c26040e901 ("common: Move clock 
> functions into a new file"). clock_legacy.h include in now missing. I'll 
> rebase the patches on current master and post an update.

It turns out that adding clock_legacy.h is not enough. The board does not boot 
current U-Boot master with nothing shown on the console. Do you have any idea 
what LX2160A related code change might have caused that?

Thanks,
baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [yocto] Support UBI u-boot

[Gabriele Zampieri]

Hi,

On Thu, Feb 6, 2020 at 11:07 AM JH  wrote:

> Thanks Gabriele and Andy,
>
> On 2/6/20, Gabriele Zampieri  wrote:
> > Hi JH,
> >
> > have you tried what we suggested you in your last thread? More
> specifically
> > adding your defconfig and tweaking it through menuconfig. and then
> specify
> > the UBOOT_MACHINE.
>
> Yes, as I posted in another thread, the MTD, UBI are all set in my
> Linux kernel defconfig, I have also added UBOOT_CONFIG = "nand" in my
> layer machine config.
>
What I missed is u-boot overlay, as you and Andy alluded. I added
> UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_nand_config", but strange
> enough, that mx6ull_14x14_evk_nand_config, did not set CONFIG_CMD_UBI
> in its config.
>

Sorry, I never tried that approach.

>
> I think I need to add an appended recipes-bsp to my layer just like I
> added the recipes-kernel to my layer to overwrite kernel defconfig, I
> need to overwrite u-boot defconfig.
>
> In kernel, to overwrite defconfig, I run bitbake -c menuconfig
> virtual/kernel, how can I generate u-boot defconfig, to run bitbake -c
> menuconfig u-boot?
>

As far as I know uboot (usually virtual/bootloader) does not have a task to
run menuconfig directly from bitbake.
I usually have a local clone of uboot and I simply run `make [...]
menuconfig|savedefconfig` , then I create a patch
to add my defconfig (custom_defconfig) to configs/ and specify
UBOOT_MACHINE = "custom_defconfig"

Thank you.
>
> Kind regards,
>
> - jh
>

Gabriele

Support UBI u-boot

[JH]

Hi,

Sorry for cross-posting, I have been asking for helping solving the
issue many days ago, but could not get those work.

(1) UBI support

I added NAND and UBIFS support to my Yocto layer machine config file:

UBOOT_CONFIG = "nand"
UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_config"
UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_nand_config"
UBOOT_CONFIG[nand] += "ubi"
UBOOT_CONFIG[nand] += "ubifs"

But my u-boot.imx-nand still could not support ubi:

=> ubi part rootfs
Unknown command 'ubi' - try 'help'

What I could be missing here?


(2) Patch u-boot parameters

I am not clear how you do to change u-boot parameters, it seems to me
I have to create my own u-boot-imx_2017.03.bbappend and patch files to
 mx6ullevk.h, to change u-boot parameters of mtdparts, NAND_ROOT_UBI,
bootcmd, etc based on my configuration.

But Yocto won't allow the patch running unless that the patch is
committed to the git repository in
https://source.codeaurora.org/external/imx/uboot-imx.git.

Ideally, I thought all u-boot parameters can be changed in a bbappend
file, could you advise if it is possible to do that way or not? If so,
how to do it?

If not, what is the policy for making parches and commit to the git
repository https://source.codeaurora.org/external/imx/uboot-imx.git?

Thank you.

Kind regards,

- jh

[U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()

[Nico Becker]

Hello,
after removing the function socfpga_sdram_apply_static_cfg() in 
misc_gen5 we can not use the FPGA2SDRAM bridge.


Without the apply static cfg the kernel crash every time,
if we try to write @ the fpga2sdram bridge. After an soft reset
everything is working.

If we add the socfpga_sdram_apply_static_cfg() in the
u-boot source code, everything is fine.
Now we can use the fpga2sdram bridge after power on.

Our setup:
- u-boot v2020.01
  - load and write fpga firmware
  - enable bridges
- boot linux

I have found some information at





--
Best regards
Nico Becker

Re: [yocto] Support UBI u-boot

[JH]

On 2/6/20, JH  wrote:
> I think I need to add an appended recipes-bsp to my layer just like I
> added the recipes-kernel to my layer to overwrite kernel defconfig, I
> need to overwrite u-boot defconfig.
>
> In kernel, to overwrite defconfig, I run bitbake -c menuconfig
> virtual/kernel, how can I generate u-boot defconfig, to run bitbake -c
> menuconfig u-boot?

Hmm, more complicated than I thought, it does not have defconfig in
u-boot like kernel does, how do you overwrite u-boot config in Yocto?

Re: [yocto] Support UBI u-boot

[JH]

Thanks Gabriele and Andy,

On 2/6/20, Gabriele Zampieri  wrote:
> Hi JH,
>
> have you tried what we suggested you in your last thread? More specifically
> adding your defconfig and tweaking it through menuconfig. and then specify
> the UBOOT_MACHINE.

Yes, as I posted in another thread, the MTD, UBI are all set in my
Linux kernel defconfig, I have also added UBOOT_CONFIG = "nand" in my
layer machine config.

What I missed is u-boot overlay, as you and Andy alluded. I added
UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_nand_config", but strange
enough, that mx6ull_14x14_evk_nand_config, did not set CONFIG_CMD_UBI
in its config.

I think I need to add an appended recipes-bsp to my layer just like I
added the recipes-kernel to my layer to overwrite kernel defconfig, I
need to overwrite u-boot defconfig.

In kernel, to overwrite defconfig, I run bitbake -c menuconfig
virtual/kernel, how can I generate u-boot defconfig, to run bitbake -c
menuconfig u-boot?

Thank you.

Kind regards,

- jh

Re: [yocto] Support UBI u-boot

[Gabriele Zampieri]

Hi JH,

have you tried what we suggested you in your last thread? More specifically
adding your defconfig and tweaking it through menuconfig. and then specify
the UBOOT_MACHINE.

However you should be able to create and apply patches for external repo
without any problem and the needs to push your changes to public repos
(unless them are useful for others).

BR
Gabriele

On Thu, Feb 6, 2020 at 7:35 AM JH  wrote:

> Hi,
>
> Sorry for cross-posting, I have been asking for helping solving the
> issue many days ago, but could not get those work.
>
> (1) UBI support
>
> I added NAND and UBIFS support to my Yocto layer machine config file:
>
> UBOOT_CONFIG = "nand"
> UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_config"
> UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_nand_config"
> UBOOT_CONFIG[nand] += "ubi"
> UBOOT_CONFIG[nand] += "ubifs"
>
> But my u-boot.imx-nand still could not support ubi:
>
> => ubi part rootfs
> Unknown command 'ubi' - try 'help'
>
> What I could be missing here?
>
>
> (2) Patch u-boot parameters
>
> I am not clear how you do to change u-boot parameters, it seems to me
> I have to create my own u-boot-imx_2017.03.bbappend and patch files to
>  mx6ullevk.h, to change u-boot parameters of mtdparts, NAND_ROOT_UBI,
> bootcmd, etc based on my configuration.
>
> But Yocto won't allow the patch running unless that the patch is
> committed to the git repository in
> https://source.codeaurora.org/external/imx/uboot-imx.git.
>
> Ideally, I thought all u-boot parameters can be changed in a bbappend
> file, could you advise if it is possible to do that way or not? If so,
> how to do it?
>
> If not, what is the policy for making parches and commit to the git
> repository https://source.codeaurora.org/external/imx/uboot-imx.git?
>
> Thank you.
>
> Kind regards,
>
> - jh
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#48284):
> https://lists.yoctoproject.org/g/yocto/message/48284
> Mute This Topic: https://lists.yoctoproject.org/mt/71016973/3618237
> Group Owner: yocto+ow...@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [
> gabbla.mal...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

uEnv.txt not read on eMMC Beaglebone black

[Benjamin Freeman]

Hi,

I have made a distribution for Beaglebone black using Buildroot 
2019.11.1. Everything works fine when all the files are flashed on a SD 
card.


I have now flashed the eMMC with the same files. Unfortunately it 
doesn't boot properly anymore. U-boot doesn't read the uEnv.txt anymore.


Here is the output I am getting:

switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
58308 bytes read in 9 ms (6.2 MiB/s)
switch to partitions #0, OK
mmc1(part 0) is current device
SD/MMC found on device 1
## Error: "bootcmd_nand0" not defined
starting USB...

I have tested with version 2019.10 and 2019.07 using am335x_evm defconfig.

Does anyone have an idea on why uEnv.txt on the eMMC is not read?

Thank you,

Benjamin Freeman

qnap nas uboot emmc flash

[tonyp]

I have borked my TS-228 QNAP nas from booting by messing with some files on
the emmc while it was mounted rw. 

Support is non-existent for this nas, so I'm attempting to recover it myself
but am a little lost.

I've got a serial hooked up and have tried loading the firmware from a usb
stick but am getting a "Error: unrecognized/unsupported machine ID (r1 =
0x138a)." when attempting to boot the kernel.

My steps so far - download and unzip the firmware. There are 3 folders -
META-INF, NASROOT (contains a few tar files) and system, as well as 9 files
- android.emmc.dtb, android.root.emmc.cpio.gz_pad.img, bluecore.audio,
config.txt, emmc.uImage, file_contexts, rescue.emmc.dtb,
rescue.root.emmc.cpio.gz_pad.img, rsa_key_2048.pem.

The file config.txt contains the following - 

# Package Configuration
secure_boot=0
fw = rescueDT rescue.emmc.dtb 0x01ff2000
fw = kernelDT android.emmc.dtb 0x01ff2000
fw = rescueRootFS rescue.root.emmc.cpio.gz_pad.img 0x0220
fw = kernelRootFS android.root.emmc.cpio.gz_pad.img 0x0220
fw = linuxKernel emmc.uImage 0x0300
fw = audioKernel bluecore.audio 0x01b0

So I tried running - 

usb start; usb dev 0

secure_boot=0; console=ttyS0,115200; fatload usb 0:1 0x01ff2000
rescue.emmc.dtb; fatload usb 0:1 0x0300 emmc.uImage; bootm 0x0300

and get the "Error: unrecognized/unsupported machine ID (r1 = 0x138a)."
when running it.

I also tried adding "fatload usb 0:1 0x0220
rescue.root.emmc.cpio.gz_pad.img" to the command with the same result.

(It's a very old Uboot on this box by the way - U-Boot 2012.07 (Jan 27 2016
- 17:16:49)).

The env is - 

Realtek> env print
baudrate=115200
bootargs=console=ttyS0,115200 earlyprintk loglevel=4
bootcmd=bootr
bootdelay=0
ethact=r8168#0
ethaddr=00:10:20:30:40:50
fdt_loadaddr=0x01FF2000
gatewayip=192.168.100.254
ipaddr=192.168.1.20
kernel_loadaddr=0x0300
mtd_part=mtdparts=rtk_nand:
netmask=255.255.255.0
rescue_audio=bluecore.audio
rescue_dtb=rescue.emmc.dtb
rescue_rootfs=rescue.root.emmc.cpio.gz_pad.img
rescue_vmlinux=emmc.uImage
rootfs_loadaddr=0x0220
serverip=192.168.1.9

I did take a copy of the emmc before I played with it, and have the file,
mmcblk0 (3.64 GB) on my desktop.

Can anyone advise the best way to proceed? Keep trying to boot a kernel in
order to manually restore the mounted emmc partition, or just flash the
mmcblk0 file onto the emmc? 

I didn't want to flash it without advice because I'm very new to this sort
of thing and didn't want to flash the wrong offset and flash over uboot.
Then the device would be done for.

Thank you for any assistance anyone can offer me.

Regards, 

Tony P



--
Sent from: http://u-boot.10912.n7.nabble.com/

[PATCH 1/2] configs: am43xx_evm_usbhost: Add configs for USB Host boot mode

[Faiz Abbas]

Enable configs to fix USB Host boot mode.

Signed-off-by: Faiz Abbas 
---
 configs/am43xx_evm_usbhost_boot_defconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index 4eed4f58b0..75bf84301f 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -17,6 +17,7 @@ CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_USB_HOST_SUPPORT=y
+CONFIG_SPL_USB_STORAGE=y
 CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_ETHER=y
 CONFIG_CMD_SPL=y
@@ -44,9 +45,14 @@ CONFIG_ENV_IS_IN_FAT=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
+CONFIG_MISC=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_MTD=y
@@ -56,6 +62,9 @@ CONFIG_SPI_FLASH_MACRONIX=y
 CONFIG_PHY_GIGE=y
 CONFIG_MII=y
 CONFIG_DRIVER_TI_CPSW=y
+CONFIG_PHY=y
+CONFIG_SPL_PHY=y
+CONFIG_OMAP_USB2_PHY=y
 CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_TI_QSPI=y
@@ -67,6 +76,7 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_OMAP=y
+CONFIG_USB_DWC3_GENERIC=y
 CONFIG_USB_DWC3_PHY_OMAP=y
 CONFIG_OMAP_USB_PHY=y
 CONFIG_USB_GADGET=y
-- 
2.19.2

[PATCH 0/2] Fix usb host boot mode in AM437x-gp-evm

[Faiz Abbas]

The following patches fix usb host boot mode in am437x-gp-evm.

Faiz Abbas (2):
  configs: am43xx_evm_usbhost: Add configs for USB Host boot mode
  configs: am43xx_evm_usbhost_boot: Add device for environment

 configs/am43xx_evm_usbhost_boot_defconfig | 12 
 1 file changed, 12 insertions(+)

-- 
2.19.2

[PATCH 2/2] configs: am43xx_evm_usbhost_boot: Add device for environment

[Faiz Abbas]

Add mmc device partition 0 as the seat of the environment.

Signed-off-by: Faiz Abbas 
---
 configs/am43xx_evm_usbhost_boot_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index 75bf84301f..21de5229c1 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -42,6 +42,8 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm"
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
 CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_INTERFACE="mmc"
+CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
-- 
2.19.2

[PATCH] mips: vcoreiii: Fix cache coherency issues

[Lars Povlsen]

This patch fixes an stability issue seen on some vcoreiii targets,
which was root caused to a cache inconsistency situation.

The inconsistency was caused by having kuseg pointing to NOR area but
used as a stack/gd/heap area during initialization, while only
relatively late remapping the RAM area into kuseg position.

The fix is to initialize the DDR right after the TLB setup, and then
remapping it into position before gd/stack/heap usage.

Reported-by: Ramin Seyed-Moussavi 
Reviewed-by: Alexandre Belloni 
Reviewed-by: Horatiu Vultur 
Signed-off-by: Lars Povlsen 
---
 arch/mips/mach-mscc/cpu.c  |  9 +
 arch/mips/mach-mscc/dram.c | 14 +-
 arch/mips/mach-mscc/include/mach/ddr.h |  4 
 arch/mips/mach-mscc/lowlevel_init.S| 17 -
 4 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/arch/mips/mach-mscc/cpu.c b/arch/mips/mach-mscc/cpu.c
index ac75d51da5..3ee589891b 100644
--- a/arch/mips/mach-mscc/cpu.c
+++ b/arch/mips/mach-mscc/cpu.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -53,7 +54,6 @@ void vcoreiii_tlb_init(void)
   MMU_REGIO_RW);
 #endif
 
-#if  CONFIG_SYS_TEXT_BASE == MSCC_FLASH_TO
/*
 * If U-Boot is located in NOR then we want to be able to use
 * the data cache in order to boot in a decent duration
@@ -71,9 +71,10 @@ void vcoreiii_tlb_init(void)
create_tlb(tlbix++, MSCC_DDR_TO, MSCC_RAM_TLB_SIZE, MMU_REGIO_RW,
   MSCC_ATTRIB2);
 
-   /* Enable caches by clearing the bit ERL, which is set on reset */
-   write_c0_status(read_c0_status() & ~BIT(2));
-#endif /* CONFIG_SYS_TEXT_BASE */
+   /* Enable mapping (using TLB) kuseg by clearing the bit ERL,
+* which is set on reset.
+*/
+   write_c0_status(read_c0_status() & ~ST0_ERL);
 }
 
 int mach_cpu_init(void)
diff --git a/arch/mips/mach-mscc/dram.c b/arch/mips/mach-mscc/dram.c
index c43f7a585b..72c70c9e84 100644
--- a/arch/mips/mach-mscc/dram.c
+++ b/arch/mips/mach-mscc/dram.c
@@ -31,7 +31,7 @@ static inline int vcoreiii_train_bytelane(void)
 
 int vcoreiii_ddr_init(void)
 {
-   int res;
+   register int res;
 
if (!(readl(BASE_CFG + ICPU_MEMCTRL_STAT)
  & ICPU_MEMCTRL_STAT_INIT_DONE)) {
@@ -40,20 +40,19 @@ int vcoreiii_ddr_init(void)
if (hal_vcoreiii_init_dqs() || vcoreiii_train_bytelane())
hal_vcoreiii_ddr_failed();
}
-#if (CONFIG_SYS_TEXT_BASE != 0x2000)
+
res = dram_check();
if (res == 0)
hal_vcoreiii_ddr_verified();
else
hal_vcoreiii_ddr_failed();
 
-   /* Clear boot-mode and read-back to activate/verify */
+   /*  Remap DDR to kuseg: Clear boot-mode */
clrbits_le32(BASE_CFG + ICPU_GENERAL_CTRL,
 ICPU_GENERAL_CTRL_BOOT_MODE_ENA);
+   /* - and read-back to activate/verify */
readl(BASE_CFG + ICPU_GENERAL_CTRL);
-#else
-   res = 0;
-#endif
+
return res;
 }
 
@@ -66,9 +65,6 @@ int print_cpuinfo(void)
 
 int dram_init(void)
 {
-   while (vcoreiii_ddr_init())
-   ;
-
gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
return 0;
 }
diff --git a/arch/mips/mach-mscc/include/mach/ddr.h 
b/arch/mips/mach-mscc/include/mach/ddr.h
index d1f4287f65..bf75e52ec3 100644
--- a/arch/mips/mach-mscc/include/mach/ddr.h
+++ b/arch/mips/mach-mscc/include/mach/ddr.h
@@ -435,16 +435,12 @@ static inline void hal_vcoreiii_ddr_failed(void)
reset = KSEG0ADDR(_machine_restart);
icache_lock((void *)reset, 128);
asm volatile ("jr %0"::"r" (reset));
-
-   panic("DDR init failed\n");
 }
 #else  /* JR2 || ServalT */
 static inline void hal_vcoreiii_ddr_failed(void)
 {
writel(0, BASE_CFG + ICPU_RESET);
writel(PERF_SOFT_RST_SOFT_CHIP_RST, BASE_CFG + PERF_SOFT_RST);
-
-   panic("DDR init failed\n");
 }
 #endif
 
diff --git a/arch/mips/mach-mscc/lowlevel_init.S 
b/arch/mips/mach-mscc/lowlevel_init.S
index dfbe06766c..91f29ae252 100644
--- a/arch/mips/mach-mscc/lowlevel_init.S
+++ b/arch/mips/mach-mscc/lowlevel_init.S
@@ -8,6 +8,7 @@
 
 .set noreorder
 .extern vcoreiii_tlb_init
+.extern vcoreiii_ddr_init
 #ifdef CONFIG_SOC_LUTON
 .extern pll_init
 #endif
@@ -17,14 +18,28 @@ LEAF(lowlevel_init)
 * As we have no stack yet, we can assume the restricted
 * luxury of the sX-registers without saving them
 */
-   moves0,ra
+
+   /* Modify ra/s0 such we return to physical NOR location */
+   li  t0, 0x0fff
+   li  t1, CONFIG_SYS_TEXT_BASE
+   and s0, ra, t0
+   add s0, s0, t1
 
jal vcoreiii_tlb_init
 nop
+
 #ifdef CONFIG_SOC_LUTON
jal pll_init
 nop
 #endif
+
+   /* Initialize DDR controller to enable stack/gd/heap */
+0:
+   jal vcoreiii_ddr_init
+nop
+

[PATCH] mips: vcoreiii: Ajust CONFIG_SYS_MEMTEST_END

[Lars Povlsen]

This patch ajust CONFIG_SYS_MEMTEST_END for vcoreiii-based systems to
avoid overwriting the relocated u-boot. The former setting was too
agressive with networking etc. enabled on some platforms.

Reviewed-by: Alexandre Belloni 
Reviewed-by: Horatiu Vultur 
Signed-off-by: Lars Povlsen 
---
 include/configs/vcoreiii.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/configs/vcoreiii.h b/include/configs/vcoreiii.h
index e69456ef7c..6a2f80c2fb 100644
--- a/include/configs/vcoreiii.h
+++ b/include/configs/vcoreiii.h
@@ -39,7 +39,8 @@
 #define CONFIG_CONS_INDEX  1
 
 #define CONFIG_SYS_MEMTEST_START   CONFIG_SYS_SDRAM_BASE
-#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + 
CONFIG_SYS_SDRAM_SIZE - SZ_1M)
+#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + \
+CONFIG_SYS_SDRAM_SIZE - SZ_4M)
 
 #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE
 
-- 
2.23.0

Re: Support UBI u-boot

[Andy Pont]

JH wrote...



I added NAND and UBIFS support to my Yocto layer machine config file:

UBOOT_CONFIG = "nand"
UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_config"
UBOOT_CONFIG[nand] += "mx6ull_14x14_evk_nand_config"
UBOOT_CONFIG[nand] += "ubi"
UBOOT_CONFIG[nand] += "ubifs"

But my u-boot.imx-nand still could not support ubi:

=> ubi part rootfs
Unknown command 'ubi' - try ‘help’
You need to start to read through the various sources to figure out for 
yourself what is going on!


Starting from the bottom, in U-Boot 2017.03 all of the command sources 
are in the “cmd” directory. The “ubi …” command are all in ubi.c.  
Reading cmd/Makefile shows that file gets added into the build if 
CONFIG_CMD_UBI is enabled.


The next place to look is whether or not that is set in your defconfig 
for U-Boot or overwritten somewhere in a recipe in your Yocto build 
environment.


-Andy.

Re: [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R

[Marek Vasut]

On 2/6/20 9:59 AM, Patrick DELAUNAY wrote:
> Hi Marek,

Hello Patrick

[...]

>> My problem is with the bootloader-Linux clock tree dependency. That 
>> dependency
>> should not exist or be minimized, otherwise you end up with a very poor 
>> long-term
>> experience, see above. And if you want for this platform to be successful in 
>> the
>> industrial/automotive deployments, then you want to make sure the long-term
>> experience is a good one.
> 
> With STM32MP15x SOC and RCC, very few clocks need to be fixed by bootloaders
> (in fact more or less the root clocks of the system = frequency of PLL1 to 
> PLL4, 
> common for many device or protected  by security feature), I think it is the 
> case for
> any platform.
> 
> All the other clocks have a initial value / source provided by bootloaders 
> but they can 
> also be modified at runtime (by device tree assigned-clock-parents for not 
> secure clocks
> and with SMC call to TF-A secure monitor for "secure" clock).
> 
> For ST boards, we are trying to don't modify the initial clock tree-source 
> only to prove
> that this clock tree is functional / correct for most of case.
> 
> But for client and after first deployment, clock tree modification must be 
> done in Linux kernel
> without any Bootloader update (and avoid all known issue for OTA).
> 
> I shared your concerns with my team and we are completely agree with you.

So, shall we expect a proper fix for the Linux kernel too ?

[...]

[PATCH v3 2/2] pxe: Get default selection from board type if label matches

[Schrempf Frieder]

From: Frieder Schrempf 

In order to auto-select an option from the pxe boot menu, that
matches the detected board, we check the board model string in the
devicetree and set the default menu selection, if it matches the
label of the menu entry and there is no default selection already
set.

This is useful in combination with SPL that loads a FIT image with
U-Boot and multiple DTBs. SPL can detect the board and choose the
matching configuration in the FIT by using
board_fit_config_name_match().

Signed-off-by: Frieder Schrempf 
---
Changes in v3:
* Get rid of #ifdef by using IS_ENABLED() in else branch.

Changes in v2:
* Don't use internal structs of menu, but instead call
  menu_set_default_by_item_data_match() that does the iteration work.
---
 cmd/pxe_utils.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c
index 53af04d7dc..253df468af 100644
--- a/cmd/pxe_utils.c
+++ b/cmd/pxe_utils.c
@@ -1220,6 +1220,46 @@ struct pxe_menu *parse_pxefile(cmd_tbl_t *cmdtp, 
unsigned long menucfg)
return cfg;
 }
 
+#ifdef CONFIG_OF_CONTROL
+int pxe_match_menu_label_with_str(void *data, void *str)
+{
+   struct pxe_label *label;
+
+   if (!data || !str)
+   return 0;
+
+   label = (struct pxe_label *)data;
+
+   if (strcmp(label->name, str) == 0)
+   return 1;
+
+   return 0;
+}
+
+int pxe_runtime_select_menu_default(struct menu *m)
+{
+   DECLARE_GLOBAL_DATA_PTR;
+   const char *model;
+   char *key;
+   int ret;
+
+   model = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
+
+   if (!model)
+   return 0;
+
+   ret = menu_set_default_by_item_data_match(m,
+   pxe_match_menu_label_with_str, (void *)model, );
+   if (ret)
+   return ret;
+
+   printf("Menu entry %s fits detected board. " \
+  "Use as default selection...\n", key);
+
+   return 0;
+}
+#endif
+
 /*
  * Converts a pxe_menu struct into a menu struct for use with U-Boot's generic
  * menu code.
@@ -1258,6 +1298,8 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu *cfg)
/*
 * After we've created items for each label in the menu, set the
 * menu's default label if one was specified.
+* If OF_CONTROL is enabled and we don't have a default specified,
+* we try to use an entry that matches the board/model name as default.
 */
if (default_num) {
err = menu_default_set(m, default_num);
@@ -1269,6 +1311,10 @@ static struct menu *pxe_menu_to_menu(struct pxe_menu 
*cfg)
 
printf("Missing default: %s\n", cfg->default_label);
}
+   } else if (IS_ENABLED(CONFIG_OF_CONTROL) &&
+  pxe_runtime_select_menu_default(m)) {
+   menu_destroy(m);
+   return NULL;
}
 
return m;
-- 
2.17.1

[PATCH v3 1/2] menu: Add a function to set the default by matching the item data

[Schrempf Frieder]

From: Frieder Schrempf 

In order to make it possible to auto select a default entry by
matching the data of the menu entries by an external matching
function, we add some helpers and expose the
menu_set_default_by_item_data_match() function.

Signed-off-by: Frieder Schrempf 
---
Changes in v3:
* Add a full function comment to describe menu_set_default_by_item_data_match().

Changes in v2:
* Keep the menu structs private and instead only expose one additional
  function, that sets the default by calling an external matching
  function on each entry.
* Change the title and commit message to reflect the changes.
---
 common/menu.c  | 54 ++
 include/menu.h |  3 +++
 2 files changed, 57 insertions(+)

diff --git a/common/menu.c b/common/menu.c
index 7b66d199a9..6110b2396c 100644
--- a/common/menu.c
+++ b/common/menu.c
@@ -160,6 +160,60 @@ static inline struct menu_item *menu_item_by_key(struct 
menu *m,
return menu_items_iter(m, menu_item_key_match, item_key);
 }
 
+/*
+ * Find the first matching item, if any exists by calling a matching function
+ * on the items data field.
+ */
+static inline struct menu_item *menu_item_by_matching_fn(struct menu *m,
+   int match(void *, void *), void * extra)
+{
+   struct list_head *pos, *n;
+   struct menu_item *item;
+   int ret;
+
+   list_for_each_safe(pos, n, >items) {
+   item = list_entry(pos, struct menu_item, list);
+   if (item->key) {
+   ret = match(item->data, extra);
+   if (ret == 1)
+   return item;
+   }
+   }
+
+   return NULL;
+}
+
+/*
+ * menu_set_default_by_item_data_match() - sets a menu default option by 
calling
+ * a matching function on each of the menu items data field.
+ *
+ * m - Points to a menu created by menu_create().
+ *
+ * match - Points to a function that is passed a pointer to the items data 
field
+ * and a pointer to extra data to compare with. It should return 1 on a
+ * match.
+ *
+ * extra - Points to some data that is passed as a second parameter to the
+ * matching function.
+ *
+ * key - Points to a char array that will be set to hold the key of the matched
+ *   menu item.
+ *
+ * Returns 0 if successful, or -ENOENT if no matching item was found.
+ */
+int menu_set_default_by_item_data_match(struct menu *m,
+   int match(void *, void *), void *extra, char **key)
+{
+   struct menu_item *item = menu_item_by_matching_fn(m, match, extra);
+
+   if (!item)
+   return -ENOENT;
+
+   *key = item->key;
+   m->default_item = item;
+   return 0;
+}
+
 /*
  * Set *choice to point to the default item's data, if any default item was
  * set, and returns 1. If no default item was set, returns -ENOENT.
diff --git a/include/menu.h b/include/menu.h
index 2d227c20bd..0a8b41a905 100644
--- a/include/menu.h
+++ b/include/menu.h
@@ -18,6 +18,9 @@ int menu_item_add(struct menu *m, char *item_key, void 
*item_data);
 int menu_destroy(struct menu *m);
 void menu_display_statusline(struct menu *m);
 int menu_default_choice(struct menu *m, void **choice);
+int menu_set_default_by_item_data_match(struct menu *m,
+   int match(void *, void *), void *extra,
+   char **key);
 
 /**
  * menu_show() Show a boot menu
-- 
2.17.1

RE: [PATCH 4/9] ARM: dts: stm32mp1: move FDCAN to PLL4_R

[Patrick DELAUNAY]

Hi Marek,

> From: Marek Vasut 
> Sent: mercredi 5 février 2020 03:23
> 
> On 2/4/20 2:16 PM, Patrick DELAUNAY wrote:
> > Hi Marek
> 
> Hello Patrick,
> 
> [...]
> 
>  What I think you are missing is that not everyone will update
>  ATF/U-Boot/Linux in lockstep. That is the problem you need to deal with
> here.
> >>>
> >>> I understood the possible issue and I hope that I will be not the
> >>> case (at least for the ST Microelectronics boards).
> >>
> >> Do I understand it correctly that you expect the customers who buy
> >> the ST chip to update bootloader in lockstep with the kernel in
> >> systems which are deployed today ?
> >>
> >> No, this does not work. If you have a working bootloader and your
> >> kernel fails to start, that is something you can recover from, If
> >> your bootloader fails to start and you need to dig an embedded system
> >> buried who-knows-where or recall a lot of systems because of a failed
> bootloader update, that would be a disaster.
> >
> > No, we don't expect a bootloader updater for all the current customers.
> >
> > We found this weakness in the clock tree configuration used in ST
> > board after our first delivery and we have already provide the patch
> > (in downstream) to clients. So we hope they already use this
> > correction in the  bootloaders used in current products.
> 
> Since it's not in mainline, they do not. Unless you expect that users of the
> STM32MP1 will use some random downstream fork of vendoruboot.

Not random but official ST delivery, without any restriction.

Today Mainline (Linux / U-Boot / TF-A / OP-TEE) have still still restriction
(power support or security support for example) as we don't finish our upstream 
of
the STM32MP15x.

But we continue to push to have reduce the difference, to be sure that customer
can use soon indifferently the Mailine or our delivery.

> > However this clock issue only occur for few case, when FDCAN and LTDC
> > are used in parallel on the boards and only if LTDC change the pixel clock.
> >
> > So it should be occurs only for few customer and the issue is not
> > blocking for most of the cases.
> >
> >>> We are aware of the possible issue to fixe these clocks in first
> >>> stage bootloader but after a long debate, we don't found a better
> >>> solution, with the
> >> constraints:
> >>> - M4 firmware require clock initialization before start and it can
> >>> be loaded by U-Boot
> >>> - clock tree is generated by CubeMX tools which generate device tree
> >>> (for bootloaders and kernel)
> >>> - "assigned-clock" management in Linux kernel could lead us to a
> >>> race condition for shared clock
> >>>
> >>> We spent a long time to found a clock tree which respect all the
> >>> constraints of the SOC before to our first release v1.0 and before I
> >>> upstream the
> >> stm32mp1 support in U-Boot.
> >>>
> >>> Then I wait a year before to upstream the patches on clock tree
> >>> initialization (and the second release v1.2) to avoid too many iteration.
> >>>  And this patch on FDCAN is the only issue found on the initial clock 
> >>> tree.
> >>>
> >>> Today I think (hope?) it will be the last patch on this part.
> >>
> >> You will keep finding clock issues and no , this will not be the last
> >> patch which fixes a clock issue.
> >>
> >> So what solution is there for those who can only update the kernel ?
> >
> > Yes, this issue can also solved by a patch in Linux DT to change the clock 
> > tree:
> >
> > _can1 {
> > assigned-clocks = < FDCAN_K >;
> > assigned-clock-parents = < PLL4_R>;  };
> >
> > It is the solution recommended for any customer which can't/wan't update the
> bootloaders.
> 
> But this should be part of mainline Linux either way and possibly Linux 
> should print
> a BIG WARNING if such "weakness" is detected and fix it up, otherwise some
> systems will become dependent on bootloader behavior and once the behaviors
> diverge sufficiently, you will end up with a platform which fails to boot.

I shared this point with Linux maintainers.
 
> If you want a physically embedded system to be deployed for 10+ years
> somewhere and you want to keep updating it with latest kernel versions 
> (because
> security fixes and so on), then you can be sure a bootloader update is not an
> option, because if the system stops working after such an update, someone will
> have to go there and physically retrieve the device and fix it, and that 
> might be
> very expensive or impossible. If you only update the kernel, then the 
> bootloader
> can still be used to recover even a failed kernel update.

I  agree.

> > And I agree that this issue also highlight a issue in the FDCAN
> > driver, which should use the API 'clk_rate_exclusive_get(clk)' to prevent
> modification by LTDC clock.
> >
> > The current patch is only to provide a better "official" clock tree in
> > U-Boot upstream, as we known the ST board is used as reference by many
> > client and also to align the clocks used in downstream
> 

[Patch v2] configs: lx2160a: Enable FSPI support

[Kuldeep Singh]

Enable FSPI controller support. So, flash environment can now be used.

Signed-off-by: Kuldeep Singh 
---
Please let me know if rebase required while applying.
v2:
-Drop other patches from series as already accepted.
-Add ENV_SECT_SIZE value as 0x2

 configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 +
 configs/lx2160aqds_tfa_defconfig | 5 -
 configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 +
 configs/lx2160ardb_tfa_defconfig | 5 -
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig 
b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
index 6989543..4c54eb4 100644
--- a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
@@ -65,6 +65,7 @@ CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
+CONFIG_NXP_FSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig
index c9a6ffb..e472c12 100644
--- a/configs/lx2160aqds_tfa_defconfig
+++ b/configs/lx2160aqds_tfa_defconfig
@@ -4,6 +4,7 @@ CONFIG_TFABOOT=y
 CONFIG_SYS_TEXT_BASE=0x8200
 CONFIG_SYS_MALLOC_F_LEN=0x6000
 CONFIG_ENV_SIZE=0x2000
+CONFIG_ENV_SECT_SIZE=0x2
 CONFIG_ENV_OFFSET=0x50
 CONFIG_DM_GPIO=y
 CONFIG_FSPI_AHB_EN_4BYTE=y
@@ -32,6 +33,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_BOARD_FIXUP=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-lx2160a-qds"
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
@@ -57,14 +59,15 @@ CONFIG_E1000=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
-CONFIG_PCIE_LAYERSCAPE_GEN4=y
 CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_PCIE_LAYERSCAPE_GEN4=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_PCF2127=y
 CONFIG_DM_SCSI=y
 CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
+CONFIG_NXP_FSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
diff --git a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig 
b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
index 5517a7d..887ca4a 100644
--- a/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
+++ b/configs/lx2160ardb_tfa_SECURE_BOOT_defconfig
@@ -60,6 +60,7 @@ CONFIG_DM_SCSI=y
 CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
+CONFIG_NXP_FSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig
index b998cb6..5d4580e 100644
--- a/configs/lx2160ardb_tfa_defconfig
+++ b/configs/lx2160ardb_tfa_defconfig
@@ -4,6 +4,7 @@ CONFIG_TFABOOT=y
 CONFIG_SYS_TEXT_BASE=0x8200
 CONFIG_SYS_MALLOC_F_LEN=0x6000
 CONFIG_ENV_SIZE=0x2000
+CONFIG_ENV_SECT_SIZE=0x2
 CONFIG_ENV_OFFSET=0x50
 CONFIG_DM_GPIO=y
 CONFIG_EMC2305=y
@@ -33,6 +34,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_OF_BOARD_FIXUP=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-lx2160a-rdb"
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
@@ -56,14 +58,15 @@ CONFIG_E1000=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
-CONFIG_PCIE_LAYERSCAPE_GEN4=y
 CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_PCIE_LAYERSCAPE_GEN4=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_PCF2127=y
 CONFIG_DM_SCSI=y
 CONFIG_DM_SERIAL=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
+CONFIG_NXP_FSPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
-- 
2.7.4