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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

Jump to solution
433 Views
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 Solution
28 Views
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

View solution in original post

7 Replies
29 Views
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

244 Views
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 Kudos
Reply
354 Views
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 Kudos
Reply
305 Views
fTL
Contributor II
Hello, Alejandro!

Is there a solution?

Thanks,
Alex
0 Kudos
Reply
270 Views
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 Kudos
Reply
342 Views
fTL
Contributor II
Hello, Alejandro!

rel_imx_6.1.55_2.2.0

Thanks,
Alex
0 Kudos
Reply
428 Views
fTL
Contributor II

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

0 Kudos
Reply