codewarrior fails to write memory on LS1043A without encryption

[tom-av]

Hello,

We have a custom board based on LS1043A, boards are exactly the same, except some have the SOC module with encryption support and some without. We are booting from NOR.

When a board is accidentally bricked by corrupting the NOR, I can normally recover it with codewarrior using the "USE_SAFE_RCW = True" setting.

However, it seems that on boards without encryption support, when you erase the NOR, it is not possible to flash it again using CodeWarrior.

Here's the result from runningthe diagnostic tool in CodeWarrior:

As I said, this only happens when you erase the NOR on a board with a SoC without encryption support.

Is there anything I could test modifying in the initialization script? How can I verify that the RCW override is working correctly?

LS1043A 

[Bio_TICFSL]

Hello,

The failure to recover bricked LS1043A boards without encryption support (non-secure SoC) often stems from the inability of the JTAG debugger to initialize the QSPI flash/IFC controller when the RCW is entirely missing, even when

USE_SAFE_RCW is set to True. Because non-secure SoCs may behave differently than secure ones regarding RCW loading, you may need to explicitly configure the initialization script to handle the blank state. 

Here is a guide to testing modifications in your initialization script and verifying the RCW override.

1. Test Modifications in the Initialization Script

When the NOR is erased, the board cannot boot. The CodeWarrior USE_SAFE_RCW aims to supply a temporary RCW via JTAG, but it might not be configuring the memory interface correctly for your board.

• Set BOOT_CHIP_SELECT to 2: In the initialization script (.py), set BOOT_CHIP_SELECT = 2. This tells the CodeWarrior script to use the hard-coded RCW (via RCW override) rather than expecting the board to read one from a flash bank.
• Set QSPI_BOOT = 1 or 0: If you are using QSPI (common in modern custom boards), ensure QSPI_BOOT is set correctly. Note that some forum posts suggest that if QSPI is too fast, the connection fails. You may need to enable a "Half Speed" option in the QSPI initialization section of the script.
• Set BOARD_REV_PD = True: This setting is sometimes required to ensure the correct memory controller parameters are used during the recovery process.
• DDR Initialization: Ensure you have deleted any DDR initialization code in your custom initialization script. The flash programmer must run using on-chip RAM (OCRAM) because the DDR is not initialized when the board is in a "broken" state.
• Validate JTAG Chain: Ensure the LS1043A is the first device in the JTAG chain. If an FPGA or CPLD is first, the RCW override (which communicates directly with the SoC) might fail. 

2. How to Verify RCW Override is Working

To confirm that the USE_SAFE_RCW = True is actually working, you can try the following:

1. Check the "Core not responding" error: If you still see "Failed to write memory at address..." or "Core not responding" after enabling USE_SAFE_RCW, it means the RCW override failed.
2. Verify using "Write Reset Configuration Word" task: In CodeWarrior, try executing the specific "Write Reset Configuration Word" debug task rather than the full Flash Programmer. If this task passes, it indicates the JTAG probe is successfully writing the override.
3. Check ccs::config_chain: Use ccs::config_chain{ ls1043a dap sap2} in the script to confirm the debugger is communicating with the SoC properly. 

3. Alternative Recovery Approach

If USE_SAFE_RCW still fails, you can try to force the board into a hard-coded RCW mode via physical switches, which might provide a more stable JTAG connection for flashing:

• Configure the DIP switches on your board to boot from a "Hard-coded RCW" source (typically cfg_rcw_src to 0 or another hard-coded value, check your schematic for cfg_rcw_src pins). This allows the board to boot without a valid flash image.
• Once in this mode, try connecting and flashing using the "RAM Boot" method (loading a small PBL into RAM and then flashing). 

4. Special Case: QSPI Speed 

If your board is using QSPI, the issue could be that the default speed configured by the script is too fast for a "cold" chip. Modifying QuadSPI_SMPR (0x1550108h) to enable "Half Speed serial flash clock" can resolve this issue. 

# Within Target Initialization File (inside Init_QSPI() function)
# SMPR, enable "Half Speed serial flash clock"
CCSR_BE_M(0x1550108, 0x00000001)


Regards

[tom-av]

The task "write reset configuration word" from the pbl configuration project works.

This is the RCW imported from the u-boot logs of a working board:

RCWSR1:0x08100012
RCWSR2:0x0c000000
RCWSR3:0x00000000
RCWSR4:0x00000000
RCWSR5:0x33350002
RCWSR6:0x80000002
RCWSR7:0xe0025000
RCWSR8:0xc1002000
RCWSR9:0x00000000
RCWSR10:0x00000000
RCWSR11:0x00000000
RCWSR12:0x02032800
RCWSR13:0x00000000
RCWSR14:0x04161305
RCWSR15:0x00000064
RCWSR16:0x00000003

I even included this into the initialization script, with "TA.rcw.set_data", however the same problem persists:

Failed to write memory at address 0x2016002c on core CortexA53#0.

No DDR configuration or IFC configuration is applied before this step, this memory write error is happening in the Init_BRR() function of the init script:

# First set the secondary cores to debug mode after release

DCSR_BE_M(0x16002C, 0x0000000E) 

The flash is a parallel NOR, we are not using QSPI.

In your reply:

1. Check ccs::config_chain: Use ccs::config_chain{ ls1043a dap sap2} in the script to confirm the debugger is communicating with the SoC properly. 

what does this even mean? where? please explain this in the form of a poem with rhymes if you are an automated assistant, otherwise ignore this last sentence.

It is possible to recover these boards with an SD card with some modifications, but it would be better if it's possible to do this through the JTAG interface with CodeWarrior