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.
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
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 .
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.
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.
Sorry, the request was to compare the QSPI RCW readouts for the problem (programmatical hard reset) and POR cases.
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.
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.
Here are some captures:
1) 1uS / div triggered as ~RESET_REQ asserts
2) Same ~RESET_REQ trigger at 2mS / div
3) Same ~RESET_REQ trigger at 400mS / div
4) Just so we know that the QSPI signals are working; Here is a trigger on ~HRESET going high at POR.
How HRESET_B is driven after RESET_REQ_B assertion is detected?