[PATCH] MAINTAINERS: Update ARM TI entry
Move TI maintainership to Tom. Updated with the following commands: find ./ -name MAINTAINERS | xargs sed -i s/"Lokesh Vutla "/"Tom Rini "/g Signed-off-by: Lokesh Vutla --- MAINTAINERS| 2 +- board/davinci/da8xxevm/MAINTAINERS | 2 +- board/ti/am43xx/MAINTAINERS| 2 +- board/ti/am57xx/MAINTAINERS| 2 +- board/ti/am64x/MAINTAINERS | 2 +- board/ti/am65x/MAINTAINERS | 2 +- board/ti/dra7xx/MAINTAINERS| 2 +- board/ti/j721e/MAINTAINERS | 2 +- board/ti/omap5_uevm/MAINTAINERS| 2 +- board/ti/panda/MAINTAINERS | 2 +- board/ti/sdp4430/MAINTAINERS | 2 +- doc/git-mailrc | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4cf0c33c5d..40a0e7ac72 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -490,7 +490,7 @@ F: arch/arm/mach-tegra/ F: arch/arm/include/asm/arch-tegra*/ ARM TI -M: Lokesh Vutla +M: Tom Rini S: Maintained T: git https://source.denx.de/u-boot/custodians/u-boot-ti.git F: arch/arm/mach-davinci/ diff --git a/board/davinci/da8xxevm/MAINTAINERS b/board/davinci/da8xxevm/MAINTAINERS index 16f1032661..993b22f2f6 100644 --- a/board/davinci/da8xxevm/MAINTAINERS +++ b/board/davinci/da8xxevm/MAINTAINERS @@ -8,7 +8,7 @@ F: configs/da850evm_nand_defconfig F: configs/da850evm_direct_nor_defconfig OMAPL138_LCDK BOARD -M: Lokesh Vutla +M: Tom Rini S: Maintained F: include/configs/omap1l38_lcdk.h F: configs/omapl138_lcdk_defconfig diff --git a/board/ti/am43xx/MAINTAINERS b/board/ti/am43xx/MAINTAINERS index ab9da22c64..5478dd7104 100644 --- a/board/ti/am43xx/MAINTAINERS +++ b/board/ti/am43xx/MAINTAINERS @@ -1,5 +1,5 @@ AM43XX BOARD -M: Lokesh Vutla +M: Tom Rini S: Maintained F: board/ti/am43xx/ F: include/configs/am43xx_evm.h diff --git a/board/ti/am57xx/MAINTAINERS b/board/ti/am57xx/MAINTAINERS index 47b694eb4b..a6f4f168fc 100644 --- a/board/ti/am57xx/MAINTAINERS +++ b/board/ti/am57xx/MAINTAINERS @@ -1,5 +1,5 @@ AM57XX EVM -M: Lokesh Vutla +M: Tom Rini S: Maintained F: board/ti/am57xx/ F: include/configs/am57xx_evm.h diff --git a/board/ti/am64x/MAINTAINERS b/board/ti/am64x/MAINTAINERS index d384a330df..eaca2b865f 100644 --- a/board/ti/am64x/MAINTAINERS +++ b/board/ti/am64x/MAINTAINERS @@ -1,6 +1,6 @@ AM64x BOARD M: Dave Gerlach -M: Lokesh Vutla +M: Tom Rini S: Maintained F: board/ti/am64x/ F: include/configs/am64x_evm.h diff --git a/board/ti/am65x/MAINTAINERS b/board/ti/am65x/MAINTAINERS index 6da4182d9f..c52f7c9112 100644 --- a/board/ti/am65x/MAINTAINERS +++ b/board/ti/am65x/MAINTAINERS @@ -1,5 +1,5 @@ AM65x BOARD -M: Lokesh Vutla +M: Tom Rini S: Maintained F: board/ti/am65x/ F: include/configs/am65x_evm.h diff --git a/board/ti/dra7xx/MAINTAINERS b/board/ti/dra7xx/MAINTAINERS index 46b6e82b36..ba3d06dab9 100644 --- a/board/ti/dra7xx/MAINTAINERS +++ b/board/ti/dra7xx/MAINTAINERS @@ -1,5 +1,5 @@ DRA7XX BOARD -M: Lokesh Vutla +M: Tom Rini S: Maintained F: board/ti/dra7xx/ F: include/configs/dra7xx_evm.h diff --git a/board/ti/j721e/MAINTAINERS b/board/ti/j721e/MAINTAINERS index 4b13f46ddc..f5ca7d06a3 100644 --- a/board/ti/j721e/MAINTAINERS +++ b/board/ti/j721e/MAINTAINERS @@ -1,5 +1,5 @@ J721E BOARD -M: Lokesh Vutla +M: Tom Rini S: Maintained F: board/ti/j721e F: include/configs/j721e_evm.h diff --git a/board/ti/omap5_uevm/MAINTAINERS b/board/ti/omap5_uevm/MAINTAINERS index 280ea2f91f..ce544828f8 100644 --- a/board/ti/omap5_uevm/MAINTAINERS +++ b/board/ti/omap5_uevm/MAINTAINERS @@ -1,5 +1,5 @@ OMAP5_UEVM BOARD -M: Lokesh Vutla +M: Tom Rini S: Maintained F: board/ti/omap5_uevm/ F: include/configs/omap5_uevm.h diff --git a/board/ti/panda/MAINTAINERS b/board/ti/panda/MAINTAINERS index 2142368271..8b8cf7daf6 100644 --- a/board/ti/panda/MAINTAINERS +++ b/board/ti/panda/MAINTAINERS @@ -1,5 +1,5 @@ PANDA BOARD -M: Lokesh Vutla +M: Tom Rini S: Maintained F: board/ti/panda/ F: include/configs/omap4_panda.h diff --git a/board/ti/sdp4430/MAINTAINERS b/board/ti/sdp4430/MAINTAINERS index ac4d0ccc19..d8b8fe600e 100644 --- a/board/ti/sdp4430/MAINTAINERS +++ b/board/ti/sdp4430/MAINTAINERS @@ -1,5 +1,5 @@ SDP4430 BOARD -M: Lokesh Vutla +M: Tom Rini S: Maintained F: board/ti/sdp4430/ F: include/configs/omap4_sdp4430.h diff --git a/doc/git-mailrc b/doc/git-mailrc index 001681c899..410be387be 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -74,7 +74,7 @@ alias socfpgauboot, marex, dinh, simongoldschmidt, tienfong alias sunxi uboot, jagan, apritzel alias tegra uboot, sjg, Tom Warren , Stephen Warren alias tegra2 tegra -alias ti uboot, lokeshvutla +alias ti uboot, trini alias
Re: [PATCH] ARM: dts: Fix node status to "okay" on TI boards
Hi Roger,
On 20/08/21 4:11 pm, Roger Quadros wrote:
> As per Device Tree core schema [1], status parameter of nodes can be either
> "okay" or "disabled".
>
> U-boot Driver Model does not recognize status="ok" and treats
> the node as disabled.
>
Is Kernel DTS updated? The idea is to not deviate from Kernel dts as much as
possible.
Thanks and regards,
Lokesh
> Signed-off-by: Roger Quadros
> ---
> arch/arm/dts/am3517-evm-ui.dtsi | 4 ++--
> arch/arm/dts/am3517-evm.dts | 2 +-
> arch/arm/dts/am437x-gp-evm.dts | 2 +-
> arch/arm/dts/am43x-epos-evm.dts | 2 +-
> arch/arm/dts/am57xx-beagle-x15-common.dtsi | 6 +++---
> arch/arm/dts/da850-evm.dts | 2 +-
> arch/arm/dts/dra7-evm.dts | 2 +-
> arch/arm/dts/dra72-evm-common.dtsi | 6 +++---
> arch/arm/dts/keystone-k2e-evm.dts | 2 +-
> arch/arm/dts/keystone-k2hk-evm.dts | 2 +-
> arch/arm/dts/keystone-k2l-evm.dts | 2 +-
> arch/arm/dts/omap3-beagle-xm.dts| 4 ++--
> arch/arm/dts/omap3-beagle.dts | 6 +++---
> arch/arm/dts/omap3-igep0020-common.dtsi | 2 +-
> arch/arm/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 2 +-
> arch/arm/dts/omap34xx.dtsi | 2 +-
> arch/arm/dts/omap36xx.dtsi | 2 +-
> arch/arm/dts/omap4-panda-common.dtsi| 6 +++---
> arch/arm/dts/omap4-sdp.dts | 8
> arch/arm/dts/omap5-board-common.dtsi| 4 ++--
> 20 files changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/dts/am3517-evm-ui.dtsi b/arch/arm/dts/am3517-evm-ui.dtsi
> index e841918c1c..54aa2522aa 100644
> --- a/arch/arm/dts/am3517-evm-ui.dtsi
> +++ b/arch/arm/dts/am3517-evm-ui.dtsi
> @@ -186,14 +186,14 @@
> };
>
> {
> - status = "ok";
> + status = "okay";
> #sound-dai-cells = <0>;
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> };
>
> {
> - status = "ok";
> + status = "okay";
> #sound-dai-cells = <0>;
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> diff --git a/arch/arm/dts/am3517-evm.dts b/arch/arm/dts/am3517-evm.dts
> index 3527c0f2df..935c471c97 100644
> --- a/arch/arm/dts/am3517-evm.dts
> +++ b/arch/arm/dts/am3517-evm.dts
> @@ -193,7 +193,7 @@
> };
>
> {
> - status = "ok";
> + status = "okay";
>
> pinctrl-names = "default";
> pinctrl-0 = <_dpi_pins>;
> diff --git a/arch/arm/dts/am437x-gp-evm.dts b/arch/arm/dts/am437x-gp-evm.dts
> index 3c500d52db..21f7691f49 100644
> --- a/arch/arm/dts/am437x-gp-evm.dts
> +++ b/arch/arm/dts/am437x-gp-evm.dts
> @@ -742,7 +742,7 @@
> };
>
> {
> - status = "ok";
> + status = "okay";
>
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> diff --git a/arch/arm/dts/am43x-epos-evm.dts b/arch/arm/dts/am43x-epos-evm.dts
> index 65f157ed59..b940bc6ccf 100644
> --- a/arch/arm/dts/am43x-epos-evm.dts
> +++ b/arch/arm/dts/am43x-epos-evm.dts
> @@ -752,7 +752,7 @@
> };
>
> {
> - status = "ok";
> + status = "okay";
>
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> diff --git a/arch/arm/dts/am57xx-beagle-x15-common.dtsi
> b/arch/arm/dts/am57xx-beagle-x15-common.dtsi
> index d6b94d528f..1912ea9a15 100644
> --- a/arch/arm/dts/am57xx-beagle-x15-common.dtsi
> +++ b/arch/arm/dts/am57xx-beagle-x15-common.dtsi
> @@ -528,13 +528,13 @@
> };
>
> {
> - status = "ok";
> + status = "okay";
>
> vdda_video-supply = <_reg>;
> };
>
> {
> - status = "ok";
> + status = "okay";
> vdda-supply = <_reg>;
>
> port {
> @@ -545,7 +545,7 @@
> };
>
> _rc {
> - status = "ok";
> + status = "okay";
> gpios = < 8 GPIO_ACTIVE_LOW>;
> };
>
> diff --git a/arch/arm/dts/da850-evm.dts b/arch/arm/dts/da850-evm.dts
> index f04bc3e153..b331cefd18 100644
> --- a/arch/arm/dts/da850-evm.dts
> +++ b/arch/arm/dts/da850-evm.dts
> @@ -405,7 +405,7 @@
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> - status = "ok";
> + status = "okay";
> cs3 {
> #address-cells = <2>;
> #size-cells = <1>;
> diff --git a/arch/arm/dts/dra7-evm.dts b/arch/arm/dts/dra7-evm.dts
> index 43de9638e3..8e9a1a80a8 100644
> --- a/arch/arm/dts/dra7-evm.dts
> +++ b/arch/arm/dts/dra7-evm.dts
> @@ -501,7 +501,7 @@
> };
>
> {
> - status = "ok";
> + status = "okay";
> pinctrl-names = "default", "sleep", "active";
> pinctrl-0 = <_pins_sleep>;
> pinctrl-1 = <_pins_sleep>;
> diff --git a/arch/arm/dts/dra72-evm-common.dtsi
> b/arch/arm/dts/dra72-evm-common.dtsi
> index 2e485a13df..964e5e9b90 100644
> --- a/arch/arm/dts/dra72-evm-common.dtsi
> +++ b/arch/arm/dts/dra72-evm-common.dtsi
> @@ -430,7 +430,7 @@
> };
>
> {
> - status = "ok";
> + status = "okay";
> pinctrl-names = "default", "sleep",
Re: [PATCH 05/16] am43xx: Drop non-DM_I2C code
On 19/08/21 8:42 am, Tom Rini wrote: > On this platform, we have DM_I2C and SPL_DM_I2C always enabled. > Remove legacy options. > > Cc: Lokesh Vutla > Signed-off-by: Tom Rini Acked-by: Lokesh Vutla Thanks and regards, Lokesh
Re: [PATCH 12/23] ti: Convert CONFIG_TI_EDMA3 to Kconfig
On 08/08/21 11:50 pm, Simon Glass wrote: > This converts the following to Kconfig: >CONFIG_TI_EDMA3 > > Signed-off-by: Simon Glass > --- > [..snip..] > diff --git a/include/configs/ti_armv7_keystone2.h > b/include/configs/ti_armv7_keystone2.h > index cfc2be7b9f0..fa4a8c7a24f 100644 > --- a/include/configs/ti_armv7_keystone2.h > +++ b/include/configs/ti_armv7_keystone2.h > @@ -155,7 +155,6 @@ > #define CONFIG_TIMESTAMP > > /* EDMA3 */ > -#define CONFIG_TI_EDMA3 Just a nit pick. Comment above should be dropped as well. Otherwise. Reviewed-by: Lokesh Vutla Thanks and Regards, Lokesh
Re: [PATCH 3/5] arm: mach-k3: Add note to auto-generated files
On 11/08/21 1:19 am, Dave Gerlach wrote: > Add a note to the automatically generated clk-data and dev-data files > for j721e and j7200 to indicate that they are in fact auto-generated and > should not be hand edited. > > Signed-off-by: Dave Gerlach Are there any guidelines/README to do this autogeneration? Thanks and regards, Lokesh > --- > arch/arm/mach-k3/j7200/clk-data.c | 2 ++ > arch/arm/mach-k3/j7200/dev-data.c | 2 ++ > arch/arm/mach-k3/j721e/clk-data.c | 2 ++ > arch/arm/mach-k3/j721e/dev-data.c | 2 ++ > 4 files changed, 8 insertions(+) > > diff --git a/arch/arm/mach-k3/j7200/clk-data.c > b/arch/arm/mach-k3/j7200/clk-data.c > index 49145bbfc8cd..649d28b1db0b 100644 > --- a/arch/arm/mach-k3/j7200/clk-data.c > +++ b/arch/arm/mach-k3/j7200/clk-data.c > @@ -2,6 +2,8 @@ > /* > * J7200 specific clock platform data > * > + * This file is auto generated. Please do not edit directly. > + * > * Copyright (C) 2020-2021 Texas Instruments Incorporated - > http://www.ti.com/ > */ > #include "k3-clk.h" > diff --git a/arch/arm/mach-k3/j7200/dev-data.c > b/arch/arm/mach-k3/j7200/dev-data.c > index c68bcc58e9a7..f7b7892da97b 100644 > --- a/arch/arm/mach-k3/j7200/dev-data.c > +++ b/arch/arm/mach-k3/j7200/dev-data.c > @@ -2,6 +2,8 @@ > /* > * J7200 specific device platform data > * > + * This file is auto generated. Please do not edit directly. > + * > * Copyright (C) 2020-2021 Texas Instruments Incorporated - > http://www.ti.com/ > */ > #include "k3-dev.h" > diff --git a/arch/arm/mach-k3/j721e/clk-data.c > b/arch/arm/mach-k3/j721e/clk-data.c > index ff9262d7bcee..aa3f50a02f59 100644 > --- a/arch/arm/mach-k3/j721e/clk-data.c > +++ b/arch/arm/mach-k3/j721e/clk-data.c > @@ -2,6 +2,8 @@ > /* > * J721E specific clock platform data > * > + * This file is auto generated. Please do not edit directly. > + * > * Copyright (C) 2020-2021 Texas Instruments Incorporated - > http://www.ti.com/ > */ > #include "k3-clk.h" > diff --git a/arch/arm/mach-k3/j721e/dev-data.c > b/arch/arm/mach-k3/j721e/dev-data.c > index 96393c713278..a8bc6ce20d1d 100644 > --- a/arch/arm/mach-k3/j721e/dev-data.c > +++ b/arch/arm/mach-k3/j721e/dev-data.c > @@ -2,6 +2,8 @@ > /* > * J721E specific device platform data > * > + * This file is auto generated. Please do not edit directly. > + * > * Copyright (C) 2020-2021 Texas Instruments Incorporated - > http://www.ti.com/ > */ > #include "k3-dev.h" >
Re: [PATCH] Nokia RX-51: Convert documentation to rst format
Hi Pali,
On 01/08/21 4:18 pm, Pali Rohár wrote:
> On Monday 26 July 2021 12:38:05 Lokesh Vutla wrote:
>> On 22/07/21 2:55 am, Pali Rohár wrote:
>>> Signed-off-by: Pali Rohár
>>> ---
>>> board/nokia/rx51/MAINTAINERS | 2 +-
>>> doc/board/index.rst | 1 +
>>> doc/board/nokia/index.rst | 7 +
>>> .../nokia/rx51.rst} | 142 +-
>>> 4 files changed, 83 insertions(+), 69 deletions(-)
>>> create mode 100644 doc/board/nokia/index.rst
>>> rename doc/{README.nokia_rx51 => board/nokia/rx51.rst} (32%)
>>
>> This doesn't apply cleanly on latest u-boot master. Can you rebase and
>> repost?
>
> Because it depends on other N900 patches which were sent to ML prior this one.
How am I supposed to know what all patches it depends on and the current status
of these patches?
Please list all the patches and their current status. Or please ping me once all
the dependent patches are merged.
Thanks and regards,
Lokesh
>
>> Thanks and regards,
>> Lokesh
>>
>>>
>>> diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
>>> index 58b16bf9a95c..25f8b3c5a9ad 100644
>>> --- a/board/nokia/rx51/MAINTAINERS
>>> +++ b/board/nokia/rx51/MAINTAINERS
>>> @@ -4,5 +4,5 @@ S: Maintained
>>> F: board/nokia/rx51/
>>> F: include/configs/nokia_rx51.h
>>> F: configs/nokia_rx51_defconfig
>>> -F: doc/README.nokia_rx51
>>> +F: doc/board/nokia/rx51.rst
>>> F: test/nokia_rx51_test.sh
>>> diff --git a/doc/board/index.rst b/doc/board/index.rst
>>> index 747511f7ddd2..4c470abbac02 100644
>>> --- a/doc/board/index.rst
>>> +++ b/doc/board/index.rst
>>> @@ -19,6 +19,7 @@ Board-specific doc
>>> intel/index
>>> kontron/index
>>> microchip/index
>>> + nokia/index
>>> rockchip/index
>>> sifive/index
>>> sipeed/index
>>> diff --git a/doc/board/nokia/index.rst b/doc/board/nokia/index.rst
>>> new file mode 100644
>>> index ..fb0db2f34244
>>> --- /dev/null
>>> +++ b/doc/board/nokia/index.rst
>>> @@ -0,0 +1,7 @@
>>> +Nokia
>>> +=
>>> +
>>> +.. toctree::
>>> + :maxdepth: 2
>>> +
>>> + rx51
>>> diff --git a/doc/README.nokia_rx51 b/doc/board/nokia/rx51.rst
>>> similarity index 32%
>>> rename from doc/README.nokia_rx51
>>> rename to doc/board/nokia/rx51.rst
>>> index e739b02088ea..c84fdcddf166 100644
>>> --- a/doc/README.nokia_rx51
>>> +++ b/doc/board/nokia/rx51.rst
>>> @@ -1,6 +1,7 @@
>>> -Board: Nokia RX-51 aka N900
>>> +Nokia RX-51 aka N900
>>> +
>>>
>>> -This board definition results in a u-boot.bin which can be chainloaded
>>> +This board definition results in a ``u-boot.bin`` which can be chainloaded
>>> from NOLO in qemu or on a real N900. It does very little hardware config
>>> because NOLO has already configured the board. Only needed is enabling
>>> internal eMMC memory via twl4030 regulator which is not enabled by NOLO.
>>> @@ -8,64 +9,64 @@ internal eMMC memory via twl4030 regulator which is not
>>> enabled by NOLO.
>>> NOLO is expecting a kernel image and will treat any image it finds in
>>> onenand as such. This u-boot is intended to be flashed to the N900 like
>>> a kernel. In order to transparently boot the original kernel, it will be
>>> -appended to u-boot.bin at 0x4. NOLO will load the entire image into
>>> +appended to ``u-boot.bin`` at 0x4. NOLO will load the entire image into
>>> (random) memory and execute u-boot, which saves hw revision, boot reason
>>> and boot mode ATAGs set by NOLO. Then the bootscripts will attempt to load
>>> -uImage, zImage or boot.scr from a fat or ext2/3/4 filesystem on external
>>> -SD card or internal eMMC memory. If this fails or keyboard is closed then
>>> -the appended kernel image will be booted using some generated and some
>>> -stored ATAGs (see boot order).
>>> +``uImage``, ``zImage`` or ``boot.scr`` file from a fat or ext2/3/4
>>> filesystem
>>> +on external SD card or internal eMMC memory. If this fails or keyboard is
>>> +closed then the appended kernel image will be booted using some generated
>>> +and some stored ATAGs (see boot order).
>>>
>>> For generating combined image of u-boot and ker
[GIT PULL] TI changes for v2021.10-rc2
Hi Tom, Please find the PR for master branch targeted for v2021.10-rc2 tag. Details about the PR are updated in the tag message. Gitlab CI report: https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/8468 The following changes since commit b70b9b07463db2f6937c7ea6d7fb5122feb7ba1b: Prepare v2021.10-rc1 (2021-07-26 20:57:18 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.10-rc2 for you to fetch changes up to a6c64d255e5117bcf78aec6911d7c034fbfe46f7: board: ti: k2g: Program PadConfig_202 before locking RSTMUX8 (2021-07-29 10:42:22 +0530) - Add MMC High speed modes for AM64 and J7200 - Add Sierra/Torrent SERDES driver - Minor clean-ups for R5F boot from SPL Alan Douglas (1): phy: cadence: Add driver for Sierra PHY Aswath Govindraju (15): mmc: sdhci_am654: Read ti, strobe-sel property from device tree arm: dts: k3-j7200-main: Add support for HS400 and update delay select values for MMCSD subsystems configs: j7200_evm_*_defconfig: Enable configs for HS400 support dt-bindings: phy: Add definitions for additional phy types phy: cadence: Add driver for Torrent SERDES board: ti: j721e: Add support for probing and configuring Torrent serdes on J7200 arm: dts: k3-j7200-main: Add DT node for torrent serdes arm: dts: k3-j7200-common-proc-board: Enable SERDES DT arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for torrent serdes configs: j7200_evm_a72_defconfig: Add config for torrent serdes and common clock framework configs: am64x_evm_r5_defconfig: Fix CONFIG_SPL_TEXT_BASE to 0x7000 arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() to spl_mmc_boot_mode() arch: dts: am642-sk-u-boot: Disable main_sdhci0 DT node and define alias index 1 for main_sdhci1 node configs: am64x_evm: Move CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART to defconfig files and enable configs to save env in eMMC and FAT write. configs: am64x_evm_*_defconfig: Enable config to support gpt and FDT library overlay Faiz Abbas (1): mmc: sdhci: Write to HOST_CONTROL2 register for HS400 speed mode Jean-Jacques Hiblot (2): phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC configs: j721e_evm_a72_defconfig: Enable the drivers required for the USB3 support Kishon Vijay Abraham I (12): dm: core: Add helper to compare node names dm: test: Add test case to check node name ignoring unit address dt-bindings: phy: Add defines for AM64 SERDES Wrapper dt-bindings: phy: cadence-torrent: Add defines for refclk driver dt-bindings: ti-serdes-mux: Add defines for AM64 SoC ARM: dts: k3-j721e: Add support for USB3 in USB0 instance env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in J7200 EVM configs: j7200_evm_a72: Add CONFIG_PREBOOT to configure ethernet PHY doc: board: Move j721e document to doc/board/ti/ directory doc: board: j721e_evm: Add documentation for firmware loading configs: am64x_evm_a53_defconfig: Enable configs to support HS200/HS400 configs: am64x_evm_*_defconfig: Enable configs to support eMMC boot Paul Barker (4): dt-bindings: Resync omap & am33xx pinctrl bindings arm: dts: Resync BeagleBone device trees arm: dts: Import am335x-sancloud-bbe devicetree configs: am335x_evm: Support GbE PHYs Suman Anna (7): arm: dts: k3-am65: Fix up MCU R5FSS cluster mode back to Split-mode arm: mach-k3: j721e: Move booting of Main R5FSS Core0 to A72 U-Boot arm: mach-k3: j721e: Cleanup MAIN R5 boot code from R5 SPL arm: mach-k3: Cleanup common start_non_linux_remote_cores() arm: dts: k3-j721e-r5: Remove MAIN R5FSS0 cluster from SPL configs: j721e_evm_r5: Disable K3 R5F remoteproc board: ti: k2g: Program PadConfig_202 before locking RSTMUX8 arch/arm/dts/Makefile |1 + arch/arm/dts/am335x-bone-common.dtsi | 185 +- arch/arm/dts/am335x-bone.dts |7 +- arch/arm/dts/am335x-boneblack-common.dtsi | 169 ++ arch/arm/dts/am335x-boneblack.dts | 217 +- arch/arm/dts/am335x-bonegreen-common.dtsi | 41 + arch/arm/dts/am335x-bonegreen.dts | 49 +- arch/arm/dts/am335x-sancloud-bbe.dts | 137 + arch/arm/dts/k3-am642-sk-u-boot.dtsi |5 + arch/arm/dts/k3-am654-base-board-u-boot.dtsi |4 + .../k3-j7200-common-proc-board-u-boot.dtsi| 12 + arch/arm/dts/k3-j7200-common-proc-board.dts | 23 + arch/arm/dts/k3-j7200-main.dtsi | 74 +- .../k3-j721e-common-proc-board-u-boot.dtsi| 19 +- .../k3-j721e-r5-common-proc-board-u-boot.dtsi | 14 - .../arm/dts/k3-j721e-r5-common-proc-board.dts |2 - arch/arm/mach-k3/am642_init.c |2 +- arch/arm/mach-k3/common.c
Re: [PATCH] board: ti: k2g: Program PadConfig_202 before locking RSTMUX8
On Mon, 26 Jul 2021 18:22:48 -0500, Suman Anna wrote: > The PADCONFIG_202 register (0x02621328) is affected by the locking > of the RSTMUX8 register (0x02620328), and so cannot be configured > in kernel. This has been confirmed as a hardware bug and affects > all K2G SoCs. > > Setup the pinmux for this pin before locking the RSTMUX8 register > to allow the ICSS1 PRU1 Ethernet PHY port to work properly. The > workaround was added only for the K2G-ICE board to configure the > pins needed for the PRUSS Ethernet usecase. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] board: ti: k2g: Program PadConfig_202 before locking RSTMUX8 https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a6c64d255e -- Thanks and Regards, Lokesh
Re: [PATCH] arm: dts: k3-am65: Fix up MCU R5FSS cluster mode back to Split-mode
On Mon, 26 Jul 2021 11:22:13 -0500, Suman Anna wrote:
> The default U-Boot environment variables and design are all set up to
> have the MCU R5FSS cluster to be in Split-mode. This is the setting
> in v2021.01 U-Boot and the dt nodes are synched with the kernel binding
> property names in commit 468ec2f3ef8f ("remoteproc: k3_r5: Sync to
> upstreamed kernel DT property names") merged in v2021.04-rc2.
>
> The mode for the cluster got switched back to LockStep mode by mistake
> in commit e49787634312 ("arm: dts: k3-am65: Sync Linux v5.11-rc6 dts
> into U-Boot") also in v2021.04-rc2. This throws the following warning
> messages when early-booting the cores using default env variables,
>
> [...]
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc,
thanks!
[1/1] arm: dts: k3-am65: Fix up MCU R5FSS cluster mode back to Split-mode
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/31b3d7a018
--
Thanks and Regards,
Lokesh
Re: [PATCH 0/5] Cleanup MAIN R5F boot from R5 SPL
On Mon, 26 Jul 2021 16:13:06 -0500, Suman Anna wrote: > The following series cleans up the code related to booting of Main > R5FSS0 Core0 from R5 SPL, and moves it to A72 U-Boot on J721E SoCs. > This is no longer supported after the R5 SPL re-architecture that > splits the System Firmware functionality onto two separate processors. > This functionality has been merged post v2021.07 tag towards v2021.10-rc1. > The Main R5FSS0 Core0 is already being booted on A72 U-Boot on J7200 > SoCs, the other SoC family that follows this split system firmware > architecture. > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/5] arm: mach-k3: j721e: Move booting of Main R5FSS Core0 to A72 U-Boot https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/05e858aefe [2/5] arm: mach-k3: j721e: Cleanup MAIN R5 boot code from R5 SPL https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/536f633d8a [3/5] arm: mach-k3: Cleanup common start_non_linux_remote_cores() https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/ea985f6d92 [4/5] arm: dts: k3-j721e-r5: Remove MAIN R5FSS0 cluster from SPL https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/24f3fb6547 [5/5] configs: j721e_evm_r5: Disable K3 R5F remoteproc https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/bcad620f68 -- Thanks and Regards, Lokesh
Re: [PATCH v2 0/6] AM64: Add support for higher speed modes and boot mode in eMMC
On Mon, 26 Jul 2021 20:58:01 +0530, Aswath Govindraju wrote: > The following series of patches add support for, > - HS200/HS400 speed modes > - eMMC boot mode > - gpt and FDT library overlay > > This series of patches, > - dependent on > https://patchwork.ozlabs.org/project/uboot/list/?series=237442 > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/6] arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() to spl_mmc_boot_mode() https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/2140d6b0ff [2/6] arch: dts: am642-sk-u-boot: Disable main_sdhci0 DT node and define alias index 1 for main_sdhci1 node https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0817dd5432 [3/6] configs: am64x_evm_a53_defconfig: Enable configs to support HS200/HS400 https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a3d58069c4 [4/6] configs: am64x_evm: Move CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART to defconfig files and enable configs to save env in eMMC and FAT write. https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/acbda111b2 [5/6] configs: am64x_evm_*_defconfig: Enable configs to support eMMC boot https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/da6a7206be [6/6] configs: am64x_evm_*_defconfig: Enable config to support gpt and FDT library overlay https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/f572129b13 -- Thanks and Regards, Lokesh
Re: [PATCH v5 00/20] TI/Cadence: Add Sierra/Torrent SERDES driver
On Wed, 21 Jul 2021 21:28:29 +0530, Kishon Vijay Abraham I wrote: > Patch series adds Sierra and Torrent SERDES driver for the SERDES > used in TI's K3 platforms. This SERDES is used by USB3, PCIe and > Ethernet. This series is mostly an adaptation of drivers added in > upstream Linux kernel. > > Changes from v4: > 1) Dropped `[PATCH v4 01/21] drivers: reset: Add devm_to_reset() to > return dummy "struct reset_ctl"` and will be worked independently of > this series. This was mainly introduced for handling optional reset > which is not mandatory for both Sierra and Torrent. > 2) Fixed sectionauthor name for j721e_evm.rst > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [01/20] dm: core: Add helper to compare node names https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/77cbaf8837 [02/20] dm: test: Add test case to check node name ignoring unit address https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/9f6ae6dec2 [03/20] dt-bindings: phy: Add definitions for additional phy types https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/4f2c79e42c [04/20] dt-bindings: phy: Add defines for AM64 SERDES Wrapper https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/2b6b37032c [05/20] dt-bindings: phy: cadence-torrent: Add defines for refclk driver https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0b5ea853be [06/20] dt-bindings: ti-serdes-mux: Add defines for AM64 SoC https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/2b0f7dee5f [07/20] phy: cadence: Add driver for Sierra PHY https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/39b823381d [08/20] phy: cadence: Add driver for Torrent SERDES https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/193c735162 [09/20] phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/1a83f9931e [10/20] board: ti: j721e: Add support for probing and configuring Torrent serdes on J7200 https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/6cfabddc3b [11/20] ARM: dts: k3-j721e: Add support for USB3 in USB0 instance https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/ad256cc894 [12/20] arm: dts: k3-j7200-main: Add DT node for torrent serdes https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/6c4be8eb7e [13/20] arm: dts: k3-j7200-common-proc-board: Enable SERDES DT https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/cbea79867e [14/20] arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for torrent serdes https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/08189ffd15 [15/20] configs: j721e_evm_a72_defconfig: Enable the drivers required for the USB3 support https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a9ed736cfa [16/20] configs: j7200_evm_a72_defconfig: Add config for torrent serdes and common clock framework https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0e64ecd703 [17/20] env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in J7200 EVM https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/15f4193fff [18/20] configs: j7200_evm_a72: Add CONFIG_PREBOOT to configure ethernet PHY https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/8fa3286408 [19/20] doc: board: Move j721e document to doc/board/ti/ directory https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/8baeeecbe3 [20/20] doc: board: j721e_evm: Add documentation for firmware loading https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/4689aabbe4 -- Thanks and Regards, Lokesh
Re: [PATCH] mmc: sdhci: Write to HOST_CONTROL2 register for HS400 speed mode
On Mon, 5 Apr 2021 20:14:28 +0530, Aswath Govindraju wrote: > Enable HS400 speed mode by writing to HOST_CONTROL2 register. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] mmc: sdhci: Write to HOST_CONTROL2 register for HS400 speed mode https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/bda47bef7c -- Thanks and Regards, Lokesh
Re: [PATCH] configs: am64x_evm_r5_defconfig: Fix CONFIG_SPL_TEXT_BASE to 0x70000000
On Mon, 26 Jul 2021 20:28:39 +0530, Aswath Govindraju wrote: > CONFIG_SPL_TEXT_BASE was set to 0x7000 in the commit, > "26f32c32b250 configs: am64x_evm_*_defconfig: Rearrange the components in > SRAM to satisfy the limitations for USB DFU boot mode". This change seems > to have been dropped during a merge commit. > > Therefore, fix this by setting CONFIG_SPL_TEXT_BASE to 0x7000. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] configs: am64x_evm_r5_defconfig: Fix CONFIG_SPL_TEXT_BASE to 0x7000 https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/159c901c60 -- Thanks and Regards, Lokesh
Re: [PATCH 0/6] AM64: Add support for higher speed modes and boot mode in eMMC
On Thu, 3 Jun 2021 14:34:22 +0530, Aswath Govindraju wrote: > The following series of patches add support for, > - HS200/HS400 speed modes > - eMMC boot mode > - gpt and FDT library overlay > > This series of patches, > - dependent on > https://patchwork.ozlabs.org/project/uboot/list/?series=237442 > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/6] arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() to spl_mmc_boot_mode() https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/2140d6b0ff [2/6] arch: dts: am642-sk-u-boot: Disable main_sdhci0 DT node and define alias index 1 for main_sdhci1 node https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0817dd5432 [3/6] configs: am64x_evm_a53_defconfig: Enable configs to support HS200/HS400 https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a3d58069c4 [4/6] configs: am64x_evm: Move CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART to defconfig files and enable configs to save env in eMMC and FAT write. https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/acbda111b2 [5/6] configs: am64x_evm_a53_defconfig/am64x_evm_r5_defconfig: Enable configs to support eMMC boot (no commit info) [6/6] configs: am64x_evm_*_defconfig: Enable config to support gpt and FDT library overlay https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/f572129b13 -- Thanks and Regards, Lokesh
Re: [PATCH 0/3] J7200: Add support for HS400 speed mode
On Tue, 25 May 2021 15:08:22 +0530, Aswath Govindraju wrote: > The following series of patches add support for HS400 speed mode on J7200 > SoC. > > For HS400 support to work, the following series of patches depend on, > https://patchwork.ozlabs.org/project/uboot/patch/20210405144428.12159-1-a-govindr...@ti.com/ > > Aswath Govindraju (3): > mmc: sdhci_am654: Read ti,strobe-sel property from device tree > arm: dts: k3-j7200-main: Add support for HS400 and update delay select > values for MMCSD subsystems > configs: j7200_evm_*_defconfig: Enable configs for HS400 support > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/3] mmc: sdhci_am654: Read ti, strobe-sel property from device tree https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/46077ef251 [2/3] arm: dts: k3-j7200-main: Add support for HS400 and update delay select values for MMCSD subsystems https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/455f9dddc8 [3/3] configs: j7200_evm_*_defconfig: Enable configs for HS400 support https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/f490d359d7 -- Thanks and Regards, Lokesh
Re: [PATCH v2 5/5] configs: am335x_evm: Fix BeagleBone Green DTB selection
On 21/07/21 12:10 pm, Paul Barker wrote: > On Wed, 21 Jul 2021 11:29:04 +0530 > Lokesh Vutla wrote: > >> On 20/07/21 1:49 pm, Paul Barker wrote: >>> On Tue, 13 Jul 2021 11:59:06 +0530 >>> Lokesh Vutla wrote: >>> >>>> On 13/07/21 1:44 am, Paul Barker wrote: >>>>> The function board_is_bone_lt() returns true for the BeagleBone Green, >>>>> the BeagleBone Enhanced and the BeagleBone Black. Therefore when >>>>> selecting which devicetree to use we must ensure that the more specific >>>>> functions board_is_bbg1() and board_is_bben() are checked first >>>>> otherwise all three devices would end up using the am335x-boneblack >>>>> devicetree. This can be achieved by placing the relevant devicetree >>>>> names (am335x-sancloud-bbe and am335x-bonegreen) before am335x-boneblack >>>>> in CONFIG_OF_LIST. >>>> >>>> Such restrictions should be handled inside board_fit_config_name_match() >>>> and >>>> hiden from user configuration. Can you update the >>>> board_fit_config_name_match() >>>> instead of updating defconfig? >>> >>> Hi Lokesh, >>> >>> Apologies for the late reply, I lost most of last week due to illness. >>> >>> I first attempted to fix this by changing the order of things in >>> `board_fit_config_name_match` but it had no effect. Looking at >>> `fit_find_config_node` in `common/common_fit.c`, we loop through the >>> list of dtbs and check each one in turn for a match. So to move >>> am335x-bonegreen ahead of am335x-boneblack we need to change the order >>> in which the dtbs are checked in `fit_find_config_node`. The simplest >>> way I could find to do that is to change the order of the names in >>> CONFIG_OF_LIST. >> >> ahh..ok got it. But still such constraints in config file is most likely will >> not be maintained in future when someone touching the config. Because not >> everyone knows this. >> >> Is it possible to create a new macro which is true only for bbb and use it >> instead in board_fit_config_name_match? > > I'm happy to have a look for an alternative solution like that. The > patch here is a quick fix though that can be applied as-is. Perhaps we > should apply this and also look for an alternative implementation of > `board_is_bone_lt`. > > If you want to leave this patch out for now, can we move ahead and > merge the other patches in this series? You are right. Applied the first 4 patches to for-rc branch. Thanks and regards, Lokesh
Re: [PATCH] Nokia RX-51: Convert documentation to rst format
On 22/07/21 2:55 am, Pali Rohár wrote:
> Signed-off-by: Pali Rohár
> ---
> board/nokia/rx51/MAINTAINERS | 2 +-
> doc/board/index.rst | 1 +
> doc/board/nokia/index.rst | 7 +
> .../nokia/rx51.rst} | 142 +-
> 4 files changed, 83 insertions(+), 69 deletions(-)
> create mode 100644 doc/board/nokia/index.rst
> rename doc/{README.nokia_rx51 => board/nokia/rx51.rst} (32%)
This doesn't apply cleanly on latest u-boot master. Can you rebase and repost?
Thanks and regards,
Lokesh
>
> diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
> index 58b16bf9a95c..25f8b3c5a9ad 100644
> --- a/board/nokia/rx51/MAINTAINERS
> +++ b/board/nokia/rx51/MAINTAINERS
> @@ -4,5 +4,5 @@ S:Maintained
> F: board/nokia/rx51/
> F: include/configs/nokia_rx51.h
> F: configs/nokia_rx51_defconfig
> -F: doc/README.nokia_rx51
> +F: doc/board/nokia/rx51.rst
> F: test/nokia_rx51_test.sh
> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 747511f7ddd2..4c470abbac02 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -19,6 +19,7 @@ Board-specific doc
> intel/index
> kontron/index
> microchip/index
> + nokia/index
> rockchip/index
> sifive/index
> sipeed/index
> diff --git a/doc/board/nokia/index.rst b/doc/board/nokia/index.rst
> new file mode 100644
> index ..fb0db2f34244
> --- /dev/null
> +++ b/doc/board/nokia/index.rst
> @@ -0,0 +1,7 @@
> +Nokia
> +=
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + rx51
> diff --git a/doc/README.nokia_rx51 b/doc/board/nokia/rx51.rst
> similarity index 32%
> rename from doc/README.nokia_rx51
> rename to doc/board/nokia/rx51.rst
> index e739b02088ea..c84fdcddf166 100644
> --- a/doc/README.nokia_rx51
> +++ b/doc/board/nokia/rx51.rst
> @@ -1,6 +1,7 @@
> -Board: Nokia RX-51 aka N900
> +Nokia RX-51 aka N900
> +
>
> -This board definition results in a u-boot.bin which can be chainloaded
> +This board definition results in a ``u-boot.bin`` which can be chainloaded
> from NOLO in qemu or on a real N900. It does very little hardware config
> because NOLO has already configured the board. Only needed is enabling
> internal eMMC memory via twl4030 regulator which is not enabled by NOLO.
> @@ -8,64 +9,64 @@ internal eMMC memory via twl4030 regulator which is not
> enabled by NOLO.
> NOLO is expecting a kernel image and will treat any image it finds in
> onenand as such. This u-boot is intended to be flashed to the N900 like
> a kernel. In order to transparently boot the original kernel, it will be
> -appended to u-boot.bin at 0x4. NOLO will load the entire image into
> +appended to ``u-boot.bin`` at 0x4. NOLO will load the entire image into
> (random) memory and execute u-boot, which saves hw revision, boot reason
> and boot mode ATAGs set by NOLO. Then the bootscripts will attempt to load
> -uImage, zImage or boot.scr from a fat or ext2/3/4 filesystem on external
> -SD card or internal eMMC memory. If this fails or keyboard is closed then
> -the appended kernel image will be booted using some generated and some
> -stored ATAGs (see boot order).
> +``uImage``, ``zImage`` or ``boot.scr`` file from a fat or ext2/3/4 filesystem
> +on external SD card or internal eMMC memory. If this fails or keyboard is
> +closed then the appended kernel image will be booted using some generated
> +and some stored ATAGs (see boot order).
>
> For generating combined image of u-boot and kernel (either in uImage or
> zImage
> -format) there is a simple script called u-boot-gen-combined. It is available
> in
> -following repository:
> +format) there is a simple script called ``u-boot-gen-combined``. It is
> available
> +in following repository:
>
> - https://github.com/pali/u-boot-maemo
> + https://github.com/pali/u-boot-maemo
>
> -To generate combined.bin image from u-boot.bin and kernel.bin (either uImage
> -or zImage) use:
> +To generate ``combined.bin`` image from ``u-boot.bin`` and ``kernel.bin``
> +(either uImage or zImage format) use::
>
> - sh u-boot-gen-combined u-boot.bin kernel.bin combined.bin
> + $ sh u-boot-gen-combined u-boot.bin kernel.bin combined.bin
>
> Original Maemo Fremantle PR1.3 zImage kernel binary is available at:
>
> -
> http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
> +
> http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
>
> -To unpack it (from DEB/AR, TAR and FIASCO) call commands:
> +To unpack it (from DEB/AR, TAR and FIASCO) call commands::
>
> - ar x kernel_2.6.28-20103103+0m5_armel.deb data.tar.gz
> - tar -O -xf data.tar.gz ./boot/zImage-2.6.28-20103103+0m5.fiasco >
> kernel_2.6.28-20103103+0m5.fiasco
> - 0x -M kernel_2.6.28-20103103+0m5.fiasco -u
> + $ ar x kernel_2.6.28-20103103+0m5_armel.deb data.tar.gz
> + $ tar -O -xf
Re: [PATCH v2 5/5] configs: am335x_evm: Fix BeagleBone Green DTB selection
On 20/07/21 1:49 pm, Paul Barker wrote: > On Tue, 13 Jul 2021 11:59:06 +0530 > Lokesh Vutla wrote: > >> On 13/07/21 1:44 am, Paul Barker wrote: >>> The function board_is_bone_lt() returns true for the BeagleBone Green, >>> the BeagleBone Enhanced and the BeagleBone Black. Therefore when >>> selecting which devicetree to use we must ensure that the more specific >>> functions board_is_bbg1() and board_is_bben() are checked first >>> otherwise all three devices would end up using the am335x-boneblack >>> devicetree. This can be achieved by placing the relevant devicetree >>> names (am335x-sancloud-bbe and am335x-bonegreen) before am335x-boneblack >>> in CONFIG_OF_LIST. >> >> Such restrictions should be handled inside board_fit_config_name_match() and >> hiden from user configuration. Can you update the >> board_fit_config_name_match() >> instead of updating defconfig? > > Hi Lokesh, > > Apologies for the late reply, I lost most of last week due to illness. > > I first attempted to fix this by changing the order of things in > `board_fit_config_name_match` but it had no effect. Looking at > `fit_find_config_node` in `common/common_fit.c`, we loop through the > list of dtbs and check each one in turn for a match. So to move > am335x-bonegreen ahead of am335x-boneblack we need to change the order > in which the dtbs are checked in `fit_find_config_node`. The simplest > way I could find to do that is to change the order of the names in > CONFIG_OF_LIST. ahh..ok got it. But still such constraints in config file is most likely will not be maintained in future when someone touching the config. Because not everyone knows this. Is it possible to create a new macro which is true only for bbb and use it instead in board_fit_config_name_match? Thanks and reagrds, Lokesh > > Thanks, >
Re: [PATCH] mmc: sdhci: Write to HOST_CONTROL2 register for HS400 speed mode
On 20/07/21 10:51 am, Jaehoon Chung wrote: > Hi Lokesh, > > On 7/20/21 1:10 PM, Lokesh Vutla wrote: >> +Tom >> >> On 20/07/21 3:45 am, Jaehoon Chung wrote: >>> Hi Aswath, >>> >>> On 7/19/21 3:48 PM, Aswath Govindraju wrote: >>>> Hi Peng, >>>> >>>> On 09/06/21 8:56 pm, Aswath Govindraju wrote: >>>>> Hi Peng, >>>>> >>>>> On 10/05/21 7:18 pm, Aswath Govindraju wrote: >>>>>> Hi Peng, >>>>>> >>>>>> On 07/04/21 3:52 am, Jaehoon Chung wrote: >>>>>>> On 4/5/21 11:44 PM, Aswath Govindraju wrote: >>>>>>>> From: Faiz Abbas >>>>>>>> >>>>>>>> Enable HS400 speed mode by writing to HOST_CONTROL2 register. >>>>>>>> >>>>>>>> Signed-off-by: Faiz Abbas >>>>>>>> Signed-off-by: Aswath Govindraju >>>>>>> >>>>>>> Reviewed-by: Jaehoon Chung >>>>>>> >>>>>> >>>>>> Can you please pick this patch if there are no comments. >>>>>> >>>>> >>>>> May I know if this okay to be merged ? >>>>> >>>> >>>> A gentle reminder on this patch. This patch has other dependencies that >>>> and are pending merge[1][2]. >>> >>> I don't have the permission to merge on u-boot-mmc git. >>> I have the permission to merge on just u-boot-pmic..But I don't know >>> whether it's the best way to apply this into my u-boot-pmic or not. :) >>> >>> I had been already reviewed about this patch.. >>> So if want to pick this, I think there is no problem about applied together >>> with below patches. >>> >>> Acked-by: Jaehoon Chung >> >> Tom, >> Is it okay if I pick this patch as per above suggestion? > > Isn't it enough my Acked-by tag? Sure it is :). I just want to make sure Tom doesn't flag it in the PR. Thanks and regards, Lokesh
Re: [PATCH] mmc: sdhci: Write to HOST_CONTROL2 register for HS400 speed mode
+Tom On 20/07/21 3:45 am, Jaehoon Chung wrote: > Hi Aswath, > > On 7/19/21 3:48 PM, Aswath Govindraju wrote: >> Hi Peng, >> >> On 09/06/21 8:56 pm, Aswath Govindraju wrote: >>> Hi Peng, >>> >>> On 10/05/21 7:18 pm, Aswath Govindraju wrote: Hi Peng, On 07/04/21 3:52 am, Jaehoon Chung wrote: > On 4/5/21 11:44 PM, Aswath Govindraju wrote: >> From: Faiz Abbas >> >> Enable HS400 speed mode by writing to HOST_CONTROL2 register. >> >> Signed-off-by: Faiz Abbas >> Signed-off-by: Aswath Govindraju > > Reviewed-by: Jaehoon Chung > Can you please pick this patch if there are no comments. >>> >>> May I know if this okay to be merged ? >>> >> >> A gentle reminder on this patch. This patch has other dependencies that >> and are pending merge[1][2]. > > I don't have the permission to merge on u-boot-mmc git. > I have the permission to merge on just u-boot-pmic..But I don't know whether > it's the best way to apply this into my u-boot-pmic or not. :) > > I had been already reviewed about this patch.. > So if want to pick this, I think there is no problem about applied together > with below patches. > > Acked-by: Jaehoon Chung Tom, Is it okay if I pick this patch as per above suggestion? Thanks and regards, Lokesh > > Best Regards, > Jaehoon Chung > >> >> [1] - >> https://protect2.fireeye.com/v1/url?k=bf905767-e00b6fae-bf91dc28-0cc47a336fae-6a3fa5daa309=1=ac3de2ef-41d1-4e60-952a-16e2b302cfdd=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D247000 >> [2] - >> https://protect2.fireeye.com/v1/url?k=c93699cd-96ada104-c9371282-0cc47a336fae-de6d85845da27eb0=1=ac3de2ef-41d1-4e60-952a-16e2b302cfdd=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D245579 >> >> Thanks, >> Aswath >> >>> Thanks, >>> Aswath >>> Thanks, Aswath > Best Regards, > Jaehoon Chung > >> --- >> drivers/mmc/sdhci.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c >> index d9ab6a0a839e..eea4701d8af5 100644 >> --- a/drivers/mmc/sdhci.c >> +++ b/drivers/mmc/sdhci.c >> @@ -507,6 +507,9 @@ void sdhci_set_uhs_timing(struct sdhci_host *host) >> case MMC_HS_200: >> reg |= SDHCI_CTRL_UHS_SDR104; >> break; >> +case MMC_HS_400: >> +reg |= SDHCI_CTRL_HS400; >> +break; >> default: >> reg |= SDHCI_CTRL_UHS_SDR12; >> } >> > >>> >> >> >
Re: [PATCH] Nokia RX-51: Update documentation about flashing
Hi, On 18/06/21 6:59 pm, Pali Rohár wrote: > This change contains update for doc/README.nokia_rx51 documentation file > with information how to load U-Boot image to device RAM without need to > flash it and also how to flash it into OneNAND via 0x flasher. > > Signed-off-by: Pali Rohár Can you please convert this file to rST ? Thanks and regards, Lokesh > --- > doc/README.nokia_rx51 | 45 +++ > 1 file changed, 45 insertions(+) > > diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51 > index 1be077514f03..e739b02088ea 100644 > --- a/doc/README.nokia_rx51 > +++ b/doc/README.nokia_rx51 > @@ -22,6 +22,51 @@ following repository: > >https://github.com/pali/u-boot-maemo > > +To generate combined.bin image from u-boot.bin and kernel.bin (either uImage > +or zImage) use: > + > + sh u-boot-gen-combined u-boot.bin kernel.bin combined.bin > + > +Original Maemo Fremantle PR1.3 zImage kernel binary is available at: > + > + > http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb > + > +To unpack it (from DEB/AR, TAR and FIASCO) call commands: > + > + ar x kernel_2.6.28-20103103+0m5_armel.deb data.tar.gz > + tar -O -xf data.tar.gz ./boot/zImage-2.6.28-20103103+0m5.fiasco > > kernel_2.6.28-20103103+0m5.fiasco > + 0x -M kernel_2.6.28-20103103+0m5.fiasco -u > + > +Flashed image must start with 2 kB "NOLO!img" header which contains size of > +the image. Header consist of bytes "NOLO!img\x02\x00\x00\x00\x00\x00\x00\x00" > +followed by 4 byte little endian size of the image and rest of the 2 kB > header > +are just zero bytes. > + > +Nokia proprietary flasher and also open source 0x flasher automatically > +prepend required "NOLO!img" header and both applications expect that image > +does not contain "NOLO!img" header. Adding "NOLO!img" header is required > +only in case using "nandwrite" tool for flashing. > + > +Open source 0x flasher is available in following repository: > + > + https://github.com/pali/0x > + > +It is possible to load u-boot.bin via USB to N900 RAM and boot it without > +need to flashing it. Via 0x running at host PC it is done: > + > + 0x -m u-boot.bin -l -b > + > +0x support also flashing kernel image either via USB or directly on > +N900 device. Flashing u-boot/kernel/combined image is done as: > + > + 0x -m combined.bin -f > + > +Via 0x is possible to generate also standard flashable image in Nokia > +FIASCO format which contains metadata information like device identification > +(RX-51) and version string (v2021.04): > + > + 0x -m RX-51:v2021.04:kernel:u-boot.bin -g u-boot.fiasco > + > There is support for hardware watchdog. Hardware watchdog is started by > NOLO so u-boot must kick watchdog to prevent reboot device (but not very > often, max every 2 seconds). There is also support for framebuffer display >
[GIT PULL] TI changes for v2021.10-rc1
Hi Tom, Please find the PR for master branch targeted for v2021.10-rc1 tag. Details about the PR are updated in the tag message. Gitlab CI report: https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/8254 The following changes since commit c11f5abce84f630c92304683d5bde3204c5612c4: Merge branch '2021-07-14-build-and-host-updates' (2021-07-14 20:10:34 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.10-rc1 for you to fetch changes up to 652982309d316b14aae5805d09239f89eb89f038: Nokia RX-51: Add check for /lib/ld-linux.so.2 in test script (2021-07-15 17:56:05 +0530) - Enabled distro boot for all TI platforms. - Cleanup for AM335x Guardian Board - PRUSS rproc on AM65 platform. - Add PMIC support for J7200 - Misc fixes for Nokia RX-51 Adam Ford (5): configs: omap3x_logic: Fix boot hang by reducing SYS_MALLOC_F_LEN arm: omap3: Make try_unlock_memory() static arm: omap3: Make secureworld_exit() static arm: omap3: Make secure_unlock_mem() static configs: am3517_evm: Fix boot hang Aswath Govindraju (2): configs: am64x_evm_a53_defconfig: Move TF-A load address to 0x701c arm: dts: k3-am64-main: Reserve OCMRAM for DMSC-lite and secure proxy communication Gireesh Hiremath (15): configs: am335x_guardian: Enable clock driver configs: am335x_guardian: add ubi fastmap support configs: am335x_guardian: add memtest configs am335x, guardian: set environment variable autoload to no am335x, guardian: code cleanup and boot optimization configs: am335x_guardian: set boot delay configs: am335x_guardian: disable spl command am335x, guardian: update swi logic am335x, guardian: Enable backlight configs: am335x_guardian: Enable display config drivers: video: hx8238 fix build bug am335x, guardian: Enable panel driver Himax HX8238D am335x, guardian: software update available status is stored in AM3352 RTC scracth register configs: am335x_guardian: Enable bootcount nvmem support configs: am335x_guardian: add register maps support Gowtham Tammana (6): arm: mach-k3: am642_init: Add missing ddr guard power: pmic: tps65941: Add compatible for LP876441 arm/dts: k3-j7200-r5-common: Add pmic lp876441 node arm/dts: k3-j7200-r5-common: Add VTM node arm/dts: k3-j7200-r5-common: Hook buck1_reg to vtm supply configs: j7200_evm_r5_defconfig: Enable AVS, PMIC and dependent configs Keerthy (2): soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs Lokesh Vutla (3): arm: dts: k3-am654-base-board: Add r5 specific u-boot dtsi arm: dts: ti: k3-am65-main: Add ICSSG nodes configs: am65x_evm_a53: Enable PRUSS remoteproc Moses Christopher (3): am335x, guardian: mem: Add board dependent mem values am335x, guardian: set tftp_load_addr in environment am335x, guardian: Update pinmux configuration Pali Rohár (3): Nokia RX-51: Add support for booting kernel in zImage format Nokia RX-51: Load bootmenu also from uSD card Nokia RX-51: Add check for /lib/ld-linux.so.2 in test script Tom Rini (7): ti: am335x_evm: Switch to DISTRO_BOOT only ti: am43xx_evm: Switch to DISTRO_BOOT only arm: ti: environment: Move in to ti: omap5: Switch to generic distro boot for non-Android cases configs: j721e_evm: Switch envboot out for distro_bootcmd arm: omap4: Disable USB_TTY and related options configs: am65x_evm: Switch envboot out for distro_bootcmd MAINTAINERS | 2 + arch/arm/dts/am335x-guardian-u-boot.dtsi | 11 + arch/arm/dts/am335x-guardian.dts | 14 +- arch/arm/dts/k3-am64-main.dtsi| 12 +- arch/arm/dts/k3-am65-main.dtsi| 463 ++ arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 205 ++-- .../dts/k3-am654-r5-base-board-u-boot.dtsi| 207 arch/arm/dts/k3-am654-r5-base-board.dts | 2 - .../arm/dts/k3-j7200-r5-common-proc-board.dts | 38 ++ .../include/asm/arch-am33xx/mem-guardian.h| 63 +++ arch/arm/include/asm/arch-omap3/sys_proto.h | 2 - arch/arm/mach-k3/am642_init.c | 2 +- arch/arm/mach-omap2/am33xx/Kconfig| 2 + arch/arm/mach-omap2/am33xx/board.c| 4 + arch/arm/mach-omap2/mem-common.c | 4 + arch/arm/mach-omap2/omap3/board.c | 21 +- board/bosch/guardian/board.c | 152 +- board/bosch/guardian/mux.c| 3 +- board/nokia/rx51/lowlevel_init.S | 12 +- configs/am335x_boneblack_vboot_defconfig | 2 +- configs/am335x_evm_defconfig | 2 +- configs/am335x_evm_spiboot_defconfig | 2 +- configs/am335x_guardian_defconfig | 30 +- configs
Re: [PATCH] Nokia RX-51: Add check for /lib/ld-linux.so.2 in test script
On Fri, 18 Jun 2021 15:31:08 +0200, Pali Rohár wrote: > Unfortunately for testing is required qflasher which works only in 32-bit > x86 mode. Apparently 64-bit x86 Azure CI has no problems as it has > preinstalled 32-bit libraries and can execute also 32-bit x86 executables. > > This change just show human readable output why nokia_rx51_test.sh test > script fails. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] Nokia RX-51: Add check for /lib/ld-linux.so.2 in test script https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/f3ff72f9ff -- Thanks and Regards, Lokesh
Re: [PATCH 1/2] Nokia RX-51: Add support for booting kernel in zImage format
On Fri, 18 Jun 2021 15:27:03 +0200, Pali Rohár wrote: > Enable U-Boot bootz command and update env scripts to try loading also > zImage file and to try booting via bootz command. > > Update also lowlevel_init.S code for checking validity of zImage magic to > correctly relocate kernel in zImage format. > > This change allows U-Boot to directly boot Linux kernel without need for > converting kernel image into U-Boot uImage format. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/2] Nokia RX-51: Add support for booting kernel in zImage format https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/77122d6fad [2/2] Nokia RX-51: Load bootmenu also from uSD card https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/da523d3250 -- Thanks and Regards, Lokesh
Re: [PATCH v3 0/5] Add PMIC node for J7200
On Wed, 14 Jul 2021 15:52:55 -0500, Gowtham Tammana wrote: > The J7200 EVM has PMIC LP876441 for supporting CPU AVS. This patchset > adds dt nodes, compatible string, and configs to enable the > corresponding driver. > > v3: > - rebased to resolve minor conflicts against master > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/5] power: pmic: tps65941: Add compatible for LP876441 https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/d4a344c393 [2/5] arm/dts: k3-j7200-r5-common: Add pmic lp876441 node https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/cbd49ed9d6 [3/5] arm/dts: k3-j7200-r5-common: Add VTM node https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/993fa93f2d [4/5] arm/dts: k3-j7200-r5-common: Hook buck1_reg to vtm supply https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/9925c76752 [5/5] configs: j7200_evm_r5_defconfig: Enable AVS, PMIC and dependent configs https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/672758829a -- Thanks and Regards, Lokesh
Re: [PATCH v2 0/5] arm: dts: Add PMIC node for J7200
On Wed, 23 Jun 2021 16:14:49 -0500, Gowtham Tammana wrote: > The J7200 EVM has PMIC LP876441 for supporting CPU AVS. This patchset > adds dt nodes, compatible string, and configs to enable the > corresponding driver. > > v2: > - rebased the changes are reordered patches 3/4 > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/5] power: pmic: tps65941: Add compatible for LP876441 https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/d4a344c393 [2/5] arm/dts: k3-j7200-r5-common: Add pmic lp876441 node https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/cbd49ed9d6 [3/5] arm/dts: k3-j7200-r5-common: Add VTM node https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/993fa93f2d [4/5] arm/dts: k3-j7200-r5-common: Hook buck1_reg to vtm supply https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/9925c76752 [5/5] configs: j7200_evm_r5_defconfig: Enable AVS, PMIC and dependent configs https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/672758829a -- Thanks and Regards, Lokesh
Re: [PATCH v3 0/5] Add SIMATIC IOT2050 board support
Hi Jan, On 14/07/21 3:09 pm, Jan Kiszka wrote: > On 14.07.21 11:29, Lokesh Vutla wrote: >> Hi Jan, >> >> On 12/06/21 1:12 am, Jan Kiszka wrote: >>> This is the baseline support for the SIMATIC IOT2050 devices. >>> >>> Changes in v3: >>> - rebased >>> - addressed several checkpatch warnings >>> - a few #ifdef -> IS_ENABLED conversions >>> - comment marker for SPDK identifier in .S file >>> - trailing whitespaces >>> - factored out rti_wdt_load_fw (less #ifdef) >> >> I see that there is no conclusion yet for the Watchdog firmware support. But >> that can be split out from this series IMO. Can you repost with basic >> support so >> that I can merge the series. Watchdog support can be dealt separately. > > I will eventually look again into that loading topic, but I would also > consider that non-critical to merge it this way first and cleanup later > if it actually turns out to be solvable in an equivalent way (result is > part of u-boot proper image) via binman. Even the configuration > interface may stay the same. > > If you still have concerns, skip patch 4 and 5 - though that would > affect an increasing demand of our users for this important feature. First 3 patches of the series throws a build error for me: https://source.denx.de/u-boot/custodians/u-boot-ti/-/jobs/292183 Can you take a look? Thanks and regards, Lokesh > > Jan >
Re: [PATCH v3 0/5] Add SIMATIC IOT2050 board support
On 14/07/21 3:09 pm, Jan Kiszka wrote: > On 14.07.21 11:29, Lokesh Vutla wrote: >> Hi Jan, >> >> On 12/06/21 1:12 am, Jan Kiszka wrote: >>> This is the baseline support for the SIMATIC IOT2050 devices. >>> >>> Changes in v3: >>> - rebased >>> - addressed several checkpatch warnings >>> - a few #ifdef -> IS_ENABLED conversions >>> - comment marker for SPDK identifier in .S file >>> - trailing whitespaces >>> - factored out rti_wdt_load_fw (less #ifdef) >> >> I see that there is no conclusion yet for the Watchdog firmware support. But >> that can be split out from this series IMO. Can you repost with basic >> support so >> that I can merge the series. Watchdog support can be dealt separately. > > I will eventually look again into that loading topic, but I would also > consider that non-critical to merge it this way first and cleanup later > if it actually turns out to be solvable in an equivalent way (result is > part of u-boot proper image) via binman. Even the configuration > interface may stay the same. I am fine if Tom or Simon agrees on this. Thanks and regards, Lokesh > > If you still have concerns, skip patch 4 and 5 - though that would > affect an increasing demand of our users for this important feature. > > Jan >
Re: [PATCH v3 0/5] Add SIMATIC IOT2050 board support
Hi Jan, On 12/06/21 1:12 am, Jan Kiszka wrote: > This is the baseline support for the SIMATIC IOT2050 devices. > > Changes in v3: > - rebased > - addressed several checkpatch warnings > - a few #ifdef -> IS_ENABLED conversions > - comment marker for SPDK identifier in .S file > - trailing whitespaces > - factored out rti_wdt_load_fw (less #ifdef) I see that there is no conclusion yet for the Watchdog firmware support. But that can be split out from this series IMO. Can you repost with basic support so that I can merge the series. Watchdog support can be dealt separately. Thanks and regards, Lokesh > > Changes in v2: > - rebased > - sync with upstream-accepted DT > - add boot switch > - include watchdog support > > Allows to boot mainline 5.10 kernels, but not the original BSP-derived > kernel we currently ship as reference. This is due to the TI sysfw ABI > breakages between 2.x and 3.x. We will soon provide a transitional > kernel that allows booting both firmware ABIs - as long as full upstream > kernel support is work in progress. > > Note that this baseline support lacks Ethernet drivers. We are working > closely with TI to ensure that the to-be-upstreamed icssg-prueth driver > will work both with new SR2.0 AM65x silicon as well as with SR1.0 which > is used in the currently shipped IOT2050 devices. > > A staging tree for complete IOT2050 support can be found at [1]. Full > image integration is available via [2]. > > Jan > > [1] https://github.com/siemens/u-boot/commits/jan/iot2050 > [2] https://github.com/siemens/meta-iot2050 > > Jan Kiszka (5): > arm: dts: Add IOT2050 device tree files > board: siemens: Add support for SIMATIC IOT2050 devices > arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry > watchdog: rti_wdt: Add support for loading firmware > configs: iot2050: Enable watchdog support, but do not auto-start it > > arch/arm/dts/Makefile | 7 +- > arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 105 +++ > .../dts/k3-am65-iot2050-common-u-boot.dtsi| 103 +++ > arch/arm/dts/k3-am65-iot2050-common.dtsi | 655 ++ > arch/arm/dts/k3-am65-iot2050-spl.dts | 16 + > arch/arm/dts/k3-am65-mcu.dtsi | 9 + > arch/arm/dts/k3-am6528-iot2050-basic.dts | 67 ++ > arch/arm/dts/k3-am6548-iot2050-advanced.dts | 66 ++ > arch/arm/mach-k3/Kconfig | 1 + > board/siemens/iot2050/Kconfig | 32 + > board/siemens/iot2050/MAINTAINERS | 8 + > board/siemens/iot2050/Makefile| 10 + > board/siemens/iot2050/README | 65 ++ > board/siemens/iot2050/board.c | 278 > board/siemens/iot2050/config.mk | 8 + > configs/iot2050_defconfig | 146 > drivers/watchdog/Kconfig | 20 + > drivers/watchdog/Makefile | 5 + > drivers/watchdog/rti_wdt.c| 72 ++ > drivers/watchdog/rti_wdt_fw.S | 20 + > include/configs/iot2050.h | 60 ++ > 21 files changed, 1752 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi > create mode 100644 arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi > create mode 100644 arch/arm/dts/k3-am65-iot2050-common.dtsi > create mode 100644 arch/arm/dts/k3-am65-iot2050-spl.dts > create mode 100644 arch/arm/dts/k3-am6528-iot2050-basic.dts > create mode 100644 arch/arm/dts/k3-am6548-iot2050-advanced.dts > create mode 100644 board/siemens/iot2050/Kconfig > create mode 100644 board/siemens/iot2050/MAINTAINERS > create mode 100644 board/siemens/iot2050/Makefile > create mode 100644 board/siemens/iot2050/README > create mode 100644 board/siemens/iot2050/board.c > create mode 100644 board/siemens/iot2050/config.mk > create mode 100644 configs/iot2050_defconfig > create mode 100644 drivers/watchdog/rti_wdt_fw.S > create mode 100644 include/configs/iot2050.h >
Re: [PATCH] arm: omap4: Disable USB_TTY and related options
On Wed, 7 Jul 2021 21:43:48 -0400, Tom Rini wrote: > The usbtty functionality is not currently used on these two platforms, > disable it. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] arm: omap4: Disable USB_TTY and related options https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0703ce018d -- Thanks and Regards, Lokesh
Re: [PATCHv2] configs: am65x_evm: Switch envboot out for distro_bootcmd
On Tue, 13 Jul 2021 10:11:39 -0400, Tom Rini wrote: > Swap out the TI-centric "envboot" logic for the generic distro_bootcmd > logic for the bootcmd we run before trying to do something more complex > involving additional firmware, etc. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] configs: am65x_evm: Switch envboot out for distro_bootcmd https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/6e188a4f7d -- Thanks and Regards, Lokesh
Re: [PATCH] ti: am335x_evm: Switch to DISTRO_BOOT only
On Thu, 10 Jun 2021 19:01:47 -0400, Tom Rini wrote: > Remove the environment support for various legacy boot methods. With > this, we will now default to booting any distribution that follows the > generic distro boot framework and no longer attempt to boot various > legacy (to this SoC) scripts/etc. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] ti: am335x_evm: Switch to DISTRO_BOOT only https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/2c732ee143 -- Thanks and Regards, Lokesh
Re: [PATCH] configs: j721e_evm: Switch envboot out for distro_bootcmd
On Thu, 1 Jul 2021 10:27:43 -0400, Tom Rini wrote: > Swap out the TI-centric "envboot" logic for the generic distro_bootcmd > logic for the bootcmd we run before trying to do something more complex > involving additional firmware, etc. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] configs: j721e_evm: Switch envboot out for distro_bootcmd https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/bb721e7edb -- Thanks and Regards, Lokesh
Re: [PATCH 1/3] ti: am43xx_evm: Switch to DISTRO_BOOT only
On Thu, 1 Jul 2021 09:26:10 -0400, Tom Rini wrote: > Remove the environment support for various legacy boot methods. With > this, we will now default to booting any distribution that follows the > generic distro boot framework and no longer attempt to boot various > legacy (to this SoC) scripts/etc. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/3] ti: am43xx_evm: Switch to DISTRO_BOOT only https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/19414cfeb0 [2/3] arm: ti: environment: Move in to https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/b2df6e066f [3/3] ti: omap5: Switch to generic distro boot for non-Android cases https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/b29343e471 -- Thanks and Regards, Lokesh
Re: [PATCH v4 00/18] am335x, guardian: update board specific changes
On Fri, 11 Jun 2021 16:13:32 +, gireesh.hirem...@in.bosch.com wrote: > address the v3 review comments > > >There are some build errors with this series, can you take a look?: > >https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-ti%2F-%2Fjobs%2F275470data=04%7C01%7CGireesh.Hiremath%40in.bosch.com%7Cba3f0660388b4b6a05c808d929a73cca%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C637586620518929932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CM6KhlG0OOJM4iSpXNcqXZXAFI9IzguGEn2%2BaI1fCOA%3Dreserved=0 > > > >Thanks and regards, > >Lokesh > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [01/18] configs: am335x_guardian: Enable clock driver https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/480bb3a3ac [02/18] am335x, guardian: mem: Add board dependent mem values https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/ebc75a558b [03/18] configs: am335x_guardian: add ubi fastmap support https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/5e0f3c76ae [04/18] am335x, guardian: set tftp_load_addr in environment https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/8b37a65af1 [05/18] configs: am335x_guardian: add memtest configs https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/29ddc64f34 [06/18] am335x, guardian: Update pinmux configuration https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/b44a5bdb2f [07/18] am335x, guardian: set environment variable autoload to no https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/f15c87f911 [08/18] am335x, guardian: code cleanup and boot optimization https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/811ab6d8e4 [09/18] configs: am335x_guardian: set boot delay https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/509f99a012 [10/18] configs: am335x_guardian: disable spl command https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/18fef39c5c [11/18] am335x, guardian: update swi logic https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/81dedc80ca [12/18] am335x, guardian: Enable backlight https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/caa92aec8d [13/18] configs: am335x_guardian: Enable display config https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/df06cac2b6 [14/18] drivers: video: hx8238 fix build bug https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/20a59f0b90 [15/18] am335x, guardian: Enable panel driver Himax HX8238D https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/890cd8cf10 [16/18] am335x, guardian: software update available status is stored in AM3352 RTC scracth register https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/211000a99c [17/18] configs: am335x_guardian: Enable bootcount nvmem support https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/4da5f9c3ba [18/18] configs: am335x_guardian: add register maps support https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/b049ec5f6d -- Thanks and Regards, Lokesh
Re: [PATCH v2 0/5] remoteproc: pru: Add remoteproc support for AM65 PRUSS
On Tue, 22 Jun 2021 12:04:26 +0530, Lokesh Vutla wrote: > This series adds support for remoteproc driver for PRUSS in AM65 SoCs. > > Changes since v1: > - Fixed checkpatch warnings > > Keerthy (2): > soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs > remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/5] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/76d99d1c14 [2/5] remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/223b2a1900 [3/5] arm: dts: k3-am654-base-board: Add r5 specific u-boot dtsi https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/5b03be065d [4/5] arm: dts: ti: k3-am65-main: Add ICSSG nodes https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/b446ca963a [5/5] configs: am65x_evm_a53: Enable PRUSS remoteproc https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/b2661c3caf -- Thanks and Regards, Lokesh
Re: [PATCH] arm: mach-k3: am642_init: Add missing ddr guard
On Thu, 24 Jun 2021 12:16:14 -0500, Gowtham Tammana wrote: > The `struct udevice *` reference is needed for either of the > K3_LOAD_SYSFW, K3_AM64_DDRSS config guards. Adding the missing > K3_AM64_DDRSS guard. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] arm: mach-k3: am642_init: Add missing ddr guard https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a27dd704ad -- Thanks and Regards, Lokesh
Re: [PATCH V2 0/3] Make omap3 board functions static
On Fri, 25 Jun 2021 14:23:05 -0500, Adam Ford wrote: > Several functions in omap3/board.c are only used in that file, and > two of them are only called when certain conditions are true in an > ifdef. Rearange these functions to also be inside the ifdef and > make them static. > > Before: > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/3] arm: omap3: Make try_unlock_memory() static https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/c19d0431e9 [2/3] arm: omap3: Make secureworld_exit() static https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/c7c426aeac [3/3] arm: omap3: Make secure_unlock_mem() static https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/834f72af36 -- Thanks and Regards, Lokesh
Re: [PATCH v2 0/2] AM64: Update the locations of various elements in SRAM
On Wed, 16 Jun 2021 22:08:19 +0530, Aswath Govindraju wrote: > The following series of patches, > - Update the location of TF-A > - Indicate reserved locations for DMSC code and secure proxy > > changes since v1: > - Moved the load address of TF-A to 0x701c to account for future > increments in the size of TF-A > - Reworded the title of patch 2 > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/2] configs: am64x_evm_a53_defconfig: Move TF-A load address to 0x701c https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/7500c2febe [2/2] arm: dts: k3-am64-main: Reserve OCMRAM for DMSC-lite and secure proxy communication https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/9199110350 -- Thanks and Regards, Lokesh
Re: [PATCH] configs: am3517_evm: Fix boot hang
On Sat, 26 Jun 2021 08:42:58 -0500, Adam Ford wrote: > SPL is really tight on space, so decrease a little memory that we > allocate in order to fix boot hang. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] configs: am3517_evm: Fix boot hang https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/56771f5378 -- Thanks and Regards, Lokesh
Re: [PATCH] configs: omap3x_logic: Fix boot hang by reducing SYS_MALLOC_F_LEN
On Fri, 25 Jun 2021 13:57:17 -0500, Adam Ford wrote: > The AM3517 uses SYS_MALLOC_F_LEN of size 0x3000, but the rest of > the OMAP3 boards from LogicPD / BeaconEmbedded use 0x4000, but > they don't boot SPL. > > Reduce the malloc size to restore booting. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] configs: omap3x_logic: Fix boot hang by reducing SYS_MALLOC_F_LEN https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/3141bf0c09 -- Thanks and Regards, Lokesh
Re: [PATCH] configs: am65x_evm: Switch envboot out for distro_bootcmd
On 02/07/21 1:34 am, Tom Rini wrote:
> Swap out the TI-centric "envboot" logic for the generic distro_bootcmd
> logic for the bootcmd we run before trying to do something more complex
> involving additional firmware, etc.
>
> Cc: Lokesh Vutla
> Signed-off-by: Tom Rini
This is causing build errors for am6 platforms.
https://source.denx.de/u-boot/custodians/u-boot-ti/-/jobs/291139
Thanks and regards,
Lokesh
> ---
> configs/am65x_evm_a53_defconfig | 2 +-
> include/configs/am65x_evm.h | 10 --
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
> index 6f9309e17147..eefcdfa36571 100644
> --- a/configs/am65x_evm_a53_defconfig
> +++ b/configs/am65x_evm_a53_defconfig
> @@ -29,7 +29,7 @@ CONFIG_SPL_LOAD_FIT=y
> CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
> # CONFIG_USE_SPL_FIT_GENERATOR is not set
> CONFIG_OF_BOARD_SETUP=y
> -CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
> boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run
> get_overlay_${boot}; run run_kern"
> +CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run init_${boot}; run
> boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run
> get_overlay_${boot}; run run_kern"
> CONFIG_LOGLEVEL=7
> CONFIG_CONSOLE_MUX=y
> CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
> index 8c50fe9d11ff..749689ca3610 100644
> --- a/include/configs/am65x_evm.h
> +++ b/include/configs/am65x_evm.h
> @@ -10,7 +10,6 @@
> #define __CONFIG_AM654_EVM_H
>
> #include
> -#include
> #include
> #include
> #include
> @@ -126,6 +125,12 @@
> DFU_ALT_INFO_EMMC \
> DFU_ALT_INFO_OSPI
>
> +#define BOOT_TARGET_DEVICES(func) \
> + func(MMC, mmc, 1) \
> + func(MMC, mmc, 0)
> +
> +#include
> +
> /* Incorporate settings into the U-Boot environment */
> #define CONFIG_EXTRA_ENV_SETTINGS\
> DEFAULT_LINUX_BOOT_ENV \
> @@ -136,7 +141,8 @@
> EXTRA_ENV_AM65X_BOARD_SETTINGS_MTD \
> EXTRA_ENV_AM65X_BOARD_SETTINGS_UBI \
> EXTRA_ENV_RPROC_SETTINGS\
> - EXTRA_ENV_DFUARGS
> + EXTRA_ENV_DFUARGS \
> + BOOTENV
>
> #define CONFIG_SYS_USB_FAT_BOOT_PARTITION 1
>
>
Re: [PATCH] configs: omap3x_logic: Enable LTO on more LogicPD OMAP3 boards
On 26/06/21 4:51 pm, Adam Ford wrote: > There are five omap3 based boards from LogicPD. Two of them > have added LTO support. Add the remaining three to use LTO. > > Signed-off-by: Adam Ford There are many merge conflicts with this patch. Can you rebase on top of latest master and repost? Thanks and regards, Lokesh > > diff --git a/configs/omap35_logic_defconfig b/configs/omap35_logic_defconfig > index 9ff5929b96..d359e32a36 100644 > --- a/configs/omap35_logic_defconfig > +++ b/configs/omap35_logic_defconfig > @@ -12,6 +12,7 @@ CONFIG_TARGET_OMAP3_LOGIC=y > # CONFIG_SPL_OMAP3_ID_NAND is not set > CONFIG_SPL=y > CONFIG_DEFAULT_DEVICE_TREE="logicpd-torpedo-35xx-devkit" > +CONFIG_LTO=y > CONFIG_DISTRO_DEFAULTS=y > CONFIG_ANDROID_BOOT_IMAGE=y > # CONFIG_USE_BOOTCOMMAND is not set > diff --git a/configs/omap35_logic_somlv_defconfig > b/configs/omap35_logic_somlv_defconfig > index 2cc7060de5..d221ace735 100644 > --- a/configs/omap35_logic_somlv_defconfig > +++ b/configs/omap35_logic_somlv_defconfig > @@ -12,6 +12,7 @@ CONFIG_TARGET_OMAP3_LOGIC=y > # CONFIG_SPL_OMAP3_ID_NAND is not set > CONFIG_SPL=y > CONFIG_DEFAULT_DEVICE_TREE="logicpd-som-lv-35xx-devkit" > +CONFIG_LTO=y > CONFIG_DISTRO_DEFAULTS=y > CONFIG_ANDROID_BOOT_IMAGE=y > # CONFIG_USE_BOOTCOMMAND is not set > diff --git a/configs/omap3_logic_somlv_defconfig > b/configs/omap3_logic_somlv_defconfig > index 90c670cee2..e2b71c5ab6 100644 > --- a/configs/omap3_logic_somlv_defconfig > +++ b/configs/omap3_logic_somlv_defconfig > @@ -12,6 +12,7 @@ CONFIG_TARGET_OMAP3_LOGIC=y > # CONFIG_SPL_OMAP3_ID_NAND is not set > CONFIG_SPL=y > CONFIG_DEFAULT_DEVICE_TREE="logicpd-som-lv-37xx-devkit" > +CONFIG_LTO=y > CONFIG_DISTRO_DEFAULTS=y > CONFIG_ANDROID_BOOT_IMAGE=y > # CONFIG_USE_BOOTCOMMAND is not set >
Re: [PATCH v2 0/5] arm: dts: Add PMIC node for J7200
On 24/06/21 2:44 am, Gowtham Tammana wrote: > The J7200 EVM has PMIC LP876441 for supporting CPU AVS. This patchset > adds dt nodes, compatible string, and configs to enable the > corresponding driver. > > v2: > - rebased the changes are reordered patches 3/4 There are minor conflicts with latest master. Can you rebase and repost? Thanks and regards, Lokesh > > v1: > - https://lore.kernel.org/u-boot/20200915113633.25449-1-g-tamm...@ti.com/ > > Gowtham Tammana (5): > power: pmic: tps65941: Add compatible for LP876441 > arm/dts: k3-j7200-r5-common: Add pmic lp876441 node > arm/dts: k3-j7200-r5-common: Add VTM node > arm/dts: k3-j7200-r5-common: Hook buck1_reg to vtm supply > configs: j7200_evm_r5_defconfig: Enable AVS, PMIC and dependent > configs > > .../arm/dts/k3-j7200-r5-common-proc-board.dts | 38 +++ > configs/j7200_evm_r5_defconfig| 6 +++ > drivers/power/pmic/tps65941.c | 1 + > include/power/tps65941.h | 1 + > 4 files changed, 46 insertions(+) >
Re: [PATCH v2 5/5] configs: am335x_evm: Fix BeagleBone Green DTB selection
On 13/07/21 1:44 am, Paul Barker wrote: > The function board_is_bone_lt() returns true for the BeagleBone Green, > the BeagleBone Enhanced and the BeagleBone Black. Therefore when > selecting which devicetree to use we must ensure that the more specific > functions board_is_bbg1() and board_is_bben() are checked first > otherwise all three devices would end up using the am335x-boneblack > devicetree. This can be achieved by placing the relevant devicetree > names (am335x-sancloud-bbe and am335x-bonegreen) before am335x-boneblack > in CONFIG_OF_LIST. Such restrictions should be handled inside board_fit_config_name_match() and hiden from user configuration. Can you update the board_fit_config_name_match() instead of updating defconfig? Thanks and regards, Lokesh
Re: [PATCH 1/4] arm: dts: am335x-boneblack: Extract common config
On 12/07/21 9:53 pm, Paul Barker wrote: > On Thu, 17 Jun 2021 12:27:55 + > Tom Rini wrote: > >> On Thu, Jun 17, 2021 at 11:31:56AM +0100, Paul Barker wrote: >>> On Thu, 17 Jun 2021 11:05:46 +0100 >>> Peter Robinson wrote: >>> On Thu, Jun 17, 2021 at 10:03 AM Paul Barker wrote: > > Configuration which is shared between the BeagleBone Black and > derivative boards like the Sancloud BeagleBone Enhanced (BBE) is > moved to a common dtsi file to prevent duplication. Are these being sent upstream to the linux kernel? >>> >>> The upstream kernel already has am335x-boneblack-common.dtsi and >>> am335x-sancloud-bbe.dts files, since 2016 and 2018 respectively. As >>> these files fell out of sync over 4 years ago I've assumed there is no >>> need to keep them in sync. We could try to resync things but that would >>> lead to an unnecessary risk of breakage, I don't have every BeagleBone >>> Black derivative board on hand to fully test such a resync. >> >> Adding in Lokesh. It would be really good to get as many of these files >> back in sync again as possible and then keep them in sync periodically. >> As I don't think there's been any breaking fixes in the dts files again, >> there shouldn't be any problems. >> > > Hi Tom, > > As there's been no reply from Lokesh I'd like to move forward with > these updates if we can. I'm happy to resync the SanCloud dts files > plus what we include, I think that will also involve copying over at > least one more dt-bindings header as well. > > I'll send an updated series shortly. Sorry for the delayed response as I was out of office last week. yes, please sync the entire dts. Thanks and regards, Lokesh > > Thanks, >
[PATCH v2 5/5] configs: am65x_evm_a53: Enable PRUSS remoteproc
Enable PRUSS remoteproc driver for AM65 Signed-off-by: Lokesh Vutla --- configs/am65x_evm_a53_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 01e027f607..512849f983 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -139,12 +139,14 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_REMOTEPROC_TI_K3_R5F=y +CONFIG_REMOTEPROC_TI_PRU=y CONFIG_DM_RESET=y CONFIG_RESET_TI_SCI=y CONFIG_DM_SERIAL=y CONFIG_SOC_DEVICE=y CONFIG_SOC_DEVICE_TI_K3=y CONFIG_SOC_TI=y +CONFIG_TI_PRUSS=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_CADENCE_QSPI=y -- 2.31.1
[PATCH v2 4/5] arm: dts: ti: k3-am65-main: Add ICSSG nodes
Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems
that are present on the K3 AM65x SoCs. The three ICSSGs are identical
to each other for the most part, with the ICSSG2 supporting slightly
enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance
is represented by a PRUSS subsystem node. These nodes are enabled by
default.
DT nodes are fetch from Linux 5.13 Kernel.
Signed-off-by: Lokesh Vutla
---
arch/arm/dts/k3-am65-main.dtsi | 463 +++
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 72 +++
2 files changed, 535 insertions(+)
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index cabdba85e0..669484b0dd 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -926,4 +926,467 @@
clocks = <_tbclk 5>, <_clks 45 0>;
clock-names = "tbclk", "fck";
};
+
+ icssg0: icssg@b00 {
+ compatible = "ti,am654-icssg";
+ reg = <0x00 0xb00 0x00 0x8>;
+ power-domains = <_pds 62 TI_SCI_PD_EXCLUSIVE>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0xb00 0x8>;
+
+ icssg0_mem: memories@0 {
+ reg = <0x0 0x2000>,
+ <0x2000 0x2000>,
+ <0x1 0x1>;
+ reg-names = "dram0", "dram1",
+ "shrdram2";
+ };
+
+ icssg0_cfg: cfg@26000 {
+ compatible = "ti,pruss-cfg", "syscon";
+ reg = <0x26000 0x200>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x26000 0x2000>;
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ icssg0_coreclk_mux: coreclk-mux@3c {
+ reg = <0x3c>;
+ #clock-cells = <0>;
+ clocks = <_clks 62 19>, /*
icssg0_core_clk */
+<_clks 62 3>; /*
icssg0_iclk */
+ assigned-clocks = <_coreclk_mux>;
+ assigned-clock-parents = <_clks 62
3>;
+ };
+
+ icssg0_iepclk_mux: iepclk-mux@30 {
+ reg = <0x30>;
+ #clock-cells = <0>;
+ clocks = <_clks 62 10>, /*
icssg0_iep_clk */
+<_coreclk_mux>; /*
core_clk */
+ assigned-clocks = <_iepclk_mux>;
+ assigned-clock-parents =
<_coreclk_mux>;
+ };
+ };
+ };
+
+ icssg0_iep0: iep@2e000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2e000 0x1000>;
+ clocks = <_iepclk_mux>;
+ };
+
+ icssg0_iep1: iep@2f000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2f000 0x1000>;
+ clocks = <_iepclk_mux>;
+ };
+
+ icssg0_mii_rt: mii-rt@32000 {
+ compatible = "ti,pruss-mii", "syscon";
+ reg = <0x32000 0x100>;
+ };
+
+ icssg0_mii_g_rt: mii-g-rt@33000 {
+ compatible = "ti,pruss-mii-g", "syscon";
+ reg = <0x33000 0x1000>;
+ };
+
+ icssg0_intc: interrupt-controller@2 {
+ compatible = "ti,icssg-intc";
+ reg = <0x2 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+;
+ interrupt-names = "host_intr0", "host_intr1",
+
[PATCH v2 3/5] arm: dts: k3-am654-base-board: Add r5 specific u-boot dtsi
So far all the u-boot specific properties for both r5 and a53 are
placed in k3-am654-base-board-u-boot.dtsi. But there are few a53
nodes that should be updated but doesn't belong to r5. So create a
separate r5 specific u-boot dtsi.
Signed-off-by: Lokesh Vutla
---
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 191 +
.../dts/k3-am654-r5-base-board-u-boot.dtsi| 193 ++
arch/arm/dts/k3-am654-r5-base-board.dts | 2 -
3 files changed, 195 insertions(+), 191 deletions(-)
create mode 100644 arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index b0602d1dad..77b7d3f452 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -1,193 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2018-2021 Texas Instruments Incorporated - http://www.ti.com/
*/
-#include
-#include
-
-/ {
- chosen {
- stdout-path = "serial2:115200n8";
- };
-
- aliases {
- serial2 = _uart0;
- ethernet0 = _port1;
- usb0 =
- usb1 =
- spi0 =
- spi1 =
- };
-};
-
-_main{
- u-boot,dm-spl;
- main-navss {
- u-boot,dm-spl;
- };
-};
-
-_mcu {
- u-boot,dm-spl;
-
- mcu-navss {
- u-boot,dm-spl;
-
- ringacc@2b80 {
- u-boot,dm-spl;
- ti,dma-ring-reset-quirk;
- };
-
- dma-controller@285c {
- u-boot,dm-spl;
- };
- };
-};
-
-_wakeup {
- u-boot,dm-spl;
-
- chipid@4314 {
- u-boot,dm-spl;
- };
-};
-
-_proxy_main {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
- k3_sysreset: sysreset-controller {
- compatible = "ti,sci-sysreset";
- u-boot,dm-spl;
- };
-};
-
-_pds {
- u-boot,dm-spl;
-};
-
-_clks {
- u-boot,dm-spl;
-};
-
-_reset {
- u-boot,dm-spl;
-};
-
-_pmx0 {
- u-boot,dm-spl;
-
- wkup_i2c0_pins_default {
- u-boot,dm-spl;
- };
-};
-
-_pmx0 {
- u-boot,dm-spl;
- usb0_pins_default: usb0_pins_default {
- pinctrl-single,pins = <
- AM65X_IOPAD(0x02bc, PIN_OUTPUT, 0) /* (AD9)
USB0_DRVVBUS */
- >;
- u-boot,dm-spl;
- };
-};
-
-_uart0_pins_default {
- u-boot,dm-spl;
-};
-
-_pmx1 {
- u-boot,dm-spl;
-};
-
-_pmx0 {
- mcu-fss0-ospi0-pins-default {
- u-boot,dm-spl;
- };
-};
-
-_uart0 {
- u-boot,dm-spl;
-};
-
-_mmc0_pins_default {
- u-boot,dm-spl;
-};
-
-_mmc1_pins_default {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
-_mdio {
- phy0: ethernet-phy@0 {
- reg = <0>;
- /* TODO: phy reset:
TCA9555RTWR(i2c:0x21)[p04].GPIO_MCU_RGMII_RSTN */
- ti,rx-internal-delay = ;
- ti,fifo-depth = ;
- };
-};
-
-_cpsw {
- reg = <0x0 0x4600 0x0 0x20>,
- <0x0 0x40f00200 0x0 0x2>;
- reg-names = "cpsw_nuss", "mac_efuse";
- /delete-property/ ranges;
-
- cpsw-phy-sel@40f04040 {
- compatible = "ti,am654-cpsw-phy-sel";
- reg= <0x0 0x40f04040 0x0 0x4>;
- reg-names = "gmii-sel";
- };
-};
-
-_i2c0 {
- u-boot,dm-spl;
-};
-
- {
- dr_mode = "peripheral";
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-
-flash@0{
- u-boot,dm-spl;
- };
-};
-
-_0 {
- status = "okay";
- u-boot,dm-spl;
-};
-
-_phy {
- status = "okay";
- u-boot,dm-spl;
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins_default>;
- dr_mode = "host";
- u-boot,dm-spl;
-};
-
-_conf {
- u-boot,dm-spl;
-};
+#include "k3-am654-r5-base-board-u-boot.dtsi"
diff --git a/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
new file mode 100644
index 00..932a65b906
--- /dev/null
+++ b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018-2021 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+
+/ {
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ aliases {
+ serial2 = _uart0;
+ ethernet0 = _port1;
+ usb0 =
+ usb1 =
+ spi0 =
+
[PATCH v2 2/5] remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs
From: Keerthy
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
processor subsystem, commonly referred to as ICSSG. Each ICSSG processor
subsystem on AM65x SR1.0 contains two primary PRU cores and two new
auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised
ICSSG IP that is based off the subsequent IP revision used on J721E
SoCs. This IP instance has two new custom auxiliary PRU cores called
Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs.
Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than
a PRU), Control and debug feature sets, but is different in terms of
sub-modules integrated around it and does not have the full capabilities
associated with a PRU core. The RTU core is typically used to aid a
PRU core in accelerating data transfers, while the Tx_PRU cores is
normally used to control the TX L2 FIFO if enabled in Ethernet
applications. Both can also be used to run independent applications.
The RTU and Tx_PRU cores though share the same Data RAMs as the PRU
cores, so the memories have to be partitioned carefully between different
applications. The new cores also support a new sub-module called Task
Manager to support two different context thread executions.
The driver currently supports the AM65xx SoC
Signed-off-by: Keerthy
Signed-off-by: Suman Anna
Signed-off-by: Murali Karicheri
Signed-off-by: Roger Quadros
Signed-off-by: Lokesh Vutla
---
MAINTAINERS| 1 +
drivers/remoteproc/Kconfig | 11 +
drivers/remoteproc/Makefile| 1 +
drivers/remoteproc/pru_rproc.c | 461 +
4 files changed, 474 insertions(+)
create mode 100644 drivers/remoteproc/pru_rproc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b85a968ac3..bc809acd01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -513,6 +513,7 @@ F: drivers/phy/phy-ti-am654.c
F: drivers/phy/ti-pipe3-phy.c
F: drivers/ram/k3*
F: drivers/remoteproc/k3_system_controller.c
+F: drivers/remoteproc/pruc_rpoc.c
F: drivers/remoteproc/ti*
F: drivers/reset/reset-ti-sci.c
F: drivers/rtc/davinci.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 7c2e4804b5..24e536463b 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -81,4 +81,15 @@ config REMOTEPROC_TI_POWER
help
Say 'y' here to add support for TI power processors such as those
found on certain TI keystone and OMAP generation SoCs.
+
+config REMOTEPROC_TI_PRU
+ bool "Support for TI's K3 based PRU remoteproc driver"
+ select REMOTEPROC
+ depends on DM
+ depends on TI_PRUSS
+ depends on ARCH_K3
+ depends on OF_CONTROL
+ help
+ Say 'y' here to add support for TI' K3 remoteproc driver.
+
endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 69ae7bd1e8..f0e83451d6 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
+obj-$(CONFIG_REMOTEPROC_TI_PRU) += pru_rproc.o
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
new file mode 100644
index 00..924070a76b
--- /dev/null
+++ b/drivers/remoteproc/pru_rproc.c
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PRU-RTU remoteproc driver for various SoCs
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Keerthy
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PRU_ICSS_PRU_CTRL registers */
+#define PRU_CTRL_CTRL 0x
+#define PRU_CTRL_STS 0x0004
+#define PRU_CTRL_WAKEUP_EN 0x0008
+#define PRU_CTRL_CYCLE 0x000C
+#define PRU_CTRL_STALL 0x0010
+#define PRU_CTRL_CTBIR00x0020
+#define PRU_CTRL_CTBIR10x0024
+#define PRU_CTRL_CTPPR00x0028
+#define PRU_CTRL_CTPPR10x002C
+
+/* CTRL register bit-fields */
+#define CTRL_CTRL_SOFT_RST_N BIT(0)
+#define CTRL_CTRL_EN BIT(1)
+#define CTRL_CTRL_SLEEPING BIT(2)
+#define CTRL_CTRL_CTR_EN BIT(3)
+#define CTRL_CTRL_SINGLE_STEP BIT(8)
+#define CTRL_CTRL_RUNSTATE BIT(15)
+
+#define RPROC_FLAGS_SHIFT 16
+#define RPROC_FLAGS_NONE 0
+#define RPROC_FLAGS_ELF_PHDR BIT(0 + RPROC_FLAGS_SHIFT)
+#define RPROC_FLAGS_ELF_SHDR BIT(1 + RPROC_FLAGS_SHIFT)
+
+/**
+ * enum pru_mem - PRU core memory range identifiers
+ */
+enum pru_mem {
+ PRU_MEM_IRAM = 0,
+ PRU_MEM_CTRL,
+ PRU_MEM_DEBUG,
+ PRU_MEM_MAX,
+};
+
+struct pru_privdata {
+ phys_addr_t pru_iram;
+ phys_addr_t pru_ctrl;
+ phys_addr_t
[PATCH v2 1/5] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
From: Keerthy
The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present of various TI SoCs such as
AM335x or AM437x or the AM654x family. Each SoC can have
one or more PRUSS instances that may or may not be identical.
The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, and
an interrupt controller. The programmable nature of the PRUs
provide flexibility to implement custom peripheral interfaces,
fast real-time responses, or specialized data handling.
Add support for pruss driver. Currently am654x family
is supported.
Signed-off-by: Keerthy
Signed-off-by: Roger Quadros
Signed-off-by: Lokesh Vutla
---
MAINTAINERS | 1 +
drivers/soc/ti/Kconfig | 11 ++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/pruss.c | 217 +
include/linux/pruss_driver.h | 227 +++
5 files changed, 457 insertions(+)
create mode 100644 drivers/soc/ti/pruss.c
create mode 100644 include/linux/pruss_driver.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 86ff5e04a6..b85a968ac3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -522,6 +522,7 @@ F: drivers/sysreset/sysreset-ti-sci.c
F: drivers/thermal/ti-bandgap.c
F: drivers/timer/omap-timer.c
F: drivers/watchdog/omap_wdt.c
+F: include/linux/pruss_driver.h
F: include/linux/soc/ti/
ARM U8500
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index e4f8834448..0ee21f9904 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -23,4 +23,15 @@ config TI_KEYSTONE_SERDES
SerDes driver for Keystone SoC used for ethernet support on TI
K2 platforms.
+config TI_PRUSS
+ bool "Support for TI's K3 based Pruss driver"
+ depends on DM
+ depends on ARCH_K3
+ depends on OF_CONTROL
+ depends on SYSCON
+ help
+ Support for TI PRU-ICSSG subsystem.
+ Currently supported on AM65xx SoCs Say Y here to support the
+ Programmable Realtime Unit (PRU).
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 4ec04ee125..34f80aad29 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_TI_K3_NAVSS_RINGACC) += k3-navss-ringacc.o
obj-$(CONFIG_TI_KEYSTONE_SERDES) += keystone_serdes.o
+obj-$(CONFIG_TI_PRUSS) += pruss.o
diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
new file mode 100644
index 00..461390925d
--- /dev/null
+++ b/drivers/soc/ti/pruss.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PRU-ICSS platform driver for various TI SoCs
+ *
+ * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PRUSS_CFG_IEPCLK 0x30
+#define ICSSG_CFG_CORE_SYNC0x3c
+
+#define ICSSG_TASK_MGR_OFFSET 0x2a000
+
+/* PRUSS_IEPCLK register bits */
+#define PRUSS_IEPCLK_IEP_OCP_CLK_ENBIT(0)
+
+/* ICSSG CORE_SYNC register bits */
+#define ICSSG_CORE_VBUSP_SYNC_EN BIT(0)
+
+/*
+ * pruss_request_tm_region() - Request pruss for task manager region
+ * @dev: corresponding k3 device
+ * @loc: the task manager physical address
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+int pruss_request_tm_region(struct udevice *dev, phys_addr_t *loc)
+{
+ struct pruss *priv;
+
+ priv = dev_get_priv(dev);
+ if (!priv || !priv->mem_regions[PRUSS_MEM_DRAM0].pa)
+ return -EINVAL;
+
+ *loc = priv->mem_regions[PRUSS_MEM_DRAM0].pa + ICSSG_TASK_MGR_OFFSET;
+
+ return 0;
+}
+
+/**
+ * pruss_request_mem_region() - request a memory resource
+ * @dev: the pruss device
+ * @mem_id: the memory resource id
+ * @region: pointer to memory region structure to be filled in
+ *
+ * This function allows a client driver to request a memory resource,
+ * and if successful, will let the client driver own the particular
+ * memory region until released using the pruss_release_mem_region()
+ * API.
+ *
+ * Returns the memory region if requested resource is available, an
+ * error otherwise
+ */
+int pruss_request_mem_region(struct udevice *dev, enum pruss_mem mem_id,
+struct pruss_mem_region *region)
+{
+ struct pruss *pruss;
+
+ pruss = dev_get_priv(dev);
+ if (!pruss || !region)
+ return -EINVAL;
+
+ if (mem_id >= PRUSS_MEM_MAX)
+ return -EINVAL;
+
+ if (pruss->mem_in_use[mem_id])
+ return -EBUSY;
+
+ *region = pruss->mem_regions[mem_id];
+ pruss->mem_in_use[mem_id] = region;
+
+ return 0;
+}
+
+/**
+ * pruss_release_mem_region() - release a memory
[PATCH v2 0/5] remoteproc: pru: Add remoteproc support for AM65 PRUSS
This series adds support for remoteproc driver for PRUSS in AM65 SoCs. Changes since v1: - Fixed checkpatch warnings Keerthy (2): soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs Lokesh Vutla (3): arm: dts: k3-am654-base-board: Add r5 specific u-boot dtsi arm: dts: ti: k3-am65-main: Add ICSSG nodes configs: am65x_evm_a53: Enable PRUSS remoteproc MAINTAINERS | 2 + arch/arm/dts/k3-am65-main.dtsi| 463 ++ arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 191 ++-- .../dts/k3-am654-r5-base-board-u-boot.dtsi| 193 arch/arm/dts/k3-am654-r5-base-board.dts | 2 - configs/am65x_evm_a53_defconfig | 2 + drivers/remoteproc/Kconfig| 11 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/pru_rproc.c| 461 + drivers/soc/ti/Kconfig| 11 + drivers/soc/ti/Makefile | 1 + drivers/soc/ti/pruss.c| 217 include/linux/pruss_driver.h | 227 + 13 files changed, 1627 insertions(+), 155 deletions(-) create mode 100644 arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi create mode 100644 drivers/remoteproc/pru_rproc.c create mode 100644 drivers/soc/ti/pruss.c create mode 100644 include/linux/pruss_driver.h -- 2.31.1
Re: [PATCH -next] ARM: dts: k3-j7200-common-proc-board-u-boot.dtsi: Fix dtc warnings
+Tom
On 14/06/21 2:12 pm, Vignesh Raghavendra wrote:
> Fix following dtc warning by explicitly setting up #size-cells
> and #address-cells when overriding node in -u-boot.dtsi
>
> arch/arm/dts/k3-j7200-common-proc-board.dtb: Warning (reg_format):
> /bus@10/bus@2838/mcu-navss/ringacc@2b80:reg: property has
> invalid length (80 bytes) (#address-cells == 2, #size-cells == 1)
>
> Signed-off-by: Vignesh Raghavendra
Tom,
If you don't mind, can you pull the patch to next directly? This fixed
the DT
warning on j7200 builds.
Thanks and regards,
Lokesh
> ---
> arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> index 41ce9fcb59..786cc48050 100644
> --- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> @@ -43,6 +43,8 @@
>
> mcu-navss{
> u-boot,dm-spl;
> + #address-cells = <2>;
> + #size-cells = <2>;
>
> ringacc@2b80 {
> reg = <0x0 0x2b80 0x0 0x40>,
>
[GIT PULL v2] TI changes for v2021.10 next
Hi Tom, Please find the PR for master branch targeted for v2021.10-next branch with checkpatch warnings fixed. Details about the PR are updated in the tag message. Gitlab CI report: https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7817 The following changes since commit e8f720ee1707b43a0e14ade87b40a1f84baeb2f3: Merge branch '2021-06-08-kconfig-migrations' into next (2021-06-09 08:19:13 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.10-next-v2 for you to fetch changes up to 5abb694d6016eaf497c3d9a3ec79382e217e7508: dma: ti: k3-udma: Add support for native configuration of chan/flow (2021-06-11 19:18:52 +0530) - HSM re-architecture support for all K3 platforms - AM64 USB support - Driver model support for Davinci RTC Aswath Govindraju (10): tools: k3_fit_atf: Add support for providing ATF load address using a Kconfig symbol arm: mach-k3: am642_init: Add support for USB boot mode arm: mach-k3: am642_init: Do USB fixups to facilitate host and device boot modes board: ti: am64x: Set the core voltage of USB PHY to 0.85V arm: dts: k3-am64-main: Add USB DT nodes arm: dts: k3-am642-*-evm: Add USB support arm: dts: k3-am642-evm-u-boot: Add U-Boot tags and fix the dr_mode to peripheral for USB subsystem configs: am64x_evm_*_defconfig: Rearrange the components in SRAM to satisfy the limitations for USB DFU boot mode arm: dts: k3-am64-main: Update the location of ATF in SRAM and increase its max size configs: am64: Enable configs to support USB host and device modes Dario Binacchi (8): rtc: davinci: enable compilation for omap architectures rtc: davinci: fix compiler errors rtc: davinci: replace 32bit access with 8bit access rtc: davinci: check BUSY bit before set TC registers rtc: davinci: use unlock/lock mechanism arm: dts: sync rtc node of am335x boards with Linux 5.9-rc7 rtc: davinci: add driver model support rtc: davinci: fix date loaded on reset Dave Gerlach (4): arm: mach-k3: Add platform data for j721e and j7200 arm: mach-k3: common: Drop main r5 start arm: mach-k3: j721e_init: Force early probe of clk-k3 driver configs: j7200_evm_r5: Enable raw access power management features Kevin Scholz (1): arm: dts: k3-j7200: ddr: Update to 0.5.0 version of DDR for LPDDR 2666MTs Lokesh Vutla (1): common: fit: Update board_fit_image_post_process() to pass fit and node_offset Pali Rohár (1): Nokia RX-51: Enable CONFIG_WDT to remove deprecation warning Tero Kristo (21): lib: rational: copy the rational fraction lib routines from Linux arm: mach-k3: introduce new config option for sysfw split remoteproc: k3-r5: remove sysfw PM calls if not supported clk: fixed_rate: add API for directly registering fixed rate clocks clk: fix clock tree dump to properly dump out every registered clock clk: do not attempt to fetch clock pointer with null device clk: add support for setting clk rate from cmdline clk: sci-clk: fix return value of set_rate clk: fix assigned-clocks to pass with deferring provider clk: fix set_rate to clean up cached rates for the hierarchy clk: add support for TI K3 SoC PLL clk: add support for TI K3 SoC clocks power: domain: Introduce driver for raw TI K3 PDs cmd: ti: pd: Add debug command for K3 power domains tools: k3_fit_atf: add DM binary to the FIT image arm: mach-k3: add support for detecting firmware images from FIT arm: mach-k3: do board config for PM only if supported arm: mach-k3: sysfw-loader: pass boardcfg to sciserver configs: j721e_evm_r5: Enable raw access power management features board: ti: j72xx: README: update build instructions and image formats arm: dts: k3-j72xx: correct MCU timer1 frequency Vignesh Raghavendra (7): mailbox: k3-sec-proxy: Add DM to DMSC communication thread firmware: ti_sci: Implement GET_RANGE with static data firmware: ti_sci: Add support for Resoure Management at R5 SPL stage. ARM: dts: j72xx-r5-common-proc-board: Add DM firmware node ARM: dts: k3: Add cfg register space for ringacc and udmap soc: ti: k3-navss-ringacc: Add support for native configuration of rings dma: ti: k3-udma: Add support for native configuration of chan/flow arch/arm/dts/am335x-bone-common.dtsi | 5 + arch/arm/dts/am335x-evm.dts| 5 + arch/arm/dts/am335x-evmsk.dts | 5 + arch/arm/dts/am335x-osd335x-common.dtsi| 6 + arch/arm/dts/k3-am64-main.dtsi | 32 +- arch/arm/dts/k3-am642-evm-u-boot.dtsi | 13 + arch/arm/dts/k3-am642
Re: [PATCH v2 0/5] Add SIMATIC IOT2050 board support
On 02/06/21 3:07 pm, Jan Kiszka wrote: > This is the baseline support for the SIMATIC IOT2050 devices. > > Changes in v2: > - rebased > - sync with upstream-accepted DT > - add boot switch > - include watchdog support > > Allows to boot mainline 5.10 kernels, but not the original BSP-derived > kernel we currently ship as reference. This is due to the TI sysfw ABI > breakages between 2.x and 3.x. We will soon provide a transitional > kernel that allows booting both firmware ABIs - as long as full upstream > kernel support is work in progress. > > Note that this baseline support lacks Ethernet drivers. We are working > closely with TI to ensure that the to-be-upstreamed icssg-prueth driver > will work both with new SR2.0 AM65x silicon as well as with SR1.0 which > is used in the currently shipped IOT2050 devices. > > A staging tree for complete IOT2050 support can be found at [1]. Full > image integration is available via [2]. > > Regarding patch 4: There has been some doubts on the proposed approach, > but there has been also no suggestion provided for a similarly > lightweight and secure embedding method. Therefore, I'm proposing our > solution once again. There are multiple checkpatch issues with this series. Can you fix them where ever possible? ➜ u-boot-ti git:(for-next) ./scripts/checkpatch.pl --strict siemens/*.patch siemens/0001-arm-dts-Add-IOT2050-device-tree-files.patch WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #50: new file mode 100644 WARNING: line length of 102 exceeds 100 columns #103: FILE: arch/arm/dts/k3-am65-iot2050-boot-image.dtsi:49: + filename = "arch/arm/dts/k3-am6528-iot2050-basic.dtb"; WARNING: line length of 105 exceeds 100 columns #113: FILE: arch/arm/dts/k3-am65-iot2050-boot-image.dtsi:59: + filename = "arch/arm/dts/k3-am6548-iot2050-advanced.dtb"; total: 0 errors, 3 warnings, 0 checks, 1025 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. siemens/0001-arm-dts-Add-IOT2050-device-tree-files.patch has style problems, please review. --- siemens/0002-board-siemens-Add-support-for-SIMATIC-IOT2050-device.patch --- WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #53: new file mode 100644 WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #282: FILE: board/siemens/iot2050/board.c:86: +#ifdef CONFIG_NET WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #338: FILE: board/siemens/iot2050/board.c:142: +#ifdef CONFIG_SPL_LOAD_FIT WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #361: FILE: board/siemens/iot2050/board.c:165: +#ifdef CONFIG_IOT2050_BOOT_SWITCH WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #404: FILE: board/siemens/iot2050/board.c:208: +#ifdef CONFIG_IOT2050_BOOT_SWITCH WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #413: FILE: board/siemens/iot2050/board.c:217: +#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #458: FILE: board/siemens/iot2050/board.c:262: +#if CONFIG_IS_ENABLED(LED) CHECK: Macro argument reuse 'func' - possible side-effects? #683: FILE: include/configs/iot2050.h:43: +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 1) \ + func(MMC, mmc, 0) \ + func(USB, usb, 0) \ + func(USB, usb, 1) \ + func(USB, usb, 2) total: 0 errors, 7 warnings, 1 checks, 606 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. siemens/0002-board-siemens-Add-support-for-SIMATIC-IOT2050-device.patch has style problems, please review. -- siemens/0003-arm64-dts-ti-k3-am65-mcu-Add-RTI-watchdog-entry.patch -- total: 0 errors, 0 warnings, 0 checks, 13 lines checked siemens/0003-arm64-dts-ti-k3-am65-mcu-Add-RTI-watchdog-entry.patch has no obvious style problems and is ready for submission. siemens/0004-watchdog-rti_wdt-Add-support-for-loading-firmware.patch WARNING: externs should be avoided in .c files #95: FILE: drivers/watchdog/rti_wdt.c:47: +extern const u32 rti_wdt_fw[]; WARNING:
Re: [PATCH v2 4/5] watchdog: rti_wdt: Add support for loading firmware
Hi Tom, On 09/06/21 6:47 pm, Jan Kiszka wrote: > On 07.06.21 13:44, Jan Kiszka wrote: >> On 07.06.21 13:40, Tom Rini wrote: >>> On Mon, Jun 07, 2021 at 03:33:52PM +0530, Lokesh Vutla wrote: >>>> +Tom, >>>> >>>> Hi Tom, >>>> >>>> On 02/06/21 3:07 pm, Jan Kiszka wrote: >>>>> From: Jan Kiszka >>>>> >>>>> To avoid the need of extra boot scripting on AM65x for loading a >>>>> watchdog firmware, add the required rproc init and loading logic for the >>>>> first R5F core to the watchdog start handler. In case the R5F cluster is >>>>> in lock-step mode, also initialize the second core. The firmware itself >>>>> is embedded into U-Boot binary to ease access to it and ensure it is >>>>> properly hashed in case of secure boot. >>>>> >>>>> One possible firmware source is https://github.com/siemens/k3-rti-wdt. >>>>> >>>>> Signed-off-by: Jan Kiszka >>>>> --- >>>>> drivers/watchdog/Kconfig | 20 >>>>> drivers/watchdog/Makefile | 5 +++ >>>>> drivers/watchdog/rti_wdt.c| 58 ++- >>>>> drivers/watchdog/rti_wdt_fw.S | 20 >>>>> 4 files changed, 102 insertions(+), 1 deletion(-) >>>>> create mode 100644 drivers/watchdog/rti_wdt_fw.S >>>>> >>>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig >>>>> index f0ff2612a6..1a1fddfe9f 100644 >>>>> --- a/drivers/watchdog/Kconfig >>>>> +++ b/drivers/watchdog/Kconfig >>>>> @@ -209,6 +209,26 @@ config WDT_K3_RTI >>>>> Say Y here if you want to include support for the K3 watchdog >>>>> timer (RTI module) available in the K3 generation of processors. >>>>> >>>>> +if WDT_K3_RTI >>>>> + >>>>> +config WDT_K3_RTI_LOAD_FW >>>>> + bool "Load watchdog firmware" >>>>> + depends on REMOTEPROC >>>>> + help >>>>> + Automatically load the specified firmware image into the MCU R5F >>>>> + core 0. On the AM65x, this firmware is supposed to handle the expiry >>>>> + of the watchdog timer, typically by resetting the system. >>>>> + >>>>> +config WDT_K3_RTI_FW_FILE >>>>> + string "Watchdog firmware image file" >>>>> + default "k3-rti-wdt.fw" >>>>> + depends on WDT_K3_RTI_LOAD_FW >>>>> + help >>>>> + Firmware image to be embedded into U-Boot and loaded on watchdog >>>>> + start. >>>> >>>> I need your input on this proach. Is it okay to include the linker file >>>> unders >>>> drivers? >>> >>> Maybe? I suppose the first thing that springs to mind is why aren't we >>> using binman and including this blob (which I happily see is GPLv2) >>> similar to how we do things with x86 for one example. >>> >> >> See https://www.mail-archive.com/u-boot@lists.denx.de/msg377894.html >> >> Jan >> > > Did this help to answer open questions? Otherwise, please let me know. > > I'd also like to avoid that his patch alone blocks 1-3 of the series > needless - but I would also not mind getting everything in at once. Can you provide your reviewed-by if you are okay with this approach? Thanks and regards, Lokesh > > Thanks, > Jan >
Re: [PATCHv6 00/26] HSM rearch series for TI K3 devices
Tom, On 11/06/21 4:48 pm, Tero Kristo wrote: > On 11/06/2021 14:08, Lokesh Vutla wrote: >> Hi Tero, >> >> On 11/06/21 2:15 pm, Tero Kristo wrote: >>> Hello, >>> >>> One more post, this time with the #ifdef hackery converted to use the >>> IS_ENABLED / CONFIG_IS_ENABLED macros, and also removed the "common.h" >>> include from k3-clk.h header. This version also contains fixes to any >>> build issues reported by Lokesh, and these are squashed in to relevant >>> patches. >> >> Can you see if the below warnings can be fixed? >> >> hsm/0018-arm-mach-k3-add-support-for-detecting-firmware-image.patch >> --- >> WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where >> possible >> #26: FILE: arch/arm/mach-k3/common.c:31: >> +#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF) > > This is static data, can't be fixed. Unless we want to compile it in always? > >> >> WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where >> possible >> #35: FILE: arch/arm/mach-k3/common.c:40: >> +#if CONFIG_IS_ENABLED(FIT_IMAGE_POST_PROCESS) > > Same, static data. > >> >> WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where >> possible >> #55: FILE: arch/arm/mach-k3/common.c:131: >> +#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF) > > This is actually just an old macro I changed from #ifdef to IS_ENABLED. Fixing > the whole file from the existing #ifdef:s should be outside the scope of this > series. > >> >> WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where >> possible >> #124: FILE: arch/arm/mach-k3/common.c:264: >> +#if CONFIG_IS_ENABLED(FIT_IMAGE_POST_PROCESS) > > This code addresses the static data defined before, changing this will break > compilation; unless we compile the data always in. > >> >> WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where >> possible >> #128: FILE: arch/arm/mach-k3/common.c:268: >> +#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF) > > Same as above. > >> WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where >> possible >> #150: FILE: arch/arm/mach-k3/common.c:290: >> +#if IS_ENABLED(CONFIG_TI_SECURE_DEVICE) > > This can't be changed, the code it addresses is only linked in with the > config, > causing a linker time failure if this is fixed. > > Imho, I am not too convinced about the checkpatch tool complaining about these > issues. :) > > -Tero > >> >> total: 0 errors, 6 warnings, 0 checks, 144 lines checked >> >> NOTE: For some of the reported defects, checkpatch may be able to >> mechanically convert to the typical style using --fix or >> --fix-inplace. >> >> hsm/0018-arm-mach-k3-add-support-for-detecting-firmware-image.patch has style >> problems, please review. >> --- >> hsm/0019-arm-mach-k3-do-board-config-for-PM-only-if-supported.patch >> --- >> WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where >> possible >> #24: FILE: arch/arm/mach-k3/sysfw-loader.c:162: >> +#if !CONFIG_IS_ENABLED(K3_DM_FW) >> >> total: 0 errors, 1 warnings, 0 checks, 13 lines checked >> >> NOTE: For some of the reported defects, checkpatch may be able to >> mechanically convert to the typical style using --fix or >> --fix-inplace. I assume you are okay with this? Thanks and regards, Lokesh >> >> >> Thanks and regards, >> Lokesh >> >
Re: [PATCHv6 00/26] HSM rearch series for TI K3 devices
Hi Tero, On 11/06/21 2:15 pm, Tero Kristo wrote: > Hello, > > One more post, this time with the #ifdef hackery converted to use the > IS_ENABLED / CONFIG_IS_ENABLED macros, and also removed the "common.h" > include from k3-clk.h header. This version also contains fixes to any > build issues reported by Lokesh, and these are squashed in to relevant > patches. Can you see if the below warnings can be fixed? hsm/0018-arm-mach-k3-add-support-for-detecting-firmware-image.patch --- WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #26: FILE: arch/arm/mach-k3/common.c:31: +#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF) WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #35: FILE: arch/arm/mach-k3/common.c:40: +#if CONFIG_IS_ENABLED(FIT_IMAGE_POST_PROCESS) WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #55: FILE: arch/arm/mach-k3/common.c:131: +#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF) WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #124: FILE: arch/arm/mach-k3/common.c:264: +#if CONFIG_IS_ENABLED(FIT_IMAGE_POST_PROCESS) WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #128: FILE: arch/arm/mach-k3/common.c:268: +#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF) WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #150: FILE: arch/arm/mach-k3/common.c:290: +#if IS_ENABLED(CONFIG_TI_SECURE_DEVICE) total: 0 errors, 6 warnings, 0 checks, 144 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. hsm/0018-arm-mach-k3-add-support-for-detecting-firmware-image.patch has style problems, please review. --- hsm/0019-arm-mach-k3-do-board-config-for-PM-only-if-supported.patch --- WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible #24: FILE: arch/arm/mach-k3/sysfw-loader.c:162: +#if !CONFIG_IS_ENABLED(K3_DM_FW) total: 0 errors, 1 warnings, 0 checks, 13 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. Thanks and regards, Lokesh
Re: [GIT PULL] TI changes for v2021.10 next
+Tero, On 10/06/21 8:55 pm, Tom Rini wrote: > On Thu, Jun 10, 2021 at 12:16:50PM +0530, Lokesh Vutla wrote: > >> Hi Tom, >> Please find the PR for master branch targeted for v2021.10-next branch. >> Details about the PR are updated in the tag message. >> >> Gitlab CI report: >> https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7780 >> >> >> The following changes since commit e8f720ee1707b43a0e14ade87b40a1f84baeb2f3: >> >> Merge branch '2021-06-08-kconfig-migrations' into next (2021-06-09 >> 08:19:13 -0400) >> >> are available in the Git repository at: >> >> https://source.denx.de/u-boot/custodians/u-boot-ti.git >> tags/ti-v2021.10-next >> >> for you to fetch changes up to 47a10af8f8a90b3d9e83fafb51372800171344a9: >> >> dma: ti: k3-udma: Add support for native configuration of chan/flow >> (2021-06-09 22:23:45 +0530) >> > > NAK: > ERROR: Avoid including common.h and dm.h in header files > #437: FILE: include/k3-clk.h:10: > +#include Interesting, I could not see this issue > > And while you're in there, there's a number of: > WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where > possible > #53: FILE: drivers/clk/clk_fixed_rate.c:62: > +#if defined(CONFIG_CLK_CCF) || defined(CONFIG_SPL_CLK_CCF) > > Where checkpatch is warning about the wrong thing, that should be > CONFIG_IS_ENABLED(CLK_CCF) at minimum and then see if we can use > if (...) instead. > Tero, Can you fix it and re-post? Thanks and regards, Lokesh
[GIT PULL] TI changes for v2021.10 next
Hi Tom, Please find the PR for master branch targeted for v2021.10-next branch. Details about the PR are updated in the tag message. Gitlab CI report: https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7780 The following changes since commit e8f720ee1707b43a0e14ade87b40a1f84baeb2f3: Merge branch '2021-06-08-kconfig-migrations' into next (2021-06-09 08:19:13 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.10-next for you to fetch changes up to 47a10af8f8a90b3d9e83fafb51372800171344a9: dma: ti: k3-udma: Add support for native configuration of chan/flow (2021-06-09 22:23:45 +0530) - HSM re-architecture support for all K3 platforms - AM64 USB support - Driver model support for Davinci RTC Aswath Govindraju (10): tools: k3_fit_atf: Add support for providing ATF load address using a Kconfig symbol arm: mach-k3: am642_init: Add support for USB boot mode arm: mach-k3: am642_init: Do USB fixups to facilitate host and device boot modes board: ti: am64x: Set the core voltage of USB PHY to 0.85V arm: dts: k3-am64-main: Add USB DT nodes arm: dts: k3-am642-*-evm: Add USB support arm: dts: k3-am642-evm-u-boot: Add U-Boot tags and fix the dr_mode to peripheral for USB subsystem configs: am64x_evm_*_defconfig: Rearrange the components in SRAM to satisfy the limitations for USB DFU boot mode arm: dts: k3-am64-main: Update the location of ATF in SRAM and increase its max size configs: am64: Enable configs to support USB host and device modes Dario Binacchi (8): rtc: davinci: enable compilation for omap architectures rtc: davinci: fix compiler errors rtc: davinci: replace 32bit access with 8bit access rtc: davinci: check BUSY bit before set TC registers rtc: davinci: use unlock/lock mechanism arm: dts: sync rtc node of am335x boards with Linux 5.9-rc7 rtc: davinci: add driver model support rtc: davinci: fix date loaded on reset Dave Gerlach (4): arm: mach-k3: Add platform data for j721e and j7200 arm: mach-k3: common: Drop main r5 start arm: mach-k3: j721e_init: Force early probe of clk-k3 driver configs: j7200_evm_r5: Enable raw access power management features Kevin Scholz (1): arm: dts: k3-j7200: ddr: Update to 0.5.0 version of DDR for LPDDR 2666MTs Lokesh Vutla (1): common: fit: Update board_fit_image_post_process() to pass fit and node_offset Pali Rohár (1): Nokia RX-51: Enable CONFIG_WDT to remove deprecation warning Tero Kristo (21): lib: rational: copy the rational fraction lib routines from Linux arm: mach-k3: introduce new config option for sysfw split remoteproc: k3-r5: remove sysfw PM calls if not supported clk: fixed_rate: add API for directly registering fixed rate clocks clk: fix clock tree dump to properly dump out every registered clock clk: do not attempt to fetch clock pointer with null device clk: add support for setting clk rate from cmdline clk: sci-clk: fix return value of set_rate clk: fix assigned-clocks to pass with deferring provider clk: fix set_rate to clean up cached rates for the hierarchy clk: add support for TI K3 SoC PLL clk: add support for TI K3 SoC clocks power: domain: Introduce driver for raw TI K3 PDs cmd: ti: pd: Add debug command for K3 power domains tools: k3_fit_atf: add DM binary to the FIT image arm: mach-k3: add support for detecting firmware images from FIT arm: mach-k3: do board config for PM only if supported arm: mach-k3: sysfw-loader: pass boardcfg to sciserver configs: j721e_evm_r5: Enable raw access power management features board: ti: j72xx: README: update build instructions and image formats arm: dts: k3-j72xx: correct MCU timer1 frequency Vignesh Raghavendra (7): mailbox: k3-sec-proxy: Add DM to DMSC communication thread firmware: ti_sci: Implement GET_RANGE with static data firmware: ti_sci: Add support for Resoure Management at R5 SPL stage. ARM: dts: j72xx-r5-common-proc-board: Add DM firmware node ARM: dts: k3: Add cfg register space for ringacc and udmap soc: ti: k3-navss-ringacc: Add support for native configuration of rings dma: ti: k3-udma: Add support for native configuration of chan/flow arch/arm/dts/am335x-bone-common.dtsi | 5 + arch/arm/dts/am335x-evm.dts | 5 + arch/arm/dts/am335x-evmsk.dts | 5 + arch/arm/dts/am335x-osd335x-common.dtsi | 6 + arch/arm/dts/k3-am64-main.dtsi| 32 +- arch/arm/dts/k3-am642-evm-u-boot.dtsi | 13 + arch/arm/dts/k3-am642-evm.dts | 18 + arch/arm/dts/k3-am642-r5-evm.dts | 18 + arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 14 + .../k3-j7200-common-proc-board-u-boot.dtsi| 30 +- ...00.dtsi => k3-j7200-ddr-evm-lp4-2666.dtsi} |
Re: [PATCHv5 00/26] Re-base / re-post of TI-K3 HSM rearch series
On 03/06/21 12:02 pm, Tero Kristo wrote: > Hi, > > As requested, this is just a rebase to the latest u-boot tip. > > Boot tested on j721e to make sure nothing got broken. Applied to u-boot-ti for-next. Thanks and regards, Lokesh > > -Tero > >
Re: [PATCH v2 0/8] rtc: davinci: add driver model support
On Wed, 2 Jun 2021 22:37:57 +0200, Dario Binacchi wrote: > The series adds driver model support for omap RTC plus some fixes. > > Changes in v2: > - Separated from Kconfig patch > - Use consistent naming (omap_rtc_. > - Remove non-DM support. It's no more used. > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git master, thanks! [1/8] rtc: davinci: enable compilation for omap architectures https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/73c3d8ebb5 [2/8] rtc: davinci: fix compiler errors https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/6acee20e57 [3/8] rtc: davinci: replace 32bit access with 8bit access https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/82a456a085 [4/8] rtc: davinci: check BUSY bit before set TC registers https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/79250ef3e2 [5/8] rtc: davinci: use unlock/lock mechanism https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/c7c7c8db00 [6/8] arm: dts: sync rtc node of am335x boards with Linux 5.9-rc7 https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/62af440e21 [7/8] rtc: davinci: add driver model support https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/9ec8b8b4ca [8/8] rtc: davinci: fix date loaded on reset https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/08ea87a6de -- Thanks and Regards, Lokesh
Re: [PATCH v2 0/7] J72xx: R5 SPL DMA support post HSM Rearch
On Mon, 7 Jun 2021 19:47:46 +0530, Vignesh Raghavendra wrote: > This series add DMA support for R5 SPL on J721e/J7200 SoCs post HSM > Rearch. > > Depends on Tero's base HSM rearch support series. > > v2: > Use IS_ENABLED() consistentially instead of #ifdef > Reword commit msg for 5/7 as suggested by Lokesh > Rebase on Tero's latest HSM base series. > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git master, thanks! [1/7] mailbox: k3-sec-proxy: Add DM to DMSC communication thread https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a492dfa4b3 [2/7] firmware: ti_sci: Implement GET_RANGE with static data https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/30df7f5031 [3/7] firmware: ti_sci: Add support for Resoure Management at R5 SPL stage. https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/7ddedf520f [4/7] ARM: dts: j72xx-r5-common-proc-board: Add DM firmware node https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/423695d8d0 [5/7] ARM: dts: k3: Add cfg register space for ringacc and udmap https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/b480093c95 [6/7] soc: ti: k3-navss-ringacc: Add support for native configuration of rings https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/1e80838d57 [7/7] dma: ti: k3-udma: Add support for native configuration of chan/flow https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/47a10af8f8 -- Thanks and Regards, Lokesh
Re: [PATCH] arm: dts: k3-j7200: ddr: Update to 0.5.0 version of DDR for LPDDR 2666MTs
On Thu, 3 Jun 2021 08:14:53 -0500, prane...@ti.com wrote: > Update the ddr settings to use the DDR reg config tool rev 0.5.0. > This enables 2666MTs LPDDR configuration on J7200. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git master, thanks! [1/1] arm: dts: k3-j7200: ddr: Update to 0.5.0 version of DDR for LPDDR 2666MTs https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/dc9f1009b1 -- Thanks and Regards, Lokesh
Re: [PATCH v2] Nokia RX-51: Enable CONFIG_WDT to remove deprecation warning
On Tue, 9 Mar 2021 21:19:15 +0100, Pali Rohár wrote: > Also convert CONFIG_HW_WATCHDOG to CONFIG_WATCHDOG. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git master, thanks! [1/1] Nokia RX-51: Enable CONFIG_WDT to remove deprecation warning https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/e61a4ff13f -- Thanks and Regards, Lokesh
Re: [PATCH v3 00/10] AM642-EVM: Add USB support
On Fri, 4 Jun 2021 22:00:30 +0530, Aswath Govindraju wrote: > The following series of patches add support for the following > - Kconfig symbol for giving the load address for ATF > - USB Mass storage boot mode in AM642-EVM > - DFU boot mode in AM642-EVM > - Host and peripheral modes for AM642-EVM in U-Boot > - Set the USB PHY core voltage to 0.85V > > [...] Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git master, thanks! [01/10] tools: k3_fit_atf: Add support for providing ATF load address using a Kconfig symbol https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/0c51509224 [02/10] arm: mach-k3: am642_init: Add support for USB boot mode https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/3ae127c4e2 [03/10] arm: mach-k3: am642_init: Do USB fixups to facilitate host and device boot modes https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/669a03e0ff [04/10] board: ti: am64x: Set the core voltage of USB PHY to 0.85V https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/397d7b0fae [05/10] arm: dts: k3-am64-main: Add USB DT nodes https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/cdb738411f [06/10] arm: dts: k3-am642-*-evm: Add USB support https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/7803a5bda9 [07/10] arm: dts: k3-am642-evm-u-boot: Add U-Boot tags and fix the dr_mode to peripheral for USB subsystem https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/1c8b404b88 [08/10] configs: am64x_evm_*_defconfig: Rearrange the components in SRAM to satisfy the limitations for USB DFU boot mode https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/26f32c32b2 [09/10] arm: dts: k3-am64-main: Update the location of ATF in SRAM and increase its max size https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/defd62ca13 [10/10] configs: am64: Enable configs to support USB host and device modes https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/ce7ad57390 -- Thanks and Regards, Lokesh
[PATCH 4/5] arm: dts: ti: k3-am65-main: Add ICSSG nodes
Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems
that are present on the K3 AM65x SoCs. The three ICSSGs are identical
to each other for the most part, with the ICSSG2 supporting slightly
enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance
is represented by a PRUSS subsystem node. These nodes are enabled by
default.
DT nodes are fetch from Linux 5.13 Kernel.
Signed-off-by: Lokesh Vutla
---
arch/arm/dts/k3-am65-main.dtsi | 463 +++
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 72 +++
2 files changed, 535 insertions(+)
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index cabdba85e0..669484b0dd 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -926,4 +926,467 @@
clocks = <_tbclk 5>, <_clks 45 0>;
clock-names = "tbclk", "fck";
};
+
+ icssg0: icssg@b00 {
+ compatible = "ti,am654-icssg";
+ reg = <0x00 0xb00 0x00 0x8>;
+ power-domains = <_pds 62 TI_SCI_PD_EXCLUSIVE>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0xb00 0x8>;
+
+ icssg0_mem: memories@0 {
+ reg = <0x0 0x2000>,
+ <0x2000 0x2000>,
+ <0x1 0x1>;
+ reg-names = "dram0", "dram1",
+ "shrdram2";
+ };
+
+ icssg0_cfg: cfg@26000 {
+ compatible = "ti,pruss-cfg", "syscon";
+ reg = <0x26000 0x200>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x26000 0x2000>;
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ icssg0_coreclk_mux: coreclk-mux@3c {
+ reg = <0x3c>;
+ #clock-cells = <0>;
+ clocks = <_clks 62 19>, /*
icssg0_core_clk */
+<_clks 62 3>; /*
icssg0_iclk */
+ assigned-clocks = <_coreclk_mux>;
+ assigned-clock-parents = <_clks 62
3>;
+ };
+
+ icssg0_iepclk_mux: iepclk-mux@30 {
+ reg = <0x30>;
+ #clock-cells = <0>;
+ clocks = <_clks 62 10>, /*
icssg0_iep_clk */
+<_coreclk_mux>; /*
core_clk */
+ assigned-clocks = <_iepclk_mux>;
+ assigned-clock-parents =
<_coreclk_mux>;
+ };
+ };
+ };
+
+ icssg0_iep0: iep@2e000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2e000 0x1000>;
+ clocks = <_iepclk_mux>;
+ };
+
+ icssg0_iep1: iep@2f000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2f000 0x1000>;
+ clocks = <_iepclk_mux>;
+ };
+
+ icssg0_mii_rt: mii-rt@32000 {
+ compatible = "ti,pruss-mii", "syscon";
+ reg = <0x32000 0x100>;
+ };
+
+ icssg0_mii_g_rt: mii-g-rt@33000 {
+ compatible = "ti,pruss-mii-g", "syscon";
+ reg = <0x33000 0x1000>;
+ };
+
+ icssg0_intc: interrupt-controller@2 {
+ compatible = "ti,icssg-intc";
+ reg = <0x2 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+;
+ interrupt-names = "host_intr0", "host_intr1",
+
[PATCH 5/5] configs: am65x_evm_a53: Enable PRUSS remoteproc
Enable PRUSS remoteproc driver for AM65 Signed-off-by: Lokesh Vutla --- configs/am65x_evm_a53_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 01e027f607..512849f983 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -139,12 +139,14 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_REMOTEPROC_TI_K3_R5F=y +CONFIG_REMOTEPROC_TI_PRU=y CONFIG_DM_RESET=y CONFIG_RESET_TI_SCI=y CONFIG_DM_SERIAL=y CONFIG_SOC_DEVICE=y CONFIG_SOC_DEVICE_TI_K3=y CONFIG_SOC_TI=y +CONFIG_TI_PRUSS=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_CADENCE_QSPI=y -- 2.31.1
[PATCH 3/5] arm: dts: k3-am654-base-board: Add r5 specific u-boot dtsi
So far all the u-boot specific properties for both r5 and a53 are
placed in k3-am654-base-board-u-boot.dtsi. But there are few a53
nodes that should be updated but doesn't belong to r5. So create a
separate r5 specific u-boot dtsi.
Signed-off-by: Lokesh Vutla
---
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 191 +
.../dts/k3-am654-r5-base-board-u-boot.dtsi| 193 ++
arch/arm/dts/k3-am654-r5-base-board.dts | 2 -
3 files changed, 195 insertions(+), 191 deletions(-)
create mode 100644 arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index b0602d1dad..77b7d3f452 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -1,193 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2018-2021 Texas Instruments Incorporated - http://www.ti.com/
*/
-#include
-#include
-
-/ {
- chosen {
- stdout-path = "serial2:115200n8";
- };
-
- aliases {
- serial2 = _uart0;
- ethernet0 = _port1;
- usb0 =
- usb1 =
- spi0 =
- spi1 =
- };
-};
-
-_main{
- u-boot,dm-spl;
- main-navss {
- u-boot,dm-spl;
- };
-};
-
-_mcu {
- u-boot,dm-spl;
-
- mcu-navss {
- u-boot,dm-spl;
-
- ringacc@2b80 {
- u-boot,dm-spl;
- ti,dma-ring-reset-quirk;
- };
-
- dma-controller@285c {
- u-boot,dm-spl;
- };
- };
-};
-
-_wakeup {
- u-boot,dm-spl;
-
- chipid@4314 {
- u-boot,dm-spl;
- };
-};
-
-_proxy_main {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
- k3_sysreset: sysreset-controller {
- compatible = "ti,sci-sysreset";
- u-boot,dm-spl;
- };
-};
-
-_pds {
- u-boot,dm-spl;
-};
-
-_clks {
- u-boot,dm-spl;
-};
-
-_reset {
- u-boot,dm-spl;
-};
-
-_pmx0 {
- u-boot,dm-spl;
-
- wkup_i2c0_pins_default {
- u-boot,dm-spl;
- };
-};
-
-_pmx0 {
- u-boot,dm-spl;
- usb0_pins_default: usb0_pins_default {
- pinctrl-single,pins = <
- AM65X_IOPAD(0x02bc, PIN_OUTPUT, 0) /* (AD9)
USB0_DRVVBUS */
- >;
- u-boot,dm-spl;
- };
-};
-
-_uart0_pins_default {
- u-boot,dm-spl;
-};
-
-_pmx1 {
- u-boot,dm-spl;
-};
-
-_pmx0 {
- mcu-fss0-ospi0-pins-default {
- u-boot,dm-spl;
- };
-};
-
-_uart0 {
- u-boot,dm-spl;
-};
-
-_mmc0_pins_default {
- u-boot,dm-spl;
-};
-
-_mmc1_pins_default {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-};
-
-_mdio {
- phy0: ethernet-phy@0 {
- reg = <0>;
- /* TODO: phy reset:
TCA9555RTWR(i2c:0x21)[p04].GPIO_MCU_RGMII_RSTN */
- ti,rx-internal-delay = ;
- ti,fifo-depth = ;
- };
-};
-
-_cpsw {
- reg = <0x0 0x4600 0x0 0x20>,
- <0x0 0x40f00200 0x0 0x2>;
- reg-names = "cpsw_nuss", "mac_efuse";
- /delete-property/ ranges;
-
- cpsw-phy-sel@40f04040 {
- compatible = "ti,am654-cpsw-phy-sel";
- reg= <0x0 0x40f04040 0x0 0x4>;
- reg-names = "gmii-sel";
- };
-};
-
-_i2c0 {
- u-boot,dm-spl;
-};
-
- {
- dr_mode = "peripheral";
-};
-
- {
- u-boot,dm-spl;
-};
-
- {
- u-boot,dm-spl;
-
-flash@0{
- u-boot,dm-spl;
- };
-};
-
-_0 {
- status = "okay";
- u-boot,dm-spl;
-};
-
-_phy {
- status = "okay";
- u-boot,dm-spl;
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_pins_default>;
- dr_mode = "host";
- u-boot,dm-spl;
-};
-
-_conf {
- u-boot,dm-spl;
-};
+#include "k3-am654-r5-base-board-u-boot.dtsi"
diff --git a/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
new file mode 100644
index 00..932a65b906
--- /dev/null
+++ b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018-2021 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+
+/ {
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ aliases {
+ serial2 = _uart0;
+ ethernet0 = _port1;
+ usb0 =
+ usb1 =
+ spi0 =
+
[PATCH 2/5] remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs
From: Keerthy
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
processor subsystem, commonly referred to as ICSSG. Each ICSSG processor
subsystem on AM65x SR1.0 contains two primary PRU cores and two new
auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised
ICSSG IP that is based off the subsequent IP revision used on J721E
SoCs. This IP instance has two new custom auxiliary PRU cores called
Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs.
Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than
a PRU), Control and debug feature sets, but is different in terms of
sub-modules integrated around it and does not have the full capabilities
associated with a PRU core. The RTU core is typically used to aid a
PRU core in accelerating data transfers, while the Tx_PRU cores is
normally used to control the TX L2 FIFO if enabled in Ethernet
applications. Both can also be used to run independent applications.
The RTU and Tx_PRU cores though share the same Data RAMs as the PRU
cores, so the memories have to be partitioned carefully between different
applications. The new cores also support a new sub-module called Task
Manager to support two different context thread executions.
The driver currently supports the AM65xx SoC
Signed-off-by: Keerthy
Signed-off-by: Suman Anna
Signed-off-by: Murali Karicheri
Signed-off-by: Roger Quadros
Signed-off-by: Lokesh Vutla
---
drivers/remoteproc/Kconfig | 11 +
drivers/remoteproc/Makefile| 1 +
drivers/remoteproc/pru_rproc.c | 461 +
3 files changed, 473 insertions(+)
create mode 100644 drivers/remoteproc/pru_rproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 7c2e4804b5..24e536463b 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -81,4 +81,15 @@ config REMOTEPROC_TI_POWER
help
Say 'y' here to add support for TI power processors such as those
found on certain TI keystone and OMAP generation SoCs.
+
+config REMOTEPROC_TI_PRU
+ bool "Support for TI's K3 based PRU remoteproc driver"
+ select REMOTEPROC
+ depends on DM
+ depends on TI_PRUSS
+ depends on ARCH_K3
+ depends on OF_CONTROL
+ help
+ Say 'y' here to add support for TI' K3 remoteproc driver.
+
endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 69ae7bd1e8..f0e83451d6 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_REMOTEPROC_TI_K3_ARM64) += ti_k3_arm64_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_K3_DSP) += ti_k3_dsp_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_K3_R5F) += ti_k3_r5f_rproc.o
obj-$(CONFIG_REMOTEPROC_TI_POWER) += ti_power_proc.o
+obj-$(CONFIG_REMOTEPROC_TI_PRU) += pru_rproc.o
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
new file mode 100644
index 00..924070a76b
--- /dev/null
+++ b/drivers/remoteproc/pru_rproc.c
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PRU-RTU remoteproc driver for various SoCs
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Keerthy
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PRU_ICSS_PRU_CTRL registers */
+#define PRU_CTRL_CTRL 0x
+#define PRU_CTRL_STS 0x0004
+#define PRU_CTRL_WAKEUP_EN 0x0008
+#define PRU_CTRL_CYCLE 0x000C
+#define PRU_CTRL_STALL 0x0010
+#define PRU_CTRL_CTBIR00x0020
+#define PRU_CTRL_CTBIR10x0024
+#define PRU_CTRL_CTPPR00x0028
+#define PRU_CTRL_CTPPR10x002C
+
+/* CTRL register bit-fields */
+#define CTRL_CTRL_SOFT_RST_N BIT(0)
+#define CTRL_CTRL_EN BIT(1)
+#define CTRL_CTRL_SLEEPING BIT(2)
+#define CTRL_CTRL_CTR_EN BIT(3)
+#define CTRL_CTRL_SINGLE_STEP BIT(8)
+#define CTRL_CTRL_RUNSTATE BIT(15)
+
+#define RPROC_FLAGS_SHIFT 16
+#define RPROC_FLAGS_NONE 0
+#define RPROC_FLAGS_ELF_PHDR BIT(0 + RPROC_FLAGS_SHIFT)
+#define RPROC_FLAGS_ELF_SHDR BIT(1 + RPROC_FLAGS_SHIFT)
+
+/**
+ * enum pru_mem - PRU core memory range identifiers
+ */
+enum pru_mem {
+ PRU_MEM_IRAM = 0,
+ PRU_MEM_CTRL,
+ PRU_MEM_DEBUG,
+ PRU_MEM_MAX,
+};
+
+struct pru_privdata {
+ phys_addr_t pru_iram;
+ phys_addr_t pru_ctrl;
+ phys_addr_t pru_debug;
+ fdt_size_t pru_iramsz;
+ fdt_size_t pru_ctrlsz;
+ fdt_size_t pru_debugsz;
+ const char *fw_name;
+ u32 iram_da;
+ u32 pdram_da;
+ u32 sdram_da;
+ u32 shrdram_da;
+ u32 bootaddr;
+ int id;
+ struct pruss *prusspriv;
+};
+
+static inline u32 pru_control_read_reg(struct pru_privdata *pru, unsigned int
reg)
+{
+ return readl(pru->pru_ctrl + reg);
+}
+
+static
[PATCH 1/5] soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
From: Keerthy
The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present of various TI SoCs such as
AM335x or AM437x or the AM654x family. Each SoC can have
one or more PRUSS instances that may or may not be identical.
The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, and
an interrupt controller. The programmable nature of the PRUs
provide flexibility to implement custom peripheral interfaces,
fast real-time responses, or specialized data handling.
Add support for pruss driver. Currently am654x family
is supported.
Signed-off-by: Keerthy
Signed-off-by: Roger Quadros
Signed-off-by: Lokesh Vutla
---
drivers/soc/ti/Kconfig | 11 ++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/pruss.c | 217 +
include/linux/pruss_driver.h | 227 +++
4 files changed, 456 insertions(+)
create mode 100644 drivers/soc/ti/pruss.c
create mode 100644 include/linux/pruss_driver.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index e4f8834448..0ee21f9904 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -23,4 +23,15 @@ config TI_KEYSTONE_SERDES
SerDes driver for Keystone SoC used for ethernet support on TI
K2 platforms.
+config TI_PRUSS
+ bool "Support for TI's K3 based Pruss driver"
+ depends on DM
+ depends on ARCH_K3
+ depends on OF_CONTROL
+ depends on SYSCON
+ help
+ Support for TI PRU-ICSSG subsystem.
+ Currently supported on AM65xx SoCs Say Y here to support the
+ Programmable Realtime Unit (PRU).
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 4ec04ee125..34f80aad29 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_TI_K3_NAVSS_RINGACC) += k3-navss-ringacc.o
obj-$(CONFIG_TI_KEYSTONE_SERDES) += keystone_serdes.o
+obj-$(CONFIG_TI_PRUSS) += pruss.o
diff --git a/drivers/soc/ti/pruss.c b/drivers/soc/ti/pruss.c
new file mode 100644
index 00..461390925d
--- /dev/null
+++ b/drivers/soc/ti/pruss.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PRU-ICSS platform driver for various TI SoCs
+ *
+ * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PRUSS_CFG_IEPCLK 0x30
+#define ICSSG_CFG_CORE_SYNC0x3c
+
+#define ICSSG_TASK_MGR_OFFSET 0x2a000
+
+/* PRUSS_IEPCLK register bits */
+#define PRUSS_IEPCLK_IEP_OCP_CLK_ENBIT(0)
+
+/* ICSSG CORE_SYNC register bits */
+#define ICSSG_CORE_VBUSP_SYNC_EN BIT(0)
+
+/*
+ * pruss_request_tm_region() - Request pruss for task manager region
+ * @dev: corresponding k3 device
+ * @loc: the task manager physical address
+ *
+ * Return: 0 if all goes good, else appropriate error message.
+ */
+int pruss_request_tm_region(struct udevice *dev, phys_addr_t *loc)
+{
+ struct pruss *priv;
+
+ priv = dev_get_priv(dev);
+ if (!priv || !priv->mem_regions[PRUSS_MEM_DRAM0].pa)
+ return -EINVAL;
+
+ *loc = priv->mem_regions[PRUSS_MEM_DRAM0].pa + ICSSG_TASK_MGR_OFFSET;
+
+ return 0;
+}
+
+/**
+ * pruss_request_mem_region() - request a memory resource
+ * @dev: the pruss device
+ * @mem_id: the memory resource id
+ * @region: pointer to memory region structure to be filled in
+ *
+ * This function allows a client driver to request a memory resource,
+ * and if successful, will let the client driver own the particular
+ * memory region until released using the pruss_release_mem_region()
+ * API.
+ *
+ * Returns the memory region if requested resource is available, an
+ * error otherwise
+ */
+int pruss_request_mem_region(struct udevice *dev, enum pruss_mem mem_id,
+struct pruss_mem_region *region)
+{
+ struct pruss *pruss;
+
+ pruss = dev_get_priv(dev);
+ if (!pruss || !region)
+ return -EINVAL;
+
+ if (mem_id >= PRUSS_MEM_MAX)
+ return -EINVAL;
+
+ if (pruss->mem_in_use[mem_id])
+ return -EBUSY;
+
+ *region = pruss->mem_regions[mem_id];
+ pruss->mem_in_use[mem_id] = region;
+
+ return 0;
+}
+
+/**
+ * pruss_release_mem_region() - release a memory resource
+ * @dev: the pruss device
+ * @region: the memory region to release
+ *
+ * This function is the complimentary function to
+ * pruss_request_mem_region(), and allows the client drivers to
+ * release back a memory resource.
+ *
+ * Returns 0 on success, an error code otherwise
+ */
+int pruss_release_mem_region(struct udevice *dev,
+struct pruss_mem_regio
[PATCH 0/5] remoteproc: pru: Add remoteproc support for AM65 PRUSS
This series adds support for remoteproc driver for PRUSS in AM65 SoCs. Keerthy (2): soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCs Lokesh Vutla (3): arm: dts: k3-am654-base-board: Add r5 specific u-boot dtsi arm: dts: ti: k3-am65-main: Add ICSSG nodes configs: am65x_evm_a53: Enable PRUSS remoteproc arch/arm/dts/k3-am65-main.dtsi| 463 ++ arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 191 ++-- .../dts/k3-am654-r5-base-board-u-boot.dtsi| 193 arch/arm/dts/k3-am654-r5-base-board.dts | 2 - configs/am65x_evm_a53_defconfig | 2 + drivers/remoteproc/Kconfig| 11 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/pru_rproc.c| 461 + drivers/soc/ti/Kconfig| 11 + drivers/soc/ti/Makefile | 1 + drivers/soc/ti/pruss.c| 217 include/linux/pruss_driver.h | 227 + 12 files changed, 1625 insertions(+), 155 deletions(-) create mode 100644 arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi create mode 100644 drivers/remoteproc/pru_rproc.c create mode 100644 drivers/soc/ti/pruss.c create mode 100644 include/linux/pruss_driver.h -- 2.31.1
Re: [PATCH v2 0/7] J72xx: R5 SPL DMA support post HSM Rearch
On 07/06/21 7:47 pm, Vignesh Raghavendra wrote: > This series add DMA support for R5 SPL on J721e/J7200 SoCs post HSM > Rearch. > > Depends on Tero's base HSM rearch support series. > > v2: > Use IS_ENABLED() consistentially instead of #ifdef > Reword commit msg for 5/7 as suggested by Lokesh > Rebase on Tero's latest HSM base series. I see the folloiwing build warnings with this series: arch/arm/dts/k3-j7200-common-proc-board.dtb: Warning (reg_format): /bus@10/bus@2838/mcu-navss/ringacc@2b80:reg: property has invalid length (80 bytes) (#address-cells == 2, #size-cells == 1) arch/arm/dts/k3-j7200-common-proc-board.dtb: Warning (avoid_default_addr_size): /bus@10/bus@2838/mcu-navss/ringacc@2b80: Relying on default #address-cells value arch/arm/dts/k3-j7200-common-proc-board.dtb: Warning (avoid_default_addr_size): /bus@10/bus@2838/mcu-navss/ringacc@2b80: Relying on default #size-cells value arch/arm/dts/k3-j7200-common-proc-board.dtb: Warning (avoid_default_addr_size): /bus@10/bus@2838/mcu-navss/dma-controller@285c: Relying on default #address-cells value arch/arm/dts/k3-j7200-common-proc-board.dtb: Warning (avoid_default_addr_size): /bus@10/bus@2838/mcu-navss/dma-controller@285c: Relying on default #size-cells value arch/arm/dts/k3-j7200-r5-common-proc-board.dtb: Warning (reg_format): /bus@10/bus@2838/mcu-navss/ringacc@2b80:reg: property has invalid length (80 bytes) (#address-cells == 2, #size-cells == 1) arch/arm/dts/k3-j7200-r5-common-proc-board.dtb: Warning (avoid_default_addr_size): /bus@10/bus@2838/mcu-navss/ringacc@2b80: Relying on default #address-cells value arch/arm/dts/k3-j7200-r5-common-proc-board.dtb: Warning (avoid_default_addr_size): /bus@10/bus@2838/mcu-navss/ringacc@2b80: Relying on default #size-cells value arch/arm/dts/k3-j7200-r5-common-proc-board.dtb: Warning (avoid_default_addr_size): /bus@10/bus@2838/mcu-navss/dma-controller@285c: Relying on default #address-cells value arch/arm/dts/k3-j7200-r5-common-proc-board.dtb: Warning (avoid_default_addr_size): /bus@10/bus@2838/mcu-navss/dma-controller@285c: Relying on default #size-cells value Can you fix it or send me fix, Ill can squash? Thanks and regards, Lokesh > > > Vignesh Raghavendra (7): > mailbox: k3-sec-proxy: Add DM to DMSC communication thread > firmware: ti_sci: Implement GET_RANGE with static data > firmware: ti_sci: Add support for Resoure Management at R5 SPL stage. > ARM: dts: j72xx-r5-common-proc-board: Add DM firmware node > ARM: dts: k3: Add cfg register space for ringacc and udmap > soc: ti: k3-navss-ringacc: Add support for native configuration of > rings > dma: ti: k3-udma: Add support for native configuration of chan/flow > > arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 14 ++ > .../k3-j7200-common-proc-board-u-boot.dtsi| 26 +++ > .../arm/dts/k3-j7200-r5-common-proc-board.dts | 17 ++ > .../k3-j721e-common-proc-board-u-boot.dtsi| 14 ++ > .../arm/dts/k3-j721e-r5-common-proc-board.dts | 18 ++ > .../firmware/ti,j721e-dm-sci.txt | 32 > drivers/dma/ti/k3-udma-u-boot.c | 177 ++ > drivers/dma/ti/k3-udma.c | 42 - > drivers/firmware/ti_sci.c | 107 +++ > drivers/firmware/ti_sci_static_data.h | 92 + > drivers/mailbox/k3-sec-proxy.c| 2 +- > drivers/soc/ti/k3-navss-ringacc-u-boot.c | 61 ++ > drivers/soc/ti/k3-navss-ringacc.c | 36 +++- > 13 files changed, 630 insertions(+), 8 deletions(-) > create mode 100644 doc/device-tree-bindings/firmware/ti,j721e-dm-sci.txt > create mode 100644 drivers/dma/ti/k3-udma-u-boot.c > create mode 100644 drivers/firmware/ti_sci_static_data.h > create mode 100644 drivers/soc/ti/k3-navss-ringacc-u-boot.c >
Re: [PATCHv5 00/26] Re-base / re-post of TI-K3 HSM rearch series
On 08/06/21 11:57 am, Tero Kristo wrote: > On 07/06/2021 14:22, Lokesh Vutla wrote: >> >> >> On 03/06/21 12:02 pm, Tero Kristo wrote: >>> Hi, >>> >>> As requested, this is just a rebase to the latest u-boot tip. >>> >>> Boot tested on j721e to make sure nothing got broken. >> >> There are some build errors. Can you take a look? >> https://source.denx.de/u-boot/custodians/u-boot-ti/-/jobs/275511 > > Hmm yeah, HS boards fail building. Attached fix, do you want me to re-post or > do > you want to squash this in? Can you point me to the patch no to squash this patch? Thanks and regards, Lokesh > > -Tero
Re: [PATCH v3 00/19] am335x, guardian: update board specific changes
On 28/05/21 3:00 pm, gireesh.hirem...@in.bosch.com wrote: > From: Gireesh Hiremath > > address the v2 review comments > >> Hi Gireesh, >> >> On 22/04/21 7:01 pm, gireesh.hirem...@in.bosch.com wrote: >>> From: Gireesh Hiremath >>> >>> add support for updated TI clock driver, backlight, splash screen, swi >>> logic, add ubi fastmap support, update pinmux, code clean up >>> >>> address the v1 review comments like: >>> split board changes and defconfig changes into separate patches, >>> adding clock support There are some build errors with this series, can you take a look?: https://source.denx.de/u-boot/custodians/u-boot-ti/-/jobs/275470 Thanks and regards, Lokesh >> >> Overall looks good. Just minor comments: >> - For config file changes can you make $subject as >> configs: am335x_guardian: ... >> - Can you rebase on top of latest master? >> >> Thanks and regards, >> Lokesh > > Hi Lokesh, > > config file subject changed to > configs: am335x_guardian:... > rebased to latest master branch > > Thanks and regards, > Gireesh Hiremath > > Gireesh Hiremath (16): > configs: am335x_guardian: Enable clock driver > configs: am335x_guardian: add ubi fastmap support > configs: am335x_guardian: add memtest configs > am335x, guardian: add memtest address range > am335x, guardian: set environment variable autoload to no > am335x, guardian: code cleanup and boot optimization > configs: am335x_guardian: set boot delay > configs: am335x_guardian: disable spl command > am335x, guardian: update swi logic > am335x, guardian: Enable backlight > configs: am335x_guardian: Enable display config > drivers: video: hx8238 fix build bug > am335x, guardian: Enable panel driver Himax HX8238D > am335x, guardian: software update available status is stored in AM3352 > RTC scracth register > configs: am335x_guardian: Enable bootcount nvmem support > configs: am335x_guardian: add register maps support > > Moses Christopher (3): > am335x, guardian: mem: Add board dependent mem values > am335x, guardian: set tftp_load_addr in environment > am335x, guardian: Update pinmux configuration > > arch/arm/dts/am335x-guardian-u-boot.dtsi | 11 ++ > arch/arm/dts/am335x-guardian.dts | 14 +- > .../include/asm/arch-am33xx/mem-guardian.h| 63 > arch/arm/mach-omap2/am33xx/Kconfig| 2 + > arch/arm/mach-omap2/am33xx/board.c| 4 + > arch/arm/mach-omap2/mem-common.c | 4 + > board/bosch/guardian/board.c | 151 +++--- > board/bosch/guardian/mux.c| 3 +- > configs/am335x_guardian_defconfig | 28 +++- > drivers/bootcount/Kconfig | 27 +++- > drivers/bootcount/Makefile| 1 + > drivers/bootcount/bootcount_nvmem.c | 57 +++ > drivers/video/Makefile| 2 +- > drivers/video/hx8238d.c | 4 +- > include/configs/am335x_guardian.h | 21 ++- > 15 files changed, 350 insertions(+), 42 deletions(-) > create mode 100644 arch/arm/include/asm/arch-am33xx/mem-guardian.h > create mode 100644 drivers/bootcount/bootcount_nvmem.c >
Re: [PATCHv5 00/26] Re-base / re-post of TI-K3 HSM rearch series
On 03/06/21 12:02 pm, Tero Kristo wrote: > Hi, > > As requested, this is just a rebase to the latest u-boot tip. > > Boot tested on j721e to make sure nothing got broken. There are some build errors. Can you take a look? https://source.denx.de/u-boot/custodians/u-boot-ti/-/jobs/275511 Thanks and regards, Lokesh > > -Tero > >
Re: [PATCH v2 4/5] watchdog: rti_wdt: Add support for loading firmware
+Tom, Hi Tom, On 02/06/21 3:07 pm, Jan Kiszka wrote: > From: Jan Kiszka > > To avoid the need of extra boot scripting on AM65x for loading a > watchdog firmware, add the required rproc init and loading logic for the > first R5F core to the watchdog start handler. In case the R5F cluster is > in lock-step mode, also initialize the second core. The firmware itself > is embedded into U-Boot binary to ease access to it and ensure it is > properly hashed in case of secure boot. > > One possible firmware source is https://github.com/siemens/k3-rti-wdt. > > Signed-off-by: Jan Kiszka > --- > drivers/watchdog/Kconfig | 20 > drivers/watchdog/Makefile | 5 +++ > drivers/watchdog/rti_wdt.c| 58 ++- > drivers/watchdog/rti_wdt_fw.S | 20 > 4 files changed, 102 insertions(+), 1 deletion(-) > create mode 100644 drivers/watchdog/rti_wdt_fw.S > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index f0ff2612a6..1a1fddfe9f 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -209,6 +209,26 @@ config WDT_K3_RTI > Say Y here if you want to include support for the K3 watchdog > timer (RTI module) available in the K3 generation of processors. > > +if WDT_K3_RTI > + > +config WDT_K3_RTI_LOAD_FW > + bool "Load watchdog firmware" > + depends on REMOTEPROC > + help > + Automatically load the specified firmware image into the MCU R5F > + core 0. On the AM65x, this firmware is supposed to handle the expiry > + of the watchdog timer, typically by resetting the system. > + > +config WDT_K3_RTI_FW_FILE > + string "Watchdog firmware image file" > + default "k3-rti-wdt.fw" > + depends on WDT_K3_RTI_LOAD_FW > + help > + Firmware image to be embedded into U-Boot and loaded on watchdog > + start. I need your input on this proach. Is it okay to include the linker file unders drivers? > + > +endif > + > config WDT_SANDBOX > bool "Enable Watchdog Timer support for Sandbox" > depends on SANDBOX && WDT > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > index 5c7ef593fe..5016ee4708 100644 > --- a/drivers/watchdog/Makefile > +++ b/drivers/watchdog/Makefile > @@ -33,7 +33,12 @@ obj-$(CONFIG_WDT_OCTEONTX) += octeontx_wdt.o > obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o > obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o > obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o > +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o > obj-$(CONFIG_WDT_SP805) += sp805_wdt.o > obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o > obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o > obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o > + [...snip..] > timer_margin = timeout_ms * priv->clk_khz / 1000; > timer_margin >>= WDT_PRELOAD_SHIFT; > if (timer_margin > WDT_PRELOAD_MAX) > diff --git a/drivers/watchdog/rti_wdt_fw.S b/drivers/watchdog/rti_wdt_fw.S > new file mode 100644 > index 00..78d99ff9f2 > --- /dev/null > +++ b/drivers/watchdog/rti_wdt_fw.S Isn't this usecase specific? IMHO, drivers might not be the right place. Did I misunderstand something? Thanks and regards, Lokesh > @@ -0,0 +1,20 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (c) Siemens AG, 2020 > + * > + * Authors: > + * Jan Kiszka > + */ > + > +.section .rodata > + > +.global rti_wdt_fw > +.global rti_wdt_fw_size > + > +rti_wdt_fw: > +.align 4 > +.incbin CONFIG_WDT_K3_RTI_FW_FILE > +rti_wdt_fw_end: > + > +rti_wdt_fw_size: > +.int rti_wdt_fw_end - rti_wdt_fw >
Re: [PATCH v2] Nokia RX-51: Enable CONFIG_WDT to remove deprecation warning
On 10/03/21 1:49 am, Pali Rohár wrote: > Also convert CONFIG_HW_WATCHDOG to CONFIG_WATCHDOG. > > Signed-off-by: Pali Rohár > --- > This patch increase u-boot.bin binary size above maximal limit. So this > patch cannot be applied yet. But it can be applied on top of the LTO > patches. So please put this patch into the queue and include it into > U-Boot after LTO patches are merged. Hi, Can you ping me once the LTO patches are merged? Thanks and regards, Lokesh
Re: [PATCH 0/3] J7200: Add support for HS400 speed mode
On 25/05/21 3:08 pm, Aswath Govindraju wrote: > The following series of patches add support for HS400 speed mode on J7200 > SoC. > > For HS400 support to work, the following series of patches depend on, > https://patchwork.ozlabs.org/project/uboot/patch/20210405144428.12159-1-a-govindr...@ti.com/ Can you ping me once the above patch is merged? Thanks and regards, Lokesh
Re: [PATCH 00/10] AM642-EVM: Add USB support
On 01/06/21 9:43 pm, Aswath Govindraju wrote: > Hi all, > > On 01/06/21 8:43 pm, Aswath Govindraju wrote: >> The following series of patches add support for the following >> - Kconfig symbol for giving the load address for ATF >> - USB Mass storrage boot mode in AM642-EVM >> - DFU boot mode in AM642-EVM >> - Host and peripheral modes for AM642-EVM in U-Boot >> - Set the USB PHY core voltage to 0.85V >> > > Patch 9 is dependent on, > https://patchwork.ozlabs.org/project/uboot/patch/20210601112147.10253-1-a-govindr...@ti.com/ Please ping me once the above patch is merged. Thanks and regards, Lokesh
Re: [PATCH 01/10] tools: k3_fit_atf: Add support for providing ATF load address using a Kconfig symbol
On 01/06/21 8:43 pm, Aswath Govindraju wrote: > Add support for providing ATF load address with a Kconfig symbol. > > Signed-off-by: Aswath Govindraju > --- > arch/arm/mach-k3/Kconfig | 7 +++ > arch/arm/mach-k3/config.mk | 1 + > tools/k3_fit_atf.sh| 9 ++--- > 3 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig > index bfbce44bfa59..2c46d7a3a798 100644 > --- a/arch/arm/mach-k3/Kconfig > +++ b/arch/arm/mach-k3/Kconfig > @@ -147,6 +147,13 @@ config SYS_K3_SPL_ATF > Enabling this will try to start Cortex-A (typically with ATF) > after SPL from R5. > > +config K3_ATF_LOAD_ADDR > + hex "Load address of ATF image" > + default 0x700 shouldn't this be 0x7000 ? Thanks and regards, Lokesh
Re: [PATCHv4 00/26] J72xx: HSM rearch support series
Hi Tero, On 11/05/21 2:00 pm, Tero Kristo wrote: > Hello, > > Couple of small changes in v4: > - re-worked patch #14 to include review comments from Jaehoon Chung > * changed code to use iopoll version instead of hand crafted loops > for timeout handling > * other mostly cosmetic changes > - patch #19/#21 changed to allow RM init to happen based on comment > from Vignesh Can you please rebase on top of latest u-boot and re-post? Thanks and regards, Lokesh > > -Tero > >
[GIT PULL] TI changes for v2021.07 rc4
Hi Tom, Please find the PR for master branch targeted for v2021.07-rc4 release. Details about the PR are updated in the tag message. Gitlab CI report: https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7645 The following changes since commit e1bf0336a58cfe873a34c36ff53e5e3806f2d263: Prepare v2021.07-rc3 (2021-05-24 20:53:13 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.07-rc4 for you to fetch changes up to fed603f868469a0d8f2548bdac137feead333c6b: ARM: ti: Increase the allocated size for MLO.raw (2021-05-27 14:56:42 +0530) - Fix reset for AM64 platforms - Enable networking PHY driver for AM64 - Fix default R5F cluster setting in J7 Dave Gerlach (1): firmware: ti_sci: Update ti_sci_msg_req_reboot to include domain Faiz Abbas (1): ARM: ti: Increase the allocated size for MLO.raw Suman Anna (3): arm: dts: k3-j721e: Fix up MAIN R5FSS cluster mode back to Split-mode arm: dts: k3-am642-evm: Add sysreset controller node arm: dts: k3-am642-sk: Add sysreset controller node Vignesh Raghavendra (1): configs: am64x_evm_a53_defconfig: Enable DP83867 PHY driver arch/arm/dts/k3-am642-evm-u-boot.dtsi | 4 arch/arm/dts/k3-am642-sk-u-boot.dtsi| 4 arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 8 configs/am64x_evm_a53_defconfig | 1 + drivers/firmware/ti_sci.c | 1 + drivers/firmware/ti_sci.h | 2 ++ include/environment/ti/dfu.h| 4 ++-- 7 files changed, 22 insertions(+), 2 deletions(-) -- 2.30.0
Re: [PATCH] configs: am64x_evm_a53_defconfig: Enable DP83867 PHY driver
On Wed, 12 May 2021 20:08:25 +0530, Vignesh Raghavendra wrote: > AM64x GP and SK EVM have DP83867 PHY connected to CPSW external port0. > Enable the driver in order to use ethernet at U-Boot prompt. > CONFIG_PHY_TI is selected by CONFIG_PHY_TI_DP83867 and thus can be dropped. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] configs: am64x_evm_a53_defconfig: Enable DP83867 PHY driver https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/df3fc620bb -- Thanks and Regards, Lokesh
Re: [PATCH v2] arm: dts: k3-j721e: Fix up MAIN R5FSS cluster mode back to Split-mode
On Tue, 18 May 2021 16:38:25 -0500, Suman Anna wrote:
> The default U-Boot environment variables and design are all set up for
> both the MAIN R5FSS clusters to be in Split-mode. This is the setting
> in v2021.01 U-Boot and the dt nodes are synched with the kernel binding
> property names in commit 468ec2f3ef8f ("remoteproc: k3_r5: Sync to
> upstreamed kernel DT property names") merged in v2021.04-rc2.
>
> The modes for both the clusters got switched back to LockStep mode by
> mistake in commit 70e167495ab2 ("arm: dts: k3-j721e: Sync Linux v5.11-rc6
> dts into U-Boot") also in v2021.04-rc2. This throws the following warning
> messages when early-booting the cores using default env variables,
>
> [...]
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc,
thanks!
[1/1] arm: dts: k3-j721e: Fix up MAIN R5FSS cluster mode back to Split-mode
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/4ec04073ab
--
Thanks and Regards,
Lokesh
Re: [PATCH 0/3] Fix 'reset' for TI K3 AM64x and J721E/J7200 boards
On Thu, 13 May 2021 20:10:54 -0500, Suman Anna wrote:
> The following patches fix the 'reset' command functionality for various
> TI K3 SoCs. Patches are based on the latest master that includes the
> AM64x board support, commit ea184cbff99e ("Merge tag 'ti-v2021.07-rc3'
> of https://source.denx.de/u-boot/custodians/u-boot-ti;).
>
> The first patch is needed for J721E/J7200 SoCs with newer System
> Firmwares (anything newer that 2020.04 SYSFW) and is backward
> compatible. Without this, the 'reset' command throws the following
> warnings,
> => reset
> resetting ...
> ti-sci-sysreset sysreset-controller: ti_sci_sysreset_request: reboot_device
> failed (-19)
> ti-sci-sysreset sysreset-controller: ti_sci_sysreset_request: reboot_device
> failed (-19)
> ti-sci-sysreset sysreset-controller: ti_sci_sysreset_request: reboot_device
> failed (-19)
> System reset not supported on this platform
> ### ERROR ### Please RESET the board ###
>
> [...]
Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc,
thanks!
[1/3] firmware: ti_sci: Update ti_sci_msg_req_reboot to include domain
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/beed30583c
[2/3] arm: dts: k3-am642-evm: Add sysreset controller node
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/a97ee92e4a
[3/3] arm: dts: k3-am642-sk: Add sysreset controller node
https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/7194a95d13
--
Thanks and Regards,
Lokesh
Re: [PATCH] ARM: ti: Increase the allocated size for MLO.raw
On Mon, 19 Apr 2021 12:20:27 +0530, Aswath Govindraju wrote: > MLO has increased to a size greater than the allocated > 128 kB in dfu_alt_info_emmc and _mmc. > > Therefore, double the allocated size for MLO.raw in > the default environment. Applied to https://source.denx.de/u-boot/custodians/u-boot-ti.git for-rc, thanks! [1/1] ARM: ti: Increase the allocated size for MLO.raw https://source.denx.de/u-boot/custodians/u-boot-ti/-/commit/fed603f868 -- Thanks and Regards, Lokesh
Re: [PATCH 6/7] rtc: davinci: add driver model support
On 07/05/21 9:45 am, Dario Binacchi wrote:
> Update the driver to support the device tree and the driver model.
> The read / write helpers in rtc_ops allow access to scratch registers
> only. The offset parameter is added to the address of the scratch0
> register.
>
> Signed-off-by: Dario Binacchi
> ---
>
> drivers/rtc/davinci.c | 373 --
> 1 file changed, 363 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/rtc/davinci.c b/drivers/rtc/davinci.c
> index 82e5eb3b43..b0a077cba7 100644
> --- a/drivers/rtc/davinci.c
> +++ b/drivers/rtc/davinci.c
> @@ -2,20 +2,20 @@
> /*
> * (C) Copyright 2011 DENX Software Engineering GmbH
> * Heiko Schocher
> + * Copyright (C) 2021 Dario Binacchi
> */
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
>
> -#if !defined(RTC_BASE) && defined(DAVINCI_RTC_BASE)
> -#define RTC_BASE DAVINCI_RTC_BASE
> -#endif
> -
> static void davinci_rtc_lock(struct davinci_rtc *rtc)
> {
> writel(0, >kick0r);
> @@ -52,9 +52,8 @@ static int davinci_rtc_wait_not_busy(struct davinci_rtc
> *rtc)
> return 0;
> }
>
> -int rtc_get(struct rtc_time *tmp)
> +static int davinci_rtc_get(struct davinci_rtc *rtc, struct rtc_time *tmp)
can we use use consistent naming? omap_rtc_?
> {
> - struct davinci_rtc *rtc = (struct davinci_rtc *)RTC_BASE;
> unsigned long sec, min, hour, mday, wday, mon_cent, year;
> int ret;
>
> @@ -92,9 +91,8 @@ int rtc_get(struct rtc_time *tmp)
> return 0;
> }
>
> -int rtc_set(struct rtc_time *tmp)
> +static int davinci_rtc_set(struct davinci_rtc *rtc, const struct rtc_time
> *tmp)
> {
> - struct davinci_rtc *rtc = (struct davinci_rtc *)RTC_BASE;
> int ret;
>
> ret = davinci_rtc_wait_not_busy(rtc);
> @@ -119,10 +117,365 @@ int rtc_set(struct rtc_time *tmp)
> return 0;
> }
>
> +static void davinci_rtc_reset(struct davinci_rtc *rtc)
> +{
> + /* run RTC counter */
> + writeb(0x01, >ctrl);
> +}
> +
> +#if !CONFIG_IS_ENABLED(DM_RTC)
Are there any users of non-DM? If not can we just drop the support for non-DM?
Thanks and regards,
Lokesh
Re: [PATCH 1/7] rtc: davinci: enable compilation for omap architectures
On 07/05/21 9:45 am, Dario Binacchi wrote: > The Davinci's onchip RTC is also present on TI OMAP1, AM33XX, AM43XX and > DRA7XX SOCs. So, let's enable compilation for these architectures too. > > Signed-off-by: Dario Binacchi > --- > > drivers/rtc/Kconfig | 7 +++ > drivers/rtc/davinci.c | 11 --- > 2 files changed, 15 insertions(+), 3 deletions(-) > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > index c84a9d2b27..cbdfddb80f 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -188,4 +188,11 @@ config RTC_ABX80X > families of ultra-low-power battery- and capacitor-backed real-time > clock chips. > > +config RTC_DAVINCI > + bool "Enable TI OMAP RTC driver" > + depends on ARCH_DAVINCI || ARCH_OMAP2PLUS I assume you are converting to a Kconfig symbol? Can you keep this as a separate patch and use tools/moveconfig.py? Thanks and regards, Lokesh
Re: [PATCH v2 00/18] am335x, guardian: update board specific changes
Hi Gireesh, On 22/04/21 7:01 pm, gireesh.hirem...@in.bosch.com wrote: > From: Gireesh Hiremath > > add support for updated TI clock driver, backlight, splash screen, > swi logic, add ubi fastmap support, update pinmux, code clean up > > address the v1 review comments like: > split board changes and defconfig changes into separate patches, > adding clock support Overall looks good. Just minor comments: - For config file changes can you make $subject as configs: am335x_guardian: ... - Can you rebase on top of latest master? Thanks and regards, Lokesh > > Gireesh Hiremath (15): > am335x, guardian: configs: Enable clock driver for guardian > am335x, guardian: configs: add ubi fastmap support > am335x, guardian: configs: cmd: add memtest configs > am335x, guardian: add memtest address range > am335x, guardian: set environment variable autoload to no > am335x, guardian: code cleanup and boot optimization > am335x, guardian: configs: set boot delay > am335x, guardian: configs: cmd : disable spl command > am335x, guardian: update swi logic > am335x, guardian: Enable backlight > am335x, guardian: configs: Enable display config > drivers: video: hx8238 fix build bug > am335x, guardian: Enable panel driver Himax HX8238D > am335x, guardian: software update available status is stored in AM3352 > RTC scracth register > am335x, guardian: configs: Enable bootcount nvmem support > > Moses Christopher (3): > am335x, guardian: mem: Add board dependent mem values > am335x, guardian: set tftp_load_addr in environment > am335x, guardian: Update pinmux configuration > > arch/arm/dts/am335x-guardian-u-boot.dtsi | 11 ++ > arch/arm/dts/am335x-guardian.dts | 14 +- > .../include/asm/arch-am33xx/mem-guardian.h| 63 > arch/arm/mach-omap2/am33xx/Kconfig| 2 + > arch/arm/mach-omap2/am33xx/board.c| 4 + > arch/arm/mach-omap2/mem-common.c | 4 + > board/bosch/guardian/board.c | 151 +++--- > board/bosch/guardian/mux.c| 3 +- > configs/am335x_guardian_defconfig | 27 +++- > drivers/bootcount/Kconfig | 27 +++- > drivers/bootcount/Makefile| 1 + > drivers/bootcount/bootcount_nvmem.c | 57 +++ > drivers/video/Makefile| 2 +- > drivers/video/hx8238d.c | 4 +- > include/configs/am335x_guardian.h | 21 ++- > 15 files changed, 349 insertions(+), 42 deletions(-) > create mode 100644 arch/arm/include/asm/arch-am33xx/mem-guardian.h > create mode 100644 drivers/bootcount/bootcount_nvmem.c >
[GIT PULL] TI changes for v2021.07 rc3
Hi Tom, Please find the PR for master branch targeted for v2021.07-rc1 release. Details about the PR are updated in the tag message. There are addition of new platform in this PR. I understand it is not expected to send these this late in the release. However, these are posted sometime ago and I could not spend time on these patches due to personal reasons. Please consider this as an exception and accept this PR. I ll try not to repeat this in future PRs. Gitlab build report: https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/7474 The following changes since commit b107761b817c421fb8eadee739656e1db38686c3: Prepare v2021.07-rc2 (2021-05-10 17:03:22 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.07-rc3 for you to fetch changes up to bbc9da58b332bd44e51ac5579040ea984b2f963b: ARM: dts: k3-am642-sk: Add ethernet related DT nodes (2021-05-12 16:36:39 +0530) - Initial support for AM64 EVM and SK - K3 DDR driver unification for J7 and AM64 platforms. - Minor fixes for TI clock driver Dario Binacchi (5): clk: ti: add custom API for memory access clk: ti: change clk_ti_latch() signature clk: ti: gate: use custom API for memory access clk: ti: am3-dpll: use custom API for memory access Revert "fdt: translate address if #size-cells = <0>" Dave Gerlach (30): arm: mach-k3: Add basic support for AM642 SoC definition arm: mach-k3: am642: Unlock all applicable control MMR registers arm: mach-k3: am642: Store boot info from ROM arm: mach-k3: am642: Load SYSFW binary and config from boot media arm: mach-k3: am642: Use mmc start and stop callbacks mmc: sdhci_am654: Add Support for TI's AM642 SoC mailbox: k3-sec-proxy: Extend valid thread IDs board: ti: am64x: Add board support for am64x evm dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64 arm: dts: ti: Add Support for AM642 SoC arm: dts: k3-am642: Add initial support for EVM arm: dts: k3-am642: Add r5 specific dt support configs: am64x_evm_r5: Add Initial support configs: am64x_evm_a53: Add Initial support dt-bindings: memory-controller: Add K3 AM64 DDRSS compatible ram: k3-j721e: lpddr4_address_slice_0_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_0_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_1_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_2_macros: Fix indentation issues ram: k3-j721e: lpddr4_data_slice_3_macros: Fix indentation issues ram: k3-j721e: lpddr4_ddr_controller_macros: Fix indentation issues ram: k3-j721e: lpddr4_phy_core_macros: Fix indentation issues ram: k3-j721e: lpddr4_pi_macros: Fix indentation issues ram: k3-j721e: lpddr4_ctl_regs: Fix checkpatch issue for types ram: k3-j721e: Rename to k3-ddrss ram: k3-ddrss: Introduce top-level CONFIG_K3_DDRSS ram: k3-ddrss: Introduce common driver with J7 SoC support ram: k3-ddrss: Introduce support for AM642 SoCs arm: dts: k3-am642: Add ddr node arm: mach-k3: am642: Add support for triggering ddr init from SPL Keerthy (2): arm: mach-k3: am642: Add support for boot device detection armv8: mach-k3: am642: Add custom MMU support Lokesh Vutla (19): ram: k3-ddrss: Enable vtt regulator if present soc: ti: k3-socinfo: Add entry for AM64X SoC family board: ti: am64x: Add support for reading eeprom data board: ti: am64x: Enable support for reading EEPROM in R5 SPL board: ti: am64x: Add support for detecting multiple device trees arm: am64x: Add support for selecting DT based on EEPROM include: configs: am64x: Avoid overlap of BSS and stack area include: configs: am64x_evm: Optimize size of SPL BSS include: configs: Update env for selecting right dtb arm: dts: k3-am64-evm: Make chip id available before pre-reloc arm: dts: k3-am642-r5-evm: Do not use power-domains for I2C arm: dts: am642-evm: Add I2C nodes arm: dts: am642-sk: Add initial sk dts arm: dts: am642-r5-sk: Add r5 specific dts configs: am64x_evm_r5: Enable checks for spl and stack sizes configs: am64x_evm_r5: Enable support for building multiple device trees configs: am64x_evm_a53: Enable configs for printing cpuinfo configs: am64x_evm_a53: Enable support for reading eeprom configs: am64x_evm_a53: Enable support for building multiple dtbs Nishanth Menon (3): arm: dts: k3-am64-main: Add GPIO nodes arm: dts: k3-am642-r5-evm: Add GPIO DDR VTT regulator configs: am64x_evm_r5: Enable GPIO regulator Suman Anna (1): arm: mach-k3: am642: Shut down R5 core after ATF startup on A53 Vignesh Raghavendra (13): board: ti: am64x: Parse MAC address from board EEPROM firmware: ti_sci: Update ti_sci_cmd_rm_udmap_tx_ch_cfg() API to the latest soc: ti: k3-navss-ringacc: Add AM64 ringacc support soc: ti: k3-navss-ringacc: Remove u
Re: [PATCH] board: ti: am64x: Parse MAC address from board EEPROM
On 10/05/21 11:44 pm, Vignesh Raghavendra wrote: > Parse MAC addresses from EEPROM and set them in the env. This is needed > to get MAC address for additional ethernet ports on the EVM. > > Signed-off-by: Vignesh Raghavendra Applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH 00/12] AM64x: DMA and ethernet support
On 10/05/21 8:06 pm, Vignesh Raghavendra wrote: > This series add ethernet and DMA support for AM64x SoC. Applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH 00/18] arm: k3-am64: Add initial support for AM64 SK
On 06/05/21 4:44 pm, Lokesh Vutla wrote: > AM642 StarterKit (SK) board is a low cost, small form factor board > designed for TI’s AM642 SoC. It supports the following interfaces: > * 2 GB LPDDR4 RAM > * x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode > * x1 USB 3.0 Type-A port > * x1 UHS-1 capable µSD card slot > * 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837 > * 512 Mbit OSPI flash > * x2 UART through UART-USB bridge > * XDS110 for onboard JTAG debug using USB > * Temperature sensors, user push buttons and LEDs > * 40-pin Raspberry Pi compatible GPIO header > * 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO) > * 54-pin header for Programmable Realtime Unit (PRU) IO pins > * Interface for remote automation. Includes: > * power measurement and reset control > * boot mode change > > This series adds support for: > - AM64 SoC detection > - AM64 board detection > - AM64 SK initial support > - Re-use EVM defconfigs for SK. > > This series depends on the following series: > - https://patchwork.ozlabs.org/user/todo/uboot/?series=240546 > - https://patchwork.ozlabs.org/user/todo/uboot/?series=241946 > - https://patchwork.ozlabs.org/user/todo/uboot/?series=242110 Fixed the timer clock frequency locally and applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH 00/17] arm: mach-k3: Initial Support for Texas Instruments AM642 Platform
On 23/04/21 9:57 pm, Dave Gerlach wrote: > Hi, > > This series adds initial support for the latest new SoC, AM642, > from Texas Instruments. > > Additional detail can be found in the patch descriptions, also > see AM64X Technical Reference Manual (SPRUIM2, Revised Jan 2021) > for further details: https://www.ti.com/lit/pdf/spruim2 Fixed the MAINTAINERS file and Timer clock frequency and applied to u-boot-ti/for-rc Thanks and regards, Lokesh > > Regards, > Dave > > Dave Gerlach (14): > arm: mach-k3: Add basic support for AM642 SoC definition > arm: mach-k3: am642: Unlock all applicable control MMR registers > arm: mach-k3: am642: Store boot info from ROM > arm: mach-k3: am642: Load SYSFW binary and config from boot media > arm: mach-k3: am642: Use mmc start and stop callbacks > mmc: sdhci_am654: Add Support for TI's AM642 SoC > mailbox: k3-sec-proxy: Extend valid thread IDs > board: ti: am64x: Add board support for am64x evm > dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM64 > arm: dts: ti: Add Support for AM642 SoC > arm: dts: k3-am642: Add initial support for EVM > arm: dts: k3-am642: Add r5 specific dt support > configs: am64x_evm_r5: Add Initial support > configs: am64x_evm_a53: Add Initial support > > Keerthy (2): > arm: mach-k3: am642: Add support for boot device detection > armv8: mach-k3: am642: Add custom MMU support > > Suman Anna (1): > arm: mach-k3: am642: Shut down R5 core after ATF startup on A53 > > arch/arm/dts/Makefile | 2 + > arch/arm/dts/k3-am64-main.dtsi| 405 ++ > arch/arm/dts/k3-am64-mcu.dtsi | 76 > arch/arm/dts/k3-am64.dtsi | 103 + > arch/arm/dts/k3-am642-evm-u-boot.dtsi | 58 +++ > arch/arm/dts/k3-am642-evm.dts | 246 +++ > arch/arm/dts/k3-am642-r5-evm.dts | 169 > arch/arm/dts/k3-am642.dtsi| 65 +++ > arch/arm/mach-k3/Kconfig | 15 +- > arch/arm/mach-k3/Makefile | 1 + > arch/arm/mach-k3/am642_init.c | 283 > arch/arm/mach-k3/arm64-mmu.c | 41 ++ > arch/arm/mach-k3/include/mach/am64_hardware.h | 52 +++ > arch/arm/mach-k3/include/mach/am64_spl.h | 44 ++ > arch/arm/mach-k3/include/mach/hardware.h | 4 + > arch/arm/mach-k3/include/mach/spl.h | 4 + > board/ti/am64x/Kconfig| 53 +++ > board/ti/am64x/Makefile | 8 + > board/ti/am64x/evm.c | 48 +++ > configs/am64x_evm_a53_defconfig | 96 + > configs/am64x_evm_r5_defconfig| 91 > drivers/mailbox/k3-sec-proxy.c| 10 +- > drivers/mmc/am654_sdhci.c | 18 + > include/configs/am64x_evm.h | 105 + > include/dt-bindings/pinctrl/k3.h | 5 +- > 25 files changed, 1988 insertions(+), 14 deletions(-) > create mode 100644 arch/arm/dts/k3-am64-main.dtsi > create mode 100644 arch/arm/dts/k3-am64-mcu.dtsi > create mode 100644 arch/arm/dts/k3-am64.dtsi > create mode 100644 arch/arm/dts/k3-am642-evm-u-boot.dtsi > create mode 100644 arch/arm/dts/k3-am642-evm.dts > create mode 100644 arch/arm/dts/k3-am642-r5-evm.dts > create mode 100644 arch/arm/dts/k3-am642.dtsi > create mode 100644 arch/arm/mach-k3/am642_init.c > create mode 100644 arch/arm/mach-k3/include/mach/am64_hardware.h > create mode 100644 arch/arm/mach-k3/include/mach/am64_spl.h > create mode 100644 board/ti/am64x/Kconfig > create mode 100644 board/ti/am64x/Makefile > create mode 100644 board/ti/am64x/evm.c > create mode 100644 configs/am64x_evm_a53_defconfig > create mode 100644 configs/am64x_evm_r5_defconfig > create mode 100644 include/configs/am64x_evm.h >
Re: [PATCH 0/5] arm: mach-k3: k3-am64: Add DDR configuration and enable
On 05/05/21 4:30 am, Dave Gerlach wrote: > This series adds the required configuration needed to use the new common > k3-ddrss driver on am64 and also adds the required dts data needed to > enable DDR usage on the k3-am642-evm platform. > > This series depends on the AM64 base support series [1] and the Common > K3 DDRSS series here [2]. > > Regards, > Dave Applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH v2 00/15] ram: k3-ddrss: Convert k3-j721e to common driver with k3-am64 support
On 11/05/21 8:51 pm, Dave Gerlach wrote: > This is v2 of the series to update the existing k3-j721e driver to a > common driver to support both j721e and the new am642 SoC. It renames > drivers/ram/k3-j721e to drivers/ram/k3-ddrss and then introduces a > refactored common driver with the existing j721e support moved to files > named with 32bit and am64 support introduced in files named with 16bit. > > Changes since v1: > * Drop unnecessary error macro re-definitions and use normal errno header > * Drop other unnecessary headers that wrap standard kernel headers > * Fixed a few camelCase functions that slipped through > * Fixed clock initialization sequence based on comment from Vignesh > > v1: https://lists.denx.de/pipermail/u-boot/2021-May/448716.html > Applied to u-boot-ti/for-rc Thanks and regards, Lokesh
Re: [PATCH v2 0/5] Revert "fdt: translate address if #size-cells = <0>"
On 01/05/21 8:35 pm, Dario Binacchi wrote:
>
> As pointed by [1] and [2] the d64b9cdcd4 ("fdt: translate address if
> #size-cells = <0>")
> commit was wrong. The series reverts the patch and fixes the issue with
> platform code, adding custom routines to access the clocks registers.
> The solution has been inspired by the Linux Kernel code.
>
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/1614324949-61314-1-git-send-email-bmeng...@gmail.com/
> [2]
> https://lore.kernel.org/linux-clk/20210402192054.7934-1-dario...@libero.it/T/
>
> Changes in v2:
> - Remove #if CONFIG_IS_ENABLED(AM33XX). It was counter intuitive.
> - Added Bin Meng Reviewed-by tag.
>
Applied to u-boot-ti/for-rc
Thanks and regards,
Lokesh
Re: [PATCH 5/7] ARM: dts: k3: Add cfg register space for ringacc and udmap
On 12/05/21 11:50 am, Vignesh Raghavendra wrote: > > > On 5/12/21 11:40 AM, Lokesh Vutla wrote: >> >> >> On 11/05/21 11:34 am, Vignesh Raghavendra wrote: >>> >>> >>> On 5/11/21 10:21 AM, Lokesh Vutla wrote: >>>> >>>> >>>> On 10/05/21 10:54 pm, Vignesh Raghavendra wrote: >>>>> R5 SPL needs access to cfg space of Rings and UDMAP, therefore add RING >>>>> CFG, TCHAN CFG and RCHAN CFG address ranges. >>>>> >>>>> Signed-off-by: Vignesh Raghavendra >>>>> --- >>>>> arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 14 ++ >>>>> .../k3-j7200-common-proc-board-u-boot.dtsi| 26 +++ >>>>> .../k3-j721e-common-proc-board-u-boot.dtsi| 14 ++ >>>> >>>> If these are specific to R5, then it should be moved to R5 dts no? >>>> -u-boot.dtsi >>>> will be applied to A53 dts as well. >>>> >>> >>> Not really.. There registers are present within respective IPs. A53/A72 >>> use DM APIs to configure these registers whereas R5 does direct >>> programming. I intend to add these ranges to kernel DT as well. Until >>> then, will be in -u-boot.dtsi. >>> >> >> You intend to add mcu-navss ringacc to kernel dts as well. I am fine with >> this. > > MCU RINGACC node itself is present in kernel dts, its just cfg register > ranges that are not populated. okay, please mention this intention in commit description. It says needed only for R5 but code is in u-boot.dtsi with the intention of being added in kernel dts. It is confusing. Thanks and regards, Lokesh
