hard reset fails with qspi boot

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

hard reset fails with qspi boot

2,218 Views
timmartin
Contributor I

Using a LS1046AE (Rev 1.0) hard reset fails (hangs) when booting from QSPI, works fine when booting from SDHC. ~RESET_REQ signal reasserts 2.4uS after initially deasserting, causing hang. See attahment for more details.

Labels (1)
0 Kudos
10 Replies

1,147 Views
norihiromichiga
Senior Contributor I

Hello folks, 

 

Recently, we faced the similar issue on custom LS1046A board.  Here is brief summary of our findings. 

1) LS1046A board with SD boot(whole system image including RCW in SD)

 -> After Linux started, asserting HRESET pin caused the system restart.

2) LS1046A board with QSPI boot(whole system image including RCW in QSPI)

-> After Linux started, HRESET pin couldn't work.  (System don't restart)

Note, atf is used for this system.

 

We know there are known errata A-010539 which prevents HRESET pin from operating and

we already disabled this workaround from u-boot.

After investigation on this system, we found that errata was still applied to QSPI boot image in the following code.

(This code may be slightly older version than one in the latest LSDK)

/yocto-sdk/build_ls1046afrwy/tmp/work/ls1046afrwy-fsl-linux/atf/git-r0/git/plat/nxp/soc-ls1046/soc.c

I don't know if your case is the same as ours, but it may be worth to check this code also.

 

Regards,

Norihiro Michigami

AVNET 

 

0 Kudos

1,784 Views
zengcl2
Contributor I

hi,timmartin,

Have you solved the problem(hard reset fails with qspi boot)?I have the same problem in LS1021ATWR board,if you solved the problem,please help me .

0 Kudos

1,860 Views
ufedor
NXP Employee
NXP Employee

Please use a digital scope and check the RCW readout behaviour in the described case.
Compare the QSPI RCW readouts for the problem and POR cases.

0 Kudos

1,860 Views
timmartin
Contributor I

Ufedor,  

I've looked at the RCW values between the two cases. See below.

The differences appear to be:

PBI_SRC (bits 192-195) SDHC = 4'b0110, QSPI = 4'b0100

IFC_MODE (bits 203-211) SDHC = 9'b0_0100_0000, QSPI = 9'b0_0010_0101

PRI_SRC match the sources  (010x QSPI, 0110 SD/MMC)

IFC_MODE matches the cfg_rcw_src: SDHC = 9'b0_0100_000  QSPI =  9'b0_0100_010x

Data Below

For the SDHC case:

From the source code:
Reset Configuration Word (RCW):                                    Bit numbering
00000000: 0c150010 0e000000 00000000 00000000           0-31    32-63     64-95    96-127
00000010: 33335559 f0005012 60040000 c1000000      128-159 160-191 192-223 224-255
00000020: 00000000 00000000 00000000 0001e87e     256-287 288-319  320-351 352-383
00000030: 20004000 24660101 00000096 00000001     384-415 416-447  448-479 480-511

Read from the RCWSR0-15 at 0x1EE0100-0x1EE013C immediately after boot
Reset Configuration Word (RCW):
00000000: 0c150010 0e000000 00000000 00000000
00000010: 33335559 f0005012 60040000 c1000000
00000020: 00000000 00000000 00000000 0001e87e
00000030: 20004000 24660101 00000096 00000001

For the QSPI case:

From the source code:
Reset Configuration Word (RCW):
00000000: 0c150010 0e000000 00000000 00000000
00000010: 33335559 f0005012 40025000 c1000000
00000020: 00000000 00000000 00000000 0001e87e
00000030: 20004000 24660101 00000096 00000001

Read from the RCWSR0-15 at 0x1EE0100-0x1EE013C immediately after boot
Reset Configuration Word (RCW):
00000000: 0c150010 0e000000 00000000 00000000
00000010: 33335559 f0005012 40025000 c1000000
00000020: 00000000 00000000 00000000 0001e87e
00000030: 20004000 24660101 00000096 00000001

Snooped from the SPI bus with oscilloscope
"Tektronix MDO3024, version v1.10, serial number C012535"
"Bus Definition: SPI"
Time, MOSI, MISO
2.111470e-02, 03 00 00 00 00 00 00 00 00 00 00 00 , 00 00 00 00 00 01 EE 01 55 AA 55 AA
2.118574e-02, 03 00 00 08 00 00 00 00 00 00 00 00 , 00 00 00 00 00 00 00 0E 10 00 15 0C
2.125678e-02, 03 00 00 10 00 00 00 00 00 00 00 00 , 00 00 00 00 00 00 00 00 00 00 00 00
2.132782e-02, 03 00 00 18 00 00 00 00 00 00 00 00 , 00 00 00 00 12 50 00 F0 59 55 33 33
2.139886e-02, 03 00 00 20 00 00 00 00 00 00 00 00 , 00 00 00 00 00 00 00 C1 00 50 02 40
2.146990e-02, 03 00 00 28 00 00 00 00 00 00 00 00 , 00 00 00 00 00 00 00 00 00 00 00 00
2.154094e-02, 03 00 00 30 00 00 00 00 00 00 00 00 , 00 00 00 00 7E E8 01 00 00 00 00 00
2.161198e-02, 03 00 00 38 00 00 00 00 00 00 00 00 , 00 00 00 00 01 01 66 24 00 40 00 20
2.168302e-02, 03 00 00 40 00 00 00 00 00 00 00 00 , 00 00 00 00 01 00 00 00 96 00 00 00
2.175406e-02, 03 00 00 48 00 00 00 00 00 00 00 00 , 00 00 00 00 00 00 10 20 5C 01 57 09

This last one from the scope is byte reversed with the SPI overhead.

0 Kudos

1,860 Views
ufedor
NXP Employee
NXP Employee

Sorry, the request was to compare the QSPI RCW readouts for the problem (programmatical hard reset) and POR cases.

0 Kudos

1,860 Views
timmartin
Contributor I

Ufedor,

Apologies, I'm missing something. In the QSPI case there is only the RCW read from the POR.

In the SDHC boot situation (working) there are two RCW reads.

1) At POR

2) At Hard Reset

In the QSPI boot situation (not working) there is one RCW read.

1) At POR

When the QSPI booted hard reset occurs, the CPU hangs after the re-assertion of ~RESET_REQ.

At this point both ~RESET_REQ and ~HRESET are being driven low by the CPU.

There is no second RCW access of the QSPI.

0 Kudos

1,860 Views
ufedor
NXP Employee
NXP Employee

You wrote:

> In the QSPI boot situation (not working) there is one RCW read.

> 1) At POR

Please capture a trace showing the QSPI signals behaviour at hard reset.

0 Kudos

1,860 Views
timmartin
Contributor I

Here are some captures:

1) 1uS / div triggered as ~RESET_REQ asserts

QSPI_01.bmp

2) Same ~RESET_REQ trigger at 2mS / div

QSPI_02.bmp

3) Same ~RESET_REQ trigger at 400mS / div

QSPI_03.bmp

4) Just so we know that the QSPI signals are working; Here is a trigger on ~HRESET going high at POR.

QSPI_POR.bmp

0 Kudos

1,860 Views
ufedor
NXP Employee
NXP Employee

How HRESET_B is driven after RESET_REQ_B assertion is detected?

0 Kudos

1,860 Views
timmartin
Contributor I

There's a CPLD. It looks for ~RESET_REQ and drives ~HRESET  low for 480nS and then tri-states the driver.

CPLD logic attached.

0 Kudos