[PATCH] imx8mm_beacon: Enable HS400 on MMC controller
The i.MX8MM is capable of HS400. Enable it in both U-Boot and SPL for faster throughput. Signed-off-by: Adam Ford diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig index c5d331f617..49d5453078 100644 --- a/configs/imx8mm_beacon_defconfig +++ b/configs/imx8mm_beacon_defconfig @@ -70,6 +70,13 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MXC=y CONFIG_DM_MMC=y CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_IO_VOLTAGE=y +CONFIG_SPL_MMC_IO_VOLTAGE=y +CONFIG_MMC_UHS_SUPPORT=y +CONFIG_SPL_MMC_UHS_SUPPORT=y +CONFIG_MMC_HS400_ES_SUPPORT=y +CONFIG_MMC_HS400_SUPPORT=y +CONFIG_SPL_MMC_HS400_SUPPORT=y CONFIG_FSL_USDHC=y CONFIG_PHYLIB=y CONFIG_PHY_ATHEROS=y -- 2.25.1
Re: [PATCH 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties
On Tue, Dec 1, 2020 at 7:32 AM Andrey Zhizhikin
wrote:
>
> i.MX8M series provide support for high speed grades in their
> usdhc controllers, which has eMMC and SDHC connected to them.
>
> Enable this support across the entire i.MX8M family by providing quirks
> to usdhc controllers designated by storage media connected to them.
>
> Signed-off-by: Andrey Zhizhikin
> Cc: Stefano Babic
> Cc: Ye Li
> ---
> arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi | 3 +++
> arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi | 3 +++
> arch/arm/dts/imx8mm-evk-u-boot.dtsi | 4
> arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 4
> arch/arm/dts/imx8mp-evk-u-boot.dtsi | 4
> arch/arm/dts/imx8mq-evk.dts | 3 +++
> 6 files changed, 21 insertions(+)
>
> diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> index 80d6475b7c..2f86fcce3e 100644
> --- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> +++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> @@ -118,8 +118,11 @@
>
> &usdhc1 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> };
>
I don't think the "u-boot," prefix is needed. Looking at other
boards' device trees, they don't seem to have this.
I tried it on the beacon imx8mm-beacon-kit, and it didn't work until I
removed the "u-boot,"
With that removed, I can get the following:
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 27
OEM: 5048
Name: SD32G
Bus Speed: 2
Mode: UHS SDR104 (208MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 29 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
u-boot=>
and
u-boot=> mmc info
Device: FSL_SDHC
Manufacturer ID: 45
OEM: 100
Name: DG403
Bus Speed: 2
Mode: HS400 (200MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 29.1 GiB
Bus Width: 8-bit DDR
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 29.1 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 4 MiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected
u-boot=>
adam
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
> diff --git a/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> b/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> index 771ab635f1..f4332edac5 100644
> --- a/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> +++ b/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> @@ -118,8 +118,11 @@
>
> &usdhc1 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> };
>
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> index 9f77d3c6ff..67666a08ec 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -100,10 +100,14 @@
>
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
>
> &usdhc3 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> + u-boot,mmc-hs400-enhanced-strobe;
> };
>
> &i2c1 {
> diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> index 98b0b9891b..e03e635213 100644
> --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> @@ -97,10 +97,14 @@
>
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
>
> &usdhc3 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> + u-boot,mmc-hs400-enhanced-strobe;
> };
>
> &wdog1 {
> diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> index 2452e9175c..0776b24a6e 100644
> --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> @@ -126,10 +126,14 @@
>
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
>
> &usdhc3 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> + u-boot,mmc-hs400-enhanced-strobe;
> };
>
> &wdog1 {
> diff --git a/arch/arm/dts/imx8mq-evk.dts b/arch/arm/dts/imx8mq-evk.dts
> index 9663683f69..985e7e7f8b 100644
> --- a/arch/arm/dts/imx8mq-evk.dts
> +++ b/arch/arm/dts/imx8mq-evk.dts
> @@ -291,6 +291,7 @@
> non-removable;
> no-sd;
> no-sdio;
> + u-boot,mmc-hs400-1_8v;
> status = "okay";
> };
>
> @@ -301,6 +302,8 @@
> pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
> cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
> vmmc-supply = <®_usdhc2_vmmc>;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> status = "okay";
> };
>
> --
> 2.17.1
>
[PATCH 3/3] arm64: dts: imx8mm-beacon: Re-sync dts file with Linux 5.10-rc6
There have been some updates to the device trees, so re-sync.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
b/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
index baa5f997d0..d6b9dedd16 100644
--- a/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
+++ b/arch/arm/dts/imx8mm-beacon-baseboard.dtsi
@@ -10,19 +10,19 @@
led0 {
label = "gen_led0";
gpios = <&pca6416_1 4 GPIO_ACTIVE_HIGH>;
- default-state = "none";
+ default-state = "off";
};
led1 {
label = "gen_led1";
gpios = <&pca6416_1 5 GPIO_ACTIVE_HIGH>;
- default-state = "none";
+ default-state = "off";
};
led2 {
label = "gen_led2";
gpios = <&pca6416_1 6 GPIO_ACTIVE_HIGH>;
- default-state = "none";
+ default-state = "off";
};
led3 {
@@ -70,7 +70,7 @@
&ecspi2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_espi2>;
- cs-gpios = <&gpio5 9 0>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
status = "okay";
eeprom@0 {
@@ -210,7 +210,7 @@
>;
};
- pinctrl_pcal6414: pcal6414-gpio {
+ pinctrl_pcal6414: pcal6414-gpiogrp {
fsl,pins = <
MX8MM_IOMUXC_SAI2_MCLK_GPIO4_IO27 0x19
>;
@@ -240,7 +240,7 @@
>;
};
- pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x41
MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
@@ -259,7 +259,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
@@ -271,7 +271,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
diff --git a/arch/arm/dts/imx8mm-beacon-som.dtsi
b/arch/arm/dts/imx8mm-beacon-som.dtsi
index 801bd02eae..b88c3c99b0 100644
--- a/arch/arm/dts/imx8mm-beacon-som.dtsi
+++ b/arch/arm/dts/imx8mm-beacon-som.dtsi
@@ -24,6 +24,26 @@
cpu-supply = <&buck2_reg>;
};
+&ddrc {
+ operating-points-v2 = <&ddrc_opp_table>;
+
+ ddrc_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-25M {
+ opp-hz = /bits/ 64 <2500>;
+ };
+
+ opp-100M {
+ opp-hz = /bits/ 64 <1>;
+ };
+
+ opp-750M {
+ opp-hz = /bits/ 64 <75000>;
+ };
+ };
+};
+
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fec1>;
@@ -52,9 +72,10 @@
pmic@4b {
compatible = "rohm,bd71847";
reg = <0x4b>;
+ pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio1>;
- interrupts = <3 GPIO_ACTIVE_LOW>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
rohm,reset-snvs-powered;
regulators {
@@ -116,7 +137,7 @@
ldo1_reg: LDO1 {
regulator-name = "ldo1";
- regulator-min-microvolt = <300>;
+ regulator-min-microvolt = <160>;
regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
@@ -124,7 +145,7 @@
ldo2_reg: LDO2 {
regulator-name = "ldo2";
- regulator-min-microvolt = <90>;
+ regulator-min-microvolt = <80>;
regulator-max-microvolt = <90>;
regulator-boot-on;
regulator-always-on;
@@ -164,7 +185,7 @@
status = "okay";
eeprom@50 {
- compatible = "microchip, at24c64d", "atmel,24c64";
+ compatible = "microchip,24c64", "atmel,24c64";
pagesize = <32>;
read-only; /* Manufacturing EEPROM programmed at factory */
reg = <0x50>;
@@ -190,6 +211,7 @@
h
[PATCH 2/3] arm: dts: imx8mm: sync dts from Linux Kernel 5.10-rc6
There have been some updates to the device tree since 5.6.
This also includes some clocks, and makes it easier to keep
board device tree files in sync with Linux
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
index 1e5e11592f..05ee062548 100644
--- a/arch/arm/dts/imx8mm.dtsi
+++ b/arch/arm/dts/imx8mm.dtsi
@@ -18,10 +18,18 @@
aliases {
ethernet0 = &fec1;
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ gpio3 = &gpio4;
+ gpio4 = &gpio5;
i2c0 = &i2c1;
i2c1 = &i2c2;
i2c2 = &i2c3;
i2c3 = &i2c4;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ mmc2 = &usdhc3;
serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
@@ -29,14 +37,6 @@
spi0 = &ecspi1;
spi1 = &ecspi2;
spi2 = &ecspi3;
- mmc0 = &usdhc1;
- mmc1 = &usdhc2;
- mmc2 = &usdhc3;
- gpio0 = &gpio1;
- gpio1 = &gpio2;
- gpio2 = &gpio3;
- gpio3 = &gpio4;
- gpio4 = &gpio5;
};
cpus {
@@ -68,6 +68,7 @@
nvmem-cells = <&cpu_speed_grade>;
nvmem-cell-names = "speed_grade";
cpu-idle-states = <&cpu_pd_wait>;
+ #cooling-cells = <2>;
};
A53_1: cpu@1 {
@@ -80,6 +81,7 @@
next-level-cache = <&A53_L2>;
operating-points-v2 = <&a53_opp_table>;
cpu-idle-states = <&cpu_pd_wait>;
+ #cooling-cells = <2>;
};
A53_2: cpu@2 {
@@ -92,6 +94,7 @@
next-level-cache = <&A53_L2>;
operating-points-v2 = <&a53_opp_table>;
cpu-idle-states = <&cpu_pd_wait>;
+ #cooling-cells = <2>;
};
A53_3: cpu@3 {
@@ -104,6 +107,7 @@
next-level-cache = <&A53_L2>;
operating-points-v2 = <&a53_opp_table>;
cpu-idle-states = <&cpu_pd_wait>;
+ #cooling-cells = <2>;
};
A53_L2: l2-cache0 {
@@ -125,7 +129,7 @@
opp-16 {
opp-hz = /bits/ 64 <16>;
- opp-microvolt = <90>;
+ opp-microvolt = <95>;
opp-supported-hw = <0xc>, <0x7>;
clock-latency-ns = <15>;
opp-suspend;
@@ -204,6 +208,38 @@
arm,no-tick-in-suspend;
};
+ thermal-zones {
+ cpu-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = <&tmu>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_crit0: trip1 {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device =
+ <&A53_0 THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ <&A53_1 THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ <&A53_2 THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ <&A53_3 THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
usbphynop1: usbphynop1 {
compatible = "usb-nop-xceiv";
clocks = <&clk IMX8MM_CLK_USB_PHY_REF>;
@@ -227,12 +263,14 @@
ranges = <0x0 0x0 0x0 0x3e00>;
aips1: bus@3000 {
- compatible = "simple-bus";
+ compatible = "fsl,aips-bus", "simple-bus";
+ reg = <0x3000 0x40>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x3000 0x3000 0x40>;
sai1: sai@300100
[PATCH 1/3] imx: imx8mm: Update clock bindings header
Import clock bindings header file from Linux 5.10-rc6 Signed-off-by: Adam Ford diff --git a/include/dt-bindings/clock/imx8mm-clock.h b/include/dt-bindings/clock/imx8mm-clock.h index 07e6c686f3..e63a5530ae 100644 --- a/include/dt-bindings/clock/imx8mm-clock.h +++ b/include/dt-bindings/clock/imx8mm-clock.h @@ -248,6 +248,32 @@ #define IMX8MM_CLK_SNVS_ROOT 228 #define IMX8MM_CLK_GIC 229 -#define IMX8MM_CLK_END 230 +#define IMX8MM_SYS_PLL1_40M_CG 230 +#define IMX8MM_SYS_PLL1_80M_CG 231 +#define IMX8MM_SYS_PLL1_100M_CG232 +#define IMX8MM_SYS_PLL1_133M_CG233 +#define IMX8MM_SYS_PLL1_160M_CG234 +#define IMX8MM_SYS_PLL1_200M_CG235 +#define IMX8MM_SYS_PLL1_266M_CG236 +#define IMX8MM_SYS_PLL1_400M_CG237 +#define IMX8MM_SYS_PLL2_50M_CG 238 +#define IMX8MM_SYS_PLL2_100M_CG239 +#define IMX8MM_SYS_PLL2_125M_CG240 +#define IMX8MM_SYS_PLL2_166M_CG241 +#define IMX8MM_SYS_PLL2_200M_CG242 +#define IMX8MM_SYS_PLL2_250M_CG243 +#define IMX8MM_SYS_PLL2_333M_CG244 +#define IMX8MM_SYS_PLL2_500M_CG245 + +#define IMX8MM_CLK_M4_CORE 246 +#define IMX8MM_CLK_VPU_CORE247 +#define IMX8MM_CLK_GPU3D_CORE 248 +#define IMX8MM_CLK_GPU2D_CORE 249 + +#define IMX8MM_CLK_CLKO2 250 + +#define IMX8MM_CLK_A53_CORE251 + +#define IMX8MM_CLK_END 252 #endif -- 2.25.1
Pull request, u-boot-tegra/master
Tom, Please pull u-boot-tegra/master into U-Boot/master. Thanks. All Tegra builds are OK on my system, and Stephen's test frame reports that all tests pass. The following changes since commit ee1e04558ff8c8ed812b986939447f129bb0b0bb: Merge branch '2020-12-02-master-imports' (2020-12-03 09:43:47 -0500) are available in the git repository at: ssh://twarren@git-mirror-santaclara:12001/m/denx.de/u-boot-tegra.git for you to fetch changes up to 4f5128ff899d0cb13a7b010f6dbffd0aba71bb25: configs: cei-tk1-som: remove CONFIG_ARMV7_PSCI in include file (2020-12-04 13:39:15 -0700) Marcel Ziswiler (5): apalis/colibri_t30: add comment about tristate and input vs. output pinmuxing colibri_t30: fix spi1 and uart2/3 resp. uartb/c pinmuxing apalis/colibri_t30: avoid uart input from floating pins apalis/colibri_t30: add note about colibri vs. nvidia uart mapping colibri_t30: disable rs232 serial transceiver forceoff pins Patrick Delaunay (1): configs: cei-tk1-som: remove CONFIG_ARMV7_PSCI in include file Peter Robinson (2): arm: tegra: define fdtfile option for distro boot arm: tegra: add options for BOOTENV_EFI_SET_FDTFILE_FALLBACK for tegra186 arch/arm/mach-tegra/tegra124/Kconfig | 1 + .../toradex/apalis_t30/pinmux-config-apalis_t30.h | 11 ++-- board/toradex/colibri_t30/colibri_t30.c| 11 .../colibri_t30/pinmux-config-colibri_t30.h| 32 -- configs/cei-tk1-som_defconfig | 1 + include/config_distro_bootcmd.h| 2 ++ include/configs/apalis_t30.h | 9 +- include/configs/cei-tk1-som.h | 2 -- include/configs/colibri_t30.h | 8 +- include/configs/tegra-common.h | 6 include/configs/tegra114-common.h | 1 + include/configs/tegra124-common.h | 1 + include/configs/tegra186-common.h | 6 include/configs/tegra20-common.h | 1 + include/configs/tegra210-common.h | 1 + include/configs/tegra30-common.h | 1 + 16 files changed, 73 insertions(+), 21 deletions(-)
About the commit imx: mx6ull: update the REFTOP_VBGADJ setting
Hi Peng I have a design with imx6ull that is running properly according to the manufacturer with the old REFTOP_VBGA set BM_ANADIG_ANA_MISC0_REFTOP_VBGADJ,. With this commit, the TJunction of the CPU is around 8 degree more than without. The commit message does not provide any info According to the design team, we need to set REFTOP_VBGADJ in PMU MISC0 according to the REFTOP_TRIM[2:0] fuse. the actually table is as below: '000" - set REFTOP_VBGADJ[2:0] to 3'b000 '001" - set REFTOP_VBGADJ[2:0] to 3'b001 '010" - set REFTOP_VBGADJ[2:0] to 3'b010 '011" - set REFTOP_VBGADJ[2:0] to 3'b011 '100" - set REFTOP_VBGADJ[2:0] to 3'b100 '101" - set REFTOP_VBGADJ[2:0] to 3'b101 '110" - set REFTOP_VBGADJ[2:0] to 3'b110 '111" - set REFTOP_VBGADJ[2:0] to 3'b111 Can someone describe to me better? The device needs to run in a very hot environment and 10 to 8 degrees on the junction are really important. In the same environment: temp without this patch 34 temp with is 43 Register value is 0x240080E8 and 0x24008088 Michael -- Michael Nazzareno Trimarchi Amarula Solutions BV COO Co-Founder Cruquiuskade 47 Amsterdam 1018 AM NL T. +31(0)851119172 M. +39(0)3479132170 [`as] https://www.amarulasolutions.com
Re: Pull request for UEFI sub-system for NEXT
On Thu, Dec 03, 2020 at 10:19:59PM +0100, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit a2c832471115d382d6dd60697be5bc74d2636eea: > > Merge branch '2020-12-01-next-imports' into next (2020-12-02 11:35:02 > -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-next > > for you to fetch changes up to 3616b4f4b97411db8721ae38c0fb29e145f1aed6: > > sandbox: enable capsule update for testing (2020-12-03 21:22:50 +0100) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] i2c: at91: fix crash when using 'i2c probe'
When issuing 'i2c probe', the driver was crashing, because at probe
there is a request with zero length buffer to write to i2c bus.
The xfer_msg function assumes the buffer is always there, and never
checks for the buffer length.
=> i2c dev 0
Setting bus to 0
=> i2c probe
Valid chip addresses:
data abort
pc : [<7ffa97dc>] lr : [<7ffa96f8>]
reloc pc : [<66f277dc>]lr : [<66f276f8>]
sp : 7fb7c110 ip : 7ff87a28 fp : 7ff99938
r10: 0002 r9 : 7fb7dec0 r8 :
r7 : e181c600 r6 : 7fb88c20 r5 : r4 : 7fb7c128
r3 : r2 : 0001 r1 : r0 : 0009
Flags: nZCv IRQs off FIQs off Mode SVC_32
Code: eb0092f4 e1a5 e8bd81f0 e594300c (e5d33000)
Resetting CPU ...
Fixes: 8800e0fa20 ("i2c: atmel: add i2c driver")
Signed-off-by: Eugen Hristev
---
drivers/i2c/at91_i2c.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
index 9d6c6d80e2..dfd649cd57 100644
--- a/drivers/i2c/at91_i2c.c
+++ b/drivers/i2c/at91_i2c.c
@@ -50,6 +50,10 @@ static int at91_i2c_xfer_msg(struct at91_i2c_bus *bus,
struct i2c_msg *msg)
u32 i;
int ret = 0;
+ /* if there is no message to send/receive, just exit quietly */
+ if (msg->len == 0)
+ return ret;
+
readl(®->sr);
if (is_read) {
writel(TWI_CR_START, ®->cr);
--
2.25.1
[PATCH] net: eth_legacy - fix build CMD_PCAP
Fix typo which would cause a build error.
Fixes: 3eaac6307df ("net: introduce packet capture support")
Signed-off-by: Jorge Ramirez-Ortiz
---
net/eth_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/eth_legacy.c b/net/eth_legacy.c
index 6e0c058761..6870afb505 100644
--- a/net/eth_legacy.c
+++ b/net/eth_legacy.c
@@ -365,7 +365,7 @@ int eth_send(void *packet, int length)
ret = eth_current->send(eth_current, packet, length);
#if defined(CONFIG_CMD_PCAP)
if (ret >= 0)
- pcap_post(packet, lengeth, true);
+ pcap_post(packet, length, true);
#endif
return ret;
}
--
2.17.1
Re: [PATCH] efi_loader: allow disabling EFI secure boot in User Mode
Hi Heinrich, Heinrich Schuchardt writes: > On 11/30/20 7:22 PM, Paulo Alcantara wrote: >> Heinrich Schuchardt writes: >> >>> On 11/30/20 3:58 PM, Paulo Alcantara wrote: Introduce a new config option CONFIG_EFI_SECURE_BOOT_VAR_DISABLE to allow disabling EFI secure boot when the platform is operating in User Mode and there is an NV+BS EFI variable called "SecureBootDisable". Otherwise, keep it enabled by default. >>> >>> could you, please, explain why this is needed. >> >> I was just looking for an easier way to disable it without having to >> mess with the secure boot variables and possibly breaking secure boot >> altogether. Of course, we could do the same by creating such >> SecureBootDisable variable and forgetting about it. Since we're gonna >> provide u-boot package with the secure boot keys (PK, KEK, db, dbx) >> enrolled in (ESP)/ubootefi.var (generated by efivar.py script), and >> those certificates are only provided at build time, that would be tricky >> to get it enabled or disabled by removing and inserting the PK, finding >> the appropriate certificate depending on whether it is openSUSE or SLES. >> >> For instance, OVMF does have something like that [1]. >> >> [1] >> https://github.com/tianocore/edk2/blob/master/OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c#L682 >> >> Thanks. >> > how would you stop an attacker from disabling secure boot on your device > and tempering with it if this configuration were enabled? Yep. There isn't much we can do, and it is even unauthenticated. Please ignore this patch. Thanks!
RE: [PATCH v2 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties
Hello,
I've realized that this patch contains wrong bindings, "u-boot," prefix should
be dropped.
Also, configuration values to enable high speed modes in eSDHC are missing from
defconfigs - those has to be added as well.
Would sent a V3 for this series, please hold the review of this one.
Sorry for the miss and noise.
> -Original Message-
> From: U-Boot On Behalf Of Andrey Zhizhikin
> Sent: Wednesday, December 2, 2020 7:01 PM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Ye Li
> Subject: [PATCH v2 2/2] ARM: dts: imx8m: add UHS or HS400/HS400ES properties
>
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
>
>
> i.MX8M series provide support for high speed grades in their usdhc
> controllers,
> which has eMMC and SDHC connected to them.
>
> Enable this support across the entire i.MX8M family by providing quirks to
> usdhc
> controllers designated by storage media connected to them.
>
> Signed-off-by: Andrey Zhizhikin
> Cc: Stefano Babic
> Cc: Ye Li
> ---
> Changes in v2:
> - Moved u-boot binding for imx8mq-evk to separate autoincluded dtsi
> files
>
> arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi | 3 +++ arch/arm/dts/fsl-imx8qxp-
> mek-u-boot.dtsi | 3 +++
> arch/arm/dts/imx8mm-evk-u-boot.dtsi | 4
> arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 4
> arch/arm/dts/imx8mp-evk-u-boot.dtsi | 4
> arch/arm/dts/imx8mq-evk-u-boot.dtsi | 9 +
> 6 files changed, 27 insertions(+)
>
> diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi b/arch/arm/dts/fsl-
> imx8qm-mek-u-boot.dtsi
> index 80d6475b7c..2f86fcce3e 100644
> --- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> +++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
> @@ -118,8 +118,11 @@
>
> &usdhc1 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> };
>
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
> diff --git a/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi b/arch/arm/dts/fsl-
> imx8qxp-mek-u-boot.dtsi
> index 771ab635f1..f4332edac5 100644
> --- a/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> +++ b/arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi
> @@ -118,8 +118,11 @@
>
> &usdhc1 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> };
>
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi b/arch/arm/dts/imx8mm-evk-
> u-boot.dtsi
> index 9f77d3c6ff..67666a08ec 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -100,10 +100,14 @@
>
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
>
> &usdhc3 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> + u-boot,mmc-hs400-enhanced-strobe;
> };
>
> &i2c1 {
> diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi b/arch/arm/dts/imx8mn-
> ddr4-evk-u-boot.dtsi
> index 98b0b9891b..e03e635213 100644
> --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> @@ -97,10 +97,14 @@
>
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
>
> &usdhc3 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> + u-boot,mmc-hs400-enhanced-strobe;
> };
>
> &wdog1 {
> diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi b/arch/arm/dts/imx8mp-evk-
> u-boot.dtsi
> index 2452e9175c..0776b24a6e 100644
> --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> @@ -126,10 +126,14 @@
>
> &usdhc2 {
> u-boot,dm-spl;
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> };
>
> &usdhc3 {
> u-boot,dm-spl;
> + u-boot,mmc-hs400-1_8v;
> + u-boot,mmc-hs400-enhanced-strobe;
> };
>
> &wdog1 {
> diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi b/arch/arm/dts/imx8mq-evk-
> u-boot.dtsi
> index 4712cf6a44..d0fc64c433 100644
> --- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
> @@ -3,3 +3,12 @@
> ®_usdhc2_vmmc {
> u-boot,off-on-delay-us = <2>; };
> +
> +&usdhc1 {
> + u-boot,mmc-hs400-1_8v;
> +};
> +
> +&usdhc2 {
> + u-boot,sd-uhs-sdr104;
> + u-boot,sd-uhs-ddr50;
> +};
> --
> 2.17.1
-- andrey
[PATCH v1] ARM: dts: imx: imx8qm-rom7720: Fix AR8031 phy-mode
Fixed wrong PHY Interface Mode
As per kernel commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode)
the correct phy-mode should be "rgmii-id", so fix it accordingly
to fix the Ethernet regression.
This problem has been exposed by commit:
commit 13114f38e2ccea9386726d8b9831dfc310589548
Fix the phy-mode accordingly to fix the regression.
Signed-off-by: Oliver Graute
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Vladimir Oltean
---
arch/arm/dts/imx8qm-rom7720-a1.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8qm-rom7720-a1.dts
b/arch/arm/dts/imx8qm-rom7720-a1.dts
index 5f9ac955ed..d1f2fff869 100644
--- a/arch/arm/dts/imx8qm-rom7720-a1.dts
+++ b/arch/arm/dts/imx8qm-rom7720-a1.dts
@@ -293,7 +293,7 @@
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fec1>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-handle = <ðphy0>;
fsl,ar8031-phy-fixup;
fsl,magic-packet;
@@ -318,7 +318,7 @@
&fec2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fec2>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-handle = <ðphy1>;
fsl,ar8031-phy-fixup;
fsl,magic-packet;
--
2.17.1
RE: [SPECIFICATION RFC] The firmware and bootloader log specification
Hello Julius, I agree with you. Using an existing standard is better than inventing a new one in this case. I think using the coreboot logging is a good idea as there is indeed a lot of support already available and it is lightweight and simple. Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervo...@eltan.com W : http://www.eltan.com "This message contains confidential information. Unless you are the intended recipient of this message, any use of this message is strictly prohibited. If you have received this message in error, please immediately notify the sender by telephone +31-(0)73-5944664 or reply email, and immediately delete this message and all copies." -Original Message- From: Grub-devel [mailto:grub-devel-bounces+wvervoorn=eltan@gnu.org] On Behalf Of Julius Werner Sent: Thursday, December 3, 2020 2:18 AM To: Daniel Kiper Cc: Coreboot ; The development of GRUB 2 ; LKML ; systemd-de...@lists.freedesktop.org; trenchboot-de...@googlegroups.com; U-Boot Mailing List ; x...@kernel.org; xen-de...@lists.xenproject.org; al...@umass.edu; alexander.burmas...@oracle.com; allen.cryp...@gmail.com; andrew.coop...@citrix.com; ard.biesheu...@linaro.org; btrot...@gmail.com; dpsm...@apertussolutions.com; eric.devol...@oracle.com; eric.snowb...@oracle.com; h...@zytor.com; h...@n-dimensional.de; javi...@redhat.com; joao.m.mart...@oracle.com; kanth.ghatr...@oracle.com; konrad.w...@oracle.com; krystian.he...@3mdeb.com; l...@nuviainc.com; lukasz.hawry...@intel.com; l...@amacapital.net; michal.zygow...@3mdeb.com; mj...@google.com; mtott...@akamai.com; Vladimir 'phcoder' Serbinenko ; piotr.k...@3mdeb.com; pjo...@redhat.com; Paul Menzel ; roger@citrix.com; ross.philip...@oracle.com; tyhi...@linux.microsoft.com; Heinrich Schuchardt Subject: Re: [SPECIFICATION RFC] The firmware and bootloader log specification Standardizing in-memory logging sounds like an interesting idea, especially with regards to components that can run on top of different firmware stacks (things like GRUB or TF-A). But I would be a bit wary of creating a "new standard to rule them all" and then expecting all projects to switch what they have over to that. I think we all know https://xkcd.com/927/. Have you looked around and evaluated existing solutions that already have some proliferation first? I think it would be much easier to convince people to standardize on something that already has existing users and drivers available in multiple projects. In coreboot we're using a very simple character ring buffer that only has two 4-byte header fields: total size and cursor (i.e. current position where you would write the next character). The top 4 bits of the cursor field are reserved for flags, one of which is the "overflow" flag that tells you whether the ring-buffer already overflowed or not (so readers know whether to print the whole ring buffer, or only from the start to the current cursor). We try to dimension the buffers so they don't overflow on a single boot, but this approach allows us to log multiple boots on platforms that can persist memory across reboots, which sometimes comes in handy. The disadvantages of that approach compared to your proposal are lack of some features, like the facilities field (although one can still just print a tag like "<0>" or "<4>" behind each newline) or timestamps (coreboot instead has separate timestamp logging). But I think a really big advantage is size: in early firmware environments before DDR training, space is often very precious and we struggle to find more than a couple of kilobytes for the log buffer. If I look at the structure you proposed, that's already 24 bytes of overhead per individual message. If we were hooking that up to our normal printk() facility in coreboot (such that each invocation creates a new message header), that would probably waste about a third of the whole log buffer on overhead. I think a complicated, syslog-style logging structure that stores individual message blocks instead of a continuous character string isn't really suitable for firmware logging. FWIW the coreboot console has existing support in Linux (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/google/memconsole-coreboot.c), SeaBIOS (https://github.com/coreboot/seabios/blob/master/src/fw/coreboot.c#L219), TF-A (https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/coreboot/cbmem_console/aarch64/cbmem_console.S), GRUB (https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/i386/coreboot/cbmemc.c), U-Boot (https://github.com/u-boot/u-boot/blob/master/drivers/misc/cbmem_console.c) and probably a couple of others I'm not aware of. And the code to add support (especially when only appending) is so simple that it just takes a couple of lines to implement (binary code size to implement the format is also alwa
Re: [PATCH 29/34] configs: sama7g5: add mmc config for sdmmc0
On 03.12.2020 23:45, Jaehoon Chung wrote: > Hi, > > On 12/3/20 8:20 PM, eugen.hris...@microchip.com wrote: >> On 03.12.2020 13:11, Jaehoon Chung wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >>> content is safe >>> >>> On 12/3/20 7:47 PM, eugen.hris...@microchip.com wrote: On 03.12.2020 12:38, Jaehoon Chung wrote: > Hi, > > On 12/3/20 6:28 PM, Eugen Hristev wrote: >> Add new config for storing environment from sdmmc0. >> Also clean-up sama7g5ek_emmc1 to point to the proper mmc device. > > Just one question, Sorry, i didn't check entire patchset. > > What is different between sama7g5ek_mmc1 and sama7g5ek_mmc? Sama7g5ek_mmc is set to store the environment in the eMMC device soldered on the board which is connected on the SDMMC0 hardware block. sama7g5ek_mmc1 is set to store the environment on the SD-Card which can be inserted in the SD slot on the board which is connected on the SDMMC1 hardware block. So basically we have two possible boot/env store configurations, one on eMMC and one on SD-Card . >>> >>> If device can know which device is used to boot, then i think that it >>> doesn't need to add one more config. >>> It can know where env is stored at runtime. >>> (with CONFIG_ENV_FAT_DEVICE_AND_PART ":" and implement >>> mmc_get_env_dev()) >>> >> >> Can you explain a little more ? I do not understand how. >> How will u-boot know if it should read the env from SD or eMMC ? > > I don't have any knowledge of your SoC. Maybe you know more exactly. > If its SoC has some registers to get boot device, it's possible to get which > device is used to boot device. It does, but U-boot is not the first stage bootloader. We have a second stage that initializes the external RAM first. U-boot is in fact the third stage. > Then you can implement mmc_get_env_dev() in its board specific file. > Then it can be got with below sequence. > In env/fat.c > env_fat_devc_and_part() > -> part_str[0] += mmc_get_env_dev() > -> mmc_get_env_dev() will be returned to proper device after read register > relevant to checking device. > > If there is no register to get boot device, it may be impossible. Even if we know the boot device, we do not wish do enforce u-boot to store the env on the same boot device. This would mean hard rules on storing the env, which is something we wish to avoid. We would like to be able to select at compile time where to store the env and the default boot device. This would allow for example to have a very fast and small QSPI memory for storing the initial stages , but have u-boot load linux and store the env from/on eMMCs or SD-Cards. > > Best Regards, > Jaehoon Chung > > >> >>> >>> commit 6731bef6966ea2b26cdcfe0109ff5a950003fd03 >>> Refs: v2020.07-1080-g6731bef696 >>> Author: David Woodhouse >>> AuthorDate: Fri Jun 19 23:07:17 2020 +0100 >>> Commit: Tom Rini >>> CommitDate: Sun Jul 26 14:35:12 2020 -0400 >>> >>> env/fat.c: allow loading from a FAT partition on the MMC boot device >>> >>> I don't want to have to specify the device; only the partition. >>> >>> This allows me to use the same image on internal eMMC or SD card for >>> Banana Pi R2, and it finds its own environment either way. >>> >>> Signed-off-by: David Woodhouse >>> [trini: Add #if/#else/#endif logic around CONFIG_SYS_MMC_ENV_DEV >>> usage, >>> whitespace changes] >>> Signed-off-by: Tom Rini >>> >>> >>> Best Regards, >>> Jaehoon Chung >>> Eugen > > Best Regards, > Jaehoon Chung > >> >> Signed-off-by: Eugen Hristev >> --- >> board/atmel/sama7g5ek/MAINTAINERS | 1 + >> configs/sama7g5ek_mmc1_defconfig | 7 ++-- >> configs/sama7g5ek_mmc_defconfig | 67 >> +++ >> 3 files changed, 72 insertions(+), 3 deletions(-) >> create mode 100644 configs/sama7g5ek_mmc_defconfig >> >> diff --git a/board/atmel/sama7g5ek/MAINTAINERS >> b/board/atmel/sama7g5ek/MAINTAINERS >> index f66953ac4e..eac972968d 100644 >> --- a/board/atmel/sama7g5ek/MAINTAINERS >> +++ b/board/atmel/sama7g5ek/MAINTAINERS >> @@ -4,4 +4,5 @@ S: Maintained >> F: board/atmel/sama7g5ek.c >> F: include/configs/sama7g5ek.h >> F: configs/sama7g5ek_mmc1_defconfig >> +F: configs/sama7g5ek_mmc_defconfig >> >> diff --git a/configs/sama7g5ek_mmc1_defconfig >> b/configs/sama7g5ek_mmc1_defconfig >> index fa4c88ffa6..b6d2f4dd05 100644 >> --- a/configs/sama7g5ek_mmc1_defconfig >> +++ b/configs/sama7g5ek_mmc1_defconfig >> @@ -2,9 +2,10 @@ CONFIG_ARM=y >> CONFIG_ARCH_AT91=y >> CONFIG_SYS_TEXT_BASE=0x66f0 >> CONFIG_TARGET_SAMA7G5EK=y >> -CONFIG_NR_DRAM_BANKS=1 >> CONFIG_SYS_MALLOC_F_LEN=0x11000 >> +CONFIG_NR_DRAM_BANKS=1 >> CONFIG_
[PATCH 2/2] board: siemens: Add support for SIMATIC IOT2050 devices
From: Jan Kiszka This adds support for the IOT2050 Basic and Advanced devices. The Basic used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS quad-core version. Both variants are booted via a Siemens-provided FSBL that runs on the R5 cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot SPL, ATF and TEE have to reside in SPI flash. Full integration into a bootable image can be found on https://github.com/siemens/meta-iot2050 Based on original board support by Le Jin, Gao Nian and Chao Zeng. Signed-off-by: Jan Kiszka --- arch/arm/mach-k3/Kconfig | 1 + board/siemens/iot2050/Kconfig | 28 board/siemens/iot2050/MAINTAINERS | 8 ++ board/siemens/iot2050/Makefile| 10 ++ board/siemens/iot2050/README | 65 + board/siemens/iot2050/board.c | 229 ++ board/siemens/iot2050/config.mk | 8 ++ configs/iot2050_defconfig | 136 ++ include/configs/iot2050.h | 60 9 files changed, 545 insertions(+) create mode 100644 board/siemens/iot2050/Kconfig create mode 100644 board/siemens/iot2050/MAINTAINERS create mode 100644 board/siemens/iot2050/Makefile create mode 100644 board/siemens/iot2050/README create mode 100644 board/siemens/iot2050/board.c create mode 100644 board/siemens/iot2050/config.mk create mode 100644 configs/iot2050_defconfig create mode 100644 include/configs/iot2050.h diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index c7d186149b..b191e88b13 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -143,4 +143,5 @@ config SYS_K3_SPL_ATF source "board/ti/am65x/Kconfig" source "board/ti/j721e/Kconfig" +source "board/siemens/iot2050/Kconfig" endif diff --git a/board/siemens/iot2050/Kconfig b/board/siemens/iot2050/Kconfig new file mode 100644 index 00..28ba746936 --- /dev/null +++ b/board/siemens/iot2050/Kconfig @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (c) Siemens AG, 2018-2020 +# +# Authors: +# Le Jin +# Jan Kiszka + +config TARGET_IOT2050_A53 + bool "IOT2050 running on A53" + select ARM64 + select SOC_K3_AM6 + select BOARD_LATE_INIT + select SYS_DISABLE_DCACHE_OPS + select BINMAN + +if TARGET_IOT2050_A53 + +config SYS_BOARD + default "iot2050" + +config SYS_VENDOR + default "siemens" + +config SYS_CONFIG_NAME + default "iot2050" + +endif diff --git a/board/siemens/iot2050/MAINTAINERS b/board/siemens/iot2050/MAINTAINERS new file mode 100644 index 00..028fd22960 --- /dev/null +++ b/board/siemens/iot2050/MAINTAINERS @@ -0,0 +1,8 @@ +IOT2050 BOARD +M: Le Jin +M: Jan Kiszka +S: Maintained +F: board/siemens/iot2050/ +F: include/configs/iot2050.h +F: configs/iot2050_defconfig +F: arch/arm/dts/iot2050-* diff --git a/board/siemens/iot2050/Makefile b/board/siemens/iot2050/Makefile new file mode 100644 index 00..5f2cfa40e8 --- /dev/null +++ b/board/siemens/iot2050/Makefile @@ -0,0 +1,10 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Makefile for Siemens IOT2050 board +# Copyright (c) Siemens AG, 2018-2020 +# +# Authors: +# Le Jin +# + +obj-y += board.o diff --git a/board/siemens/iot2050/README b/board/siemens/iot2050/README new file mode 100644 index 00..b63f05b5cf --- /dev/null +++ b/board/siemens/iot2050/README @@ -0,0 +1,65 @@ +SIMATIC IOT2050 BASIC and ADVANCED +== + +The SIMATIC IOT2050 is an open industrial IoT gateway that is using the TI +AM6528 GP (Basic variant) or the AM6548 HS (Advanced variant). The Advanced +variant is prepared for secure boot. + +The IOT2050 starts only from OSPI. It loads a Siemens-provided bootloader +called SE-Boot for the MCU domain (R5F cores), then hands over to ATF and +OP-TEE, before booting U-Boot on the A53 cores. This describes how to build all +open artifacts into a flashable image for the OSPI flash. The flash image will +work on both variants. + + +Dependencies + + +ATF:Upstream release 2.4 or newer +OP-TEE: Upstream release 3.10.0 or newer + +Binary dependencies can be found in +https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild. +The following binaries from that source need to be present in the build folder: + + - tiboot3.bin + - sysfw.itb + - sysfw.itb_HS + + +Building + + +Make sure that CROSS_COMPILE is set appropriately: + +export CROSS_COMPILE=aarch64-linux-gnu- + +ATF: + +make PLAT=k3 SPD=opteed K3_USART=1 + +OP-TEE: + +make PLATFORM=k3-am65x CFG_ARM64_core=y \ + CFG_TEE_CORE_LOG_LEVEL=2 CFG_CONSOLE_UART=1 + +U-Boot: + +export ATF=/path/to/bl31.bin +export TEE=/path/to/tee-pager_v2.bin +make iot2050_defconfig +make + + +Flashing + + +Via U-Boot: + +sf probe +load mmc 0:1 $loadaddr /path/to/flash.bin +sf update $loadaddr 0x0 $filesize + +Via external programmer Dediprog
[PATCH 1/2] arm: dts: Add IOT2050 device tree files
From: Jan Kiszka
Prepares for the addition of the IOT2050 board which is based on the TI
AM65x. The board comes in two variants, Basic and Advanced, so there are
separate dts files. Furthermore, the SPL has its own device tree.
Based on original board support by Le Jin, Gao Nian and Chao Zeng.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/Makefile| 7 +-
arch/arm/dts/iot2050-advanced.dts| 62 +
arch/arm/dts/iot2050-basic.dts | 61 +
arch/arm/dts/iot2050-boot-image.dtsi | 105 +
arch/arm/dts/iot2050-common.dtsi | 341 +++
arch/arm/dts/iot2050-spl.dts | 16 ++
6 files changed, 591 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/iot2050-advanced.dts
create mode 100644 arch/arm/dts/iot2050-basic.dts
create mode 100644 arch/arm/dts/iot2050-boot-image.dtsi
create mode 100644 arch/arm/dts/iot2050-common.dtsi
create mode 100644 arch/arm/dts/iot2050-spl.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e2e8a5fb7a..bf2bd8e8a3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -968,7 +968,12 @@ dtb-$(CONFIG_STM32MP15x) += \
stm32mp15xx-dhcom-picoitx.dtb \
stm32mp15xx-dhcor-avenger96.dtb
-dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb k3-am654-r5-base-board.dtb
+dtb-$(CONFIG_SOC_K3_AM6) += \
+ k3-am654-base-board.dtb \
+ k3-am654-r5-base-board.dtb \
+ iot2050-spl.dtb \
+ iot2050-basic.dtb \
+ iot2050-advanced.dtb
dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
k3-j721e-r5-common-proc-board.dtb \
k3-j7200-common-proc-board.dtb \
diff --git a/arch/arm/dts/iot2050-advanced.dts
b/arch/arm/dts/iot2050-advanced.dts
new file mode 100644
index 00..ed8ef5beac
--- /dev/null
+++ b/arch/arm/dts/iot2050-advanced.dts
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2020
+ *
+ * Authors:
+ * Le Jin
+ * Jan Kiszka
+ */
+
+/dts-v1/;
+
+#include "iot2050-common.dtsi"
+#include "iot2050-boot-image.dtsi"
+
+/ {
+ compatible = "siemens,iot2050-advanced", "ti,am654";
+ model = "Siemens IOT2050 Advanced Base Board";
+
+ aliases {
+ mmc0 = &sdhci1;
+ mmc1 = &sdhci0;
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ /* 2G RAM */
+ reg = <0x 0x8000 0x 0x8000>,
+ <0x0008 0x8000 0x 0x>;
+ };
+};
+
+&main_pmx0 {
+ main_mmc0_pins_default: main_mmc0_pins_default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN, 0) /*
(B25) MMC0_CLK */
+ AM65X_IOPAD(0x01aC, PIN_INPUT_PULLUP, 0)/*
(B27) MMC0_CMD */
+ AM65X_IOPAD(0x01a4, PIN_INPUT_PULLUP, 0)/*
(A26) MMC0_DAT0 */
+ AM65X_IOPAD(0x01a0, PIN_INPUT_PULLUP, 0)/*
(E25) MMC0_DAT1 */
+ AM65X_IOPAD(0x019c, PIN_INPUT_PULLUP, 0)/*
(C26) MMC0_DAT2 */
+ AM65X_IOPAD(0x0198, PIN_INPUT_PULLUP, 0)/*
(A25) MMC0_DAT3 */
+ AM65X_IOPAD(0x0194, PIN_INPUT_PULLUP, 0)/*
(E24) MMC0_DAT4 */
+ AM65X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0)/*
(A24) MMC0_DAT5 */
+ AM65X_IOPAD(0x018c, PIN_INPUT_PULLUP, 0)/*
(B26) MMC0_DAT6 */
+ AM65X_IOPAD(0x0188, PIN_INPUT_PULLUP, 0)/*
(D25) MMC0_DAT7 */
+ AM65X_IOPAD(0x01b4, PIN_INPUT_PULLUP, 0)/*
(A23) MMC0_SDCD */
+ AM65X_IOPAD(0x01b0, PIN_INPUT, 0) /*
(C25) MMC0_DS */
+ >;
+ };
+};
+
+/* eMMC */
+&sdhci0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc0_pins_default>;
+ bus-width = <8>;
+ non-removable;
+ ti,driver-strength-ohm = <50>;
+};
+
+&main_uart0 {
+ status = "disabled";
+};
diff --git a/arch/arm/dts/iot2050-basic.dts b/arch/arm/dts/iot2050-basic.dts
new file mode 100644
index 00..dd27244b95
--- /dev/null
+++ b/arch/arm/dts/iot2050-basic.dts
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2020
+ *
+ * Authors:
+ * Le Jin
+ * Jan Kiszka
+ */
+
+/dts-v1/;
+
+#include "iot2050-common.dtsi"
+#include "iot2050-boot-image.dtsi"
+
+/ {
+ compatible = "siemens,iot2050-basic", "ti,am654";
+ model = "Siemens IOT2050 Basic Base Board";
+
+ memory@8000 {
+ device_type = "memory";
+ /* 1G RAM */
+ reg = <0x 0x8000 0x 0x4000>,
+ <0x0008 0x8000 0x 0x>;
+ };
+};
+
+/* eMMC */
+&sdhci0 {
+ status = "disabled";
+};
+
+&main_pmx0 {
+ main_ua
[PATCH 0/2] Add SIMATIC IOT2050 board support
This is the baseline support for the SIMATIC IOT2050 devices. Allows to boot mainline 5.10 kernels, but not the original BSP-derived kernel we currently ship as reference. This is due to the TI sysfw ABI breakages between 2.x and 3.x. We will soon provide a transitional kernel that allows booting both firmware ABIs - as long as full upstream kernel support is work in progress. Note that this baseline support lacks Ethernet drivers. We are working closely with TI to ensure that the to-be-upstreamed icssg-prueth driver will work both with new SR2.0 AM65x silicon as well as with SR1.0 which is used in the currently shipped IOT2050 devices. Related but not strictly needed for baseline support is [1], i.e. embedding of the watchdog firmware that is required on the AM65x. I will soon pick up that discussion again. A staging tree for complete IOT2050 support can be found at [2]. Full image integration is available via [3]. Jan [1] https://patchwork.ozlabs.org/project/uboot/patch/a42ab2dde9a588a8efc186474becd837f2e470c5.1592910910.git.jan.kis...@siemens.com/ [2] https://github.com/siemens/u-boot/commits/jan/iot2050 [3] https://github.com/siemens/meta-iot2050 Jan Kiszka (2): arm: dts: Add IOT2050 device tree files board: siemens: Add support for SIMATIC IOT2050 devices arch/arm/dts/Makefile| 7 +- arch/arm/dts/iot2050-advanced.dts| 62 + arch/arm/dts/iot2050-basic.dts | 61 + arch/arm/dts/iot2050-boot-image.dtsi | 105 + arch/arm/dts/iot2050-common.dtsi | 341 +++ arch/arm/dts/iot2050-spl.dts | 16 ++ arch/arm/mach-k3/Kconfig | 1 + board/siemens/iot2050/Kconfig| 28 +++ board/siemens/iot2050/MAINTAINERS| 8 + board/siemens/iot2050/Makefile | 10 + board/siemens/iot2050/README | 65 + board/siemens/iot2050/board.c| 229 ++ board/siemens/iot2050/config.mk | 8 + configs/iot2050_defconfig| 136 +++ include/configs/iot2050.h| 60 + 15 files changed, 1136 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/iot2050-advanced.dts create mode 100644 arch/arm/dts/iot2050-basic.dts create mode 100644 arch/arm/dts/iot2050-boot-image.dtsi create mode 100644 arch/arm/dts/iot2050-common.dtsi create mode 100644 arch/arm/dts/iot2050-spl.dts create mode 100644 board/siemens/iot2050/Kconfig create mode 100644 board/siemens/iot2050/MAINTAINERS create mode 100644 board/siemens/iot2050/Makefile create mode 100644 board/siemens/iot2050/README create mode 100644 board/siemens/iot2050/board.c create mode 100644 board/siemens/iot2050/config.mk create mode 100644 configs/iot2050_defconfig create mode 100644 include/configs/iot2050.h -- 2.26.2
