[PATCH v3] rockchip: configs: sandbox: enable rkmtd command

[Johan Jonker]

Enable rkmtd command for testing with sandbox_defconfig
and sandbox64_defconfig.

Signed-off-by: Johan Jonker 
---
 configs/sandbox64_defconfig | 1 +
 configs/sandbox_defconfig   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 1a033b22018b..1a01f51a0b75 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -58,6 +58,7 @@ CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_TEMPERATURE=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_RKMTD=y
 CONFIG_CMD_WDT=y
 CONFIG_CMD_WRITE=y
 CONFIG_CMD_CAT=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 01830c7bd255..cc54e6dec5af 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -84,6 +84,7 @@ CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_TEMPERATURE=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_RKMTD=y
 CONFIG_CMD_WDT=y
 CONFIG_CMD_WRITE=y
 CONFIG_CMD_AXI=y
--
2.39.2

Re: [PATCH 4/4] test: dm: add SCMI power domain protocol test

[Tom Rini]

On Tue, Sep 26, 2023 at 04:00:43PM +0900, AKASHI Takahiro wrote:

> This ut has tests for the SCMI power domain protocol as well as DM
> interfaces for power domain devices.
> 
> Signed-off-by: AKASHI Takahiro 
> Reviewed-by: Simon Glass 
> ---
>  test/dm/scmi.c | 107 -
>  1 file changed, 106 insertions(+), 1 deletion(-)

With v6 of the required series there is no scmi command, so, how do we
test this support now?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/6] tools: mkeficapsule: Add support to print capsule headers

[Simon Glass]

Add support to dump the contents of capsule headers. This is useful as
a debug feature for checking the contents of the capsule headers, and
can also be used in capsule verification.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
---
Changes since V1:
* Get rid of the superfluous hdr_size variable in the
  dump_fmp_payload_header() function

 tools/eficapsule.h   |   2 +
 tools/mkeficapsule.c | 227 ++-
 2 files changed, 228 insertions(+), 1 deletion(-)

Applied to u-boot-dm, thanks!

Re: [PATCH 1/3] arm64: Use FEAT_HAFDBS to track dirty pages when available

[Marc Zyngier]

On 2023-10-13 03:40, Chris Packham wrote:

Hi Marc, Paul,

On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu)
 wrote:


From: Marc Zyngier 

Some recent arm64 cores have a facility that allows the page
table walker to track the dirty state of a page. This makes it
really efficient to perform CMOs by VA as we only need to look
at dirty pages.

Signed-off-by: Marc Zyngier 
[ Paul: pick from the Android tree. Rebase to the upstream ]
Signed-off-by: Ying-Chun Liu (PaulLiu) 
Cc: Tom Rini 
Link: 
https://android.googlesource.com/platform/external/u-boot/+/3c433724e6f830a6b2edd5ec3d4a504794887263


I think this may have caused a regression for the Marvell AC5X
board(s). I found that v2023.07 locked up at boot but v2023.01 was
fine. The lockup seemed to be in the 'Net:' init probably just as the
mvneta driver was being initialised.

A git bisect led me to this change although for this specific change
instead of the lockup I get a crash so maybe I'm actually hitting a
different issue.

Any thoughts as to why this may have caused problems?


Not really. What CPUs does this platform have? What is the offending
driver doing to trigger the issue? Can you provide some level of
tracing?

M.
--
Jazz is not dead. It just smells funny...

Re: [PATCH v2 4/6] binman: capsule: Use dumped capsule header contents for verification

[Simon Glass]

On Tue, 10 Oct 2023 at 02:12, Sughosh Ganu  wrote:
>
> The various fields of a generated capsule are currently verified
> through hard-coded offsets. Use the dump-capsule feature for dumping
> the capsule header contents and use those for capsule verification.
>
> Signed-off-by: Sughosh Ganu 
> ---
> Changes since V1:
> * Move the get_binman_test_guid() function outside the
>   Entry_efi_capsule class so that it can be called from outside the
>   module.
> * Use lowercase characters in the GUID values
> * Add comments for the _GetCapsuleHeaders() function.
> * Use a simple dict in _GetCapsuleHeaders() for storing the capsule
>   header values dumped by the mkeficapsule tool.
>
>  tools/binman/etype/efi_capsule.py |  24 +--
>  tools/binman/ftest.py | 105 ++
>  2 files changed, 82 insertions(+), 47 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 4/5] pinctrl: single: fix compile warnings with PHYS_64BIT on 32bit

[Simon Glass]

On Wed, 27 Sept 2023 at 06:34, Matthias Schiffer
 wrote:
>
> pinctrl-single uses fdt_addr_t and phys_addr_t inconsistently, but both
> are wrong to be passed to readb() etc., which expect a pointer or
> pointer-sized integer. Change the driver to use
> dev_read_addr_size_index_ptr(), so we consistently deal with void*
> (except for the sandbox case and single_get_pin_muxing()).
>
> Signed-off-by: Matthias Schiffer 
> ---
>
> Tested on x86 sandbox and TI AM62x. No new unit test failures in
> sandbox.
>
>  drivers/pinctrl/pinctrl-single.c | 33 +---
>  1 file changed, 18 insertions(+), 15 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH v2 2/6] doc: capsule: Add documentation for the capsule dump feature

[Simon Glass]

Add documentation to explain the printing of the capsule headers
through the mkeficapsule tool.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Simon Glass 
---
Changes since V1: None

 doc/develop/uefi/uefi.rst | 17 +
 1 file changed, 17 insertions(+)

Applied to u-boot-dm, thanks!

Re: [PATCH] binman: bintool: Change make target arg type from string to list

[Simon Glass]

On Wed, 4 Oct 2023 at 02:56,  wrote:
>
> From: Lukas Funke 
>
> The argument type of `build_from_git` was changed from string to list
> in d71e7116997f14097735f04cc7847f0a68dbc485.
>
> This commit adapts the argument type of all bintools using this
> function.
>
> Signed-off-by: Lukas Funke 
>
> ---
>
>  tools/binman/btool/bootgen.py  | 2 +-
>  tools/binman/btool/fiptool.py  | 2 +-
>  tools/binman/btool/futility.py | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 
Tested-by: Simon Glass 

Thank you.

Can you please resolve the test-coverage issue, too? It is the one
line in the whole of binman with no coverage. If it is not needed, we
can delete the line, perhaps?

tools/binman/etype/xilinx_bootgen.py   72  199%

The offending line is 216:

   data = tools.read_file(bootbin_fname)

Regards,
Simon

Applied to u-boot-dm, thanks!

Re: [PATCH 1/1] sandbox: fix spl_board_init

[Simon Glass]

On Mon, 2 Oct 2023 at 19:00, Heinrich Schuchardt
 wrote:
>
> sandbox_spl_defconfig with CONFIG_SPL_UNIT_TEST=n fails to build.
>
> in function `spl_board_init':
> arch/sandbox/cpu/spl.c:134:(.text.spl_board_init+0x4a):
> undefined reference to `ut_run_list'
>
> Add the missing configuration check.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/sandbox/cpu/spl.c | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 1/5] core: fix doc comments of dev_read_addr*() and related functions

[Simon Glass]

On Wed, 27 Sept 2023 at 07:34, Matthias Schiffer
 wrote:
>
> - The dev_read_addr_name*() family of functions has no "index" argument,
>   doc comments should refer to "name"
> - Specify the error return for several devfdt_get_addr*() functions
>
> Signed-off-by: Matthias Schiffer 
> ---
>  include/dm/fdtaddr.h | 12 ++--
>  include/dm/read.h|  6 +++---
>  2 files changed, 9 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 3/5] core: introduce dev_read_addr_name[_size]_ptr() functions

[Simon Glass]

On Wed, 27 Sept 2023 at 06:34, Matthias Schiffer
 wrote:
>
> Same as dev_read_addr_name[_size](), but returns a pointer, cast
> through map_sysmem().
>
> Signed-off-by: Matthias Schiffer 
> ---
>  drivers/core/fdtaddr.c | 21 +
>  drivers/core/read.c| 21 +
>  include/dm/fdtaddr.h   | 31 +++
>  include/dm/read.h  | 41 +
>  4 files changed, 114 insertions(+)
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH v2 6/6] binman: capsule: Add support for generating EFI empty capsules

[Simon Glass]

On Tue, 10 Oct 2023 at 02:12, Sughosh Ganu  wrote:
>
> Add support in binman for generating EFI empty capsules. These
> capsules are used in the FWU A/B update feature. Also add test cases
> in binman for the corresponding code coverage.
>
> Signed-off-by: Sughosh Ganu 
> ---
> Changes since V1:
> * Instead of using two separate boolean values, use a 'capsule-type'
>   property for indicating generation of an accept/revert capsule.
> * Make corresponding changes in the sanity checks, documentation and
>   tests based on the above change.
> * Use lower case characters for GUIDs.
> * Call get_binman_test_guid() from the efi_capsule entry module.
> * Add the documentation entry for the empty capsules in entries.rst.
> * Remove the #[address,size]-cells properties from the test dts' for
>   empty capsules.
>
>  tools/binman/entries.rst  | 44 ++
>  tools/binman/etype/efi_empty_capsule.py   | 86 +++
>  tools/binman/ftest.py | 57 
>  tools/binman/test/319_capsule_accept.dts  | 13 +++
>  tools/binman/test/320_capsule_revert.dts  | 11 +++
>  .../test/321_capsule_accept_missing_guid.dts  | 11 +++
>  .../test/322_empty_capsule_type_missing.dts   | 12 +++
>  .../323_capsule_accept_revert_missing.dts | 13 +++
>  8 files changed, 247 insertions(+)
>  create mode 100644 tools/binman/etype/efi_empty_capsule.py
>  create mode 100644 tools/binman/test/319_capsule_accept.dts
>  create mode 100644 tools/binman/test/320_capsule_revert.dts
>  create mode 100644 tools/binman/test/321_capsule_accept_missing_guid.dts
>  create mode 100644 tools/binman/test/322_empty_capsule_type_missing.dts
>  create mode 100644 tools/binman/test/323_capsule_accept_revert_missing.dts
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 5/5] treewide: use dev_read_addr_*_ptr() where appropriate

[Simon Glass]

On Wed, 27 Sept 2023 at 07:34, Matthias Schiffer
 wrote:
>
> A follow-up to commit 842fb5de424e
> ("drivers: use devfdt_get_addr_size_index_ptr when cast to pointer")
> and commit 320a1938b6f7
> ("drivers: use devfdt_get_addr_index_ptr when cast to pointer").
>
> In addition to using the *_ptr variants of these functions where the
> address is cast to a pointer, this also changes devfdt_get_addr_*() to
> dev_read_addr_*() in a few places. Some variable and field types are
> changed from fdt_addr_t or phys_addr_t to void* where the cast was
> happening later.
>
> This patch fixes a number of compile warnings when building a 32bit
> U-Boot with CONFIG_PHYS_64BIT=y. In some places, it also fixes error
> handling where the return value of dev_read_addr() etc. was checked for
> NULL instead of FDT_ADDR_T_NONE.
>
> Signed-off-by: Matthias Schiffer 
> ---
>
> This seems to work correctly (tested on x86 sandbox and TI AM62x; I have
> not tested the Tegra, Sun4i and BCM drivers), but I have two questions:
>
> It is not entirely clear to me what the difference between
> dev_read_addr_ptr*() and dev_remap_addr*() etc. is, but some drivers mix
> both. Should dev_remap_addr*() be used for __iomem? Is __iomem used
> consistently in U-Boot at all?

Perhaps there is no difference in U-Boot due to virtual and physical
addresses being the same mostly?

>
> Furthermore, can devfdt_get_*() be replaced with dev_read_*()
> unconditionally? Is there any reason why devfdt_get_*() hasn't been
> dropped entirely in a treewide search-and-replace?

Yes you can replace it...dev_read calls the devfdt interface if !OF_LIVE

>
> The k3-sec-proxy change goes on top of my other patch "mailbox:
> k3-sec-proxy: fix error handling for missing scfg in FDT" I submitted
> yesterday.
>
>
>  arch/arm/mach-k3/sysfw-loader.c   | 16 
>  drivers/dma/ti/k3-udma.c  |  5 ++---
>  drivers/gpio/tegra186_gpio.c  |  4 ++--
>  drivers/mailbox/k3-sec-proxy.c| 18 +-
>  drivers/phy/allwinner/phy-sun4i-usb.c | 12 ++--
>  drivers/phy/phy-bcm-sr-pcie.c |  4 ++--
>  drivers/ram/k3-am654-ddrss.c  | 20 ++--
>  drivers/ram/k3-ddrss/k3-ddrss.c   | 23 ++-
>  drivers/soc/ti/k3-navss-ringacc.c | 12 ++--
>  9 files changed, 55 insertions(+), 59 deletions(-)
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Please pull u-boot-dm

[Simon Glass]

Hi Tom,


https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/18115

https://dev.azure.com/simon0972/u-boot/_build/results?buildId=53=results


The following changes since commit d5d24e2e0a3f54175e458d89acd626da939e1130:

  Merge tag 'efi-2024-01-rc1' of
https://source.denx.de/u-boot/custodians/u-boot-efi (2023-10-13
11:08:10 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git tags/dm-pull-13oct23

for you to fetch changes up to 74aae507bc4d5726308c191d3191d9cd624ba0d2:

  binman: capsule: Add support for generating EFI empty capsules
(2023-10-13 14:01:42 -0600)


improvements with dev_read_addr_..._ptr()
scan all entries in multi-device boot_targets
EFI empty-capsule support


Heinrich Schuchardt (1):
  sandbox: fix spl_board_init

Lukas Funke (1):
  binman: bintool: Change make target arg type from string to list

Matthias Schiffer (5):
  core: fix doc comments of dev_read_addr*() and related functions
  core: return FDT_ADDR_T_NONE from devfdt_get_addr_[size_]name() on errors
  core: introduce dev_read_addr_name[_size]_ptr() functions
  pinctrl: single: fix compile warnings with PHYS_64BIT on 32bit
  treewide: use dev_read_addr_*_ptr() where appropriate

Simon Glass (1):
  bootstd: Scan all bootdevs in a boot_targets entry

Sughosh Ganu (6):
  tools: mkeficapsule: Add support to print capsule headers
  doc: capsule: Add documentation for the capsule dump feature
  binman: capsule: Remove superfluous [address, size]-cells properties
  binman: capsule: Use dumped capsule header contents for verification
  btool: mkeficapsule: Add support for EFI empty capsule generation
  binman: capsule: Add support for generating EFI empty capsules

 arch/arm/mach-k3/sysfw-loader.c |  16 +--
 arch/sandbox/cpu/spl.c  |   3 +
 boot/bootdev-uclass.c   |   3 +-
 boot/bootflow.c |  21 +++-
 doc/develop/uefi/uefi.rst   |  17 +++
 drivers/core/fdtaddr.c  |  25 -
 drivers/core/read.c |  21 
 drivers/dma/ti/k3-udma.c|   5 +-
 drivers/gpio/tegra186_gpio.c|   4 +-
 drivers/mailbox/k3-sec-proxy.c  |  18 +--
 drivers/phy/allwinner/phy-sun4i-usb.c   |  12 +-
 drivers/phy/phy-bcm-sr-pcie.c   |   4 +-
 drivers/pinctrl/pinctrl-single.c|  34 +++---
 drivers/ram/k3-am654-ddrss.c|  20 ++--
 drivers/ram/k3-ddrss/k3-ddrss.c |  23 ++--
 drivers/soc/ti/k3-navss-ringacc.c   |  12 +-
 include/dm/fdtaddr.h|  47 ++--
 include/dm/read.h   |  47 +++-
 test/boot/bootdev.c |  10 ++
 tools/binman/btool/bootgen.py   |   2 +-
 tools/binman/btool/fiptool.py   |   2 +-
 tools/binman/btool/futility.py  |   2 +-
 tools/binman/btool/mkeficapsule.py  |  26 +
 tools/binman/entries.rst|  44 
 tools/binman/etype/efi_capsule.py   |  24 +++-
 tools/binman/etype/efi_empty_capsule.py |  86 +++
 tools/binman/ftest.py   | 160
---
 tools/binman/test/311_capsule.dts   |   3 -
 tools/binman/test/312_capsule_signed.dts|   3 -
 tools/binman/test/313_capsule_version.dts   |   3 -
 tools/binman/test/314_capsule_signed_ver.dts|   3 -
 tools/binman/test/315_capsule_oemflags.dts  |   3 -
 tools/binman/test/316_capsule_missing_key.dts   |   3 -
 tools/binman/test/317_capsule_missing_index.dts |   3 -
 tools/binman/test/318_capsule_missing_guid.dts  |   3 -
 tools/binman/test/319_capsule_accept.dts|  13 +++
 tools/binman/test/320_capsule_revert.dts|  11 ++
 tools/binman/test/321_capsule_accept_missing_guid.dts   |  11 ++
 tools/binman/test/322_empty_capsule_type_missing.dts|  12 ++
 tools/binman/test/323_capsule_accept_revert_missing.dts |  13 +++
 tools/eficapsule.h  |   2 +
 tools/mkeficapsule.c| 227
+-
 42 files changed, 837 insertions(+), 164 deletions(-)
 create mode 100644 tools/binman/etype/efi_empty_capsule.py
 create mode 100644 tools/binman/test/319_capsule_accept.dts
 create mode 100644 

Re: [PATCH] bootstd: Scan all bootdevs in a boot_targets entry

[Simon Glass]

Hi,

On Sat, 23 Sept 2023 at 13:50, Simon Glass  wrote:
>
> When the boot_targets environment variable is used with the distro-boot
> scripts, each device is included individually. For example, if there
> are three mmc devices, then we will have something like:
>
>boot_targets="mmc0 mmc1 mmc2"
>
> In contrast, standard boot supports specifying just the uclass, i.e.:
>
>boot_targets="mmc"
>
> The intention is that this should scan all MMC devices, but in fact it
> currently only scans the first.
>
> Update the logic to handle this case, without required BOOTSTD_FULL to
> be enabled.
>
> I believe at least three people reported this, but I found two.
>
> Signed-off-by: Simon Glass 
> Reported-by: Date Huang 
> Reported-by: Vincent Stehlé 
> ---
>
>  boot/bootdev-uclass.c |  3 ++-
>  boot/bootflow.c   | 21 +++--
>  test/boot/bootdev.c   | 10 ++
>  3 files changed, 31 insertions(+), 3 deletions(-)

I'm going to pick this one up. There are no formal tested-by tags but
there are two reports on the mailing list that it fixes the problem.
[1] [2]

Regards,
Simon

[1] https://lore.kernel.org/all/ZSMlNWJ9f7HkoaNg@Dell-Inspiron-15/
[2] 
https://lore.kernel.org/all/vi1pr08mb2847b5efd8f36e5a4d41febd83...@vi1pr08mb2847.eurprd08.prod.outlook.com/

Applied to u-boot-dm, thanks!

Re: [PATCH v2 3/6] binman: capsule: Remove superfluous [address,size]-cells properties

[Simon Glass]

On Tue, 10 Oct 2023 at 02:12, Sughosh Ganu  wrote:
>
> The #address-cells and #size-cells are not needed for running the
> capsule generation binman tests. Remove the superfluous properties.
>
> Signed-off-by: Sughosh Ganu 
> ---
> Changes since V1:
> * New patch based on review comment from Simon.
>
>  tools/binman/test/311_capsule.dts   | 3 ---
>  tools/binman/test/312_capsule_signed.dts| 3 ---
>  tools/binman/test/313_capsule_version.dts   | 3 ---
>  tools/binman/test/314_capsule_signed_ver.dts| 3 ---
>  tools/binman/test/315_capsule_oemflags.dts  | 3 ---
>  tools/binman/test/316_capsule_missing_key.dts   | 3 ---
>  tools/binman/test/317_capsule_missing_index.dts | 3 ---
>  tools/binman/test/318_capsule_missing_guid.dts  | 3 ---
>  8 files changed, 24 deletions(-)
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 2/5] core: return FDT_ADDR_T_NONE from devfdt_get_addr_[size_]name() on errors

[Simon Glass]

On Wed, 27 Sept 2023 at 07:34, Matthias Schiffer
 wrote:
>
> Checking for the error cast to fdt_addr_t is rather awkward - IS_ERR()
> can be used, but it's not really made to be used on fdt_addr_t, which
> may not even be the same size as a native pointer.
>
> Most places in U-Boot only check for FDT_ADDR_T_NONE; let's adjust the
> error return to match the expectation.
>
> Signed-off-by: Matthias Schiffer 
> ---
>  drivers/core/fdtaddr.c | 4 ++--
>  include/dm/fdtaddr.h   | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH v2 5/6] btool: mkeficapsule: Add support for EFI empty capsule generation

[Simon Glass]

On Tue, 10 Oct 2023 at 02:12, Sughosh Ganu  wrote:
>
> Add a method to the mkeficapsule bintool to generate empty
> capsules. These are capsules needed for the FWU A/B update feature.
>
> Signed-off-by: Sughosh Ganu 
> ---
> Changes since V1:
> * Use a single boolean value to indicate the generation of either of
>   accept/revert capsule.
> * Move the parameters added to the list on the same line in a couple
>   of places.
>
>  tools/binman/btool/mkeficapsule.py | 26 ++
>  1 file changed, 26 insertions(+)
>

Reviewed-by: Simon Glass 

Applied to u-boot-dm, thanks!

Re: [PATCH 4/7] m68k: Remove common.h usage

[Angelo Dureghello]

Hi Tom,

sorry, applied all now, it works, i can boot properly.

Thanks.

Acked-by: Angelo Dureghello 

On 13/10/23 10:55 PM, Tom Rini wrote:

On Fri, Oct 13, 2023 at 10:53:04PM +0200, Angelo Dureghello wrote:

Hi Tom,


On 13/10/23 1:03 AM, Tom Rini wrote:

We can remove common.h from most cases of the code here, and only a few
places need an additional header instead.

Signed-off-by: Tom Rini 
---
Cc: Angelo Dureghello 
---
   arch/m68k/cpu/mcf523x/cpu.c | 1 -
   arch/m68k/cpu/mcf523x/cpu_init.c| 1 -
   arch/m68k/cpu/mcf523x/interrupts.c  | 1 -
   arch/m68k/cpu/mcf523x/speed.c   | 1 -
   arch/m68k/cpu/mcf52x2/cpu.c | 1 -
   arch/m68k/cpu/mcf52x2/cpu_init.c| 3 +--
   arch/m68k/cpu/mcf52x2/interrupts.c  | 1 -
   arch/m68k/cpu/mcf52x2/speed.c   | 1 -
   arch/m68k/cpu/mcf530x/cpu.c | 1 -
   arch/m68k/cpu/mcf530x/cpu_init.c| 1 -
   arch/m68k/cpu/mcf530x/interrupts.c  | 1 -
   arch/m68k/cpu/mcf530x/speed.c   | 1 -
   arch/m68k/cpu/mcf532x/cpu.c | 1 -
   arch/m68k/cpu/mcf532x/cpu_init.c| 1 -
   arch/m68k/cpu/mcf532x/interrupts.c  | 1 -
   arch/m68k/cpu/mcf532x/speed.c   | 1 -
   arch/m68k/cpu/mcf5445x/cpu.c| 1 -
   arch/m68k/cpu/mcf5445x/cpu_init.c   | 1 -
   arch/m68k/cpu/mcf5445x/dspi.c   | 1 -
   arch/m68k/cpu/mcf5445x/interrupts.c | 1 -
   arch/m68k/cpu/mcf5445x/speed.c  | 1 -
   arch/m68k/cpu/mcf5445x/start.S  | 1 -
   arch/m68k/include/asm/immap.h   | 1 +
   arch/m68k/include/asm/immap_520x.h  | 1 +
   arch/m68k/include/asm/immap_5235.h  | 1 +
   arch/m68k/include/asm/immap_5272.h  | 1 +
   arch/m68k/include/asm/immap_5275.h  | 1 +
   arch/m68k/include/asm/immap_5282.h  | 1 +
   arch/m68k/include/asm/immap_5301x.h | 1 +
   arch/m68k/include/asm/immap_5307.h  | 2 ++
   arch/m68k/include/asm/immap_5329.h  | 1 +
   arch/m68k/include/asm/immap_5441x.h | 1 +
   arch/m68k/lib/bdinfo.c  | 3 ++-
   arch/m68k/lib/bootm.c   | 1 -
   arch/m68k/lib/cache.c   | 2 +-
   arch/m68k/lib/fec.c | 2 +-
   arch/m68k/lib/interrupts.c  | 2 +-
   arch/m68k/lib/time.c| 1 -
   arch/m68k/lib/traps.c   | 1 -
   39 files changed, 17 insertions(+), 30 deletions(-)



building for mcf5307 i get this error

In file included from arch/m68k/lib/bootm.c:7:
include/bootstage.h:225:1: error: unknown type name 'ulong'; did you mean
'long'?
   225 | ulong timer_get_boot_us(void);
   | ^


Did you apply the whole series?  The first few patches fix some global
issues.



--
Angelo Dureghello
w: www.kernel-space.org
e: ang...@kernel-space.org

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Simon Glass]

Hi Rob,

On Fri, 13 Oct 2023 at 13:42, Rob Herring  wrote:
>
> On Fri, Oct 6, 2023 at 7:03 PM Simon Glass  wrote:
> >
> > Hi Ard,
> >
> > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> > >
> > > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > > >
> > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > > > >
> > > > > > Hi Rob,
> > > > > >
> > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  
> > > > > > wrote:
> > > > > > >
> > > > > > > It is common to split firmware into 'Platform Init', which does 
> > > > > > > the
> > > > > > > initial hardware setup and a "Payload" which selects the OS to be 
> > > > > > > booted.
> > > > > > > Thus an handover interface is required between these two pieces.
> > > > > > >
> > > > > > > Where UEFI boot-time services are not available, but UEFI 
> > > > > > > firmware is
> > > > > > > present on either side of this interface, information about 
> > > > > > > memory usage
> > > > > > > and attributes must be presented to the "Payload" in some form.
> > > > > > >
> > > > > > > This aims to provide an small schema addition for the memory 
> > > > > > > mapping
> > > > > > > needed to keep these two pieces working together well.
> > > > > > >
> > > > > > > Signed-off-by: Simon Glass 
> > > > > > > ---
> > > > > > >
> > > > > > > Changes in v7:
> > > > > > > - Rename acpi-reclaim to acpi
> > > > > > > - Drop individual mention of when memory can be reclaimed
> > > > > > > - Rewrite the item descriptions
> > > > > > > - Add back the UEFI text (with trepidation)
> > > > > >
> > > > > > I am again checking on this series. Can it be applied, please?
> > > > > >
> > > > >
> > > > > Apologies for the delay in response. I have been away.
> > > >
> > > > OK, I hope you had a nice trip.
> > > >
> > >
> > > Thanks, it was wonderful!
> > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > Changes in v6:
> > > > > > > - Drop mention of UEFI
> > > > > > > - Use compatible strings instead of node names
> > > > > > >
> > > > > > > Changes in v5:
> > > > > > > - Drop the memory-map node (should have done that in v4)
> > > > > > > - Tidy up schema a bit
> > > > > > >
> > > > > > > Changes in v4:
> > > > > > > - Make use of the reserved-memory node instead of creating a new 
> > > > > > > one
> > > > > > >
> > > > > > > Changes in v3:
> > > > > > > - Reword commit message again
> > > > > > > - cc a lot more people, from the FFI patch
> > > > > > > - Split out the attributes into the /memory nodes
> > > > > > >
> > > > > > > Changes in v2:
> > > > > > > - Reword commit message
> > > > > > >
> > > > > > >  .../reserved-memory/common-reserved.yaml  | 71 
> > > > > > > +++
> > > > > > >  1 file changed, 71 insertions(+)
> > > > > > >  create mode 100644 
> > > > > > > dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > > >
> > > > > > > diff --git 
> > > > > > > a/dtschema/schemas/reserved-memory/common-reserved.yaml 
> > > > > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > > > new file mode 100644
> > > > > > > index 000..f7fbdfd
> > > > > > > --- /dev/null
> > > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > > > @@ -0,0 +1,71 @@
> > > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > > > > > +%YAML 1.2
> > > > > > > +---
> > > > > > > +$id: 
> > > > > > > http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > > +
> > > > > > > +title: Common memory reservations
> > > > > > > +
> > > > > > > +description: |
> > > > > > > +  Specifies that the reserved memory region can be used for the 
> > > > > > > purpose
> > > > > > > +  indicated by its compatible string.
> > > > > > > +
> > > > > > > +  Clients may reuse this reserved memory if they understand what 
> > > > > > > it is for,
> > > > > > > +  subject to the notes below.
> > > > > > > +
> > > > > > > +maintainers:
> > > > > > > +  - Simon Glass 
> > > > > > > +
> > > > > > > +allOf:
> > > > > > > +  - $ref: reserved-memory.yaml
> > > > > > > +
> > > > > > > +properties:
> > > > > > > +  compatible:
> > > > > > > +description: |
> > > > > > > +  This describes some common memory reservations, with the 
> > > > > > > compatible
> > > > > > > +  string indicating what it is used for:
> > > > > > > +
> > > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) 
> > > > > > > tables
> > > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This 
> > > > > > > is reserved by
> > > > > > > +   the firmware for its use and is required to be saved 
> > > > > > > and restored
> > > > > > > +   across an NVS sleep
> > > > > > > + boot-code: Contains code used for booting which is not 
> > > > > > > needed by the OS
> > > > > > > + boot-code: Contains data 

Re: [PATCH 4/7] m68k: Remove common.h usage

[Tom Rini]

On Fri, Oct 13, 2023 at 10:53:04PM +0200, Angelo Dureghello wrote:
> Hi Tom,
> 
> 
> On 13/10/23 1:03 AM, Tom Rini wrote:
> > We can remove common.h from most cases of the code here, and only a few
> > places need an additional header instead.
> > 
> > Signed-off-by: Tom Rini 
> > ---
> > Cc: Angelo Dureghello 
> > ---
> >   arch/m68k/cpu/mcf523x/cpu.c | 1 -
> >   arch/m68k/cpu/mcf523x/cpu_init.c| 1 -
> >   arch/m68k/cpu/mcf523x/interrupts.c  | 1 -
> >   arch/m68k/cpu/mcf523x/speed.c   | 1 -
> >   arch/m68k/cpu/mcf52x2/cpu.c | 1 -
> >   arch/m68k/cpu/mcf52x2/cpu_init.c| 3 +--
> >   arch/m68k/cpu/mcf52x2/interrupts.c  | 1 -
> >   arch/m68k/cpu/mcf52x2/speed.c   | 1 -
> >   arch/m68k/cpu/mcf530x/cpu.c | 1 -
> >   arch/m68k/cpu/mcf530x/cpu_init.c| 1 -
> >   arch/m68k/cpu/mcf530x/interrupts.c  | 1 -
> >   arch/m68k/cpu/mcf530x/speed.c   | 1 -
> >   arch/m68k/cpu/mcf532x/cpu.c | 1 -
> >   arch/m68k/cpu/mcf532x/cpu_init.c| 1 -
> >   arch/m68k/cpu/mcf532x/interrupts.c  | 1 -
> >   arch/m68k/cpu/mcf532x/speed.c   | 1 -
> >   arch/m68k/cpu/mcf5445x/cpu.c| 1 -
> >   arch/m68k/cpu/mcf5445x/cpu_init.c   | 1 -
> >   arch/m68k/cpu/mcf5445x/dspi.c   | 1 -
> >   arch/m68k/cpu/mcf5445x/interrupts.c | 1 -
> >   arch/m68k/cpu/mcf5445x/speed.c  | 1 -
> >   arch/m68k/cpu/mcf5445x/start.S  | 1 -
> >   arch/m68k/include/asm/immap.h   | 1 +
> >   arch/m68k/include/asm/immap_520x.h  | 1 +
> >   arch/m68k/include/asm/immap_5235.h  | 1 +
> >   arch/m68k/include/asm/immap_5272.h  | 1 +
> >   arch/m68k/include/asm/immap_5275.h  | 1 +
> >   arch/m68k/include/asm/immap_5282.h  | 1 +
> >   arch/m68k/include/asm/immap_5301x.h | 1 +
> >   arch/m68k/include/asm/immap_5307.h  | 2 ++
> >   arch/m68k/include/asm/immap_5329.h  | 1 +
> >   arch/m68k/include/asm/immap_5441x.h | 1 +
> >   arch/m68k/lib/bdinfo.c  | 3 ++-
> >   arch/m68k/lib/bootm.c   | 1 -
> >   arch/m68k/lib/cache.c   | 2 +-
> >   arch/m68k/lib/fec.c | 2 +-
> >   arch/m68k/lib/interrupts.c  | 2 +-
> >   arch/m68k/lib/time.c| 1 -
> >   arch/m68k/lib/traps.c   | 1 -
> >   39 files changed, 17 insertions(+), 30 deletions(-)
> > 
> 
> building for mcf5307 i get this error
> 
> In file included from arch/m68k/lib/bootm.c:7:
> include/bootstage.h:225:1: error: unknown type name 'ulong'; did you mean
> 'long'?
>   225 | ulong timer_get_boot_us(void);
>   | ^

Did you apply the whole series?  The first few patches fix some global
issues.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 4/7] m68k: Remove common.h usage

[Angelo Dureghello]

Hi Tom,


On 13/10/23 1:03 AM, Tom Rini wrote:

We can remove common.h from most cases of the code here, and only a few
places need an additional header instead.

Signed-off-by: Tom Rini 
---
Cc: Angelo Dureghello 
---
  arch/m68k/cpu/mcf523x/cpu.c | 1 -
  arch/m68k/cpu/mcf523x/cpu_init.c| 1 -
  arch/m68k/cpu/mcf523x/interrupts.c  | 1 -
  arch/m68k/cpu/mcf523x/speed.c   | 1 -
  arch/m68k/cpu/mcf52x2/cpu.c | 1 -
  arch/m68k/cpu/mcf52x2/cpu_init.c| 3 +--
  arch/m68k/cpu/mcf52x2/interrupts.c  | 1 -
  arch/m68k/cpu/mcf52x2/speed.c   | 1 -
  arch/m68k/cpu/mcf530x/cpu.c | 1 -
  arch/m68k/cpu/mcf530x/cpu_init.c| 1 -
  arch/m68k/cpu/mcf530x/interrupts.c  | 1 -
  arch/m68k/cpu/mcf530x/speed.c   | 1 -
  arch/m68k/cpu/mcf532x/cpu.c | 1 -
  arch/m68k/cpu/mcf532x/cpu_init.c| 1 -
  arch/m68k/cpu/mcf532x/interrupts.c  | 1 -
  arch/m68k/cpu/mcf532x/speed.c   | 1 -
  arch/m68k/cpu/mcf5445x/cpu.c| 1 -
  arch/m68k/cpu/mcf5445x/cpu_init.c   | 1 -
  arch/m68k/cpu/mcf5445x/dspi.c   | 1 -
  arch/m68k/cpu/mcf5445x/interrupts.c | 1 -
  arch/m68k/cpu/mcf5445x/speed.c  | 1 -
  arch/m68k/cpu/mcf5445x/start.S  | 1 -
  arch/m68k/include/asm/immap.h   | 1 +
  arch/m68k/include/asm/immap_520x.h  | 1 +
  arch/m68k/include/asm/immap_5235.h  | 1 +
  arch/m68k/include/asm/immap_5272.h  | 1 +
  arch/m68k/include/asm/immap_5275.h  | 1 +
  arch/m68k/include/asm/immap_5282.h  | 1 +
  arch/m68k/include/asm/immap_5301x.h | 1 +
  arch/m68k/include/asm/immap_5307.h  | 2 ++
  arch/m68k/include/asm/immap_5329.h  | 1 +
  arch/m68k/include/asm/immap_5441x.h | 1 +
  arch/m68k/lib/bdinfo.c  | 3 ++-
  arch/m68k/lib/bootm.c   | 1 -
  arch/m68k/lib/cache.c   | 2 +-
  arch/m68k/lib/fec.c | 2 +-
  arch/m68k/lib/interrupts.c  | 2 +-
  arch/m68k/lib/time.c| 1 -
  arch/m68k/lib/traps.c   | 1 -
  39 files changed, 17 insertions(+), 30 deletions(-)



building for mcf5307 i get this error

In file included from arch/m68k/lib/bootm.c:7:
include/bootstage.h:225:1: error: unknown type name 'ulong'; did you 
mean 'long'?

  225 | ulong timer_get_boot_us(void);
  | ^

regards,
--
Angelo Dureghello
w: www.kernel-space.org
e: ang...@kernel-space.org

Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

[Rob Herring]

On Fri, Oct 6, 2023 at 7:03 PM Simon Glass  wrote:
>
> Hi Ard,
>
> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel  wrote:
> >
> > On Fri, 6 Oct 2023 at 20:17, Simon Glass  wrote:
> > >
> > > Hi Ard,
> > >
> > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel  wrote:
> > > >
> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass  wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass  wrote:
> > > > > >
> > > > > > It is common to split firmware into 'Platform Init', which does the
> > > > > > initial hardware setup and a "Payload" which selects the OS to be 
> > > > > > booted.
> > > > > > Thus an handover interface is required between these two pieces.
> > > > > >
> > > > > > Where UEFI boot-time services are not available, but UEFI firmware 
> > > > > > is
> > > > > > present on either side of this interface, information about memory 
> > > > > > usage
> > > > > > and attributes must be presented to the "Payload" in some form.
> > > > > >
> > > > > > This aims to provide an small schema addition for the memory mapping
> > > > > > needed to keep these two pieces working together well.
> > > > > >
> > > > > > Signed-off-by: Simon Glass 
> > > > > > ---
> > > > > >
> > > > > > Changes in v7:
> > > > > > - Rename acpi-reclaim to acpi
> > > > > > - Drop individual mention of when memory can be reclaimed
> > > > > > - Rewrite the item descriptions
> > > > > > - Add back the UEFI text (with trepidation)
> > > > >
> > > > > I am again checking on this series. Can it be applied, please?
> > > > >
> > > >
> > > > Apologies for the delay in response. I have been away.
> > >
> > > OK, I hope you had a nice trip.
> > >
> >
> > Thanks, it was wonderful!
> >
> > > >
> > > > >
> > > > > >
> > > > > > Changes in v6:
> > > > > > - Drop mention of UEFI
> > > > > > - Use compatible strings instead of node names
> > > > > >
> > > > > > Changes in v5:
> > > > > > - Drop the memory-map node (should have done that in v4)
> > > > > > - Tidy up schema a bit
> > > > > >
> > > > > > Changes in v4:
> > > > > > - Make use of the reserved-memory node instead of creating a new one
> > > > > >
> > > > > > Changes in v3:
> > > > > > - Reword commit message again
> > > > > > - cc a lot more people, from the FFI patch
> > > > > > - Split out the attributes into the /memory nodes
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Reword commit message
> > > > > >
> > > > > >  .../reserved-memory/common-reserved.yaml  | 71 
> > > > > > +++
> > > > > >  1 file changed, 71 insertions(+)
> > > > > >  create mode 100644 
> > > > > > dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > >
> > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml 
> > > > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > > new file mode 100644
> > > > > > index 000..f7fbdfd
> > > > > > --- /dev/null
> > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> > > > > > @@ -0,0 +1,71 @@
> > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > > > > +%YAML 1.2
> > > > > > +---
> > > > > > +$id: 
> > > > > > http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: Common memory reservations
> > > > > > +
> > > > > > +description: |
> > > > > > +  Specifies that the reserved memory region can be used for the 
> > > > > > purpose
> > > > > > +  indicated by its compatible string.
> > > > > > +
> > > > > > +  Clients may reuse this reserved memory if they understand what 
> > > > > > it is for,
> > > > > > +  subject to the notes below.
> > > > > > +
> > > > > > +maintainers:
> > > > > > +  - Simon Glass 
> > > > > > +
> > > > > > +allOf:
> > > > > > +  - $ref: reserved-memory.yaml
> > > > > > +
> > > > > > +properties:
> > > > > > +  compatible:
> > > > > > +description: |
> > > > > > +  This describes some common memory reservations, with the 
> > > > > > compatible
> > > > > > +  string indicating what it is used for:
> > > > > > +
> > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) 
> > > > > > tables
> > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This 
> > > > > > is reserved by
> > > > > > +   the firmware for its use and is required to be saved 
> > > > > > and restored
> > > > > > +   across an NVS sleep
> > > > > > + boot-code: Contains code used for booting which is not 
> > > > > > needed by the OS
> > > > > > + boot-code: Contains data used for booting which is not 
> > > > > > needed by the OS
> > > > > > + runtime-code: Contains code used for interacting with the 
> > > > > > system when
> > > > > > +   running the OS
> > > > > > + runtime-data: Contains data used for interacting with the 
> > > > > > system when
> > > > > > +   running the OS
> > > > > > +
> > > > > > +enum:
> > 

Re: [SPAM] [PATCH 20/26] test: spl: Add functions to create images

[Xavier Drudis Ferran]

El Wed, Oct 11, 2023 at 09:56:20PM -0400, Sean Anderson deia:
> This add some basic functions to create images, and a test for said
> functions. This is not intended to be a test of the image parsing
> functions, but rather a framework for creating minimal images for testing
> load methods. That said, it does do an OK job at finding bugs in the image
> parsing directly.
> 
> Since we have two methods for loading/parsing FIT images, add LOAD_FIT_FULL
> as a separate CI run.
> 
> Signed-off-by: Sean Anderson 
> ---
> 
>  .azure-pipelines.yml |   4 +
>  .gitlab-ci.yml   |   7 +
>  arch/sandbox/cpu/u-boot-spl.lds  |   2 +
>  configs/sandbox_noinst_defconfig |   6 +
>  configs/sandbox_spl_defconfig|   6 +
>  include/test/spl.h   | 117 ++
>  test/image/spl_load.c| 352 +++
>  test/image/spl_load_os.c |   5 +-
>  8 files changed, 495 insertions(+), 4 deletions(-)
>  create mode 100644 include/test/spl.h
>
[...]
> diff --git a/test/image/spl_load.c b/test/image/spl_load.c
> index 1a57bf846d2..ca3777cab37 100644
> --- a/test/image/spl_load.c
> +++ b/test/image/spl_load.c
> @@ -4,7 +4,15 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  int board_fit_config_name_match(const char *name)
>  {
> @@ -15,3 +23,347 @@ struct legacy_img_hdr *spl_get_load_buffer(ssize_t 
> offset, size_t size)
>  {
>   return map_sysmem(0x10, 0);
>  }
> +
> +/* Try to reuse the load buffer to conserve memory */
> +void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len)
> +{
> + static void *buf;
> + static size_t size;
> + static bool invalid = true;
> +
> + if (invalid || size < sectors * bl_len) {
> + if (!invalid)
> + free(buf);
> + buf = malloc_cache_aligned(sectors * bl_len);
> + invalid = false;

Should size be updated here or am I being thick ?
size = ALIGN(sectors * bl_len, ARCH_DMA_MINALIGN);

> + }
> + return buf;
> +}
> +

[PULL] u-boot-usb/master

[Marek Vasut]

The following changes since commit 86700279645921fb2c28c41711deb7d7ed75bc29:

  Merge branch '2023-10-12-assorted-TI-platform-updates' (2023-10-12 17:02:51 
-0400)

are available in the Git repository at:

  git://source.denx.de/u-boot-usb.git master

for you to fetch changes up to bc8e94c902d8b5a24d6b31963fc26058b54986ef:

  usb: gadget: atmel: fix transfer of queued requests (2023-10-13 13:42:10 
+0200)


Artur Rojek (1):
  usb: gadget: atmel: fix transfer of queued requests

 drivers/usb/gadget/atmel_usba_udc.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

Re: [PATCH 5/4] mkimage: update man page and -h output

[Rasmus Villemoes]

On 12/10/2023 04.17, Sean Anderson wrote:

> I was hoping you would respond to my most-recent email regarding this
> series.
> In particular:
> 
> | Why does mkimage have to do this? Can't you just use truncate or, in a
> | binman context, align-size?

In both cases, that just affects the size of the file, but does not
affect the totalsize field in the fdt header.

Wrt. binman, just as I was somewhat misled by the short mkimage -h
output into thinking that this already worked as I expected, binman's
fit,align documentation can also be read that way - and the
_implementation_ certainly currently unconditionally translates a
fit,align property into a -B argument to mkimage. So if we don't want
mkimage to support a -B by itself, binman documentation and code would
probably need another patch to reject that as well.

Rasmus

Re: U-Boot 2023.10 does not boot from uSD on RPi4

[Tom Rini]

On Fri, Oct 13, 2023 at 05:22:03PM +0100, Peter Robinson wrote:
> On Fri, Oct 13, 2023 at 5:09 PM Peter Robinson  wrote:
> >
> > On Tue, Oct 10, 2023 at 3:58 PM Simon Glass  wrote:
> > >
> > > Hi,
> > >
> > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet  
> > > wrote:
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Peter Robinson 
> > > > > Sent: Tuesday, October 10, 2023 12:22 PM
> > > > > To: Guillaume Gardet 
> > > > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass
> > > > > ; u-boot@lists.denx.de
> > > > > Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4
> > > > >
> > > > > On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet
> > > > >  wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > U-Boot 2023.10 does not boot from uSD on RPi4.
> > > > > > This has been found on openSUSE Tumbleweed. The only diff we need 
> > > > > > is:
> > > > > >   -CONFIG_OF_EMBED=y
> > > > > >   +CONFIG_OF_BOARD=y
> > > > > > To use firmware provided Device Tree. But that should not affect 
> > > > > > the mmc
> > > > > behavior too much, I think.
> > > > >
> > > > > I've been booting Fedora fine on a RPi4 BUT there's issues with the 
> > > > > display
> > > > > turning off [1] when the accelerated display modules load
> > > > > (vc4) as a result of this patch set. Can you confirm if that's the 
> > > > > same problem
> > > > > you're seeing?
> > > >
> > > > No, that's not my problem. My issue is grub was not loaded by u-boot 
> > > > from uSD.
> > > > It seems more like Simon's problem: 
> > > > https://lists.denx.de/pipermail/u-boot/2023-October/533162.html
> > > >
> > > > @Simon, can you check if the patch below fixes your boot problem on 
> > > > RPi4, please?
> > >
> > > This has been reported at least twice before. There is a fix [2] which is 
> > > in my queue to apply.
> >
> > Looking at that patch it scans the first 3 devices, how does it handle
> > non storage devices like SDIO WiFi modules? It shouldn't be trying to
> > scan those.
> 
> And in the case of the RPi the other enabled SDHCI interface is the
> WiFi, why would we even be trying to boot off a non storage interface,
> something here just feels broken/wrong in general.
> 
> The patch does make it work with pure upstream, and I'm not sure why
> the Fedora build boots it fine out of the box, but the patch just
> feels like it's hacking around some other underlying problem with
> bootstd, we didn't have this problem with the previous method and
> trying to boot off non storage interfaces feels like it could cause
> other problems.

I think the answer here is that we're doing the best we can given that
we just don't know until run time what we have. In the case where sdhci
is something other than storage, we get as far as asking "are you a
block device?" which then fails when sdhci is a WiFi an not an eMMC.
This does mean the user could notice "Card did not respond to voltage
select! : -110" being printed, and I don't know if we should do
anything about that (it's a handy message when your uSD isn't fully
inserted, etc).  But since we (can) support everything on a single
build, we just have to figure it out at run time.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 2/7] rockchip: dm: prepare rkmtd UCLASS

[Johan Jonker]

On 10/13/23 18:57, Simon Glass wrote:
> Hi Johan,
> 
> On Thu, 12 Oct 2023 at 13:51, Johan Jonker  wrote:
>>
>> Prepare a rkmtd UCLASS in use for writing Rockchip boot blocks
>> in combination with existing userspace tools and rockusb command.
>>
>> Signed-off-by: Johan Jonker 
>> Reviewed-by: Kever Yang 
>> ---
>>  disk/part.c| 4 
>>  drivers/block/blk-uclass.c | 1 +
>>  include/dm/uclass-id.h | 1 +
>>  3 files changed, 6 insertions(+)
> 

> Do you have a sandbox test for this somewhere?

Maybe have a look at:
[PATCH v3 6/7] rockchip: test: dm: add rkmtd test

The CONFIG_SANDBOX is used to select as much of the driver functionality for 
testing without MTD driver hardware.

Config CMD_RKMTD will select RKMTD, but is not added to a sandbox_defconfig 
file yet.

Not sure what is preferred. Please advise what patch I should produce.

Johan

> 
>>
>> diff --git a/disk/part.c b/disk/part.c
>> index 85244b09f359..36b88205eca7 100644
>> --- a/disk/part.c
>> +++ b/disk/part.c
>> @@ -197,6 +197,7 @@ void dev_print(struct blk_desc *desc)
>> case UCLASS_PVBLOCK:
>> case UCLASS_HOST:
>> case UCLASS_BLKMAP:
>> +   case UCLASS_RKMTD:
>> printf ("Vendor: %s Rev: %s Prod: %s\n",
>> desc->vendor,
>> desc->revision,
>> @@ -330,6 +331,9 @@ static void print_part_header(const char *type, struct 
>> blk_desc *desc)
>> case UCLASS_PVBLOCK:
>> puts("PV BLOCK");
>> break;
>> +   case UCLASS_RKMTD:
>> +   puts("RKMTD");
>> +   break;
>> case UCLASS_VIRTIO:
>> puts("VirtIO");
>> break;
>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
>> index f126547cc7e6..30ad5bbb0024 100644
>> --- a/drivers/block/blk-uclass.c
>> +++ b/drivers/block/blk-uclass.c
>> @@ -36,6 +36,7 @@ static struct {
>> { UCLASS_VIRTIO, "virtio" },
>> { UCLASS_PVBLOCK, "pvblock" },
>> { UCLASS_BLKMAP, "blkmap" },
>> +   { UCLASS_RKMTD, "rkmtd" },
>>  };
>>
>>  static enum uclass_id uclass_name_to_iftype(const char *uclass_idname)
>> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
>> index 0432c95c9edc..2fc672df0a3a 100644
>> --- a/include/dm/uclass-id.h
>> +++ b/include/dm/uclass-id.h
>> @@ -120,6 +120,7 @@ enum uclass_id {
>> UCLASS_REGULATOR,   /* Regulator device */
>> UCLASS_REMOTEPROC,  /* Remote Processor device */
>> UCLASS_RESET,   /* Reset controller device */
>> +   UCLASS_RKMTD,   /* Rockchip MTD device */
>> UCLASS_RNG, /* Random Number Generator */
>> UCLASS_RTC, /* Real time clock device */
>> UCLASS_SCMI_AGENT,  /* Interface with an SCMI server */
>> --
>> 2.39.2
>>
> 
> Regards,
> Simon

Re: [PATCH v12 5/8] test: Add sandbox TPM boot measurement

[Ilias Apalodimas]

Hi Eddie,

This doesn't apply on -master, can you please rebase?

Thanks
/Ilias

On Thu, 12 Oct 2023 at 16:49, Eddie James  wrote:
>
> Use the sandbox TPM driver to measure some boot images in a unit
> test case.
>
> Signed-off-by: Eddie James 
> Reviewed-by: Simon Glass 
> Acked-by: Ilias Apalodimas 
> ---
> Changes since v5:
>  - Only compile in the measurement u-boot command when
>CONFIG_MEASURED_BOOT is enabled.
>
>  arch/sandbox/dts/sandbox.dtsi | 13 +++
>  arch/sandbox/dts/test.dts | 13 +++
>  configs/sandbox_defconfig |  1 +
>  include/test/suites.h |  1 +
>  test/boot/Makefile|  1 +
>  test/boot/measurement.c   | 66 +++
>  test/cmd_ut.c |  4 +++
>  7 files changed, 99 insertions(+)
>  create mode 100644 test/boot/measurement.c
>
> diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
> index ff7e5584c5..241f397ba6 100644
> --- a/arch/sandbox/dts/sandbox.dtsi
> +++ b/arch/sandbox/dts/sandbox.dtsi
> @@ -4,11 +4,23 @@
>   * and sandbox64 builds.
>   */
>
> +#include 
>  #include 
>
>  #define USB_CLASS_HUB  9
>
>  / {
> +   reserved-memory {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   event_log: tcg_event_log {
> +   no-map;
> +   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
> +   };
> +   };
> +
> binman {
> };
>
> @@ -342,6 +354,7 @@
>
> tpm2 {
> compatible = "sandbox,tpm2";
> +   memory-region = <_log>;
> };
>
> triangle {
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 9a863ea732..bb2ddd9bf2 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -9,6 +9,7 @@
>
>  /dts-v1/;
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -68,6 +69,17 @@
> osd0 = "/osd";
> };
>
> +   reserved-memory {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   event_log: tcg_event_log {
> +   no-map;
> +   reg = <(CFG_SYS_SDRAM_SIZE - 0x2000) 0x2000>;
> +   };
> +   };
> +
> binman: binman {
> };
>
> @@ -1422,6 +1434,7 @@
>
> tpm2 {
> compatible = "sandbox,tpm2";
> +   memory-region = <_log>;
> };
>
> tpm {
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index d667cb9ae4..12c387a77e 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -349,3 +349,4 @@ CONFIG_UNIT_TEST=y
>  CONFIG_UT_TIME=y
>  CONFIG_UT_DM=y
>  CONFIG_ARM_FFA_TRANSPORT=y
> +CONFIG_MEASURED_BOOT=y
> diff --git a/include/test/suites.h b/include/test/suites.h
> index 1c7dc65966..48ed549c13 100644
> --- a/include/test/suites.h
> +++ b/include/test/suites.h
> @@ -45,6 +45,7 @@ int do_ut_font(struct cmd_tbl *cmdtp, int flag, int argc, 
> char *const argv[]);
>  int do_ut_lib(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
>  int do_ut_loadm(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> argv[]);
>  int do_ut_log(struct cmd_tbl *cmdtp, int flag, int argc, char * const 
> argv[]);
> +int do_ut_measurement(struct cmd_tbl *cmdtp, int flag, int argc, char * 
> const argv[]);
>  int do_ut_mem(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
>  int do_ut_optee(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> argv[]);
>  int do_ut_overlay(struct cmd_tbl *cmdtp, int flag, int argc,
> diff --git a/test/boot/Makefile b/test/boot/Makefile
> index 52947580ae..068522cb9e 100644
> --- a/test/boot/Makefile
> +++ b/test/boot/Makefile
> @@ -4,6 +4,7 @@
>
>  obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o bootmeth.o
>  obj-$(CONFIG_FIT) += image.o
> +obj-$(CONFIG_MEASURED_BOOT) += measurement.o
>
>  obj-$(CONFIG_EXPO) += expo.o
>  obj-$(CONFIG_CEDIT) += cedit.o
> diff --git a/test/boot/measurement.c b/test/boot/measurement.c
> new file mode 100644
> index 00..9db2ed324c
> --- /dev/null
> +++ b/test/boot/measurement.c
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Test for measured boot functions
> + *
> + * Copyright 2023 IBM Corp.
> + * Written by Eddie James 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MEASUREMENT_TEST(_name, _flags)\
> +   UNIT_TEST(_name, _flags, measurement_test)
> +
> +static int measure(struct unit_test_state *uts)
> +{
> +   struct bootm_headers images;
> +   const size_t size = 1024;
> +   u8 *kernel;
> +   u8 *initrd;
> +   size_t i;
> +
> +   kernel = malloc(size);
> +   initrd = malloc(size);
> +
> +   images.os.image_start = map_to_sysmem(kernel);
> +   

Re: [PATCH] bootstd: Scan all bootdevs in a boot_targets entry

[Simon Glass]

Hi,

On Sat, 23 Sept 2023 at 13:50, Simon Glass  wrote:
>
> When the boot_targets environment variable is used with the distro-boot
> scripts, each device is included individually. For example, if there
> are three mmc devices, then we will have something like:
>
>boot_targets="mmc0 mmc1 mmc2"
>
> In contrast, standard boot supports specifying just the uclass, i.e.:
>
>boot_targets="mmc"
>
> The intention is that this should scan all MMC devices, but in fact it
> currently only scans the first.
>
> Update the logic to handle this case, without required BOOTSTD_FULL to
> be enabled.
>
> I believe at least three people reported this, but I found two.
>
> Signed-off-by: Simon Glass 
> Reported-by: Date Huang 
> Reported-by: Vincent Stehlé 
> ---
>
>  boot/bootdev-uclass.c |  3 ++-
>  boot/bootflow.c   | 21 +++--
>  test/boot/bootdev.c   | 10 ++
>  3 files changed, 31 insertions(+), 3 deletions(-)

I'm going to pick this one up. There are no formal tested-by tags but
there are two reports on the mailing list that it fixes the problem.
[1] [2]

Regards,
Simon

[1] https://lore.kernel.org/all/ZSMlNWJ9f7HkoaNg@Dell-Inspiron-15/
[2] 
https://lore.kernel.org/all/vi1pr08mb2847b5efd8f36e5a4d41febd83...@vi1pr08mb2847.eurprd08.prod.outlook.com/

Re: [PATCH 3/5] core: introduce dev_read_addr_name[_size]_ptr() functions

[Simon Glass]

On Wed, 27 Sept 2023 at 06:34, Matthias Schiffer
 wrote:
>
> Same as dev_read_addr_name[_size](), but returns a pointer, cast
> through map_sysmem().
>
> Signed-off-by: Matthias Schiffer 
> ---
>  drivers/core/fdtaddr.c | 21 +
>  drivers/core/read.c| 21 +
>  include/dm/fdtaddr.h   | 31 +++
>  include/dm/read.h  | 41 +
>  4 files changed, 114 insertions(+)
>

Reviewed-by: Simon Glass 

Re: [PATCH 4/5] pinctrl: single: fix compile warnings with PHYS_64BIT on 32bit

[Simon Glass]

On Wed, 27 Sept 2023 at 06:34, Matthias Schiffer
 wrote:
>
> pinctrl-single uses fdt_addr_t and phys_addr_t inconsistently, but both
> are wrong to be passed to readb() etc., which expect a pointer or
> pointer-sized integer. Change the driver to use
> dev_read_addr_size_index_ptr(), so we consistently deal with void*
> (except for the sandbox case and single_get_pin_muxing()).
>
> Signed-off-by: Matthias Schiffer 
> ---
>
> Tested on x86 sandbox and TI AM62x. No new unit test failures in
> sandbox.
>
>  drivers/pinctrl/pinctrl-single.c | 33 +---
>  1 file changed, 18 insertions(+), 15 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 4/7] m68k: Remove common.h usage

[Simon Glass]

Hi Tom,

On Fri, 13 Oct 2023 at 08:17, Tom Rini  wrote:
>
> On Fri, Oct 13, 2023 at 08:14:57AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 12 Oct 2023 at 16:11, Tom Rini  wrote:
> > >
> > > We can remove common.h from most cases of the code here, and only a few
> > > places need an additional header instead.
> > >
> > > Signed-off-by: Tom Rini 
> > > ---
> > > Cc: Angelo Dureghello 
> > > ---
> > >  arch/m68k/cpu/mcf523x/cpu.c | 1 -
> > >  arch/m68k/cpu/mcf523x/cpu_init.c| 1 -
> > >  arch/m68k/cpu/mcf523x/interrupts.c  | 1 -
> > >  arch/m68k/cpu/mcf523x/speed.c   | 1 -
> > >  arch/m68k/cpu/mcf52x2/cpu.c | 1 -
> > >  arch/m68k/cpu/mcf52x2/cpu_init.c| 3 +--
> > >  arch/m68k/cpu/mcf52x2/interrupts.c  | 1 -
> > >  arch/m68k/cpu/mcf52x2/speed.c   | 1 -
> > >  arch/m68k/cpu/mcf530x/cpu.c | 1 -
> > >  arch/m68k/cpu/mcf530x/cpu_init.c| 1 -
> > >  arch/m68k/cpu/mcf530x/interrupts.c  | 1 -
> > >  arch/m68k/cpu/mcf530x/speed.c   | 1 -
> > >  arch/m68k/cpu/mcf532x/cpu.c | 1 -
> > >  arch/m68k/cpu/mcf532x/cpu_init.c| 1 -
> > >  arch/m68k/cpu/mcf532x/interrupts.c  | 1 -
> > >  arch/m68k/cpu/mcf532x/speed.c   | 1 -
> > >  arch/m68k/cpu/mcf5445x/cpu.c| 1 -
> > >  arch/m68k/cpu/mcf5445x/cpu_init.c   | 1 -
> > >  arch/m68k/cpu/mcf5445x/dspi.c   | 1 -
> > >  arch/m68k/cpu/mcf5445x/interrupts.c | 1 -
> > >  arch/m68k/cpu/mcf5445x/speed.c  | 1 -
> > >  arch/m68k/cpu/mcf5445x/start.S  | 1 -
> > >  arch/m68k/include/asm/immap.h   | 1 +
> > >  arch/m68k/include/asm/immap_520x.h  | 1 +
> > >  arch/m68k/include/asm/immap_5235.h  | 1 +
> > >  arch/m68k/include/asm/immap_5272.h  | 1 +
> > >  arch/m68k/include/asm/immap_5275.h  | 1 +
> > >  arch/m68k/include/asm/immap_5282.h  | 1 +
> > >  arch/m68k/include/asm/immap_5301x.h | 1 +
> > >  arch/m68k/include/asm/immap_5307.h  | 2 ++
> > >  arch/m68k/include/asm/immap_5329.h  | 1 +
> > >  arch/m68k/include/asm/immap_5441x.h | 1 +
> > >  arch/m68k/lib/bdinfo.c  | 3 ++-
> > >  arch/m68k/lib/bootm.c   | 1 -
> > >  arch/m68k/lib/cache.c   | 2 +-
> > >  arch/m68k/lib/fec.c | 2 +-
> > >  arch/m68k/lib/interrupts.c  | 2 +-
> > >  arch/m68k/lib/time.c| 1 -
> > >  arch/m68k/lib/traps.c   | 1 -
> > >  39 files changed, 17 insertions(+), 30 deletions(-)
> >
> > I just wondered what we do about '#ifdef CFG_...' which presumably is
> > not included without common.h ? How does that work?
>
> The first header in common.h is config.h which is where many CFG_...
> instances are.

OK, so that comes later...

Regards,
Simon

Re: U-Boot 2023.10 does not boot from uSD on RPi4

[Simon Glass]

Hi Peter,

On Fri, 13 Oct 2023 at 09:22, Peter Robinson  wrote:
>
> On Fri, Oct 13, 2023 at 5:09 PM Peter Robinson  wrote:
> >
> > On Tue, Oct 10, 2023 at 3:58 PM Simon Glass  wrote:
> > >
> > > Hi,
> > >
> > > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet  
> > > wrote:
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Peter Robinson 
> > > > > Sent: Tuesday, October 10, 2023 12:22 PM
> > > > > To: Guillaume Gardet 
> > > > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass
> > > > > ; u-boot@lists.denx.de
> > > > > Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4
> > > > >
> > > > > On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet
> > > > >  wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > U-Boot 2023.10 does not boot from uSD on RPi4.
> > > > > > This has been found on openSUSE Tumbleweed. The only diff we need 
> > > > > > is:
> > > > > >   -CONFIG_OF_EMBED=y
> > > > > >   +CONFIG_OF_BOARD=y
> > > > > > To use firmware provided Device Tree. But that should not affect 
> > > > > > the mmc
> > > > > behavior too much, I think.
> > > > >
> > > > > I've been booting Fedora fine on a RPi4 BUT there's issues with the 
> > > > > display
> > > > > turning off [1] when the accelerated display modules load
> > > > > (vc4) as a result of this patch set. Can you confirm if that's the 
> > > > > same problem
> > > > > you're seeing?
> > > >
> > > > No, that's not my problem. My issue is grub was not loaded by u-boot 
> > > > from uSD.
> > > > It seems more like Simon's problem: 
> > > > https://lists.denx.de/pipermail/u-boot/2023-October/533162.html
> > > >
> > > > @Simon, can you check if the patch below fixes your boot problem on 
> > > > RPi4, please?
> > >
> > > This has been reported at least twice before. There is a fix [2] which is 
> > > in my queue to apply.
> >
> > Looking at that patch it scans the first 3 devices, how does it handle
> > non storage devices like SDIO WiFi modules? It shouldn't be trying to
> > scan those.
>
> And in the case of the RPi the other enabled SDHCI interface is the
> WiFi, why would we even be trying to boot off a non storage interface,
> something here just feels broken/wrong in general.
>
> The patch does make it work with pure upstream, and I'm not sure why
> the Fedora build boots it fine out of the box, but the patch just
> feels like it's hacking around some other underlying problem with
> bootstd, we didn't have this problem with the previous method and
> trying to boot off non storage interfaces feels like it could cause
> other problems.

Does U-Boot assume that any SDHCI interface holds storage? Does it use
a different compatible string for WiFi?

The call to bootdev_setup_for_sibling_blk() in mmc_bind() is what sets
up the bootdev, so I suppose there could be a condition there.

Having said that, I doubt it would cause any problems.

If your comment is about my patch, then could you please reply there,
to avoid confusion?

Regards,
Simon

Re: [PATCH v3 2/7] rockchip: dm: prepare rkmtd UCLASS

[Simon Glass]

Hi Johan,

On Thu, 12 Oct 2023 at 13:51, Johan Jonker  wrote:
>
> Prepare a rkmtd UCLASS in use for writing Rockchip boot blocks
> in combination with existing userspace tools and rockusb command.
>
> Signed-off-by: Johan Jonker 
> Reviewed-by: Kever Yang 
> ---
>  disk/part.c| 4 
>  drivers/block/blk-uclass.c | 1 +
>  include/dm/uclass-id.h | 1 +
>  3 files changed, 6 insertions(+)

Do you have a sandbox test for this somewhere?

>
> diff --git a/disk/part.c b/disk/part.c
> index 85244b09f359..36b88205eca7 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -197,6 +197,7 @@ void dev_print(struct blk_desc *desc)
> case UCLASS_PVBLOCK:
> case UCLASS_HOST:
> case UCLASS_BLKMAP:
> +   case UCLASS_RKMTD:
> printf ("Vendor: %s Rev: %s Prod: %s\n",
> desc->vendor,
> desc->revision,
> @@ -330,6 +331,9 @@ static void print_part_header(const char *type, struct 
> blk_desc *desc)
> case UCLASS_PVBLOCK:
> puts("PV BLOCK");
> break;
> +   case UCLASS_RKMTD:
> +   puts("RKMTD");
> +   break;
> case UCLASS_VIRTIO:
> puts("VirtIO");
> break;
> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> index f126547cc7e6..30ad5bbb0024 100644
> --- a/drivers/block/blk-uclass.c
> +++ b/drivers/block/blk-uclass.c
> @@ -36,6 +36,7 @@ static struct {
> { UCLASS_VIRTIO, "virtio" },
> { UCLASS_PVBLOCK, "pvblock" },
> { UCLASS_BLKMAP, "blkmap" },
> +   { UCLASS_RKMTD, "rkmtd" },
>  };
>
>  static enum uclass_id uclass_name_to_iftype(const char *uclass_idname)
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index 0432c95c9edc..2fc672df0a3a 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -120,6 +120,7 @@ enum uclass_id {
> UCLASS_REGULATOR,   /* Regulator device */
> UCLASS_REMOTEPROC,  /* Remote Processor device */
> UCLASS_RESET,   /* Reset controller device */
> +   UCLASS_RKMTD,   /* Rockchip MTD device */
> UCLASS_RNG, /* Random Number Generator */
> UCLASS_RTC, /* Real time clock device */
> UCLASS_SCMI_AGENT,  /* Interface with an SCMI server */
> --
> 2.39.2
>

Regards,
Simon

Re: [PATCH] .gitignore: ignore misc include, simple-bin, and tools/generated build artifacts

[Simon Glass]

Hi John,

On Fri, 13 Oct 2023 at 06:26, John Clark  wrote:
>
> make rock5b-rk3588_defconfig
> make
> git status
>
> before
> ~~~
> On branch master
> Your branch is ahead of 'origin/master' by 1 commit.
>   (use "git push" to publish your local commits)
>
> Untracked files:
>   (use "git add ..." to include in what will be committed)
> include/autoconf.mk
> include/autoconf.mk.dep
> include/config.h
> mkimage-in-simple-bin-spi.mkimage-rockchip-tpl
> mkimage-in-simple-bin-spi.mkimage-u-boot-spl
> mkimage-in-simple-bin.mkimage-rockchip-tpl
> mkimage-in-simple-bin.mkimage-u-boot-spl
> simple-bin-spi.map
> simple-bin.fit.fit
> simple-bin.fit.itb
> simple-bin.map
> tools/generated/
>
> after
> ~~~
> On branch master
> Your branch is ahead of 'origin/master' by 1 commit.
>   (use "git push" to publish your local commits)
>
> nothing to commit, working tree clean
>
> Signed-off-by: John Clark 
>
> ---
>
>  .gitignore | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

The mkimage and simple-bin things seem board-specific. Once we get
binman to put intermediate-output files in a subdir, we should be able
to drop this.

>
> diff --git a/.gitignore b/.gitignore
> index 84051b7bfd..a1a79e92fe 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -44,8 +44,10 @@ fit-dtb.blob*
>  /MLO*
>  /SPL*
>  /System.map
> -/u-boot*
>  /boards.cfg
> +/mkimage-in-simple-bin*
> +/simple-bin*
> +/u-boot*
>  /*.log
>
>  #
> @@ -59,12 +61,15 @@ fit-dtb.blob*
>  # Generated files
>  #
>  /spl/
> +/tools/generated/
>  /tpl/
>  /defconfig
>
>  #
>  # Generated include files
>  #
> +/include/autoconf.mk*
> +/include/config.h
>  /include/config/
>  /include/generated/
>
> --
> 2.42.0
>

Regards,
Simon

Re: [PATCH v2] patman: Add a 'keep_change_id' setting

[Simon Glass]

On Thu, 12 Oct 2023 at 20:06, Maxim Cournoyer  wrote:
>
> A Change-Id can be useful for traceability purposes, and some projects
> may wish to have them preserved.  This change makes it configurable
> via a new 'keep_change_id' setting.
>
> Signed-off-by: Maxim Cournoyer 
> ---
>
> Changes in v2:
> - Add missing argument to send parser
> - Correctly propagate args.keep_change_id
>
>  tools/patman/__main__.py|  2 ++
>  tools/patman/control.py | 12 +---
>  tools/patman/patchstream.py | 17 -
>  tools/patman/patman.rst | 11 ++-
>  tools/patman/test_checkpatch.py | 16 
>  5 files changed, 45 insertions(+), 13 deletions(-)

Reviewed-by: Simon Glass 

[PATCH v1] zynqmp: migrate gqspi debug to logging

[Ibai Erkiaga]

The following patch migrates the usage of debug and printf functions
to the relevant logging function as per U-Boot DM guidelines.

Additionally some of the debugging statements have been rearanged for
a more meaningfull debug experience.

aarch64-linux-gnu-size reports 229 bytes less when debug is enabled at
file level, while is just 5bytes more when disabled.

Signed-off-by: Ibai Erkiaga 
---
 drivers/spi/zynqmp_gqspi.c | 82 +++---
 1 file changed, 33 insertions(+), 49 deletions(-)

diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index ec59ef5804..a323994fb2 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -5,6 +5,8 @@
  * Xilinx ZynqMP Generic Quad-SPI(QSPI) controller driver(master mode only)
  */
 
+#define LOG_CATEGORY UCLASS_SPI
+
 #include 
 #include 
 #include 
@@ -192,8 +194,6 @@ static int zynqmp_qspi_of_to_plat(struct udevice *bus)
 {
struct zynqmp_qspi_plat *plat = dev_get_plat(bus);
 
-   debug("%s\n", __func__);
-
plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
 GQSPI_REG_OFFSET);
plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
@@ -250,7 +250,7 @@ static u32 zynqmp_qspi_genfifo_mode(u8 buswidth)
case 4:
return GQSPI_SPI_MODE_QSPI;
default:
-   debug("Unsupported bus width %u\n", buswidth);
+   log_warning("Unsupported bus width %u\n", buswidth);
return GQSPI_SPI_MODE_SPI;
}
 }
@@ -262,6 +262,8 @@ static void zynqmp_qspi_fill_gen_fifo(struct 
zynqmp_qspi_priv *priv,
u32 config_reg, ier;
int ret = 0;
 
+   log_content("%s, GFIFO_CMD: 0x%X\n", __func__, gqspi_fifo_reg);
+
writel(gqspi_fifo_reg, >genfifo);
 
config_reg = readl(>confr);
@@ -278,7 +280,7 @@ static void zynqmp_qspi_fill_gen_fifo(struct 
zynqmp_qspi_priv *priv,
ret = wait_for_bit_le32(>isr, GQSPI_IXR_GFEMTY_MASK, 1,
GQSPI_TIMEOUT, 1);
if (ret)
-   printf("%s Timeout\n", __func__);
+   log_warning("%s, Timeout\n", __func__);
 
 }
 
@@ -286,6 +288,8 @@ static void zynqmp_qspi_chipselect(struct zynqmp_qspi_priv 
*priv, int is_on)
 {
u32 gqspi_fifo_reg = 0;
 
+   log_debug("%s, assert: %d\r\n", __func__, is_on);
+
if (is_on) {
gqspi_fifo_reg = zynqmp_qspi_bus_select(priv);
gqspi_fifo_reg |= GQSPI_SPI_MODE_SPI |
@@ -295,8 +299,6 @@ static void zynqmp_qspi_chipselect(struct zynqmp_qspi_priv 
*priv, int is_on)
gqspi_fifo_reg |= GQSPI_IMD_DATA_CS_DEASSERT;
}
 
-   debug("GFIFO_CMD_CS: 0x%x\n", gqspi_fifo_reg);
-
zynqmp_qspi_fill_gen_fifo(priv, gqspi_fifo_reg);
 }
 
@@ -311,8 +313,8 @@ static void zynqmp_qspi_set_tapdelay(struct udevice *bus, 
u32 baudrateval)
clk_rate = plat->frequency;
reqhz = (clk_rate / (GQSPI_BAUD_DIV_SHIFT << baudrateval));
 
-   debug("%s, req_hz:%d, clk_rate:%d, baudrateval:%d\n",
- __func__, reqhz, clk_rate, baudrateval);
+   log_debug("%s, clk_rate:%d, baudrateval:%d, bus_clk: %d\n",
+ __func__, clk_rate, baudrateval, reqhz);
 
if (!(IS_ENABLED(CONFIG_ARCH_VERSAL) ||
  IS_ENABLED(CONFIG_ARCH_VERSAL_NET))) {
@@ -362,7 +364,8 @@ static int zynqmp_qspi_set_speed(struct udevice *bus, uint 
speed)
u32 confr;
u8 baud_rate_val = 0;
 
-   debug("%s\n", __func__);
+   log_debug("%s, Speed: %d, Max: %d\n", __func__, speed, plat->frequency);
+
if (speed > plat->frequency)
speed = plat->frequency;
 
@@ -383,9 +386,8 @@ static int zynqmp_qspi_set_speed(struct udevice *bus, uint 
speed)
confr &= ~GQSPI_BAUD_DIV_MASK;
confr |= (baud_rate_val << 3);
writel(confr, >confr);
-   zynqmp_qspi_set_tapdelay(bus, baud_rate_val);
 
-   debug("regs=%p, speed=%d\n", priv->regs, plat->speed_hz);
+   zynqmp_qspi_set_tapdelay(bus, baud_rate_val);
}
 
return 0;
@@ -399,8 +401,6 @@ static int zynqmp_qspi_probe(struct udevice *bus)
unsigned long clock;
int ret;
 
-   debug("%s: bus:%p, priv:%p\n", __func__, bus, priv);
-
priv->regs = plat->regs;
priv->dma_regs = plat->dma_regs;
priv->io_mode = plat->io_mode;
@@ -416,7 +416,6 @@ static int zynqmp_qspi_probe(struct udevice *bus)
dev_err(bus, "failed to get rate\n");
return clock;
}
-   debug("%s: CLK %ld\n", __func__, clock);
 
ret = clk_enable();
if (ret) {
@@ -429,6 +428,8 @@ static int zynqmp_qspi_probe(struct udevice *bus)
/* init the zynq spi hw */
zynqmp_qspi_init_hw(priv);
 
+   log_debug("%s, Rerence clock frequency: %ld\n", __func__, clock);
+
return 0;
 }
 
@@ -438,7 +439,8 @@ static int 

[PATCH v1] drivers: don't compile Secure Monitor UCLASS unconditionally

[Alexey Romanov]

It makes no sense to compile Secure Monitor unconditionally.
For example, this break the SPL build on boards with a small
allowed SPL image size.

Fixes: 126fbbefd89e ("drivers: introduce Secure Monitor uclass")

Signed-off-by: Alexey Romanov 
---
 drivers/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index b7bd3633b1..1a768fed2b 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_$(SPL_TPL_)VIRTIO) += virtio/
 obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox/
 obj-$(CONFIG_$(SPL_)REMOTEPROC) += remoteproc/
 obj-$(CONFIG_$(SPL_)SYSINFO) += sysinfo/
+obj-$(CONFIG_$(SPL_TPL_)SM) += sm/
 obj-$(CONFIG_$(SPL_TPL_)TPM) += tpm/
 obj-$(CONFIG_XEN) += xen/
 obj-$(CONFIG_$(SPL_)FPGA) += fpga/
@@ -124,4 +125,3 @@ obj-$(CONFIG_DM_RNG) += rng/
 endif
 
 obj-y += soc/
-obj-y += sm/
-- 
2.25.1

Re: [PATCH] ls1088a: Move maintainership over to Udit Agarwal

[Tom Rini]

On Fri, Oct 13, 2023 at 12:55:15PM -0400, Tom Rini wrote:

> As Ashish Kumar's email address is no longer valid, move these platforms
> over to Udit as they are the maintainer for some of the other similar
> platforms already.
> 
> Signed-off-by: Tom Rini 
> ---
> Cc: Udit Agarwal 

Well, NAK this as Udit is also bouncing.  Peng?

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] ls1088a: Move maintainership over to Udit Agarwal

[Tom Rini]

As Ashish Kumar's email address is no longer valid, move these platforms
over to Udit as they are the maintainer for some of the other similar
platforms already.

Signed-off-by: Tom Rini 
---
Cc: Udit Agarwal 
---
 board/freescale/ls1088a/MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/freescale/ls1088a/MAINTAINERS 
b/board/freescale/ls1088a/MAINTAINERS
index 95a14149e4fb..1707ce9ca02b 100644
--- a/board/freescale/ls1088a/MAINTAINERS
+++ b/board/freescale/ls1088a/MAINTAINERS
@@ -1,5 +1,5 @@
 LS1088ARDB BOARD
-M: Ashish Kumar 
+M: Udit Agarwal 
 S: Maintained
 F: board/freescale/ls1088a/
 F: include/configs/ls1088ardb.h
@@ -9,7 +9,7 @@ F:  configs/ls1088ardb_tfa_defconfig
 F: configs/ls1088ardb_tfa_SECURE_BOOT_defconfig
 
 LS1088AQDS BOARD
-M: Ashish Kumar 
+M: Udit Agarwal 
 S: Maintained
 F: board/freescale/ls1088a/
 F: include/configs/ls1088aqds.h
-- 
2.34.1

Re: Pull request efi-2024-01-rc1

[Tom Rini]

On Fri, Oct 13, 2023 at 04:51:31PM +0200, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit 997bef3c6d22d12c7fd092fb831bf94d114c9f6f:
> 
>   Merge branch '2023-10-11-port-gen_compile_commands_py' (2023-10-11
> 13:25:01 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2024-01-rc1
> 
> for you to fetch changes up to c1ab04626d6b05c6e82dfe4d97d3f62f7310d612:
> 
>   efi_loader: use well-known guid for auto-created boot option
> (2023-10-12 08:32:27 +0200)
> 
> Gitlab CI showed no issues:
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/18093
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [GIT PULL] xilinx patches for v2024.01-rc1 v3

[Tom Rini]

On Fri, Oct 13, 2023 at 02:44:49PM +0200, Michal Simek wrote:

> Hi Tom,
> 
> please apply to following patches to your tree. The most of them are DT
> chagnes are coming from Linux dt schema validation, fixing DT warnings W=1,
> sync it with upstream kernel
> and adding missing pieces. Also new DTSes are added to described other
> boards. It most interesting are adding support for new Kria SOM Kd240 board
> and descriptions related to System Controllers which
> are ZynqMP based SOCs available on Versal/Versal NET evaluation boards which
> are handling DUT resources.
> 
> There are other changes sent but I want to clean my queue to enable testing 
> for it.
> 
> Thanks,
> Michal
> 
> The following changes since commit 83aa0ed1e93e1ffac24888d98d37a5b04ed3fb07:
> 
>   Merge branch '2023-10-06-spl-prepare-for-universal-payload' (2023-10-06
> 17:23:47 -0400)
> 
> are available in the Git repository at:
> 
>   g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git
> tags/xilinx-for-v2024.01-rc1-v3
> 
> for you to fetch changes up to 7a82bfff5ea7089905dff14e65436d23c1e5adc4:
> 
>   test/py: net: Add a test for 'pxe get' command (2023-10-10 14:57:29 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Pull request for u-boot-nand-20230417

[Tom Rini]

On Fri, Oct 13, 2023 at 02:40:32PM +0200, Dario Binacchi wrote:

> Hello Tom,
> 
> The following changes since commit 86700279645921fb2c28c41711deb7d7ed75bc29:
> 
>   Merge branch '2023-10-12-assorted-TI-platform-updates' (2023-10-12
> 17:02:51 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
> tags/u-boot-nand-20231013
> 
> for you to fetch changes up to be0da1257f189c09604b01bc04a7e8411bf18e5c:
> 
>   dfu: mtd: mark bad the MTD block on erase error (2023-10-13 10:49:07 +0200)
> 
> Gitlab CI showed no issues:
> https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/18106
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 06/11] board: ti: introduce basic board files for the am62px family

[Bryan Brattlof]

Hey Tom!

On October 13, 2023 thus sayeth Tom Rini:
> On Thu, Oct 12, 2023 at 06:06:23PM -0500, Bryan Brattlof wrote:
> 
> > Introduce the basic files needed to support the am62px family of SoCs
> > 
> > Co-developed-by: Hari Hagalla 
> > Signed-off-by: Hari Hagalla 
> > Signed-off-by: Bryan Brattlof 
> [snip]
> > diff --git a/board/ti/am62px/evm.c b/board/ti/am62px/evm.c
> > new file mode 100644
> > index 0..44793cbed6536
> > --- /dev/null
> > +++ b/board/ti/am62px/evm.c
> > @@ -0,0 +1,30 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Board specific initialization for AM62Px platforms
> > + *
> > + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +int board_init(void)
> > +{
> > +   return 0;
> > +}
> > +
> > +int dram_init(void)
> > +{
> > +   return fdtdec_setup_mem_size_base();
> > +}
> > +
> > +int dram_init_banksize(void)
> > +{
> > +   return fdtdec_setup_memory_banksize();
> > +}
> 
> Similar to what I said about another platform yesterday, lets split this
> up in to "base.c" and "evm.c".  The good news is that so far, I think
> all of this should just be in base.c instead.  Second, here and
> elsewhere don't add common.h but instead add what you need.  And
> finally, for all of the new files please audit what headers you're
> adding.  7 headers for 5 function prototypes is a bit much.  Thanks.
> 

Yeah I can clean this up :)

> -- 
> Tom

Re: [PATCH v2 2/2] patman: Add a little documentation on the checkpatch tests

[Tom Rini]

On Fri, Oct 13, 2023 at 09:28:33AM -0700, Simon Glass wrote:

> These texts lack comments. Add some so that it is clearer what is going
> on.
> 
> Signed-off-by: Simon Glass 

Ah, OK, I see now why my changes failed, thanks.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH v2 2/2] patman: Add a little documentation on the checkpatch tests

[Simon Glass]

These texts lack comments. Add some so that it is clearer what is going
on.

Signed-off-by: Simon Glass 
---

(no changes since v1)

 tools/patman/test_checkpatch.py | 49 +
 1 file changed, 49 insertions(+)

diff --git a/tools/patman/test_checkpatch.py b/tools/patman/test_checkpatch.py
index f8117460ced2..0a8f7408f146 100644
--- a/tools/patman/test_checkpatch.py
+++ b/tools/patman/test_checkpatch.py
@@ -18,19 +18,47 @@ from patman import commit
 
 
 class Line:
+"""Single changed line in one file in a patch
+
+Args:
+fname (str): Filename containing the added line
+text (str): Text of the added line
+"""
 def __init__(self, fname, text):
 self.fname = fname
 self.text = text
 
 
 class PatchMaker:
+"""Makes a patch for checking with checkpatch.pl
+
+The idea here is to create a patch which adds one line in one file,
+intended to provoke a checkpatch error or warning. The base patch is empty
+(i.e. invalid), so you should call add_line() to add at least one line.
+"""
 def __init__(self):
+"""Set up the PatchMaker object
+
+Properties:
+lines (list of Line): List of lines to add to the patch. Note that
+each line has both a file and some text associated with it,
+since for simplicity we just add a single line for each file
+"""
 self.lines = []
 
 def add_line(self, fname, text):
+"""Add to the list of filename/line pairs"""
 self.lines.append(Line(fname, text))
 
 def get_patch_text(self):
+"""Build the patch text
+
+Takes a base patch and adds a diffstat and patch for each filename/line
+pair in the list.
+
+Returns:
+str: Patch text ready for submission to checkpatch
+"""
 base = '''From 125b77450f4c66b8fd9654319520bbe795c9ef31 Mon Sep 17 
00:00:00 2001
 From: Simon Glass 
 Date: Sun, 14 Jun 2020 09:45:14 -0600
@@ -75,6 +103,11 @@ Signed-off-by: Simon Glass 
 return '\n'.join(lines)
 
 def get_patch(self):
+"""Get the patch text and write it into a temporary file
+
+Returns:
+str: Filename containing the patch
+"""
 inhandle, inname = tempfile.mkstemp()
 infd = os.fdopen(inhandle, 'w')
 infd.write(self.get_patch_text())
@@ -82,6 +115,22 @@ Signed-off-by: Simon Glass 
 return inname
 
 def run_checkpatch(self):
+"""Run checkpatch on the patch file
+
+Returns:
+namedtuple containing:
+ok: False=failure, True=ok
+problems: List of problems, each a dict:
+'type'; error or warning
+'msg': text message
+'file' : filename
+'line': line number
+errors: Number of errors
+warnings: Number of warnings
+checks: Number of checks
+lines: Number of lines
+stdout: Full output of checkpatch
+"""
 return checkpatch.check_patch(self.get_patch(), show_types=True)
 
 
-- 
2.42.0.655.g421f12c284-goog

[PATCH v2 1/2] checkpatch.pl: Make common.h check boarder

[Simon Glass]

From: Tom Rini 

At this point in time we should not add common.h to any new files, so
make checkpatch.pl complain.

Signed-off-by: Tom Rini 
Signed-off-by: Simon Glass 
---

Changes in v2:
- Only check one header at a time in checkpatch.pl

 scripts/checkpatch.pl   | 10 --
 tools/patman/test_checkpatch.py |  9 +++--
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 488d73a0ed77..b8eb57f38c74 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2636,12 +2636,18 @@ sub u_boot_line {
  "All CONFIG symbols are managed by Kconfig\n" . 
$herecurr);
}
 
-   # Don't put common.h and dm.h in header files
-   if ($realfile =~ /\.h$/ && $rawline =~ 
/^\+#include\s*<(common|dm)\.h>*/) {
+   # Don't put dm.h in header files
+   if ($realfile =~ /\.h$/ && $rawline =~ /^\+#include\s**/) {
ERROR("BARRED_INCLUDE_IN_HDR",
  "Avoid including common.h and dm.h in header files\n" . 
$herecurr);
}
 
+   # Don't add common.h to files
+   if ($rawline =~ /^\+#include\s**/) {
+   ERROR("BARRED_INCLUDE_COMMON_H",
+ "Do not add common.h to files\n" . $herecurr);
+   }
+
# Do not disable fdt / initrd relocation
if ($rawline =~ /^\+.*(fdt|initrd)_high=0x/) {
ERROR("DISABLE_FDT_OR_INITRD_RELOC",
diff --git a/tools/patman/test_checkpatch.py b/tools/patman/test_checkpatch.py
index a8bb364e42b2..f8117460ced2 100644
--- a/tools/patman/test_checkpatch.py
+++ b/tools/patman/test_checkpatch.py
@@ -238,7 +238,7 @@ index 000..2234c87
 + * passed to kernel in the ATAGs
 + */
 +
-+#include 
++#include 
 +
 +struct bootstage_record {
 +  u32 time_us;
@@ -401,10 +401,15 @@ index 000..2234c87
 def test_barred_include_in_hdr(self):
 """Test for using a barred include in a header file"""
 pm = PatchMaker()
-#pm.add_line('include/myfile.h', '#include ')
 pm.add_line('include/myfile.h', '#include ')
 self.check_single_message(pm, 'BARRED_INCLUDE_IN_HDR', 'error')
 
+def test_barred_include_common_h(self):
+"""Test for adding common.h to a file"""
+pm = PatchMaker()
+pm.add_line('include/myfile.h', '#include ')
+self.check_single_message(pm, 'BARRED_INCLUDE_COMMON_H', 'error')
+
 def test_config_is_enabled_config(self):
 """Test for accidental CONFIG_IS_ENABLED(CONFIG_*) calls"""
 pm = PatchMaker()
-- 
2.42.0.655.g421f12c284-goog

Re: U-Boot 2023.10 does not boot from uSD on RPi4

[Peter Robinson]

On Fri, Oct 13, 2023 at 5:09 PM Peter Robinson  wrote:
>
> On Tue, Oct 10, 2023 at 3:58 PM Simon Glass  wrote:
> >
> > Hi,
> >
> > On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet  
> > wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Peter Robinson 
> > > > Sent: Tuesday, October 10, 2023 12:22 PM
> > > > To: Guillaume Gardet 
> > > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass
> > > > ; u-boot@lists.denx.de
> > > > Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4
> > > >
> > > > On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet
> > > >  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > U-Boot 2023.10 does not boot from uSD on RPi4.
> > > > > This has been found on openSUSE Tumbleweed. The only diff we need is:
> > > > >   -CONFIG_OF_EMBED=y
> > > > >   +CONFIG_OF_BOARD=y
> > > > > To use firmware provided Device Tree. But that should not affect the 
> > > > > mmc
> > > > behavior too much, I think.
> > > >
> > > > I've been booting Fedora fine on a RPi4 BUT there's issues with the 
> > > > display
> > > > turning off [1] when the accelerated display modules load
> > > > (vc4) as a result of this patch set. Can you confirm if that's the same 
> > > > problem
> > > > you're seeing?
> > >
> > > No, that's not my problem. My issue is grub was not loaded by u-boot from 
> > > uSD.
> > > It seems more like Simon's problem: 
> > > https://lists.denx.de/pipermail/u-boot/2023-October/533162.html
> > >
> > > @Simon, can you check if the patch below fixes your boot problem on RPi4, 
> > > please?
> >
> > This has been reported at least twice before. There is a fix [2] which is 
> > in my queue to apply.
>
> Looking at that patch it scans the first 3 devices, how does it handle
> non storage devices like SDIO WiFi modules? It shouldn't be trying to
> scan those.

And in the case of the RPi the other enabled SDHCI interface is the
WiFi, why would we even be trying to boot off a non storage interface,
something here just feels broken/wrong in general.

The patch does make it work with pure upstream, and I'm not sure why
the Fedora build boots it fine out of the box, but the patch just
feels like it's hacking around some other underlying problem with
bootstd, we didn't have this problem with the previous method and
trying to boot off non storage interfaces feels like it could cause
other problems.

Re: U-Boot 2023.10 does not boot from uSD on RPi4

[Peter Robinson]

On Tue, Oct 10, 2023 at 3:58 PM Simon Glass  wrote:
>
> Hi,
>
> On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet  
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Peter Robinson 
> > > Sent: Tuesday, October 10, 2023 12:22 PM
> > > To: Guillaume Gardet 
> > > Cc: mbrug...@suse.com; Ivan Ivanov ; Simon Glass
> > > ; u-boot@lists.denx.de
> > > Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4
> > >
> > > On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet
> > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > U-Boot 2023.10 does not boot from uSD on RPi4.
> > > > This has been found on openSUSE Tumbleweed. The only diff we need is:
> > > >   -CONFIG_OF_EMBED=y
> > > >   +CONFIG_OF_BOARD=y
> > > > To use firmware provided Device Tree. But that should not affect the mmc
> > > behavior too much, I think.
> > >
> > > I've been booting Fedora fine on a RPi4 BUT there's issues with the 
> > > display
> > > turning off [1] when the accelerated display modules load
> > > (vc4) as a result of this patch set. Can you confirm if that's the same 
> > > problem
> > > you're seeing?
> >
> > No, that's not my problem. My issue is grub was not loaded by u-boot from 
> > uSD.
> > It seems more like Simon's problem: 
> > https://lists.denx.de/pipermail/u-boot/2023-October/533162.html
> >
> > @Simon, can you check if the patch below fixes your boot problem on RPi4, 
> > please?
>
> This has been reported at least twice before. There is a fix [2] which is in 
> my queue to apply.

Looking at that patch it scans the first 3 devices, how does it handle
non storage devices like SDIO WiFi modules? It shouldn't be trying to
scan those.

> Regarding the display problem, I got my rpi4 running again and Fedora 
> installed, but I won't get back to it until the end of the week as I'm at 
> osfc.
>
> Regards,
> Simon
>
> >
> > Thanks,
> > Guillaume
> >
>
> [2] 
> https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/
>
> > >
> > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html
> > >
> > > > 'git bisect' points to:
> > > > **
> > > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9
> > > > Author: Simon Glass 
> > > > Date:   Thu Jul 27 15:54:28 2023 -0600
> > > >
> > > > arm: rpi: Switch to standard boot
> > > >
> > > > Drop use of the distro scripts and use standard boot instead.
> > > >
> > > > We don't need to specify the mmc devices individually, since they 
> > > > are
> > > > used in order from 0 to 2, and standard boot uses that order anyway.
> > > >
> > > > Signed-off-by: Simon Glass 
> > > > **
> > > >
> > > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 
> > > > nor RPi
> > > Zero 2 W):
> > > > **
> > > > diff --git a/board/raspberrypi/rpi/rpi.env
> > > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644
> > > > --- a/board/raspberrypi/rpi/rpi.env
> > > > +++ b/board/raspberrypi/rpi/rpi.env
> > > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250
> > > >  fdt_addr_r=0x0260
> > > >  ramdisk_addr_r=0x0270
> > > >
> > > > -boot_targets=mmc usb pxe dhcp
> > > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp
> > > > **
> > > >
> > > > So, the comment from Simon " We don't need to specify the mmc devices
> > > individually, since they are used in order from 0 to 2, and standard boot 
> > > uses that
> > > order anyway" seems wrong for the RPi4 case.
> > > >
> > > > Cheers,
> > > > Guillaume
> > > >
> > > > IMPORTANT NOTICE: The contents of this email and any attachments are
> > > confidential and may also be privileged. If you are not the intended 
> > > recipient,
> > > please notify the sender immediately and do not disclose the contents to 
> > > any
> > > other person, use it for any purpose, or store or copy the information in 
> > > any
> > > medium. Thank you.
> > IMPORTANT NOTICE: The contents of this email and any attachments are 
> > confidential and may also be privileged. If you are not the intended 
> > recipient, please notify the sender immediately and do not disclose the 
> > contents to any other person, use it for any purpose, or store or copy the 
> > information in any medium. Thank you.

Re: [PATCH v3 2/2] dfu: mtd: mark bad the MTD block on erase error

[Dario Binacchi]

Hello Patrick,

On Mon, Jun 05, 2023 at 09:52:08AM +0200, Patrick Delaunay wrote:
> In the MTD DFU backend, it is needed to mark the NAND block bad when the
> erase failed with the -EIO error, as it is done in UBI and JFFS2 code.
> 
> This operation is not done in the MTD framework, but the bad block
> tag (in BBM or in BBT) is required to avoid to write data on this block
> in the next DFU_OP_WRITE loop in mtd_block_op(): the code skip the bad
> blocks, tested by mtd_block_isbad().
> 
> Without this patch, when the NAND block become bad on DFU write operation
> - low probability on new NAND - the DFU write operation will always failed
> because the failing block is never marked bad.
> 
> This patch also adds a test to avoid to request an erase operation on a
> block already marked bad; this test is not performed in MTD framework
> in mtd_erase().
> 
> Reviewed-by: Michael Trimarchi 
> Signed-off-by: Patrick Delaunay 

Applied to nand-next,
thanks and regards,

Dario

> ---
> 
> Changes in v3:
> - Split serie with trace fix and support of bad block in MTD erase
> - Fix trace for "bbt reserved" when mtd_block_isbad return 2
> 
> Changes in v2:
> - fix mtd_block_isbad offset parameter for erase check
> - Add trace when bad block are skipped in erase loop
> - Add remaining byte in trace "Limit reached"
> 
>  drivers/dfu/dfu_mtd.c | 30 ++
>  1 file changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
> index b764f091786d..271d485d1c9a 100644
> --- a/drivers/dfu/dfu_mtd.c
> +++ b/drivers/dfu/dfu_mtd.c
> @@ -91,22 +91,36 @@ static int mtd_block_op(enum dfu_op op, struct dfu_entity 
> *dfu,
>   return -EIO;
>   }
>  
> + /* Skip the block if it is bad, don't erase it again */
> + ret = mtd_block_isbad(mtd, erase_op.addr);
> + if (ret) {
> + printf("Skipping %s at 0x%08llx\n",
> +ret == 1 ? "bad block" : "bbt reserved",
> +erase_op.addr);
> + erase_op.addr += mtd->erasesize;
> + continue;
> + }
> +
>   ret = mtd_erase(mtd, _op);
>  
>   if (ret) {
> - /* Abort if its not a bad block error */
> - if (ret != -EIO) {
> - printf("Failure while erasing at offset 
> 0x%llx\n",
> -erase_op.fail_addr);
> - return 0;
> + /* If this is not -EIO, we have no idea what to 
> do. */
> + if (ret == -EIO) {
> + printf("Marking bad block at 0x%08llx 
> (%d)\n",
> +erase_op.fail_addr, ret);
> + ret = mtd_block_markbad(mtd, 
> erase_op.addr);
> + }
> + /* Abort if it is not -EIO or can't mark bad */
> + if (ret) {
> + printf("Failure while erasing at offset 
> 0x%llx (%d)\n",
> +erase_op.fail_addr, ret);
> + return ret;
>   }
> - printf("Skipping bad block at 0x%08llx\n",
> -erase_op.addr);
>   } else {
>   remaining -= mtd->erasesize;
>   }
>  
> - /* Continue erase behind bad block */
> + /* Continue erase behind the current block */
>   erase_op.addr += mtd->erasesize;
>   }
>   }

Re: [PATCH v3 1/2] dfu: mtd: fix the trace when limit is reached

[Dario Binacchi]

Hello Patrick,

On Mon, Jun 05, 2023 at 09:52:07AM +0200, Patrick Delaunay wrote:
> The offset variable = 'off' used in the error trace when limit is reach
> on erase operation is incorect as 'erase_op.addr' is used in the loop.
> This patch corrects the copy paste issue between the erase loop and
> the write loop.
> 
> This patch also adds the 'remaining' information to allow to debug of
> limit issues.
> 
> Fixes: 6015af28ee6d ("dfu: add backend for MTD device")
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Patrice Chotard 

Applied to nand-next,
thanks and regards

Dario
> ---
> 
> (no changes since v1)
> 
>  drivers/dfu/dfu_mtd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
> index c7075f12eca9..b764f091786d 100644
> --- a/drivers/dfu/dfu_mtd.c
> +++ b/drivers/dfu/dfu_mtd.c
> @@ -86,8 +86,8 @@ static int mtd_block_op(enum dfu_op op, struct dfu_entity 
> *dfu,
>  
>   while (remaining) {
>   if (erase_op.addr + remaining > lim) {
> - printf("Limit reached 0x%llx while erasing at 
> offset 0x%llx\n",
> -lim, off);
> + printf("Limit reached 0x%llx while erasing at 
> offset 0x%llx, remaining 0x%llx\n",
> +lim, erase_op.addr, remaining);
>   return -EIO;
>   }
>  

Re: [PATCH 1/7] checkpatch.pl: Make common.h check boarder

[Simon Glass]

Hi Tom,

On Fri, 13 Oct 2023 at 08:16, Tom Rini  wrote:
>
> On Fri, Oct 13, 2023 at 08:15:00AM -0700, Simon Glass wrote:
> > On Thu, 12 Oct 2023 at 16:04, Tom Rini  wrote:
> > >
> > > At this point in time we should not add common.h to any new files, so
> > > make checkpatch.pl complain.
> > >
> > > Signed-off-by: Tom Rini 
> > > ---
> > > Cc: Simon Glass 
> > >
> > > This causes a bunch of patman tests, for checkpatch, to now fail and I
> > > don't really understand why, at all.  And that was before I added a test
> > > for the new error, which I had hoped would clear up the problem.
> > > ---
> > >  scripts/checkpatch.pl   | 8 +++-
> > >  tools/patman/test_checkpatch.py | 7 ++-
> > >  2 files changed, 13 insertions(+), 2 deletions(-)
> >
> > Reviewed-by: Simon Glass 
>
> It can't be reviewed, as I can't actually apply it, as it causes CI to
> fail as patman tests now fail, and I don't know why.

Well the code looks OK to me. I will take a look.

Regards,
Simon

Re: [PATCH 4/7] m68k: Remove common.h usage

[Tom Rini]

On Fri, Oct 13, 2023 at 08:14:57AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 12 Oct 2023 at 16:11, Tom Rini  wrote:
> >
> > We can remove common.h from most cases of the code here, and only a few
> > places need an additional header instead.
> >
> > Signed-off-by: Tom Rini 
> > ---
> > Cc: Angelo Dureghello 
> > ---
> >  arch/m68k/cpu/mcf523x/cpu.c | 1 -
> >  arch/m68k/cpu/mcf523x/cpu_init.c| 1 -
> >  arch/m68k/cpu/mcf523x/interrupts.c  | 1 -
> >  arch/m68k/cpu/mcf523x/speed.c   | 1 -
> >  arch/m68k/cpu/mcf52x2/cpu.c | 1 -
> >  arch/m68k/cpu/mcf52x2/cpu_init.c| 3 +--
> >  arch/m68k/cpu/mcf52x2/interrupts.c  | 1 -
> >  arch/m68k/cpu/mcf52x2/speed.c   | 1 -
> >  arch/m68k/cpu/mcf530x/cpu.c | 1 -
> >  arch/m68k/cpu/mcf530x/cpu_init.c| 1 -
> >  arch/m68k/cpu/mcf530x/interrupts.c  | 1 -
> >  arch/m68k/cpu/mcf530x/speed.c   | 1 -
> >  arch/m68k/cpu/mcf532x/cpu.c | 1 -
> >  arch/m68k/cpu/mcf532x/cpu_init.c| 1 -
> >  arch/m68k/cpu/mcf532x/interrupts.c  | 1 -
> >  arch/m68k/cpu/mcf532x/speed.c   | 1 -
> >  arch/m68k/cpu/mcf5445x/cpu.c| 1 -
> >  arch/m68k/cpu/mcf5445x/cpu_init.c   | 1 -
> >  arch/m68k/cpu/mcf5445x/dspi.c   | 1 -
> >  arch/m68k/cpu/mcf5445x/interrupts.c | 1 -
> >  arch/m68k/cpu/mcf5445x/speed.c  | 1 -
> >  arch/m68k/cpu/mcf5445x/start.S  | 1 -
> >  arch/m68k/include/asm/immap.h   | 1 +
> >  arch/m68k/include/asm/immap_520x.h  | 1 +
> >  arch/m68k/include/asm/immap_5235.h  | 1 +
> >  arch/m68k/include/asm/immap_5272.h  | 1 +
> >  arch/m68k/include/asm/immap_5275.h  | 1 +
> >  arch/m68k/include/asm/immap_5282.h  | 1 +
> >  arch/m68k/include/asm/immap_5301x.h | 1 +
> >  arch/m68k/include/asm/immap_5307.h  | 2 ++
> >  arch/m68k/include/asm/immap_5329.h  | 1 +
> >  arch/m68k/include/asm/immap_5441x.h | 1 +
> >  arch/m68k/lib/bdinfo.c  | 3 ++-
> >  arch/m68k/lib/bootm.c   | 1 -
> >  arch/m68k/lib/cache.c   | 2 +-
> >  arch/m68k/lib/fec.c | 2 +-
> >  arch/m68k/lib/interrupts.c  | 2 +-
> >  arch/m68k/lib/time.c| 1 -
> >  arch/m68k/lib/traps.c   | 1 -
> >  39 files changed, 17 insertions(+), 30 deletions(-)
> 
> I just wondered what we do about '#ifdef CFG_...' which presumably is
> not included without common.h ? How does that work?

The first header in common.h is config.h which is where many CFG_...
instances are.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues

[Tom Rini]

On Fri, Oct 13, 2023 at 11:11:04AM -0400, Da Xue wrote:
> On Fri, Oct 13, 2023 at 7:47 AM Marek Vasut  wrote:
> >
> > On 10/13/23 06:53, Venkatesh Yadav Abbarapu wrote:
> > > The xhci host controller driver trying to queue the URB's and it is
> > > getting halted at the endpoint, thereby hitting the BUG_ON's.
> > > Mostly these kind of random issues are seen on faulty boards.
> > > Removing these BUG_ON's from the U-Boot xhci code, as in Linux kernel
> > > xhci code BUG_ON/BUG's are removed entirely.
> > > Please also note, that BUG_ON() is not recommended any more in the Linux
> > > kernel.
> > > Similar issue has been observed on TI AM437x board and they created a 
> > > patch
> > > in Linux kernel as below
> > > https://patches.linaro.org/project/linux-usb/patch/1390250711-25840-1-git-send-email-ba...@ti.com/
> > >
> > > Signed-off-by: Venkatesh Yadav Abbarapu 
> >
> > I already explained to Xilinx how to sync the driver with Linux and why
> > this is needed to move forward, multiple times, and even provided a
> > script which does most of the work automatically, since it is basically
> > automated process. Xilinx did not even bother to test the script and
> > provide any feedback.
> >
> > Until that happens, this patch is rejected.
> 
> This patch also causes all of the USB devices on certain platforms to
> not be detected:
> 
> scanning bus usb@c900 for devices... Device not responding to set address.
> 
>   USB device not accepting new address (error=8000)

Yes, we are stuck at the impasse where the custodian is asking for
someone to try and do the re-sync, and everyone else will assist with
testing on other platforms, but the re-sync hasn't happened.  Can we
please get someone from AMD to attempt the re-sync?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 7/7] rockchip: doc: add rkmtd.rst

[Simon Glass]

On Thu, 12 Oct 2023 at 13:52, Johan Jonker  wrote:
>
> Add documention for Rockchip rkmtd virtual block device.
>
> Signed-off-by: Johan Jonker 
> ---
>
> Changed V3:
>   New patch
> ---
>  doc/board/rockchip/index.rst |   1 +
>  doc/board/rockchip/rkmtd.rst | 105 +++
>  2 files changed, 106 insertions(+)
>  create mode 100644 doc/board/rockchip/rkmtd.rst
>

Reviewed-by: Simon Glass 

Re: [PATCH 1/7] checkpatch.pl: Make common.h check boarder

[Tom Rini]

On Fri, Oct 13, 2023 at 08:15:00AM -0700, Simon Glass wrote:
> On Thu, 12 Oct 2023 at 16:04, Tom Rini  wrote:
> >
> > At this point in time we should not add common.h to any new files, so
> > make checkpatch.pl complain.
> >
> > Signed-off-by: Tom Rini 
> > ---
> > Cc: Simon Glass 
> >
> > This causes a bunch of patman tests, for checkpatch, to now fail and I
> > don't really understand why, at all.  And that was before I added a test
> > for the new error, which I had hoped would clear up the problem.
> > ---
> >  scripts/checkpatch.pl   | 8 +++-
> >  tools/patman/test_checkpatch.py | 7 ++-
> >  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Simon Glass 

It can't be reviewed, as I can't actually apply it, as it causes CI to
fail as patman tests now fail, and I don't know why.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 4/7] m68k: Remove common.h usage

[Simon Glass]

Hi Tom,

On Thu, 12 Oct 2023 at 16:11, Tom Rini  wrote:
>
> We can remove common.h from most cases of the code here, and only a few
> places need an additional header instead.
>
> Signed-off-by: Tom Rini 
> ---
> Cc: Angelo Dureghello 
> ---
>  arch/m68k/cpu/mcf523x/cpu.c | 1 -
>  arch/m68k/cpu/mcf523x/cpu_init.c| 1 -
>  arch/m68k/cpu/mcf523x/interrupts.c  | 1 -
>  arch/m68k/cpu/mcf523x/speed.c   | 1 -
>  arch/m68k/cpu/mcf52x2/cpu.c | 1 -
>  arch/m68k/cpu/mcf52x2/cpu_init.c| 3 +--
>  arch/m68k/cpu/mcf52x2/interrupts.c  | 1 -
>  arch/m68k/cpu/mcf52x2/speed.c   | 1 -
>  arch/m68k/cpu/mcf530x/cpu.c | 1 -
>  arch/m68k/cpu/mcf530x/cpu_init.c| 1 -
>  arch/m68k/cpu/mcf530x/interrupts.c  | 1 -
>  arch/m68k/cpu/mcf530x/speed.c   | 1 -
>  arch/m68k/cpu/mcf532x/cpu.c | 1 -
>  arch/m68k/cpu/mcf532x/cpu_init.c| 1 -
>  arch/m68k/cpu/mcf532x/interrupts.c  | 1 -
>  arch/m68k/cpu/mcf532x/speed.c   | 1 -
>  arch/m68k/cpu/mcf5445x/cpu.c| 1 -
>  arch/m68k/cpu/mcf5445x/cpu_init.c   | 1 -
>  arch/m68k/cpu/mcf5445x/dspi.c   | 1 -
>  arch/m68k/cpu/mcf5445x/interrupts.c | 1 -
>  arch/m68k/cpu/mcf5445x/speed.c  | 1 -
>  arch/m68k/cpu/mcf5445x/start.S  | 1 -
>  arch/m68k/include/asm/immap.h   | 1 +
>  arch/m68k/include/asm/immap_520x.h  | 1 +
>  arch/m68k/include/asm/immap_5235.h  | 1 +
>  arch/m68k/include/asm/immap_5272.h  | 1 +
>  arch/m68k/include/asm/immap_5275.h  | 1 +
>  arch/m68k/include/asm/immap_5282.h  | 1 +
>  arch/m68k/include/asm/immap_5301x.h | 1 +
>  arch/m68k/include/asm/immap_5307.h  | 2 ++
>  arch/m68k/include/asm/immap_5329.h  | 1 +
>  arch/m68k/include/asm/immap_5441x.h | 1 +
>  arch/m68k/lib/bdinfo.c  | 3 ++-
>  arch/m68k/lib/bootm.c   | 1 -
>  arch/m68k/lib/cache.c   | 2 +-
>  arch/m68k/lib/fec.c | 2 +-
>  arch/m68k/lib/interrupts.c  | 2 +-
>  arch/m68k/lib/time.c| 1 -
>  arch/m68k/lib/traps.c   | 1 -
>  39 files changed, 17 insertions(+), 30 deletions(-)

I just wondered what we do about '#ifdef CFG_...' which presumably is
not included without common.h ? How does that work?

Regards,
Simon

Re: [PATCH 1/7] checkpatch.pl: Make common.h check boarder

[Simon Glass]

On Thu, 12 Oct 2023 at 16:04, Tom Rini  wrote:
>
> At this point in time we should not add common.h to any new files, so
> make checkpatch.pl complain.
>
> Signed-off-by: Tom Rini 
> ---
> Cc: Simon Glass 
>
> This causes a bunch of patman tests, for checkpatch, to now fail and I
> don't really understand why, at all.  And that was before I added a test
> for the new error, which I had hoped would clear up the problem.
> ---
>  scripts/checkpatch.pl   | 8 +++-
>  tools/patman/test_checkpatch.py | 7 ++-
>  2 files changed, 13 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 2/7] include: Add in a few places

[Simon Glass]

On Thu, 12 Oct 2023 at 16:04, Tom Rini  wrote:
>
> These files references a number of types that are defined in
>  (and so forth), so include it here rather than rely on
> indirect inclusion.
>
> Signed-off-by: Tom Rini 
> ---
> Cc: Simon Glass 
> ---
>  include/bootstage.h | 1 +
>  include/cache.h | 2 ++
>  include/cpu.h   | 2 ++
>  3 files changed, 5 insertions(+)
>

Reviewed-by: Simon Glass 

Re: [PATCH v3 5/7] rockchip: cmd: add rkmtd command

[Simon Glass]

On Thu, 12 Oct 2023 at 13:52, Johan Jonker  wrote:
>
> The command rkmtd creates a virtual block device to transfer
> Rockchip boot block data to and from NAND with block orientated
> tools like "ums" and "rockusb".
>
> It uses the Rockchip MTD driver to scan for boot blocks and copies
> data from the first block in a GPT formated virtual disk.
> Data must be written in U-boot "idbloader.img" format and start at
> partition "loader1" offset 64. The data header is parsed
> for length and offset. When the last sector is received
> it erases up to 5 erase blocks on NAND and writes bootblocks
> in a pattern depending on the NAND ID. Data is then verified.
> When a block turns out bad the block header is discarded.
>
> Signed-off-by: Johan Jonker 
> ---
>
> Changed V3:
>   Split driver from command
>   Split header
>   Restyle
> ---
>  cmd/Kconfig  |   8 ++
>  cmd/Makefile |   1 +
>  cmd/rkmtd.c  | 204 +++
>  3 files changed, 213 insertions(+)
>  create mode 100644 cmd/rkmtd.c

Reviewed-by: Simon Glass 

Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues

[Da Xue]

On Fri, Oct 13, 2023 at 7:47 AM Marek Vasut  wrote:
>
> On 10/13/23 06:53, Venkatesh Yadav Abbarapu wrote:
> > The xhci host controller driver trying to queue the URB's and it is
> > getting halted at the endpoint, thereby hitting the BUG_ON's.
> > Mostly these kind of random issues are seen on faulty boards.
> > Removing these BUG_ON's from the U-Boot xhci code, as in Linux kernel
> > xhci code BUG_ON/BUG's are removed entirely.
> > Please also note, that BUG_ON() is not recommended any more in the Linux
> > kernel.
> > Similar issue has been observed on TI AM437x board and they created a patch
> > in Linux kernel as below
> > https://patches.linaro.org/project/linux-usb/patch/1390250711-25840-1-git-send-email-ba...@ti.com/
> >
> > Signed-off-by: Venkatesh Yadav Abbarapu 
>
> I already explained to Xilinx how to sync the driver with Linux and why
> this is needed to move forward, multiple times, and even provided a
> script which does most of the work automatically, since it is basically
> automated process. Xilinx did not even bother to test the script and
> provide any feedback.
>
> Until that happens, this patch is rejected.

This patch also causes all of the USB devices on certain platforms to
not be detected:

scanning bus usb@c900 for devices... Device not responding to set address.

  USB device not accepting new address (error=8000)

Pull request efi-2024-01-rc1

[Heinrich Schuchardt]

Dear Tom,

The following changes since commit 997bef3c6d22d12c7fd092fb831bf94d114c9f6f:

  Merge branch '2023-10-11-port-gen_compile_commands_py' (2023-10-11
13:25:01 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2024-01-rc1

for you to fetch changes up to c1ab04626d6b05c6e82dfe4d97d3f62f7310d612:

  efi_loader: use well-known guid for auto-created boot option
(2023-10-12 08:32:27 +0200)

Gitlab CI showed no issues:
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/18093


Pull request efi-2024-01-rc1

Documentation:

* Bump urllib3 version
* Migrate Renesas board docs to rst
* Link an introduction video

UEFI

* Use same GUID as EDK II for auto-created boot options
* Clean up BitBlt test


Heinrich Schuchardt (1):
  efi_selftest: BitBlt test

Masahisa Kojima (1):
  efi_loader: use well-known guid for auto-created boot option

Paul Barker (1):
  doc: Migrate Renesas board docs to rst

Simon Glass (1):
  doc: Add a short intro video

Tom Rini (1):
  sphinx: Bump urllib3 version

Weizhao Ouyang (1):
  cyclic: doc: Update documentation for CONFIG_CYCLIC_MAX_CPU_TIME_US

 doc/README.rmobile |  99 -
 doc/board/renesas/renesas.rst  | 255
+
 doc/develop/cyclic.rst |  10 +-
 doc/learn/talks.rst|   3 +
 doc/sphinx/requirements.txt|   2 +-
 include/efi_loader.h   |   4 +-
 lib/efi_selftest/efi_selftest_bitblt.c |  83 ---
 7 files changed, 298 insertions(+), 158 deletions(-)
 delete mode 100644 doc/README.rmobile

Re: [PATCH v2] i2c: designware_i2c: adjust timing calculation

[Heiko Schocher]

Hello Heinrich,

On 13.10.23 15:09, Heinrich Schuchardt wrote:
> In SPL probing of the designware_i2c device on the StarFive VisionFive 2
> board fails with
> 
> dw_i2c: mode 0, ic_clk 100, speed 10,
> period 10 rise 1 fall 1 tlow 5 thigh 4 spk 0
> dw_i2c: bad counts. hcnt = -4 lcnt = 4
> device_probe: i2c@1205 failed to probe -22
> 
> When changing the offset for the high phase from 7 to 3 the device is
> probed correctly. This now matches the value from the Linux driver.
> 
> Without this fix the memory size of the StarFive VisionFive 2 board cannot
> be read from EEPROM.
> 
> Fixes: e71b6f6622d6 ("i2c: designware_i2c: Rewrite timing calculation")
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   use the same timing offset at Linux
>   provide a descriptive comment for the constant
> ---
>  drivers/i2c/designware_i2c.c | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)

Many thanks for this update!

Reviewed-by: Heiko Schocher 

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Erika Unter
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] .gitignore: ignore misc include, simple-bin, and tools/generated build artifacts

[John Clark]

make rock5b-rk3588_defconfig
make
git status

before
~~~
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Untracked files:
  (use "git add ..." to include in what will be committed)
include/autoconf.mk
include/autoconf.mk.dep
include/config.h
mkimage-in-simple-bin-spi.mkimage-rockchip-tpl
mkimage-in-simple-bin-spi.mkimage-u-boot-spl
mkimage-in-simple-bin.mkimage-rockchip-tpl
mkimage-in-simple-bin.mkimage-u-boot-spl
simple-bin-spi.map
simple-bin.fit.fit
simple-bin.fit.itb
simple-bin.map
tools/generated/

after
~~~
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

Signed-off-by: John Clark 

---

 .gitignore | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index 84051b7bfd..a1a79e92fe 100644
--- a/.gitignore
+++ b/.gitignore
@@ -44,8 +44,10 @@ fit-dtb.blob*
 /MLO*
 /SPL*
 /System.map
-/u-boot*
 /boards.cfg
+/mkimage-in-simple-bin*
+/simple-bin*
+/u-boot*
 /*.log
 
 #
@@ -59,12 +61,15 @@ fit-dtb.blob*
 # Generated files
 #
 /spl/
+/tools/generated/
 /tpl/
 /defconfig
 
 #
 # Generated include files
 #
+/include/autoconf.mk*
+/include/config.h
 /include/config/
 /include/generated/
 
-- 
2.42.0

[PATCH] Makefile: remove misc include and simple-bin build artifacts on clean

[John Clark]

make rock5b-rk3588_defconfig
make
make clean
git status

before
~~~
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add ..." to include in what will be committed)
include/autoconf.mk
include/autoconf.mk.dep
include/config.h
mkimage-in-simple-bin-spi.mkimage-rockchip-tpl
mkimage-in-simple-bin-spi.mkimage-u-boot-spl
mkimage-in-simple-bin.mkimage-rockchip-tpl
mkimage-in-simple-bin.mkimage-u-boot-spl
simple-bin.fit.fit
simple-bin.fit.itb

after
~~~
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

Signed-off-by: John Clark 

---

 Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index b204a50043..7ba4ad45c8 100644
--- a/Makefile
+++ b/Makefile
@@ -2156,15 +2156,15 @@ CLEAN_DIRS  += $(MODVERDIR) \
   $(foreach d, spl tpl vpl, $(patsubst %,$d/%, \
$(filter-out include, $(shell ls -1 $d 2>/dev/null
 
-CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h \
-  include/generated/env.* drivers/video/u_boot_logo.S \
+CLEAN_FILES += include/autoconf.mk* include/bmp_logo.h include/bmp_logo_data.h 
\
+  include/config.h include/generated/env.* 
drivers/video/u_boot_logo.S \
   tools/version.h u-boot* MLO* SPL System.map fit-dtb.blob* \
   u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log \
   lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \
   idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \
   mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
   itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
-  mkimage.rom.mkimage rom.map simple-bin.map simple-bin-spi.map \
+  mkimage.rom.mkimage mkimage-in-simple-bin* rom.map simple-bin* \
   idbloader-spi.img lib/efi_loader/helloworld_efi.S
 
 # Directories & files removed with 'make mrproper'
-- 
2.42.0

[PATCH v2] i2c: designware_i2c: adjust timing calculation

[Heinrich Schuchardt]

In SPL probing of the designware_i2c device on the StarFive VisionFive 2
board fails with

dw_i2c: mode 0, ic_clk 100, speed 10,
period 10 rise 1 fall 1 tlow 5 thigh 4 spk 0
dw_i2c: bad counts. hcnt = -4 lcnt = 4
device_probe: i2c@1205 failed to probe -22

When changing the offset for the high phase from 7 to 3 the device is
probed correctly. This now matches the value from the Linux driver.

Without this fix the memory size of the StarFive VisionFive 2 board cannot
be read from EEPROM.

Fixes: e71b6f6622d6 ("i2c: designware_i2c: Rewrite timing calculation")

Signed-off-by: Heinrich Schuchardt 
---
v2:
use the same timing offset at Linux
provide a descriptive comment for the constant
---
 drivers/i2c/designware_i2c.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index e54de42abc..215ce010cb 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -24,6 +24,17 @@
  */
 #define DW_I2C_COMP_TYPE   0x44570140
 
+/*
+ * This constant is used to calculate when during the clock high phase the data
+ * bit shall be read. The value was copied from the Linux v6.5 function
+ * i2c_dw_scl_hcnt() which provides the following explanation:
+ *
+ * "This is just an experimental rule: the tHD;STA period turned out to be
+ * proportinal to (_HCNT + 3). With this setting, we could meet both tHIGH and
+ * tHD;STA timing specs."
+ */
+#define T_HD_STA_OFFSET 3
+
 static int dw_i2c_enable(struct i2c_regs *i2c_base, bool enable)
 {
u32 ena = enable ? IC_ENABLE_0B : 0;
@@ -155,10 +166,10 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, enum 
i2c_speed_mode mode,
 
/*
 * Back-solve for hcnt and lcnt according to the following equations:
-* SCL_High_time = [(HCNT + IC_*_SPKLEN + 7) * ic_clk] + SCL_Fall_time
+* SCL_High_time = [(HCNT + IC_*_SPKLEN + T_HD_STA_OFFSET) * ic_clk] + 
SCL_Fall_time
 * SCL_Low_time = [(LCNT + 1) * ic_clk] - SCL_Fall_time + SCL_Rise_time
 */
-   hcnt = min_thigh_cnt - fall_cnt - 7 - spk_cnt;
+   hcnt = min_thigh_cnt - fall_cnt - T_HD_STA_OFFSET - spk_cnt;
lcnt = min_tlow_cnt - rise_cnt + fall_cnt - 1;
 
if (hcnt < 0 || lcnt < 0) {
@@ -170,13 +181,13 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, enum 
i2c_speed_mode mode,
 * Now add things back up to ensure the period is hit. If it is off,
 * split the difference and bias to lcnt for remainder
 */
-   tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1;
+   tot = hcnt + lcnt + T_HD_STA_OFFSET + spk_cnt + rise_cnt + 1;
 
if (tot < period_cnt) {
diff = (period_cnt - tot) / 2;
hcnt += diff;
lcnt += diff;
-   tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1;
+   tot = hcnt + lcnt + T_HD_STA_OFFSET + spk_cnt + rise_cnt + 1;
lcnt += period_cnt - tot;
}
 

Re: [PATCH 0/4] clk: imx: add i.MX93 CCF driver

[Sébastien Szymanski]

Hello,

On 7/25/23 10:08, Sébastien Szymanski wrote:

This series adds i.MX93 CCF driver, modifed from Linux kernel 6.5-rc2
and adapted for U-Boot.

Patches 2 and 3 come from NXP U-Boot.

A boot log and a dump of the clock tree are available at the following
URL:
https://pastebin.com/7WbubSXK

Alice Guo (1):
   arm: dts: imx93: add a per clock for LPUART1

Sébastien Szymanski (2):
   clk: imx: add i.MX93 CCF driver
   imx93_evk: defconfig: enable clock driver

Ye Li (1):
   serial: lpuart: Enable IPG clock



gentle ping.
Maybe someone at NXP can help review this patchset?

Regards,


  arch/arm/dts/imx93-11x11-evk-u-boot.dtsi |  23 ++
  arch/arm/dts/imx93.dtsi  |   4 +-
  board/freescale/imx93_evk/imx93_evk.c|   2 -
  configs/imx93_11x11_evk_defconfig|   2 +
  drivers/clk/imx/Kconfig  |  18 ++
  drivers/clk/imx/Makefile |   2 +
  drivers/clk/imx/clk-composite-93.c   | 142 +
  drivers/clk/imx/clk-fracn-gppll.c| 382 +++
  drivers/clk/imx/clk-gate-93.c| 148 +
  drivers/clk/imx/clk-imx93.c  | 343 
  drivers/clk/imx/clk.h|  42 +++
  drivers/serial/serial_lpuart.c   |  14 +-
  include/dt-bindings/clock/imx93-clock.h  |   6 +-
  13 files changed, 1122 insertions(+), 6 deletions(-)
  create mode 100644 drivers/clk/imx/clk-composite-93.c
  create mode 100644 drivers/clk/imx/clk-fracn-gppll.c
  create mode 100644 drivers/clk/imx/clk-gate-93.c
  create mode 100644 drivers/clk/imx/clk-imx93.c



--
Sébastien Szymanski, Armadeus Systems
Software engineer

Re: [PATCH 2/2] bootcount: Add driver model I2C driver

[Philip Oberfichtner]

Hello Heiko,

On Fri, Oct 13, 2023 at 01:28:47PM +0200, Heiko Schocher wrote:
> [...]
> > 
> > bootcount {
> > compatible = "u-boot,bootcount-i2c";
> > i2c-bus = <>;
> > address = <0x52>;
> 
> Hmm.. do we really need this here with DTS. Why not using a phandle
> to a real i2c device? Something like this for example:
> 
>   i2cbcdev = _rtc;
> 
> with
> 
>  {
> i2c_rtc: rtc@68 {
> [...]
> 
> and so there is no need for knowing the bus and address ...
> 

Yeah I agree that would be much better, but ...

> [...]
> 
> when you use a phandle, you can replace the part from reading "offset"
> with this:
> 
>   uclass_get_device_by_phandle(UCLASS_I2C, dev, "i2cbcdev", >bcdev);
> 
> of course plus error checking...

This does not work, UCLASS_I2C is used for the *bus above* the device we
actually want.

Next thing I thougt about: Why not use the UCLASS_I2C_GENERIC. But this
expects a "i2c-chip" compatible string, which our rtc or whatever device
obviously does not have.

I think using UCLASS_I2C_GENERIC might indeed be the best approach.
Maybe using something like 'device_bind_driver()'. But again, this
expects the parent device to be there already as far as I can tell.

Any suggestions?

Best regards,
Philip


> 
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct bootcount_ops bootcount_i2c_ops = {
> > +   .get = bootcount_i2c_get,
> > +   .set = bootcount_i2c_set,
> > +};
> > +
> > +static const struct udevice_id bootcount_i2c_ids[] = {
> > +   { .compatible = "u-boot,bootcount-i2c" },
> > +   { }
> > +};
> > +
> > +U_BOOT_DRIVER(bootcount_i2c) = {
> > +   .name   = "bootcount-i2c",
> > +   .id = UCLASS_BOOTCOUNT,
> > +   .priv_auto  = sizeof(struct bootcount_i2c_priv),
> > +   .probe  = bootcount_i2c_probe,
> > +   .of_match   = bootcount_i2c_ids,
> > +   .ops= _i2c_ops,
> > +};
> > 
> 
> bye,
> Heiko
> -- 
> DENX Software Engineering GmbH,  Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH 07/26] arm: imx: Check header before calling spl_load_imx_container

[Tom Rini]

On Thu, Oct 12, 2023 at 09:39:22PM -0400, Sean Anderson wrote:
> On 10/12/23 12:40, Tom Rini wrote:
> > On Wed, Oct 11, 2023 at 09:56:07PM -0400, Sean Anderson wrote:
> > > Make sure we have an IMX header before calling spl_load_imx_container,
> > > since if we don't it will fail with -ENOENT. This allows us to fall back 
> > > to
> > > legacy/raw images if they are also enabled.
> > > 
> > > To avoid too much bloat, Legacy/Raw images are disabled for the four
> > > configs which only boot from raw MMC.
> > > 
> > > Future work could include merging imx_container.h with imx8image.h, since
> > > they appear to define mostly the same structures.
> > > 
> > > Signed-off-by: Sean Anderson 
> > 
> > So, since you mention bloat, this sounds like it's making functional
> > changes here, but that's not intentional, yes?  Or to ask another way,
> > is deneb disabling features here, to save space now that it can, or
> > because they're growing "a bunch" and this reduces the growth?
> > 
> 
> This is a functional change, one which likely should have been in place from
> the start, but a functional change nonetheless. Previously, all non-IMX8 
> images
> (except FITs without FIT_FULL) would be optimized out if the only image load
> method supported IMX8 images. With this change, support for these image types
> now has an effect.
> 
> There are seven boards with SPL_LOAD_IMX_CONTAINER enabled:
> 
> imx93_11x11_evk_ld imx8qm_mek imx8qxp_mek giedi imx93_11x11_evk imx8ulp_evk 
> deneb
> 
> All of these boards also have SPL_RAW_IMAGE_SUPPORT and 
> SPL_LEGACY_IMAGE_FORMAT
> enabled as well. However, none have FIT support enabled. Of the six load 
> methods
> affected by this patch, only SPL_MMC and SPL_BOOTROM_SUPPORT are enabled with
> SPL_LOAD_IMX_CONTAINER. spl_romapi_load_image_seekable does not support legacy
> or raw images, so there is no growth. However, mmc_load_image_raw_sector does
> support loading legacy/raw images. Since these images could not have been 
> booted
> before, I have disabled support for legacy/raw images on these four boards. 
> This
> reduces bloat from around 800 bytes to around 200.

Ah, OK, thanks for explaining.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 06/11] board: ti: introduce basic board files for the am62px family

[Tom Rini]

On Thu, Oct 12, 2023 at 06:06:23PM -0500, Bryan Brattlof wrote:

> Introduce the basic files needed to support the am62px family of SoCs
> 
> Co-developed-by: Hari Hagalla 
> Signed-off-by: Hari Hagalla 
> Signed-off-by: Bryan Brattlof 
[snip]
> diff --git a/board/ti/am62px/evm.c b/board/ti/am62px/evm.c
> new file mode 100644
> index 0..44793cbed6536
> --- /dev/null
> +++ b/board/ti/am62px/evm.c
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Board specific initialization for AM62Px platforms
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int board_init(void)
> +{
> + return 0;
> +}
> +
> +int dram_init(void)
> +{
> + return fdtdec_setup_mem_size_base();
> +}
> +
> +int dram_init_banksize(void)
> +{
> + return fdtdec_setup_memory_banksize();
> +}

Similar to what I said about another platform yesterday, lets split this
up in to "base.c" and "evm.c".  The good news is that so far, I think
all of this should just be in base.c instead.  Second, here and
elsewhere don't add common.h but instead add what you need.  And
finally, for all of the new files please audit what headers you're
adding.  7 headers for 5 function prototypes is a bit much.  Thanks.

-- 
Tom


signature.asc
Description: PGP signature

[GIT PULL] xilinx patches for v2024.01-rc1 v3

[Michal Simek]

Hi Tom,

please apply to following patches to your tree. The most of them are DT chagnes 
are coming from Linux dt schema validation, fixing DT warnings W=1, sync it with 
upstream kernel
and adding missing pieces. Also new DTSes are added to described other boards. 
It most interesting are adding support for new Kria SOM Kd240 board and 
descriptions related to System Controllers which
are ZynqMP based SOCs available on Versal/Versal NET evaluation boards which are 
handling DUT resources.


There are other changes sent but I want to clean my queue to enable testing for 
it.

Thanks,
Michal

The following changes since commit 83aa0ed1e93e1ffac24888d98d37a5b04ed3fb07:

  Merge branch '2023-10-06-spl-prepare-for-universal-payload' (2023-10-06 
17:23:47 -0400)


are available in the Git repository at:

  g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git 
tags/xilinx-for-v2024.01-rc1-v3


for you to fetch changes up to 7a82bfff5ea7089905dff14e65436d23c1e5adc4:

  test/py: net: Add a test for 'pxe get' command (2023-10-10 14:57:29 +0200)


Xilinx changes for v2024.01-rc1 v3

clk:
- remove additional compatible strings for Versal NET

net:
- zynq_gem: Fix clock calculation for MDC for higher frequencies

pinctrl:
- core: Extend pinmux status buffere size
- zynqmp driver: Show also tristate configuration

test:
- add test case for pxe get

Xilinx:
- describe SelectMAP boot mode

Zynq:
- Fix nand description in DT

ZynqMP:
- DTS sync patches with kernel and also W=1 related fixes
- Add support for KD240, zcu670, e-a2197 with x-prc cards, SC revB/C with i2c
  description for other SC based boards
- k24 psu_init cleanup


Laurent Pinchart (2):
  arm64: dts: zynqmp: zcu106a: Describe DisplayPort connector
  arm64: dts: zynqmp: Add ports for the DisplayPort subsystem

Love Kumar (1):
  test/py: net: Add a test for 'pxe get' command

Michal Simek (29):
  arm64: zynqmp: Describe assigned-clocks for uarts
  arm64: zynqmp: Rename dt overlay file names from dts to dtso
  arm64: zynqmp: Remove resetin/out from K24 psu_init
  arm64: zynqmp: Describe interrupts by using macros
  arm64: xilinx: Remove address/size-cells from flash node
  arm64: xilinx: Use lower case for partition address
  arm64: zynqmp: Describe bus-width for SD card on KV260
  arm64: zynqmp: Fix Siva's email address format
  arm64: xilinx: Put ethernet phys to mdio node
  arm64: xilinx: Remove address/size-cells from gem nodes
  arm64: zynqmp: Convert kv260-revA overlay to ASCII text
  arm64: zynqmp: Sync licenses with Linux kernel
  ARM: zynq: Describe nand device in DT
  arm64: zynqmp: Aligned QSPI configuration with latest spec
  arm64: zynqmp: Add support for KD240 Kria SOM CC
  arm64: zynqmp: Remove xlnx,fclk nodes
  arm64: zynqmp: Add support for vck190 revB system controller
  arm64: zynqmp: Add x-prc-01/02/03/04/05 revA support from SC
  arm64: zynqmp: Add support for vpk120-revA
  arm64: zynqmp: Create description for generic SC (vpk120-revB)
  arm64: zynqmp: Add support for SC revC
  arm64: zynqmp: Describe i2c structures for SCs
  arm64: zynqmp: Add support for VPXA2785
  arm64: zynqmp: Add support for zcu670-revA
  arm64: zynqmp: Add support for zcu670-revB
  arm: dts: xilinx: Remove undocumented is-dual property
  arm64: zynqmp: Do not use '_' in DT node names
  Revert "clk: versal: Enable clock driver for Versal NET"
  arm64: xilinx: Do not use '_' in si5335 DT node names

Polak, Leszek (1):
  arm64: versal: Add SelectMAP boot mode identification

Tanmay Shah (1):
  arm64: dts: xilinx: zynqmp: Add RPU subsystem device node

Venkatesh Yadav Abbarapu (4):
  net: zynq_gem: Update the MDC clock divisor in the probe function
  pinctrl: Increase size of pinmux status buffer
  pinctrl: zynqmp: Display the tristate configuration for all pins
  net: phy: xilinx_phy: Get rid of using property xlnx, phy-type

 arch/arm/dts/Makefile|  20 +
 arch/arm/dts/avnet-ultra96-rev1.dts  |   2 +-
 arch/arm/dts/bitmain-antminer-s9.dts |   3 +
 arch/arm/dts/versal-mini-emmc0.dts   |   2 +-
 arch/arm/dts/versal-mini-emmc1.dts   |   2 +-
 arch/arm/dts/versal-mini-ospi.dtsi   |   2 +-
 arch/arm/dts/versal-mini-qspi.dtsi   |   2 +-
 arch/arm/dts/versal-mini.dts |   2 +-
 arch/arm/dts/zynq-cc108.dts  |   1 -
 arch/arm/dts/zynq-dlc20-rev1.0.dts   |   1 -
 arch/arm/dts/zynq-minized.dts|   1 -
 

Re: [PATCH v2 0/2] tegra_mmc: get tap and trim from dts

[Thierry Reding]

From: Thierry Reding 


On Thu, 24 Aug 2023 21:53:30 +0300, Svyatoslav Ryhel wrote:
> Default-tap and default-trim values are used for eMMC setup
> mostly on T114+ devices. As for now, those values are hardcoded
> for T210 and ignored for all other Tegra generations. Fix this
> by passing tap and trim values from dts.
> 

Applied, thanks!

[1/2] ARM: tegra210: set default-tap and default-trim values in sdhci nodes
  (no commit info)
[2/2] mmc: tegra: get default-tap and default-trim from device tree
  (no commit info)

Best regards,
-- 
Thierry Reding 

Re: [PATCH v2 00/16] General tegra and board improvements

[Thierry Reding]

From: Thierry Reding 


On Thu, 24 Aug 2023 22:25:47 +0300, Svyatoslav Ryhel wrote:
> This patchset follows Transformers, Grouper, LG X3 and Endeavoru
> bringup and contains changes from v9 of previous patchset and
> some new improvenets.
> 
> List of changes:
> - separated tf600t and p1801-t device trees since they use
>   different video path bindings
> - enabled booting from usb devices (USB > SD > eMMC)
> - fixed tf201 dock usb line binding
> - removed transformer board pmic gpios setup
> - refresh USB option converted into enter console for transformers
> - updated device trees for future DM PMIC migration
> - re-synced defconfigs
> - added base voltages setup from board for t114 same as on t30
> - adjusted ebtupdate to work with non-encrypted re-crypted devices
> - attempt to move setup of some env values to arch
> - config fragments moved to board/vendor/device/configs/ dir
>   (requires pending u-boot patch)
> 
> [...]

Applied, thanks!

[01/16] ARM: dts: p1801-t: separate from common transformers tree
(no commit info)
[02/16] ARM: dts: tf600t: separate from common transformers tree
(no commit info)
[03/16] configs: transformer_t30: support booting from USB
(no commit info)
[04/16] ARM: dts: tf201: configure dock USB phy
(no commit info)
[05/16] board: asus: transformer-t30: remove PMIC GPIOs configuration
(no commit info)
[06/16] configs: transformer_t30: convert bootmenu option
(no commit info)
[07/16] ARM: dts: transformer-t30: complete missing bindings
(no commit info)
[08/16] ARM: dts: endeavoru: complete missing bindings
(no commit info)
[09/16] ARM: dts: lg-x3: complete missing bindings
(no commit info)
[10/16] ARM: dts: grouper: complete missing bindings
(no commit info)
[11/16] configs: transformer_t30: grouper: lg-x3: endeavoru: sync defconfigs
(no commit info)
[12/16] ARM: tegra114: enable base voltages setup from board
(no commit info)
[13/16] ARM: tegra20: tegra30: support EBTUPDATE on non-encrypted devices
(no commit info)
[14/16] ARM: tegra: board2: add generic late init
(no commit info)
[15/16] board: tegra30: remove nvidia_board_late_init calls
(no commit info)
[16/16] board: asus: lg: move config fragments into device boards
(no commit info)

Best regards,
-- 
Thierry Reding 

Pull request for u-boot-nand-20230417

[Dario Binacchi]

Hello Tom,

The following changes since commit 86700279645921fb2c28c41711deb7d7ed75bc29:

  Merge branch '2023-10-12-assorted-TI-platform-updates' (2023-10-12
17:02:51 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git
tags/u-boot-nand-20231013

for you to fetch changes up to be0da1257f189c09604b01bc04a7e8411bf18e5c:

  dfu: mtd: mark bad the MTD block on erase error (2023-10-13 10:49:07 +0200)

Gitlab CI showed no issues:
https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/18106


Pull request for u-boot-nand-20231013

The first 5 patches are from Mikhail Kshevetskiy, aligning the mtd spinand
core with kernel version 5.15.43, fixing a bug on Winbond, and adding
support for Winbond W25NO2KV.

The other 2 patches are from Patrick Delaunay and they fix a bug and mark
bad the MTD block on erase error.


Mikhail Kshevetskiy (5):
  mtd/spinand: rework detect procedure for different READ_ID operation
  mtd/spinand: sync core spinand code with linux-5.10.118
  mtd/spinand: sync supported devices with linux-5.15.43
  mtd: spinand: winbond: fix flash identification
  mtd: spinand: winbond: add Winbond W25N02KV flash support

Patrick Delaunay (2):
  dfu: mtd: fix the trace when limit is reached
  dfu: mtd: mark bad the MTD block on erase error

 drivers/dfu/dfu_mtd.c |  34 --
 drivers/mtd/nand/spi/Makefile |   2 +-
 drivers/mtd/nand/spi/core.c   | 129
+-
 drivers/mtd/nand/spi/gigadevice.c | 253
--
 drivers/mtd/nand/spi/macronix.c   | 190
+
 drivers/mtd/nand/spi/micron.c | 194
++-
 drivers/mtd/nand/spi/paragon.c| 133

 drivers/mtd/nand/spi/toshiba.c| 104
+-
 drivers/mtd/nand/spi/winbond.c| 116
+++-
 include/linux/mtd/nand.h  |   5 ++-
 include/linux/mtd/spinand.h   |  97
++
 11 files changed, 927 insertions(+), 330 deletions(-)
 create mode 100644 drivers/mtd/nand/spi/paragon.c


-- 
Dario Binacchi

Senior Embedded Linux Developer

dario.binac...@amarulasolutions.com

__


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
i...@amarulasolutions.com

www.amarulasolutions.com

Re: [PATCH 1/2] bootcount: Remove legacy I2C driver

[Heiko Schocher]

Hello Phillip,

On 13.10.23 13:35, Philip Oberfichtner wrote:
> Hi Heiko,
> 
> Thank you for reviewing.
> 
> On Fri, Oct 13, 2023 at 01:21:41PM +0200, Heiko Schocher wrote:
>> [...]
>>
>> Hmm.. I find some boards in mainline which still use this driver:
>>
>> u-boot  [master] $ grep -lr BOOTCOUNT_I2C .
>> ./configs/sandbox_defconfig
>> ./configs/mx53ppd_defconfig
>> ./configs/ge_bx50v3_defconfig
>> [...]
>>
>> So your remove patch will break them ... okay sandbox should be
>> easy to convert to your DM approach patch from this series.
>>
> 
> 
> $ git grep -r BOOTCOUNT_I2C
> configs/ge_bx50v3_defconfig:CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
> configs/mx53ppd_defconfig:CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
> configs/sandbox_defconfig:CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
> 
> Those boards use CONFIG_DM_BOOTCOUNT_I2C_EEPROM, which is not touched by
> this removal, is it?

Heh, yes, sorry!

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

Re: [PATCH v2] usb: xhci: Workaround to fix the USB halted endpoint issues

[Marek Vasut]

On 10/13/23 06:53, Venkatesh Yadav Abbarapu wrote:

The xhci host controller driver trying to queue the URB's and it is
getting halted at the endpoint, thereby hitting the BUG_ON's.
Mostly these kind of random issues are seen on faulty boards.
Removing these BUG_ON's from the U-Boot xhci code, as in Linux kernel
xhci code BUG_ON/BUG's are removed entirely.
Please also note, that BUG_ON() is not recommended any more in the Linux
kernel.
Similar issue has been observed on TI AM437x board and they created a patch
in Linux kernel as below
https://patches.linaro.org/project/linux-usb/patch/1390250711-25840-1-git-send-email-ba...@ti.com/

Signed-off-by: Venkatesh Yadav Abbarapu 


I already explained to Xilinx how to sync the driver with Linux and why 
this is needed to move forward, multiple times, and even provided a 
script which does most of the work automatically, since it is basically 
automated process. Xilinx did not even bother to test the script and 
provide any feedback.


Until that happens, this patch is rejected.

Re: [PATCH 1/2] bootcount: Remove legacy I2C driver

[Philip Oberfichtner]

Hi Heiko,

Thank you for reviewing.

On Fri, Oct 13, 2023 at 01:21:41PM +0200, Heiko Schocher wrote:
> [...]
>
> Hmm.. I find some boards in mainline which still use this driver:
> 
> u-boot  [master] $ grep -lr BOOTCOUNT_I2C .
> ./configs/sandbox_defconfig
> ./configs/mx53ppd_defconfig
> ./configs/ge_bx50v3_defconfig
> [...]
> 
> So your remove patch will break them ... okay sandbox should be
> easy to convert to your DM approach patch from this series.
> 


$ git grep -r BOOTCOUNT_I2C
configs/ge_bx50v3_defconfig:CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
configs/mx53ppd_defconfig:CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
configs/sandbox_defconfig:CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y

Those boards use CONFIG_DM_BOOTCOUNT_I2C_EEPROM, which is not touched by
this removal, is it?

Best regards,
Philip


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

Re: [PATCH 2/2] bootcount: Add driver model I2C driver

[Heiko Schocher]

Hello Philip,

On 13.10.23 11:43, Philip Richard Oberfichtner wrote:
> This adds a generic I2C bootcounter adhering to driver model to replace
> the previously removed legacy implementation.
> 
> There is no change in functionality, it can be used on any I2C device.
> The device tree configuration may look like this for example:
> 
>   bootcount {
>   compatible = "u-boot,bootcount-i2c";
>   i2c-bus = <>;
>   address = <0x52>;

Hmm.. do we really need this here with DTS. Why not using a phandle
to a real i2c device? Something like this for example:

i2cbcdev = _rtc;

with

 {
i2c_rtc: rtc@68 {
[...]

and so there is no need for knowing the bus and address ...

>   offset = <0x11>;
>   };
> 
> Signed-off-by: Philip Richard Oberfichtner 
> ---
>  drivers/bootcount/Kconfig|  10 +++
>  drivers/bootcount/Makefile   |   1 +
>  drivers/bootcount/bootcount_dm_i2c.c | 126 +++
>  3 files changed, 137 insertions(+)
>  create mode 100644 drivers/bootcount/bootcount_dm_i2c.c
> 
> diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
> index 7a2548ace2..1cf1de2b6d 100644
> --- a/drivers/bootcount/Kconfig
> +++ b/drivers/bootcount/Kconfig
> @@ -109,6 +109,16 @@ config DM_BOOTCOUNT_RTC
> Accesses to the backing store are performed using the write16
> and read16 ops of DM RTC devices.
>  
> +config DM_BOOTCOUNT_I2C
> + bool "Driver Model boot counter on I2C device"
> + depends on DM_I2C
> + help
> +   Enable support for the bootcounter on a generic i2c device, like a
> +   RTC or PMIC. This requires an 'i2c-bus', the i2c chip 'address' and
> +   the 'offset' to read to and write from. All of the three settings are
> +   defined as device tree properties using the "u-boot,bootcount-i2c"
> +   compatible string.
> +
>  config DM_BOOTCOUNT_I2C_EEPROM
>   bool "Support i2c eeprom devices as a backing store for bootcount"
>   depends on I2C_EEPROM
> diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
> index d6d2389c16..e7771f5b36 100644
> --- a/drivers/bootcount/Makefile
> +++ b/drivers/bootcount/Makefile
> @@ -13,5 +13,6 @@ obj-$(CONFIG_DM_BOOTCOUNT)  += bootcount-uclass.o
>  obj-$(CONFIG_DM_BOOTCOUNT_PMIC_PFUZE100) += pmic_pfuze100.o
>  obj-$(CONFIG_DM_BOOTCOUNT_RTC)  += rtc.o
>  obj-$(CONFIG_DM_BOOTCOUNT_I2C_EEPROM)+= i2c-eeprom.o
> +obj-$(CONFIG_DM_BOOTCOUNT_I2C)   += bootcount_dm_i2c.o
>  obj-$(CONFIG_DM_BOOTCOUNT_SPI_FLASH) += spi-flash.o
>  obj-$(CONFIG_DM_BOOTCOUNT_SYSCON) += bootcount_syscon.o
> diff --git a/drivers/bootcount/bootcount_dm_i2c.c 
> b/drivers/bootcount/bootcount_dm_i2c.c
> new file mode 100644
> index 00..227641f77e
> --- /dev/null
> +++ b/drivers/bootcount/bootcount_dm_i2c.c
> @@ -0,0 +1,126 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2023
> + * Philip Richard Oberfichtner 
> + *
> + * Based on previous work from Heiko Schocher (legacy bootcount_i2c.c driver)
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define BC_MAGIC 0x55
> +
> +struct bootcount_i2c_priv {
> + struct udevice *chip;

may rename chip to i2cbcdev or bcdev ?

> + unsigned int offset;
> +};
> +
> +static int bootcount_i2c_set(struct udevice *dev, const u32 val)
> +{
> + int ret;
> + struct bootcount_i2c_priv *priv = dev_get_priv(dev);
> +
> + ret = dm_i2c_reg_write(priv->chip, priv->offset, BC_MAGIC);
> + if (ret < 0)
> + goto err_exit;
> +
> + ret = dm_i2c_reg_write(priv->chip, priv->offset + 1, val & 0xff);
> + if (ret < 0)
> + goto err_exit;
> +
> + return 0;
> +
> +err_exit:
> + log_debug("%s: Error writing to I2C device (%d)\n", __func__, ret);
> + return ret;
> +}
> +
> +static int bootcount_i2c_get(struct udevice *dev, u32 *val)
> +{
> + int ret;
> + struct bootcount_i2c_priv *priv = dev_get_priv(dev);
> +
> + ret = dm_i2c_reg_read(priv->chip, priv->offset);
> + if (ret < 0)
> + goto err_exit;
> +
> + if ((ret & 0xff) != BC_MAGIC) {
> + log_debug("%s: Invalid Magic, reset bootcounter.\n", __func__);
> + *val = 0;
> + return bootcount_i2c_set(dev, 0);
> + }
> +
> + ret = dm_i2c_reg_read(priv->chip, priv->offset + 1);
> + if (ret < 0)
> + goto err_exit;
> +
> + *val = ret;
> + return 0;
> +
> +err_exit:
> + log_debug("%s: Error reading from I2C device (%d)\n", __func__, ret);
> + return ret;
> +}
> +
> +static int bootcount_i2c_probe(struct udevice *dev)
> +{
> + struct bootcount_i2c_priv *priv = dev_get_priv(dev);
> + struct ofnode_phandle_args phandle_args;
> + struct udevice *bus;
> + unsigned int addr;
> + int ret;
> +
> + ret = dev_read_u32(dev, "offset", >offset);
> + if (ret) {
> + log_debug("%s: Unable to get offset\n", 

Re: [PATCH 1/2] bootcount: Remove legacy I2C driver

[Heiko Schocher]

Hello Philip,

On 13.10.23 11:43, Philip Richard Oberfichtner wrote:
> The legacy I2C bootcounter will hereby be removed and eventually
> be replaced by a driver model implementation in the follow-up commit.
> 
> The legacy driver has the following drawbacks:
>   - It's not adhering to the driver model
>   - Settings are grabbed from Kconfig rather than device tree
>   - i2c_{read,write} are being used instead of dm_i2c_{read,write}
> 
> Signed-off-by: Philip Richard Oberfichtner 
> ---
>  drivers/bootcount/Kconfig | 24 +++--
>  drivers/bootcount/Makefile|  1 -
>  drivers/bootcount/bootcount_i2c.c | 43 ---
>  3 files changed, 3 insertions(+), 65 deletions(-)
>  delete mode 100644 drivers/bootcount/bootcount_i2c.c

Hmm.. I find some boards in mainline which still use this driver:

u-boot  [master] $ grep -lr BOOTCOUNT_I2C .
./configs/sandbox_defconfig
./configs/mx53ppd_defconfig
./configs/ge_bx50v3_defconfig
[...]

So your remove patch will break them ... okay sandbox should be
easy to convert to your DM approach patch from this series.

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

Re: [PATCH] arm: dts: k3-j721e-mcu-wakeup: Add MCU domain ESM instance

[Kumar, Udit]

On 10/13/2023 3:59 PM, Neha Malcom Francis wrote:

Currently J721E defines only the main_esm in DTS. Add node for mcu_esm
as well.

According to J721E TRM (12.11.2.2 ESM Environment) [1], we see that the
interrupt line from ESMi (main_esm) is routed to MCU_ESM (mcu_esm). This
is MCU_ESM0_LVL_IN_95 with interrupt ID 95. Configure mcu_esm
accordingly so that errors from main_esm are routed to mcu_esm and
handled.

[1] https://www.ti.com/lit/zip/spruil1

Signed-off-by: Neha Malcom Francis 
---
Upstream kernel effort:
https://lore.kernel.org/lkml/20230926142810.602384-1-n-fran...@ti.com/



should part of next u-boot, kernel sync, no?




  arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi 
b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
index 05d6ef127b..fa8af20c78 100644
--- a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
@@ -671,4 +671,11 @@
power-domains = <_pds 154 TI_SCI_PD_EXCLUSIVE>;
#thermal-sensor-cells = <1>;
};
+
+   mcu_esm: esm@4080 {
+   compatible = "ti,j721e-esm";
+   reg = <0x00 0x4080 0x00 0x1000>;
+   ti,esm-pins = <95>;
+   bootph-pre-ram;
+   };
  };

[PATCH] arm: dts: k3-j721e-mcu-wakeup: Add MCU domain ESM instance

[Neha Malcom Francis]

Currently J721E defines only the main_esm in DTS. Add node for mcu_esm
as well.

According to J721E TRM (12.11.2.2 ESM Environment) [1], we see that the
interrupt line from ESMi (main_esm) is routed to MCU_ESM (mcu_esm). This
is MCU_ESM0_LVL_IN_95 with interrupt ID 95. Configure mcu_esm
accordingly so that errors from main_esm are routed to mcu_esm and
handled.

[1] https://www.ti.com/lit/zip/spruil1

Signed-off-by: Neha Malcom Francis 
---
Upstream kernel effort:
https://lore.kernel.org/lkml/20230926142810.602384-1-n-fran...@ti.com/

 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi 
b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
index 05d6ef127b..fa8af20c78 100644
--- a/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
@@ -671,4 +671,11 @@
power-domains = <_pds 154 TI_SCI_PD_EXCLUSIVE>;
#thermal-sensor-cells = <1>;
};
+
+   mcu_esm: esm@4080 {
+   compatible = "ti,j721e-esm";
+   reg = <0x00 0x4080 0x00 0x1000>;
+   ti,esm-pins = <95>;
+   bootph-pre-ram;
+   };
 };
-- 
2.34.1

RE: U-Boot 2023.10 does not boot from uSD on RPi4

[Guillaume Gardet]

Hi,

Indeed, your patch [2] fixes my boot problem.

Thanks,
Guillaume


From: Simon Glass 
Sent: Tuesday, October 10, 2023 4:58 PM
To: Guillaume Gardet 
Cc: Peter Robinson ; Matthias Brugger 
; Ivan Ivanov ; U-Boot Mailing List 

Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4

Hi,

On Tue, 10 Oct 2023 at 04:39, Guillaume Gardet 
mailto:guillaume.gar...@arm.com>> wrote:
>
>
>
> > -Original Message-
> > From: Peter Robinson mailto:pbrobin...@gmail.com>>
> > Sent: Tuesday, October 10, 2023 12:22 PM
> > To: Guillaume Gardet 
> > mailto:guillaume.gar...@arm.com>>
> > Cc: mbrug...@suse.com; Ivan Ivanov 
> > mailto:ivan.iva...@suse.com>>; Simon Glass
> > mailto:s...@chromium.org>>; 
> > u-boot@lists.denx.de
> > Subject: Re: U-Boot 2023.10 does not boot from uSD on RPi4
> >
> > On Tue, Oct 10, 2023 at 10:26 AM Guillaume Gardet
> > mailto:guillaume.gar...@arm.com>> wrote:
> > >
> > > Hi,
> > >
> > > U-Boot 2023.10 does not boot from uSD on RPi4.
> > > This has been found on openSUSE Tumbleweed. The only diff we need is:
> > >   -CONFIG_OF_EMBED=y
> > >   +CONFIG_OF_BOARD=y
> > > To use firmware provided Device Tree. But that should not affect the mmc
> > behavior too much, I think.
> >
> > I've been booting Fedora fine on a RPi4 BUT there's issues with the display
> > turning off [1] when the accelerated display modules load
> > (vc4) as a result of this patch set. Can you confirm if that's the same 
> > problem
> > you're seeing?
>
> No, that's not my problem. My issue is grub was not loaded by u-boot from uSD.
> It seems more like Simon's problem: 
> https://lists.denx.de/pipermail/u-boot/2023-October/533162.html
>
> @Simon, can you check if the patch below fixes your boot problem on RPi4, 
> please?

This has been reported at least twice before. There is a fix [2] which is in my 
queue to apply.

Regarding the display problem, I got my rpi4 running again and Fedora 
installed, but I won't get back to it until the end of the week as I'm at osfc.

Regards,
Simon

>
> Thanks,
> Guillaume
>

[2] 
https://patchwork.ozlabs.org/project/uboot/patch/20230923205017.1754340-1-...@chromium.org/

> >
> > [1] https://lists.denx.de/pipermail/u-boot/2023-October/533158.html
> >
> > > 'git bisect' points to:
> > > **
> > > commit c771e5b8c2a186fb072b6c6f571d4a3cc86efba9
> > > Author: Simon Glass mailto:s...@chromium.org>>
> > > Date:   Thu Jul 27 15:54:28 2023 -0600
> > >
> > > arm: rpi: Switch to standard boot
> > >
> > > Drop use of the distro scripts and use standard boot instead.
> > >
> > > We don't need to specify the mmc devices individually, since they are
> > > used in order from 0 to 2, and standard boot uses that order anyway.
> > >
> > > Signed-off-by: Simon Glass 
> > > mailto:s...@chromium.org>>
> > > **
> > >
> > > The following patch fixes the boot from uSD on RPi4 (not tested on RPi3 
> > > nor RPi
> > Zero 2 W):
> > > **
> > > diff --git a/board/raspberrypi/rpi/rpi.env
> > > b/board/raspberrypi/rpi/rpi.env index 30228285ed..02210b97b5 100644
> > > --- a/board/raspberrypi/rpi/rpi.env
> > > +++ b/board/raspberrypi/rpi/rpi.env
> > > @@ -74,4 +74,4 @@ pxefile_addr_r=0x0250
> > >  fdt_addr_r=0x0260
> > >  ramdisk_addr_r=0x0270
> > >
> > > -boot_targets=mmc usb pxe dhcp
> > > +boot_targets=mmc0 mmc1 mmc2 usb pxe dhcp
> > > **
> > >
> > > So, the comment from Simon " We don't need to specify the mmc devices
> > individually, since they are used in order from 0 to 2, and standard boot 
> > uses that
> > order anyway" seems wrong for the RPi4 case.
> > >
> > > Cheers,
> > > Guillaume
> > >
> > > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended 
> > recipient,
> > please notify the sender immediately and do not disclose the contents to any
> > other person, use it for any purpose, or store or copy the information in 
> > any
> > medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

[PATCH 2/2] bootcount: Add driver model I2C driver

[Philip Richard Oberfichtner]

This adds a generic I2C bootcounter adhering to driver model to replace
the previously removed legacy implementation.

There is no change in functionality, it can be used on any I2C device.
The device tree configuration may look like this for example:

bootcount {
compatible = "u-boot,bootcount-i2c";
i2c-bus = <>;
address = <0x52>;
offset = <0x11>;
};

Signed-off-by: Philip Richard Oberfichtner 
---
 drivers/bootcount/Kconfig|  10 +++
 drivers/bootcount/Makefile   |   1 +
 drivers/bootcount/bootcount_dm_i2c.c | 126 +++
 3 files changed, 137 insertions(+)
 create mode 100644 drivers/bootcount/bootcount_dm_i2c.c

diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index 7a2548ace2..1cf1de2b6d 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -109,6 +109,16 @@ config DM_BOOTCOUNT_RTC
  Accesses to the backing store are performed using the write16
  and read16 ops of DM RTC devices.
 
+config DM_BOOTCOUNT_I2C
+   bool "Driver Model boot counter on I2C device"
+   depends on DM_I2C
+   help
+ Enable support for the bootcounter on a generic i2c device, like a
+ RTC or PMIC. This requires an 'i2c-bus', the i2c chip 'address' and
+ the 'offset' to read to and write from. All of the three settings are
+ defined as device tree properties using the "u-boot,bootcount-i2c"
+ compatible string.
+
 config DM_BOOTCOUNT_I2C_EEPROM
bool "Support i2c eeprom devices as a backing store for bootcount"
depends on I2C_EEPROM
diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
index d6d2389c16..e7771f5b36 100644
--- a/drivers/bootcount/Makefile
+++ b/drivers/bootcount/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_DM_BOOTCOUNT)  += bootcount-uclass.o
 obj-$(CONFIG_DM_BOOTCOUNT_PMIC_PFUZE100) += pmic_pfuze100.o
 obj-$(CONFIG_DM_BOOTCOUNT_RTC)  += rtc.o
 obj-$(CONFIG_DM_BOOTCOUNT_I2C_EEPROM)  += i2c-eeprom.o
+obj-$(CONFIG_DM_BOOTCOUNT_I2C) += bootcount_dm_i2c.o
 obj-$(CONFIG_DM_BOOTCOUNT_SPI_FLASH)   += spi-flash.o
 obj-$(CONFIG_DM_BOOTCOUNT_SYSCON) += bootcount_syscon.o
diff --git a/drivers/bootcount/bootcount_dm_i2c.c 
b/drivers/bootcount/bootcount_dm_i2c.c
new file mode 100644
index 00..227641f77e
--- /dev/null
+++ b/drivers/bootcount/bootcount_dm_i2c.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2023
+ * Philip Richard Oberfichtner 
+ *
+ * Based on previous work from Heiko Schocher (legacy bootcount_i2c.c driver)
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define BC_MAGIC   0x55
+
+struct bootcount_i2c_priv {
+   struct udevice *chip;
+   unsigned int offset;
+};
+
+static int bootcount_i2c_set(struct udevice *dev, const u32 val)
+{
+   int ret;
+   struct bootcount_i2c_priv *priv = dev_get_priv(dev);
+
+   ret = dm_i2c_reg_write(priv->chip, priv->offset, BC_MAGIC);
+   if (ret < 0)
+   goto err_exit;
+
+   ret = dm_i2c_reg_write(priv->chip, priv->offset + 1, val & 0xff);
+   if (ret < 0)
+   goto err_exit;
+
+   return 0;
+
+err_exit:
+   log_debug("%s: Error writing to I2C device (%d)\n", __func__, ret);
+   return ret;
+}
+
+static int bootcount_i2c_get(struct udevice *dev, u32 *val)
+{
+   int ret;
+   struct bootcount_i2c_priv *priv = dev_get_priv(dev);
+
+   ret = dm_i2c_reg_read(priv->chip, priv->offset);
+   if (ret < 0)
+   goto err_exit;
+
+   if ((ret & 0xff) != BC_MAGIC) {
+   log_debug("%s: Invalid Magic, reset bootcounter.\n", __func__);
+   *val = 0;
+   return bootcount_i2c_set(dev, 0);
+   }
+
+   ret = dm_i2c_reg_read(priv->chip, priv->offset + 1);
+   if (ret < 0)
+   goto err_exit;
+
+   *val = ret;
+   return 0;
+
+err_exit:
+   log_debug("%s: Error reading from I2C device (%d)\n", __func__, ret);
+   return ret;
+}
+
+static int bootcount_i2c_probe(struct udevice *dev)
+{
+   struct bootcount_i2c_priv *priv = dev_get_priv(dev);
+   struct ofnode_phandle_args phandle_args;
+   struct udevice *bus;
+   unsigned int addr;
+   int ret;
+
+   ret = dev_read_u32(dev, "offset", >offset);
+   if (ret) {
+   log_debug("%s: Unable to get offset\n", __func__);
+   return ret;
+   }
+
+   ret = dev_read_u32(dev, "address", );
+   if (ret) {
+   log_debug("%s: Unable to get chip address\n", __func__);
+   return ret;
+   }
+
+   ret = dev_read_phandle_with_args(dev, "i2c-bus", NULL, 0, 0, 
_args);
+   if (ret) {
+   log_debug("%s: Unable to get phandle\n", __func__);
+   return ret;
+   }
+
+   ret = uclass_get_device_by_ofnode(UCLASS_I2C, phandle_args.node, );
+   if (ret) {
+   

[PATCH 1/2] bootcount: Remove legacy I2C driver

[Philip Richard Oberfichtner]

The legacy I2C bootcounter will hereby be removed and eventually
be replaced by a driver model implementation in the follow-up commit.

The legacy driver has the following drawbacks:
- It's not adhering to the driver model
- Settings are grabbed from Kconfig rather than device tree
- i2c_{read,write} are being used instead of dm_i2c_{read,write}

Signed-off-by: Philip Richard Oberfichtner 
---
 drivers/bootcount/Kconfig | 24 +++--
 drivers/bootcount/Makefile|  1 -
 drivers/bootcount/bootcount_i2c.c | 43 ---
 3 files changed, 3 insertions(+), 65 deletions(-)
 delete mode 100644 drivers/bootcount/bootcount_i2c.c

diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index 570252d186..7a2548ace2 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -79,14 +79,6 @@ config BOOTCOUNT_RAM
  Store the bootcount in DRAM protected against bit errors
  due to short power loss or holding a system in RESET.
 
-config BOOTCOUNT_I2C
-   bool "Boot counter on I2C device"
-   help
- Enable support for the bootcounter on an i2c (like RTC) device.
- CFG_SYS_I2C_RTC_ADDR = i2c chip address
- CONFIG_SYS_BOOTCOUNT_ADDR = i2c addr which is used for
- the bootcounter.
-
 config BOOTCOUNT_AT91
bool "Boot counter for Atmel AT91SAM9XE"
depends on AT91SAM9XE
@@ -175,14 +167,6 @@ config BOOTCOUNT_BOOTLIMIT
  counter being cleared.
  If set to 0, do not set a boot limit in the environment.
 
-config BOOTCOUNT_ALEN
-   int "I2C address length"
-   default 1
-   depends on BOOTCOUNT_I2C
-   help
- Length of the the I2C address at SYS_BOOTCOUNT_ADDR for storing
- the boot counter.
-
 config SYS_BOOTCOUNT_SINGLEWORD
bool "Use single word to pack boot count and magic value"
depends on BOOTCOUNT_GENERIC
@@ -218,7 +202,7 @@ config SYS_BOOTCOUNT_ADDR
default 0x44E3E000 if BOOTCOUNT_AM33XX || BOOTCOUNT_AM33XX_NVMEM
default 0xE0115FF8 if ARCH_LS1043A || ARCH_LS1021A
depends on BOOTCOUNT_AM33XX || BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
-  BOOTCOUNT_I2C || BOOTCOUNT_AM33XX_NVMEM
+  BOOTCOUNT_AM33XX_NVMEM
help
  Set the address used for reading and writing the boot counter.
 
@@ -226,13 +210,11 @@ config SYS_BOOTCOUNT_MAGIC
hex "Magic value for the boot counter"
default 0xB001C041 if BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
  BOOTCOUNT_AM33XX || BOOTCOUNT_ENV || \
- BOOTCOUNT_RAM || BOOTCOUNT_I2C || \
- BOOTCOUNT_AT91 || DM_BOOTCOUNT
+ BOOTCOUNT_RAM || BOOTCOUNT_AT91 || DM_BOOTCOUNT
default 0xB0 if BOOTCOUNT_AM33XX_NVMEM
depends on BOOTCOUNT_GENERIC || BOOTCOUNT_EXT || \
   BOOTCOUNT_AM33XX || BOOTCOUNT_ENV || \
-  BOOTCOUNT_RAM || BOOTCOUNT_I2C || \
-  BOOTCOUNT_AT91 || DM_BOOTCOUNT || \
+  BOOTCOUNT_RAM || BOOTCOUNT_AT91 || DM_BOOTCOUNT || \
   BOOTCOUNT_AM33XX_NVMEM
help
  Set the magic value used for the boot counter.
diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
index b65959a384..d6d2389c16 100644
--- a/drivers/bootcount/Makefile
+++ b/drivers/bootcount/Makefile
@@ -6,7 +6,6 @@ obj-$(CONFIG_BOOTCOUNT_AT91)+= bootcount_at91.o
 obj-$(CONFIG_BOOTCOUNT_AM33XX) += bootcount_davinci.o
 obj-$(CONFIG_BOOTCOUNT_RAM)+= bootcount_ram.o
 obj-$(CONFIG_BOOTCOUNT_ENV)+= bootcount_env.o
-obj-$(CONFIG_BOOTCOUNT_I2C)+= bootcount_i2c.o
 obj-$(CONFIG_BOOTCOUNT_EXT)+= bootcount_ext.o
 obj-$(CONFIG_BOOTCOUNT_AM33XX_NVMEM)   += bootcount_nvmem.o
 
diff --git a/drivers/bootcount/bootcount_i2c.c 
b/drivers/bootcount/bootcount_i2c.c
deleted file mode 100644
index b3ac67ea35..00
--- a/drivers/bootcount/bootcount_i2c.c
+++ /dev/null
@@ -1,43 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2013
- * Heiko Schocher, DENX Software Engineering, h...@denx.de.
- */
-
-#include 
-#include 
-#include 
-
-#define BC_MAGIC   0xbc
-
-void bootcount_store(ulong a)
-{
-   unsigned char buf[3];
-   int ret;
-
-   buf[0] = BC_MAGIC;
-   buf[1] = (a & 0xff);
-   ret = i2c_write(CFG_SYS_I2C_RTC_ADDR, CONFIG_SYS_BOOTCOUNT_ADDR,
- CONFIG_BOOTCOUNT_ALEN, buf, 2);
-   if (ret != 0)
-   puts("Error writing bootcount\n");
-}
-
-ulong bootcount_load(void)
-{
-   unsigned char buf[3];
-   int ret;
-
-   ret = i2c_read(CFG_SYS_I2C_RTC_ADDR, CONFIG_SYS_BOOTCOUNT_ADDR,
-  CONFIG_BOOTCOUNT_ALEN, buf, 2);
-   if (ret != 0) {
-   puts("Error loading bootcount\n");
-   return 0;
-   }
-   if (buf[0] == BC_MAGIC)
-   

[PATCH 0/2] bootcount: Replace I2C legacy implementation by driver model

[Philip Richard Oberfichtner]

The generic I2C bootcounter driver does not yet adhere to driver model.
This patchset intends to replace the legacy implementation.

There are currently no upstream boards using the driver, so it should be
safe to just remove it. For downstream users it should be straighforward to
switch to the new implementation.

Philip Richard Oberfichtner (2):
  bootcount: Remove legacy I2C driver
  bootcount: Add driver model I2C driver

 drivers/bootcount/Kconfig|  34 +++-
 drivers/bootcount/Makefile   |   2 +-
 drivers/bootcount/bootcount_dm_i2c.c | 126 +++
 drivers/bootcount/bootcount_i2c.c|  43 -
 4 files changed, 140 insertions(+), 65 deletions(-)
 create mode 100644 drivers/bootcount/bootcount_dm_i2c.c
 delete mode 100644 drivers/bootcount/bootcount_i2c.c

-- 
2.42.0

Re: [PATCH 3/7] arc: Remove common.h usage

[Alexey Brodkin]

Hi Tom,

> We can remove common.h from most cases of the code here, and only a few
> places need an additional header instead.
> 
> Signed-off-by: Tom Rini 
> ---
> Cc: Alexey Brodkin 
> Cc: Eugeniy Paltsev 
> Cc: uboot-snps-...@synopsys.com
> ---
>  arch/arc/lib/bootm.c   | 1 -
>  arch/arc/lib/cache.c   | 1 -
>  arch/arc/lib/cpu.c | 1 -
>  arch/arc/lib/init_helpers.c| 1 -
>  arch/arc/lib/interrupts.c  | 2 +-
>  arch/arc/lib/relocate.c| 1 -
>  arch/arc/lib/reset.c   | 1 -
>  board/abilis/tb100/tb100.c | 1 -
>  board/synopsys/axs10x/axs10x.c | 1 -
>  board/synopsys/emsdp/emsdp.c   | 1 -
>  board/synopsys/hsdk/clk-lib.h  | 1 -
>  board/synopsys/hsdk/env-lib.c  | 2 ++
>  board/synopsys/hsdk/env-lib.h  | 1 -
>  board/synopsys/hsdk/hsdk.c | 1 -
>  board/synopsys/iot_devkit/iot_devkit.c | 1 -
>  board/synopsys/nsim/nsim.c | 1 -
>  16 files changed, 3 insertions(+), 15 deletions(-)

Thanks for the improvement!

Acked-by: Alexey Brodkin 

Re: [PATCH 1/1] i2c: designware_i2c: adjust timing calculation

[Heiko Schocher]

Hello Heinrich,

On 13.10.23 10:32, Heinrich Schuchardt wrote:
> On 10/13/23 06:37, Heiko Schocher wrote:
>> Hello Heinrich,
>>
>> On 11.10.23 06:48, Heinrich Schuchardt wrote:
>>> In SPL probing of the designware_i2c device on the StarFive VisionFive 2
>>> board fails with
>>>
>>>  dw_i2c: mode 0, ic_clk 100, speed 10,
>>>  period 10 rise 1 fall 1 tlow 5 thigh 4 spk 0
>>>  dw_i2c: bad counts. hcnt = -4 lcnt = 4
>>>  device_probe: i2c@1205 failed to probe -22
>>>
>>> When changing the offset for the high phase from 7 to 1 the device is
>>> probed correctly.
>>>
>>> Without this fix the memory size of the StarFive VisionFive 2 board cannot
>>> be read from EEPROM.
>>>
>>> Fixes: e71b6f6622d6 ("i2c: designware_i2c: Rewrite timing calculation")
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>   drivers/i2c/designware_i2c.c | 8 
>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
>>> index e54de42abc..55e582091c 100644
>>> --- a/drivers/i2c/designware_i2c.c
>>> +++ b/drivers/i2c/designware_i2c.c
>>> @@ -155,10 +155,10 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, 
>>> enum i2c_speed_mode mode,
>>>     /*
>>>    * Back-solve for hcnt and lcnt according to the following equations:
>>> - * SCL_High_time = [(HCNT + IC_*_SPKLEN + 7) * ic_clk] + SCL_Fall_time
>>> + * SCL_High_time = [(HCNT + IC_*_SPKLEN + 1) * ic_clk] + SCL_Fall_time
>>>    * SCL_Low_time = [(LCNT + 1) * ic_clk] - SCL_Fall_time + 
>>> SCL_Rise_time
>>>    */
>>> -    hcnt = min_thigh_cnt - fall_cnt - 7 - spk_cnt;
>>> +    hcnt = min_thigh_cnt - fall_cnt - 1 - spk_cnt;
>>>   lcnt = min_tlow_cnt - rise_cnt + fall_cnt - 1;
>>>     if (hcnt < 0 || lcnt < 0) {
>>> @@ -170,13 +170,13 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, 
>>> enum i2c_speed_mode mode,
>>>    * Now add things back up to ensure the period is hit. If it is off,
>>>    * split the difference and bias to lcnt for remainder
>>>    */
>>> -    tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1;
>>> +    tot = hcnt + lcnt + 1 + spk_cnt + rise_cnt + 1;
>>>     if (tot < period_cnt) {
>>>   diff = (period_cnt - tot) / 2;
>>>   hcnt += diff;
>>>   lcnt += diff;
>>> -    tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1;
>>> +    tot = hcnt + lcnt + 1 + spk_cnt + rise_cnt + 1;
>>>   lcnt += period_cnt - tot;
>>>   }
>>
>> What are this magic constants? Are they somewhere documented in the RM?
> 
> I have no access to Designware reference manuals. Do you have?

No.

>> Hmm... and does this may break other boards? Should we have this in
>> someway configurable?
>>
>> Tried to look fast in the linux driver... and it seems to me, this
>> constants depend at least on i2c_speed_mode?
>>
>> bye,
>> Heiko
> 
> https://www.nxp.com/docs/en/user-guide/UM10204.pdf has I2C timing diagrams in 
> Figure 38 and Figure 39.
> 
> Linux has a function i2c_dw_scl_hcnt() where depending on parameter cond 
> either a value of 8 or 3 is
> used. All invocations of i2c_dw_scl_hcnt() have cond = 0, offset = 0. Linux' 
> i2c_dw_scl_lcnt()
> always uses 1.
> 
> The Linux comments are:
> 
> cond==True
>     IC_[FS]S_SCL_HCNT + (1+4+3) >= IC_CLK * tHIGH
> 
> cond==False
>     IC_[FS]S_SCL_HCNT + 3 >= IC_CLK * (tHD;STA + tf)
> 
> The U-Boot comment has:
> 
>     SCL_High_time = [(HCNT + IC_*_SPKLEN + 7) * ic_clk] + SCL_Fall_time
> 
> This lets me assume that these are the matching pieces of code.

Yep, I looked at the exact same code, and you are correct, with

"All invocations of i2c_dw_scl_hcnt() have cond = 0, offset = 0."

> While my patch had %s/ 7 / 1 / we would need %s/ 7 / 3 / to match the Linux 
> formula. This should be
> enough to avoid the observed "bad count" error on the VisionFive 2.

Can  you try this out? And if it works may I ask if you send a v2
with some explanation added in U-Boot code, that we sync here with
that what you found in kernel driver?

Many Thanks!

bye,
Heiko
> 
> Best regards
> 
> Heinrich

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

Re: [PATCH] test/py: net: Add a test for 'pxe get' command

[Michal Simek]

On 10/3/23 15:12, Love Kumar wrote:

Execute the 'pxe get' command to download a pxe configuration file from
the TFTP server and validate its interpretation.

Signed-off-by: Love Kumar 
---
  test/py/tests/test_net.py | 66 +++
  1 file changed, 66 insertions(+)

diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index cd4b4dc53cbc..b2241ae6a482 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -6,6 +6,7 @@
  
  import pytest

  import u_boot_utils
+import uuid
  
  """

  Note: This test relies on boardenv_* containing configuration values to define
@@ -61,6 +62,16 @@ env__net_nfs_readable_file = {
  'crc32': 'c2244b26',
  }
  
+# Details regarding a file that may be read from a TFTP server. This variable

+# may be omitted or set to None if PXE testing is not possible or desired.
+env__net_pxe_readable_file = {
+'fn': 'default',
+'addr': 0x200,
+'size': 74,
+'timeout': 5,
+'pattern': 'Linux',
+}
+
  # True if a router advertisement service is connected to the network, and 
should
  # be tested. If router advertisement testing is not possible or desired, this
  variable may be omitted or set to False.
@@ -260,3 +271,58 @@ def test_net_nfs(u_boot_console):
  
  output = u_boot_console.run_command('crc32 %x $filesize' % addr)

  assert expected_crc in output
+
+@pytest.mark.buildconfigspec("cmd_net")
+@pytest.mark.buildconfigspec("cmd_pxe")
+def test_net_pxe_get(u_boot_console):
+"""Test the pxe get command.
+
+A pxe configuration file is downloaded from the TFTP server and interpreted
+to boot the images mentioned in pxe configuration file.
+
+The details of the file to download are provided by the boardenv_* file;
+see the comment at the beginning of this file.
+"""
+
+if not net_set_up:
+pytest.skip("Network not initialized")
+
+test_net_setup_static(u_boot_console)
+
+f = u_boot_console.config.env.get("env__net_pxe_readable_file", None)
+if not f:
+pytest.skip("No PXE readable file to read")
+
+addr = f.get("addr", None)
+timeout = f.get("timeout", u_boot_console.p.timeout)
+
+pxeuuid = uuid.uuid1()
+u_boot_console.run_command(f"setenv pxeuuid {pxeuuid}")
+expected_text_uuid = f"Retrieving file: pxelinux.cfg/{pxeuuid}"
+
+ethaddr = u_boot_console.run_command("echo $ethaddr")
+ethaddr = ethaddr.replace(':', '-')
+expected_text_ethaddr = f"Retrieving file: pxelinux.cfg/01-{ethaddr}"
+
+ip = u_boot_console.run_command("echo $ipaddr")
+ip = ip.split('.')
+ipaddr_file = "".join(['%02x' % int(x) for x in ip]).upper()
+expected_text_ipaddr = f"Retrieving file: pxelinux.cfg/{ipaddr_file}"
+expected_text_default = f"Retrieving file: pxelinux.cfg/default"
+
+with u_boot_console.temporary_timeout(timeout):
+output = u_boot_console.run_command("pxe get")
+
+assert "TIMEOUT" not in output
+assert expected_text_uuid in output
+assert expected_text_ethaddr in output
+assert expected_text_ipaddr in output
+
+i = 1
+for i in range(0, len(ipaddr_file) - 1):
+expected_text_ip = f"Retrieving file: pxelinux.cfg/{ipaddr_file[:-i]}"
+assert expected_text_ip in output
+i += 1
+
+assert expected_text_default in output
+assert "Config file 'default.boot' found" in output


Applied.
M

Re: [PATCH 1/1] riscv: enable CONFIG_DEBUG_UART by default

[Rick Chen]

> From: Heinrich Schuchardt 
> Sent: Saturday, September 23, 2023 7:35 AM
> To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> 
> Cc: u-boot@lists.denx.de; Heinrich Schuchardt 
> 
> Subject: [PATCH 1/1] riscv: enable CONFIG_DEBUG_UART by default
>
> Most boards don't enable the pre-console buffer. So we will not see any early 
> messages. OpenSBI 1.3 provides us with the debug console extension that can 
> fill this gap.
>
> For S-Mode U-Boot enable CONFIG_DEBUG_UART by default.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rick Chen 

Re: [PATCH 7/7] riscv: Remove common.h usage

[Rick Chen]

> From: Tom Rini 
> Sent: Friday, October 13, 2023 7:04 AM
> To: u-boot@lists.denx.de
> Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> 
> Subject: [PATCH 7/7] riscv: Remove common.h usage
>
> We can remove common.h from most cases of the code here, and only a few 
> places need an additional header instead.
>
> Signed-off-by: Tom Rini 
> ---
> Cc: Rick Chen 
> Cc: Leo 
> ---

Reviewed-by: Rick Chen 

Re: [PATCH 1/1] configs: sifive: enable poweroff command on Unmatched

[Rick Chen]

> From: Heinrich Schuchardt 
> Sent: Sunday, October 01, 2023 1:41 PM
> To: Paul Walmsley ; Green Wan 
> Cc: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) 
> ; u-boot@lists.denx.de; Heinrich Schuchardt 
> 
> Subject: [PATCH 1/1] configs: sifive: enable poweroff command on Unmatched
>
> Powering off the SiFive HiFive Unmatched board is supported both via the SBI 
> and GPIO sysreset drivers. See device-tree entry
>
> compatible = "gpio-poweroff".
>
> Enable the poweroff command.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  configs/sifive_unmatched_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rick Chen 

Re: [PATCH 1/1] i2c: designware_i2c: adjust timing calculation

[Heinrich Schuchardt]

On 10/13/23 06:37, Heiko Schocher wrote:

Hello Heinrich,

On 11.10.23 06:48, Heinrich Schuchardt wrote:

In SPL probing of the designware_i2c device on the StarFive VisionFive 2
board fails with

 dw_i2c: mode 0, ic_clk 100, speed 10,
 period 10 rise 1 fall 1 tlow 5 thigh 4 spk 0
 dw_i2c: bad counts. hcnt = -4 lcnt = 4
 device_probe: i2c@1205 failed to probe -22

When changing the offset for the high phase from 7 to 1 the device is
probed correctly.

Without this fix the memory size of the StarFive VisionFive 2 board cannot
be read from EEPROM.

Fixes: e71b6f6622d6 ("i2c: designware_i2c: Rewrite timing calculation")
Signed-off-by: Heinrich Schuchardt 
---
  drivers/i2c/designware_i2c.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index e54de42abc..55e582091c 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -155,10 +155,10 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, enum 
i2c_speed_mode mode,
  
  	/*

 * Back-solve for hcnt and lcnt according to the following equations:
-* SCL_High_time = [(HCNT + IC_*_SPKLEN + 7) * ic_clk] + SCL_Fall_time
+* SCL_High_time = [(HCNT + IC_*_SPKLEN + 1) * ic_clk] + SCL_Fall_time
 * SCL_Low_time = [(LCNT + 1) * ic_clk] - SCL_Fall_time + SCL_Rise_time
 */
-   hcnt = min_thigh_cnt - fall_cnt - 7 - spk_cnt;
+   hcnt = min_thigh_cnt - fall_cnt - 1 - spk_cnt;
lcnt = min_tlow_cnt - rise_cnt + fall_cnt - 1;
  
  	if (hcnt < 0 || lcnt < 0) {

@@ -170,13 +170,13 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, enum 
i2c_speed_mode mode,
 * Now add things back up to ensure the period is hit. If it is off,
 * split the difference and bias to lcnt for remainder
 */
-   tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1;
+   tot = hcnt + lcnt + 1 + spk_cnt + rise_cnt + 1;
  
  	if (tot < period_cnt) {

diff = (period_cnt - tot) / 2;
hcnt += diff;
lcnt += diff;
-   tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1;
+   tot = hcnt + lcnt + 1 + spk_cnt + rise_cnt + 1;
lcnt += period_cnt - tot;
}


What are this magic constants? Are they somewhere documented in the RM?


I have no access to Designware reference manuals. Do you have?



Hmm... and does this may break other boards? Should we have this in
someway configurable?

Tried to look fast in the linux driver... and it seems to me, this
constants depend at least on i2c_speed_mode?

bye,
Heiko


https://www.nxp.com/docs/en/user-guide/UM10204.pdf has I2C timing 
diagrams in Figure 38 and Figure 39.


Linux has a function i2c_dw_scl_hcnt() where depending on parameter cond 
either a value of 8 or 3 is used. All invocations of i2c_dw_scl_hcnt() 
have cond = 0, offset = 0. Linux' i2c_dw_scl_lcnt() always uses 1.


The Linux comments are:

cond==True
IC_[FS]S_SCL_HCNT + (1+4+3) >= IC_CLK * tHIGH

cond==False
IC_[FS]S_SCL_HCNT + 3 >= IC_CLK * (tHD;STA + tf)

The U-Boot comment has:

SCL_High_time = [(HCNT + IC_*_SPKLEN + 7) * ic_clk] + SCL_Fall_time

This lets me assume that these are the matching pieces of code.

While my patch had %s/ 7 / 1 / we would need %s/ 7 / 3 / to match the 
Linux formula. This should be enough to avoid the observed "bad count" 
error on the VisionFive 2.


Best regards

Heinrich

Re: [RESEND PATCH v2] rockchip: include: asm: fix entering download mode rk3066

[Kever Yang]

On 2023/9/19 23:28, Johan Jonker wrote:

Keep track of the re-entries with help of the lr register.
This binary can be re-used and called from various BROM functions.
Only when it's called from the part that handles SPI, NAND or EMMC
hardware it needs to early return to BROM ones.
In download mode when it handles data on USB OTG and UART0
this section must be skipped.

Unlike newer Rockchip SoC models the rk3066 BROM code does not have built-in
support to enter download mode on return to BROM. This binary must check
the boot mode register for the BOOT_BROM_DOWNLOAD flag and reset if it's set.
It then returns to BROM to the end of the function that reads boot blocks.
>From there the BROM code goes into a download mode and waits for data
on USB OTG and UART0.

Signed-off-by: Johan Jonker 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Note:
   Normal boot flow is OK.
   In download mode this binary hangs after return to BROM for unknown reasons.
   Replace CODE471_OPTION with 30_LPDDR2_300MHz_DD.bin for now.

   Could Rockchip disclose what further conditions must be met
   in rk3066 download mode?

Changed V2:
   Move file to rk3066 specific location
   Replace retry_counter by LR check
   Add DNL mode return address
   Restyle
   Reword
---
  arch/arm/include/asm/arch-rk3066/boot0.h | 77 +++-
  arch/arm/mach-rockchip/Kconfig   | 17 +-
  arch/arm/mach-rockchip/rk3066/Kconfig|  6 ++
  3 files changed, 98 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rk3066/boot0.h 
b/arch/arm/include/asm/arch-rk3066/boot0.h
index 28c0fb9a4c6b..1af4b9c1d7ba 100644
--- a/arch/arm/include/asm/arch-rk3066/boot0.h
+++ b/arch/arm/include/asm/arch-rk3066/boot0.h
@@ -3,6 +3,81 @@
  #ifndef __ASM_ARCH_BOOT0_H__
  #define __ASM_ARCH_BOOT0_H__

-#include 
+#include 

+/*
+ * Execution starts on the instruction following this 4-byte header
+ * (containing the magic 'RK30'). This magic constant will be written into
+ * the final image by the rkimage tool, but we need to reserve space for it 
here.
+ */
+#ifdef CONFIG_SPL_BUILD
+   b   1f  /* if overwritten, entry-address is at the next word */
+1:
+#endif
+
+#if CONFIG_IS_ENABLED(ROCKCHIP_EARLYRETURN_TO_BROM)
+/*
+ * Keep track of the re-entries with help of the lr register.
+ * This binary can be re-used and called from various BROM functions.
+ * Only when it's called from the part that handles SPI, NAND or EMMC
+ * hardware it needs to early return to BROM ones.
+ * In download mode when it handles data on USB OTG and UART0
+ * this section must be skipped.
+ */
+   ldr r3, =CONFIG_ROCKCHIP_BOOT_LR_REG
+   cmp lr, r3  /* if (LR != CONFIG_ROCKCHIP_BOOT_LR_REG)   
 */
+   bne reset   /* goto reset;  
 */
+/*
+ * Unlike newer Rockchip SoC models the rk3066 BROM code does not have built-in
+ * support to enter download mode on return to BROM. This binary must check
+ * the boot mode register for the BOOT_BROM_DOWNLOAD flag and reset if it's 
set.
+ * It then returns to BROM to the end of the function that reads boot blocks.
+ * From there the BROM code goes into a download mode and waits for data
+ * on USB OTG and UART0.
+ */
+   ldr r2, =BOOT_BROM_DOWNLOAD
+   ldr r3, =CONFIG_ROCKCHIP_BOOT_MODE_REG
+   ldr r0, [r3]/* if (readl(CONFIG_ROCKCHIP_BOOT_MODE_REG) !=  
 */
+   cmp r0, r2  /* BOOT_BROM_DOWNLOAD) {
 */
+   bne early_return/* goto early_return;   
 */
+   /* } else { 
 */
+   mov r0, #0
+   str r0, [r3]/* writel(0, 
CONFIG_ROCKCHIP_BOOT_MODE_REG); */
+
+   ldr r3, =CONFIG_ROCKCHIP_BOOT_RETURN_REG
+   bx  r3  /* return to 
CONFIG_ROCKCHIP_BOOT_RETURN_REG;*/
+
+early_return:
+   bx  lr  /*  return to LR in BROM
 */
+
+SAVE_SP_ADDR:
+   .word 0
+
+   .globl save_boot_params
+save_boot_params:
+   push{r1-r12, lr}
+   ldr r0, =SAVE_SP_ADDR
+   str sp, [r0]
+   b   save_boot_params_ret
+
+   .globl back_to_bootrom
+back_to_bootrom:
+   ldr r0, =SAVE_SP_ADDR
+   ldr sp, [r0]
+   mov r0, #0
+   pop {r1-r12, pc}
+#endif
+
+#if (defined(CONFIG_SPL_BUILD))
+/* U-Boot proper of armv7 does not need this */
+   b reset
+#endif
+
+/*
+ * For armv7, the addr '_start' will be used as vector start address
+ * and is written to the VBAR register, which needs to aligned to 0x20.
+ */
+   .align(5), 0x0
+_start:
+   ARM_VECTORS
  #endif
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 07b5595dac8c..84a2f0d5ff48 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -402,7 +402,7 @@ config SPL_ROCKCHIP_BACK_TO_BROM
  config 

Re: [PATCH v2 5/5] clk: rockchip: rk3588: fix up the frac pll calculation

[Kever Yang]

On 2023/10/12 18:18, Elaine Zhang wrote:

rk3588 frac pll:
FFVCO = ((m + k / 65536) * FFIN) / p
FFOUT = ((m + k / 65536) * FFIN) / (p * 2s)
k is the original code, but the K[15:0] is complement code
(6'b1000___ <= K[15:0] <= 16'b0111___),
need to be converted.

Signed-off-by: Elaine Zhang 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/clk/rockchip/clk_pll.c | 102 +
  1 file changed, 78 insertions(+), 24 deletions(-)

diff --git a/drivers/clk/rockchip/clk_pll.c b/drivers/clk/rockchip/clk_pll.c
index d657ef38f3c6..1bb31b3313b5 100644
--- a/drivers/clk/rockchip/clk_pll.c
+++ b/drivers/clk/rockchip/clk_pll.c
@@ -168,13 +168,71 @@ rockchip_pll_clk_set_by_auto(ulong fin_hz,
return rate_table;
  }
  
+static u32

+rockchip_rk3588_pll_k_get(u32 m, u32 p, u32 s, u64 fin_hz, u64 fvco)
+{
+   u64 fref, fout, ffrac;
+   u32 k = 0;
+
+   fref = fin_hz / p;
+   ffrac = fvco - (m * fref);
+   fout = ffrac * 65536;
+   k = fout / fref;
+   if (k > 32767) {
+   fref = fin_hz / p;
+   ffrac = ((m + 1) * fref) - fvco;
+   fout = ffrac * 65536;
+   k = ((fout * 10 / fref) + 7) / 10;
+   if (k > 32767)
+   k = 0;
+   else
+   k = ~k + 1;
+   }
+   return k;
+}
+
+static struct rockchip_pll_rate_table *
+rockchip_rk3588_pll_frac_by_auto(unsigned long fin_hz, unsigned long fout_hz)
+{
+   struct rockchip_pll_rate_table *rate_table = _auto_table;
+   u32 p, m, s, k;
+   u64 fvco;
+
+   for (s = 0; s <= 6; s++) {
+   fvco = (u64)fout_hz << s;
+   if (fvco < RK3588_VCO_MIN_HZ || fvco > RK3588_VCO_MAX_HZ)
+   continue;
+   for (p = 1; p <= 4; p++) {
+   for (m = 64; m <= 1023; m++) {
+   if ((fvco >= m * fin_hz / p) &&
+   (fvco < (m + 1) * fin_hz / p)) {
+   k = rockchip_rk3588_pll_k_get(m, p, s,
+ fin_hz,
+ fvco);
+   if (!k)
+   continue;
+   rate_table->p = p;
+   rate_table->s = s;
+   rate_table->k = k;
+   if (k > 32767)
+   rate_table->m = m + 1;
+   else
+   rate_table->m = m;
+   return rate_table;
+   }
+   }
+   }
+   }
+   return NULL;
+}
+
  static struct rockchip_pll_rate_table *
  rk3588_pll_clk_set_by_auto(unsigned long fin_hz,
   unsigned long fout_hz)
  {
struct rockchip_pll_rate_table *rate_table = _auto_table;
u32 p, m, s;
-   ulong fvco, fref, fout, ffrac;
+   ulong fvco;
  
  	if (fin_hz == 0 || fout_hz == 0 || fout_hz == fin_hz)

return NULL;
@@ -202,27 +260,12 @@ rk3588_pll_clk_set_by_auto(unsigned long fin_hz,
}
pr_err("CANNOT FIND Fout by auto,fout = %lu\n", fout_hz);
} else {
-   for (s = 0; s <= 6; s++) {
-   fvco = fout_hz << s;
-   if (fvco < RK3588_VCO_MIN_HZ ||
-   fvco > RK3588_VCO_MAX_HZ)
-   continue;
-   for (p = 1; p <= 4; p++) {
-   for (m = 64; m <= 1023; m++) {
-   if ((fvco >= m * fin_hz / p) && (fvco < 
(m + 1) * fin_hz / p)) {
-   rate_table->p = p;
-   rate_table->m = m;
-   rate_table->s = s;
-   fref = fin_hz / p;
-   ffrac = fvco - (m * fref);
-   fout = ffrac * 65536;
-   rate_table->k = fout / fref;
-   return rate_table;
-   }
-   }
-   }
-   }
-   pr_err("CANNOT FIND Fout by auto,fout = %lu\n", fout_hz);
+   rate_table = rockchip_rk3588_pll_frac_by_auto(fin_hz, fout_hz);
+   if (!rate_table)
+   pr_err("CANNOT FIND Fout by auto,fout = %lu\n",
+  fout_hz);
+   else
+ 

Re: [PATCH v2 4/5] clk: rockchip: rk3588: Avoid re-setting the pll rate of dclk_vop's parent

[Kever Yang]

On 2023/10/12 18:18, Elaine Zhang wrote:

Optimize setting process.

Signed-off-by: Elaine Zhang 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/clk/rockchip/clk_rk3588.c | 24 +---
  1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3588.c 
b/drivers/clk/rockchip/clk_rk3588.c
index 7ba037ad72ba..a995dd5591d3 100644
--- a/drivers/clk/rockchip/clk_rk3588.c
+++ b/drivers/clk/rockchip/clk_rk3588.c
@@ -1130,13 +1130,23 @@ static ulong rk3588_dclk_vop_set_clk(struct 
rk3588_clk_priv *priv,
}
  
  	if (sel == DCLK_VOP_SRC_SEL_V0PLL) {

-   div = DIV_ROUND_UP(RK3588_VOP_PLL_LIMIT_FREQ, rate);
-   rk_clrsetreg(>clksel_con[conid],
-mask,
-DCLK_VOP_SRC_SEL_V0PLL << sel_shift |
-((div - 1) << div_shift));
-   rockchip_pll_set_rate(_pll_clks[V0PLL],
- priv->cru, V0PLL, div * rate);
+   pll_rate = rockchip_pll_get_rate(_pll_clks[V0PLL],
+priv->cru, V0PLL);
+   if (pll_rate >= RK3588_VOP_PLL_LIMIT_FREQ && pll_rate % rate == 
0) {
+   div = DIV_ROUND_UP(pll_rate, rate);
+   rk_clrsetreg(>clksel_con[conid],
+mask,
+DCLK_VOP_SRC_SEL_V0PLL << sel_shift |
+((div - 1) << div_shift));
+   } else {
+   div = DIV_ROUND_UP(RK3588_VOP_PLL_LIMIT_FREQ, rate);
+   rk_clrsetreg(>clksel_con[conid],
+mask,
+DCLK_VOP_SRC_SEL_V0PLL << sel_shift |
+((div - 1) << div_shift));
+   rockchip_pll_set_rate(_pll_clks[V0PLL],
+ priv->cru, V0PLL, div * rate);
+   }
} else {
for (i = 0; i <= DCLK_VOP_SRC_SEL_AUPLL; i++) {
switch (i) {

Re: [PATCH v2 3/5] clk: rockchip: rk3588: support aclk_top_root set 750M

[Kever Yang]

On 2023/10/11 18:29, Elaine Zhang wrote:

aclk_top_root choose a parent clock that does not change.

Signed-off-by: Elaine Zhang 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/clk/rockchip/clk_rk3588.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3588.c 
b/drivers/clk/rockchip/clk_rk3588.c
index c86176264147..7ba037ad72ba 100644
--- a/drivers/clk/rockchip/clk_rk3588.c
+++ b/drivers/clk/rockchip/clk_rk3588.c
@@ -306,12 +306,18 @@ static ulong rk3588_top_set_clk(struct rk3588_clk_priv 
*priv,
  
  	switch (clk_id) {

case ACLK_TOP_ROOT:
-   src_clk_div = DIV_ROUND_UP(priv->gpll_hz, rate);
+   if (!(priv->cpll_hz % rate)) {
+   src_clk = ACLK_TOP_ROOT_SRC_SEL_CPLL;
+   src_clk_div = DIV_ROUND_UP(priv->cpll_hz, rate);
+   } else {
+   src_clk = ACLK_TOP_ROOT_SRC_SEL_GPLL;
+   src_clk_div = DIV_ROUND_UP(priv->gpll_hz, rate);
+   }
assert(src_clk_div - 1 <= 31);
rk_clrsetreg(>clksel_con[8],
 ACLK_TOP_ROOT_DIV_MASK |
 ACLK_TOP_ROOT_SRC_SEL_MASK,
-(ACLK_TOP_ROOT_SRC_SEL_GPLL <<
+(src_clk <<
  ACLK_TOP_ROOT_SRC_SEL_SHIFT) |
 (src_clk_div - 1) << ACLK_TOP_ROOT_DIV_SHIFT);
break;

Re: [PATCH v2 2/5] clk: rk3588: Add 742.5M parameter for PLL

[Kever Yang]

On 2023/10/11 18:29, Elaine Zhang wrote:

From: Guochun Huang 

For a specific frequency.

Signed-off-by: Guochun Huang 
Signed-off-by: Elaine Zhang 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/clk/rockchip/clk_rk3588.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk_rk3588.c 
b/drivers/clk/rockchip/clk_rk3588.c
index 119b1337bdf2..c86176264147 100644
--- a/drivers/clk/rockchip/clk_rk3588.c
+++ b/drivers/clk/rockchip/clk_rk3588.c
@@ -36,6 +36,7 @@ static struct rockchip_pll_rate_table rk3588_pll_rates[] = {
RK3588_PLL_RATE(81600, 2, 272, 2, 0),
RK3588_PLL_RATE(786432000, 2, 262, 2, 9437),
RK3588_PLL_RATE(78600, 1, 131, 2, 0),
+   RK3588_PLL_RATE(74250, 4, 495, 2, 0),
RK3588_PLL_RATE(722534400, 8, 963, 2, 24850),
RK3588_PLL_RATE(6, 2, 200, 2, 0),
RK3588_PLL_RATE(59400, 2, 198, 2, 0),

Re: [PATCH v2 1/5] clk: rockchip: rk3568: support dclk_vop select more parent clks

[Kever Yang]

On 2023/10/11 18:29, Elaine Zhang wrote:

For dclk_vop to support more frequencies.

Signed-off-by: Elaine Zhang 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  drivers/clk/rockchip/clk_rk3568.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3568.c 
b/drivers/clk/rockchip/clk_rk3568.c
index 599b7b130eb9..68f59e57 100644
--- a/drivers/clk/rockchip/clk_rk3568.c
+++ b/drivers/clk/rockchip/clk_rk3568.c
@@ -1838,7 +1838,7 @@ static ulong rk3568_dclk_vop_set_clk(struct 
rk3568_clk_priv *priv,
rockchip_pll_set_rate(_pll_clks[VPLL],
  priv->cru, VPLL, div * rate);
} else {
-   for (i = 0; i <= DCLK_VOP_SEL_CPLL; i++) {
+   for (i = sel; i <= DCLK_VOP_SEL_CPLL; i++) {
switch (i) {
case DCLK_VOP_SEL_GPLL:
pll_rate = priv->gpll_hz;
@@ -2785,9 +2785,15 @@ static int rk3568_dclk_vop_set_parent(struct clk *clk, 
struct clk *parent)
if (parent->id == PLL_VPLL) {
rk_clrsetreg(>clksel_con[con_id], DCLK0_VOP_SEL_MASK,
 DCLK_VOP_SEL_VPLL << DCLK0_VOP_SEL_SHIFT);
-   } else {
+   } else if (parent->id == PLL_HPLL) {
rk_clrsetreg(>clksel_con[con_id], DCLK0_VOP_SEL_MASK,
 DCLK_VOP_SEL_HPLL << DCLK0_VOP_SEL_SHIFT);
+   } else if (parent->id == PLL_CPLL) {
+   rk_clrsetreg(>clksel_con[con_id], DCLK0_VOP_SEL_MASK,
+DCLK_VOP_SEL_CPLL << DCLK0_VOP_SEL_SHIFT);
+   } else {
+   rk_clrsetreg(>clksel_con[con_id], DCLK0_VOP_SEL_MASK,
+DCLK_VOP_SEL_GPLL << DCLK0_VOP_SEL_SHIFT);
}
  
  	return 0;

Re: [PATCH] rockchip: dts: rk3328: Sync rock64 device tree file from Linux

[Kever Yang]

On 2023/10/11 02:27, Matwey V. Kornilov wrote:

Sync the rk3328-rock64 dts from v6.6-rc5.

See Linux kernel commit for details:

 03633c4ef1fb ("arm64: dts: rockchip: fix USB regulator on ROCK64")

Signed-off-by: Matwey V. Kornilov 

Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/dts/rk3328-rock64.dts | 14 ++
  1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/arm/dts/rk3328-rock64.dts b/arch/arm/dts/rk3328-rock64.dts
index f69a38f42d..0a27fa5271 100644
--- a/arch/arm/dts/rk3328-rock64.dts
+++ b/arch/arm/dts/rk3328-rock64.dts
@@ -37,7 +37,8 @@
vin-supply = <_io>;
};
  
-	vcc_host_5v: vcc-host-5v-regulator {

+   /* Common enable line for all of the rails mentioned in the labels */
+   vcc_host_5v: vcc_host1_5v: vcc_otg_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
@@ -48,17 +49,6 @@
vin-supply = <_sys>;
};
  
-	vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {

-   compatible = "regulator-fixed";
-   gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_host_drv>;
-   regulator-name = "vcc_host1_5v";
-   regulator-always-on;
-   regulator-boot-on;
-   vin-supply = <_sys>;
-   };
-
vcc_sys: vcc-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";