Help. LS1046A won't boot after loading PBI. Suggestions?

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

Help. LS1046A won't boot after loading PBI. Suggestions?

1,408件の閲覧回数
AbelianMeme
Contributor III

Hello everyone. I am trying to get an LS1046A to boot on a custom board design. The RCW and PBI are being loaded from QSPI. By trial and error I found out I need the byte swapped version of the compiled RCW file. Through the scope I can watch the CPU load this entire file over SPI. However, it never proceeds to load u-boot.

I have used the QSPI .rcw file from the ls4096ardb, with minor changes to disable all of the Serdes lines. I will need PCIe later, but right now I just want to get it to boot. Below is the RCW configuration I am using.

The LS1046A loads the entire rcw+pbi bin file, and I have verified all bytes are transferred correctly across the SPI bus, including the CRC. The basics, such as making sure the CONT bit is cleared on the final transfer are all correct, as is readily seen because the CPU stops loading.

But the CPU simply does not proceed to loading the u-boot binary. I know it does nothing because it never tries to access the SPI bus again with the 0x40100000 address. ASLEEP is asserted, and a few hundred milliseconds later it resets and starts all over again.

I have no idea what might be wrong at this point. I have disabled all the Serdes lines and PLL's, and still nothing proceeds. I can watch on the scope when the SPI bus speeds up, so I know the PLL is locking and the system is switching from SYS_CLK to the PLL. Can anyone suggest what else I can try? I have changed everything I can think of. Nothing makes a difference. The CPU just stubbornly won't proceed after the PBI stage.

Thank you for any assistance. It is very frustrating.

 

P.S. Please note I have removed several PBI modules from the default LS1046ARDB example. They make no difference to the problem I am facing. I removed anything unnecessary during troubleshooting.

----------------

#include <ls1046a.rcwi>

%littleendian64b=1
%dont64bswapcrc=1

SYS_PLL_RAT=6
MEM_PLL_RAT=21
CGA_PLL1_RAT=16
CGA_PLL2_RAT=14
SRDS_PLL_PD_S1=3
SRDS_PLL_PD_S2=3
SRDS_PRTCL_S1=0
SRDS_PRTCL_S2=0
SRDS_PLL_REF_CLK_SEL_S1=0
SRDS_PLL_REF_CLK_SEL_S2=0
SRDS_DIV_PEX_S1=0
SRDS_DIV_PEX_S2=0
DDR_FDBK_MULT=2
DDR_REFCLK_SEL=0
PBI_src=4
IFC_MODE=37
HWA_CGA_M1_CLK_SEL=6
DRAM_LAT=1
SPI_EXT=1
UART_BASE=7
IFC_GRP_A_EXT=1
IFC_GRP_D_EXT=1
IFC_GRP_E1_EXT=1
IFC_GRP_F_EXT=1
IRQ_OUT=1
TVDD_VSEL=1
DVDD_VSEL=2
EVDD_VSEL=2
IIC2_EXT=1
SYSCLK_FREQ=600
HWA_CGA_M2_CLK_SEL=1

/* Set BOOTLOCPTR to 0x0040100000 */

.pbi
write 0x570600, 0x00000000
write 0x570604, 0x40100000
.end

 

#include <cci_barrier_disable.rcw>

/*  cci_barrier_disable.rcw

 *.pbi
 * write 0x570178, 0x0000e010
 * write 0x180000, 0x00000008
 * .end

*/


#include <a009531.rcw>

/*  a009531.rcw

 * .pbi
 * write 0x570158, 0x00000300
 * flush
 * awrite 0x400098, 0x00000000
 * awrite 0x500098, 0x00000000
 * awrite 0x600098, 0x00000000
 * .end
*/


#include <qspi_endianness.rcw>

/* qspi_endianness.rcw

 * .pbi
 * /* QSPI END_CFG 64 bit LE -/
 * write 0x550000, 0x000f400c
 * .end
*/

 

 

0 件の賞賛
4 返答(返信)

1,401件の閲覧回数
ufedor
NXP Employee
NXP Employee

In the RCW the followinf line has to be commented out:

#include <a009531.rcw>

This line addresses the Erratum A-009531 which affects PCIe.

When SRDS_PRTCL_S1=0 and SRDS_PRTCL_S2=0 all PCIe controllers are disabled and any access to them will stall the SoC.

1,395件の閲覧回数
AbelianMeme
Contributor III

Hi Ufedor.

 

Thank you for the suggestion. Unfortunately, removing that PBI section did not have any effect. The CPU still fails to boot.  Is there anything else that could be wrong?

Under what other circumstances will it not proceed to load the boot file?  I have tried to strip away as much as I possibly can. It simply will not proceed beyond loading the RCW+PBI commands. It does that reliably.

 

 

0 件の賞賛

1,389件の閲覧回数
ufedor
NXP Employee
NXP Employee

Please provide latest SPI binary image for inspection.

0 件の賞賛

1,378件の閲覧回数
AbelianMeme
Contributor III

Hi ufedor.

 

We found the problem. It was on our end. The problem was insufficient pullup on the HRESET_B line. It was remaining low and holding the chip in reset. Once we corrected this the chip now proceeds to read the boot program from the flash.

 

Thank you for your assistance.

0 件の賞賛