Congatec SXM8P U-BOOT Console Port Change

[engconcepts]

Hello all,

I am using the following configuration

Congatec SMX8-PLUS SMARC module install on their SMC1 carrier card

Yocto NXP i.MX Release Distro 5.15-kirkstone imx8mp-cgtsx8p

I have everything built and running fine on the SMC1 carrier board with the ttymxc1 as the console port.    I am trying to switch the default console for U-BOOT from ttymxc1 to ttymxc3.  This is due to development of the custom carrier board where the ttxmxc1 is suspect.  I tried changing the define in yocto/sources/meta-freescale-3rdparty/conf/machine/imx8mp-cgtsx8p.conf

from SERIAL _CONSOLES = "115200;ttymxc1" to SERIAL_CONSOLES="115200;ttymxc3"

This worked to get me a kernel terminal on ttymxc3 after boot.  The U-BOOT output and kernel boot process still is outputting to ttymxc1, and also end up with a kernel terminal prompt.  I would like the entire U-BOOT console output from HW reset to full boot to output to the ttymxc3 port.  I suspect there is some define I have to set somewhere in the BSP's U-BOOT files, but I can 't seem to find anything relevant.  I know in the end the SPI Flash image will need to be built and flash to the onboard SPI flash.   However, I'm missing the key piece of where to make the change.  As a note the flash image is bootcontainer__imx8mp-cgtsx8p__fspi.bin

Thanks,

Chris

[spetroce]

In the kernel source I did this:

diff --git a/arch/arm64/boot/dts/congatec/imx8mp-cgtqx8p.dts b/arch/arm64/boot/dts/congatec/imx8mp-cgtqx8p.dts
index e55e20fa65a1..ffa0b55056e0 100755
--- a/arch/arm64/boot/dts/congatec/imx8mp-cgtqx8p.dts
+++ b/arch/arm64/boot/dts/congatec/imx8mp-cgtqx8p.dts
@@ -28,7 +28,7 @@ memory@40000000 {
};

chosen {
- stdout-path = &uart2;
+ stdout-path = &uart1;
};

gpio-keys {

In U-Boot:

diff --git a/arch/arm/dts/imx8mp-cgtqx8p.dts b/arch/arm/dts/imx8mp-cgtqx8p.dts
index c0d2f0749e..128c26b411 100644
--- a/arch/arm/dts/imx8mp-cgtqx8p.dts
+++ b/arch/arm/dts/imx8mp-cgtqx8p.dts
@@ -18,8 +18,8 @@
compatible = "cgt,qx8p", "fsl,imx8mp-evk", "fsl,imx8mp";

chosen {
- bootargs = "console=ttymxc1,115200 earlycon=ec_imx6q,0x30890000,115200";
- stdout-path = &uart2;
+ bootargs = "console=ttymxc0,115200 earlycon=ec_imx6q,0x30860000,115200";
+ stdout-path = &uart1;
};

memory@40000000 {
@@ -395,6 +395,14 @@
};
};

+&uart1 {
+ /* RF board USB console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+ status = "okay";
+};

/* uart1: Q-Seven UART0 with CTS/RTS (unused) */
/* uart4: on module uart DCE1 (X4: pin 1 and pin 6) (unused) */
@@ -654,6 +662,13 @@
>;
};

+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x49
+ MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x49
+ >;
+ };
+
pinctrl_uart2: uart2grp {
fsl,pins = <
MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x49
diff --git a/include/configs/cgtqx8p.h b/include/configs/cgtqx8p.h
index 763edecf84..3e311e2d53 100644
--- a/include/configs/cgtqx8p.h
+++ b/include/configs/cgtqx8p.h
@@ -20,7 +20,7 @@
* OR: QSEVEN pins 185/188 (DEFAULT: GPIO0 and GPIO3)
* - 3: on module debug port (DCE1), iMX8mp: uart 4
*/
-#define CGT_SERIAL_CONSOLE_NR 1
+#define CGT_SERIAL_CONSOLE_NR 0

/*
* MMCAUTODETECT_ENV=yes enables automatic adaption of MMCDEV and MMCROOT on

This was done for the Q7 iMX8 SOM. I flashed this to the QSPI flash and the SPL bootloader reported out the new UART1 console port (nothing out of the congatec console port). However, as I forcasted in my last update, you should make sure you have the eval board because if you flash the bootloader into the SPI flash during runtime and something is not right, you will not be able to fix it. I unfortunately have not received my eval board in the mail yet. I say this because these modifications I've made for some reason do not make it past the SPL bootloader. It's on it's way there though because I did get UART1 console sort of working now.

[engconcepts]

I finally was able to get back to this and was able to get a working solution, although not the cleanest/correct way to do it.  I edited the following two files:

1) ~/yocto/build-dir/tmp/work/imx8mp_cgtsx8p-poky-linux/u-boot-congatec-sx8p/2022.04-r0/git/include.configs/cgtsx8p.h.  In that file I changed #DEFINE CONSOLE_UART_NUMBER 2 to 1, which changes ttymxc1 to ttymxc0.

2) ~/yocto/sources/meta-freescale-3rdparty/conf/machine/imx8mp-cgtsx8p.conf.  In that file I changed SERIAL_CONSOLE="115200;ttymxc1" to  SERIAL_CONSOLE="115200;ttymxc0"

In order to ensure a clean build, I deleted the tmp directory sstate-cache directories.  Right after I initiated bitbake, I copied the the modified cgtsx8p.h to the directory listed in 1) as the bitbake process populates the work directory I suspect an "un-pack" process.  In the end I was able to build the imx8-image-multimedia image.  I made a SD card with imx-image-multimedia-imx8mp-cgtsx8p.wic and bootcontainer__imx8mp-cgtsx8p__sd.bin.  I also copied bootcontainer__imx8mp-cgtsx8p__fspi.bin to the SD card.  After booting off the SD card, I flashed the bootcontainer__imx8mp-cgtsx8p__fspi.bin into the first partition of the QPSI(/dev/mtd0).  After power-on reset, I now how both u-boot and kernel output going to ttymxc0 vice ttymxc1.  Interestingly enough, I get a login prompt on ttymxc1(nothing else).  It still behaves the same with the SMARC module X2 connector Rx/Tx working for ttymxc1 and the carrier board's ttymxc1 only working with transmit.  This is suspected behavior and the reason why I was trying to move the port off of ttymxc1.  Anyhow, the solution I'm sure isn't the correct way to do it, but it will get me by for now.  From quick searches this morning, it appears that I might have to create a patch for the respective recipe where these header files get picked up to do it the correct way.  All new territory  for me.  I'll keep you posted on my findings, although I'm slow since I'm coming from 20+ years of VxWorks on 68K/X86 vice Yocto/ARM.  Hope this helps you though.

[engconcepts]

Finally got this figured out. Here is what I did for the SMARC version.  I think you just need to substitute the Q7 files vice what I'm doing.

1) $MACHINE=imx8mp-cgtsxp DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b build-dir

2) devtool modify u-boot-congatec-sx8p.  This will create a workspace directory under your build directory...in my case ~yocto/build-dir. Path will be build-dir/workspace/sources/u-boot-congatec-sx8p/include/configs

3)modify cgtsx8p.h to move to whatever serial port you want uboot to send console/kernel output to

4) git add cgtsx8p.h 

5) git commit -m "insert your comment for change here"

6) devtool update-recipe u-boot-congatec-sx8p

7)devtool reset u-boot-congatec-sx8p to delete the workspace.  I just left this in place for what it's worth

That's it.  The process creates a patch that applies the serial port change.  Hope this helps you.  Let me know if you have any questions.

Chris

[engconcepts]

I haven't gone down that path yet since I haven't had chance to put time into it again.  I polled the US Congatec FAE about this and he is in Germany this week and going to try and get some clues from them at the corporate office.  I was concerned about bricking the board too, however, I think I could recover since I have the SMC1 eval board and "should" be able to do a forced recovery.

[spetroce]

From the User Guide:

So the conga-qmx8-plus boots from SPI flash by default and to boot from another source, you must modify the SoC eFuses. If you go to the Wiki for the yocto project you will see this in section 4: "With the above created system image the system boots from SD-Card. It is possible to boot from QSPI if the bootcontainer is flashed inside first SPI partition." This is perhaps slightly misleading or incorrect. Was "possible to boot from QSPI" written when DIP switches were a thing on early revs of the SOM so you had the option? Or is it saying, if you wipe the first SPI partition that it won't try to use that bootloader? (Doubt it). Anyway, this is probably all the same deal for the SMX8-PLUS SMARC. In that case, the bootloader is loaded from SPI flash. You must edit the board header file (where the environment is setup), the device tree to make sure the console will be set to the correct uart, and it looks like update the defconfig to not boot from SPI flash as well. Build the project, flash it to the SPI flash, and hope it works. I'm assuming you need the congatec dev board to work through this because if you brick u-boot using the on SOM runtime flash procedure, you won't be able to fix it.

[engconcepts]

On the default SPI bootcontainer that came with the SMX8P SMARC module, it would default to trying to boot off the net with BOOTP.  If I had the SD card installed that had the kernel image on it, the SPI boot loader would grab the kernel off the SD card.  In order to boot directly from the SD card with the Boot Select switches, both the kernal and bootcontainer had to be copied to the SD card.  I was also able to copy the bootable SD card to the onboard eMMC and was able to boot directly off of it when the corresponding Bool Select switches were set.

[spetroce]

Very interesting that you are working on this becuase I am also trying to do the exact same thing (with UART1, ie. ttymxc0) with the Q7 form factor version of this SOM. I changed the device tree files, the u-boot board files, and the machine config file in the yocto project. After all of this, I do get a prompt after boot on startup, but all of the u-boot and kernel output is still coming out of the uart2 debug port. I am in the thick of it right now and figuring it out, so I can't offer any solutions yet. Given that I have literally changed everything throughout yocto and u-boot from uart2 to uart1, it is very strange that something could still be coming out the uart2 port. This only leads me to believe that settings are being loaded either from onboard flash or from somewhere else in u-boot. Please let me know if you figure anything out.

[spetroce]

I have replaced every instance of "Booting from mmc ..." with "Boooting from mmc ..." within u-boot, flashed the wic image to the SD card, and I still get "Booting from mmc ...". So this definetly tells me something is being loaded outside of the SD card. I tried setting CONFIG_ENV_IS_IN_SPI_FLASH=n, but I get the same result.