LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Boot Hello, We are bringing up a custom LS1046A board based on the LS1046ARDB design. Autonomous cold boot is failing, but CodeWarrior/QCVS intervention allows the processor to reach BL2, BL31 and the U-Boot console. We have observed the cold-boot failure with eMMC, SD card and QSPI NOR, so we would appreciate guidance on isolating the common reset/clock/PBL path. Platform and differences from LS1046ARDB Item Custom-board configuration Processor LS1046AE Rev. 1.0; U-Boot reports SVR 0x87070010 Power/reset control No CPLD. An STM32 BMC, PCA9539 I/O expander, level translators and discrete reset circuitry implement sequencing and SD/eMMC selection. DDR 4 GiB, single-rank, 64-bit non-ECC DDR4, initialized at 1600 MT/s. This differs from the 8 GiB ECC configuration used in our RDB comparison. DDR initialization succeeds after assisted boot; full memory-margin qualification is still pending. Clocks 100 MHz primary reference; the working assisted configuration uses the single-ended SYSCLK selection. DDR uses the differential reference path. U-Boot reports CPU 1800 MHz, platform 600 MHz and FMan 700 MHz. eMMC Macronix MX52LM08A11XVI, different from the RDB device. U-Boot identifies manufacturer 0xc2, name M08A11, MMC 5.1 and approximately 7.3 GiB user capacity. SD/eMMC interface BMC-controlled selection and EVDD: 1.8 V for eMMC and 3.3 V for SD. QSPI NOR S25FS512S, 64 MiB per device. NOR detection has succeeded on this board. Other peripherals Custom Ethernet/PHY routing and SerDes configuration; no PCIe devices are used. Software A1-specific board/device-tree changes, TF-A v2.12.0 based on lf-6.12.49-2.2.0, U-Boot 2025.04. U-Boot watchdog is disabled for bring-up. The reset network has also been reworked during this investigation: a competing processor-POR driver branch was isolated, the direct BMC-to-TRST drive was disconnected, and a hardware POR/TRST coupling path was fitted. HRESET sensing by the BMC remains connected. Latest native cold-boot observation We found and corrected an unintended earlier SoC reset in the BMC sequence. In the subsequent scope capture, taken from a fully powered-off start without any CodeWarrior or QCVS action: - PORESET_B rises when the BMC releases processor reset. - eMMC CLK and CMD activity starts after that edge. - No normal BL2/U-Boot console output follows. Some earlier attempts produced only a junk UART character. - The trace labelled HRESET_B stays HIGH, approximately 1.8 V; we do not observe a LOW assertion before or during the captured eMMC activity. The BMC HRESET input also repeatedly reads HIGH. CodeWarrior/QCVS behavior During the cold-boot stall, CodeWarrior Inspect can report that 'CortexA72#0' is not found on the JTAG chain and suggest checking the RCW or enabling RCW override. However, clicking Debug with RCW apply enabled, or applying the RCW through QCVS, allows boot to progress. Sometimes Debug reports “core not in debug mode” while the UART reaches U-Boot. In other attempts the target is halted and `continue` allows boot to finish. We reduced the initialization script to: from cw.dbg import ta def run_init_file(): target = ta.create() target.rcw.set_source(0x40) target.rcw.set_data({13: 0x00004504}) target.rcw.apply() The physical straps were set for SD/eMMC source '0x40'. The supplied word 13 is identical to the value already stored in eMMC. This reduced script also enabled assisted boot. Separate tests using 'set_source(0x9E)' with the same word succeeded as well. There are no explicit DDR initialization, BRR, PC, SCTLR or resume operations in this reduced script. We recognize that 'rcw.apply()' and the debugger launch framework can still perform internal reset/run-control operations; this is not a passive attach. After assistance, all 16 RCWSR words matched the intended media RCW. BL2 was present in OCRAM and the instrumented boot chain completed DDR initialization, eMMC/FIP loading, BL31 and U-Boot. Post-intervention 'RSTRQPBLSR' reads were zero, but we do not regard those as a capture of the original cold-failure state. Tests already performed Test Observation Native boot from eMMC No autonomous console boot; debugger-assisted recovery reaches U-Boot. Native boot from SD Similar cold-boot failure despite BMC detecting/selecting SD; assisted boot was possible. Native boot from QSPI NOR Latest testing also shows the cold-boot failure. We have not established that all three media stop at the same internal stage. Standalone hard-coded source straps 0x9E and 0x9F Later tests did not obtain the expected standalone reset progression. We understand that a hard-coded RCW alone is not a complete U-Boot image. Stock RDB initialization with safe RCW enabled Allowed recovery, but also modifies DDR, CPU state and peripherals, so this was not an isolated test. Minimal apply-only script above Recovery possible even with word 13 equal to the stored value, using source requests 0x9E and 0x40. QCVS RCW test/readback Test passed and readback matched the intended configuration after intervention. Native fetch remains unverified. Removed three inherited PCIe PBI accesses No improvement in native cold boot. Disabled SerDes2, then both SerDes blocks No improvement. Assisted U-Boot logs confirmed the modified RCW words. DDR diagnostic SPD read and 4 GiB initialization at 1600 MT/s succeeded after assistance; not a full margin test. Added BL2/BL31/U-Boot milestone logging Assisted boot completes all stages. Native failure gives no first BL2 milestone; these logs cannot trace the hardware PBL itself. eMMC RCW and image placement The eMMC baseline with both SerDes enabled is: 0c100012 0e000000 00000000 00000000 13335a06 40400012 60040000 c1000000 00000000 00000000 00000000 0001c83e 00004504 24001002 00000096 00000001 For the both-SerDes-disabled experiment, only these words changed: RCW05 = 00000000 RCW06 = 00f00012 In the eMMC user area, with 512-byte sectors: Component Start LBA Byte offset RCW + PBI + BL2 container (bl2_emmc.pbl) 0x8 0x1000 FIP containing BL31 and U-Boot 0x800 0x100000 FMan microcode 0x4800 0x900000 The written PBL/BL2 and FIP regions were read back and their SHA-256 values matched the files transferred for those tests. The PBI stream was decoded and its CRC checked. It sets the OCRAM boot location, performs inherited NXP interconnect/USB preparation and PBL synchronization operations, and copies BL2 into OCRAM. Removing the PCIe-register accesses did not resolve the stall. DDR initialization is performed later by BL2. We also read eMMC `EXT_CSD[162] = 0x00` and `EXT_CSD[179] = 0x00`; we have not made irreversible changes to those settings. Guidance requested 1. HRESET timing: At exactly which point should LS1046A assert HRESET_B LOW relative to PORESET_B, valid reference clocks and initial eMMC transactions? If processor-side probing confirms no LOW assertion, which reset, clock, power-domain, strap or test-mode conditions should we check first? 2. Capture before intervention: Is there a supported CodeWarrior/CCS System Access Port procedure to read the stalled PBL/DCFG/eSDHC state before the A72 core is discoverable, without reset or RCW override? Please provide the required access context, commands and most useful status/error registers. 3. RCW apply semantics: What precisely does `rcw.apply()` do with source `0x40` or `0x9E` and only one supplied word? Which reset/debug controls are exercised, and how are unspecified RCW words obtained? We want to identify the action that permits recovery when the supplied word does not change the resulting RCW. 4. RCW/PBI review: Do the eMMC RCW and placement above reveal any issue? Are there additional mandatory PBI operations or relevant silicon errata for this custom configuration? 5. Next decisive measurement: Given the symptom across eMMC, SD and QSPI, what measurement or non-invasive register capture would best separate a reset/clock/strap problem from boot-medium initialization, RCW acquisition or later PBI execution? Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo @Hiran_E_H
HRESET_B is not being asserted in the waveform, which is not expected.
Please refer to Section 5.1 (Bring-up Process Using SD Card) in AN12081. Although the document describes the SPL/U-Boot flow, the current BL2/BL31 flow follows a very similar hardware boot sequence. Please compare your waveform with Figure 3.
Based on the current observations, suspect a hardware issue related to reset related part. It may also be helpful to compare your reset design against the FRWY-LS1046A, which does not use a CPLD.
In addition, please verify the ASLEEP signal, as it is an important signal during the boot process.
Thanks. Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo sequence capture during testing Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo Hello, Thank you for pointing us to LS1046A Reference Manual section 4.4.1. We are checking steps 1–4 as well as steps 5–15, and comparing our measurements with AN12081 section 5.1 / Figures 3–4. Below is an update from our 29 September tests, with a 30 September follow-up on the QCVS-generated SD candidate. We will attach oscilloscope captures of PORESET_B, HRESET_B, SD CMD and RESET_REQ_B for review. Updated HRESET observation On a second A1 custom board, initially tested without the earlier board's reset reworks, we can observe HRESET_B going LOW before PORESET_B is released. This differs from the earlier capture where HRESET_B appeared continuously HIGH. We are not treating that earlier waveform as representative of this board. For the current differential-clock SD test: During standalone cold startup, HRESET_B is LOW before PORESET_B rises and remains LOW afterward. No BL2 console output appears. After CodeWarrior Debug/RCW apply, HRESET_B goes HIGH. The debugger initially stops at PC=0. Clicking Continue then allows BL2 → BL31 → U-Boot to run. Please help us interpret the attached captures, including SD CMD and RESET_REQ_B activity, against the expected sequence. In below picture - we did not insert SD card - so we were able to see reset request going low. (Note in some pictures emmc cmd is mentioned by mistake instead of sd cmd) Captured with SD inserted - switch strapped to emmc/sd card mode. Captured with with poreset_b, hreset_b, reset_request, vcc1v8 with SD card insertedCaptured with with poreset_b, hreset_b, reset_request, vcc1v8 with SD card insertedCaptured with with poreset_b, hreset_b, reset_request, vcc1v8 with SD card insertedCaptured with with poreset_b, hreset_b, reset_request, vcc1v8 with SD card insertedCaptured with with poreset_b, hreset_b, reset_request, vcc1v8 with SD card inserted Captured with with poreset_b, hreset_b, reset_request, sd_cmdCaptured with with poreset_b, hreset_b, reset_request, sd_cmdCaptured with with poreset_b, hreset_b, reset_request, sd_cmdCaptured with with poreset_b, hreset_b, reset_request, sd_cmdCaptured with with poreset_b, hreset_b, reset_request, sd_cmd Captured with with poreset_b, hreset_b, sd_cmd, trst_b(jtag reset)Captured with with poreset_b, hreset_b, sd_cmd, trst_b(jtag reset)Captured with with poreset_b, hreset_b, sd_cmd, trst_b(jtag reset)Captured with with poreset_b, hreset_b, sd_cmd, trst_b(jtag reset)Captured with with poreset_b, hreset_b, sd_cmd, trst_b(jtag reset) Captured after entering debug mode after cold start stallCaptured after entering debug mode after cold start stallCaptured after entering debug mode after cold start stallCaptured after entering debug mode after cold start stallCaptured after entering debug mode after cold start stall New SD RCW test We kept external SD/MMC boot selected (cfg_rcw_src=0x40) and generated a new SD image with both SerDes blocks disabled. We selected the 100 MHz differential primary reference and adopted the active clock ratios from the hard-coded 0x9F example, while retaining the A1 pinmux and SD boot/PBI configuration. This is not hard-coded boot: the full RCW and PBI must still be fetched from SD. We are not bypassing media acquisition or PLL locking. Setting Value Primary reference DIFF_SYSCLK/B, nominal 100 MHz; cfg_eng_use0=0 A1 switch positions SW5 pole2 ON(differential clock selection ); SW8 poles1–8 0010 0000 (1=ON)(boot source switch strap) SYS_PLL_RAT 4 → platform 400 MHz CGA_PLL1_RAT 13 → CPU 1300 MHz CGA_PLL2_RAT 10 → PLL2 1000 MHz; FMan 500 MHz MEM_PLL_RAT 16 → DDR 1600 MT/s DDR_REFCLK_SEL / DDR_FDBK_MULT 1 / 2; differential DDR reference SRDS_PRTCL_S1 / SRDS_PRTCL_S2 0 / 0 SRDS_PLL_PD_S1 / SRDS_PLL_PD_S2 3 / 3; both PLLs down in each SerDes block PBI_SRC / BOOT_HO 6 / 0 EVDD_VSEL 2, SD 3.3 V configuration DIMM 4 GiB, single-rank, 64-bit non-ECC DDR4; training seed not margin-qualified The full RCW used in this tested image, also confirmed after debugger intervention, is: RCW01–04: 0810000d 0a000000 00000000 00000000
RCW05–08: 00000000 00f00012 60040000 c1000000
RCW09–12: 00000000 00000000 00000000 0001c83e
RCW13–16: 00004504 24001102 00000096 00000001 Result: the native cold-boot stall remained. After debugger assistance, U-Boot reported CPU 1300 MHz, platform 400 MHz, DDR 1600 MT/s and FMan 500 MHz, matching the intended ratios. SD initialization and FIP loading succeeded. Exact debugger intervention and resulting state The initialization callback only calls the following RCW API operations: from cw.dbg import ta
def run_init_file():
target = ta.create()
target.rcw.set_source(0x40)
target.rcw.set_data({13: 0x00004504})
target.rcw.apply() Word 13 is identical to the value already stored on SD. The script has no explicit DDR initialization, BRR/PC writes or Continue command. We recognize that apply() and debugger startup can internally change reset/debug state. After Debug, before Continue, we read: PC = 00000000
PORSR1 @ 01ee0000 = 205b7fff
RSTRQPBLSR @ 01ee00b4 = 00000000
RSTRQMR1 @ 01ee00c0 = 00004000
RSTRQSR1 @ 01ee00c8 = 00000000
BRR @ 01ee00e4 = 00000000
SCFG_SCRATCHRW0/1 = 00000000 / 10000000
DDR SDRAM_CFG = 07000000 (MEM_EN clear) All 16 RCWSR words matched the tested SD image. The first 64 bytes at OCRAM 0x10000000 matched its BL2 entry code. Thus the lack of UART output at PC=0 did not mean that hardware PBL had not progressed. Continue alone was enough to run BL2/BL31/U-Boot; no manual BRR write was used in this run. These are post-intervention readings, not preserved native-stall status. We are not using their zero error values to conclude that the original cold attempt had no PBL/clock/reset error. Image placement and exact PBI setup Both our SD and eMMC packages use 512-byte sectors: RCW/PBI/BL2 .pbl: LBA 0x8, byte offset 0x1000. fip_uboot.bin containing BL31 and U-Boot: LBA 0x800, byte offset 0x100000. For eMMC these are offsets in the user area, not boot0/boot1. The SD whole-disk image has been checked byte-for-byte at these offsets; the earlier eMMC writes also passed readback SHA-256 verification. The exact setup stream in the tested SD PBL is below. Each row is the serialized PBI command word followed by its data word, in stream order; these are not debugger memory-write commands: 09570600 00000000
09570604 10000000
09570178 0000e010
09180000 00000008
09570418 0000009e
0957041c 0000009e
09570420 0000009e
09570158 00001000
09610000 00000000
096100c0 000fffff
09570604 10000000
09570158 00001000
096100c0 000fffff This includes the scratch boot pointer, inherited interconnect/USB setup, flush and synchronization operations. Repeated operations are preserved. There are no PCIe setup writes. The stream then contains 844 ACS64 transfers to OCRAM: the 53,953-byte BL2 plus 63 zero-padding bytes. The tested PBL ends with 08610040 6d8bdebf (END/CRC), and its total size is 57,576 bytes. We also independently generated a PBL using QCVS today. Parsing and CRC verification found its PBI operations and BL2 payload identical to the tested image. We deliberately changed RCW12 from 0001c83e to 0001a8fe (ASLEEP=0, RTC=1, IRQ_BASE=63); only that word and the CRC differ. Its SHA-256 is: 2d3389fce4ead088957caf6251022b5526be8565e812a8aab8fce21bd8923277 30 September update: we tested the newer QCVS-generated SD candidate and again encountered a native cold-boot stall. Replacing the PBL with the actual QCVS export therefore did not resolve the symptom. Its PBI and BL2 payload remain identical to the previous image, so this does not exclude a shared configuration issue or prove that the cause is hardware. The detailed HRESET/register readings and confirmed assisted-success sequence above refer to the earlier RCW12=0001c83e run. The debugger-recovery result and detailed waveforms for this latest RCW12=0001a8fe run have not yet been added to this update. Guidance requested With HRESET_B asserted before POR release but remaining LOW afterward, which measurements best separate an RCW-fetch/validation failure from PLL locking or the platform-clock switchover in steps 11–14? We will also continue checking the early power/clock/strap conditions in steps 1–4. Since step 15 releases the SoC's HRESET drive and step 17 executes PBI, is it reasonable to prioritize the earlier stages, provided we exclude an external HRESET driver or a brief release/reassertion? Please also review the RCW and PBI above for any missing or incorrect configuration. Can CCS/SAP access native reset/PBL status or documented PLL-lock status while HRESET remains LOW, without RCW apply or another reset? Please provide the exact access context, commands and register/bit definitions. Ordinary Inspect has previously failed to find CortexA72#0 in this state. What precisely does set_source(0x40) plus a matching word-13 override and apply() do to reset, TRST and debug controls? We would like to isolate the action that allows boot without changing the final RCW contents. We can provide the generated PBL, complete UART/debugger logs and additional scope captures. Bring-up is blocked on autonomous cold boot, so guidance on the next discriminating test would be greatly appreciated. Also I was told as a self-test , if we strap 0x9e or 0x9f without SD card or blank emmc - we will be able to see HRESET_B going low to high when POREST_B is released from 0 to 1. We tried capturing this in RDB board and was able to observe this . So on our custom board if we do the same - same behaviour is to be observed? Thank you. Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo @Hiran_E_H
Please refer to LS1046A Reference Manual, 4.4.1 Power-on reset sequence
There may be an issue between steps 5 and 15.
Since the starting point of HRESET_B cannot be clearly identified, steps 1 to 4 should also be checked.
Thanks Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo ASLEEP is always high as LED connected is always ON. We took a second board without any hardware rework and tried to boot from SD card with same RCW except change in voltage selection and is observing HRESET_B is being low before PORESET_B is released from low to high. The spike in HRESET_B - we are expecting is due to 1.8v pull up after PMIC PG and SoC starts driving the HRESET_B low. Currenltly we are probing to see emmc/SD CMD, DATA and CLK to see if there is any transaction is occuring. May I know what conditions to be obeyed for SoC to release HRESET_B. Out of Curiosity we put the same SD card in the a ls1046a_rdb board and tried powering ON which reached upto uboot console. Re: LS1046A custom board: cold boot fails from eMMC, SD and QSPI; CodeWarrior RCW apply enables U-Bo Hi @Hiran_E_H
1.It is difficult to clearly distinguish between an RCW loading issue and a PLL lock issue based on the current information. However, if CCS can successfully access the device and the PLL-related waveforms appear normal, the likelihood of a PLL issue may be lower. I would recommend comparing the SD command waveforms between a standalone cold boot and a CCS-assisted boot. In particular, compare the waveform duration and sequence to determine whether there are any abnormalities during RCW loading. You may also refer to the Reference Manual, Table 4-8 "RCW State Timing", to check whether the SD card clock reflects the expected frequency transitions during the boot process. Please note that these transitions depend on both successful RCW loading and proper PLL lock.
2.Yes, I agree with your approach. Based on the information available, it is reasonable to focus on steps 1 through 15 first, especially the early power, clock, reset, and boot-source related stages.
3.You may try the CCS commands below to verify whether the LS1046A can be accessed while the device remains in this state. For example, you can attempt to read the RCWSR registers:
(bin) 1 % delete all
(bin) 2 % config cc cwtap
(bin) 3 % show cc
(bin) 4 % ccs::config_chain {ls1043a dap sap2}
(bin) 5 % display ::ccs::get_config_chain
(bin) 6 % ccs::display_mem 32 0x01ee0000 4 0 100
Show more lines
4.You may also refer to the Reference Manual, Table 4-8 "RCW State Timing", and observe whether the SD card clock reflects the expected frequency changes during RCW processing.
I would recommend verifying the associated waveforms during the boot sequence. In practice, I typically use the HARD-CODED mode during initial debugging. As an additional check, you could configure the board to use a hard-coded RCW and verify whether the observed waveforms follow the sequence described in Figure 4-1 "Power-on Reset Sequence". If the waveforms match the expected behavior, the reset-related hardware design is generally likely to be functioning correctly.
I will be OoO for more than one week, so there will be no updates from my side during this period.
If this issue is urgent, please create a new thread so that another team member can assist you.
Thank you.
記事全体を表示
