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