date:20220312

Hi Heinrich,

On Mon, 21 Feb 2022 at 11:59, Heinrich Schuchardt  wrote:
>
> On 2/21/22 01:43, AKASHI Takahiro wrote:
> > Hi Simon,
> >
> > On Sat, Feb 19, 2022 at 04:11:08PM -0700, Simon Glass wrote:
> >> Hi,
> >>
> >> On Sun, 13 Feb 2022 at 17:54, AKASHI Takahiro
> >>  wrote:
> >>>
> >>> Heinrich,
> >>>
> >>> On Fri, Feb 11, 2022 at 08:16:34PM +0100, Heinrich Schuchardt wrote:
>  On 2/9/22 11:10, AKASHI Takahiro wrote:
> > With this enhancement, mkeficapsule will be able to sign a capsule
> > file when it is created. A signature added will be used later
> > in the verification at FMP's SetImage() call.
> >
> > To do that, we need specify additional command parameters:
> > -monotonic-cout  : monotonic count
> > -private-key  : private key file
> > -certificate  : certificate file
> > Only when all of those parameters are given, a signature will be added
> > to a capsule file.
> >
> > Users are expected to maintain and increment the monotonic count at
> > every time of the update for each firmware image.
> >
> > Signed-off-by: AKASHI Takahiro 
> > Reviewed-by: Simon Glass 
> > Acked-by: Ilias Apalodimas 
> > ---
> >.azure-pipelines.yml |   2 +-
> >tools/Makefile   |   1 +
> >tools/eficapsule.h   | 115 +
> >tools/mkeficapsule.c | 380 
> > +++
> >4 files changed, 463 insertions(+), 35 deletions(-)
> >create mode 100644 tools/eficapsule.h
> >>
> >> I'm not sure if it is this patch or something else, but building is
> >> broken as it needs
> >>
> >> gnutls/gnutls.h
> >>
> >> Please update the docs in doc/build/gcc.rst to fix this.
> >
> > I have not noticed that there is *another* list of package dependency.
> > It is easy to fix against gnutls.h, but gnutls.h (or libgnutls-dev)
> > is NOT the only component missing in the list.
> >
> > Comparing gcc.rst with gitlab-ci.yml, there already exist a lot of
> > such packages:
> >
> > gcc.rst   |  gitlab-ci.yml
> > ==   ==
> >>  automake
> >>  autopoint
> > bc   bc
> >>  binutils-dev
> > bisonbison
> > build-essential  build-essential
> > coccinelle|  clang-10
> >>  coreutils
> >>  cpio
> >>  cppcheck
> >>  curl
> > device-tree-compiler device-tree-compiler
> > dfu-util  |  dosfstools
> >>  e2fsprogs
> > efitools efitools
> >>  fakeroot
> > flex flex
> > gdiskgdisk
> >>  git
> >>  gnu-efi
> > graphviz graphviz
> >>  grub-efi-amd64-bin
> >>  grub-efi-ia32-bin
>
> There are some package that are not needed for building at all like
> these GRUB packages which just serve as test binaries.
>
> >>  help2man
> >>  iasl
> > imagemagick  imagemagick
> > liblz4-tool   |  iputils-ping
> > libguestfs-tools libguestfs-tools
> > libncurses-dev|  libgnutls28-dev
> > libpython3-dev|  libgnutls30
> >>  libisl15
> >>  liblz4-tool
> >>  libpixman-1-dev
> >>  libpython-dev

We could split the list, but on the other hand, who develops code in
U-Boot without running the tests? Perhaps we could split into things
needed to build sandbox and things needed to run tests?

>
> libpython-dev does not even exist in Ubuntu 22.04. Who cares about
> Python2 package anymore?

Everything in U-Boot is migrated.

Regards,
Simon

>
> Best regards
>
> Heinrich
>
> >>  libsdl1.2-dev
> > libsdl2-dev  libsdl2-dev
> > libssl-dev   libssl-dev
> > lz4   |  libudev-dev
> > lzma  |  libusb-1.0-0-dev
> > lzma-alone   lzma-alone
> >>  lzop
> >>  mount
> >>  mtd-utils
> >>  mtools
> > openssl

[PATCH v2 2/2] x86: Correct the coreboot header file in MAINTAINERS

This board has its own config header file. Correct it.

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

(no changes since v1)

 board/coreboot/coreboot/MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/coreboot/coreboot/MAINTAINERS 
b/board/coreboot/coreboot/MAINTAINERS
index a05673bb0be..ee12d32ce7c 100644
--- a/board/coreboot/coreboot/MAINTAINERS
+++ b/board/coreboot/coreboot/MAINTAINERS
@@ -2,12 +2,12 @@ COREBOOT BOARD
 M: Simon Glass 
 S: Maintained
 F: board/coreboot/coreboot/
-F: include/configs/chromebook_link.h
+F: include/configs/coreboot.h
 F: configs/coreboot_defconfig
 
 COREBOOT64 BOARD
 M: Simon Glass 
 S: Maintained
 F: board/coreboot/coreboot/
-F: include/configs/chromebook_link.h
+F: include/configs/coreboot.h
 F: configs/coreboot64_defconfig
-- 
2.35.1.723.g4982287a31-goog

[PATCH v2 1/2] x86: Add an enum name for the GNVS firmware type

This enum is currently anonymous. Add a name so it can be used in the
code.

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

Changes in v2:
- Add some comments for the enum

 arch/x86/include/asm/intel_gnvs.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/intel_gnvs.h 
b/arch/x86/include/asm/intel_gnvs.h
index fc743dc9285..0b69530edbf 100644
--- a/arch/x86/include/asm/intel_gnvs.h
+++ b/arch/x86/include/asm/intel_gnvs.h
@@ -47,7 +47,13 @@ enum {
BINF_RW_B = 2
 };
 
-enum {
+/**
+ * enum cros_fw_type_t - Used to indicate Chromium OS firmware type
+ *
+ * Chromium OS uses a region of the GNVS starting at offset 0x100 to store
+ * various bits of information, including the type of firmware being booted
+ */
+enum cros_fw_type_t {
FIRMWARE_TYPE_AUTO_DETECT = -1,
FIRMWARE_TYPE_RECOVERY = 0,
FIRMWARE_TYPE_NORMAL = 1,
-- 
2.35.1.723.g4982287a31-goog

[PATCH] env: Allow text-env tests to run with awk

At present the tests assume that gawk is being used. Adjust the tests so
that the names are inserted in alphabetical order, so that awk is happy.

Also use PROCINFO to make gawk output in alphabetical order. This is not
ideal, since it changes the env-car ordering from what the user provided,
but it may be acceptable.

Signed-off-by: Simon Glass 
Reported-by: Patrick Delaunay 
Fixes: https://source.denx.de/u-boot/u-boot/-/issues/10
---

 scripts/env2string.awk|  5 -
 test/py/tests/test_env.py | 28 ++--
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/scripts/env2string.awk b/scripts/env2string.awk
index 1bfe9ed07a4..de470a49941 100644
--- a/scripts/env2string.awk
+++ b/scripts/env2string.awk
@@ -81,7 +81,10 @@ END {
if (do_output) {
printf("%s", "#define CONFIG_EXTRA_ENV_TEXT \"")
 
-   # Print out all the variables
+   # Print out all the variables by alphabetic order, if using
+   # gawk. This allows test_env_test.py to work on both awk (where
+   # this next line does nothing)
+   PROCINFO["sorted_in"] = "@ind_str_asc"
for (var in vars) {
env = vars[var]
print var "=" vars[var] "\\0"
diff --git a/test/py/tests/test_env.py b/test/py/tests/test_env.py
index b2f3470de94..6d08565f0b5 100644
--- a/test/py/tests/test_env.py
+++ b/test/py/tests/test_env.py
@@ -554,42 +554,42 @@ def test_env_text(u_boot_console):
 
 # two vars
 check_script('''fred=123
-ernie=456''', 'fred=123\\0ernie=456\\0')
+mary=456''', 'fred=123\\0mary=456\\0')
 
 # blank lines
 check_script('''fred=123
 
 
-ernie=456
+mary=456
 
-''', 'fred=123\\0ernie=456\\0')
+''', 'fred=123\\0mary=456\\0')
 
 # append
 check_script('''fred=123
-ernie=456
-fred+= 456''', 'fred=123 456\\0ernie=456\\0')
+mary=456
+fred+= 456''', 'fred=123 456\\0mary=456\\0')
 
 # append from empty
 check_script('''fred=
-ernie=456
-fred+= 456''', 'fred= 456\\0ernie=456\\0')
+mary=456
+fred+= 456''', 'fred= 456\\0mary=456\\0')
 
 # variable with + in it
-check_script('fred+ernie=123', 'fred+ernie=123\\0')
+check_script('fred+mary=123', 'fred+mary=123\\0')
 
 # ignores variables that are empty
 check_script('''fred=
 fred+=
-ernie=456''', 'ernie=456\\0')
+mary=456''', 'mary=456\\0')
 
 # single-character env name
-check_script('''f=123
+check_script('''m=123
 e=456
-f+= 456''', 'e=456\\0f=123 456\\0')
+m+= 456''', 'e=456\\0m=123 456\\0')
 
 # contains quotes
 check_script('''fred="my var"
-ernie=another"''', 'fred=\\"my var\\"\\0ernie=another\\"\\0')
+mary=another"''', 'fred=\\"my var\\"\\0mary=another\\"\\0')
 
 # variable name ending in +
 check_script('''fred\\+=my var
@@ -598,7 +598,7 @@ fred++= again''', 'fred+=my var again\\0')
 # variable name containing +
 check_script('''fred+jane=both
 fred+jane+=again
-ernie=456''', 'fred+jane=bothagain\\0ernie=456\\0')
+mary=456''', 'fred+jane=bothagain\\0mary=456\\0')
 
 # multi-line vars - new vars always start at column 1
 check_script('''fred=first
@@ -607,7 +607,7 @@ ernie=456''', 'fred+jane=bothagain\\0ernie=456\\0')
 
after blank
  confusing=oops
-ernie=another"''', 'fred=first second third with tab after blank 
confusing=oops\\0ernie=another\\"\\0')
+mary=another"''', 'fred=first second third with tab after blank 
confusing=oops\\0mary=another\\"\\0')
 
 # real-world example
 check_script('''ubifs_boot=
-- 
2.35.1.723.g4982287a31-goog

Re: [PATCH v2 2/2] clk: imx8mq: Add a clock driver for the imx8mq

2022-03-12 Thread Marek Vasut

On 3/11/22 20:33, Angus Ainslie wrote:

On 2022-03-11 11:19, Marek Vasut wrote:

On 3/11/22 19:41, Angus Ainslie wrote:

On 2022-03-11 10:05, Marek Vasut wrote:

On 3/11/22 18:02, Angus Ainslie wrote:

On 2022-03-11 08:57, Marek Vasut wrote:

On 3/11/22 17:35, Angus Ainslie wrote:
All of the PLLs and clocks are initialized so the subsystems
below are

functional and tested.

1) USB host and peripheral
2) ECSPI
3) UART
4) I2C all busses
5) USDHC for eMMC support
6) USB storage
7) GPIO
8) DRAM

The PLL rate tables are from the kernel
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43cdaa1567ad3931fbde438853947d45238cc040

That patch is three years old.
That patch is for MX8M Mini clock, not for MX8M(Q).

You can use the abbreviated commit ID instead:
43cdaa1567ad3 ("clk: imx8mm: Move 1443X/1416X PLL clock structure
to common place")

But that seems to be the wrong commit.

That's the commit where the imx8m PLL frequency table is moved to a
common file for use by all of the imx8m variants. The imx8mq linux
driver does not even use the frequency tables so there is not a
specific commit for it.

Isn't large part of this driver coming from these tables ?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/clk/imx/clk-imx8mq.c

When I said tables I was referring to the PLL frequency tables.

Ahh, hmmm, I see that we now have three copies of those PLL tables in
each MX8M{M,N,P} driver and Linux instead has this in common code. Can
you deduplicate the PLL tables before we add fourth copy ?

Ok I can do that for the imx8m* clock drivers.

You can do that as a separate patch too, possibly afterward as well.
If something breaks, it would be easy to bisect.

The driver is modelled after the u-boot imx8mm u-boot driver with
register and mux updates from the imx8mq reference manual. Very
little comes from the imx8mq kernel driver. Mainly I just verified
mux naming and register offsets against that driver.

Would it make sense to pick the Linux kernel tables instead then,
instead of hand-writing them from scratch ? That seems error prone.

It's a good thing I didn't just copy the kernel drivers because I found
an error there. After this driver accepted there will very few if any
updates to the mux tables as I think most if not all of the clocks
you'll need in u-boot are defined. If there are any future updates those
could be cut and pasted.

I had one more look at the kernel and u-boot drivers and now I finally
see what you mean with the tables being disparate ... all right.

Re: [PATCH] usb: dwc2: handle return code of dev_read_size() in of to plat function

2022-03-12 Thread Marek Vasut


On 3/12/22 18:22, Wolfgang Grandegger wrote:

dev_read_size() returns -EINVAL (-22) if the property does not exist.


Which property ?


Signed-off-by: Wolfgang Grandegger 
---
  drivers/usb/gadget/dwc2_udc_otg.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c
index 2748270..00f7e8e 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -996,8 +996,9 @@ static int dwc2_udc_otg_of_to_plat(struct udevice *dev)
plat->rx_fifo_sz = dev_read_u32_default(dev, "g-rx-fifo-size", 0);
plat->np_tx_fifo_sz = dev_read_u32_default(dev, "g-np-tx-fifo-size", 0);
  
-	plat->tx_fifo_sz_nb =

-   dev_read_size(dev, "g-tx-fifo-size") / sizeof(u32);
+   ret = dev_read_size(dev, "g-tx-fifo-size");
+   if (ret > 0)
+   platdata->tx_fifo_sz_nb = ret / sizeof(u32);


If ret <= 0, then platdata->tx_fifo_sz_nb is now uninitialized ?


if (plat->tx_fifo_sz_nb > DWC2_MAX_HW_ENDPOINTS)
plat->tx_fifo_sz_nb = DWC2_MAX_HW_ENDPOINTS;
if (plat->tx_fifo_sz_nb) {
@@ -1052,7 +1053,6 @@ static int dwc2_udc_otg_reset_init(struct udevice *dev,
return ret;
  
  	ret = reset_assert_bulk(resets);

-
if (!ret) {
udelay(2);
ret = reset_deassert_bulk(resets);


This shouldn't be part of the patch ?

Re: [PATCH v10 3/9] env: Allow U-Boot scripts to be placed in a .env file

Hi Patrick,

On Thu, 10 Feb 2022 at 04:20, Patrick DELAUNAY
 wrote:
>
> Hi Simon,
>
> On 10/22/21 05:08, Simon Glass wrote:
> > At present U-Boot environment variables, and thus scripts, are defined
> > by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> > to this file and dealing with quoting and newlines is harder than it
> > should be. It would be better if we could just type the script into a
> > text file and have it included by U-Boot.
> >
> > Add a feature that brings in a .env file associated with the board
> > config, if present. To use it, create a file in a board/
> > directory, typically called .env and controlled by the
> > CONFIG_ENV_SOURCE_FILE option.
> >
> > The environment variables should be of the form "var=value". Values can
> > extend to multiple lines. See the README under 'Environment Variables:'
> > for more information and an example.
> >
> > In many cases environment variables need access to the U-Boot CONFIG
> > variables to select different options. Enable this so that the environment
> > scripts can be as useful as the ones currently in the board config files.
> > This uses the C preprocessor, means that comments can be included in the
> > environment using /* ... */
> >
> > Also support += to allow variables to be appended to. This is needed when
> > using the preprocessor.
> >
> > Signed-off-by: Simon Glass 
> > Reviewed-by: Marek Behún 
> > Tested-by: Marek Behún 
> > ---
> ...
> >
> >
> >   MAINTAINERS   |   7 +++
> >   Makefile  |  66 ++-
> >   config.mk |   2 +
> >   doc/usage/environment.rst |  81 -
> >   doc/usage/index.rst   |   1 +
> >   env/Kconfig   |  18 +++
> >   env/embedded.c|   1 +
> >   include/env_default.h |  11 
> >   scripts/env2string.awk|  80 
> >   test/py/tests/test_env.py | 107 ++
> >   10 files changed, 372 insertions(+), 2 deletions(-)
> >   create mode 100644 scripts/env2string.awk
> >
>
> ...
>
>
> For information, it seems the new test "test_env_text" failed when the
> gawk is not installed on Ubuntu distribution,
>
> or when /usr/bin/mawk is used as alternative (sudo update-alternatives
> --config awk)
>
> The test result is
>
> test/py/tests/test_env.py:556: in test_env_text
>  check_script('''fred=123
> test/py/tests/test_env.py:542: in check_script
>  assert result == expect
> E   assert '#define CONF...red=123\\0"\n' == '#define CONF...nie=456\\0"\n'
> E - #define CONFIG_EXTRA_ENV_TEXT "ernie=456\0fred=123\0"
> E ?   --
> E + #define CONFIG_EXTRA_ENV_TEXT "fred=123\0ernie=456\0"
> E ?++
>  Captured
> stdout call -
> +awk -f /u-boot/scripts/env2string.awk /tmp/tmp0zgiwrd9/infile
> #define CONFIG_EXTRA_ENV_TEXT "fred=123\0"
> +awk -f /u-boot/scripts/env2string.awk /tmp/tmpq6xej0ct/infile
> +awk -f /u-boot/scripts/env2string.awk /tmp/tmpyrn10apn/infile
> #define CONFIG_EXTRA_ENV_TEXT "ernie=456\0fred=123\0"
>
>
> => the env variables are sorted in alphabetic order in mawk output / in
> creation order in gawk ouput
>
> I don't found solution to be POSIX compliant and to guarantee the output
> order
>
>
>  >> By default, when a for loop traverses an array, the order is undefined,
>
>  >> meaning that the awk implementation determines the order in which
>
>  >> the array is traversed. This order is usually based on the internal
>
>  >> implementation of arrays and will vary from one version of awk to
> the next.
>
>
> References:
>
> https://www.gnu.org/software/gawk/manual/html_node/Controlling-Scanning.html
>
> https://www.gnu.org/software/gawk/manual/html_node/Controlling-Array-Traversal.html
>
>
> > diff --git a/scripts/env2string.awk b/scripts/env2string.awk
> > new file mode 100644
> > index 000..57d0fc8f3ba
> > --- /dev/null
> > +++ b/scripts/env2string.awk
> > @@ -0,0 +1,80 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright 2021 Google, Inc
> > +#
> > +# SPDX-License-Identifier:   GPL-2.0+
> > +#
> > +# Awk script to parse a text file containing an environment and convert it
> > +# to a C string which can be compiled into U-Boot.
> > +
> > +# The resulting output is:
> > +#
> > +#   #define CONFIG_EXTRA_ENV_TEXT ""
> > +#
> > +# If the input is empty, this script outputs a comment instead.
> > +
> > +BEGIN {
> > + # env holds the env variable we are currently processing
> > + env = "";
> > + ORS = ""
> > +}
> > +
>
>
> ...
>
>
> > +
> > +END {
> > + # Record the value of the variable now completed. If the variable is
> > + # empty it is not set.
> > + if (length(env) != 0) {
> > + vars[var] = env
> > + }
> > +
> > + if

Re: [PATCH v3 21/26] binman: Support splitting an ELF file into multiple nodes

Hi Alper,

On Thu, 10 Mar 2022 at 12:36, Alper Nebi Yasak  wrote:
>
> On 06/03/2022 06:19, Simon Glass wrote:
> > Some boards need to load an ELF file using the 'loadables' property, but
> > the file has segments at different memory addresses. This means that it
> > cannot be supplied as a flat binary.
> >
> > Allow generating a separate node in the FIT for each segment in the ELF,
> > with a different load address for each.
> >
> > Also add checks that the fit,xxx directives are valid.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v3:
> > - Fix 'segmnet' typo
> > - Use seq == 0 instead of 'not seq'
> >
> > Changes in v2:
> > - Rewrite this to use the new FIT entry-type implementation
> > - Rename op-tee to tee-os
> >
> >  tools/binman/entries.rst | 146 
> >  tools/binman/etype/fit.py| 229 ++-
> >  tools/binman/ftest.py| 147 
> >  tools/binman/test/226_fit_split_elf.dts  |  67 ++
> >  tools/binman/test/227_fit_bad_dir.dts|   9 +
> >  tools/binman/test/228_fit_bad_dir_config.dts |   9 +
> >  6 files changed, 597 insertions(+), 10 deletions(-)
> >  create mode 100644 tools/binman/test/226_fit_split_elf.dts
> >  create mode 100644 tools/binman/test/227_fit_bad_dir.dts
> >  create mode 100644 tools/binman/test/228_fit_bad_dir_config.dts
>
> I still can't like this enough to add a Reviewed-by, but I guess you'll
> apply the series up to and maybe including this, so:
>
> Acked-by: Alper Nebi Yasak 

Yes OK I will do that in the next few days.

Then I will await your thoughts on next steps.

Regards,
Simon

Re: [PATCH 1/1] doc: add libgnutls28-dev to build dependencies

On Sat, 12 Mar 2022 at 03:58, Heinrich Schuchardt
 wrote:
>
> mkeficapsule requires package libgnutls28-dev for building
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  doc/build/gcc.rst | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)

Reviewed-by: Simon Glass

Re: [PATCH v2 26/28] serial: dm: Add support for puts

Hi Sean,

On Fri, 11 Mar 2022 at 22:53, Sean Anderson  wrote:
>
> On 3/12/22 12:02 AM, Simon Glass wrote:
> > Hi Sean,
> >
> > On Thu, 10 Mar 2022 at 13:51, Sean Anderson  wrote:
> >>
> >> Some serial drivers can be vastly more efficient when printing multiple
> >> characters at once. Non-DM serial has had a puts option for these sorts
> >> of drivers; implement it for DM serial as well.
> >>
> >> Because we have to add carriage returns, we can't just pass the whole
> >> string directly to the serial driver. Instead, we print up to the
> >> newline, then print a carriage return, and then continue on. This is
> >> less efficient, but it is better than printing each character
> >> individually. It also avoids having to allocate memory just to add a few
> >> characters.
> >>
> >> Drivers may perform short writes (such as filling a FIFO) and return the
> >> number of characters written in len. We loop over them in the same way
> >> that _serial_putc loops over putc.
> >>
> >> This results in around 148 bytes of bloat for all boards with DM_SERIAL
> >> enabled:
> >
> > So let's put it behind a Kconfig, particularly for SPL.
>
> I've added a config for this for v3.
>
> >>
> >> vexpress_aemv8a_juno: all +148 rodata +8 text +140
> >> u-boot: add: 2/0, grow: 0/-2 bytes: 232/-92 (140)
> >>   function   old new   delta
> >>   _serial_puts - 200+200
> >>   strchrnul-  32 +32
> >>   serial_puts 68  24 -44
> >>   serial_stub_puts56   8 -48
> >>
> >> Signed-off-by: Sean Anderson 
> >> ---
> >>
> >> Changes in v2:
> >> - New
> >>
> >>   drivers/serial/serial-uclass.c | 27 +--
> >>   include/serial.h   | 18 ++
> >>   2 files changed, 43 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/serial/serial-uclass.c 
> >> b/drivers/serial/serial-uclass.c
> >> index 362cedd955..352ad986f7 100644
> >> --- a/drivers/serial/serial-uclass.c
> >> +++ b/drivers/serial/serial-uclass.c
> >> @@ -199,8 +199,31 @@ static void _serial_putc(struct udevice *dev, char ch)
> >>
> >>   static void _serial_puts(struct udevice *dev, const char *str)
> >>   {
> >> -   while (*str)
> >> -   _serial_putc(dev, *str++);
> >> +   struct dm_serial_ops *ops = serial_get_ops(dev);
> >> +
> >> +   if (!ops->puts) {
> >> +   while (*str)
> >> +   _serial_putc(dev, *str++);
> >> +   }
> >> +
> >> +   do {
> >> +   const char *newline = strchrnul(str, '\n');
> >> +   size_t len = newline - str + !!*newline;
> >> +
> >> +   do {
> >> +   int err;
> >> +   size_t written = len;
> >> +
> >> +   err = ops->puts(dev, str, );
> >> +   if (err && err != -EAGAIN)
> >> +   return;
> >> +   str += written;
> >> +   len -= written;
> >> +   } while (len);
> >> +
> >> +   if (*newline)
> >> +   _serial_putc(dev, '\r');
> >> +   } while (*str);
> >>   }
> >>
> >>   static int __serial_getc(struct udevice *dev)
> >> diff --git a/include/serial.h b/include/serial.h
> >> index 2681d26c82..ea96d904d8 100644
> >> --- a/include/serial.h
> >> +++ b/include/serial.h
> >> @@ -195,6 +195,24 @@ struct dm_serial_ops {
> >>   * @return 0 if OK, -ve on error
> >>   */
> >>  int (*putc)(struct udevice *dev, const char ch);
> >> +   /**
> >> +* puts() - Write a string
> >> +*
> >> +* This writes a string. This function should be implemented only 
> >> if
> >> +* writing multiple characters at once is more performant than just
> >> +* calling putc() in a loop.
> >> +*
> >> +* If the whole string cannot be written at once, then @len should 
> >> be
> >> +* set to the number of characters written, and this function 
> >> should
> >> +* return -EAGAIN.
> >> +*
> >> +* @dev: Device pointer
> >> +* @s: The string to write
> >> +* @len: The length of the string to write. This should be set to 
> >> the
> >> +*   number of characters actually written on return.
> >
> > How about returning the number of characters written? That is more
> > like the posix write() function and saves an arg.
>
> OK, how about positive return is bytes written and negative error.

SGTM

>
> >> +* @return 0 if OK, -ve on error
> >> +*/
> >> +   int (*puts)(struct udevice *dev, const char *s, size_t *len);
> >>  /**
> >>   * pending() - Check if input/output characters are waiting
> >>   *
> >> --
> >> 2.25.1
> >>
> >
> > Is it possible to add a test

Re: [PATCH v3 6/8] cmd: rng: Add support for selecting RNG device

Hi Sughosh,

On Thu, 10 Mar 2022 at 05:43, Sughosh Ganu  wrote:
>
> hi Simon,
>
> On Wed, 9 Mar 2022 at 21:02, Simon Glass  wrote:
> >
> > Hi Sugosh,
> >
> > On Fri, 4 Mar 2022 at 06:35, Sughosh Ganu  wrote:
> > >
> > > The 'rng' u-boot command is used for printing a select number of
> > > random bytes on the console. Currently, the RNG device from which the
> > > random bytes are read is fixed. However, a platform can have multiple
> > > RNG devices, one example being qemu, which has a virtio RNG device and
> > > the RNG pseudo device through the TPM chip.
> > >
> > > Extend the 'rng' command so that the user can provide the RNG device
> > > number from which the random bytes are to be read. This will be the
> > > device index under the RNG uclass.
> > >
> > > Signed-off-by: Sughosh Ganu 
> > > Tested-by: Heinrich Schuchardt 
> > > ---
> > >
> > > Changes since V2: None
> > >
> > >  cmd/rng.c | 31 +++
> > >  1 file changed, 23 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/cmd/rng.c b/cmd/rng.c
> > > index 1ad5a096c0..bb89cfa784 100644
> > > --- a/cmd/rng.c
> > > +++ b/cmd/rng.c
> > > @@ -13,19 +13,34 @@
> > >
> > >  static int do_rng(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> > > argv[])
> > >  {
> > > -   size_t n = 0x40;
> > > +   size_t n;
> > > struct udevice *dev;
> > > void *buf;
> > > +   int devnum;
> > > int ret = CMD_RET_SUCCESS;
> > >
> > > -   if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
> > > +   switch (argc) {
> > > +   case 1:
> > > +   devnum = 0;
> > > +   n = 0x40;
> > > +   break;
> > > +   case 2:
> > > +   devnum = hextoul(argv[1], NULL);
> > > +   n = 0x40;
> > > +   break;
> > > +   case 3:
> > > +   devnum = hextoul(argv[1], NULL);
> > > +   n = hextoul(argv[2], NULL);
> > > +   break;
> > > +   default:
> > > +   return CMD_RET_USAGE;
> > > +   }
> > > +
> > > +   if (uclass_get_device(UCLASS_RNG, devnum, ) || !dev) {
> >
> > Devices are numbered by aliases, so you should use
> > uclass_get_device_by_seq() here.
> >
> > > printf("No RNG device\n");
> > > return CMD_RET_FAILURE;
> > > }
> > >
> > > -   if (argc >= 2)
> > > -   n = hextoul(argv[1], NULL);
> > > -
> > > buf = malloc(n);
> >
> > No need to malloc(), just set a limit for (say 64) bytes. See how
> > cmd_mem.c does it.
>
> These changes were not made as part of this patch. This is already
> existing code. I will make the changes that you suggest nonetheless.
> Btw, can you please take a look at the v4 patchset for this series.
> Thanks.

Ah I see, then you could do it as another patch.

Regards,
Simon

Re: [PATCH v3 3/8] tpm: rng: Add driver model interface for TPM RNG device

Hi Sughosh.

On Wed, 9 Mar 2022 at 04:18, Sughosh Ganu  wrote:
>
> hi Simon,
>
> On Wed, 9 Mar 2022 at 11:30, Sughosh Ganu  wrote:
> >
> > hi Simon,
> >
> > Thanks for looking into this. I now have a fair idea of the structure
> > that you are looking for this interface.
> >
> > On Wed, 9 Mar 2022 at 08:05, Simon Glass  wrote:
> > >
> > > Hi Sugosh,
> > >
> > > On Fri, 4 Mar 2022 at 06:35, Sughosh Ganu  wrote:
> > > >
> > > > The TPM device has a builtin random number generator(RNG)
> > > > functionality. Expose the RNG functions of the TPM device to the
> > > > driver model so that they can be used by the EFI_RNG_PROTOCOL if the
> > > > protocol is installed.
> > > >
> > > > Also change the function arguments and return type of the random
> > > > number functions to comply with the driver model api.
> > > >
> > > > Signed-off-by: Sughosh Ganu 
> > > > ---
> > > >
> > > > Changes since V2:
> > > >
> > > > * Export the existing tpm*_get_random functions to the driver model
> > > >   instead of moving them to the drivers/rng/ directory.
>
> 
>
> > > > diff --git a/lib/tpm_api.c b/lib/tpm_api.c
> > > > index da48058abe..3584fda98c 100644
> > > > --- a/lib/tpm_api.c
> > > > +++ b/lib/tpm_api.c
> > > > @@ -6,6 +6,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -265,12 +266,26 @@ u32 tpm_get_permissions(struct udevice *dev, u32 
> > > > index, u32 *perm)
> > > > return -ENOSYS;
> > > >  }
> > > >
> > > > +#if CONFIG_IS_ENABLED(DM_RNG)
> > > >  int tpm_get_random(struct udevice *dev, void *data, u32 count)
> > > >  {
> > > > +   int ret = -ENOSYS;
> > > > +   struct udevice *rng_dev;
> > > > +
> > > > if (tpm_is_v1(dev))
> > > > -   return tpm1_get_random(dev, data, count);
> > > > +   ret = uclass_get_device_by_driver(UCLASS_RNG,
> > > > + 
> > > > DM_DRIVER_GET(tpm1_rng),
> > > > + _dev);
> > >
> > > Er, tpm_get_random() should take a tpm device. The random device
> > > should be handled by the caller, which should call
> > > tpm_get_random(rand_dev->parent...
> >
> > Okay. I will make the changes as per your suggestion. Thanks for the
> > review of the patch.
>
> Having had a relook at this, the tpm_get_random is indeed getting the
> TPM device. Which is why the call to tpm_is_v1 is being called with
> the same 'dev' argument. So I believe this function is currently as
> per what you are looking for. Getting the TPM device as the first
> argument.

OK.

Regards,
Simon

Re: Porting U-Boot's UEFI Payload to coreboot

Hi Ahamed,

On Sat, 12 Mar 2022 at 08:23, Ahamed Husni  wrote:
>
> Hello,
>
> Sorry for the delay. Thank you for the replies.
>
> On Tue, Mar 8, 2022 at 9:39 PM Simon Glass  wrote:
> >
> > Hi,
> >
> > On Tue, 8 Mar 2022 at 06:57, Heinrich Schuchardt  wrote:
> > >
> > > On 3/8/22 13:59, Ahamed Husni wrote:
> > > > Hi everyone,
> > > >
> > > > I am trying to work on a project to port the U-Boot UEFI code to 
> > > > coreboot
> > > > as a payload.
> > > > I haven't worked with UEFI before except running a basic EFI payload in 
> > > > a
> > > > coreboot/u-boot environment. (Serial output:
> > > > https://gist.github.com/drac98/6166d29f6c3a2baf2f4e791925ea98d3)
> > > >
> > > > I would like to know how UEFI is implemented in U-Boot. Is UEFI 
> > > > integrated
> > > > into u-boot or is it implemented like a payload?
> > >
> > > Hello Ahamed,
> > >
> > > the UEFI API implementation is an integral part of U-Boot.
> > >
> > > >
> > > > Where is the UEFI source code? Is it the following files in the tree
> > > > https://source.denx.de/u-boot/custodians/u-boot-efi
> > > > lib/
> > > > |__ efi/
> > > > |__ efi_driver/
> > > > |__ efi_loader/
> > >
> > > U-Boot can both be run on top of UEFI. This is the code you find in
> > > /lib/efi/. Furthermore UEFI can run as a firmware providing the UEFI
> > > API. This is what you find in /lib/efi_loader/ and /lib/efi_driver/.
> Then I should look at the lib/efi_loader/ and lib/efi_driver/ I guess. Thank 
> you!
>
> > >
> > > You can build U-Boot as payload for coreboot which offers the UEFI API
> > > implementation. See configs/coreboot64_defconfig.
> > >
> > > U-Boot runs ARM and RISC-V Linux successfully via UEFI.
> > >
> > > What architecture are you looking at?
> I'll be mostly working with a x86_64 QEMU target.
> I am proposing this project for the GSoC this year.
> So the architecture could change after discussions.
>
> > >
> > > Simon (on CC) has been working on U-Boot on UEFI and Coreboot while I
> > > have concentrated on the UEFI API implementation in U-Boot.
> @Simon can I CC you to the discussion in coreboot?

Yes that is OK.

>
> >
> > Yes you can use U-Boot as a coreboot payload - this is now running in
> > CI so we make sure it works on each release. I plan to add more test
> > cases to it but have been waiting to see if coreboot can add something
> > similar to its CI.
>
> I used U-Boot (v2019.4) as a coreboot payload to run my hello world EFI 
> payload and it
> worked.
>
> I also tried different combinations of the applications,
> | Arch | U-Boot | EFI | Status |
> ||-||-|
> | 32bit | 32bit | 32bit | Success |
> | 64bit | 32bit | 32bit | Success |
> | 64bit | 64bit | 64bit | Fails and reboot |
> | 64bit | 64bit | 32bit | Fails and returns back to shell printing the error 
> code |
> | 64bit | 32bit | 64bit | Fails and returns back to shell printing the error 
> code |
>
> The last two fail because the EFI does not support booting a 64-bit 
> application from a 32-bit EFI (or vice versa) as mentioned in the u-boot 
> docs. Is this something in the UEFI specification?

Yes.

+Ilias Apalodimas might comment on that too.

>
> The third one fails because 64-bit EFI is not supported yet.

It is supported now but there are some problems and it needs some
work. You are welcome to look at it and I can help.

+Christian Melki was testing that

>
> Is there a way to run 64-bit EFI with something like the 32-bit SPL binary 
> used to boot 64-bit u-boot in coreboot(32-bit)?
> Ex: can we boot a 64bit Windows/Linux with 32-bit EFI? It seems linux can 
> work with 32bit EFI from this thread.

It sounds like you found the coreboot64 build which uses SPL to switch
to 64bit, then runs 64-bit U-Boot.

But if I understand correctly, your question is more for Linux and
Windows I think, so I would check there.


>
> Best Regards,
> Husni Faiz.
>
> >
> > +Stefan Reinauer as we have been talking about this
> >
> > It seems better to go that way than trying to duplicate efforts. We
> > have a program now to move UEFI to use driver model properly, for
> > example.
> >
> > Regards,
> > Simon

Re: [PATCH v2 1/1] cmd: add serial console support for the cls command

Hi Heinrich,

On Sat, 12 Mar 2022 at 05:05, Heinrich Schuchardt
 wrote:
>
>
>
> On 3/12/22 06:02, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Fri, 11 Mar 2022 at 00:06, Heinrich Schuchardt
> >  wrote:
> >>
> >> On 2/11/22 21:29, Simon Glass wrote:
> >>> On Fri, 11 Feb 2022 at 10:11, Heinrich Schuchardt
> >>>  wrote:
> 
>  Currently the cls command does not support the serial console
> 
>  The screen can be cleared in the video uclass, the colored frame buffer
>  console, and the serial console by sending the same escape sequence.
>  This reduces the cls command to a single printf() statement on most
>  boards.
> 
>  Signed-off-by: Heinrich Schuchardt 
>  ---
>  v2:
>    support cls with CONFIG_DM_VIDEO=y and CONFIG_VIDEO_ANSI=n
>  ---
> cmd/cls.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>>
> >>> Reviewed-by: Simon Glass 
> >>>
> >>> (would be better with if() instead of #if)
> >>
> >> This is not possible because you chose to give two functions with a
> >> different number of parameters the same name (video_clear()).
> >
> > Yes that is bad, but I sent a series to remove cfb_console:
> >
> > https://patchwork.ozlabs.org/project/uboot/list/?series=282367
>
> There still remains:
>
> In lcd.h there is an #ifndef CONFIG_DM_VIDEO hiding the definition of
> lcd_clear().

OK, well you can drop that if you like. I cannot see why the #iifdef
is needed there.

I am waiting for the video series to go in but can do a series to
remove the LCD stuff after that.

Regards,
Simon

Re: [PATCH v3 24/31] bootstd: Add an implementation of EFI bootmgr

Hi Ilias,

On Sat, 12 Mar 2022 at 02:37, Ilias Apalodimas
 wrote:
>
> Hi Simon
>
> On Sun, 6 Mar 2022 at 05:08, Simon Glass  wrote:
>>
>> Hi Heinrich,
>>
>> On Wed, 19 Jan 2022 at 04:47, Heinrich Schuchardt  wrote:
>> >
>> > On 1/19/22 02:43, Simon Glass wrote:
>> > > Add a bootmeth driver which handles EFI boot manager, using EFI_LOADER.
>> > >
>> > > In effect, this provides the same functionality as the 'bootefi bootmgr'
>> > > command and shares the same code. But the interface into it is via a
>> > > bootmeth, so it does not require any special scripts, etc.
>> > >
>> > > For now this requires the 'bootefi' command be enabled. Future work may
>> > > tidy this up so that it can be used without CONFIG_CMDLINE being enabled.
>> > >
>> > > Signed-off-by: Simon Glass 
>> > > ---
>> > >
>> > > Changes in v3:
>> > > - Add a log category
>> > >
>> > >   boot/Makefile   |  3 ++
>> > >   boot/bootmeth_efi_mgr.c | 86 +
>> > >   2 files changed, 89 insertions(+)
>> > >   create mode 100644 boot/bootmeth_efi_mgr.c
>> > >
>> > > diff --git a/boot/Makefile b/boot/Makefile
>> > > index 795665f7ce5..38b10d81f0d 100644
>> > > --- a/boot/Makefile
>> > > +++ b/boot/Makefile
>> > > @@ -31,6 +31,9 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootstd-uclass.o
>> > >   obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_DISTRO) += bootmeth_distro.o
>> > >   obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_DISTRO_PXE) += bootmeth_pxe.o
>> > >   obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EFILOADER) += bootmeth_efi.o
>> > > +ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL
>> > > +obj-$(CONFIG_$(SPL_TPL_)CMD_BOOTEFI_BOOTMGR) += bootmeth_efi_mgr.o
>> > > +endif
>> > >
>> > >   obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
>> > >   obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
>> > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
>> > > new file mode 100644
>> > > index 000..a6914466db7
>> > > --- /dev/null
>> > > +++ b/boot/bootmeth_efi_mgr.c
>> > > @@ -0,0 +1,86 @@
>> > > +// SPDX-License-Identifier: GPL-2.0+
>> > > +/*
>> > > + * Bootmethod for EFI boot manager
>> > > + *
>> > > + * Copyright 2021 Google LLC
>> > > + * Written by Simon Glass 
>> > > + */
>> > > +
>> > > +#define LOG_CATEGORY UCLASS_BOOTSTD
>> > > +
>> > > +#include 
>> > > +#include 
>> > > +#include 
>> > > +#include 
>> > > +#include 
>> > > +#include 
>> > > +
>> > > +static int efi_mgr_check(struct udevice *dev, struct bootflow_iter 
>> > > *iter)
>> > > +{
>> > > + int ret;
>> > > +
>> > > + /* Must be an bootstd device */
>> > > + ret = bootflow_iter_uses_system(iter);
>> > > + if (ret)
>> > > + return log_msg_ret("net", ret);
>> > > +
>> > > + return 0;
>> > > +}
>> > > +
>> > > +static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow 
>> > > *bflow)
>> > > +{
>> > > + /*
>> > > +  * Just assume there is something to boot since we don't have any 
>> > > way
>> > > +  * of knowing in advance
>> > > +  */
>> > > + bflow->state = BOOTFLOWST_READY;
>> > > +
>> > > + return 0;
>> > > +}
>> > > +
>> > > +static int efi_mgr_read_file(struct udevice *dev, struct bootflow 
>> > > *bflow,
>> > > + const char *file_path, ulong addr, ulong 
>> > > *sizep)
>> > > +{
>> > > + /* Files are loaded by the 'bootefi bootmgr' command */
>> > > +
>> > > + return -ENOSYS;
>> > > +}
>> > > +
>> > > +static int efi_mgr_boot(struct udevice *dev, struct bootflow *bflow)
>> > > +{
>> > > + int ret;
>> > > +
>> > > + /* Booting is handled by the 'bootefi bootmgr' command */
>> > > + ret = run_command("bootefi bootmgr", 0);
>> >
>> > You are missing to provide the device tree.
>>
>> OK well I can deal with that when I get to it, I suppose. Which distro
>> can I try with?
>
>
> Any recent distro would work.  If you try to run an installer keep in mind 
> setting up grub will fail (since runtime variable support isn't yet 
> supported).  You can find more info on installing fedora here[1] just skip 
> the security and encryption parts

I see that Fedora 35 is out, so I will give that a go at some point.

>
> [1] https://www.linaro.org/blog/securing-a-device-with-trusted-substrate/

Regards,
Simon

Re: [PATCH v4 13/33] bootstd: Add the bootstd uclass and core implementation

Hi Ilias,

On Sat, 12 Mar 2022 at 07:35, Ilias Apalodimas
 wrote:
>
> Hi Simon,
>
>  +
> > +/* For now, bind the boormethod device if none are found in the devicetree 
> > */
> > +int dm_scan_other(bool pre_reloc_only)
> > +{
> > + struct udevice *bootstd;
> > + int ret;
> > +
> > + /* These are not needed before relocation */
> > + if (!(gd->flags & GD_FLG_RELOC))
> > + return 0;
> > +
> > + /* Create a bootstd device if needed */
> > + uclass_find_first_device(UCLASS_BOOTSTD, );
> > + if (!bootstd) {
> > + ret = device_bind_driver(gd->dm_root, "bootstd_drv", 
> > "bootstd",
> > +  );
> > + if (ret)
> > + return log_msg_ret("bootstd", ret);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static const struct udevice_id bootstd_ids[] = {
> > + { .compatible = "u-boot,boot-std" },
> > + { }
> > +};
> > +
> > +U_BOOT_DRIVER(bootstd_drv) = {
> > + .id = UCLASS_BOOTSTD,
> > + .name   = "bootstd_drv",
> > + .of_to_plat = bootstd_of_to_plat,
> > + .probe  = bootstd_probe,
> > + .remove = bootstd_remove,
> > + .of_match   = bootstd_ids,
> > + .priv_auto  = sizeof(struct bootstd_priv),
> > +};
> > +
> > +UCLASS_DRIVER(bootstd) = {
> > + .id = UCLASS_BOOTSTD,
> > + .name   = "bootstd",
> > +#if CONFIG_IS_ENABLED(OF_REAL)
> > + .post_bind  = dm_scan_fdt_dev,
> > +#endif
> > +};
> > diff --git a/doc/device-tree-bindings/bootstd.txt 
> > b/doc/device-tree-bindings/bootstd.txt
> > new file mode 100644
> > index 00..f048b9dd32
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/bootstd.txt
> > @@ -0,0 +1,28 @@
> > +U-Boot standard boot device (bootstd)
> > +=
> > +
> > +This is the controlling device for U-Boot standard boot, providing a way to
> > +boot operating systems in a way that can be controlled by distros.
>
> A bit more info on how this can be controlled by distros would be helpful.
> What are you expecting from distros here?  Most of the current installers
> (at least on x86 and armv8) set the Boot to SHIM and assume the
> efibootmgr will take care of that.

Well then it would use the bootmgr bootmeth, which is included in this
series. Most of the code here is related to moving on from the current
scripts.

> > +
> > +Required properties:
> > +
> > +compatible: "u-boot,boot-std"
>
> This needs to end up on every board controldtb? Or is there another way of
> defining those nodes?

No, this node is optional.

>
> > +
> > +Optional properties:
> > +
> > +filename-prefixes:
> > +   List of strings, each a directory to search for bootflow files
> > +
> > +bootdev-order:
> > +   List of bootdevs to check for bootflows, each a bootdev label (the media
> > +   uclass followed by the numeric sequence number of the media device)
> > +
> > +
> > +Example:
> > +
> > + bootstd {
> > + compatible = "u-boot,boot-std";
> > +
> > + filename-prefixes = "/", "/boot/";
> > + bootdev-order = "mmc2", "mmc1";
> > + };
>
> [...]

Regards,
Simon

Re: [PATCH v2 02/13] Makefile: Allow LTO to be disabled for a build

Hi Tom,

On Mon, 7 Mar 2022 at 07:33, Tom Rini  wrote:
>
> On Fri, Mar 04, 2022 at 08:42:57AM -0700, Simon Glass wrote:
>
> > LTO (Link-Time Optimisation) is an very useful feature which can
> > significantly reduce the size of U-Boot binaries. So far it has been
> > made available for selected ARM boards and sandbox.
> >
> > However, incremental builds are much slower when LTO is used. For example,
> > an incremental build of sandbox takes 2.1 seconds on my machine, but 6.7
> > seconds with LTO enabled.
> >
> > Add a LTO_BUILD=n parameter to the build, so it can be disabled during
> > development if needed, for faster builds.
> >
> > Add some documentation about LTO while we are here.
> >
> > Signed-off-by: Simon Glass 
>
> We don't need this since you can do:
> make EXTRA_CFLAGS="-fno-lto" EXTRA_LDFLAGS="-fno-lto"
> to pass -fno-lto to compile/linking and disable lto and per
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 this has been working
> for some time.

Thanks for that, it is a big pain point for me, picking up this patch
for every series I write. The incremental build time for sandbox goes
from 3 seconds to 27 seconds on my laptop with LTO, which is
intolerable.

The EXTRA_CFLAGS says it is for 'Backward compatibility' and it still
does the various LTO things (i.e. it changes the build logic). It
seems odd to me to enable the option and then disable it later in the
command line. It is therefore not quite equivalent. But it seems to
work well enough for me fom a small amount of testing. If you are
really set on not having a special option for it, I can live with it
for now. I'm also not convinced that my patch entirely removes the LTO
stuff in a consistent way.

> Not that you need to respin the series for this.

Regards,
Simon

Re: [PATCH] mmc: xenon_sdhci: remove wait_dat0 SDHCI OP

2022-03-12 Thread Marek Behún

On Fri, 11 Mar 2022 19:52:40 +0100
Pali Rohár  wrote:

> + Marek
> 
> Xenon eMMC is broken in U-Boot, could you check / verify it on A3720 eMMC 
> based board?

I can confirm this. I also had to workaround this issue, I reverted the
commit adding support for wait_dat0 in my internal repo.

For now I am pro this solution, so

Reviewed-by: Marek Behún 

Marek

Re: No u-boot-rockchip pull request sent or merged for v2022.04


Hi Tom, Simon, Philipp,

    Thanks for your help, I think my spare time is getting back and I 
can handle the work of patch review and verify on different SoCs/boards 
for u-boot-rockchip now.


I will land patches and fixes which is ready to land to master for 
v2022.04 and others to for-next for v2022.07.



Thanks,
- Kever
On 2022/3/12 03:01, Tom Rini wrote:

On Fri, Mar 11, 2022 at 09:56:59PM +0300, Alper Nebi Yasak wrote:

On 11/03/2022 21:18, Simon Glass wrote:

On Fri, 11 Mar 2022 at 11:16, Alper Nebi Yasak  wrote:

I haven't been paying enough attention to others' patches. For those of
mine, I think I can only call my RK3399 eMMC fix [1] a regression fix.
IIRC it has been broken since v2021.10 on some boards (but not all).

[1] rockchip: sdhci: Fix RK3399 eMMC PHY power cycling
https://patchwork.ozlabs.org/project/uboot/patch/20220128224240.4226-3-alpernebiya...@gmail.com/

Apler, would you be interested in being a co-maintainer for Rockchip?

I can try. Not sure how much I'll be able to help (both time and
knowledge-wise), I only have a chromebook_kevin and just know few things
about rk3399 stuff at best, learning as I go along. But I would like to
help.


I very much want to get your other patches landed too, particularly
the 'kevin' ones as I have that board in my lab.

Me too. Would they go into -next and v2022.07 at this point?

Well, how self contained is it all?

Re: Porting U-Boot's UEFI Payload to coreboot

2022-03-12 Thread Ahamed Husni

Hello,

Sorry for the delay. Thank you for the replies.

On Tue, Mar 8, 2022 at 9:39 PM Simon Glass  wrote:
>
> Hi,
>
> On Tue, 8 Mar 2022 at 06:57, Heinrich Schuchardt 
wrote:
> >
> > On 3/8/22 13:59, Ahamed Husni wrote:
> > > Hi everyone,
> > >
> > > I am trying to work on a project to port the U-Boot UEFI code to
coreboot
> > > as a payload.
> > > I haven't worked with UEFI before except running a basic EFI payload
in a
> > > coreboot/u-boot environment. (Serial output:
> > > https://gist.github.com/drac98/6166d29f6c3a2baf2f4e791925ea98d3)
> > >
> > > I would like to know how UEFI is implemented in U-Boot. Is UEFI
integrated
> > > into u-boot or is it implemented like a payload?
> >
> > Hello Ahamed,
> >
> > the UEFI API implementation is an integral part of U-Boot.
> >
> > >
> > > Where is the UEFI source code? Is it the following files in the tree
> > > https://source.denx.de/u-boot/custodians/u-boot-efi
> > > lib/
> > > |__ efi/
> > > |__ efi_driver/
> > > |__ efi_loader/
> >
> > U-Boot can both be run on top of UEFI. This is the code you find in
> > /lib/efi/. Furthermore UEFI can run as a firmware providing the UEFI
> > API. This is what you find in /lib/efi_loader/ and /lib/efi_driver/.
Then I should look at the lib/efi_loader/ and lib/efi_driver/ I guess.
Thank you!

> >
> > You can build U-Boot as payload for coreboot which offers the UEFI API
> > implementation. See configs/coreboot64_defconfig.
> >
> > U-Boot runs ARM and RISC-V Linux successfully via UEFI.
> >
> > What architecture are you looking at?
I'll be mostly working with a x86_64 QEMU target.
I am proposing this project for the GSoC this year.
So the architecture could change after discussions.

> >
> > Simon (on CC) has been working on U-Boot on UEFI and Coreboot while I
> > have concentrated on the UEFI API implementation in U-Boot.
@Simon can I CC you to the discussion in coreboot?

>
> Yes you can use U-Boot as a coreboot payload - this is now running in
> CI so we make sure it works on each release. I plan to add more test
> cases to it but have been waiting to see if coreboot can add something
> similar to its CI.

I used U-Boot (v2019.4) as a coreboot payload to run my hello world EFI
payload and it
worked.

I also tried different combinations of the applications,
| Arch | U-Boot | EFI | Status |
||-||-|
| 32bit | 32bit | 32bit | Success |
| 64bit | 32bit | 32bit | Success |
| 64bit | 64bit | 64bit | Fails and reboot |
| 64bit | 64bit | 32bit | Fails and returns back to shell printing the
error code |
| 64bit | 32bit | 64bit | Fails and returns back to shell printing the
error code |

The last two fail because the EFI does not support booting a 64-bit
application from a 32-bit EFI (or vice versa) as mentioned in the u-boot
docs. Is this something in the UEFI specification?

The third one fails because 64-bit EFI is not supported yet.

Is there a way to run 64-bit EFI with something like the 32-bit SPL binary
used to boot 64-bit u-boot in coreboot(32-bit)?
Ex: can we boot a 64bit Windows/Linux with 32-bit EFI? It seems linux can
work with 32bit EFI from this
 thread.

Best Regards,
Husni Faiz.

>
> +Stefan Reinauer as we have been talking about this
>
> It seems better to go that way than trying to duplicate efforts. We
> have a program now to move UEFI to use driver model properly, for
> example.
>
> Regards,
> Simon

Re: [PATCH v1 00/11] rockchip fixes and extend rk3568 support


+ Joseph Chen

On 2022/2/22 09:31, Peter Geis wrote:

to: Simon Glass 
to: Philipp Tomsich 
to: Kever Yang 
to: Lukasz Majewski 
to: Sean Anderson 
to: Peng Fan 
to: Jaehoon Chung 
to: Heiko Stübner 
cc: u-boot@lists.denx.de

Good Evening,

The following is a few patches for rockchip mainline u-boot support.
Patches 1-3 are fixes for the rk3568 reset handler, rockchip emmc dma to
sram, and building the rockchip-sfc driver.
Patch 4 adds a sanity check for the minimum sfc frequency.
Patch 5 and 6 add adc support to spl and enable the rockchip recovery
handler in spl, before attempting to load u-boot.
Patch 7 enables rk3568 spl bootrom device detection.
Patch 8 enables automatic clock gating and other power saving features
on rk3568, which solves the chip running hotter compared to downstream.
Patch 9 and 10 move the dwc3 platform data to the chip specific code and
enable dwc3 otg support on rk3568.
Patch 11 is an RFC patch for fixing ram detection on rk3568. Downstream
goes about this a different way, where they implemented a special
library to handle this.

Please review and *especially test* patch 11.

Very Respectfully,
Peter Geis

Peter Geis (11):
   clk: rockchip: rk3568: fix reset handler
   mmc: sdhci: allow disabling sdma in spl
   spi: rockchip-sfc: fix building rockchip-sfc
   spi: rockchip-sfc: sanity check minimum freq
   spl: support adc drivers in spl
   rockchip: handle bootrom recovery mode in spl
   rockchip: rk3568: add boot device detection
   rockchip: rk3568: enable automatic clock gating
   rockchip: move dwc3 config to chip specific handler
   rockchip: rk3568: add dwc3 otg support
   [RFC] rockchip: rk356x: attempt to fix ram detection

  arch/arm/mach-rockchip/Kconfig |   1 +
  arch/arm/mach-rockchip/Makefile|   6 +-
  arch/arm/mach-rockchip/board.c |  24 --
  arch/arm/mach-rockchip/boot_mode.c |   4 +-
  arch/arm/mach-rockchip/rk3399/rk3399.c |  29 +++
  arch/arm/mach-rockchip/rk3568/rk3568.c | 112 +
  arch/arm/mach-rockchip/sdram.c |  19 +++--
  common/board_f.c   |   7 ++
  common/spl/Kconfig |   5 ++
  drivers/Makefile   |   1 +
  drivers/clk/rockchip/clk_rk3568.c  |   2 +
  drivers/mmc/Kconfig|   7 ++
  drivers/mmc/sdhci.c|   6 +-
  drivers/spi/rockchip_sfc.c |   6 ++
  include/configs/rk3568_common.h|   5 ++
  15 files changed, 197 insertions(+), 37 deletions(-)

Re: [PATCH v3 1/6] rockchip: move ROCKCHIP_STIMER_BASE to Kconfig


Hi Johan,

On 2022/3/12 18:01, Johan Jonker wrote:


On 3/12/22 09:51, Jagan Teki wrote:

On Thu, Dec 30, 2021 at 10:18 PM Johan Jonker  wrote:

Move ROCKCHIP_STIMER_BASE to Kconfig.

Signed-off-by: Johan Jonker
---

Changed V3:
   add ROCKCHIP_STIMER
---
  arch/arm/mach-rockchip/Kconfig| 22 ++
  arch/arm/mach-rockchip/px30/Kconfig   |  3 +++
  arch/arm/mach-rockchip/rk3036/Kconfig |  3 +++
  arch/arm/mach-rockchip/rk3128/Kconfig |  3 +++
  arch/arm/mach-rockchip/rk322x/Kconfig |  3 +++
  arch/arm/mach-rockchip/rk3288/Kconfig |  3 +++
  arch/arm/mach-rockchip/rk3308/Kconfig | 10 ++
  arch/arm/mach-rockchip/rk3328/Kconfig |  3 +++
  arch/arm/mach-rockchip/rk3368/Kconfig |  3 +++
  arch/arm/mach-rockchip/rk3399/Kconfig |  3 +++
  arch/arm/mach-rockchip/rk3568/Kconfig |  3 +++
  include/configs/px30_common.h |  1 -
  include/configs/rk3036_common.h   |  1 -
  include/configs/rk3128_common.h   |  1 -
  include/configs/rk322x_common.h   |  1 -
  include/configs/rk3288_common.h   |  1 -
  include/configs/rk3308_common.h   |  1 -
  include/configs/rk3328_common.h   |  1 -
  include/configs/rk3368_common.h   |  1 -
  include/configs/rk3399_common.h   |  1 -
  include/configs/rk3568_common.h   |  1 -
  21 files changed, 55 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index da6871eb..7a624c64 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -343,6 +343,28 @@ config ROCKCHIP_BOOT_MODE_REG
   The Soc will enter to different boot mode(defined in 
asm/arch-rockchip/boot_mode.h)
   according to the value from this register.

+config ROCKCHIP_STIMER
+   bool "Rockchip STIMER support"
+   default y
+   depends on (ROCKCHIP_PX30||   \
+   ROCKCHIP_RK3036|| \
+   ROCKCHIP_RK3128|| \
+   ROCKCHIP_RK322X|| \
+   ROCKCHIP_RK3288|| \
+   ROCKCHIP_RK3308|| \
+   ROCKCHIP_RK3328|| \
+   ROCKCHIP_RK3368|| \
+   ROCKCHIP_RK3399|| \
+   ROCKCHIP_RK3568)

What if we select !(SOC-Which-don't-support-stimer). I believe the
condition check here is much simpler.

The condition would be simpler that's correct, but this patch is made
with rk3066 in mind and there's no ROCKCHIP_RK3066 available yet.
The right approach is to only include SoC's that have a specific
property/functionality linked to there specific config tag.
U-boot should be generic. And we should not have to fix all dependencies
all over the place when a SoC doesn't have something.

Please advise how to support other SoC's like rk3066.
Thanks for you hard working on this, would you mind to share what's the 
motivation for support rk3066 and MK808 board?
RK3066 is an SoC release at 2012, which has been EOL for a long time, 
and MK808 is a product at 2013, almost 10 years ago.



I'm not object for enable more SoC support on the mainline, and I know 
you have spend a lot
of time on this, I have do something like this before, but to be honest 
I don't think it's a good idea to add support for

rk3066 on mainline now.


I merge the patches from Paweł Jarosz many years ago into rockchip local 
u-boot and make it work,
I want to make the branch support as much SoCs as possible at that time. 
But later I found there is no people to use
it, and the U-Boot is getting more and more heavy, old SoC support is 
the one part people want to clean,
for it always bring in more '#if, #else' or something like this clean up 
series patches, and more terrible thing is how to
always maintain the source code works on the old hardware. I do make 
everything work for a long time at first,
but one day my only rk3066 board is broken, and I'm not able to do it 
anymore.


Thanks,
- Kever

Johan


Jagan.

Re: [PATCH v4 13/33] bootstd: Add the bootstd uclass and core implementation

2022-03-12 Thread Ilias Apalodimas

Hi Simon, 

 +
> +/* For now, bind the boormethod device if none are found in the devicetree */
> +int dm_scan_other(bool pre_reloc_only)
> +{
> + struct udevice *bootstd;
> + int ret;
> +
> + /* These are not needed before relocation */
> + if (!(gd->flags & GD_FLG_RELOC))
> + return 0;
> +
> + /* Create a bootstd device if needed */
> + uclass_find_first_device(UCLASS_BOOTSTD, );
> + if (!bootstd) {
> + ret = device_bind_driver(gd->dm_root, "bootstd_drv", "bootstd",
> +  );
> + if (ret)
> + return log_msg_ret("bootstd", ret);
> + }
> +
> + return 0;
> +}
> +
> +static const struct udevice_id bootstd_ids[] = {
> + { .compatible = "u-boot,boot-std" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(bootstd_drv) = {
> + .id = UCLASS_BOOTSTD,
> + .name   = "bootstd_drv",
> + .of_to_plat = bootstd_of_to_plat,
> + .probe  = bootstd_probe,
> + .remove = bootstd_remove,
> + .of_match   = bootstd_ids,
> + .priv_auto  = sizeof(struct bootstd_priv),
> +};
> +
> +UCLASS_DRIVER(bootstd) = {
> + .id = UCLASS_BOOTSTD,
> + .name   = "bootstd",
> +#if CONFIG_IS_ENABLED(OF_REAL)
> + .post_bind  = dm_scan_fdt_dev,
> +#endif
> +};
> diff --git a/doc/device-tree-bindings/bootstd.txt 
> b/doc/device-tree-bindings/bootstd.txt
> new file mode 100644
> index 00..f048b9dd32
> --- /dev/null
> +++ b/doc/device-tree-bindings/bootstd.txt
> @@ -0,0 +1,28 @@
> +U-Boot standard boot device (bootstd)
> +=
> +
> +This is the controlling device for U-Boot standard boot, providing a way to
> +boot operating systems in a way that can be controlled by distros.

A bit more info on how this can be controlled by distros would be helpful.
What are you expecting from distros here?  Most of the current installers
(at least on x86 and armv8) set the Boot to SHIM and assume the
efibootmgr will take care of that.
> +
> +Required properties:
> +
> +compatible: "u-boot,boot-std"

This needs to end up on every board controldtb? Or is there another way of
defining those nodes?

> +
> +Optional properties:
> +
> +filename-prefixes:
> +   List of strings, each a directory to search for bootflow files
> +
> +bootdev-order:
> +   List of bootdevs to check for bootflows, each a bootdev label (the media
> +   uclass followed by the numeric sequence number of the media device)
> +
> +
> +Example:
> +
> + bootstd {
> + compatible = "u-boot,boot-std";
> +
> + filename-prefixes = "/", "/boot/";
> + bootdev-order = "mmc2", "mmc1";
> + };

[...]

Thanks
/Ilias

Re: No u-boot-rockchip pull request sent or merged for v2022.04

Hi Alper,

On 2022/3/12 02:15, Alper Nebi Yasak wrote:

On 11/03/2022 18:43, Tom Rini wrote:

On Fri, Mar 11, 2022 at 12:05:42AM +0300, Alper Nebi Yasak wrote:

I have a few Rockchip-related series [1] that I was expecting to land
for v2022.04 (including improvements for chromebook_bob, support for the
chromebook_kevin board, rk3399 eMMC fixes) but there hasn't been a
u-boot-rockchip pull request since the one for v2022.01 [2]. There's
also more pending patches from other people [3].

Kever seems unresponsive, last message to the mailing list was that pull
request in December 2021. I did send on-list mails as To: Kever whenever
Simon happened to poke me about chromebook_kevin not being merged, but
to no avail.

What should be done here, any advice?

I've been hoping for something to show up soon myself. To start with,

are there any rockchip related regression fixes you're aware of?

I haven't been paying enough attention to others' patches. For those of
mine, I think I can only call my RK3399 eMMC fix [1] a regression fix.

The eMMC driver is always not robust enough on mainline U-Boot, eg.
there still have many

offlist patches on rockchip branch to make all the SoCs work(we do try
to upstream them before), and the patch series you

mentioned which broken the chromebook_kevin board is one of patch want
to clean up and support

rk3568, so I think we also need to test this fix on rk3568 board.

Thanks,
- Kever

IIRC it has been broken since v2021.10 on some boards (but not all).

[1] rockchip: sdhci: Fix RK3399 eMMC PHY power cycling
https://patchwork.ozlabs.org/project/uboot/patch/20220128224240.4226-3-alpernebiya...@gmail.com/

Re: [PATCH v1] MAINTAINERS: add rockchip regex for more files and directories




On 2022/3/12 04:16, Jagan Teki wrote:

On Fri, Dec 24, 2021 at 10:41 PM Johan Jonker  wrote:

The current files and directories with wildcard patterns for
Rockchip patches in MAINTAINERS is not always complete.
Add the regex for DT related files and a generic regex for
catching some other forgotten cases, so that the maintainers
receive all Rockchip related patches.

Signed-off-by: Johan Jonker 
---

Reviewed-by: Jagan Teki 


Reviewed-by: Kever Yang

Re: No u-boot-rockchip pull request sent or merged for v2022.04


Hi Alper,

    Sorry for reply late, I apologize for not  able to make a pull 
request for v2022.04 till now, I'm really busy for pass few weeks, the 
reason including some change from both my work and my family.


I will check the patches on the list for u-boot-rockchip and land them 
once I have check the patch and works on my boards.



Thanks,
- Kever
On 2022/3/11 05:05, Alper Nebi Yasak wrote:

Hi Tom,

I have a few Rockchip-related series [1] that I was expecting to land
for v2022.04 (including improvements for chromebook_bob, support for the
chromebook_kevin board, rk3399 eMMC fixes) but there hasn't been a
u-boot-rockchip pull request since the one for v2022.01 [2]. There's
also more pending patches from other people [3].

Kever seems unresponsive, last message to the mailing list was that pull
request in December 2021. I did send on-list mails as To: Kever whenever
Simon happened to poke me about chromebook_kevin not being merged, but
to no avail.

What should be done here, any advice?

Sorry for being quite late with this,
Alper.


[1] Patches by me
https://patchwork.ozlabs.org/project/uboot/list/?submitter=78732

[2] Pull request: u-boot-rockchip-20211226
https://lore.kernel.org/u-boot/c12f6f2b-8c5a-654a-ad6a-5aed4a938...@rock-chips.com/

[3] Patches assigned to Kever Yang
https://patchwork.ozlabs.org/project/uboot/list/?delegate=93623

Pull request for efi-2022-04-rc3-2

2022-03-12 Thread Heinrich Schuchardt


Dear Tom,

The following changes since commit 589c659035a44a683b087fd75fe0b7667f7be7f5:

  Merge branch '2022-03-08-assorted-fixes' (2022-03-08 08:42:51 -0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2022-04-rc3-2

for you to fetch changes up to 66028930dac08f7116b5e3cdba35c3e65676c0cd:

  efi_loader: copy GUID in InstallProtocolInterface() (2022-03-12
12:27:07 +0100)

Gitlab CI showed no issues:

https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11247


Pull request for efi-2022-04-rc3-2

Documentation:
* Fix description for SiFive Unmatched
* Add libgnutls28-dev to build dependencies

UEFI
* Avoid possibly invalid GUID pointers for protocol interfaces

Other
* Serial console support for cls command


Heinrich Schuchardt (4):
  cmd: add serial console support for the cls command
  doc: path to u-boot-spl.bin on SiFive Unmatched board
  doc: add libgnutls28-dev to build dependencies
  efi_loader: copy GUID in InstallProtocolInterface()

 cmd/cls.c | 10 --
 doc/board/sifive/unmatched.rst|  2 +-
 doc/build/gcc.rst | 11 ++-
 include/efi_loader.h  |  2 +-
 lib/efi_loader/efi_boottime.c | 14 +++---
 lib/efi_loader/efi_image_loader.c |  2 +-
 6 files changed, 24 insertions(+), 17 deletions(-)

[PATCH] led: led_pwm: Add a driver for LEDs connected to PWM

2022-03-12 Thread Ivan Vozvakhov

Add a driver which allows to use of LEDs connected
to PWM (Linux compatible).
MAINTAINERS: add i.vozvakhov as a maintainer of leds-pwm
C(required during new functionality adding).

Signed-off-by: Ivan Vozvakhov 
---

 MAINTAINERS|   6 +
 doc/device-tree-bindings/leds/leds-pwm.txt |  47 +
 drivers/led/Kconfig|   6 +
 drivers/led/Makefile   |   1 +
 drivers/led/led_pwm.c  | 192 +
 5 files changed, 252 insertions(+)
 create mode 100644 doc/device-tree-bindings/leds/leds-pwm.txt
 create mode 100644 drivers/led/led_pwm.c

diff --git a/MAINTAINERS b/MAINTAINERS
index fb171e0c68..2e8f8cdada 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -869,6 +869,12 @@ F: doc/README.kwbimage
 F: doc/kwboot.1
 F: tools/kwb*
 
+LED
+M: Ivan Vozvakhov 
+S: Supported
+F: doc/device-tree-bindings/leds/leds-pwm.txt
+F: drivers/led/led_pwm.c
+
 LOGGING
 M: Simon Glass 
 S: Maintained
diff --git a/doc/device-tree-bindings/leds/leds-pwm.txt 
b/doc/device-tree-bindings/leds/leds-pwm.txt
new file mode 100644
index 00..186e8a848f
--- /dev/null
+++ b/doc/device-tree-bindings/leds/leds-pwm.txt
@@ -0,0 +1,47 @@
+LEDs connected to PWM (Linux compatible)
+
+Required properties:
+- compatible : should be "pwm-leds".
+
+Each LED is represented as a sub-node of the pwm-leds device.  Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+- pwms :  (required) LED pwm channel, see "pwms property" in
+  doc/device-tree-bindings/pwm/pwm.txt
+- label :  (optional) LED label, see "label property" in
+  doc/device-tree-bindings/led/common.txt
+- max-brightness :  (optional, unsigned, default 255) Maximum brightness 
possible
+  for the LED
+- active-low :  (optional, boolean, default false) For PWMs where the LED is
+  wired to supply rather than ground
+- u-boot,default-brightness :  (optional, unsigned, default 0) Initial state
+  of pwm-leds
+
+Example:
+
+leds {
+compatible = "pwm-leds";
+status = "okay";
+
+blue {
+label = "led-blue";
+pwms = < 0 10 0>;
+max-brightness = <255>;
+u-boot,default-brightness = <127>;
+};
+
+green {
+label = "led-green";
+pwms = < 0 10 0>;
+max-brightness = <255>;
+u-boot,default-brightness = <127>;
+};
+
+red {
+label = "led-red";
+pwms = < 0 10 0>;
+max-brightness = <255>;
+u-boot,default-brightness = <127>;
+};
+}
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index cc87fbf395..48616e2f55 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -42,6 +42,12 @@ config LED_CORTINA
  This option enables support for LEDs connected to the Cortina
  Access CA SOCs.
 
+config LED_PWM
+   bool "LED PWM"
+   depends on LED && DM_PWM
+   help
+ Enable support for LEDs connected to PWM.
+ Linux compatible ofdata.
 
 config LED_BLINK
bool "Support LED blinking"
diff --git a/drivers/led/Makefile b/drivers/led/Makefile
index 8e3ae7f146..c31a59e1aa 100644
--- a/drivers/led/Makefile
+++ b/drivers/led/Makefile
@@ -7,5 +7,6 @@ obj-y += led-uclass.o
 obj-$(CONFIG_LED_BCM6328) += led_bcm6328.o
 obj-$(CONFIG_LED_BCM6358) += led_bcm6358.o
 obj-$(CONFIG_LED_BCM6858) += led_bcm6858.o
+obj-$(CONFIG_LED_PWM) += led_pwm.o
 obj-$(CONFIG_$(SPL_)LED_GPIO) += led_gpio.o
 obj-$(CONFIG_LED_CORTINA) += led_cortina.o
diff --git a/drivers/led/led_pwm.c b/drivers/led/led_pwm.c
new file mode 100644
index 00..4e50272258
--- /dev/null
+++ b/drivers/led/led_pwm.c
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 VK
+ * Author: Ivan Vozvakhov 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LEDS_PWM_DRIVER_NAME   "led_pwm"
+
+struct led_pwm_priv {
+   struct udevice *pwm;
+   uint period;/* period in ns */
+   uint duty;  /* duty cycle in ns */
+   uint channel;   /* pwm channel number */
+   bool active_low;/* pwm polarity */
+   bool enabled;
+};
+
+static int led_pwm_enable(struct udevice *dev)
+{
+   struct led_pwm_priv *priv = dev_get_priv(dev);
+   int ret;
+
+   ret = pwm_set_invert(priv->pwm, priv->channel, priv->active_low);
+   if (ret)
+   return ret;
+
+   ret = pwm_set_config(priv->pwm, priv->channel, priv->period, 
priv->duty);
+   if (ret)
+   return ret;
+
+   ret = pwm_set_enable(priv->pwm, priv->channel, true);
+   if (ret)
+   return ret;
+
+   priv->enabled = true;
+
+   return 0;
+}
+
+static int led_pwm_disable(struct udevice *dev)
+{
+   struct led_pwm_priv *priv = dev_get_priv(dev);
+   int ret;
+
+   ret = pwm_set_config(priv->pwm, priv->channel, priv->period, 0);
+   if (ret)
+   return ret;
+
+   ret =

Re: [PATCH v2 1/1] cmd: add serial console support for the cls command

2022-03-12 Thread Heinrich Schuchardt





On 3/12/22 06:02, Simon Glass wrote:

Hi Heinrich,

On Fri, 11 Mar 2022 at 00:06, Heinrich Schuchardt
 wrote:


On 2/11/22 21:29, Simon Glass wrote:

On Fri, 11 Feb 2022 at 10:11, Heinrich Schuchardt
 wrote:


Currently the cls command does not support the serial console

The screen can be cleared in the video uclass, the colored frame buffer
console, and the serial console by sending the same escape sequence.
This reduces the cls command to a single printf() statement on most
boards.

Signed-off-by: Heinrich Schuchardt 
---
v2:
  support cls with CONFIG_DM_VIDEO=y and CONFIG_VIDEO_ANSI=n
---
   cmd/cls.c | 8 ++--
   1 file changed, 6 insertions(+), 2 deletions(-)


Reviewed-by: Simon Glass 

(would be better with if() instead of #if)


This is not possible because you chose to give two functions with a
different number of parameters the same name (video_clear()).


Yes that is bad, but I sent a series to remove cfb_console:

https://patchwork.ozlabs.org/project/uboot/list/?series=282367


There still remains:

In lcd.h there is an #ifndef CONFIG_DM_VIDEO hiding the definition of 
lcd_clear().


Best regards

Heinrich



Regards,
Simon

[PATCH 1/1] doc: add libgnutls28-dev to build dependencies

2022-03-12 Thread Heinrich Schuchardt

mkeficapsule requires package libgnutls28-dev for building

Signed-off-by: Heinrich Schuchardt 
---
 doc/build/gcc.rst | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst
index b883cf73ee..470a7aa349 100644
--- a/doc/build/gcc.rst
+++ b/doc/build/gcc.rst
@@ -25,11 +25,12 @@ Depending on the build targets further packages maybe needed
 
 sudo apt-get install bc bison build-essential coccinelle \
   device-tree-compiler dfu-util efitools flex gdisk graphviz imagemagick \
-  liblz4-tool libguestfs-tools libncurses-dev libpython3-dev libsdl2-dev \
-  libssl-dev lz4 lzma lzma-alone openssl pkg-config python3 \
-  python3-coverage python3-pkg-resources python3-pycryptodome \
-  python3-pyelftools python3-pytest python3-sphinxcontrib.apidoc \
-  python3-sphinx-rtd-theme python3-virtualenv swig
+  liblz4-tool libgnutls28-dev libguestfs-tools libncurses-dev \
+  libpython3-dev libsdl2-dev libssl-dev lz4 lzma lzma-alone openssl \
+  pkg-config python3 python3-coverage python3-pkg-resources \
+  python3-pycryptodome python3-pyelftools python3-pytest \
+  python3-sphinxcontrib.apidoc python3-sphinx-rtd-theme python3-virtualenv 
\
+  swig
 
 SUSE based
 ~~
-- 
2.34.1

Re: [PATCH][RFC] image: fdt: Fix DT relocation handling with multiple DRAM banks with gap

2022-03-12 Thread Marek Vasut


On 3/12/22 06:02, Simon Glass wrote:

Hi Marek,

On Fri, 11 Mar 2022 at 19:41, Marek Vasut  wrote:


On 3/12/22 03:24, Simon Glass wrote:

Hi Marek,

On Wed, 21 Jul 2021 at 18:05, Marek Vasut  wrote:


The current implementation of boot_relocate_fdt() places DT at the
highest usable DRAM address, which is calculated as:
env_get_bootm_low() + env_get_bootm_mapsize()
which by default becomes gd->ram_base + gd->ram_size.

Systems like i.MX53 can have multiple DRAM banks with gap between them,
e.g. have DRAM at 0x7000-0x8fff and 0xb000-0xcfff , so
for them the calculated highest DRAM address is 0xafff, which is
exactly in the gap and thus not usable.

Fix this by iterating over all DRAM banks and tracking the remaining
amount of the total mapping size obtained from env_get_bootm_mapsize().
Limit the maximum LMB area size to each bank, to avoid using nonexistent
DRAM.

Signed-off-by: Marek Vasut 
Cc: Heinrich Schuchardt 
Cc: Simon Glass 
Cc: Tom Rini 
---
   common/image-fdt.c | 40 
   1 file changed, 36 insertions(+), 4 deletions(-)


Reviewed-by: Simon Glass 

Should we put this behind a Kconfig option to reduce code size?


Since this depends on DT content, we cannot predict what kind of DT will
be passed to U-Boot, so no, we cannot put this behind a Kconfig option.


Doesn't it only affect boards with disjoint memory?


Sure, it does trigger nasty unexpected failures on some systems. And you 
cannot really tell whether a board may or may not be populated with such 
a memory setup, because you cannot predict what will be in the DT.


Besides, there is far more code which correctly does handle multiple 
memory areas and it is also not ifdef'd out, so I don't see why we 
should special case this one. That would only lead to inconsistency and 
more people running into this kind of problem and wasting a lot of time 
trying to figure out a fix, and then arriving at some loadaddr 
workaround instead.

Re: [PATCH v3 1/6] rockchip: move ROCKCHIP_STIMER_BASE to Kconfig

2022-03-12 Thread Johan Jonker




On 3/12/22 09:51, Jagan Teki wrote:
> On Thu, Dec 30, 2021 at 10:18 PM Johan Jonker  wrote:
>>
>> Move ROCKCHIP_STIMER_BASE to Kconfig.
>>
>> Signed-off-by: Johan Jonker 
>> ---
>>
>> Changed V3:
>>   add ROCKCHIP_STIMER
>> ---
>>  arch/arm/mach-rockchip/Kconfig| 22 ++
>>  arch/arm/mach-rockchip/px30/Kconfig   |  3 +++
>>  arch/arm/mach-rockchip/rk3036/Kconfig |  3 +++
>>  arch/arm/mach-rockchip/rk3128/Kconfig |  3 +++
>>  arch/arm/mach-rockchip/rk322x/Kconfig |  3 +++
>>  arch/arm/mach-rockchip/rk3288/Kconfig |  3 +++
>>  arch/arm/mach-rockchip/rk3308/Kconfig | 10 ++
>>  arch/arm/mach-rockchip/rk3328/Kconfig |  3 +++
>>  arch/arm/mach-rockchip/rk3368/Kconfig |  3 +++
>>  arch/arm/mach-rockchip/rk3399/Kconfig |  3 +++
>>  arch/arm/mach-rockchip/rk3568/Kconfig |  3 +++
>>  include/configs/px30_common.h |  1 -
>>  include/configs/rk3036_common.h   |  1 -
>>  include/configs/rk3128_common.h   |  1 -
>>  include/configs/rk322x_common.h   |  1 -
>>  include/configs/rk3288_common.h   |  1 -
>>  include/configs/rk3308_common.h   |  1 -
>>  include/configs/rk3328_common.h   |  1 -
>>  include/configs/rk3368_common.h   |  1 -
>>  include/configs/rk3399_common.h   |  1 -
>>  include/configs/rk3568_common.h   |  1 -
>>  21 files changed, 55 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
>> index da6871eb..7a624c64 100644
>> --- a/arch/arm/mach-rockchip/Kconfig
>> +++ b/arch/arm/mach-rockchip/Kconfig
>> @@ -343,6 +343,28 @@ config ROCKCHIP_BOOT_MODE_REG
>>   The Soc will enter to different boot mode(defined in 
>> asm/arch-rockchip/boot_mode.h)
>>   according to the value from this register.
>>
>> +config ROCKCHIP_STIMER
>> +   bool "Rockchip STIMER support"
>> +   default y
>> +   depends on (ROCKCHIP_PX30||   \
>> +   ROCKCHIP_RK3036|| \
>> +   ROCKCHIP_RK3128|| \
>> +   ROCKCHIP_RK322X|| \
>> +   ROCKCHIP_RK3288|| \
>> +   ROCKCHIP_RK3308|| \
>> +   ROCKCHIP_RK3328|| \
>> +   ROCKCHIP_RK3368|| \
>> +   ROCKCHIP_RK3399|| \
>> +   ROCKCHIP_RK3568)
> 

> What if we select !(SOC-Which-don't-support-stimer). I believe the
> condition check here is much simpler.

The condition would be simpler that's correct, but this patch is made
with rk3066 in mind and there's no ROCKCHIP_RK3066 available yet.
The right approach is to only include SoC's that have a specific
property/functionality linked to there specific config tag.
U-boot should be generic. And we should not have to fix all dependencies
all over the place when a SoC doesn't have something.

Please advise how to support other SoC's like rk3066.

Johan

> 
> Jagan.

Re: [PATCH v2 2/2] mmc: dw_mmc: support transfer mode auto detection

2022-03-12 Thread Johan Jonker




On 3/12/22 10:23, Jagan Teki wrote:
> On Wed, Feb 23, 2022 at 6:37 PM Johan Jonker  wrote:
>>
>> From: Paweł Jarosz 
>>
>> dw_mmc supports two transfer modes in u-boot: IDMA and FIFO.
>> This patch adds auto detection of transfer mode and
>> eliminates the need to set this in host config struct.
>> Allow handling for a u-boot,spl-fifo-mode host property in the
>> logic to not put the MMC controllers into FIFO mode for all time.
> 

> Does it mean fifo-mode property is not useful in SPI and U-Boot
> proper? If yes better drop that change as part of this patch.

This is about setting the fifo-mode for rk3066/rk3188 without DT as
these early models don't seem to have IDMA.

Handling of the fifo_mode variable is still needed for the Rockchip
exception that needs to be included in the logic.

rockchip: dwmmc: add handling for u-boot, spl-fifo-mode
https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/commit/c8dd0e42d709c9734f313c547d0707e27ca0de51

We could remove normal fifo-mode parsing, but as this is a generic file
for multiple SoC families I'm a little bit reluctant to change that for
other drivers then Rockchip.

Otherwise patch V1 does the job without changing dw_mmc.c

Please advise what direction we should go or what changes should be made.

Kind regards,

Johan Jonker


>>
>> Signed-off-by: Paweł Jarosz 
>> Signed-off-by: Johan Jonker 
>> ---
>>
>> Changed V2:
>>   use bitfield_extract
>>   remove use_dma variable
>>   include fifo_mode from host in logic
>> ---
>>  drivers/mmc/dw_mmc.c | 6 ++
>>  include/dwmmc.h  | 5 +
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
>> index a949dad5..7e2cd5ed 100644
>> --- a/drivers/mmc/dw_mmc.c
>> +++ b/drivers/mmc/dw_mmc.c
>> @@ -536,6 +536,12 @@ static int dwmci_init(struct mmc *mmc)
>> return -EIO;
>> }
>>
>> +   if (!host->fifo_mode &&
>> +   SDMMC_GET_TRANS_MODE(dwmci_readl(host, DWMCI_HCON)) == 
>> DMA_INTERFACE_IDMA)
>> +   host->fifo_mode = 0;
>> +   else
>> +   host->fifo_mode = 1;
> 
> fifo_mode is bool so use true/false.
> 
> Jagan.

Re: [PATCH v3 24/31] bootstd: Add an implementation of EFI bootmgr

2022-03-12 Thread Ilias Apalodimas

Hi Simon

On Sun, 6 Mar 2022 at 05:08, Simon Glass  wrote:

> Hi Heinrich,
>
> On Wed, 19 Jan 2022 at 04:47, Heinrich Schuchardt 
> wrote:
> >
> > On 1/19/22 02:43, Simon Glass wrote:
> > > Add a bootmeth driver which handles EFI boot manager, using EFI_LOADER.
> > >
> > > In effect, this provides the same functionality as the 'bootefi
> bootmgr'
> > > command and shares the same code. But the interface into it is via a
> > > bootmeth, so it does not require any special scripts, etc.
> > >
> > > For now this requires the 'bootefi' command be enabled. Future work may
> > > tidy this up so that it can be used without CONFIG_CMDLINE being
> enabled.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > > Changes in v3:
> > > - Add a log category
> > >
> > >   boot/Makefile   |  3 ++
> > >   boot/bootmeth_efi_mgr.c | 86
> +
> > >   2 files changed, 89 insertions(+)
> > >   create mode 100644 boot/bootmeth_efi_mgr.c
> > >
> > > diff --git a/boot/Makefile b/boot/Makefile
> > > index 795665f7ce5..38b10d81f0d 100644
> > > --- a/boot/Makefile
> > > +++ b/boot/Makefile
> > > @@ -31,6 +31,9 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootstd-uclass.o
> > >   obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_DISTRO) += bootmeth_distro.o
> > >   obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_DISTRO_PXE) += bootmeth_pxe.o
> > >   obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EFILOADER) += bootmeth_efi.o
> > > +ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL
> > > +obj-$(CONFIG_$(SPL_TPL_)CMD_BOOTEFI_BOOTMGR) += bootmeth_efi_mgr.o
> > > +endif
> > >
> > >   obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
> > >   obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += fdt_region.o
> > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> > > new file mode 100644
> > > index 000..a6914466db7
> > > --- /dev/null
> > > +++ b/boot/bootmeth_efi_mgr.c
> > > @@ -0,0 +1,86 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Bootmethod for EFI boot manager
> > > + *
> > > + * Copyright 2021 Google LLC
> > > + * Written by Simon Glass 
> > > + */
> > > +
> > > +#define LOG_CATEGORY UCLASS_BOOTSTD
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +static int efi_mgr_check(struct udevice *dev, struct bootflow_iter
> *iter)
> > > +{
> > > + int ret;
> > > +
> > > + /* Must be an bootstd device */
> > > + ret = bootflow_iter_uses_system(iter);
> > > + if (ret)
> > > + return log_msg_ret("net", ret);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow
> *bflow)
> > > +{
> > > + /*
> > > +  * Just assume there is something to boot since we don't have
> any way
> > > +  * of knowing in advance
> > > +  */
> > > + bflow->state = BOOTFLOWST_READY;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int efi_mgr_read_file(struct udevice *dev, struct bootflow
> *bflow,
> > > + const char *file_path, ulong addr, ulong
> *sizep)
> > > +{
> > > + /* Files are loaded by the 'bootefi bootmgr' command */
> > > +
> > > + return -ENOSYS;
> > > +}
> > > +
> > > +static int efi_mgr_boot(struct udevice *dev, struct bootflow *bflow)
> > > +{
> > > + int ret;
> > > +
> > > + /* Booting is handled by the 'bootefi bootmgr' command */
> > > + ret = run_command("bootefi bootmgr", 0);
> >
> > You are missing to provide the device tree.
>
> OK well I can deal with that when I get to it, I suppose. Which distro
> can I try with?
>

Any recent distro would work.  If you try to run an installer keep in mind
setting up grub will fail (since runtime variable support isn't yet
supported).  You can find more info on installing fedora here[1] just skip
the security and encryption parts

[1] https://www.linaro.org/blog/securing-a-device-with-trusted-substrate/

Cheers
/Ilias

>
> Regards,
> Simon
>

Re: [PATCH v2 2/2] mmc: dw_mmc: support transfer mode auto detection

On Wed, Feb 23, 2022 at 6:37 PM Johan Jonker  wrote:
>
> From: Paweł Jarosz 
>
> dw_mmc supports two transfer modes in u-boot: IDMA and FIFO.
> This patch adds auto detection of transfer mode and
> eliminates the need to set this in host config struct.
> Allow handling for a u-boot,spl-fifo-mode host property in the
> logic to not put the MMC controllers into FIFO mode for all time.

Does it mean fifo-mode property is not useful in SPI and U-Boot
proper? If yes better drop that change as part of this patch.
>
> Signed-off-by: Paweł Jarosz 
> Signed-off-by: Johan Jonker 
> ---
>
> Changed V2:
>   use bitfield_extract
>   remove use_dma variable
>   include fifo_mode from host in logic
> ---
>  drivers/mmc/dw_mmc.c | 6 ++
>  include/dwmmc.h  | 5 +
>  2 files changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index a949dad5..7e2cd5ed 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -536,6 +536,12 @@ static int dwmci_init(struct mmc *mmc)
> return -EIO;
> }
>
> +   if (!host->fifo_mode &&
> +   SDMMC_GET_TRANS_MODE(dwmci_readl(host, DWMCI_HCON)) == 
> DMA_INTERFACE_IDMA)
> +   host->fifo_mode = 0;
> +   else
> +   host->fifo_mode = 1;

fifo_mode is bool so use true/false.

Jagan.

Re: [PATCH v1 2/2] rockchip: mmc: rockchip_dw_mmc: add rk3066/rk3188 support

2022-03-12 Thread Johan Jonker

Hi Jagan,

On 3/12/22 10:02, Jagan Teki wrote:
> On Sat, Jan 8, 2022 at 12:04 AM Johan Jonker  wrote:
>>
>> The Rockchip SoCs rk3066/rk3188 have mmc DT nodes
>> with as compatible string "rockchip,rk2928-dw-mshc".
>> Add support to the existing driver with help of
>> a DM_DRIVER_ALIAS.
>>
>> This type needs a permanent enabled fifo.
>> The other Rockchip SoCs not always have the property
>> "fifo-mode" in the TPL/SPL DT nodes, so dtplat structures
> 

> No, it is not true. we have property for spl/tpl to enable that.
> "u-boot,spl-fifo-mode"

This is not usable for rk3066/rk3188 and OF_PLATDATA in combination with
c code as there's no guaranty that other models have this property in
the dtplat structure.

It's about finding a solution for disabling fifo-mode and OF_PLATDATA.

There's also a V2 with a more generic approach. Could you have a look at
it as well. Whatever which method is preferred.

#if CONFIG_IS_ENABLED(OF_PLATDATA)
struct dtd_rockchip_rk3288_dw_mshc dtplat;
#endif

Johan

Re: [PATCH] rockchip: ram: sdram_rk3x88: replace comma by semicolon

On Wed, Jan 12, 2022 at 10:02 PM Johan Jonker  wrote:
>
> A comma at the end of a line gives sometimes strange
> effects in combination with some code formatters,
> so replace a comma by a semicolon in the sdram_rk3188.c
> and sdram_rk3288.c files.
>
> Signed-off-by: Johan Jonker 
> ---

Reviewed-by: Jagan Teki

Re: [PATCH v1 2/2] rockchip: mmc: rockchip_dw_mmc: add rk3066/rk3188 support

On Sat, Jan 8, 2022 at 12:04 AM Johan Jonker  wrote:
>
> The Rockchip SoCs rk3066/rk3188 have mmc DT nodes
> with as compatible string "rockchip,rk2928-dw-mshc".
> Add support to the existing driver with help of
> a DM_DRIVER_ALIAS.
>
> This type needs a permanent enabled fifo.
> The other Rockchip SoCs not always have the property
> "fifo-mode" in the TPL/SPL DT nodes, so dtplat structures

No, it is not true. we have property for spl/tpl to enable that.
"u-boot,spl-fifo-mode"

Re: [PATCH v1 3/3] rockchip: serial: Kconfig: add select SYS_NS16550 to config ROCKCHIP_SERIAL

On Sun, Jan 9, 2022 at 8:56 PM Johan Jonker  wrote:
>
> The Rockchip serial driver depends on an enabled NS16550 driver,
> so add select SYS_NS16550 to config ROCKCHIP_SERIAL.
>
> Signed-off-by: Johan Jonker 
> ---
>  drivers/serial/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index 6c8fdda9..054bd21e 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -737,6 +737,7 @@ config PL01X_SERIAL
>  config ROCKCHIP_SERIAL
> bool "Rockchip on-chip UART support"
> depends on DM_SERIAL && SPL_OF_PLATDATA
> +   select SYS_NS16550

Other places of rockchip code are implying and selecting the
SYS_NS16550, so removing those would be part of this global select.

Jagan.

Re: [PATCH v3 1/6] rockchip: move ROCKCHIP_STIMER_BASE to Kconfig

On Thu, Dec 30, 2021 at 10:18 PM Johan Jonker  wrote:
>
> Move ROCKCHIP_STIMER_BASE to Kconfig.
>
> Signed-off-by: Johan Jonker 
> ---
>
> Changed V3:
>   add ROCKCHIP_STIMER
> ---
>  arch/arm/mach-rockchip/Kconfig| 22 ++
>  arch/arm/mach-rockchip/px30/Kconfig   |  3 +++
>  arch/arm/mach-rockchip/rk3036/Kconfig |  3 +++
>  arch/arm/mach-rockchip/rk3128/Kconfig |  3 +++
>  arch/arm/mach-rockchip/rk322x/Kconfig |  3 +++
>  arch/arm/mach-rockchip/rk3288/Kconfig |  3 +++
>  arch/arm/mach-rockchip/rk3308/Kconfig | 10 ++
>  arch/arm/mach-rockchip/rk3328/Kconfig |  3 +++
>  arch/arm/mach-rockchip/rk3368/Kconfig |  3 +++
>  arch/arm/mach-rockchip/rk3399/Kconfig |  3 +++
>  arch/arm/mach-rockchip/rk3568/Kconfig |  3 +++
>  include/configs/px30_common.h |  1 -
>  include/configs/rk3036_common.h   |  1 -
>  include/configs/rk3128_common.h   |  1 -
>  include/configs/rk322x_common.h   |  1 -
>  include/configs/rk3288_common.h   |  1 -
>  include/configs/rk3308_common.h   |  1 -
>  include/configs/rk3328_common.h   |  1 -
>  include/configs/rk3368_common.h   |  1 -
>  include/configs/rk3399_common.h   |  1 -
>  include/configs/rk3568_common.h   |  1 -
>  21 files changed, 55 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index da6871eb..7a624c64 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -343,6 +343,28 @@ config ROCKCHIP_BOOT_MODE_REG
>   The Soc will enter to different boot mode(defined in 
> asm/arch-rockchip/boot_mode.h)
>   according to the value from this register.
>
> +config ROCKCHIP_STIMER
> +   bool "Rockchip STIMER support"
> +   default y
> +   depends on (ROCKCHIP_PX30||   \
> +   ROCKCHIP_RK3036|| \
> +   ROCKCHIP_RK3128|| \
> +   ROCKCHIP_RK322X|| \
> +   ROCKCHIP_RK3288|| \
> +   ROCKCHIP_RK3308|| \
> +   ROCKCHIP_RK3328|| \
> +   ROCKCHIP_RK3368|| \
> +   ROCKCHIP_RK3399|| \
> +   ROCKCHIP_RK3568)

What if we select !(SOC-Which-don't-support-stimer). I believe the
condition check here is much simpler.

Jagan.

Pull request: u-boot-spi/master