Hello to all of you!
We would like to change the default serial console from UART5 to UART4. It is a custom board but very similar to imx8ulp-evk.
I changed several thing in that direction:
imx8ulp-evk.dts (lpuart5 -> lpuart4 and pin control)
imx8ulp-evk-u-boot.dtsi (lpuart5 -> lpuart4)
u-boot - .\include\configs\imx8ulp_evk.h (ttyLP1->ttyLP0)
layer - \meta-freescale\conf\machine\include\imx8ulp-evk.inc (SERIAL_CONSOLES = "115200;ttyLP1" -> SERIAL_CONSOLES = "115200;ttyLP0")
imx-atf - \imx-atf\plat\imx\imx8ulp\include\platform_def.h (#define IMX_LPUART_BASE IMX_LPUART5_BASE -> #define IMX_LPUART_BASE IMX_LPUART4_BASE)
\conf\local.conf - ATF_BOOT_UART_BASE = "0x29390000"
I have got 13%2:1>Fail HID(W):LIBUSB_ERROR_PIPE(8.647s) during uuu -v SDPS: boot -scanterm -f core-image-minimal-imx8ulp-lpddr4-evk.wic.zst/* -scanlimited 0x800000
What am I missing?
Thanks,
Alex
已解决! 转到解答。
**The Solution Unveiled!**
No amount of forehead-flattening frustration will solve this task, save for relentless digging and perhaps a curse or two per minute...
Regardless of your modifications in the device tree(s), if the PCC LPUART4 Register (PCC_LPUART4) isn't properly configured, any attempt to write to LPUART4 will throw an exception. This is why `uuu` halts with a LIBUSB_ERROR_PIPE, essentially a STALL event indicating no response from the other end.
BTW I enabled both UART4 and UART5 in the u-boot device tree.
With invaluable help from a knowledgeable friend (thankfully, such expertise still exists), we discovered that attempting to read from one of LPUART4's registers (`__raw_readl(0x29390010);`) in the Secondary Program Loader (SPL), while UART5 was set as the default serial console, resulted in an exception, stalling `uuu`. The issue was resolved by enabling the clock source for LPUART4 with `__raw_writel(0xd2000000, 0x292D00E4);`.
Although we thought the issue was pinpointed, our investigation continued.
The clock initialization within `lpuart_serial_probe` (located in `serial_lpuart.c` for the iMX8ULP serial driver) should work when CONFIG_CLK=y, but it didn't or I missed something ..
Our digging led us down the clock configuration path where we stumbled upon what might as well have been a magic number:
- In `/arch/arm/include/asm/arch-imx8ulp/imx-regs.h`, line 50:
```c
#define LPUART_BASE LPUART5_RBASE
```
- Similarly, this was mirrored in the ATF firmware:
`/plat/imx/imx8ulp/include/platform_def.h`, line 72:
```c
#define IMX_LPUART_BASE IMX_LPUART5_BASE
```
To fully resolve this, you must update the device trees (both the board `.dts` and `*-u-boot.dtsi` files), and modify these two files to reflect the chosen LPUART. Also, ensure to review SPL-related files for any IO conflicts with your selected LPUART.
That's the crux of it.
- Alex
**The Solution Unveiled!**
No amount of forehead-flattening frustration will solve this task, save for relentless digging and perhaps a curse or two per minute...
Regardless of your modifications in the device tree(s), if the PCC LPUART4 Register (PCC_LPUART4) isn't properly configured, any attempt to write to LPUART4 will throw an exception. This is why `uuu` halts with a LIBUSB_ERROR_PIPE, essentially a STALL event indicating no response from the other end.
BTW I enabled both UART4 and UART5 in the u-boot device tree.
With invaluable help from a knowledgeable friend (thankfully, such expertise still exists), we discovered that attempting to read from one of LPUART4's registers (`__raw_readl(0x29390010);`) in the Secondary Program Loader (SPL), while UART5 was set as the default serial console, resulted in an exception, stalling `uuu`. The issue was resolved by enabling the clock source for LPUART4 with `__raw_writel(0xd2000000, 0x292D00E4);`.
Although we thought the issue was pinpointed, our investigation continued.
The clock initialization within `lpuart_serial_probe` (located in `serial_lpuart.c` for the iMX8ULP serial driver) should work when CONFIG_CLK=y, but it didn't or I missed something ..
Our digging led us down the clock configuration path where we stumbled upon what might as well have been a magic number:
- In `/arch/arm/include/asm/arch-imx8ulp/imx-regs.h`, line 50:
```c
#define LPUART_BASE LPUART5_RBASE
```
- Similarly, this was mirrored in the ATF firmware:
`/plat/imx/imx8ulp/include/platform_def.h`, line 72:
```c
#define IMX_LPUART_BASE IMX_LPUART5_BASE
```
To fully resolve this, you must update the device trees (both the board `.dts` and `*-u-boot.dtsi` files), and modify these two files to reflect the chosen LPUART. Also, ensure to review SPL-related files for any IO conflicts with your selected LPUART.
That's the crux of it.
- Alex
Hello @fTL
Thank you for your patience, I am still trying to get it works, I am having the same issue as you. I am checking if the upower of ELE firmware are related to this issue.
I will let you know when I have an update.
Best regards,
Salas.