[PATCH 8/8] configs: am64x_evm_r5/a53_defconfig: Enable configs required for Ethboot
Enable config options needed to support Ethernet boot on AM64x SK.
Signed-off-by: Vignesh Raghavendra
---
configs/am64x_evm_a53_defconfig | 4
configs/am64x_evm_r5_defconfig | 12
2 files changed, 16 insertions(+)
diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index aafbb410b6..b8add31a30 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -28,6 +28,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
CONFIG_BOARD_LATE_INIT=y
+CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_STACK_R=y
CONFIG_SPL_SEPARATE_BSS=y
@@ -36,8 +37,11 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
CONFIG_SPL_DMA=y
CONFIG_SPL_ENV_SUPPORT=y
CONFIG_SPL_I2C=y
+CONFIG_SPL_ETH=y
CONFIG_SPL_DM_MAILBOX=y
CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_NET=y
+CONFIG_SPL_NET_VCI_STRING="AM64X U-Boot A53 SPL"
CONFIG_SPL_POWER_DOMAIN=y
CONFIG_SPL_RAM_SUPPORT=y
CONFIG_SPL_RAM_DEVICE=y
diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig
index f564fa064e..01c1bc02ae 100644
--- a/configs/am64x_evm_r5_defconfig
+++ b/configs/am64x_evm_r5_defconfig
@@ -36,10 +36,14 @@ CONFIG_SPL_SEPARATE_BSS=y
CONFIG_SPL_EARLY_BSS=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SPL_DMA=y
CONFIG_SPL_ENV_SUPPORT=y
CONFIG_SPL_I2C=y
+CONFIG_SPL_ETH=y
CONFIG_SPL_DM_MAILBOX=y
CONFIG_SPL_DM_SPI_FLASH=y
+CONFIG_SPL_NET=y
+CONFIG_SPL_NET_VCI_STRING="AM64X U-Boot R5 SPL"
CONFIG_SPL_DM_RESET=y
CONFIG_SPL_POWER_DOMAIN=y
CONFIG_SPL_RAM_SUPPORT=y
@@ -61,6 +65,7 @@ CONFIG_CMD_REMOTEPROC=y
CONFIG_CMD_USB=y
CONFIG_CMD_USB_MASS_STORAGE=y
# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
CONFIG_CMD_TIME=y
CONFIG_CMD_FAT=y
CONFIG_OF_CONTROL=y
@@ -84,12 +89,15 @@ CONFIG_DFU_MMC=y
CONFIG_DFU_RAM=y
CONFIG_DFU_SF=y
CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000
+CONFIG_DMA_CHANNELS=y
+CONFIG_TI_K3_NAVSS_UDMA=y
CONFIG_TI_SCI_PROTOCOL=y
CONFIG_DA8XX_GPIO=y
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_OMAP24XX=y
CONFIG_DM_MAILBOX=y
CONFIG_K3_SEC_PROXY=y
+CONFIG_SPL_MISC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_ADMA=y
CONFIG_SPL_MMC_SDHCI_ADMA=y
@@ -97,6 +105,9 @@ CONFIG_MMC_SDHCI_AM654=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_SPANSION=y
CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_PHY_TI_DP83867=y
+CONFIG_DM_ETH=y
+CONFIG_TI_AM65_CPSW_NUSS=y
CONFIG_PINCTRL=y
# CONFIG_PINCTRL_GENERIC is not set
CONFIG_SPL_PINCTRL=y
@@ -114,6 +125,7 @@ CONFIG_DM_RESET=y
CONFIG_RESET_TI_SCI=y
CONFIG_SPECIFY_CONSOLE_INDEX=y
CONFIG_DM_SERIAL=y
+CONFIG_SOC_TI=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_CADENCE_QSPI=y
--
2.34.1
[PATCH 7/8] ARM: dts: K3-am642-r5-sk: Enable Second CPSW port in R5/A53 SPL
Enable Second Ethernet port on which ROM support Ethboot.
Signed-off-by: Vignesh Raghavendra
---
arch/arm/dts/k3-am642-r5-sk.dts | 74
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 40 ++-
2 files changed, 113 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am642-r5-sk.dts b/arch/arm/dts/k3-am642-r5-sk.dts
index 79eff8259f..b4a0438449 100644
--- a/arch/arm/dts/k3-am642-r5-sk.dts
+++ b/arch/arm/dts/k3-am642-r5-sk.dts
@@ -5,6 +5,8 @@
/dts-v1/;
+#include
+#include
#include "k3-am642.dtsi"
#include "k3-am64-sk-lp4-1333MTs.dtsi"
#include "k3-am64-ddr.dtsi"
@@ -107,6 +109,47 @@
AM64X_IOPAD(0x029c, PIN_INPUT_PULLUP, 0)/*
(C20) MMC1_SDWP */
>;
};
+
+ mdio1_pins_default: mdio1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* (R2)
PRG0_PRU1_GPO19.MDIO0_MDC */
+ AM64X_IOPAD(0x01f8, PIN_INPUT, 4) /* (P5)
PRG0_PRU1_GPO18.MDIO0_MDIO */
+ >;
+ };
+
+ rgmii1_pins_default: rgmii1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x011c, PIN_INPUT, 4) /* (AA13)
PRG1_PRU1_GPO5.RGMII1_RD0 */
+ AM64X_IOPAD(0x0128, PIN_INPUT, 4) /* (U12)
PRG1_PRU1_GPO8.RGMII1_RD1 */
+ AM64X_IOPAD(0x0150, PIN_INPUT, 4) /* (Y13)
PRG1_PRU1_GPO18.RGMII1_RD2 */
+ AM64X_IOPAD(0x0154, PIN_INPUT, 4) /* (V12)
PRG1_PRU1_GPO19.RGMII1_RD3 */
+ AM64X_IOPAD(0x00d8, PIN_INPUT, 4) /* (W13)
PRG1_PRU0_GPO8.RGMII1_RXC */
+ AM64X_IOPAD(0x00cc, PIN_INPUT, 4) /* (V13)
PRG1_PRU0_GPO5.RGMII1_RX_CTL */
+ AM64X_IOPAD(0x0124, PIN_OUTPUT, 4) /* (V15)
PRG1_PRU1_GPO7.RGMII1_TD0 */
+ AM64X_IOPAD(0x012c, PIN_OUTPUT, 4) /* (V14)
PRG1_PRU1_GPO9.RGMII1_TD1 */
+ AM64X_IOPAD(0x0130, PIN_OUTPUT, 4) /* (W14)
PRG1_PRU1_GPO10.RGMII1_TD2 */
+ AM64X_IOPAD(0x014c, PIN_OUTPUT, 4) /* (AA14)
PRG1_PRU1_GPO17.RGMII1_TD3 */
+ AM64X_IOPAD(0x00e0, PIN_OUTPUT, 4) /* (U14)
PRG1_PRU0_GPO10.RGMII1_TXC */
+ AM64X_IOPAD(0x00dc, PIN_OUTPUT, 4) /* (U15)
PRG1_PRU0_GPO9.RGMII1_TX_CTL */
+ >;
+ };
+
+ rgmii2_pins_default: rgmii2-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0108, PIN_INPUT, 4) /* (W11)
PRG1_PRU1_GPO0.RGMII2_RD0 */
+ AM64X_IOPAD(0x010c, PIN_INPUT, 4) /* (V11)
PRG1_PRU1_GPO1.RGMII2_RD1 */
+ AM64X_IOPAD(0x0110, PIN_INPUT, 4) /* (AA12)
PRG1_PRU1_GPO2.RGMII2_RD2 */
+ AM64X_IOPAD(0x0114, PIN_INPUT, 4) /* (Y12)
PRG1_PRU1_GPO3.RGMII2_RD3 */
+ AM64X_IOPAD(0x0120, PIN_INPUT, 4) /* (U11)
PRG1_PRU1_GPO6.RGMII2_RXC */
+ AM64X_IOPAD(0x0118, PIN_INPUT, 4) /* (W12)
PRG1_PRU1_GPO4.RGMII2_RX_CTL */
+ AM64X_IOPAD(0x0134, PIN_OUTPUT, 4) /* (AA10)
PRG1_PRU1_GPO11.RGMII2_TD0 */
+ AM64X_IOPAD(0x0138, PIN_OUTPUT, 4) /* (V10)
PRG1_PRU1_GPO12.RGMII2_TD1 */
+ AM64X_IOPAD(0x013c, PIN_OUTPUT, 4) /* (U10)
PRG1_PRU1_GPO13.RGMII2_TD2 */
+ AM64X_IOPAD(0x0140, PIN_OUTPUT, 4) /* (AA11)
PRG1_PRU1_GPO14.RGMII2_TD3 */
+ AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y10)
PRG1_PRU1_GPO16.RGMII2_TXC */
+ AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
+ >;
+ };
};
{
@@ -142,4 +185,35 @@
pinctrl-0 = <_mmc1_pins_default>;
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default
+_pins_default
+_pins_default>;
+};
+
+_port1 {
+ phy-mode = "rgmii-rxid";
+ phy-handle = <_phy0>;
+};
+
+_port2 {
+ phy-mode = "rgmii-rxid";
+ phy-handle = <_phy1>;
+};
+
+_mdio {
+ cpsw3g_phy0: ethernet-phy@0 {
+ reg = <0>;
+ ti,rx-internal-delay = ;
+ ti,fifo-depth = ;
+ };
+
+ cpsw3g_phy1: ethernet-phy@1 {
+ reg = <1>;
+ ti,rx-internal-delay = ;
+ ti,fifo-depth = ;
+ };
+};
+
#include "k3-am642-sk-u-boot.dtsi"
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index efbcfb36e9..ade040e601 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -100,13 +100,51 @@
<0x0 0x43000200 0x0 0x8>;
reg-names = "cpsw_nuss", "mac_efuse";
/delete-property/ ranges;
+ u-boot,dm-spl;
cpsw-phy-sel@04044 {
compatible = "ti,am64-phy-gmii-sel";
reg = <0x0 0x43004044 0x0 0x8>;
+ u-boot,dm-spl;
+ };
+
+
[PATCH 6/8] configs: am64x_evm: set eth1 as boot interface
ROM supports boot from CPSW second port, therefore set eth1 boot
interface
Signed-off-by: Vignesh Raghavendra
---
include/configs/am64x_evm.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index 99624081c3..cd4b658e5f 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -33,7 +33,7 @@
* our memory footprint. The less we use for BSS the more we have available
* for everything else.
*/
-#define CONFIG_SPL_BSS_MAX_SIZE0x1000
+#define CONFIG_SPL_BSS_MAX_SIZE0xa000
/*
* Link BSS to be within SPL in a dedicated region located near the top of
* the MCU SRAM, this way making it available also before relocation. Note
@@ -64,6 +64,7 @@
"if test $fdtfile = undefined; then " \
"echo WARNING: Could not determine device tree to use;
fi; \0" \
"name_kern=Image\0" \
+ "ethact=eth0\0" \
"console=ttyS2,115200n8\0" \
"args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 " \
"${mtdparts}\0" \
@@ -140,4 +141,6 @@
#define CONFIG_SYS_USB_FAT_BOOT_PARTITION 1
+#define CONFIG_SPL_ETH_DEVICE "eth1"
+
#endif /* __CONFIG_AM642_EVM_H */
--
2.34.1
[PATCH 5/8] mach-k3: am64_spl: Alias Ethernet RGMII boot to CPGMAC
This is required to enables spl_net boot on AM64x Signed-off-by: Vignesh Raghavendra --- arch/arm/mach-k3/include/mach/am64_spl.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-k3/include/mach/am64_spl.h b/arch/arm/mach-k3/include/mach/am64_spl.h index 607b09c2e5..b4f396b2c0 100644 --- a/arch/arm/mach-k3/include/mach/am64_spl.h +++ b/arch/arm/mach-k3/include/mach/am64_spl.h @@ -12,6 +12,7 @@ #define BOOT_DEVICE_QSPI 0x02 #define BOOT_DEVICE_SPI0x03 #define BOOT_DEVICE_ETHERNET 0x04 +#define BOOT_DEVICE_CPGMAC 0x04 #define BOOT_DEVICE_ETHERNET_RGMII 0x04 #define BOOT_DEVICE_ETHERNET_RMII 0x05 #define BOOT_DEVICE_I2C0x06 -- 2.34.1
[PATCH 4/8] mach-k3: am642_init: Probe AM65 CPSW NUSS for R5/A53 SPL
In order to support Ethernet boot on AM64x, probe AM65 CPSW NUSS.
Signed-off-by: Vignesh Raghavendra
---
arch/arm/mach-k3/am642_init.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index 533905daeb..184f1a2761 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -196,6 +196,13 @@ void board_init_f(ulong dummy)
if (ret)
panic("DRAM init failed: %d\n", ret);
#endif
+ if (IS_ENABLED(CONFIG_SPL_ETH) && IS_ENABLED(CONFIG_TI_AM65_CPSW_NUSS)
&&
+ spl_boot_device() == BOOT_DEVICE_ETHERNET) {
+ struct udevice *cpswdev;
+
+ if (uclass_get_device_by_driver(UCLASS_MISC,
DM_DRIVER_GET(am65_cpsw_nuss), ))
+ printf("Failed to probe am65_cpsw_nuss driver\n");
+ }
}
u32 spl_mmc_boot_mode(const u32 boot_device)
--
2.34.1
[PATCH 3/8] board: ti: am64x: Init DRAM size in R5/A53 SPL
Call dram_init_banksize() from spl_board_init() otherwise TFTP download fails due to lmb_get_free_size() not able to find unreserved region due to lack of DRAM size info. Required to support Ethernet boot on AM64x. Signed-off-by: Vignesh Raghavendra --- board/ti/am64x/evm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c index 1a9f69c6cf..8373c768f1 100644 --- a/board/ti/am64x/evm.c +++ b/board/ti/am64x/evm.c @@ -196,5 +196,8 @@ void spl_board_init(void) val = readl(CTRLMMR_USB0_PHY_CTRL); val &= ~(CORE_VOLTAGE); writel(val, CTRLMMR_USB0_PHY_CTRL); + + /* Init DRAM size for R5/A53 SPL */ + dram_init_banksize(); } #endif -- 2.34.1
[PATCH 2/8] net: ti: am65-cpsw: Add support for multi port independent MAC mode
On certain TI SoC, like AM64x there is a CPSW3G which supports 2
external independent MAC ports for single CPSW instance.
It is not possible for Ethernet driver to register more than one port
for given instance.
This patch modifies top level CPSW NUSS as UCLASS_MISC and binds
UCLASS_ETH to individual ports so as to support bring up more than one
Ethernet interface in U-Boot.
Note that there is no isolation in the since, CPSW NUSS is in promisc
mode and forwards all packets to host.
Since top level driver is now UCLASS_MISC, board files would need to
instantiate this driver explicitly.
Signed-off-by: Vignesh Raghavendra
---
drivers/net/ti/Kconfig | 2 +
drivers/net/ti/am65-cpsw-nuss.c | 77 +
2 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index f2dbbd0128..59c96d862d 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -28,6 +28,8 @@ config DRIVER_TI_KEYSTONE_NET
config TI_AM65_CPSW_NUSS
bool "TI K3 AM65x MCU CPSW Nuss Ethernet controller driver"
depends on ARCH_K3
+ imply MISC_INIT_R
+ imply MISC
select PHYLIB
help
This driver supports TI K3 MCU CPSW Nuss Ethernet controller
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 3ab6a30828..6ae69b51c7 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -597,7 +597,7 @@ static int am65_cpsw_phy_init(struct udevice *dev)
return ret;
}
-static int am65_cpsw_ofdata_parse_phy(struct udevice *dev, ofnode port_np)
+static int am65_cpsw_ofdata_parse_phy(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_plat(dev);
struct am65_cpsw_priv *priv = dev_get_priv(dev);
@@ -605,7 +605,9 @@ static int am65_cpsw_ofdata_parse_phy(struct udevice *dev,
ofnode port_np)
const char *phy_mode;
int ret = 0;
- phy_mode = ofnode_read_string(port_np, "phy-mode");
+ dev_read_u32(dev, "reg", >port_id);
+
+ phy_mode = dev_read_string(dev, "phy-mode");
if (phy_mode) {
pdata->phy_interface =
phy_get_interface_by_name(phy_mode);
@@ -617,13 +619,13 @@ static int am65_cpsw_ofdata_parse_phy(struct udevice
*dev, ofnode port_np)
}
}
- ofnode_read_u32(port_np, "max-speed", (u32 *)>max_speed);
+ dev_read_u32(dev, "max-speed", (u32 *)>max_speed);
if (pdata->max_speed)
dev_err(dev, "Port %u speed froced to %uMbit\n",
priv->port_id, pdata->max_speed);
priv->has_phy = true;
- ret = ofnode_parse_phandle_with_args(port_np, "phy-handle",
+ ret = ofnode_parse_phandle_with_args(dev_ofnode(dev), "phy-handle",
NULL, 0, 0, _args);
if (ret) {
dev_err(dev, "can't parse phy-handle port %u (%d)\n",
@@ -646,21 +648,46 @@ out:
return ret;
}
-static int am65_cpsw_probe_cpsw(struct udevice *dev)
+static int am65_cpsw_port_probe(struct udevice *dev)
{
struct am65_cpsw_priv *priv = dev_get_priv(dev);
struct eth_pdata *pdata = dev_get_plat(dev);
struct am65_cpsw_common *cpsw_common;
- ofnode ports_np, node;
- int ret, i;
+ char portname[15];
+ int ret;
priv->dev = dev;
- cpsw_common = calloc(1, sizeof(*priv->cpsw_common));
- if (!cpsw_common)
- return -ENOMEM;
+ cpsw_common = dev_get_priv(dev->parent);
priv->cpsw_common = cpsw_common;
+ sprintf(portname, "%s%s", dev->parent->name, dev->name);
+ device_set_name(dev, portname);
+
+ ret = am65_cpsw_ofdata_parse_phy(dev);
+ if (ret)
+ goto out;
+
+ am65_cpsw_gmii_sel_k3(priv, pdata->phy_interface, priv->port_id);
+
+ ret = am65_cpsw_mdio_init(dev);
+ if (ret)
+ goto out;
+
+ ret = am65_cpsw_phy_init(dev);
+ if (ret)
+ goto out;
+out:
+ return ret;
+}
+
+static int am65_cpsw_probe_nuss(struct udevice *dev)
+{
+ struct am65_cpsw_common *cpsw_common = dev_get_priv(dev);
+ ofnode ports_np, node;
+ int ret, i;
+ struct udevice *port_dev;
+
cpsw_common->dev = dev;
cpsw_common->ss_base = dev_read_addr(dev);
if (cpsw_common->ss_base == FDT_ADDR_T_NONE)
@@ -723,10 +750,9 @@ static int am65_cpsw_probe_cpsw(struct udevice *dev)
if (disabled)
continue;
- priv->port_id = port_id;
- ret = am65_cpsw_ofdata_parse_phy(dev, node);
+ ret = device_bind_driver_to_node(dev, "am65_cpsw_nuss_port",
ofnode_get_name(node), node, _dev);
if (ret)
- goto out;
+ printf("SCREEEM\n");
}
for (i = 0; i < AM65_CPSW_CPSWNU_MAX_PORTS; i++) {
@@
[PATCH 1/8] mach-k3: common: Instantiate AM65 CPSW NUSS wrapper
Probe toplevel AM65 CPSW NUSS driver from misc_init_r() when driver
is enabled. Since driver is modeled as UCLASS_MISC, we need to
explicitly probe the driver. Use common misc_init_r() that entire
K3 family of SoCs.
Signed-off-by: Vignesh Raghavendra
---
arch/arm/mach-k3/common.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 2666cd2d7b..39d00270b7 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -549,3 +549,19 @@ void spl_board_prepare_for_linux(void)
dcache_disable();
}
#endif
+
+int misc_init_r(void)
+{
+ if (IS_ENABLED(CONFIG_TI_AM65_CPSW_NUSS)) {
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_DRIVER_GET(am65_cpsw_nuss),
+ );
+ if (ret)
+ printf("Failed to probe am65_cpsw_nuss driver\n");
+ }
+
+ return 0;
+}
--
2.34.1
[PATCH 0/8] ARM: ti: AM64x: Add Ethernet boot support on AM64x SK
This series enables ethernet boot support on AM64x SK. AM64x SoC has CPSW3g IP that supports 2 ext Eth port. ROM supports booting from 2nd port. But currently am65-cpsw-nuss only supports single port (1st port). So the first two patches modify driver to support more than 1 ext port. This is done by breaking up am65-cpsw-nuss into UCLASS_MISC for toplevel NUSS driver and UCLASS_ETH for each of individual ports. Next 4 patches add mach-k3 and board level changes to enable Ethernet and TFTP to work at SPL. Last two patches add dts and config changes need to for Ethernet boot. Tested on AM64x SK with RGMII 1G bootmode at 1G. https://controlc.com/90d555ee Sanity tested TFTP at U-Boot prompt on AM65x and J721e. Vignesh Raghavendra (8): mach-k3: common: Instantiate AM65 CPSW NUSS wrapper net: ti: am65-cpsw: Add support for multi port independent MAC mode board: ti: am64x: Init DRAM size in R5/A53 SPL mach-k3: am642_init: Probe AM65 CPSW NUSS for R5/A53 SPL mach-k3: am64_spl: Alias Ethernet RGMII boot to CPGMAC configs: am64x_evm: set eth1 as boot interface ARM: dts: K3-am642-r5-sk: Enable Second CPSW port in R5/A53 SPL configs: am64x_evm_r5/a53_defconfig: Enable configs required for Ethboot arch/arm/dts/k3-am642-r5-sk.dts | 74 +++ arch/arm/dts/k3-am642-sk-u-boot.dtsi | 40 +++- arch/arm/mach-k3/am642_init.c| 7 +++ arch/arm/mach-k3/common.c| 16 + arch/arm/mach-k3/include/mach/am64_spl.h | 1 + board/ti/am64x/evm.c | 3 + configs/am64x_evm_a53_defconfig | 4 ++ configs/am64x_evm_r5_defconfig | 12 drivers/net/ti/Kconfig | 2 + drivers/net/ti/am65-cpsw-nuss.c | 77 +++- include/configs/am64x_evm.h | 5 +- 11 files changed, 212 insertions(+), 29 deletions(-) -- 2.34.1
Re: [PATCH] configs: rock-pi-4: Enable rockchip efuse support
On 2021/11/26 上午3:52, Sjoerd Simons wrote: Enable efuse support for reading the cpuid#, serial# and generate a board unique mac address Signed-off-by: Sjoerd Simons Reviewed-by: Kever Yang Thanks, - Kever --- configs/rock-pi-4-rk3399_defconfig | 1 + configs/rock-pi-4c-rk3399_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index 9366eba8f15..032b9086699 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -31,6 +31,7 @@ CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y +CONFIG_ROCKCHIP_EFUSE=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_MMC_DW=y diff --git a/configs/rock-pi-4c-rk3399_defconfig b/configs/rock-pi-4c-rk3399_defconfig index ac045d1492f..6f5e8666b0d 100644 --- a/configs/rock-pi-4c-rk3399_defconfig +++ b/configs/rock-pi-4c-rk3399_defconfig @@ -31,6 +31,7 @@ CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y +CONFIG_ROCKCHIP_EFUSE=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_MMC_DW=y
Re: [PATCH] rockchip: boot_mode: fix fastboot command
On 2021/11/26 上午2:05, John Keeping wrote:
The USB controller index must be separated from the type argument,
otherwise the preboot command fails with the error:
Error: Wrong USB controller index format
Add the missing space to fix fastboot mode here.
Signed-off-by: John Keeping
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/mach-rockchip/boot_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/boot_mode.c
b/arch/arm/mach-rockchip/boot_mode.c
index 2158934159..1a1a887fc2 100644
--- a/arch/arm/mach-rockchip/boot_mode.c
+++ b/arch/arm/mach-rockchip/boot_mode.c
@@ -95,7 +95,7 @@ int setup_boot_mode(void)
switch (boot_mode) {
case BOOT_FASTBOOT:
debug("%s: enter fastboot!\n", __func__);
- env_set("preboot", "setenv preboot; fastboot usb0");
+ env_set("preboot", "setenv preboot; fastboot usb 0");
break;
case BOOT_UMS:
debug("%s: enter UMS!\n", __func__);
Re: [PATCH v2 4/4] rockchip: rk3399: Add support for chromebook_kevin
On 2021/12/14 上午6:15, Alper Nebi Yasak wrote:
From: "Marty E. Plummer"
Add support for Kevin, an RK3399-based convertible chromebook that is
very similar to Bob. This patch is mostly based on existing support for
Bob, with only minor changes for Kevin-specific things.
Unlike other Gru boards, coreboot sets Kevin's center logic to 925 mV,
so adjust it here in the dts as well. The rk3399-gru-kevin devicetree
has an unknown event code reference which has to be defined, set it
to the Linux counterpart. The new defconfig is copied from Bob with the
diffconfig:
DEFAULT_DEVICE_TREE "rk3399-gru-bob" -> "rk3399-gru-kevin"
DEFAULT_FDT_FILE "rockchip/rk3399-gru-bob.dtb" ->
"rockchip/rk3399-gru-kevin.dtb"
VIDEO_ROCKCHIP_MAX_XRES 1280 -> 2400
VIDEO_ROCKCHIP_MAX_YRES 800 -> 1600
+TARGET_CHROMEBOOK_KEVIN y
With this Kevin can boot from SPI flash to a usable U-Boot prompt on the
display with the keyboard working, but cannot boot into Linux for
unknown reasons.
eMMC starts in a working state but fails to re-init, microSD card works
but at a lower-than-expected speed, USB works but causes a hang on
de-init. There are known workarounds to solve eMMC and USB issues.
Cc: Marty E. Plummer
Cc: Simon Glass
[Alper: commit message, resync config with Bob, update MAINTAINERS,
add to Rockchip doc, add Kconfig help message, set regulator]
Co-developed-by: Alper Nebi Yasak
Signed-off-by: Alper Nebi Yasak
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Marty had signed-off an earlier version of this [1], but not the updated
version I continued on top of [2]. So I'm not sure if I can add his
sign-off to this as is, and I hope he can reply to this with a sign-off.
[1] https://patchwork.ozlabs.org/patch/1053386/
[2] https://patchwork.ozlabs.org/comment/2488899/
Changes in v2:
- Rebase on u-boot/next, fixing conflict in board_debug_uart_init()
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi | 11 ++
arch/arm/mach-rockchip/rk3399/Kconfig | 11 ++
arch/arm/mach-rockchip/rk3399/rk3399.c| 3 +-
arch/arm/mach-rockchip/spl.c | 3 +-
board/google/gru/Kconfig | 16 +++
board/google/gru/MAINTAINERS | 8 ++
board/google/gru/gru.c| 2 +-
configs/chromebook_kevin_defconfig| 116 ++
doc/board/rockchip/rockchip.rst | 1 +
include/dt-bindings/input/linux-event-codes.h | 3 +-
11 files changed, 171 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
create mode 100644 configs/chromebook_kevin_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7f622fedbda7..d6883994f21a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -132,6 +132,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-ficus.dtb \
rk3399-firefly.dtb \
rk3399-gru-bob.dtb \
+ rk3399-gru-kevin.dtb \
rk3399-khadas-edge.dtb \
rk3399-khadas-edge-captain.dtb \
rk3399-khadas-edge-v.dtb \
diff --git a/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
b/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
new file mode 100644
index ..c03bd48e95d7
--- /dev/null
+++ b/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki
+ */
+
+#include "rk3399-gru-u-boot.dtsi"
+#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"
+
+_centerlogic_pwm {
+ regulator-init-microvolt = <925000>;
+};
diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig
b/arch/arm/mach-rockchip/rk3399/Kconfig
index 17628f917127..0833e083d9ef 100644
--- a/arch/arm/mach-rockchip/rk3399/Kconfig
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -14,6 +14,17 @@ config TARGET_CHROMEBOOK_BOB
display. It includes a Chrome OS EC (Cortex-M3) to provide access to
the keyboard and battery functions.
+config TARGET_CHROMEBOOK_KEVIN
+ bool "Samsung Chromebook Plus (RK3399)"
+ select HAS_ROM
+ select ROCKCHIP_SPI_IMAGE
+ help
+ Kevin is a RK3399-based convertible chromebook. It has two USB 3.0
+ Type-C ports, 4GB of SDRAM, WiFi and a 12.3" 2400x1600 display. It
+ uses its USB ports for both power and external display. It includes
+ a Chromium OS EC (Cortex-M3) to provide access to the keyboard and
+ battery functions.
+
config TARGET_EVB_RK3399
bool "RK3399 evaluation board"
help
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index d40969c88898..01a05599cd0d 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -140,7 +140,8 @@ void board_debug_uart_init(void)
struct rockchip_gpio_regs * const gpio = (void *)GPIO0_BASE;
if (IS_ENABLED(CONFIG_SPL_BUILD) &&
-
Re: [PATCH v2 3/4] rockchip: bob: Enable more configs
On 2021/12/14 上午6:15, Alper Nebi Yasak wrote:
This patch enables some configs that should be working on the Bob board,
based on what is observed to work on the Kevin board.
The Bob board uses an Embedded DisplayPort panel compatible with the
simple panel and Rockchip eDP drivers. Its backlight is controlled by
the Chromium OS Embedded Controller Pulse Width Modulator. Enable these
for the board.
Also set VIDEO_ROCKCHIP_MAX_{XRES,YRES} to 1280x800, the resolution of
its panel. This had to be done for the Kevin board, but it's untested if
this is actually necessary for Bob.
The Rockchip video driver needs to assert/deassert some resets, so also
enable the reset controller. RESET_ROCKCHIP defaults to y for this board
when DM_RESET=y, so it's enough to set that.
The Bob board has two USB 3.0 Type-C ports and one USB 2.0 Type-A port
on its right side. Enable the configs relevant to USB devices so these
can be used. This is despite a known issue with RK3399 boards where USB
de-init causes a hang, as there is a known workaround.
Some other rk3399-based devices enable support for the SoC's random
number generator in commit a475bef5340c ("configs: rk3399: enable rng on
firefly/rock960/rockpro64"), as it can provide a KASLR seed when booting
using UEFI. Enable it for Bob as well.
The default misc_init_r() for Rockchip boards sets cpuid and ethernet
MAC address based on e-fuse block. A previous patch extends this on Gru
boards to set registers related to SoC IO domains as is necessary on
these boards. Enable this function and configs for it on Bob.
The eMMC on this board is capable of running at a HS400 Enhanced Strobe
configuration, and the microSD slot at Ultra High Speed SDR104. Enable
the configs for these as the hardware supports these modes. There are
problems causing the devices to run at lower speeds, but these configs
are enabled in hope that these will be solved later. Enabling ADMA
currently makes the eMMC stop working, so it is kept disabled.
The microSD card slot on this board (and others based on Gru) is
connected to a GPIO controlled regulator (ppvar-sd-card-io), which must
be operable by U-Boot. Enable the relevant config option to allow this.
Bob boards also use the Winbond W25Q64DW SPI flash chip, enable support
for Winbond SPI flash chips in the board config so U-Boot can boot with
this chip.
Signed-off-by: Alper Nebi Yasak
Reviewed-by: Kever Yang
Thanks,
- Kever
---
(no changes since v1)
configs/chromebook_bob_defconfig | 27 ++-
include/configs/gru.h| 3 +++
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index fe938c659172..048fa8e0c043 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -21,6 +21,7 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_R=y
+CONFIG_MISC_INIT_R=y
CONFIG_BLOBLIST=y
CONFIG_BLOBLIST_SIZE=0x1000
CONFIG_BLOBLIST_ADDR=0x10
@@ -52,26 +53,40 @@ CONFIG_ROCKCHIP_GPIO=y
CONFIG_I2C_CROS_EC_TUNNEL=y
CONFIG_SYS_I2C_ROCKCHIP=y
CONFIG_I2C_MUX=y
-CONFIG_DM_KEYBOARD=y
CONFIG_CROS_EC_KEYB=y
+CONFIG_MISC=y
+CONFIG_ROCKCHIP_EFUSE=y
CONFIG_CROS_EC=y
CONFIG_CROS_EC_SPI=y
CONFIG_PWRSEQ=y
CONFIG_MMC_PWRSEQ=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS400_ES_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
CONFIG_MMC_DW=y
CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
CONFIG_SF_DEFAULT_BUS=1
CONFIG_SF_DEFAULT_SPEED=2000
CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_WINBOND=y
CONFIG_DM_ETH=y
CONFIG_ETH_DESIGNWARE=y
CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_TYPEC=y
CONFIG_PMIC_RK8XX=y
CONFIG_REGULATOR_PWM=y
+CONFIG_DM_REGULATOR_GPIO=y
CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_CROS_EC=y
CONFIG_PWM_ROCKCHIP=y
+CONFIG_DM_RESET=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_ROCKCHIP=y
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_ROCKCHIP_SPI=y
CONFIG_SYSRESET=y
@@ -80,11 +95,21 @@ CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_DWC3=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_GENERIC=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_KEYBOARD=y
CONFIG_USB_HOST_ETHER=y
CONFIG_USB_ETHER_ASIX=y
CONFIG_USB_ETHER_ASIX88179=y
CONFIG_USB_ETHER_MCS7830=y
CONFIG_USB_ETHER_RTL8152=y
CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_DM_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_VIDEO_ROCKCHIP_MAX_XRES=1280
+CONFIG_VIDEO_ROCKCHIP_MAX_YRES=800
+CONFIG_DISPLAY_ROCKCHIP_EDP=y
CONFIG_CMD_DHRYSTONE=y
CONFIG_ERRNO_STR=y
diff --git a/include/configs/gru.h b/include/configs/gru.h
index be2dc79968c0..b1084bb21d4d 100644
--- a/include/configs/gru.h
+++ b/include/configs/gru.h
@@ -13,4 +13,7 @@
#include
+#define CONFIG_USB_OHCI_NEW
+#define
Re: [PATCH v2 2/4] rockchip: gru: Add more devicetree settings
On 2021/12/14 上午6:15, Alper Nebi Yasak wrote:
From: Simon Glass
This adds some devicetree settings for the Gru-based boards, based on
what works on a Kevin board.
Gru-based boards usually have an 8MiB SPI flash chip and boot from it.
Make the u-boot.rom file intended to be flashed on it match its size.
Add properties for booting from SPI, and only try to boot from SPI as
MMC and SD card don't seem to work in SPL yet.
The Chromium OS EC needs a delay between transactions so it can get
itself ready. Also it currently uses a non-standard way of specifying
the interrupt. Add these so that the EC works reliably.
The Rockchip Embedded DisplayPort driver is looking for a rockchip,panel
property to find the panel it should work on. Add the property for the
Gru-based boards.
The U-Boot GPIO controlled regulator driver only considers the
"enable-gpios" devicetree property, not the singular "enable-gpio" one.
Some devicetree source files have the singular form as they were added
to Linux kernel when it used that form, and imported to U-Boot as is.
Fix one instance of this in the Gru boards' devicetree to the form that
works in U-Boot.
The PWM controlled regulator driver complains that there is no init
voltage set for a regulator it drives, though it's not clear which one.
Set them all to the voltage levels coreboot sets them: 900 mV.
The RK3399 SoC needs to know the voltage level that some supplies
provides, including one fixed 1.8V audio-related regulator. Although
this synchronization is currently statically done in the board init
functions, a not-so-hypothetical driver that does this dynamically would
query the regulator only to get -ENODATA and be confused. Make sure
U-Boot knows this supply is at 1.8V by setting its limits to that.
Most of this is a reapplication of commit 08c85b57a5ec ("rockchip: gru:
Add extra device-tree settings") whose changes were removed during a
sync with Linux at commit 167efc2c7a46 ("arm64: dts: rk3399: Sync
v5.7-rc1 from Linux"). Apply things to rk3399-gru-u-boot.dtsi instead so
they don't get lost again.
Signed-off-by: Simon Glass
[Alper: move to -u-boot.dtsi, rewrite commit message, add more nodes]
Co-developed-by: Alper Nebi Yasak
Signed-off-by: Alper Nebi Yasak
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Kept sign-off and author as Simon based on the aforementioned commit.
(no changes since v1)
arch/arm/dts/rk3399-gru-u-boot.dtsi | 55 +
1 file changed, 55 insertions(+)
diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi
b/arch/arm/dts/rk3399-gru-u-boot.dtsi
index 390ac2bb5a9a..33734e99be50 100644
--- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
@@ -5,6 +5,61 @@
#include "rk3399-u-boot.dtsi"
+/ {
+ chosen {
+ u-boot,spl-boot-order = _flash;
+ };
+
+ config {
+ u-boot,spl-payload-offset = <0x4>;
+ };
+};
+
+ {
+ rom {
+ size = <0x80>;
+ };
+};
+
+_ec {
+ ec-interrupt = < RK_PA1 GPIO_ACTIVE_LOW>;
+};
+
+ {
+ rockchip,panel = <_panel>;
+};
+
+_audio {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+};
+
+_bigcpu_pwm {
+ regulator-init-microvolt = <90>;
+};
+
+_centerlogic_pwm {
+ regulator-init-microvolt = <90>;
+};
+
+_gpu_pwm {
+ regulator-init-microvolt = <90>;
+};
+
+_litcpu_pwm {
+ regulator-init-microvolt = <90>;
+};
+
+_sd_card_io {
+ enable-gpios = < 2 GPIO_ACTIVE_HIGH>;
+};
+
+ {
+ spi-activate-delay = <100>;
+ spi-max-frequency = <300>;
+ spi-deactivate-delay = <200>;
+};
+
_flash {
u-boot,dm-pre-reloc;
};
Re: [PATCH v2 1/4] rockchip: gru: Set up SoC IO domain registers
On 2021/12/14 上午6:15, Alper Nebi Yasak wrote:
The RK3399 SoC needs to know the voltage value provided by some
regulators, which is done by setting relevant register bits. Configure
these the way other RK3399 boards do, but with the same values as are
set in the equivalent code in coreboot.
Signed-off-by: Alper Nebi Yasak
Reviewed-by: Kever Yang
Thanks,
- Kever
---
There is a driver for this on Rockchip's repo, I managed to forward-port
it and get it working. If that's more desirable than doing it per-board
like this I can send that upstream (but I'd prefer to do it after this).
Changes in v2:
- Drop unnecessary ifdef.
- Clarify commit message regarding 'values set in coreboot'.
board/google/gru/gru.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c
index 23080c1798b7..cbf62a9427c9 100644
--- a/board/google/gru/gru.c
+++ b/board/google/gru/gru.c
@@ -6,6 +6,17 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GRF_IO_VSEL_BT656_SHIFT 0
+#define GRF_IO_VSEL_AUDIO_SHIFT 1
+#define PMUGRF_CON0_VSEL_SHIFT 8
+#define PMUGRF_CON0_VOL_SHIFT 9
#ifdef CONFIG_SPL_BUILD
/* provided to defeat compiler optimisation in board_init_f() */
@@ -54,3 +65,44 @@ int board_early_init_r(void)
return 0;
}
#endif
+
+static void setup_iodomain(void)
+{
+ struct rk3399_grf_regs *grf =
+ syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+ struct rk3399_pmugrf_regs *pmugrf =
+ syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
+
+ /* BT656 and audio is in 1.8v domain */
+ rk_setreg(>io_vsel, (1 << GRF_IO_VSEL_BT656_SHIFT |
+ 1 << GRF_IO_VSEL_AUDIO_SHIFT));
+
+ /*
+* Set GPIO1 1.8v/3.0v source select to PMU1830_VOL
+* and explicitly configure that PMU1830_VOL to be 1.8V
+*/
+ rk_setreg(>soc_con0, (1 << PMUGRF_CON0_VSEL_SHIFT |
+ 1 << PMUGRF_CON0_VOL_SHIFT));
+}
+
+int misc_init_r(void)
+{
+ const u32 cpuid_offset = 0x7;
+ const u32 cpuid_length = 0x10;
+ u8 cpuid[cpuid_length];
+ int ret;
+
+ setup_iodomain();
+
+ ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
+ if (ret)
+ return ret;
+
+ ret = rockchip_cpuid_set(cpuid, cpuid_length);
+ if (ret)
+ return ret;
+
+ ret = rockchip_setup_macaddr();
+
+ return ret;
+}
Re: [PATCH v2 3/3] engicam: px30: Add Engicam PX30.Core C.TOUCH 2.0 10.1" OF
On 2021/11/16 上午1:38, Jagan Teki wrote: PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. C.TOUCH 2.0 is a general purpose carrier board with capacitive touch interface support. 10.1" OF is a capacitive touch 10.1" Open Frame panel solutions. PX30.Core needs to mount on top of C.TOUCH 2.0 carrier with pluged 10.1" OF for creating complete PX30.Core C.TOUCH 2.0 10.1" Open Frame. Add support for it. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang Thanks, - Kever --- Changes for v2: - none arch/arm/dts/Makefile | 1 + arch/arm/mach-rockchip/px30/Kconfig | 8 ++ board/engicam/px30_core/MAINTAINERS | 6 + configs/px30-core-ctouch2-of10-px30_defconfig | 108 ++ 4 files changed, 123 insertions(+) create mode 100644 configs/px30-core-ctouch2-of10-px30_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 57a33d0bc4..95465d1dac 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -79,6 +79,7 @@ dtb-$(CONFIG_ROCKCHIP_PX30) += \ px30-evb.dtb \ px30-firefly.dtb \ px30-engicam-px30-core-ctouch2.dtb \ + px30-engicam-px30-core-ctouch2-of10.dtb \ px30-engicam-px30-core-edimm2.2.dtb \ rk3326-odroid-go2.dtb diff --git a/arch/arm/mach-rockchip/px30/Kconfig b/arch/arm/mach-rockchip/px30/Kconfig index aa5cc471ee..145bf3591f 100644 --- a/arch/arm/mach-rockchip/px30/Kconfig +++ b/arch/arm/mach-rockchip/px30/Kconfig @@ -27,6 +27,14 @@ config TARGET_PX30_CORE * PX30.Core needs to mount on top of CTOUCH2.0 for creating complete PX30.Core C.TOUCH Carrier board. + PX30.Core CTOUCH2-OF10: + * PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. + * CTOUCH2.0 is a general purpose Carrier board with capacitive + touch interface support. + * 10.1" OF is a capacitive touch 10.1" Open Frame panel solutions. + * PX30.Core needs to mount on top of C.TOUCH 2.0 carrier with pluged +10.1" OF for creating complete PX30.Core C.TOUCH 2.0 10.1" Open Frame. + config ROCKCHIP_BOOT_MODE_REG default 0xff010200 diff --git a/board/engicam/px30_core/MAINTAINERS b/board/engicam/px30_core/MAINTAINERS index b87ca22207..77f0c2dba5 100644 --- a/board/engicam/px30_core/MAINTAINERS +++ b/board/engicam/px30_core/MAINTAINERS @@ -4,6 +4,12 @@ M: Suniel Mahesh S:Maintained F:configs/px30-core-ctouch2-px30_defconfig +PX30-Core-CTOUCH2.0-OF10 +M: Jagan Teki +M: Suniel Mahesh +S: Maintained +F: configs/px30-core-ctouch2-of10-px30_defconfig + PX30-Core-EDIMM2.2 M:Jagan Teki M:Suniel Mahesh diff --git a/configs/px30-core-ctouch2-of10-px30_defconfig b/configs/px30-core-ctouch2-of10-px30_defconfig new file mode 100644 index 00..664c9774eb --- /dev/null +++ b/configs/px30-core-ctouch2-of10-px30_defconfig @@ -0,0 +1,108 @@ +CONFIG_ARM=y +CONFIG_SKIP_LOWLEVEL_INIT=y +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_DEFAULT_DEVICE_TREE="px30-engicam-px30-core-ctouch2-of10" +CONFIG_SPL_TEXT_BASE=0x +CONFIG_ROCKCHIP_PX30=y +CONFIG_TARGET_PX30_CORE=y +CONFIG_DEBUG_UART_CHANNEL=1 +CONFIG_TPL_LIBGENERIC_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC=y +CONFIG_SPL_STACK_R_ADDR=0x60 +CONFIG_DEBUG_UART_BASE=0xFF16 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_DEBUG_UART=y +CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 +CONFIG_SYS_LOAD_ADDR=0x800800 +# CONFIG_ANDROID_BOOT_IMAGE is not set +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_DEFAULT_FDT_FILE="rockchip/px30-engicam-px30-core-ctouch2-of10.dtb" +# CONFIG_CONSOLE_MUX is not set +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_MISC_INIT_R=y +CONFIG_SPL_BOOTROM_SUPPORT=y +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_SPL_STACK_R=y +# CONFIG_TPL_BANNER_PRINT is not set +CONFIG_SPL_ATF=y +# CONFIG_TPL_FRAMEWORK is not set +# CONFIG_CMD_BOOTD is not set +# CONFIG_CMD_ELF is not set +# CONFIG_CMD_IMI is not set +# CONFIG_CMD_XIMG is not set +# CONFIG_CMD_LZMADEC is not set +# CONFIG_CMD_UNZIP is not set +CONFIG_CMD_GPT=y +# CONFIG_CMD_LOADB is not set +# CONFIG_CMD_LOADS is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y +# CONFIG_CMD_ITEST is not set +# CONFIG_CMD_SETEXPR is not set +# CONFIG_SPL_DOS_PARTITION is not set +# CONFIG_ISO_PARTITION is not set +CONFIG_EFI_PARTITION_ENTRIES_NUMBERS=64 +CONFIG_SPL_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_REGMAP=y +CONFIG_SPL_REGMAP=y +CONFIG_SYSCON=y +CONFIG_SPL_SYSCON=y +CONFIG_CLK=y +CONFIG_SPL_CLK=y +CONFIG_FASTBOOT_BUF_ADDR=0x800800
Re: [PATCH v2 2/3] arm64: dts: rockchip: Sync px30 from linux-next
On 2021/11/16 上午1:38, Jagan Teki wrote:
Sync the px30 devicetree files from linux-next tree.
commit <14ce8069f48b> ("lib/stackdepot: allow optional init and
stack_table allocation by kvmalloc() - fixup3")
Note, this path even sync rk3326 files as it depends on px30.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changes for v2:
- add sync on v5.15
- add sync on rk3326
arch/arm/dts/Makefile | 4 +-
arch/arm/dts/px30-engicam-common.dtsi | 90 ++
arch/arm/dts/px30-engicam-ctouch2.dtsi| 22 ++
arch/arm/dts/px30-engicam-edimm2.2.dtsi | 59
.../px30-engicam-px30-core-ctouch2-of10.dts | 77 +
...dts => px30-engicam-px30-core-ctouch2.dts} | 4 +-
.../dts/px30-engicam-px30-core-edimm2.2.dts | 43 +++
...-core.dtsi => px30-engicam-px30-core.dtsi} | 11 +-
arch/arm/dts/px30-evb.dts | 143 --
arch/arm/dts/px30-px30-core-edimm2.2.dts | 21 --
arch/arm/dts/px30-u-boot.dtsi | 4 +
arch/arm/dts/px30.dtsi| 270 +-
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi| 2 +-
arch/arm/dts/rk3326-odroid-go2.dts| 178 +++-
configs/px30-core-ctouch2-px30_defconfig | 4 +-
configs/px30-core-edimm2.2-px30_defconfig | 4 +-
16 files changed, 681 insertions(+), 255 deletions(-)
create mode 100644 arch/arm/dts/px30-engicam-px30-core-ctouch2-of10.dts
rename arch/arm/dts/{px30-px30-core-ctouch2.dts =>
px30-engicam-px30-core-ctouch2.dts} (80%)
create mode 100644 arch/arm/dts/px30-engicam-px30-core-edimm2.2.dts
rename arch/arm/dts/{px30-px30-core.dtsi => px30-engicam-px30-core.dtsi} (96%)
delete mode 100644 arch/arm/dts/px30-px30-core-edimm2.2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cc34da7bd8..57a33d0bc4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -78,8 +78,8 @@ dtb-$(CONFIG_MACH_S700) += \
dtb-$(CONFIG_ROCKCHIP_PX30) += \
px30-evb.dtb \
px30-firefly.dtb \
- px30-px30-core-ctouch2.dtb \
- px30-px30-core-edimm2.2.dtb \
+ px30-engicam-px30-core-ctouch2.dtb \
+ px30-engicam-px30-core-edimm2.2.dtb \
rk3326-odroid-go2.dtb
dtb-$(CONFIG_ROCKCHIP_RK3036) += \
diff --git a/arch/arm/dts/px30-engicam-common.dtsi
b/arch/arm/dts/px30-engicam-common.dtsi
index bd5bde989e..3429e124d9 100644
--- a/arch/arm/dts/px30-engicam-common.dtsi
+++ b/arch/arm/dts/px30-engicam-common.dtsi
@@ -6,6 +6,11 @@
*/
/ {
+ aliases {
+ mmc1 =
+ mmc2 =
+ };
+
vcc5v0_sys: vcc5v0-sys {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_sys";/* +5V */
@@ -14,6 +19,63 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
};
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <>;
+ clock-names = "ext_clock";
+ post-power-on-delay-ms = <80>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ };
+
+ vcc3v3_btreg: vcc3v3-btreg {
+ compatible = "regulator-gpio";
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ regulator-name = "btreg-gpio-supply";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ states = <330 0x0>;
+ };
+
+ vcc3v3_rf_aux_mod: vcc3v3-rf-aux-mod {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_rf_aux_mod";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_sys>;
+ };
+
+ xin32k: xin32k {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "xin32k";
+ };
+};
+
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ clock-frequency = <5000>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ mmc-pwrseq = <_pwrseq>;
+ non-removable;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ brcmf: wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ };
};
{
@@ -25,6 +87,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
cap-sd-highspeed;
card-detect-delay = <800>;
@@ -33,7 +99,31 @@
status = "okay";
};
+ {
+ status = "okay";
+
+ u2phy_host: host-port {
+
Re: [PATCH v2 1/3] arm64: dts: rockchip: px30: Move dmc into -u-boot.dtsi
On 2021/11/16 上午1:38, Jagan Teki wrote:
dmc node is specific to U-Boot, it is always better practice
to maintain U-Boot specific nodes into -u-boot.dtsi files
in order to maintain Linux dts file sync compatibility.
Move the dmc into px30-u-boot.dtsi, also add dmc node
explicitly in rk3326-odroid-go2-u-boot.dtsi since it is
using px30.dts.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changes for v2:
- none
arch/arm/dts/px30-u-boot.dtsi | 10 ++
arch/arm/dts/px30.dtsi | 5 -
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 10 ++
3 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/arch/arm/dts/px30-u-boot.dtsi b/arch/arm/dts/px30-u-boot.dtsi
index 029c8fbd8d..bbed7dcde5 100644
--- a/arch/arm/dts/px30-u-boot.dtsi
+++ b/arch/arm/dts/px30-u-boot.dtsi
@@ -13,6 +13,12 @@
u-boot,spl-boot-order = ,
};
+ dmc {
+ u-boot,dm-pre-reloc;
+ compatible = "rockchip,px30-dmc", "syscon";
+ reg = <0x0 0xff2a 0x0 0x1000>;
+ };
+
rng: rng@ff0b {
compatible = "rockchip,cryptov2-rng";
reg = <0x0 0xff0b 0x0 0x4000>;
@@ -20,10 +26,6 @@
};
};
- {
- u-boot,dm-pre-reloc;
-};
-
{
clock-frequency = <2400>;
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/px30.dtsi b/arch/arm/dts/px30.dtsi
index ef706486dc..ef77b7b997 100644
--- a/arch/arm/dts/px30.dtsi
+++ b/arch/arm/dts/px30.dtsi
@@ -151,11 +151,6 @@
interrupt-affinity = <>, <>, <>, <>;
};
- dmc: dmc {
- compatible = "rockchip,px30-dmc", "syscon";
- reg = <0x0 0xff2a 0x0 0x1000>;
- };
-
display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
ports = <_out>, <_out>;
diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
index bffaa3edf3..63d87e16e1 100644
--- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
+++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
@@ -16,6 +16,12 @@
serial2 =
spi0 =
};
+
+ dmc {
+ u-boot,dm-pre-reloc;
+ compatible = "rockchip,px30-dmc", "syscon";
+ reg = <0x0 0xff2a 0x0 0x1000>;
+ };
};
/* U-Boot clk driver for px30 cannot set GPU_CLK */
@@ -32,10 +38,6 @@
<1>, <1700>;
};
- {
- u-boot,dm-pre-reloc;
-};
-
{
u-boot,dm-pre-reloc;
};
Re: [PATCH] power: pmic/fan53555: allow dm be omitted by SPL
On 2021/11/12 下午10:10, Quentin Schulz wrote: Allow the dm driver be omitted by SPL. Cc: Quentin Schulz Signed-off-by: Quentin Schulz Reviewed-by: Kever Yang Thanks, - Kever --- drivers/power/pmic/Kconfig | 14 ++ drivers/power/pmic/Makefile | 2 +- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig index b9fda428df..ce0adb18a4 100644 --- a/drivers/power/pmic/Kconfig +++ b/drivers/power/pmic/Kconfig @@ -128,6 +128,20 @@ config DM_PMIC_FAN53555 The driver implements read/write operations for use with the FAN53555 regulator driver and binds the regulator driver to its node. +config SPL_DM_PMIC_FAN53555 + bool "Enable support for OnSemi FAN53555 in SPL" + depends on SPL_DM_REGULATOR && SPL_DM_I2C + select SPL_DM_REGULATOR_FAN53555 + help + This config enables implementation of driver-model PMIC + uclass features for the FAN53555 regulator. The FAN53555 is + a (family of) single-output regulators that supports + transitioning between two different output voltages based on + an voltage selection pin. + + The driver implements read/write operations for use with the FAN53555 + regulator driver and binds the regulator driver to its node. + config DM_PMIC_MP5416 bool "Enable Driver Model for PMIC MP5416" help diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile index e1922df00f..401cde32cf 100644 --- a/drivers/power/pmic/Makefile +++ b/drivers/power/pmic/Makefile @@ -4,7 +4,7 @@ # Lukasz Majewski obj-$(CONFIG_$(SPL_TPL_)DM_PMIC) += pmic-uclass.o -obj-$(CONFIG_DM_PMIC_FAN53555) += fan53555.o +obj-$(CONFIG_$(SPL_)DM_PMIC_FAN53555) += fan53555.o obj-$(CONFIG_$(SPL_)DM_PMIC_DA9063) += da9063.o obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o obj-$(CONFIG_DM_PMIC_MAX8998) += max8998.o
Re: [RFC PATCH v2 3/8] FWU: stm32mp1: Add helper functions for accessing FWU metadata
() should Hi Sughosh and Ilias,
I would like to confirm that what the plat_fill_gpt_partition_guids()
should return.
2021年12月19日(日) 16:07 Sughosh Ganu :
> +static int plat_fill_gpt_partition_guids(struct blk_desc *desc,
> +efi_guid_t **part_guid_arr)
> +{
> + int i, ret = 0;
> + u32 part;
> + struct dfu_entity *dfu;
> + struct disk_partition info;
> + efi_guid_t part_type_guid;
> + int alt_num = dfu_get_alt_number();
> +
> + dfu_init_env_entities(NULL, NULL);
> +
> + for (i = 0, part = 1; i < alt_num; i++) {
> + dfu = dfu_get_entity(i);
> +
> + if (!dfu)
> + continue;
> +
> + /*
> +* Currently, Multi Bank update
> +* feature is being supported
> +* only on GPT partitioned
> +* MMC/SD devices.
> +*/
> + if (dfu->dev_type != DFU_DEV_MMC)
> + continue;
> +
> + if (part_get_info(desc, part, )) {
> + part++;
> + continue;
> + }
> +
> + uuid_str_to_bin(info.type_guid, part_type_guid.b,
> + UUID_STR_FORMAT_GUID);
> + guidcpy((*part_guid_arr + i), _type_guid);
> + part++;
> + }
> +
> + dfu_free_entities();
> +
> + return ret;
> +}
So on this platform which uses GPT partition for each bank, it stores
the GUID for each partition.
I think this information will be shown in the ESRT, but not used for
specifying capsule image_type_uuid.
This is strange.
Without this FWU multi-bank update, the array will only have the
image_type UUID.
Thus, user can use ESRT to confirm what UUID should be specified for
the capsule file. (it has image-type UUID)
(of course that is fixed value on one platform anyway)
And when FWU multi-bank update is enabled, that changes to the
partition GUIDs. But those GUIDs are NOT used when making the capsule
file nor doing the update process, because we should not specify the
bank index directly, right?
We will set a unique image-type UUID on each image entry, and use it
for making a capsule file, but the capsule file itself doesn't specify
the banks. And acceptance/revert capsule file also doesn't specify it.
Acceptance file will also uses image_type UUID, but not the partition
UUID for the bank.
Maybe I'm wrong, but I'm confusing. And this is important for the
platform which doesn't use GPT.
Thank you,
--
Masami Hiramatsu
Re: [PATCH v3 1/3] rockchip: Kconfig: Enable SPL support for rk3568
On 2021/10/26 上午10:42, Nico Cheng wrote: Enable SPL support in Kconfig and add some related option in rk3568_common.h Signed-off-by: Nico Cheng Signed-off-by: Jason Zhu Reviewed-by: Kever Yang Thanks, - Kever --- (no changes since v1) arch/arm/mach-rockchip/Kconfig | 2 ++ configs/evb-rk3568_defconfig| 25 - include/configs/rk3568_common.h | 4 3 files changed, 30 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index b164afb529..21b9c381cf 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -260,6 +260,8 @@ config ROCKCHIP_RK3399 config ROCKCHIP_RK3568 bool "Support Rockchip RK3568" select ARM64 + select SUPPORT_SPL + select SPL select CLK select PINCTRL select RAM diff --git a/configs/evb-rk3568_defconfig b/configs/evb-rk3568_defconfig index a102a5a999..a145b71ac2 100644 --- a/configs/evb-rk3568_defconfig +++ b/configs/evb-rk3568_defconfig @@ -1,20 +1,42 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x00a0 +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 -CONFIG_DEFAULT_DEVICE_TREE="rk3568-evb" CONFIG_ROCKCHIP_RK3568=y +CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_SERIAL_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_SPL_STACK_R_ADDR=0x60 CONFIG_TARGET_EVB_RK3568=y CONFIG_DEBUG_UART_BASE=0xFE66 CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_DEFAULT_DEVICE_TREE="rk3568-evb" CONFIG_DEBUG_UART=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-evb.dtb" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_SPL_STACK_R=y +CONFIG_SPL_SEPARATE_BSS=y +CONFIG_SPL_CRC32_SUPPORT=y +CONFIG_SPL_ATF=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y # CONFIG_CMD_SETEXPR is not set +# CONFIG_SPL_DOS_PARTITION is not set +CONFIG_SPL_OF_CONTROL=y +CONFIG_OF_LIVE=y CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SPL_REGMAP=y +CONFIG_SPL_SYSCON=y +CONFIG_SPL_CLK=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y @@ -28,6 +50,7 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_REGULATOR_PWM=y CONFIG_PWM_ROCKCHIP=y +CONFIG_SPL_RAM=y CONFIG_DM_RESET=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 diff --git a/include/configs/rk3568_common.h b/include/configs/rk3568_common.h index b6568917ea..47fc91779e 100644 --- a/include/configs/rk3568_common.h +++ b/include/configs/rk3568_common.h @@ -18,6 +18,10 @@ #define CONFIG_SYS_INIT_SP_ADDR 0x00c0 #define CONFIG_SYS_LOAD_ADDR 0x00c00800 +#define CONFIG_SPL_STACK 0x0040 +#define CONFIG_SPL_MAX_SIZE0x2 +#define CONFIG_SPL_BSS_START_ADDR 0x400 +#define CONFIG_SPL_BSS_MAX_SIZE0x4000 #define CONFIG_SYS_BOOTM_LEN (64 << 20)/* 64M */ #define CONFIG_SYS_SDRAM_BASE 0
Re: [PATCH v3 2/3] arm: dts: rockchip: rk3568: Enable sdhci and sdmmc0 node
On 2021/10/26 上午10:42, Nico Cheng wrote:
Enable sdhci and sdmmc0 node in rk3568-u-boot.dtsi
Signed-off-by: Nico Cheng
Reviewed-by: Kever Yang
Thanks,
- Kever
---
(no changes since v1)
arch/arm/dts/rk3568-u-boot.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/dts/rk3568-u-boot.dtsi b/arch/arm/dts/rk3568-u-boot.dtsi
index 1570f13fc7..5a80dda275 100644
--- a/arch/arm/dts/rk3568-u-boot.dtsi
+++ b/arch/arm/dts/rk3568-u-boot.dtsi
@@ -9,6 +9,10 @@
mmc1 =
};
+ chosen {
+ u-boot,spl-boot-order = ,
+ };
+
dmc: dmc {
compatible = "rockchip,rk3568-dmc";
u-boot,dm-pre-reloc;
@@ -35,3 +39,16 @@
u-boot,dm-pre-reloc;
status = "okay";
};
+
+ {
+ u-boot,dm-spl;
+ status = "okay";
+};
+
+ {
+ bus-width = <8>;
+ u-boot,dm-spl;
+ mmc-hs200-1_8v;
+ status = "okay";
+};
+
Re: [PATCH v3 3/3] rockchip: rk3568: add arch_cpu_init()
On 2021/10/26 上午10:42, Nico Cheng wrote:
We configured the drive strength and security of EMMC in
arch_cpu_init().
Signed-off-by: Nico Cheng
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changes in v3:
Replace configuration parameters of SGRF_SOC_CON4 with macro
definitions.
Changes in v2:
We use the rk_clrreg function instead of the writel to set eMMC sdmmc0 to
secure.
Modify comments to make them more explicit.
arch/arm/mach-rockchip/rk3568/rk3568.c | 27 +++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c
b/arch/arm/mach-rockchip/rk3568/rk3568.c
index 973b4f9dcb..22eeb77d41 100644
--- a/arch/arm/mach-rockchip/rk3568/rk3568.c
+++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
@@ -11,9 +11,18 @@
#include
#include
-#define PMUGRF_BASE 0xfdc2
-#define GRF_BASE 0xfdc6
-
+#define PMUGRF_BASE0xfdc2
+#define GRF_BASE 0xfdc6
+#define GRF_GPIO1B_DS_20x218
+#define GRF_GPIO1B_DS_30x21c
+#define GRF_GPIO1C_DS_00x220
+#define GRF_GPIO1C_DS_10x224
+#define GRF_GPIO1C_DS_20x228
+#define GRF_GPIO1C_DS_30x22c
+#define SGRF_BASE 0xFDD18000
+#define SGRF_SOC_CON4 0x10
+#define EMMC_HPROT_SECURE_CTRL 0x03
+#define SDMMC0_HPROT_SECURE_CTRL 0x01
/* PMU_GRF_GPIO0D_IOMUX_L */
enum {
GPIO0D1_SHIFT = 4,
@@ -81,5 +90,17 @@ void board_debug_uart_init(void)
int arch_cpu_init(void)
{
+#ifdef CONFIG_SPL_BUILD
+ /* Set the emmc sdmmc0 to secure */
+ rk_clrreg(SGRF_BASE + SGRF_SOC_CON4, (EMMC_HPROT_SECURE_CTRL << 11
+ | SDMMC0_HPROT_SECURE_CTRL << 4));
+ /* set the emmc driver strength to level 2 */
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_2);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1B_DS_3);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_0);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_1);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_2);
+ writel(0x3f3f0707, GRF_BASE + GRF_GPIO1C_DS_3);
+#endif
return 0;
}
Re: [PATCH] rockchip: Add initial support for the PinePhone Pro
Hi Martin,
Is there a update for this patch with the link to mainline kernel
commit?
Thanks,
- Kever
On 2021/10/22 上午1:18, Martijn Braam wrote:
This is a new device by PINE64 that's very similar to the Pinebook Pro
that's already supported.
Specification:
- Rockchip RK3399
- 4GB Dual-Channel LPDDR4
- 128GB eMMC
- mSD card slot
- AP6255 for 802.11ac WiFi and Bluetooth
- 6 inch 720*1440 DSI display
- Quectel EG25g usb modem
- Type-C port with alt-mode display (DP 1.2) and PD charging.
Signed-off-by: Martijn Braam
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi | 44 ++
arch/arm/dts/rk3399-pinephone-pro.dts | 520 ++
arch/arm/mach-rockchip/rk3399/Kconfig | 8 +
board/pine64/pinephone-pro-rk3399/Kconfig | 15 +
board/pine64/pinephone-pro-rk3399/MAINTAINERS | 8 +
board/pine64/pinephone-pro-rk3399/Makefile| 1 +
.../pinephone-pro-rk3399.c| 57 ++
configs/pinephone-pro-rk3399_defconfig| 92
include/configs/pinephone-pro-rk3399.h| 23 +
10 files changed, 769 insertions(+)
create mode 100644 arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-pinephone-pro.dts
create mode 100644 board/pine64/pinephone-pro-rk3399/Kconfig
create mode 100644 board/pine64/pinephone-pro-rk3399/MAINTAINERS
create mode 100644 board/pine64/pinephone-pro-rk3399/Makefile
create mode 100644 board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
create mode 100644 configs/pinephone-pro-rk3399_defconfig
create mode 100644 include/configs/pinephone-pro-rk3399.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ed3d360bb1..3206370226 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -137,6 +137,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-nanopi-r4s.dtb \
rk3399-orangepi.dtb \
rk3399-pinebook-pro.dtb \
+ rk3399-pinephone-pro.dtb \
rk3399-puma-haikou.dtb \
rk3399-roc-pc.dtb \
rk3399-roc-pc-mezzanine.dtb \
diff --git a/arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi
b/arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi
new file mode 100644
index 00..9d44db5978
--- /dev/null
+++ b/arch/arm/dts/rk3399-pinephone-pro-u-boot.dtsi
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Peter Robinson
+ * Copyright (C) 2021 Martijn Braam
+ */
+
+#include "rk3399-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
+
+/ {
+ aliases {
+ spi0 =
+ };
+
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+
+ config {
+ u-boot,spl-payload-offset = <0x6>; /* @ 384KB */
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ max-frequency = <2500>;
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ max-frequency = <2000>;
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3399-pinephone-pro.dts
b/arch/arm/dts/rk3399-pinephone-pro.dts
new file mode 100644
index 00..3fe1845ced
--- /dev/null
+++ b/arch/arm/dts/rk3399-pinephone-pro.dts
@@ -0,0 +1,520 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2021 Martijn Braam
+ */
+
+/dts-v1/;
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "Pine64 PinePhone Pro";
+ compatible = "pine64,pinephone-pro", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ };
+
+ /* Power tree */
+ /* Root power source */
+ vcc_sysin: vcc-sysin {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sysin";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ /* Main 3.3v supply */
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_sysin>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+};
+
+_l0 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l1 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l2 {
+ cpu-supply = <_cpu_l>;
+};
+
+_l3 {
+ cpu-supply = <_cpu_l>;
+};
+
+_b0 {
+ cpu-supply = <_cpu_b>;
+};
+
+_b1 {
+ cpu-supply = <_cpu_b>;
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ mali-supply = <_gpu>;
+ status = "okay";
+};
+
+ {
+ clock-frequency = <40>;
+ i2c-scl-rising-time-ns = <168>;
+
Re: [PATCH] engicam: Rename board dir, px30_core to px30
Hi Jagan,
Please add 'rockchip' prefix in the subject.
Thanks,
- Kever
On 2021/8/4 下午5:07, Jagan Teki wrote:
Engicam hardware design solutions are based on System On Modules(SoM)
with various SoCs like i.MX6, i.MX8 and PX30 etc.
The current directory structure uses the simplest way to understand
these designs by listing each of these SoC in board/engicam/SoC and
inside SoC directory has SoM file name as a board file name.
Right now all of the SoC's follow a similar approach except px30.
So rename px30_core to px30.
Signed-off-by: Jagan Teki
---
Note:
This patch is on top of
https://patchwork.ozlabs.org/project/uboot/cover/20210804090551.90819-1-ja...@amarulasolutions.com/
arch/arm/mach-rockchip/px30/Kconfig | 2 +-
board/engicam/{px30_core => px30}/Kconfig | 2 +-
board/engicam/{px30_core => px30}/MAINTAINERS | 0
board/engicam/{px30_core => px30}/Makefile| 0
board/engicam/{px30_core => px30}/px30_core.c | 0
5 files changed, 2 insertions(+), 2 deletions(-)
rename board/engicam/{px30_core => px30}/Kconfig (90%)
rename board/engicam/{px30_core => px30}/MAINTAINERS (100%)
rename board/engicam/{px30_core => px30}/Makefile (100%)
rename board/engicam/{px30_core => px30}/px30_core.c (100%)
diff --git a/arch/arm/mach-rockchip/px30/Kconfig
b/arch/arm/mach-rockchip/px30/Kconfig
index 98e09019a2..7b9b380dfa 100644
--- a/arch/arm/mach-rockchip/px30/Kconfig
+++ b/arch/arm/mach-rockchip/px30/Kconfig
@@ -68,7 +68,7 @@ config DEBUG_UART_CHANNEL
For using the UART for early debugging the route to use needs
to be declared (0 or 1).
-source "board/engicam/px30_core/Kconfig"
+source "board/engicam/px30/Kconfig"
source "board/hardkernel/odroid_go2/Kconfig"
source "board/rockchip/evb_px30/Kconfig"
diff --git a/board/engicam/px30_core/Kconfig b/board/engicam/px30/Kconfig
similarity index 90%
rename from board/engicam/px30_core/Kconfig
rename to board/engicam/px30/Kconfig
index a03be78369..10a7ec203f 100644
--- a/board/engicam/px30_core/Kconfig
+++ b/board/engicam/px30/Kconfig
@@ -1,7 +1,7 @@
if TARGET_PX30_CORE
config SYS_BOARD
- default "px30_core"
+ default "px30"
config SYS_VENDOR
default "engicam"
diff --git a/board/engicam/px30_core/MAINTAINERS
b/board/engicam/px30/MAINTAINERS
similarity index 100%
rename from board/engicam/px30_core/MAINTAINERS
rename to board/engicam/px30/MAINTAINERS
diff --git a/board/engicam/px30_core/Makefile b/board/engicam/px30/Makefile
similarity index 100%
rename from board/engicam/px30_core/Makefile
rename to board/engicam/px30/Makefile
diff --git a/board/engicam/px30_core/px30_core.c
b/board/engicam/px30/px30_core.c
similarity index 100%
rename from board/engicam/px30_core/px30_core.c
rename to board/engicam/px30/px30_core.c
[PATCH] board: ls1088a: update ifc node name to be memory-controller
LF-4834: kernel boot failed
IFC-NOR and QSPI are muxed on SoC.
So disable IFC node in dts if QSPI is enabled or disable QSPI node in dts
in case QSPI is not enabled.
The nor-flash offset in uboot is invalid because of the following changes:
project: linux-nxp
* commit 'b6bd3c1f6ce17353601187c51424c18257735cc3':
arm64: dts: freescale: update ifc node name to be memory-controller
Need to modify "ifc/nor" to "memory-controller/nor" in fdt_path_offset().
Signed-off-by: Jianpeng Bu
---
board/freescale/ls1088a/ls1088a.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/board/freescale/ls1088a/ls1088a.c
b/board/freescale/ls1088a/ls1088a.c
index f5dc449d89..7b5f8d2486 100644
--- a/board/freescale/ls1088a/ls1088a.c
+++ b/board/freescale/ls1088a/ls1088a.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2017-2018 NXP
+ * Copyright 2017-2018, 2021 NXP
*/
#include
#include
@@ -923,10 +923,10 @@ void fsl_fdt_fixup_flash(void *fdt)
}
if (disable_ifc) {
- offset = fdt_path_offset(fdt, "/soc/ifc/nor");
+ offset = fdt_path_offset(fdt, "/soc/memory-controller/nor");
if (offset < 0)
- offset = fdt_path_offset(fdt, "/ifc/nor");
+ offset = fdt_path_offset(fdt, "/memory-controller/nor");
} else {
offset = fdt_path_offset(fdt, "/soc/quadspi");
@@ -936,10 +936,10 @@ void fsl_fdt_fixup_flash(void *fdt)
#else
#ifdef CONFIG_FSL_QSPI
- offset = fdt_path_offset(fdt, "/soc/ifc/nor");
+ offset = fdt_path_offset(fdt, "/soc/memory-controller/nor");
if (offset < 0)
- offset = fdt_path_offset(fdt, "/ifc/nor");
+ offset = fdt_path_offset(fdt, "/memory-controller/nor");
#else
offset = fdt_path_offset(fdt, "/soc/quadspi");
--
2.25.1
Re: [RFC PATCH v2 0/3] imx8m: move env_get_location for imx8mn and imx8mp at board level
On Sun, Dec 19, 2021 at 10:11:44AM +0800, Peng Fan (OSS) wrote: > > > On 2021/12/1 4:17, Tommaso Merciai wrote: > > This series move env_get_location from soc to board level. As suggested > > by Michael make no sense to define an > > unique way for multiple board. One board can boot from emmc and having > > env on spi flash etc.. Anyways, this function is kept in both imx8mn > > and imx8mp evk boards instead of being completely dropped. > > (as suggested by Andrey ) > > If there are other i.MX8MN/P boards already uses the function, move > it to i.mx8mn/p_evk would break other boards. If i.MX8MN/P evk are > the other users, it should be ok to move the board code. Hi Peng, Maybe declare it as __weak in soc.c and ovverride it a board level can be a valid solution? Let me know. thanks. tommaso > > Regards, > Peng. > > > > > Tommaso Merciai (3): > >imx8m: drop env_get_location for imx8mn and imx8mp > >imx: imx8mn_evk: override env_get_location > >imx: imx8mp_evk: override env_get_location > > > > arch/arm/mach-imx/imx8m/soc.c | 39 - > > board/freescale/imx8mn_evk/imx8mn_evk.c | 35 ++ > > board/freescale/imx8mp_evk/imx8mp_evk.c | 34 + > > 3 files changed, 69 insertions(+), 39 deletions(-) > >
Re: [PATCH 0/3] Apple M1 power management controller support
> From: Jaehoon Chung > Date: Wed, 22 Dec 2021 18:56:18 +0900 Dear Jaehoon, Just noticed that I accidentally included some unrelated driver/mailbox changes in the first patch from this series. So I sent a v2 without those. Thanks, Mark > Hi Mark, > > On 12/21/21 5:30 PM, Mark Kettenis wrote: > >> From: Jaehoon Chung > >> Date: Tue, 21 Dec 2021 08:00:38 +0900 > > Hello Jaehoon, > > > >> Dear Mark, > >> > >> On 12/7/21 4:03 AM, Mark Kettenis wrote: > >>> This series adds support for the power management controller found on > >>> Apple SoCs based on the device tree bindings submitted to upstream > >>> Linux. This is needed to enable power domains for devices that > >>> haven't been enabled by earlier boot stages. > >> Is there any patch before applied this patchset? > > This is based on next, with the watchdog patch applied: > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=271919 > > > > The drivers are independent, but I suppose you get conflicts in > > Kconfig and maybe the device tree without that series applied. > > Thanks for sharing information. I will check on next branch. > > Best Regards, > Jaehoon Chung > > > > > Cheers, > > > > Mark > > > >>> > >>> Mark Kettenis (3): > >>> arm: dts: apple: Update Apple M1 device trees > >>> arm: dts: apple: Add u-boot,dm-pre-reloc properties > >>> power: domain: Add Apple pmgr driver > >>> > >>> arch/arm/Kconfig|4 + > >>> arch/arm/dts/Makefile |5 +- > >>> arch/arm/dts/t8103-j274-u-boot.dtsi |1 + > >>> arch/arm/dts/t8103-j274.dts | 122 +-- > >>> arch/arm/dts/t8103-j293-u-boot.dtsi |1 + > >>> arch/arm/dts/t8103-j293.dts | 92 +-- > >>> arch/arm/dts/t8103-j313-u-boot.dtsi |1 + > >>> arch/arm/dts/t8103-j313.dts | 57 ++ > >>> arch/arm/dts/t8103-j456-u-boot.dtsi |1 + > >>> arch/arm/dts/t8103-j456.dts | 71 ++ > >>> arch/arm/dts/t8103-j457-u-boot.dtsi |1 + > >>> arch/arm/dts/t8103-j457.dts | 59 ++ > >>> arch/arm/dts/t8103-jxxx.dtsi| 140 > >>> arch/arm/dts/t8103-pmgr.dtsi| 1136 +++ > >>> arch/arm/dts/t8103-u-boot.dtsi | 25 + > >>> arch/arm/dts/t8103.dtsi | 585 +++--- > >>> drivers/mailbox/Kconfig |9 + > >>> drivers/mailbox/Makefile|1 + > >>> drivers/power/domain/Kconfig|8 + > >>> drivers/power/domain/Makefile |1 + > >>> drivers/power/domain/apple-pmgr.c | 113 +++ > >>> 21 files changed, 2005 insertions(+), 428 deletions(-) > >>> create mode 100644 arch/arm/dts/t8103-j274-u-boot.dtsi > >>> create mode 100644 arch/arm/dts/t8103-j293-u-boot.dtsi > >>> create mode 100644 arch/arm/dts/t8103-j313-u-boot.dtsi > >>> create mode 100644 arch/arm/dts/t8103-j313.dts > >>> create mode 100644 arch/arm/dts/t8103-j456-u-boot.dtsi > >>> create mode 100644 arch/arm/dts/t8103-j456.dts > >>> create mode 100644 arch/arm/dts/t8103-j457-u-boot.dtsi > >>> create mode 100644 arch/arm/dts/t8103-j457.dts > >>> create mode 100644 arch/arm/dts/t8103-jxxx.dtsi > >>> create mode 100644 arch/arm/dts/t8103-pmgr.dtsi > >>> create mode 100644 arch/arm/dts/t8103-u-boot.dtsi > >>> create mode 100644 drivers/power/domain/apple-pmgr.c > >>> > >> > >
[PATCH v2 3/3] power: domain: Add Apple pmgr driver
This driver supports power domains for the power management
controller found on Apple SoCs.
Signed-off-by: Mark Kettenis
---
arch/arm/Kconfig | 3 +
drivers/power/domain/Kconfig | 8 +++
drivers/power/domain/Makefile | 1 +
drivers/power/domain/apple-pmgr.c | 113 ++
4 files changed, 125 insertions(+)
create mode 100644 drivers/power/domain/apple-pmgr.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 59e031de04..40d3f66acb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -938,6 +938,9 @@ config ARCH_APPLE
select OF_BOARD
select PINCTRL
select POSITION_INDEPENDENT
+ select POWER_DOMAIN
+ select REGMAP
+ select SYSCON
select SYSRESET
select SYSRESET_WATCHDOG
select SYSRESET_WATCHDOG_AUTO
diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig
index 99b3f9ae71..6ef7a3b3a7 100644
--- a/drivers/power/domain/Kconfig
+++ b/drivers/power/domain/Kconfig
@@ -9,6 +9,14 @@ config POWER_DOMAIN
domains). This may be used to save power. This API provides the
means to control such power management hardware.
+config APPLE_PMGR_POWER_DOMAIN
+ bool "Enable the Apple PMGR power domain driver"
+ depends on POWER_DOMAIN
+ default y if ARCH_APPLE
+ help
+ Enable support for manipulating the Apple M1 power domains via
+ MMIO mapped registers.
+
config BCM6328_POWER_DOMAIN
bool "Enable the BCM6328 power domain driver"
depends on POWER_DOMAIN && ARCH_BMIPS
diff --git a/drivers/power/domain/Makefile b/drivers/power/domain/Makefile
index 3d1e5f073c..530ae35671 100644
--- a/drivers/power/domain/Makefile
+++ b/drivers/power/domain/Makefile
@@ -4,6 +4,7 @@
#
obj-$(CONFIG_$(SPL_)POWER_DOMAIN) += power-domain-uclass.o
+obj-$(CONFIG_APPLE_PMGR_POWER_DOMAIN) += apple-pmgr.o
obj-$(CONFIG_BCM6328_POWER_DOMAIN) += bcm6328-power-domain.o
obj-$(CONFIG_IMX8_POWER_DOMAIN) += imx8-power-domain-legacy.o
imx8-power-domain.o
obj-$(CONFIG_IMX8M_POWER_DOMAIN) += imx8m-power-domain.o
diff --git a/drivers/power/domain/apple-pmgr.c
b/drivers/power/domain/apple-pmgr.c
new file mode 100644
index 00..08a30c8ebf
--- /dev/null
+++ b/drivers/power/domain/apple-pmgr.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021 Mark Kettenis
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define APPLE_PMGR_PS_TARGET GENMASK(3, 0)
+#define APPLE_PMGR_PS_ACTUAL GENMASK(7, 4)
+
+#define APPLE_PMGR_PS_ACTIVE 0xf
+#define APPLE_PMGR_PS_PWRGATE 0x0
+
+#define APPLE_PMGR_PS_SET_TIMEOUT 100
+
+struct apple_pmgr_priv {
+ struct regmap *regmap;
+ u32 offset;
+};
+
+static int apple_pmgr_request(struct power_domain *power_domain)
+{
+ return 0;
+}
+
+static int apple_pmgr_rfree(struct power_domain *power_domain)
+{
+ return 0;
+}
+
+static int apple_pmgr_ps_set(struct power_domain *power_domain, u32 pstate)
+{
+ struct apple_pmgr_priv *priv = dev_get_priv(power_domain->dev);
+ uint reg;
+
+ regmap_update_bits(priv->regmap, priv->offset, APPLE_PMGR_PS_TARGET,
+ FIELD_PREP(APPLE_PMGR_PS_TARGET, pstate));
+
+ return regmap_read_poll_timeout(
+ priv->regmap, priv->offset, reg,
+ (FIELD_GET(APPLE_PMGR_PS_ACTUAL, reg) == pstate), 1,
+ APPLE_PMGR_PS_SET_TIMEOUT);
+}
+
+static int apple_pmgr_on(struct power_domain *power_domain)
+{
+ return apple_pmgr_ps_set(power_domain, APPLE_PMGR_PS_ACTIVE);
+}
+
+static int apple_pmgr_off(struct power_domain *power_domain)
+{
+ return 0;
+}
+
+static int apple_pmgr_of_xlate(struct power_domain *power_domain,
+ struct ofnode_phandle_args *args)
+{
+ if (args->args_count != 0) {
+ debug("Invalid args_count: %d\n", args->args_count);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static const struct udevice_id apple_pmgr_ids[] = {
+ { .compatible = "apple,pmgr-pwrstate" },
+ { /* sentinel */ }
+};
+
+static int apple_pmgr_probe(struct udevice *dev)
+{
+ struct apple_pmgr_priv *priv = dev_get_priv(dev);
+ int ret;
+
+ ret = dev_power_domain_on(dev);
+ if (ret)
+ return ret;
+
+ priv->regmap = syscon_get_regmap(dev->parent);
+ if (IS_ERR(priv->regmap))
+ return PTR_ERR(priv->regmap);
+
+ ret = dev_read_u32(dev, "reg", >offset);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+struct power_domain_ops apple_pmgr_ops = {
+ .request = apple_pmgr_request,
+ .rfree = apple_pmgr_rfree,
+ .on = apple_pmgr_on,
+ .off = apple_pmgr_off,
+ .of_xlate = apple_pmgr_of_xlate,
+};
+
+U_BOOT_DRIVER(apple_pmgr) = {
+ .name = "apple_pmgr",
+ .id = UCLASS_POWER_DOMAIN,
+ .of_match =
[PATCH v2 1/3] arm: dts: apple: Update Apple M1 device trees
This synchronizes the device trees with those that are in the
process of being upstreamed into Linux 5.16 or proposed for
Linux 5.17. This includes device trees for machines that were
still missing.
There are still some differences that will hopefully be resolved
soon.
Signed-off-by: Mark Kettenis
---
arch/arm/dts/Makefile|5 +-
arch/arm/dts/t8103-j274.dts | 122 +---
arch/arm/dts/t8103-j293.dts | 92 +--
arch/arm/dts/t8103-j313.dts | 57 ++
arch/arm/dts/t8103-j456.dts | 71 +++
arch/arm/dts/t8103-j457.dts | 59 ++
arch/arm/dts/t8103-jxxx.dtsi | 140 +
arch/arm/dts/t8103-pmgr.dtsi | 1136 ++
arch/arm/dts/t8103.dtsi | 585 +
9 files changed, 1839 insertions(+), 428 deletions(-)
create mode 100644 arch/arm/dts/t8103-j313.dts
create mode 100644 arch/arm/dts/t8103-j456.dts
create mode 100644 arch/arm/dts/t8103-j457.dts
create mode 100644 arch/arm/dts/t8103-jxxx.dtsi
create mode 100644 arch/arm/dts/t8103-pmgr.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7f622fedbd..35872e1574 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -34,7 +34,10 @@ dtb-$(CONFIG_TARGET_A7Y17LTE) += exynos78x0-axy17lte.dtb
dtb-$(CONFIG_ARCH_APPLE) += \
t8103-j274.dtb \
- t8103-j293.dtb
+ t8103-j293.dtb \
+ t8103-j313.dtb \
+ t8103-j456.dtb \
+ t8103-j457.dtb
dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-evm.dtb \
diff --git a/arch/arm/dts/t8103-j274.dts b/arch/arm/dts/t8103-j274.dts
index aef1ae29b6..2144768147 100644
--- a/arch/arm/dts/t8103-j274.dts
+++ b/arch/arm/dts/t8103-j274.dts
@@ -10,126 +10,48 @@
/dts-v1/;
#include "t8103.dtsi"
+#include "t8103-jxxx.dtsi"
/ {
compatible = "apple,j274", "apple,t8103", "apple,arm-platform";
model = "Apple Mac mini (M1, 2020)";
aliases {
- serial0 =
- ethernet0 =
- wifi0 =
- };
-
- chosen {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- stdout-path = "serial0";
-
- framebuffer0: framebuffer@0 {
- compatible = "apple,simple-framebuffer",
"simple-framebuffer";
- reg = <0 0 0 0>; /* To be filled by loader */
- /* Format properties will be added by loader */
- status = "disabled";
- };
- };
-
- memory@8 {
- device_type = "memory";
- reg = <0x8 0 0x2 0>; /* To be filled by loader */
+ ethernet0 =
};
};
- {
- status = "okay";
-};
-
-_dart_0 {
- status = "okay";
-};
+/*
+ * Provide labels for the USB type C ports.
+ */
-_dart_1 {
- status = "okay";
+ {
+ label = "USB-C Back-left";
};
-_dart_2 {
- status = "okay";
+ {
+ label = "USB-C Back-right";
};
- {
- status = "okay";
-
- pci0: pci@0,0 {
- device_type = "pci";
- reg = <0x0 0x0 0x0 0x0 0x0>;
- pwren-gpios = < 13 0>;
- reset-gpios = <_ap 152 0>;
- max-link-speed = <2>;
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
- };
-
- pci1: pci@1,0 {
- device_type = "pci";
- reg = <0x800 0x0 0x0 0x0 0x0>;
- reset-gpios = <_ap 153 0>;
- max-link-speed = <2>;
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
- };
-
- pci2: pci@2,0 {
- device_type = "pci";
- reg = <0x1000 0x0 0x0 0x0 0x0>;
- reset-gpios = <_ap 33 0>;
- max-link-speed = <1>;
+/*
+ * Force the bus number assignments so that we can declare some of the
+ * on-board devices and properties that are populated by the bootloader
+ * (such as MAC addresses).
+ */
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
- };
+ {
+ bus-range = <2 2>;
};
- {
- wifi0: network@0,0 {
- reg = <0x1 0x0 0x0 0x0 0x0>;
- local-mac-address = [00 00 00 00 00 00];
- };
-};
-
- {
- eth0: ethernet@0,0 {
+ {
+ bus-range = <3 3>;
+ ethernet0: ethernet@0,0 {
reg = <0x3 0x0 0x0 0x0 0x0>;
- local-mac-address = [00 00 00 00 00 00];
+ /* To be filled by the loader */
+ local-mac-address = [00 10 18 00 00 00];
};
};
-_0_dart_0 {
- status = "okay";
-};
-
-_0_dart_1 {
- status = "okay";
-};
-
-_0 {
- status = "okay";
-};
-
-_1_dart_0 {
- status = "okay";
-};
-
-_1_dart_1 {
- status = "okay";
-};
-
-_1 {
+ {
status = "okay";
};
diff --git a/arch/arm/dts/t8103-j293.dts b/arch/arm/dts/t8103-j293.dts
index 4a22596cf4..cf92ee53e0 100644
[PATCH v2 2/3] arm: dts: apple: Add u-boot,dm-pre-reloc properties
These are necessary to make sure the power domains needed for the
serial console are availble in the pre-relocation phase.
Signed-off-by: Mark Kettenis
---
arch/arm/dts/t8103-j274-u-boot.dtsi | 1 +
arch/arm/dts/t8103-j293-u-boot.dtsi | 1 +
arch/arm/dts/t8103-j313-u-boot.dtsi | 1 +
arch/arm/dts/t8103-j456-u-boot.dtsi | 1 +
arch/arm/dts/t8103-j457-u-boot.dtsi | 1 +
arch/arm/dts/t8103-u-boot.dtsi | 25 +
6 files changed, 30 insertions(+)
create mode 100644 arch/arm/dts/t8103-j274-u-boot.dtsi
create mode 100644 arch/arm/dts/t8103-j293-u-boot.dtsi
create mode 100644 arch/arm/dts/t8103-j313-u-boot.dtsi
create mode 100644 arch/arm/dts/t8103-j456-u-boot.dtsi
create mode 100644 arch/arm/dts/t8103-j457-u-boot.dtsi
create mode 100644 arch/arm/dts/t8103-u-boot.dtsi
diff --git a/arch/arm/dts/t8103-j274-u-boot.dtsi
b/arch/arm/dts/t8103-j274-u-boot.dtsi
new file mode 100644
index 00..6c8dd5a56f
--- /dev/null
+++ b/arch/arm/dts/t8103-j274-u-boot.dtsi
@@ -0,0 +1 @@
+#include "t8103-u-boot.dtsi"
diff --git a/arch/arm/dts/t8103-j293-u-boot.dtsi
b/arch/arm/dts/t8103-j293-u-boot.dtsi
new file mode 100644
index 00..6c8dd5a56f
--- /dev/null
+++ b/arch/arm/dts/t8103-j293-u-boot.dtsi
@@ -0,0 +1 @@
+#include "t8103-u-boot.dtsi"
diff --git a/arch/arm/dts/t8103-j313-u-boot.dtsi
b/arch/arm/dts/t8103-j313-u-boot.dtsi
new file mode 100644
index 00..6c8dd5a56f
--- /dev/null
+++ b/arch/arm/dts/t8103-j313-u-boot.dtsi
@@ -0,0 +1 @@
+#include "t8103-u-boot.dtsi"
diff --git a/arch/arm/dts/t8103-j456-u-boot.dtsi
b/arch/arm/dts/t8103-j456-u-boot.dtsi
new file mode 100644
index 00..6c8dd5a56f
--- /dev/null
+++ b/arch/arm/dts/t8103-j456-u-boot.dtsi
@@ -0,0 +1 @@
+#include "t8103-u-boot.dtsi"
diff --git a/arch/arm/dts/t8103-j457-u-boot.dtsi
b/arch/arm/dts/t8103-j457-u-boot.dtsi
new file mode 100644
index 00..6c8dd5a56f
--- /dev/null
+++ b/arch/arm/dts/t8103-j457-u-boot.dtsi
@@ -0,0 +1 @@
+#include "t8103-u-boot.dtsi"
diff --git a/arch/arm/dts/t8103-u-boot.dtsi b/arch/arm/dts/t8103-u-boot.dtsi
new file mode 100644
index 00..43f552979d
--- /dev/null
+++ b/arch/arm/dts/t8103-u-boot.dtsi
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+_sio_busif {
+ u-boot,dm-pre-reloc;
+};
+
+_sio {
+ u-boot,dm-pre-reloc;
+};
+
+_uart_p {
+ u-boot,dm-pre-reloc;
+};
+
+_uart0 {
+ u-boot,dm-pre-reloc;
+};
--
2.34.1
[PATCH v2 0/3] Apple M1 power management controller support
This series adds support for the power management controller found on Apple SoCs based on the device tree bindings submitted to upstream Linux. This is needed to enable power domains for devices that haven't been enabled by earlier boot stages. ChangeLog: v2: - Drop unrelated changes from device tree update Mark Kettenis (3): arm: dts: apple: Update Apple M1 device trees arm: dts: apple: Add u-boot,dm-pre-reloc properties power: domain: Add Apple pmgr driver arch/arm/Kconfig|3 + arch/arm/dts/Makefile |5 +- arch/arm/dts/t8103-j274-u-boot.dtsi |1 + arch/arm/dts/t8103-j274.dts | 122 +-- arch/arm/dts/t8103-j293-u-boot.dtsi |1 + arch/arm/dts/t8103-j293.dts | 92 +-- arch/arm/dts/t8103-j313-u-boot.dtsi |1 + arch/arm/dts/t8103-j313.dts | 57 ++ arch/arm/dts/t8103-j456-u-boot.dtsi |1 + arch/arm/dts/t8103-j456.dts | 71 ++ arch/arm/dts/t8103-j457-u-boot.dtsi |1 + arch/arm/dts/t8103-j457.dts | 59 ++ arch/arm/dts/t8103-jxxx.dtsi| 140 arch/arm/dts/t8103-pmgr.dtsi| 1136 +++ arch/arm/dts/t8103-u-boot.dtsi | 25 + arch/arm/dts/t8103.dtsi | 585 +++--- drivers/power/domain/Kconfig|8 + drivers/power/domain/Makefile |1 + drivers/power/domain/apple-pmgr.c | 113 +++ 19 files changed, 1994 insertions(+), 428 deletions(-) create mode 100644 arch/arm/dts/t8103-j274-u-boot.dtsi create mode 100644 arch/arm/dts/t8103-j293-u-boot.dtsi create mode 100644 arch/arm/dts/t8103-j313-u-boot.dtsi create mode 100644 arch/arm/dts/t8103-j313.dts create mode 100644 arch/arm/dts/t8103-j456-u-boot.dtsi create mode 100644 arch/arm/dts/t8103-j456.dts create mode 100644 arch/arm/dts/t8103-j457-u-boot.dtsi create mode 100644 arch/arm/dts/t8103-j457.dts create mode 100644 arch/arm/dts/t8103-jxxx.dtsi create mode 100644 arch/arm/dts/t8103-pmgr.dtsi create mode 100644 arch/arm/dts/t8103-u-boot.dtsi create mode 100644 drivers/power/domain/apple-pmgr.c -- 2.34.1
Re: [PATCH v2 0/3] Conformance Profiles Table support in U-boot
On 12/23/21 15:51, Jose Marinho wrote: patch v2: - address v1 comments - define EFI_EBBR_2_0_CONFORMANCE unconditionally. - introduce ECPT EFI selftet - drop the efidebug ECPT print The Conformance Profiles Table (ECPT) table will be included in the UEFI specification 2.9+. @Samer: The current spec draft assuming compliance if the table is not present makes no sense and needs to be fixed. U-Boot should not create a precedent of an implementation of this broken design. @Jose: As you cannot define under which circumstances the EBBR 2.0 GUID should be set we should not implement this table at all. Best regards Heinrich The ECPT table was introduced in UEFI following the code-first path. The acceptance ticket can be viewed at: https://bugzilla.tianocore.org/show_bug.cgi?id=3591 This patch set implements the ECPT table in U-boot. Jose Marinho (3): efi: Create ECPT table efi: ECPT add EBBRv2.0 conformance profile efi: ECPT EFI selftest cmd/efidebug.c | 4 + include/efi_api.h| 14 include/efi_loader.h | 7 ++ lib/efi_loader/Kconfig | 11 +++ lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_conformance.c | 75 +++ lib/efi_loader/efi_setup.c | 6 ++ lib/efi_selftest/Makefile| 2 + lib/efi_selftest/efi_selftest_ecpt.c | 105 +++ 9 files changed, 225 insertions(+) create mode 100644 lib/efi_loader/efi_conformance.c create mode 100644 lib/efi_selftest/efi_selftest_ecpt.c
Re: [PATCH 2/3] efi: ECPT add EBBRv2.0 conformance profile
On 12/23/21 15:57, Jose Marinho wrote:
Hi Heinrich,
Thank you for your reviews.
-Original Message-
From: Heinrich Schuchardt
Sent: 17 December 2021 17:27
To: Jose Marinho ; u-boot@lists.denx.de
Cc: ilias.apalodi...@linaro.org; sughosh.g...@linaro.org;
takahiro.aka...@linaro.org; ag...@csgraf.de; nd
Subject: Re: [PATCH 2/3] efi: ECPT add EBBRv2.0 conformance profile
On 12/17/21 13:55, Jose Marinho wrote:
Display the EBBRv2.0 conformance in the ECPT table.
The EBBRv2.0 conformance profile is set in the ECPT if
CONFIG_EFI_EBBR_2_0_CONFORMANCE=y.
The config defaults to 'n'.
Signed-off-by: Jose Marinho
---
include/efi_api.h| 4
lib/efi_loader/Kconfig | 6 ++
lib/efi_loader/efi_conformance.c | 9 +
3 files changed, 19 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h index
6fd4f04de3..49919caa35 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -230,6 +230,10 @@ enum efi_reset_type {
EFI_GUID(0x36122546, 0xf7ef, 0x4c8f, 0xbd, 0x9b, \
0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b)
+#define EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID \
+ EFI_GUID(0xcce33c35, 0x74ac, 0x4087, 0xbc, 0xe7, \
+0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27)
+
struct efi_conformance_profiles_table {
u16 version;
u16 number_of_profiles;
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index
b2398976f4..ab7476f68b 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -373,4 +373,10 @@ config EFI_ECPT
help
Enabling this option created the ECPT UEFI table.
+config EFI_EBBR_2_0_CONFORMANCE
+ bool "Add the EBBRv2.0 conformance entry to the ECPT table"
+ depends on EFI_ECPT
With this dependency the symbol EFI_EBBR_2_0_CONFORMANCE is
superfluous.
Can we add EFI_EBBR_2_0_CONFORMANCE unconditionally or are there
relevant configuration flags in U-Boot that must be enabled to claim EBBR 2.0
compliance? E.g.
* CONFIG_CMD_BOOTEFI_BOOTMGR
* CONFIG_EFI_GET_TIME
* CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT
I've removed the "depends on" in PATCH v2.
Ideally the EFI_EBBR_2_0_CONFORMANCE should depend on all the CONFIGS required
by EBBR 2.0.
I'm not sure whether this is feasible, i.e. whether there is a set of CONFIGS_*
which when enabled make the implementation EBBRv2.0 compliant.
Also, as the u-boot code evolves, these dependencies would need to be carefully
maintained perhaps.
Perhaps the best choice is to let the FW provider to set EBBR_2_0_CONFORMANCE
in the platform config file once the FW has been deemed EBBRv2.0 compliant.
The firmware provider is the U-Boot project. If we do not know under
which circumstances we might add the EBBR 2.0 conformance GUID, I prefer
not to implement the table at all.
Best regards
Heinrich
+ default n
+ help
+ Enabling this option adds the EBBRv2.0 conformance entry to the
ECPT UEFI table.
endif
diff --git a/lib/efi_loader/efi_conformance.c
b/lib/efi_loader/efi_conformance.c
index 86c26d6b79..b490ff3326 100644
--- a/lib/efi_loader/efi_conformance.c
+++ b/lib/efi_loader/efi_conformance.c
@@ -12,6 +12,7 @@
#include
const efi_guid_t efi_ecpt_guid =
EFI_CONFORMANCE_PROFILES_TABLE_GUID;
+const efi_guid_t efi_ebbr_2_0_guid =
+EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
#define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1
@@ -29,6 +30,9 @@ efi_status_t efi_ecpt_register(void)
EFI_PRINT("ECPT table creation start\n");
+ if (IS_ENABLED(CONFIG_EFI_EBBR_2_0_CONFORMANCE))
+ num_entries++;
+
ecpt_size = num_entries * sizeof(efi_guid_t)
+ sizeof(struct efi_conformance_profiles_table);
ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, ecpt_size, @@ -
44,6
+48,11 @@ efi_status_t efi_ecpt_register(void)
ecpt->version = EFI_CONFORMANCE_PROFILES_TABLE_VERSION;
ecpt->number_of_profiles = num_entries;
+ if (IS_ENABLED(CONFIG_EFI_EBBR_2_0_CONFORMANCE)) {
+ num_entries--;
+ guidcpy(>conformance_profiles[num_entries],
_ecpt_guid);
+ }
+
if (num_entries)
EFI_PRINT("ECPT check conformance profiles, not all entries
populated in table\n");
Re: [PATCH 0/3] Conformance Profiles Table support in U-boot
On 12/23/21 16:20, Jose Marinho wrote: Hi Heinrich, The change suggested in https://bugzilla.tianocore.org/show_bug.cgi?id=3591 is a not well designed: How could the missing of a table ever be taken as a sign of compliance? Below is my interpretation of intent behind the ECPT changes: The UEFI spec specifies a set of requirements for UEFI compliance in Section 2.6. Any complete UEFI implementation must adhere to the requirements in Section 2.6. The Conformance Profiles allow for "partial" UEFI implementations, which implement a subset of the full UEFI requirements. The conformance with a particular profile should be explicitly advertised (via the conformance profiles table). If not, then full compliance with the Section 2.6 requirements is assumed. How would an application make use of the table? What information does it provide that is not better obtained from API calls? With the ECPT, an application can easily detect the UEFI profile that's implemented and hence adopt a model of execution that suits that profile. Alternatively the application could probe the different RT services, UEFI variables, etc to "detect" a profile. The table allows for a more straightforward or simpler detection. U-Boot in many cases will not implement any of the profiles in full. E.g. GetTime() might be missing if there is no RTC. The table will not be very helpful as it will be empty in these cases. Why should we blow up the U-Boot code size with this - most of the time - useless table? As the table is not defined in UEFI 2.9 and no software uses it, why should we implement it? The code first UEFI ECR was accepted. Once a UEFI ECR is accepted it becomes part of the UEFI specification. Code first? https://bugzilla.tianocore.org/show_bug.cgi?id=3591 does not indicate any implementation of code using or providing the table. The way the new table was defined does not make sense. It is assumed that if the table is missing the UEFI implementation is compliant to the complete UEFI spec. This aspect needs to be fixed. It is not too late to do so. This is the paragraph that needs to change: "The absence of this table shall indicate that the platform implementation is conformant with the UEFI specification requirements, as defined in section 2.6. This is equivalent to publishing this configuration table with the EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID conformance profile." Best regards Heinrich Regards, Jose Best regards Heinrich The ECPT table was introduced in UEFI following the code-first path. The acceptance ticket can be viewed at: https://bugzilla.tianocore.org/show_bug.cgi?id=3591 This patch set implements the ECPT table in U-boot. Jose Marinho (3): efi: Create ECPT table efi: ECPT add EBBRv2.0 conformance profile cmd: efi: efidebug print ECPT table cmd/efidebug.c | 45 +++ include/efi_api.h| 14 ++ include/efi_loader.h | 9 lib/efi_loader/Kconfig | 12 + lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_conformance.c | 75 lib/efi_loader/efi_setup.c | 6 +++ 7 files changed, 162 insertions(+) create mode 100644 lib/efi_loader/efi_conformance.c
[PATCH] dm: Fix OF_BAD_ADDR definition
When OF_LIVE flag is enabled on a 64 bits platform, there is an
issue when dev_read_addr() is called and need to perform an address
translation using __of_translate_address().
In case of error, __of_translate_address() return value is OF_BAD_ADDR
(wich is defined in include/dm/of.h to ((u64)-1) = 0x).
The return value of dev_read_addr() is often compared to FDT_ADDR_T_NONE
which is defined as (-1U) = 0x.
In this case the comparison is always false.
To fix this issue, define OF_BAD_ADDR to FDT_ADDR_T_NONE.
Signed-off-by: Patrice Chotard
---
include/dm/of.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dm/of.h b/include/dm/of.h
index 5cb6f44a6c..0208cc234a 100644
--- a/include/dm/of.h
+++ b/include/dm/of.h
@@ -95,7 +95,7 @@ static inline bool of_live_active(void)
return gd_of_root() != NULL;
}
-#define OF_BAD_ADDR((u64)-1)
+#define OF_BAD_ADDRFDT_ADDR_T_NONE
static inline const char *of_node_full_name(const struct device_node *np)
{
--
2.17.1
RE: [PATCH 0/3] Conformance Profiles Table support in U-boot
Hi Heinrich, > > The change suggested in > https://bugzilla.tianocore.org/show_bug.cgi?id=3591 > is a not well designed: How could the missing of a table ever be taken as a > sign of compliance? > Below is my interpretation of intent behind the ECPT changes: The UEFI spec specifies a set of requirements for UEFI compliance in Section 2.6. Any complete UEFI implementation must adhere to the requirements in Section 2.6. The Conformance Profiles allow for "partial" UEFI implementations, which implement a subset of the full UEFI requirements. The conformance with a particular profile should be explicitly advertised (via the conformance profiles table). If not, then full compliance with the Section 2.6 requirements is assumed. > How would an application make use of the table? > What information does it provide that is not better obtained from API calls? > With the ECPT, an application can easily detect the UEFI profile that's implemented and hence adopt a model of execution that suits that profile. Alternatively the application could probe the different RT services, UEFI variables, etc to "detect" a profile. The table allows for a more straightforward or simpler detection. > As the table is not defined in UEFI 2.9 and no software uses it, why should we > implement it? The code first UEFI ECR was accepted. Once a UEFI ECR is accepted it becomes part of the UEFI specification. Regards, Jose > Best regards > > Heinrich > > > The ECPT table was introduced in UEFI following the code-first path. > > The acceptance ticket can be viewed at: > > https://bugzilla.tianocore.org/show_bug.cgi?id=3591 > > > > This patch set implements the ECPT table in U-boot. > > > > Jose Marinho (3): > >efi: Create ECPT table > >efi: ECPT add EBBRv2.0 conformance profile > >cmd: efi: efidebug print ECPT table > > > > cmd/efidebug.c | 45 +++ > > include/efi_api.h| 14 ++ > > include/efi_loader.h | 9 > > lib/efi_loader/Kconfig | 12 + > > lib/efi_loader/Makefile | 1 + > > lib/efi_loader/efi_conformance.c | 75 > > > lib/efi_loader/efi_setup.c | 6 +++ > > 7 files changed, 162 insertions(+) > > create mode 100644 lib/efi_loader/efi_conformance.c > >
Re: [PATCH 1/6] udoo_spl: Initialize the eSDHC controller in SPL
Hi Tom/Stefano, On Mon, Dec 20, 2021 at 1:10 PM Peter Robinson wrote: > Reviewed-by: Peter Robinson Please consider this series and Peter's series on udoo_neo for 2022.01. They make udoo and udoo_neo functional in U-Boot again.
RE: [PATCH 1/3] efi: Create ECPT table
Hi Heinrich,
> -Original Message-
> From: Heinrich Schuchardt
> Sent: 17 December 2021 17:20
> To: Jose Marinho ; u-boot@lists.denx.de
> Cc: ilias.apalodi...@linaro.org; sughosh.g...@linaro.org;
> takahiro.aka...@linaro.org; ag...@csgraf.de; nd
> Subject: Re: [PATCH 1/3] efi: Create ECPT table
>
> On 12/17/21 13:55, Jose Marinho wrote:
> > The ECPT table will be included in the UEFI specification 2.9+.
> > The ECPT table was introduced in UEFI following the code-first path.
> > The acceptance ticket can be viewed at:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=3591
> >
> > The Conformance Profiles table is a UEFI configuration table that
> > contains GUID of the UEFI profiles that the UEFI implementation conforms
> with.
> >
> > The ECPT table is created when CONFIG_EFI_ECPT=y.
> > The config is set by default.
> >
> > Signed-off-by: Jose Marinho
> > ---
> > cmd/efidebug.c | 4 ++
> > include/efi_api.h| 10 +
> > include/efi_loader.h | 7
> > lib/efi_loader/Kconfig | 6 +++
> > lib/efi_loader/Makefile | 1 +
> > lib/efi_loader/efi_conformance.c | 66
>
> > lib/efi_loader/efi_setup.c | 6 +++
> > 7 files changed, 100 insertions(+)
> > create mode 100644 lib/efi_loader/efi_conformance.c
> >
> > diff --git a/cmd/efidebug.c b/cmd/efidebug.c index
> > a977ca9c72..a53a5029fa 100644
> > --- a/cmd/efidebug.c
> > +++ b/cmd/efidebug.c
> > @@ -619,6 +619,10 @@ static const struct {
> > "TCG2 Final Events Table",
> > EFI_TCG2_FINAL_EVENTS_TABLE_GUID,
> > },
> > + {
> > + "EFI Conformance Profiles Table",
> > + EFI_CONFORMANCE_PROFILES_TABLE_GUID,
>
> Just as side note. Consider sending a patch for GRUB to amend:
>
> grub-core/commands/efi/lsefisystab.c
> include/grub/efi/api.h
>
> > + },
> > };
> >
> > /**
> > diff --git a/include/efi_api.h b/include/efi_api.h index
> > 80109f012b..6fd4f04de3 100644
> > --- a/include/efi_api.h
> > +++ b/include/efi_api.h
> > @@ -226,6 +226,16 @@ enum efi_reset_type {
> > EFI_GUID(0x6dcbd5ed, 0xe82d, 0x4c44, 0xbd, 0xa1, \
> > 0x71, 0x94, 0x19, 0x9a, 0xd9, 0x2a)
> >
> > +#define EFI_CONFORMANCE_PROFILES_TABLE_GUID \
> > + EFI_GUID(0x36122546, 0xf7ef, 0x4c8f, 0xbd, 0x9b, \
> > +0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b)
> > +
> > +struct efi_conformance_profiles_table {
> > + u16 version;
> > + u16 number_of_profiles;
> > + efi_guid_t conformance_profiles[];
> > +} __packed;
> > +
> > struct efi_capsule_header {
> > efi_guid_t capsule_guid;
> > u32 header_size;
> > diff --git a/include/efi_loader.h b/include/efi_loader.h index
> > d52e399841..d20ff396d0 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -976,6 +976,13 @@ efi_status_t efi_capsule_authenticate(const void
> *capsule,
> >*/
> > efi_status_t efi_esrt_register(void);
> >
> > +/**
> > + * efi_ecpt_register() - Install the ECPT system table.
> > + *
> > + * Return: status code
> > + */
> > +efi_status_t efi_ecpt_register(void);
> > +
> > /**
> >* efi_esrt_populate() - Populates the ESRT entries from the FMP
> instances
> >* present in the system.
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index
> > 700dc838dd..b2398976f4 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -367,4 +367,10 @@ config EFI_ESRT
> > help
> > Enabling this option creates the ESRT UEFI system table.
> >
> > +config EFI_ECPT
> > + bool "Enable the UEFI ECPT generation"
> > + default y
> > + help
> > + Enabling this option created the ECPT UEFI table.
> > +
> > endif
> > diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index
> > fd344cea29..9f5a0cebd1 100644
> > --- a/lib/efi_loader/Makefile
> > +++ b/lib/efi_loader/Makefile
> > @@ -64,6 +64,7 @@ obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
> > obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
> > obj-$(CONFIG_EFI_LOAD_FILE2_INITRD) += efi_load_initrd.o
> > obj-$(CONFIG_EFI_SIGNATURE_SUPPORT) += efi_signature.o
> > +obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
> >
> > EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
> > $(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE) diff --git
> > a/lib/efi_loader/efi_conformance.c b/lib/efi_loader/efi_conformance.c
> > new file mode 100644
> > index 00..86c26d6b79
> > --- /dev/null
> > +++ b/lib/efi_loader/efi_conformance.c
> > @@ -0,0 +1,66 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * EFI conformance profile table
> > + *
> > + * Copyright (C) 2022 Arm Ltd.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +const efi_guid_t efi_ecpt_guid =
> EFI_CONFORMANCE_PROFILES_TABLE_GUID;
> > +
> > +#define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1
> > +
> > +/**
> > + * efi_ecpt_register() - Install
Re: [PATCH v2 2/3] efi: ECPT add EBBRv2.0 conformance profile
Hi Jose, On Thu, Dec 23, 2021 at 11:52 AM Jose Marinho wrote: > The config defaults to 'n'. No need to mention this as it is the standard. > +config EFI_EBBR_2_0_CONFORMANCE > + bool "Add the EBBRv2.0 conformance entry to the ECPT table" > + default n You should remove "default n"
RE: [PATCH 3/3] cmd: efi: efidebug print ECPT table
Hi Heinrich,
I dropped the ECPT print in efidebug in PATCH v2. Additionally I've introduced
an efi selftet.
Regards,
Jose
> -Original Message-
> From: Heinrich Schuchardt
> Sent: 17 December 2021 18:07
> To: Jose Marinho ; u-boot@lists.denx.de
> Cc: ilias.apalodi...@linaro.org; sughosh.g...@linaro.org;
> takahiro.aka...@linaro.org; ag...@csgraf.de; nd
> Subject: Re: [PATCH 3/3] cmd: efi: efidebug print ECPT table
>
> On 12/17/21 13:55, Jose Marinho wrote:
> > Signed-off-by: Jose Marinho
> > ---
> > cmd/efidebug.c | 41
> +
> > include/efi_loader.h | 2 ++
> > 2 files changed, 43 insertions(+)
> >
> > diff --git a/cmd/efidebug.c b/cmd/efidebug.c index
> > a53a5029fa..c3246e1820 100644
> > --- a/cmd/efidebug.c
> > +++ b/cmd/efidebug.c
> > @@ -889,6 +889,38 @@ static int do_efi_show_tables(struct cmd_tbl
> *cmdtp, int flag,
> > return CMD_RET_SUCCESS;
> > }
> >
> > +#ifdef CONFIG_EFI_ECPT
> > +static int do_efi_ecpt(struct cmd_tbl *cmdtp, int flag,
> > + int argc, char * const argv[]) {
> > + struct efi_conformance_profiles_table *ecpt;
> > +
> > + if (argc != 1)
> > + return CMD_RET_USAGE;
> > +
> > + for (int idx = 0; idx < systab.nr_tables; idx++)
> > + if (!guidcmp(_ecpt_guid, [idx].guid))
> > + ecpt = (struct efi_system_resource_table
> > +*)systab.tables[idx].table;
> > +
> > + if (!ecpt) {
> > + log_info("ECPT: table not present\n");
> > + return CMD_RET_SUCCESS;
> > + }
> > +
> > + const int num_profiles = ecpt->number_of_profiles;
> > +
> > + printf("\n");
> > + printf("ECPT: version:%d\n", ecpt->version);
> > + printf("ECPT: num profiles:%d\n", num_profiles);
> > +
> > + for (int i = 0; i < num_profiles; i++)
> > + printf("ECPT: profile %d = %pUL\n", i,
> >conformance_profiles[i]);
> > + printf("\n");
> > +
> > + return CMD_RET_SUCCESS;
> > +}
> > +#endif /* CONFIG_EFI_ECPT */
> > +
> > /**
> >* create_initrd_dp() - Create a special device for our Boot### option
> >*
> > @@ -1681,6 +1713,11 @@ static struct cmd_tbl cmd_efidebug_sub[] = {
> > "", ""),
> > U_BOOT_CMD_MKENT(query, CONFIG_SYS_MAXARGS, 1,
> do_efi_query_info,
> > "", ""),
> > +#ifdef CONFIG_EFI_ECPT
> > + U_BOOT_CMD_MKENT(ecpt, CONFIG_SYS_MAXARGS, 1,
> do_efi_ecpt,
> > +"", ""),
> > +#endif
> > +
> > };
> >
> > /**
> > @@ -1769,6 +1806,10 @@ static char efidebug_help_text[] =
> > " - show UEFI memory map\n"
> > "efidebug tables\n"
> > " - show UEFI configuration tables\n"
> > +#ifdef CONFIG_EFI_ECPT
> > + "efidebug ecpt\n"
> > + " - show UEFI conformance profiles table\n"
> > +#endif
> > #ifdef CONFIG_CMD_BOOTEFI_BOOTMGR
> > "efidebug test bootmgr\n"
> > " - run simple bootmgr for test\n"
> > diff --git a/include/efi_loader.h b/include/efi_loader.h index
> > d20ff396d0..d60a340136 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -310,6 +310,8 @@ extern const efi_guid_t
> efi_guid_firmware_management_protocol;
> > extern const efi_guid_t efi_esrt_guid;
> > /* GUID of the SMBIOS table */
> > extern const efi_guid_t smbios_guid;
> > +/* GUID for the ECPT */
> > +extern const efi_guid_t efi_ecpt_guid;
> >
> > extern char __efi_runtime_start[], __efi_runtime_stop[];
> > extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
>
> Our interest is to keep the U-Boot binary size small. I see no need to print
> the
> ECPT table.
>
> What make more sense is a unit test that checks the consistency of the table.
>
> Best regards
>
> Heinrich
RE: [PATCH 2/3] efi: ECPT add EBBRv2.0 conformance profile
Hi Heinrich,
Thank you for your reviews.
> -Original Message-
> From: Heinrich Schuchardt
> Sent: 17 December 2021 17:27
> To: Jose Marinho ; u-boot@lists.denx.de
> Cc: ilias.apalodi...@linaro.org; sughosh.g...@linaro.org;
> takahiro.aka...@linaro.org; ag...@csgraf.de; nd
> Subject: Re: [PATCH 2/3] efi: ECPT add EBBRv2.0 conformance profile
>
> On 12/17/21 13:55, Jose Marinho wrote:
> > Display the EBBRv2.0 conformance in the ECPT table.
> >
> > The EBBRv2.0 conformance profile is set in the ECPT if
> > CONFIG_EFI_EBBR_2_0_CONFORMANCE=y.
> > The config defaults to 'n'.
> >
> >
> > Signed-off-by: Jose Marinho
> > ---
> > include/efi_api.h| 4
> > lib/efi_loader/Kconfig | 6 ++
> > lib/efi_loader/efi_conformance.c | 9 +
> > 3 files changed, 19 insertions(+)
> >
> > diff --git a/include/efi_api.h b/include/efi_api.h index
> > 6fd4f04de3..49919caa35 100644
> > --- a/include/efi_api.h
> > +++ b/include/efi_api.h
> > @@ -230,6 +230,10 @@ enum efi_reset_type {
> > EFI_GUID(0x36122546, 0xf7ef, 0x4c8f, 0xbd, 0x9b, \
> > 0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b)
> >
> > +#define EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID \
> > + EFI_GUID(0xcce33c35, 0x74ac, 0x4087, 0xbc, 0xe7, \
> > +0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27)
> > +
> > struct efi_conformance_profiles_table {
> > u16 version;
> > u16 number_of_profiles;
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index
> > b2398976f4..ab7476f68b 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -373,4 +373,10 @@ config EFI_ECPT
> > help
> > Enabling this option created the ECPT UEFI table.
> >
> > +config EFI_EBBR_2_0_CONFORMANCE
> > + bool "Add the EBBRv2.0 conformance entry to the ECPT table"
> > + depends on EFI_ECPT
>
> With this dependency the symbol EFI_EBBR_2_0_CONFORMANCE is
> superfluous.
>
> Can we add EFI_EBBR_2_0_CONFORMANCE unconditionally or are there
> relevant configuration flags in U-Boot that must be enabled to claim EBBR 2.0
> compliance? E.g.
>
> * CONFIG_CMD_BOOTEFI_BOOTMGR
> * CONFIG_EFI_GET_TIME
> * CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT
>
I've removed the "depends on" in PATCH v2.
Ideally the EFI_EBBR_2_0_CONFORMANCE should depend on all the CONFIGS required
by EBBR 2.0.
I'm not sure whether this is feasible, i.e. whether there is a set of CONFIGS_*
which when enabled make the implementation EBBRv2.0 compliant.
Also, as the u-boot code evolves, these dependencies would need to be carefully
maintained perhaps.
Perhaps the best choice is to let the FW provider to set EBBR_2_0_CONFORMANCE
in the platform config file once the FW has been deemed EBBRv2.0 compliant.
>
> > + default n
> > + help
> > + Enabling this option adds the EBBRv2.0 conformance entry to the
> ECPT UEFI table.
> > endif
> > diff --git a/lib/efi_loader/efi_conformance.c
> > b/lib/efi_loader/efi_conformance.c
> > index 86c26d6b79..b490ff3326 100644
> > --- a/lib/efi_loader/efi_conformance.c
> > +++ b/lib/efi_loader/efi_conformance.c
> > @@ -12,6 +12,7 @@
> > #include
> >
> > const efi_guid_t efi_ecpt_guid =
> > EFI_CONFORMANCE_PROFILES_TABLE_GUID;
> > +const efi_guid_t efi_ebbr_2_0_guid =
> > +EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
> >
> > #define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1
> >
> > @@ -29,6 +30,9 @@ efi_status_t efi_ecpt_register(void)
> >
> > EFI_PRINT("ECPT table creation start\n");
> >
> > + if (IS_ENABLED(CONFIG_EFI_EBBR_2_0_CONFORMANCE))
> > + num_entries++;
> > +
> > ecpt_size = num_entries * sizeof(efi_guid_t)
> > + sizeof(struct efi_conformance_profiles_table);
> > ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, ecpt_size, @@ -
> 44,6
> > +48,11 @@ efi_status_t efi_ecpt_register(void)
> > ecpt->version = EFI_CONFORMANCE_PROFILES_TABLE_VERSION;
> > ecpt->number_of_profiles = num_entries;
> >
> > + if (IS_ENABLED(CONFIG_EFI_EBBR_2_0_CONFORMANCE)) {
> > + num_entries--;
> > + guidcpy(>conformance_profiles[num_entries],
> _ecpt_guid);
> > + }
> > +
> > if (num_entries)
> > EFI_PRINT("ECPT check conformance profiles, not all entries
> > populated in table\n");
> >
Re: [PATCH V2] usb: ehci-mx6: Enable OTG detection on imx8mm and imx8mn
Hi Adam, On Thu, Dec 23, 2021 at 11:08 AM Adam Ford wrote: > > The imx8mm and imx8mn appear compatible with imx7d-usb > flags in the OTG driver. If the dr_mode is defined as > host or peripheral, the device appears to operate correctly, > however the auto host/peripheral detection results in an error. > > The solution isn't just adding checks for imx8mm and imx8mn to > the check for imx7, because the USB clock needs to be running > to read from the USBNC_PHY_STATUS_OFFSET register or it will hang. > > The init_type in both priv and plat data are the same, so it doesn't > make sense to configure the data in the plat data and copy the > data to priv when priv can be configured directly. Instead, rename > ehci_usb_of_to_plat to ehci_usb_dr_mode and call it from the > probe functions after the clocks are enabled, but before the data > is required. > > With that added, the additional checks for imx8mm and imx8mn will > allow reading the register to automatically determine the state > (host or device) of the OTG controller. > > Signed-off-by: Adam Ford Tested "ums 0 mmc 0" on a imx7s-warp. It still works fine: Tested-by: Fabio Estevam
[PATCH v2 3/3] efi: ECPT EFI selftest
This test ensures the ECPT table is present and is consistent.
Invocation from the sandbox platform:
add to sandbox_defconfig:
+CONFIG_CMD_BOOTEFI_SELFTEST=y
make sandbox_capsule_defconfig all
./u-boot -d arch/sandbox/dts/test.dtb
bootefi selftest
Signed-off-by: Jose Marinho
---
lib/efi_selftest/Makefile| 2 +
lib/efi_selftest/efi_selftest_ecpt.c | 105 +++
2 files changed, 107 insertions(+)
create mode 100644 lib/efi_selftest/efi_selftest_ecpt.c
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 9ff6e1760c..6cf548653f 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -112,3 +112,5 @@ $(obj)/efi_selftest_loadimage.o:
$(obj)/efi_miniapp_file_image_exit.h
$(obj)/efi_selftest_startimage_exit.o: $(obj)/efi_miniapp_file_image_exit.h
$(obj)/efi_selftest_startimage_return.o: $(obj)/efi_miniapp_file_image_return.h
+
+obj-$(CONFIG_EFI_ECPT) += efi_selftest_ecpt.o
diff --git a/lib/efi_selftest/efi_selftest_ecpt.c
b/lib/efi_selftest/efi_selftest_ecpt.c
new file mode 100644
index 00..555b59bc90
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_ecpt.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test ECPT tables support
+ *
+ * Copyright (C) 2022 Arm Ltd.
+ */
+#include
+#include
+#include
+
+static const struct efi_system_table *local_systable;
+
+/*
+ * Setup unit test.
+ *
+ * @handle:handle of the loaded image
+ * @systable: system table
+ * @return:EFI_ST_SUCCESS for success
+ */
+static int setup(const efi_handle_t handle,
+const struct efi_system_table *systable)
+{
+ local_systable = systable;
+
+ return EFI_ST_SUCCESS;
+}
+
+/*
+ * Traverse the ECPT table looking for a particular profile.
+ *
+ * @profile_guid: the guid of the conformance profile to find
+ * @ecpt: a pointer to the ECPT table
+ * @return: true if profile_guid is an entry in ECPT, false otherwise
+ */
+static bool find_profile(efi_guid_t *profile_guid,
+struct efi_conformance_profiles_table *ecpt)
+{
+ for (int idx = 0; idx < local_systable->nr_tables; idx++)
+ if (!guidcmp(profile_guid, >conformance_profiles[idx]))
+ return true;
+ return false;
+}
+
+/*
+ * Perform the test
+ *
+ * The test consists of the following steps:
+ *
+ * 1) Obtain the ECPT
+ * 2) Quantify the number of expected profiles
+ * 3) Verify that each expected profile is in the ECPT
+ * 4) Ensure that the number of ECPT entries is the expected
+ *
+ * The failure of any of the above steps results in a test failure.
+ *
+ */
+static int execute(void)
+{
+ struct efi_conformance_profiles_table *ecpt;
+ efi_status_t ret = EFI_SUCCESS;
+ struct efi_boot_services *bt;
+ int expected_num_entries;
+
+ bt = local_systable->boottime;
+
+ if (!bt) {
+ efi_st_error("Cannot find boottime services structure\n");
+ return EFI_ST_FAILURE;
+ }
+
+ for (int idx = 0; idx < local_systable->nr_tables; idx++)
+ if (!guidcmp(_ecpt_guid, _systable->tables[idx].guid))
+ ecpt = (struct efi_conformance_profiles_table *)
+ local_systable->tables[idx].table;
+
+ if (!ecpt) {
+ efi_st_error("ECPT table not present\n");
+ return EFI_ST_FAILURE;
+ }
+
+ /*
+* Check for presence of each expected profile.
+*/
+ if (IS_ENABLED(CONFIG_EFI_EBBR_2_0_CONFORMANCE)) {
+ expected_num_entries++;
+ if (!find_profile(_ecpt_guid, ecpt)) {
+ efi_st_error("failed to find profile %pUL\n",
_ecpt_guid);
+ return EFI_ST_FAILURE;
+ }
+ }
+
+ if (ecpt->number_of_profiles != expected_num_entries) {
+ efi_st_error("Mismatch in number of ECPT entries\n");
+ return EFI_ST_FAILURE;
+ }
+
+ return EFI_ST_SUCCESS;
+}
+
+EFI_UNIT_TEST(ecpt) = {
+ .name = "ecpt",
+ .phase = EFI_EXECUTE_BEFORE_BOOTTIME_EXIT,
+ .setup = setup,
+ .execute = execute,
+};
--
2.25.1
[PATCH v2 1/3] efi: Create ECPT table
The ECPT table will be included in the UEFI specification 2.9+.
The ECPT table was introduced in UEFI following the code-first path. The
acceptance ticket can be viewed at:
https://bugzilla.tianocore.org/show_bug.cgi?id=3591
The Conformance Profiles table is a UEFI configuration table that contains
GUID of the UEFI profiles that the UEFI implementation conforms with.
The ECPT table is created when CONFIG_EFI_ECPT=y.
The config is set by default.
Signed-off-by: Jose Marinho
---
cmd/efidebug.c | 4 ++
include/efi_api.h| 10 +
include/efi_loader.h | 7
lib/efi_loader/Kconfig | 6 +++
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_conformance.c | 66
lib/efi_loader/efi_setup.c | 6 +++
7 files changed, 100 insertions(+)
create mode 100644 lib/efi_loader/efi_conformance.c
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index a977ca9c72..a53a5029fa 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -619,6 +619,10 @@ static const struct {
"TCG2 Final Events Table",
EFI_TCG2_FINAL_EVENTS_TABLE_GUID,
},
+ {
+ "EFI Conformance Profiles Table",
+ EFI_CONFORMANCE_PROFILES_TABLE_GUID,
+ },
};
/**
diff --git a/include/efi_api.h b/include/efi_api.h
index 80109f012b..6fd4f04de3 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -226,6 +226,16 @@ enum efi_reset_type {
EFI_GUID(0x6dcbd5ed, 0xe82d, 0x4c44, 0xbd, 0xa1, \
0x71, 0x94, 0x19, 0x9a, 0xd9, 0x2a)
+#define EFI_CONFORMANCE_PROFILES_TABLE_GUID \
+ EFI_GUID(0x36122546, 0xf7ef, 0x4c8f, 0xbd, 0x9b, \
+0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b)
+
+struct efi_conformance_profiles_table {
+ u16 version;
+ u16 number_of_profiles;
+ efi_guid_t conformance_profiles[];
+} __packed;
+
struct efi_capsule_header {
efi_guid_t capsule_guid;
u32 header_size;
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d52e399841..d20ff396d0 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -976,6 +976,13 @@ efi_status_t efi_capsule_authenticate(const void *capsule,
*/
efi_status_t efi_esrt_register(void);
+/**
+ * efi_ecpt_register() - Install the ECPT system table.
+ *
+ * Return: status code
+ */
+efi_status_t efi_ecpt_register(void);
+
/**
* efi_esrt_populate() - Populates the ESRT entries from the FMP instances
* present in the system.
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 700dc838dd..b2398976f4 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -367,4 +367,10 @@ config EFI_ESRT
help
Enabling this option creates the ESRT UEFI system table.
+config EFI_ECPT
+ bool "Enable the UEFI ECPT generation"
+ default y
+ help
+ Enabling this option created the ECPT UEFI table.
+
endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index fd344cea29..9f5a0cebd1 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
obj-$(CONFIG_EFI_LOAD_FILE2_INITRD) += efi_load_initrd.o
obj-$(CONFIG_EFI_SIGNATURE_SUPPORT) += efi_signature.o
+obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
$(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
diff --git a/lib/efi_loader/efi_conformance.c b/lib/efi_loader/efi_conformance.c
new file mode 100644
index 00..1bb06c3b7e
--- /dev/null
+++ b/lib/efi_loader/efi_conformance.c
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * EFI conformance profile table
+ *
+ * Copyright (C) 2022 Arm Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+const efi_guid_t efi_ecpt_guid = EFI_CONFORMANCE_PROFILES_TABLE_GUID;
+
+#define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1
+
+/**
+ * efi_ecpt_register() - Install the ECPT system table.
+ *
+ * Return: status code
+ */
+efi_status_t efi_ecpt_register(void)
+{
+ int num_entries = 0;
+ struct efi_conformance_profiles_table *ecpt;
+ efi_status_t ret;
+ size_t ecpt_size = 0;
+
+ efi_debug("ECPT table creation start\n");
+
+ ecpt_size = num_entries * sizeof(efi_guid_t)
+ + sizeof(struct efi_conformance_profiles_table);
+ ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, ecpt_size,
+ (void **));
+
+ if (ret != EFI_SUCCESS) {
+ efi_debug("ECPT cannot allocate memory for %u entries (%zu
bytes)\n",
+ num_entries, ecpt_size);
+
+ return ret;
+ }
+
+ ecpt->version = EFI_CONFORMANCE_PROFILES_TABLE_VERSION;
+ ecpt->number_of_profiles = num_entries;
+
+ if (num_entries)
+ efi_debug("ECPT check conformance
[PATCH v2 0/3] Conformance Profiles Table support in U-boot
patch v2: - address v1 comments - define EFI_EBBR_2_0_CONFORMANCE unconditionally. - introduce ECPT EFI selftet - drop the efidebug ECPT print The Conformance Profiles Table (ECPT) table will be included in the UEFI specification 2.9+. The ECPT table was introduced in UEFI following the code-first path. The acceptance ticket can be viewed at: https://bugzilla.tianocore.org/show_bug.cgi?id=3591 This patch set implements the ECPT table in U-boot. Jose Marinho (3): efi: Create ECPT table efi: ECPT add EBBRv2.0 conformance profile efi: ECPT EFI selftest cmd/efidebug.c | 4 + include/efi_api.h| 14 include/efi_loader.h | 7 ++ lib/efi_loader/Kconfig | 11 +++ lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_conformance.c | 75 +++ lib/efi_loader/efi_setup.c | 6 ++ lib/efi_selftest/Makefile| 2 + lib/efi_selftest/efi_selftest_ecpt.c | 105 +++ 9 files changed, 225 insertions(+) create mode 100644 lib/efi_loader/efi_conformance.c create mode 100644 lib/efi_selftest/efi_selftest_ecpt.c -- 2.25.1
[PATCH v2 2/3] efi: ECPT add EBBRv2.0 conformance profile
Display the EBBRv2.0 conformance in the ECPT table.
The EBBRv2.0 conformance profile is set in the ECPT if
CONFIG_EFI_EBBR_2_0_CONFORMANCE=y.
The config defaults to 'n'.
Signed-off-by: Jose Marinho
---
include/efi_api.h| 4
lib/efi_loader/Kconfig | 5 +
lib/efi_loader/efi_conformance.c | 9 +
3 files changed, 18 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h
index 6fd4f04de3..49919caa35 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -230,6 +230,10 @@ enum efi_reset_type {
EFI_GUID(0x36122546, 0xf7ef, 0x4c8f, 0xbd, 0x9b, \
0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b)
+#define EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID \
+ EFI_GUID(0xcce33c35, 0x74ac, 0x4087, 0xbc, 0xe7, \
+0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27)
+
struct efi_conformance_profiles_table {
u16 version;
u16 number_of_profiles;
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index b2398976f4..9688d48366 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -373,4 +373,9 @@ config EFI_ECPT
help
Enabling this option created the ECPT UEFI table.
+config EFI_EBBR_2_0_CONFORMANCE
+ bool "Add the EBBRv2.0 conformance entry to the ECPT table"
+ default n
+ help
+ Enabling this option adds the EBBRv2.0 conformance entry to the ECPT
UEFI table.
endif
diff --git a/lib/efi_loader/efi_conformance.c b/lib/efi_loader/efi_conformance.c
index 1bb06c3b7e..325afe2d56 100644
--- a/lib/efi_loader/efi_conformance.c
+++ b/lib/efi_loader/efi_conformance.c
@@ -12,6 +12,7 @@
#include
const efi_guid_t efi_ecpt_guid = EFI_CONFORMANCE_PROFILES_TABLE_GUID;
+const efi_guid_t efi_ebbr_2_0_guid = EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
#define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1
@@ -29,6 +30,9 @@ efi_status_t efi_ecpt_register(void)
efi_debug("ECPT table creation start\n");
+ if (IS_ENABLED(CONFIG_EFI_EBBR_2_0_CONFORMANCE))
+ num_entries++;
+
ecpt_size = num_entries * sizeof(efi_guid_t)
+ sizeof(struct efi_conformance_profiles_table);
ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, ecpt_size,
@@ -44,6 +48,11 @@ efi_status_t efi_ecpt_register(void)
ecpt->version = EFI_CONFORMANCE_PROFILES_TABLE_VERSION;
ecpt->number_of_profiles = num_entries;
+ if (IS_ENABLED(CONFIG_EFI_EBBR_2_0_CONFORMANCE)) {
+ num_entries--;
+ guidcpy(>conformance_profiles[num_entries],
_ecpt_guid);
+ }
+
if (num_entries)
efi_debug("ECPT check conformance profiles, not all entries
populated in table\n");
--
2.25.1
[PATCH V2] usb: ehci-mx6: Enable OTG detection on imx8mm and imx8mn
The imx8mm and imx8mn appear compatible with imx7d-usb
flags in the OTG driver. If the dr_mode is defined as
host or peripheral, the device appears to operate correctly,
however the auto host/peripheral detection results in an error.
The solution isn't just adding checks for imx8mm and imx8mn to
the check for imx7, because the USB clock needs to be running
to read from the USBNC_PHY_STATUS_OFFSET register or it will hang.
The init_type in both priv and plat data are the same, so it doesn't
make sense to configure the data in the plat data and copy the
data to priv when priv can be configured directly. Instead, rename
ehci_usb_of_to_plat to ehci_usb_dr_mode and call it from the
probe functions after the clocks are enabled, but before the data
is required.
With that added, the additional checks for imx8mm and imx8mn will
allow reading the register to automatically determine the state
(host or device) of the OTG controller.
Signed-off-by: Adam Ford
---
V2: Rename ehci_usb_of_to_plat to ehci_usb_dr_mode and call it
from the probe after the clocks are enabled, but before
the data is needed.
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 1bd6147c76..f2a34b7f06 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -513,7 +513,7 @@ static const struct ehci_ops mx6_ehci_ops = {
static int ehci_usb_phy_mode(struct udevice *dev)
{
- struct usb_plat *plat = dev_get_plat(dev);
+ struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
void *__iomem addr = dev_read_addr_ptr(dev);
void *__iomem phy_ctrl, *__iomem phy_status;
const void *blob = gd->fdt_blob;
@@ -540,18 +540,18 @@ static int ehci_usb_phy_mode(struct udevice *dev)
val = readl(phy_ctrl);
if (val & USBPHY_CTRL_OTG_ID)
- plat->init_type = USB_INIT_DEVICE;
+ priv->init_type = USB_INIT_DEVICE;
else
- plat->init_type = USB_INIT_HOST;
- } else if (is_mx7()) {
+ priv->init_type = USB_INIT_HOST;
+ } else if (is_mx7() || is_imx8mm() || is_imx8mn()) {
phy_status = (void __iomem *)(addr +
USBNC_PHY_STATUS_OFFSET);
val = readl(phy_status);
if (val & USBNC_PHYSTATUS_ID_DIG)
- plat->init_type = USB_INIT_DEVICE;
+ priv->init_type = USB_INIT_DEVICE;
else
- plat->init_type = USB_INIT_HOST;
+ priv->init_type = USB_INIT_HOST;
} else {
return -EINVAL;
}
@@ -559,19 +559,19 @@ static int ehci_usb_phy_mode(struct udevice *dev)
return 0;
}
-static int ehci_usb_of_to_plat(struct udevice *dev)
+static int ehci_usb_dr_mode(struct udevice *dev)
{
- struct usb_plat *plat = dev_get_plat(dev);
+ struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
enum usb_dr_mode dr_mode;
dr_mode = usb_get_dr_mode(dev_ofnode(dev));
switch (dr_mode) {
case USB_DR_MODE_HOST:
- plat->init_type = USB_INIT_HOST;
+ priv->init_type = USB_INIT_HOST;
break;
case USB_DR_MODE_PERIPHERAL:
- plat->init_type = USB_INIT_DEVICE;
+ priv->init_type = USB_INIT_DEVICE;
break;
case USB_DR_MODE_OTG:
case USB_DR_MODE_UNKNOWN:
@@ -639,10 +639,8 @@ static int mx6_parse_dt_addrs(struct udevice *dev)
static int ehci_usb_probe(struct udevice *dev)
{
- struct usb_plat *plat = dev_get_plat(dev);
struct usb_ehci *ehci = dev_read_addr_ptr(dev);
struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
- enum usb_init_type type = plat->init_type;
struct ehci_hccr *hccr;
struct ehci_hcor *hcor;
int ret;
@@ -660,8 +658,6 @@ static int ehci_usb_probe(struct udevice *dev)
return ret;
priv->ehci = ehci;
- priv->init_type = type;
- priv->phy_type = usb_get_phy_mode(dev_ofnode(dev));
#if CONFIG_IS_ENABLED(CLK)
ret = clk_get_by_index(dev, 0, >clk);
@@ -677,6 +673,11 @@ static int ehci_usb_probe(struct udevice *dev)
mdelay(1);
#endif
+ ret = ehci_usb_dr_mode(dev);
+ if (ret)
+ goto err_clk;
+ priv->phy_type = usb_get_phy_mode(dev_ofnode(dev));
+
#if CONFIG_IS_ENABLED(DM_REGULATOR)
ret = device_get_supply_regulator(dev, "vbus-supply",
>vbus_supply);
@@ -700,7 +701,7 @@ static int ehci_usb_probe(struct udevice *dev)
#if CONFIG_IS_ENABLED(DM_REGULATOR)
if (priv->vbus_supply) {
ret = regulator_set_enable(priv->vbus_supply,
- (type == USB_INIT_DEVICE) ?
+ (priv->init_type == USB_INIT_DEVICE)
?
[PATCH] dma: ti: k3-udma: Fix rflow reservation for PKTDMA
Driver has a bug in that it uses rflow_in_use bitmap when setting up free rflow
range
from TISCI but use rflow_map for reservation in __udma_reserve_rflow()
Fix this by dropping rflow_in_use bitmap array and use rflow_map for
PKTDMA. BCDMA does not need rflow_in_use either.
This fixes CPSW3g not able to get DMA channels at R5 SPL on AM64x
Signed-off-by: Vignesh Raghavendra
---
drivers/dma/ti/k3-udma.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 411edef3a7..86603d43f1 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -165,7 +165,6 @@ struct udma_dev {
unsigned long *rchan_map;
unsigned long *rflow_map;
unsigned long *rflow_map_reserved;
- unsigned long *rflow_in_use;
unsigned long *tflow_map;
struct udma_bchan *bchans;
@@ -1448,15 +1447,11 @@ static int bcdma_setup_resources(struct udma_dev *ud)
sizeof(unsigned long), GFP_KERNEL);
ud->rchans = devm_kcalloc(dev, ud->rchan_cnt, sizeof(*ud->rchans),
GFP_KERNEL);
- /* BCDMA do not really have flows, but the driver expect it */
- ud->rflow_in_use = devm_kcalloc(dev, BITS_TO_LONGS(ud->rchan_cnt),
- sizeof(unsigned long),
- GFP_KERNEL);
ud->rflows = devm_kcalloc(dev, ud->rchan_cnt, sizeof(*ud->rflows),
GFP_KERNEL);
if (!ud->bchan_map || !ud->tchan_map || !ud->rchan_map ||
- !ud->rflow_in_use || !ud->bchans || !ud->tchans || !ud->rchans ||
+ !ud->bchans || !ud->tchans || !ud->rchans ||
!ud->rflows)
return -ENOMEM;
@@ -1535,16 +1530,16 @@ static int pktdma_setup_resources(struct udma_dev *ud)
sizeof(unsigned long), GFP_KERNEL);
ud->rchans = devm_kcalloc(dev, ud->rchan_cnt, sizeof(*ud->rchans),
GFP_KERNEL);
- ud->rflow_in_use = devm_kcalloc(dev, BITS_TO_LONGS(ud->rflow_cnt),
- sizeof(unsigned long),
- GFP_KERNEL);
+ ud->rflow_map = devm_kcalloc(dev, BITS_TO_LONGS(ud->rflow_cnt),
+sizeof(unsigned long),
+GFP_KERNEL);
ud->rflows = devm_kcalloc(dev, ud->rflow_cnt, sizeof(*ud->rflows),
GFP_KERNEL);
ud->tflow_map = devm_kmalloc_array(dev, BITS_TO_LONGS(ud->tflow_cnt),
sizeof(unsigned long), GFP_KERNEL);
if (!ud->tchan_map || !ud->rchan_map || !ud->tflow_map || !ud->tchans ||
- !ud->rchans || !ud->rflows || !ud->rflow_in_use)
+ !ud->rchans || !ud->rflows || !ud->rflow_map)
return -ENOMEM;
/* Get resource ranges from tisci */
@@ -1592,12 +1587,12 @@ static int pktdma_setup_resources(struct udma_dev *ud)
rm_res = tisci_rm->rm_ranges[RM_RANGE_RFLOW];
if (IS_ERR(rm_res)) {
/* all rflows are assigned exclusively to Linux */
- bitmap_zero(ud->rflow_in_use, ud->rflow_cnt);
+ bitmap_zero(ud->rflow_map, ud->rflow_cnt);
} else {
- bitmap_fill(ud->rflow_in_use, ud->rflow_cnt);
+ bitmap_fill(ud->rflow_map, ud->rflow_cnt);
for (i = 0; i < rm_res->sets; i++) {
rm_desc = _res->desc[i];
- bitmap_clear(ud->rflow_in_use, rm_desc->start,
+ bitmap_clear(ud->rflow_map, rm_desc->start,
rm_desc->num);
dev_dbg(dev, "ti-sci-res: rflow: %d:%d\n",
rm_desc->start, rm_desc->num);
--
2.34.1
[PATCH] ARM: mach-k3: sysfw-loader: Copy sysfw.itb to OCRAM in OSPI/SPI bootmode
In case of xSPI bootmode OSPI flash is in DDR mode and needs to be accessed
in multiple of 16bit accesses Hence we cannot parse sysfw.itb FIT image
directly on OSPI flash via MMIO window. So, copy the image to internal
on-chip RAM before parsing the image.
Moreover, board cfg data maybe modified by ROM/TIFS in case of HS platform
and thus cannot reside in OSPI/xSPI and needs to be copied over to
internal OCRAM.
This unblocks OSPI/xSPI boot on HS platforms
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Dave Gerlach
Tested-by: Keerthy
---
arch/arm/mach-k3/sysfw-loader.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
index 9ce576186c..5e48c36ccd 100644
--- a/arch/arm/mach-k3/sysfw-loader.c
+++ b/arch/arm/mach-k3/sysfw-loader.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include "common.h"
@@ -335,6 +336,14 @@ static void *k3_sysfw_get_spi_addr(void)
return (void *)(addr + CONFIG_K3_SYSFW_IMAGE_SPI_OFFS);
}
+
+static void k3_sysfw_spi_copy(u32 *dst, u32 *src, size_t len)
+{
+ size_t i;
+
+ for (i = 0; i < len / sizeof(*dst); i++)
+ *dst++ = *src++;
+}
#endif
void k3_sysfw_loader(bool rom_loaded_sysfw,
@@ -344,6 +353,9 @@ void k3_sysfw_loader(bool rom_loaded_sysfw,
struct spl_image_info spl_image = { 0 };
struct spl_boot_device bootdev = { 0 };
struct ti_sci_handle *ti_sci;
+#if CONFIG_IS_ENABLED(SPI_LOAD)
+ void *sysfw_spi_base;
+#endif
int ret = 0;
if (rom_loaded_sysfw) {
@@ -394,9 +406,11 @@ void k3_sysfw_loader(bool rom_loaded_sysfw,
#endif
#if CONFIG_IS_ENABLED(SPI_LOAD)
case BOOT_DEVICE_SPI:
- sysfw_load_address = k3_sysfw_get_spi_addr();
- if (!sysfw_load_address)
+ sysfw_spi_base = k3_sysfw_get_spi_addr();
+ if (!sysfw_spi_base)
ret = -ENODEV;
+ k3_sysfw_spi_copy(sysfw_load_address, sysfw_spi_base,
+ CONFIG_K3_SYSFW_IMAGE_SIZE_MAX);
break;
#endif
#if CONFIG_IS_ENABLED(YMODEM_SUPPORT)
--
2.34.1
Re: [PATCH v2 1/3] arm64: dts: rockchip: px30: Move dmc into -u-boot.dtsi
On Wed, Dec 8, 2021 at 10:50 AM Jagan Teki wrote:
>
> Hi Kever,
>
> On Mon, Nov 15, 2021 at 11:08 PM Jagan Teki
> wrote:
> >
> > dmc node is specific to U-Boot, it is always better practice
> > to maintain U-Boot specific nodes into -u-boot.dtsi files
> > in order to maintain Linux dts file sync compatibility.
> >
> > Move the dmc into px30-u-boot.dtsi, also add dmc node
> > explicitly in rk3326-odroid-go2-u-boot.dtsi since it is
> > using px30.dts.
> >
> > Signed-off-by: Jagan Teki
> > ---
> > Changes for v2:
> > - none
> >
> > arch/arm/dts/px30-u-boot.dtsi | 10 ++
> > arch/arm/dts/px30.dtsi | 5 -
> > arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 10 ++
> > 3 files changed, 12 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/dts/px30-u-boot.dtsi b/arch/arm/dts/px30-u-boot.dtsi
> > index 029c8fbd8d..bbed7dcde5 100644
> > --- a/arch/arm/dts/px30-u-boot.dtsi
> > +++ b/arch/arm/dts/px30-u-boot.dtsi
> > @@ -13,6 +13,12 @@
> > u-boot,spl-boot-order = ,
> > };
> >
> > + dmc {
> > + u-boot,dm-pre-reloc;
> > + compatible = "rockchip,px30-dmc", "syscon";
> > + reg = <0x0 0xff2a 0x0 0x1000>;
> > + };
> > +
> > rng: rng@ff0b {
> > compatible = "rockchip,cryptov2-rng";
> > reg = <0x0 0xff0b 0x0 0x4000>;
> > @@ -20,10 +26,6 @@
> > };
> > };
> >
> > - {
> > - u-boot,dm-pre-reloc;
> > -};
> > -
> > {
> > clock-frequency = <2400>;
> > u-boot,dm-pre-reloc;
> > diff --git a/arch/arm/dts/px30.dtsi b/arch/arm/dts/px30.dtsi
> > index ef706486dc..ef77b7b997 100644
> > --- a/arch/arm/dts/px30.dtsi
> > +++ b/arch/arm/dts/px30.dtsi
> > @@ -151,11 +151,6 @@
> > interrupt-affinity = <>, <>, <>, <>;
> > };
> >
> > - dmc: dmc {
> > - compatible = "rockchip,px30-dmc", "syscon";
> > - reg = <0x0 0xff2a 0x0 0x1000>;
> > - };
> > -
> > display_subsystem: display-subsystem {
> > compatible = "rockchip,display-subsystem";
> > ports = <_out>, <_out>;
> > diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> > b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> > index bffaa3edf3..63d87e16e1 100644
> > --- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
> > @@ -16,6 +16,12 @@
> > serial2 =
> > spi0 =
> > };
> > +
> > + dmc {
> > + u-boot,dm-pre-reloc;
> > + compatible = "rockchip,px30-dmc", "syscon";
> > + reg = <0x0 0xff2a 0x0 0x1000>;
> > + };
> > };
> >
> > /* U-Boot clk driver for px30 cannot set GPU_CLK */
> > @@ -32,10 +38,6 @@
> > <1>, <1700>;
> > };
> >
> > - {
> > - u-boot,dm-pre-reloc;
> > -};
> > -
> > {
> > u-boot,dm-pre-reloc;
> > };
> > --
> > 2.25.1
> >
>
> Any chance to apply these?
Gentle ping!
Re: [PATCH] rockchip: puma/lion: update MAINTAINERS file
Hi Quentin, Please just add some commit message for this commit, the empty commit message is not able to accept. Thanks, - Kever On 2021/11/12 下午10:17, Quentin Schulz wrote: Cc: Quentin Schulz Signed-off-by: Quentin Schulz --- board/theobroma-systems/lion_rk3368/MAINTAINERS | 2 +- board/theobroma-systems/puma_rk3399/MAINTAINERS | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/theobroma-systems/lion_rk3368/MAINTAINERS b/board/theobroma-systems/lion_rk3368/MAINTAINERS index 857f784d21..a5b4cb31b4 100644 --- a/board/theobroma-systems/lion_rk3368/MAINTAINERS +++ b/board/theobroma-systems/lion_rk3368/MAINTAINERS @@ -1,5 +1,5 @@ LION-RK3368 (RK3368-uQ7 system-on-module) -M: Philipp Tomsich +M: Quentin Schulz M:Klaus Goger S:Maintained F:board/theobroma-systems/lion_rk3368 diff --git a/board/theobroma-systems/puma_rk3399/MAINTAINERS b/board/theobroma-systems/puma_rk3399/MAINTAINERS index ccec09c386..1ec2dd72d6 100644 --- a/board/theobroma-systems/puma_rk3399/MAINTAINERS +++ b/board/theobroma-systems/puma_rk3399/MAINTAINERS @@ -1,5 +1,5 @@ PUMA-RK3399 -M: Philipp Tomsich +M: Quentin Schulz M:Klaus Goger S:Maintained F:board/theobroma-systems/puma_rk3399
Re: [PATCH] doc: rockchip: puma: update build and flash instructions
On 2021/11/12 下午10:15, Quentin Schulz wrote:
Long gone is the time a custom TF-A was needed for Puma, upstream TF-A
works just fine now.
The flashing instructions are updated to match how newer rkdeveloptool
and rkbin work.
Finally, rkbin provides a way to flash SPI via USB OTG interface so
let's document that.
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
Reviewed-by: Kever Yang
Thanks,
- Kever
---
board/theobroma-systems/puma_rk3399/README | 66 ++
doc/README.rockchip| 27 +++--
2 files changed, 38 insertions(+), 55 deletions(-)
diff --git a/board/theobroma-systems/puma_rk3399/README
b/board/theobroma-systems/puma_rk3399/README
index 9b31b0b379..254c3bbe96 100644
--- a/board/theobroma-systems/puma_rk3399/README
+++ b/board/theobroma-systems/puma_rk3399/README
@@ -26,25 +26,17 @@ RK3399-Q7 features:
Here is the step-by-step to boot to U-Boot on rk3399.
-Get the Source and build ATF/Cortex-M0 binaries
-===
+Get the Source and build ATF binary
+===
- > git clone git://git.theobroma-systems.com/arm-trusted-firmware.git
- > git clone git://git.theobroma-systems.com/rk3399-cortex-m0.git
+ > git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
Compile the ATF
===
- > cd arm-trusted-firmware
+ > cd trusted-firmware-a
> make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
- > cp build/rk3399/release/bl31.bin ../u-boot/bl31-rk3399.bin
-
-Compile the M0 firmware
-===
-
- > cd ../rk3399-cortex-m0
- > make CROSS_COMPILE=arm-cortex_m0-eabi-
- > cp rk3399m0.bin ../u-boot
+ > cp build/rk3399/release/bl31/bl31.elf ../u-boot/bl31.elf
Compile the U-Boot
==
@@ -55,23 +47,22 @@ Compile the U-Boot
Package the image
=
-Creating a SPL image for SD-Card/eMMC
- > tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin spl_mmc.img
-Creating a SPL image for SPI-NOR
- > tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin spl_nor.img
-Create the FIT image containing U-Boot proper, ATF, M0 Firmware, devicetree
- > make CROSS_COMPILE=aarch64-linux-gnu-
+The SPL image for SD-Card/eMMC is readily available in idbloader.img at the
+root of U-Boot after compilation.
+
+Creating an SPL image for SPI-NOR:
+ > tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader-spi.img
Flash the image
===
Copy the SPL to offset 32k for SD/eMMC, offset 0 for NOR-Flash and the FIT
-image to offset 256k card.
+image to offset 256k.
SD-Card
---
- > dd if=spl_mmc.img of=/dev/sdb seek=64
+ > dd if=idbloader.img of=/dev/sdb seek=64
> dd if=u-boot.itb of=/dev/sdb seek=512
eMMC
@@ -84,24 +75,27 @@ help of the Rockchip loader binary.
> cd rkdeveloptool
> autoreconf -i && ./configure && make
> git clone https://github.com/rockchip-linux/rkbin.git
- > ./rkdeveloptool db rkbin/rk33/rk3399_loader_v1.08.106.bin
- > ./rkdeveloptool wl 64 ../spl_mmc.img
+ > cd rkbin
+ > ./tools/boot_merger RKBOOT/RK3399MINIALL.ini
+ > cd ..
+ > ./rkdeveloptool db rkbin/rk3399_loader_v1.25.126.bin
+ > ./rkdeveloptool wl 64 ../idbloader.img
> ./rkdeveloptool wl 512 ../u-boot.itb
NOR-Flash
-
-Writing the SPI NOR Flash requires a running U-Boot. For the sake of simplicity
-we assume you have a SD-Card with a partition containing the required files
-ready.
-
- > load mmc 1:1 ${kernel_addr_r} spl_nor.img
- > sf probe
- > sf erase 0 +$filesize
- > sf write $kernel_addr_r 0 ${filesize}
- > load mmc 1:1 ${kernel_addr_r} u-boot.itb
- > sf erase 0x4 +$filesize
- > sf write $kernel_addr_r 0x4 ${filesize}
-
+rkdeveloptool allows to flash the on-board SPI via the USB OTG interface with
+help of the Rockchip loader binary.
-Reboot the system and you should see a U-Boot console on UART0 (115200n8).
+ > git clone https://github.com/rockchip-linux/rkdeveloptool
+ > cd rkdeveloptool
+ > autoreconf -i && ./configure && make
+ > git clone https://github.com/rockchip-linux/rkbin.git
+ > cd rkbin
+ > ./tools/boot_merger RKBOOT/RK3399MINIALL_SPINOR.ini
+ > cd ..
+ > ./rkdeveloptool db rkbin/rk3399_loader_spinor_v1.25.114.bin
+ > ./rkdeveloptool ef
+ > ./rkdeveloptool wl 0 ../idbloader-spi.img
+ > ./rkdeveloptool wl 512 ../u-boot.itb
diff --git a/doc/README.rockchip b/doc/README.rockchip
index 154166ec78..52b5140eca 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -81,30 +81,19 @@ Building
- Compile ATF
- For Puma board.
+ => git clone https://github.com/ARM-software/arm-trusted-firmware.git
+ => cd arm-trusted-firmware
- => git clone git://git.theobroma-systems.com/arm-trusted-firmware.git
- => cd arm-trusted-firmware
- => make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
+ (export cross compiler path for Cortex-M0 MCU likely
Re: [PATCH v1 1/3] arm: xea: Modify board code to generate single binary u-boot
On Thu, Dec 23, 2021 at 09:42:13AM +0100, Lukasz Majewski wrote:
> Hi Tom,
>
> > On Wed, Dec 22, 2021 at 01:49:02PM +0100, Lukasz Majewski wrote:
> >
> > > This change provides the possibility to build XEA (imx287 based)
> > > board U-Boot as a single binary (without support for
> > > CONFIG_SPL_FRAMEWORK).
> > >
> > > The generated u-boot.sb can be used in the factory environment to
> > > for example perform initial setup or HW testing.
> > >
> > > It can be used with 'uuu' utility
> > > (SDPS: boot -f /srv/tftp/xea/u-boot.sb)
> > >
> > > The board_init_ll() is used in arch/arm/cpu/arm926ejs/mxs/start.S,
> > > which is utilized when CONFIG_SPL_FRAMEWORK is disabled.
> > >
> > > However, when it is enabled the arch/arm/cpu/arm926ejs/start.S is
> > > used, which requires the lowlevel_init() function.
> > >
> > > Signed-off-by: Lukasz Majewski
> > > ---
> > >
> > > board/liebherr/xea/spl_xea.c | 8
> > > board/liebherr/xea/xea.c | 3 ++-
> > > 2 files changed, 10 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/board/liebherr/xea/spl_xea.c
> > > b/board/liebherr/xea/spl_xea.c index 192f68fca5f..5ee561b8b78 100644
> > > --- a/board/liebherr/xea/spl_xea.c
> > > +++ b/board/liebherr/xea/spl_xea.c
> > > @@ -290,6 +290,13 @@ u32 mxs_dram_vals[] = {
> > > 0x, 0x
> > > };
> > >
> > > +/* #ifndef CONFIG_SPL_FRAMEWORK */
> > > +#if !CONFIG_IS_ENABLED(FRAMEWORK)
> > > +void board_init_ll(const u32 arg, const uint32_t *resptr)
> > > +{
> > > + mxs_common_spl_init(arg, resptr, iomux_setup,
> > > ARRAY_SIZE(iomux_setup)); +}
> > > +#else
> > > void lowlevel_init(void)
> > > {
> > > struct mxs_pinctrl_regs *pinctrl_regs =
> > > @@ -301,3 +308,4 @@ void lowlevel_init(void)
> > >
> > > mxs_common_spl_init(0, NULL, iomux_setup,
> > > ARRAY_SIZE(iomux_setup)); }
> > > +#endif
> > > diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
> > > index cd11b0ada77..685e2e26a18 100644
> > > --- a/board/liebherr/xea/xea.c
> > > +++ b/board/liebherr/xea/xea.c
> > > @@ -58,7 +58,8 @@ static void init_clocks(void)
> > > mxs_set_sspclk(MXC_SSPCLK3, 96000, 0);
> > > }
> > >
> > > -#ifdef CONFIG_SPL_BUILD
> > > +/* #if CONFIG_SPL_BUILD && CONFIG_SPL_FRAMEWORK */
> > > +#if CONFIG_IS_ENABLED(BUILD) && CONFIG_IS_ENABLED(FRAMEWORK)
> > > void board_init_f(ulong arg)
> > > {
> > > init_clocks();
> >
> > I know checkpatch.pl has a warning, but maybe the text needs to be
> > tweaked there slightly?
>
> Yes, exactly - this was done to silence the checkpatch.pl error.
>
> > Using CONFIG_IS_ENABLED here is less
> > readable / clear than CONFIG_SPL_BUILD (which is special) and
> > CONFIG_SPL_FRAMEWORK (there's no CONFIG_FRAMEWORK and this board
> > isn't going to use TPL).
> >
>
> If you prefer I can just add the preprocessor code from the above
> comment.
It's a warning not an error, please just use #ifdef here instead,
thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 00/16] Sync NXP LS1028A-RDB device trees between U-Boot and Linux
On Thu, Dec 23, 2021 at 01:47:48PM +0100, Michael Walle wrote: > Am 2021-12-23 13:44, schrieb Vladimir Oltean: > > On Thu, Dec 23, 2021 at 06:34:13AM +, Priyanka Jain wrote: > > > >The Linux side of device tree patches were merged today, and I see you've > > > >reviewed the U-Boot side of changes too. Could you please pick them up? > > > > > > Yes, I will pick the series as part of next pull-request for 2022.04 > > > > Thanks. Could you also delete the '#include > > "fsl-ls1028a-rdb-u-boot.dtsi"' > > line from patch 14/16 like Michael suggested, or should I resend for > > that? > > Patch 15/16 is also affected? I guess you took the linux dts and added > that include line afterwards? that shouldn't be necessary. Alright, I'll send v3 later today or tomorrow.
Re: [PATCH v2 00/16] Sync NXP LS1028A-RDB device trees between U-Boot and Linux
Am 2021-12-23 13:44, schrieb Vladimir Oltean: On Thu, Dec 23, 2021 at 06:34:13AM +, Priyanka Jain wrote: >The Linux side of device tree patches were merged today, and I see you've >reviewed the U-Boot side of changes too. Could you please pick them up? Yes, I will pick the series as part of next pull-request for 2022.04 Thanks. Could you also delete the '#include "fsl-ls1028a-rdb-u-boot.dtsi"' line from patch 14/16 like Michael suggested, or should I resend for that? Patch 15/16 is also affected? I guess you took the linux dts and added that include line afterwards? that shouldn't be necessary. -michael
Re: [PATCH v2 00/16] Sync NXP LS1028A-RDB device trees between U-Boot and Linux
On Thu, Dec 23, 2021 at 06:34:13AM +, Priyanka Jain wrote: > >The Linux side of device tree patches were merged today, and I see you've > >reviewed the U-Boot side of changes too. Could you please pick them up? > > Yes, I will pick the series as part of next pull-request for 2022.04 Thanks. Could you also delete the '#include "fsl-ls1028a-rdb-u-boot.dtsi"' line from patch 14/16 like Michael suggested, or should I resend for that?
Re: [RFC PATCH v2 6/8] FWU: Add boot time checks as highlighted by the FWU specification
hi Takahiro,
On Mon, 20 Dec 2021 at 15:55, AKASHI Takahiro
wrote:
> Hi Sughosh,
>
> On Mon, Dec 20, 2021 at 03:36:37PM +0530, Sughosh Ganu wrote:
> > hi Takahiro,
> >
> > On Mon, 20 Dec 2021 at 11:39, AKASHI Takahiro <
> takahiro.aka...@linaro.org>
> > wrote:
> >
> > > Sughosh,
> > >
> > > On Sun, Dec 19, 2021 at 12:36:03PM +0530, Sughosh Ganu wrote:
> > > > The FWU Multi Bank Update specification requires the Update Agent to
> > > > carry out certain checks at the time of platform boot. The Update
> > > > Agent is the component which is responsible for updating the firmware
> > > > components and maintaining and keeping the metadata in sync.
> > > >
> > > > The spec requires that the Update Agent perform the following checks
> > > > at the time of boot
> > > > * Sanity check of both the metadata copies maintained by the
> platform.
> > > > * Get the boot index passed to U-Boot by the prior stage bootloader
> > > > and use this value for metadata bookkeeping.
> > > > * Check if the system is booting in Trial State. If the system boots
> > > > in the Trial State for more than a specified number of boot counts,
> > > > change the Active Bank to be booting the platform from.
> > > >
> > > > Add these checks in the board initialisation sequence, invoked after
> > > > relocation.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > Changes since V1:
> > > > * Define a funtion fwu_update_checks_pass to do the checks
> > > > before initiating the update
> > > > * Log the status of the boottime checks using boottime_check
> > > > variable and allow system to boot instead of hanging the
> > > > platform(fwu_boottime_checks)
> > > >
> > > > common/board_r.c | 6 ++
> > > > include/fwu.h | 3 +
> > > > lib/fwu_updates/fwu.c | 163
> ++
> > > > 3 files changed, 172 insertions(+)
> > > > create mode 100644 lib/fwu_updates/fwu.c
> > > >
> > > > diff --git a/common/board_r.c b/common/board_r.c
> > > > index 31a59c585a..81678870b9 100644
> > > > --- a/common/board_r.c
> > > > +++ b/common/board_r.c
> > > > @@ -78,6 +78,9 @@
> > > > #ifdef CONFIG_EFI_SETUP_EARLY
> > > > #include
> > > > #endif
> > > > +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> > > > +#include
> > > > +#endif
> > > >
> > > > DECLARE_GLOBAL_DATA_PTR;
> > > >
> > > > @@ -805,6 +808,9 @@ static init_fnc_t init_sequence_r[] = {
> > > > #endif
> > > > #ifdef CONFIG_EFI_SETUP_EARLY
> > > > (init_fnc_t)efi_init_obj_list,
> > > > +#endif
> > > > +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> > > > + fwu_boottime_checks,
> > > > #endif
> > >
> > > Maybe I don't understand your code well.
> > > Why do you want to call fwu_boottime_checks() here?
> > > Why not in CONFIG_EFI_CAPSULE_UPDATE_EARLY (i.e. efi_launch_capsules()
> > > in main_loop())?
> > >
> >
> > These are boot time checks which are to be carried out during platform
> > boot. Do you see any issue if we place the call to fwu_boottime_checks in
> > the init_sequence.
>
> No, I don't see any specific issue right now.
>
> > I would like to avoid having the fwu boot time checks
> > tied up with CONFIG_EFI_CAPSULE_ON_DISK_EARLY.
>
> My question was why you want to avoid that.
> In main_loop(), update_tftp(), as well as efi capsule code, is put there.
> It would be a good practice to have similar functionality called in one
> place.
>
Keeping the call to fwu_boottime_checks separate allows one to try it out
separately from the u-boot shell, by not
enabling CONFIG_EFI_CAPSULE_ON_DISK_EARLY. Also, currently, the FWU code is
closely tied up with the capsule update code. But in the future, if someone
wants to use the fwu metadata without using the capsule format for the
update, that would be possible with the call being separate. But I agree
that this is a hypothetical case which may or may not happen. If you don't
have a strong opinion on this, I would prefer it be kept separate. Let me
know.
-sughosh
> -Takahiro Akashi
>
>
> > -sughosh
> >
> >
> > >
> > > -Takahiro Akashi
> > >
> > > > run_main_loop,
> > > > };
> > > > diff --git a/include/fwu.h b/include/fwu.h
> > > > index 5ba437798d..2d2e674d6a 100644
> > > > --- a/include/fwu.h
> > > > +++ b/include/fwu.h
> > > > @@ -16,6 +16,9 @@
> > > > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> > > >0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> > > >
> > > > +int fwu_boottime_checks(void);
> > > > +u8 fwu_update_checks_pass(void);
> > > > +
> > > > int fwu_get_active_index(u32 *active_idx);
> > > > int fwu_update_active_index(u32 active_idx);
> > > > int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> > > > diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
> > > > new file mode 100644
> > > > index 00..e964f9b0b1
> > > > --- /dev/null
> > > > +++ b/lib/fwu_updates/fwu.c
> > > > @@ -0,0 +1,163 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * Copyright (c) 2021, Linaro Limited
> > > > +
Re: [RFC PATCH v2 7/8] FWU: Add support for FWU Multi Bank Update feature
hi Masami, On Thu, 23 Dec 2021 at 06:23, Masami Hiramatsu wrote: > Hi Sughosh, > > Can you move the FWU related configs to lib/fwu_updates/Kconfig ? > FWU multi bank update is an independent feature, thus I think it is > better to have its own Kconfig file and the lib/Kconfig only includes > it. > (I did it on my development series) > Okay, I have moved the FWU config options in a Kconfig file under lib/fwu_updates/. This gets sourced from lib/Kconfig. -sughosh > > Thank you, > > 2021年12月19日(日) 16:07 Sughosh Ganu : > > > > The FWU Multi Bank Update feature supports updation of firmware images > > to one of multiple sets(also called banks) of images. The firmware > > images are clubbed together in banks, with the system booting images > > from the active bank. Information on the images such as which bank > > they belong to is stored as part of the metadata structure, which is > > stored on the same storage media as the firmware images on a dedicated > > partition. > > > > At the time of update, the metadata is read to identify the bank to > > which the images need to be flashed(update bank). On a successful > > update, the metadata is modified to set the updated bank as active > > bank to subsequently boot from. > > > > Signed-off-by: Sughosh Ganu > > --- > > Changes since V1: > > * Call function fwu_update_checks_pass to check if the > > update can be initiated > > * Do not allow firmware update from efi_init_obj_list as the > > fwu boot-time checks need to be run > > > > include/fwu.h| 18 +++- > > lib/Kconfig | 32 ++ > > lib/Makefile | 1 + > > lib/efi_loader/efi_capsule.c | 198 ++- > > lib/efi_loader/efi_setup.c | 3 +- > > lib/fwu_updates/Makefile | 11 ++ > > lib/fwu_updates/fwu.c| 27 + > > 7 files changed, 284 insertions(+), 6 deletions(-) > > create mode 100644 lib/fwu_updates/Makefile > > > > diff --git a/include/fwu.h b/include/fwu.h > > index 2d2e674d6a..bf50fe9277 100644 > > --- a/include/fwu.h > > +++ b/include/fwu.h > > @@ -10,14 +10,28 @@ > > > > #include > > > > -#define FWU_MDATA_VERSION 0x1 > > +#define FWU_MDATA_GUID \ > > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > > +0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > > + > > +#define FWU_OS_REQUEST_FW_REVERT_GUID \ > > + EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \ > > +0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0) > > + > > +#define FWU_OS_REQUEST_FW_ACCEPT_GUID \ > > + EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \ > > +0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8) > > > > #define FWU_MDATA_GUID \ > > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > > 0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > > > > -int fwu_boottime_checks(void); > > +#define FWU_MDATA_VERSION 0x1 > > +#define FWU_IMAGE_ACCEPTED 0x1 > > + > > u8 fwu_update_checks_pass(void); > > +int fwu_boottime_checks(void); > > +int fwu_trial_state_ctr_start(void); > > > > int fwu_get_active_index(u32 *active_idx); > > int fwu_update_active_index(u32 active_idx); > > diff --git a/lib/Kconfig b/lib/Kconfig > > index 807a4c6ade..7cb306317c 100644 > > --- a/lib/Kconfig > > +++ b/lib/Kconfig > > @@ -835,3 +835,35 @@ config PHANDLE_CHECK_SEQ > > When there are multiple device tree nodes with same name, > >enable this config option to distinguish them using > > phandles in fdtdec_get_alias_seq() function. > > + > > +config FWU_MULTI_BANK_UPDATE > > + bool "Enable FWU Multi Bank Update Feature" > > + depends on EFI_HAVE_CAPSULE_SUPPORT > > + select PARTITION_TYPE_GUID > > + select EFI_SETUP_EARLY > > + help > > + Feature for updating firmware images on platforms having > > + multiple banks(copies) of the firmware images. One of the > > + bank is selected for updating all the firmware components > > + > > +config FWU_NUM_BANKS > > + int "Number of Banks defined by the platform" > > + depends on FWU_MULTI_BANK_UPDATE > > + help > > + Define the number of banks of firmware images on a platform > > + > > +config FWU_NUM_IMAGES_PER_BANK > > + int "Number of firmware images per bank" > > + depends on FWU_MULTI_BANK_UPDATE > > + help > > + Define the number of firmware images per bank. This value > > + should be the same for all the banks. > > + > > +config FWU_TRIAL_STATE_CNT > > + int "Number of times system boots in Trial State" > > + depends on FWU_MULTI_BANK_UPDATE > > + default 3 > > + help > > + With FWU Multi Bank Update feature enabled, number of times > > + the platform is allowed to boot in Trial State after an > > + update. > > diff --git a/lib/Makefile b/lib/Makefile > > index 5ddbc77ed6..bc5c1e22fc 100644 > > --- a/lib/Makefile > > +++ b/lib/Makefile > > @@ -9,6 +9,7
How should I set load_address for fdt in the .its file...
Hello all, I saw https://www.thegoodpenguin.co.uk/blog/u-boot-fit-image-overview/ and used it to make .itb file (FIT image). (see the its sample right below the line saying : Let's try this out by creating an image tree source file (.its): ) I was doing the experiment and found the load address of fdt was set wrong and changed it to the next address after the linux kernel (but 8 byte aligned). But the SPL program complains it can't find the 'configurations' node. So I'm curious about how I should set the address. But I'm not sure how to set the 'load_address' and 'entry_address' for fdt. Should I set it so that fdt is just placed some place above the linux Image? And why doesn't initrd image node have those 'load_address' and 'entry_address'? Thanks for reading. Chan Kim
Re: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil, Am 2021-12-23 09:46, schrieb Sahil Malhotra (OSS): -Original Message- From: U-Boot On Behalf Of Michael Walle Sent: Monday, December 20, 2021 6:23 PM To: Sahil Malhotra (OSS) Cc: ZHIZHIKIN Andrey ; Clément Faure ; Gaurav Jain ; Pankaj Gupta ; Priyanka Jain ; u-boot@lists.denx.de; Varun Sethi ; Ye Li Subject: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature Caution: EXT Email Hi Sahil, Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS): >> DT nodes can be statically disabled if we know that they are held by >> HAB and are not released to NS World. >> >> OP-TEE does set the status itself via dt_enable_secure_status(), >> which should present the properly configured FDT when U-Boot takes over. > Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay > which gets merged with DTB provided for Linux bootup and then Linux > boots with merged DTB. > But u-boot uses the DTB embedded in its image. How can we modify that > DTB or merge DTB overlay passed by OP-TEE with uboot DTB ? But then u-boot has the "wrong" dtb. What is the reason, there is an overlay instead of a whole dtb? what if the overlay doesn't match the dtb? "wrong" dtb means that uboot will not be aware of CAAM job ring which is taken by OP-TEE and uboot on LS platforms currently use JR0, which is not being used by any other entity in LS bootflow. I don't know I follow. u-boot and linux should have the same device tree; regardless if that device is used or not. So applying the overlay just for linux isn't enough here. We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE reserves One Job Ring for its use and that is communicated to Kernel using DTB overlay. what if the overlay doesn't match the dtb? I didn't get this point, can you please elaborate a little. You are merging a dtb fragment with an unknown dtb, right? Who says they match? you might have an old dtb where the supplied dtb fragment doesn't make any sense. I might be missing something here. Eg. where is the linux dtb supposed to come from? This patchset is really missing an example and a description how things should work. -michael
Re: [PATCH v3 1/2] binman: Do not pollute source tree when build with `make O=...`
On Thu, Dec 23, 2021 at 7:08 AM Simon Glass wrote: > On Tue, 14 Dec 2021 at 17:33, Simon Glass wrote: > > > > Importing libraries in Python caches the bytecode by default. > > Since we run scripts in source tree it ignores the current directory > > settings, which is $(srctree), and creates cache just in the middle > > of the source tree. Move cache to the current directory. > > > > Signed-off-by: Andy Shevchenko > > --- > > v3: avoided crash (Simon), preserved tree hierarchy > > tools/binman/main.py | 13 - > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > Applied to u-boot-dm/next, thanks! > > I didn't notice this before, but this seems to create files like this: > > ./tools/binman/usr/lib/python3/dist-packages/elftools/common/construct_utils.cpython-39.pyc > > We don't really want to 'recache' the common Python files. Do you > think we should revert this patch, or find another fix? I'm not sure I understand. efitools is not common, it's a separate (non-standard) module and it's cached. -- With Best Regards, Andy Shevchenko
RE: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Michael, > -Original Message- > From: U-Boot On Behalf Of Michael Walle > Sent: Monday, December 20, 2021 6:23 PM > To: Sahil Malhotra (OSS) > Cc: ZHIZHIKIN Andrey ; Clément > Faure ; Gaurav Jain ; > Pankaj Gupta ; Priyanka Jain > ; u-boot@lists.denx.de; Varun Sethi > ; Ye Li > Subject: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature > > Caution: EXT Email > > Hi Sahil, > > Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS): > >> DT nodes can be statically disabled if we know that they are held by > >> HAB and are not released to NS World. > >> > >> OP-TEE does set the status itself via dt_enable_secure_status(), > >> which should present the properly configured FDT when U-Boot takes > over. > > Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay > > which gets merged with DTB provided for Linux bootup and then Linux > > boots with merged DTB. > > But u-boot uses the DTB embedded in its image. How can we modify that > > DTB or merge DTB overlay passed by OP-TEE with uboot DTB ? > > But then u-boot has the "wrong" dtb. What is the reason, there is an overlay > instead of a whole dtb? what if the overlay doesn't match the dtb? "wrong" dtb means that uboot will not be aware of CAAM job ring which is taken by OP-TEE and uboot on LS platforms currently use JR0, which is not being used by any other entity in LS bootflow. We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE reserves One Job Ring for its use and that is communicated to Kernel using DTB overlay. > what if the overlay doesn't match the dtb? I didn't get this point, can you please elaborate a little. Regards, Sahil Malhotra
Re: [PATCH v1 1/3] arm: xea: Modify board code to generate single binary u-boot
Hi Tom,
> On Wed, Dec 22, 2021 at 01:49:02PM +0100, Lukasz Majewski wrote:
>
> > This change provides the possibility to build XEA (imx287 based)
> > board U-Boot as a single binary (without support for
> > CONFIG_SPL_FRAMEWORK).
> >
> > The generated u-boot.sb can be used in the factory environment to
> > for example perform initial setup or HW testing.
> >
> > It can be used with 'uuu' utility
> > (SDPS: boot -f /srv/tftp/xea/u-boot.sb)
> >
> > The board_init_ll() is used in arch/arm/cpu/arm926ejs/mxs/start.S,
> > which is utilized when CONFIG_SPL_FRAMEWORK is disabled.
> >
> > However, when it is enabled the arch/arm/cpu/arm926ejs/start.S is
> > used, which requires the lowlevel_init() function.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> >
> > board/liebherr/xea/spl_xea.c | 8
> > board/liebherr/xea/xea.c | 3 ++-
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/board/liebherr/xea/spl_xea.c
> > b/board/liebherr/xea/spl_xea.c index 192f68fca5f..5ee561b8b78 100644
> > --- a/board/liebherr/xea/spl_xea.c
> > +++ b/board/liebherr/xea/spl_xea.c
> > @@ -290,6 +290,13 @@ u32 mxs_dram_vals[] = {
> > 0x, 0x
> > };
> >
> > +/* #ifndef CONFIG_SPL_FRAMEWORK */
> > +#if !CONFIG_IS_ENABLED(FRAMEWORK)
> > +void board_init_ll(const u32 arg, const uint32_t *resptr)
> > +{
> > + mxs_common_spl_init(arg, resptr, iomux_setup,
> > ARRAY_SIZE(iomux_setup)); +}
> > +#else
> > void lowlevel_init(void)
> > {
> > struct mxs_pinctrl_regs *pinctrl_regs =
> > @@ -301,3 +308,4 @@ void lowlevel_init(void)
> >
> > mxs_common_spl_init(0, NULL, iomux_setup,
> > ARRAY_SIZE(iomux_setup)); }
> > +#endif
> > diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
> > index cd11b0ada77..685e2e26a18 100644
> > --- a/board/liebherr/xea/xea.c
> > +++ b/board/liebherr/xea/xea.c
> > @@ -58,7 +58,8 @@ static void init_clocks(void)
> > mxs_set_sspclk(MXC_SSPCLK3, 96000, 0);
> > }
> >
> > -#ifdef CONFIG_SPL_BUILD
> > +/* #if CONFIG_SPL_BUILD && CONFIG_SPL_FRAMEWORK */
> > +#if CONFIG_IS_ENABLED(BUILD) && CONFIG_IS_ENABLED(FRAMEWORK)
> > void board_init_f(ulong arg)
> > {
> > init_clocks();
>
> I know checkpatch.pl has a warning, but maybe the text needs to be
> tweaked there slightly?
Yes, exactly - this was done to silence the checkpatch.pl error.
> Using CONFIG_IS_ENABLED here is less
> readable / clear than CONFIG_SPL_BUILD (which is special) and
> CONFIG_SPL_FRAMEWORK (there's no CONFIG_FRAMEWORK and this board
> isn't going to use TPL).
>
If you prefer I can just add the preprocessor code from the above
comment.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpec1isAS8Cd.pgp
Description: OpenPGP digital signature
