Re: [PATCH 2/3] soc: qcom: rpmh and cmd-db drivers

2024-07-08 Thread Sumit Garg
Hi Caleb,

On Mon, 8 Jul 2024 at 16:13, Caleb Connolly  wrote:
>
> Hi Sumit,
>
> Sorry for the late response.
>
> In general, I'd rather keep this port closer to the Linux original, so
> that future cherry-picking of new features and fixes is easier. This is
> quite standard practice in U-Boot (and why the compatibility macro's are
> included in the first place).
>
> Otherwise, we end up with our own quite different implementation, with
> the higher maintenance burden that comes with it.
>
> This port doesn't do a perfect job at keeping close to upstream, but
> still I don't think we should stray further without a good justification.
>

As per your cover letter:

Quote:
   "These drivers were originally taken from Linux, however they have been
heavily modified and simplified for U-Boot. Since the original Linux
drivers contained heavy optimisations related to multithreading and
asynchronous probing, as well as support for idle and suspend states
which we don't need to deal with here."

This made me think the driver is nowhere close to Linux driver
functionality wise. Also, the commit message doesn't say which Linux
commit this driver is influenced from. I am not really sure if
cherry-picking will be straight forward. IMHO, if we are heavily
modifying a driver port for U-Boot then it should be done properly as
per U-Boot needs. A middle ground approach which you have taken is
only going to lead to confusion and rather negatively impact
maintenance.

-Sumit

> Kind regards,
>
> >> +EXPORT_SYMBOL(cmd_db_read_addr);
> >
> > Export symbols aren't required in U-Boot here and other instances in this 
> > patch.
>
> ...
>
> >> +   /*
> >> +* Wait until we read back the same value.  Use a counter rather 
> >> than
> >> +* ktime for timeout since this may be called after timekeeping 
> >> stops.
> >> +*/
> >> +   for (i = 0; i < USEC_PER_SEC; i++) {
> >> +   if (readl(addr) == data)
> >> +   return;
> >> +   udelay(1);
> >> +   }
> >
> > Can we rather use readx_poll_sleep_timeout() here instead?
>
> ...
> >> +   for (i = 0; i < 5 * USEC_PER_SEC; i++) {
> >> +   if (readl(tcs_reg_addr(drv, reg, tcs_id)) & BIT(tcs_id))
> >> +   break;
> >> +   udelay(1);
> >> +   }
> >
> > Can we rather use readx_poll_sleep_timeout() here instead?
>
> ...
>
> >> +
> >> +   spin_lock_irqsave(>lock, flags);
> >
> > Locks aren't needed in U-Boot, can be dropped here and other places.
> >
>
> ...
>
> >> +
> >> +   spin_lock_init(>lock);
> >> +   init_waitqueue_head(>tcs_wait);
> >
> > Similarly waitqueue should be dropped too.
> >
> > -Sumit
>
> --
> // Caleb (they/them)


Re: [PATCH] configs: am62x_evm_a53_defconfig: Remove CONFIG_SYS_BOOTM_LEN

2024-07-08 Thread Manorit Chawdhry
Hi Kamlesh,

On 17:20-20240708, Kamlesh Gurudasani wrote:
> Increase the maximum size of the buffer that is used to decompress
> the OS image in to.
> 
> If image size is greater than the buffer, boot
> will fail with following error,
> "Error: inflate() returned -5"
> "gzip compressed: uncompress error -1"
> 
> Default limit for ARM64 platforms is 0x400, remove
> CONFIG_SYS_BOOTM_LEN=0x800, so that it follows default limit.

Why were we failing with a larger buffer size..?

Regards,
Manorit

> 
> Signed-off-by: Kamlesh Gurudasani 
> ---
>  configs/am62x_evm_a53_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
> index ca993b427b..dfa5ecc847 100644
> --- a/configs/am62x_evm_a53_defconfig
> +++ b/configs/am62x_evm_a53_defconfig
> @@ -32,7 +32,6 @@ CONFIG_SPL_SPI=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
>  CONFIG_BOOTSTD_FULL=y
> -CONFIG_SYS_BOOTM_LEN=0x80
>  CONFIG_BOOTCOMMAND="run findfdt; run envboot; bootflow scan -lb"
>  CONFIG_BOARD_LATE_INIT=y
>  CONFIG_SPL_MAX_SIZE=0x58000
> 
> ---
> base-commit: fd46ea0e701920eb205c2bce9d527bf0dec10b59
> change-id: 20240708-remove-bootm-len-ab4e46039656
> 
> Best regards,
> -- 
> Kamlesh Gurudasani 
> 


[PATCH] xilinx: Enable the NFS command for zynqmp_kria

2024-07-08 Thread Prasad Kummari
Enabled the default utilization of the NFS command on ZynqMP Kria
platforms to facilitate booting images through the network using
the NFS protocol.

Signed-off-by: Prasad Kummari 
---
 configs/xilinx_zynqmp_kria_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/xilinx_zynqmp_kria_defconfig 
b/configs/xilinx_zynqmp_kria_defconfig
index 58e88b25fd..4c66c536d0 100644
--- a/configs/xilinx_zynqmp_kria_defconfig
+++ b/configs/xilinx_zynqmp_kria_defconfig
@@ -81,6 +81,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_BOOTP_MAY_FAIL=y
 CONFIG_BOOTP_BOOTFILESIZE=y
 CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_NFS=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EFIDEBUG=y
-- 
2.25.1



[PATCH] ti: omap: am3517evm: Move environment definition to env file

2024-07-08 Thread Adam Ford
Instead of cluttering up a header file with a bunch of defines,
move the default environmental variables to a file called
am3517evm.env and reference it from the defconfig.  Also
remove dead comments.

Signed-off-by: Adam Ford 

diff --git a/board/logicpd/am3517evm/am3517evm.env 
b/board/logicpd/am3517evm/am3517evm.env
new file mode 100644
index 00..77bb31c416
--- /dev/null
+++ b/board/logicpd/am3517evm/am3517evm.env
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+console=ttyS2,115200n8
+fdtfile=am3517-evm.dtb
+fdtaddr=0x82C0
+vram=16M
+bootenv=uEnv.txt
+mmcdev=0
+mmcpart=1
+mmcroot=/dev/mmcblk0p2 rw
+mmcrootfstype=ext4 rootwait fixrtc
+mmcargs=setenv bootargs console=${console} ${mtdparts} ${optargs} 
root=${mmcroot} rootfstype=${mmcrootfstype} ${cmdline}
+nandargs=setenv bootargs console=${console} ${mtdparts} ${optargs} 
root=ubi0:rootfs rw ubi.mtd=rootfs rootfstype=ubifs rootwait ${cmdline}
+loadbootenv=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootenv}
+importbootenv=echo "Importing environment from mmc ..."; env import -t 
${loadaddr} ${filesize}
+bootscript=echo "Running bootscript from mmc ..."; source ${loadaddr}
+loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootfile}
+loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdtaddr} ${fdtfile}
+mmcboot=echo "Booting from mmc ..."; run mmcargs; bootz ${loadaddr} - 
${fdtaddr}
+nandboot=echo "Booting from nand ..."; run nandargs; nand read ${loadaddr} 
2a 80; nand read ${fdtaddr} aa 8; bootm ${loadaddr} - ${fdtaddr}
diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index 70498ca7fb..3236f1dd67 100644
--- a/configs/am3517_evm_defconfig
+++ b/configs/am3517_evm_defconfig
@@ -6,6 +6,7 @@ CONFIG_TEXT_BASE=0x8010
 CONFIG_SYS_MALLOC_F_LEN=0x4000
 CONFIG_TI_COMMON_CMD_OPTIONS=y
 CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SOURCE_FILE="am3517evm"
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x4020ff00
 CONFIG_DEFAULT_DEVICE_TREE="ti/omap/am3517-evm"
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index b75c648388..e3432ebeaa 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -15,7 +15,7 @@
 #include 
 
 /* Board NAND Info. */
-#ifdef CONFIG_MTD_RAW_NAND
+#if defined(CONFIG_MTD_RAW_NAND)
 #define CFG_SYS_NAND_ECCPOS{ 2,  3,  4,  5,  6,  7,  8,  9, 10, \
 11, 12, 13, 14, 16, 17, 18, 19, 20, \
 21, 22, 23, 24, 25, 26, 27, 28, 30, \
@@ -35,61 +35,8 @@
  *  DTB  4 * NAND_BLOCK_SIZE = 512 KiB  @ 0xAA
  *  RootFS  Remaining Flash Space   @ 0xB2
  */
-#endif /* CONFIG_MTD_RAW_NAND */
-
-/* Environment information */
-#define CFG_EXTRA_ENV_SETTINGS \
-   "loadaddr=0x8200\0" \
-   "console=ttyS2,115200n8\0" \
-   "fdtfile=am3517-evm.dtb\0" \
-   "fdtaddr=0x82C0\0" \
-   "vram=16M\0" \
-   "bootenv=uEnv.txt\0" \
-   "cmdline=\0" \
-   "optargs=\0" \
-   "mmcdev=0\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rw\0" \
-   "mmcrootfstype=ext4 rootwait fixrtc\0" \
-   "mmcargs=setenv bootargs console=${console} " \
-   "${mtdparts} " \
-   "${optargs} " \
-   "root=${mmcroot} " \
-   "rootfstype=${mmcrootfstype} " \
-   "${cmdline}\0" \
-   "nandargs=setenv bootargs console=${console} " \
-   "${mtdparts} " \
-   "${optargs} " \
-   "root=ubi0:rootfs rw ubi.mtd=rootfs " \
-   "rootfstype=ubifs rootwait " \
-   "${cmdline}\0" \
-   "loadbootenv=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootenv}\0"\
-   "importbootenv=echo Importing environment from mmc ...; " \
-   "env import -t ${loadaddr} ${filesize}\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source ${loadaddr}\0" \
-   "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootfile}\0" \
-   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdtaddr} ${fdtfile}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "bootz ${loadaddr} - ${fdtaddr}\0" \
-   "nandboot=echo Booting from nand ...; " \
-   "run nandargs; " \
-   "nand read ${loadaddr} 2a 80; " \
-   "nand read ${fdtaddr} aa 8; " \
-   "bootm ${loadaddr} - ${fdtaddr}\0" \
-
-/* Miscellaneous configurable options */
-
-/* memtest works on */
 
-/* FLASH and environment organization */
-
-/*  PISMO SUPPORT *** */
-   /* on one chip */
-
-#if defined(CONFIG_MTD_RAW_NAND)
 #define CFG_SYS_FLASH_BASE NAND_BASE
-#endif
+#endif /* CONFIG_MTD_RAW_NAND */
 
 #endif /* __CONFIG_H */
-- 
2.43.0



Re: [PATCH v2 00/40] mmc: dw_mmc: Enable eMMC on E850-96 board

2024-07-08 Thread Sam Protsenko
On Thu, Jun 27, 2024 at 9:42 AM Tom Rini  wrote:
>
> On Wed, Jun 26, 2024 at 10:12:12PM +0530, Anand Moon wrote:
> > Hi Sam,
> >
> > On Wed, 19 Jun 2024 at 02:26, Sam Protsenko  
> > wrote:
> > >
> > > If there are no new comments on this series, can you please apply it?
> > >
> > > Thanks!
> >
> > Tested on Odroid XU4 and Odrroid U3 boards
> >
> > Please add my
> >
> > Reviewed-by: Anand Moon 
> > Tested-by: Anand Moon 
>
> Thanks, Minkyu will you be able to pick these up (and other outstanding
> patches) for a pull request to -next soon?
>

Hi Minkyu,

Gentle nudge :) Could you please apply this series? I'm working on
some other features requiring eMMC enabled, so it would be great to
have it merged soon.

Thanks!

> --
> Tom


Re: [PATCH v4 00/14] mediatek: cumulative trivial fix for OF_UPSTREAM support

2024-07-08 Thread Tom Rini
On Mon, 24 Jun 2024 23:03:26 +0200, Christian Marangi wrote:

> This is an initial series that have all the initial trivial
> fixes required for usage of OF_UPSTREAM for the mediatek SoC
> 
> This also contains the pcie-gen3 driver and the required tphy
> support driver to make it work.
> 
> Subsequent series will follow with conversion of the mtk-clk
> to permit usage of OF_UPSTREAM and upstream clk ID.
> 
> [...]

Applied to u-boot/master, thanks!

-- 
Tom




Re: Please pull u-boot-marvell/master

2024-07-08 Thread Tom Rini
On Mon, Jul 08, 2024 at 04:22:52PM +0200, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following Marvell MVEBU related patches into master:
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [GIT PULL] Please pull u-boot-imx-master-20240706

2024-07-08 Thread Tom Rini
On Sat, Jul 06, 2024 at 05:45:47PM -0300, Fabio Estevam wrote:

> Hi Tom,
> 
> Please pull from u-boot-imx/master, thanks.
> 
> The following changes since commit fd46ea0e701920eb205c2bce9d527bf0dec10b59:
> 
>   Merge branch '2024-07-05-assorted-updates' (2024-07-05 16:36:43 -0600)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git 
> tags/u-boot-imx-master-20240706
> 
> for you to fetch changes up to 3d4c29258f8b4c4a5cf4ce79fb1ac80f66e4cf65:
> 
>   clk: imx: add mux ops for i.MX8M composite clk (2024-07-06 15:40:04 -0300)
> 
> u-boot-imx-master-20240706

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


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

2024-07-08 Thread Tom Rini
On Sat, Jul 06, 2024 at 05:46:39PM +0200, Marek Vasut wrote:

> The following changes since commit fd46ea0e701920eb205c2bce9d527bf0dec10b59:
> 
>   Merge branch '2024-07-05-assorted-updates' (2024-07-05 16:36:43 -0600)
> 
> are available in the Git repository at:
> 
>   git://source.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 2fc8638403c740e2dffb8d338bb58694779fd0f9:
> 
>   usb: Assimilate usb_get_descriptor() to linux (2024-07-06 14:45:34 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] u-boot-sh/next-clk-sync

2024-07-08 Thread Tom Rini
On Sat, Jul 06, 2024 at 05:45:22PM +0200, Marek Vasut wrote:

> This is for master branch .
> 
> The following changes since commit 1ebd659cf020843fd8e8ef90d85a66941cbab6ec:
> 
>   Merge tag 'u-boot-dfu-20240606' of 
> https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-06-06 08:24:15 
> -0600)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sh.git next-clk-sync
> 
> for you to fetch changes up to 3c4ee884b73c8c21a1afcefef7d44d6a96fe9bf2:
> 
>   pinctrl: renesas: Synchronize R-Car R8A779G0 V4H PFC tables with Linux 
> 6.9.3 (2024-07-06 14:47:13 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] Revert "buildman: Always use the full path in CROSS_COMPILE"

2024-07-08 Thread Tom Rini
On Fri, 05 Jul 2024 14:34:07 -0600, Tom Rini wrote:

> There are operations in buildman that result in running the cross-tools
> (such as performing size checks) and now that we have not modified PATH
> to know where our tools are, these operations fail.
> 
> This reverts commit 6c0a3cf75f72370deec3ee516a9dd377397af207.
> 
> 
> [...]

Applied to u-boot/master, thanks!

-- 
Tom




[RFC v4 1/2] doc: Remove FIT documentation that is elsewhere

2024-07-08 Thread Sam Povilus
FIT documentation is now a separate project, instead of having a
duplicate, we should point at the other project.

Signed-off-by: Sam Povilus 
---
 doc/usage/fit/index.rst  |   4 +-
 doc/usage/fit/source_file_format.rst | 682 +--
 2 files changed, 5 insertions(+), 681 deletions(-)

diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index bd25bd30b2..52b7d90bbc 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -4,8 +4,8 @@ Flat Image Tree (FIT)
 =
 
 U-Boot uses Flat Image Tree (FIT) as a standard file format for packaging
-images that it it reads and boots. Documentation about FIT is available at
-doc/uImage.FIT
+images that it reads and boots. Documentation about FIT is available in 
+`the Flattened Image Tree project `_.
 
 .. toctree::
 :maxdepth: 1
diff --git a/doc/usage/fit/source_file_format.rst 
b/doc/usage/fit/source_file_format.rst
index b2b1e42bd7..0c44329a82 100644
--- a/doc/usage/fit/source_file_format.rst
+++ b/doc/usage/fit/source_file_format.rst
@@ -3,682 +3,6 @@
 Flattened Image Tree (FIT) Format
 =
 
-Introduction
-
-
-The number of elements playing a role in the kernel booting process has
-increased over time and now typically includes the devicetree, kernel image and
-possibly a ramdisk image. Generally, all must be placed in the system memory 
and
-booted together.
-
-For firmware images a similar process has taken place, with various binaries
-loaded at different addresses, such as ARM's ATF, OpenSBI, FPGA and U-Boot
-itself.
-
-FIT provides a flexible and extensible format to deal with this complexity. It
-provides support for multiple components. It also supports multiple
-configurations, so that the same FIT can be used to boot multiple boards, with
-some components in common (e.g. kernel) and some specific to that board (e.g.
-devicetree).
-
-Terminology
-~~~
-
-This document defines FIT by providing FDT (Flat Device Tree) bindings. These
-describe the final form of the FIT at the moment when it is used. The user
-perspective may be simpler, as some of the properties (like timestamps and
-hashes) are filled in automatically by the U-Boot mkimage tool.
-
-To avoid confusion with the kernel FDT the following naming convention is used:
-
-FIT
-Flattened Image Tree
-
-FIT is formally a flattened devicetree (in the libfdt meaning), which conforms
-to bindings defined in this document.
-
-.its
-image tree source
-
-.itb
-flattened image tree blob
-
-Image-building procedure
-
-
-The following picture shows how the FIT is prepared. Input consists of
-image source file (.its) and a set of data files. Image is created with the
-help of standard U-Boot mkimage tool which in turn uses dtc (device tree
-compiler) to produce image tree blob (.itb). The resulting .itb file is the
-actual binary of a new FIT::
-
-tqm5200.its
-+
-vmlinux.bin.gz mkimage + dtc   xfer to target
-eldk-4.2-ramdisk  --> tqm5200.itb --> boot
-tqm5200.dtb  /|\
-  |
- 'new FIT'
-
-Steps:
-
-#. Create .its file, automatically filled-in properties are omitted
-
-#. Call mkimage tool on a .its file
-
-#. mkimage calls dtc to create .itb image and assures that
-   missing properties are added
-
-#. .itb (new FIT) is uploaded onto the target and used therein
-
-
-Unique identifiers
-~~
-
-To identify FIT sub-nodes representing images, hashes, configurations (which
-are defined in the following sections), the "unit name" of the given sub-node
-is used as it's identifier as it assures uniqueness without additional
-checking required.
-
-
-External data
-~
-
-FIT is normally built initially with image data in the 'data' property of each
-image node. It is also possible for this data to reside outside the FIT itself.
-This allows the 'FDT' part of the FIT to be quite small, so that it can be
-loaded and scanned without loading a large amount of data. Then when an image 
is
-needed it can be loaded from an external source.
-
-External FITs use 'data-offset' or 'data-position' instead of 'data'.
-
-The mkimage tool can convert a FIT to use external data using the `-E` 
argument,
-optionally using `-p` to specific a fixed position.
-
-It is often desirable to align each image to a block size or cache-line size
-(e.g. 512 bytes), so that there is no need to copy it to an aligned address 
when
-reading the image data. The mkimage tool provides a `-B` argument to support
-this.
-
-Root-node properties
-
-
-The root node of the FIT should have the following layout::
-
-/ o image-tree
-|- description = "image description"
-|- timestamp = <12399321>
-|- #address-cells = <1>
-|
-o 

[RFC v4 2/2] doc: add missing table of content links

2024-07-08 Thread Sam Povilus
add missing table of content links, make alphabetical

Signed-off-by: Sam Povilus 
---
 doc/usage/fit/index.rst | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index 52b7d90bbc..ceed452701 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -10,10 +10,23 @@ images that it reads and boots. Documentation about FIT is 
available in
 .. toctree::
 :maxdepth: 1
 
-source_file_format
+beaglebone_vboot
 howto
-x86-fit-boot
+kernel_fdt
+kernel_fdts_compressed
+kernel
+multi
+multi_spl
+multi-with-fpga
+multi-with-loadables
+overlay-fdt-boot
+sec_firmware_ppa
 signature
+sign-configs
+sign-images
+source_file_format
+uefi
+update3
+update_uboot
 verified-boot
-beaglebone_vboot
-overlay-fdt-boot
+x86-fit-boot
\ No newline at end of file
-- 
2.34.1



[RFC v4 0/2] FIT documentation link vs copy

2024-07-08 Thread Sam Povilus
I'm proposing linking the FIT documentation instead of double book keeping it, 
it does have the disadvantage of making it more difficult to see the 
documentation especially if offline. 

v2: update table of contents instead of removing
v3: remove duplicate entries, provide commit message
v4: cleanup: newlines, duplicated word, commit order


Sam Povilus (2):
  doc: Remove FIT documentation that is elsewhere
  doc: add missing table of content links

 doc/usage/fit/index.rst  |  25 +-
 doc/usage/fit/source_file_format.rst | 682 +--
 2 files changed, 22 insertions(+), 685 deletions(-)

-- 
2.34.1



Re: [RFC v3 1/2] doc: Remove FIT documentation that is elsewhere

2024-07-08 Thread Heinrich Schuchardt

On 08.07.24 17:39, Sam Povilus wrote:

FIT documentation is now a separate project, instead of having a
duplicate, we should point at the other project.

Signed-off-by: Sam Povilus 
---
  doc/usage/fit/index.rst  |   5 +-
  doc/usage/fit/source_file_format.rst | 682 +--
  2 files changed, 5 insertions(+), 682 deletions(-)

diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index bd25bd30b2..af2e481212 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -4,13 +4,12 @@ Flat Image Tree (FIT)
  =

  U-Boot uses Flat Image Tree (FIT) as a standard file format for packaging
-images that it it reads and boots. Documentation about FIT is available at
-doc/uImage.FIT
+images that it it reads and boots. Documentation about FIT is available in


%s/it it/it/


+`the Flattened Image Tree project `_.

  .. toctree::
  :maxdepth: 1

-source_file_format


It would preferable not to remove the line in this patch instead of
adding it in the second patch again.


  howto
  x86-fit-boot
  signature
diff --git a/doc/usage/fit/source_file_format.rst 
b/doc/usage/fit/source_file_format.rst
index b2b1e42bd7..0c44329a82 100644
--- a/doc/usage/fit/source_file_format.rst
+++ b/doc/usage/fit/source_file_format.rst
@@ -3,682 +3,6 @@
  Flattened Image Tree (FIT) Format
  =

-Introduction
-
-
-The number of elements playing a role in the kernel booting process has
-increased over time and now typically includes the devicetree, kernel image and
-possibly a ramdisk image. Generally, all must be placed in the system memory 
and
-booted together.
-
-For firmware images a similar process has taken place, with various binaries
-loaded at different addresses, such as ARM's ATF, OpenSBI, FPGA and U-Boot
-itself.
-
-FIT provides a flexible and extensible format to deal with this complexity. It
-provides support for multiple components. It also supports multiple
-configurations, so that the same FIT can be used to boot multiple boards, with
-some components in common (e.g. kernel) and some specific to that board (e.g.
-devicetree).
-
-Terminology
-~~~
-
-This document defines FIT by providing FDT (Flat Device Tree) bindings. These
-describe the final form of the FIT at the moment when it is used. The user
-perspective may be simpler, as some of the properties (like timestamps and
-hashes) are filled in automatically by the U-Boot mkimage tool.
-
-To avoid confusion with the kernel FDT the following naming convention is used:
-
-FIT
-Flattened Image Tree
-
-FIT is formally a flattened devicetree (in the libfdt meaning), which conforms
-to bindings defined in this document.
-
-.its
-image tree source
-
-.itb
-flattened image tree blob
-
-Image-building procedure
-
-
-The following picture shows how the FIT is prepared. Input consists of
-image source file (.its) and a set of data files. Image is created with the
-help of standard U-Boot mkimage tool which in turn uses dtc (device tree
-compiler) to produce image tree blob (.itb). The resulting .itb file is the
-actual binary of a new FIT::
-
-tqm5200.its
-+
-vmlinux.bin.gz mkimage + dtc   xfer to target
-eldk-4.2-ramdisk  --> tqm5200.itb --> boot
-tqm5200.dtb  /|\
-  |
- 'new FIT'
-
-Steps:
-
-#. Create .its file, automatically filled-in properties are omitted
-
-#. Call mkimage tool on a .its file
-
-#. mkimage calls dtc to create .itb image and assures that
-   missing properties are added
-
-#. .itb (new FIT) is uploaded onto the target and used therein
-
-
-Unique identifiers
-~~
-
-To identify FIT sub-nodes representing images, hashes, configurations (which
-are defined in the following sections), the "unit name" of the given sub-node
-is used as it's identifier as it assures uniqueness without additional
-checking required.
-
-
-External data
-~
-
-FIT is normally built initially with image data in the 'data' property of each
-image node. It is also possible for this data to reside outside the FIT itself.
-This allows the 'FDT' part of the FIT to be quite small, so that it can be
-loaded and scanned without loading a large amount of data. Then when an image 
is
-needed it can be loaded from an external source.
-
-External FITs use 'data-offset' or 'data-position' instead of 'data'.
-
-The mkimage tool can convert a FIT to use external data using the `-E` 
argument,
-optionally using `-p` to specific a fixed position.
-
-It is often desirable to align each image to a block size or cache-line size
-(e.g. 512 bytes), so that there is no need to copy it to an aligned address 
when
-reading the image data. The mkimage tool provides a `-B` argument to support
-this.
-
-Root-node 

Re: [RFC v3 2/2] doc: add missing table of content links

2024-07-08 Thread Heinrich Schuchardt

On 08.07.24 18:04, Heinrich Schuchardt wrote:

On 08.07.24 17:39, Sam Povilus wrote:

add missing table of content links, make alphabetical

Signed-off-by: Sam Povilus 
---
  doc/usage/fit/index.rst | 21 ++---
  1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index af2e481212..ed28dc89ae 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -10,9 +10,24 @@ images that it it reads and boots. Documentation
about FIT is available in
  .. toctree::
  :maxdepth: 1

+    beaglebone_vboot
  howto
-    x86-fit-boot
+    kernel_fdt
+    kernel_fdts_compressed
+    kernel
+    multi
+    multi_spl
+    multi-with-fpga
+    multi-with-loadables
+    overlay-fdt-boot
+    sec_firmware_ppa
  signature
+    sign-configs
+    sign-images
+    source_file_format


In patch 1 you delete this page.

Run 'make html' fails on this.

When changing documentation, please, build it.


Got that wrong.

The trailing blank line can be removed when merging.

Reviewed-by: Heinrich Schuchardt 




+    uefi
+    update3
+    update_uboot
  verified-boot
-    beaglebone_vboot
-    overlay-fdt-boot
+    x86-fit-boot
+


We should avoid trailing blank lines at the end of files.

Otherwise looks good to me.

Best regards

Heinrich





Re: [RFC v3 2/2] doc: add missing table of content links

2024-07-08 Thread Heinrich Schuchardt

On 08.07.24 17:39, Sam Povilus wrote:

add missing table of content links, make alphabetical

Signed-off-by: Sam Povilus 
---
  doc/usage/fit/index.rst | 21 ++---
  1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index af2e481212..ed28dc89ae 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -10,9 +10,24 @@ images that it it reads and boots. Documentation about FIT 
is available in
  .. toctree::
  :maxdepth: 1

+beaglebone_vboot
  howto
-x86-fit-boot
+kernel_fdt
+kernel_fdts_compressed
+kernel
+multi
+multi_spl
+multi-with-fpga
+multi-with-loadables
+overlay-fdt-boot
+sec_firmware_ppa
  signature
+sign-configs
+sign-images
+source_file_format


In patch 1 you delete this page.

Run 'make html' fails on this.

When changing documentation, please, build it.


+uefi
+update3
+update_uboot
  verified-boot
-beaglebone_vboot
-overlay-fdt-boot
+x86-fit-boot
+


We should avoid trailing blank lines at the end of files.

Otherwise looks good to me.

Best regards

Heinrich



Re: [PATCH v3 1/5] linux/bitmap.h: add bitmap_empty helper

2024-07-08 Thread Tom Rini
On Mon, Jul 08, 2024 at 02:20:23PM +0200, Caleb Connolly wrote:

> Import this function from Linux.
> 
> Signed-off-by: Caleb Connolly 

Since I just told someone else this too, please note that tag you're
taking this from in the Linux Kernel, thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 6/6] linux: bitmap.h: Add for_each_set_bit_from() function

2024-07-08 Thread Tom Rini
On Mon, Jul 08, 2024 at 01:22:07PM +0530, Scaria Kochidanadu wrote:

> Add function macro for_each_set_bit_from(), an extension to the already
> existing function macro for_each_set_bit() to iterate through set bits
> of a variable from a given bit index as required by the MCASP Driver.
> 
> Signed-off-by: Scaria Kochidanadu 
> ---
>  include/linux/bitmap.h | 5 +
>  1 file changed, 5 insertions(+)

Please note the Linux Kernel commit (or tag, really) you're backporting
this function from and emphasize that, not what you're using it for,
thanks.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/6] arm: dts: k3-am625-sk-u-boot.dtsi: Add sound driver nodes

2024-07-08 Thread Tom Rini
On Mon, Jul 08, 2024 at 01:22:05PM +0530, Scaria Kochidanadu wrote:

> Update the am625-sk-u-boot device tree to incorporate the sound card and
> sound drivers: MCASP and TLV320AIC3106 Codec
> 
> Signed-off-by: Scaria Kochidanadu 
> ---
>  arch/arm/dts/k3-am625-sk-u-boot.dtsi | 85 
>  1 file changed, 85 insertions(+)

Where's all of this in the upstream dts?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/6] sound: ti: Add sound support for am625 board in Uboot

2024-07-08 Thread Tom Rini
On Mon, Jul 08, 2024 at 01:22:02PM +0530, Scaria Kochidanadu wrote:

> Add a UCLASS_SOUND driver for Texas Instruments SoCs which ties together
> the tlv320aic3106 audio codec and MCASP I2S controller. Enable audio
> playback functionality by taking a data pointer and data size as the
> sound data. The uboot sound play command takes time and frequency as
> input and creates the data for a beep sound with the given parameters,
> which is then passed to the sound play function.
[snip]
> +++ b/drivers/sound/ti_sound.c
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2024 Texas Instruments Incorporated - https://www.ti.com/
> + * Scaria M Kochidanadu, s-kochidan...@ti.com
> + *
> + * based on the uboot samsung sound driver, which is
> + *
> + * Copyright 2018 Google, LLC
> + * Written by Simon Glass 
> + */
> +
> +#include  /* boot information for Linux kernel */
> +/* Pull in stuff for the build system */
> +#ifdef DO_DEPS_ONLY
> +#include 
> +#endif
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Please audit this list. I really am confused by .

> +static int ti_sound_stop_play(struct udevice *dev)
> +{
> + /* This function is necassary to satisfy the function calls
> +  * in the Uboot command: sound play
> +  */
> + return 0;

/*
 * Like this...
 */

[snip]
> +static const struct udevice_id ti_sound_ids[] = {
> + { .compatible = "simple-audio-card" },
> + { }
> +};

Adding an actual simple-audio-card framework for U-Boot would be great.
This driver implies (and is?) TI-centric, instead. So lets rework this
to be split appropriately? Thanks.

-- 
Tom


signature.asc
Description: PGP signature


[RFC v3 0/2] FIT documentation link vs copy

2024-07-08 Thread Sam Povilus
I'm proposing linking the FIT documentation instead of double book keeping it, 
it does have the disadvantage of making it more difficult to see the 
documentation especially if offline. 

v2: update table of contents instead of removing
v3: remove duplicate entries, provide commit message

Sam Povilus (2):
  doc: Remove FIT documentation that is elsewhere
  doc: add missing table of content links

 doc/usage/fit/index.rst  |  26 +-
 doc/usage/fit/source_file_format.rst | 682 +--
 2 files changed, 23 insertions(+), 685 deletions(-)

-- 
2.34.1



[RFC v3 2/2] doc: add missing table of content links

2024-07-08 Thread Sam Povilus
add missing table of content links, make alphabetical 

Signed-off-by: Sam Povilus 
---
 doc/usage/fit/index.rst | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index af2e481212..ed28dc89ae 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -10,9 +10,24 @@ images that it it reads and boots. Documentation about FIT 
is available in
 .. toctree::
 :maxdepth: 1
 
+beaglebone_vboot
 howto
-x86-fit-boot
+kernel_fdt
+kernel_fdts_compressed
+kernel
+multi
+multi_spl
+multi-with-fpga
+multi-with-loadables
+overlay-fdt-boot
+sec_firmware_ppa
 signature
+sign-configs
+sign-images
+source_file_format
+uefi
+update3
+update_uboot
 verified-boot
-beaglebone_vboot
-overlay-fdt-boot
+x86-fit-boot
+
-- 
2.34.1



[RFC v3 1/2] doc: Remove FIT documentation that is elsewhere

2024-07-08 Thread Sam Povilus
FIT documentation is now a separate project, instead of having a
duplicate, we should point at the other project.

Signed-off-by: Sam Povilus 
---
 doc/usage/fit/index.rst  |   5 +-
 doc/usage/fit/source_file_format.rst | 682 +--
 2 files changed, 5 insertions(+), 682 deletions(-)

diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index bd25bd30b2..af2e481212 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -4,13 +4,12 @@ Flat Image Tree (FIT)
 =
 
 U-Boot uses Flat Image Tree (FIT) as a standard file format for packaging
-images that it it reads and boots. Documentation about FIT is available at
-doc/uImage.FIT
+images that it it reads and boots. Documentation about FIT is available in 
+`the Flattened Image Tree project `_.
 
 .. toctree::
 :maxdepth: 1
 
-source_file_format
 howto
 x86-fit-boot
 signature
diff --git a/doc/usage/fit/source_file_format.rst 
b/doc/usage/fit/source_file_format.rst
index b2b1e42bd7..0c44329a82 100644
--- a/doc/usage/fit/source_file_format.rst
+++ b/doc/usage/fit/source_file_format.rst
@@ -3,682 +3,6 @@
 Flattened Image Tree (FIT) Format
 =
 
-Introduction
-
-
-The number of elements playing a role in the kernel booting process has
-increased over time and now typically includes the devicetree, kernel image and
-possibly a ramdisk image. Generally, all must be placed in the system memory 
and
-booted together.
-
-For firmware images a similar process has taken place, with various binaries
-loaded at different addresses, such as ARM's ATF, OpenSBI, FPGA and U-Boot
-itself.
-
-FIT provides a flexible and extensible format to deal with this complexity. It
-provides support for multiple components. It also supports multiple
-configurations, so that the same FIT can be used to boot multiple boards, with
-some components in common (e.g. kernel) and some specific to that board (e.g.
-devicetree).
-
-Terminology
-~~~
-
-This document defines FIT by providing FDT (Flat Device Tree) bindings. These
-describe the final form of the FIT at the moment when it is used. The user
-perspective may be simpler, as some of the properties (like timestamps and
-hashes) are filled in automatically by the U-Boot mkimage tool.
-
-To avoid confusion with the kernel FDT the following naming convention is used:
-
-FIT
-Flattened Image Tree
-
-FIT is formally a flattened devicetree (in the libfdt meaning), which conforms
-to bindings defined in this document.
-
-.its
-image tree source
-
-.itb
-flattened image tree blob
-
-Image-building procedure
-
-
-The following picture shows how the FIT is prepared. Input consists of
-image source file (.its) and a set of data files. Image is created with the
-help of standard U-Boot mkimage tool which in turn uses dtc (device tree
-compiler) to produce image tree blob (.itb). The resulting .itb file is the
-actual binary of a new FIT::
-
-tqm5200.its
-+
-vmlinux.bin.gz mkimage + dtc   xfer to target
-eldk-4.2-ramdisk  --> tqm5200.itb --> boot
-tqm5200.dtb  /|\
-  |
- 'new FIT'
-
-Steps:
-
-#. Create .its file, automatically filled-in properties are omitted
-
-#. Call mkimage tool on a .its file
-
-#. mkimage calls dtc to create .itb image and assures that
-   missing properties are added
-
-#. .itb (new FIT) is uploaded onto the target and used therein
-
-
-Unique identifiers
-~~
-
-To identify FIT sub-nodes representing images, hashes, configurations (which
-are defined in the following sections), the "unit name" of the given sub-node
-is used as it's identifier as it assures uniqueness without additional
-checking required.
-
-
-External data
-~
-
-FIT is normally built initially with image data in the 'data' property of each
-image node. It is also possible for this data to reside outside the FIT itself.
-This allows the 'FDT' part of the FIT to be quite small, so that it can be
-loaded and scanned without loading a large amount of data. Then when an image 
is
-needed it can be loaded from an external source.
-
-External FITs use 'data-offset' or 'data-position' instead of 'data'.
-
-The mkimage tool can convert a FIT to use external data using the `-E` 
argument,
-optionally using `-p` to specific a fixed position.
-
-It is often desirable to align each image to a block size or cache-line size
-(e.g. 512 bytes), so that there is no need to copy it to an aligned address 
when
-reading the image data. The mkimage tool provides a `-B` argument to support
-this.
-
-Root-node properties
-
-
-The root node of the FIT should have the following layout::
-
-/ o image-tree
-|- description = "image description"
-|- 

Re: Warnings with xilinx_zynqmp_virt

2024-07-08 Thread Michal Simek

Hi Simon,

On 7/2/24 17:51, Simon Glass wrote:

Hi Michal,

I am seeing errors when building xilinx_zynqmp_virt:

Can't set hash 'value' property for 'hash' node(FDT_ERR_NOSPACE)
Can't set hash value for 'hash' hash node in 'fdt_35' image node
Can't add verification data for node 'fdt_35' ()

The problem is visible in CI, e.g. [1]

A bisect points to this, but it might not be helpful:

46f04087712 (refs/bisect/bad) arm64: zynqmp: Add support for vck190
revB system controller



I am aware about this issue.  I didn't have time to dig into it but actually 
that error should be suppress.


It is based on your commit
commit a9468115699de562f08796bf2eabd832435bedec
Author: Simon Glass 
AuthorDate: Mon Jun 2 22:04:53 2014 -0600
Commit: Tom Rini 
CommitDate: Wed Jun 11 16:25:46 2014 -0400

mkimage: Automatically make space in FDT when full

When adding hashes or signatures, the target FDT may be full. Detect this
and automatically try again after making 1KB of space.

Signed-off-by: Simon Glass 


that there is missing space in FDT. The first error should be reported from this 
function


diff --git a/boot/image-fit.c b/boot/image-fit.c
index 9253f81fff54..3509ed3bd168 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -1218,7 +1218,7 @@ int fit_set_timestamp(void *fit, int noffset, time_t 
timestamp)

ret = fdt_setprop(fit, noffset, FIT_TIMESTAMP_PROP, ,
sizeof(uint32_t));
if (ret) {
-   debug("Can't set '%s' property for '%s' node (%s)\n",
+   fprintf(stderr, "Can't set '%s' property for '%s' node (%s)\n",
  FIT_TIMESTAMP_PROP, fit_get_name(fit, noffset, NULL),
  fdt_strerror(ret));
return ret == -FDT_ERR_NOSPACE ? -ENOSPC : -1;


but
commit 8df81e17f81ba0542f6dbb7636db64fa56c12d8a
Author: Simon Glass 
AuthorDate: Sun May 1 13:55:37 2016 -0600
Commit: Tom Rini 
CommitDate: Mon May 23 11:50:18 2016 -0400

image-fit: Don't display an error in fit_set_timestamp()

This function returns an error code and its caller may be able to fix the
error. For example fit_handle_file() expands the device tree to fit if there
is a lack of space.

In this case the caller does not want an error displayed. It is confusing,
since it suggests that something is wrong, when it fact everything is fine.
Drop the error.

Signed-off-by: Simon Glass 

change it from printf to debug
I think the same chagne should be done for my error messages. Something like 
this.

diff --git a/tools/image-host.c b/tools/image-host.c
index 49ce7436bb97..e9e5eebe8dc3 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -40,7 +40,7 @@ static int fit_set_hash_value(void *fit, int noffset, uint8_t 
*value,


ret = fdt_setprop(fit, noffset, FIT_VALUE_PROP, value, value_len);
if (ret) {
-   fprintf(stderr, "Can't set hash '%s' property for '%s' 
node(%s)\n",
+   debug("Can't set hash '%s' property for '%s' node(%s)\n",
FIT_VALUE_PROP, fit_get_name(fit, noffset, NULL),
fdt_strerror(ret));
return ret == -FDT_ERR_NOSPACE ? -ENOSPC : -EIO;



Also the board seems to be the only one still using SPL_FIT_GENERATOR.
The migration message was added almost 3 years ago. Would it be
possible to move it to use Binman?


we have it on our todo list but Venkatesh didn't get to that yet.

Thanks,
Michal



[PATCH] doc/sphinx/requirements.txt: Bump certifi and urllib3

2024-07-08 Thread Tom Rini
As reported by GitHub dependabot, both of these packages should be
bumped to their latest versions to address security issues (neither of
which has a CVE assigned).

Reported-by: GitHub dependabot
Signed-off-by: Tom Rini 
---
 doc/sphinx/requirements.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt
index 306b05a995e6..40dde599916e 100644
--- a/doc/sphinx/requirements.txt
+++ b/doc/sphinx/requirements.txt
@@ -1,6 +1,6 @@
 alabaster==0.7.16
 Babel==2.15.0
-certifi==2024.6.2
+certifi==2024.7.4
 charset-normalizer==3.3.2
 docutils==0.20.1
 idna==3.7
@@ -22,4 +22,4 @@ sphinxcontrib-jquery==4.1
 sphinxcontrib-jsmath==1.0.1
 sphinxcontrib-qthelp==1.0.7
 sphinxcontrib-serializinghtml==1.1.10
-urllib3==2.2.1
+urllib3==2.2.2
-- 
2.34.1



Re: [RFC PATCH v2 16/48] lmb: config: add lmb config symbols for SPL

2024-07-08 Thread Tom Rini
On Mon, Jul 08, 2024 at 05:06:45PM +0530, Sughosh Ganu wrote:
> On Sat, 6 Jul 2024 at 01:18, Tom Rini  wrote:
> >
> > On Thu, Jul 04, 2024 at 01:05:12PM +0530, Sughosh Ganu wrote:
> >
> > > Add separate config symbols for enabling the LMB module for the SPL
> > > phase. The LMB module implementation now relies on alloced list data
> > > structure which requires heap area to be present. Add specific config
> > > symbol for the SPL phase of U-Boot so that this can be enabled on
> > > platforms which support a heap in SPL.
> > >
> > > Signed-off-by: Sughosh Ganu 
> > > ---
> > > Changes since V1: New patch
> > >
> > >  lib/Kconfig | 12 +++-
> > >  1 file changed, 11 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/lib/Kconfig b/lib/Kconfig
> > > index 072ed0ecfa..7eea517b3b 100644
> > > --- a/lib/Kconfig
> > > +++ b/lib/Kconfig
> > > @@ -1103,7 +1103,17 @@ config LMB
> > >   default y if ARC || ARM || M68K || MICROBLAZE || MIPS || \
> > >NIOS2 || PPC || RISCV || SANDBOX || SH || X86 || XTENSA
> > >   help
> > > -   Support the library logical memory blocks.
> > > +   Support the library logical memory blocks. This will require
> > > +   a malloc() implementation for defining the data structures
> > > +   needed for maintaining the LMB memory map.
> >
> > Even today, LMB really should be def_bool y rather than an option, so
> > this series should correct that. That said...
> 
> Okay
> 
> >
> > > +config SPL_LMB
> > > + bool "Enable LMB module for SPL"
> > > + depends on SPL && SPL_FRAMEWORK && SPL_SYS_MALLOC
> > > + help
> > > +   Enable support for Logical Memory Block library routines in
> > > +   SPL. This will require a malloc() implementation for defining
> > > +   the data structures needed for maintaining the LMB memory map.
> >
> > The question I guess becomes when do we need LMB in SPL, exactly? And I
> > guess it's another case where it should be def_bool y (but still depends
> > on what you have here) since we need to make sure we don't overwrite
> > running SPL.
> 
> So this is a question even I had. Do we really need to enable LMB in
> SPL ? The main reason for introducing the symbol was to have more
> granularity to remove the LMB code from SPL, but should this really be
> enabled in SPL is something that I am not too sure about.

Yes, we need to ensure we obey reservations in SPL, both for U-Boot and
for when we boot the OS from SPL.

-- 
Tom


signature.asc
Description: PGP signature


Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent

2024-07-08 Thread Tom Rini
On Thu, Jul 04, 2024 at 01:04:56PM +0530, Sughosh Ganu wrote:

> The aim of this patch series is to fix the current state of
> incoherence between modules when it comes to memory usage. The primary
> issue that this series is trying to fix is that the EFI memory module
> which is responsible for allocating and freeing memory, does not have
> any visibility of the memory that is being used by the LMB
> module. This is further complicated by the fact that the LMB
> allocations are caller specific -- the LMB memory map is not global
> nor persistent. This means that the memory "allocated" by the LMB
> module might be relevant only for a given function. Hence one of the
> requirements for making the memory usage visible across modules is to
> make LMB allocations persistent and global, and then have means to
> communicate the use of memory across modules.
> 
> The first set of patches in this series work on making the LMB memory
> map persistent and global. This is being done keeping in mind the
> usage of LMB memory by platforms where the same memory region can be
> used to load multiple different images. What is not allowed is to
> overwrite memory that has been allocated by the other module,
> currently the EFI memory module. This is being achieved by introducing
> a new flag, LMB_NOOVERWRITE, which represents memory which cannot be
> re-requested once allocated.
> 
> A review comment on the earlier version was to do away with the static
> arrays for the LMB lists of free and used memory. This version
> uses the alloced list data structure for the LMB lists.
> 
> The second set of patches are making changes to the EFI memory module
> to make use of the LMB functions to allocate and free memory. A
> *_flags() version of LMB API's has been introduced for the same. The
> earlier version was using notification mechanism from both LMB and EFI
> modules to maintain memory coherence. This version makes use of the
> LMB API functions for the memory allocations. This is based on review
> comments of EFI maintainers.

Please re-work so that the series is bisectable. For example
xilinx_zynqmp_r5 fails that check currently. And I found that looking in
to why it grows by ~1500 bytes overall. This likely is due to
CONFIG_EFI_LOADER=n and so while the case where EFI_LOADER is enabled
tends to be a size win (reduction) or wash we need to look at the
CONFIG_EFI_LOADER=n case more. The alist code will be a little growth
and that's fine enough. But realloc and do_bdinfo are the two big
growths at the top, in this case.

-- 
Tom


signature.asc
Description: PGP signature


Please pull u-boot-marvell/master

2024-07-08 Thread Stefan Roese

Hi Tom,

please pull the following Marvell MVEBU related patches into master:


- Add mvebu_espressobin_ultra-88f3720_defconfig (Benjamin)
- Update DTS for Thecus N2350 board (Tony)
- Add "old" Marvell DDR3 training for Armada 38x and Turris Omnia
  (Marek)
- Misc turris_omnia changes (Marek)


Here the Azure build, without any issues:

https://dev.azure.com/sr0718/u-boot/_build/results?buildId=372=results

Thanks,
Stefan

The following changes since commit fd46ea0e701920eb205c2bce9d527bf0dec10b59:

  Merge branch '2024-07-05-assorted-updates' (2024-07-05 16:36:43 -0600)

are available in the Git repository at:

  g...@source.denx.de:u-boot/custodians/u-boot-marvell.git

for you to fetch changes up to 711443eafe0d8064744f6ee69cef08b032346c74:

  mvebu: armada-8k: respect CONFIG_DISTRO_DEFAULTS (2024-07-08 08:20:58 
+0200)



Benjamin Schneider (1):
  configs: add mvebu_espressobin_ultra-88f3720_defconfig

Marek Behún (16):
  arm: mvebu: turris_omnia: Disable ext4 write support in defconfig
  ddr: marvell: a38x: debug: return from ddr3_tip_print_log() early 
if we won't print anything

  ddr: marvell: a38x: debug: Remove unused variables
  ddr: marvell: a38x: debug: Define DDR_VIEWER_TOOL variables only 
if needed, and make them static
  ddr: marvell: a38x: debug: Allow compiling with immutable debug 
settings to reduce binary size
  arm: mvebu: turris_omnia: Enable immutable debug settings in DDR3 
training by default

  arm: mvebu: turris_omnia: Fix ethernet PHY reset gpio FDT fixup
  arm: mvebu: turris_omnia: Implement EEPROM layout for the 
'eeprom' command

  arm: mvebu: turris_omnia: Enable the 'eeprom' command
  arm: mvebu: turris_omnia: Extend EEPROM info structure
  arm: mvebu: turris_omnia: Read DDR speed from EEPROM
  ddr: marvell: a38x: Import old DDR training code from 2017 
version of U-Boot

  ddr: marvell: a38x: old: Fix some compiler warning of the old code
  ddr: marvell: a38x: old: Backport immutable debug settings
  arm: mvebu: a38x: Add optional support for using old DDR3 
training code

  arm: mvebu: turris_omnia: Support old DDR3 training

Robert Marko (1):
  mvebu: armada-8k: respect CONFIG_DISTRO_DEFAULTS

Tony Dinh (2):
  arm: mvebu: env_sf_get_env_addr() missing check for 
CONFIG_ENV_IS_IN_SPI_FLASH

  arm: dts: mvebu: Update DTS for Thecus N2350 board

 arch/arm/dts/armada-385-thecus-n2350.dts   |   10 +-
 arch/arm/mach-mvebu/Kconfig|   15 +
 arch/arm/mach-mvebu/cpu.c  |2 +-
 arch/arm/mach-mvebu/include/mach/cpu.h |1 +
 arch/arm/mach-mvebu/spl.c  |   37 +-
 board/CZ.NIC/turris_omnia/Makefile |2 +
 board/CZ.NIC/turris_omnia/eeprom.c |  190 ++
 board/CZ.NIC/turris_omnia/old_ddr3_training.c  |   63 +
 board/CZ.NIC/turris_omnia/turris_omnia.c   |  199 +-
 board/Marvell/mvebu_armada-37xx/MAINTAINERS|5 +
 configs/mvebu_espressobin_ultra-88f3720_defconfig  |  106 +
 configs/turris_omnia_defconfig |6 +-
 drivers/ddr/marvell/a38x/Makefile  |2 +
 drivers/ddr/marvell/a38x/ddr3_debug.c  |   30 +-
 drivers/ddr/marvell/a38x/ddr3_init.c   |3 +-
 drivers/ddr/marvell/a38x/ddr3_init.h   |   43 +-
 drivers/ddr/marvell/a38x/old/Makefile  |   29 +
 drivers/ddr/marvell/a38x/old/ddr3_a38x.c   |  737 ++
 drivers/ddr/marvell/a38x/old/ddr3_a38x.h   |   93 +
 drivers/ddr/marvell/a38x/old/ddr3_a38x_mc_static.h |  226 ++
 drivers/ddr/marvell/a38x/old/ddr3_a38x_topology.h  |   22 +
 drivers/ddr/marvell/a38x/old/ddr3_a38x_training.c  |   39 +
 drivers/ddr/marvell/a38x/old/ddr3_debug.c  | 1546 
 .../ddr/marvell/a38x/old/ddr3_hws_hw_training.c|  147 ++
 .../ddr/marvell/a38x/old/ddr3_hws_hw_training.h|   49 +
 .../marvell/a38x/old/ddr3_hws_hw_training_def.h|  464 
 .../ddr/marvell/a38x/old/ddr3_hws_sil_training.h   |   17 +
 drivers/ddr/marvell/a38x/old/ddr3_init.c   |  769 ++
 drivers/ddr/marvell/a38x/old/ddr3_init.h   |  405 +++
 drivers/ddr/marvell/a38x/old/ddr3_logging_def.h|  101 +
 drivers/ddr/marvell/a38x/old/ddr3_patterns_64bit.h |  924 +++
 drivers/ddr/marvell/a38x/old/ddr3_topology_def.h   |   76 +
 drivers/ddr/marvell/a38x/old/ddr3_training.c   | 2650 


 drivers/ddr/marvell/a38x/old/ddr3_training_bist.c  |  288 +++
 .../a38x/old/ddr3_training_centralization.c|  711 ++
 drivers/ddr/marvell/a38x/old/ddr3_training_db.c|  651 +
 .../ddr/marvell/a38x/old/ddr3_training_hw_algo.c   |  685 +
 .../ddr/marvell/a38x/old/ddr3_training_hw_algo.h   |   14 +
 

Re: [PATCH] mvebu: armada-8k: respect CONFIG_DISTRO_DEFAULTS

2024-07-08 Thread Stefan Roese

On 6/21/24 11:46, Robert Marko wrote:

Currently, Armada 8k config header is setting boot devices and including
 regardless of the CONFIG_DISTRO_DEFAULTS being
enabled or not, thus populating the environment for distro boot even on
devices that have no need for it.

So, lets simply respect the value of CONFIG_DISTRO_DEFAULTS.

Signed-off-by: Robert Marko 


Applied to u-boot-marvell/master

Thanks,
Stefan


---
  include/configs/mvebu_armada-8k.h | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/configs/mvebu_armada-8k.h 
b/include/configs/mvebu_armada-8k.h
index 239a09763a..6fedbe9ee3 100644
--- a/include/configs/mvebu_armada-8k.h
+++ b/include/configs/mvebu_armada-8k.h
@@ -30,7 +30,7 @@
  /*
   * PCI configuration
   */
-
+#ifdef CONFIG_DISTRO_DEFAULTS
  #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 1) \
func(MMC, mmc, 0) \
@@ -40,6 +40,9 @@
func(DHCP, dhcp, na)
  
  #include 

+#else
+#define BOOTENV
+#endif
  
  #define CFG_EXTRA_ENV_SETTINGS	\

"scriptaddr=0x6d0\0"  \


Viele Grüße,
Stefan Roese

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


Re: [PATCH u-boot-marvell 00/16] Turris Omnia DDR training changes

2024-07-08 Thread Stefan Roese

On 6/18/24 17:34, Marek Behún wrote:

Hi Stefan,

this is v2 of the series adds some changes to DDR3 training for Armada
38x and Turris Omnia.

I also put one unrelated patch (Fix ethernet PHY reset gpio FDT fixup)
here.

It depends on stuff in Tom's next branch.


Applied to u-boot-marvell/master

Thanks,
Stefan



Marek

Marek Behún (16):
   arm: mvebu: turris_omnia: Disable ext4 write support in defconfig
   ddr: marvell: a38x: debug: return from ddr3_tip_print_log() early if
 we won't print anything
   ddr: marvell: a38x: debug: Remove unused variables
   ddr: marvell: a38x: debug: Define DDR_VIEWER_TOOL variables only if
 needed, and make them static
   ddr: marvell: a38x: debug: Allow compiling with immutable debug
 settings to reduce binary size
   arm: mvebu: turris_omnia: Enable immutable debug settings in DDR3
 training by default
   arm: mvebu: turris_omnia: Fix ethernet PHY reset gpio FDT fixup
   arm: mvebu: turris_omnia: Implement EEPROM layout for the 'eeprom'
 command
   arm: mvebu: turris_omnia: Enable the 'eeprom' command
   arm: mvebu: turris_omnia: Extend EEPROM info structure
   arm: mvebu: turris_omnia: Read DDR speed from EEPROM
   ddr: marvell: a38x: Import old DDR training code from 2017 version of
 U-Boot
   ddr: marvell: a38x: old: Fix some compiler warning of the old code
   ddr: marvell: a38x: old: Backport immutable debug settings
   arm: mvebu: a38x: Add optional support for using old DDR3 training
 code
   arm: mvebu: turris_omnia: Support old DDR3 training

  arch/arm/mach-mvebu/Kconfig   |   15 +
  arch/arm/mach-mvebu/include/mach/cpu.h|1 +
  arch/arm/mach-mvebu/spl.c |   37 +-
  board/CZ.NIC/turris_omnia/Makefile|2 +
  board/CZ.NIC/turris_omnia/eeprom.c|  190 ++
  board/CZ.NIC/turris_omnia/old_ddr3_training.c |   63 +
  board/CZ.NIC/turris_omnia/turris_omnia.c  |  199 +-
  configs/turris_omnia_defconfig|6 +-
  drivers/ddr/marvell/a38x/Makefile |2 +
  drivers/ddr/marvell/a38x/ddr3_debug.c |   30 +-
  drivers/ddr/marvell/a38x/ddr3_init.c  |3 +-
  drivers/ddr/marvell/a38x/ddr3_init.h  |   43 +-
  drivers/ddr/marvell/a38x/old/Makefile |   29 +
  drivers/ddr/marvell/a38x/old/ddr3_a38x.c  |  737 +
  drivers/ddr/marvell/a38x/old/ddr3_a38x.h  |   93 +
  .../marvell/a38x/old/ddr3_a38x_mc_static.h|  226 ++
  .../ddr/marvell/a38x/old/ddr3_a38x_topology.h |   22 +
  .../ddr/marvell/a38x/old/ddr3_a38x_training.c |   39 +
  drivers/ddr/marvell/a38x/old/ddr3_debug.c | 1546 ++
  .../marvell/a38x/old/ddr3_hws_hw_training.c   |  147 +
  .../marvell/a38x/old/ddr3_hws_hw_training.h   |   49 +
  .../a38x/old/ddr3_hws_hw_training_def.h   |  464 +++
  .../marvell/a38x/old/ddr3_hws_sil_training.h  |   17 +
  drivers/ddr/marvell/a38x/old/ddr3_init.c  |  769 +
  drivers/ddr/marvell/a38x/old/ddr3_init.h  |  405 +++
  .../ddr/marvell/a38x/old/ddr3_logging_def.h   |  101 +
  .../marvell/a38x/old/ddr3_patterns_64bit.h|  924 ++
  .../ddr/marvell/a38x/old/ddr3_topology_def.h  |   76 +
  drivers/ddr/marvell/a38x/old/ddr3_training.c  | 2650 +
  .../ddr/marvell/a38x/old/ddr3_training_bist.c |  288 ++
  .../a38x/old/ddr3_training_centralization.c   |  711 +
  .../ddr/marvell/a38x/old/ddr3_training_db.c   |  651 
  .../marvell/a38x/old/ddr3_training_hw_algo.c  |  685 +
  .../marvell/a38x/old/ddr3_training_hw_algo.h  |   14 +
  .../ddr/marvell/a38x/old/ddr3_training_ip.h   |  178 ++
  .../marvell/a38x/old/ddr3_training_ip_bist.h  |   54 +
  .../old/ddr3_training_ip_centralization.h |   15 +
  .../marvell/a38x/old/ddr3_training_ip_db.h|   34 +
  .../marvell/a38x/old/ddr3_training_ip_def.h   |  173 ++
  .../a38x/old/ddr3_training_ip_engine.c| 1354 +
  .../a38x/old/ddr3_training_ip_engine.h|   85 +
  .../marvell/a38x/old/ddr3_training_ip_flow.h  |  349 +++
  .../marvell/a38x/old/ddr3_training_ip_pbs.h   |   41 +
  .../a38x/old/ddr3_training_ip_prv_if.h|  107 +
  .../a38x/old/ddr3_training_ip_static.h|   31 +
  .../marvell/a38x/old/ddr3_training_leveling.c | 1836 
  .../marvell/a38x/old/ddr3_training_leveling.h |   17 +
  .../ddr/marvell/a38x/old/ddr3_training_pbs.c  |  994 +++
  .../marvell/a38x/old/ddr3_training_static.c   |  537 
  .../ddr/marvell/a38x/old/ddr_topology_def.h   |  121 +
  .../ddr/marvell/a38x/old/ddr_training_ip_db.h |   16 +
  .../marvell/a38x/old/glue_symbol_renames.h|  247 ++
  drivers/ddr/marvell/a38x/old/silicon_if.h |   17 +
  drivers/ddr/marvell/a38x/old/xor.h|   92 +
  54 files changed, 17475 insertions(+), 57 deletions(-)
  create mode 100644 board/CZ.NIC/turris_omnia/eeprom.c
  create mode 100644 board/CZ.NIC/turris_omnia/old_ddr3_training.c
  create mode 100644 drivers/ddr/marvell/a38x/old/Makefile
  create mode 100644 

Re: [PATCH] arm: dts: mvebu: Update DTS for Thecus N2350 board

2024-07-08 Thread Stefan Roese

On 6/11/24 23:42, Tony Dinh wrote:

Hi Dragan,

On Sun, Jun 9, 2024 at 6:07 PM Dragan Simic  wrote:


Hello Tony,

Please see a few comments below.

On 2024-06-10 02:34, Tony Dinh wrote:

- Change the spi-max-frequency to 5000 (50 Mhz). According to the
data sheet[1], the MX25L3205D max frequency is 86 Mhz. Using 50 Mhz in
the DTS to ensure u-boot is consistent with what Linux kernel expected.
- Update GPIO fan to conform to the latest DT binding.


There's no need for the bullet points, plain prose will do fine instead.


I like bullet points :) All my patch descriptions have bullet points
when there are 2 or more different items.




[1]
MX25L3205D-MX25L1605D-MX25L6405D-Macronix-MX25L3205DM2I-12G-datasheet.pdf


Unless you can provide a real, working URL for the datasheet, this
reference
should actually be deleted.


It was my oversight. That should have been this URL:

https://www.macronix.com/Lists/Datasheet/Attachments/8575/MX25L3205D,%203V,%2032Mb,%20v1.5.pdf

I'll wait for Stefan to review the patch and let him decide whether I
should send in a V2 patch or he will modify the commit description.


I've changed the commit message accordingly.

Applied to u-boot-marvell/master

Thanks,
Stefan



Thanks for the comments!

All the best,
Tony




Signed-off-by: Tony Dinh 
---

  arch/arm/dts/armada-385-thecus-n2350.dts | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
b/arch/arm/dts/armada-385-thecus-n2350.dts
index 253cf01130..fdaa444e51 100644
--- a/arch/arm/dts/armada-385-thecus-n2350.dts
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -2,7 +2,7 @@
  /*
   * Device Tree file for Thecus N2350 board
   *
- * Copyright (C) 2018-2023 Tony Dinh 
+ * Copyright (C) 2018-2024 Tony Dinh 
   * Copyright (C) 2018 Manuel Jung 
   */

@@ -143,9 +143,9 @@
   fan {
   compatible = "gpio-fan";
   gpios = < 16 GPIO_ACTIVE_HIGH>;
- gpio-fan,speed-map = <0  0
- 600  1
- 3000 2 >;
+ gpio-fan,speed-map = <0  0>,
+ <600  1>,
+ <3000 2 >;
   pinctrl-0 = <_fan>;
   pinctrl-names = "default";
   };
@@ -415,7 +415,7 @@
   compatible = "jedec,spi-nor";
   reg = <0>;

- spi-max-frequency = <10800>;
+ spi-max-frequency = <5000>;
   spi-cpha;

   partition@0 {


Viele Grüße,
Stefan Roese

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


Re: [PATCH] arm: mvebu: env_sf_get_env_addr() missing check for CONFIG_ENV_IS_IN_SPI_FLASH

2024-07-08 Thread Stefan Roese

On 6/6/24 02:12, Tony Dinh wrote:

The CONFIG_ENV_OFFSET is undefined if boot device is UART
(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART), or envs are not stored on flash
(CONFIG_ENV_IS_NOWHERE). Check for CONFIG_ENV_IS_IN_SPI_FLASH as the first
condition to determine whether env_sf_get_env_addr() should be provided.

Signed-off-by: Tony Dinh 


Applied to u-boot-marvell/master

Thanks,
Stefan


---

  arch/arm/mach-mvebu/cpu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 7c62a5dbb6..6dd729ae6e 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -36,7 +36,7 @@ static const struct mbus_win windows[] = {
  };
  
  /* SPI0 CS0 Flash of size MBUS_SPI_SIZE is mapped to address MBUS_SPI_BASE */

-#if CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
+#if defined(CONFIG_ENV_IS_IN_SPI_FLASH) && CONFIG_ENV_SPI_BUS == 0 && 
CONFIG_ENV_SPI_CS == 0 && \
  CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= MBUS_SPI_SIZE
  void *env_sf_get_env_addr(void)
  {


Viele Grüße,
Stefan Roese

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


Re: [PATCH v3] configs: add mvebu_espressobin_ultra-88f3720_defconfig

2024-07-08 Thread Stefan Roese

On 5/30/24 06:47, Benjamin Schneider wrote:

Add support for a Marvell Armada 3720 device variant

Signed-off-by: Benjamin Schneider 


Applied to u-boot-marvell/master

Thanks,
Stefan


---

Changes in v3:
- Fix typo in MAINTAINERS

  board/Marvell/mvebu_armada-37xx/MAINTAINERS   |   5 +
  .../mvebu_espressobin_ultra-88f3720_defconfig | 106 ++
  2 files changed, 111 insertions(+)
  create mode 100644 configs/mvebu_espressobin_ultra-88f3720_defconfig

diff --git a/board/Marvell/mvebu_armada-37xx/MAINTAINERS 
b/board/Marvell/mvebu_armada-37xx/MAINTAINERS
index 9b0afeef10..e96499e161 100644
--- a/board/Marvell/mvebu_armada-37xx/MAINTAINERS
+++ b/board/Marvell/mvebu_armada-37xx/MAINTAINERS
@@ -9,3 +9,8 @@ ESPRESSOBin BOARD
  M:Konstantin Porotchkin 
  S:Maintained
  F:configs/mvebu_espressobin-88f3720_defconfig
+
+ESPRESSOBin Ultra BOARD
+M: Ben Schneider 
+S: Maintained
+F: configs/mvebu_espressobin_ultra-88f3720_defconfig
diff --git a/configs/mvebu_espressobin_ultra-88f3720_defconfig 
b/configs/mvebu_espressobin_ultra-88f3720_defconfig
new file mode 100644
index 00..c6ffaaabca
--- /dev/null
+++ b/configs/mvebu_espressobin_ultra-88f3720_defconfig
@@ -0,0 +1,106 @@
+CONFIG_ARM=y
+CONFIG_ARCH_CPU_INIT=y
+CONFIG_ARCH_MVEBU=y
+CONFIG_TEXT_BASE=0x
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
+CONFIG_TARGET_MVEBU_ARMADA_37XX=y
+CONFIG_SF_DEFAULT_SPEED=4000
+CONFIG_ENV_SIZE=0x1
+CONFIG_ENV_OFFSET=0x3F
+CONFIG_ENV_SECT_SIZE=0x1
+CONFIG_DM_GPIO=y
+CONFIG_OF_UPSTREAM=y
+CONFIG_DEFAULT_DEVICE_TREE="marvell/armada-3720-espressobin-ultra"
+CONFIG_SYS_LOAD_ADDR=0x600
+CONFIG_PCI=y
+CONFIG_AHCI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_PREBOOT=y
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_BOARD_LATE_INIT=y
+CONFIG_SYS_MAXARGS=32
+CONFIG_CMD_FUSE=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_SATA=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_WDT=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_BTRFS=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_SQUASHFS=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_MAC_PARTITION=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_ARP_TIMEOUT=200
+CONFIG_NET_RETRY_COUNT=50
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_AHCI_PCI=y
+CONFIG_AHCI_MVEBU=y
+CONFIG_LBA48=y
+CONFIG_SYS_64BIT_LBA=y
+CONFIG_CLK=y
+CONFIG_CLK_MVEBU=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_MV=y
+CONFIG_MISC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_XENON=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_ISSI=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_MTD=y
+CONFIG_PHY_MARVELL=y
+CONFIG_PHY_FIXED=y
+CONFIG_PHY_GIGE=y
+CONFIG_DM_DSA=y
+CONFIG_MV88E6XXX=y
+CONFIG_MVNETA=y
+CONFIG_MVMDIO=y
+CONFIG_NVME_PCI=y
+CONFIG_PCI_AARDVARK=y
+CONFIG_PHY=y
+CONFIG_MVEBU_COMPHY_SUPPORT=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_ARMADA_37XX=y
+CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DEFAULT_ENV_IS_RW=y
+CONFIG_MVEBU_A3700_UART=y
+CONFIG_MVEBU_A3700_SPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+# CONFIG_WATCHDOG_AUTOSTART is not set
+CONFIG_WDT=y
+CONFIG_WDT_ARMADA_37XX=y
+CONFIG_SHA1=y
+CONFIG_DM_RTC=y
+CONFIG_RTC_PCF8563=y
+# CONFIG_DEBUG_UART=y
+# CONFIG_DEBUG_UART_BASE=0xd0012000
+# CONFIG_DEBUG_UART_CLOCK=25804800
+# CONFIG_DEBUG_UART_SHIFT=2
+# CONFIG_DEBUG_UART_ANNOUNCE=y


Viele Grüße,
Stefan Roese

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


Re: [RFC PATCH v2 18/48] lmb: introduce a function to add memory to the lmb memory map

2024-07-08 Thread Tom Rini
On Thu, Jul 04, 2024 at 01:05:14PM +0530, Sughosh Ganu wrote:

> Introduce a function lmb_add_memory() to add available memory to the
> LMB memory map. Call this function during board init once the LMB data
> structures have been initialised.
> 
> Signed-off-by: Sughosh Ganu 
> ---
> Changes since V1:
> * Add memory only till ram_top to the LMB memory map, instead of all
>   enumerated memory.
> 
>  include/lmb.h | 11 +++
>  lib/lmb.c | 42 ++
>  2 files changed, 53 insertions(+)

Checkpatch:
ERROR: space prohibited before that close parenthesis ')'
#78: FILE: lib/lmb.c:274:
+   if (rgn_top > ram_top )

-- 
Tom


signature.asc
Description: PGP signature


Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent

2024-07-08 Thread Tom Rini
On Thu, Jul 04, 2024 at 01:04:56PM +0530, Sughosh Ganu wrote:

> The aim of this patch series is to fix the current state of
> incoherence between modules when it comes to memory usage. The primary
> issue that this series is trying to fix is that the EFI memory module
> which is responsible for allocating and freeing memory, does not have
> any visibility of the memory that is being used by the LMB
> module. This is further complicated by the fact that the LMB
> allocations are caller specific -- the LMB memory map is not global
> nor persistent. This means that the memory "allocated" by the LMB
> module might be relevant only for a given function. Hence one of the
> requirements for making the memory usage visible across modules is to
> make LMB allocations persistent and global, and then have means to
> communicate the use of memory across modules.
> 
> The first set of patches in this series work on making the LMB memory
> map persistent and global. This is being done keeping in mind the
> usage of LMB memory by platforms where the same memory region can be
> used to load multiple different images. What is not allowed is to
> overwrite memory that has been allocated by the other module,
> currently the EFI memory module. This is being achieved by introducing
> a new flag, LMB_NOOVERWRITE, which represents memory which cannot be
> re-requested once allocated.
> 
> A review comment on the earlier version was to do away with the static
> arrays for the LMB lists of free and used memory. This version
> uses the alloced list data structure for the LMB lists.
> 
> The second set of patches are making changes to the EFI memory module
> to make use of the LMB functions to allocate and free memory. A
> *_flags() version of LMB API's has been introduced for the same. The
> earlier version was using notification mechanism from both LMB and EFI
> modules to maintain memory coherence. This version makes use of the
> LMB API functions for the memory allocations. This is based on review
> comments of EFI maintainers.

On am64x_evm_a53, the last test in test/py/tests/test_net_boot.py fails
due to:
...
TFTP from server 192.168.116.10; our IP address is 192.168.116.23
Filename 'pxelinux.cfg/default-arm-k3'.
Load address: 0x8010
Loading: ##  64 Bytes
 8.8 KiB/s
done
Bytes transferred = 64 (40 hex)
  1  pxe  ready   ethernet 0  port@1.bootdev.0  
extlinux/extlinux.conf
** Booting bootflow 'port@1.bootdev.0' with pxe
Retrieving file: pxelinux.cfg/default-arm
am65_cpsw_nuss_port ethernet@800port@1: K3 CPSW: rflow_id_base: 16
link up on port 1, speed 1000, full duplex
Using ethernet@800port@1 device
TFTP from server 192.168.116.10; our IP address is 192.168.116.23
Filename 'pxelinux.cfg/default-arm'.

TFTP error: trying to overwrite reserved memory...
Couldn't retrieve pxelinux.cfg/default-arm

And note that the pxelinux.cfg files are created as defined by the
example within the test. This test is also still fine on Pi 4.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] configs: am62x_evm_a53_defconfig: Remove CONFIG_SYS_BOOTM_LEN

2024-07-08 Thread Tom Rini
On Mon, Jul 08, 2024 at 05:20:40PM +0530, Kamlesh Gurudasani wrote:

> Increase the maximum size of the buffer that is used to decompress
> the OS image in to.
> 
> If image size is greater than the buffer, boot
> will fail with following error,
> "Error: inflate() returned -5"
> "gzip compressed: uncompress error -1"
> 
> Default limit for ARM64 platforms is 0x400, remove
> CONFIG_SYS_BOOTM_LEN=0x800, so that it follows default limit.
> 
> Signed-off-by: Kamlesh Gurudasani 
> ---
>  configs/am62x_evm_a53_defconfig | 1 -
>  1 file changed, 1 deletion(-)

Please check and correct all of the TI K3 platforms. We have at least
this from a quick grep on am6*:
configs/am62x_beagleplay_a53_defconfig:CONFIG_SYS_BOOTM_LEN=0x80
configs/am62x_evm_a53_defconfig:CONFIG_SYS_BOOTM_LEN=0x80
configs/am65x_evm_r5_defconfig:CONFIG_SYS_BOOTM_LEN=0x400
configs/am65x_evm_r5_usbdfu_defconfig:CONFIG_SYS_BOOTM_LEN=0x400
configs/am65x_evm_r5_usbmsc_defconfig:CONFIG_SYS_BOOTM_LEN=0x400

(And so are those larger values on the R5 core actually needed?)

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v5 0/6] Introduce UBI block device

2024-07-08 Thread Alexey Romanov
Hello, ping.

On Wed, Jun 26, 2024 at 01:45:21PM +0300, Alexey Romanov wrote:
> Hello!
> 
> This series adds support for the UBI block device, which
> allows to read/write data block by block. For example,
> it can now be used for BCB or Android AB command:
> 
>   $ bcb load ubi 0 part_name
> 
> Tested only on SPI NAND, so bind is made only for
> SPI NAND drivers. Can be used with mtdblock device [1].
> 
> ---
> 
> Changes V1 -> V2 [2]:
> 
>  - Rebased over mtdblock v2 patchset [3].
>  - Compile UBI partitions support only if CONFIG_BLK option
>is enabled.
> 
> Changes V2 -> V3 [4]:
> 
>  - Fix build warnings: use LBAF printf format string for lbaint_t types.
> 
> Changes V3 -> V4 [5]:
> 
>  - Rebased over u-boot/master.
>  - Fix build errors and warnings if CONFIG_BLK isn't enabled.
>  - Fix failed tests in cases is ubiblock device isn't binded.
> 
> Changes V4 -> V5 [6]:
> 
>   - Rebased over u-boot/master.
>   - Fix build errors when CONFIG_MTD and CONFIG_MTD_UBI isn't enabled.
>   - Use auto blk device devnum generation when call
> blk_create_devicef (pass -1 parameter instead of dev_seq(dev)).
> 
> Links:
> 
>   [1] 
> https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/
>   [2] 
> https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/
>   [3] 
> https://lore.kernel.org/all/20240307130726.1582487-1-avroma...@salutedevices.com/
>   [4] 
> https://lore.kernel.org/all/20240325144148.3738195-1-avroma...@salutedevices.com/
>   [5] 
> https://lore.kernel.org/all/20240524111319.3512009-1-avroma...@salutedevices.com/
>   [6] 
> https://lore.kernel.org/all/20240603155740.1840571-1-avroma...@salutedevices.com/
> 
> Alexey Romanov (6):
>   ubi: allow to read from volume with offset
>   ubi: allow to write to volume with offset
>   drivers: introduce UBI block abstraction
>   disk: don't try search for partition type if already set
>   disk: support UBI partitions
>   spinand: bind UBI block
> 
>  cmd/ubi.c   |  78 --
>  disk/part.c |   7 ++
>  drivers/block/blk-uclass.c  |   1 +
>  drivers/mtd/nand/spi/core.c |   9 ++-
>  drivers/mtd/ubi/Makefile|   1 +
>  drivers/mtd/ubi/block.c | 130 
>  drivers/mtd/ubi/part.c  |  99 +++
>  env/ubi.c   |  16 ++---
>  include/part.h  |   2 +
>  include/ubi_uboot.h |  13 +++-
>  10 files changed, 339 insertions(+), 17 deletions(-)
>  create mode 100644 drivers/mtd/ubi/block.c
>  create mode 100644 drivers/mtd/ubi/part.c
> 
> -- 
> 2.34.1
> 

-- 
Thank you,
Alexey

Re: [PATCH v6 0/3] Introduce mtdblock device

2024-07-08 Thread Alexey Romanov
Hello, ping.

On Wed, Jun 26, 2024 at 01:44:37PM +0300, Alexey Romanov wrote:
> Hello!
> 
> This series adds support for the mtdblock device, which
> allows to read/write data block by block. For example,
> it can now be used for BCB or Android AB command:
> 
>   $ bcb load mtd 0 part_name
> 
> Tested only on SPI NAND, so bind is made only for
> SPI NAND drivers.
> 
> ---
> 
> Changes V1 -> V2 [1]:
> 
>   - Drop patch [2].
>   - Add warning if bind NAND mtdblock device.
>   - Move documentation of mtdblock implementation
> from commit message to the source code.
>   - Remove __maybe_unused from mtd partition functions
> description.
>   - Use blk_enabled() instead of #ifdefs.
> 
> Changes V2 -> V3 [2]:
> 
>   - Rebased over [3].
>   - Rename mtd_bread/bwrite -> mtd_blk_read/write.
>   - Fix GPL-2.0 license short name definiton in headers.
>   - Add empty line after MTD_ENTRY_NUMBERS define.
> 
> Changes V3 -> V4 [4]:
> 
>   - Fix build warnings: use LBAF printf format string for lbaint_t types.
> 
> Changes V4 -> V5 [5]:
> 
>   - Rebased over u-boot/master.
>   - Fix build errors and warnings if CONFIG_BLK isn't enabled.
>   - Fix failed tests in cases is mtdblock device isn't binded.
> 
> Changes V5 -> V6 [6]:
> 
>   - Rebased over u-boot/master.
>   - Fix build errors when CONFIG_MTD isn't enabled.
>   - Use auto blk device devnum generation when call
> blk_create_devicef (pass -1 parameter instead of dev_seq(dev)).
> 
> Links:
> 
>   - [1] 
> https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/
>   - [2] 
> https://lore.kernel.org/all/20240227100441.1811047-5-avroma...@salutedevices.com/
>   - [3] 
> https://lore.kernel.org/u-boot/20240403114047.84030-1-heinrich.schucha...@canonical.com/T/#u
>   - [4] 
> https://lore.kernel.org/all/20240404105813.1520732-1-avroma...@salutedevices.com/
>   - [5] 
> https://lore.kernel.org/all/20240524102920.2631731-1-avroma...@salutedevices.com/
>   - [6] 
> https://lore.kernel.org/all/20240603155702.1840464-1-avroma...@salutedevices.com/
> 
> Alexey Romanov (3):
>   disk: support MTD partitions
>   drivers: introduce mtdblock abstraction
>   spinand: bind mtdblock
> 
>  disk/part.c |   3 +-
>  drivers/block/blk-uclass.c  |   1 +
>  drivers/mtd/Kconfig |   1 +
>  drivers/mtd/Makefile|   3 +
>  drivers/mtd/mtdblock.c  | 227 
>  drivers/mtd/mtdpart.c   |  76 
>  drivers/mtd/nand/spi/core.c |  20 
>  include/linux/mtd/mtd.h |  25 
>  include/part.h  |   3 +
>  9 files changed, 358 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/mtd/mtdblock.c
> 
> -- 
> 2.34.1
> 

-- 
Thank you,
Alexey

[PATCH 2/6] sound: ti: Add TLV320AIC3106 Codec

2024-07-08 Thread Scaria Kochidanadu
This patch adds driver for  TLV320AIC3106 audio Codec.
Initialize and start the codec[1] with appropriate settings and
hardware parameters according to the audio data and the sound card
defined in the devicetree. The codec audio data bus is
programmable for I2S, DSP or TDM modes, and it also has a programmable
PLL for clock generation.
Below default settings are used as u-boot doesn't support file playback:
Codec being the clock and frame master, using the I2S audio format,
sampling rate and width of audio data in one slot.

The data sheet for the codec can be obtained here for further details
about its settings and working-

Link: https://www.ti.com/product/TLV320AIC3106 [1]

The driver is based on the kernel codec driver[2].
Link:
https://gitlab.com/linux-kernel/linux-next/-/blob/master/sound/soc/codecs/tlv320aic3x.c
[2]

Signed-off-by: Scaria Kochidanadu 
---
 MAINTAINERS   |   2 +
 drivers/sound/Kconfig |   8 +
 drivers/sound/Makefile|   1 +
 drivers/sound/tlv320aic3106.c | 758 ++
 drivers/sound/tlv320aic3106.h | 336 +++
 5 files changed, 1105 insertions(+)
 create mode 100644 drivers/sound/tlv320aic3106.c
 create mode 100644 drivers/sound/tlv320aic3106.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 785afff1a7..5d7c260bfc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -739,6 +739,8 @@ F:  drivers/rtc/davinci.c
 F: drivers/serial/serial_omap.c
 F: drivers/soc/ti/
 F: drivers/sound/ti_sound.c
+F: drivers/sound/tlv320aic3106.c
+F: drivers/sound/tlv320aic3106.h
 F: drivers/sysreset/sysreset-ti-sci.c
 F: drivers/thermal/ti-bandgap.c
 F: drivers/timer/omap-timer.c
diff --git a/drivers/sound/Kconfig b/drivers/sound/Kconfig
index be9f18b6c7..3f124cfb2b 100644
--- a/drivers/sound/Kconfig
+++ b/drivers/sound/Kconfig
@@ -158,4 +158,12 @@ config I2S_TI
   option provides an implementation for sound_init() and
   sound_play().
 
+config SOUND_TLV320AIC3106
+bool "Support TLV320AIC3106 audio codec"
+depends on I2S_TI
+help
+  Enable the TLV320AIC3106 audio codec. This is connected via I2S for
+  audio data and I2C for codec control. At present it only works
+  with the MCASP driver.
+
 endmenu
diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile
index 95aaa8521c..1e9fbd1000 100644
--- a/drivers/sound/Makefile
+++ b/drivers/sound/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_SOUND_RT5677)+= rt5677.o
 obj-$(CONFIG_INTEL_BROADWELL)  += broadwell_i2s.o broadwell_sound.o
 obj-$(CONFIG_SOUND_IVYBRIDGE)  += ivybridge_sound.o
 obj-$(CONFIG_I2S_TI)+= ti_sound.o
+obj-$(CONFIG_SOUND_TLV320AIC3106)   += tlv320aic3106.o
diff --git a/drivers/sound/tlv320aic3106.c b/drivers/sound/tlv320aic3106.c
new file mode 100644
index 00..b80b70
--- /dev/null
+++ b/drivers/sound/tlv320aic3106.c
@@ -0,0 +1,758 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Scaria M Kochidanadu, s-kochidan...@ti.com
+ *
+ * based on the linux tlv320aic3x codec driver, which is
+ *
+ * Author:  Vladimir Barinov, 
+ * Copyright:   (C) 2007 MontaVista Software, Inc., 
+ */
+
+#include  /* boot information for Linux kernel */
+/* Pull in stuff for the build system */
+#ifdef DO_DEPS_ONLY
+#include 
+#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "tlv320aic3106.h"
+
+enum aic3x_micbias_voltage {
+   AIC3X_MICBIAS_OFF = 0,
+   AIC3X_MICBIAS_2_0V = 1,
+   AIC3X_MICBIAS_2_5V = 2,
+   AIC3X_MICBIAS_AVDDV = 3,
+};
+
+enum snd_soc_bias_level {
+   SND_SOC_BIAS_OFF = 0,
+   SND_SOC_BIAS_STANDBY = 1,
+   SND_SOC_BIAS_PREPARE = 2,
+   SND_SOC_BIAS_ON = 3,
+};
+
+struct reg_values {
+   unsigned int reg;
+   unsigned int def;
+};
+
+static const struct reg_values aic3x_default[] = {
+   {   0, 0x00 }, {   1, 0x00 }, {   2, 0x00 }, {   3, 0x10 },
+   {   4, 0x04 }, {   5, 0x00 }, {   6, 0x00 }, {   7, 0x00 },
+   {   8, 0x00 }, {   9, 0x00 }, {  10, 0x00 }, {  11, 0x01 },
+   {  12, 0x00 }, {  13, 0x00 }, {  14, 0x00 }, {  15, 0x80 },
+   {  16, 0x80 }, {  17, 0xff }, {  18, 0xff }, {  19, 0x78 },
+   {  20, 0x78 }, {  21, 0x78 }, {  22, 0x78 }, {  23, 0x78 },
+   {  24, 0x78 }, {  25, 0x00 }, {  26, 0x00 }, {  27, 0xfe },
+   {  28, 0x00 }, {  29, 0x00 }, {  30, 0xfe }, {  31, 0x00 },
+   {  32, 0x18 }, {  33, 0x18 }, {  34, 0x00 }, {  35, 0x00 },
+   {  36, 0x00 }, {  37, 0x00 }, {  38, 0x00 }, {  39, 0x00 },
+   {  40, 0x00 }, {  41, 0x00 }, {  42, 0x00 }, {  43, 0x80 },
+   {  44, 0x80 }, {  45, 0x00 }, {  46, 0x00 }, {  47, 0x00 },
+   {  48, 0x00 }, {  49, 0x00 }, {  50, 0x00 }, {  51, 0x04 },
+   {  52, 0x00 }, {  53, 0x00 }, {  54, 0x00 }, {  55, 0x00 },
+   {  56, 0x00 }, {  57, 0x00 }, {  58, 0x04 }, {  59, 0x00 },
+   {  

[PATCH 6/6] linux: bitmap.h: Add for_each_set_bit_from() function

2024-07-08 Thread Scaria Kochidanadu
Add function macro for_each_set_bit_from(), an extension to the already
existing function macro for_each_set_bit() to iterate through set bits
of a variable from a given bit index as required by the MCASP Driver.

Signed-off-by: Scaria Kochidanadu 
---
 include/linux/bitmap.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 0a8503af9f..da3aa428b6 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -159,6 +159,11 @@ static inline unsigned long find_first_bit(const unsigned 
long *addr, unsigned l
 (bit) < (size);\
 (bit) = find_next_bit((addr), (size), (bit) + 1))
 
+#define for_each_set_bit_from(_bit, _addr, _size) \
+   for ((_bit) = find_next_bit((_addr), (_size), (_bit));  \
+   (_bit) < (_size);   \
+   (_bit) = find_next_bit((_addr), (_size), (_bit) + 1))
+
 static inline unsigned long
 bitmap_find_next_zero_area(unsigned long *map,
   unsigned long size,
-- 
2.34.1



[PATCH 5/6] configs: am62x_evm_a53_defconfig: Enable sound and I2C commands

2024-07-08 Thread Scaria Kochidanadu
Add the tlv320aic3106 codec and sound driver in the defconfig, and
enable the sound commands in Uboot. Also enable the I2C communication
for transfer to and from the codec.

Signed-off-by: Scaria Kochidanadu 
---
 configs/am62x_evm_a53_defconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 6c708dcb05..858946d7fc 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -51,8 +51,10 @@ CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
 CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_CMD_BOOTEFI_SELFTEST=y
 CONFIG_CMD_NVEDIT_EFI=y
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_EFIDEBUG=y
+CONFIG_CMD_SOUND=y
 CONFIG_MMC_SPEED_MODE_SET=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
@@ -71,6 +73,8 @@ CONFIG_CLK_TI_SCI=y
 CONFIG_DMA_CHANNELS=y
 CONFIG_TI_K3_NAVSS_UDMA=y
 CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_OMAP24XX=y
 CONFIG_DM_MAILBOX=y
 CONFIG_K3_SEC_PROXY=y
 CONFIG_SUPPORT_EMMC_BOOT=y
@@ -100,6 +104,11 @@ CONFIG_RESET_TI_SCI=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_EMULATION=y
 CONFIG_DM_SERIAL=y
+CONFIG_SOUND=y
+CONFIG_I2S=y
+CONFIG_SOUND_RT5677=y
+CONFIG_I2S_TI=y
+CONFIG_SOUND_TLV320AIC3106=y
 CONFIG_SOC_DEVICE=y
 CONFIG_SOC_DEVICE_TI_K3=y
 CONFIG_SOC_TI=y
-- 
2.34.1



[PATCH 4/6] arm: dts: k3-am625-sk-u-boot.dtsi: Add sound driver nodes

2024-07-08 Thread Scaria Kochidanadu
Update the am625-sk-u-boot device tree to incorporate the sound card and
sound drivers: MCASP and TLV320AIC3106 Codec

Signed-off-by: Scaria Kochidanadu 
---
 arch/arm/dts/k3-am625-sk-u-boot.dtsi | 85 
 1 file changed, 85 insertions(+)

diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index fa778b0ff4..74c273d940 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -10,6 +10,91 @@
chosen {
tick-timer = _timer0;
};
+
+   tlv320_mclk: clk-0 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <12288000>;
+   };
+
+   codec_audio: sound {
+   compatible = "simple-audio-card";
+   ti,codec = <>;
+   simple-audio-card,name = "AM62x-SKEVM";
+   simple-audio-card,widgets =
+   "Headphone","Headphone Jack",
+   "Line", "Line In",
+   "Microphone",   "Microphone Jack";
+   simple-audio-card,routing =
+   "Headphone Jack",   "HPLOUT",
+   "Headphone Jack",   "HPROUT",
+   "LINE1L",   "Line In",
+   "LINE1R",   "Line In",
+   "MIC3R","Microphone Jack",
+   "Microphone Jack",  "Mic Bias";
+   simple-audio-card,format = "dsp_b";
+   simple-audio-card,bitclock-master = <_master>;
+   simple-audio-card,frame-master = <_master>;
+   simple-audio-card,bitclock-inversion;
+
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   };
+
+   sound_master: simple-audio-card,codec {
+   sound-dai = <>;
+   clocks = <_mclk>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+   #sound-dai-cells = <0>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_mcasp1_pins_default>;
+
+   op-mode = <0>;  /* MCASP_IIS_MODE */
+   tdm-slots = <2>;
+
+   ti,i2s-epll-clock-frequency = <9600>;
+   ti,i2s-sampling-rate = <48000>;
+   ti,i2s-bits-per-sample = <16>;
+   ti,i2s-channels = <2>;
+   ti,i2s-lr-clk-framesize = <256>;
+   ti,i2s-bit-clk-framesize = <32>;
+   ti,i2s-id = <0>;
+
+   serial-dir = <
+  1 0 2 0
+  0 0 0 0
+  0 0 0 0
+  0 0 0 0
+   >;  /* 0: INACTIVE, 1: TX, 2: RX */
+   tx-num-evt = <0>;
+   rx-num-evt = <0>;
+};
+
+_i2c1 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c1_pins_default>;
+   clock-frequency = <10>;
+
+   tlv320aic3106: audio-codec@1b {
+   #sound-dai-cells = <0>;
+   compatible = "ti,tlv320aic3106";
+   reg = <0x1b>;
+   ai3x-micbias-vg = <1>;  /* 2.0V */
+   ai3x-ocmv = <1>;
+
+   /* Regulators */
+   AVDD-supply = <_3v3_sys>;
+   IOVDD-supply = <_3v3_sys>;
+   DRVDD-supply = <_3v3_sys>;
+   DVDD-supply = <_1v8>;
+   };
 };
 
 _timer0 {
-- 
2.34.1



[PATCH 3/6] sound: ti: Add MCASP driver for transfer of Audio data to sound codec

2024-07-08 Thread Scaria Kochidanadu
This patch adds driver for I2S interface for TI AM62x Soc.
Configure the MCASP [1] component with appropriate settings and
hardware parameters according to the audio data and devicetree.
Set up the MCASP pins and fill the transmit buffers. The driver
uses polling method to transfer data to the codec, since
u-boot does not have DMA driver or interrupt functionality.

The TRM for the AM62X SoC contain the information for the MCASP
component-
Link: https://www.ti.com/lit/ug/spruiv7b/spruiv7b.pdf [1] (Section
12.1.1 : Audio Peripherals-MCASP)

The driver is based on the kernel mcasp driver[2].
Link:
https://gitlab.com/linux-kernel/linux-next/-/blob/master/sound/soc/ti/davinci-mcasp.c
[2]

Signed-off-by: Scaria Kochidanadu 
---
 MAINTAINERS   |2 +
 drivers/sound/Makefile|1 +
 drivers/sound/davinci-mcasp.h |  413 
 drivers/sound/mcasp_i2s.c | 1123 +
 4 files changed, 1539 insertions(+)
 create mode 100644 drivers/sound/davinci-mcasp.h
 create mode 100644 drivers/sound/mcasp_i2s.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 5d7c260bfc..6097b3ba62 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -738,6 +738,8 @@ F:  drivers/reset/reset-ti-sci.c
 F: drivers/rtc/davinci.c
 F: drivers/serial/serial_omap.c
 F: drivers/soc/ti/
+F: drivers/sound/davinci-mcasp.h
+F: drivers/sound/mcasp_i2s.c
 F: drivers/sound/ti_sound.c
 F: drivers/sound/tlv320aic3106.c
 F: drivers/sound/tlv320aic3106.h
diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile
index 1e9fbd1000..2068649172 100644
--- a/drivers/sound/Makefile
+++ b/drivers/sound/Makefile
@@ -24,4 +24,5 @@ obj-$(CONFIG_SOUND_RT5677)+= rt5677.o
 obj-$(CONFIG_INTEL_BROADWELL)  += broadwell_i2s.o broadwell_sound.o
 obj-$(CONFIG_SOUND_IVYBRIDGE)  += ivybridge_sound.o
 obj-$(CONFIG_I2S_TI)+= ti_sound.o
+obj-$(CONFIG_I2S_TI)+= mcasp_i2s.o
 obj-$(CONFIG_SOUND_TLV320AIC3106)   += tlv320aic3106.o
diff --git a/drivers/sound/davinci-mcasp.h b/drivers/sound/davinci-mcasp.h
new file mode 100644
index 00..83c77ba26c
--- /dev/null
+++ b/drivers/sound/davinci-mcasp.h
@@ -0,0 +1,413 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * ALSA SoC McASP Audio Layer for TI DAVINCI processor
+ *
+ * MCASP related definitions
+ *
+ * Author: Nirmal Pandey ,
+ * Suresh Rajashekara 
+ * Steve Chen 
+ *
+ * Copyright:   (C) 2009 MontaVista Software, Inc., 
+ * Copyright:   (C) 2009  Texas Instruments, India
+ */
+
+#ifndef DAVINCI_MCASP_H
+#define DAVINCI_MCASP_H
+
+/*
+ * McASP register definitions
+ */
+#define DAVINCI_MCASP_PID_REG  0x00
+#define DAVINCI_MCASP_PWREMUMGT_REG0x04
+
+#define DAVINCI_MCASP_PFUNC_REG0x10
+#define DAVINCI_MCASP_PDIR_REG 0x14
+#define DAVINCI_MCASP_PDOUT_REG0x18
+#define DAVINCI_MCASP_PDSET_REG0x1c
+
+#define DAVINCI_MCASP_PDCLR_REG0x20
+
+#define DAVINCI_MCASP_TLGC_REG 0x30
+#define DAVINCI_MCASP_TLMR_REG 0x34
+
+#define DAVINCI_MCASP_GBLCTL_REG   0x44
+#define DAVINCI_MCASP_AMUTE_REG0x48
+#define DAVINCI_MCASP_LBCTL_REG0x4c
+
+#define DAVINCI_MCASP_TXDITCTL_REG 0x50
+
+#define DAVINCI_MCASP_GBLCTLR_REG  0x60
+#define DAVINCI_MCASP_RXMASK_REG   0x64
+#define DAVINCI_MCASP_RXFMT_REG0x68
+#define DAVINCI_MCASP_RXFMCTL_REG  0x6c
+
+#define DAVINCI_MCASP_ACLKRCTL_REG 0x70
+#define DAVINCI_MCASP_AHCLKRCTL_REG0x74
+#define DAVINCI_MCASP_RXTDM_REG0x78
+#define DAVINCI_MCASP_EVTCTLR_REG  0x7c
+
+#define DAVINCI_MCASP_RXSTAT_REG   0x80
+#define DAVINCI_MCASP_RXTDMSLOT_REG0x84
+#define DAVINCI_MCASP_RXCLKCHK_REG 0x88
+#define DAVINCI_MCASP_REVTCTL_REG  0x8c
+
+#define DAVINCI_MCASP_GBLCTLX_REG  0xa0
+#define DAVINCI_MCASP_TXMASK_REG   0xa4
+#define DAVINCI_MCASP_TXFMT_REG0xa8
+#define DAVINCI_MCASP_TXFMCTL_REG  0xac
+
+#define DAVINCI_MCASP_ACLKXCTL_REG 0xb0
+#define DAVINCI_MCASP_AHCLKXCTL_REG0xb4
+#define DAVINCI_MCASP_TXTDM_REG0xb8
+#define DAVINCI_MCASP_EVTCTLX_REG  0xbc
+
+#define DAVINCI_MCASP_TXSTAT_REG   0xc0
+#define DAVINCI_MCASP_TXTDMSLOT_REG0xc4
+#define DAVINCI_MCASP_TXCLKCHK_REG 0xc8
+#define DAVINCI_MCASP_XEVTCTL_REG  0xcc
+
+/* Left(even TDM Slot) Channel Status Register File */
+#define DAVINCI_MCASP_DITCSRA_REG  0x100
+/* Right(odd TDM slot) Channel Status Register File */
+#define DAVINCI_MCASP_DITCSRB_REG  0x118
+/* Left(even TDM slot) User Data Register File */
+#define DAVINCI_MCASP_DITUDRA_REG  0x130
+/* Right(odd TDM Slot) User Data Register File */
+#define DAVINCI_MCASP_DITUDRB_REG  0x148
+
+/* Serializer n Control Register */
+#define DAVINCI_MCASP_XRSRCTL_BASE_REG 0x180
+#define DAVINCI_MCASP_XRSRCTL_REG(n)   (DAVINCI_MCASP_XRSRCTL_BASE_REG + \
+   ((n) << 2))

[PATCH 0/6] Enable audio playback in AM62x SoC

2024-07-08 Thread Scaria Kochidanadu
This series enables audio playback over u-boot for TI AM62x SoC.
It ports MCASP driver which acts as I2S audio signal generator and
TLV320AIC3106 which converts the digital audio to analog.
Lastly, this also adds sound driver to complete the audio graph and enables
audio playback using u-boot command.

Audio can be played over at u-boot prompt using below command :
sound play  
This plays a beep sound for the given duration and of the given frequency.

Scaria Kochidanadu (6):
  sound: ti: Add sound support for am625 board in Uboot
  sound: ti: Add TLV320AIC3106 Codec
  sound: ti: Add MCASP driver for transfer of Audio data to sound codec
  arm: dts: k3-am625-sk-u-boot.dtsi: Add sound driver nodes
  configs: am62x_evm_a53_defconfig: Enable sound and I2C commands
  linux: bitmap.h: Add for_each_set_bit_from() function

 MAINTAINERS  |5 +
 arch/arm/dts/k3-am625-sk-u-boot.dtsi |   85 ++
 configs/am62x_evm_a53_defconfig  |9 +
 drivers/sound/Kconfig|   18 +
 drivers/sound/Makefile   |3 +
 drivers/sound/davinci-mcasp.h|  413 ++
 drivers/sound/mcasp_i2s.c| 1123 ++
 drivers/sound/ti_sound.c |  119 +++
 drivers/sound/tlv320aic3106.c|  758 +
 drivers/sound/tlv320aic3106.h|  336 
 include/linux/bitmap.h   |5 +
 11 files changed, 2874 insertions(+)
 create mode 100644 drivers/sound/davinci-mcasp.h
 create mode 100644 drivers/sound/mcasp_i2s.c
 create mode 100644 drivers/sound/ti_sound.c
 create mode 100644 drivers/sound/tlv320aic3106.c
 create mode 100644 drivers/sound/tlv320aic3106.h

-- 
2.34.1



[PATCH 1/6] sound: ti: Add sound support for am625 board in Uboot

2024-07-08 Thread Scaria Kochidanadu
Add a UCLASS_SOUND driver for Texas Instruments SoCs which ties together
the tlv320aic3106 audio codec and MCASP I2S controller. Enable audio
playback functionality by taking a data pointer and data size as the
sound data. The uboot sound play command takes time and frequency as
input and creates the data for a beep sound with the given parameters,
which is then passed to the sound play function.

The code is based on the samsung sound driver[1] in uboot.

Link: 
https://gitlab.com/u-boot/u-boot/-/blob/master/drivers/sound/samsung_sound.c [1]

Signed-off-by: Scaria Kochidanadu 
---
 MAINTAINERS  |   1 +
 drivers/sound/Kconfig|  10 
 drivers/sound/Makefile   |   1 +
 drivers/sound/ti_sound.c | 119 +++
 4 files changed, 131 insertions(+)
 create mode 100644 drivers/sound/ti_sound.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f8afd7d51e..785afff1a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -738,6 +738,7 @@ F:  drivers/reset/reset-ti-sci.c
 F: drivers/rtc/davinci.c
 F: drivers/serial/serial_omap.c
 F: drivers/soc/ti/
+F: drivers/sound/ti_sound.c
 F: drivers/sysreset/sysreset-ti-sci.c
 F: drivers/thermal/ti-bandgap.c
 F: drivers/timer/omap-timer.c
diff --git a/drivers/sound/Kconfig b/drivers/sound/Kconfig
index 0948d8caab..be9f18b6c7 100644
--- a/drivers/sound/Kconfig
+++ b/drivers/sound/Kconfig
@@ -148,4 +148,14 @@ config SOUND_WM8994
  audio data and I2C for codec control. At present it only works
  with the Samsung I2S driver.
 
+config I2S_TI
+bool "Enable I2S support for AM62x SoCs"
+depends on I2S
+help
+  TI AM62x SoCs support an I2S interface for sending audio
+  data to an audio codec. This option enables support for this,
+  using one of the available audio codec drivers. Enabling this
+  option provides an implementation for sound_init() and
+  sound_play().
+
 endmenu
diff --git a/drivers/sound/Makefile b/drivers/sound/Makefile
index 9b40c8012f..95aaa8521c 100644
--- a/drivers/sound/Makefile
+++ b/drivers/sound/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_SOUND_I8254) += i8254_beep.o
 obj-$(CONFIG_SOUND_RT5677) += rt5677.o
 obj-$(CONFIG_INTEL_BROADWELL)  += broadwell_i2s.o broadwell_sound.o
 obj-$(CONFIG_SOUND_IVYBRIDGE)  += ivybridge_sound.o
+obj-$(CONFIG_I2S_TI)+= ti_sound.o
diff --git a/drivers/sound/ti_sound.c b/drivers/sound/ti_sound.c
new file mode 100644
index 00..a424a99b72
--- /dev/null
+++ b/drivers/sound/ti_sound.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Scaria M Kochidanadu, s-kochidan...@ti.com
+ *
+ * based on the uboot samsung sound driver, which is
+ *
+ * Copyright 2018 Google, LLC
+ * Written by Simon Glass 
+ */
+
+#include  /* boot information for Linux kernel */
+/* Pull in stuff for the build system */
+#ifdef DO_DEPS_ONLY
+#include 
+#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int ti_sound_setup(struct udevice *dev)
+{
+   struct sound_uc_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct i2s_uc_priv *i2s_priv = dev_get_uclass_priv(uc_priv->i2s);
+   int ret;
+
+   if (uc_priv->setup_done)
+   return -EALREADY;
+
+   ret = audio_codec_set_params(uc_priv->codec, i2s_priv->id,
+i2s_priv->samplingrate,
+i2s_priv->samplingrate * i2s_priv->rfs,
+i2s_priv->bitspersample,
+i2s_priv->channels);
+
+   if (ret) {
+   return ret;
+   printf("failed in set_params\n");
+   }
+   uc_priv->setup_done = true;
+
+   return 0;
+}
+
+static int ti_sound_play(struct udevice *dev, void *data, uint data_size)
+{
+   struct sound_uc_priv *uc_priv = dev_get_uclass_priv(dev);
+
+   return i2s_tx_data(uc_priv->i2s, data, data_size);
+}
+
+static int ti_sound_stop_play(struct udevice *dev)
+{
+   /* This function is necassary to satisfy the function calls
+* in the Uboot command: sound play
+*/
+   return 0;
+}
+
+static int ti_sound_probe(struct udevice *dev)
+{
+   struct sound_uc_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct ofnode_phandle_args args;
+   ofnode node;
+   int ret;
+
+   ret = uclass_get_device_by_phandle(UCLASS_AUDIO_CODEC, dev,
+  "ti,codec",
+  _priv->codec);
+   if (ret) {
+   debug("Failed to probe audio codec\n");
+   return ret;
+   }
+
+   node = ofnode_find_subnode(dev_ofnode(dev), "simple-audio-card,cpu");
+   if (!ofnode_valid(node)) {
+   debug("Failed to find /cpu subnode\n");
+   return -EINVAL;
+   }
+
+   ret = 

[PATCH] net: ftgmac100: Add Aspeed AST2700 support

2024-07-08 Thread Jacky Chou
Add support of Aspeed AST2700 SoC.  AST2700 is based on ARM64 so modify
the DMA address related code to fit both ARM and ARM64.  Besides, the
RMII/RGMII mode control register is moved from SCU500 to MAC50 so
initialize the register in ftgmac100_start correspondingly.

Signed-off-by: Jacky Chou 
---
 drivers/net/ftgmac100.c | 66 +
 drivers/net/ftgmac100.h | 12 
 2 files changed, 65 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c
index 9fb8c12838..a909a0b309 100644
--- a/drivers/net/ftgmac100.c
+++ b/drivers/net/ftgmac100.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ftgmac100.h"
 
@@ -58,6 +59,15 @@
 enum ftgmac100_model {
FTGMAC100_MODEL_FARADAY,
FTGMAC100_MODEL_ASPEED,
+   FTGMAC100_MODEL_ASPEED_AST2700,
+};
+
+union ftgmac100_dma_addr {
+   dma_addr_t addr;
+   struct {
+   u32 lo;
+   u32 hi;
+   };
 };
 
 /**
@@ -97,6 +107,8 @@ struct ftgmac100_data {
/* End of RX/TX ring buffer bits. Depend on model */
u32 rxdes0_edorr_mask;
u32 txdes0_edotr_mask;
+
+   bool is_ast2700;
 };
 
 /*
@@ -321,6 +333,7 @@ static int ftgmac100_start(struct udevice *dev)
struct eth_pdata *plat = dev_get_plat(dev);
struct ftgmac100_data *priv = dev_get_priv(dev);
struct ftgmac100 *ftgmac100 = priv->iobase;
+   union ftgmac100_dma_addr dma_addr = {.hi = 0, .lo = 0};
struct phy_device *phydev = priv->phydev;
unsigned int maccr, dblac, desc_size;
ulong start, end;
@@ -342,6 +355,7 @@ static int ftgmac100_start(struct udevice *dev)
priv->rx_index = 0;
 
for (i = 0; i < PKTBUFSTX; i++) {
+   priv->txdes[i].txdes2 = 0;
priv->txdes[i].txdes3 = 0;
priv->txdes[i].txdes0 = 0;
}
@@ -352,7 +366,14 @@ static int ftgmac100_start(struct udevice *dev)
flush_dcache_range(start, end);
 
for (i = 0; i < PKTBUFSRX; i++) {
-   priv->rxdes[i].rxdes3 = (unsigned int)net_rx_packets[i];
+   unsigned int ip_align = 0;
+
+   dma_addr.addr = (dma_addr_t)net_rx_packets[i];
+   priv->rxdes[i].rxdes2 = 
FIELD_PREP(FTGMAC100_RXDES2_RXBUF_BADR_HI, dma_addr.hi);
+   /* For IP alignment */
+   if ((dma_addr.lo & (PKTALIGN - 1)) == 0)
+   ip_align = 2;
+   priv->rxdes[i].rxdes3 = dma_addr.lo + ip_align;
priv->rxdes[i].rxdes0 = 0;
}
priv->rxdes[PKTBUFSRX - 1].rxdes0 = priv->rxdes0_edorr_mask;
@@ -362,10 +383,14 @@ static int ftgmac100_start(struct udevice *dev)
flush_dcache_range(start, end);
 
/* transmit ring */
-   writel((u32)priv->txdes, >txr_badr);
+   dma_addr.addr = (dma_addr_t)priv->txdes;
+   writel(dma_addr.lo, >txr_badr);
+   writel(dma_addr.hi, >txr_badr_hi);
 
/* receive ring */
-   writel((u32)priv->rxdes, >rxr_badr);
+   dma_addr.addr = (dma_addr_t)priv->rxdes;
+   writel(dma_addr.lo, >rxr_badr);
+   writel(dma_addr.hi, >rxr_badr_hi);
 
/* Configure TX/RX decsriptor size
 * This size is calculated based on cache line.
@@ -394,6 +419,10 @@ static int ftgmac100_start(struct udevice *dev)
FTGMAC100_MACCR_RX_RUNT |
FTGMAC100_MACCR_RX_BROADPKT;
 
+   if (priv->is_ast2700 && (priv->phydev->interface == 
PHY_INTERFACE_MODE_RMII ||
+priv->phydev->interface == 
PHY_INTERFACE_MODE_NCSI))
+   maccr |= FTGMAC100_MACCR_RMII_ENABLE;
+
writel(maccr, >maccr);
 
ret = phy_startup(phydev);
@@ -443,9 +472,11 @@ static int ftgmac100_recv(struct udevice *dev, int flags, 
uchar **packetp)
ulong des_start = ((ulong)curr_des) & ~(ARCH_DMA_MINALIGN - 1);
ulong des_end = des_start +
roundup(sizeof(*curr_des), ARCH_DMA_MINALIGN);
-   ulong data_start = curr_des->rxdes3;
+   union ftgmac100_dma_addr data_start = { .lo = 0, .hi = 0 };
ulong data_end;
 
+   data_start.hi = FIELD_GET(FTGMAC100_RXDES2_RXBUF_BADR_HI, 
curr_des->rxdes2);
+   data_start.lo = curr_des->rxdes3;
invalidate_dcache_range(des_start, des_end);
 
if (!(curr_des->rxdes0 & FTGMAC100_RXDES0_RXPKT_RDY))
@@ -465,9 +496,9 @@ static int ftgmac100_recv(struct udevice *dev, int flags, 
uchar **packetp)
   __func__, priv->rx_index, rxlen);
 
/* Invalidate received data */
-   data_end = data_start + roundup(rxlen, ARCH_DMA_MINALIGN);
-   invalidate_dcache_range(data_start, data_end);
-   *packetp = (uchar *)data_start;
+   data_end = data_start.addr + roundup(rxlen, ARCH_DMA_MINALIGN);
+   invalidate_dcache_range(data_start.addr, data_end);
+   *packetp = (uchar *)data_start.addr;
 
return rxlen;
 }
@@ -493,6 +524,7 @@ static int ftgmac100_send(struct 

[PATCH v3 5/5] fixup! soc: qcom: rpmh and cmd-db drivers

2024-07-08 Thread Caleb Connolly
---
 drivers/soc/qcom/rpmh-rsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
index 1f8428c415a1..30756a32d590 100644
--- a/drivers/soc/qcom/rpmh-rsc.c
+++ b/drivers/soc/qcom/rpmh-rsc.c
@@ -549,9 +549,9 @@ static int rpmh_rsc_bind(struct udevice *dev)
ret = cmd_db_init();
if (ret)
return ret;
 
-   return dm_scan_fdt_dev(dev);
+   return 0;
 }
 
 static int rpmh_rsc_probe(struct udevice *dev)
 {

-- 
2.45.2



[PATCH v3 2/5] soc: qcom: rpmh and cmd-db drivers

2024-07-08 Thread Caleb Connolly
Introduce two Qualcomm SoC drivers, the RPMh and cmd-db. RPMh is a the
name for the second generation Resource Power Management hub on Qualcomm
SoCs. Most core regulators have to be controlled via this hub.

The cmd-db is a region of memory which contains offsets and data about
how to communicate with the RPMh.

Tested-by: Neil Armstrong  # on SM8550 & SM8^%)
Signed-off-by: Caleb Connolly 
---
 drivers/soc/Kconfig  |   1 +
 drivers/soc/Makefile |   1 +
 drivers/soc/qcom/Kconfig |  25 ++
 drivers/soc/qcom/Makefile|   4 +
 drivers/soc/qcom/cmd-db.c| 261 
 drivers/soc/qcom/rpmh-internal.h | 141 +
 drivers/soc/qcom/rpmh-rsc.c  | 628 +++
 drivers/soc/qcom/rpmh.c  | 112 +++
 include/soc/qcom/cmd-db.h|  42 +++
 include/soc/qcom/rpmh.h  |  29 ++
 include/soc/qcom/tcs.h   |  78 +
 11 files changed, 1322 insertions(+)

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cee506fe4747..8ef408d9ba1b 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -47,8 +47,9 @@ config SOC_XILINX_VERSAL_NET
  Enable this option to select SoC device id driver for Xilinx Versal 
NET.
  This allows other drivers to verify the SoC familiy & revision using
  matching SoC attributes.
 
+source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/samsung/Kconfig"
 source "drivers/soc/ti/Kconfig"
 
 endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 5ec89a053165..abcc8a88950f 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,8 +4,9 @@
 
 obj-$(CONFIG_SOC_AMD_VERSAL2) += soc_amd_versal2.o
 obj-$(CONFIG_SOC_SAMSUNG) += samsung/
 obj-$(CONFIG_SOC_TI) += ti/
+obj-$(CONFIG_SOC_QCOM) += qcom/
 obj-$(CONFIG_SOC_DEVICE) += soc-uclass.o
 obj-$(CONFIG_SOC_DEVICE_TI_K3) += soc_ti_k3.o
 obj-$(CONFIG_SANDBOX) += soc_sandbox.o
 obj-$(CONFIG_SOC_XILINX_ZYNQMP) += soc_xilinx_zynqmp.o
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
new file mode 100644
index ..a0872c5b3c83
--- /dev/null
+++ b/drivers/soc/qcom/Kconfig
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+menuconfig SOC_QCOM
+   bool "Qualcomm SOC drivers support"
+   help
+ Say Y here if you want to enable Qualcomm SOC drivers support.
+
+if SOC_QCOM
+
+config QCOM_COMMAND_DB
+   bool "Qualcomm Command DB"
+   help
+ Command DB queries shared memory by key string for shared system
+ resources. Platform drivers that require to set state of a shared
+ resource on a RPM-hardened platform must use this database to get
+ SoC specific identifier and information for the shared resources.
+
+config QCOM_RPMH
+   bool "Qualcomm RPMh support"
+   depends on QCOM_COMMAND_DB
+   help
+ Say y here to support the Qualcomm RPMh (resource peripheral manager)
+ if you need to control regulators on Qualcomm platforms, say y here.
+
+endif # SOC_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
new file mode 100644
index ..4fca569cfb77
--- /dev/null
+++ b/drivers/soc/qcom/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
+obj-$(CONFIG_QCOM_RPMH)+= rpmh-rsc.o rpmh.o
diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
new file mode 100644
index ..62f1479bda09
--- /dev/null
+++ b/drivers/soc/qcom/cmd-db.c
@@ -0,0 +1,261 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2016-2018, 2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023, Linaro Ltd.
+ */
+
+#define pr_fmt(fmt) "cmd-db: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define NUM_PRIORITY   2
+#define MAX_SLV_ID 8
+#define SLAVE_ID_MASK  0x7
+#define SLAVE_ID_SHIFT 16
+
+/**
+ * struct entry_header: header for each entry in cmddb
+ *
+ * @id: resource's identifier
+ * @priority: unused
+ * @addr: the address of the resource
+ * @len: length of the data
+ * @offset: offset from :@data_offset, start of the data
+ */
+struct entry_header {
+   u8 id[8];
+   __le32 priority[NUM_PRIORITY];
+   __le32 addr;
+   __le16 len;
+   __le16 offset;
+};
+
+/**
+ * struct rsc_hdr: resource header information
+ *
+ * @slv_id: id for the resource
+ * @header_offset: entry's header at offset from the end of the cmd_db_header
+ * @data_offset: entry's data at offset from the end of the cmd_db_header
+ * @cnt: number of entries for HW type
+ * @version: MSB is major, LSB is minor
+ * @reserved: reserved for future use.
+ */
+struct rsc_hdr {
+   __le16 slv_id;
+   __le16 header_offset;
+   __le16 data_offset;
+   __le16 cnt;
+   __le16 version;
+   __le16 reserved[3];
+};
+
+/**
+ * struct cmd_db_header: The DB header information
+ *
+ * @version: The 

[PATCH v3 4/5] qcom_defconfig: enable rpmh regulators

2024-07-08 Thread Caleb Connolly
Enable RPMh, cmd-db, and RPMh regulators. Additionally enable
CMD_REGULATOR for debugging.

Signed-off-by: Caleb Connolly 
---
 configs/qcom_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index 60a8e38cc6bb..8a55bb9af708 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -35,8 +35,9 @@ CONFIG_CMD_UFS=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_CAT=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_EFIDEBUG=y
+CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_LOG=y
 CONFIG_OF_LIVE=y
 CONFIG_BUTTON_QCOM_PMIC=y
 CONFIG_CLK=y
@@ -90,11 +91,15 @@ CONFIG_PINCTRL_QCOM_SM8650=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_QCOM=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_QCOM_RPMH=y
 CONFIG_SCSI=y
 CONFIG_MSM_SERIAL=y
 CONFIG_MSM_GENI_SERIAL=y
+CONFIG_SOC_QCOM=y
+CONFIG_QCOM_COMMAND_DB=y
+CONFIG_QCOM_RPMH=y
 CONFIG_SPMI_MSM=y
 CONFIG_SYSINFO=y
 CONFIG_SYSINFO_SMBIOS=y
 CONFIG_USB=y

-- 
2.45.2



[PATCH v3 3/5] power: regulator: add qcom-rpmh-regulator

2024-07-08 Thread Caleb Connolly
Add a regulator driver for controlling the PMIC rails via the RPMh on
Qualcomm platforms. This driver is restricted to only know about rails
which are required by u-boot.

Signed-off-by: Caleb Connolly 
---
 drivers/power/regulator/Kconfig   |   8 +
 drivers/power/regulator/Makefile  |   1 +
 drivers/power/regulator/qcom-rpmh-regulator.c | 536 ++
 3 files changed, 545 insertions(+)

diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 102ec7bc5f89..bc061c20d75e 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -215,8 +215,16 @@ config DM_REGULATOR_GPIO
This config enables implementation of driver-model regulator uclass
features for gpio regulators. The driver implements get/set for
voltage value.
 
+config DM_REGULATOR_QCOM_RPMH
+   bool "Enable driver model for Qualcomm RPMh regulator"
+   depends on DM_REGULATOR && QCOM_RPMH
+   ---help---
+ Enable support for the Qualcomm RPMh regulator. The driver
+ implements get/set api for a limited set of regulators used
+ by u-boot.
+
 config SPL_DM_REGULATOR_GPIO
bool "Enable Driver Model for GPIO REGULATOR in SPL"
depends on DM_REGULATOR_GPIO && SPL_GPIO
select SPL_DM_REGULATOR_COMMON
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index f79932d83307..56a527612b74 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -20,8 +20,9 @@ obj-$(CONFIG_$(SPL_)REGULATOR_PWM) += pwm_regulator.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_FAN53555) += fan53555.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_COMMON) += regulator_common.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
+obj-$(CONFIG_DM_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_$(SPL_TPL_)REGULATOR_RK8XX) += rk8xx.o
 obj-$(CONFIG_DM_REGULATOR_S2MPS11) += s2mps11_regulator.o
 obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
 obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/qcom-rpmh-regulator.c 
b/drivers/power/regulator/qcom-rpmh-regulator.c
new file mode 100644
index ..7ddd6e3d21bf
--- /dev/null
+++ b/drivers/power/regulator/qcom-rpmh-regulator.c
@@ -0,0 +1,536 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018-2021, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+/**
+ * enum rpmh_regulator_type - supported RPMh accelerator types
+ * @VRM:   RPMh VRM accelerator which supports voting on enable, voltage,
+ * and mode of LDO, SMPS, and BOB type PMIC regulators.
+ * @XOB:   RPMh XOB accelerator which supports voting on the enable state
+ * of PMIC regulators.
+ */
+enum rpmh_regulator_type {
+   VRM,
+   XOB,
+};
+
+enum rpmh_regulator_mode {
+   REGULATOR_MODE_RETENTION,
+   REGULATOR_MODE_LPM,
+   REGULATOR_MODE_AUTO,
+   REGULATOR_MODE_HPM,
+};
+
+#define RPMH_REGULATOR_REG_VRM_VOLTAGE 0x0
+#define RPMH_REGULATOR_REG_ENABLE  0x4
+#define RPMH_REGULATOR_REG_VRM_MODE0x8
+
+#define PMIC4_LDO_MODE_RETENTION   4
+#define PMIC4_LDO_MODE_LPM 5
+#define PMIC4_LDO_MODE_HPM 7
+
+#define PMIC4_SMPS_MODE_RETENTION  4
+#define PMIC4_SMPS_MODE_PFM5
+#define PMIC4_SMPS_MODE_AUTO   6
+#define PMIC4_SMPS_MODE_PWM7
+
+#define PMIC4_BOB_MODE_PASS0
+#define PMIC4_BOB_MODE_PFM 1
+#define PMIC4_BOB_MODE_AUTO2
+#define PMIC4_BOB_MODE_PWM 3
+
+#define PMIC5_LDO_MODE_RETENTION   3
+#define PMIC5_LDO_MODE_LPM 4
+#define PMIC5_LDO_MODE_HPM 7
+
+#define PMIC5_SMPS_MODE_RETENTION  3
+#define PMIC5_SMPS_MODE_PFM4
+#define PMIC5_SMPS_MODE_AUTO   6
+#define PMIC5_SMPS_MODE_PWM7
+
+#define PMIC5_BOB_MODE_PASS2
+#define PMIC5_BOB_MODE_PFM 4
+#define PMIC5_BOB_MODE_AUTO6
+#define PMIC5_BOB_MODE_PWM 7
+
+/**
+ * struct linear_range - table of selector - value pairs
+ *
+ * Define a lookup-table for range of values. Intended to help when looking
+ * for a register value matching certaing physical measure (like voltage).
+ * Usable when increment of one in register always results a constant increment
+ * of the physical measure (like voltage).
+ *
+ * @min:  Lowest value in range
+ * @min_sel: Lowest selector for range
+ * @max_sel: Highest selector for range
+ * @step: Value step size
+ */
+struct linear_range {
+   unsigned int min;
+   unsigned int min_sel;
+   

[PATCH v3 1/5] linux/bitmap.h: add bitmap_empty helper

2024-07-08 Thread Caleb Connolly
Import this function from Linux.

Signed-off-by: Caleb Connolly 
---
 include/linux/bitmap.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 0a8503af9f14..40ca2212cb40 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -195,8 +195,16 @@ static inline void bitmap_fill(unsigned long *dst, 
unsigned int nbits)
memset(dst, 0xff, len);
}
 }
 
+static inline bool bitmap_empty(const unsigned long *src, unsigned int nbits)
+{
+   if (small_const_nbits(nbits))
+   return !(*src & BITMAP_LAST_WORD_MASK(nbits));
+
+   return find_first_bit(src, nbits) == nbits;
+}
+
 static inline void bitmap_or(unsigned long *dst, const unsigned long *src1,
 const unsigned long *src2, unsigned int nbits)
 {
if (small_const_nbits(nbits))

-- 
2.45.2



[PATCH v3 0/5] qcom: rpmh core and regulator support

2024-07-08 Thread Caleb Connolly
This series introduces support for the RPMh (Resource Power Manager
(hardened)) co-processor and associated regulator driver found on most
modern Qualcomm platforms (since ~2017).

Even though most regulators are controlled via SPMI, the specific
regions on the PMICs for controlling the regulators are restricted and
can't be accessed by the Applications Processor (AP/HLOS). Instead,
these resources are proxied via the RPMh where they can be voted on by
multiple subsystems (Linux, the modem, and the other DSPs). This is done
for security (to protect clocks, power domains, and regulators that are
specifically relevant for the trustzone) as well as to simplify the
management of shared peripherals and to allow for handover of
peripherals like the USB controller.

For U-Boot, our main concern is the regulators. Since all regulators on
the system are controlled via the RPMh, it is necessary to support it to
enable USB VBUS on some platforms, and may be needed for other
peripherals in the future.

Communicating with the RPMh additional requires accessing the cmd-db
shared memory region, this contains key/value maps to determine the
address of specific resources on the RPMh.

Introduce support for the cmd-db, the RPMh framework, and some of the
regulators that are necessary to enable USB VBUS on the RB5 development
board.

These drivers were originally taken from Linux, however they have been
heavily modified and simplified for U-Boot. Since the original Linux
drivers contained heavy optimisations related to multithreading and
asynchronous probing, as well as support for idle and suspend states
which we don't need to deal with here.

The U-Boot version of the driver supports a single TCS and always
requests a response from the RPMh, since we don't need to worry about
having multiple transactions in flight at once.

---
Changes in v3:
- Don't call dm_scan_fdt_dev(), since DM core will scan.
- Link to v2: 
https://lore.kernel.org/r/20240708-b4-qcom-rpmh-v2-0-8bc765606...@linaro.org

Changes in v2:
- Implement Neil's suggestions and fixes for SM8[56]50
- Slightly refactor cmd_db_init() for better abstraction.
- Improve logging (printf -> log_err/dev_err)
- Add missing error check in rpmh_regulators_bind()
- Link to v1: 
https://lore.kernel.org/r/20240617-b4-qcom-rpmh-v1-0-bd2336923...@linaro.org

---
Caleb Connolly (5):
  linux/bitmap.h: add bitmap_empty helper
  soc: qcom: rpmh and cmd-db drivers
  power: regulator: add qcom-rpmh-regulator
  qcom_defconfig: enable rpmh regulators
  fixup! soc: qcom: rpmh and cmd-db drivers

 configs/qcom_defconfig|   5 +
 drivers/power/regulator/Kconfig   |   8 +
 drivers/power/regulator/Makefile  |   1 +
 drivers/power/regulator/qcom-rpmh-regulator.c | 536 ++
 drivers/soc/Kconfig   |   1 +
 drivers/soc/Makefile  |   1 +
 drivers/soc/qcom/Kconfig  |  25 +
 drivers/soc/qcom/Makefile |   4 +
 drivers/soc/qcom/cmd-db.c | 261 +++
 drivers/soc/qcom/rpmh-internal.h  | 141 ++
 drivers/soc/qcom/rpmh-rsc.c   | 628 ++
 drivers/soc/qcom/rpmh.c   | 112 +
 include/linux/bitmap.h|   8 +
 include/soc/qcom/cmd-db.h |  42 ++
 include/soc/qcom/rpmh.h   |  29 ++
 include/soc/qcom/tcs.h|  78 
 16 files changed, 1880 insertions(+)
---
change-id: 20240611-b4-qcom-rpmh-fcfd32ac2940
base-commit: 50adc932e7aa34e6d9c738ec13ed09382a9d109a

// Caleb (they/them)



Re: [PATCH] board: sifive: unmatched: remove extra space in fdtfile value

2024-07-08 Thread Leo Liang
On Mon, Jun 24, 2024 at 11:46:58AM +0200, Andreas Schwab wrote:
> Fixes: 44a792c994 ("riscv: sifive: unmatched: migrate to text environment")
> Signed-off-by: Andreas Schwab 
> ---
>  board/sifive/unmatched/unmatched.env | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Leo Yu-Chi Liang 


Re: [PATCH 1/1] riscv: semihosting: correct alignment

2024-07-08 Thread Leo Liang
On Wed, Jun 19, 2024 at 05:22:52PM +0200, Heinrich Schuchardt wrote:
> Commit 7400d34ba992 ("riscv: semihosting: replace inline assembly with
> assembly file") reduced the alignment of function smh_trap().
> 
> As described in the "RISC-V Semihosting" specification [1] the ssli,
> ebreak, and srai statements must all reside in the same memory page.
> 
> [1] RISC-V Semihosting, Version 0.4, 12th June 2024
> https://github.com/riscv-non-isa/riscv-semihosting
> 
> Fixes: 7400d34ba992 ("riscv: semihosting: replace inline assembly with 
> assembly file")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/lib/semihosting.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Leo Yu-Chi Liang 


Re: [PATCH 1/1] riscv: add RISC-V fields to bdinfo command

2024-07-08 Thread Leo Liang
On Fri, Jun 07, 2024 at 10:41:17AM +0200, Heinrich Schuchardt wrote:
> The firmware invoking main U-Boot uses
> 
> * a0 to pass the boot hart
> * a1 to pass a device-tree
> 
> Let the bdinfo command print this information, e.g.
> 
> boot hart   = 0x001b
> firmware fdt= 0x87e0
> 
> The firmware fdt field will only be printed if it is non-zero.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/lib/Makefile |  1 +
>  arch/riscv/lib/bdinfo.c | 18 ++
>  2 files changed, 19 insertions(+)
>  create mode 100644 arch/riscv/lib/bdinfo.c

Reviewed-by: Leo Yu-Chi Liang 


[PATCH] configs: am62x_evm_a53_defconfig: Remove CONFIG_SYS_BOOTM_LEN

2024-07-08 Thread Kamlesh Gurudasani
Increase the maximum size of the buffer that is used to decompress
the OS image in to.

If image size is greater than the buffer, boot
will fail with following error,
"Error: inflate() returned -5"
"gzip compressed: uncompress error -1"

Default limit for ARM64 platforms is 0x400, remove
CONFIG_SYS_BOOTM_LEN=0x800, so that it follows default limit.

Signed-off-by: Kamlesh Gurudasani 
---
 configs/am62x_evm_a53_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index ca993b427b..dfa5ecc847 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -32,7 +32,6 @@ CONFIG_SPL_SPI=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
 CONFIG_BOOTSTD_FULL=y
-CONFIG_SYS_BOOTM_LEN=0x80
 CONFIG_BOOTCOMMAND="run findfdt; run envboot; bootflow scan -lb"
 CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_MAX_SIZE=0x58000

---
base-commit: fd46ea0e701920eb205c2bce9d527bf0dec10b59
change-id: 20240708-remove-bootm-len-ab4e46039656

Best regards,
-- 
Kamlesh Gurudasani 



[PATCH] ARM: stm32: Fix secure_waitbits() mask check

2024-07-08 Thread Marek Vasut
Do not apply bitwise AND to register value and expected value, only
apply bitwise AND to register value and mask, and only then compare
the result with expected value that the function polls for.

Fixes: b49105320a5b ("stm32mp: psci: Implement PSCI system suspend and DRAM 
SSR")
Signed-off-by: Marek Vasut 
---
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Tom Rini 
Cc: u-boot@lists.denx.de
Cc: uboot-st...@st-md-mailman.stormreply.com
---
 arch/arm/mach-stm32mp/stm32mp1/psci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-stm32mp/stm32mp1/psci.c 
b/arch/arm/mach-stm32mp/stm32mp1/psci.c
index e99103910d9..ffdafea464d 100644
--- a/arch/arm/mach-stm32mp/stm32mp1/psci.c
+++ b/arch/arm/mach-stm32mp/stm32mp1/psci.c
@@ -393,8 +393,7 @@ static int __secure secure_waitbits(u32 reg, u32 mask, u32 
val)
asm volatile("mrrc p15, 0, %Q0, %R0, c14" : "=r" (start));
for (;;) {
tmp = readl(reg);
-   tmp &= mask;
-   if ((tmp & val) == val)
+   if ((tmp & mask) == val)
return 0;
asm volatile("mrrc p15, 0, %Q0, %R0, c14" : "=r" (end));
if ((end - start) > delay)
-- 
2.43.0



Re: [RFC PATCH v2 16/48] lmb: config: add lmb config symbols for SPL

2024-07-08 Thread Sughosh Ganu
On Sat, 6 Jul 2024 at 01:18, Tom Rini  wrote:
>
> On Thu, Jul 04, 2024 at 01:05:12PM +0530, Sughosh Ganu wrote:
>
> > Add separate config symbols for enabling the LMB module for the SPL
> > phase. The LMB module implementation now relies on alloced list data
> > structure which requires heap area to be present. Add specific config
> > symbol for the SPL phase of U-Boot so that this can be enabled on
> > platforms which support a heap in SPL.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> > Changes since V1: New patch
> >
> >  lib/Kconfig | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index 072ed0ecfa..7eea517b3b 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -1103,7 +1103,17 @@ config LMB
> >   default y if ARC || ARM || M68K || MICROBLAZE || MIPS || \
> >NIOS2 || PPC || RISCV || SANDBOX || SH || X86 || XTENSA
> >   help
> > -   Support the library logical memory blocks.
> > +   Support the library logical memory blocks. This will require
> > +   a malloc() implementation for defining the data structures
> > +   needed for maintaining the LMB memory map.
>
> Even today, LMB really should be def_bool y rather than an option, so
> this series should correct that. That said...

Okay

>
> > +config SPL_LMB
> > + bool "Enable LMB module for SPL"
> > + depends on SPL && SPL_FRAMEWORK && SPL_SYS_MALLOC
> > + help
> > +   Enable support for Logical Memory Block library routines in
> > +   SPL. This will require a malloc() implementation for defining
> > +   the data structures needed for maintaining the LMB memory map.
>
> The question I guess becomes when do we need LMB in SPL, exactly? And I
> guess it's another case where it should be def_bool y (but still depends
> on what you have here) since we need to make sure we don't overwrite
> running SPL.

So this is a question even I had. Do we really need to enable LMB in
SPL ? The main reason for introducing the symbol was to have more
granularity to remove the LMB code from SPL, but should this really be
enabled in SPL is something that I am not too sure about.

-sughosh

>
> --
> Tom


[PATCH v2 4/4] qcom_defconfig: enable rpmh regulators

2024-07-08 Thread Caleb Connolly
Enable RPMh, cmd-db, and RPMh regulators. Additionally enable
CMD_REGULATOR for debugging.

Signed-off-by: Caleb Connolly 
---
 configs/qcom_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
index 60a8e38cc6bb..8a55bb9af708 100644
--- a/configs/qcom_defconfig
+++ b/configs/qcom_defconfig
@@ -35,8 +35,9 @@ CONFIG_CMD_UFS=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_CAT=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_EFIDEBUG=y
+CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_LOG=y
 CONFIG_OF_LIVE=y
 CONFIG_BUTTON_QCOM_PMIC=y
 CONFIG_CLK=y
@@ -90,11 +91,15 @@ CONFIG_PINCTRL_QCOM_SM8650=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_QCOM=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_QCOM_RPMH=y
 CONFIG_SCSI=y
 CONFIG_MSM_SERIAL=y
 CONFIG_MSM_GENI_SERIAL=y
+CONFIG_SOC_QCOM=y
+CONFIG_QCOM_COMMAND_DB=y
+CONFIG_QCOM_RPMH=y
 CONFIG_SPMI_MSM=y
 CONFIG_SYSINFO=y
 CONFIG_SYSINFO_SMBIOS=y
 CONFIG_USB=y

-- 
2.45.2



[PATCH v2 2/4] soc: qcom: rpmh and cmd-db drivers

2024-07-08 Thread Caleb Connolly
Introduce two Qualcomm SoC drivers, the RPMh and cmd-db. RPMh is a the
name for the second generation Resource Power Management hub on Qualcomm
SoCs. Most core regulators have to be controlled via this hub.

The cmd-db is a region of memory which contains offsets and data about
how to communicate with the RPMh.

Tested-by: Neil Armstrong  # on SM8550 & SM8^%)
Signed-off-by: Caleb Connolly 
---
 drivers/soc/Kconfig  |   1 +
 drivers/soc/Makefile |   1 +
 drivers/soc/qcom/Kconfig |  25 ++
 drivers/soc/qcom/Makefile|   4 +
 drivers/soc/qcom/cmd-db.c| 261 
 drivers/soc/qcom/rpmh-internal.h | 141 +
 drivers/soc/qcom/rpmh-rsc.c  | 628 +++
 drivers/soc/qcom/rpmh.c  | 112 +++
 include/soc/qcom/cmd-db.h|  42 +++
 include/soc/qcom/rpmh.h  |  29 ++
 include/soc/qcom/tcs.h   |  78 +
 11 files changed, 1322 insertions(+)

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cee506fe4747..8ef408d9ba1b 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -47,8 +47,9 @@ config SOC_XILINX_VERSAL_NET
  Enable this option to select SoC device id driver for Xilinx Versal 
NET.
  This allows other drivers to verify the SoC familiy & revision using
  matching SoC attributes.
 
+source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/samsung/Kconfig"
 source "drivers/soc/ti/Kconfig"
 
 endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 5ec89a053165..abcc8a88950f 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -4,8 +4,9 @@
 
 obj-$(CONFIG_SOC_AMD_VERSAL2) += soc_amd_versal2.o
 obj-$(CONFIG_SOC_SAMSUNG) += samsung/
 obj-$(CONFIG_SOC_TI) += ti/
+obj-$(CONFIG_SOC_QCOM) += qcom/
 obj-$(CONFIG_SOC_DEVICE) += soc-uclass.o
 obj-$(CONFIG_SOC_DEVICE_TI_K3) += soc_ti_k3.o
 obj-$(CONFIG_SANDBOX) += soc_sandbox.o
 obj-$(CONFIG_SOC_XILINX_ZYNQMP) += soc_xilinx_zynqmp.o
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
new file mode 100644
index ..a0872c5b3c83
--- /dev/null
+++ b/drivers/soc/qcom/Kconfig
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+menuconfig SOC_QCOM
+   bool "Qualcomm SOC drivers support"
+   help
+ Say Y here if you want to enable Qualcomm SOC drivers support.
+
+if SOC_QCOM
+
+config QCOM_COMMAND_DB
+   bool "Qualcomm Command DB"
+   help
+ Command DB queries shared memory by key string for shared system
+ resources. Platform drivers that require to set state of a shared
+ resource on a RPM-hardened platform must use this database to get
+ SoC specific identifier and information for the shared resources.
+
+config QCOM_RPMH
+   bool "Qualcomm RPMh support"
+   depends on QCOM_COMMAND_DB
+   help
+ Say y here to support the Qualcomm RPMh (resource peripheral manager)
+ if you need to control regulators on Qualcomm platforms, say y here.
+
+endif # SOC_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
new file mode 100644
index ..4fca569cfb77
--- /dev/null
+++ b/drivers/soc/qcom/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
+obj-$(CONFIG_QCOM_RPMH)+= rpmh-rsc.o rpmh.o
diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
new file mode 100644
index ..62f1479bda09
--- /dev/null
+++ b/drivers/soc/qcom/cmd-db.c
@@ -0,0 +1,261 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2016-2018, 2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023, Linaro Ltd.
+ */
+
+#define pr_fmt(fmt) "cmd-db: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define NUM_PRIORITY   2
+#define MAX_SLV_ID 8
+#define SLAVE_ID_MASK  0x7
+#define SLAVE_ID_SHIFT 16
+
+/**
+ * struct entry_header: header for each entry in cmddb
+ *
+ * @id: resource's identifier
+ * @priority: unused
+ * @addr: the address of the resource
+ * @len: length of the data
+ * @offset: offset from :@data_offset, start of the data
+ */
+struct entry_header {
+   u8 id[8];
+   __le32 priority[NUM_PRIORITY];
+   __le32 addr;
+   __le16 len;
+   __le16 offset;
+};
+
+/**
+ * struct rsc_hdr: resource header information
+ *
+ * @slv_id: id for the resource
+ * @header_offset: entry's header at offset from the end of the cmd_db_header
+ * @data_offset: entry's data at offset from the end of the cmd_db_header
+ * @cnt: number of entries for HW type
+ * @version: MSB is major, LSB is minor
+ * @reserved: reserved for future use.
+ */
+struct rsc_hdr {
+   __le16 slv_id;
+   __le16 header_offset;
+   __le16 data_offset;
+   __le16 cnt;
+   __le16 version;
+   __le16 reserved[3];
+};
+
+/**
+ * struct cmd_db_header: The DB header information
+ *
+ * @version: The 

[PATCH v2 3/4] power: regulator: add qcom-rpmh-regulator

2024-07-08 Thread Caleb Connolly
Add a regulator driver for controlling the PMIC rails via the RPMh on
Qualcomm platforms. This driver is restricted to only know about rails
which are required by u-boot.

Signed-off-by: Caleb Connolly 
---
 drivers/power/regulator/Kconfig   |   8 +
 drivers/power/regulator/Makefile  |   1 +
 drivers/power/regulator/qcom-rpmh-regulator.c | 536 ++
 3 files changed, 545 insertions(+)

diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 102ec7bc5f89..bc061c20d75e 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -215,8 +215,16 @@ config DM_REGULATOR_GPIO
This config enables implementation of driver-model regulator uclass
features for gpio regulators. The driver implements get/set for
voltage value.
 
+config DM_REGULATOR_QCOM_RPMH
+   bool "Enable driver model for Qualcomm RPMh regulator"
+   depends on DM_REGULATOR && QCOM_RPMH
+   ---help---
+ Enable support for the Qualcomm RPMh regulator. The driver
+ implements get/set api for a limited set of regulators used
+ by u-boot.
+
 config SPL_DM_REGULATOR_GPIO
bool "Enable Driver Model for GPIO REGULATOR in SPL"
depends on DM_REGULATOR_GPIO && SPL_GPIO
select SPL_DM_REGULATOR_COMMON
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index f79932d83307..56a527612b74 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -20,8 +20,9 @@ obj-$(CONFIG_$(SPL_)REGULATOR_PWM) += pwm_regulator.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_FAN53555) += fan53555.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_COMMON) += regulator_common.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
+obj-$(CONFIG_DM_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_$(SPL_TPL_)REGULATOR_RK8XX) += rk8xx.o
 obj-$(CONFIG_DM_REGULATOR_S2MPS11) += s2mps11_regulator.o
 obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
 obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/qcom-rpmh-regulator.c 
b/drivers/power/regulator/qcom-rpmh-regulator.c
new file mode 100644
index ..7ddd6e3d21bf
--- /dev/null
+++ b/drivers/power/regulator/qcom-rpmh-regulator.c
@@ -0,0 +1,536 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018-2021, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+/**
+ * enum rpmh_regulator_type - supported RPMh accelerator types
+ * @VRM:   RPMh VRM accelerator which supports voting on enable, voltage,
+ * and mode of LDO, SMPS, and BOB type PMIC regulators.
+ * @XOB:   RPMh XOB accelerator which supports voting on the enable state
+ * of PMIC regulators.
+ */
+enum rpmh_regulator_type {
+   VRM,
+   XOB,
+};
+
+enum rpmh_regulator_mode {
+   REGULATOR_MODE_RETENTION,
+   REGULATOR_MODE_LPM,
+   REGULATOR_MODE_AUTO,
+   REGULATOR_MODE_HPM,
+};
+
+#define RPMH_REGULATOR_REG_VRM_VOLTAGE 0x0
+#define RPMH_REGULATOR_REG_ENABLE  0x4
+#define RPMH_REGULATOR_REG_VRM_MODE0x8
+
+#define PMIC4_LDO_MODE_RETENTION   4
+#define PMIC4_LDO_MODE_LPM 5
+#define PMIC4_LDO_MODE_HPM 7
+
+#define PMIC4_SMPS_MODE_RETENTION  4
+#define PMIC4_SMPS_MODE_PFM5
+#define PMIC4_SMPS_MODE_AUTO   6
+#define PMIC4_SMPS_MODE_PWM7
+
+#define PMIC4_BOB_MODE_PASS0
+#define PMIC4_BOB_MODE_PFM 1
+#define PMIC4_BOB_MODE_AUTO2
+#define PMIC4_BOB_MODE_PWM 3
+
+#define PMIC5_LDO_MODE_RETENTION   3
+#define PMIC5_LDO_MODE_LPM 4
+#define PMIC5_LDO_MODE_HPM 7
+
+#define PMIC5_SMPS_MODE_RETENTION  3
+#define PMIC5_SMPS_MODE_PFM4
+#define PMIC5_SMPS_MODE_AUTO   6
+#define PMIC5_SMPS_MODE_PWM7
+
+#define PMIC5_BOB_MODE_PASS2
+#define PMIC5_BOB_MODE_PFM 4
+#define PMIC5_BOB_MODE_AUTO6
+#define PMIC5_BOB_MODE_PWM 7
+
+/**
+ * struct linear_range - table of selector - value pairs
+ *
+ * Define a lookup-table for range of values. Intended to help when looking
+ * for a register value matching certaing physical measure (like voltage).
+ * Usable when increment of one in register always results a constant increment
+ * of the physical measure (like voltage).
+ *
+ * @min:  Lowest value in range
+ * @min_sel: Lowest selector for range
+ * @max_sel: Highest selector for range
+ * @step: Value step size
+ */
+struct linear_range {
+   unsigned int min;
+   unsigned int min_sel;
+   

[PATCH v2 1/4] linux/bitmap.h: add bitmap_empty helper

2024-07-08 Thread Caleb Connolly
Import this function from Linux.

Signed-off-by: Caleb Connolly 
---
 include/linux/bitmap.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 0a8503af9f14..40ca2212cb40 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -195,8 +195,16 @@ static inline void bitmap_fill(unsigned long *dst, 
unsigned int nbits)
memset(dst, 0xff, len);
}
 }
 
+static inline bool bitmap_empty(const unsigned long *src, unsigned int nbits)
+{
+   if (small_const_nbits(nbits))
+   return !(*src & BITMAP_LAST_WORD_MASK(nbits));
+
+   return find_first_bit(src, nbits) == nbits;
+}
+
 static inline void bitmap_or(unsigned long *dst, const unsigned long *src1,
 const unsigned long *src2, unsigned int nbits)
 {
if (small_const_nbits(nbits))

-- 
2.45.2



[PATCH v2 0/4] qcom: rpmh core and regulator support

2024-07-08 Thread Caleb Connolly
This series introduces support for the RPMh (Resource Power Manager
(hardened)) co-processor and associated regulator driver found on most
modern Qualcomm platforms (since ~2017).

Even though most regulators are controlled via SPMI, the specific
regions on the PMICs for controlling the regulators are restricted and
can't be accessed by the Applications Processor (AP/HLOS). Instead,
these resources are proxied via the RPMh where they can be voted on by
multiple subsystems (Linux, the modem, and the other DSPs). This is done
for security (to protect clocks, power domains, and regulators that are
specifically relevant for the trustzone) as well as to simplify the
management of shared peripherals and to allow for handover of
peripherals like the USB controller.

For U-Boot, our main concern is the regulators. Since all regulators on
the system are controlled via the RPMh, it is necessary to support it to
enable USB VBUS on some platforms, and may be needed for other
peripherals in the future.

Communicating with the RPMh additional requires accessing the cmd-db
shared memory region, this contains key/value maps to determine the
address of specific resources on the RPMh.

Introduce support for the cmd-db, the RPMh framework, and some of the
regulators that are necessary to enable USB VBUS on the RB5 development
board.

These drivers were originally taken from Linux, however they have been
heavily modified and simplified for U-Boot. Since the original Linux
drivers contained heavy optimisations related to multithreading and
asynchronous probing, as well as support for idle and suspend states
which we don't need to deal with here.

The U-Boot version of the driver supports a single TCS and always
requests a response from the RPMh, since we don't need to worry about
having multiple transactions in flight at once.

---
Changes in v2:
- Implement Neil's suggestions and fixes for SM8[56]50
- Slightly refactor cmd_db_init() for better abstraction.
- Improve logging (printf -> log_err/dev_err)
- Add missing error check in rpmh_regulators_bind()
- Link to v1: 
https://lore.kernel.org/r/20240617-b4-qcom-rpmh-v1-0-bd2336923...@linaro.org

---
Caleb Connolly (4):
  linux/bitmap.h: add bitmap_empty helper
  soc: qcom: rpmh and cmd-db drivers
  power: regulator: add qcom-rpmh-regulator
  qcom_defconfig: enable rpmh regulators

 configs/qcom_defconfig|   5 +
 drivers/power/regulator/Kconfig   |   8 +
 drivers/power/regulator/Makefile  |   1 +
 drivers/power/regulator/qcom-rpmh-regulator.c | 536 ++
 drivers/soc/Kconfig   |   1 +
 drivers/soc/Makefile  |   1 +
 drivers/soc/qcom/Kconfig  |  25 +
 drivers/soc/qcom/Makefile |   4 +
 drivers/soc/qcom/cmd-db.c | 261 +++
 drivers/soc/qcom/rpmh-internal.h  | 141 ++
 drivers/soc/qcom/rpmh-rsc.c   | 628 ++
 drivers/soc/qcom/rpmh.c   | 112 +
 include/linux/bitmap.h|   8 +
 include/soc/qcom/cmd-db.h |  42 ++
 include/soc/qcom/rpmh.h   |  29 ++
 include/soc/qcom/tcs.h|  78 
 16 files changed, 1880 insertions(+)
---
change-id: 20240611-b4-qcom-rpmh-fcfd32ac2940
base-commit: 50adc932e7aa34e6d9c738ec13ed09382a9d109a

// Caleb (they/them)



Re: [PATCH 2/3] soc: qcom: rpmh and cmd-db drivers

2024-07-08 Thread Caleb Connolly

Hi Sumit,

Sorry for the late response.

In general, I'd rather keep this port closer to the Linux original, so 
that future cherry-picking of new features and fixes is easier. This is 
quite standard practice in U-Boot (and why the compatibility macro's are 
included in the first place).


Otherwise, we end up with our own quite different implementation, with 
the higher maintenance burden that comes with it.


This port doesn't do a perfect job at keeping close to upstream, but 
still I don't think we should stray further without a good justification.


Kind regards,


+EXPORT_SYMBOL(cmd_db_read_addr);


Export symbols aren't required in U-Boot here and other instances in this patch.


...


+   /*
+* Wait until we read back the same value.  Use a counter rather than
+* ktime for timeout since this may be called after timekeeping stops.
+*/
+   for (i = 0; i < USEC_PER_SEC; i++) {
+   if (readl(addr) == data)
+   return;
+   udelay(1);
+   }


Can we rather use readx_poll_sleep_timeout() here instead?


...

+   for (i = 0; i < 5 * USEC_PER_SEC; i++) {
+   if (readl(tcs_reg_addr(drv, reg, tcs_id)) & BIT(tcs_id))
+   break;
+   udelay(1);
+   }


Can we rather use readx_poll_sleep_timeout() here instead?


...


+
+   spin_lock_irqsave(>lock, flags);


Locks aren't needed in U-Boot, can be dropped here and other places.



...


+
+   spin_lock_init(>lock);
+   init_waitqueue_head(>tcs_wait);


Similarly waitqueue should be dropped too.

-Sumit


--
// Caleb (they/them)


Re: [PATCH] dt-bindings: nvmem: convert U-Boot env to a layout

2024-07-08 Thread Rafał Miłecki

On 8.07.2024 08:32, Miquel Raynal wrote:

zaj...@gmail.com wrote on Sat,  6 Jul 2024 00:58:21 +0200:


From: Rafał Miłecki 

U-Boot environment variables can be stored in various data sources. MTD
is just one of available options. Refactor DT binding into a layout so
it can be used with UBI volumes and other NVMEM devices.

Link: https://lore.kernel.org/all/20231221173421.13737-1-zaj...@gmail.com/
Signed-off-by: Rafał Miłecki 
---
I'm sending this PATCH without Linux changes to see if this is the
right approach - for developers and (DT) maintainers to review it first.

My previous attempt (see above Link) turned out in refusal so I'm just
trying to save some time in case this one goes wrong as well.

Hopefully the included example (which I really think we should add)
explains well how I think this binding should be used with layouts.

If I get some positive feedback I'll work on V2 with actual Linux
changes.



I am still in favor of this change. I know from a binding perspective
it might be questionable; but from an OS perspective it makes total
sense to deprecated the old U-Boot env "device" driver in favor of this.


Please note that at this point I didn't decide to deprecate the old
binding (using "u-boot,env" for flash device partition). That would
require mixing "nvmem-layout" with "partitions" which I believe Rob
objected to.

My PATCH in its current form just allows reusing this binding with
"nvmem-layout"s which is needed for cases where we agreed to allow
"nvmem-layout" (UBI volumes and pure - non-MTD - NVMEM devices).

If we want to refactor this binding in MTD partitions context I hope we
can handle that at different time if we agree on some solution. I hope
and I don't think this should be a blocked for this PATCH.


[PATCH] config: Enable the config CONFIG_MMC_SPEED_MODE_SET

2024-07-08 Thread Venkatesh Yadav Abbarapu
Enable setting speed mode using mmc dev commands.
The speed mode is provided as the last argument in these commands
(ex: mmc dev 0 0 10) and is indicated using the index from enum
bus_mode in include/mmc.h. A speed mode can be set if it is enabled
from device tree or from capabilities register

Signed-off-by: Venkatesh Yadav Abbarapu 
---
 configs/amd_versal2_virt_defconfig   | 1 +
 configs/xilinx_versal_net_virt_defconfig | 1 +
 configs/xilinx_versal_virt_defconfig | 1 +
 configs/xilinx_zynq_virt_defconfig   | 2 +-
 configs/xilinx_zynqmp_virt_defconfig | 1 +
 5 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/configs/amd_versal2_virt_defconfig 
b/configs/amd_versal2_virt_defconfig
index 2d611f84cd..f8df0b53e5 100644
--- a/configs/amd_versal2_virt_defconfig
+++ b/configs/amd_versal2_virt_defconfig
@@ -59,6 +59,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_SQUASHFS=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_CMD_UBI=y
+CONFIG_MMC_SPEED_MODE_SET=y
 CONFIG_PARTITION_TYPE_GUID=y
 CONFIG_OF_BOARD=y
 CONFIG_DTB_RESELECT=y
diff --git a/configs/xilinx_versal_net_virt_defconfig 
b/configs/xilinx_versal_net_virt_defconfig
index 53ef81e64d..40a9b16b9c 100644
--- a/configs/xilinx_versal_net_virt_defconfig
+++ b/configs/xilinx_versal_net_virt_defconfig
@@ -58,6 +58,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_SQUASHFS=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_CMD_UBI=y
+CONFIG_MMC_SPEED_MODE_SET=y
 CONFIG_PARTITION_TYPE_GUID=y
 CONFIG_OF_BOARD=y
 CONFIG_DTB_RESELECT=y
diff --git a/configs/xilinx_versal_virt_defconfig 
b/configs/xilinx_versal_virt_defconfig
index 915f0b993c..dc1754f6d1 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -59,6 +59,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_SQUASHFS=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_CMD_UBI=y
+CONFIG_MMC_SPEED_MODE_SET=y
 CONFIG_PARTITION_TYPE_GUID=y
 CONFIG_OF_BOARD=y
 CONFIG_ENV_IS_NOWHERE=y
diff --git a/configs/xilinx_zynq_virt_defconfig 
b/configs/xilinx_zynq_virt_defconfig
index 9be904fd30..f8b6a3f1aa 100644
--- a/configs/xilinx_zynq_virt_defconfig
+++ b/configs/xilinx_zynq_virt_defconfig
@@ -81,6 +81,7 @@ CONFIG_CMD_MTDPARTS=y
 CONFIG_CMD_MTDPARTS_SPREAD=y
 CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y
 CONFIG_CMD_UBI=y
+CONFIG_MMC_SPEED_MODE_SET=y
 CONFIG_OF_BOARD=y
 CONFIG_OF_LIST="zynq-zc702 zynq-zc706 zynq-zc770-xm010 zynq-zc770-xm011 
zynq-zc770-xm011-x16 zynq-zc770-xm012 zynq-zc770-xm013 zynq-cc108 zynq-microzed 
zynq-minized zynq-picozed zynq-zed zynq-zturn zynq-zturn-v5 zynq-zybo 
zynq-zybo-z7 zynq-dlc20-rev1.0"
 CONFIG_ENV_IS_NOWHERE=y
@@ -155,4 +156,3 @@ CONFIG_SYS_TIMER_COUNTS_DOWN=y
 CONFIG_SPL_GZIP=y
 CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
-CONFIG_TOOLS_MKEFICAPSULE=y
diff --git a/configs/xilinx_zynqmp_virt_defconfig 
b/configs/xilinx_zynqmp_virt_defconfig
index fa912ae3bb..1133134e3f 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -101,6 +101,7 @@ CONFIG_CMD_MTDPARTS=y
 CONFIG_CMD_MTDPARTS_SPREAD=y
 CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y
 CONFIG_CMD_UBI=y
+CONFIG_MMC_SPEED_MODE_SET=y
 CONFIG_PARTITION_TYPE_GUID=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_BOARD=y
-- 
2.17.1



[PATCH] net: remove duplicate eth_env_set_enetaddr_by_index() declaration

2024-07-08 Thread A. Sverdlin
From: Alexander Sverdlin 

eth_env_set_enetaddr_by_index() declaration is duplicated in eth_internal.h
and net.h, but all units including eth_internal.h already include net.h.
Remove the superfluous declaration.

Signed-off-by: Alexander Sverdlin 
---
 net/eth_internal.h | 16 
 1 file changed, 16 deletions(-)

diff --git a/net/eth_internal.h b/net/eth_internal.h
index 0b829a8d388..cb302c157b5 100644
--- a/net/eth_internal.h
+++ b/net/eth_internal.h
@@ -11,22 +11,6 @@
 /* Do init that is common to driver model and legacy networking */
 void eth_common_init(void);
 
-/**
- * eth_env_set_enetaddr_by_index() - set the MAC address environment variable
- *
- * This sets up an environment variable with the given MAC address (@enetaddr).
- * The environment variable to be set is defined by <@base_name><@index>addr.
- * If @index is 0 it is omitted. For common Ethernet this means ethaddr,
- * eth1addr, etc.
- *
- * @base_name: Base name for variable, typically "eth"
- * @index: Index of interface being updated (>=0)
- * @enetaddr:  Pointer to MAC address to put into the variable
- * Return: 0 if OK, other value on error
- */
-int eth_env_set_enetaddr_by_index(const char *base_name, int index,
-uchar *enetaddr);
-
 int eth_mac_skip(int index);
 void eth_current_changed(void);
 void eth_set_dev(struct udevice *dev);
-- 
2.45.2



Re: [PATCH] spl: fit: List DTOs applied by SPL in U-Boot control DT

2024-07-08 Thread Quentin Schulz

Hi Marek,

On 7/7/24 2:29 AM, Marek Vasut wrote:

On 7/1/24 10:42 AM, Quentin Schulz wrote:

Hi Marek,


Hi,


Shouldn't this rather be in /config node?


This is what I had there originally, but then I realized that some 
DTs might not have the /config node in them (or am I mistaken?), so 
I moved the new properties into the root node, which surely exists.


It also keeps the code simpler, as it doesn't have to fiddle with 
creation of the /config node if it doesn't exist.




I don't think we should pollute the root node with this. If we want 
to be able to expose this in a proper binding to the upstream DT 
binding repo, I'm not sure this is going to fly :/


The other option is to add more code into SPL, that's not great.

I can check if /config node exists, and if so, add it there, 
otherwise do nothing. That should be some sort of compromise between 
bloat and config node. What do you think ?


[...]



Considering that we're trying to have the same DT for U-Boot and Linux 
kernel in the long run and that `git grep "\s+config {"` returns 
nothing in dts/upstream/src, I'm not sure this amounts to anything but 
dead-code? We could also always insert this node as pre/post process 
of the DT compilation? But I think some people want to reuse the exact 
same DTB (like, the binary itself) between U-Boot and the Linux kernel.


In my case, the /config node is inserted via *-u-boot.dtsi , I don't 
think those DT extras are going away anytime soon, esp. because of the 
'bootph-*' properties.




The bootph properties are standardized (?) now. The kernel accepts them 
(see the ti and xilinx DTSes for Aarch64 for example) and it's part of 
the dt-schema now: 
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml 
though I cannot find it in the DT specification (not sure they need to 
be there though).


I guess we can start with checking if the /config node exists and we 
can figure something smarter once we need it?


[...]


2- Add info about which DTBOs were applied to the kernel DTB?


SPL DTOs or DTOs applied from kernel fitImage ? Or a merging of those ?


DTOs that U-Boot proper applies to the kernel DTB either via fitimage 
configs, maybe also via syslinux (via 
`fdtoverlays`/`devicetree-overlay`) and the like?


Isn't that something that would be better (=more flexible and fixable if 
broken without bootloader update) done in a boot script which could be 
embedded in a fitImage ?


That's one way to do it though you risk desynchronization between the 
boot script and which overlays are applied and in which order. 
Additionally, can we actually already run a boot script from a 
configuration node? Because one can simply boot with a fit configuration 
and all of its DTBOs will be applied (if I'm not mistaken), if the boot 
script needs to be executed standalone before booting the configuration 
node, that's quite a surprising workflow (but that would work; we could 
probably also have the boot script directly call the bootm command with 
the proper configuration node, but then one would have to find a way on 
how to select which boot script to use between each representing their 
own configuration node?).


Cheers,
Quentin


Re: [PATCH] Revert "zlib: Port fix for CVE-2016-9841 to U-Boot"

2024-07-08 Thread Michal Simek




On 6/27/24 17:49, Tom Rini wrote:

In commit 340fdf1303dc ("zlib: Port fix for CVE-2016-9841 to U-Boot")
Michal brings in (correctly) the upstream fix for CVE-2016-9841.
However, when upstream was fixing this issue they also removed a
necessary optimization for some CPU classes as part of simplifying the
code. This in turn leads to boot failures on the platforms as they now
take too long to decompress images and so the watchdog sees the system
as stuck.

The long term fix here is as Christophe has posted, which is to restore
the optimization. Given the nearness of the release, what I do here is
very similar, result wise, but less so, code wise. This is a revert of
Michal's commit _except_ we only allow for post-increment in the code,
thus keeping the CVE resolved. For the next release this commit shall be
reverted and then Christophe's patch applied.


Sorry I was out and sorry for problems. Good to see this patch.
I pretty much think that long term goal should be to use upstream zlib
and sync it up regularly.

Thanks,
Michal



[PATCH v2 3/3] mtd: rawnand: meson: read/write access for boot ROM pages

2024-07-08 Thread Arseniy Krasnov
Boot ROM on Meson needs some pages to be read/written in a special mode:
384 byte ECC mode (so called "short" by Amlogic) and with scrambling
enabled. Such pages are located on the chip in the following way (for
example):

[ p0 ][ p1 ][ p2 ][ p3 ][ p4 ][ p5 ][ p6 ][ p7 ] ... [ pN ]
  ^   ^   ^   ^

pX is page number "X". "^" means "special" page used by boot ROM - e.g.
every 2nd page in the range of [0, 7]. Step (2 here) and last page in
range is read from the device tree.

Signed-off-by: Arseniy Krasnov 
---
 drivers/mtd/nand/raw/meson_nand.c | 56 +--
 1 file changed, 46 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/raw/meson_nand.c 
b/drivers/mtd/nand/raw/meson_nand.c
index 19f005202b..54ea035d8d 100644
--- a/drivers/mtd/nand/raw/meson_nand.c
+++ b/drivers/mtd/nand/raw/meson_nand.c
@@ -40,6 +40,7 @@
 #define NFC_CMD_RB BIT(20)
 #define NFC_CMD_SCRAMBLER_ENABLE   BIT(19)
 #define NFC_CMD_SCRAMBLER_DISABLE  0
+#define NFC_CMD_SHORTMODE_ENABLE   1
 #define NFC_CMD_SHORTMODE_DISABLE  0
 #define NFC_CMD_RB_INT BIT(14)
 #define NFC_CMD_RB_INT_NO_PIN  ((0xb << 10) | BIT(18) | BIT(16))
@@ -78,6 +79,8 @@
 
 #define DMA_DIR(dir)   ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N)
 
+#define NFC_SHORT_MODE_ECC_SZ  384
+
 #define ECC_CHECK_RETURN_FF-1
 
 #define NAND_CE0   (0xe << 10)
@@ -141,6 +144,8 @@
 struct meson_nfc_nand_chip {
struct list_head node;
struct nand_chip nand;
+   u32 boot_pages;
+   u32 boot_page_step;
 
u32 bch_mode;
u8 *data_buf;
@@ -229,33 +234,46 @@ static void meson_nfc_cmd_seed(const struct meson_nfc 
*nfc, u32 seed)
   nfc->reg_base + NFC_REG_CMD);
 }
 
+static int meson_nfc_is_boot_page(struct nand_chip *nand, int page)
+{
+   const struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
+
+   return (nand->options & NAND_IS_BOOT_MEDIUM) &&
+  !(page % meson_chip->boot_page_step) &&
+  (page < meson_chip->boot_pages);
+}
+
 static void meson_nfc_cmd_access(struct nand_chip *nand, bool raw, bool dir, 
int page)
 {
+   const struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
struct mtd_info *mtd = nand_to_mtd(nand);
const struct meson_nfc *nfc = 
nand_get_controller_data(mtd_to_nand(mtd));
-   const struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
-   u32 bch = meson_chip->bch_mode, cmd;
int len = mtd->writesize, pagesize, pages;
int scrambler;
+   u32 cmd;
 
if (nand->options & NAND_NEED_SCRAMBLING)
scrambler = NFC_CMD_SCRAMBLER_ENABLE;
else
scrambler = NFC_CMD_SCRAMBLER_DISABLE;
 
-   pagesize = nand->ecc.size;
-
if (raw) {
len = mtd->writesize + mtd->oobsize;
cmd = len | scrambler | DMA_DIR(dir);
-   writel(cmd, nfc->reg_base + NFC_REG_CMD);
-   return;
-   }
+   } else if (meson_nfc_is_boot_page(nand, page)) {
+   pagesize = NFC_SHORT_MODE_ECC_SZ >> 3;
+   pages = mtd->writesize / 512;
 
-   pages = len / nand->ecc.size;
+   scrambler = NFC_CMD_SCRAMBLER_ENABLE;
+   cmd = CMDRWGEN(DMA_DIR(dir), scrambler, NFC_ECC_BCH8_1K,
+  NFC_CMD_SHORTMODE_ENABLE, pagesize, pages);
+   } else {
+   pagesize = nand->ecc.size >> 3;
+   pages = len / nand->ecc.size;
 
-   cmd = CMDRWGEN(DMA_DIR(dir), scrambler, bch,
-  NFC_CMD_SHORTMODE_DISABLE, pagesize, pages);
+   cmd = CMDRWGEN(DMA_DIR(dir), scrambler, meson_chip->bch_mode,
+  NFC_CMD_SHORTMODE_DISABLE, pagesize, pages);
+   }
 
if (scrambler == NFC_CMD_SCRAMBLER_ENABLE)
meson_nfc_cmd_seed(nfc, page);
@@ -1132,6 +1150,24 @@ static int meson_nfc_nand_chip_init(struct udevice *dev, 
struct meson_nfc *nfc,
goto err_chip_buf_free;
}
 
+   if (nand->options & NAND_IS_BOOT_MEDIUM) {
+   ret = ofnode_read_u32(node, "amlogic,boot-pages",
+ _chip->boot_pages);
+   if (ret) {
+   dev_err(dev, "could not retrieve 'amlogic,boot-pages' 
property: %d",
+   ret);
+   goto err_chip_buf_free;
+   }
+
+   ret = ofnode_read_u32(node, "amlogic,boot-page-step",
+ _chip->boot_page_step);
+   if (ret) {
+   dev_err(dev, "could not retrieve 
'amlogic,boot-page-step' property: %d",
+   ret);
+   goto err_chip_buf_free;
+   }
+   }
+
ret = nand_register(0, mtd);
if (ret) {
dev_err(dev, "'nand_register()' failed: %d\n", ret);

[PATCH v2 2/3] mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'

2024-07-08 Thread Arseniy Krasnov
Move call 'meson_nfc_cmd_seed()' and check for 'NAND_NEED_SCRAMBLING'
to 'meson_nfc_cmd_access()', thus removing code duplication.

Signed-off-by: Arseniy Krasnov 
---
 drivers/mtd/nand/raw/meson_nand.c | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/nand/raw/meson_nand.c 
b/drivers/mtd/nand/raw/meson_nand.c
index 5d411c4594..19f005202b 100644
--- a/drivers/mtd/nand/raw/meson_nand.c
+++ b/drivers/mtd/nand/raw/meson_nand.c
@@ -229,14 +229,19 @@ static void meson_nfc_cmd_seed(const struct meson_nfc 
*nfc, u32 seed)
   nfc->reg_base + NFC_REG_CMD);
 }
 
-static void meson_nfc_cmd_access(struct nand_chip *nand, bool raw, bool dir,
-int scrambler)
+static void meson_nfc_cmd_access(struct nand_chip *nand, bool raw, bool dir, 
int page)
 {
struct mtd_info *mtd = nand_to_mtd(nand);
const struct meson_nfc *nfc = 
nand_get_controller_data(mtd_to_nand(mtd));
const struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
u32 bch = meson_chip->bch_mode, cmd;
int len = mtd->writesize, pagesize, pages;
+   int scrambler;
+
+   if (nand->options & NAND_NEED_SCRAMBLING)
+   scrambler = NFC_CMD_SCRAMBLER_ENABLE;
+   else
+   scrambler = NFC_CMD_SCRAMBLER_DISABLE;
 
pagesize = nand->ecc.size;
 
@@ -252,6 +257,9 @@ static void meson_nfc_cmd_access(struct nand_chip *nand, 
bool raw, bool dir,
cmd = CMDRWGEN(DMA_DIR(dir), scrambler, bch,
   NFC_CMD_SHORTMODE_DISABLE, pagesize, pages);
 
+   if (scrambler == NFC_CMD_SCRAMBLER_ENABLE)
+   meson_nfc_cmd_seed(nfc, page);
+
writel(cmd, nfc->reg_base + NFC_REG_CMD);
 }
 
@@ -566,14 +574,7 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
return ret;
}
 
-   if (nand->options & NAND_NEED_SCRAMBLING) {
-   meson_nfc_cmd_seed(nfc, page);
-   meson_nfc_cmd_access(nand, raw, DIRWRITE,
-NFC_CMD_SCRAMBLER_ENABLE);
-   } else {
-   meson_nfc_cmd_access(nand, raw, DIRWRITE,
-NFC_CMD_SCRAMBLER_DISABLE);
-   }
+   meson_nfc_cmd_access(nand, raw, DIRWRITE, page);
 
cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_PAGEPROG;
writel(cmd, nfc->reg_base + NFC_REG_CMD);
@@ -644,14 +645,7 @@ static int meson_nfc_read_page_sub(struct nand_chip *nand,
if (ret)
return ret;
 
-   if (nand->options & NAND_NEED_SCRAMBLING) {
-   meson_nfc_cmd_seed(nfc, page);
-   meson_nfc_cmd_access(nand, raw, DIRREAD,
-NFC_CMD_SCRAMBLER_ENABLE);
-   } else {
-   meson_nfc_cmd_access(nand, raw, DIRREAD,
-NFC_CMD_SCRAMBLER_DISABLE);
-   }
+   meson_nfc_cmd_access(nand, raw, DIRREAD, page);
 
meson_nfc_wait_dma_finish(nfc);
meson_nfc_check_ecc_pages_valid(nfc, nand, raw);
-- 
2.30.1



[PATCH v2 1/3] mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag

2024-07-08 Thread Arseniy Krasnov
Based on Linux kernel:
commit f922bd798bb9 ("mtd: rawnand: add an option to specify NAND chip as a 
boot device")

Allow to define a NAND chip as a boot device. This can be helpful
for the selection of the ECC algorithm and strength in case the boot
ROM supports only a subset of controller provided options.

Signed-off-by: Arseniy Krasnov 
---
 Changelog: 
 v1 -> v2:  
  * Place 'NAND_IS_BOOT_MEDIUM' according its numerical value.

 drivers/mtd/nand/raw/nand_base.c | 3 +++
 include/linux/mtd/rawnand.h  | 5 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index c40a0f23d7..ed605b4af5 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4458,6 +4458,9 @@ static int nand_dt_init(struct mtd_info *mtd, struct 
nand_chip *chip, ofnode nod
if (ret == 16)
chip->options |= NAND_BUSWIDTH_16;
 
+   if (ofnode_read_bool(node, "nand-is-boot-medium"))
+   chip->options |= NAND_IS_BOOT_MEDIUM;
+
if (ofnode_read_bool(node, "nand-on-flash-bbt"))
chip->bbt_options |= NAND_BBT_USE_FLASH;
 
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index fb002ae641..61690e816f 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -248,6 +248,11 @@ enum nand_ecc_algo {
  * kmap'ed, vmalloc'ed highmem buffers being passed from upper layers
  */
 #define NAND_USE_BOUNCE_BUFFER 0x0010
+/*
+ * Whether the NAND chip is a boot medium. Drivers might use this information
+ * to select ECC algorithms supported by the boot ROM or similar restrictions.
+ */
+#define NAND_IS_BOOT_MEDIUM0x0040
 
 /* Options set by nand scan */
 /* bbt has already been read */
-- 
2.30.1



[PATCH v2 0/3] Meson: R/W support for pages used by boot ROM

2024-07-08 Thread Arseniy Krasnov
Patchset is based on patchset for Linux (today merged to nand-next):
https://lore.kernel.org/linux-mtd/20240507230903.3399594-1-avkras...@salutedevices.com/

Here is description from it:

 >  Amlogic's boot ROM code needs that some pages on NAND must be written
 >  in special "short" ECC mode with scrambling enabled. Such pages:
 >  1) Contain some metadata about hardware.
 >  2) Located with some interval starting from 0 offset, until some
 > specified offset. Interval and second offset are set in the
 > device tree.
 >  
 >  This patchset adds R/W support for such pages. To enable it we can setup
 >  it in dts:
 >  
 >  nand-is-boot-medium;
 >  amlogic,boot-pages = <1024>;
 >  amlogic,boot-page-step = <128>;
 >  
 >  It means that each 128th page in range 0 to 1024 pages will be accessed
 >  in special mode ("short" ECC + scrambling). In practice this feature is
 >  needed when we want to update first block of NAND - driver will enable
 >  required mode by itself using value from device tree.

The only difference is that patchset for Linux updates DT bindings, while
this adds NAND_IS_BOOT_MEDIUM flag support.

Changelog:
 v1 -> v2:
 * Pls see per-patch changelog.

Arseniy Krasnov (3):
  mtd: rawnand: nand_base: support for 'NAND_IS_BOOT_MEDIUM' flag
  mtd: rawnand: meson: refactor use of 'meson_nfc_cmd_access()'
  mtd: rawnand: meson: read/write access for boot ROM pages

 drivers/mtd/nand/raw/meson_nand.c | 84 +--
 drivers/mtd/nand/raw/nand_base.c  |  3 ++
 include/linux/mtd/rawnand.h   |  5 ++
 3 files changed, 65 insertions(+), 27 deletions(-)

-- 
2.30.1



Re: [PATCH 2/3] rockchip: fix wrong PCI range address in rk3568 dtsi

2024-07-08 Thread Etienne Dublé




Le 25/06/2024 à 13:31, Etienne Dublé a écrit :

The bus addresses should be isolated to each pci controller if I am not
mistaken, so changing the bus address was probably just done as a
workaround because of some other unknown bug.


OK.


Hum, could be an issue in pci core of U-Boot that expect unique bus
addresses across all pci controllers.

Will run some quick tests on my R5C later.


OK, thanks for looking at it.



Hello Jonas,

Could you have a look at this issue with the 2nd interface on the nanopi 
r5c, and your idea about a possible issue in U-Boot core about 
non-unique PCI bus addresses?


Thanks,
Etienne


--
Etienne Dublé
CNRS / LIG - Bâtiment IMAG
700 avenue Centrale - 38401 St Martin d'Hères
Bureau 426 - Tel 0457421431



Re: [PATCH] zlib: Fix big performance regression

2024-07-08 Thread Christophe Leroy




Le 05/07/2024 à 17:47, Tom Rini a écrit :

On Sun, Jun 30, 2024 at 08:49:08PM +0200, Christophe Leroy wrote:



Le 30/06/2024 à 20:28, Christophe Leroy a écrit :



Le 30/06/2024 à 16:54, Tom Rini a écrit :

On Sun, Jun 30, 2024 at 10:47:06AM +0200, Christophe Leroy wrote:



Le 27/06/2024 à 21:40, Tom Rini a écrit :

On Thu, Jun 27, 2024 at 01:34:55PM -0600, Tom Rini wrote:

On Thu, Jun 27, 2024 at 10:25:21AM +0200, Christophe Leroy wrote:


Commit 340fdf1303dc ("zlib: Port fix for CVE-2016-9841 to U-Boot")
brings a big performance regression in inflate_fast(), which leads
to watchdog timer reset on powerpc 8xx.

It looks like that commit does more than what it describe, it
especially removed an important optimisation that was doing copies
using halfwords instead of bytes. That unexpected change multiplied
by almost 4 the time spent in inflate_fast() and increased by 40%
the overall time needed to uncompress linux kernel image.

So partially revert that commit but keep post incrementation as it
is the initial purpose of said commit.

Fixes: 340fdf1303dc ("zlib: Port fix for CVE-2016-9841 to U-Boot")
Signed-off-by: Christophe Leroy 
---
    lib/zlib/inffast.c | 51
--
    1 file changed, 40 insertions(+), 11 deletions(-)


Both this, and my mostly revert lead to CI failures around compression
tests:
https://source.denx.de/u-boot/u-boot/-/jobs/859329


A full revert however, is fine.



Is it that ? :

FAILED
test/py/tests/test_ut.py::test_ut[ut_compression_compression_test_gzip]

It seems like when the optimisation was added by commit
cd514aeb996e ("zlib:
Optimize decompression"), only the pre-increment implementation was
available.

When POSTINC was added by commit e89516f031db ("zlib: split up to match
original source tree"), I guess it was not verified because POSTINC is
#undef by zlib.h.

With the following change I don't get the FAILED
ut_compression_compression_test_gzip CI anymore
(https://source.denx.de/u-boot/custodians/u-boot-mpc8xx/-/jobs/859937)

diff --git a/lib/zlib/inffast.c b/lib/zlib/inffast.c
index c271d85ea1..5dc0574202 100644
--- a/lib/zlib/inffast.c
+++ b/lib/zlib/inffast.c
@@ -257,7 +257,7 @@ void inflate_fast(z_streamp strm, unsigned start)
  sfrom = (unsigned short *)(from - OFF);
  loops = len >> 1;
  do
-   PUP(sout) = get_unaligned(++sfrom);
+   PUP(sout) = get_unaligned(sfrom++);
  while (--loops);
  out = (unsigned char *)sout + OFF;
  from = (unsigned char *)sfrom + OFF;


Ah, thanks! Testing again now.



That's probably not enough. I thought other failures were unrelated but
I gave it a try with a full revert and I get no failure at all with that
so there must be other things.

I find that pat16 = *(sout-2+2*OFF) suspicious, sout being a short it
means -4 bytes which is not what is expected I think.


That's it. I get all green with the following, see
https://source.denx.de/u-boot/custodians/u-boot-mpc8xx/-/pipelines/21391

diff --git a/lib/zlib/inffast.c b/lib/zlib/inffast.c
index c271d85ea1..69268caee8 100644
--- a/lib/zlib/inffast.c
+++ b/lib/zlib/inffast.c
@@ -257,14 +257,14 @@ void inflate_fast(z_streamp strm, unsigned start)
sfrom = (unsigned short *)(from - OFF);
loops = len >> 1;
do
-   PUP(sout) = get_unaligned(++sfrom);
+   PUP(sout) = get_unaligned(sfrom++);
while (--loops);
out = (unsigned char *)sout + OFF;
from = (unsigned char *)sfrom + OFF;
} else { /* dist == 1 or dist == 2 */
unsigned short pat16;

-   pat16 = *(sout-2+2*OFF);
+   pat16 = *(sout-1+OFF);
if (dist == 1)
  #if defined(__BIG_ENDIAN)
pat16 = (pat16 & 0xff) | ((pat16 & 0xff ) << 8);


Now that the release is out, can you please do a new patch to
re-introduce the optimization required on your platform? A revert of
"bbacdd3ef7762fbdeab43ceea5205d1fd0f25bbd" is required first (and
separate) and I'll push that shortly. If you don't have time currently,
I can try and v2 your original patch with these changes included, thanks!



I will try to send something tomorrow.


Re: [PATCH] dt-bindings: nvmem: convert U-Boot env to a layout

2024-07-08 Thread Miquel Raynal
Hi Rafał,

zaj...@gmail.com wrote on Sat,  6 Jul 2024 00:58:21 +0200:

> From: Rafał Miłecki 
> 
> U-Boot environment variables can be stored in various data sources. MTD
> is just one of available options. Refactor DT binding into a layout so
> it can be used with UBI volumes and other NVMEM devices.
> 
> Link: https://lore.kernel.org/all/20231221173421.13737-1-zaj...@gmail.com/
> Signed-off-by: Rafał Miłecki 
> ---
> I'm sending this PATCH without Linux changes to see if this is the
> right approach - for developers and (DT) maintainers to review it first.
> 
> My previous attempt (see above Link) turned out in refusal so I'm just
> trying to save some time in case this one goes wrong as well.
> 
> Hopefully the included example (which I really think we should add)
> explains well how I think this binding should be used with layouts.
> 
> If I get some positive feedback I'll work on V2 with actual Linux
> changes.
> 

I am still in favor of this change. I know from a binding perspective
it might be questionable; but from an OS perspective it makes total
sense to deprecated the old U-Boot env "device" driver in favor of this.

Thanks,
Miquèl


Re: Missing eth1addr for Banana Pi BPI-R3

2024-07-08 Thread Leith Bade
Hi Daniel,

> When using OpenWrt, we are dealing with this differently:
> The random address generated by Linux is made persistent on first boot
> for both ethernet devices:
>
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/base-files/etc/uci-defaults/99_fwenv-store-ethaddr.sh;h=e9cb4f921d9aedd82550d0cc8935687135ec83a3;hb=HEAD
>
> And eventhough U-Boot at this point knows nothing about there being more
> than one Ethernet MAC it still sets the address stored in eth1addr for
> the Ethernet MAC pointed to by the 'ethernet1' alias.
>
> However, to let U-Boot do that for you, we would need to change the
> Ethernet driver in U-Boot to expose all MACs rather than just one of
> them.

That is an interesting workaround, I will try it out.

In the meantime I managed to configure systemd-networkd to assign a
permanent MAC address.

It is unfortunate that these boards don't come with preallocated MAC
addresses which would remove the need for random ones.

Thanks,
Leith Bade


[PATCH 6/6] configs: phycore_am64x_a53_defconfig: Enable SOM detection

2024-07-08 Thread Daniel Schultz
Enable SOM detection for the phyCORE-AM64x and also set
CONFIG_CMD_EXTENSION as requirement for this feature.

Signed-off-by: Daniel Schultz 
---
 configs/phycore_am64x_a53_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/phycore_am64x_a53_defconfig 
b/configs/phycore_am64x_a53_defconfig
index fe09f79796d..c4145e9c10c 100644
--- a/configs/phycore_am64x_a53_defconfig
+++ b/configs/phycore_am64x_a53_defconfig
@@ -10,6 +10,7 @@ CONFIG_NR_DRAM_BANKS=2
 CONFIG_SOC_K3_AM642=y
 CONFIG_K3_ATF_LOAD_ADDR=0x701c
 CONFIG_TARGET_PHYCORE_AM64X_A53=y
+CONFIG_PHYTEC_SOM_DETECTION=y
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048
 CONFIG_ENV_SIZE=0x2
@@ -63,6 +64,7 @@ CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
 CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_EXTENSION=y
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_DFU=y
 CONFIG_CMD_GPT=y
-- 
2.25.1



[PATCH 5/6] configs: phytec_am62x_a53_defconfig: Set CONFIG_CMD_EXTENSION

2024-07-08 Thread Daniel Schultz
CONFIG_CMD_EXTENSION is required to load SOM detection overlays.

Signed-off-by: Daniel Schultz 
---
 configs/phycore_am62x_a53_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/phycore_am62x_a53_defconfig 
b/configs/phycore_am62x_a53_defconfig
index 06b8834e074..ec75b1a424d 100644
--- a/configs/phycore_am62x_a53_defconfig
+++ b/configs/phycore_am62x_a53_defconfig
@@ -63,6 +63,7 @@ CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
 CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_EXTENSION=y
 CONFIG_CMD_DFU=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
-- 
2.25.1



[PATCH 4/6] board: phytec: common: Kconfig: Enable SUPPORT_EXTENSION_SCAN

2024-07-08 Thread Daniel Schultz
Enable SUPPORT_EXTENSION_SCAN for the phyCORE-AM62x and -AM64x
boards.

Signed-off-by: Daniel Schultz 
---
 board/phytec/common/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/phytec/common/Kconfig b/board/phytec/common/Kconfig
index f394ace786a..120f58b6ec6 100644
--- a/board/phytec/common/Kconfig
+++ b/board/phytec/common/Kconfig
@@ -24,6 +24,7 @@ config PHYTEC_AM62_SOM_DETECTION
depends on (TARGET_PHYCORE_AM62X_A53 || TARGET_PHYCORE_AM62X_R5) && \
   PHYTEC_SOM_DETECTION
select PHYTEC_SOM_DETECTION_BLOCKS
+   select SUPPORT_EXTENSION_SCAN
depends on SPL_I2C && DM_I2C
default y
help
@@ -35,6 +36,7 @@ config PHYTEC_AM64_SOM_DETECTION
depends on (TARGET_PHYCORE_AM64X_A53 || TARGET_PHYCORE_AM64X_R5) && \
   PHYTEC_SOM_DETECTION
select PHYTEC_SOM_DETECTION_BLOCKS
+   select SUPPORT_EXTENSION_SCAN
depends on SPL_I2C && DM_I2C
default y
help
-- 
2.25.1



[PATCH 3/6] board: phytec: common: k3: Add SOM detection overlays

2024-07-08 Thread Daniel Schultz
Add overlays to disable or alter SOM features according
to the EEPROM image content.

Signed-off-by: Daniel Schultz 
---
 board/phytec/common/k3/board.c | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/board/phytec/common/k3/board.c b/board/phytec/common/k3/board.c
index 3d7e090ccaa..867dd880675 100644
--- a/board/phytec/common/k3/board.c
+++ b/board/phytec/common/k3/board.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../am6_som_detection.h"
 
@@ -104,3 +105,47 @@ int ft_board_setup(void *blob, struct bd_info *bd)
return 0;
 }
 #endif
+
+#if IS_ENABLED(CONFIG_CMD_EXTENSION)
+int extension_board_scan(struct list_head *extension_list)
+{
+   struct extension *extension = NULL;
+   struct phytec_eeprom_data data;
+   int count = 0;
+   int ret;
+
+   ret = phytec_eeprom_data_setup(, 0, EEPROM_ADDR);
+   if (ret)
+   return count;
+
+   if (phytec_get_am6_eth() == 0) {
+   extension = phytec_add_extension("Disable Ethernet phy",
+
"k3-am6xx-phycore-disable-eth-phy.dtbo", "");
+   list_add_tail(>list, extension_list);
+   count++;
+   }
+
+   if (phytec_get_am6_spi() == PHYTEC_EEPROM_VALUE_X) {
+   extension = phytec_add_extension("Disable SPI NOR Flash",
+
"k3-am6xx-phycore-disable-spi-nor.dtbo", "");
+   list_add_tail(>list, extension_list);
+   count++;
+   }
+
+   if (phytec_am6_is_qspi()) {
+   extension = phytec_add_extension("Select QSPI NOR Flash",
+
"k3-am6xx-phycore-qspi-nor.dtbo", "");
+   list_add_tail(>list, extension_list);
+   count++;
+   }
+
+   if (phytec_get_am6_rtc() == 0) {
+   extension = phytec_add_extension("Disable RTC",
+
"k3-am6xx-phycore-disable-rtc.dtbo", "");
+   list_add_tail(>list, extension_list);
+   count++;
+   }
+
+   return count;
+}
+#endif
-- 
2.25.1



[PATCH 2/6] include: env: phytec: k3_mmc: Apply extension overlays

2024-07-08 Thread Daniel Schultz
Run the mmc_apply_extensions routine to apply overlays
added by the extension framework.

Signed-off-by: Daniel Schultz 
---
 include/env/phytec/k3_mmc.env | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/env/phytec/k3_mmc.env b/include/env/phytec/k3_mmc.env
index 3d3595ceb7e..3c0b1359dda 100644
--- a/include/env/phytec/k3_mmc.env
+++ b/include/env/phytec/k3_mmc.env
@@ -18,4 +18,5 @@ mmcboot=run mmcargs;
run loadimage;
run loadfdt;
run mmc_apply_overlays;
+   run mmc_apply_extensions;
booti ${loadaddr} - ${fdt_addr_r}
-- 
2.25.1



[PATCH 1/6] include: env: phytec: overlays: Add extension command

2024-07-08 Thread Daniel Schultz
Add a new environment routine to apply extensions. Our SOM detection
adds overlays via the extension framework to alter the kernel
device-tree according to the flashed EEPROM image.

Signed-off-by: Daniel Schultz 
---
 include/env/phytec/overlays.env | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/env/phytec/overlays.env b/include/env/phytec/overlays.env
index 78721cde654..50110e731bd 100644
--- a/include/env/phytec/overlays.env
+++ b/include/env/phytec/overlays.env
@@ -23,6 +23,16 @@ mmc_apply_overlays=
fi;
done;
fi;
+#ifdef CONFIG_CMD_EXTENSION
+mmc_apply_extensions=
+   setenv extension_overlay_addr ${fdtoverlay_addr_r};
+   setenv extension_overlay_cmd 'load mmc ${mmcdev}:${mmcpart}
+ ${fdtoverlay_addr_r} ${extension_overlay_name}';
+   extension scan;
+   extension apply all;
+#else
+mmc_apply_extensions=echo "no extension command"
+#endif
 net_load_bootenv=${get_cmd} ${bootenv_addr_r} ${bootenv}
 net_load_overlay=${get_cmd} ${fdtoverlay_addr_r} ${overlay}
 net_apply_overlays=
@@ -36,3 +46,13 @@ net_apply_overlays=
fi;
done;
fi;
+#ifdef CONFIG_CMD_EXTENSION
+net_apply_extensions=
+   setenv extension_overlay_addr ${fdtoverlay_addr_r};
+   setenv extension_overlay_cmd '${get_cmd} ${fdtoverlay_addr_r}
+${extension_overlay_name}';
+   extension scan;
+   extension apply all;
+#else
+net_apply_extensions=echo "no extension command"
+#endif
-- 
2.25.1



[PATCH 0/6] Extend SOM detection

2024-07-08 Thread Daniel Schultz
This patchset extends PHYTEC's SOM detection for the
K3 platforms.

It adds generic support to apply overlays via the
extension framework inside the overlays.env file. Additionally,
the K3 mmc boot environment applies these overlays now.

It also adds the 'extension_board_scan' hook to the K3 board
code and adds all missing configs in the phyCORE-AM62x and
-AM64x A53 defconfigs.

Daniel Schultz (6):
  include: env: phytec: overlays: Add extension command
  include: env: phytec: k3_mmc: Apply extension overlays
  board: phytec: common: k3: Add SOM detection overlays
  board: phytec: common: Kconfig: Enable SUPPORT_EXTENSION_SCAN
  configs: phytec_am62x_a53_defconfig: Set CONFIG_CMD_EXTENSION
  configs: phycore_am64x_a53_defconfig: Enable SOM detection

 board/phytec/common/Kconfig |  2 ++
 board/phytec/common/k3/board.c  | 45 +
 configs/phycore_am62x_a53_defconfig |  1 +
 configs/phycore_am64x_a53_defconfig |  2 ++
 include/env/phytec/k3_mmc.env   |  1 +
 include/env/phytec/overlays.env | 20 +
 6 files changed, 71 insertions(+)

-- 
2.25.1