Re: Please pull u-boot-marvell/master
On Fri, Apr 14, 2023 at 08:09:05AM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the following Marvell MVEBU related patches: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-sunxi/master for v2023.07
On Thu, Apr 13, 2023 at 11:20:48AM +0100, Andre Przywara wrote: > Hi Tom, > > please pull the sunxi/master branch, containing the first part of the > 2023.07 changes. > > The biggest change is some refactoring of the H616 DRAM driver, which > allows better fine-tuning for each board, and is the base for pending > LPDDR3 and LPDDR4 support, needed by new boards. > The sun8i-emac Ethernet driver sees some refactoring that enables it for > the Allwinner D1 EMAC IP. The sunxi HDMI driver is now using more DT > properties. Also the early SPL code now supports some odd H616 SoC > variant. > > There are some more patches pending, that require the final review > touches and some testing, I will send a separate PR for them later. > > The gitlab CI completed successfully, and I boot tested a few boards with > different SoCs, via FEL and SD card, into Linux. > > Thanks, > Andre > > === > The following changes since commit 9e804638bfe2693a908abf066ff66c251572afa7: > > Merge tag 'for-v2023-07-rc1' of > https://source.denx.de/u-boot/custodians/u-boot-i2c (2023-04-11 09:29:28 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master > > for you to fetch changes up to 5fc892e83f34a0b082ff46d3cc411d6813c1f726: > > sunxi: A64: drop boot0 header reservation (2023-04-12 00:17:22 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] board: ti: j721s2: Add support to detect daughtercards
On Tue, Apr 11, 2023 at 01:09:23PM +0530, Siddharth Vadapalli wrote: > Hello Tom, > > On 10/04/23 19:00, Tom Rini wrote: > > On Mon, Apr 10, 2023 at 11:40:15AM +0530, Siddharth Vadapalli wrote: > > > >> From: Kishon Vijay Abraham I > >> > >> Add support to detect daughtercards (GESI Ethernet card) in-order > >> to set the MAC address of the main CPSW2G interface. > >> > >> Signed-off-by: Kishon Vijay Abraham I > >> Signed-off-by: Siddharth Vadapalli > >> --- > >> board/ti/j721s2/evm.c | 130 ++ > >> 1 file changed, 130 insertions(+) > > > > Do we (a) use this interface in U-Boot? If not (b) can Linux not read > > Yes, the MAIN CPSW2G interface can be used in U-Boot. Alright, thanks. -- Tom signature.asc Description: PGP signature
[PATCH V3 1/3] net: phy: dp83867: Explicitly check against sgmii
dp83867 driver only supports sgmii and not all the newer protocols.
Drop the usage of the generic phy_interface_is_sgmii function and just
matchup to the specific mode supported.
Reported-by: Tom Rini
Suggested-by: Marek Vasut
Suggested-by: Marek Behún
Link:
https://lore.kernel.org/all/b82ac325-4818-8e72-054b-640268dbf...@mailbox.org/
Signed-off-by: Nishanth Menon
---
Changes since v2:
* New patch.
drivers/net/phy/dp83867.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index b861bf7cef36..7111e36aa0d0 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -330,7 +330,7 @@ static int dp83867_config(struct phy_device *phydev)
DP83867_RGMIIDCTL, delay);
}
- if (phy_interface_is_sgmii(phydev)) {
+ if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
if (dp83867->sgmii_ref_clk_en)
phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_SGMIICTL,
DP83867_SGMII_TYPE);
--
2.40.0
[PATCH V3 2/3] net: phy: Drop phy_interface_is_sgmii
Recent commit 75d28899e3e9 ("net: phy: Synchronize PHY interface modes
with Linux") reordered the enum definitions. This caused the range of
enums that this api was checking to go bad.
There aren't anymore users of phy_interface_is_sgmii, so, just drop
it. Also the protocols are so very different that it makes no sense to
provide a helper wrapper in the hope of reuse for phy drivers.
Reported-by: Tom Rini
Suggested-by: Marek Vasut
Suggested-by: Marek Behún
Link: https://lore.kernel.org/all/20230414103852.38705065@dellmb/
Signed-off-by: Nishanth Menon
---
Changes Since v2:
* Redone the patch, but original versions below (did'nt make sense to
carry reviewed-by)
* Just drop the phy_interface_is_sgmii
V2: https://lore.kernel.org/r/20230414042433.3436425-2...@ti.com
V1: https://lore.kernel.org/r/20230413180713.2922524-2...@ti.com
include/phy.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/phy.h b/include/phy.h
index a837fed72352..cb87d1d4fc95 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -365,18 +365,6 @@ static inline bool phy_interface_is_rgmii(struct
phy_device *phydev)
phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
}
-/**
- * phy_interface_is_sgmii - Convenience function for testing if a PHY interface
- * is SGMII (all variants)
- * @phydev: the phy_device struct
- * @return: true if MII bus is SGMII or false if it is not
- */
-static inline bool phy_interface_is_sgmii(struct phy_device *phydev)
-{
- return phydev->interface >= PHY_INTERFACE_MODE_SGMII &&
- phydev->interface <= PHY_INTERFACE_MODE_QSGMII;
-}
-
bool phy_interface_is_ncsi(void);
/* PHY UIDs for various PHYs that are referenced in external code */
--
2.40.0
[PATCH V3 3/3] net: phy: Make phy_interface_is_rgmii a switch statement
Recent commit 75d28899e3e9 ("net: phy: Synchronize PHY interface modes
with Linux") reordered the enum definitions. This exposed a problem
in range checking functions to identify the interface type. Though
this specific api wasn't impacted (all the RGMII definitions remained
within range), this experience should be used to never to have to face
this kind of challenge again.
While it is possible for the phy drivers to use the enums directly,
drivers such as dp83867, dp83869, marvell, micrel_ksz90x1 etc use this
api.
Reported-by: Tom Rini
Reviewed-by: Marek Vasut
Reviewed-by: Marek Behún
Signed-off-by: Nishanth Menon
---
Changes since V2:
* picked up reviewed-by
* s/was'nt/wasn't/g in commit message, minor rewording.
V2: https://lore.kernel.org/r/20230414042433.3436425-3...@ti.com
V1: https://lore.kernel.org/r/20230413180713.2922524-3...@ti.com
include/phy.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/phy.h b/include/phy.h
index cb87d1d4fc95..247223d92be7 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -361,8 +361,15 @@ int get_phy_id(struct mii_dev *bus, int addr, int devad,
u32 *phy_id);
*/
static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
{
- return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
- phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
+ switch (phydev->interface) {
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ return 1;
+ default:
+ return 0;
+ }
}
bool phy_interface_is_ncsi(void);
--
2.40.0
[PATCH V3 0/3] net: phy: phy_interface_is_rgmii update, drop phy_interface_is_sgmii
Originally reported by Tom[1], turned out to be that recent commit
75d28899e3e9 ("net: phy: Synchronize PHY interface modes with Linux")
reordered the enum definitions which in turn broke the range checks.
we are left with two options:
a) check against explicit values to help reuse as much as possible and
let compiler optimize where applicable
or
b) be very explicit in phy drivers and drop these helpers.
I have chosen to go with (a) approach.
Tested on am64x, though the dp83867 is used elsewhere as well.
Changes since V2:
* Dropped fixing up sgmii api, instead: just fixup the phy driver, drop
the api
* picked reviewed by for the rgmii
V2: https://lore.kernel.org/all/20230414042433.3436425-1...@ti.com/
V1: https://lore.kernel.org/all/20230413180713.2922524-1...@ti.com/
Nishanth Menon (3):
net: phy: dp83867: Explicitly check against sgmii
net: phy: Drop phy_interface_is_sgmii
net: phy: Make phy_interface_is_rgmii a switch statement
drivers/net/phy/dp83867.c | 2 +-
include/phy.h | 23 +--
2 files changed, 10 insertions(+), 15 deletions(-)
--
2.40.0
Re: [PATCH v3 0/5] enable DMA and CPSW nodes for am62ax SoC family
On 13:01-20230414, Bryan Brattlof wrote: > Hello again everyone! > > This patch series syncs TI's am62ax device tree files with what has been > merged in the v6.3-rc6 of the Linux Kernel. This series will also enable > YMODEM support to make automated testing (which uses the UART boot > method to load the bootloaders into the SoC) > > Thanks for reviewing > ~Bryan > > Changes from v2: [1] > - pulled linux dtbs from v6.3-rc6 instead of -rc4 > > Changed from v1: [0] > - Rebased on top of -next branch > - dropped 'u-boot,dm-spl' for the new 'bootph-pre-ram' properties > > [0] https://lore.kernel.org/u-boot/20230327184035.2128786-1...@ti.com/ > [1] https://lore.kernel.org/u-boot/20230402213617.1759491-1...@ti.com/ > > Bryan Brattlof (4): > arm: dts: sync am62ax dtbs with linux v6.3-rc6 > arm: dts: add DMA and CPSW nodes for uboot > configs: enable net features for am62ax > configs: am62ax: enable ymodem support for a53 spl > > Vignesh Raghavendra (1): > dma: ti: k3-udma: Introduce DMA support for the am62ax > > arch/arm/dts/k3-am62a-main.dtsi | 365 ++ > arch/arm/dts/k3-am62a-mcu.dtsi| 51 > arch/arm/dts/k3-am62a-wakeup.dtsi | 2 +- > arch/arm/dts/k3-am62a7-r5-sk.dts | 8 + NAK - not complete. This needs to drop everything duplicate => why is memory reserved-memory duplicate? chosen Please send the uart pinmux patches upstream. Remember: board.dts - included by u-boot.dtsi -> included by r5.dtsi there is 0 need to duplicate stuff. > arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 26 +- > arch/arm/dts/k3-am62a7-sk.dts | 75 +- > arch/arm/dts/k3-am62a7.dtsi | 1 + > configs/am62ax_evm_a53_defconfig | 7 +- > drivers/dma/ti/Makefile | 1 + > drivers/dma/ti/k3-psil-am62a.c| 196 ++ > drivers/dma/ti/k3-psil-priv.h | 1 + > drivers/dma/ti/k3-psil.c | 2 + > 12 files changed, 729 insertions(+), 6 deletions(-) > create mode 100644 drivers/dma/ti/k3-psil-am62a.c > > > base-commit: a25dcda452bf6a6de72764a8d990d72e5def643d > -- > 2.40.0 > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 3/5] arm: dts: add DMA and CPSW nodes for uboot
On 13:01-20230414, Bryan Brattlof wrote:
> Update the uboot dtsi to enable DMA and CPSW at the uboot level
>
> Signed-off-by: Bryan Brattlof
> ---
> arch/arm/dts/k3-am62a7-r5-sk.dts | 8
> arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 26 +-
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/k3-am62a7-r5-sk.dts
> b/arch/arm/dts/k3-am62a7-r5-sk.dts
> index c953a82c7a5e9..b4c2fd7f50038 100644
> --- a/arch/arm/dts/k3-am62a7-r5-sk.dts
> +++ b/arch/arm/dts/k3-am62a7-r5-sk.dts
> @@ -143,3 +143,11 @@
> status = "okay";
> bootph-pre-ram;
> };
> +
> +_pktdma {
> + ti,sci = <_tifs>;
> +};
> +
> +_bcdma {
> + ti,sci = <_tifs>;
> +};
> diff --git a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> index cf938c43b832e..fd3f7e63d5da6 100644
> --- a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
> @@ -15,7 +15,7 @@
> };
> };
>
> -_main{
> +_main {
> bootph-pre-ram;
>
> timer1: timer@240 {
> @@ -138,3 +138,27 @@
> _mmc1 {
> bootph-pre-ram;
> };
> +
> +_bcdma {
> + bootph-pre-ram;
> +};
> +
> +_pktdma {
> + bootph-pre-ram;
> +};
> +
> + {
> + reg = <0x00 0x0800 0x00 0x20>,
> + <0x00 0x43000200 0x00 0x8>;
> + reg-names = "cpsw_nuss", "mac_efuse";
mac_efuse needs to go to upstream kernel.
> + /delete-property/ ranges;
> + pinctrl-0 = <_mdio1_pins_default
> + _rgmii1_pins_default>;
Why not do this hack in board.dts and mark it due to MDIO limitation?
> + bootph-pre-ram;
> +
> + cpsw-phy-sel@04044 {
> + compatible = "ti,am64-phy-gmii-sel";
> + reg = <0x00 0x00104044 0x00 0x8>;
> + bootph-pre-ram;
> + };
> +};
> --
> 2.40.0
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v2 2/5] arm: dts: sync am62ax dtbs with linux v6.3-rc4
Hi Tom On April 2, 2023 thus sayeth Bryan Brattlof: > To enable Ethernet support at the uboot level, pull the device tree > files from the v6.3-rc4 version of the Linux kernel. > > Signed-off-by: Bryan Brattlof > --- > arch/arm/dts/k3-am62a-main.dtsi | 365 ++ > arch/arm/dts/k3-am62a-mcu.dtsi| 51 + > arch/arm/dts/k3-am62a-wakeup.dtsi | 2 +- > arch/arm/dts/k3-am62a7-sk.dts | 70 ++ > arch/arm/dts/k3-am62a7.dtsi | 1 + > 5 files changed, 488 insertions(+), 1 deletion(-) > I'm going to update this to pull in v6.3-rc6 to align with what Nishanth and Andrew have been doing so all the SoCs will be on the same tag ~Bryan
[PATCH v3 2/5] arm: dts: sync am62ax dtbs with linux v6.3-rc6
To enable Ethernet support at the uboot level, pull the device tree
files from the v6.3-rc6 version of the Linux kernel.
Signed-off-by: Bryan Brattlof
---
arch/arm/dts/k3-am62a-main.dtsi | 365 ++
arch/arm/dts/k3-am62a-mcu.dtsi| 51 +
arch/arm/dts/k3-am62a-wakeup.dtsi | 2 +-
arch/arm/dts/k3-am62a7-sk.dts | 75 +-
arch/arm/dts/k3-am62a7.dtsi | 1 +
5 files changed, 490 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/k3-am62a-main.dtsi b/arch/arm/dts/k3-am62a-main.dtsi
index bc4b50bcd1773..393a1a40b68b8 100644
--- a/arch/arm/dts/k3-am62a-main.dtsi
+++ b/arch/arm/dts/k3-am62a-main.dtsi
@@ -48,6 +48,18 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00 0x00 0x0010 0x2>;
+
+ phy_gmii_sel: phy@4044 {
+ compatible = "ti,am654-phy-gmii-sel";
+ reg = <0x4044 0x8>;
+ #phy-cells = <1>;
+ };
+
+ epwm_tbclk: clock-controller@4130 {
+ compatible = "ti,am62-epwm-tbclk", "syscon";
+ reg = <0x4130 0x4>;
+ #clock-cells = <1>;
+ };
};
dmss: bus@4800 {
@@ -69,6 +81,67 @@
interrupt-names = "rx_012";
interrupts = ;
};
+
+ inta_main_dmss: interrupt-controller@4800 {
+ compatible = "ti,sci-inta";
+ reg = <0x00 0x4800 0x00 0x10>;
+ #interrupt-cells = <0>;
+ interrupt-controller;
+ interrupt-parent = <>;
+ msi-controller;
+ ti,sci = <>;
+ ti,sci-dev-id = <28>;
+ ti,interrupt-ranges = <6 70 34>;
+ ti,unmapped-event-sources = <_bcdma>,
<_pktdma>;
+ };
+
+ main_bcdma: dma-controller@485c0100 {
+ compatible = "ti,am64-dmss-bcdma";
+ reg = <0x00 0x485c0100 0x00 0x100>,
+ <0x00 0x4c00 0x00 0x2>,
+ <0x00 0x4a82 0x00 0x2>,
+ <0x00 0x4aa4 0x00 0x2>,
+ <0x00 0x4bc0 0x00 0x10>;
+ reg-names = "gcfg", "bchanrt", "rchanrt", "tchanrt",
"ringrt";
+ msi-parent = <_main_dmss>;
+ #dma-cells = <3>;
+ ti,sci = <>;
+ ti,sci-dev-id = <26>;
+ ti,sci-rm-range-bchan = <0x20>; /* BLOCK_COPY_CHAN */
+ ti,sci-rm-range-rchan = <0x21>; /* SPLIT_TR_RX_CHAN */
+ ti,sci-rm-range-tchan = <0x22>; /* SPLIT_TR_TX_CHAN */
+ };
+
+ main_pktdma: dma-controller@485c {
+ compatible = "ti,am64-dmss-pktdma";
+ reg = <0x00 0x485c 0x00 0x100>,
+ <0x00 0x4a80 0x00 0x2>,
+ <0x00 0x4aa0 0x00 0x4>,
+ <0x00 0x4b80 0x00 0x40>;
+ reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+ msi-parent = <_main_dmss>;
+ #dma-cells = <2>;
+ ti,sci = <>;
+ ti,sci-dev-id = <30>;
+ ti,sci-rm-range-tchan = <0x23>, /* UNMAPPED_TX_CHAN */
+ <0x24>, /* CPSW_TX_CHAN */
+ <0x25>, /* SAUL_TX_0_CHAN */
+ <0x26>; /* SAUL_TX_1_CHAN */
+ ti,sci-rm-range-tflow = <0x10>, /*
RING_UNMAPPED_TX_CHAN */
+ <0x11>, /* RING_CPSW_TX_CHAN */
+ <0x12>, /* RING_SAUL_TX_0_CHAN
*/
+ <0x13>; /* RING_SAUL_TX_1_CHAN
*/
+ ti,sci-rm-range-rchan = <0x29>, /* UNMAPPED_RX_CHAN */
+ <0x2b>, /* CPSW_RX_CHAN */
+ <0x2d>, /* SAUL_RX_0_CHAN */
+ <0x2f>, /* SAUL_RX_1_CHAN */
+ <0x31>, /* SAUL_RX_2_CHAN */
+ <0x33>; /* SAUL_RX_3_CHAN */
+ ti,sci-rm-range-rflow = <0x2a>, /*
FLOW_UNMAPPED_RX_CHAN */
+ <0x2c>, /* FLOW_CPSW_RX_CHAN */
+ <0x2e>, /*
FLOW_SAUL_RX_0/1_CHAN */
+ <0x32>; /*
[PATCH v3 3/5] arm: dts: add DMA and CPSW nodes for uboot
Update the uboot dtsi to enable DMA and CPSW at the uboot level
Signed-off-by: Bryan Brattlof
---
arch/arm/dts/k3-am62a7-r5-sk.dts | 8
arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 26 +-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am62a7-r5-sk.dts b/arch/arm/dts/k3-am62a7-r5-sk.dts
index c953a82c7a5e9..b4c2fd7f50038 100644
--- a/arch/arm/dts/k3-am62a7-r5-sk.dts
+++ b/arch/arm/dts/k3-am62a7-r5-sk.dts
@@ -143,3 +143,11 @@
status = "okay";
bootph-pre-ram;
};
+
+_pktdma {
+ ti,sci = <_tifs>;
+};
+
+_bcdma {
+ ti,sci = <_tifs>;
+};
diff --git a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
index cf938c43b832e..fd3f7e63d5da6 100644
--- a/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am62a7-sk-u-boot.dtsi
@@ -15,7 +15,7 @@
};
};
-_main{
+_main {
bootph-pre-ram;
timer1: timer@240 {
@@ -138,3 +138,27 @@
_mmc1 {
bootph-pre-ram;
};
+
+_bcdma {
+ bootph-pre-ram;
+};
+
+_pktdma {
+ bootph-pre-ram;
+};
+
+ {
+ reg = <0x00 0x0800 0x00 0x20>,
+ <0x00 0x43000200 0x00 0x8>;
+ reg-names = "cpsw_nuss", "mac_efuse";
+ /delete-property/ ranges;
+ pinctrl-0 = <_mdio1_pins_default
+_rgmii1_pins_default>;
+ bootph-pre-ram;
+
+ cpsw-phy-sel@04044 {
+ compatible = "ti,am64-phy-gmii-sel";
+ reg = <0x00 0x00104044 0x00 0x8>;
+ bootph-pre-ram;
+ };
+};
--
2.40.0
[PATCH v3 5/5] configs: am62ax: enable ymodem support for a53 spl
Automated testing inside TI currently relies on loading the boot-loaders
into the SoC via UART. Enable SPL_YMODEM_SUPPORT so our testing
infrastructure can boot (and test) our boards.
Fixes: 719bd650c30e8 ("configs: introduce configs for the am62a")
Signed-off-by: Bryan Brattlof
---
configs/am62ax_evm_a53_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index e17bfd4dd2936..10c9d5268c846 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -34,6 +34,7 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
CONFIG_SPL_DM_MAILBOX=y
CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_YMODEM_SUPPORT=y
CONFIG_CMD_MMC=y
CONFIG_OF_CONTROL=y
CONFIG_SPL_OF_CONTROL=y
--
2.40.0
[PATCH v3 4/5] configs: enable net features for am62ax
Enable DMA and CPSW options we now support for the am62ax SoC family Signed-off-by: Bryan Brattlof --- configs/am62ax_evm_a53_defconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig index 46a95a692e9ac..e17bfd4dd2936 100644 --- a/configs/am62ax_evm_a53_defconfig +++ b/configs/am62ax_evm_a53_defconfig @@ -40,7 +40,6 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y -# CONFIG_NET is not set CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_REGMAP=y @@ -49,15 +48,20 @@ CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y CONFIG_CLK_TI_SCI=y +CONFIG_DMA_CHANNELS=y +CONFIG_TI_K3_NAVSS_UDMA=y CONFIG_TI_SCI_PROTOCOL=y # CONFIG_GPIO is not set # CONFIG_I2C is not set CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y +# CONFIG_SPL_MISC is not set CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ADMA=y CONFIG_SPL_MMC_SDHCI_ADMA=y CONFIG_MMC_SDHCI_AM654=y +CONFIG_PHY_TI_DP83867=y +CONFIG_TI_AM65_CPSW_NUSS=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_SINGLE=y -- 2.40.0
[PATCH v3 1/5] dma: ti: k3-udma: Introduce DMA support for the am62ax
From: Vignesh Raghavendra
In preparation for enabling ethernet for the am62ax family of SoCs,
introduce the initial DMA channel settings for the am62ax
Signed-off-by: Vignesh Raghavendra
[b...@ti.com: expanded on commit message]
Signed-off-by: Bryan Brattlof
---
drivers/dma/ti/Makefile| 1 +
drivers/dma/ti/k3-psil-am62a.c | 196 +
drivers/dma/ti/k3-psil-priv.h | 1 +
drivers/dma/ti/k3-psil.c | 2 +
4 files changed, 200 insertions(+)
create mode 100644 drivers/dma/ti/k3-psil-am62a.c
diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index 6807eb8e8b2d3..f4e0271efbf32 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -8,3 +8,4 @@ k3-psil-data-$(CONFIG_SOC_K3_J721E) += k3-psil-j721e.o
k3-psil-data-$(CONFIG_SOC_K3_J721S2) += k3-psil-j721s2.o
k3-psil-data-$(CONFIG_SOC_K3_AM642) += k3-psil-am64.o
k3-psil-data-$(CONFIG_SOC_K3_AM625) += k3-psil-am62.o
+k3-psil-data-$(CONFIG_SOC_K3_AM62A7) += k3-psil-am62a.o
diff --git a/drivers/dma/ti/k3-psil-am62a.c b/drivers/dma/ti/k3-psil-am62a.c
new file mode 100644
index 0..ca9d71f914220
--- /dev/null
+++ b/drivers/dma/ti/k3-psil-am62a.c
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#include
+
+#include "k3-psil-priv.h"
+
+#define PSIL_PDMA_XY_TR(x) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_PDMA_XY, \
+ .mapped_channel_id = -1,\
+ .default_flow_id = -1, \
+ }, \
+ }
+
+#define PSIL_PDMA_XY_PKT(x)\
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_PDMA_XY, \
+ .mapped_channel_id = -1,\
+ .default_flow_id = -1, \
+ .pkt_mode = 1, \
+ }, \
+ }
+
+#define PSIL_ETHERNET(x, ch, flow_base, flow_cnt) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 16, \
+ .mapped_channel_id = ch,\
+ .flow_start = flow_base,\
+ .flow_num = flow_cnt, \
+ .default_flow_id = flow_base, \
+ }, \
+ }
+
+#define PSIL_SAUL(x, ch, flow_base, flow_cnt, default_flow, tx)\
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 64, \
+ .mapped_channel_id = ch,\
+ .flow_start = flow_base,\
+ .flow_num = flow_cnt, \
+ .default_flow_id = default_flow,\
+ .notdpkt = tx, \
+ }, \
+ }
+
+#define PSIL_PDMA_MCASP(x) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_PDMA_XY, \
+ .pdma_acc32 = 1,\
+ .pdma_burst = 1,\
+ }, \
+ }
+
+#define PSIL_CSI2RX(x) \
+ { \
+ .thread_id = x, \
+
[PATCH v3 0/5] enable DMA and CPSW nodes for am62ax SoC family
Hello again everyone! This patch series syncs TI's am62ax device tree files with what has been merged in the v6.3-rc6 of the Linux Kernel. This series will also enable YMODEM support to make automated testing (which uses the UART boot method to load the bootloaders into the SoC) Thanks for reviewing ~Bryan Changes from v2: [1] - pulled linux dtbs from v6.3-rc6 instead of -rc4 Changed from v1: [0] - Rebased on top of -next branch - dropped 'u-boot,dm-spl' for the new 'bootph-pre-ram' properties [0] https://lore.kernel.org/u-boot/20230327184035.2128786-1...@ti.com/ [1] https://lore.kernel.org/u-boot/20230402213617.1759491-1...@ti.com/ Bryan Brattlof (4): arm: dts: sync am62ax dtbs with linux v6.3-rc6 arm: dts: add DMA and CPSW nodes for uboot configs: enable net features for am62ax configs: am62ax: enable ymodem support for a53 spl Vignesh Raghavendra (1): dma: ti: k3-udma: Introduce DMA support for the am62ax arch/arm/dts/k3-am62a-main.dtsi | 365 ++ arch/arm/dts/k3-am62a-mcu.dtsi| 51 arch/arm/dts/k3-am62a-wakeup.dtsi | 2 +- arch/arm/dts/k3-am62a7-r5-sk.dts | 8 + arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 26 +- arch/arm/dts/k3-am62a7-sk.dts | 75 +- arch/arm/dts/k3-am62a7.dtsi | 1 + configs/am62ax_evm_a53_defconfig | 7 +- drivers/dma/ti/Makefile | 1 + drivers/dma/ti/k3-psil-am62a.c| 196 ++ drivers/dma/ti/k3-psil-priv.h | 1 + drivers/dma/ti/k3-psil.c | 2 + 12 files changed, 729 insertions(+), 6 deletions(-) create mode 100644 drivers/dma/ti/k3-psil-am62a.c base-commit: a25dcda452bf6a6de72764a8d990d72e5def643d -- 2.40.0
Re: [PATCH v4 1/6] FWU: Add FWU metadata access driver for MTD storage regions
On Fri, Apr 14, 2023 at 8:56 AM Michal Simek wrote: > On 4/10/23 05:56, Jassi Brar wrote: > > On Wed, 29 Mar 2023 at 07:00, Michal Simek wrote: > >> On 3/27/23 23:15, jassisinghb...@gmail.com wrote: > > > >>> diff --git a/drivers/fwu-mdata/raw_mtd.c b/drivers/fwu-mdata/raw_mtd.c > >>> new file mode 100644 > >>> index 00..4b1a10073a > >>> --- /dev/null > >>> +++ b/drivers/fwu-mdata/raw_mtd.c > >>> @@ -0,0 +1,272 @@ > >>> +// SPDX-License-Identifier: GPL-2.0+ > >> > >> Just a note: Did you choose GPL-2.0+ by purpose? Or it is just c? > >> > > just c though isn't that the same as GPL-2.0-or-later ? > > license choice is up to you. We normally use just gpl-2.0. > I think more than "we", the subsystem dictates licensing. All FWU code is under GPL-2.0-or-later. > >> > >> As I said this DT binding should be approved first to make sure that we > >> don't > >> need to fix DT binding in future. Just simply do it right from the > >> begining. > >> > > Yes, I will cc Rob in the next submission (I only forgot last time). > > However, let us note that fwu-mdata-gpt.yaml isn't blessed either. > > I am not sure if there is any reason for the fwu node to even be in > > the dts for kernel. But sure it is good to have it eyeballed by the DT > > gods. > > It doesn't really go to kernel. > Simon pushed options node directly to dt-schema > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml#L96 > And that would be also location for this node too. > Yes, but I have resend the already existisng bindings in uboot. My patch only modified them. Not a big problem. -j
Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support
On 13/04/2023 12:05, yanhong wang wrote: On 2023/4/13 17:03, Torsten Duwe wrote: On Thu, 13 Apr 2023 10:05:28 +0800 yanhong wang wrote: the definition of DT refers to Linux and is consistent with the definition framework of Linux. This is one of the desired goals, to avoid confusion, usually. But note there are already the -u-boot.dtsi files; in this case it would be vice-versa: U-Boot could be simple, the kernel required a different treatment. As long as the resulting tree matches the hardware! The difference between 1.2A and 1.3B is the PHY type and phy clock delay configuration, which are reflected in DT, and the difference in defconfig is the configuration of the DT file. Is defconfig defined separately or merged? You are the implementer, this is your decision. You make a proposal, and it will get accepted or not. We only make suggestions, with the intention to improve the code. Thanks. A defconfig matches a piece of hardware, which is more developer-friendly and less confusing, so defconfig is better defined separately. My opinion isIn my opinion user-friendlyness is more important then developer friendly that from an end-user point of view it's much easier to have one binary that works on all different board versions. If not users will have to know which board version they have to flash the correct U-Boot. For the RaspberryPi we even went further and put effort into U-Boot development to have one U-Boot binary which can boot RPi3 and RPi4 boards. In that sense I would advise you to revisit your decision to put a developer-friendly approach over an end-user-friendly one. As Torsten said, it shouldn't be too difficult to update the device-tree at boot time to fit the actual board you are running U-Boot on. Just my thoughts about the issue :) Best regards, Matthias The EEPROM is being prepared and will be submitted as soon as possible. Is it necessary to incorporate EEPROM into this submission? When eeprom is supported, the MAC address will be read from eeprom. The board reversion can be read from eeprom, but phy clock delay configuration cannot be read from eeprom, only in DT. But the board revision number in EEPROM can be used to differentiate between 1.2 and 1.3, right? Yes, board reversion read from eeprom can distinguish between 1.2A and 1.3B. 1.2A and 1.3B are two sets of hardware, and the differences between the hardware are defined by DT, which is more concise and clear. When I look at the code and my test results, this is my proposal to pull this in, in order to simplify things and avoid duplication. Whether you do so is up to you, see above. Let me recap: * the device tree *must* match the hardware at hand. * the differences are minor and could be patched, Copy is error prone and causes extra work. It is my firm conviction that this patch set does not introduce hardware variants, and it would be the task of the ethernet driver patch set to split the code (DT+defconfig) OR to provide a patching method. Maybe I find a few cycles to look at the EEPROM. Torsten
Re: [PATCH v4 3/6] tools: Add mkfwumdata tool for FWU metadata image
On Fri, Apr 14, 2023 at 8:53 AM Michal Simek wrote: > > > > On 4/10/23 06:05, Jassi Brar wrote: > > On Wed, 29 Mar 2023 at 07:29, Michal Simek wrote: > >> On 3/27/23 23:16, jassisinghb...@gmail.com wrote: > > > >>> diff --git a/tools/mkfwumdata.c b/tools/mkfwumdata.c > >>> new file mode 100644 > >>> index 00..43dabf3b72 > >>> --- /dev/null > >>> +++ b/tools/mkfwumdata.c > >>> @@ -0,0 +1,334 @@ > >>> +// SPDX-License-Identifier: GPL-2.0+ > >>> +/* > >>> + * Copyright (c) 2023, Linaro Limited > >>> + */ > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +/* This will dynamically allocate the fwu_mdata */ > >>> +#define CONFIG_FWU_NUM_BANKS 0 > >>> +#define CONFIG_FWU_NUM_IMAGES_PER_BANK 0 > >> > >> These two are completely unused. > >> > > these are necessary for include/fwu_mdata.h that comes later. > > If that's come later, add it later. > Can you please actually look at the code to see the underlying constraint? -j
[PATCH v3] watchdog: arm_smc_wdt: add watchdog support
Implement a ARM SMCCC based driver that allow to use
a secure watchdog on the platform.
Signed-off-by: Lionel Debieve
Reviewed-by: Patrick Delaunay
Reviewed-by: Stefan Roese
Tested-by: Patrick Delaunay
---
Changes in v3:
- Adds missing log error when probe failed
Changes in v2:
- Adds log messages on error path
- Addressed coding style comments
- Applied review tags
drivers/watchdog/Kconfig | 8 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/arm_smc_wdt.c | 123 +
3 files changed, 132 insertions(+)
create mode 100644 drivers/watchdog/arm_smc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index b5ac8f7f50d..3a0341f609d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -352,6 +352,14 @@ config WDT_TANGIER
Intel Tangier SoC. If you're using a board with Intel Tangier
SoC, say Y here.
+config WDT_ARM_SMC
+ bool "ARM SMC watchdog timer support"
+ depends on WDT && ARM_SMCCC
+ imply WATCHDOG
+ help
+ Select this to enable Arm SMC watchdog timer. This watchdog will
manage
+ a watchdog based on ARM SMCCC communication.
+
config SPL_WDT
bool "Enable driver model for watchdog timer drivers in SPL"
depends on SPL_DM
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 446d961d7d2..a4633c0d2fa 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_$(SPL_TPL_)WDT) += wdt-uclass.o
obj-$(CONFIG_WDT_SANDBOX) += sandbox_wdt.o
obj-$(CONFIG_WDT_ALARM_SANDBOX) += sandbox_alarm-wdt.o
obj-$(CONFIG_WDT_APPLE) += apple_wdt.o
+obj-$(CONFIG_WDT_ARM_SMC) += arm_smc_wdt.o
obj-$(CONFIG_WDT_ARMADA_37XX) += armada-37xx-wdt.o
obj-$(CONFIG_WDT_ASPEED) += ast_wdt.o
obj-$(CONFIG_WDT_AST2600) += ast2600_wdt.o
diff --git a/drivers/watchdog/arm_smc_wdt.c b/drivers/watchdog/arm_smc_wdt.c
new file mode 100644
index 000..0ea5700
--- /dev/null
+++ b/drivers/watchdog/arm_smc_wdt.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * ARM Secure Monitor Call watchdog driver
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ * This file is based on Linux driver drivers/watchdog/arm_smc_wdt.c
+ */
+
+#define LOG_CATEGORY UCLASS_WDT
+
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "arm_smc_wdt"
+
+#define WDT_TIMEOUT_SECS(TIMEOUT) ((TIMEOUT) / 1000)
+
+enum smcwd_call {
+ SMCWD_INIT = 0,
+ SMCWD_SET_TIMEOUT = 1,
+ SMCWD_ENABLE= 2,
+ SMCWD_PET = 3,
+ SMCWD_GET_TIMELEFT = 4,
+};
+
+struct smcwd_priv_data {
+ u32 smc_id;
+ unsigned int min_timeout;
+ unsigned int max_timeout;
+};
+
+static int smcwd_call(struct udevice *dev, enum smcwd_call call,
+ unsigned long arg, struct arm_smccc_res *res)
+{
+ struct smcwd_priv_data *priv = dev_get_priv(dev);
+ struct arm_smccc_res local_res;
+
+ if (!res)
+ res = _res;
+
+ arm_smccc_smc(priv->smc_id, call, arg, 0, 0, 0, 0, 0, res);
+
+ if (res->a0 == PSCI_RET_NOT_SUPPORTED)
+ return -ENODEV;
+ if (res->a0 == PSCI_RET_INVALID_PARAMS)
+ return -EINVAL;
+ if (res->a0 != PSCI_RET_SUCCESS)
+ return -EIO;
+
+ return 0;
+}
+
+static int smcwd_reset(struct udevice *dev)
+{
+ return smcwd_call(dev, SMCWD_PET, 0, NULL);
+}
+
+static int smcwd_stop(struct udevice *dev)
+{
+ return smcwd_call(dev, SMCWD_ENABLE, 0, NULL);
+}
+
+static int smcwd_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+ struct smcwd_priv_data *priv = dev_get_priv(dev);
+ u64 timeout_sec = WDT_TIMEOUT_SECS(timeout_ms);
+ int err;
+
+ if (timeout_sec < priv->min_timeout || timeout_sec > priv->max_timeout)
{
+ dev_err(dev, "Timeout value not supported\n");
+ return -EINVAL;
+ }
+
+ err = smcwd_call(dev, SMCWD_SET_TIMEOUT, timeout_sec, NULL);
+ if (err) {
+ dev_err(dev, "Timeout out configuration failed\n");
+ return err;
+ }
+
+ return smcwd_call(dev, SMCWD_ENABLE, 1, NULL);
+}
+
+static int smcwd_probe(struct udevice *dev)
+{
+ struct smcwd_priv_data *priv = dev_get_priv(dev);
+ struct arm_smccc_res res;
+ int err;
+
+ priv->smc_id = dev_read_u32_default(dev, "arm,smc-id", 0x82003D06);
+
+ err = smcwd_call(dev, SMCWD_INIT, 0, );
+ if (err < 0) {
+ dev_err(dev, "Init failed %i\n", err);
+ return err;
+ }
+
+ priv->min_timeout = res.a1;
+ priv->max_timeout = res.a2;
+
+ return 0;
+}
+
+static const struct wdt_ops smcwd_ops = {
+ .start = smcwd_start,
+ .stop = smcwd_stop,
+ .reset = smcwd_reset,
+};
+
+static const struct
Re: [PATCH 1/3] dt-bindings: misc: esm: Add ESM support for TI K3 devices
On 14/04/2023 12:52, Neha Malcom Francis wrote:
> Document the binding for TI K3 ESM (Error Signaling Module) block.
>
> Signed-off-by: Neha Malcom Francis
> ---
> .../devicetree/bindings/misc/esm-k3.yaml | 54 +++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/esm-k3.yaml
>
> diff --git a/Documentation/devicetree/bindings/misc/esm-k3.yaml
> b/Documentation/devicetree/bindings/misc/esm-k3.yaml
> new file mode 100644
> index ..5e637add3b0e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/esm-k3.yaml
Filename matching compatible. Missing vendor prefix and device name.
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2022 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/misc/esm-k3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments K3 ESM Binding
Drop: Binding
> +
> +maintainers:
> + - Neha Malcom Francis
> +
> +description: |
> + The ESM (Error Signaling Module) is an IP block on TI K3 devices
> + that allows handling of safety events somewhat similar to what interrupt
> + controller would do. The safety signals have their separate paths within
> + the SoC, and they are handld by the ESM, which routes them to the proper
typo: handled
> + destination, which can be system reset, interrupt controller, etc. In the
> + simplest configuration the signals are just routed to reset the SoC.
There is no proper bindings directory for ESM? Misc is discouraged.
> +
> +properties:
> + compatible:
> +const: ti,j721e-esm
> +
> + reg:
> +items:
> + - description: physical address and length of the registers which
> + contain revision and debug features
Drop useless "physical address and length of the registers which". reg
cannot be anything else.
> + - description: physical address and length of the registers which
> + indicate strapping options
> +
> + ti,esm-pins:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description: |
Do not need '|' unless you need to preserve formatting.
> + integer array of ESM event IDs to route to external event pin which can
> + be used to reset the SoC. The array can have an arbitrary amount of
> event
> + IDs listed on it.
What is ESM event ID? The property name suggests pins...
> +minItems: 1
> +maxItems: 255
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - ti,esm-pins
> +
> +examples:
> + - |
> +main_esm: esm@70 {
Drop label.
> +compatible = "ti,j721e-esm";
> +reg = <0x0 0x70 0x0 0x1000>;
> +ti,esm-pins = <344>, <345>;
> +};
Best regards,
Krzysztof
Support for NXP S32K3 Family
Hi Folks, I am trying to build a u-boot boot-loader for my S32K344 board. Can you guys please help me, which defconf/config file is suitable for my S32K344 board for building a u-boot binaries? Regards Ashok
Re: [PATCH] mtd: cfi: respect reg address length
Hi Stefan,
On Fri, 2023-04-14 at 08:57 +0200, Stefan Roese wrote:
> Hi Nuno,
>
> On 3/27/23 15:22, Nuno Sá wrote:
> > flash_get_size() will get the flash size from the device itself and
> > go
> > through all erase regions to read protection status. However, the
> > device
> > mappable region (eg: devicetree reg property) might be lower than
> > the
> > device full size which means that the above cycle will result in a
> > data
> > bus exception. This change fixes it by reading the 'addr_size'
> > during
> > probe() and also use that as one possible upper limit.
> >
> > Signed-off-by: Nuno Sá
> > ---
> >
> > To give a bit more of background for this patch, I caught this
> > issue
> > when running u-boot on microblaze which uses xilinx
> > axi_linear_flash IP.
> > On ADI designs using that IP, the flash size was set to 32MiB
> > resulting
> > in the mentioned data bus exception as we obviously access past the
> > IP size.
> >
> > That said, there was not real reason for the flash truncation so
> > we'll
> > be fixing our designs so the IP will contemplate the complete flash
> > size.
> >
> > For the above reason, I was not really sure to mark the patch as
> > RFC or
> > not... Anyways, it still feels like a valid "protection" to have
> > rather
> > then just aborting (even if it does not really make sense to ever
> > truncate the flash in devicetree).
> >
> > drivers/mtd/cfi_flash.c | 10 --
> > include/flash.h | 1 +
> > 2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> > index f378f6fb6139..432d0d5c9ecb 100644
> > --- a/drivers/mtd/cfi_flash.c
> > +++ b/drivers/mtd/cfi_flash.c
> > @@ -2196,7 +2196,11 @@ ulong flash_get_size(phys_addr_t base, int
> > banknum)
> > /* multiply the size by the number of chips */
> > info->size *= size_ratio;
> > max_size = cfi_flash_bank_size(banknum);
> > - if (max_size && info->size > max_size) {
> > + if (max_size)
> > + max_size = min(info->addr_size, max_size);
> > + else
> > + max_size = info->addr_size;
> > + if (info->size > max_size) {
> > debug("[truncated from %ldMiB]", info->size
> > >> 20);
> > info->size = max_size;
> > }
> > @@ -2492,15 +2496,17 @@ unsigned long flash_init(void)
> > static int cfi_flash_probe(struct udevice *dev)
> > {
> > fdt_addr_t addr;
> > + fdt_size_t size;
> > int idx;
> >
> > for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
> > - addr = dev_read_addr_index(dev, idx);
> > + addr = dev_read_addr_size_index(dev, idx, );
> > if (addr == FDT_ADDR_T_NONE)
> > break;
> >
> > flash_info[cfi_flash_num_flash_banks].dev = dev;
> > flash_info[cfi_flash_num_flash_banks].base = addr;
> > + flash_info[cfi_flash_num_flash_banks].addr_size =
> > size;
> > cfi_flash_num_flash_banks++;
> > }
> > gd->bd->bi_flashstart = flash_info[0].base;
> > diff --git a/include/flash.h b/include/flash.h
> > index 95992fa689bb..3710a2731b76 100644
> > --- a/include/flash.h
> > +++ b/include/flash.h
> > @@ -46,6 +46,7 @@ typedef struct {
> > #ifdef CONFIG_CFI_FLASH /* DM-specific
> > parts */
> > struct udevice *dev;
> > phys_addr_t base;
> > + phys_size_t addr_size;
> > #endif
> > } flash_info_t;
> >
>
> Running a CI world build leads to many errors. Here an example:
>
> $ make integratorcp_cm926ejs_defconfig
> $ make -sj
> In file included from include/linux/bitops.h:22,
> from include/log.h:15,
> from include/linux/printk.h:4,
> from include/common.h:20,
> from drivers/mtd/cfi_flash.c:19:
> drivers/mtd/cfi_flash.c: In function 'flash_get_size':
> drivers/mtd/cfi_flash.c:2200:44: error: 'flash_info_t' has no member
> named 'addr_size'
> 2200 | max_size = min(info->addr_size,
> max_size);
> | ^~
> include/linux/kernel.h:182:16: note: in definition of macro 'min'
> 182 | typeof(x) _min1 = (x); \
> | ^
> drivers/mtd/cfi_flash.c:2200:44: error: 'flash_info_t' has no member
> named 'addr_size'
> 2200 | max_size = min(info->addr_size,
> max_size);
> | ^~
> include/linux/kernel.h:182:28: note: in definition of macro 'min'
> 182 | typeof(x) _min1 = (x); \
> | ^
> include/linux/kernel.h:184:24: warning: comparison of distinct
> pointer
> types lacks a cast
> 184 | (void) (&_min1 == &_min2);
Re: [PATCH v4 0/9] Add video damage tracking
Hi, this patch set applies cleanly on 2023.01 and solves the issue on the rockpro64 where the grub would take forever to draw on the screen. Thanks
[PATCH] arm: mach-k3: am62a7: Enable QoS for DSS
Enable Quality of Service (QoS) blocks for Display SubSystem (DSS), by
servicing the DSS - DDR traffic from the Real-Time (RT) queue. This is
done by setting the DSS DMA orderID to 8.
The C7x and VPAC have been overwhelming the DSS's access to the DDR
(when it was accessing via the Non Real-Time (NRT) Queue), primarily
because their functional frequencies, and hence DDR accesses, were
significantly higher than that of DSS. This led the display to flicker
when certain edgeAI models were being run.
With the DSS traffic serviced from the RT queue, the flickering issue
has been found to be mitigated.
The am62a qos files are auto generated from the k3 resource partitioning
tool.
Section-3.1.12, "QoS Programming Guide", in the AM62A TRM[1], provides
more information about the QoS, and section-14.1, "System Interconnect
Registers", provides the register descriptions.
[1] AM62A Tech Ref Manual: https://www.ti.com/lit/pdf/spruj16
Signed-off-by: Aradhya Bhatia
---
arch/arm/mach-k3/am62a7_init.c| 16 +++
arch/arm/mach-k3/am62ax/Makefile | 1 +
arch/arm/mach-k3/am62ax/am62a_qos_data.c | 47 +
arch/arm/mach-k3/include/mach/am62a_qos.h | 114 ++
arch/arm/mach-k3/include/mach/hardware.h | 9 ++
5 files changed, 187 insertions(+)
create mode 100644 arch/arm/mach-k3/am62ax/am62a_qos_data.c
create mode 100644 arch/arm/mach-k3/include/mach/am62a_qos.h
diff --git a/arch/arm/mach-k3/am62a7_init.c b/arch/arm/mach-k3/am62a7_init.c
index 02da24a3d6f0..2a827a31cf19 100644
--- a/arch/arm/mach-k3/am62a7_init.c
+++ b/arch/arm/mach-k3/am62a7_init.c
@@ -65,6 +65,20 @@ static void ctrl_mmr_unlock(void)
mmr_unlock(PADCFG_MMR1_BASE, 1);
}
+#if (IS_ENABLED(CONFIG_CPU_V7R))
+static void setup_qos(void)
+{
+ u32 i;
+
+ for (i = 0; i < am62a_qos_count; i++)
+ writel(am62a_qos_data[i].val, (uintptr_t)am62a_qos_data[i].reg);
+}
+#else
+static void setup_qos(void)
+{
+}
+#endif
+
void board_init_f(ulong dummy)
{
struct udevice *dev;
@@ -158,6 +172,8 @@ void board_init_f(ulong dummy)
panic("DRAM init failed: %d\n", ret);
#endif
+ setup_qos();
+
printf("am62a_init: %s done\n", __func__);
}
diff --git a/arch/arm/mach-k3/am62ax/Makefile b/arch/arm/mach-k3/am62ax/Makefile
index c58e52df1fa2..02a941805e9a 100644
--- a/arch/arm/mach-k3/am62ax/Makefile
+++ b/arch/arm/mach-k3/am62ax/Makefile
@@ -4,3 +4,4 @@
obj-y += clk-data.o
obj-y += dev-data.o
+obj-y += am62a_qos_data.o
diff --git a/arch/arm/mach-k3/am62ax/am62a_qos_data.c
b/arch/arm/mach-k3/am62ax/am62a_qos_data.c
new file mode 100644
index ..01b76f7493c3
--- /dev/null
+++ b/arch/arm/mach-k3/am62ax/am62a_qos_data.c
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * am62a Quality of Service (QoS) Configuration Data
+ * Auto generated from K3 Resource Partitioning tool
+ *
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+#include
+#include
+#include "common.h"
+
+struct k3_qos_data am62a_qos_data[] = {
+ /* modules_qosConfig0 - 1 endpoints, 4 channels */
+ {
+ .reg = K3_DSS_UL_MAIN_0_VBUSM_DMA + 0x100 + 0x4 * 0,
+ .val = ORDERID_8,
+ },
+ {
+ .reg = K3_DSS_UL_MAIN_0_VBUSM_DMA + 0x100 + 0x4 * 1,
+ .val = ORDERID_8,
+ },
+ {
+ .reg = K3_DSS_UL_MAIN_0_VBUSM_DMA + 0x100 + 0x4 * 2,
+ .val = ORDERID_8,
+ },
+ {
+ .reg = K3_DSS_UL_MAIN_0_VBUSM_DMA + 0x100 + 0x4 * 3,
+ .val = ORDERID_8,
+ },
+
+ /* Following registers set 1:1 mapping for orderID MAP1/MAP2
+* remap registers. orderID x is remapped to orderID x again
+* This is to ensure orderID from MAP register is unchanged
+*/
+
+ /* K3_DSS_UL_MAIN_0_VBUSM_DMA - 1 groups */
+ {
+ .reg = K3_DSS_UL_MAIN_0_VBUSM_DMA + 0,
+ .val = 0x76543210,
+ },
+ {
+ .reg = K3_DSS_UL_MAIN_0_VBUSM_DMA + 4,
+ .val = 0xfedcba98,
+ },
+};
+
+uint32_t am62a_qos_count = sizeof(am62a_qos_data) / sizeof(am62a_qos_data[0]);
diff --git a/arch/arm/mach-k3/include/mach/am62a_qos.h
b/arch/arm/mach-k3/include/mach/am62a_qos.h
new file mode 100644
index ..c74d69a28f8c
--- /dev/null
+++ b/arch/arm/mach-k3/include/mach/am62a_qos.h
@@ -0,0 +1,114 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Keystone3 Quality of service endpoint definitions
+ * Auto generated by K3 Resource Partitioning Tool
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#define QOS_0 (0 << 0)
+#define QOS_1 (1 << 0)
+#define QOS_2 (2 << 0)
+#define QOS_3 (3 << 0)
+#define QOS_4 (4 << 0)
+#define QOS_5 (5 << 0)
+#define QOS_6 (6 << 0)
+#define QOS_7 (7 << 0)
+
+#define ORDERID_0 (0 << 4)
+#define ORDERID_1 (1 << 4)
+#define ORDERID_2 (2 << 4)
+#define
Re: [PATCH v5 0/6] FWU: Add support for mtd backed feature on DeveloperBox
On 4/11/23 01:01, jaswinder.si...@linaro.org wrote: From: Jassi Brar Introduce support for mtd backed storage for FWU feature and enable it on Synquacer platform based DeveloperBox. This revision is rebased onto patchset that trims the FWU api https://lore.kernel.org/u-boot/20230306231747.1888513-1-jassisinghb...@gmail.com/ Changes since v4: * Provide default/weak implementations of fwu_plat_get_alt_num and fwu_plat_get_bootidx * Provide man page for mkfwumdata * Misc typo fixes and cosmetic changes Changes since v3: * Fix and Update documentation to also build optee for FWU FIP image. * Fixed checkpatch warnings * Made local functions static. * Split config changes to a separate patch * Fix authorship of three patches. Jassi Brar (4): dt: fwu: developerbox: enable fwu banks and mdata regions configs: move to new flash layout and boot flow fwu: DeveloperBox: add support for FWU fwu: provide default fwu_plat_get_bootidx Masami Hiramatsu (2): FWU: Add FWU metadata access driver for MTD storage regions tools: Add mkfwumdata tool for FWU metadata image .../synquacer-sc2a11-developerbox-u-boot.dtsi | 49 ++- board/socionext/developerbox/Makefile | 1 + board/socionext/developerbox/developerbox.c | 8 + board/socionext/developerbox/fwu_plat.c | 37 ++ configs/synquacer_developerbox_defconfig | 12 +- doc/board/socionext/developerbox.rst | 155 +++- doc/mkfwumdata.1 | 89 + drivers/fwu-mdata/Kconfig | 15 + drivers/fwu-mdata/Makefile| 1 + drivers/fwu-mdata/raw_mtd.c | 272 ++ include/configs/synquacer.h | 10 + include/fwu.h | 32 ++ lib/fwu_updates/Makefile | 1 + lib/fwu_updates/fwu.c | 18 + lib/fwu_updates/fwu_mtd.c | 185 ++ tools/Kconfig | 9 + tools/Makefile| 4 + tools/mkfwumdata.c| 334 ++ 18 files changed, 1221 insertions(+), 11 deletions(-) create mode 100644 board/socionext/developerbox/fwu_plat.c create mode 100644 doc/mkfwumdata.1 create mode 100644 drivers/fwu-mdata/raw_mtd.c create mode 100644 lib/fwu_updates/fwu_mtd.c create mode 100644 tools/mkfwumdata.c Jassi sent email to dt guys and I would wait for finding the right location for dt binding and get it review before this can be merged. I have commented some stuff in v4 which I would like to see in v6 especially to explain that uuid which is not used anywhere. Thanks, Michal
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
On 4/11/23 07:38, Krzysztof Kozlowski wrote:
On 11/04/2023 01:21, jaswinder.si...@linaro.org wrote:
From: Jassi Brar
Any requirement of FWU should not require changes to bindings
of other subsystems. For example, for mtd-backed storage we
can do without requiring 'fixed-partitions' children to also
carry 'uuid', a property which is non-standard and not in the
bindings.
There exists no code yet, so we can change the fwu-mtd bindings
to contain all properties within the fwu-mdata node.
Signed-off-by: Jassi Brar
---
Hi Rob, Hi Krzysztof,
I was suggested, and I agree, it would be a good idea to get your blessings
for the location and meta-data (fwu-mdata) bindings for the FWU.
The FWU images can be located in GPT partitions or MTD backed storage.
The basic bindings for fwu-mdata has already been merged in uboot (ideally they
too should have had your review). Now I am trying to fully support MTD backed
storage and hence looking for your review. The proposed bindings are totally
self-contained and don't require changes to any other subsystem.
Thanks.
I think we do not review U-Boot bindings usually, except these put in
the Linux kernel. There were few targeting U-Boot specifically (e.g.
Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and
Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want
our blessing, the bindings should be done in Linux kernel repo.
At least for us our goal is to have be able to share the same dt binding
document in U-Boot and Linux.
I am pretty sure that reviewing other project bindings would be too much
of work for me.
That's understandable. Pretty much it is more about to find a right location.
Simon added options node for u-boot directly to dt-schema
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml#L96
And if this is the same category it should maybe go directly to dt-schema
instead.
What about?
options {
fwu-mdata {
...
};
};
This thread is pretty much asking for suggesting where this can go to be able to
pass yaml checking which is required by SR.
Thanks,
Michal
Re: [PATCH v4 1/6] FWU: Add FWU metadata access driver for MTD storage regions
On 4/10/23 05:56, Jassi Brar wrote:
On Wed, 29 Mar 2023 at 07:00, Michal Simek wrote:
On 3/27/23 23:15, jassisinghb...@gmail.com wrote:
diff --git a/drivers/fwu-mdata/raw_mtd.c b/drivers/fwu-mdata/raw_mtd.c
new file mode 100644
index 00..4b1a10073a
--- /dev/null
+++ b/drivers/fwu-mdata/raw_mtd.c
@@ -0,0 +1,272 @@
+// SPDX-License-Identifier: GPL-2.0+
Just a note: Did you choose GPL-2.0+ by purpose? Or it is just c?
just c though isn't that the same as GPL-2.0-or-later ?
license choice is up to you. We normally use just gpl-2.0.
...
+
+extern struct fwu_mtd_image_info fwu_mtd_images[];
if there is a need to share it. It should go to header.
include/fwu,h would be the header. Which is supposed to be very
global, and doesn't seem very appropriate to mention private data
shared between a driver and helper library.
If people still insist, I will make the change.
And fwu_mtd_images[] is not defined when only this patch is applied.
It means order of patches is not right. 1/6 and 2/6 should be swapped
I think 1 and 2 should be merged rather.
no issue with it.
..
+ if (!mtd_priv->mtd) {
+ log_err("Failed to find mtd device by fwu-mdata-store\n");
+ return -ENODEV;
+ }
+
+ /* Get the offset of primary and seconday mdata */
typo
ok
..
+
+static const struct udevice_id fwu_mdata_ids[] = {
+ { .compatible = "u-boot,fwu-mdata-mtd" },
+ { }
+};
As I said this DT binding should be approved first to make sure that we don't
need to fix DT binding in future. Just simply do it right from the begining.
Yes, I will cc Rob in the next submission (I only forgot last time).
However, let us note that fwu-mdata-gpt.yaml isn't blessed either.
I am not sure if there is any reason for the fwu node to even be in
the dts for kernel. But sure it is good to have it eyeballed by the DT
gods.
It doesn't really go to kernel.
Simon pushed options node directly to dt-schema
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml#L96
And that would be also location for this node too.
Thanks,
Michal
Re: [PATCH v4 3/6] tools: Add mkfwumdata tool for FWU metadata image
On 4/10/23 06:05, Jassi Brar wrote: On Wed, 29 Mar 2023 at 07:29, Michal Simek wrote: On 3/27/23 23:16, jassisinghb...@gmail.com wrote: diff --git a/tools/mkfwumdata.c b/tools/mkfwumdata.c new file mode 100644 index 00..43dabf3b72 --- /dev/null +++ b/tools/mkfwumdata.c @@ -0,0 +1,334 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) 2023, Linaro Limited + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* This will dynamically allocate the fwu_mdata */ +#define CONFIG_FWU_NUM_BANKS 0 +#define CONFIG_FWU_NUM_IMAGES_PER_BANK 0 These two are completely unused. these are necessary for include/fwu_mdata.h that comes later. If that's come later, add it later. M
Re: [PATCH v4 3/6] tools: Add mkfwumdata tool for FWU metadata image
On 4/10/23 06:25, Jassi Brar wrote: On Wed, 29 Mar 2023 at 15:02, Simon Glass wrote: Hi, On Tue, 28 Mar 2023 at 10:16, wrote: From: Masami Hiramatsu Add 'mkfwumdata' tool to generate FWU metadata image for the meta-data partition to be used in A/B Update imeplementation. Signed-off-by: Masami Hiramatsu Signed-off-by: Sughosh Ganu Signed-off-by: Jassi Brar --- tools/Kconfig | 9 ++ tools/Makefile | 4 + tools/mkfwumdata.c | 334 + 3 files changed, 347 insertions(+) create mode 100644 tools/mkfwumdata.c Can you please look at putting this in binman instead, since we would rather not have another tool with no tests. Must I do that? I have no history with binman and it seems the mkfwumdata.c would need to be rewritten in python? I think it is about calling this utility from python not about rewriting it to python. M
Re: [PATCH v4 6/6] fwu: DeveloperBox: add support for FWU
On 4/10/23 06:21, Jassi Brar wrote:
On Wed, 29 Mar 2023 at 08:02, Michal Simek wrote:
On 3/27/23 23:16, jassisinghb...@gmail.com wrote:
.
+
+void fwu_plat_get_bootidx(uint *boot_idx)
+{
+ int ret;
+ u32 active_idx;
+ u32 *bootidx = boot_idx;
+
+ ret = fwu_get_active_index(_idx);
+
nit: remove this newline
ok
+ if (ret < 0)
+ *bootidx = -1;
+
+ *bootidx = active_idx;
Is this logic here right?
If fwu_get_active_index fails you setup bootidx to -1
and right after it you rewrite it to active_idx initialized in
fwu_get_active_index() to mdata->active_index.
It means why to do *bootidx = -1; at all?
yes :) it's a silly remnant of history of changes.
Actually this goes away after implementing the default/weak function.
+}
diff --git a/configs/synquacer_developerbox_defconfig
b/configs/synquacer_developerbox_defconfig
index 09e12b739b..d09684153a 100644
--- a/configs/synquacer_developerbox_defconfig
+++ b/configs/synquacer_developerbox_defconfig
@@ -97,3 +97,11 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_IGNORE_OSINDICATIONS=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
+CONFIG_EFI_SECURE_BOOT=y
+CONFIG_FWU_MULTI_BANK_UPDATE=y
+CONFIG_FWU_MDATA=y
+CONFIG_FWU_MDATA_MTD=y
+CONFIG_FWU_NUM_BANKS=2
+CONFIG_FWU_NUM_IMAGES_PER_BANK=1
+CONFIG_CMD_FWU_METADATA=y
+CONFIG_TOOLS_MKFWUMDATA=y
doesn't look like that it was created via savedefconfig.
Yes. I had some other config changes too and picked only the relevant
ones together.
But this is defconfig not documentation.
+And make a FIP image.::
+
+ cp build/synquacer/release/fip.bin SPI_NOR_NEWFIP.fd
+ tools/fiptool/fiptool update --tb-fw build/synquacer/release/bl2.bin
SPI_NOR_NEWFIP.fd
+
+UUIDs for the FWU Multi Bank Update
+---
+
+FWU multi-bank update requires some UUIDs. The DeveloperBox platform uses
+following UUIDs.
+
+ - Location UUID for the FIP image: 17e86d77-41f9-4fd7-87ec-a55df9842de5
In past you have it listed at flash node in DT. I see you have removed it
between v3 and v4 without any note about it.
Is it still needed? And should it be listed in DT spec again?
After the dt change, we no longer require this. But the location_uuid
is a standard member of an fwu_image_entry and cmd/fwu_mdata.c always
print it. So I think this should be seen as just what a platform wants
some unique id to be printed for the image (?).
I am fine with your explanation but documentation should make this clear that
uuid is required by spec but not actually used by current implementation or
description.
M
Re: [PATCH 2/2] reset: rockchip: implement rk3588 lookup table
Hi Kever,
On Fri, Apr 14, 2023 at 12:03:00PM +0300, Eugen Hristev wrote:
> On 4/14/23 10:02, Kever Yang wrote:
> > On 2023/4/13 19:36, Eugen Hristev wrote:
> > > The current DT bindings for the rk3588 clock use a different ID than the
> > > one that is supposed to be written to the hardware registers.
> > > Thus, we cannot use directly the id provided in the phandle, but rather
> > > use a lookup table to correctly setup the hardware.
> > >
> > > This approach has been implemented already in Linux, by commit :
> > > f1c506d152ff ("clk: rockchip: add clock controller for the RK3588")
> > >
> > > Hence, implement a similar approach using the lookup table, and adapt
> > > the existing reset driver to work with SoCs using lookup table.
> > > The file rst-rk3588.c has been copied as much as possible from Linux.
> >
> > I didn't follow the kernel closely, I'm not sure if there have any
> > discussion on this,
> >
> > but I think we can reuse the generic reset driver
> > "drivers/reset/reset-rockchip.c"
> >
> > as we have done for all other SoCs, but not add a new file for rk3588
> > and more for
> >
> > other SoCs. What we need to do is update the ID with encode version in
> > the header
> >
> > file like rockchip vendorkernel/U-Boot.
>
> This would not work, because in vendor U-boot we have different numbers for
> the same defines.
>
> E.g.:
>
> Vendor U-boot:
> #define SRST_PCIE4_POWER_UP 529
>
> While in upstream Linux/Uboot:
> #define SRST_PCIE4_POWER_UP 298
>
> So to be able to keep this file in sync with Linux :
> https://elixir.bootlin.com/u-boot/latest/source/include/dt-bindings/clock/rockchip,rk3588-cru.h
>
> ... we need to have a translation table. We cannot update the id
> in the header above. This would break the ABI and compatibility
> with Linux.
You can follow the discussion that lead to the difference between
upstream and vendor reset handling in this thread:
https://lore.kernel.org/all/97bb42c0-725f-3611-ff3f-0c7344aa0...@linaro.org/
-- Sebastian
signature.asc
Description: PGP signature
Re: [PATCH V2 2/2] net: phy: Make phy_interface_is_rgmii a switch statement
On 4/14/23 06:24, Nishanth Menon wrote:
Recent commit 75d28899e3e9 ("net: phy: Synchronize PHY interface modes
with Linux") reordered the enum definitions. This exposed a problem in
range checking functions to identify the interface type. Though this
specific api was'nt impacted (all the RGMII definitions remained within
Nit: "wasn't" , apostrophe in the wrong place .
range), this experience should be used to never to have to face this
kind of challenge again.
While it is possible for the phy drivers to practically use the enum's
directly, drivers such as dp83867, dp83869, marvell, micrel_ksz90x1 etc
use the same.
Reported-by: Tom Rini
Signed-off-by: Nishanth Menon
Reviewed-by: Marek Vasut
Re: [PATCH V2 1/2] net: phy: Make phy_interface_is_sgmii a switch statement
On 4/14/23 06:24, Nishanth Menon wrote:
Recent commit 75d28899e3e9 ("net: phy: Synchronize PHY interface modes
with Linux") reordered the enum definitions. This caused the range of
enums that this api was checking to go bad.
While it is possible for the phy drivers to practically use the enum's
directly, drivers such as dp83867 use this helper to manage the
configuration of the phy correctly.
Reported-by: Tom Rini
Signed-off-by: Nishanth Menon
Reviewed-by: Marek Vasut
It would be nice if you could do a follow-up patch as suggested by Marek
Behun and inline this function into the TI PHY driver instead.
[PATCH] include: configs: j721e_evm: Fix name_fdt for J7200
Currently, name_fdt is not set for J7200, fix this so right DTB is
picked during boot.
Signed-off-by: Neha Malcom Francis
---
board/ti/j721e/j721e.env | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index 446395adfa..222b5b12dd 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -12,6 +12,8 @@ findfdt=
setenv name_fdt ${default_device_tree};
if test $board_name = j721e; then
setenv name_fdt k3-j721e-common-proc-board.dtb; fi;
+ if test $board_name = j7200; then
+ setenv name_fdt k3-j7200-common-proc-board.dtb; fi;
if test $board_name = j721e-eaik || test $board_name = j721e-sk; then
setenv name_fdt k3-j721e-sk.dtb; fi;
setenv fdtfile ${name_fdt}
--
2.34.1
Re: [PATCH 0/3] Add support for ESM
Please ignore following patches, send by mistake. Sorry for the spam! On 14/04/23 16:22, Neha Malcom Francis wrote: ESM (Error Signaling Module) is a fundamental IP responsible for handling safety events. The driver currently present in U-Boot is responsible for configuring ESM. This patch series adds dt-binding and nodes for J721E and J7200. This goes towards end goal of having DTB sync with that of U-Boot as well as ensuring completeness of hardware description in devicetree. Neha Malcom Francis (3): dt-bindings: misc: esm: Add ESM support for TI K3 devices arm64: dts: ti: k3-j721e: Add ESM support arm64: dts: ti: k3-j7200: Add ESM support .../devicetree/bindings/misc/esm-k3.yaml | 54 +++ arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 6 +++ arch/arm64/boot/dts/ti/k3-j7200.dtsi | 1 + arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 + 4 files changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/esm-k3.yaml -- Thanking You Neha Malcom Francis
Re: [PATCH 2/2] sunxi: binman: Fix U-Boot offset when SPL is not 32 KiB
On Sat, 21 Jan 2023 17:25:17 -0600
Samuel Holland wrote:
Hi Samuel,
> On sunxi boards, SPL looks for U-Boot at a 32 KiB offset, unless SPL is
> larger than 32 KiB, in which case U-Boot immediately follows SPL. See
> the logic in spl_mmc_get_uboot_raw_sector() and spl_spi_load_image().
>
> In two cases, the existing binman description mismatches the SPL code.
> For 64-bit boards, binman would place U-Boot immediately following SPL,
> even if SPL is smaller than 32 KiB. This can happen when SPL MMC support
> is disabled (i.e. when booting from SPI flash).
>
> In contrast, for 32-bit boards, binman would place U-Boot at 32 KiB,
> even if SPL is larger than that. This happens because the 'offset'
> property does not consider the size of previous entries.
>
> Fix both issues by setting a minimum size for the SPL entry, which
> exactly matches the logic in the SPL code. Unfortunately, this size must
> be provided as a magic number, since none of the relevant config symbols
> (SPL_PAD_TO, SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, and SYS_SPI_U_BOOT_OFFS)
> are guaranteed to be defined in all cases.
>
> Fixes: cfa3db602caf ("sunxi: Convert 64-bit boards to use binman")
> Signed-off-by: Samuel Holland
thanks for this patch. Indeed a 24K arm64 SPL would break the image, and
this patch fixes it. The exact inner workings of binman are beyond me, but
I build tested various key platforms and it seems to work now.
Maybe that would also fix the build problem I saw with the 32-bit FIT
series.
Reviewed-by: Andre Przywara
Queued for sunxi/master.
Cheers,
Andre
> ---
>
> arch/arm/dts/sunxi-u-boot.dtsi | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> index 2028d5b6a9..8a6c9e901a 100644
> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> @@ -31,6 +31,11 @@
> pad-byte = <0xff>;
>
> blob {
> + /*
> + * This value matches SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> + * and SYS_SPI_U_BOOT_OFFS if those are defined.
> + */
> + min-size = <0x8000>;
> filename = "spl/sunxi-spl.bin";
> };
>
> @@ -107,7 +112,6 @@
> };
> #else
> u-boot-img {
> - offset = ;
> };
> #endif
> };
[PATCH 3/3] arm64: dts: ti: k3-j7200: Add ESM support
Add address entry mapping ESM on J7200.
Signed-off-by: Neha Malcom Francis
---
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 6 ++
arch/arm64/boot/dts/ti/k3-j7200.dtsi | 1 +
2 files changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
index ef352e32f19d..89f816f5e53d 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -1010,4 +1010,10 @@ main_r5fss0_core1: r5f@5d0 {
ti,loczrama = <1>;
};
};
+
+ main_esm: esm@70 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x70 0x0 0x1000>;
+ ti,esm-pins = <656>, <657>;
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
index bbe380c72a7e..4998eb4fbe75 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
@@ -128,6 +128,7 @@ cbass_main: bus@10 {
#size-cells = <2>;
ranges = <0x00 0x0010 0x00 0x0010 0x00 0x0002>, /*
ctrl mmr */
<0x00 0x0060 0x00 0x0060 0x00 0x00031100>, /*
GPIO */
+<0x00 0x0070 0x00 0x0070 0x00 0x1000>, /*
ESM */
<0x00 0x00a4 0x00 0x00a4 0x00 0x0800>, /*
timesync router */
<0x00 0x0100 0x00 0x0100 0x00 0x0d00>, /*
Most peripherals */
<0x00 0x3000 0x00 0x3000 0x00 0x0c40>, /*
MAIN NAVSS */
--
2.34.1
[PATCH 0/3] Add support for ESM
ESM (Error Signaling Module) is a fundamental IP responsible for handling safety events. The driver currently present in U-Boot is responsible for configuring ESM. This patch series adds dt-binding and nodes for J721E and J7200. This goes towards end goal of having DTB sync with that of U-Boot as well as ensuring completeness of hardware description in devicetree. Neha Malcom Francis (3): dt-bindings: misc: esm: Add ESM support for TI K3 devices arm64: dts: ti: k3-j721e: Add ESM support arm64: dts: ti: k3-j7200: Add ESM support .../devicetree/bindings/misc/esm-k3.yaml | 54 +++ arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 6 +++ arch/arm64/boot/dts/ti/k3-j7200.dtsi | 1 + arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 + 4 files changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/esm-k3.yaml -- 2.34.1
[PATCH 2/3] arm64: dts: ti: k3-j721e: Add ESM support
Add address entry mapping ESM on J721E.
Signed-off-by: Neha Malcom Francis
---
arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e.dtsi
b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
index b912143b6a11..52bcde601eb8 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
@@ -131,6 +131,7 @@ cbass_main: bus@10 {
#size-cells = <2>;
ranges = <0x00 0x0010 0x00 0x0010 0x00 0x0002>, /*
ctrl mmr */
<0x00 0x0060 0x00 0x0060 0x00 0x00031100>, /*
GPIO */
+<0x00 0x0070 0x00 0x0070 0x00 0x1000>, /*
ESM */
<0x00 0x0090 0x00 0x0090 0x00 0x00012000>, /*
serdes */
<0x00 0x00a4 0x00 0x00a4 0x00 0x0800>, /*
timesync router */
<0x00 0x0600 0x00 0x0600 0x00 0x0040>, /*
USBSS0 */
--
2.34.1
[PATCH 1/3] dt-bindings: misc: esm: Add ESM support for TI K3 devices
Document the binding for TI K3 ESM (Error Signaling Module) block.
Signed-off-by: Neha Malcom Francis
---
.../devicetree/bindings/misc/esm-k3.yaml | 54 +++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/esm-k3.yaml
diff --git a/Documentation/devicetree/bindings/misc/esm-k3.yaml
b/Documentation/devicetree/bindings/misc/esm-k3.yaml
new file mode 100644
index ..5e637add3b0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/esm-k3.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/esm-k3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 ESM Binding
+
+maintainers:
+ - Neha Malcom Francis
+
+description: |
+ The ESM (Error Signaling Module) is an IP block on TI K3 devices
+ that allows handling of safety events somewhat similar to what interrupt
+ controller would do. The safety signals have their separate paths within
+ the SoC, and they are handld by the ESM, which routes them to the proper
+ destination, which can be system reset, interrupt controller, etc. In the
+ simplest configuration the signals are just routed to reset the SoC.
+
+properties:
+ compatible:
+const: ti,j721e-esm
+
+ reg:
+items:
+ - description: physical address and length of the registers which
+ contain revision and debug features
+ - description: physical address and length of the registers which
+ indicate strapping options
+
+ ti,esm-pins:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+ integer array of ESM event IDs to route to external event pin which can
+ be used to reset the SoC. The array can have an arbitrary amount of event
+ IDs listed on it.
+minItems: 1
+maxItems: 255
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - ti,esm-pins
+
+examples:
+ - |
+main_esm: esm@70 {
+compatible = "ti,j721e-esm";
+reg = <0x0 0x70 0x0 0x1000>;
+ti,esm-pins = <344>, <345>;
+};
--
2.34.1
Re: [PATCH u-boot 3/4] sunxi: eMMC: Add comments explaining mapping between bootpart and mmc_switch_part()
On Thu, 13 Apr 2023 23:10:56 +0200 Pali Rohár wrote: > Mapping between bootpart taken from EXT_CSD_EXTRACT_BOOT_PART() and > Partition Access bits used by the mmc_switch_part() function may be quite > misleading. So add extended comment describing why in sunxi case is this > mapping just a simple identity. Because in generic case this mapping > requires non-trivial mapping table. Ah, indeed, many thanks for clearing this up! I missed the subtleties of bootpart meaning slightly different things between EXT_CSD_EXTRACT_BOOT_PART and mmc_switch_part(). It looks like we were quite lucky as we only care about 1 and 2 here! > Signed-off-by: Pali Rohár Acked-by: Andre Przywara Queued for sunxi/master. Cheers, Andre > --- > arch/arm/mach-sunxi/board.c | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c > index 391a65a5495f..73519f6262ec 100644 > --- a/arch/arm/mach-sunxi/board.c > +++ b/arch/arm/mach-sunxi/board.c > @@ -381,7 +381,17 @@ static bool sunxi_valid_emmc_boot(struct mmc *mmc) > (mmc->ext_csd[EXT_CSD_BOOT_BUS_WIDTH] & 0x1b) != 0x09) > return false; > > - /* Partition 0 is the user data partition, bootpart must be 1 or 2. */ > + /* > + * bootpart == 0 means that eMMC booting is disabled. > + * bootpart == 1 or 2 means to boot from Boot Partition 1 or 2. > + * bootpart == 7 means to boot from User Area. > + * Other bootpart values are reserved. > + * mmc_switch_part() takes partition access value which is: > + * 0 for User Area; 1-2 for Boot Partition 1-2; 3 for RPMB; 4-7 for GP > 1-4. > + * We allow booting only from Boot Partition 1 or 2 so > + * bootpart mapping between EXT_CSD_EXTRACT_BOOT_PART() > + * and mmc_switch_part() is straightforward identity. > + */ > if (bootpart != 1 && bootpart != 2) > return false; >
Re: [PATCH v2 6/6] mtd: nand: sunxi: Pass the device to the init function
On Fri, Apr 14, 2023 at 12:23 PM Andre Przywara wrote:
>
> On Sun, 22 Jan 2023 16:06:36 -0600
> Samuel Holland wrote:
>
> > This more closely matches the U-Boot driver to the Linux version.
> >
> > Signed-off-by: Samuel Holland
>
> Reviewed-by: Andre Przywara
>
> Thanks!
> Andre
>
> > ---
> >
> > (no changes since v1)
> >
> > drivers/mtd/nand/raw/sunxi_nand.c | 39 ---
> > 1 file changed, 20 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/sunxi_nand.c
> > b/drivers/mtd/nand/raw/sunxi_nand.c
> > index dda51a39b0..c0fa1e310c 100644
> > --- a/drivers/mtd/nand/raw/sunxi_nand.c
> > +++ b/drivers/mtd/nand/raw/sunxi_nand.c
> > @@ -1604,7 +1604,8 @@ static int sunxi_nand_ecc_init(struct mtd_info *mtd,
> > struct nand_ecc_ctrl *ecc)
> > return 0;
> > }
> >
> > -static int sunxi_nand_chip_init(ofnode np, struct sunxi_nfc *nfc, int
> > devnum)
> > +static int sunxi_nand_chip_init(struct udevice *dev, struct sunxi_nfc *nfc,
> > + ofnode np, int devnum)
> > {
> > const struct nand_sdr_timings *timings;
> > struct sunxi_nand_chip *chip;
> > @@ -1620,7 +1621,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> >
> > nsels /= sizeof(u32);
> > if (!nsels || nsels > 8) {
> > - dev_err(nfc->dev, "invalid reg property size\n");
> > + dev_err(dev, "invalid reg property size\n");
> > return -EINVAL;
> > }
> >
> > @@ -1628,7 +1629,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> > (nsels * sizeof(struct sunxi_nand_chip_sel)),
> > GFP_KERNEL);
> > if (!chip) {
> > - dev_err(nfc->dev, "could not allocate chip\n");
> > + dev_err(dev, "could not allocate chip\n");
> > return -ENOMEM;
> > }
> >
> > @@ -1638,19 +1639,19 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> > for (i = 0; i < nsels; i++) {
> > ret = ofnode_read_u32_index(np, "reg", i, );
> > if (ret) {
> > - dev_err(nfc->dev, "could not retrieve reg property:
> > %d\n",
> > + dev_err(dev, "could not retrieve reg property: %d\n",
> > ret);
> > return ret;
> > }
> >
> > if (tmp > NFC_MAX_CS) {
> > - dev_err(nfc->dev,
> > + dev_err(dev,
> > "invalid reg value: %u (max CS = 7)\n", tmp);
> > return -EINVAL;
> > }
> >
> > if (test_and_set_bit(tmp, >assigned_cs)) {
> > - dev_err(nfc->dev, "CS %d already assigned\n", tmp);
> > + dev_err(dev, "CS %d already assigned\n", tmp);
> > return -EINVAL;
> > }
> >
> > @@ -1661,9 +1662,9 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> > chip->sels[i].rb.type = RB_NATIVE;
> > chip->sels[i].rb.info.nativeid = tmp;
> > } else {
> > - ret = gpio_request_by_name_nodev(np, "rb-gpios", i,
> > -
> > >sels[i].rb.info.gpio,
> > - GPIOD_IS_IN);
> > + ret = gpio_request_by_name(dev, "rb-gpios", i,
> > +
> > >sels[i].rb.info.gpio,
> > +GPIOD_IS_IN);
> > if (ret)
> > chip->sels[i].rb.type = RB_GPIO;
> > else
> > @@ -1674,7 +1675,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> > timings = onfi_async_timing_mode_to_sdr_timings(0);
> > if (IS_ERR(timings)) {
> > ret = PTR_ERR(timings);
> > - dev_err(nfc->dev,
> > + dev_err(dev,
> > "could not retrieve timings for ONFI mode 0: %d\n",
> > ret);
> > return ret;
> > @@ -1682,7 +1683,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> >
> > ret = sunxi_nand_chip_set_timings(nfc, chip, timings);
> > if (ret) {
> > - dev_err(nfc->dev, "could not configure chip timings: %d\n",
> > ret);
> > + dev_err(dev, "could not configure chip timings: %d\n", ret);
> > return ret;
> > }
> >
> > @@ -1717,25 +1718,25 @@ static int sunxi_nand_chip_init(ofnode np, struct
> > sunxi_nfc *nfc, int devnum)
> >
> > ret = sunxi_nand_chip_init_timings(nfc, chip);
> > if (ret) {
> > - dev_err(nfc->dev, "could not configure chip timings: %d\n",
> > ret);
> >
Re: [PATCH v2 0/6] mtd: nand: sunxi: Convert to devicetree and the driver model
On Sun, 22 Jan 2023 16:06:30 -0600 Samuel Holland wrote: Hi, > This series converts the sunxi NAND driver to get its resources (clocks, > resets, pins) from the devicetree, and probe using the driver model. > > In addition to the immediate cleanup, this allows backporting more > patches (bugfixes, newer SoC support) from the Linux driver. so I cannot test this, and raw NAND support seems dodgy at best in general, but in the interest of getting the non-DM legacy out of our drivers, I will take it. Not sure if any actual (mainline) users are out there, I guess we will see ;-) Queued for sunxi/master. Cheers, Andre > Changes in v2: > - Fix A80 bus clock/reset bit positions > > Samuel Holland (6): > clk: sunxi: Add NAND clocks and resets > pinctrl: sunxi: Add NAND pinmuxes > mtd: nand: sunxi: Remove an unnecessary check > mtd: nand: sunxi: Convert from fdtdec to ofnode > mtd: nand: sunxi: Convert to the driver model > mtd: nand: sunxi: Pass the device to the init function > > board/sunxi/board.c | 5 +- > drivers/clk/sunxi/clk_a10.c | 2 + > drivers/clk/sunxi/clk_a10s.c | 2 + > drivers/clk/sunxi/clk_a23.c | 3 + > drivers/clk/sunxi/clk_a31.c | 6 + > drivers/clk/sunxi/clk_a64.c | 3 + > drivers/clk/sunxi/clk_a80.c | 8 ++ > drivers/clk/sunxi/clk_a83t.c | 3 + > drivers/clk/sunxi/clk_h3.c| 3 + > drivers/clk/sunxi/clk_h6.c| 6 + > drivers/clk/sunxi/clk_h616.c | 6 + > drivers/clk/sunxi/clk_r40.c | 3 + > drivers/mtd/nand/raw/sunxi_nand.c | 173 -- > drivers/pinctrl/sunxi/pinctrl-sunxi.c | 13 ++ > include/fdtdec.h | 1 - > lib/fdtdec.c | 1 - > 16 files changed, 138 insertions(+), 100 deletions(-) >
Re: [PATCH v2 6/6] mtd: nand: sunxi: Pass the device to the init function
On Sun, 22 Jan 2023 16:06:36 -0600
Samuel Holland wrote:
> This more closely matches the U-Boot driver to the Linux version.
>
> Signed-off-by: Samuel Holland
Reviewed-by: Andre Przywara
Thanks!
Andre
> ---
>
> (no changes since v1)
>
> drivers/mtd/nand/raw/sunxi_nand.c | 39 ---
> 1 file changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/sunxi_nand.c
> b/drivers/mtd/nand/raw/sunxi_nand.c
> index dda51a39b0..c0fa1e310c 100644
> --- a/drivers/mtd/nand/raw/sunxi_nand.c
> +++ b/drivers/mtd/nand/raw/sunxi_nand.c
> @@ -1604,7 +1604,8 @@ static int sunxi_nand_ecc_init(struct mtd_info *mtd,
> struct nand_ecc_ctrl *ecc)
> return 0;
> }
>
> -static int sunxi_nand_chip_init(ofnode np, struct sunxi_nfc *nfc, int devnum)
> +static int sunxi_nand_chip_init(struct udevice *dev, struct sunxi_nfc *nfc,
> + ofnode np, int devnum)
> {
> const struct nand_sdr_timings *timings;
> struct sunxi_nand_chip *chip;
> @@ -1620,7 +1621,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> sunxi_nfc *nfc, int devnum)
>
> nsels /= sizeof(u32);
> if (!nsels || nsels > 8) {
> - dev_err(nfc->dev, "invalid reg property size\n");
> + dev_err(dev, "invalid reg property size\n");
> return -EINVAL;
> }
>
> @@ -1628,7 +1629,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> sunxi_nfc *nfc, int devnum)
> (nsels * sizeof(struct sunxi_nand_chip_sel)),
> GFP_KERNEL);
> if (!chip) {
> - dev_err(nfc->dev, "could not allocate chip\n");
> + dev_err(dev, "could not allocate chip\n");
> return -ENOMEM;
> }
>
> @@ -1638,19 +1639,19 @@ static int sunxi_nand_chip_init(ofnode np, struct
> sunxi_nfc *nfc, int devnum)
> for (i = 0; i < nsels; i++) {
> ret = ofnode_read_u32_index(np, "reg", i, );
> if (ret) {
> - dev_err(nfc->dev, "could not retrieve reg property:
> %d\n",
> + dev_err(dev, "could not retrieve reg property: %d\n",
> ret);
> return ret;
> }
>
> if (tmp > NFC_MAX_CS) {
> - dev_err(nfc->dev,
> + dev_err(dev,
> "invalid reg value: %u (max CS = 7)\n", tmp);
> return -EINVAL;
> }
>
> if (test_and_set_bit(tmp, >assigned_cs)) {
> - dev_err(nfc->dev, "CS %d already assigned\n", tmp);
> + dev_err(dev, "CS %d already assigned\n", tmp);
> return -EINVAL;
> }
>
> @@ -1661,9 +1662,9 @@ static int sunxi_nand_chip_init(ofnode np, struct
> sunxi_nfc *nfc, int devnum)
> chip->sels[i].rb.type = RB_NATIVE;
> chip->sels[i].rb.info.nativeid = tmp;
> } else {
> - ret = gpio_request_by_name_nodev(np, "rb-gpios", i,
> -
> >sels[i].rb.info.gpio,
> - GPIOD_IS_IN);
> + ret = gpio_request_by_name(dev, "rb-gpios", i,
> +>sels[i].rb.info.gpio,
> +GPIOD_IS_IN);
> if (ret)
> chip->sels[i].rb.type = RB_GPIO;
> else
> @@ -1674,7 +1675,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> sunxi_nfc *nfc, int devnum)
> timings = onfi_async_timing_mode_to_sdr_timings(0);
> if (IS_ERR(timings)) {
> ret = PTR_ERR(timings);
> - dev_err(nfc->dev,
> + dev_err(dev,
> "could not retrieve timings for ONFI mode 0: %d\n",
> ret);
> return ret;
> @@ -1682,7 +1683,7 @@ static int sunxi_nand_chip_init(ofnode np, struct
> sunxi_nfc *nfc, int devnum)
>
> ret = sunxi_nand_chip_set_timings(nfc, chip, timings);
> if (ret) {
> - dev_err(nfc->dev, "could not configure chip timings: %d\n",
> ret);
> + dev_err(dev, "could not configure chip timings: %d\n", ret);
> return ret;
> }
>
> @@ -1717,25 +1718,25 @@ static int sunxi_nand_chip_init(ofnode np, struct
> sunxi_nfc *nfc, int devnum)
>
> ret = sunxi_nand_chip_init_timings(nfc, chip);
> if (ret) {
> - dev_err(nfc->dev, "could not configure chip timings: %d\n",
> ret);
> + dev_err(dev, "could not configure chip timings: %d\n", ret);
> return ret;
> }
>
> ret = sunxi_nand_ecc_init(mtd, >ecc);
> if (ret) {
> - dev_err(nfc->dev, "ECC init failed: %d\n", ret);
> + dev_err(dev, "ECC init
Re: [PATCH v2 4/6] mtd: nand: sunxi: Convert from fdtdec to ofnode
On Sun, 22 Jan 2023 16:06:34 -0600
Samuel Holland wrote:
Hi,
> As a first step toward converting this driver to the driver model, use
> the ofnode abstraction to replace direct references to the FDT blob.
>
> Using ofnode_read_u32_index removes an extra pair of loops and makes the
> allwinner,rb property optional, matching the devicetree binding.
So certainly the old code looks somewhat wrong, if I refer to the binding.
I am still not 100% sure this works for all cases, but the Linux driver
does the same thing, and the DTs seem to have one cell only anyway,
and the "fdtdec to ofnode" part looks fine, so in the interest of getting
this converted over to DM:
Acked-by: Andre Przywara
Cheers,
Andre
> Signed-off-by: Samuel Holland
> ---
>
> (no changes since v1)
>
> drivers/mtd/nand/raw/sunxi_nand.c | 73 +++
> include/fdtdec.h | 1 -
> lib/fdtdec.c | 1 -
> 3 files changed, 26 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/sunxi_nand.c
> b/drivers/mtd/nand/raw/sunxi_nand.c
> index 0f10edfdb2..7185efbebf 100644
> --- a/drivers/mtd/nand/raw/sunxi_nand.c
> +++ b/drivers/mtd/nand/raw/sunxi_nand.c
> @@ -25,11 +25,10 @@
> */
>
> #include
> -#include
> +#include
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -45,8 +44,6 @@
> #include
> #include
>
> -DECLARE_GLOBAL_DATA_PTR;
> -
> #define NFC_REG_CTL 0x
> #define NFC_REG_ST 0x0004
> #define NFC_REG_INT 0x0008
> @@ -1605,19 +1602,18 @@ static int sunxi_nand_ecc_init(struct mtd_info *mtd,
> struct nand_ecc_ctrl *ecc)
> return 0;
> }
>
> -static int sunxi_nand_chip_init(int node, struct sunxi_nfc *nfc, int devnum)
> +static int sunxi_nand_chip_init(ofnode np, struct sunxi_nfc *nfc, int devnum)
> {
> const struct nand_sdr_timings *timings;
> - const void *blob = gd->fdt_blob;
> struct sunxi_nand_chip *chip;
> struct mtd_info *mtd;
> struct nand_chip *nand;
> int nsels;
> int ret;
> int i;
> - u32 cs[8], rb[8];
> + u32 tmp;
>
> - if (!fdt_getprop(blob, node, "reg", ))
> + if (!ofnode_get_property(np, "reg", ))
> return -EINVAL;
>
> nsels /= sizeof(u32);
> @@ -1638,25 +1634,12 @@ static int sunxi_nand_chip_init(int node, struct
> sunxi_nfc *nfc, int devnum)
> chip->selected = -1;
>
> for (i = 0; i < nsels; i++) {
> - cs[i] = -1;
> - rb[i] = -1;
> - }
> -
> - ret = fdtdec_get_int_array(gd->fdt_blob, node, "reg", cs, nsels);
> - if (ret) {
> - dev_err(nfc->dev, "could not retrieve reg property: %d\n", ret);
> - return ret;
> - }
> -
> - ret = fdtdec_get_int_array(gd->fdt_blob, node, "allwinner,rb", rb,
> -nsels);
> - if (ret) {
> - dev_err(nfc->dev, "could not retrieve reg property: %d\n", ret);
> - return ret;
> - }
> -
> - for (i = 0; i < nsels; i++) {
> - int tmp = cs[i];
> + ret = ofnode_read_u32_index(np, "reg", i, );
> + if (ret) {
> + dev_err(nfc->dev, "could not retrieve reg property:
> %d\n",
> + ret);
> + return ret;
> + }
>
> if (tmp > NFC_MAX_CS) {
> dev_err(nfc->dev,
> @@ -1671,15 +1654,14 @@ static int sunxi_nand_chip_init(int node, struct
> sunxi_nfc *nfc, int devnum)
>
> chip->sels[i].cs = tmp;
>
> - tmp = rb[i];
> - if (tmp >= 0 && tmp < 2) {
> + if (!ofnode_read_u32_index(np, "allwinner,rb", i, ) &&
> + tmp < 2) {
> chip->sels[i].rb.type = RB_NATIVE;
> chip->sels[i].rb.info.nativeid = tmp;
> } else {
> - ret = gpio_request_by_name_nodev(offset_to_ofnode(node),
> - "rb-gpios", i,
> - >sels[i].rb.info.gpio,
> - GPIOD_IS_IN);
> + ret = gpio_request_by_name_nodev(np, "rb-gpios", i,
> +
> >sels[i].rb.info.gpio,
> + GPIOD_IS_IN);
> if (ret)
> chip->sels[i].rb.type = RB_GPIO;
> else
> @@ -1711,7 +1693,7 @@ static int sunxi_nand_chip_init(int node, struct
> sunxi_nfc *nfc, int devnum)
>* in the DT.
>*/
> nand->ecc.mode = NAND_ECC_HW;
> - nand->flash_node = offset_to_ofnode(node);
> + nand->flash_node = np;
> nand->select_chip = sunxi_nfc_select_chip;
> nand->cmd_ctrl = sunxi_nfc_cmd_ctrl;
> nand->read_buf = sunxi_nfc_read_buf;
> @@ -1760,15 +1742,13
Re: [PATCH v2 1/2] ARM: dts: rk3588-rock-5b-u-boot: add u-boot, dm-spl to pinctrl for sdmmc
On 4/14/23 11:55, Kever Yang wrote:
On 2023/3/18 00:29, Eugen Hristev wrote:
To be able to initialize the pinctrl correctly at SPL level and read
u-boot proper from SD-Card, the pinctrl must be initialized.
Signed-off-by: Eugen Hristev
Reviewed-by: Kever Yang
Hi Kever,
The properties must be changed to bootph, I will update and send a new
version.
Eugen
Thanks,
- Kever
---
Changes in v2:
- add u-boot,dm-spl to pull up nodes, to also setup the pull control
correctly. Also, in the loop that initializes multiple pins, only the
first will be muxed as the loop will break when the pull up node is not
found.
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 26 +
1 file changed, 26 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index e1d240baf35d..a9d506ba6515 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -124,6 +124,8 @@
};
{
+ u-boot,dm-spl;
+
usb {
vcc5v0_host_en: vcc5v0-host-en {
rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO _pull_none>;
@@ -131,6 +133,30 @@
};
};
+_pull_up_drv_level_2 {
+ u-boot,dm-spl;
+};
+
+_pull_up {
+ u-boot,dm-spl;
+};
+
+_bus4 {
+ u-boot,dm-spl;
+};
+
+_clk {
+ u-boot,dm-spl;
+};
+
+_cmd {
+ u-boot,dm-spl;
+};
+
+_det {
+ u-boot,dm-spl;
+};
+
_host0_ehci {
companion = <_host0_ohci>;
phys = <_host>;
Re: [PATCH] ram: rk3399: add missing high row detection
On 2023/3/23 18:35, Jonathan Liu wrote: For 2 GB LPDDR4 single-rank RAM with 16 rows, the Rockchip ddr init bin prints: "Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB" U-Boot TPL prints: "BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB" Add missing high row detection so that U-Boot TPL prints Row=16, same as the Rockchip ddr init bin: "BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB" Signed-off-by: Jonathan Liu Reviewed-by: Kever Yang Thanks, - Kever --- drivers/ram/rockchip/sdram_rk3399.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ram/rockchip/sdram_rk3399.c b/drivers/ram/rockchip/sdram_rk3399.c index b1fea04e84..b597448203 100644 --- a/drivers/ram/rockchip/sdram_rk3399.c +++ b/drivers/ram/rockchip/sdram_rk3399.c @@ -2749,6 +2749,8 @@ static u64 dram_detect_cap(struct dram_info *dram, /* detect cs1 row */ sdram_detect_cs1_row(cap_info, params->base.dramtype); + sdram_detect_high_row(cap_info); + /* detect die bw */ sdram_detect_dbw(cap_info, params->base.dramtype);
Re: [PATCH v2 3/3] rk3566: radxa-cm3: Enable USB OTG
On 2023/2/26 21:22, Manoj Sai wrote: Enable USB OTG support and update the fastboot buffer address for Radxa Compute Module 3 IO Board. This would help to use fastboot by default. Signed-off-by: Manoj Sai --- Changes for v2 :- - Updated the fastboot buffer address in drivers/fastboot/Kconfig. --- configs/radxa-cm3-io-rk3566_defconfig | 2 ++ drivers/fastboot/Kconfig | 1 + 2 files changed, 3 insertions(+) diff --git a/configs/radxa-cm3-io-rk3566_defconfig b/configs/radxa-cm3-io-rk3566_defconfig index 2100cf2cb2..aba3a65e7f 100644 --- a/configs/radxa-cm3-io-rk3566_defconfig +++ b/configs/radxa-cm3-io-rk3566_defconfig @@ -21,6 +21,7 @@ CONFIG_DEBUG_UART_BASE=0xFE66 CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SYS_LOAD_ADDR=0xc00800 CONFIG_DEBUG_UART=y +# CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_SPL_LOAD_FIT=y @@ -74,4 +75,5 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y +CONFIG_USB_GADGET=y CONFIG_ERRNO_STR=y diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig index eefa34779c..53f0b3a659 100644 --- a/drivers/fastboot/Kconfig +++ b/drivers/fastboot/Kconfig @@ -41,6 +41,7 @@ config FASTBOOT_BUF_ADDR default 0x800800 if ROCKCHIP_RK3288 || ROCKCHIP_RK3329 || \ ROCKCHIP_RK3399 default 0x28 if ROCKCHIP_RK3368 + default 0xc00800 if ROCKCHIP_RK3568 Why you need a new address for rk3568? Thanks, - Kever default 0x10 if ARCH_ZYNQMP default 0 if SANDBOX help
Re: [PATCH v2 2/3] rockchip: rk356x: update the dwc3_device register offset
Hi Manoj,
This functions has been update, please check the latest version.
Thanks,
- Kever
On 2023/2/26 21:22, Manoj Sai wrote:
update the dwc3_device register offset in board_usb_init()
for rk3568 platforms.
Signed-off-by: Manoj Sai
Reviewed-by: Jagan Teki
---
Changes for v2:-
- None
---
arch/arm/mach-rockchip/board.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index f1f70c81d0..c7729c966a 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -300,6 +300,9 @@ int usb_gadget_handle_interrupts(int index)
int board_usb_init(int index, enum usb_init_type init)
{
+ if (IS_ENABLED(CONFIG_ROCKCHIP_RK3568))
+ dwc3_device_data.base = 0xfcc0;
+
return dwc3_uboot_init(_device_data);
}
#endif /* CONFIG_USB_DWC3_GADGET */
Re: [PATCH v2 1/3] arm: dts: rockchip: rk3566: Enable USB OTG for Radxa CM3
On 2023/2/26 21:22, Manoj Sai wrote:
Enable USB OTG support for Radxa Compute Module 3 IO Board
Signed-off-by: Manoj Sai
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changes for v2 :-
- None.
Note: Above changeset has sent to kernel mailing list, which is currently under
review.
https://lore.kernel.org/linux-arm-kernel/20230223135929.630787-1-abbaraju.manoj...@amarulasolutions.com/T/#u
---
arch/arm/dts/rk3566-radxa-cm3-io.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/rk3566-radxa-cm3-io.dts
b/arch/arm/dts/rk3566-radxa-cm3-io.dts
index d89d5263cb..5e4236af4f 100644
--- a/arch/arm/dts/rk3566-radxa-cm3-io.dts
+++ b/arch/arm/dts/rk3566-radxa-cm3-io.dts
@@ -254,6 +254,14 @@
status = "okay";
};
+_otg {
+ status = "okay";
+};
+
+_host0_xhci {
+ status = "okay";
+};
+
{
assigned-clocks = < DCLK_VOP0>, < DCLK_VOP1>;
assigned-clock-parents = < PLL_HPLL>, < PLL_VPLL>;
Re: [PATCH 2/2] reset: rockchip: implement rk3588 lookup table
On 4/14/23 10:02, Kever Yang wrote:
+ Heiko and Elaine,
Hi Eugen,
On 2023/4/13 19:36, Eugen Hristev wrote:
The current DT bindings for the rk3588 clock use a different ID than the
one that is supposed to be written to the hardware registers.
Thus, we cannot use directly the id provided in the phandle, but rather
use a lookup table to correctly setup the hardware.
This approach has been implemented already in Linux, by commit :
f1c506d152ff ("clk: rockchip: add clock controller for the RK3588")
Hence, implement a similar approach using the lookup table, and adapt
the existing reset driver to work with SoCs using lookup table.
The file rst-rk3588.c has been copied as much as possible from Linux.
I didn't follow the kernel closely, I'm not sure if there have any
discussion on this,
but I think we can reuse the generic reset driver
"drivers/reset/reset-rockchip.c"
as we have done for all other SoCs, but not add a new file for rk3588
and more for
other SoCs. What we need to do is update the ID with encode version in
the header
file like rockchip vendorkernel/U-Boot.
Hi Kever,
This would not work, because in vendor U-boot we have different numbers
for the same defines.
E.g.:
Vendor U-boot:
#define SRST_PCIE4_POWER_UP 529
While in upstream Linux/Uboot:
#define SRST_PCIE4_POWER_UP 298
So to be able to keep this file in sync with Linux :
https://elixir.bootlin.com/u-boot/latest/source/include/dt-bindings/clock/rockchip,rk3588-cru.h
... we need to have a translation table .
We cannot update the id in the header above. This would break the ABI
and compatibility with Linux.
Do you agree ?
Thanks,
- Kever
Adapt the clk rk3588 driver as well to bind the reset driver with the
lookup table.
Signed-off-by: Eugen Hristev
---
arch/arm/include/asm/arch-rockchip/clock.h | 21 +
drivers/clk/rockchip/clk_rk3588.c | 2 +-
drivers/reset/Makefile | 2 +-
drivers/reset/reset-rockchip.c | 46 +-
drivers/reset/rst-rk3588.c | 854 +
5 files changed, 912 insertions(+), 13 deletions(-)
create mode 100644 drivers/reset/rst-rk3588.c
diff --git a/arch/arm/include/asm/arch-rockchip/clock.h
b/arch/arm/include/asm/arch-rockchip/clock.h
index f002ebcb7ac1..f01c5aeb71cb 100644
--- a/arch/arm/include/asm/arch-rockchip/clock.h
+++ b/arch/arm/include/asm/arch-rockchip/clock.h
@@ -194,5 +194,26 @@ int rockchip_get_clk(struct udevice **devp);
* Return: 0 success, or error value
*/
int rockchip_reset_bind(struct udevice *pdev, u32 reg_offset, u32
reg_number);
+/*
+ * rockchip_reset_bind_lut() - Bind soft reset device as child of
clock device
+ * using a dedicated SoC lookup table
+ * @pdev: clock udevice
+ * @lookup_table: register lookup_table dedicated to SoC
+ * @reg_offset: the first offset in cru for softreset registers
+ * @reg_number: the reg numbers of softreset registers
+ * Return: 0 success, or error value
+ */
+int rockchip_reset_bind_lut(struct udevice *pdev, const int
*lookup_table,
+ u32 reg_offset, u32 reg_number);
+/*
+ * rk3588_reset_bind_lut() - Bind soft reset device as child of clock
device
+ * using dedicated RK3588 lookup table
+ *
+ * @pdev: clock udevice
+ * @reg_offset: the first offset in cru for softreset registers
+ * @reg_number: the reg numbers of softreset registers
+ * Return: 0 success, or error value
+ */
+int rk3588_reset_bind_lut(struct udevice *pdev, u32 reg_offset, u32
reg_number);
#endif
diff --git a/drivers/clk/rockchip/clk_rk3588.c
b/drivers/clk/rockchip/clk_rk3588.c
index c93c9c304d40..f972aa93d717 100644
--- a/drivers/clk/rockchip/clk_rk3588.c
+++ b/drivers/clk/rockchip/clk_rk3588.c
@@ -1994,7 +1994,7 @@ static int rk3588_clk_bind(struct udevice *dev)
#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rk3588_cru, softrst_con[0]);
- ret = rockchip_reset_bind(dev, ret, 49158);
+ ret = rk3588_reset_bind_lut(dev, ret, 49158);
if (ret)
debug("Warning: software reset driver bind faile\n");
#endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 6c8b45ecbabf..163022eb0be1 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
obj-$(CONFIG_RESET_AST2500) += reset-ast2500.o
obj-$(CONFIG_RESET_AST2600) += reset-ast2600.o
-obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o
+obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o rst-rk3588.o
obj-$(CONFIG_RESET_MESON) += reset-meson.o
obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_RESET_MEDIATEK) += reset-mediatek.o
diff --git a/drivers/reset/reset-rockchip.c
b/drivers/reset/reset-rockchip.c
index e0a95edd80ac..be256bf032b2 100644
--- a/drivers/reset/reset-rockchip.c
+++
Re: [PATCH 2/2] rockchip: ringneck-px30: enforce ENV_IS_NOWHERE with Kconfig select
On 2023/3/2 01:31, Quentin Schulz wrote:
From: Quentin Schulz
Instead of letting the compiler error out if CONFIG_ENV_IS_NOWHERE is
not selected by the user, let's just enforce it when the user builds for
Ringneck PX30 so that no check needs to be performed by the compiler and
the configuration is always valid.
Suggested-by: Tom Rini
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
Reviewed-by: Kever Yang
Thanks,
- Kever
---
board/theobroma-systems/ringneck_px30/Kconfig | 1 +
board/theobroma-systems/ringneck_px30/ringneck-px30.c | 4
configs/ringneck-px30_defconfig | 1 -
3 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/board/theobroma-systems/ringneck_px30/Kconfig
b/board/theobroma-systems/ringneck_px30/Kconfig
index 24d94807db8..c33253bdad8 100644
--- a/board/theobroma-systems/ringneck_px30/Kconfig
+++ b/board/theobroma-systems/ringneck_px30/Kconfig
@@ -11,6 +11,7 @@ config SYS_CONFIG_NAME
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
+ select ENV_IS_NOWHERE
config ENV_SIZE
default 0x3000
diff --git a/board/theobroma-systems/ringneck_px30/ringneck-px30.c
b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
index 47d1a40ef7c..bb1bb4acf5c 100644
--- a/board/theobroma-systems/ringneck_px30/ringneck-px30.c
+++ b/board/theobroma-systems/ringneck_px30/ringneck-px30.c
@@ -118,10 +118,6 @@ int mmc_get_env_dev(void)
return CONFIG_SYS_MMC_ENV_DEV;
}
-#if !IS_ENABLED(CONFIG_ENV_IS_NOWHERE)
-#error Please enable CONFIG_ENV_IS_NOWHERE
-#endif
-
enum env_location arch_env_get_location(enum env_operation op, int prio)
{
const char *boot_device =
diff --git a/configs/ringneck-px30_defconfig b/configs/ringneck-px30_defconfig
index 91706d8def2..e9234efc2a0 100644
--- a/configs/ringneck-px30_defconfig
+++ b/configs/ringneck-px30_defconfig
@@ -68,7 +68,6 @@ CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_LIVE=y
CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates
assigned-clock-parents"
CONFIG_ENV_OVERWRITE=y
-CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_SPL_DM_SEQ_ALIAS=y
Re: [PATCH 1/2] rockchip: puma-rk3399: enforce ENV_IS_NOWHERE with Kconfig select
On 2023/3/2 01:31, Quentin Schulz wrote:
From: Quentin Schulz
Instead of letting the compiler error out if CONFIG_ENV_IS_NOWHERE is
not selected by the user, let's just enforce it when the user builds for
Puma RK3399 so that no check needs to be performed by the compiler and
the configuration is always valid.
Suggested-by: Tom Rini
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
Reviewed-by: Kever Yang
Thanks,
- Kever
---
board/theobroma-systems/puma_rk3399/Kconfig | 1 +
board/theobroma-systems/puma_rk3399/puma-rk3399.c | 4
configs/puma-rk3399_defconfig | 1 -
3 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/board/theobroma-systems/puma_rk3399/Kconfig
b/board/theobroma-systems/puma_rk3399/Kconfig
index 15af55574c0..cc745f56b57 100644
--- a/board/theobroma-systems/puma_rk3399/Kconfig
+++ b/board/theobroma-systems/puma_rk3399/Kconfig
@@ -11,6 +11,7 @@ config SYS_CONFIG_NAME
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
+ select ENV_IS_NOWHERE
config ENV_SIZE
default 0x4000
diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index 97f398bd754..614a60ee8f9 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -136,10 +136,6 @@ int mmc_get_env_dev(void)
return CONFIG_SYS_MMC_ENV_DEV;
}
-#if !IS_ENABLED(CONFIG_ENV_IS_NOWHERE)
-#error Please enable CONFIG_ENV_IS_NOWHERE
-#endif
-
enum env_location arch_env_get_location(enum env_operation op, int prio)
{
const char *boot_device =
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 9e3e23f825c..59017b26944 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -55,7 +55,6 @@ CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_LIVE=y
CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates
assigned-clock-parents"
CONFIG_ENV_OVERWRITE=y
-CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_SPI_MAX_HZ=5000
Re: [PATCH] board: rockchip: add Anbernic RGXX3 Series Devices
On 2023/3/17 01:46, Chris Morgan wrote:
From: Chris Morgan
The Anbernic RGxx3 is a "pseudo-device" that encompasses the following
devices:
- Anbernic RG353M
- Anbernic RG353P
- Anbernic RG353V
- Anbernic RG353VS
- Anbernic RG503
The rk3566-anbernic-rgxx3.dtsi is synced with upstream Linux, but
rk3566-anbernic-rgxx3.dts is a U-Boot specific devicetree that
is used for all RGxx3 devices.
Via the board.c file, the bootloader automatically sets the correct
fdtfile, board, and board_name environment variables so that the
correct devicetree can be passed to Linux. It is also possible to
simply hard-code a single devicetree in the boot.scr file and use
that to load Linux as well.
The common specifications for each device are:
- Rockchip RK3566 SoC
- 2 external SDMMC slots
- 1 USB-C host port, 1 USB-C peripheral port
- 1 mini-HDMI output
- MIPI-DSI based display panel
- ADC controlled joysticks with a GPIO mux
- GPIO buttons
- A PWM controlled vibrator
- An ADC controlled button
All of the common features are defined in the devicetree synced from
upstream Linux.
TODO: DSI panel auto-detection for the RG353 devices (requires porting
of DSI controller driver and DSI-DPHY driver to send DSI commands to
the panel).
Signed-off-by: Chris Morgan
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/Makefile | 1 +
.../arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi | 85 ++
arch/arm/dts/rk3566-anbernic-rgxx3.dts| 18 +
arch/arm/dts/rk3566-anbernic-rgxx3.dtsi | 786 ++
arch/arm/mach-rockchip/rk3568/Kconfig | 14 +
board/anbernic/rgxx3_rk3566/Kconfig | 15 +
board/anbernic/rgxx3_rk3566/MAINTAINERS | 6 +
board/anbernic/rgxx3_rk3566/Makefile | 6 +
board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c| 203 +
configs/anbernic-rgxx3_defconfig | 78 ++
doc/board/anbernic/index.rst | 9 +
doc/board/anbernic/rgxx3.rst | 47 ++
doc/board/index.rst | 1 +
doc/board/rockchip/rockchip.rst | 3 +
include/configs/anbernic-rgxx3-rk3566.h | 12 +
15 files changed, 1284 insertions(+)
create mode 100644 arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3566-anbernic-rgxx3.dts
create mode 100644 arch/arm/dts/rk3566-anbernic-rgxx3.dtsi
create mode 100644 board/anbernic/rgxx3_rk3566/Kconfig
create mode 100644 board/anbernic/rgxx3_rk3566/MAINTAINERS
create mode 100644 board/anbernic/rgxx3_rk3566/Makefile
create mode 100644 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
create mode 100644 configs/anbernic-rgxx3_defconfig
create mode 100644 doc/board/anbernic/index.rst
create mode 100644 doc/board/anbernic/rgxx3.rst
create mode 100644 include/configs/anbernic-rgxx3-rk3566.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c160e884bf..74dd55f700 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -165,6 +165,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399pro-rock-pi-n10.dtb
dtb-$(CONFIG_ROCKCHIP_RK3568) += \
+ rk3566-anbernic-rgxx3.dtb \
rk3568-evb.dtb \
rk3566-radxa-cm3-io.dtb \
rk3568-rock-3a.dtb
diff --git a/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
b/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
new file mode 100644
index 00..2ae8186228
--- /dev/null
+++ b/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+
+ rng: rng@fe388000 {
+ compatible = "rockchip,cryptov2-rng";
+ reg = <0x0 0xfe388000 0x0 0x2000>;
+ status = "okay";
+ };
+};
+
+ {
+ assigned-clocks =
+ < CLK_RTC_32K>,
+ < PLL_PPLL>,
+ < PCLK_PMU>, < PLL_CPLL>,
+ < PLL_GPLL>,
+ < ACLK_BUS>, < PCLK_BUS>,
+ < ACLK_TOP_HIGH>, < ACLK_TOP_LOW>,
+ < HCLK_TOP>, < PCLK_TOP>,
+ < ACLK_PERIMID>, < HCLK_PERIMID>,
+ < CPLL_500M>, < CPLL_333M>,
+ < CPLL_250M>, < CPLL_125M>,
+ < CPLL_100M>, < CPLL_62P5M>,
+ < CPLL_50M>, < CPLL_25M>;
+ assigned-clock-rates =
+ <32768>,
+ <2>,
+ <1>, <10>,
+ <118800>,
+ <15000>, <1>,
+ <5>, <4>,
+ <15000>, <1>,
+ <3>, <15000>,
+ <5>, <3>,
+
Re: [PATCH v2 2/2] configs: rockchip: rock5b-rk3588: add pinctrl to SPL
On 2023/3/18 00:29, Eugen Hristev wrote: Add pinctrl driver in SPL. Do not remove pinctrl properties for SPL dtb. Signed-off-by: Eugen Hristev Reviewed-by: Kever Yang Thanks, - Kever --- configs/rock5b-rk3588_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig index 86acb6da4306..6ae57874c4d5 100644 --- a/configs/rock5b-rk3588_defconfig +++ b/configs/rock5b-rk3588_defconfig @@ -48,7 +48,7 @@ CONFIG_CMD_REGULATOR=y # CONFIG_SPL_DOS_PARTITION is not set CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIVE=y -CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y CONFIG_SPL_CLK=y @@ -65,6 +65,7 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_SPL_PINCTRL=y CONFIG_REGULATOR_PWM=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_ROCKCHIP=y
Re: [PATCH v2 1/2] ARM: dts: rk3588-rock-5b-u-boot: add u-boot, dm-spl to pinctrl for sdmmc
On 2023/3/18 00:29, Eugen Hristev wrote:
To be able to initialize the pinctrl correctly at SPL level and read
u-boot proper from SD-Card, the pinctrl must be initialized.
Signed-off-by: Eugen Hristev
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changes in v2:
- add u-boot,dm-spl to pull up nodes, to also setup the pull control
correctly. Also, in the loop that initializes multiple pins, only the
first will be muxed as the loop will break when the pull up node is not
found.
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 26 +
1 file changed, 26 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index e1d240baf35d..a9d506ba6515 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -124,6 +124,8 @@
};
{
+ u-boot,dm-spl;
+
usb {
vcc5v0_host_en: vcc5v0-host-en {
rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO _pull_none>;
@@ -131,6 +133,30 @@
};
};
+_pull_up_drv_level_2 {
+ u-boot,dm-spl;
+};
+
+_pull_up {
+ u-boot,dm-spl;
+};
+
+_bus4 {
+ u-boot,dm-spl;
+};
+
+_clk {
+ u-boot,dm-spl;
+};
+
+_cmd {
+ u-boot,dm-spl;
+};
+
+_det {
+ u-boot,dm-spl;
+};
+
_host0_ehci {
companion = <_host0_ohci>;
phys = <_host>;
Re: [PATCH 2/2] rockchip: video: Add support for RK3568 DSI Host
On 2023/3/25 02:53, Chris Morgan wrote:
From: Chris Morgan
Add support for DSI Host controller on Rockchip RK3568. This driver
is heavily based on the Rockchip dw_mipi_dsi_rockchip.c driver in
Linux and the stm32_dsi.c driver in U-Boot. It should be easy to add
support for other SoCs as the only missing component from the mainline
driver is setting the VOP big or VOP little (which the rk3568 does
not have).
Driver was tested for use in sending commands to a DSI panel in order
to obtain the panel ID.
Signed-off-by: Chris Morgan
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/video/dw_mipi_dsi.c | 9 +
drivers/video/rockchip/Kconfig| 8 +
drivers/video/rockchip/Makefile | 1 +
drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 898 ++
4 files changed, 916 insertions(+)
create mode 100644 drivers/video/rockchip/dw_mipi_dsi_rockchip.c
diff --git a/drivers/video/dw_mipi_dsi.c b/drivers/video/dw_mipi_dsi.c
index 6d9c5a9476..a4606923ff 100644
--- a/drivers/video/dw_mipi_dsi.c
+++ b/drivers/video/dw_mipi_dsi.c
@@ -806,6 +806,15 @@ static int dw_mipi_dsi_init(struct udevice *dev,
return -EINVAL;
}
+ /*
+* The Rockchip based devices don't have px_clk, so simply move
+* on.
+*/
+ if (IS_ENABLED(CONFIG_DISPLAY_ROCKCHIP_DW_MIPI)) {
+ dw_mipi_dsi_bridge_set(dsi, timings);
+ return 0;
+ }
+
ret = clk_get_by_name(device->dev, "px_clk", );
if (ret) {
dev_err(device->dev, "peripheral clock get error %d\n", ret);
diff --git a/drivers/video/rockchip/Kconfig b/drivers/video/rockchip/Kconfig
index b03866347b..01804dcb1c 100644
--- a/drivers/video/rockchip/Kconfig
+++ b/drivers/video/rockchip/Kconfig
@@ -69,4 +69,12 @@ config DISPLAY_ROCKCHIP_MIPI
support. The mipi controller and dphy on rk3288& rk3399 support
16,18, 24 bits per pixel with up to 2k resolution ratio.
+config DISPLAY_ROCKCHIP_DW_MIPI
+ bool "Rockchip Designware MIPI"
+ depends on VIDEO_ROCKCHIP
+ select VIDEO_DW_MIPI_DSI
+ help
+ Select the Designware MIPI DSI controller in use on some Rockchip
+ SOCs.
+
endif
diff --git a/drivers/video/rockchip/Makefile b/drivers/video/rockchip/Makefile
index 9aced5ef3f..8128289cc8 100644
--- a/drivers/video/rockchip/Makefile
+++ b/drivers/video/rockchip/Makefile
@@ -15,4 +15,5 @@ obj-$(CONFIG_DISPLAY_ROCKCHIP_HDMI) += rk_hdmi.o $(obj-hdmi-y)
obj-mipi-$(CONFIG_ROCKCHIP_RK3288) += rk3288_mipi.o
obj-mipi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_mipi.o
obj-$(CONFIG_DISPLAY_ROCKCHIP_MIPI) += rk_mipi.o $(obj-mipi-y)
+obj-$(CONFIG_DISPLAY_ROCKCHIP_DW_MIPI) += dw_mipi_dsi_rockchip.o
endif
diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
new file mode 100644
index 00..ca548a60b7
--- /dev/null
+++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
@@ -0,0 +1,898 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Author(s): Chris Morgan
+ *
+ * This MIPI DSI controller driver is heavily based on the Linux Kernel
+ * driver from drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c and the
+ * U-Boot driver from drivers/video/stm32/stm32_dsi.c.
+ */
+
+#define LOG_CATEGORY UCLASS_VIDEO_BRIDGE
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define USEC_PER_SEC 100L
+
+/*
+ * DSI wrapper registers & bit definitions
+ * Note: registers are named as in the Reference Manual
+ */
+#define DSI_WCR0x0404 /* Wrapper Control Reg */
+#define WCR_DSIEN BIT(3) /* DSI ENable */
+
+#define DSI_PHY_TST_CTRL0 0xb4
+#define PHY_TESTCLKBIT(1)
+#define PHY_UNTESTCLK 0
+#define PHY_TESTCLRBIT(0)
+#define PHY_UNTESTCLR 0
+
+#define DSI_PHY_TST_CTRL1 0xb8
+#define PHY_TESTEN BIT(16)
+#define PHY_UNTESTEN 0
+#define PHY_TESTDOUT(n)(((n) & 0xff) << 8)
+#define PHY_TESTDIN(n) (((n) & 0xff) << 0)
+
+#define BYPASS_VCO_RANGE BIT(7)
+#define VCO_RANGE_CON_SEL(val) (((val) & 0x7) << 3)
+#define VCO_IN_CAP_CON_DEFAULT (0x0 << 1)
+#define VCO_IN_CAP_CON_LOW (0x1 << 1)
+#define VCO_IN_CAP_CON_HIGH(0x2 << 1)
+#define REF_BIAS_CUR_SEL BIT(0)
+
+#define CP_CURRENT_3UA 0x1
+#define CP_CURRENT_4_5UA 0x2
+#define CP_CURRENT_7_5UA 0x6
+#define CP_CURRENT_6UA 0x9
+#define CP_CURRENT_12UA0xb
+#define CP_CURRENT_SEL(val)((val) & 0xf)
+#define CP_PROGRAM_EN BIT(7)
+
+#define LPF_RESISTORS_15_5KOHM 0x1
+#define LPF_RESISTORS_13KOHM 0x2
+#define LPF_RESISTORS_11_5KOHM 0x4
+#define LPF_RESISTORS_10_5KOHM 0x8
Re: [PATCH 1/2] drivers: phy: add Innosilicon DSI-DPHY driver
On 2023/3/25 02:53, Chris Morgan wrote: From: Chris Morgan Add support for the Innosilicon DSI-DPHY driver for Rockchip SOCs. The driver was ported from Linux and tested on a Rockchip RK3566 based device to query the panel ID via a DSI command. Signed-off-by: Chris Morgan Reviewed-by: Kever Yang Thanks, - Kever --- drivers/phy/rockchip/Kconfig | 8 + drivers/phy/rockchip/Makefile | 1 + .../phy/rockchip/phy-rockchip-inno-dsidphy.c | 680 ++ 3 files changed, 689 insertions(+) create mode 100644 drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig index 1305763940..f87ca8c310 100644 --- a/drivers/phy/rockchip/Kconfig +++ b/drivers/phy/rockchip/Kconfig @@ -4,6 +4,14 @@ menu "Rockchip PHY driver" +config PHY_ROCKCHIP_INNO_DSIDPHY + bool "Rockchip INNO DSIDPHY Driver" + depends on ARCH_ROCKCHIP + select PHY + select MIPI_DPHY_HELPERS + help + Support for Rockchip MIPI DPHY with Innosilicon IP block. + config PHY_ROCKCHIP_INNO_USB2 bool "Rockchip INNO USB2PHY Driver" depends on ARCH_ROCKCHIP diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile index a236877234..25a803a8a8 100644 --- a/drivers/phy/rockchip/Makefile +++ b/drivers/phy/rockchip/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY) += phy-rockchip-naneng-combphy.o obj-$(CONFIG_PHY_ROCKCHIP_PCIE) += phy-rockchip-pcie.o obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3) += phy-rockchip-snps-pcie3.o obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o +obj-$(CONFIG_PHY_ROCKCHIP_INNO_DSIDPHY)+= phy-rockchip-inno-dsidphy.o diff --git a/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c new file mode 100644 index 00..9ed7af0d6e --- /dev/null +++ b/drivers/phy/rockchip/phy-rockchip-inno-dsidphy.c @@ -0,0 +1,680 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2018 Rockchip Electronics Co. Ltd. + * + * Author: Wyon Bi + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define UPDATE(x, h, l)(((x) << (l)) & GENMASK((h), (l))) + +/* + * The offset address[7:0] is distributed two parts, one from the bit7 to bit5 + * is the first address, the other from the bit4 to bit0 is the second address. + * when you configure the registers, you must set both of them. The Clock Lane + * and Data Lane use the same registers with the same second address, but the + * first address is different. + */ +#define FIRST_ADDRESS(x) (((x) & 0x7) << 5) +#define SECOND_ADDRESS(x) (((x) & 0x1f) << 0) +#define PHY_REG(first, second) (FIRST_ADDRESS(first) | \ +SECOND_ADDRESS(second)) + +/* Analog Register Part: reg00 */ +#define BANDGAP_POWER_MASK BIT(7) +#define BANDGAP_POWER_DOWN BIT(7) +#define BANDGAP_POWER_ON 0 +#define LANE_EN_MASK GENMASK(6, 2) +#define LANE_EN_CK BIT(6) +#define LANE_EN_3 BIT(5) +#define LANE_EN_2 BIT(4) +#define LANE_EN_1 BIT(3) +#define LANE_EN_0 BIT(2) +#define POWER_WORK_MASKGENMASK(1, 0) +#define POWER_WORK_ENABLE UPDATE(1, 1, 0) +#define POWER_WORK_DISABLE UPDATE(2, 1, 0) +/* Analog Register Part: reg01 */ +#define REG_SYNCRST_MASK BIT(2) +#define REG_SYNCRST_RESET BIT(2) +#define REG_SYNCRST_NORMAL 0 +#define REG_LDOPD_MASK BIT(1) +#define REG_LDOPD_POWER_DOWN BIT(1) +#define REG_LDOPD_POWER_ON 0 +#define REG_PLLPD_MASK BIT(0) +#define REG_PLLPD_POWER_DOWN BIT(0) +#define REG_PLLPD_POWER_ON 0 +/* Analog Register Part: reg03 */ +#define REG_FBDIV_HI_MASK BIT(5) +#define REG_FBDIV_HI(x)UPDATE((x >> 8), 5, 5) +#define REG_PREDIV_MASKGENMASK(4, 0) +#define REG_PREDIV(x) UPDATE(x, 4, 0) +/* Analog Register Part: reg04 */ +#define REG_FBDIV_LO_MASK GENMASK(7, 0) +#define REG_FBDIV_LO(x)UPDATE(x, 7, 0) +/* Analog Register Part: reg05 */ +#define SAMPLE_CLOCK_PHASE_MASKGENMASK(6, 4) +#define SAMPLE_CLOCK_PHASE(x) UPDATE(x, 6, 4) +#define CLOCK_LANE_SKEW_PHASE_MASK GENMASK(2, 0) +#define CLOCK_LANE_SKEW_PHASE(x) UPDATE(x, 2, 0) +/* Analog Register Part:
Re: [PATCH v3 3/3] rockchip: otp: fix misc_read() return values
On 2023/3/27 19:01, John Keeping wrote:
The documentation for misc_read() says:
Return: number of bytes read if OK (may be 0 if EOF), -ve on error
The Rockchip efuse driver implements this so it should return the number
of bytes read rather than zero on success. Fix this so that the driver
follows the usual contract for read operations.
Reviewed-by: Simon Glass
Reviewed-by: Jonas Karlman
Signed-off-by: John Keeping
Reviewed-by: Kever Yang
Thanks,
- Kever
---
v3: unchanged
v2: new patch
drivers/misc/rockchip-otp.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/rockchip-otp.c b/drivers/misc/rockchip-otp.c
index c19cd5ce62..4814e0e501 100644
--- a/drivers/misc/rockchip-otp.c
+++ b/drivers/misc/rockchip-otp.c
@@ -89,7 +89,7 @@ static int dump_otp(struct cmd_tbl *cmdtp, int flag,
for (i = 0; true; i += sizeof(data)) {
ret = misc_read(dev, i, , sizeof(data));
- if (ret < 0)
+ if (ret <= 0)
return 0;
print_buffer(i, data, 1, sizeof(data), sizeof(data));
@@ -249,8 +249,10 @@ static int rockchip_otp_read(struct udevice *dev, int
offset,
offset += data->offset;
- if (data->block_size <= 1)
- return data->read(dev, offset, buf, size);
+ if (data->block_size <= 1) {
+ ret = data->read(dev, offset, buf, size);
+ goto done;
+ }
block_start = offset / data->block_size;
block_offset = offset % data->block_size;
@@ -266,7 +268,9 @@ static int rockchip_otp_read(struct udevice *dev, int
offset,
memcpy(buf, buffer + block_offset, size);
free(buffer);
- return ret;
+
+done:
+ return ret < 0 ? ret : size;
}
static const struct misc_ops rockchip_otp_ops = {
Re: [PATCH v3 2/3] rockchip: efuse: fix misc_read() return values
On 2023/3/27 19:01, John Keeping wrote:
The documentation for misc_read() says:
Return: number of bytes read if OK (may be 0 if EOF), -ve on error
The Rockchip efuse driver implements this so it should return the number
of bytes read rather than zero on success. Fix this so that the driver
follows the usual contract for read operations.
Reviewed-by: Simon Glass
Reviewed-by: Jonas Karlman
Signed-off-by: John Keeping
Reviewed-by: Kever Yang
Thanks,
- Kever
---
v3: unchanged
v2:
- Fix when block_size > 1 by moving the return value to the main
rockchip_efuse_read() wrapper and leaving the individual
implementations alone (Jonas)
drivers/misc/rockchip-efuse.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/rockchip-efuse.c b/drivers/misc/rockchip-efuse.c
index 60931a5131..2f96b79ea4 100644
--- a/drivers/misc/rockchip-efuse.c
+++ b/drivers/misc/rockchip-efuse.c
@@ -73,7 +73,7 @@ static int dump_efuse(struct cmd_tbl *cmdtp, int flag,
for (i = 0; true; i += sizeof(data)) {
ret = misc_read(dev, i, , sizeof(data));
- if (ret < 0)
+ if (ret <= 0)
return 0;
print_buffer(i, data, 1, sizeof(data), sizeof(data));
@@ -238,8 +238,10 @@ static int rockchip_efuse_read(struct udevice *dev, int
offset,
offset += data->offset;
- if (data->block_size <= 1)
- return data->read(dev, offset, buf, size);
+ if (data->block_size <= 1) {
+ ret = data->read(dev, offset, buf, size);
+ goto done;
+ }
block_start = offset / data->block_size;
block_offset = offset % data->block_size;
@@ -255,7 +257,9 @@ static int rockchip_efuse_read(struct udevice *dev, int
offset,
memcpy(buf, buffer + block_offset, size);
free(buffer);
- return ret;
+
+done:
+ return ret < 0 ? ret : size;
}
static const struct misc_ops rockchip_efuse_ops = {
Re: [PATCH v3 1/3] rockchip: misc: fix misc_read() return check
On 2023/3/27 19:01, John Keeping wrote:
misc_read() is documented to return the number of bytes read or a
negative error value. The Rockchip drivers currently do not implement
this correctly and instead return zero on success or a negative error
value.
In preparation for fixing the drivers, fix the condition here to only
error on negative values.
Suggested-by: Jonas Karlman
Signed-off-by: John Keeping
Reviewed-by: Kever Yang
Thanks,
- Kever
---
v3: new patch
arch/arm/mach-rockchip/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
index 849014d2fb..7d03f0c2b6 100644
--- a/arch/arm/mach-rockchip/misc.c
+++ b/arch/arm/mach-rockchip/misc.c
@@ -83,7 +83,7 @@ int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
/* read the cpu_id range from the efuses */
ret = misc_read(dev, cpuid_offset, cpuid, cpuid_length);
- if (ret) {
+ if (ret < 0) {
debug("%s: reading cpuid from the efuses failed\n",
__func__);
return -1;
Re: [PATCH] clk: rockchip: rk3568: Add dummy I2S1_MCLKOUT_TX clock support
On 2023/4/2 23:58, Jonas Karlman wrote: A RK3568 device tree pmic node can reference the I2S1_MCLKOUT_TX clock in assigned-clocks, add dummy support to set parent of this clock to the rk3568 cru driver. Fixes probe of pmic driver and missing regulators on affected boards, rk3568-evb and rk3568-rock-3a. Signed-off-by: Jonas Karlman Reviewed-by: Kever Yang Thanks, - Kever --- drivers/clk/rockchip/clk_rk3568.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/rockchip/clk_rk3568.c b/drivers/clk/rockchip/clk_rk3568.c index 1c6adc56f913..cefc263971a6 100644 --- a/drivers/clk/rockchip/clk_rk3568.c +++ b/drivers/clk/rockchip/clk_rk3568.c @@ -2838,6 +2838,8 @@ static int rk3568_clk_set_parent(struct clk *clk, struct clk *parent) case ACLK_RKVDEC_PRE: case CLK_RKVDEC_CORE: return rk3568_rkvdec_set_parent(clk, parent); + case I2S1_MCLKOUT_TX: + break; default: return -ENOENT; }
Re: [PATCH v2] mmc: dw_mmc: reset controller after data error
On 2023/4/3 18:44, Eugen Hristev wrote:
From: Ziyuan Xu
Per dw_mmc databook, it's recommended to reset the host controller if
some data-related error occurred.
Implement a reset mechanism.
Signed-off-by: Ziyuan Xu
Co-developed-by: Jason Zhu
Signed-off-by: Jason Zhu
[eugen.hris...@collabora.com: modified a bit the variables initialization]
Signed-off-by: Eugen Hristev
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changes in v2:
- actually decrement the reset timeout timer
drivers/mmc/dw_mmc.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 5085a3b491da..d6cad998b0cd 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -138,7 +138,7 @@ static int dwmci_data_transfer(struct dwmci_host *host,
struct mmc_data *data)
{
struct mmc *mmc = host->mmc;
int ret = 0;
- u32 timeout, mask, size, i, len = 0;
+ u32 timeout, reset_timeout = 100, status, ctrl, mask, size, i, len = 0;
u32 *buf = NULL;
ulong start = get_timer(0);
u32 fifo_depth = (((host->fifoth_val & RX_WMARK_MASK) >>
@@ -159,6 +159,24 @@ static int dwmci_data_transfer(struct dwmci_host *host,
struct mmc_data *data)
/* Error during data transfer. */
if (mask & (DWMCI_DATA_ERR | DWMCI_DATA_TOUT)) {
debug("%s: DATA ERROR!\n", __func__);
+
+ dwmci_wait_reset(host, DWMCI_RESET_ALL);
+ dwmci_writel(host, DWMCI_CMD, DWMCI_CMD_PRV_DAT_WAIT |
+DWMCI_CMD_UPD_CLK | DWMCI_CMD_START);
+
+ do {
+ status = dwmci_readl(host, DWMCI_CMD);
+ if (!reset_timeout--)
+ break;
+ udelay(100);
+ } while (status & DWMCI_CMD_START);
+
+ if (!host->fifo_mode) {
+ ctrl = dwmci_readl(host, DWMCI_BMOD);
+ ctrl |= DWMCI_BMOD_IDMAC_RESET;
+ dwmci_writel(host, DWMCI_BMOD, ctrl);
+ }
+
ret = -EINVAL;
break;
}
[PATCH 1/1] sandbox: enable CONFIG_EFI_CAPSULE_AUTHENTICATE
Without CONFIG_EFI_CAPSULE_AUTHENTICATE=y the following tests are skipped: * test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py * test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py Signed-off-by: Heinrich Schuchardt --- configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index ca95b2c5d2..01c191818d 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -335,6 +335,7 @@ CONFIG_ERRNO_STR=y CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y +CONFIG_EFI_CAPSULE_AUTHENTICATE=y CONFIG_EFI_SECURE_BOOT=y CONFIG_TEST_FDTDEC=y CONFIG_UNIT_TEST=y diff --git a/configs/sandbox_flattree_defconfig b/configs/sandbox_flattree_defconfig index e9fcc5b0cb..8c2bceae22 100644 --- a/configs/sandbox_flattree_defconfig +++ b/configs/sandbox_flattree_defconfig @@ -226,6 +226,7 @@ CONFIG_ERRNO_STR=y CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y +CONFIG_EFI_CAPSULE_AUTHENTICATE=y CONFIG_UNIT_TEST=y CONFIG_UT_TIME=y CONFIG_UT_DM=y -- 2.39.2
Re: [PATCH V2 2/2] net: phy: Make phy_interface_is_rgmii a switch statement
On Thu, 13 Apr 2023 23:24:33 -0500
Nishanth Menon wrote:
> Recent commit 75d28899e3e9 ("net: phy: Synchronize PHY interface modes
> with Linux") reordered the enum definitions. This exposed a problem in
> range checking functions to identify the interface type. Though this
> specific api was'nt impacted (all the RGMII definitions remained within
> range), this experience should be used to never to have to face this
> kind of challenge again.
>
> While it is possible for the phy drivers to practically use the enum's
> directly, drivers such as dp83867, dp83869, marvell, micrel_ksz90x1 etc
> use the same.
>
> Reported-by: Tom Rini
> Signed-off-by: Nishanth Menon
> ---
> Changes since V1:
> * Switch update based on feedback from Marek
>
> V1: https://lore.kernel.org/r/20230413180713.2922524-3...@ti.com
> include/phy.h | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/include/phy.h b/include/phy.h
> index 51dadcf14478..600966bc8b20 100644
> --- a/include/phy.h
> +++ b/include/phy.h
> @@ -361,8 +361,15 @@ int get_phy_id(struct mii_dev *bus, int addr, int devad,
> u32 *phy_id);
> */
> static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
> {
> - return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
> - phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
> + switch (phydev->interface) {
> + case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + return 1;
> + default:
> + return 0;
> + }
> }
>
> /**
Reviewed-by: Marek Behún
Re: [PATCH V2 1/2] net: phy: Make phy_interface_is_sgmii a switch statement
On Thu, 13 Apr 2023 23:24:32 -0500
Nishanth Menon wrote:
> Recent commit 75d28899e3e9 ("net: phy: Synchronize PHY interface modes
> with Linux") reordered the enum definitions. This caused the range of
> enums that this api was checking to go bad.
>
> While it is possible for the phy drivers to practically use the enum's
> directly, drivers such as dp83867 use this helper to manage the
> configuration of the phy correctly.
>
> Reported-by: Tom Rini
> Signed-off-by: Nishanth Menon
> ---
> Changes Since v1:
> * Switch update based on feedback from Marek
>
> V1: https://lore.kernel.org/r/20230413180713.2922524-2...@ti.com
>
> include/phy.h | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/include/phy.h b/include/phy.h
> index a837fed72352..51dadcf14478 100644
> --- a/include/phy.h
> +++ b/include/phy.h
> @@ -373,8 +373,15 @@ static inline bool phy_interface_is_rgmii(struct
> phy_device *phydev)
> */
> static inline bool phy_interface_is_sgmii(struct phy_device *phydev)
> {
> - return phydev->interface >= PHY_INTERFACE_MODE_SGMII &&
> - phydev->interface <= PHY_INTERFACE_MODE_QSGMII;
> + switch (phydev->interface) {
> + case PHY_INTERFACE_MODE_SGMII:
> + case PHY_INTERFACE_MODE_QUSGMII:
> + case PHY_INTERFACE_MODE_USXGMII:
> + case PHY_INTERFACE_MODE_QSGMII:
> + return 1;
> + default:
> + return 0;
> + }
> }
>
> bool phy_interface_is_ncsi(void);
Reviewed-by: Marek Behún
Please also consider dropping this function, since it is used only in
one driver
drivers/net/phy/dp83867.c
and that device does not actually support QUSGMII, USXGMII nor QSGMII.
It only supports SGMII.
With rgmii, the corresponding phy_interface_is_rgmii() function makes
sense, but for SGMII the four modes are entirely too different for this
to make sense.
Marek
[PATCH 1/1] test: fix pylint warning for capsule tests
Fix pylint warnings like:
* Class inherits from object
* Missing module description
* Missing class description
* First line of comment blank
* Superfluous imports
Signed-off-by: Heinrich Schuchardt
---
test/py/tests/test_efi_capsule/conftest.py| 27
.../test_capsule_firmware_fit.py | 35
.../test_capsule_firmware_signed_fit.py | 41 ++-
.../test_capsule_firmware_signed_raw.py | 38 -
4 files changed, 65 insertions(+), 76 deletions(-)
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index 4879f2b5c2..0e5137de60 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -2,30 +2,21 @@
# Copyright (c) 2020, Linaro Limited
# Author: AKASHI Takahiro
-import os
-import os.path
-import re
-from subprocess import call, check_call, check_output, CalledProcessError
-import pytest
-from capsule_defs import *
+"""Fixture for UEFI capsule test
+"""
-#
-# Fixture for UEFI capsule test
-#
+from subprocess import call, check_call, CalledProcessError
+import pytest
+from capsule_defs import CAPSULE_DATA_DIR, CAPSULE_INSTALL_DIR, EFITOOLS_PATH
@pytest.fixture(scope='session')
def efi_capsule_data(request, u_boot_config):
-"""Set up a file system to be used in UEFI capsule and
- authentication test.
-
-Args:
-request: Pytest request object.
-u_boot_config: U-boot configuration.
+"""Set up a file system to be used in UEFI capsule and authentication test
+and return a ath to disk image to be used for testing
-Return:
-A path to disk image to be used for testing
+request -- Pytest request object.
+u_boot_config -- U-boot configuration.
"""
-global CAPSULE_DATA_DIR, CAPSULE_INSTALL_DIR
mnt_point = u_boot_config.persistent_data_dir + '/test_efi_capsule'
data_dir = mnt_point + CAPSULE_DATA_DIR
diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware_fit.py
b/test/py/tests/test_efi_capsule/test_capsule_firmware_fit.py
index d28b53a1a1..9ee152818d 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware_fit.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_fit.py
@@ -1,16 +1,13 @@
# SPDX-License-Identifier: GPL-2.0+
# Copyright (c) 2020, Linaro Limited
# Author: AKASHI Takahiro
-#
-# U-Boot UEFI: Firmware Update Test
-"""
+"""U-Boot UEFI: Firmware Update Test
This test verifies capsule-on-disk firmware update for FIT images
"""
-from subprocess import check_call, check_output, CalledProcessError
import pytest
-from capsule_defs import *
+from capsule_defs import CAPSULE_DATA_DIR, CAPSULE_INSTALL_DIR
@pytest.mark.boardspec('sandbox_flattree')
@@ -24,15 +21,18 @@ from capsule_defs import *
@pytest.mark.buildconfigspec('cmd_nvedit_efi')
@pytest.mark.buildconfigspec('cmd_sf')
@pytest.mark.slow
-class TestEfiCapsuleFirmwareFit(object):
+class TestEfiCapsuleFirmwareFit():
+"""Test capsule-on-disk firmware update for FIT images
+"""
+
def test_efi_capsule_fw1(
self, u_boot_config, u_boot_console, efi_capsule_data):
-"""
-Test Case 1 - Update U-Boot and U-Boot environment on SPI Flash
- but with an incorrect GUID value in the capsule
- No update should happen
- 0x10-0x15: U-Boot binary (but dummy)
- 0x15-0x20: U-Boot environment (but dummy)
+"""Test Case 1
+Update U-Boot and U-Boot environment on SPI Flash
+but with an incorrect GUID value in the capsule
+No update should happen
+0x10-0x15: U-Boot binary (but dummy)
+0x15-0x20: U-Boot environment (but dummy)
"""
# other tests might have run and the
# system might not be in a clean state.
@@ -74,8 +74,6 @@ class TestEfiCapsuleFirmwareFit(object):
capsule_early = u_boot_config.buildconfig.get(
'config_efi_capsule_on_disk_early')
-capsule_auth = u_boot_config.buildconfig.get(
-'config_efi_capsule_authenticate')
# reboot
u_boot_console.restart_uboot(expect_reset = capsule_early)
@@ -107,11 +105,12 @@ class TestEfiCapsuleFirmwareFit(object):
def test_efi_capsule_fw2(
self, u_boot_config, u_boot_console, efi_capsule_data):
+"""Test Case 2
+Update U-Boot and U-Boot environment on SPI Flash
+0x10-0x15: U-Boot binary (but dummy)
+0x15-0x20: U-Boot environment (but dummy)
"""
-Test Case 2 - Update U-Boot and U-Boot environment on SPI Flash
- 0x10-0x15: U-Boot binary (but dummy)
- 0x15-0x20: U-Boot environment (but dummy)
-"""
+
disk_img = efi_capsule_data
with u_boot_console.log.section('Test Case 2-a,
Re: [PATCH v2 02/10] arm: dts: introduce j784s4 u-boot dtbs
Hari,
On 21/03/23 19:40, Hari Nagalla wrote:
> Introduce the base dts files needed for u-boot or to augment the linux
> dtbs for use in the u-boot-spl and u-boot binaries.
>
> Signed-off-by: Apurva Nandan
> Signed-off-by: Hari Nagalla
> ---
> arch/arm/dts/Makefile|2 +
> arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi | 8757 +
> arch/arm/dts/k3-j784s4-ddr.dtsi | 8858 ++
> arch/arm/dts/k3-j784s4-evm-u-boot.dtsi | 135 +
> arch/arm/dts/k3-j784s4-r5-evm.dts| 209 +
> 5 files changed, 17961 insertions(+)
> create mode 100644 arch/arm/dts/k3-j784s4-ddr-evm-lp4-4266.dtsi
> create mode 100644 arch/arm/dts/k3-j784s4-ddr.dtsi
> create mode 100644 arch/arm/dts/k3-j784s4-evm-u-boot.dtsi
> create mode 100644 arch/arm/dts/k3-j784s4-r5-evm.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7a577deb50..7690fd21db 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1264,6 +1264,8 @@ dtb-$(CONFIG_SOC_K3_J721S2) +=
> k3-am68-sk-base-board.dtb\
> k3-am68-sk-r5-base-board.dtb\
> k3-j721s2-common-proc-board.dtb\
> k3-j721s2-r5-common-proc-board.dtb
[...]
> +
> +_sdhci1 {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/k3-j784s4-r5-evm.dts
> b/arch/arm/dts/k3-j784s4-r5-evm.dts
> new file mode 100644
> index 00..7350a9be34
> --- /dev/null
> +++ b/arch/arm/dts/k3-j784s4-r5-evm.dts
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-j784s4.dtsi"
> +#include
> +#include "k3-j784s4-ddr-evm-lp4-4266.dtsi"
> +#include "k3-j784s4-ddr.dtsi"
Based on the patch by Nishanth at:
https://lore.kernel.org/r/20230414075726.387461-13...@ti.com/
It might be better for "k3-j784s4-r5-evm.dts" to inherit "k3-j784s4-evm.dts" as
it will prevent duplication.
[...]
--
Regards,
Siddharth.
Re: [PATCH] mtd: cfi: respect reg address length
Hi Nuno Sá,
On 4/14/23 09:37, Nuno Sá wrote:
Hi Stefan,
On Fri, 2023-04-14 at 08:57 +0200, Stefan Roese wrote:
Hi Nuno,
On 3/27/23 15:22, Nuno Sá wrote:
flash_get_size() will get the flash size from the device itself and
go
through all erase regions to read protection status. However, the
device
mappable region (eg: devicetree reg property) might be lower than
the
device full size which means that the above cycle will result in a
data
bus exception. This change fixes it by reading the 'addr_size'
during
probe() and also use that as one possible upper limit.
Signed-off-by: Nuno Sá
---
To give a bit more of background for this patch, I caught this
issue
when running u-boot on microblaze which uses xilinx
axi_linear_flash IP.
On ADI designs using that IP, the flash size was set to 32MiB
resulting
in the mentioned data bus exception as we obviously access past the
IP size.
That said, there was not real reason for the flash truncation so
we'll
be fixing our designs so the IP will contemplate the complete flash
size.
For the above reason, I was not really sure to mark the patch as
RFC or
not... Anyways, it still feels like a valid "protection" to have
rather
then just aborting (even if it does not really make sense to ever
truncate the flash in devicetree).
drivers/mtd/cfi_flash.c | 10 --
include/flash.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index f378f6fb6139..432d0d5c9ecb 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -2196,7 +2196,11 @@ ulong flash_get_size(phys_addr_t base, int
banknum)
/* multiply the size by the number of chips */
info->size *= size_ratio;
max_size = cfi_flash_bank_size(banknum);
- if (max_size && info->size > max_size) {
+ if (max_size)
+ max_size = min(info->addr_size, max_size);
+ else
+ max_size = info->addr_size;
+ if (info->size > max_size) {
debug("[truncated from %ldMiB]", info->size
20);
info->size = max_size;
}
@@ -2492,15 +2496,17 @@ unsigned long flash_init(void)
static int cfi_flash_probe(struct udevice *dev)
{
fdt_addr_t addr;
+ fdt_size_t size;
int idx;
for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
- addr = dev_read_addr_index(dev, idx);
+ addr = dev_read_addr_size_index(dev, idx, );
if (addr == FDT_ADDR_T_NONE)
break;
flash_info[cfi_flash_num_flash_banks].dev = dev;
flash_info[cfi_flash_num_flash_banks].base = addr;
+ flash_info[cfi_flash_num_flash_banks].addr_size =
size;
cfi_flash_num_flash_banks++;
}
gd->bd->bi_flashstart = flash_info[0].base;
diff --git a/include/flash.h b/include/flash.h
index 95992fa689bb..3710a2731b76 100644
--- a/include/flash.h
+++ b/include/flash.h
@@ -46,6 +46,7 @@ typedef struct {
#ifdef CONFIG_CFI_FLASH /* DM-specific
parts */
struct udevice *dev;
phys_addr_t base;
+ phys_size_t addr_size;
#endif
} flash_info_t;
Running a CI world build leads to many errors. Here an example:
$ make integratorcp_cm926ejs_defconfig
$ make -sj
In file included from include/linux/bitops.h:22,
from include/log.h:15,
from include/linux/printk.h:4,
from include/common.h:20,
from drivers/mtd/cfi_flash.c:19:
drivers/mtd/cfi_flash.c: In function 'flash_get_size':
drivers/mtd/cfi_flash.c:2200:44: error: 'flash_info_t' has no member
named 'addr_size'
2200 | max_size = min(info->addr_size,
max_size);
| ^~
include/linux/kernel.h:182:16: note: in definition of macro 'min'
182 | typeof(x) _min1 = (x); \
| ^
drivers/mtd/cfi_flash.c:2200:44: error: 'flash_info_t' has no member
named 'addr_size'
2200 | max_size = min(info->addr_size,
max_size);
| ^~
include/linux/kernel.h:182:28: note: in definition of macro 'min'
182 | typeof(x) _min1 = (x); \
| ^
include/linux/kernel.h:184:24: warning: comparison of distinct
pointer
types lacks a cast
184 | (void) (&_min1 == &_min2); \
| ^~
drivers/mtd/cfi_flash.c:2200:36: note: in expansion of macro 'min'
2200 | max_size = min(info->addr_size,
max_size);
| ^~~
drivers/mtd/cfi_flash.c:2202:40: error: 'flash_info_t' has no member
named 'addr_size'
2202 |
[PATCH 17/23] arm: dts: k3-am642-evm-u-boot: Drop the i2c node
Drop the i2c and mux description, since we have it on main board dts.
Signed-off-by: Nishanth Menon
---
Again causes a bisect break at this point due to some weird dependency
with r5 which I could not cleanly resolve.
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index c8fd08885366..6e85101f134e 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -34,21 +34,14 @@
_pmx0 {
bootph-pre-ram;
- main_i2c0_pins_default: main-i2c0-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
I2C0_SCL */
- AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
I2C0_SDA */
- >;
- };
+};
+
+_i2c0_pins_default {
+ bootph-pre-ram;
};
_i2c0 {
- status = "okay";
bootph-pre-ram;
- pinctrl-names = "default";
- pinctrl-0 = <_i2c0_pins_default>;
- clock-frequency = <40>;
};
_uart0 {
--
2.40.0
[PATCH 15/23] arm: dts: k3-am642-evm: Add main_uart1 description
Add main_uart1 description in evm devicetree.
This is a pending upstream kernel updates as of v6.3-rc6.
Signed-off-by: Nishanth Menon
---
Sent to kernel.org
https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/
arch/arm/dts/k3-am642-evm.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index 82d356a66793..9cc271d9a22a 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -230,6 +230,16 @@
>;
};
+ /* XXX: Upstream kernel TODO: send upstream pinmux */
+ main_uart1_pins_default: main-uart1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0248, PIN_INPUT, 0) /*
(D16) UART1_CTSn */
+ AM64X_IOPAD(0x024c, PIN_OUTPUT, 0) /*
(E16) UART1_RTSn */
+ AM64X_IOPAD(0x0240, PIN_INPUT, 0) /*
(E15) UART1_RXD */
+ AM64X_IOPAD(0x0244, PIN_OUTPUT, 0) /*
(E14) UART1_TXD */
+ >;
+ };
+
main_uart0_pins_default: main-uart0-pins-default {
pinctrl-single,pins = <
AM64X_IOPAD(0x0238, PIN_INPUT, 0) /* (B16) UART0_CTSn */
@@ -355,6 +365,9 @@
/* main_uart1 is reserved for firmware usage */
_uart1 {
status = "reserved";
+ /* XXX: Upstream kernel TODO: send upstream pinmux */
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart1_pins_default>;
};
_i2c1 {
--
2.40.0
[PATCH 04/23] arm: dts: k3-am642-sk: Fix mmc1 pinmux pull polarity
Fix the pinmux pull polarity.
This is a pending upstream kernel updates as of v6.3-rc6.
Signed-off-by: Nishanth Menon
---
Sent to kernel.org
https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/
arch/arm/dts/k3-am642-sk.dts | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/k3-am642-sk.dts b/arch/arm/dts/k3-am642-sk.dts
index 4fb279489cfc..cc2027417e86 100644
--- a/arch/arm/dts/k3-am642-sk.dts
+++ b/arch/arm/dts/k3-am642-sk.dts
@@ -223,15 +223,17 @@
_pmx0 {
main_mmc1_pins_default: main-mmc1-pins-default {
+ /* XXX: Kernel-Upstream: TODO: Upstream (pull changes) */
pinctrl-single,pins = <
- AM64X_IOPAD(0x0294, PIN_INPUT, 0) /* (J19) MMC1_CMD */
+ AM64X_IOPAD(0x029c, PIN_INPUT_PULLUP, 0) /* (C20)
MMC1_SDWP */
+ AM64X_IOPAD(0x0298, PIN_INPUT_PULLUP, 0) /* (D19)
MMC1_SDCD */
+ AM64X_IOPAD(0x0294, PIN_INPUT_PULLUP, 0) /* (J19)
MMC1_CMD */
AM64X_IOPAD(0x0290, PIN_INPUT, 0) /* (#N/A) MMC1_CLKLB
*/
- AM64X_IOPAD(0x028c, PIN_INPUT, 0) /* (L20) MMC1_CLK */
- AM64X_IOPAD(0x0288, PIN_INPUT, 0) /* (K21) MMC1_DAT0 */
- AM64X_IOPAD(0x0284, PIN_INPUT, 0) /* (L21) MMC1_DAT1 */
- AM64X_IOPAD(0x0280, PIN_INPUT, 0) /* (K19) MMC1_DAT2 */
- AM64X_IOPAD(0x027c, PIN_INPUT, 0) /* (K18) MMC1_DAT3 */
- AM64X_IOPAD(0x0298, PIN_INPUT, 0) /* (D19) MMC1_SDCD */
+ AM64X_IOPAD(0x028c, PIN_INPUT_PULLDOWN, 0) /* (L20)
MMC1_CLK */
+ AM64X_IOPAD(0x0288, PIN_INPUT_PULLUP, 0) /* (K21)
MMC1_DAT0 */
+ AM64X_IOPAD(0x0284, PIN_INPUT_PULLUP, 0) /* (L21)
MMC1_DAT1 */
+ AM64X_IOPAD(0x0280, PIN_INPUT_PULLUP, 0) /* (K19)
MMC1_DAT2 */
+ AM64X_IOPAD(0x027c, PIN_INPUT_PULLUP, 0) /* (K18)
MMC1_DAT3 */
>;
};
--
2.40.0
[PATCH 05/23] arm: dts: k3-am642-sk: Add main_uart1 description
Add main_uart1 description in sk devicetree.
This is a pending upstream kernel updates as of v6.3-rc6.
Signed-off-by: Nishanth Menon
---
Sent to kernel.org
https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/
arch/arm/dts/k3-am642-sk.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/k3-am642-sk.dts b/arch/arm/dts/k3-am642-sk.dts
index cc2027417e86..a0431ad374a5 100644
--- a/arch/arm/dts/k3-am642-sk.dts
+++ b/arch/arm/dts/k3-am642-sk.dts
@@ -246,6 +246,16 @@
>;
};
+ /* XXX: Kernel-Upstream: TODO: Upstream */
+ main_uart1_pins_default: main-uart1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0248, PIN_INPUT, 0) /* (D16) UART1_CTSn */
+ AM64X_IOPAD(0x024c, PIN_OUTPUT, 0) /* (E16) UART1_RTSn
*/
+ AM64X_IOPAD(0x0240, PIN_INPUT, 0) /* (E15) UART1_RXD */
+ AM64X_IOPAD(0x0244, PIN_OUTPUT, 0) /* (E14) UART1_TXD */
+ >;
+ };
+
main_usb0_pins_default: main-usb0-pins-default {
pinctrl-single,pins = <
AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19)
USB0_DRVVBUS */
@@ -349,6 +359,9 @@
_uart1 {
/* main_uart1 is reserved for firmware usage */
status = "reserved";
+ /* XXX: Kernel-Upstream: TODO: Upstream pinmux */
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart1_pins_default>;
};
_i2c1 {
--
2.40.0
[PATCH 14/23] arm: dts: k3-am642-evm: Add DDR vtt regulator
Describe the DDR vtt regulator on evm
This is a pending upstream kernel updates as of v6.3-rc6.
Signed-off-by: Nishanth Menon
---
Sent to kernel.org
https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/
I skipped doing the regulator renaming etc, it is just churn
un-necessary for the original purpose of fixing the r5.dts
arch/arm/dts/k3-am642-evm.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index ed3a6f1341b0..82d356a66793 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -148,6 +148,21 @@
regulator-boot-on;
};
+ /* XXX: Upstream kernel TODO: send upstream */
+ vtt_supply: regulator-5 {
+ compatible = "regulator-fixed";
+ regulator-name = "vtt";
+ pinctrl-names = "default";
+ pinctrl-0 = <_vtt_pins_default>;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <_gpio0 12 GPIO_ACTIVE_HIGH>;
+ vin-supply = <_3v3>;
+ enable-active-high;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
leds {
compatible = "gpio-leds";
@@ -322,6 +337,13 @@
AM64X_IOPAD(0x0258, PIN_OUTPUT, 0) /* (C17) MCAN1_TX */
>;
};
+
+ /* XXX: Upstream kernel TODO: send upstream */
+ ddr_vtt_pins_default: ddr-vtt-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0030, PIN_OUTPUT_PULLUP, 7) /* (L18)
OSPI0_CSN1.GPIO0_12 */
+ >;
+ };
};
_uart0 {
--
2.40.0
[PATCH 02/23] arm: dts: k3-am64: Update devicetree to sync with v6.3-rc6
Sync with Kernel.org v6.3-rc6 tag.
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/k3-am642.dtsi b/arch/arm/dts/k3-am642.dtsi
index 8a76f4821b11..7a6eedea3aae 100644
--- a/arch/arm/dts/k3-am642.dtsi
+++ b/arch/arm/dts/k3-am642.dtsi
@@ -58,6 +58,7 @@
L2_0: l2-cache0 {
compatible = "cache";
cache-level = <2>;
+ cache-unified;
cache-size = <0x4>;
cache-line-size = <64>;
cache-sets = <256>;
--
2.40.0
[PATCH 23/23] configs: am64x_evm_a53_defconfig: Just use distroboot
Just use distroboot when we are attempting to enable that by default.
Signed-off-by: Nishanth Menon
---
we should probably do this for all other defconfigs instead of the weird
hacks folks have been doing inconsistenly in am62x, j721e defconfig.
if we are distroboot, just do it.. envboot is for personal user
overrides.
configs/am64x_evm_a53_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index 6543ae76fcb1..ea6165d8f7e1 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -31,7 +31,7 @@ CONFIG_SPL_SPI=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run distro_bootcmd"
CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x18
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
--
2.40.0
[PATCH 20/23] arm: dts: k3-am642-evm-u-boot: Add missing pinmux notations
Add required pinmux spl notations for pinmux entries that are missing.
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index afd1fc4c0b0b..11a4cb5dad88 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -45,6 +45,10 @@
bootph-pre-ram;
};
+_uart0_pins_default {
+ bootph-pre-ram;
+};
+
_uart0 {
bootph-pre-ram;
};
@@ -102,6 +106,18 @@
bootph-pre-ram;
};
+_pins_default {
+ bootph-pre-ram;
+};
+
+_pins_default {
+ bootph-pre-ram;
+};
+
+_pins_default {
+ bootph-pre-ram;
+};
+
{
reg = <0x0 0x800 0x0 0x20>,
<0x0 0x43000200 0x0 0x8>;
--
2.40.0
[PATCH 13/23] arm: dts: k3-am642-evm: Move the mdio pinmux down to evm.dts
Since networking is needed even for u-boot, lets move the MDIO pinmux
hack down to evm.dts.
Until MDIO is converted to DM model, it won't be possible to probe for
pinmux from the MDIO node. To work around this, hack the board dts
to set the default mux option to include MDIO. This hack is a limitation
for now till we get u-boot MDIO driver into DM model.
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 4
arch/arm/dts/k3-am642-evm.dts | 3 ++-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 64857b09099d..c8fd08885366 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -113,10 +113,6 @@
<0x0 0x43000200 0x0 0x8>;
reg-names = "cpsw_nuss", "mac_efuse";
/delete-property/ ranges;
- pinctrl-0 = <_pins_default/* HACK: as MDIO driver is not
DM enabled */
-_pins_default
-_pins_default>;
-
cpsw-phy-sel@04044 {
compatible = "ti,am64-phy-gmii-sel";
reg = <0x0 0x43004044 0x0 0x8>;
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index 39feea78a084..ed3a6f1341b0 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -425,7 +425,8 @@
{
pinctrl-names = "default";
- pinctrl-0 = <_pins_default
+ pinctrl-0 = <_pins_default/* HACK: as MDIO driver is not
DM enabled */
+_pins_default
_pins_default>;
};
--
2.40.0
[PATCH 19/23] arm: dts: k3-am642-evm-u-boot: Re-organize the pinmux
Reorder the pinmux to place it above the interface for easier tracking.
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 83e00c3f4553..afd1fc4c0b0b 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -49,20 +49,16 @@
bootph-pre-ram;
};
- {
- dr_mode="peripheral";
- bootph-pre-ram;
-};
-
- {
+_usb0_pins_default {
bootph-pre-ram;
};
-_mmc1_pins_default {
+ {
+ dr_mode="peripheral";
bootph-pre-ram;
};
-_usb0_pins_default {
+ {
bootph-pre-ram;
};
@@ -98,6 +94,10 @@
bootph-pre-ram;
};
+_mmc1_pins_default {
+ bootph-pre-ram;
+};
+
{
bootph-pre-ram;
};
--
2.40.0
[PATCH 12/23] arm: dts: k3-am642-r5-sk: Use am642-sk.dts and k3-am642-sk-u-boot.dtsi
Use am642-sk.dts to represent the Board and selectively enable/override
the configurations necessary. And since am642-sk-u-boot.dtsi also needs
to setup common properties, instead of re-inventing everything, just
reuse the definitions.
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-r5-sk.dts | 194 +++-
1 file changed, 18 insertions(+), 176 deletions(-)
diff --git a/arch/arm/dts/k3-am642-r5-sk.dts b/arch/arm/dts/k3-am642-r5-sk.dts
index 9ff4dd3dd365..8ac6cc77256c 100644
--- a/arch/arm/dts/k3-am642-r5-sk.dts
+++ b/arch/arm/dts/k3-am642-r5-sk.dts
@@ -5,31 +5,18 @@
/dts-v1/;
-#include
-#include
-#include
-#include "k3-am642.dtsi"
+#include "k3-am642-sk.dts"
#include "k3-am64-sk-lp4-1600MTs.dtsi"
#include "k3-am64-ddr.dtsi"
-/ {
- chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
+#include "k3-am642-sk-u-boot.dtsi"
+/ {
aliases {
remoteproc0 =
remoteproc1 = _0;
};
- memory@8000 {
- device_type = "memory";
- /* 2G RAM */
- reg = <0x 0x8000 0x 0x8000>;
- bootph-pre-ram;
- };
-
a53_0: a53@0 {
compatible = "ti,am654-rproc";
reg = <0x00 0x00a9 0x00 0x10>;
@@ -46,18 +33,6 @@
bootph-pre-ram;
};
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- secure_ddr: optee@9e80 {
- reg = <0x00 0x9e80 0x00 0x0180>; /* for OP-TEE
*/
- alignment = <0x1000>;
- no-map;
- };
- };
-
clk_200mhz: dummy-clock-200mhz {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -73,9 +48,8 @@
mbox-names = "tx", "rx";
bootph-pre-ram;
};
-};
-_main {
+ /* XXX: Upstream kernel TODO: send upstream */
main_esm: esm@42 {
compatible = "ti,j721e-esm";
reg = <0x0 0x42 0x0 0x1000>;
@@ -86,6 +60,8 @@
_mcu {
bootph-pre-ram;
+
+ /* XXX: Upstream kernel TODO: send upstream */
mcu_esm: esm@410 {
compatible = "ti,j721e-esm";
reg = <0x0 0x410 0x0 0x1000>;
@@ -94,92 +70,8 @@
};
};
-_pmx0 {
- bootph-pre-ram;
- main_uart0_pins_default: main-uart0-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x0238, PIN_INPUT, 0) /*
(B16) UART0_CTSn */
- AM64X_IOPAD(0x023c, PIN_OUTPUT, 0) /*
(A16) UART0_RTSn */
- AM64X_IOPAD(0x0230, PIN_INPUT, 0) /*
(D15) UART0_RXD */
- AM64X_IOPAD(0x0234, PIN_OUTPUT, 0) /*
(C16) UART0_TXD */
- >;
- };
-
- main_uart1_pins_default: main-uart1-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x0248, PIN_INPUT, 0) /*
(D16) UART1_CTSn */
- AM64X_IOPAD(0x024c, PIN_OUTPUT, 0) /*
(E16) UART1_RTSn */
- AM64X_IOPAD(0x0240, PIN_INPUT, 0) /*
(E15) UART1_RXD */
- AM64X_IOPAD(0x0244, PIN_OUTPUT, 0) /*
(E14) UART1_TXD */
- >;
- };
-
- main_mmc1_pins_default: main-mmc1-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x0294, PIN_INPUT_PULLUP, 0)/*
(J19) MMC1_CMD */
- AM64X_IOPAD(0x028c, PIN_INPUT_PULLDOWN, 0) /*
(L20) MMC1_CLK */
- AM64X_IOPAD(0x0288, PIN_INPUT_PULLUP, 0)/*
(K21) MMC1_DAT0 */
- AM64X_IOPAD(0x0284, PIN_INPUT_PULLUP, 0)/*
(L21) MMC1_DAT1 */
- AM64X_IOPAD(0x0280, PIN_INPUT_PULLUP, 0)/*
(K19) MMC1_DAT2 */
- AM64X_IOPAD(0x027c, PIN_INPUT_PULLUP, 0)/*
(K18) MMC1_DAT3 */
- AM64X_IOPAD(0x0298, PIN_INPUT_PULLUP, 0)/*
(D19) MMC1_SDCD */
- AM64X_IOPAD(0x029c, PIN_INPUT_PULLUP, 0)/*
(C20) MMC1_SDWP */
- >;
- };
-
- main_usb0_pins_default: main-usb0-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19)
USB0_DRVVBUS */
- >;
- };
-
- mdio1_pins_default: mdio1-pins-default {
- pinctrl-single,pins = <
- AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* (R2)
PRG0_PRU1_GPO19.MDIO0_MDC */
- AM64X_IOPAD(0x01f8,
[PATCH 06/23] arm: dts: k3-am642-sk: Add main_i2c0 and eeprom
Add missing main_i2c0 node and eeprom property.
This is a pending upstream kernel updates as of v6.3-rc6.
Signed-off-by: Nishanth Menon
---
Sent to kernel.org
https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/
arch/arm/dts/k3-am642-sk.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/dts/k3-am642-sk.dts b/arch/arm/dts/k3-am642-sk.dts
index a0431ad374a5..5d16aa0d7596 100644
--- a/arch/arm/dts/k3-am642-sk.dts
+++ b/arch/arm/dts/k3-am642-sk.dts
@@ -262,6 +262,14 @@
>;
};
+ /* XXX: Kernel-Upstream: TODO: Upstream */
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
I2C0_SCL */
+ AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
I2C0_SDA */
+ >;
+ };
+
main_i2c1_pins_default: main-i2c1-pins-default {
pinctrl-single,pins = <
AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18)
I2C1_SCL */
@@ -364,6 +372,19 @@
pinctrl-0 = <_uart1_pins_default>;
};
+/* XXX: Kernel-Upstream: TODO: Upstream */
+_i2c0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+
+ eeprom@51 {
+ compatible = "atmel,24c512";
+ reg = <0x51>;
+ };
+};
+
_i2c1 {
status = "okay";
pinctrl-names = "default";
--
2.40.0
[PATCH 21/23] arm: dts: k3-am642-r5-evm: Use am642-evm.dts and k3-am642-evm-u-boot.dtsi
Use am642-evm.dts to represent the Board and selectively
enable/override the configurations necessary. And since
am642-evm-u-boot.dtsi also needs to setup common properties, instead
of re-inventing everything, just reuse the definitions.
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-r5-evm.dts | 203 +--
1 file changed, 29 insertions(+), 174 deletions(-)
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index ca5ce4a35a5c..140dd90fbdf1 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -5,29 +5,18 @@
/dts-v1/;
-#include "k3-am642.dtsi"
+#include "k3-am642-evm.dts"
#include "k3-am64-evm-ddr4-1600MTs.dtsi"
#include "k3-am64-ddr.dtsi"
-/ {
- chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
+#include "k3-am642-evm-u-boot.dtsi"
+/ {
aliases {
remoteproc0 =
remoteproc1 = _0;
};
- memory@8000 {
- device_type = "memory";
- /* 2G RAM */
- reg = <0x 0x8000 0x 0x8000>;
-
- bootph-pre-ram;
- };
-
a53_0: a53@0 {
compatible = "ti,am654-rproc";
reg = <0x00 0x00a9 0x00 0x10>;
@@ -44,34 +33,12 @@
bootph-pre-ram;
};
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- secure_ddr: optee@9e80 {
- reg = <0x00 0x9e80 0x00 0x0180>; /* for OP-TEE
*/
- alignment = <0x1000>;
- no-map;
- };
- };
-
clk_200mhz: dummy-clock-200mhz {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <2>;
bootph-pre-ram;
};
-
- vtt_supply: vtt-supply {
- compatible = "regulator-gpio";
- regulator-name = "vtt";
- regulator-min-microvolt = <0>;
- regulator-max-microvolt = <330>;
- gpios = <_gpio0 12 GPIO_ACTIVE_HIGH>;
- states = <0 0x0 330 0x1>;
- bootph-pre-ram;
- };
};
_main {
@@ -81,9 +48,8 @@
mbox-names = "tx", "rx";
bootph-pre-ram;
};
-};
-_main {
+ /* XXX: Upstream kernel TODO: send upstream */
main_esm: esm@42 {
compatible = "ti,j721e-esm";
reg = <0x0 0x42 0x0 0x1000>;
@@ -94,6 +60,8 @@
_mcu {
bootph-pre-ram;
+
+ /* XXX: Upstream kernel TODO: send upstream */
mcu_esm: esm@410 {
compatible = "ti,j721e-esm";
reg = <0x0 0x410 0x0 0x1000>;
@@ -102,115 +70,8 @@
};
};
-_pmx0 {
- bootph-pre-ram;
- main_uart0_pins_default: main-uart0-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x0238, PIN_INPUT, 0) /*
(B16) UART0_CTSn */
- AM64X_IOPAD(0x023c, PIN_OUTPUT, 0) /*
(A16) UART0_RTSn */
- AM64X_IOPAD(0x0230, PIN_INPUT, 0) /*
(D15) UART0_RXD */
- AM64X_IOPAD(0x0234, PIN_OUTPUT, 0) /*
(C16) UART0_TXD */
- >;
- };
-
- main_uart1_pins_default: main-uart1-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x0248, PIN_INPUT, 0) /*
(D16) UART1_CTSn */
- AM64X_IOPAD(0x024c, PIN_OUTPUT, 0) /*
(E16) UART1_RTSn */
- AM64X_IOPAD(0x0240, PIN_INPUT, 0) /*
(E15) UART1_RXD */
- AM64X_IOPAD(0x0244, PIN_OUTPUT, 0) /*
(E14) UART1_TXD */
- >;
- };
-
- main_mmc0_pins_default: main-mmc0-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN, 0) /*
(B25) MMC0_CLK */
- AM64X_IOPAD(0x01aC, PIN_INPUT_PULLUP, 0)/*
(B27) MMC0_CMD */
- AM64X_IOPAD(0x01a4, PIN_INPUT_PULLUP, 0)/*
(A26) MMC0_DAT0 */
- AM64X_IOPAD(0x01a0, PIN_INPUT_PULLUP, 0)/*
(E25) MMC0_DAT1 */
- AM64X_IOPAD(0x019c, PIN_INPUT_PULLUP, 0)/*
(C26) MMC0_DAT2 */
- AM64X_IOPAD(0x0198, PIN_INPUT_PULLUP, 0)/*
(A25) MMC0_DAT3 */
- AM64X_IOPAD(0x0194, PIN_INPUT_PULLUP, 0)/*
(E24) MMC0_DAT4 */
- AM64X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0)/*
(A24) MMC0_DAT5 */
- AM64X_IOPAD(0x018c,
[PATCH 03/23] arm: dts: k3-am642-sk: Add a note to handle pinmux till MDIO DM conversion is done
Until MDIO is converted to DM model, it won't be possible to probe for
pinmux from the MDIO node. To work around this, lets hack the board dts
to set the default mux option to include MDIO. This hack is a limitation
for now till we get u-boot MDIO driver into DM model.
Signed-off-by: Nishanth Menon
---
Cant send this upstream.
arch/arm/dts/k3-am642-sk.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am642-sk.dts b/arch/arm/dts/k3-am642-sk.dts
index 2e2d40da360a..4fb279489cfc 100644
--- a/arch/arm/dts/k3-am642-sk.dts
+++ b/arch/arm/dts/k3-am642-sk.dts
@@ -439,7 +439,9 @@
{
pinctrl-names = "default";
- pinctrl-0 = <_pins_default
+ /* XXX: U-boot HACK: mdio pinmux till MDIO DM conversion is done */
+ pinctrl-0 = <_pins_default
+_pins_default
_pins_default>;
};
--
2.40.0
[PATCH 11/23] arm: dts: k3-am642-sk-u-boot: Drop aliases and stdout
These are inherited from am642-sk.dts itself.
While at this, fix up a minor formatting error with main_cbass.
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 4a5ab6a7c4be..25a32206a244 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -5,20 +5,15 @@
/ {
chosen {
- stdout-path = "serial2:115200n8";
tick-timer =
};
- aliases {
- mmc1 =
- };
-
memory@8000 {
bootph-pre-ram;
};
};
-_main{
+_main {
bootph-pre-ram;
/* XXX: Upstream kernel TODO: send upstream */
--
2.40.0
[PATCH 22/23] include: configs: am64x_evm: Change to using .env
Move to using .env file for setting up environment variables for am64x.
Signed-off-by: Nishanth Menon
---
I think this was long time pending.. but anyways..
board/ti/am64x/Kconfig | 3 +
board/ti/am64x/am64x.env| 37
include/configs/am64x_evm.h | 117 ++--
3 files changed, 72 insertions(+), 85 deletions(-)
create mode 100644 board/ti/am64x/am64x.env
diff --git a/board/ti/am64x/Kconfig b/board/ti/am64x/Kconfig
index afb54f8cdabb..bc99b041228d 100644
--- a/board/ti/am64x/Kconfig
+++ b/board/ti/am64x/Kconfig
@@ -37,6 +37,9 @@ config SYS_VENDOR
config SYS_CONFIG_NAME
default "am64x_evm"
+config ENV_SOURCE_FILE
+ default "am64x"
+
source "board/ti/common/Kconfig"
endif
diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
new file mode 100644
index ..28ba0ac073b8
--- /dev/null
+++ b/board/ti/am64x/am64x.env
@@ -0,0 +1,37 @@
+#include
+#include
+
+default_device_tree=k3-am642-evm.dtb
+findfdt=
+ setenv name_fdt ${default_device_tree};
+ if test $board_name = am64x_gpevm; then
+ setenv name_fdt k3-am642-evm.dtb; fi;
+ if test $board_name = am64x_skevm; then
+ setenv name_fdt k3-am642-sk.dtb; fi;
+ setenv fdtfile ${name_fdt}
+
+name_kern=Image
+console=ttyS2,115200n8
+args_all=setenv optargs ${optargs} ${mtdparts}
+run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+
+boot=mmc
+mmcdev=1
+bootpart=1:2
+bootdir=/boot
+rd_spec=-
+init_mmc=run args_all args_mmc
+get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
+get_overlay_mmc=
+ fdt address ${fdtaddr};
+ fdt resize 0x10;
+ for overlay in $name_overlays;
+ do;
+ load mmc ${bootpart} ${dtboaddr} ${bootdir}/${overlay} &&
+ fdt apply ${dtboaddr};
+ done;
+get_kern_mmc=load mmc ${bootpart} ${loadaddr}
+ ${bootdir}/${name_kern}
+get_fit_mmc=load mmc ${bootpart} ${addr_fit}
+ ${bootdir}/${name_fit}
+partitions=name=rootfs,start=0,size=-,uuid=${uuid_gpt_rootfs}
diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index 26a7f2521ecc..6c5987b6e0cd 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -2,7 +2,7 @@
/*
* Configuration header file for K3 AM642 SoC family
*
- * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2023 Texas Instruments Incorporated - https://www.ti.com/
* Keerthy
*/
@@ -10,98 +10,45 @@
#define __CONFIG_AM642_EVM_H
#include
-#include
-#include
-#include
-#include
/* DDR Configuration */
#define CFG_SYS_SDRAM_BASE10x88000
-#define PARTS_DEFAULT \
- /* Linux partitions */ \
- "name=rootfs,start=0,size=-,uuid=${uuid_gpt_rootfs}\0"
-
-/* U-Boot general configuration */
-#define EXTRA_ENV_AM642_BOARD_SETTINGS \
- "findfdt=" \
- "if test $board_name = am64x_gpevm; then " \
- "setenv fdtfile k3-am642-evm.dtb; fi; " \
- "if test $board_name = am64x_skevm; then " \
- "setenv fdtfile k3-am642-sk.dtb; fi;" \
- "if test $fdtfile = undefined; then " \
- "echo WARNING: Could not determine device tree to use;
fi; \0" \
- "name_kern=Image\0" \
- "console=ttyS2,115200n8\0" \
- "args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 " \
- "${mtdparts}\0" \
- "run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}\0"
-
-/* U-Boot MMC-specific configuration */
-#define EXTRA_ENV_AM642_BOARD_SETTINGS_MMC \
- "boot=mmc\0"\
- "mmcdev=1\0"\
- "bootpart=1:2\0"\
- "bootdir=/boot\0" \
- "rd_spec=-\0" \
- "init_mmc=run args_all args_mmc\0" \
- "get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
- "get_overlay_mmc=" \
- "fdt address ${fdtaddr};" \
- "fdt resize 0x10;" \
- "for overlay in $name_overlays;"\
- "do;" \
- "load mmc ${bootpart} ${dtboaddr} ${bootdir}/${overlay} && "
\
- "fdt apply ${dtboaddr};"\
- "done;\0" \
-
[PATCH 10/23] arm: dts: k3-am642-sk-u-boot: Document timer as missing upstream
Mark the timer as missing in upstream kernel.
Signed-off-by: Nishanth Menon
---
Sent to kernel.org
https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/
once the patches are merged, we can consider integrating the same in the
appropriate sync, I have tried to stay off main SoC dtsi file mods in
this series.
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 122a304d4501..4a5ab6a7c4be 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -20,6 +20,8 @@
_main{
bootph-pre-ram;
+
+ /* XXX: Upstream kernel TODO: send upstream */
timer1: timer@240 {
compatible = "ti,omap5430-timer";
reg = <0x0 0x240 0x0 0x80>;
--
2.40.0
[PATCH 18/23] arm: dts: k3-am642-evm-u-boot: Drop stdout and cosmetic fixups
stdout is provided in evm.dts, add documentation that timer needs to be
fixed in upstream. While at it, fix a minor formatting error
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 6e85101f134e..83e00c3f4553 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -5,7 +5,6 @@
/ {
chosen {
- stdout-path = "serial2:115200n8";
tick-timer =
};
@@ -14,8 +13,10 @@
};
};
-_main{
+_main {
bootph-pre-ram;
+
+ /* XXX: Upstream kernel TODO: send upstream pinmux */
timer1: timer@240 {
compatible = "ti,omap5430-timer";
reg = <0x0 0x240 0x0 0x80>;
--
2.40.0
[PATCH 07/23] arm: dts: k3-am642-sk-u-boot: Drop the i2c node
Drop the i2c and mux description, since we have it on main board dts.
Signed-off-by: Nishanth Menon
---
This causes a bisect break with some weird dependency on r5-sk.dts on
u-boot.dtsi
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index f6b8b887e4c1..aa3551c2bb4a 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -38,20 +38,14 @@
_pmx0 {
bootph-pre-ram;
- main_i2c0_pins_default: main-i2c0-pins-default {
- bootph-pre-ram;
- pinctrl-single,pins = <
- AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
I2C0_SCL */
- AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
I2C0_SDA */
- >;
- };
+};
+
+_i2c0_pins_default {
+ bootph-pre-ram;
};
_i2c0 {
bootph-pre-ram;
- pinctrl-names = "default";
- pinctrl-0 = <_i2c0_pins_default>;
- clock-frequency = <40>;
};
_uart0 {
--
2.40.0
[PATCH 01/23] Revert "ARM: dts: k3-am642-sk-u-boot: add PMIC node"
The original patch is completely wrong.
a) https://www.ti.com/tool/SK-AM64#design-files shows no such PMIC
driving the supplies.
b) This should have gone upstream to am64-sk.dts and NOT hacked into
u-boot.dtsi.
This reverts commit 28a4c3113445d4400639f357fae0def007a41093.
Cc: Neil Armstrong
Cc: Kevin Hilman
Signed-off-by: Nishanth Menon
---
https://www.ti.com/tool/SK-AM64B seems to be TPS6522053RHBR, but
anyways, it is not this dts - revert, and when the board dts is added to
kernel.org, we can see how to backport it - this just adds to all kind
of confusion when syncing with kernel.org
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 61
1 file changed, 61 deletions(-)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 69dbe943bdf3..f6b8b887e4c1 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -52,67 +52,6 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c0_pins_default>;
clock-frequency = <40>;
-
- tps65219: pmic@30 {
- compatible = "ti,tps65219";
- reg = <0x30>;
-
- regulators {
- buck1_reg: buck1 {
- regulator-name = "VDD_CORE";
- regulator-min-microvolt = <75>;
- regulator-max-microvolt = <75>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- buck2_reg: buck2 {
- regulator-name = "VCC1V8";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- buck3_reg: buck3 {
- regulator-name = "VDD_LPDDR4";
- regulator-min-microvolt = <110>;
- regulator-max-microvolt = <110>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo1_reg: ldo1 {
- regulator-name = "VDDSHV_SD_IO_PMIC";
- regulator-min-microvolt = <3300>;
- regulator-max-microvolt = <3300>;
- };
-
- ldo2_reg: ldo2 {
- regulator-name = "VDDAR_CORE";
- regulator-min-microvolt = <85>;
- regulator-max-microvolt = <85>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo3_reg: ldo3 {
- regulator-name = "VDDA_1V8";
- regulator-min-microvolt = <1800>;
- regulator-max-microvolt = <1800>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo4_reg: ldo4 {
- regulator-name = "VDD_PHY_2V5";
- regulator-min-microvolt = <2500>;
- regulator-max-microvolt = <2500>;
- regulator-boot-on;
- regulator-always-on;
- };
- };
- };
};
_uart0 {
--
2.40.0
[PATCH 09/23] arm: dts: k3-am642-sk-u-boot: Mark main_uart0 to be used for spl
we need to configure the pinmux for main_uart0 to get console
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 57797a59e05d..122a304d4501 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -48,6 +48,10 @@
bootph-pre-ram;
};
+_uart0_pins_default {
+ bootph-pre-ram;
+};
+
_uart0 {
bootph-pre-ram;
};
--
2.40.0
[PATCH 16/23] arm: dts: k3-am642-evm: Add main_i2c0 and eeprom
Add missing main_i2c0 node and eeprom property.
This is a pending upstream kernel updates as of v6.3-rc6.
Signed-off-by: Nishanth Menon
---
Sent to kernel.org
https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/
arch/arm/dts/k3-am642-evm.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
index 9cc271d9a22a..c20215b68d8f 100644
--- a/arch/arm/dts/k3-am642-evm.dts
+++ b/arch/arm/dts/k3-am642-evm.dts
@@ -258,6 +258,14 @@
>;
};
+ /* XXX: Upstream kernel TODO: send upstream pinmux */
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
I2C0_SCL */
+ AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
I2C0_SDA */
+ >;
+ };
+
main_i2c1_pins_default: main-i2c1-pins-default {
pinctrl-single,pins = <
AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18)
I2C1_SCL */
@@ -370,6 +378,20 @@
pinctrl-0 = <_uart1_pins_default>;
};
+/* XXX: Upstream kernel TODO: send upstream pinmux */
+_i2c0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c0_pins_default>;
+ clock-frequency = <40>;
+
+ eeprom@50 {
+ /* AT24CM01 */
+ compatible = "atmel,24c1024";
+ reg = <0x50>;
+ };
+};
+
_i2c1 {
status = "okay";
pinctrl-names = "default";
--
2.40.0
[PATCH 08/23] arm: dts: k3-am642-sk-u-boot: Drop redundant usb dr_mode property
We do not need that property to be defined as it is already defined in
am642-sk.dts
Signed-off-by: Nishanth Menon
---
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index aa3551c2bb4a..57797a59e05d 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -152,7 +152,6 @@
};
{
- dr_mode = "host";
bootph-pre-ram;
};
--
2.40.0
[PATCH 00/23] arm: dts: k3-am64: Sync with kernel.org and
Hi, This is a bit painful series, so apologies in advance for the patchbomb. I did'nt see any clean way to do this, so here goes. First: there are dts mismatches and overrides being done in u-boot in varied manner that should have been submitted to kernel.org in the first place, so, https://lore.kernel.org/linux-devicetree/20230414073328.381336-1...@ti.com/ This series picks some of those nodes up and marks them so that merge is a lot more logical. There are still stuff like esm and cpsw that will need a little more work. This series cleans up the dt, switches to .env mode and finally defaults to distroboot with none of the fancy stuff. I have tried to maintain bisectability, but the r5-sk stuff is a bit too broken for me to succeed cleanly.. but it did'nt make sense to confuse review by squashing everything up. Let me know if there is a better bisect option, and I can try. Logs are available: (including a log with the last two patches applied for distoboot default) https://gist.github.com/nmenon/6b09f55251225d3f3cce076c32a33bba Tested along with the ethernet fixup I had sent earlier: https://lore.kernel.org/u-boot/20230414042433.3436425-1...@ti.com/ Baseline for these patches: 9e804638bfe2 Merge tag 'for-v2023-07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-i2c Nishanth Menon (23): Revert "ARM: dts: k3-am642-sk-u-boot: add PMIC node" arm: dts: k3-am64: Update devicetree to sync with v6.3-rc6 arm: dts: k3-am642-sk: Add a note to handle pinmux till MDIO DM conversion is done arm: dts: k3-am642-sk: Fix mmc1 pinmux pull polarity arm: dts: k3-am642-sk: Add main_uart1 description arm: dts: k3-am642-sk: Add main_i2c0 and eeprom arm: dts: k3-am642-sk-u-boot: Drop the i2c node arm: dts: k3-am642-sk-u-boot: Drop redundant usb dr_mode property arm: dts: k3-am642-sk-u-boot: Mark main_uart0 to be used for spl arm: dts: k3-am642-sk-u-boot: Document timer as missing upstream arm: dts: k3-am642-sk-u-boot: Drop aliases and stdout arm: dts: k3-am642-r5-sk: Use am642-sk.dts and k3-am642-sk-u-boot.dtsi arm: dts: k3-am642-evm: Move the mdio pinmux down to evm.dts arm: dts: k3-am642-evm: Add DDR vtt regulator arm: dts: k3-am642-evm: Add main_uart1 description arm: dts: k3-am642-evm: Add main_i2c0 and eeprom arm: dts: k3-am642-evm-u-boot: Drop the i2c node arm: dts: k3-am642-evm-u-boot: Drop stdout and cosmetic fixups arm: dts: k3-am642-evm-u-boot: Re-organize the pinmux arm: dts: k3-am642-evm-u-boot: Add missing pinmux notations arm: dts: k3-am642-r5-evm: Use am642-evm.dts and k3-am642-evm-u-boot.dtsi include: configs: am64x_evm: Change to using .env configs: am64x_evm_a53_defconfig: Just use distroboot arch/arm/dts/k3-am642-evm-u-boot.dtsi | 52 --- arch/arm/dts/k3-am642-evm.dts | 60 +++- arch/arm/dts/k3-am642-r5-evm.dts | 203 -- arch/arm/dts/k3-am642-r5-sk.dts | 194 +++- arch/arm/dts/k3-am642-sk-u-boot.dtsi | 89 ++- arch/arm/dts/k3-am642-sk.dts | 54 ++- arch/arm/dts/k3-am642.dtsi| 1 + board/ti/am64x/Kconfig| 3 + board/ti/am64x/am64x.env | 37 + configs/am64x_evm_a53_defconfig | 2 +- include/configs/am64x_evm.h | 117 --- 11 files changed, 266 insertions(+), 546 deletions(-) create mode 100644 board/ti/am64x/am64x.env -- 2.40.0
Re: [PATCH 2/2] reset: rockchip: implement rk3588 lookup table
+ Heiko and Elaine,
Hi Eugen,
On 2023/4/13 19:36, Eugen Hristev wrote:
The current DT bindings for the rk3588 clock use a different ID than the
one that is supposed to be written to the hardware registers.
Thus, we cannot use directly the id provided in the phandle, but rather
use a lookup table to correctly setup the hardware.
This approach has been implemented already in Linux, by commit :
f1c506d152ff ("clk: rockchip: add clock controller for the RK3588")
Hence, implement a similar approach using the lookup table, and adapt
the existing reset driver to work with SoCs using lookup table.
The file rst-rk3588.c has been copied as much as possible from Linux.
I didn't follow the kernel closely, I'm not sure if there have any
discussion on this,
but I think we can reuse the generic reset driver
"drivers/reset/reset-rockchip.c"
as we have done for all other SoCs, but not add a new file for rk3588
and more for
other SoCs. What we need to do is update the ID with encode version in
the header
file like rockchip vendorkernel/U-Boot.
Thanks,
- Kever
Adapt the clk rk3588 driver as well to bind the reset driver with the
lookup table.
Signed-off-by: Eugen Hristev
---
arch/arm/include/asm/arch-rockchip/clock.h | 21 +
drivers/clk/rockchip/clk_rk3588.c | 2 +-
drivers/reset/Makefile | 2 +-
drivers/reset/reset-rockchip.c | 46 +-
drivers/reset/rst-rk3588.c | 854 +
5 files changed, 912 insertions(+), 13 deletions(-)
create mode 100644 drivers/reset/rst-rk3588.c
diff --git a/arch/arm/include/asm/arch-rockchip/clock.h
b/arch/arm/include/asm/arch-rockchip/clock.h
index f002ebcb7ac1..f01c5aeb71cb 100644
--- a/arch/arm/include/asm/arch-rockchip/clock.h
+++ b/arch/arm/include/asm/arch-rockchip/clock.h
@@ -194,5 +194,26 @@ int rockchip_get_clk(struct udevice **devp);
* Return: 0 success, or error value
*/
int rockchip_reset_bind(struct udevice *pdev, u32 reg_offset, u32 reg_number);
+/*
+ * rockchip_reset_bind_lut() - Bind soft reset device as child of clock device
+ *using a dedicated SoC lookup table
+ * @pdev: clock udevice
+ * @lookup_table: register lookup_table dedicated to SoC
+ * @reg_offset: the first offset in cru for softreset registers
+ * @reg_number: the reg numbers of softreset registers
+ * Return: 0 success, or error value
+ */
+int rockchip_reset_bind_lut(struct udevice *pdev, const int *lookup_table,
+ u32 reg_offset, u32 reg_number);
+/*
+ * rk3588_reset_bind_lut() - Bind soft reset device as child of clock device
+ * using dedicated RK3588 lookup table
+ *
+ * @pdev: clock udevice
+ * @reg_offset: the first offset in cru for softreset registers
+ * @reg_number: the reg numbers of softreset registers
+ * Return: 0 success, or error value
+ */
+int rk3588_reset_bind_lut(struct udevice *pdev, u32 reg_offset, u32
reg_number);
#endif
diff --git a/drivers/clk/rockchip/clk_rk3588.c
b/drivers/clk/rockchip/clk_rk3588.c
index c93c9c304d40..f972aa93d717 100644
--- a/drivers/clk/rockchip/clk_rk3588.c
+++ b/drivers/clk/rockchip/clk_rk3588.c
@@ -1994,7 +1994,7 @@ static int rk3588_clk_bind(struct udevice *dev)
#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)
ret = offsetof(struct rk3588_cru, softrst_con[0]);
- ret = rockchip_reset_bind(dev, ret, 49158);
+ ret = rk3588_reset_bind_lut(dev, ret, 49158);
if (ret)
debug("Warning: software reset driver bind faile\n");
#endif
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 6c8b45ecbabf..163022eb0be1 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
obj-$(CONFIG_RESET_AST2500) += reset-ast2500.o
obj-$(CONFIG_RESET_AST2600) += reset-ast2600.o
-obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o
+obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o rst-rk3588.o
obj-$(CONFIG_RESET_MESON) += reset-meson.o
obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_RESET_MEDIATEK) += reset-mediatek.o
diff --git a/drivers/reset/reset-rockchip.c b/drivers/reset/reset-rockchip.c
index e0a95edd80ac..be256bf032b2 100644
--- a/drivers/reset/reset-rockchip.c
+++ b/drivers/reset/reset-rockchip.c
@@ -21,6 +21,7 @@
struct rockchip_reset_priv {
void __iomem *base;
+ const int *lut;
/* Rockchip reset reg locate at cru controller */
u32 reset_reg_offset;
/* Rockchip reset reg number */
@@ -30,11 +31,15 @@ struct rockchip_reset_priv {
static int rockchip_reset_request(struct reset_ctl *reset_ctl)
{
struct rockchip_reset_priv *priv = dev_get_priv(reset_ctl->dev);
+ unsigned long id = reset_ctl->id;
+
+ if (priv->lut)
+ id = priv->lut[id];
debug("%s(reset_ctl=%p) (dev=%p, id=%lu) (reg_num=%d)\n", __func__,
Re: [PATCH] mtd: cfi: respect reg address length
Hi Nuno,
On 3/27/23 15:22, Nuno Sá wrote:
flash_get_size() will get the flash size from the device itself and go
through all erase regions to read protection status. However, the device
mappable region (eg: devicetree reg property) might be lower than the
device full size which means that the above cycle will result in a data
bus exception. This change fixes it by reading the 'addr_size' during
probe() and also use that as one possible upper limit.
Signed-off-by: Nuno Sá
---
To give a bit more of background for this patch, I caught this issue
when running u-boot on microblaze which uses xilinx axi_linear_flash IP.
On ADI designs using that IP, the flash size was set to 32MiB resulting
in the mentioned data bus exception as we obviously access past the
IP size.
That said, there was not real reason for the flash truncation so we'll
be fixing our designs so the IP will contemplate the complete flash
size.
For the above reason, I was not really sure to mark the patch as RFC or
not... Anyways, it still feels like a valid "protection" to have rather
then just aborting (even if it does not really make sense to ever
truncate the flash in devicetree).
drivers/mtd/cfi_flash.c | 10 --
include/flash.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index f378f6fb6139..432d0d5c9ecb 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -2196,7 +2196,11 @@ ulong flash_get_size(phys_addr_t base, int banknum)
/* multiply the size by the number of chips */
info->size *= size_ratio;
max_size = cfi_flash_bank_size(banknum);
- if (max_size && info->size > max_size) {
+ if (max_size)
+ max_size = min(info->addr_size, max_size);
+ else
+ max_size = info->addr_size;
+ if (info->size > max_size) {
debug("[truncated from %ldMiB]", info->size >> 20);
info->size = max_size;
}
@@ -2492,15 +2496,17 @@ unsigned long flash_init(void)
static int cfi_flash_probe(struct udevice *dev)
{
fdt_addr_t addr;
+ fdt_size_t size;
int idx;
for (idx = 0; idx < CFI_MAX_FLASH_BANKS; idx++) {
- addr = dev_read_addr_index(dev, idx);
+ addr = dev_read_addr_size_index(dev, idx, );
if (addr == FDT_ADDR_T_NONE)
break;
flash_info[cfi_flash_num_flash_banks].dev = dev;
flash_info[cfi_flash_num_flash_banks].base = addr;
+ flash_info[cfi_flash_num_flash_banks].addr_size = size;
cfi_flash_num_flash_banks++;
}
gd->bd->bi_flashstart = flash_info[0].base;
diff --git a/include/flash.h b/include/flash.h
index 95992fa689bb..3710a2731b76 100644
--- a/include/flash.h
+++ b/include/flash.h
@@ -46,6 +46,7 @@ typedef struct {
#ifdef CONFIG_CFI_FLASH /* DM-specific parts */
struct udevice *dev;
phys_addr_t base;
+ phys_size_t addr_size;
#endif
} flash_info_t;
Running a CI world build leads to many errors. Here an example:
$ make integratorcp_cm926ejs_defconfig
$ make -sj
In file included from include/linux/bitops.h:22,
from include/log.h:15,
from include/linux/printk.h:4,
from include/common.h:20,
from drivers/mtd/cfi_flash.c:19:
drivers/mtd/cfi_flash.c: In function 'flash_get_size':
drivers/mtd/cfi_flash.c:2200:44: error: 'flash_info_t' has no member
named 'addr_size'
2200 | max_size = min(info->addr_size, max_size);
|^~
include/linux/kernel.h:182:16: note: in definition of macro 'min'
182 | typeof(x) _min1 = (x); \
|^
drivers/mtd/cfi_flash.c:2200:44: error: 'flash_info_t' has no member
named 'addr_size'
2200 | max_size = min(info->addr_size, max_size);
|^~
include/linux/kernel.h:182:28: note: in definition of macro 'min'
182 | typeof(x) _min1 = (x); \
|^
include/linux/kernel.h:184:24: warning: comparison of distinct pointer
types lacks a cast
184 | (void) (&_min1 == &_min2); \
|^~
drivers/mtd/cfi_flash.c:2200:36: note: in expansion of macro 'min'
2200 | max_size = min(info->addr_size, max_size);
|^~~
drivers/mtd/cfi_flash.c:2202:40: error: 'flash_info_t' has no member
named 'addr_size'
2202 | max_size = info->addr_size;
|^~
make[2]: *** [scripts/Makefile.build:257: drivers/mtd/cfi_flash.o] Error 1
make[1]: ***
Re: [PATCH v2 2/3] colibri-imx7: specify MTD partitions on command line
Hello Stefano, On Mon, Feb 06, 2023 at 11:48:37PM +0100, Francesco Dolcini wrote: > From: Francesco Dolcini > > Disable fdt_fixup_mtdparts() and pass MTD partition on the command > line. Dynamically editing the fdt with a static partitions configuration > is not required and there is no advantages compared to using the command > line. This change should prevent boot failures as the one in [0]. > > Cc: Marek Vasut > Cc: Miquel Raynal > Link: > https://lore.kernel.org/all/y4dgbtgnwpm6s...@francesco-nb.int.toradex.com/ [0] > Link: https://lore.kernel.org/all/20230105123334.7f90c289@xps-13/ > Signed-off-by: Francesco Dolcini > --- > v2: > - improved commit message > - removed dead code > --- > board/toradex/colibri_imx7/colibri_imx7.c | 10 -- > configs/colibri_imx7_defconfig| 1 - > include/configs/colibri_imx7.h| 2 +- > 3 files changed, 1 insertion(+), 12 deletions(-) On Mon, Feb 06, 2023 at 11:48:38PM +0100, Francesco Dolcini wrote: > From: Francesco Dolcini > > Disable fdt_fixup_mtdparts() and pass MTD partition on the command > line. Dynamically editing the fdt with a static partitions configuration > is not required and there is no advantages compared to using the command > line. This change should prevent boot failures as the one in [0]. > > Cc: Marek Vasut > Cc: Miquel Raynal > Link: > https://lore.kernel.org/all/y4dgbtgnwpm6s...@francesco-nb.int.toradex.com/ [0] > Link: https://lore.kernel.org/all/20230105123334.7f90c289@xps-13/ > Signed-off-by: Francesco Dolcini Stefano: Can you pick those two patches? Or someone else should pick those? Thanks, Francesco
Re: [PATCH v2 1/3] fdt: validate/fix cells count on mtdpart fixup
On Thu, Apr 06, 2023 at 11:25:27AM -0400, Tom Rini wrote: > On Tue, Apr 04, 2023 at 06:18:03PM +0200, Francesco Dolcini wrote: > > +Stefano > > > > On Mon, Feb 06, 2023 at 06:17:31PM -0500, Tom Rini wrote: > > > On Mon, Feb 06, 2023 at 11:48:36PM +0100, Francesco Dolcini wrote: > > > > > > > From: Francesco Dolcini > > > > > > > > Fixup #size-cells value when updating the MTD partitions, this is > > > > required to prevent issues in case the MTD parent set #size-cells to > > > > zero. > > > > This could happen for example in the legacy case in which the partitions > > > > are created as direct child of the mtd node and that specific node has > > > > no children. Recent clean-up on Linux device tree files created a boot > > > > regression on colibri-imx7 [0]. > > > > > > > > This fixup has the limitation to assume 32-bit (#size-cells=1) > > > > addressing, therefore it will not work with device bigger than 4GiB. > > > > > > > > This change also enforce #address-cells to be the same as #size-cells, > > > > this was already silently enforced by fdt_node_set_part_info(), now this > > > > is checked explicitly and partition fixup will just fail in such case. > > > > > > > > When the partition list is static the preferred way to pass the mtd > > > > partition list to the kernel is to either define those in the source DTS > > > > file or use mtdparts= in the command line. > > > > Tweaking the DT from U-Boot should be avoided, unless some dynamic > > > > changes are required, since it proved to be problematic when not > > > > following the evolution of the "standard". > > > > > > > > Link: > > > > https://lore.kernel.org/all/y4dgbtgnwpm6s...@francesco-nb.int.toradex.com/ > > > > Link: > > > > https://lore.kernel.org/all/20221202071900.1143950-1-france...@dolcini.it/ > > > > Cc: Marek Vasut > > > > Cc: Miquel Raynal > > > > Signed-off-by: Francesco Dolcini > > > > --- > > > > v2: improved commit message > > > > --- > > > > common/fdt_support.c | 45 ++-- > > > > 1 file changed, 35 insertions(+), 10 deletions(-) > > > > > > I'm dropping the linux-mtd list here and adding a bunch more platform > > > maintainers. In general, calling fdt_fixup_mtdparts is the wrong choice. > > > I see we do have a few cases in U-Boot where we're clearly doing > > > something dynamic to the partition table, but it looks like at first > > > glance most callers are using this hook when they should either be > > > having the partition map in the device tree properly (and using one of > > > the appropriate bindings) or passing the map in via the kernel command > > > line. I would like to ask everyone I've added to the list here to > > > please audit your platform and update it as needed. Thanks! > > > > Hello Tom, > > what should we do with this patch? No feedback so far, apart this email > > from you. > > > > Stefano: maybe you can pick patches 2 and 3 ? > > I thought someone chimed in for the STM32 side? Whoops, yes, I remember the same. However, what about this patch, do we want to merge it? It solves a potential issue and from what I can tell it does not introduce new one. Francesco
Please pull u-boot-marvell/master
Hi Tom, please pull the following Marvell MVEBU related patches: - mvebu: Boot support for 4K Native disks (Pali) - a38x: Perform DDR training sequence again for 2nd boot (Tony) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=292=results Thanks, Stefan The following changes since commit 9e804638bfe2693a908abf066ff66c251572afa7: Merge tag 'for-v2023-07-rc1' of https://source.denx.de/u-boot/custodians/u-boot-i2c (2023-04-11 09:29:28 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 6add83991b2887619d0b25e4068b4c0082a4596a: ddr: marvell: a38x: Perform DDR training sequence again for 2nd boot (2023-04-13 11:34:47 +0200) Pali Rohár (7): arm: mvebu: spl: Do not hardcode SATA block size to 512 cmd: mvebu/bubt: a38x: Do not hardcode SATA block size to 512 tools: imagetool: Extend print_header() by params argument tools: kwbimage: Simplify align code tools: kwbimage: Add support for SATA images with non-512 byte block size tools: kwboot: Add support for parsing SATA images with non-512 block size arm: mvebu: spl: Allow to build SATA kwbimage for 4K Native disks Tony Dinh (1): ddr: marvell: a38x: Perform DDR training sequence again for 2nd boot arch/arm/mach-mvebu/Kconfig| 10 +++ arch/arm/mach-mvebu/Makefile | 5 ++ arch/arm/mach-mvebu/kwbimage.cfg.in| 3 + arch/arm/mach-mvebu/spl.c | 11 ++- cmd/mvebu/bubt.c | 7 +- drivers/ddr/marvell/a38x/mv_ddr_plat.c | 7 -- tools/aisimage.c | 2 +- tools/atmelimage.c | 2 +- tools/default_image.c | 7 +- tools/fit_common.c | 5 ++ tools/fit_common.h | 2 + tools/fit_image.c | 2 +- tools/gpimage.c| 2 +- tools/imagetool.c | 4 +- tools/imagetool.h | 2 +- tools/imx8image.c | 2 +- tools/imx8mimage.c | 2 +- tools/imximage.c | 2 +- tools/kwbimage.c | 144 + tools/kwboot.c | 35 +++- tools/lpc32xximage.c | 2 +- tools/mkimage.c| 2 +- tools/mtk_image.c | 2 +- tools/mxsimage.c | 2 +- tools/omapimage.c | 2 +- tools/pblimage.c | 2 +- tools/rkcommon.c | 2 +- tools/rkcommon.h | 2 +- tools/socfpgaimage.c | 2 +- tools/stm32image.c | 2 +- tools/sunxi_egon.c | 2 +- tools/sunxi_toc0.c | 2 +- tools/ublimage.c | 2 +- tools/vybridimage.c| 2 +- tools/zynqimage.c | 2 +- tools/zynqmpimage.c| 2 +- tools/zynqmpimage.h| 2 +- 37 files changed, 199 insertions(+), 91 deletions(-)
Re: [PATCH] ddr: marvell: a38x: Perform DDR training sequence again for 2nd boot
On 4/3/23 06:42, Tony Dinh wrote:
- DDR Training sequence happens very fast. The speedup in boot time is
negligible by skipping the training sequence during 2nd boot or after.
So remove the check and skip.
- This change improves the robustness of DDR training. If u-boot crashed
during DDR training, the training could be left in a limbo state, where
the BootROM has recorded that it is already in a 2nd boot. The training
must be repeated in this scenario to get out of this limbo state, but due
to the check it cannot be performed.
Signed-off-by: Tony Dinh
Applied to u-boot-marvell/master
Thanks,
Stefan
---
drivers/ddr/marvell/a38x/mv_ddr_plat.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
index 6e7949ac72..8ec9fb0874 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
@@ -1363,13 +1363,6 @@ int mv_ddr_pre_training_soc_config(const char *ddr_type)
DRAM_RESET_MASK_MASKED << DRAM_RESET_MASK_OFFS);
}
- /* Check if DRAM is already initialized */
- if (reg_read(REG_BOOTROM_ROUTINE_ADDR) &
- (1 << REG_BOOTROM_ROUTINE_DRAM_INIT_OFFS)) {
- printf("%s Training Sequence - 2nd boot - Skip\n", ddr_type);
- return MV_OK;
- }
-
/* Fix read ready phases for all SOC in reg 0x15c8 */
reg_val = reg_read(TRAINING_DBG_3_REG);
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
