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

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

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

ソリューションへジャンプ
649件の閲覧回数
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 解決策
244件の閲覧回数
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 返答(返信)
245件の閲覧回数
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

460件の閲覧回数
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 件の賞賛
返信
570件の閲覧回数
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 件の賞賛
返信
521件の閲覧回数
fTL
Contributor II
Hello, Alejandro!

Is there a solution?

Thanks,
Alex
0 件の賞賛
返信
486件の閲覧回数
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 件の賞賛
返信
558件の閲覧回数
fTL
Contributor II
Hello, Alejandro!

rel_imx_6.1.55_2.2.0

Thanks,
Alex
0 件の賞賛
返信
644件の閲覧回数
fTL
Contributor II

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

0 件の賞賛
返信