iMX8ULP - change u-boot serial console from UART5 to UART4

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

iMX8ULP - change u-boot serial console from UART5 to UART4

跳至解决方案
793 次查看
fTL
Contributor II

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

1 解答
388 次查看
fTL
Contributor II

**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

在原帖中查看解决方案

7 回复数
389 次查看
fTL
Contributor II

**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

604 次查看
wacampbell
Contributor I

Hi, I am also trying to change the serial console from UART5 to UART7.

I've tried the same steps and I'm seeing the same results.

Any updates on this?

0 项奖励
回复
714 次查看
Alejandro_Salas
NXP TechSupport
NXP TechSupport

Hello @fTL 

Could you please share your BSP version?

I need to test it by my side.

 

Best regards,

Salas.

0 项奖励
回复
665 次查看
fTL
Contributor II
Hello, Alejandro!

Is there a solution?

Thanks,
Alex
0 项奖励
回复
630 次查看
Alejandro_Salas
NXP TechSupport
NXP TechSupport

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.

0 项奖励
回复
702 次查看
fTL
Contributor II
Hello, Alejandro!

rel_imx_6.1.55_2.2.0

Thanks,
Alex
0 项奖励
回复
788 次查看
fTL
Contributor II

Image with a default serial console (UART5) is loading without troubles.

0 项奖励
回复