We have built a custom board using Rev 2.0 of the LS1021A in which the UART pins are not accessible.
Our goal is to boot from SPI flash and interact with U-Boot through LPUART.
Since the Linux SDK for LS1021A v0.4 does not support building a PBL for SPI flash, we have built our own. Our PBL is based on the one shipped in IFC NOR Bank 0 of the TWR board but modified with our custom RCW and a "Boot Location Pointer" of 40001000 (offset 0x1000 of SPI flash).
Our PBL is as follows:
08080010 00000000 00000000 10000000
10000000 08007922 60025A00 81046000
00000000 00000000 00000000 2003E800
00004504 24BB3140 00000000 00000000
After applying a 64-bit byte swap to the PBL before programming (as suggested in this post), the LS1 is able to successfully read in the PBL, verify the CRC, jump to the boot entry location, and read about 3KB of the U-Boot built from the Linux SDK for LS1021A v0.4 with no modifications (other than setting UBOOT_CONFIG ??= "qspi" in meta-fsl-arm/conf/machine/ls1021atwr.conf).
At this point in the boot process, reading from SPI flash has ceased, nothing has come out of LPUART, and LPUART is unresponsive.
We are unsure whether this means that something went wrong or that U-Boot is waiting for input over UART.
If you have any advice or insight into the build process or SPI booting with LPUART enabled, we would greatly appreciate it.
Thank you in advance!
After getting in touch with Freescale/NXP, we were directed to rcw_1000_qspiboot_swap.bin in version 1.9 of the SDK.
From this file, we were able to determine the two PBI's necessary for booting from QSPI:
After completing these changes, everything looks to be working correctly.
When configured to boot from the SD card, we can #define CONFIG_LPUART in include/configs/ls1021atwr.h and successfully communicate over LPUART so we are not having a problem with LPUART in general (just when booting from SPI).
And we aren't certain that our problem is even LPUART based. It could be that the binary built as a result of bitbaking u-boot with the UBOOT_CONFIG ??= "qspi" setting in meta-fsl-arm/conf/machine/ls1021atwr.conf isn't actually compatible with the LS1021 yet. This is especially possible since we haven't been able to verify that anyone has successfully booted this way before.
what changes u have did in RCW for enabling LPUART(the values of UART_BASE and UART_EXT field = ?) for SD card u-boot image.I tried to to enable LPUART by giving UART_EXT=100 , 001 ,010 . But none is working. Do u have done any other changes in RCW or U_BOOT.
What about Rev 1.0 ?
I am also having an LS1021A Rev1.0 based reference board. By default, LPUART1 is disabled (pins are multiplexed with UART2). The console is coming from UART1. Whenever I tried to enable LPUART1 by changing RCW, (to a combination of UART1 and LPUART1 enabled, and UART2 disabled) the console is not coming from UART1 for U-boot. But kernel prints are coming through UART1 itself, but again file system prints are not coming. And neither through LPUART1 (verified by probing).
I have tried different RCW field values for this UART_EXT field , but only the default combination (000) is working. No other combinations are working which will enable LPUART1.
Any idea ?
Because your post is a response to the post in which I describe that LPUART works when booting from the SD Card, I assume you're asking in the context of booting from SD.
We set UART_EXT to 100. But you will also need to set UBOOT_CONFIG ??= "sdcard" in meta-fsl-arm/conf/machine/ls1021atwr.conf and add #define CONFIG_LPUART in include/configs/ls1021atwr.h before you have a U-Boot formatted for SD which communicates over LPUART1.
Building u-boot (cleansstate, patch, compile, bitbake) with no source modification using Linux SDK for LS1021A v0.4, applying the same 64-bit byte swap to it, and placing it at offset 0x1000 after the PBL above does not work. After reading the PBL and jumping to 0x1000, the LS1 reads 96 bytes of SPI flash before stopping.
Repeating the same process, but with the 64-bit byte swap only on the PBL (not on the U-Boot), fails but reads 3344 bytes before stopping.
In both cases, nothing is shown over LPUART.