Re: [PATCH 1/5] imx: imx8mm-beacon: Move environment definition to env file
On Mon, Jun 12, 2023 at 11:27 AM Tom Rini wrote: > > On Mon, Jun 12, 2023 at 07:53:53AM -0500, Adam Ford wrote: > > On Sun, May 28, 2023 at 2:18 PM Adam Ford wrote: > > > > > > Instead of cluttering up a header file with a bunch of defines, > > > move the default environmental variables to a file called > > > imx8mm_beacon.env and reference it from the defconfig. > > > > > > > Stefano / Tom, > > > > Is this series OK? If so, I'll continue to do this to other Beacon > > and Logic PD boards. > > Yes, this all looked good to me, thanks! thanks adam Are you able to merge this in now that the July release is behind us? I haven't seen it get any traction. > > -- > Tom
Re: [PATCH 2/5] MAINTAINERS: Add some missing defconfig files to existing entries
On Tue, Jul 18, 2023 at 11:20 AM Tom Rini wrote: > > We have a few places where defconfigs were added (or renamed) and not > included in their previously listed MAINTAINERS entry, correct this. > For the beacon boards: Acked-by: Adam Ford > Signed-off-by: Tom Rini > --- > Cc: Adam Ford > Cc: Chris Packham > Cc: Jan Kiszka > Cc: Neil Armstrong > Cc: Stefan Roese > --- > board/Marvell/db-88f6820-amc/MAINTAINERS | 1 + > board/amlogic/w400/MAINTAINERS | 1 + > board/beacon/imx8mm/MAINTAINERS | 1 + > board/beacon/imx8mn/MAINTAINERS | 1 + > board/siemens/iot2050/MAINTAINERS| 3 ++- > board/solidrun/clearfog/MAINTAINERS | 2 ++ > 6 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/board/Marvell/db-88f6820-amc/MAINTAINERS > b/board/Marvell/db-88f6820-amc/MAINTAINERS > index abf5b7efdc93..d519eb47b84c 100644 > --- a/board/Marvell/db-88f6820-amc/MAINTAINERS > +++ b/board/Marvell/db-88f6820-amc/MAINTAINERS > @@ -4,3 +4,4 @@ S: Maintained > F: board/Marvell/db-88f6820-amc/ > F: include/configs/db-88f6820-amc.h > F: configs/db-88f6820-amc_defconfig > +F: configs/db-88f6820-amc_nand_defconfig > diff --git a/board/amlogic/w400/MAINTAINERS b/board/amlogic/w400/MAINTAINERS > index 117f79ea047b..19b1f30e6213 100644 > --- a/board/amlogic/w400/MAINTAINERS > +++ b/board/amlogic/w400/MAINTAINERS > @@ -5,6 +5,7 @@ L: u-boot-amlo...@groups.io > F: board/amlogic/w400/ > F: configs/bananapi-cm4-cm4io_defconfig > F: configs/bananapi-m2s_defconfig > +F: configs/odroid-n2l_defconfig > F: configs/radxa-zero2_defconfig > F: doc/board/amlogic/w400.rst > F: doc/board/amlogic/bananapi-cm4io.rst > diff --git a/board/beacon/imx8mm/MAINTAINERS b/board/beacon/imx8mm/MAINTAINERS > index d48ba8605bba..d8a5d0973694 100644 > --- a/board/beacon/imx8mm/MAINTAINERS > +++ b/board/beacon/imx8mm/MAINTAINERS > @@ -5,4 +5,5 @@ S: Maintained > F: board/beacon/imx8mm/ > F: include/configs/imx8mm_beacon.h > F: configs/imx8mm_beacon_defconfig > +F: configs/imx8mm_beacon_fspi_defconfig > F: doc/board/beacon/ > diff --git a/board/beacon/imx8mn/MAINTAINERS b/board/beacon/imx8mn/MAINTAINERS > index 4805cb255cc0..6dcef21a65e9 100644 > --- a/board/beacon/imx8mn/MAINTAINERS > +++ b/board/beacon/imx8mn/MAINTAINERS > @@ -5,3 +5,4 @@ F: board/beacon/imx8mn/ > F: include/configs/imx8mn_beacon.h > F: configs/imx8mn_beacon_defconfig > F: configs/imx8mn_beacon_2g_defconfig > +F: configs/imx8mn_beacon_fspi_defconfig > diff --git a/board/siemens/iot2050/MAINTAINERS > b/board/siemens/iot2050/MAINTAINERS > index 1b525356c2d6..aa21de2099f7 100644 > --- a/board/siemens/iot2050/MAINTAINERS > +++ b/board/siemens/iot2050/MAINTAINERS > @@ -4,6 +4,7 @@ M: Jan Kiszka > S: Maintained > F: board/siemens/iot2050/ > F: include/configs/iot2050.h > -F: configs/iot2050_defconfig > +F: configs/iot2050_pg1_defconfig > +F: configs/iot2050_pg2_defconfig > F: arch/arm/dts/iot2050-* > F: doc/board/siemens/iot2050.rst > diff --git a/board/solidrun/clearfog/MAINTAINERS > b/board/solidrun/clearfog/MAINTAINERS > index 6646d96206bf..55bd1278049a 100644 > --- a/board/solidrun/clearfog/MAINTAINERS > +++ b/board/solidrun/clearfog/MAINTAINERS > @@ -5,3 +5,5 @@ F: board/soldrun/clearfog/ > F: include/configs/clearfog.h > F: configs/clearfog_defconfig > F: configs/clearfog_gt_8k_defconfig > +F: configs/clearfog_sata_defconfig > +F: configs/clearfog_spi_defconfig > -- > 2.34.1 >
[PATCH 1/5] configs: imx8mp_beacon: Do not set SYS_CONSOLE_IS_IN_ENV
The hardware only supports a specific console port, so remove the
option to change the console location in the environment.
Signed-off-by: Adam Ford
---
configs/imx8mp_beacon_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/imx8mp_beacon_defconfig b/configs/imx8mp_beacon_defconfig
index b686af8d18..c758ff371d 100644
--- a/configs/imx8mp_beacon_defconfig
+++ b/configs/imx8mp_beacon_defconfig
@@ -42,6 +42,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_BOOTCOMMAND="mmc dev ${mmcdev}; if mmc rescan; then if run
loadbootscript; then run bootscript; else if run loadimage; then run mmcboot;
else run netboot; fi; fi; else booti ${loadaddr} - ${fdt_addr}; fi"
CONFIG_DEFAULT_FDT_FILE="imx8mp-beacon-kit.dtb"
+# CONFIG_SYS_CONSOLE_IS_IN_ENV is not set
# CONFIG_SYS_DEVICE_NULLDEV is not set
CONFIG_SPL_MAX_SIZE=0x26000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
--
2.40.1
[PATCH 2/5] configs: imx8mm_beacon: Enable fastboot downloading
Fastboot is necessary to use UUU enhanced functions, so enable it. Signed-off-by: Adam Ford --- configs/imx8mm_beacon_defconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig index 031470c169..886d912650 100644 --- a/configs/imx8mm_beacon_defconfig +++ b/configs/imx8mm_beacon_defconfig @@ -86,6 +86,11 @@ CONFIG_SPL_CLK_COMPOSITE_CCF=y CONFIG_CLK_COMPOSITE_CCF=y CONFIG_SPL_CLK_IMX8MM=y CONFIG_CLK_IMX8MM=y +CONFIG_USB_FUNCTION_FASTBOOT=y +CONFIG_FASTBOOT_BUF_ADDR=0x4280 +CONFIG_FASTBOOT_BUF_SIZE=0x2000 +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=2 CONFIG_MXC_GPIO=y CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y @@ -142,6 +147,5 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_SDP_LOADADDR=0x4040 -CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_SPL_USB_SDP_SUPPORT=y CONFIG_IMX_WATCHDOG=y -- 2.40.1
[PATCH 3/5] configs: imx8mm_beacon: Disable the WDT autostart
Auto-starting the WDT can cause false reboots when the user is not intentionally trying to use the WDT, so leave it off until it is requested. Signed-off-by: Adam Ford --- configs/imx8mm_beacon_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig index 886d912650..b33e113580 100644 --- a/configs/imx8mm_beacon_defconfig +++ b/configs/imx8mm_beacon_defconfig @@ -148,4 +148,5 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y CONFIG_SDP_LOADADDR=0x4040 CONFIG_SPL_USB_SDP_SUPPORT=y +# CONFIG_WATCHDOG_AUTOSTART is not set CONFIG_IMX_WATCHDOG=y -- 2.40.1
[PATCH 4/5] configs: imx8mn_beacon: Do not set SYS_CONSOLE_IS_IN_ENV
The hardware only supports a specific console port, so remove the
option to change the console location in the environment.
Signed-off-by: Adam Ford
---
configs/imx8mn_beacon_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig
index 9409d5142c..cfff20f84f 100644
--- a/configs/imx8mn_beacon_defconfig
+++ b/configs/imx8mn_beacon_defconfig
@@ -34,6 +34,7 @@ CONFIG_OF_SYSTEM_SETUP=y
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="mmc dev ${mmcdev}; if mmc rescan; then if run
loadbootscript; then run bootscript; else if run loadimage; then run mmcboot;
else run netboot; fi; fi; else booti ${loadaddr} - ${fdt_addr}; fi"
CONFIG_DEFAULT_FDT_FILE="imx8mn-beacon-kit.dtb"
+# CONFIG_SYS_CONSOLE_IS_IN_ENV is not set
CONFIG_SPL_MAX_SIZE=0x25000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x95
--
2.40.1
[PATCH 5/5] configs: imx8mn_beacon: Disable the WDT autostart
Auto-starting the WDT can cause false reboots when the user is not intentionally trying to use the WDT, so leave it off until it is requested. Signed-off-by: Adam Ford --- configs/imx8mn_beacon_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig index cfff20f84f..d1c27ce22c 100644 --- a/configs/imx8mn_beacon_defconfig +++ b/configs/imx8mn_beacon_defconfig @@ -150,4 +150,5 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y +# CONFIG_WATCHDOG_AUTOSTART is not set CONFIG_IMX_WATCHDOG=y -- 2.40.1
[PATCH 1/3] configs: rzg2_beacon: Disable the ability to remove devices
In order to save some space, disable the ability to dynamically remove devices. Without this, U-Boot is too large to load without recompiling TF-A. Signed-off-by: Adam Ford diff --git a/configs/rzg2_beacon_defconfig b/configs/rzg2_beacon_defconfig index 73abe966b8..7b14d225b5 100644 --- a/configs/rzg2_beacon_defconfig +++ b/configs/rzg2_beacon_defconfig @@ -48,6 +48,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_MMC_ENV_PART=2 CONFIG_VERSION_VARIABLE=y +# CONFIG_DM_DEVICE_REMOVE is not set CONFIG_REGMAP=y CONFIG_SYSCON=y CONFIG_CLK=y -- 2.40.1
[PATCH 2/3] configs: rzg2_beacon: Realign ENV location and offset
The ENV size and offset were changed to different values in Beacon's downstream release. Change them to the same values as the downstream for consistent behavior. Signed-off-by: Adam Ford diff --git a/configs/rzg2_beacon_defconfig b/configs/rzg2_beacon_defconfig index 7b14d225b5..534f641e84 100644 --- a/configs/rzg2_beacon_defconfig +++ b/configs/rzg2_beacon_defconfig @@ -3,7 +3,8 @@ CONFIG_ARCH_RMOBILE=y CONFIG_TEXT_BASE=0x5000 CONFIG_SYS_MALLOC_LEN=0x400 CONFIG_SYS_MALLOC_F_LEN=0x2000 -CONFIG_ENV_OFFSET=0x0 +CONFIG_ENV_SIZE=0x2000 +CONFIG_ENV_OFFSET=0xE000 CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="r8a774a1-beacon-rzg2m-kit" CONFIG_RCAR_GEN3=y -- 2.40.1
[PATCH 3/3] arm: rmobile: rzg2_beacon: Auto select Linux device tree by SoC
There is a function inside the board file to autodetect which device
tree is needed by U-Boot to properly load its own device tree, but
it currently defaults to always loading RZ/G2M for Linux. This is
not correct for other SoC variants. Add board_late_init function
to query the SoC name and use that to determine which device tree
is loaded for booting Linux.
Signed-off-by: Adam Ford
diff --git a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
index 99fe1edfb3..6d37ff6ac9 100644
--- a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
+++ b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -17,6 +18,38 @@ int board_init(void)
return 0;
}
+#if IS_ENABLED(CONFIG_BOARD_LATE_INIT)
+static u8 get_SoC_letter(void)
+{
+ const u8 *name = rzg_get_cpu_name();
+
+ if (*name)
+ return name[6];
+
+ return 0;
+}
+
+int board_late_init(void)
+{
+ /* If already defined, exit */
+ if (!env_get("fdt_file")) {
+ switch (get_SoC_letter()) {
+ case 'A':
+ env_set("fdt_file", "r8a774a1-beacon-rzg2m-kit.dtb");
+ break;
+ case 'B':
+ env_set("fdt_file", "r8a774b1-beacon-rzg2n-kit.dtb");
+ break;
+ case 'E':
+ env_set("fdt_file", "r8a774e1-beacon-rzg2h-kit.dtb");
+ break;
+ }
+ }
+
+ return 0;
+}
+#endif /* CONFIG_BOARD_LATE_INIT */
+
#if IS_ENABLED(CONFIG_MULTI_DTB_FIT)
int board_fit_config_name_match(const char *name)
{
diff --git a/configs/rzg2_beacon_defconfig b/configs/rzg2_beacon_defconfig
index 534f641e84..6894448b22 100644
--- a/configs/rzg2_beacon_defconfig
+++ b/configs/rzg2_beacon_defconfig
@@ -21,6 +21,7 @@ CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="mmc dev ${mmcdev}; if mmc rescan; then if run
loadbootscript; then run bootscript; else if run loadimage; then run mmcboot;
else run netboot; fi; fi; else booti ${loadaddr} - ${fdt_addr}; fi"
CONFIG_DEFAULT_FDT_FILE="r8a774a1-beacon-rzg2m-kit.dtb"
# CONFIG_BOARD_EARLY_INIT_F is not set
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SYS_MALLOC_BOOTPARAMS=y
CONFIG_HUSH_PARSER=y
CONFIG_SYS_MAXARGS=64
diff --git a/include/configs/beacon-rzg2m.h b/include/configs/beacon-rzg2m.h
index 65c01835cc..493b98fbdf 100644
--- a/include/configs/beacon-rzg2m.h
+++ b/include/configs/beacon-rzg2m.h
@@ -18,7 +18,6 @@
"fdt_addr=0x4800\0" \
"loadaddr=0x4808\0" \
"boot_fdt=try\0" \
- "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
"initrd_addr=0x4380\0" \
"mmcdev=1\0" \
"mmcpart=1\0" \
--
2.40.1
Re: [PATCH 1/3] configs: rzg2_beacon: Disable the ability to remove devices
On Thu, Oct 26, 2023 at 8:44 PM Marek Vasut wrote: > > On 10/26/23 01:13, Adam Ford wrote: > > In order to save some space, disable the ability to dynamically > > remove devices. Without this, U-Boot is too large to load without > > recompiling TF-A. > > Did you enable LTO yet ? Yes. > > Striping DM_REMOVE seems like a really bad idea, doesn't that break 'usb > reset' and its removal of devices ? I did not, but we can drop this one, and I'll just have to re-compile TF-A to load a larger U-Boot. adam
Re: [PATCH 3/3] arm: rmobile: rzg2_beacon: Auto select Linux device tree by SoC
On Thu, Oct 26, 2023 at 8:44 PM Marek Vasut wrote: > > On 10/26/23 01:13, Adam Ford wrote: > > There is a function inside the board file to autodetect which device > > tree is needed by U-Boot to properly load its own device tree, but > > it currently defaults to always loading RZ/G2M for Linux. This is > > not correct for other SoC variants. Add board_late_init function > > to query the SoC name and use that to determine which device tree > > is loaded for booting Linux. > > Can't this be scripted in environment instead ? Do you have a recommendation for how to read the SoC type from a script? adam
Re: [PATCH 2/3] configs: rzg2_beacon: Realign ENV location and offset
On Wed, Oct 25, 2023 at 6:13 PM Adam Ford wrote: > > The ENV size and offset were changed to different > values in Beacon's downstream release. Change them to the > same values as the downstream for consistent behavior. > > Signed-off-by: Adam Ford Marek, I know you had some feedback on other patches in this series. I'll drop one, and refactor another, but is this one ok to merge as-is or should I re-post without the other patches? adam > > diff --git a/configs/rzg2_beacon_defconfig b/configs/rzg2_beacon_defconfig > index 7b14d225b5..534f641e84 100644 > --- a/configs/rzg2_beacon_defconfig > +++ b/configs/rzg2_beacon_defconfig > @@ -3,7 +3,8 @@ CONFIG_ARCH_RMOBILE=y > CONFIG_TEXT_BASE=0x5000 > CONFIG_SYS_MALLOC_LEN=0x400 > CONFIG_SYS_MALLOC_F_LEN=0x2000 > -CONFIG_ENV_OFFSET=0x0 > +CONFIG_ENV_SIZE=0x2000 > +CONFIG_ENV_OFFSET=0xE000 > CONFIG_DM_GPIO=y > CONFIG_DEFAULT_DEVICE_TREE="r8a774a1-beacon-rzg2m-kit" > CONFIG_RCAR_GEN3=y > -- > 2.40.1 >
Re: [PATCH 0/7] arm: dts: Create common imx8mn-u-boot
On Mon, Aug 15, 2022 at 6:43 AM Adam Ford wrote: > > On Sun, Aug 14, 2022 at 5:57 PM Fabio Estevam wrote: > > > > Hi Adam, > > > > On Sun, Jul 31, 2022 at 8:46 PM Adam Ford wrote: > > > > > > Every imx8mn board has a bunch of similar entries on their > > > respective board-u-boot.dtsi file to make the board bootable. > > > Instead of maintaining multiple files with duplicate code, > > > have them all point to a new, common file. This file includes > > > the necessary nodes that were common to nearly all boards > > > and added spba1 to help faciliate SPL_DM_SERIAL. This also > > > adds support for CONFIG_FSPI_CONF_HEADER which can be used > > > to generate flash.bin files for booting from FlexSPI. > > > > > > Adam Ford (7): > > > arm: dts: imx8mn-u-boot: Create common imx8mn-u-boot.dtsi > > > arm: dts: imx8mn-beacon-kit: Consolidate with imx8mn-u-boot > > > arm: dts: imx8mn-bsh-smm-s2: Consolidate with imx8mn-u-boot > > > arm: dts: imx8mn-ddr4-evk: Consolidate with imx8mn-u-boot > > > arm: dts: imx8mn-evk: Consolidate with imx8mn-u-boot > > > arm: dts: imx8mn-var-som-symphony: Consolidate with imx8mn-u-boot > > > arm: dts: imx8mn-venice: Consolidate with imx8mn-u-boot > > > > For the series: > > > > Reviewed-by: Fabio Estevam > Stefano, It's been over a month, and I haven't heard any feedback from you and it doesn't appear this series has been accepted. Without it, Nano boards with DM_SERIAL in SPL won't' boot because of the device tree change which moved the UART's into a subnode. Are you able to apply to this series? As I mentioned before, I can squash the dependent patch into this series and push a V2 if you want. With a pending release in a few weeks, it would be nice to have the Nano boards booting again. thanks! adam > Thanks! > > Stefano, > > If you want me to squash the 1 dependent patch, I can squash it into > this series and submit a V2, but getting this series applied should > fix a bunch of boards which don't boot properly. > > adam
Re: [PATCH 4/4] ARM: dts: imx8m: imx8mm-mx8menlo: Enable SPL SDP support
On Mon, Sep 19, 2022 at 5:02 PM Fabio Estevam wrote: > > Hi Marek, > > On 19/09/2022 16:41, Marek Vasut wrote: > > Enable DM USB, DM PHY and USB gadget support in imx8mm-mx8menlo SPL > > to let the board continue SDP loading of second stage after the first > > stage was loaded by BootROM SDP implementation. It is not possible to > > jump back into BootROM v1 and let the BootROM implementation continue > > the SDP loading, all this has to be performed by the U-Boot CI HDRC > > controller driver and SDP protocol implementation, both of which fit > > into the SPL just barely. > > > > With this patch, it is possible to start both U-Boot SPL and U-Boot > > using e.g. uuu on this board as follows: > > > > $ uuu -brun spl flash.bin > > > > Signed-off-by: Marek Vasut > > This is great, I was able to test SPL SDP on an imx8mm-evk after > applying these > same changes to imx8mm-evk and reducing the SPL size. Fabio, Can you tell me what you did to reduce the SPL size? adam > > For the series: > > Reviewed-by: Fabio Estevam
Re: [PATCH 4/4] ARM: dts: imx8m: imx8mm-mx8menlo: Enable SPL SDP support
On Sat, Sep 24, 2022 at 1:52 PM Michael Nazzareno Trimarchi wrote: > > On Sat, Sep 24, 2022 at 8:38 PM Adam Ford wrote: > > > > On Mon, Sep 19, 2022 at 5:02 PM Fabio Estevam wrote: > > > > > > Hi Marek, > > > > > > On 19/09/2022 16:41, Marek Vasut wrote: > > > > Enable DM USB, DM PHY and USB gadget support in imx8mm-mx8menlo SPL > > > > to let the board continue SDP loading of second stage after the first > > > > stage was loaded by BootROM SDP implementation. It is not possible to > > > > jump back into BootROM v1 and let the BootROM implementation continue > > > > the SDP loading, all this has to be performed by the U-Boot CI HDRC > > > > controller driver and SDP protocol implementation, both of which fit > > > > into the SPL just barely. > > > > > > > > With this patch, it is possible to start both U-Boot SPL and U-Boot > > > > using e.g. uuu on this board as follows: > > > > > > > > $ uuu -brun spl flash.bin > > > > > > > > Signed-off-by: Marek Vasut > > > > > > This is great, I was able to test SPL SDP on an imx8mm-evk after > > > applying these > > > same changes to imx8mm-evk and reducing the SPL size. > > > > Fabio, > > > > Can you tell me what you did to reduce the SPL size? > > > > CONFIG_LTO from the other patch Bummer. I was hoping there was more. I already have LTO enabled. I was hoping there was more to it. adam > > Michael > > > adam > > > > > > For the series: > > > > > > Reviewed-by: Fabio Estevam > > > > -- > Michael Nazzareno Trimarchi > Co-Founder & Chief Executive Officer > M. +39 347 913 2170 > mich...@amarulasolutions.com > __ > > Amarula Solutions BV > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > T. +31 (0)85 111 9172 > i...@amarulasolutions.com > www.amarulasolutions.com
Re: [PATCH 4/4] ARM: dts: imx8m: imx8mm-mx8menlo: Enable SPL SDP support
On Sat, Sep 24, 2022 at 2:00 PM Michael Nazzareno Trimarchi wrote: > > > > Il sab 24 set 2022, 20:54 Adam Ford ha scritto: >> >> On Sat, Sep 24, 2022 at 1:52 PM Michael Nazzareno Trimarchi >> wrote: >> > >> > On Sat, Sep 24, 2022 at 8:38 PM Adam Ford wrote: >> > > >> > > On Mon, Sep 19, 2022 at 5:02 PM Fabio Estevam wrote: >> > > > >> > > > Hi Marek, >> > > > >> > > > On 19/09/2022 16:41, Marek Vasut wrote: >> > > > > Enable DM USB, DM PHY and USB gadget support in imx8mm-mx8menlo SPL >> > > > > to let the board continue SDP loading of second stage after the first >> > > > > stage was loaded by BootROM SDP implementation. It is not possible to >> > > > > jump back into BootROM v1 and let the BootROM implementation continue >> > > > > the SDP loading, all this has to be performed by the U-Boot CI HDRC >> > > > > controller driver and SDP protocol implementation, both of which fit >> > > > > into the SPL just barely. >> > > > > >> > > > > With this patch, it is possible to start both U-Boot SPL and U-Boot >> > > > > using e.g. uuu on this board as follows: >> > > > > >> > > > > $ uuu -brun spl flash.bin >> > > > > >> > > > > Signed-off-by: Marek Vasut >> > > > >> > > > This is great, I was able to test SPL SDP on an imx8mm-evk after >> > > > applying these >> > > > same changes to imx8mm-evk and reducing the SPL size. >> > > >> > > Fabio, >> > > >> > > Can you tell me what you did to reduce the SPL size? >> > > >> > >> > CONFIG_LTO from the other patch >> >> Bummer. I was hoping there was more. I already have LTO enabled. I >> was hoping there was more to it. > > > What version of U-Boot are you using? > > Mainline or some older one. Are you compile under yocto? I am using the Mainline with the aarch64 gcc from Ubuntu 22.04. I am over by ~1100 bytes with LTO enabled, but I'm going through my SPL drivers to see what I can either remove or reduce functionality. adam > > Michael > > >> >> adam >> > >> > Michael >> > >> > > adam >> > > > >> > > > For the series: >> > > > >> > > > Reviewed-by: Fabio Estevam >> > >> > >> > >> > -- >> > Michael Nazzareno Trimarchi >> > Co-Founder & Chief Executive Officer >> > M. +39 347 913 2170 >> > mich...@amarulasolutions.com >> > __ >> > >> > Amarula Solutions BV >> > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL >> > T. +31 (0)85 111 9172 >> > i...@amarulasolutions.com >> > www.amarulasolutions.com
Re: [PATCH 4/4] ARM: dts: imx8m: imx8mm-mx8menlo: Enable SPL SDP support
On Sat, Sep 24, 2022 at 4:47 PM Marek Vasut wrote: > > On 9/24/22 21:10, Adam Ford wrote: > > Hi, > > [...] > > > I am using the Mainline with the aarch64 gcc from Ubuntu 22.04. I am > > over by ~1100 bytes with LTO enabled, but I'm going through my SPL > > drivers to see what I can either remove or reduce functionality. > > Try > > $ aarch64...readelf -s spl/u-boot-spl | sort -nk 3 > > That should give you a list of large symbols you might want to inspect. Thank you! adam
Re: [PATCH 4/4] ARM: dts: imx8m: imx8mm-mx8menlo: Enable SPL SDP support
On Mon, Sep 26, 2022 at 11:59 AM Tim Harvey wrote: > > On Sat, Sep 24, 2022, 2:54 PM Adam Ford wrote: > > > > On Sat, Sep 24, 2022 at 4:47 PM Marek Vasut wrote: > > > > > > On 9/24/22 21:10, Adam Ford wrote: > > > > > > Hi, > > > > > > [...] > > > > > > > I am using the Mainline with the aarch64 gcc from Ubuntu 22.04. I am > > > > over by ~1100 bytes with LTO enabled, but I'm going through my SPL > > > > drivers to see what I can either remove or reduce functionality. > > > > > > Try > > > > > > $ aarch64...readelf -s spl/u-boot-spl | sort -nk 3 > > > > > > That should give you a list of large symbols you might want to inspect. > > > > Thank you! > > > > Adam, > > I'm curious what you find as my SPL for imx8mm_venice_defconfig also > overflows by about 3K when enabling what's needed here for SDP as > well. I have 4 different dram configs which are chewing up about 1K > each. Tim, I have it building successfully now, and it loads over USB. I had to disable BD718x7 PMIC children binding which required a small change to the PMIC driver [1]. I then removed HS400, HS200 and UHS support in SPL. Once I did all that, the code size fit into SPL space. [1] - https://patchwork.ozlabs.org/project/uboot/patch/20220817112403.68144-2-aford...@gmail.com/ I'll try to push my patch today or tomorrow. I was doing some other clean-up, but I might just push that as a small series in itself. adam > > Best Regards, > > Tim
Re: [PATCH 4/4] ARM: dts: imx8m: imx8mm-mx8menlo: Enable SPL SDP support
On Mon, Sep 26, 2022 at 12:12 PM Fabio Estevam wrote: > > Hi Adam, > > On Mon, Sep 26, 2022 at 2:07 PM Adam Ford wrote: > > > Tim, > > > > I have it building successfully now, and it loads over USB. I had to > > disable BD718x7 PMIC children binding which required a small change to > > the PMIC driver [1]. I then removed HS400, HS200 and UHS support in > > SPL. Once I did all that, the code size fit into SPL space. > > > > [1] - > > https://patchwork.ozlabs.org/project/uboot/patch/20220817112403.68144-2-aford...@gmail.com/ > > > > I'll try to push my patch today or tomorrow. I was doing some other > > clean-up, but I might just push that as a small series in itself. > > Ok, great. > > Does "ums 0 mmc 0" work for you if you run it, stop it via CTRL+C and rerun > it? > I didn't try UMS. I was going to investigate Fastboot, but I'll give it try this week. > On an imx8mm_evk, I get USB errors after the CTRL+C and ums fails to > mount after that. Do you need to do a USB reset or anything? adam
Re: [PATCH v2] imx8mn-ddr4-evk-u-boot: Fix broken boot
On Mon, Oct 3, 2022 at 9:02 AM Fabio Estevam wrote:
>
> When the imx8mn.dtsi file was pulled in from Linux, the UARTs
> were moved into an spba sub-node which wasn't being included
> in the SPL device tree. This meant the references to the UART
> weren't being handled properly and when booting the system would
> constantly reboot. Fix this by adding the spba node to the spl
> device tree to restore normal booting.
>
> Based on the patch from Adam Ford for the imx8mn-beacon-kit-u-boot
> board.
>
> Fixes: 4e5114daf9eb ("imx8mn: synchronise device tree with linux")
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - Fix typo in commit log: imx8mm.dtsi--> imx8mn.dtsi
>
> Hi Tom and Stefano,
>
> I know today is release day. Could this one be applied directly?
I have a series to push this fix into a common imx8mn-u-boot.dtsi file
[1]. Theoretically, pulling in that series should fix all the 8mn's.
[1] - https://patchwork.ozlabs.org/project/uboot/list/?series=312016
adam
>
> It fixes a boot regression.
>
> Thanks
>
> arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> index 78773c198e..3a9ba8b8c9 100644
> --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> @@ -26,6 +26,10 @@
> u-boot,dm-spl;
> };
>
> +&spba1 {
> + u-boot,dm-spl;
> +};
> +
> &clk {
> u-boot,dm-spl;
> u-boot,dm-pre-reloc;
> --
> 2.25.1
>
Re: [PATCH v1 21/26] imx8mn: synchronise device tree with linux
On Wed, Aug 3, 2022 at 8:02 AM Marcel Ziswiler
wrote:
>
> Hi Adam
>
> On Sun, 2022-07-31 at 11:58 -0500, Adam Ford wrote:
> > On Thu, Jul 21, 2022 at 8:44 AM Marcel Ziswiler wrote:
> > >
> > > From: Marcel Ziswiler
> > >
> > > Synchronise device tree with linux v5.19-rc5.
> > >
> > > Signed-off-by: Marcel Ziswiler
> >
> > For what it's worth to others who may have been impacted, this patch
> > broke my nano booting because the imx8mn.dtsi now has the UART's as
> > subnodes to spba1 which wasn't being included in SPL's device tree.
> > It's likely to impact others who are booting with DM_SERIAL enabled on
> > their Nano.
>
> Sorry about that.
>
> > To fix, I had to add a small line of code to my
> > imx8mn-beacon-kit-u-boot.dtsi file with the following:
> >
> > &spba1 {
> >u-boot,dm-spl;
> > };
> >
> > With that, my board boots again. If anyone else is using DM_SERIAL
> > and having issues no longer starting, give that a try.
> >
> > Since there are few nano boards with common -u-boot.dtsi entries, it
> > seems like it makes sense to have a common imx8mn-u-boot.dtsi file
> > like we do for Mini and Plus. I'll try to work on that as I have
> > time. (hopefully today)
>
> Thanks for your help in correcting this.
Marcel,
Have you seen the patch series I posted at [1]?
I know Tim Harvey replied 'tested-by' to the cover letter. Might you
have a chance to test it?
[1] - https://patchwork.ozlabs.org/project/uboot/list/?series=312016
>
> Cheers
>
> Marcel
Re: [PATCH 1/7] arm: dts: imx8mn-u-boot: Create common imx8mn-u-boot.dtsi
On Sun, Jul 31, 2022 at 6:46 PM Adam Ford wrote:
>
> Multiple boards create duplicate entries in their respective
> -u-boot.dtsi files which all basically do the same thing.
> To consolidate these and make it easier to make improvements
> going forward, consolidate them all into one place.
>
> This file creates a flash.bin image using binman, and supports
> LPDDR4, DDR4 and DDR3. Since individual boards use different
> peripherals and different UART ports, those entries were kept
> in their respective board files, but the spba1 node was addded
> which contains all UART1-3 to help facilitate SPL_DM_SERIAL.
> Individual users will still need to include their respective
> UART and pinctrl nodes for those UARTS.
>
> This consolidated file also supports generating a flash.bin file
> which can boot from flexSPI if CONFIG_FSPI_CONF_HEADER is
> enabled.
>
Fabio / Peng,
Any chance either one of you could review this? This series should
fix any Nano boards that cannot boot and currently use DM_SERIAL.
after 4e5114daf9eb ("imx8mn: synchronise device tree with linux")
which moved the UART nodes under the SPBA node.
thanks
adam
> Signed-off-by: Adam Ford
> ---
> Patches on top of [1]
>
> [1] -
> https://patchwork.ozlabs.org/project/uboot/patch/20220731171610.487086-1-aford...@gmail.com/
>
> diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi
> new file mode 100644
> index 00..327d4070fc
> --- /dev/null
> +++ b/arch/arm/dts/imx8mn-u-boot.dtsi
> @@ -0,0 +1,248 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2022 Logic PD, Inc dba Beacon EmbeddedWorks
> + */
> +
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> + };
> +
> + wdt-reboot {
> + compatible = "wdt-reboot";
> + wdt = <&wdog1>;
> + u-boot,dm-spl;
> + };
> +};
> +
> +&{/soc@0} {
> + u-boot,dm-pre-reloc;
> + u-boot,dm-spl;
> +};
> +
> +&aips1 {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +&aips2 {
> + u-boot,dm-spl;
> +};
> +
> +&aips3 {
> + u-boot,dm-spl;
> +};
> +
> +&aips4 {
> + u-boot,dm-spl;
> +};
> +
> +&clk {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ assigned-clock-rates;
> +};
> +
> +&iomuxc {
> + u-boot,dm-spl;
> +};
> +
> +&osc_24m {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +&spba1 {
> + u-boot,dm-spl;
> +};
> +
> +&wdog1 {
> + u-boot,dm-spl;
> +};
> +
> +&binman {
> +u-boot-spl-ddr {
> + filename = "u-boot-spl-ddr.bin";
> + pad-byte = <0xff>;
> + align-size = <4>;
> + align = <4>;
> +
> + u-boot-spl {
> + align-end = <4>;
> + filename = "u-boot-spl.bin";
> + };
> +
> + ddr-1d-imem-fw {
> +#ifdef CONFIG_IMX8M_LPDDR4
> + filename = "lpddr4_pmu_train_1d_imem.bin";
> +#elif CONFIG_IMX8M_DDR4
> + filename = "ddr4_imem_1d.bin";
> +#else
> + filename = "ddr3_imem_1d.bin";
> +#endif
> + type = "blob-ext";
> + align-end = <4>;
> + };
> +
> + ddr-1d-dmem-fw {
> +#ifdef CONFIG_IMX8M_LPDDR4
> + filename = "lpddr4_pmu_train_1d_dmem.bin";
> +#elif CONFIG_IMX8M_DDR4
> + filename = "ddr4_dmem_1d.bin";
> +#else
> + filename = "ddr3_dmem_1d.bin";
> +#endif
> + type = "blob-ext";
> + align-end = <4>;
> + };
> +
> + ddr-2d-imem-fw {
> +#ifdef CONFIG_IMX8M_LPDDR4
> + filename = "lpddr4_pmu_train_2d_imem.bin";
> +#elif CONFIG_IMX8M_DDR4
> + filename = "ddr4_imem_2d.bin";
> +#endif
> + type = "blob-ext";
> +
Re: [PATCH 0/7] arm: dts: Create common imx8mn-u-boot
On Sun, Aug 14, 2022 at 5:57 PM Fabio Estevam wrote: > > Hi Adam, > > On Sun, Jul 31, 2022 at 8:46 PM Adam Ford wrote: > > > > Every imx8mn board has a bunch of similar entries on their > > respective board-u-boot.dtsi file to make the board bootable. > > Instead of maintaining multiple files with duplicate code, > > have them all point to a new, common file. This file includes > > the necessary nodes that were common to nearly all boards > > and added spba1 to help faciliate SPL_DM_SERIAL. This also > > adds support for CONFIG_FSPI_CONF_HEADER which can be used > > to generate flash.bin files for booting from FlexSPI. > > > > Adam Ford (7): > > arm: dts: imx8mn-u-boot: Create common imx8mn-u-boot.dtsi > > arm: dts: imx8mn-beacon-kit: Consolidate with imx8mn-u-boot > > arm: dts: imx8mn-bsh-smm-s2: Consolidate with imx8mn-u-boot > > arm: dts: imx8mn-ddr4-evk: Consolidate with imx8mn-u-boot > > arm: dts: imx8mn-evk: Consolidate with imx8mn-u-boot > > arm: dts: imx8mn-var-som-symphony: Consolidate with imx8mn-u-boot > > arm: dts: imx8mn-venice: Consolidate with imx8mn-u-boot > > For the series: > > Reviewed-by: Fabio Estevam Thanks! Stefano, If you want me to squash the 1 dependent patch, I can squash it into this series and submit a V2, but getting this series applied should fix a bunch of boards which don't boot properly. adam
[PATCH 1/4] configs: imx8mn_beacon: Re-align memory to standard imx8mn settings
The imx8mn_beacon board does not use the same memory map as the reference design from NXP or other imx8mn boards. As such, memory is more limited in SPL. Moving SPL_BSS_START_ADDR and SPL_STACK to default locations increases the amount of available meory for the SPL stack. Doing this allows the board to no longer define CONFIG_MALLOC_F_ADDR. Since SYS_LOAD_ADDR also does not align with other boards, move it too. Signed-off-by: Adam Ford --- Depends on https://patchwork.ozlabs.org/project/uboot/list/?series=312020 https://patchwork.ozlabs.org/project/uboot/list/?series=312016 https://patchwork.ozlabs.org/project/uboot/list/?series=312002 diff --git a/configs/imx8mn_beacon_2g_defconfig b/configs/imx8mn_beacon_2g_defconfig index bd17788768..98a75d4950 100644 --- a/configs/imx8mn_beacon_2g_defconfig +++ b/configs/imx8mn_beacon_2g_defconfig @@ -15,10 +15,9 @@ CONFIG_TARGET_IMX8MN_BEACON=y CONFIG_IMX8MN_BEACON_2GB_LPDDR=y CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000 CONFIG_SPL=y CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x4800 -CONFIG_SYS_LOAD_ADDR=0x4048 +CONFIG_SYS_LOAD_ADDR=0x4200 CONFIG_SYS_MEMTEST_START=0x4000 CONFIG_SYS_MEMTEST_END=0x4400 CONFIG_LTO=y @@ -34,12 +33,12 @@ CONFIG_DEFAULT_FDT_FILE="imx8mn-beacon-kit.dtb" CONFIG_ARCH_MISC_INIT=y CONFIG_SPL_MAX_SIZE=0x25000 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y -CONFIG_SPL_BSS_START_ADDR=0x95e000 +CONFIG_SPL_BSS_START_ADDR=0x95 CONFIG_SPL_BSS_MAX_SIZE=0x2000 CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_BOOTROM_SUPPORT=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x187ff0 +CONFIG_SPL_STACK=0x98 CONFIG_SYS_SPL_MALLOC=y CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x4220 diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig index 738d308f45..271578985f 100644 --- a/configs/imx8mn_beacon_defconfig +++ b/configs/imx8mn_beacon_defconfig @@ -14,10 +14,9 @@ CONFIG_SPL_TEXT_BASE=0x912000 CONFIG_TARGET_IMX8MN_BEACON=y CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000 CONFIG_SPL=y CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x4800 -CONFIG_SYS_LOAD_ADDR=0x4048 +CONFIG_SYS_LOAD_ADDR=0x4200 CONFIG_SYS_MEMTEST_START=0x4000 CONFIG_SYS_MEMTEST_END=0x4400 CONFIG_LTO=y @@ -33,12 +32,12 @@ CONFIG_DEFAULT_FDT_FILE="imx8mn-beacon-kit.dtb" CONFIG_ARCH_MISC_INIT=y CONFIG_SPL_MAX_SIZE=0x25000 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y -CONFIG_SPL_BSS_START_ADDR=0x95e000 +CONFIG_SPL_BSS_START_ADDR=0x95 CONFIG_SPL_BSS_MAX_SIZE=0x2000 CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_BOOTROM_SUPPORT=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x187ff0 +CONFIG_SPL_STACK=0x98 CONFIG_SYS_SPL_MALLOC=y CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x4220 diff --git a/configs/imx8mn_beacon_fspi_defconfig b/configs/imx8mn_beacon_fspi_defconfig index ecaefd8930..6da2182eb3 100644 --- a/configs/imx8mn_beacon_fspi_defconfig +++ b/configs/imx8mn_beacon_fspi_defconfig @@ -14,10 +14,9 @@ CONFIG_SPL_TEXT_BASE=0x912000 CONFIG_TARGET_IMX8MN_BEACON=y CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000 CONFIG_SPL=y CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x4800 -CONFIG_SYS_LOAD_ADDR=0x4048 +CONFIG_SYS_LOAD_ADDR=0x4200 CONFIG_SYS_MEMTEST_START=0x4000 CONFIG_SYS_MEMTEST_END=0x4400 CONFIG_LTO=y @@ -33,12 +32,12 @@ CONFIG_DEFAULT_FDT_FILE="imx8mn-beacon-kit.dtb" CONFIG_ARCH_MISC_INIT=y CONFIG_SPL_MAX_SIZE=0x25000 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y -CONFIG_SPL_BSS_START_ADDR=0x95e000 +CONFIG_SPL_BSS_START_ADDR=0x95 CONFIG_SPL_BSS_MAX_SIZE=0x2000 CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_BOOTROM_SUPPORT=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x187ff0 +CONFIG_SPL_STACK=0x98 CONFIG_SYS_SPL_MALLOC=y CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x4220 diff --git a/include/configs/imx8mn_beacon.h b/include/configs/imx8mn_beacon.h index 6faecbde77..930b11b75e 100644 --- a/include/configs/imx8mn_beacon.h +++ b/include/configs/imx8mn_beacon.h @@ -13,14 +13,6 @@ #define CONFIG_SYS_UBOOT_BASE \ (QSPI0_AMBA_BASE + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512) -#ifdef CONFIG_SPL_BUILD -/* malloc f used before GD_FLG_FULL_MALLOC_INIT set */ -#define CONFIG_MALLOC_F_ADDR 0x184000 - -/* For RAW image gives a error info not panic */ - -#endif /* CONFIG_SPL_BUILD */ - /* Initial environment variables */ #define CONFIG_EXTRA_ENV_SETTINGS \ "script=boot.scr\0" \ -- 2.34.1
[PATCH 3/4] configs: imx8mn_beacon: Enable SPL_DM_PMIC_BD71837
To properly operate the Nano with LPDDR4 at 1.6GHz, the voltage needs to be adjusted before DDR is initialized. Enable the PMIC in SPL to do this. Signed-off-by: Adam Ford diff --git a/configs/imx8mn_beacon_2g_defconfig b/configs/imx8mn_beacon_2g_defconfig index 98a75d4950..fda545a9ad 100644 --- a/configs/imx8mn_beacon_2g_defconfig +++ b/configs/imx8mn_beacon_2g_defconfig @@ -121,6 +121,7 @@ CONFIG_PINCTRL_IMX8M=y CONFIG_DM_PMIC=y # CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_DM_PMIC_BD71837=y +CONFIG_SPL_DM_PMIC_BD71837=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_BD71837=y CONFIG_DM_REGULATOR_FIXED=y diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig index 271578985f..0ffcbcb475 100644 --- a/configs/imx8mn_beacon_defconfig +++ b/configs/imx8mn_beacon_defconfig @@ -125,6 +125,7 @@ CONFIG_PINCTRL_IMX8M=y CONFIG_DM_PMIC=y # CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_DM_PMIC_BD71837=y +CONFIG_SPL_DM_PMIC_BD71837=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_BD71837=y CONFIG_DM_REGULATOR_FIXED=y diff --git a/configs/imx8mn_beacon_fspi_defconfig b/configs/imx8mn_beacon_fspi_defconfig index 6da2182eb3..94d069cbfa 100644 --- a/configs/imx8mn_beacon_fspi_defconfig +++ b/configs/imx8mn_beacon_fspi_defconfig @@ -125,6 +125,7 @@ CONFIG_PINCTRL_IMX8M=y CONFIG_DM_PMIC=y # CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_DM_PMIC_BD71837=y +CONFIG_SPL_DM_PMIC_BD71837=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_BD71837=y CONFIG_DM_REGULATOR_FIXED=y -- 2.34.1
[PATCH 2/4] regulator: bd718x7: Only bind children when PMIC_CHILDREN is enabled
If the bd718x7 is required, but PMIC_CHILDREN is disabled, this
driver throws a compile error. Fix this by putting the function
to bind children into an if-statement checking for PMIC_CHILDREN.
Allowing PMIC_CHILDREN to be disabled in SPL saves some space and
still permits some read/write functions to access the PMIC in
early startup.
Signed-off-by: Adam Ford
diff --git a/drivers/power/pmic/bd71837.c b/drivers/power/pmic/bd71837.c
index cb9238972f..fdbbd6f559 100644
--- a/drivers/power/pmic/bd71837.c
+++ b/drivers/power/pmic/bd71837.c
@@ -63,10 +63,11 @@ static int bd71837_bind(struct udevice *dev)
debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
- children = pmic_bind_children(dev, regulators_node, pmic_children_info);
- if (!children)
- debug("%s: %s - no child found\n", __func__, dev->name);
-
+ if (CONFIG_IS_ENABLED(PMIC_CHILDREN)) {
+ children = pmic_bind_children(dev, regulators_node,
pmic_children_info);
+ if (!children)
+ debug("%s: %s - no child found\n", __func__, dev->name);
+ }
/* Always return success for this device */
return 0;
}
--
2.34.1
[PATCH 4/4] imx: imx8mn-beacon: Configure PMIC before DDR initialization
The DDR is configured for LPDDR4 running at 1.6GHz which requires
the voltage on the PMIC to rise a bit or it will be running out of
spec.
Signed-off-by: Adam Ford
diff --git a/board/beacon/imx8mn/spl.c b/board/beacon/imx8mn/spl.c
index 029f71bc99..9acd916180 100644
--- a/board/beacon/imx8mn/spl.c
+++ b/board/beacon/imx8mn/spl.c
@@ -74,6 +74,38 @@ static iomux_v3_cfg_t const pwm_pads[] = {
IMX8MN_PAD_GPIO1_IO01__PWM1_OUT | MUX_PAD_CTRL(PWM1_PAD_CTRL),
};
+static int power_init_board(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = pmic_get("pmic@4b", &dev);
+ if (ret == -ENODEV) {
+ puts("No pmic\n");
+ return 0;
+ }
+
+ if (ret != 0)
+ return ret;
+
+ /* decrease RESET key long push time from the default 10s to 10ms */
+ pmic_reg_write(dev, BD718XX_PWRONCONFIG1, 0x0);
+
+ /* unlock the PMIC regs */
+ pmic_reg_write(dev, BD718XX_REGLOCK, 0x1);
+
+ /* increase VDD_SOC to typical value 0.85v before first DRAM access */
+ pmic_reg_write(dev, BD718XX_BUCK1_VOLT_RUN, 0x0f);
+
+ /* increase VDD_DRAM to 0.975v for 3Ghz DDR */
+ pmic_reg_write(dev, BD718XX_1ST_NODVS_BUCK_VOLT, 0x83);
+
+ /* lock the PMIC regs */
+ pmic_reg_write(dev, BD718XX_REGLOCK, 0x11);
+
+ return 0;
+}
+
int board_early_init_f(void)
{
/* Claiming pwm pins prevents LCD flicker during startup*/
@@ -107,6 +139,9 @@ void board_init_f(ulong dummy)
enable_tzc380();
+ /* LPDDR4 at 1.6GHz requires a voltage adjustment on the PMIC */
+ power_init_board();
+
/* DDR initialization */
spl_dram_init();
--
2.34.1
[PATCH V4] arm64: imx: Add support for imx8mp-beacon-kit
Beacon Embedded has an i.MX8M Plus development kit which consists
of a SOM + baseboard. The SOM includes Bluetooth, WiFi, QSPI, eMMC,
and one Ethernet PHY. The baseboard includes audio, HDMI, USB-C Dual
Role port, USB Hub with five ports, a PCIe slot, and a second Ethernet
PHY. The device trees are already queued for inclusion in Linux 6.3.
Signed-off-by: Adam Ford
Reviewed-by: Tom Rini
---
V4: Rebase off Marek V's EQOS series.
Remove code no longer needed from the EQOS series
Remove unnecessary include files.
V3: Fix Doc indicies to fix errors with 'make htmldocs'
Remove duplicated entries in imx8mp_beacon.env found in env_default.h
Remove unnecessary include options from imx8mp_beacon.h
V2: Move default environment from imx8mp_beacon.h to imx8mp_beacon.env
Move README to beacon-imx8mp.rst
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d9b719f85d..d812ad4048 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -986,6 +986,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-beacon-kit.dtb \
imx8mq-mnt-reform2.dtb \
imx8mq-phanbell.dtb \
+ imx8mp-beacon-kit.dtb \
imx8mp-dhcom-pdk2.dtb \
imx8mp-evk.dtb \
imx8mp-icore-mx8mp-edimm2.2.dtb \
diff --git a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
new file mode 100644
index 00..0f7c91a078
--- /dev/null
+++ b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022 Logic PD, Inc DBA Beacon EmbeddedWorks
+ */
+
+#include "imx8mp-u-boot.dtsi"
+
+/ {
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <&wdog1>;
+ u-boot,dm-spl;
+ };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25} {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
+ u-boot,dm-spl;
+};
+
+&crypto {
+ u-boot,dm-spl;
+};
+
+&eqos {
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+ðphy0 {
+ reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <15000>;
+ reset-deassert-us = <10>;
+};
+
+&fec {
+ phy-reset-gpios = <&gpio4 18 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <15>;
+ phy-reset-post-delay = <100>;
+};
+
+&flexspi {
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_400M>;
+};
+
+&gpio1 {
+ u-boot,dm-spl;
+};
+
+&gpio2 {
+ u-boot,dm-spl;
+};
+
+&gpio3 {
+ u-boot,dm-spl;
+};
+
+&gpio4 {
+ u-boot,dm-spl;
+};
+
+&gpio5 {
+ u-boot,dm-spl;
+};
+
+&i2c1 {
+ u-boot,dm-spl;
+};
+
+&i2c2 {
+ u-boot,dm-spl;
+};
+
+&i2c3 {
+ u-boot,dm-spl;
+};
+
+&pca6416 {
+ compatible = "ti,tca6416";
+ label = "exp4";
+};
+
+&pca6416_1 {
+ compatible = "ti,tca6416";
+ label = "exp4";
+};
+
+&pca6416_3 {
+ compatible = "ti,tca6416";
+ label = "exp2";
+};
+
+&pinctrl_i2c1 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_pmic {
+ u-boot,dm-spl;
+};
+
+&pinctrl_reg_usdhc2_vmmc {
+ u-boot,dm-spl;
+};
+
+&pinctrl_uart2 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_usdhc2_gpio {
+ u-boot,dm-spl;
+};
+
+&pinctrl_usdhc2 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_usdhc3 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_wdog {
+ u-boot,dm-spl;
+};
+
+®_usdhc2_vmmc {
+ u-boot,dm-spl;
+ u-boot,off-on-delay-us = <2>;
+};
+
+&sec_jr0 {
+ u-boot,dm-spl;
+};
+
+&sec_jr1 {
+ u-boot,dm-spl;
+};
+
+&sec_jr2 {
+ u-boot,dm-spl;
+};
+
+&tpm {
+ compatible = "tcg,tpm_tis-spi";
+};
+
+&uart2 {
+ u-boot,dm-spl;
+};
+
+&usdhc1 {
+ u-boot,dm-spl;
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC1>;
+ assigned-clock-rates = <4>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_400M>;
+};
+
+&usdhc2 {
+ u-boot,dm-spl;
+ sd-uhs-sdr104;
+ sd-uhs-ddr50;
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC2>;
+ assigned-clock-rates = <4>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_400M>;
+};
+
+&usdhc3 {
+ u-boot,dm-spl;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC3>;
+ assigned-clock-rates = <4>;
+ assigned-clock-parents = <&clk IMX8MP_SY
[PATCH V5] arm64: imx: Add support for imx8mp-beacon-kit
Beacon Embedded has an i.MX8M Plus development kit which consists
of a SOM + baseboard. The SOM includes Bluetooth, WiFi, QSPI, eMMC,
and one Ethernet PHY. The baseboard includes audio, HDMI, USB-C Dual
Role port, USB Hub with five ports, a PCIe slot, and a second Ethernet
PHY. The device trees are already queued for inclusion in Linux 6.3.
Signed-off-by: Adam Ford
Reviewed-by: Tom Rini
---
V5: Rebase off next instead of imx branch.
Replace u-boot,dm-spl with bootph-pre-ram
V4: Rebase off Marek V's EQOS series.
Remove code no longer needed from the EQOS series
Remove unnecessary include files.
V3: Fix Doc indicies to fix errors with 'make htmldocs'
Remove duplicated entries in imx8mp_beacon.env found in env_default.h
Remove unnecessary include options from imx8mp_beacon.h
V2: Move default environment from imx8mp_beacon.h to imx8mp_beacon.env
Move README to beacon-imx8mp.rst
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c160e884bf..eff9c69969 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -995,6 +995,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-beacon-kit.dtb \
imx8mq-mnt-reform2.dtb \
imx8mq-phanbell.dtb \
+ imx8mp-beacon-kit.dtb \
imx8mp-dhcom-pdk2.dtb \
imx8mp-evk.dtb \
imx8mp-icore-mx8mp-edimm2.2.dtb \
diff --git a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
new file mode 100644
index 00..5ca631e9d8
--- /dev/null
+++ b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022 Logic PD, Inc DBA Beacon EmbeddedWorks
+ */
+
+#include "imx8mp-u-boot.dtsi"
+
+/ {
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <&wdog1>;
+ bootph-pre-ram;
+ };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25} {
+ bootph-pre-ram;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
+ bootph-pre-ram;
+};
+
+&crypto {
+ bootph-pre-ram;
+};
+
+&eqos {
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+ðphy0 {
+ reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <15000>;
+ reset-deassert-us = <10>;
+};
+
+&fec {
+ phy-reset-gpios = <&gpio4 18 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <15>;
+ phy-reset-post-delay = <100>;
+};
+
+&flexspi {
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_400M>;
+};
+
+&gpio1 {
+ bootph-pre-ram;
+};
+
+&gpio2 {
+ bootph-pre-ram;
+};
+
+&gpio3 {
+ bootph-pre-ram;
+};
+
+&gpio4 {
+ bootph-pre-ram;
+};
+
+&gpio5 {
+ bootph-pre-ram;
+};
+
+&i2c1 {
+ bootph-pre-ram;
+};
+
+&i2c2 {
+ bootph-pre-ram;
+};
+
+&i2c3 {
+ bootph-pre-ram;
+};
+
+&pca6416 {
+ compatible = "ti,tca6416";
+ label = "exp4";
+};
+
+&pca6416_1 {
+ compatible = "ti,tca6416";
+ label = "exp4";
+};
+
+&pca6416_3 {
+ compatible = "ti,tca6416";
+ label = "exp2";
+};
+
+&pinctrl_i2c1 {
+ bootph-pre-ram;
+};
+
+&pinctrl_pmic {
+ bootph-pre-ram;
+};
+
+&pinctrl_reg_usdhc2_vmmc {
+ bootph-pre-ram;
+};
+
+&pinctrl_uart2 {
+ bootph-pre-ram;
+};
+
+&pinctrl_usdhc2_gpio {
+ bootph-pre-ram;
+};
+
+&pinctrl_usdhc2 {
+ bootph-pre-ram;
+};
+
+&pinctrl_usdhc3 {
+ bootph-pre-ram;
+};
+
+&pinctrl_wdog {
+ bootph-pre-ram;
+};
+
+®_usdhc2_vmmc {
+ bootph-pre-ram;
+ u-boot,off-on-delay-us = <2>;
+};
+
+&sec_jr0 {
+ bootph-pre-ram;
+};
+
+&sec_jr1 {
+ bootph-pre-ram;
+};
+
+&sec_jr2 {
+ bootph-pre-ram;
+};
+
+&tpm {
+ compatible = "tcg,tpm_tis-spi";
+};
+
+&uart2 {
+ bootph-pre-ram;
+};
+
+&usdhc1 {
+ bootph-pre-ram;
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC1>;
+ assigned-clock-rates = <4>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_400M>;
+};
+
+&usdhc2 {
+ bootph-pre-ram;
+ sd-uhs-sdr104;
+ sd-uhs-ddr50;
+ assigned-clocks = <&clk IMX8MP_CLK_USDHC2>;
+ assigned-clock-rates = <4>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_400M>;
+};
+
+&usdhc3 {
+ bootph-pre-ram;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ assigned-clocks = &
Re: [PATCH 15/19] ARM: dts: renesas: Synchronize RZ R8A774A1 RZ/G2M DTs with Linux 6.5.3
On Sun, Sep 17, 2023 at 9:18 AM Marek Vasut
wrote:
>
> Synchronize RZ R8A774A1 RZ/G2M DTs with Linux 6.5.3,
Thanks!
> commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
>
> Signed-off-by: Marek Vasut
Reviewed-by: Adam Ford
> ---
> arch/arm/dts/beacon-renesom-baseboard.dtsi | 45 ++
> arch/arm/dts/beacon-renesom-som.dtsi | 2 +-
> arch/arm/dts/hihope-common.dtsi| 21 --
> arch/arm/dts/r8a774a1-beacon-rzg2m-kit.dts | 21 --
> arch/arm/dts/r8a774a1-u-boot.dtsi | 1 -
> arch/arm/dts/r8a774a1.dtsi | 14 ---
> 6 files changed, 57 insertions(+), 47 deletions(-)
>
> diff --git a/arch/arm/dts/beacon-renesom-baseboard.dtsi
> b/arch/arm/dts/beacon-renesom-baseboard.dtsi
> index 8166e3c1ff4..2e9927b9773 100644
> --- a/arch/arm/dts/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm/dts/beacon-renesom-baseboard.dtsi
> @@ -367,7 +367,7 @@
>
> assigned-clocks = <&versaclock6_bb 1>, <&versaclock6_bb 2>,
> <&versaclock6_bb 3>, <&versaclock6_bb 4>;
> - assigned-clock-rates = <2400>, <2400>, <2400>,
> + assigned-clock-rates = <2400>, <2400>, <24576000>,
><24576000>;
>
> OUT1 {
> @@ -437,20 +437,6 @@
> };
> };
>
> - /* 0 - lcd_reset */
> - /* 1 - lcd_pwr */
> - /* 2 - lcd_select */
> - /* 3 - backlight-enable */
> - /* 4 - Touch_shdwn */
> - /* 5 - LCD_H_pol */
> - /* 6 - lcd_V_pol */
> - gpio_exp1: gpio@20 {
> - compatible = "onnn,pca9654";
> - reg = <0x20>;
> - gpio-controller;
> - #gpio-cells = <2>;
> - };
> -
> touchscreen@26 {
> compatible = "ilitek,ili2117";
> reg = <0x26>;
> @@ -482,6 +468,16 @@
> };
> };
> };
> +
> + gpio_exp1: gpio@70 {
> + compatible = "nxp,pca9538";
> + reg = <0x70>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-line-names = "lcd_reset", "lcd_pwr", "lcd_select",
> + "backlight-enable", "Touch_shdwn",
> + "LCD_H_pol", "lcd_V_pol";
> + };
> };
>
> &lvds0 {
> @@ -638,6 +634,25 @@
> #clock-cells = <1>;
> clock-frequency = <11289600>;
>
> + /* Reference versaclock instead of audio_clk_a */
> + clocks = <&cpg CPG_MOD 1005>,
> +<&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
> +<&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
> +<&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
> +<&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
> +<&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
> +<&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
> +<&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
> +<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
> +<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
> +<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
> +<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
> +<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
> +<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
> +<&versaclock6_bb 4>, <&audio_clk_b>,
> +<&audio_clk_c>,
> +<&cpg CPG_CORE CPG_AUDIO_CLK_I>;
> +
> status = "okay";
>
> ports {
> diff --git a/arch/arm/dts/beacon-renesom-som.dtsi
> b/arch/arm/dts/beacon-renesom-som.dtsi
> index d3fc8ffd5b4..68b04e56ae5 100644
> --- a/arch/arm/dts/beacon-renesom-som.dtsi
> +++ b/arch/arm/dts/beacon-renesom-som.dtsi
> @@ -59,7 +59,7 @@
> status = "okay";
>
> phy0: ethernet-phy@0 {
> - compatible = "ethernet-phy-id004d.d074",
> + compatible = "ethernet-phy-id0022.1640",
> "ethernet-phy-ieee802.3-c22";
>
Re: Unable to implement board fdt-fixup for imx8m CPU
On Mon, Apr 24, 2023 at 4:57 PM Hugo Villeneuve wrote: > > On Mon, 24 Apr 2023 15:01:35 -0600 > Simon Glass wrote: > > > Hi Hugo, > > > > On Mon, 24 Apr 2023 at 14:53, Hugo Villeneuve wrote: > > > > > > Hi, > > > according to this document: > > > > > > doc/develop/driver-model/fdt-fixup.rst > > > > > > it is suggested that boards implement the board_fix_fdt() function to > > > tweak the device tree. I am trying to do just that, but unfortunately I > > > cannot because the following source file already has an implementation of > > > board_fix_fdt(): > > > > > > arch/arm/mach-imx/imx8m/soc.c > > > > > > For all boards using a imx8m CPU, how can we implement board_fix_fdt()? > > > > If you enable CONFIG_EVENT you can use EVT_FT_FIXUP to add as many > > fixup functions as you need. > > > > Migration to use that mechanism everywhere hasn't really started, but > > I think it would be useful. > > Hi Simon, > to be more precise, I need to modify the FDT used by U-Boot to tweak some > ethernet PHY properties before initializing the ethernet controller. I do > _not_ need to fix the FDT before booting in the OS. Can you modify the -u-boot.dtsi file? You can add additional device tree stuff to that. I think a few boards do this already specifically for the Ethernet stuff. adam > > With that in mind, do you still think using CONFIG_EVENT is the way to go? I > am not sure from my reading of the source code because it seems that fixup > events are called just before booting into the OS. > > Thank you, > Hugo.
Re: imx8mm/imx8mn hang on usb stop / ehci_shutdown
On Thu, Apr 27, 2023 at 12:14 PM Tim Harvey wrote:
>
> On Wed, Mar 15, 2023 at 3:01 PM Tim Harvey wrote:
> >
> > Greetings,
> >
> > I'm seeing a hang on imx8mm-venice and imx8mn-venice boards which have
> > a USB host controller in host mode when ehci_shutdown() is called
> > (which is called for 'usb stop' as well as when booting a kernel once
> > 'usb start' has been issued).
> >
> > This appears to be caused by the ehci_shutdown() function,
> > specifically the write to the or_portsc register to set EHCI_PS_SUSP:
> > for (i = 0; i < max_ports; i++) {
> > reg = ehci_readl(&ctrl->hcor->or_portsc[i]);
> > reg |= EHCI_PS_SUSP;
> > ehci_writel(&ctrl->hcor->or_portsc[i], reg);
> > }
> >
> > Does anyone else out there with an imx8mm/imx8mn board with usbotg1 or
> > usbotg2 configured with dr_mode="host" see this as well?
> >
> > I'm not clear where the equivalent code would be in the Linux kernel
> > to compare with. I do know that commenting out the ehcI_write above
> > keeps ehci_shutdown from hanging but does cause the handshake to fail
> > on the next cmd that disables CMD_RUN and thus prints "EHCI failed to
> > shut down host controller.".
> >
> > Any ideas?
> >
> > Best Regards,
> >
> > Tim
>
> I haven't heard any response here so I did some more digging. This
> hang should be affecting all imx8mm/imx8mn devices that have USB host
> controllers configured for host mode (dr_mode = "host") and would
> appear for anyone that ever does a 'usb stop' (or does a 'usb start'
> followed by a kernel boot for example of loading kernel from USB) in
> U-Boot.
>
> The issue is caused by the pgc_otg{1,2} and/or pgc_hsiomix power
> domains getting disabled for the 'usb_hub' device (which is present
> for the USB host even if you have no hub) prior to ehci_shutdown being
> called.
>
> The following patch resolves this but I'm thinking there should be a
> better way to control this from ehci-mx6.c?
There was some re-organization of the power domains in Linux in the
device tree [1]. Do you know if those propagated to U-Boot?
adam
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm.dtsi?h=v6.3&id=4585c79ff477f9517b7f384a4fce351417e8fa36
>
> diff --git a/common/usb_hub.c b/common/usb_hub.c
> index 85c0822d8b7b..03237deaa0be 100644
> --- a/common/usb_hub.c
> +++ b/common/usb_hub.c
> @@ -948,7 +948,7 @@ U_BOOT_DRIVER(usb_generic_hub) = {
> .name = "usb_hub",
> .id = UCLASS_USB_HUB,
> .of_match = usb_hub_ids,
> - .flags = DM_FLAG_ALLOC_PRIV_DMA,
> + .flags = DM_FLAG_ALLOC_PRIV_DMA | DM_FLAG_LEAVE_PD_ON,
> };
>
>
> Best Regards,
>
> Tim
Re: imx8mm/imx8mn hang on usb stop / ehci_shutdown
On Thu, Apr 27, 2023 at 12:52 PM Tim Harvey wrote: > > On Thu, Apr 27, 2023 at 10:49 AM Fabio Estevam wrote: > > > > Hi Adam, > > > > On Thu, Apr 27, 2023 at 2:42 PM Adam Ford wrote: > > > > > There was some re-organization of the power domains in Linux in the > > > device tree [1]. Do you know if those propagated to U-Boot? > > > > Excellent, I just synced the kernel imx8mm.dtsi with U-Boot and it > > does fix the "ums 0 mmc 1" issue I just described. > > > > I will submit the dtsi sync patch. Thanks! > > Fabio, > > The original issue I was trying to solve should not be visible on > imx8mm-evk unless you changed its usbotg1 to dr_mode = "host" in which > case you should see a hang with a simple 'usb start && usb stop'. If you leave it without the "host" but connect a device to the port with a host adapter, do you get the same behavior? adam > > Best Regards, > > Tim
Re: imx8mm/imx8mn hang on usb stop / ehci_shutdown
On Thu, Apr 27, 2023 at 12:49 PM Fabio Estevam wrote: > > Hi Adam, > > On Thu, Apr 27, 2023 at 2:42 PM Adam Ford wrote: > > > There was some re-organization of the power domains in Linux in the > > device tree [1]. Do you know if those propagated to U-Boot? > > Excellent, I just synced the kernel imx8mm.dtsi with U-Boot and it > does fix the "ums 0 mmc 1" issue I just described. > > I will submit the dtsi sync patch. Thanks! Any chance you can update the imx8mn.dtsi as well when you do the patch? Nano has the same USB controller, it's likely to have the same issue. adam
Re: [PATCH 2/3] arm: dts: imx8mn: Sync with Linux 6.3
On Thu, Apr 27, 2023 at 1:08 PM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> Sync imx8mn.dtsi with Linux 6.3.
>
> Signed-off-by: Fabio Estevam
Reviewed-by: Adam Ford
> ---
> arch/arm/dts/imx8mn.dtsi | 46 ++--
> 1 file changed, 35 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mn.dtsi b/arch/arm/dts/imx8mn.dtsi
> index cb2836bfbd95..9e0ddd6b7a32 100644
> --- a/arch/arm/dts/imx8mn.dtsi
> +++ b/arch/arm/dts/imx8mn.dtsi
> @@ -139,6 +139,7 @@
> A53_L2: l2-cache0 {
> compatible = "cache";
> cache-level = <2>;
> + cache-unified;
> cache-size = <0x8>;
> cache-line-size = <64>;
> cache-sets = <512>;
> @@ -295,6 +296,7 @@
> sai2: sai@3002 {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x3002 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clk IMX8MN_CLK_SAI2_IPG>,
> <&clk IMX8MN_CLK_DUMMY>,
> @@ -309,6 +311,7 @@
> sai3: sai@3003 {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x3003 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clk IMX8MN_CLK_SAI3_IPG>,
> <&clk IMX8MN_CLK_DUMMY>,
> @@ -323,6 +326,7 @@
> sai5: sai@3005 {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x3005 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clk IMX8MN_CLK_SAI5_IPG>,
> <&clk IMX8MN_CLK_DUMMY>,
> @@ -339,6 +343,7 @@
> sai6: sai@3006 {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x3006 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clk IMX8MN_CLK_SAI6_IPG>,
> <&clk IMX8MN_CLK_DUMMY>,
> @@ -396,6 +401,7 @@
> sai7: sai@300b {
> compatible = "fsl,imx8mn-sai",
> "fsl,imx8mq-sai";
> reg = <0x300b 0x1>;
> + #sound-dai-cells = <0>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clk IMX8MN_CLK_SAI7_IPG>,
> <&clk IMX8MN_CLK_DUMMY>,
> @@ -497,6 +503,8 @@
> compatible = "fsl,imx8mn-tmu",
> "fsl,imx8mm-tmu";
> reg = <0x3026 0x1>;
> clocks = <&clk IMX8MN_CLK_TMU_ROOT>;
> + nvmem-cells = <&tmu_calib>;
> + nvmem-cell-names = "calib";
> #thermal-sensor-cells = <0>;
> };
>
> @@ -551,7 +559,7 @@
> reg = <0x3033 0x1>;
> };
>
> - gpr: iomuxc-gpr@3034 {
> + gpr: syscon@3034 {
> compatible = "fsl,imx8mn-iomuxc-gpr",
> "syscon";
> reg =
Re: [PATCH 3/3] arm: dts: imx8mp: Sync with Linux 6.3
On Thu, Apr 27, 2023 at 1:09 PM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> Sync imx8mp.dtsi and imx8mp-clock.h with Linux 6.3.
>
> Signed-off-by: Fabio Estevam
Reviewed-by: Adam Ford
> ---
> arch/arm/dts/imx8mp.dtsi | 374 ---
> include/dt-bindings/clock/imx8mp-clock.h | 14 +-
> 2 files changed, 270 insertions(+), 118 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mp.dtsi b/arch/arm/dts/imx8mp.dtsi
> index bb916a0948a8..a237275ee017 100644
> --- a/arch/arm/dts/imx8mp.dtsi
> +++ b/arch/arm/dts/imx8mp.dtsi
> @@ -123,6 +123,7 @@
>
> A53_L2: l2-cache0 {
> compatible = "cache";
> + cache-unified;
> cache-level = <2>;
> cache-size = <0x8>;
> cache-line-size = <64>;
> @@ -379,6 +380,8 @@
> compatible = "fsl,imx8mp-tmu";
> reg = <0x3026 0x1>;
> clocks = <&clk IMX8MP_CLK_TSENSOR_ROOT>;
> + nvmem-cells = <&tmu_calib>;
> + nvmem-cell-names = "calib";
> #thermal-sensor-cells = <1>;
> };
>
> @@ -411,7 +414,7 @@
> reg = <0x3033 0x1>;
> };
>
> - gpr: iomuxc-gpr@3034 {
> + gpr: syscon@3034 {
> compatible = "fsl,imx8mp-iomuxc-gpr",
> "syscon";
> reg = <0x3034 0x1>;
> };
> @@ -424,27 +427,44 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - imx8mp_uid: unique-id@420 {
> + /*
> +* The register address below maps to the MX8M
> +* Fusemap Description Table entries this way.
> +* Assuming
> +* reg = ;
> +* then
> +* Fuse Address = (ADDR * 4) + 0x400
> +* Note that if SIZE is greater than 4, then
> +* each subsequent fuse is located at offset
> +* +0x10 in Fusemap Description Table (e.g.
> +* reg = <0x8 0x8> describes fuses 0x420 and
> +* 0x430).
> +*/
> + imx8mp_uid: unique-id@8 { /* 0x420-0x430 */
> reg = <0x8 0x8>;
> };
>
> - cpu_speed_grade: speed-grade@10 {
> + cpu_speed_grade: speed-grade@10 { /* 0x440 */
> reg = <0x10 4>;
> };
>
> - eth_mac1: mac-address@90 {
> + eth_mac1: mac-address@90 { /* 0x640 */
> reg = <0x90 6>;
> };
>
> - eth_mac2: mac-address@96 {
> + eth_mac2: mac-address@96 { /* 0x658 */
> reg = <0x96 6>;
> };
> +
> + tmu_calib: calib@264 { /* 0xd90-0xdc0 */
> + reg = <0x264 0x10>;
> + };
> };
>
> - anatop: anatop@3036 {
> - compatible = "fsl,imx8mp-anatop",
> "fsl,imx8mm-anatop",
> -"syscon";
> + anatop: clock-controller@3036 {
> + compatible = "fsl,imx8mp-anatop",
> "fsl,imx8mm-anatop";
> reg = <0x3036 0x1>;
> + #clock-cells = <1>;
> };
>
> snvs: snvs@3037 {
> @@ -523,6 +543,7 @@
> compatible = "fsl,imx8mp-gpc";
>
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Thu, Apr 27, 2023 at 1:08 PM Fabio Estevam wrote:
>
> From: Fabio Estevam
>
> Sync imx8mm.dtsi with Linux 6.3.
>
> The motivation for doing this sync was a bug when doing "ums 0 mmc 1"
> on imx8mm-evk. It worked well for the first time, but after doing
> a CTRL+C and launching the ums again, the command did not work.
>
> Adam Ford suggested to sync imx8mm.dtsi with the Linux dts, as there was
> a recent USB power domain reorganization there.
>
> After syncing the imx8mm.dtsi with Linux, the ums command works without
> problem after a CTRL+C.
>
> Suggested-by: Adam Ford
> Signed-off-by: Fabio Estevam
Reviewed-by: Adam Ford
> ---
> arch/arm/dts/imx8mm.dtsi | 52 +---
> 1 file changed, 38 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
> index afb90f59c83c..31f4548f85cf 100644
> --- a/arch/arm/dts/imx8mm.dtsi
> +++ b/arch/arm/dts/imx8mm.dtsi
> @@ -139,6 +139,7 @@
> A53_L2: l2-cache0 {
> compatible = "cache";
> cache-level = <2>;
> + cache-unified;
> cache-size = <0x8>;
> cache-line-size = <64>;
> cache-sets = <512>;
> @@ -276,6 +277,7 @@
> assigned-clocks = <&clk IMX8MM_CLK_USB_PHY_REF>;
> assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_100M>;
> clock-names = "main_clk";
> + power-domains = <&pgc_otg1>;
> };
>
> usbphynop2: usbphynop2 {
> @@ -285,6 +287,7 @@
> assigned-clocks = <&clk IMX8MM_CLK_USB_PHY_REF>;
> assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_100M>;
> clock-names = "main_clk";
> + power-domains = <&pgc_otg2>;
> };
>
> soc: soc@0 {
> @@ -493,6 +496,8 @@
> compatible = "fsl,imx8mm-tmu";
> reg = <0x3026 0x1>;
> clocks = <&clk IMX8MM_CLK_TMU_ROOT>;
> + nvmem-cells = <&tmu_calib>;
> + nvmem-cell-names = "calib";
> #thermal-sensor-cells = <0>;
> };
>
> @@ -547,8 +552,8 @@
> reg = <0x3033 0x1>;
> };
>
> - gpr: iomuxc-gpr@3034 {
> - compatible = "fsl,imx8mm-iomuxc-gpr",
> "fsl,imx6q-iomuxc-gpr", "syscon";
> + gpr: syscon@3034 {
> + compatible = "fsl,imx8mm-iomuxc-gpr",
> "syscon";
> reg = <0x3034 0x1>;
> };
>
> @@ -560,22 +565,40 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> - imx8mm_uid: unique-id@410 {
> + /*
> +* The register address below maps to the MX8M
> +* Fusemap Description Table entries this way.
> +* Assuming
> +* reg = ;
> +* then
> +* Fuse Address = (ADDR * 4) + 0x400
> +* Note that if SIZE is greater than 4, then
> +* each subsequent fuse is located at offset
> +* +0x10 in Fusemap Description Table (e.g.
> +* reg = <0x4 0x8> describes fuses 0x410 and
> +* 0x420).
> +*/
> + imx8mm_uid: unique-id@4 { /* 0x410-0x420 */
> reg = <0x4 0x8>;
> };
>
> - cpu_speed_grade: speed-grade@10 {
> + cpu_speed_grade: speed-grade@10 { /* 0x440 */
> reg = <0x10 4>;
> };
>
> - fec_mac_address: mac-address@90 {
> + tmu_calib: calib@3c { /* 0x4f0 */
> + reg
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Thu, Apr 27, 2023 at 5:25 PM Tim Harvey wrote:
>
> On Thu, Apr 27, 2023 at 12:49 PM Fabio Estevam wrote:
> >
> > On Thu, Apr 27, 2023 at 4:44 PM Tim Harvey wrote:
> >
> > > Fabio,
> > >
> > > Sorry for the confusion.
> > >
> > > This imx8mm dt sync patch will hang on imx8mm boards that use 'both'
> > > usbotg1 and usbotg2. You can reproduce this hang on your imx8mm-evk by
> > > enabling usbotg2 in the dt (the board has it but it is not enabled due
> > > to the gpio based usb 3.0 mux not being sorted out yet):
> > > +&usbotg2 {
> > > + dr_mode = "otg";
> > > + status = "okay";
> > > +};
> > > +
> > >
> > > u-boot=> usb start && usb tree
> > > starting USB...
> > > Bus usb@32e4: Bus usb@32e5:
> > > ^^^ imx8mm-evk hangs
> >
> > Yes, I can reproduce the hang, but it happens with or without the
> > imx8mm dt sync.
> >
>
> Fabio,
>
> I do 'not' see a hang on imx8mm-evk on 'usb start && usb tree' on
> master (my other issue was on a 'usb stop' but only with usb
> controllers in host mode).
>
> > This hang is a separate issue, not dt related, as far as I understand.
> >
> > The imx8mm dts sync does solve the issue of running 'ums' after CTRL+C.
>
> I don't agree. The hang 'is' related because all my imx8mm-venice-*
> boards which use 'both' USB controllers hang with this patch on a 'usb
> start' and don't hang without it. While a basic 'review' of the patch
> looks good but actual product testing shows issues. As a maintainer
> for ARM FREESCALE IMX you must have another imx8mm board which uses
> both usbotg devices to test against and verify you see what I see?
>
> Until we know what other fix is needed to go along with this:
> Nacked-by: Tim Harvey
What is the harm is sync'ing the device tree with the kernel? I seemed
like you found a solution with the regulator patch. Did I
misunderstand that?
adam
>
> I've verified that it's the changes from Linux commit 4585c79ff477f
> ("arm64: dts: imx8mm: correct usb power domains") that causes the
> hang, but I don't know why yet.
>
> Why are we seeing different behavior on the imx8mm-evk? Are we on
> different branches? My testing today is on caf0a88d9f31
>
> Best Regards,
>
> Tim
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Fri, Apr 28, 2023 at 10:27 AM Tim Harvey wrote:
>
> On Fri, Apr 28, 2023 at 4:57 AM Adam Ford wrote:
> >
> > On Thu, Apr 27, 2023 at 5:25 PM Tim Harvey wrote:
> > >
> > > On Thu, Apr 27, 2023 at 12:49 PM Fabio Estevam wrote:
> > > >
> > > > On Thu, Apr 27, 2023 at 4:44 PM Tim Harvey
> > > > wrote:
> > > >
> > > > > Fabio,
> > > > >
> > > > > Sorry for the confusion.
> > > > >
> > > > > This imx8mm dt sync patch will hang on imx8mm boards that use 'both'
> > > > > usbotg1 and usbotg2. You can reproduce this hang on your imx8mm-evk by
> > > > > enabling usbotg2 in the dt (the board has it but it is not enabled due
> > > > > to the gpio based usb 3.0 mux not being sorted out yet):
> > > > > +&usbotg2 {
> > > > > + dr_mode = "otg";
> > > > > + status = "okay";
> > > > > +};
> > > > > +
> > > > >
> > > > > u-boot=> usb start && usb tree
> > > > > starting USB...
> > > > > Bus usb@32e4: Bus usb@32e5:
> > > > > ^^^ imx8mm-evk hangs
> > > >
> > > > Yes, I can reproduce the hang, but it happens with or without the
> > > > imx8mm dt sync.
> > > >
> > >
> > > Fabio,
> > >
> > > I do 'not' see a hang on imx8mm-evk on 'usb start && usb tree' on
> > > master (my other issue was on a 'usb stop' but only with usb
> > > controllers in host mode).
> > >
> > > > This hang is a separate issue, not dt related, as far as I understand.
> > > >
> > > > The imx8mm dts sync does solve the issue of running 'ums' after CTRL+C.
> > >
> > > I don't agree. The hang 'is' related because all my imx8mm-venice-*
> > > boards which use 'both' USB controllers hang with this patch on a 'usb
> > > start' and don't hang without it. While a basic 'review' of the patch
> > > looks good but actual product testing shows issues. As a maintainer
> > > for ARM FREESCALE IMX you must have another imx8mm board which uses
> > > both usbotg devices to test against and verify you see what I see?
> > >
> > > Until we know what other fix is needed to go along with this:
> > > Nacked-by: Tim Harvey
> >
> > What is the harm is sync'ing the device tree with the kernel? I seemed
> > like you found a solution with the regulator patch. Did I
> > misunderstand that?
> >
> > adam
>
> Adam,
>
> No, the regulator patch did 'not' resolve the issue created by syncing
> the imx8mm dt (I caused confusion by responding to the wrong thread -
> the regulator patch resolved a different issue).
Ok.
>
> Could you please verify my results on a board that uses both usbotg1
> and usbotg2? What I see is on master + this imx8mm dt sync
> (specifically the changes from Linux commit 4585c79ff477f ("arm64:
> dts: imx8mm: correct usb power domains")) the board hangs on usb start
> when bringing up usbotg2.
I can, but I am about to board a plane to go visit some sick family,
but I'll try to do it early next week.
I have a board with both USB controllers enabled. My OTG2 is
host-only, so I think it's similar to your setup.
Should I apply the regulator patch when I test?
adam
>
> Best Regards,
>
> Tim
Re: [PATCH 1/3] arm: dts: imx8mm: Sync with Linux 6.3
On Fri, Apr 28, 2023 at 11:26 AM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Fri, Apr 28, 2023 at 12:48 PM Tim Harvey wrote:
>
> > Yes I think that is similar enough to test. In my experience simply
> > enabling otg2 via dt on imx8mm-evk shows the issue I see here but
> > Fabio says he sees a hang on 'usb start' even before this dt sync and
> > I don't know why my results on an imx8mm-evk differ.
>
> I started from scratch today and now our results match.
>
> Applied the following change against U-Boot master:
>
> diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi
> index 7d6317d95b13..898639e33d5e 100644
> --- a/arch/arm/dts/imx8mm-evk.dtsi
> +++ b/arch/arm/dts/imx8mm-evk.dtsi
> @@ -417,6 +417,10 @@
> };
> };
>
> +&usbotg2 {
> + status = "okay";
> +};
> +
> &usdhc2 {
> assigned-clocks = <&clk IMX8MM_CLK_USDHC2>;
> assigned-clock-rates = <2>;
> diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
> index ab9ad41b4548..70c7a21f2d9f 100644
> --- a/configs/imx8mm_evk_defconfig
> +++ b/configs/imx8mm_evk_defconfig
> @@ -119,3 +119,4 @@ CONFIG_CI_UDC=y
> CONFIG_SDP_LOADADDR=0x4040
> CONFIG_USB_GADGET_DOWNLOAD=y
> CONFIG_IMX_WATCHDOG=y
> +CONFIG_CMD_USB=y
> --
> 2.34.1
>
> Running "usb start" does not hang.
>
> Running "ums 0 mmc 1", CTRL+C and then "ums 0 mmc 1" does not work (SD
> card is not mounted on PC on the second time).
>
> After applying the imx8mm.dtsi sync with kernel 6.3:
>
> Running "ums 0 mmc 1", CTRL+C and then "ums 0 mmc 1" works fine.
>
> "usb start" hangs.
>
> So, yes, I agree we cannot do the imx8mm.dtsi sync with 6.3 right now
> as we need to fix the USB hang first.
>
> If anyone has any ideas as to why syncing the commit below:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/freescale/imx8mm.dtsi?h=v6.3&id=4585c79ff477f9517b7f384a4fce351417e8fa36
>
> causes issues in U-Boot, please let us know.
I am not in a place to test this as I am traveling, but I thought I'd
throw out an idea. The power-domain looks like it moved to the
usbphynop2 driver which has the compatible name of "usb-nop-xceiv"
Is there a a driver for this? Does it get enabled?
If not, maybe we could update the imx8mm-u-u-boot.dtsi to restore the
power-domains to a driver that is present.
adam
>
> Thanks
Re: [PATCH 3/3] arm: dts: imx8mp: Sync with Linux 6.3
On Fri, May 19, 2023 at 5:19 PM Tim Harvey wrote:
>
> On Wed, May 3, 2023 at 9:11 AM Tim Harvey wrote:
> >
> > On Thu, Apr 27, 2023 at 11:09 AM Fabio Estevam wrote:
> > >
> > > From: Fabio Estevam
> > >
> > > Sync imx8mp.dtsi and imx8mp-clock.h with Linux 6.3.
> > >
> > > Signed-off-by: Fabio Estevam
> > > ---
> > > arch/arm/dts/imx8mp.dtsi | 374 ---
> > > include/dt-bindings/clock/imx8mp-clock.h | 14 +-
> > > 2 files changed, 270 insertions(+), 118 deletions(-)
> > >
> > > diff --git a/arch/arm/dts/imx8mp.dtsi b/arch/arm/dts/imx8mp.dtsi
> > > index bb916a0948a8..a237275ee017 100644
> > > --- a/arch/arm/dts/imx8mp.dtsi
> > > +++ b/arch/arm/dts/imx8mp.dtsi
> > > @@ -123,6 +123,7 @@
> > >
> > > A53_L2: l2-cache0 {
> > > compatible = "cache";
> > > + cache-unified;
> > > cache-level = <2>;
> > > cache-size = <0x8>;
> > > cache-line-size = <64>;
> > > @@ -379,6 +380,8 @@
> > > compatible = "fsl,imx8mp-tmu";
> > > reg = <0x3026 0x1>;
> > > clocks = <&clk IMX8MP_CLK_TSENSOR_ROOT>;
> > > + nvmem-cells = <&tmu_calib>;
> > > + nvmem-cell-names = "calib";
> > > #thermal-sensor-cells = <1>;
> > > };
> > >
> > > @@ -411,7 +414,7 @@
> > > reg = <0x3033 0x1>;
> > > };
> > >
> > > - gpr: iomuxc-gpr@3034 {
> > > + gpr: syscon@3034 {
> > > compatible = "fsl,imx8mp-iomuxc-gpr",
> > > "syscon";
> > > reg = <0x3034 0x1>;
> > > };
> > > @@ -424,27 +427,44 @@
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > >
> > > - imx8mp_uid: unique-id@420 {
> > > + /*
> > > +* The register address below maps to the
> > > MX8M
> > > +* Fusemap Description Table entries this
> > > way.
> > > +* Assuming
> > > +* reg = ;
> > > +* then
> > > +* Fuse Address = (ADDR * 4) + 0x400
> > > +* Note that if SIZE is greater than 4,
> > > then
> > > +* each subsequent fuse is located at
> > > offset
> > > +* +0x10 in Fusemap Description Table
> > > (e.g.
> > > +* reg = <0x8 0x8> describes fuses 0x420
> > > and
> > > +* 0x430).
> > > +*/
> > > + imx8mp_uid: unique-id@8 { /* 0x420-0x430
> > > */
> > > reg = <0x8 0x8>;
> > > };
> > >
> > > - cpu_speed_grade: speed-grade@10 {
> > > + cpu_speed_grade: speed-grade@10 { /*
> > > 0x440 */
> > > reg = <0x10 4>;
> > > };
> > >
> > > - eth_mac1: mac-address@90 {
> > > + eth_mac1: mac-address@90 { /* 0x640 */
> > > reg = <0x90 6>;
> > > };
> > >
> > > - eth_mac2: mac-address@96 {
> > > + eth_mac2: mac-address@96 { /* 0x658 */
> > > reg = <0x96 6>;
> > > };
> > > +
> > > + tmu_calib: calib@264 { /* 0xd90-0xdc0 */
> > > + reg = <0x264 0x10>;
> > > + };
> > > };
> > >
> > > - anatop: anatop@3036 {
> > > - compatible = "fsl,imx8mp-anatop",
> > > "fsl,imx8mm-anatop",
> > > -"syscon";
> > > + anatop: clock-controller@3036 {
> > > + compatible = "fsl,imx8mp-anatop",
> > > "fsl,imx8mm-anatop";
> > > reg = <0x3036 0x1>;
> > > + #clock-cells = <1>;
> > > };
> > >
> > > snvs: snvs@3037 {
> > > @@ -523,6 +543,7 @@
> > > compatible = "fsl,imx8mp-gpc";
> > > reg
Re: [PATCH 3/3] arm: dts: imx8mp: Sync with Linux 6.3
On Fri, May 19, 2023 at 5:34 PM Tim Harvey wrote:
>
> On Fri, May 19, 2023 at 3:31 PM Tim Harvey wrote:
> >
> > On Fri, May 19, 2023 at 3:27 PM Adam Ford wrote:
> > >
> > > On Fri, May 19, 2023 at 5:19 PM Tim Harvey wrote:
> > > >
> > > > On Wed, May 3, 2023 at 9:11 AM Tim Harvey wrote:
> > > > >
> > > > > On Thu, Apr 27, 2023 at 11:09 AM Fabio Estevam
> > > > > wrote:
> > > > > >
> > > > > > From: Fabio Estevam
> > > > > >
> > > > > > Sync imx8mp.dtsi and imx8mp-clock.h with Linux 6.3.
> > > > > >
> > > > > > Signed-off-by: Fabio Estevam
> > > > > > ---
> > > > > > arch/arm/dts/imx8mp.dtsi | 374
> > > > > > ---
> > > > > > include/dt-bindings/clock/imx8mp-clock.h | 14 +-
> > > > > > 2 files changed, 270 insertions(+), 118 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm/dts/imx8mp.dtsi b/arch/arm/dts/imx8mp.dtsi
> > > > > > index bb916a0948a8..a237275ee017 100644
> > > > > > --- a/arch/arm/dts/imx8mp.dtsi
> > > > > > +++ b/arch/arm/dts/imx8mp.dtsi
> > > > > > @@ -123,6 +123,7 @@
> > > > > >
> > > > > > A53_L2: l2-cache0 {
> > > > > > compatible = "cache";
> > > > > > + cache-unified;
> > > > > > cache-level = <2>;
> > > > > > cache-size = <0x8>;
> > > > > > cache-line-size = <64>;
> > > > > > @@ -379,6 +380,8 @@
> > > > > > compatible = "fsl,imx8mp-tmu";
> > > > > > reg = <0x3026 0x1>;
> > > > > > clocks = <&clk
> > > > > > IMX8MP_CLK_TSENSOR_ROOT>;
> > > > > > + nvmem-cells = <&tmu_calib>;
> > > > > > + nvmem-cell-names = "calib";
> > > > > > #thermal-sensor-cells = <1>;
> > > > > > };
> > > > > >
> > > > > > @@ -411,7 +414,7 @@
> > > > > > reg = <0x3033 0x1>;
> > > > > > };
> > > > > >
> > > > > > - gpr: iomuxc-gpr@3034 {
> > > > > > + gpr: syscon@3034 {
> > > > > > compatible =
> > > > > > "fsl,imx8mp-iomuxc-gpr", "syscon";
> > > > > > reg = <0x3034 0x1>;
> > > > > > };
> > > > > > @@ -424,27 +427,44 @@
> > > > > > #address-cells = <1>;
> > > > > > #size-cells = <1>;
> > > > > >
> > > > > > - imx8mp_uid: unique-id@420 {
> > > > > > + /*
> > > > > > +* The register address below maps
> > > > > > to the MX8M
> > > > > > +* Fusemap Description Table
> > > > > > entries this way.
> > > > > > +* Assuming
> > > > > > +* reg = ;
> > > > > > +* then
> > > > > > +* Fuse Address = (ADDR * 4) +
> > > > > > 0x400
> > > > > > +* Note that if SIZE is greater
> > > > > > than 4, then
> > > > > > +* each subsequent fuse is located
> > > > > > at offset
> > > > > > +* +0x10 in Fusemap Description
> > > > > > Table (e.g.
> > > > > > +* reg = <0x8 0x8>
Re: [PATCH 3/3] arm: dts: imx8mp: Sync with Linux 6.3
On Mon, May 22, 2023 at 3:49 PM Fabio Estevam wrote: > > Hi Tim, > > On Fri, May 19, 2023 at 8:00 PM Tim Harvey wrote: > > > Fabio, > > > > There's more to be done here also. With this patch, and with the > > spba-bus added to u-boot.dtsi, if you try to enable usb (usb start) > > you get: > > starting USB... > > Bus usb@3820: > > Enable clock-controller@3038 failed > > probe failed, error -2 > > No working controllers found > > > > So until we get this figured out please don't apply this. > > I don't have any imx8mp-based board here to debug this problem, so it > would be nice > if someone else could investigate this. I can do some testing on the imx8mp-beacon board, but it will likely be a few days before I can get to it. adam > > Thanks
Re: [PATCH] Revert "spl: Drop bd_info in the data section"
On Fri, Apr 9, 2021 at 2:20 PM Alex G. wrote: > > Hi Simon > > On 4/8/21 6:55 PM, Simon Glass wrote: > > Hi Alexandru, > > > > On Fri, 9 Apr 2021 at 04:56, Alexandru Gagniuc wrote: > >> > >> This reverts commit 38d6b7ebdaee3e0e8426ef1b9df88bdce8ae2e75. > >> > >> struct global_data contains a pointer to the bd_info structure. This > >> pointer was populated spl_set_bd() to a pre-allocated bd_info in the > >> ".data" section. The referenced commit replaced this mechanism to one > >> that uses malloc(). That new mechanism is only used if SPL_ALLOC_BD=y. > >> which very few boards do. > >> > >> The result is that (struct global_data)->bd is NULL in SPL on most > >> platforms. This breaks falcon mode, since arch_fixup_fdt() tries to > >> access (struct global_data)->bd and set the "/memory" node in the > >> devicetree. The result is that the "/memory" node contains garbage > >> values, causing linux to panic() as it sets up the page table. > >> > >> Instead of trying to fix the mess, potentially causing other issues, > >> revert to the code that worked, while this change is reworked. > > > > The goal here is to drop a feature that few boards use and reduce > > memory usage in SPL. It has been in place for two releases now. > > > > If Falcon mode needs it, perhaps you could add an 'imply' in the > > Kconfig for that feature? Is there one? Or perhaps > > CONFIG_ARCH_FIXUP_FDT_MEMORY ? > > > > One option would be to return an error in arch_fixup_fdt(). In > > general, fixups make things tricky because there is no way to > > determine when they are used but at least this one has a CONFIG. > > > > The argument that this has been in place for two releases is incorrect. > Commit 38d6b7ebdaee3e0e8426ef1b9df88bdce8ae2e75 was only introduced with > the v2021.04 release. It definitely was not in 2021.01. It's only in the > last release, which is four days old t the time of this writing. > > Although I was able to find one example, the reality is that we don't > know the full extent of the breakage. The prudent thing at this point is > to revert. > > The knowledge of how to init the platform is in the devicetree and code. > Why should kconfig also be involved in storing this knowledge? By this > model, as the number of boards increases without bounds, every "if" > predicate tends to be Kconfig driven. That is not maintainable, and why > I think the original change --and the proposed fixes-- are broken by design. > > Furthermore, I'm happy to discuss what to do about Falcon mode, and if > we should kill it entirely (I have an alternative proposal). But we > shouldn't have that discussion in a manner holding my platform hostage. > To be fair to you, I don't think reverting a 64-byte savings in .data > will hold your platform hostage either. That original patch broke a bunch of OMAP boards, but enabling SPL_ALLOC_BD was the solution to fix the issue. Can you try enabling SPL_ALLOC_BD and see if that fixes it? Maybe we can make falcon mode imply it. adam > > Alex >
Re: [PATCH] Revert "spl: Drop bd_info in the data section"
On Fri, Apr 16, 2021 at 3:41 PM Tim Harvey wrote: > > On Mon, Apr 12, 2021 at 11:44 AM Simon Glass wrote: > > > > Hi Tom, > > > > On Tue, 13 Apr 2021 at 06:38, Tom Rini wrote: > > > > > > On Tue, Apr 13, 2021 at 06:26:08AM +1200, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Tue, 13 Apr 2021 at 06:18, Tom Rini wrote: > > > > > > > > > > On Tue, Apr 13, 2021 at 05:49:19AM +1200, Simon Glass wrote: > > > [snip] > > > > > > As to a weak function, what would the default behaviour be? If we > > > > > > can > > > > > > define that, then it would be better IMO. > > > > > > > > > > > > When we try to refactor things, weak functions and undefined (or > > > > > > arch-specific behaviour) can really make things tough. > > > > > > > > > > Well, what was the problem you were trying to solve here? I assumed > > > > > there was a case where things actively broke, with the previous > > > > > design, > > > > > and it's not just the 64byte savings in some cases. But is it? > > > > > > > > Yes the region of memory is not writable, so must be allocated at > > > > runtime. > > > > > > Where, on x86? Some ARM cases? That's one of the other things to sort > > > out here. > > > > Yes, on coral and likely newer things to come...For ARM I don't know > > of any such problems. > > > > I'm not sure I understand if there is agreement on a solution to this > patch breaking several or many boards? I count 58 IMX6 boards using > SPL and none of them currently define CONFIG_SPL_ALLOC_BD=y. It sounds > like Adam said OMAP boards were broken as well and I'm not clear if > those boards are fixed yet either. I have already submitted a patch for the OMAP boards that I maintain to address the issue. I wonder if it would make sense to make these architectures select CONFIG_SPL_ALLOC_BD automatically instead of having a bunch of individual boards enable it. I have not checked any of the IMX8M or IMX6 boards that I maintain, but I am watching this thread. I can test the CONFIG_SPL_ALLOC_BD on my boards if people think there is value. adam > > Best regards, > > Tim
Re: [PATCH V2 24/24] ARM: imx8m: verdin-imx8mm: Enable USB Host support
On Tue, Apr 27, 2021 at 10:50 AM Tim Harvey wrote:
>
> On Mon, Apr 26, 2021, 5:35 PM Marek Vasut wrote:
> >
> > On 4/27/21 2:01 AM, Tim Harvey wrote:
> > [...]
> > >>> Why would the power domain get probed/enabled for the usbotg2
> > >>> bus but not the usbotg1 bus? Here is some debugging:
> > >>> u-boot=> usb start
> > >>> starting USB...
> > >>> Bus usb@32e4: ehci_usb_phy_mode usb@32e4
> > >>> usb@32e4 probe ret=-22
> > >>> probe failed, error -22
> > >>> ^^^ probe fails here because ehci_usb_phy_mode returns EINVAL for
> > >>> dr_mode=otg but if we try to read the phy_status reg we will hang b/c
> > >>> power domain is not enabled yet
> > >>> Bus usb@32e5: imx8m_power_domain_probe gpc@303a
> > >>> imx8m_power_domain_probe pgc
> > >>> ^^^ why did power domain get probed on the 2nd bus and not the first?
> > >>
> > >> I don't know, can you have a look ?
> > >
> > > Marek,
> > >
> > > The reg domain does not get enabled for usbotg1 because
> > > device_of_to_plat gets called 'before' dev_power_domain_on in
> > > device_probe.
> > >
> > > The following will get imx8mm USB otg working:
> > >
> > > For OTG defer setting type until probe after clock and power have been
> > > brought up.
> > > index 06be9deaaa..2183ae4f9d 100644
> > > --- a/drivers/usb/host/ehci-mx6.c
> > > +++ b/drivers/usb/host/ehci-mx6.c
> > > @@ -523,7 +523,7 @@ static int ehci_usb_phy_mode(struct udevice *dev)
> > > plat->init_type = USB_INIT_DEVICE;
> > > else
> > > plat->init_type = USB_INIT_HOST;
> > > - } else if (is_mx7()) {
> > > + } else if (is_mx7() || is_imx8mm()) {
> > > phy_status = (void __iomem *)(addr +
> > >USBNC_PHY_STATUS_OFFSET);
> > > val = readl(phy_status);
> > > @@ -555,7 +555,10 @@ static int ehci_usb_of_to_plat(struct udevice *dev)
> > > break;
> > > case USB_DR_MODE_OTG:
> > > case USB_DR_MODE_UNKNOWN:
> > > - return ehci_usb_phy_mode(dev);
> > > + if (is_imx8mm())
> >
> > Does this mean OTG doesn't work on the 8MM then ?
>
> IMX8MM USB in general still doesn't work without your:
> usb: ehci-mx6: Limit PHY address parsing to !CONFIG_PHY
>
> With your patch, IMX8MM 'host' works but 'otg' will fail probe with
> -22 (due ehci_usb_phy_mode called from of_to_plat and it not having a
> case for imx8mm)
>
> >
> > > + plat->init_type = USB_INIT_HOST;
> > > + else
> > > + return ehci_usb_phy_mode(dev);
> > > };
> > >
> > > return 0;
> > > @@ -657,6 +660,13 @@ static int ehci_usb_probe(struct udevice *dev)
> > > mdelay(1);
> > > #endif
> > >
> > > + if (is_imx8mm() && (usb_get_dr_mode(dev_ofnode(dev)) ==
> > > USB_DR_MODE_OTG)) {
> > > + ret = ehci_usb_phy_mode(dev);
> > > + if (ret)
> > > + return ret;
> > > + priv->init_type = plat->init_type;
> > > + };
> >
> > I have to wonder, why not move the whole OTG/Host/Device detection to
> > probe then ?
>
> Yes, I think that is the right thing to do.
>
> >
> > Also, could you submit a regular patch ?
>
> Yes, I will post patches to fix IMX8MM OTG. Can you submit your 'usb:
> ehci-mx6: Limit PHY address parsing to !CONFIG_PHY' patch so I can go
> on top of that or can I just pull that into my series?
If you want me to test it on either a Mini or Nano, feel free to CC me
as well. I was out of town the last week, so I wasn't in a place to
do any work.
I am a little behind, so I might need some pointers to prerequisite
patches if they're necessary.
thanks,
adam
>
> Best regards,
>
> Tim
Re: [RFC PATCH u-boot 00/12] U-Boot LTO (Sandbox + ARM Nokia RX-51)
On Sat, Mar 6, 2021 at 10:06 PM Marek Behun wrote: > > On Sat, 6 Mar 2021 21:45:02 -0600 > Adam Ford wrote: > > > On Sat, Mar 6, 2021 at 3:49 PM Marek Behun wrote: > > > > > > On Sat, 6 Mar 2021 22:38:52 +0100 > > > Pali Rohár wrote: > > > > > > > On Saturday 06 March 2021 22:19:22 Marek Behun wrote: > > > > > On Sat, 6 Mar 2021 22:00:45 +0100 > > > > > Pali Rohár wrote: > > > > > > > > > > > On Saturday 06 March 2021 21:54:00 Marek Behun wrote: > > > > > > > On Sat, 6 Mar 2021 21:41:14 +0100 > > > > > > > Pali Rohár wrote: > > > > > > > > > > > > > > > On Saturday 06 March 2021 15:08:13 Tom Rini wrote: > > > > > > > > > Perhaps we'll default to yes on some SoCs. The omap3 thing > > > > > > > > > is a bit > > > > > > > > > odd, but we'll see what happens on real N900 hardware. > > > > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > Could you send me a link to git repo / branch and tell me from > > > > > > > > which > > > > > > > > commit should I do tests on real N900 hardware? I will test it > > > > > > > > and let > > > > > > > > you know results. > > > > > > > > > > > > > > > > Adding maemo ML to the loop as on the maemo list are more > > > > > > > > people with > > > > > > > > N900 HW and U-Boot. > > > > > > > > > > > > > > https://github.com/elkablo/u-boot branch lto > > > > > > > > > > > > Sorry, compilation is failing :-( > > > > > > > > > > > > $ git clone https://github.com/elkablo/u-boot -b lto --depth=100 > > > > > > Cloning into 'u-boot'... > > > > > > remote: Enumerating objects: 33644, done. > > > > > > remote: Counting objects: 100% (33644/33644), done. > > > > > > remote: Compressing objects: 100% (20116/20116), done. > > > > > > remote: Total 33644 (delta 15838), reused 19947 (delta 13018), > > > > > > pack-reused 0 > > > > > > Receiving objects: 100% (33644/33644), 26.28 MiB | 10.21 MiB/s, > > > > > > done. > > > > > > Resolving deltas: 100% (15838/15838), done. > > > > > > > > > > > > $ cd u-boot > > > > > > > > > > > > $ make CROSS_COMPILE=arm-linux-gnueabi- nokia_rx51_config > > > > > > HOSTCC scripts/basic/fixdep > > > > > > HOSTCC scripts/kconfig/conf.o > > > > > > YACCscripts/kconfig/zconf.tab.c > > > > > > LEX scripts/kconfig/zconf.lex.c > > > > > > HOSTCC scripts/kconfig/zconf.tab.o > > > > > > HOSTLD scripts/kconfig/conf > > > > > > # > > > > > > # configuration written to .config > > > > > > # > > > > > > > > > > > > $ make CROSS_COMPILE=arm-linux-gnueabi- u-boot.bin > > > > > > ... > > > > > > LTO u-boot > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: > > > > > > > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: > > > > > > DWARF error: offset (1258291444) greater than or equal to > > > > > > .debug_str size (676) > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: > > > > > > DWARF error: offset (1459618036) greater than or equal to > > > > > > .debug_str size (676) > > > > > > /usr/lib/gcc-cross/arm-linux-gnueabi/8/../../../../arm-linux-gnueabi/bin/ld: > > > > > > DWARF error: could not find abbrev number 48028 > > > > > > /tmp/cc8l0QSQ.ltrans3.ltrans.o: in function > > > > > > `omap3_set_aux_cr_secure': > > > > > > :(.text+0x6eb8): undefined reference to > > > > > > `do_omap3_emu_romcode_call' > > > > > > collect2: error: ld returned 1 exit status > > > > > > make: *** [Makefile:1808: u-boot] Error 1 > > > > > > > &
Re: [PATCH 10/10] arm: imx: imx8m: Add basic PSCI provider implementation
On Wed, Dec 21, 2022 at 6:47 PM Marek Vasut wrote:
>
> Implement basic PSCI provider to let OS turn CPU cores off and on,
> power off and restart the system and determine PSCI version. This
> is sufficient to remove the need for the ATF BL31 blob altogether.
>
> To make use of this functionality, active the following Kconfig options:
> # CONFIG_PSCI_RESET is not set
> CONFIG_ARMV8_MULTIENTRY=y
> CONFIG_ARMV8_SET_SMPEN=y
> CONFIG_ARMV8_SPL_EXCEPTION_VECTORS=y
> CONFIG_ARMV8_EA_EL3_FIRST=y
> CONFIG_ARMV8_PSCI=y
> CONFIG_ARMV8_PSCI_CPUS_PER_CLUSTER=4
> CONFIG_ARMV8_SECURE_BASE=0x97
I am guessing 0x97 was for the 8MP based on the previous location
of ATF. Is that true? If that's the case, can I assume that this
address would be 0x91, 0x92 and 0x96 for the imx8mq,
imx8mm and imx8mn respectively?
> CONFIG_ARM_SMCCC=y
> CONFIG_SYS_HAS_ARMV8_SECURE_BASE=y
>
> Signed-off-by: Marek Vasut
> ---
> Cc: "Ariel D'Alessandro"
> Cc: "NXP i.MX U-Boot Team"
> Cc: "Ying-Chun Liu (PaulLiu)"
> Cc: Adam Ford
> Cc: Andrejs Cainikovs
> Cc: Fabio Estevam
> Cc: Manoj Sai
> Cc: Marcel Ziswiler
> Cc: Michael Trimarchi
> Cc: Peng Fan
> Cc: Ricardo Salveti
> Cc: Simon Glass
> Cc: Stefano Babic
> Cc: Tim Harvey
> Cc: Ye Li
> ---
> arch/arm/mach-imx/imx8m/Kconfig | 8 +
> arch/arm/mach-imx/imx8m/Makefile | 1 +
> arch/arm/mach-imx/imx8m/psci.c | 288 +++
> 3 files changed, 297 insertions(+)
> create mode 100644 arch/arm/mach-imx/imx8m/psci.c
>
> diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
> index 9e957e2de57..080c84f8163 100644
> --- a/arch/arm/mach-imx/imx8m/Kconfig
> +++ b/arch/arm/mach-imx/imx8m/Kconfig
> @@ -27,6 +27,14 @@ config IMX8MP
> config SYS_SOC
> default "imx8m"
>
> +config SYS_HAS_ARMV8_SECURE_BASE
> + bool "Enable secure address for PSCI image"
> + depends on ARMV8_PSCI
> + help
> + PSCI image can be re-located to secure RAM.
> + If enabled, please also define the value for ARMV8_SECURE_BASE,
> + for i.MX8M, it could be some address in OCRAM.
> +
> choice
> prompt "NXP i.MX8M board select"
> optional
> diff --git a/arch/arm/mach-imx/imx8m/Makefile
> b/arch/arm/mach-imx/imx8m/Makefile
> index d9dee894aae..abd5ddc1774 100644
> --- a/arch/arm/mach-imx/imx8m/Makefile
> +++ b/arch/arm/mach-imx/imx8m/Makefile
> @@ -4,5 +4,6 @@
>
> obj-y += lowlevel_init.o
> obj-y += clock_slice.o soc.o
> +obj-$(CONFIG_ARMV8_PSCI) += psci.o
> obj-$(CONFIG_IMX8MQ) += clock_imx8mq.o
> obj-$(CONFIG_IMX8MM)$(CONFIG_IMX8MN)$(CONFIG_IMX8MP) += clock_imx8mm.o
> diff --git a/arch/arm/mach-imx/imx8m/psci.c b/arch/arm/mach-imx/imx8m/psci.c
> new file mode 100644
> index 000..62f0b768cfa
> --- /dev/null
> +++ b/arch/arm/mach-imx/imx8m/psci.c
> @@ -0,0 +1,288 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * This file implements basic PSCI support for i.MX8M
> + *
> + * Copyright (C) 2022 Marek Vasut
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SNVS_LPCR 0x38
> +#define SNVS_LPCR_TOP BIT(6)
> +#define SNVS_LPCR_DP_ENBIT(5)
> +#define SNVS_LPCR_SRTC_ENV BIT(0)
> +
> +#define MPIDR_AFF0 GENMASK(7, 0)
> +
> +#define GPC_LPCR_A53_AD0x4
> +#define EN_Cn_WFI_PDN(cpu) BIT(cpu) & 1) * 2) + (((cpu) & 2)
> * 8)))
> +#define GPC_PGC_nCTRL(cpu) (0x800 + ((cpu) * 0x40))
> +#define PGC_PCRBIT(0)
> +#define GPC_CPU_PGC_SW_PUP_REQ (IS_ENABLED(CONFIG_IMX8MP) ? 0xd0 :
> 0xf0)
> +#define COREn_A53_SW_PUP_REQ(cpu) BIT(cpu)
> +
> +#define SRC_A53RCR10x8
> +#define A53_COREn_ENABLE(n)BIT(n)
> +#define SRC_GPR(n) (0x74 + ((n) * 4))
> +
> +/*
> + * Helper code
> + */
> +static u8 psci_state[CONFIG_ARMV8_PSCI_NR_CPUS] __secure_data = {
> + PSCI_AFFINITY_LEVEL_ON,
> + PSCI_AFFINITY_LEVEL_OFF,
> + PSCI_AFFINITY_LEVEL_OFF,
> + PSCI_AFFINITY_LEVEL_OFF
> +};
> +
> +int psci_update_dt(void *fdt)
> +{
> + return 0;
> +}
> +
> +__secure static void psci_set_state(int cpu, u8 state)
> +{
> + psci_state[cpu] = state;
> + dsb();
> + isb();
> +}
> +
> +__secure static s32 psci_cp
Re: [PATCH 10/10] arm: imx: imx8m: Add basic PSCI provider implementation
On Wed, Dec 21, 2022 at 9:58 PM Marek Vasut wrote: > > On 12/22/22 04:05, Adam Ford wrote: > > On Wed, Dec 21, 2022 at 6:47 PM Marek Vasut wrote: > >> > >> Implement basic PSCI provider to let OS turn CPU cores off and on, > >> power off and restart the system and determine PSCI version. This > >> is sufficient to remove the need for the ATF BL31 blob altogether. > >> > >> To make use of this functionality, active the following Kconfig options: > >># CONFIG_PSCI_RESET is not set > >>CONFIG_ARMV8_MULTIENTRY=y > >>CONFIG_ARMV8_SET_SMPEN=y > >>CONFIG_ARMV8_SPL_EXCEPTION_VECTORS=y > >>CONFIG_ARMV8_EA_EL3_FIRST=y > >>CONFIG_ARMV8_PSCI=y > >>CONFIG_ARMV8_PSCI_CPUS_PER_CLUSTER=4 > >>CONFIG_ARMV8_SECURE_BASE=0x97 > > > > I am guessing 0x97 was for the 8MP based on the previous location > > of ATF. Is that true? If that's the case, can I assume that this > > address would be 0x91, 0x92 and 0x96 for the imx8mq, > > imx8mm and imx8mn respectively? > > It was for MX8MP, but you can pick whichever address you want, since it > is U-Boot that installs the SMC handlers, you are no longer forced to > somehow try and accommodate custom not well fitting load address picked > by some 3rd party binary blob. I patched U-Boot's master with this series and I tried it on imx8mn_beacon and imx8mm_beacon without success. I never even saw the SPL message. I tried to focus on the Nano since the boot ROM in that one is more similar to that of the 8mp, but the behaviour was similar to that of the Nano. Are there any dependencies or should I have used a specific starting branch? adam
Re: [PATCH 10/10] arm: imx: imx8m: Add basic PSCI provider implementation
On Mon, Jan 2, 2023 at 5:41 PM Marek Vasut wrote: > > On 1/2/23 17:44, Adam Ford wrote: > > On Wed, Dec 21, 2022 at 9:58 PM Marek Vasut wrote: > >> > >> On 12/22/22 04:05, Adam Ford wrote: > >>> On Wed, Dec 21, 2022 at 6:47 PM Marek Vasut wrote: > >>>> > >>>> Implement basic PSCI provider to let OS turn CPU cores off and on, > >>>> power off and restart the system and determine PSCI version. This > >>>> is sufficient to remove the need for the ATF BL31 blob altogether. > >>>> > >>>> To make use of this functionality, active the following Kconfig options: > >>>> # CONFIG_PSCI_RESET is not set > >>>> CONFIG_ARMV8_MULTIENTRY=y > >>>> CONFIG_ARMV8_SET_SMPEN=y > >>>> CONFIG_ARMV8_SPL_EXCEPTION_VECTORS=y > >>>> CONFIG_ARMV8_EA_EL3_FIRST=y > >>>> CONFIG_ARMV8_PSCI=y > >>>> CONFIG_ARMV8_PSCI_CPUS_PER_CLUSTER=4 > >>>> CONFIG_ARMV8_SECURE_BASE=0x97 > >>> > >>>I am guessing 0x97 was for the 8MP based on the previous location > >>> of ATF. Is that true? If that's the case, can I assume that this > >>> address would be 0x91, 0x92 and 0x96 for the imx8mq, > >>> imx8mm and imx8mn respectively? > >> > >> It was for MX8MP, but you can pick whichever address you want, since it > >> is U-Boot that installs the SMC handlers, you are no longer forced to > >> somehow try and accommodate custom not well fitting load address picked > >> by some 3rd party binary blob. > > > > I patched U-Boot's master with this series and I tried it on > > imx8mn_beacon and imx8mm_beacon without success. I never even saw the > > SPL message. I tried to focus on the Nano since the boot ROM in that > > one is more similar to that of the 8mp, but the behaviour was similar > > to that of the Nano. Are there any dependencies or should I have used > > a specific starting branch? > > Nope . But if you don't even see output from SPL, that's where I would > start looking. Do you see output from SPL without this series ? Note > that bulk of this series content applies to U-Boot proper, not SPL so far. Without the patch series the generated flash.bin file booted both the Mini and the Nano just fine. I have a pending 8m plus that I can also try, since that is what you used. I just wanted to make sure I was starting from the right place before I went too far with it. adam
Re: [PATCH 10/10] arm: imx: imx8m: Add basic PSCI provider implementation
On Mon, Jan 2, 2023 at 5:58 PM Marek Vasut wrote: > > On 1/3/23 00:47, Adam Ford wrote: > > On Mon, Jan 2, 2023 at 5:41 PM Marek Vasut wrote: > >> > >> On 1/2/23 17:44, Adam Ford wrote: > >>> On Wed, Dec 21, 2022 at 9:58 PM Marek Vasut wrote: > >>>> > >>>> On 12/22/22 04:05, Adam Ford wrote: > >>>>> On Wed, Dec 21, 2022 at 6:47 PM Marek Vasut wrote: > >>>>>> > >>>>>> Implement basic PSCI provider to let OS turn CPU cores off and on, > >>>>>> power off and restart the system and determine PSCI version. This > >>>>>> is sufficient to remove the need for the ATF BL31 blob altogether. > >>>>>> > >>>>>> To make use of this functionality, active the following Kconfig > >>>>>> options: > >>>>>> # CONFIG_PSCI_RESET is not set > >>>>>> CONFIG_ARMV8_MULTIENTRY=y > >>>>>> CONFIG_ARMV8_SET_SMPEN=y > >>>>>> CONFIG_ARMV8_SPL_EXCEPTION_VECTORS=y > >>>>>> CONFIG_ARMV8_EA_EL3_FIRST=y > >>>>>> CONFIG_ARMV8_PSCI=y > >>>>>> CONFIG_ARMV8_PSCI_CPUS_PER_CLUSTER=4 > >>>>>> CONFIG_ARMV8_SECURE_BASE=0x97 > >>>>> > >>>>> I am guessing 0x97 was for the 8MP based on the previous > >>>>> location > >>>>> of ATF. Is that true? If that's the case, can I assume that this > >>>>> address would be 0x91, 0x92 and 0x96 for the imx8mq, > >>>>> imx8mm and imx8mn respectively? > >>>> > >>>> It was for MX8MP, but you can pick whichever address you want, since it > >>>> is U-Boot that installs the SMC handlers, you are no longer forced to > >>>> somehow try and accommodate custom not well fitting load address picked > >>>> by some 3rd party binary blob. > >>> > >>> I patched U-Boot's master with this series and I tried it on > >>> imx8mn_beacon and imx8mm_beacon without success. I never even saw the > >>> SPL message. I tried to focus on the Nano since the boot ROM in that > >>> one is more similar to that of the 8mp, but the behaviour was similar > >>> to that of the Nano. Are there any dependencies or should I have used > >>> a specific starting branch? > >> > >> Nope . But if you don't even see output from SPL, that's where I would > >> start looking. Do you see output from SPL without this series ? Note > >> that bulk of this series content applies to U-Boot proper, not SPL so far. > > > > Without the patch series the generated flash.bin file booted both the > > Mini and the Nano just fine. I have a pending 8m plus that I can also > > try, since that is what you used. I just wanted to make sure I was > > starting from the right place before I went too far with it. > > Try and drop > > [PATCH 09/10] arm: imx: imx8m: Program CSU and TZASC if PSCI provider > > does SPL start then ? I reverted 9/19 without success either. I'll try to do a git bisect to see if I can narrow it down. I might see if my employer will let me borrow a debugger. Debugging SPL is a bit challenging due to the relocation step, but I am not convinced I am geting that far since I get no text output at all. > > I plan to try this on Nano at some point this month too. I'll let you know my findings when I get some more time to test this. adam
[PATCH] arm: dts: rz-g2-beacon-u-boot: Fix QSPI Regression
The QSPI is accessed via the RPC-IF, but the compatible flags
previously used a different name. This compatibel name was changed
which broke the ability to access the QSPI. Fix this by removing
the custom naming reference.
Fixes: 68083b897b57 ("renesas: Fix RPC-IF compatible values")
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/rz-g2-beacon-u-boot.dtsi
b/arch/arm/dts/rz-g2-beacon-u-boot.dtsi
index 4d17854918..da1c3b0939 100644
--- a/arch/arm/dts/rz-g2-beacon-u-boot.dtsi
+++ b/arch/arm/dts/rz-g2-beacon-u-boot.dtsi
@@ -45,7 +45,6 @@
};
&rpc {
- compatible = "renesas,rcar-gen3-rpc";
pinctrl-0 = <&qspi_pins>;
pinctrl-names = "default";
num-cs = <1>;
--
2.34.1
[PATCH] arm: rmobile: rzg2_beacon: Enable alternative Ethernet PHY
Due to the part shortage, the AR8031 PHY was replaced with a Micrel KSZ9131. Enabling both config options keeps backward compatibility with either platform, and both appear to be auto-detected. Signed-off-by: Adam Ford diff --git a/configs/rzg2_beacon_defconfig b/configs/rzg2_beacon_defconfig index 36787057a2..b4ea6c630a 100644 --- a/configs/rzg2_beacon_defconfig +++ b/configs/rzg2_beacon_defconfig @@ -68,6 +68,8 @@ CONFIG_SPI_FLASH_WINBOND=y CONFIG_BITBANGMII=y CONFIG_BITBANGMII_MULTI=y CONFIG_PHY_ATHEROS=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_RENESAS_RAVB=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y -- 2.34.1
Applying DTB Overlays from ATF on RZ/G2
ATF generates a couple memory nodes based on how it's compiled and
generates a reserved-memory node, and I want to overlay it with the
device tree so Linux knows about this reserved memory.
When I boot U-Boot, I can read the reserved-memory node:
=> fdt addr 0xe631e588
Working FDT set to e631e588
=> fdt print /reserved-memory
reserved-memory {
lossy-decompression@5400 {
renesas,formats = <0x>;
no-map;
reg = <0x 0x5400 0x 0x0300>;
compatible = "renesas,lossy-decompression", "shared-dma-pool";
};
};
=>
I attempt to overlay it with the following:
=> run loadfdt
65932 bytes read in 6 ms (10.5 MiB/s)
=> fdt addr $load_addr
Working fdt: e631e588
=> fdt resize 8192
=> fdt apply 0xe631e588
At this point, I would expect the reserved-memory node to be merged
with the main FDT, but it appears to be missing.
=> fdt print /reserved-memory
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
=>
There are no errors, but there are no overlays either.
Does someone have any suggestions as to what I am doing wrong?
Without the reserved memory node, Linux can crash if it tries to use
the memory in that restricted area, and that node might change
depending on how ATF is compiled.
Thanks for any help.
adam
Re: Applying DTB Overlays from ATF on RZ/G2
On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt wrote:
>
> On 1/4/23 22:35, Adam Ford wrote:
> > ATF generates a couple memory nodes based on how it's compiled and
> > generates a reserved-memory node, and I want to overlay it with the
> > device tree so Linux knows about this reserved memory.
> >
> > When I boot U-Boot, I can read the reserved-memory node:
> >
> > => fdt addr 0xe631e588
> > Working FDT set to e631e588
> > => fdt print /reserved-memory
> > reserved-memory {
> > lossy-decompression@5400 {
> > renesas,formats = <0x>;
> > no-map;
> > reg = <0x 0x5400 0x 0x0300>;
> > compatible = "renesas,lossy-decompression", "shared-dma-pool";
> > };
> > };
> > =>
> >
> > I attempt to overlay it with the following:
> >
> > => run loadfdt
> > 65932 bytes read in 6 ms (10.5 MiB/s)
> > => fdt addr $load_addr
>
> When actually setting the address you will see a message "Working FDT
> set to %lx\n". So I assume $load_addr is empty.
>
> Did you mean $loadaddr or $fileaddr?
Opps, that was a copy-paste error. Even with that, I still get the
failure to overlay:
=> run loadfdt
65932 bytes read in 6 ms (10.5 MiB/s)
=> fdt addr $fdt_addr
Working FDT set to 4800
=> fdt resize 8192
=> fdt apply 0xe631e588
=> fdt print /reserved-memory
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
=>
>
> > Working fdt: e631e588
> > => fdt resize 8192
> > => fdt apply 0xe631e588
>
> Here you are apply the devicetree at e631e588 to itself which cannot work.
>
> Best regards
>
> Heinrich
>
> >
> > At this point, I would expect the reserved-memory node to be merged
> > with the main FDT, but it appears to be missing.
> >
> > => fdt print /reserved-memory
> > libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
> > =>
> >
> > There are no errors, but there are no overlays either.
> >
> > Does someone have any suggestions as to what I am doing wrong?
> > Without the reserved memory node, Linux can crash if it tries to use
> > the memory in that restricted area, and that node might change
> > depending on how ATF is compiled.
> >
> > Thanks for any help.
> >
> > adam
>
Re: [PATCH] arm: rmobile: rzg2_beacon: Enable alternative Ethernet PHY
On Wed, Jan 4, 2023 at 7:46 PM Marek Vasut wrote: > > On 1/4/23 19:05, Adam Ford wrote: > > Due to the part shortage, the AR8031 PHY was replaced with a > > Micrel KSZ9131. Enabling both config options keeps backward > > compatibility with either platform, and both appear to be > > auto-detected. > > Reviewed-by: Marek Vasut > > (is this material for 2023.01 release or can this wait?) This can wait. The new boards haven't shipped to anyone yet. adam
Re: Applying DTB Overlays from ATF on RZ/G2
On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut wrote:
>
> On 1/5/23 00:48, Heinrich Schuchardt wrote:
> > Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford :
> >> On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt
> >> wrote:
> >>>
> >>> On 1/4/23 22:35, Adam Ford wrote:
> >>>> ATF generates a couple memory nodes based on how it's compiled and
> >>>> generates a reserved-memory node, and I want to overlay it with the
> >>>> device tree so Linux knows about this reserved memory.
> >>>>
> >>>> When I boot U-Boot, I can read the reserved-memory node:
> >>>>
> >>>> => fdt addr 0xe631e588
> >>>> Working FDT set to e631e588
> >>>> => fdt print /reserved-memory
> >>>> reserved-memory {
> >>>> lossy-decompression@5400 {
> >>>> renesas,formats = <0x>;
> >>>> no-map;
> >>>> reg = <0x 0x5400 0x 0x0300>;
> >>>> compatible = "renesas,lossy-decompression", "shared-dma-pool";
> >>>> };
> >>>> };
> >>>> =>
> >>>>
> >>>> I attempt to overlay it with the following:
> >>>>
> >>>> => run loadfdt
> >>>> 65932 bytes read in 6 ms (10.5 MiB/s)
> >>>> => fdt addr $load_addr
> >>>
> >>> When actually setting the address you will see a message "Working FDT
> >>> set to %lx\n". So I assume $load_addr is empty.
> >>>
> >>> Did you mean $loadaddr or $fileaddr?
> >>
> >> Opps, that was a copy-paste error. Even with that, I still get the
> >> failure to overlay:
> >>
> >
> > Did you load a .dtbo file to apply? You cannot apply a devicetree.
> >
> > Is the fdt that you want to apply the overlay to built with symbols (dtc
> > parameter -@)?
>
> Note that the fragment passed to U-Boot by upstream ATF is already
> automatically merged into the U-Boot control DT (see
> board/renesas/rcar-common/common.c ) . U-Boot should pass that on to
> Linux automatically.
I ran some tests, and it appears the function fdtdec_board_setup is
never getting called. That looks like the code that grabs the blob
from ATF. I intentionally removed the memory nodes from the kernel
device tree expecting the memory nodes to get added from ATF, but when
I booted it, it promptly hung. That implied to me that the memory
nodes didn't get added from ATF.
I added some debug code and noticed that ft_board_setup did not get
executed, so I created a call to fdtdec_board_setup from
ft_board_setup and my board booted just fine. I am curious to know if
other rcar/rzg2 boards are seeing something similar? Is calling
fdtdec_board_setup from ft_board_setup appropriate?
adam
Re: Applying DTB Overlays from ATF on RZ/G2
On Sat, Jan 7, 2023 at 6:01 AM Adam Ford wrote:
>
> On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut wrote:
> >
> > On 1/5/23 00:48, Heinrich Schuchardt wrote:
> > > Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford :
> > >> On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt
> > >> wrote:
> > >>>
> > >>> On 1/4/23 22:35, Adam Ford wrote:
> > >>>> ATF generates a couple memory nodes based on how it's compiled and
> > >>>> generates a reserved-memory node, and I want to overlay it with the
> > >>>> device tree so Linux knows about this reserved memory.
> > >>>>
> > >>>> When I boot U-Boot, I can read the reserved-memory node:
> > >>>>
> > >>>> => fdt addr 0xe631e588
> > >>>> Working FDT set to e631e588
> > >>>> => fdt print /reserved-memory
> > >>>> reserved-memory {
> > >>>> lossy-decompression@5400 {
> > >>>> renesas,formats = <0x>;
> > >>>> no-map;
> > >>>> reg = <0x 0x5400 0x 0x0300>;
> > >>>> compatible = "renesas,lossy-decompression", "shared-dma-pool";
> > >>>> };
> > >>>> };
> > >>>> =>
> > >>>>
+ CC Biju Das
> > >>>> I attempt to overlay it with the following:
> > >>>>
> > >>>> => run loadfdt
> > >>>> 65932 bytes read in 6 ms (10.5 MiB/s)
> > >>>> => fdt addr $load_addr
> > >>>
> > >>> When actually setting the address you will see a message "Working FDT
> > >>> set to %lx\n". So I assume $load_addr is empty.
> > >>>
> > >>> Did you mean $loadaddr or $fileaddr?
> > >>
> > >> Opps, that was a copy-paste error. Even with that, I still get the
> > >> failure to overlay:
> > >>
> > >
> > > Did you load a .dtbo file to apply? You cannot apply a devicetree.
> > >
> > > Is the fdt that you want to apply the overlay to built with symbols (dtc
> > > parameter -@)?
> >
> > Note that the fragment passed to U-Boot by upstream ATF is already
> > automatically merged into the U-Boot control DT (see
> > board/renesas/rcar-common/common.c ) . U-Boot should pass that on to
> > Linux automatically.
>
> I ran some tests, and it appears the function fdtdec_board_setup is
> never getting called. That looks like the code that grabs the blob
> from ATF. I intentionally removed the memory nodes from the kernel
> device tree expecting the memory nodes to get added from ATF, but when
> I booted it, it promptly hung. That implied to me that the memory
> nodes didn't get added from ATF.
>
> I added some debug code and noticed that ft_board_setup did not get
> executed, so I created a call to fdtdec_board_setup from
> ft_board_setup and my board booted just fine. I am curious to know if
> other rcar/rzg2 boards are seeing something similar? Is calling
> fdtdec_board_setup from ft_board_setup appropriate?
>
> adam
Re: Applying DTB Overlays from ATF on RZ/G2
On Mon, Jan 9, 2023 at 2:46 AM Biju Das wrote:
>
> Hi Adam,
>
> > Subject: Re: Applying DTB Overlays from ATF on RZ/G2
> >
> > On Sat, Jan 7, 2023 at 6:01 AM Adam Ford wrote:
> > >
> > > On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut wrote:
> > > >
> > > > On 1/5/23 00:48, Heinrich Schuchardt wrote:
> > > > > Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford :
> > > > >> On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt
> > wrote:
> > > > >>>
> > > > >>> On 1/4/23 22:35, Adam Ford wrote:
> > > > >>>> ATF generates a couple memory nodes based on how it's compiled
> > > > >>>> and generates a reserved-memory node, and I want to overlay it
> > > > >>>> with the device tree so Linux knows about this reserved memory.
> > > > >>>>
> > > > >>>> When I boot U-Boot, I can read the reserved-memory node:
> > > > >>>>
> > > > >>>> => fdt addr 0xe631e588
> > > > >>>> Working FDT set to e631e588
> > > > >>>> => fdt print /reserved-memory
> > > > >>>> reserved-memory {
> > > > >>>> lossy-decompression@5400 {
> > > > >>>> renesas,formats = <0x>; no-map; reg = <0x
> > > > >>>> 0x5400 0x 0x0300>; compatible =
> > > > >>>> "renesas,lossy-decompression", "shared-dma-pool"; }; }; =>
> > > > >>>>
> >
> > + CC Biju Das
>
> > > > >>>> I attempt to overlay it with the following:
> > > > >>>>
> > > > >>>> => run loadfdt
> > > > >>>> 65932 bytes read in 6 ms (10.5 MiB/s) => fdt addr $load_addr
> > > > >>>
> > > > >>> When actually setting the address you will see a message
> > > > >>> "Working FDT set to %lx\n". So I assume $load_addr is empty.
> > > > >>>
> > > > >>> Did you mean $loadaddr or $fileaddr?
> > > > >>
> > > > >> Opps, that was a copy-paste error. Even with that, I still get
> > > > >> the failure to overlay:
> > > > >>
> > > > >
> > > > > Did you load a .dtbo file to apply? You cannot apply a devicetree.
> > > > >
> > > > > Is the fdt that you want to apply the overlay to built with symbols
> > (dtc parameter -@)?
> > > >
> > > > Note that the fragment passed to U-Boot by upstream ATF is already
> > > > automatically merged into the U-Boot control DT (see
> > > > board/renesas/rcar-common/common.c ) . U-Boot should pass that on to
> > > > Linux automatically.
> > >
> > > I ran some tests, and it appears the function fdtdec_board_setup is
> > > never getting called.
>
> Without that board detection and proper memory detection in u-boot/kernel
> won't happen.
> [1]
> https://elixir.bootlin.com/u-boot/latest/source/board/hoperun/hihope-rzg2/hihope-rzg2.c#L83
>
Right now, my device trees have the memory node(s), but not the
reserved-memory node which I'm trying to insert dymanically based on
how ATF is built.
>
> > > That looks like the code that grabs the blob
> > > from ATF. I intentionally removed the memory nodes from the kernel
> > > device tree expecting the memory nodes to get added from ATF, but when
> > > I booted it, it promptly hung. That implied to me that the memory
> > > nodes didn't get added from ATF.
> > >
> > > I added some debug code and noticed that ft_board_setup did not get
> > > executed, so I created a call to fdtdec_board_setup from
> > > ft_board_setup and my board booted just fine. I am curious to know if
> > > other rcar/rzg2 boards are seeing something similar? Is calling
> > > fdtdec_board_setup from ft_board_setup appropriate?
>
> It should be working as we are using lossy compression for media playback for
> VLP release
> and VLP release[1] is using Mainline ATF and U-boot. Similar case for R-Car.
> I remember correctly for lossy compression case, we explicitly add a node in
> kernel [2].
>
> [1]
> https://github.com/renesas-rz/rz_linux-cip/blob/rz-5.10-cip17/arch/arm64/boot/dts/renesas/r8a774b1-hihope-rzg2n.dts#L27
>
> [2]
> https://github.com/renesas-rcar/linux-bsp/blob/v5.10.41/rcar-5.1.3.rc10/arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dts#L32
>
Your custom repo has the reserved-memory node in the device tree. I
was trying to figure out how to get the reserved-memory node to
propagate from ATF through U-Boot to Linux without needing to have the
reserved-memory node in the device tree. I had attempted to add the
reserved-memory node upstream, and Geert asked me to use ATF insead.
I added debug code into the function that reads the ATF node that is
passed to U-Boot and it doesn't appear to be getting called unless I
modify the code to explicitly do it. I wasn't sure if I am missing a
Kconfig option somewhere.
adam
>
> Cheers,
> Biju
>
>
Re: Applying DTB Overlays from ATF on RZ/G2
On Tue, Jan 10, 2023 at 7:02 AM Marek Vasut wrote:
>
> On 1/7/23 13:01, Adam Ford wrote:
> > On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut wrote:
> >>
> >> On 1/5/23 00:48, Heinrich Schuchardt wrote:
> >>> Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford :
> >>>> On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt
> >>>> wrote:
> >>>>>
> >>>>> On 1/4/23 22:35, Adam Ford wrote:
> >>>>>> ATF generates a couple memory nodes based on how it's compiled and
> >>>>>> generates a reserved-memory node, and I want to overlay it with the
> >>>>>> device tree so Linux knows about this reserved memory.
> >>>>>>
> >>>>>> When I boot U-Boot, I can read the reserved-memory node:
> >>>>>>
> >>>>>> => fdt addr 0xe631e588
> >>>>>> Working FDT set to e631e588
> >>>>>> => fdt print /reserved-memory
> >>>>>> reserved-memory {
> >>>>>> lossy-decompression@5400 {
> >>>>>> renesas,formats = <0x>;
> >>>>>> no-map;
> >>>>>> reg = <0x 0x5400 0x 0x0300>;
> >>>>>> compatible = "renesas,lossy-decompression", "shared-dma-pool";
> >>>>>> };
> >>>>>> };
> >>>>>> =>
> >>>>>>
> >>>>>> I attempt to overlay it with the following:
> >>>>>>
> >>>>>> => run loadfdt
> >>>>>> 65932 bytes read in 6 ms (10.5 MiB/s)
> >>>>>> => fdt addr $load_addr
> >>>>>
> >>>>> When actually setting the address you will see a message "Working FDT
> >>>>> set to %lx\n". So I assume $load_addr is empty.
> >>>>>
> >>>>> Did you mean $loadaddr or $fileaddr?
> >>>>
> >>>> Opps, that was a copy-paste error. Even with that, I still get the
> >>>> failure to overlay:
> >>>>
> >>>
> >>> Did you load a .dtbo file to apply? You cannot apply a devicetree.
> >>>
> >>> Is the fdt that you want to apply the overlay to built with symbols (dtc
> >>> parameter -@)?
> >>
> >> Note that the fragment passed to U-Boot by upstream ATF is already
> >> automatically merged into the U-Boot control DT (see
> >> board/renesas/rcar-common/common.c ) . U-Boot should pass that on to
> >> Linux automatically.
> >
> > I ran some tests, and it appears the function fdtdec_board_setup is
> > never getting called. That looks like the code that grabs the blob
> > from ATF. I intentionally removed the memory nodes from the kernel
> > device tree expecting the memory nodes to get added from ATF, but when
> > I booted it, it promptly hung. That implied to me that the memory
> > nodes didn't get added from ATF.
> >
> > I added some debug code and noticed that ft_board_setup did not get
> > executed, so I created a call to fdtdec_board_setup from
> > ft_board_setup and my board booted just fine. I am curious to know if
> > other rcar/rzg2 boards are seeing something similar? Is calling
> > fdtdec_board_setup from ft_board_setup appropriate?
>
> Note that fdtdec_board_setup() is called very early on when U-Boot
> itself starts up and it is used to patch the fragment passed from ATF
> into U-Boot control DT. The ft_board_setup() is called before booting
> OS, i.e. at much later stage.
>
> Can you maybe summarize what exactly it is that you're trying to pass
> through , and from where to where ?
There is a reserved-memory node generated by ATF and I want to pass
that node to the Linux Kernel, so the memory is reserved, because
accessing the memory will cause Linux to crash. I wanted to put the
reserved-memory node into the kernel dts file, but Geert asked me to
pass the blob from ATF instead of hard-coding it into the dts.
I am just trying to figure out how to make that happen, because it
appears the memory isn't being reserved.
adam
Re: Applying DTB Overlays from ATF on RZ/G2
On Tue, Jan 10, 2023 at 7:40 AM Marek Vasut wrote:
>
> On 1/10/23 14:19, Adam Ford wrote:
> > On Tue, Jan 10, 2023 at 7:02 AM Marek Vasut wrote:
> >>
> >> On 1/7/23 13:01, Adam Ford wrote:
> >>> On Wed, Jan 4, 2023 at 5:55 PM Marek Vasut wrote:
> >>>>
> >>>> On 1/5/23 00:48, Heinrich Schuchardt wrote:
> >>>>> Am 5. Januar 2023 00:19:36 MEZ schrieb Adam Ford :
> >>>>>> On Wed, Jan 4, 2023 at 5:15 PM Heinrich Schuchardt
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On 1/4/23 22:35, Adam Ford wrote:
> >>>>>>>> ATF generates a couple memory nodes based on how it's compiled and
> >>>>>>>> generates a reserved-memory node, and I want to overlay it with the
> >>>>>>>> device tree so Linux knows about this reserved memory.
> >>>>>>>>
> >>>>>>>> When I boot U-Boot, I can read the reserved-memory node:
> >>>>>>>>
> >>>>>>>> => fdt addr 0xe631e588
> >>>>>>>> Working FDT set to e631e588
> >>>>>>>> => fdt print /reserved-memory
> >>>>>>>> reserved-memory {
> >>>>>>>> lossy-decompression@5400 {
> >>>>>>>> renesas,formats = <0x>;
> >>>>>>>> no-map;
> >>>>>>>> reg = <0x 0x5400 0x 0x0300>;
> >>>>>>>> compatible = "renesas,lossy-decompression", "shared-dma-pool";
> >>>>>>>> };
> >>>>>>>> };
> >>>>>>>> =>
> >>>>>>>>
> >>>>>>>> I attempt to overlay it with the following:
> >>>>>>>>
> >>>>>>>> => run loadfdt
> >>>>>>>> 65932 bytes read in 6 ms (10.5 MiB/s)
> >>>>>>>> => fdt addr $load_addr
> >>>>>>>
> >>>>>>> When actually setting the address you will see a message "Working FDT
> >>>>>>> set to %lx\n". So I assume $load_addr is empty.
> >>>>>>>
> >>>>>>> Did you mean $loadaddr or $fileaddr?
> >>>>>>
> >>>>>> Opps, that was a copy-paste error. Even with that, I still get the
> >>>>>> failure to overlay:
> >>>>>>
> >>>>>
> >>>>> Did you load a .dtbo file to apply? You cannot apply a devicetree.
> >>>>>
> >>>>> Is the fdt that you want to apply the overlay to built with symbols
> >>>>> (dtc parameter -@)?
> >>>>
> >>>> Note that the fragment passed to U-Boot by upstream ATF is already
> >>>> automatically merged into the U-Boot control DT (see
> >>>> board/renesas/rcar-common/common.c ) . U-Boot should pass that on to
> >>>> Linux automatically.
> >>>
> >>> I ran some tests, and it appears the function fdtdec_board_setup is
> >>> never getting called. That looks like the code that grabs the blob
> >>> from ATF. I intentionally removed the memory nodes from the kernel
> >>> device tree expecting the memory nodes to get added from ATF, but when
> >>> I booted it, it promptly hung. That implied to me that the memory
> >>> nodes didn't get added from ATF.
> >>>
> >>> I added some debug code and noticed that ft_board_setup did not get
> >>> executed, so I created a call to fdtdec_board_setup from
> >>> ft_board_setup and my board booted just fine. I am curious to know if
> >>> other rcar/rzg2 boards are seeing something similar? Is calling
> >>> fdtdec_board_setup from ft_board_setup appropriate?
> >>
> >> Note that fdtdec_board_setup() is called very early on when U-Boot
> >> itself starts up and it is used to patch the fragment passed from ATF
> >> into U-Boot control DT. The ft_board_setup() is called before booting
> >> OS, i.e. at much later stage.
> >>
> >> Can you maybe summarize what exactly it is that you're trying to pass
> >> through , and from where to where ?
> >
> > There is a reserved-memory node generated by ATF and I want to pass
> > that node to the Linux Kernel, so the memory is reserved, because
> > accessing the memory will cause Linux to crash. I wanted to put the
> > reserved-memory node into the kernel dts file, but Geert asked me to
> > pass the blob from ATF instead of hard-coding it into the dts.
> > I am just trying to figure out how to make that happen, because it
> > appears the memory isn't being reserved.
>
> So, can you check whether the U-Boot control DT does contain this
> reserved memory node ?
>
> => fdt addr $fdtcontroladdr
> => fdt print /path/to/the/node
>
=> fdt addr $fdtcontroladdr
Working FDT set to bbedccb0
=> fdt print /reserved-memory
reserved-memory {
lossy-decompression@5400 {
compatible = "renesas,lossy-decompression", "shared-dma-pool";
reg = <0x 0x5400 0x 0x0300>;
no-map;
renesas,formats = <0x>;
};
};
=>
So it does appear that the reserved-memory is showing up here.
Is there a way to export just this node and append it to the kernel's DTB?
adam
> ?
>
> If so, then it is up to U-Boot to pass its own reserved memory nodes
> onward to Linux.
Re: [PATCH 1/5] configs: imx8mp_beacon: Do not set SYS_CONSOLE_IS_IN_ENV
On Thu, Oct 26, 2023 at 9:20 AM Fabio Estevam wrote: > > On Wed, Oct 25, 2023 at 8:05 PM Adam Ford wrote: > > > > The hardware only supports a specific console port, so remove the > > option to change the console location in the environment. > > > > Signed-off-by: Adam Ford > > For the series: > Fabio / Stefan, Is there any chance this series can be applied to imx-next? > Reviewed-by: Fabio Estevam
Re: [PATCH 2/2] ARM: dts: imx8mm-venice: prepare for dek blob encapsulation
On Fri, Dec 15, 2023 at 12:41 PM Fabio Estevam wrote: > > Hi Tim, > > On Fri, Dec 15, 2023 at 3:34 PM Tim Harvey wrote: > > > Fabio, > > > > The commit log details are not valid for upstream. I was basing this > > off of 8d060e4a66d6884341fbb3d8ab1d837a3f173d47 which made it upstream > > with the same message. > > > > I can submit a v2 if necessary. > > Yes, please submit a v2 and I will queue this series and the TPM one > to u-boot-imx next. This node appears to already be in the imx8mm-u-boot.dtsi encapsulated by an #ifdef looking for optee. Can this ifdef be expanded to include CONFIG_SECURE_BOOT? adam > Regards, > > Fabio Estevam
[PATCH 1/2] renesas: beacon-rzg2m: Add Marek to MAINTAINER file
Since any changes to the RZ/G2 family go through Marek's tree, update the MAINTAINER file to automatically show his name when running get_maintainer.pl. Without this, he is not copied. Signed-off-by: Adam Ford diff --git a/board/beacon/beacon-rzg2m/MAINTAINERS b/board/beacon/beacon-rzg2m/MAINTAINERS index f8042bb2c4..a4a920a017 100644 --- a/board/beacon/beacon-rzg2m/MAINTAINERS +++ b/board/beacon/beacon-rzg2m/MAINTAINERS @@ -1,5 +1,6 @@ BEACON_RZG2M BOARD M: Adam Ford +M: Marek Vasut S: Maintained F: board/beacon/beacon-rzg2m/ F: include/configs/beacon-rzg2m.h -- 2.43.0
[PATCH 2/2] configs: rzg2_beacon: Realign ENV location and offset
The ENV size and offset were changed to different values in Beacon's downstream release. Change them to the same values as the downstream for consistent behavior. Signed-off-by: Adam Ford diff --git a/configs/rzg2_beacon_defconfig b/configs/rzg2_beacon_defconfig index 4aabb1fe03..234c965023 100644 --- a/configs/rzg2_beacon_defconfig +++ b/configs/rzg2_beacon_defconfig @@ -3,7 +3,8 @@ CONFIG_ARCH_RENESAS=y CONFIG_TEXT_BASE=0x5000 CONFIG_SYS_MALLOC_LEN=0x400 CONFIG_SYS_MALLOC_F_LEN=0x2000 -CONFIG_ENV_OFFSET=0x0 +CONFIG_ENV_SIZE=0x2000 +CONFIG_ENV_OFFSET=0xE000 CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a774a1-beacon-rzg2m-kit" CONFIG_RCAR_GEN3=y -- 2.43.0
Re: USB OTG mode for DWC3 (ie imx8mp) host controller with usb_ether USB Ethernet gadget?
On Mon, Jun 24, 2024 at 2:39 PM Tim Harvey wrote: > > Greetings, > > What is missing in U-Boot for the DWC3 host controller to support OTG > mode for usb_ether (USB Ethernet gadget)? I'm unable to get the usb > ethernet gadget to work for the imx8mp as it errors out with 'No UDC > available in the system'. > > The ums/acm/sdp gadget's all call udc_device_get_by_index to get the > UDC controller which for DWC3 is provided by > drivers/usb/dwc3/dwc3-generic.c and these gadgets work, however > usb_ether is different in that it calls usb_gadget_register_driver to > bind the gadget driver to the UDC and for DWC3 this calls > usb_gadget_probe_driver which iterates over udc_list which does not > contain DWC3 hosts that are in peripheral/otg mode. > > Before I spend a lot more time on this I wanted to see if anyone else > understands why boards with DWC3 host controllers like imx8mp don't > seem to register controllers in udc_list that are not in host mode. > > I'm also unclear how to get a DWC3 controller to switch roles > dynamically at runtime based on a gpio state for example. That support > appears to be missing and I'm not sure what the right way would be to > go about adding it. I notice that some imx8mp boards like the > imx8mp-evk have a u-boot.dtsi that just forces its OTG controller to > peripheral mode and I force the imx8mp-venice OTG controllers into > host mode. I think there is some interaction between the DWC controller and a type-c controller, but I think the mainline code lacks a proper type-c controller and/or framework. Not everyone might use a USB Type-C chip, but it seems like if the USB is set to dual-role, it could default to peripheral mode until someone starts the USB host stuff with 'usb start' I am just not sure how to handle situations where a USB cable may be connected to a host computer and someone issues a start command and brings up VBUS which may cause a voltage contention. I think some people tried to push a Type-C driver if memory serves, but I think it was rejected. I don't recall the details and my memory is terrible. :-) adam > > Best Regards, > > Tim
[PATCH] ARM: dts: imx8mp-beacon-kit-u-boot: Drop EQoS clock work-around
Since commit ecb1c37a7b64 ("clk: imx8mp: Add EQoS MAC clock"),
the clocks for the DWMAC driver can be configured, and removing
them breaks operation.
Fixes: ecb1c37a7b64 ("clk: imx8mp: Add EQoS MAC clock")
Suggested-by: Tim Harvey
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
index ed183f83a7..380146596c 100644
--- a/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-beacon-kit-u-boot.dtsi
@@ -32,12 +32,6 @@
bootph-pre-ram;
};
-&eqos {
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
-};
-
ðphy0 {
reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
reset-assert-us = <15000>;
--
2.43.0
[PATCH] ti: omap: am3517evm: Move environment definition to env file
Instead of cluttering up a header file with a bunch of defines,
move the default environmental variables to a file called
am3517evm.env and reference it from the defconfig. Also
remove dead comments.
Signed-off-by: Adam Ford
diff --git a/board/logicpd/am3517evm/am3517evm.env
b/board/logicpd/am3517evm/am3517evm.env
new file mode 100644
index 00..77bb31c416
--- /dev/null
+++ b/board/logicpd/am3517evm/am3517evm.env
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+console=ttyS2,115200n8
+fdtfile=am3517-evm.dtb
+fdtaddr=0x82C0
+vram=16M
+bootenv=uEnv.txt
+mmcdev=0
+mmcpart=1
+mmcroot=/dev/mmcblk0p2 rw
+mmcrootfstype=ext4 rootwait fixrtc
+mmcargs=setenv bootargs console=${console} ${mtdparts} ${optargs}
root=${mmcroot} rootfstype=${mmcrootfstype} ${cmdline}
+nandargs=setenv bootargs console=${console} ${mtdparts} ${optargs}
root=ubi0:rootfs rw ubi.mtd=rootfs rootfstype=ubifs rootwait ${cmdline}
+loadbootenv=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootenv}
+importbootenv=echo "Importing environment from mmc ..."; env import -t
${loadaddr} ${filesize}
+bootscript=echo "Running bootscript from mmc ..."; source ${loadaddr}
+loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootfile}
+loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdtaddr} ${fdtfile}
+mmcboot=echo "Booting from mmc ..."; run mmcargs; bootz ${loadaddr} -
${fdtaddr}
+nandboot=echo "Booting from nand ..."; run nandargs; nand read ${loadaddr}
2a 80; nand read ${fdtaddr} aa 8; bootm ${loadaddr} - ${fdtaddr}
diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index 70498ca7fb..3236f1dd67 100644
--- a/configs/am3517_evm_defconfig
+++ b/configs/am3517_evm_defconfig
@@ -6,6 +6,7 @@ CONFIG_TEXT_BASE=0x8010
CONFIG_SYS_MALLOC_F_LEN=0x4000
CONFIG_TI_COMMON_CMD_OPTIONS=y
CONFIG_NR_DRAM_BANKS=2
+CONFIG_ENV_SOURCE_FILE="am3517evm"
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x4020ff00
CONFIG_DEFAULT_DEVICE_TREE="ti/omap/am3517-evm"
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index b75c648388..e3432ebeaa 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -15,7 +15,7 @@
#include
/* Board NAND Info. */
-#ifdef CONFIG_MTD_RAW_NAND
+#if defined(CONFIG_MTD_RAW_NAND)
#define CFG_SYS_NAND_ECCPOS{ 2, 3, 4, 5, 6, 7, 8, 9, 10, \
11, 12, 13, 14, 16, 17, 18, 19, 20, \
21, 22, 23, 24, 25, 26, 27, 28, 30, \
@@ -35,61 +35,8 @@
* DTB 4 * NAND_BLOCK_SIZE = 512 KiB @ 0xAA
* RootFS Remaining Flash Space @ 0xB2
*/
-#endif /* CONFIG_MTD_RAW_NAND */
-
-/* Environment information */
-#define CFG_EXTRA_ENV_SETTINGS \
- "loadaddr=0x8200\0" \
- "console=ttyS2,115200n8\0" \
- "fdtfile=am3517-evm.dtb\0" \
- "fdtaddr=0x82C0\0" \
- "vram=16M\0" \
- "bootenv=uEnv.txt\0" \
- "cmdline=\0" \
- "optargs=\0" \
- "mmcdev=0\0" \
- "mmcpart=1\0" \
- "mmcroot=/dev/mmcblk0p2 rw\0" \
- "mmcrootfstype=ext4 rootwait fixrtc\0" \
- "mmcargs=setenv bootargs console=${console} " \
- "${mtdparts} " \
- "${optargs} " \
- "root=${mmcroot} " \
- "rootfstype=${mmcrootfstype} " \
- "${cmdline}\0" \
- "nandargs=setenv bootargs console=${console} " \
- "${mtdparts} " \
- "${optargs} " \
- "root=ubi0:rootfs rw ubi.mtd=rootfs " \
- "rootfstype=ubifs rootwait " \
- "${cmdline}\0" \
- "loadbootenv=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootenv}\0"\
- "importbootenv=echo Importing environment from mmc ...; " \
- "env import -t ${loadaddr} ${filesize}\0" \
- "bootscript=echo Running bootscript from mmc ...; " \
- "source ${loadaddr}\0" \
- "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootfile}\0" \
- "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdtaddr} ${fdtfile}\0" \
- "mmcboot=echo Booting from mmc ...; " \
- "run mmcargs; " \
- "bootz ${loadaddr} - ${fdtaddr}\0" \
- "nandboot=echo Booting from nand ...; " \
- "run nandargs; " \
- "nand read ${loadaddr} 2a 80; " \
- "nand read ${fdtaddr} aa 8; " \
- "bootm ${loadaddr} - ${fdtaddr}\0" \
-
-/* Miscellaneous configurable options */
-
-/* memtest works on */
-/* FLASH and environment organization */
-
-/* PISMO SUPPORT *** */
- /* on one chip */
-
-#if defined(CONFIG_MTD_RAW_NAND)
#define CFG_SYS_FLASH_BASE NAND_BASE
-#endif
+#endif /* CONFIG_MTD_RAW_NAND */
#endif /* __CONFIG_H */
--
2.43.0
Re: [PATCH v1] tools: mkimage: Add support for i.MXRT FlexSPI Header
On Thu, Jan 25, 2024 at 2:10 PM Fabio Estevam wrote: > > Hi Adam, > > On Tue, Jan 23, 2024 at 11:15 PM Jesse Taube wrote: > > > > Modify imx8m Flex SPI Configuration Block to work with imxrt. > > Add more Flex SPI configuration options to Kconfig. > > > > Signed-off-by: Jesse Taube > > Could you please test it on imx8mn_beacon_fspi_defconfig ? Yes. I was planning on doing it this weekend. I'll try to get it done sooner and report back the results. adam
Re: [PATCH v1] tools: mkimage: Add support for i.MXRT FlexSPI Header
On Tue, Jan 23, 2024 at 8:15 PM Jesse Taube wrote:
>
> Modify imx8m Flex SPI Configuration Block to work with imxrt.
> Add more Flex SPI configuration options to Kconfig.
>
> Signed-off-by: Jesse Taube
I had to go back in time, because it appears the current version of
'master' doesn't fully boot the FSPI, but when I applied this patch
against a working version, it still worked when I was done. I'll try
to git bisect the issue when I have time, but for now:
Tested-by: Adam Ford #imx8mn-beacon
adam
> ---
> include/imximage.h | 42 +
> tools/Kconfig | 21 +
> tools/imx8mimage.c | 41
> tools/imximage.c | 77 ++
> 4 files changed, 143 insertions(+), 38 deletions(-)
>
> diff --git a/include/imximage.h b/include/imximage.h
> index c1ecc0b7cb..a951699d0a 100644
> --- a/include/imximage.h
> +++ b/include/imximage.h
> @@ -210,33 +210,37 @@ typedef struct {
> uint8_t datasetup;
> uint8_t coladdrwidth;
> uint8_t devcfgenable;
> - uint8_t reserved_2[3];
> + uint8_t deviceModeType;
> + uint16_t waitTimeCfgCommands;
> uint8_t devmodeseq[4];
> - uint8_t devmodearg[4];
> + uint32_t devmodearg;
> uint8_t cmd_enable;
> - uint8_t reserved_3[3];
> + uint8_t configModeType[3];
> uint8_t cmd_seq[16] ;
> uint8_t cmd_arg[16];
> - uint8_t controllermisc[4];
> + uint32_t controllermisc;
> uint8_t dev_type;
> uint8_t sflash_pad;
> uint8_t serial_clk;
> - uint8_t lut_custom ;
> - uint8_t reserved_4[8];
> - uint8_t sflashA1[4];
> - uint8_t sflashA2[4];
> - uint8_t sflashB1[4];
> - uint8_t sflashB2[4];
> - uint8_t cspadover[4];
> - uint8_t sclkpadover[4];
> - uint8_t datapadover[4];
> - uint8_t dqspadover[4];
> - uint8_t timeout[4];
> - uint8_t commandInt[4];
> - uint8_t datavalid[4];
> - uint8_t busyoffset[2];
> - uint8_t busybitpolarity[2];
> + uint8_t lut_custom;
> + uint8_t reserved_2[8];
> + uint32_t sflashA1;
> + uint32_t sflashA2;
> + uint32_t sflashB1;
> + uint32_t sflashB2;
> + uint32_t cspadover;
> + uint32_t sclkpadover;
> + uint32_t datapadover;
> + uint32_t dqspadover;
> + uint32_t timeout;
> + uint32_t commandInt;
> + uint16_t datavalid[2];
> + uint16_t busyoffset;
> + uint16_t busybitpolarity;
> uint8_t lut[256];
> + uint8_t lutCustomSeq[48];
> + uint8_t reserved_3[16];
> +
> } __attribute__((packed)) fspi_conf;
>
> typedef void (*set_dcd_val_t)(struct imx_header *imxhdr,
> diff --git a/tools/Kconfig b/tools/Kconfig
> index f01ed783e6..667807b331 100644
> --- a/tools/Kconfig
> +++ b/tools/Kconfig
> @@ -148,6 +148,27 @@ config SERIAL_CLK_FREQUENCY
> Chip specific frequency: other value 30MHz
> 1-30MHz 2-50MHz 3-60MHz 4-75MHz 5-80MHz 6-100MHz 7-133MHz 8-166MHz
>
> +config FSPI_COL_ADDR_W
> + hex "Column Address With"
> + default 0x00
> + depends on FSPI_CONF_HEADER
> + help
> + Default 0. For HyperBus protocol, it is fixed to 3
> +
> +config FSPI_CONTROLLER_MISC
> + hex "FSPI miscellaneous control"
> + default 0x
> + depends on FSPI_CONF_HEADER
> + help
> + Default 0. [0x40] Controller Misc Options
> +
> +config FSPI_FLASH_A1_SIZE
> + hex "Size in bytes of Flash A1"
> + default 0x1000
> + depends on FSPI_CONF_HEADER
> + help
> + Size of Flash connected to A1 in bytes
> +
> config LUT_CUSTOM_SEQUENCE
> hex "Enable Custom Look Up Table(LUT) Sequence"
> default 0x00
> diff --git a/tools/imx8mimage.c b/tools/imx8mimage.c
> index 21075c2379..939f829a9f 100644
> --- a/tools/imx8mimage.c
> +++ b/tools/imx8mimage.c
> @@ -426,36 +426,39 @@ static int generate_fspi_header (int ifd)
> .read_sample = CONFIG_READ_CLK_SOURCE,
> .datahold = 0x03,
> .datasetup = 0x03,
> - .coladdrwidth = 0x00,
> + .coladdrwidth = CONFIG_FSPI_COL_ADDR_W,
> .devcfgenable = 0x00,
> - .reserved_2 = {0x00, 0x00, 0x00},
> + .deviceModeType = 0x00,
> + .waitTimeCfgCommands = 0x,
> .devmodeseq = {0x00, 0x00, 0x00, 0x00},
> - .devmodearg = {0x00, 0x00, 0x00, 0x00},
> + .devmodearg = 0x,
> .cmd_enable = 0x00,
> - .reserved_3 = {0x
Re: [PATCH v1] tools: mkimage: Add support for i.MXRT FlexSPI Header
On Fri, Jan 26, 2024 at 1:11 PM Fabio Estevam wrote: > > Hi Adam, > > On Thu, Jan 25, 2024 at 7:37 PM Adam Ford wrote: > > > I had to go back in time, because it appears the current version of > > 'master' doesn't fully boot the FSPI, but when I applied this patch > > against a working version, it still worked when I was done. I'll try > > to git bisect the issue when I have time, but for now: > > > > Tested-by: Adam Ford #imx8mn-beacon > > Thanks for testing, appreciate it. I will queue this one. > No problem. Sorry it took so long. > Hopefully, we can figure out the cause of the regression. I must have done something wrong when I tested this before, because it's working fine for me now even when applied against the main trunk, so I think all is good. adam
[PATCH] arm64: imx: imx8mp-beacon: Add support for 4GB Variant
A new variant of the i.MX8MP System-on-module from Beacon is
available which contains 4GB of RAM vs 6GB. The memory
timings are slightly different, so a different config is necessary
to build the different timing file.
Signed-off-by: Adam Ford
diff --git a/board/beacon/imx8mp/Kconfig b/board/beacon/imx8mp/Kconfig
index 3c0fca9be8..3a673c749b 100644
--- a/board/beacon/imx8mp/Kconfig
+++ b/board/beacon/imx8mp/Kconfig
@@ -9,8 +9,13 @@ config SYS_VENDOR
config SYS_CONFIG_NAME
default "imx8mp_beacon"
+config IMX8MP_BEACON_4GB_LPDDR
+ bool "Enable 4GB LPDDR"
+ help
+ Enable this if the SOM has 4GB of RAM instead of
+ the default 6GB variant.
+
config IMX_CONFIG
default "board/freescale/imx8mp_evk/imximage-8mp-lpddr4.cfg"
-
endif
diff --git a/board/beacon/imx8mp/MAINTAINERS b/board/beacon/imx8mp/MAINTAINERS
index 3750551a4a..78afa3f6ae 100644
--- a/board/beacon/imx8mp/MAINTAINERS
+++ b/board/beacon/imx8mp/MAINTAINERS
@@ -4,3 +4,4 @@ S: Maintained
F: board/beacon/imx8mp/
F: include/configs/imx8mp_beacon.h
F: configs/imx8mp_beacon_defconfig
+F: configs/imx8mp_beacon_4g_defconfig
diff --git a/board/beacon/imx8mp/Makefile b/board/beacon/imx8mp/Makefile
index 264720f6d4..e7e2d316a3 100644
--- a/board/beacon/imx8mp/Makefile
+++ b/board/beacon/imx8mp/Makefile
@@ -9,5 +9,10 @@ obj-y += ../../freescale/common/
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
-obj-$(CONFIG_IMX8M_LPDDR4) += lpddr4_timing.o
+
+ifdef CONFIG_IMX8MP_BEACON_4GB_LPDDR
+obj-y += lpddr4_4g_timing.o
+else
+obj-y += lpddr4_timing.o
+endif
endif
diff --git a/board/beacon/imx8mp/lpddr4_4g_timing.c
b/board/beacon/imx8mp/lpddr4_4g_timing.c
new file mode 100644
index 00..51cef2c32b
--- /dev/null
+++ b/board/beacon/imx8mp/lpddr4_4g_timing.c
@@ -0,0 +1,1842 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright 2023 Logic PD, Inc dba Beacon EmbeddedWorks */
+
+#include
+#include
+
+struct dram_cfg_param ddr_ddrc_cfg[] = {
+ /** Initialize DDRC registers **/
+ { 0x3d400304, 0x1 },
+ { 0x3d400030, 0x1 },
+ { 0x3d40, 0xa3080020 },
+ { 0x3d400020, 0x1323 },
+ { 0x3d400024, 0x1e84800 },
+ { 0x3d400064, 0x7a0118 },
+ { 0x3d400070, 0x7027f90 },
+ { 0x3d400074, 0x790 },
+ { 0x3d4000d0, 0xc00307a3 },
+ { 0x3d4000d4, 0xc5 },
+ { 0x3d4000dc, 0xf4003f },
+ { 0x3d4000e0, 0x33 },
+ { 0x3d4000e8, 0x660048 },
+ { 0x3d4000ec, 0x160048 },
+ { 0x3d400100, 0x2028222a },
+ { 0x3d400104, 0x8083f },
+ { 0x3d40010c, 0xe0e000 },
+ { 0x3d400110, 0x12040a12 },
+ { 0x3d400114, 0x2050f0f },
+ { 0x3d400118, 0x1010009 },
+ { 0x3d40011c, 0x502 },
+ { 0x3d400130, 0x20800 },
+ { 0x3d400134, 0xe12 },
+ { 0x3d400138, 0x120 },
+ { 0x3d400144, 0xc80064 },
+ { 0x3d400180, 0x3e8001e },
+ { 0x3d400184, 0x3207a12 },
+ { 0x3d400188, 0x0 },
+ { 0x3d400190, 0x49f820e },
+ { 0x3d400194, 0x80303 },
+ { 0x3d4001b4, 0x1f0e },
+ { 0x3d4001a0, 0xe0400018 },
+ { 0x3d4001a4, 0xdf00e4 },
+ { 0x3d4001a8, 0x8000 },
+ { 0x3d4001b0, 0x11 },
+ { 0x3d4001c0, 0x1 },
+ { 0x3d4001c4, 0x1 },
+ { 0x3d4000f4, 0x799 },
+ { 0x3d400108, 0x9121b1c },
+ { 0x3d400200, 0x17 },
+ { 0x3d400208, 0x0 },
+ { 0x3d40020c, 0x0 },
+ { 0x3d400210, 0x1f1f },
+ { 0x3d400204, 0x80808 },
+ { 0x3d400214, 0x7070707 },
+ { 0x3d400218, 0x7070707 },
+ { 0x3d40021c, 0xf0f },
+ { 0x3d400250, 0x1705 },
+ { 0x3d400254, 0x2c },
+ { 0x3d40025c, 0x430 },
+ { 0x3d400264, 0x900093e7 },
+ { 0x3d40026c, 0x2005574 },
+ { 0x3d400400, 0x111 },
+ { 0x3d400404, 0x72ff },
+ { 0x3d400408, 0x72ff },
+ { 0x3d400494, 0x2100e07 },
+ { 0x3d400498, 0x620096 },
+ { 0x3d40049c, 0x1100e07 },
+ { 0x3d4004a0, 0xc8012c },
+ { 0x3d402020, 0x1021 },
+ { 0x3d402024, 0x30d400 },
+ { 0x3d402050, 0x20d000 },
+ { 0x3d402064, 0xc001c },
+ { 0x3d4020dc, 0x84 },
+ { 0x3d4020e0, 0x33 },
+ { 0x3d4020e8, 0x660048 },
+ { 0x3d4020ec, 0x160048 },
+ { 0x3d402100, 0xa040305 },
+ { 0x3d402104, 0x30407 },
+ { 0x3d402108, 0x203060b },
+ { 0x3d40210c, 0x505000 },
+ { 0x3d402110, 0x2040202 },
+ { 0x3d402114, 0x2030202 },
+ { 0x3d402118, 0x1010004 },
+ { 0x3d40211c, 0x302 },
+ { 0x3d402130, 0x20300 },
+ { 0x3d402134, 0xa12 },
+ { 0x3d402138, 0x1d },
+ { 0x3d402144, 0x14000a },
+ { 0x3d402180, 0x640004 },
+ { 0x3d402190, 0x3818200 },
+ { 0x3d402194, 0x80303 },
+ { 0x3d4021b4, 0x100 },
+ { 0x3d4020f4, 0x599 },
+ { 0x3d403020, 0x1021 },
+ { 0x3d403024, 0xc3500 },
+ { 0x3d403050, 0x20d000 },
+ { 0x3d403064, 0x30007 },
Re: [PATCH] arm64: imx: imx8mp-beacon: Add support for 4GB Variant
On Fri, Nov 17, 2023 at 8:41 AM Tom Rini wrote: > > On Thu, Nov 16, 2023 at 07:31:53PM -0600, Adam Ford wrote: > > > A new variant of the i.MX8MP System-on-module from Beacon is > > available which contains 4GB of RAM vs 6GB. The memory > > timings are slightly different, so a different config is necessary > > to build the different timing file. > > > > Signed-off-by: Adam Ford > > Might this be a case for using config fragments instead? I didn't realize U-Boot was supporting that. I'll submit a V2 with the defconfig option removed. Is there an example you can direct me to that does this already? thanks! adam > See doc/develop/board_best_practices.rst > > -- > Tom
Re: [PATCH 023/149] board: beacon: Remove and add needed includes
On Tue, Apr 30, 2024 at 9:43 PM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini Acked-by: Adam Ford > --- > Cc: Adam Ford > --- > board/beacon/beacon-rzg2m/beacon-rzg2m.c | 1 - > board/beacon/imx8mm/lpddr4_timing.c | 1 - > board/beacon/imx8mm/spl.c| 1 - > board/beacon/imx8mn/spl.c| 1 - > board/beacon/imx8mp/imx8mp_beacon.c | 1 - > board/beacon/imx8mp/spl.c| 1 - > 6 files changed, 6 deletions(-) > > diff --git a/board/beacon/beacon-rzg2m/beacon-rzg2m.c > b/board/beacon/beacon-rzg2m/beacon-rzg2m.c > index 99fe1edfb330..099053235ded 100644 > --- a/board/beacon/beacon-rzg2m/beacon-rzg2m.c > +++ b/board/beacon/beacon-rzg2m/beacon-rzg2m.c > @@ -3,7 +3,6 @@ > * Copyright 2020 Compass Electronics Group, LLC > */ > > -#include > #include > #include > > diff --git a/board/beacon/imx8mm/lpddr4_timing.c > b/board/beacon/imx8mm/lpddr4_timing.c > index 8e48b9d81b77..c1498dd5eaf4 100644 > --- a/board/beacon/imx8mm/lpddr4_timing.c > +++ b/board/beacon/imx8mm/lpddr4_timing.c > @@ -4,7 +4,6 @@ > */ > > #include > -#include > #include > #include > > diff --git a/board/beacon/imx8mm/spl.c b/board/beacon/imx8mm/spl.c > index 1632238bf5dd..12013aa5a4da 100644 > --- a/board/beacon/imx8mm/spl.c > +++ b/board/beacon/imx8mm/spl.c > @@ -1,6 +1,5 @@ > // SPDX-License-Identifier: GPL-2.0+ > > -#include > #include > #include > #include > diff --git a/board/beacon/imx8mn/spl.c b/board/beacon/imx8mn/spl.c > index b4d46f11f98d..f03841e5a01d 100644 > --- a/board/beacon/imx8mn/spl.c > +++ b/board/beacon/imx8mn/spl.c > @@ -3,7 +3,6 @@ > * Copyright 2020 Compass Electronics Group, LLC > */ > > -#include > #include > #include > #include > diff --git a/board/beacon/imx8mp/imx8mp_beacon.c > b/board/beacon/imx8mp/imx8mp_beacon.c > index 8963a51fbba0..dd74e7c0f755 100644 > --- a/board/beacon/imx8mp/imx8mp_beacon.c > +++ b/board/beacon/imx8mp/imx8mp_beacon.c > @@ -1,7 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0+ > /* Copyright 2023 Logic PD, Inc dba Beacon EmbeddedWorks */ > > -#include > #include > #include > #include > diff --git a/board/beacon/imx8mp/spl.c b/board/beacon/imx8mp/spl.c > index 591e8ca9ab5b..30d577f7e0e3 100644 > --- a/board/beacon/imx8mp/spl.c > +++ b/board/beacon/imx8mp/spl.c > @@ -4,7 +4,6 @@ > * > */ > > -#include > #include > #include > #include > -- > 2.34.1 >
Re: [PATCH 048/149] board: davinci: Remove and add needed includes
On Tue, Apr 30, 2024 at 9:44 PM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini Acked-by: Adam Ford > --- > Cc: Adam Ford > --- > board/davinci/da8xxevm/da850evm.c | 2 +- > board/davinci/da8xxevm/omapl138_lcdk.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/board/davinci/da8xxevm/da850evm.c > b/board/davinci/da8xxevm/da850evm.c > index 05053a87a5a9..0011c8285237 100644 > --- a/board/davinci/da8xxevm/da850evm.c > +++ b/board/davinci/da8xxevm/da850evm.c > @@ -8,7 +8,7 @@ > * Copyright (C) 2007 Sergey Kubushyn > */ > > -#include > +#include > #include > #include > #include > diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c > b/board/davinci/da8xxevm/omapl138_lcdk.c > index 9738e2bd9c77..607e05ad9ae4 100644 > --- a/board/davinci/da8xxevm/omapl138_lcdk.c > +++ b/board/davinci/da8xxevm/omapl138_lcdk.c > @@ -8,7 +8,7 @@ > * Copyright (C) 2007 Sergey Kubushyn > */ > > -#include > +#include > #include > #include > #include > -- > 2.34.1 >
Re: [PATCH 086/149] board: logicpd: Remove and add needed includes
On Tue, Apr 30, 2024 at 9:44 PM Tom Rini wrote: > > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini Acked-by: Adam Ford > --- > Cc: Adam Ford > --- > board/logicpd/am3517evm/am3517evm.c | 1 - > board/logicpd/imx6/imx6logic.c | 1 - > board/logicpd/omap3som/omap3logic.c | 2 +- > 3 files changed, 1 insertion(+), 3 deletions(-) > > diff --git a/board/logicpd/am3517evm/am3517evm.c > b/board/logicpd/am3517evm/am3517evm.c > index e69a73f2af6f..e6ca31016b7c 100644 > --- a/board/logicpd/am3517evm/am3517evm.c > +++ b/board/logicpd/am3517evm/am3517evm.c > @@ -10,7 +10,6 @@ > * Texas Instruments Incorporated - https://www.ti.com/ > */ > > -#include > #include > #include > #include > diff --git a/board/logicpd/imx6/imx6logic.c b/board/logicpd/imx6/imx6logic.c > index 0d53548dcb4b..589136fd64aa 100644 > --- a/board/logicpd/imx6/imx6logic.c > +++ b/board/logicpd/imx6/imx6logic.c > @@ -8,7 +8,6 @@ > * and updates by Jagan Teki > */ > > -#include > #include > #include > #include > diff --git a/board/logicpd/omap3som/omap3logic.c > b/board/logicpd/omap3som/omap3logic.c > index 86992829caf4..a9fe61918b6a 100644 > --- a/board/logicpd/omap3som/omap3logic.c > +++ b/board/logicpd/omap3som/omap3logic.c > @@ -10,7 +10,7 @@ > * Richard Woodruff > * Syed Mohammed Khasim > */ > -#include > +#include > #include > #include > #include > -- > 2.34.1 >
[PATCH V2 1/4] arm: davinci: Migrate da850-evm to OF_UPSTREAM
The da850-evm can remove the U-Boot device trees if migrated
to OF_UPSTREAM. This means pointing the device trees to the
ti/davinci directory.
Signed-off-by: Adam Ford
---
v2: Remove DTS from Makefile.
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c9f1b25ad6..d6135c41ad 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -41,7 +41,6 @@ dtb-$(CONFIG_ARCH_APPLE) += \
t8103-j457.dtb
dtb-$(CONFIG_ARCH_DAVINCI) += \
- da850-evm.dtb \
da850-lcdk.dtb \
da850-lego-ev3.dtb
diff --git a/arch/arm/dts/da850-evm.dts b/arch/arm/dts/da850-evm.dts
deleted file mode 100644
index 378af9f344..00
--- a/arch/arm/dts/da850-evm.dts
+++ /dev/null
@@ -1,453 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Device Tree for DA850 EVM board
- *
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-/dts-v1/;
-#include "da850.dtsi"
-#include
-
-/ {
- compatible = "ti,da850-evm", "ti,da850";
- model = "DA850/AM1808/OMAP-L138 EVM";
-
- chosen {
- stdout-path = &serial2;
- };
-
- aliases {
- serial0 = &serial0;
- serial1 = &serial1;
- serial2 = &serial2;
- ethernet0 = ð0;
- spi0 = &spi1;
- };
-
- backlight: backlight-pwm {
- pinctrl-names = "default";
- pinctrl-0 = <&ecap2_pins>;
- power-supply = <&backlight_lcd>;
- compatible = "pwm-backlight";
- /*
-* The PWM here corresponds to production hardware. The
-* schematic needs to be 1015171 (15 March 2010), Rev A
-* or newer.
-*/
- pwms = <&ecap2 0 5 0>;
- brightness-levels = <0 10 20 30 40 50 60 70 80 90 99>;
- default-brightness-level = <7>;
- };
-
- panel {
- compatible = "ti,tilcdc,panel";
- pinctrl-names = "default";
- pinctrl-0 = <&lcd_pins>;
- /*
-* The vpif and the LCD are mutually exclusive.
-* To enable VPIF, change the status below to 'disabled' then
-* then change the status of the vpif below to 'okay'
-*/
- status = "okay";
- enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>; /* lcd_panel_pwr */
-
- panel-info {
- ac-bias = <255>;
- ac-bias-intrpt = <0>;
- dma-burst-sz = <16>;
- bpp = <16>;
- fdd = <0x80>;
- sync-edge = <0>;
- sync-ctrl = <1>;
- raster-order = <0>;
- fifo-th = <0>;
- };
-
- display-timings {
- native-mode = <&timing0>;
- timing0: 480x272 {
- clock-frequency = <900>;
- hactive = <480>;
- vactive = <272>;
- hfront-porch = <3>;
- hback-porch = <2>;
- hsync-len = <42>;
- vback-porch = <3>;
- vfront-porch = <4>;
- vsync-len = <11>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <1>;
- };
- };
- };
-
- vbat: fixedregulator0 {
- compatible = "regulator-fixed";
- regulator-name = "vbat";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- regulator-boot-on;
- };
-
- baseboard_3v3: fixedregulator-3v3 {
- /* TPS73701DCQ */
- compatible = "regulator-fixed";
- regulator-name = "baseboard_3v3";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- vin-supply = <&vbat>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- baseboard_1v8: fixedregulator-1v8 {
- /* TPS73701DCQ */
- compatible = "regulator-fixed";
- regulator-name = "baseboard_1v8"
[PATCH V2 2/4] arm: ti: am3517_evm: Migrate to OF_UPSTREAM
With the feature of OF_UPSTREAM now available, the device trees
for the SOM and baseboard can now deleted and the device tree
locations need to point to the ti/omap directory.
Signed-off-by: Adam Ford
---
V2: Remove DT reference from Makefile.
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d6135c41ad..f9b582a87e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -482,7 +482,6 @@ dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb am437x-sk-evm.dtb
\
am437x-idk-evm.dtb \
am4372-generic.dtb \
am437x-cm-t43.dtb
-dtb-$(CONFIG_TARGET_AM3517_EVM) += am3517-evm.dtb
dtb-$(CONFIG_TARGET_THUNDERX_88XX) += thunderx-88xx.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += \
diff --git a/arch/arm/dts/am3517-evm.dts b/arch/arm/dts/am3517-evm.dts
deleted file mode 100644
index d21bb2ccd0..00
--- a/arch/arm/dts/am3517-evm.dts
+++ /dev/null
@@ -1,339 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2011 Texas Instruments Incorporated - https://www.ti.com/
- */
-/dts-v1/;
-
-#include "am3517.dtsi"
-#include "am3517-som.dtsi"
-#include "am3517-evm-ui.dtsi"
-#include
-
-/ {
- model = "TI AM3517 EVM (AM3517/05 TMDSEVM3517)";
- compatible = "ti,am3517-evm", "ti,am3517", "ti,omap3";
-
- aliases {
- display0 = &lcd0;
- };
-
- chosen {
- stdout-path = &uart3;
- };
-
- memory@8000 {
- device_type = "memory";
- reg = <0x8000 0x1000>; /* 256 MB */
- };
-
- vmmc_fixed: vmmc {
- compatible = "regulator-fixed";
- regulator-name = "vmmc_fixed";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
-
- gpio-keys {
- compatible = "gpio-keys-polled";
- poll-interval = <100>;
-
- button-user {
- label = "User Push Button";
- linux,code = ;
- gpios = <&tca6416 5 GPIO_ACTIVE_LOW>;
- };
-
- switch-1 {
- label = "User Switch 1";
- linux,code = ;
- gpios = <&tca6416 8 GPIO_ACTIVE_LOW>;
- };
-
- switch-2 {
- label = "User Switch 2";
- linux,code = ;
- gpios = <&tca6416 9 GPIO_ACTIVE_LOW>;
- };
-
- switch-3 {
- label = "User Switch 3";
- linux,code = ;
- gpios = <&tca6416 10 GPIO_ACTIVE_LOW>;
- };
-
- switch-4 {
- label = "User Switch 4";
- linux,code = ;
- gpios = <&tca6416 11 GPIO_ACTIVE_LOW>;
- };
-
- switch-5 {
- label = "User Switch 5";
- linux,code = ;
- gpios = <&tca6416 12 GPIO_ACTIVE_LOW>;
- };
-
- switch-6 {
- label = "User Switch 6";
- linux,code = ;
- gpios = <&tca6416 13 GPIO_ACTIVE_LOW>;
- };
-
- switch-7 {
- label = "User Switch 7";
- linux,code = ;
- gpios = <&tca6416 14 GPIO_ACTIVE_LOW>;
- };
-
- switch-8 {
- label = "User Switch 8";
- linux,code = ;
- gpios = <&tca6416 15 GPIO_ACTIVE_LOW>;
- };
- };
-
- gpio-leds {
- compatible = "gpio-leds";
-
- pinctrl-names = "default";
- pinctrl-0 = <&leds_pins>;
-
- user_led_1 {
- label = "am3517evm:green:user_led_1";
- gpios = <&tca6416 7 GPIO_ACTIVE_LOW>;
- default-state = "on";
- };
-
- user_led_2 {
- label = "am3517evm:green:user_led_2";
- gpios = <&tca6416 6 GPIO_ACTIVE_LOW>;
- default-state = "on";
- };
-
- user_led_3 {
- label = "am3517evm:green:user_led_3";
- gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "mmc0"; /* SD/MMC card activity
*/
[PATCH V2 3/4] arm: ti: logicpd-torpedo: Migrate to OF_UPSTREAM
The DM37 and OMAP35 Torpedo share a few files, but both of them
can be migrated to OF_UPSTREAM with a small update to their
respective u-boot.dtsi files to address changes made the aliases.
Both defconfigs need to properly point to the upstream directory
structure for the device trees. With those updated, the U-Boot
device tree files can be deleted.
Signed-off-by: Adam Ford
---
V2: Remove DT from Makefile
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f9b582a87e..b163ae18fc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1143,9 +1143,7 @@ dtb-$(CONFIG_TARGET_USB_A9263) += usb_a9263.dtb
dtb-$(CONFIG_TARGET_OMAP3_LOGIC) += \
logicpd-som-lv-35xx-devkit.dtb \
- logicpd-som-lv-37xx-devkit.dtb \
- logicpd-torpedo-35xx-devkit.dtb \
- logicpd-torpedo-37xx-devkit.dtb
+ logicpd-som-lv-37xx-devkit.dtb
dtb-$(CONFIG_TARGET_OMAP3_EVM) += \
omap3-evm-37xx.dtb \
diff --git a/arch/arm/dts/logicpd-torpedo-35xx-devkit-u-boot.dtsi
b/arch/arm/dts/logicpd-torpedo-35xx-devkit-u-boot.dtsi
index 4744872f7c..d14d68e458 100644
--- a/arch/arm/dts/logicpd-torpedo-35xx-devkit-u-boot.dtsi
+++ b/arch/arm/dts/logicpd-torpedo-35xx-devkit-u-boot.dtsi
@@ -14,6 +14,8 @@
aliases {
/delete-property/ serial1;
/delete-property/ serial2;
+ /delete-property/ mmc1;
+ /delete-property/ mmc2;
};
ethernet@0800 {
diff --git a/arch/arm/dts/logicpd-torpedo-35xx-devkit.dts
b/arch/arm/dts/logicpd-torpedo-35xx-devkit.dts
deleted file mode 100644
index cb08aa62d9..00
--- a/arch/arm/dts/logicpd-torpedo-35xx-devkit.dts
+++ /dev/null
@@ -1,21 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-
-/dts-v1/;
-
-#include "omap34xx.dtsi"
-#include "logicpd-torpedo-som.dtsi"
-#include "logicpd-torpedo-baseboard.dtsi"
-#include "omap-gpmc-smsc9221.dtsi"
-
-/ {
- model = "LogicPD Zoom OMAP35xx Torpedo Development Kit";
- compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3430", "ti,omap3";
-};
-
-&omap3_pmx_core {
- isp1763_pins: pinmux_isp1763_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2154, PIN_INPUT_PULLUP |
MUX_MODE4)/* sdmmc1_dat6.gpio_128 */
- >;
- };
-};
diff --git a/arch/arm/dts/logicpd-torpedo-37xx-devkit-u-boot.dtsi
b/arch/arm/dts/logicpd-torpedo-37xx-devkit-u-boot.dtsi
index 2c34344504..8e8e2e4096 100644
--- a/arch/arm/dts/logicpd-torpedo-37xx-devkit-u-boot.dtsi
+++ b/arch/arm/dts/logicpd-torpedo-37xx-devkit-u-boot.dtsi
@@ -10,6 +10,8 @@
aliases {
/delete-property/ serial1;
/delete-property/ serial2;
+ /delete-property/ mmc1;
+ /delete-property/ mmc2;
};
ethernet@0800 {
diff --git a/arch/arm/dts/logicpd-torpedo-37xx-devkit.dts
b/arch/arm/dts/logicpd-torpedo-37xx-devkit.dts
deleted file mode 100644
index 07ea822fe4..00
--- a/arch/arm/dts/logicpd-torpedo-37xx-devkit.dts
+++ /dev/null
@@ -1,96 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-
-/dts-v1/;
-
-#include "omap36xx.dtsi"
-#include "logicpd-torpedo-som.dtsi"
-#include "omap-gpmc-smsc9221.dtsi"
-#include "logicpd-torpedo-baseboard.dtsi"
-
-/ {
- model = "LogicPD Zoom DM3730 Torpedo + Wireless Development Kit";
- compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3";
-
- wl12xx_vmmc: wl12xx_vmmc {
- compatible = "regulator-fixed";
- regulator-name = "vwl1271";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- gpio = <&gpio5 29 0>; /* gpio157 */
- startup-delay-us = <7>;
- enable-active-high;
- vin-supply = <&vmmc2>;
- };
-};
-
-/*
- * Only found on the wireless SOM. For the SOM without wireless, the pins for
- * MMC3 can be routed with jumpers to the second MMC slot on the devkit and
- * gpio157 is not connected. So this should be OK to keep common for now,
- * probably device tree overlays is the way to go with the various SOM and
- * jumpering combinations for the long run.
- */
-&mmc3 {
- interrupts-extended = <&intc 94 &omap3_pmx_core 0x136>;
- pinctrl-0 = <&mmc3_pins &mmc3_core2_pins>;
- pinctrl-names = "default";
- vmmc-supply = <&wl12xx_vmmc>;
- non-removable;
- bus-width = <4>;
- cap-power-off-card;
- #address-cells = <1>;
- #size-cells = <0>;
- wlcore: wlcore@2 {
- compatible = "ti,wl1283";
- reg = <2>;
- interrupt-pa
[PATCH V2 4/4] arm: ti: logicpd-som-lv: Migrate to OF_UPSTREAM
The DM37 and OMAP35 SOM-LV share a few files, but both of them
can be migrated to OF_UPSTREAM with a small update to their
respective u-boot.dtsi files to address changes made the aliases.
Both defconfigs need to properly point to the upstream directory
structure for the device trees. With those updated, the U-Boot
device tree files can be deleted.
Signed-off-by: Adam Ford
---
V2: Remove DT from Makefile
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b163ae18fc..a4c2ef2aaa 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1141,10 +1141,6 @@ dtb-$(CONFIG_TARGET_ETHERNUT5) += ethernut5.dtb
dtb-$(CONFIG_TARGET_USB_A9263) += usb_a9263.dtb
-dtb-$(CONFIG_TARGET_OMAP3_LOGIC) += \
- logicpd-som-lv-35xx-devkit.dtb \
- logicpd-som-lv-37xx-devkit.dtb
-
dtb-$(CONFIG_TARGET_OMAP3_EVM) += \
omap3-evm-37xx.dtb \
omap3-evm.dtb
diff --git a/arch/arm/dts/logicpd-som-lv-35xx-devkit-u-boot.dtsi
b/arch/arm/dts/logicpd-som-lv-35xx-devkit-u-boot.dtsi
index 6f11852a33..d77fa38746 100644
--- a/arch/arm/dts/logicpd-som-lv-35xx-devkit-u-boot.dtsi
+++ b/arch/arm/dts/logicpd-som-lv-35xx-devkit-u-boot.dtsi
@@ -14,6 +14,8 @@
aliases {
/delete-property/ serial1;
/delete-property/ serial2;
+ /delete-property/ mmc1;
+ /delete-property/ mmc2;
};
ethernet@0800 {
diff --git a/arch/arm/dts/logicpd-som-lv-35xx-devkit.dts
b/arch/arm/dts/logicpd-som-lv-35xx-devkit.dts
deleted file mode 100644
index f690bc83bf..00
--- a/arch/arm/dts/logicpd-som-lv-35xx-devkit.dts
+++ /dev/null
@@ -1,27 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-
-/dts-v1/;
-
-#include "omap34xx.dtsi"
-#include "logicpd-som-lv.dtsi"
-#include "logicpd-som-lv-baseboard.dtsi"
-#include "omap-gpmc-smsc9221.dtsi"
-
-/ {
- model = "LogicPD Zoom OMAP35xx SOM-LV Development Kit";
- compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3430", "ti,omap3";
-};
-
-&omap3_pmx_core2 {
-
- hsusb2_2_pins: pinmux_hsusb2_2_pins {
- pinctrl-single,pins = <
- OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
- OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
- OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
- OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
- OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
- OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
- >;
- };
-};
diff --git a/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
b/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
index 6f11852a33..d77fa38746 100644
--- a/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
+++ b/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
@@ -14,6 +14,8 @@
aliases {
/delete-property/ serial1;
/delete-property/ serial2;
+ /delete-property/ mmc1;
+ /delete-property/ mmc2;
};
ethernet@0800 {
diff --git a/arch/arm/dts/logicpd-som-lv-37xx-devkit.dts
b/arch/arm/dts/logicpd-som-lv-37xx-devkit.dts
deleted file mode 100644
index e28e9625be..00
--- a/arch/arm/dts/logicpd-som-lv-37xx-devkit.dts
+++ /dev/null
@@ -1,27 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-
-/dts-v1/;
-
-#include "omap36xx.dtsi"
-#include "logicpd-som-lv.dtsi"
-#include "logicpd-som-lv-baseboard.dtsi"
-#include "omap-gpmc-smsc9221.dtsi"
-
-/ {
- model = "LogicPD Zoom DM3730 SOM-LV Development Kit";
- compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap3";
-};
-
-&omap3_pmx_core2 {
-
- hsusb2_2_pins: pinmux_hsusb2_2_pins {
- pinctrl-single,pins = <
- OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
- OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
- OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
- OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
- OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
- OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
- >;
- };
-};
diff --git a/arch/arm/dts/logicpd-som-lv-baseboard.dt
Re: [PATCH] ARM: dts: renesas: Remove leftovers after OF_UPSTREAM conversion
On Sun, May 19, 2024 at 3:40 PM Marek Vasut
wrote:
>
> Remove leftover DTSI files after OF_UPSTREAM conversion.
> Those are no longer used and no longer necessary, remove them.
> No functional change.
>
This seems like the right thing to do.
> Signed-off-by: Marek Vasut
Acked-by: Adam Ford
> ---
> Cc: Adam Ford
> Cc: Tom Rini
> ---
> arch/arm/dts/salvator-common.dtsi| 1104 --
> arch/arm/dts/salvator-x.dtsi | 29 -
> arch/arm/dts/salvator-xs.dtsi| 85 --
> arch/arm/dts/ulcb-audio-graph-card.dtsi | 85 --
> arch/arm/dts/ulcb-audio-graph-card2.dtsi | 26 -
> arch/arm/dts/ulcb.dtsi | 509 --
> 6 files changed, 1838 deletions(-)
> delete mode 100644 arch/arm/dts/salvator-common.dtsi
> delete mode 100644 arch/arm/dts/salvator-x.dtsi
> delete mode 100644 arch/arm/dts/salvator-xs.dtsi
> delete mode 100644 arch/arm/dts/ulcb-audio-graph-card.dtsi
> delete mode 100644 arch/arm/dts/ulcb-audio-graph-card2.dtsi
> delete mode 100644 arch/arm/dts/ulcb.dtsi
>
> diff --git a/arch/arm/dts/salvator-common.dtsi
> b/arch/arm/dts/salvator-common.dtsi
> deleted file mode 100644
> index 4a3d5037821..000
> --- a/arch/arm/dts/salvator-common.dtsi
> +++ /dev/null
> @@ -1,1104 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * Device Tree Source for common parts of Salvator-X board variants
> - *
> - * Copyright (C) 2015-2016 Renesas Electronics Corp.
> - */
> -
> -/*
> - * SSI-AK4613
> - *
> - * This command is required when Playback/Capture
> - *
> - * amixer set "DVC Out" 100%
> - * amixer set "DVC In" 100%
> - *
> - * You can use Mute
> - *
> - * amixer set "DVC Out Mute" on
> - * amixer set "DVC In Mute" on
> - *
> - * You can use Volume Ramp
> - *
> - * amixer set "DVC Out Ramp Up Rate" "0.125 dB/64 steps"
> - * amixer set "DVC Out Ramp Down Rate" "0.125 dB/512 steps"
> - * amixer set "DVC Out Ramp" on
> - * aplay xxx.wav &
> - * amixer set "DVC Out" 80% // Volume Down
> - * amixer set "DVC Out" 100% // Volume Up
> - */
> -
> -#include
> -#include
> -
> -/ {
> - aliases {
> - i2c0 = &i2c0;
> - i2c1 = &i2c1;
> - i2c2 = &i2c2;
> - i2c3 = &i2c3;
> - i2c4 = &i2c4;
> - i2c5 = &i2c5;
> - i2c6 = &i2c6;
> - i2c7 = &i2c_dvfs;
> - serial0 = &scif2;
> - serial1 = &hscif1;
> - ethernet0 = &avb;
> - mmc0 = &sdhi2;
> - mmc1 = &sdhi0;
> - mmc2 = &sdhi3;
> - };
> -
> - chosen {
> - bootargs = "ignore_loglevel rw root=/dev/nfs ip=on";
> - stdout-path = "serial0:115200n8";
> - };
> -
> - audio_clkout: audio-clkout {
> - /*
> -* This is same as <&rcar_sound 0>
> -* but needed to avoid cs2000/rcar_sound probe dead-lock
> -*/
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <12288000>;
> - };
> -
> - backlight: backlight {
> - compatible = "pwm-backlight";
> - pwms = <&pwm1 0 5>;
> -
> - brightness-levels = <256 128 64 16 8 4 0>;
> - default-brightness-level = <6>;
> -
> - power-supply = <®_12v>;
> - enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
> - };
> -
> - cvbs-in {
> - compatible = "composite-video-connector";
> - label = "CVBS IN";
> -
> - port {
> - cvbs_con: endpoint {
> - remote-endpoint = <&adv7482_ain7>;
> - };
> - };
> - };
> -
> - hdmi-in {
> - compatible = "hdmi-connector";
> - label = "HDMI IN";
> - type = "a";
> -
> - port {
> - hdmi_in_con: endpoint {
> - remote-endpoint = <&adv7482_hdmi>;
> - };
> - };
> - };
> -
> - hdmi0-out {
> - compatible = &
[PATCH 1/3] arm64: imx: imx8mp-beacon: Migrate to OF_UPSTREAM
The imx8mp-beacon boards can migrate to OF_UPSTREAM which also
allows for the removal the device tree files.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d85a33055c..04ffa1f165 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1095,7 +1095,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-beacon-kit.dtb \
imx8mq-mnt-reform2.dtb \
imx8mq-phanbell.dtb \
- imx8mp-beacon-kit.dtb \
imx8mp-data-modul-edm-sbc.dtb \
imx8mp-dhcom-som-overlay-rev100.dtbo \
imx8mp-dhcom-som-overlay-eth1xfast.dtbo \
diff --git a/arch/arm/dts/imx8mp-beacon-kit.dts
b/arch/arm/dts/imx8mp-beacon-kit.dts
deleted file mode 100644
index a08057410b..00
--- a/arch/arm/dts/imx8mp-beacon-kit.dts
+++ /dev/null
@@ -1,783 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright 2023 Logic PD, Inc dba Beacon EmbeddedWorks
- */
-
-/dts-v1/;
-
-#include
-#include
-#include "imx8mp.dtsi"
-#include "imx8mp-beacon-som.dtsi"
-
-/ {
- model = "Beacon EmbeddedWorks i.MX8MPlus Development kit";
- compatible = "beacon,imx8mp-beacon-kit", "fsl,imx8mp";
-
- aliases {
- ethernet0 = &eqos;
- ethernet1 = &fec;
- };
-
- chosen {
- stdout-path = &uart2;
- };
-
- clk_xtal25: clock-xtal25 {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <2500>;
- };
-
- connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- data-role = "dual";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- hs_ep: endpoint {
- remote-endpoint = <&usb3_hs_ep>;
- };
- };
- port@1 {
- reg = <1>;
-
- ss_ep: endpoint {
- remote-endpoint = <&hd3ss3220_in_ep>;
- };
- };
- };
- };
-
- dmic_codec: dmic-codec {
- compatible = "dmic-codec";
- num-channels = <1>;
- #sound-dai-cells = <0>;
- };
-
- gpio-keys {
- compatible = "gpio-keys";
- autorepeat;
-
- button-0 {
- label = "btn0";
- linux,code = ;
- gpios = <&pca6416_1 12 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- wakeup-source;
- };
-
- button-1 {
- label = "btn1";
- linux,code = ;
- gpios = <&pca6416_1 13 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- wakeup-source;
- };
-
- button-2 {
- label = "btn2";
- linux,code = ;
- gpios = <&pca6416_1 14 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- wakeup-source;
- };
-
- button-3 {
- label = "btn3";
- linux,code = ;
- gpios = <&pca6416_1 15 (GPIO_ACTIVE_LOW |
GPIO_PULL_UP)>;
- wakeup-source;
- };
- };
-
- bridge-connector {
- compatible = "hdmi-connector";
- type = "a";
-
- port {
- hdmi_con: endpoint {
- remote-endpoint = <&adv7535_out>;
- };
- };
- };
-
- leds {
- compatible = "gpio-leds";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_led3>;
-
- led-0 {
- label = "gen_led0";
- gpios = <&pca6416_1 4 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
-
- led-1 {
- label = "gen_led1";
- gpios = <&pca6416_1 5 GPIO_ACTIVE_HIGH>;
- default-state = "off";
- };
-
- led-2 {
- label = "gen_led2";
- gpios = <&pca6416_1 6 GPIO_ACTIVE_HIGH>;
-
[PATCH 2/3] arm64: imx: imx8mm-beacon: Migrate to OF_UPSTREAM
The imx8mm-beacon boards can migrate to OF_UPSTREAM which also
allows for the removal the device tree files.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 04ffa1f165..443d651827 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1091,7 +1091,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-evk.dtb \
imx8mn-var-som-symphony.dtb \
imx8mq-evk.dtb \
- imx8mm-beacon-kit.dtb \
imx8mn-beacon-kit.dtb \
imx8mq-mnt-reform2.dtb \
imx8mq-phanbell.dtb \
diff --git a/arch/arm/dts/imx8mm-beacon-kit.dts
b/arch/arm/dts/imx8mm-beacon-kit.dts
deleted file mode 100644
index 74a7b0cc10..00
--- a/arch/arm/dts/imx8mm-beacon-kit.dts
+++ /dev/null
@@ -1,19 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MIT)
-/*
- * Copyright 2020 Compass Electronics Group, LLC
- */
-
-/dts-v1/;
-
-#include "imx8mm.dtsi"
-#include "imx8mm-beacon-som.dtsi"
-#include "imx8mm-beacon-baseboard.dtsi"
-
-/ {
- model = "Beacon EmbeddedWorks i.MX8M Mini Development Kit";
- compatible = "beacon,imx8mm-beacon-kit", "fsl,imx8mm";
-
- chosen {
- stdout-path = &uart2;
- };
-};
diff --git a/arch/arm/dts/imx8mm-beacon-som.dtsi
b/arch/arm/dts/imx8mm-beacon-som.dtsi
deleted file mode 100644
index cf07987ccc..00
--- a/arch/arm/dts/imx8mm-beacon-som.dtsi
+++ /dev/null
@@ -1,461 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MIT)
-/*
- * Copyright 2020 Compass Electronics Group, LLC
- */
-
-/ {
- aliases {
- rtc0 = &rtc;
- rtc1 = &snvs_rtc;
- };
-
- usdhc1_pwrseq: usdhc1_pwrseq {
- compatible = "mmc-pwrseq-simple";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usdhc1_gpio>;
- reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
- clocks = <&osc_32k>;
- clock-names = "ext_clock";
- post-power-on-delay-ms = <80>;
- };
-
- memory@4000 {
- device_type = "memory";
- reg = <0x0 0x4000 0 0x8000>;
- };
-};
-
-&A53_0 {
- cpu-supply = <&buck2_reg>;
-};
-
-&A53_1 {
- cpu-supply = <&buck2_reg>;
-};
-
-&A53_2 {
- cpu-supply = <&buck2_reg>;
-};
-
-&A53_3 {
- 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>;
- phy-mode = "rgmii-id";
- phy-handle = <ðphy0>;
- fsl,magic-packet;
- status = "okay";
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ethphy0: ethernet-phy@0 {
- compatible = "ethernet-phy-ieee802.3-c22";
- reg = <0>;
- };
- };
-};
-
-&flexspi {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_flexspi>;
- status = "okay";
-
- flash@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "jedec,spi-nor";
- spi-max-frequency = <8000>;
- spi-tx-bus-width = <1>;
- spi-rx-bus-width = <4>;
- };
-};
-
-&i2c1 {
- clock-frequency = <40>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c1>;
- status = "okay";
-
- pmic@4b {
- compatible = "rohm,bd71847";
- reg = <0x4b>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pmic>;
- interrupt-parent = <&gpio1>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
- rohm,reset-snvs-powered;
-
- #clock-cells = <0>;
- clocks = <&osc_32k 0>;
- clock-output-names = "clk-32k-out";
-
- regulators {
- buck1_reg: BUCK1 {
- regulator-name = "buck1";
-
[PATCH 3/3] arm64: imx: imx8mn-beacon: Migrate to OF_UPSTREAM
The imx8mn-beacon boards can migrate to OF_UPSTREAM which also
allows for the removal the device tree files.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 443d651827..6ddd6e311e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1091,7 +1091,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-evk.dtb \
imx8mn-var-som-symphony.dtb \
imx8mq-evk.dtb \
- imx8mn-beacon-kit.dtb \
imx8mq-mnt-reform2.dtb \
imx8mq-phanbell.dtb \
imx8mp-data-modul-edm-sbc.dtb \
diff --git a/arch/arm/dts/imx8mn-beacon-kit.dts
b/arch/arm/dts/imx8mn-beacon-kit.dts
deleted file mode 100644
index 1392ce0258..00
--- a/arch/arm/dts/imx8mn-beacon-kit.dts
+++ /dev/null
@@ -1,19 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MIT)
-/*
- * Copyright 2020 Compass Electronics Group, LLC
- */
-
-/dts-v1/;
-
-#include "imx8mn.dtsi"
-#include "imx8mn-beacon-som.dtsi"
-#include "imx8mn-beacon-baseboard.dtsi"
-
-/ {
- model = "Beacon EmbeddedWorks i.MX8M Nano Development Kit";
- compatible = "beacon,imx8mn-beacon-kit", "fsl,imx8mn";
-
- chosen {
- stdout-path = &uart2;
- };
-};
diff --git a/arch/arm/dts/imx8mn-beacon-som.dtsi
b/arch/arm/dts/imx8mn-beacon-som.dtsi
deleted file mode 100644
index 1133cded9b..00
--- a/arch/arm/dts/imx8mn-beacon-som.dtsi
+++ /dev/null
@@ -1,472 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MIT)
-/*
- * Copyright 2020 Compass Electronics Group, LLC
- */
-
-/ {
- aliases {
- rtc0 = &rtc;
- rtc1 = &snvs_rtc;
- spi0 = &flexspi;
- };
-
- usdhc1_pwrseq: usdhc1_pwrseq {
- compatible = "mmc-pwrseq-simple";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usdhc1_gpio>;
- reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
- clocks = <&osc_32k>;
- clock-names = "ext_clock";
- post-power-on-delay-ms = <80>;
- };
-
- memory@4000 {
- device_type = "memory";
- reg = <0x0 0x4000 0 0x8000>;
- };
-};
-
-&A53_0 {
- cpu-supply = <&buck2_reg>;
-};
-
-&A53_1 {
- cpu-supply = <&buck2_reg>;
-};
-
-&A53_2 {
- cpu-supply = <&buck2_reg>;
-};
-
-&A53_3 {
- cpu-supply = <&buck2_reg>;
-};
-
-/* DDR controller is running LPDDR at 800MHz which requires 0.95V */
-&a53_opp_table {
- opp-12 {
- opp-microvolt = <95>;
- };
-};
-
-&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-800M {
- opp-hz = /bits/ 64 <8>;
- };
- };
-};
-
-&fec1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec1>;
- phy-mode = "rgmii-id";
- phy-handle = <ðphy0>;
- phy-supply = <&buck6_reg>;
- phy-reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
- fsl,magic-packet;
- status = "okay";
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ethphy0: ethernet-phy@0 {
- compatible = "ethernet-phy-ieee802.3-c22";
- reg = <0>;
- };
- };
-};
-
-&flexspi {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_flexspi>;
- status = "okay";
-
- flash@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "jedec,spi-nor";
- spi-max-frequency = <8000>;
- spi-tx-bus-width = <1>;
- spi-rx-bus-width = <4>;
- };
-};
-
-&i2c1 {
- clock-frequency = <40>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c1>;
- status = "okay";
-
- pmic@4b {
- compatible = "rohm,bd71847";
- reg = <0x4b>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_pmic>;
- interrupt-parent = <&gpio1>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
-
[PATCH 1/4] arm: davinci: Migrate da850-evm to OF_UPSTREAM
The da850-evm can remove the U-Boot device trees if migrated
to OF_UPSTREAM. This means pointing the device trees to the
ti/davinci directory.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/da850-evm.dts b/arch/arm/dts/da850-evm.dts
deleted file mode 100644
index 378af9f344..00
--- a/arch/arm/dts/da850-evm.dts
+++ /dev/null
@@ -1,453 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Device Tree for DA850 EVM board
- *
- * Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
- */
-/dts-v1/;
-#include "da850.dtsi"
-#include
-
-/ {
- compatible = "ti,da850-evm", "ti,da850";
- model = "DA850/AM1808/OMAP-L138 EVM";
-
- chosen {
- stdout-path = &serial2;
- };
-
- aliases {
- serial0 = &serial0;
- serial1 = &serial1;
- serial2 = &serial2;
- ethernet0 = ð0;
- spi0 = &spi1;
- };
-
- backlight: backlight-pwm {
- pinctrl-names = "default";
- pinctrl-0 = <&ecap2_pins>;
- power-supply = <&backlight_lcd>;
- compatible = "pwm-backlight";
- /*
-* The PWM here corresponds to production hardware. The
-* schematic needs to be 1015171 (15 March 2010), Rev A
-* or newer.
-*/
- pwms = <&ecap2 0 5 0>;
- brightness-levels = <0 10 20 30 40 50 60 70 80 90 99>;
- default-brightness-level = <7>;
- };
-
- panel {
- compatible = "ti,tilcdc,panel";
- pinctrl-names = "default";
- pinctrl-0 = <&lcd_pins>;
- /*
-* The vpif and the LCD are mutually exclusive.
-* To enable VPIF, change the status below to 'disabled' then
-* then change the status of the vpif below to 'okay'
-*/
- status = "okay";
- enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>; /* lcd_panel_pwr */
-
- panel-info {
- ac-bias = <255>;
- ac-bias-intrpt = <0>;
- dma-burst-sz = <16>;
- bpp = <16>;
- fdd = <0x80>;
- sync-edge = <0>;
- sync-ctrl = <1>;
- raster-order = <0>;
- fifo-th = <0>;
- };
-
- display-timings {
- native-mode = <&timing0>;
- timing0: 480x272 {
- clock-frequency = <900>;
- hactive = <480>;
- vactive = <272>;
- hfront-porch = <3>;
- hback-porch = <2>;
- hsync-len = <42>;
- vback-porch = <3>;
- vfront-porch = <4>;
- vsync-len = <11>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <1>;
- };
- };
- };
-
- vbat: fixedregulator0 {
- compatible = "regulator-fixed";
- regulator-name = "vbat";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- regulator-boot-on;
- };
-
- baseboard_3v3: fixedregulator-3v3 {
- /* TPS73701DCQ */
- compatible = "regulator-fixed";
- regulator-name = "baseboard_3v3";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- vin-supply = <&vbat>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- baseboard_1v8: fixedregulator-1v8 {
- /* TPS73701DCQ */
- compatible = "regulator-fixed";
- regulator-name = "baseboard_1v8";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- vin-supply = <&vbat>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- backlight_lcd: backlight-regulator {
- compatible = "regulator-fixed&qu
[PATCH 2/4] arm: ti: am3517_evm: Migrate to OF_UPSTREAM
With the feature of OF_UPSTREAM now available, the device trees
for the SOM and baseboard can now deleted and the device tree
locations need to point to the ti/omap directory.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/am3517-evm.dts b/arch/arm/dts/am3517-evm.dts
deleted file mode 100644
index d21bb2ccd0..00
--- a/arch/arm/dts/am3517-evm.dts
+++ /dev/null
@@ -1,339 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2011 Texas Instruments Incorporated - https://www.ti.com/
- */
-/dts-v1/;
-
-#include "am3517.dtsi"
-#include "am3517-som.dtsi"
-#include "am3517-evm-ui.dtsi"
-#include
-
-/ {
- model = "TI AM3517 EVM (AM3517/05 TMDSEVM3517)";
- compatible = "ti,am3517-evm", "ti,am3517", "ti,omap3";
-
- aliases {
- display0 = &lcd0;
- };
-
- chosen {
- stdout-path = &uart3;
- };
-
- memory@8000 {
- device_type = "memory";
- reg = <0x8000 0x1000>; /* 256 MB */
- };
-
- vmmc_fixed: vmmc {
- compatible = "regulator-fixed";
- regulator-name = "vmmc_fixed";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
-
- gpio-keys {
- compatible = "gpio-keys-polled";
- poll-interval = <100>;
-
- button-user {
- label = "User Push Button";
- linux,code = ;
- gpios = <&tca6416 5 GPIO_ACTIVE_LOW>;
- };
-
- switch-1 {
- label = "User Switch 1";
- linux,code = ;
- gpios = <&tca6416 8 GPIO_ACTIVE_LOW>;
- };
-
- switch-2 {
- label = "User Switch 2";
- linux,code = ;
- gpios = <&tca6416 9 GPIO_ACTIVE_LOW>;
- };
-
- switch-3 {
- label = "User Switch 3";
- linux,code = ;
- gpios = <&tca6416 10 GPIO_ACTIVE_LOW>;
- };
-
- switch-4 {
- label = "User Switch 4";
- linux,code = ;
- gpios = <&tca6416 11 GPIO_ACTIVE_LOW>;
- };
-
- switch-5 {
- label = "User Switch 5";
- linux,code = ;
- gpios = <&tca6416 12 GPIO_ACTIVE_LOW>;
- };
-
- switch-6 {
- label = "User Switch 6";
- linux,code = ;
- gpios = <&tca6416 13 GPIO_ACTIVE_LOW>;
- };
-
- switch-7 {
- label = "User Switch 7";
- linux,code = ;
- gpios = <&tca6416 14 GPIO_ACTIVE_LOW>;
- };
-
- switch-8 {
- label = "User Switch 8";
- linux,code = ;
- gpios = <&tca6416 15 GPIO_ACTIVE_LOW>;
- };
- };
-
- gpio-leds {
- compatible = "gpio-leds";
-
- pinctrl-names = "default";
- pinctrl-0 = <&leds_pins>;
-
- user_led_1 {
- label = "am3517evm:green:user_led_1";
- gpios = <&tca6416 7 GPIO_ACTIVE_LOW>;
- default-state = "on";
- };
-
- user_led_2 {
- label = "am3517evm:green:user_led_2";
- gpios = <&tca6416 6 GPIO_ACTIVE_LOW>;
- default-state = "on";
- };
-
- user_led_3 {
- label = "am3517evm:green:user_led_3";
- gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "mmc0"; /* SD/MMC card activity
*/
- };
-
- user_led_4 {
- label = "am3517evm:green:user_led_4";
- gpios = <&gpio1 31 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- };
- };
-
- lcd0: display@0 {
- /* This isn't the exact LCD, but the timings meet spec */
- /* To make it work, set CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 */
- compatible = "newh
[PATCH 3/4] arm: ti: logicpd-torpedo: Migrate to OF_UPSTREAM
The DM37 and OMAP35 Torpedo share a few files, but both of them
can be migrated to OF_UPSTREAM with a small update to their
respective u-boot.dtsi files to address changes made the aliases.
Both defconfigs need to properly point to the upstream directory
structure for the device trees. With those updated, the U-Boot
device tree files can be deleted.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/logicpd-torpedo-35xx-devkit-u-boot.dtsi
b/arch/arm/dts/logicpd-torpedo-35xx-devkit-u-boot.dtsi
index 4744872f7c..d14d68e458 100644
--- a/arch/arm/dts/logicpd-torpedo-35xx-devkit-u-boot.dtsi
+++ b/arch/arm/dts/logicpd-torpedo-35xx-devkit-u-boot.dtsi
@@ -14,6 +14,8 @@
aliases {
/delete-property/ serial1;
/delete-property/ serial2;
+ /delete-property/ mmc1;
+ /delete-property/ mmc2;
};
ethernet@0800 {
diff --git a/arch/arm/dts/logicpd-torpedo-35xx-devkit.dts
b/arch/arm/dts/logicpd-torpedo-35xx-devkit.dts
deleted file mode 100644
index cb08aa62d9..00
--- a/arch/arm/dts/logicpd-torpedo-35xx-devkit.dts
+++ /dev/null
@@ -1,21 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-
-/dts-v1/;
-
-#include "omap34xx.dtsi"
-#include "logicpd-torpedo-som.dtsi"
-#include "logicpd-torpedo-baseboard.dtsi"
-#include "omap-gpmc-smsc9221.dtsi"
-
-/ {
- model = "LogicPD Zoom OMAP35xx Torpedo Development Kit";
- compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3430", "ti,omap3";
-};
-
-&omap3_pmx_core {
- isp1763_pins: pinmux_isp1763_pins {
- pinctrl-single,pins = <
- OMAP3_CORE1_IOPAD(0x2154, PIN_INPUT_PULLUP |
MUX_MODE4)/* sdmmc1_dat6.gpio_128 */
- >;
- };
-};
diff --git a/arch/arm/dts/logicpd-torpedo-37xx-devkit-u-boot.dtsi
b/arch/arm/dts/logicpd-torpedo-37xx-devkit-u-boot.dtsi
index 2c34344504..8e8e2e4096 100644
--- a/arch/arm/dts/logicpd-torpedo-37xx-devkit-u-boot.dtsi
+++ b/arch/arm/dts/logicpd-torpedo-37xx-devkit-u-boot.dtsi
@@ -10,6 +10,8 @@
aliases {
/delete-property/ serial1;
/delete-property/ serial2;
+ /delete-property/ mmc1;
+ /delete-property/ mmc2;
};
ethernet@0800 {
diff --git a/arch/arm/dts/logicpd-torpedo-37xx-devkit.dts
b/arch/arm/dts/logicpd-torpedo-37xx-devkit.dts
deleted file mode 100644
index 07ea822fe4..00
--- a/arch/arm/dts/logicpd-torpedo-37xx-devkit.dts
+++ /dev/null
@@ -1,96 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-
-/dts-v1/;
-
-#include "omap36xx.dtsi"
-#include "logicpd-torpedo-som.dtsi"
-#include "omap-gpmc-smsc9221.dtsi"
-#include "logicpd-torpedo-baseboard.dtsi"
-
-/ {
- model = "LogicPD Zoom DM3730 Torpedo + Wireless Development Kit";
- compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3";
-
- wl12xx_vmmc: wl12xx_vmmc {
- compatible = "regulator-fixed";
- regulator-name = "vwl1271";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- gpio = <&gpio5 29 0>; /* gpio157 */
- startup-delay-us = <7>;
- enable-active-high;
- vin-supply = <&vmmc2>;
- };
-};
-
-/*
- * Only found on the wireless SOM. For the SOM without wireless, the pins for
- * MMC3 can be routed with jumpers to the second MMC slot on the devkit and
- * gpio157 is not connected. So this should be OK to keep common for now,
- * probably device tree overlays is the way to go with the various SOM and
- * jumpering combinations for the long run.
- */
-&mmc3 {
- interrupts-extended = <&intc 94 &omap3_pmx_core 0x136>;
- pinctrl-0 = <&mmc3_pins &mmc3_core2_pins>;
- pinctrl-names = "default";
- vmmc-supply = <&wl12xx_vmmc>;
- non-removable;
- bus-width = <4>;
- cap-power-off-card;
- #address-cells = <1>;
- #size-cells = <0>;
- wlcore: wlcore@2 {
- compatible = "ti,wl1283";
- reg = <2>;
- interrupt-parent = <&gpio5>;
- interrupts = <24 IRQ_TYPE_EDGE_RISING>; /* gpio 152 */
- ref-clock-frequency = <2600>;
- tcxo-clock-frequency = <2600>;
- };
-};
-
-&uart2 {
- /delete-property/dma-names;
- bluetooth {
- compatible = "ti,wl1283-st";
- enable-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* gpio 162 */
- max-speed = <300>;
- };
-};
-
-/* The DM3730 has a faster L3 than OMAP35, so inc
[PATCH 4/4] arm: ti: logicpd-som-lv: Migrate to OF_UPSTREAM
The DM37 and OMAP35 SOM-LV share a few files, but both of them
can be migrated to OF_UPSTREAM with a small update to their
respective u-boot.dtsi files to address changes made the aliases.
Both defconfigs need to properly point to the upstream directory
structure for the device trees. With those updated, the U-Boot
device tree files can be deleted.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/logicpd-som-lv-35xx-devkit-u-boot.dtsi
b/arch/arm/dts/logicpd-som-lv-35xx-devkit-u-boot.dtsi
index 6f11852a33..d77fa38746 100644
--- a/arch/arm/dts/logicpd-som-lv-35xx-devkit-u-boot.dtsi
+++ b/arch/arm/dts/logicpd-som-lv-35xx-devkit-u-boot.dtsi
@@ -14,6 +14,8 @@
aliases {
/delete-property/ serial1;
/delete-property/ serial2;
+ /delete-property/ mmc1;
+ /delete-property/ mmc2;
};
ethernet@0800 {
diff --git a/arch/arm/dts/logicpd-som-lv-35xx-devkit.dts
b/arch/arm/dts/logicpd-som-lv-35xx-devkit.dts
deleted file mode 100644
index f690bc83bf..00
--- a/arch/arm/dts/logicpd-som-lv-35xx-devkit.dts
+++ /dev/null
@@ -1,27 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-
-/dts-v1/;
-
-#include "omap34xx.dtsi"
-#include "logicpd-som-lv.dtsi"
-#include "logicpd-som-lv-baseboard.dtsi"
-#include "omap-gpmc-smsc9221.dtsi"
-
-/ {
- model = "LogicPD Zoom OMAP35xx SOM-LV Development Kit";
- compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3430", "ti,omap3";
-};
-
-&omap3_pmx_core2 {
-
- hsusb2_2_pins: pinmux_hsusb2_2_pins {
- pinctrl-single,pins = <
- OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
- OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
- OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
- OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
- OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
- OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
- >;
- };
-};
diff --git a/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
b/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
index 6f11852a33..d77fa38746 100644
--- a/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
+++ b/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
@@ -14,6 +14,8 @@
aliases {
/delete-property/ serial1;
/delete-property/ serial2;
+ /delete-property/ mmc1;
+ /delete-property/ mmc2;
};
ethernet@0800 {
diff --git a/arch/arm/dts/logicpd-som-lv-37xx-devkit.dts
b/arch/arm/dts/logicpd-som-lv-37xx-devkit.dts
deleted file mode 100644
index e28e9625be..00
--- a/arch/arm/dts/logicpd-som-lv-37xx-devkit.dts
+++ /dev/null
@@ -1,27 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-
-/dts-v1/;
-
-#include "omap36xx.dtsi"
-#include "logicpd-som-lv.dtsi"
-#include "logicpd-som-lv-baseboard.dtsi"
-#include "omap-gpmc-smsc9221.dtsi"
-
-/ {
- model = "LogicPD Zoom DM3730 SOM-LV Development Kit";
- compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap3";
-};
-
-&omap3_pmx_core2 {
-
- hsusb2_2_pins: pinmux_hsusb2_2_pins {
- pinctrl-single,pins = <
- OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
- OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
- OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
- OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
- OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
- OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
- >;
- };
-};
diff --git a/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
b/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
deleted file mode 100644
index 7d0468a237..00
--- a/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
+++ /dev/null
@@ -1,237 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-
-/ {
- gpio_keys {
- compatible = "gpio-keys";
- pinctrl-names = "default";
- pinctrl-0 = <&gpio_key_pins>;
-
- sysboot2 {
- label = "gpio3";
-
Re: [PATCH 1/4] arm: davinci: Migrate da850-evm to OF_UPSTREAM
On Thu, Apr 11, 2024 at 7:05 PM Tom Rini wrote: > > On Wed, Apr 03, 2024 at 10:00:09PM -0500, Adam Ford wrote: > > > The da850-evm can remove the U-Boot device trees if migrated > > to OF_UPSTREAM. This means pointing the device trees to the > > ti/davinci directory. > > > > Signed-off-by: Adam Ford > > This series leads to failure to build for omapl138_lcdk and lego_ev3 or > was I supposed to bring in something else first? Thanks. I just got back from 10 days in Europe for the Embedded World Conference. It should have been based on [1], but I haven't checked to see if it was applied. I (maybe wrongly) assumed [1] would have been applied before this patch was. Once I get caught up, I'll look to see what's going one. adam [1] - https://www.mail-archive.com/u-boot@lists.denx.de/msg505123.html > > -- > Tom
Re: [PATCH 1/4] arm: davinci: Migrate da850-evm to OF_UPSTREAM
On Tue, Apr 16, 2024 at 6:53 AM Adam Ford wrote: > > On Thu, Apr 11, 2024 at 7:05 PM Tom Rini wrote: > > > > On Wed, Apr 03, 2024 at 10:00:09PM -0500, Adam Ford wrote: > > > > > The da850-evm can remove the U-Boot device trees if migrated > > > to OF_UPSTREAM. This means pointing the device trees to the > > > ti/davinci directory. > > > > > > Signed-off-by: Adam Ford > > > > This series leads to failure to build for omapl138_lcdk and lego_ev3 or > > was I supposed to bring in something else first? Thanks. > > I just got back from 10 days in Europe for the Embedded World > Conference. It should have been based on [1], but I haven't checked > to see if it was applied. I (maybe wrongly) assumed [1] would have > been applied before this patch was. > > Once I get caught up, I'll look to see what's going one. > Tom - Can you point me to a failing log for this, so I can try to replicate it? adam > adam > > [1] - https://www.mail-archive.com/u-boot@lists.denx.de/msg505123.html > > > > > > > -- > > Tom
Re: [PATCH] arm: imx: imx8m: Enable the SError exception
On Fri, Jan 12, 2024 at 1:07 AM Ye Li wrote: > > To work with commit 2f3c920(imx8m: workaround ROM serror), > we need to enable the SError exception and install vector in SPL. > > Signed-off-by: Ye Li > Reviewed-by: Peng Fan > --- > arch/arm/mach-imx/imx8m/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig > index 67da198..88ef732 100644 > --- a/arch/arm/mach-imx/imx8m/Kconfig > +++ b/arch/arm/mach-imx/imx8m/Kconfig > @@ -11,14 +11,17 @@ config IMX8MQ > bool > select IMX8M > select CLK_IMX8MQ > + select ARMV8_SPL_EXCEPTION_VECTORS > > config IMX8MM > bool > select IMX8M > + select ARMV8_SPL_EXCEPTION_VECTORS > > config IMX8MN > bool > select IMX8M > + select ARMV8_SPL_EXCEPTION_VECTORS > > config IMX8MP > bool > -- > 2.7.4 > Would this not also work for 8MP? If that's the case, should the section of ARMV8_SPL_EXCEPTION_VECTORS fall under "config IMX8M" for simplicity? adam
Re: [PATCH 7/7] verdin-imx8mp_defconfig: Enable PCIe/NVMe support
On Wed, Feb 21, 2024 at 6:27 AM Marek Vasut wrote: > > On 2/21/24 13:12, Sumit Garg wrote: > > On Wed, 21 Feb 2024 at 16:11, Marek Vasut wrote: > >> > >> On 2/21/24 10:18, Marcel Ziswiler wrote: > >>> Hi Sumit > >>> > >>> On Wed, 2024-02-21 at 08:55 +0100, Francesco Dolcini wrote: > Hello Sumit, > > On Tue, Feb 20, 2024 at 06:40:56PM +0530, Sumit Garg wrote: > > Also, enable reset driver which is a prerequisite for PCIe support. > > > > Signed-off-by: Sumit Garg > > --- > >configs/verdin-imx8mp_defconfig | 9 + > >1 file changed, 9 insertions(+) > > > > diff --git a/configs/verdin-imx8mp_defconfig > > b/configs/verdin-imx8mp_defconfig > > index 22b8a334dfa..d8bd644322b 100644 > > --- a/configs/verdin-imx8mp_defconfig > > +++ b/configs/verdin-imx8mp_defconfig > > @@ -185,3 +185,12 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 > >CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 > >CONFIG_IMX_WATCHDOG=y > >CONFIG_HEXDUMP=y > > +CONFIG_DM_RESET=y > > +CONFIG_RESET_IMX=y > > +CONFIG_PCI=y > > +CONFIG_PCIE_DW_IMX8=y > > +CONFIG_PHY_IMX8M_PCIE=y > > +CONFIG_CMD_PCI=y > > +CONFIG_NVME=y > > +CONFIG_NVME_PCI=y > > +CONFIG_CMD_NVME=y > > This will increase the u-boot proper size > >>> > >>> Yes, I checked and it is actually slightly more than 32 K. > >>> > and marginally increase the > boot time (because of a bigger binary to be read from the eMMC). > >>> > >>> That was also my concern. > >>> > Apart of that do you expect any other impact on those changes? SPL > binary size should not be affected, correct? > > Asking this out loudly to confirm that nothing unexpected is going to > happen because of these changes. > >>> > >>> Other than that I actually gave it a quick try and PCIe/NVMe does indeed > >>> work and the regular boot is not > >>> affected (other than the slight size and boot time increase, of course). > >>> > For my curiosity, care to share what's the use case? Do you plan to have > the OS stored into an NVME device? > >>> > >>> For us the question is basically whether that use case does mandate > >>> enforcing such changes for each and every > >>> customer. Plus the regular expected maintenance effort any such change > >>> brings with it, of course. > >> > >> You can always enable this support on MX8MP EVK, it has M2 slot and this > >> would add build coverage of this code too, without impacting Verdin. > > > > I would have chosen that as the base platform to enable but > > unfortunately I don't have that at my desk. However, if someone is > > willing to test this patch-set on MX8MP EVK then I am happy to extend > > corresponding defconfig too. > > I think we can surely find a platform on which this can be enabled by > default and tested by people. My development machine crashed (my fault for running a pre-release OS),but I have an i.MX8M Plus and an NVMe drive that I can test once I get my machine running again. adam
Re: [PATCH v2 5/8] phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY
On Mon, Feb 26, 2024 at 2:05 AM Sumit Garg wrote:
>
> Add initial support for i.MX8M{M/P} PCIe PHY. On i.MX8M{M/P} SoCs PCIe
> PHY initialization moved to this standalone PHY driver.
>
> Inspired from counterpart Linux kernel v6.8-rc3 driver:
> drivers/phy/freescale/phy-fsl-imx8m-pcie.c.
I have a PCIe device that works just fine in Linux. I have applied
your series an enabled the same config options as you did along with
some others to resolve some build issues.
Any ideas how to address:
nxp_imx8_pcie_phy pcie-phy@32f0: PHY: Failed to power on
pcie-phy@32f0: -110.
My PHY node looks like this
&pcie_phy {
fsl,refclk-pad-mode = ;
clocks = <&pcie0_refclk>;
clock-names = "ref";
status = "okay";
};
The pcie_refcllk is defined as a 100MHz fixed clock in U-Boot. clk
dump shows it to be:
10|-- clock-pcie
>
> Signed-off-by: Sumit Garg
> ---
> drivers/phy/Kconfig | 9 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-imx8m-pcie.c | 269 +++
> 3 files changed, 279 insertions(+)
> create mode 100644 drivers/phy/phy-imx8m-pcie.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 60138beca498..110ec8f5008d 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -284,6 +284,15 @@ config PHY_IMX8MQ_USB
> help
> Support the USB3.0 PHY in NXP i.MX8MQ or i.MX8MP SoC
>
> +config PHY_IMX8M_PCIE
> + bool "NXP i.MX8MM/i.MX8MP PCIe PHY Driver"
> + depends on PHY
> + depends on IMX8MM || IMX8MP
This should also depend on SYSCON and REGMAP to prevent build errors.
> + help
> + Support the PCIe PHY in NXP i.MX8MM or i.MX8MP SoC
> +
> + This PHY is found on i.MX8M devices supporting PCIe.
> +
> config PHY_XILINX_ZYNQMP
> tristate "Xilinx ZynqMP PHY driver"
> depends on PHY && ARCH_ZYNQMP
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 2e8723186c05..7a2b764492be 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_PHY_DA8XX_USB) += phy-da8xx-usb.o
> obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> obj-$(CONFIG_PHY_NPCM_USB) += phy-npcm-usb.o
> obj-$(CONFIG_PHY_IMX8MQ_USB) += phy-imx8mq-usb.o
> +obj-$(CONFIG_PHY_IMX8M_PCIE) += phy-imx8m-pcie.o
> obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o
> obj-y += cadence/
> obj-y += ti/
> diff --git a/drivers/phy/phy-imx8m-pcie.c b/drivers/phy/phy-imx8m-pcie.c
> new file mode 100644
> index ..e09a7ac97235
> --- /dev/null
> +++ b/drivers/phy/phy-imx8m-pcie.c
> @@ -0,0 +1,269 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2024 Linaro Ltd.
> + *
> + * Derived from Linux counterpart driver
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define IMX8MM_PCIE_PHY_CMN_REG061 0x184
> +#define ANA_PLL_CLK_OUT_TO_EXT_IO_EN BIT(0)
> +#define IMX8MM_PCIE_PHY_CMN_REG062 0x188
> +#define ANA_PLL_CLK_OUT_TO_EXT_IO_SEL BIT(3)
> +#define IMX8MM_PCIE_PHY_CMN_REG063 0x18C
> +#define AUX_PLL_REFCLK_SEL_SYS_PLLGENMASK(7, 6)
> +#define IMX8MM_PCIE_PHY_CMN_REG064 0x190
> +#define ANA_AUX_RX_TX_SEL_TX BIT(7)
> +#define ANA_AUX_RX_TERM_GND_ENBIT(3)
> +#define ANA_AUX_TX_TERM BIT(2)
> +#define IMX8MM_PCIE_PHY_CMN_REG065 0x194
> +#define ANA_AUX_RX_TERM (BIT(7) | BIT(4))
> +#define ANA_AUX_TX_LVLGENMASK(3, 0)
> +#define IMX8MM_PCIE_PHY_CMN_REG075 0x1D4
> +#define ANA_PLL_DONE 0x3
> +#define PCIE_PHY_TRSV_REG5 0x414
> +#define PCIE_PHY_TRSV_REG6 0x418
> +
> +#define IMX8MM_GPR_PCIE_REF_CLK_SELGENMASK(25, 24)
> +#define IMX8MM_GPR_PCIE_REF_CLK_PLL
> FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x3)
> +#define IMX8MM_GPR_PCIE_REF_CLK_EXT
> FIELD_PREP(IMX8MM_GPR_PCIE_REF_CLK_SEL, 0x2)
> +#define IMX8MM_GPR_PCIE_AUX_EN BIT(19)
> +#define IMX8MM_GPR_PCIE_CMN_RSTBIT(18)
> +#define IMX8MM_GPR_PCIE_POWER_OFF BIT(17)
> +#define IMX8MM_GPR_PCIE_SSC_EN BIT(16)
> +#define IMX8MM_GPR_PCIE_AUX_EN_OVERRIDEBIT(9)
> +
> +#define IOMUXC_GPR14_OFFSET0x38
> +
> +enum imx8_pcie_phy_type {
> + IMX8MM,
> + IMX8MP,
> +};
> +
> +struct imx8_pcie_phy_drvdata {
> + const char*gpr;
> + enumimx8_pcie_phy_type variant;
> +};
> +
> +struct imx8_pcie_phy {
> + ulong base;
> + struct clk hsio_clk;
> + struct regmap *iomuxc_gpr;
> + struct reset_ctlperst;
> + struct reset_ctlreset;
> + u32 refclk_pad_mode;
> + u32 tx_deemph_gen1;
> + u32 tx_deemph_gen2;
> + bool
Re: [PATCH v2 6/8] pci: Add DW PCIe controller support for iMX8MP SoC
On Mon, Feb 26, 2024 at 2:05 AM Sumit Garg wrote:
>
> pcie_imx doesn't seem to share any useful code for iMX8 SoC and it is
> tied to quite old port of pcie_designware driver from Linux which
> suffices only iMX6 specific needs.
>
> But currently we have the common DWC specific bits which alligns pretty
> well with DW PCIe controller on iMX8MP SoC. So lets reuse those common
> bits instead as a new driver for iMX8 SoCs. It should be fairly easy to
> add support for other iMX8 variants to this driver.
>
> iMX8MP SoC also comes up with standalone PCIe PHY support, so hence we
> can reuse the generic PHY infrastructure to power on PCIe PHY.
>
> Signed-off-by: Sumit Garg
> ---
> drivers/pci/Kconfig | 8 +
> drivers/pci/Makefile | 1 +
> drivers/pci/pcie_dw_imx.c | 314 ++
> 3 files changed, 323 insertions(+)
> create mode 100644 drivers/pci/pcie_dw_imx.c
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 463ec47eb92d..7edbf35004a9 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -413,4 +413,12 @@ config PCIE_STARFIVE_JH7110
> Say Y here if you want to enable PLDA XpressRich PCIe controller
> support on StarFive JH7110 SoC.
>
> +config PCIE_DW_IMX
> + bool "i.MX DW PCIe controller support"
> + depends on ARCH_IMX8M
I think this also needs to depend on REGMAP to prevent build errors.
adam
> + select PCIE_DW_COMMON
> + help
> + Say Y here if you want to enable DW PCIe controller support on
> + iMX SoCs.
> +
> endif
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 72ef8b4bc772..2927c519129b 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -53,3 +53,4 @@ obj-$(CONFIG_PCIE_UNIPHIER) += pcie_uniphier.o
> obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o
> obj-$(CONFIG_PCIE_PLDA_COMMON) += pcie_plda_common.o
> obj-$(CONFIG_PCIE_STARFIVE_JH7110) += pcie_starfive_jh7110.o
> +obj-$(CONFIG_PCIE_DW_IMX) += pcie_dw_imx.o
> diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
> new file mode 100644
> index ..7856823c9188
> --- /dev/null
> +++ b/drivers/pci/pcie_dw_imx.c
> @@ -0,0 +1,314 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2024 Linaro Ltd.
> + *
> + * Author: Sumit Garg
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pcie_dw_common.h"
> +
> +#define PCIE_LINK_CAPABILITY 0x7c
> +#define TARGET_LINK_SPEED_MASK 0xf
> +#define LINK_SPEED_GEN_1 0x1
> +#define LINK_SPEED_GEN_2 0x2
> +#define LINK_SPEED_GEN_3 0x3
> +
> +#define PCIE_MISC_CONTROL_1_OFF0x8bc
> +#define PCIE_DBI_RO_WR_EN BIT(0)
> +
> +#define PCIE_PORT_DEBUG0 0x728
> +#define PCIE_PORT_DEBUG1 0x72c
> +#define PCIE_PORT_DEBUG1_LINK_UP BIT(4)
> +#define PCIE_PORT_DEBUG1_LINK_IN_TRAINING BIT(29)
> +
> +#define PCIE_LINK_UP_TIMEOUT_MS100
> +
> +#define IOMUXC_GPR14_OFFSET0x38
> +#define IMX8M_GPR_PCIE_CLK_REQ_OVERRIDE_EN BIT(10)
> +#define IMX8M_GPR_PCIE_CLK_REQ_OVERRIDEBIT(11)
> +
> +struct pcie_dw_imx {
> + /* Must be first member of the struct */
> + struct pcie_dw dw;
> + struct regmap *iomuxc_gpr;
> + struct clk_bulk clks;
> + struct gpio_descreset_gpio;
> + struct reset_ctlapps_reset;
> + struct phy phy;
> +};
> +
> +static void pcie_dw_configure(struct pcie_dw_imx *priv, u32 cap_speed)
> +{
> + dw_pcie_dbi_write_enable(&priv->dw, true);
> +
> + clrsetbits_le32(priv->dw.dbi_base + PCIE_LINK_CAPABILITY,
> + TARGET_LINK_SPEED_MASK, cap_speed);
> +
> + dw_pcie_dbi_write_enable(&priv->dw, false);
> +}
> +
> +static void imx_pcie_ltssm_enable(struct pcie_dw_imx *priv)
> +{
> + reset_deassert(&priv->apps_reset);
> +}
> +
> +static void imx_pcie_ltssm_disable(struct pcie_dw_imx *priv)
> +{
> + reset_assert(&priv->apps_reset);
> +}
> +
> +static bool is_link_up(u32 val)
> +{
> + return ((val & PCIE_PORT_DEBUG1_LINK_UP) &&
> + (!(val & PCIE_PORT_DEBUG1_LINK_IN_TRAINING)));
> +}
> +
> +static int wait_link_up(struct pcie_dw_imx *priv)
> +{
> + u32 val;
> +
> + return readl_poll_sleep_timeout(priv->dw.dbi_base + PCIE_PORT_DEBUG1,
> + val, is_link_up(val), 1, 10);
> +}
> +
> +static int pcie_link_up(struct pcie_dw_imx *priv, u32 cap_speed)
> +{
> + int ret;
> +
> + /* DW pre link configurations */
> + pcie_dw_configure(priv, cap_speed);
> +
> +
Re: [PATCH 03/13] imx: ddr: imx8m: add print for DRAM rate
On Mon, Dec 28, 2020 at 7:27 AM Peng Fan (OSS) wrote:
>
> From: Ye Li
>
> Enable print to show the DRAM rate of current setting and training
> result.
>
> Signed-off-by: Ye Li
> Reviewed-by: Peng Fan
> Signed-off-by: Peng Fan
> ---
> drivers/ddr/imx/imx8m/ddr_init.c | 7 ---
> drivers/ddr/imx/imx8m/ddrphy_utils.c | 2 +-
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/ddr/imx/imx8m/ddr_init.c
> b/drivers/ddr/imx/imx8m/ddr_init.c
> index 99a67edfb0..65739dbaa7 100644
> --- a/drivers/ddr/imx/imx8m/ddr_init.c
> +++ b/drivers/ddr/imx/imx8m/ddr_init.c
> @@ -96,7 +96,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
> unsigned int tmp, initial_drate, target_freq;
> int ret;
>
> - debug("DDRINFO: start DRAM init\n");
> + printf("DDRINFO: start DRAM init\n");
Why not make this optional? With debug enabled, it will print. This
makes extra chatter for everyone.
It also undoes: 0d3bc813 ("imx8m: ddr_init: Move ddr_init() messages
to debug level")
>
> /* Step1: Follow the power up procedure */
> if (is_imx8mq()) {
> @@ -119,6 +119,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
>
> initial_drate = dram_timing->fsp_msg[0].drate;
> /* default to the frequency point 0 clock */
> + printf("DDRINFO: DRAM rate %dMTS\n", initial_drate);
> ddrphy_init_set_dfi_clk(initial_drate);
>
> /* D-aasert the presetn */
> @@ -185,7 +186,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
> tmp = reg32_read(DDRPHY_CalBusy(0));
> } while ((tmp & 0x1));
>
> - debug("DDRINFO:ddrphy calibration done\n");
> + printf("DDRINFO:ddrphy calibration done\n");
>
> /* Step15: Set SWCTL.sw_done to 0 */
> reg32_write(DDRC_SWCTL(0), 0x);
> @@ -240,7 +241,7 @@ int ddr_init(struct dram_timing_info *dram_timing)
>
> /* enable port 0 */
> reg32_write(DDRC_PCTRL_0(0), 0x0001);
> - debug("DDRINFO: ddrmix config done\n");
> + printf("DDRINFO: ddrmix config done\n");
>
> board_dram_ecc_scrub();
>
> diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c
> b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> index 0f8baefb1f..326b92d784 100644
> --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c
> +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c
> @@ -104,7 +104,7 @@ int wait_ddrphy_training_complete(void)
> debug("Training PASS\n");
> return 0;
> } else if (mail == 0xff) {
> - debug("Training FAILED\n");
> + printf("Training FAILED\n");
> return -1;
> }
> }
> --
> 2.28.0
>
Re: [PATCH 05/13] imx: imx8mn_evk: correct stack/malloc adress
On Mon, Dec 28, 2020 at 7:28 AM Peng Fan (OSS) wrote:
>
> From: Peng Fan
>
> Move SP to end of OCRAM space. Drop MALLOC_F to make it alloc from
> stack space.
>
> Signed-off-by: Peng Fan
> ---
> drivers/power/power_i2c.c| 8
> include/configs/imx8mn_evk.h | 9 +++--
> 2 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
> index 5a0455e119..b67ac2f027 100644
> --- a/drivers/power/power_i2c.c
> +++ b/drivers/power/power_i2c.c
> @@ -23,7 +23,7 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
>
> if (check_reg(p, reg))
> return -EINVAL;
> -#if defined(CONFIG_DM_I2C)
> +#if CONFIG_IS_ENABLED(DM_I2C)
> struct udevice *dev;
> int ret;
>
> @@ -67,7 +67,7 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
> return -EINVAL;
> }
>
> -#if defined(CONFIG_DM_I2C)
> +#if CONFIG_IS_ENABLED(DM_I2C)
> return dm_i2c_write(dev, reg, buf, pmic_i2c_tx_num);
> #else
> return i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
> @@ -83,7 +83,7 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
> if (check_reg(p, reg))
> return -EINVAL;
>
> -#if defined(CONFIG_DM_I2C)
> +#if CONFIG_IS_ENABLED(DM_I2C)
> struct udevice *dev;
>
> ret = i2c_get_chip_for_busnum(p->bus, pmic_i2c_addr,
> @@ -131,7 +131,7 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
> int pmic_probe(struct pmic *p)
> {
> debug("Bus: %d PMIC:%s probed!\n", p->bus, p->name);
> -#if defined(CONFIG_DM_I2C)
> +#if CONFIG_IS_ENABLED(DM_I2C)
> struct udevice *dev;
> int ret;
>
> diff --git a/include/configs/imx8mn_evk.h b/include/configs/imx8mn_evk.h
> index a6333085fe..61db244e98 100644
> --- a/include/configs/imx8mn_evk.h
> +++ b/include/configs/imx8mn_evk.h
> @@ -20,17 +20,14 @@
> (QSPI0_AMBA_BASE + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512)
>
> #ifdef CONFIG_SPL_BUILD
> -#define CONFIG_SPL_STACK 0x95fff0
> -#define CONFIG_SPL_BSS_START_ADDR 0x0095
> -#define CONFIG_SPL_BSS_MAX_SIZESZ_8K /* 8 KB */
> +#define CONFIG_SPL_STACK 0x98
> +#define CONFIG_SPL_BSS_START_ADDR 0x95
> +#define CONFIG_SPL_BSS_MAX_SIZESZ_4K /* 8 KB */
If ATF sits at 96 and CONFIG_SPL_BSS_START_ADDR starts at
0x95, 8K should fit with extra space. I think it should be able
to go even larger.
I took your patch and applied it to the Beacon 8mn kit and, I was able
to set the max size to SZ_64K with CONFIG_SPL_BSS_START_ADDR set to
0x95
The reference manual states that OCRAM starts at 91. What is
located in the space between 91 and 95?
> #define CONFIG_SYS_SPL_MALLOC_START0x4220
> #define CONFIG_SYS_SPL_MALLOC_SIZE SZ_512K /* 512 KB */
> #define CONFIG_SYS_ICACHE_OFF
> #define CONFIG_SYS_DCACHE_OFF
>
> -/* malloc f used before GD_FLG_FULL_MALLOC_INIT set */
> -#define CONFIG_MALLOC_F_ADDR 0x0094
> -
> /* For RAW image gives a error info not panic */
> #define CONFIG_SPL_ABORT_ON_RAW_IMAGE
>
> --
> 2.28.0
>
[PATCH 1/2] imx8mm_beacon: Enable fixed regulator in SPL
Because SPL can support SD UHS, the fixed regulator needs to be
enabled in SPL to reset the SD card.
Fixes: 1a5d9c84b472 ("imx8mm_beacon: Enable HS400 on MMC controller")
Signed-off-by: Adam Ford
diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig
index 49d5453078..b0ea87a58c 100644
--- a/configs/imx8mm_beacon_defconfig
+++ b/configs/imx8mm_beacon_defconfig
@@ -95,6 +95,7 @@ CONFIG_SPL_DM_REGULATOR=y
CONFIG_DM_REGULATOR_BD71837=y
CONFIG_SPL_DM_REGULATOR_BD71837=y
CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_SPL_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
CONFIG_CONS_INDEX=2
CONFIG_DM_SERIAL=y
--
2.25.1
[PATCH 2/2] ARM: dts: imx8mm-beacon: add UHS and HS400/HS400ES properties
i.MX8M Mini can provide support for high speed grades in the
usdhc controllers.
On the imx8mm-beacon-kit, the sdhc2 hosts a microSD card, and
sdhc3 hosts an eMMC capable of HS400ES.
In order to toggle this mode in SPL, the reg_usdhc2_vmmc must
be available in SPL. Add all these flags to
imx8mm-beacon-kit-u-boot.dtsi
Suggested-by: Andrey Zhizhikin
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
b/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
index 6d80a529ae..d7da29c592 100644
--- a/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi
@@ -38,6 +38,7 @@
};
®_usdhc2_vmmc {
+ u-boot,dm-spl;
u-boot,off-on-delay-us = <2>;
};
@@ -112,10 +113,14 @@
&usdhc2 {
u-boot,dm-spl;
+ sd-uhs-sdr104;
+ sd-uhs-ddr50;
};
&usdhc3 {
u-boot,dm-spl;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
};
&i2c1 {
--
2.25.1
Re: [PATCH 2/2] ARM: dts: imx8mm-beacon: add UHS and HS400/HS400ES properties
On Wed, Dec 30, 2020 at 8:22 AM Fabio Estevam wrote:
>
> Hi Adam,
>
> On Wed, Dec 30, 2020 at 11:14 AM Adam Ford wrote:
>
> > &usdhc2 {
> > u-boot,dm-spl;
> > + sd-uhs-sdr104;
> > + sd-uhs-ddr50;
>
> Shouldn't these properties be part of the main dtsi instead of adding
> them to the u-boot.dtsi one?
Linux doesn't appear to need it, and no 64-bit imx boards in Linux
appear to use them. Some layerscape boards appear to use these flags.
If it's not necessary for Linux, but it is necessary for U-Boot, it
seems like the -u-boot.dtsi file is the right place to put it.
It's consistent with that was done for the imx8mm-evk-u-boot.dtsi and others [1]
[1] -
https://gitlab.denx.de/u-boot/u-boot/-/commit/50b1a69cee0dc06d0c713a5a978998f2b4a9cb31
adam
