AnsweredAssumed Answered

sc58x adi_rom_boot() problem with multiboot (SPI + erased memory)

Question asked by lukma on Jul 25, 2017
Latest reply on Sep 1, 2017 by Jithul_Janardhanan

Dear Analog,


I'm trying to implement following multiboot scenario:


int main (....) {


adi_rom_Boot((void*) SPI_NOR_SHARC1_FW,BITM_ROM_BFLAG_RETURN,0,0,0x10207);

adi_rom_Boot((void*) SPI_NOR_SHARC2_FW,BITM_ROM_BFLAG_RETURN,0,0,0x10207);

/* Boot SPL */
adi_rom_Boot((void*) SPI_NOR_SPL,0,0,0,0x10207);

/* We shall not return here ! */



In the above example FW for SHARC cores (1,2) are loaded from SPI NOR. As the last one the ARM Core0 SPL bootloader is loaded.

This setup generally works, but........


When I erase (or alter it in any other way) SPI_NOR_SHARC1_FW SPI-NOR area, then adi_rom_Boot() hangs without giving any chance for recovery (it jumps to 0x11e4 - which is in Rom address).


My idea would be to read first LDR block header (16 B) and check if at least:

- it is not 0xFFs

- the xor is correct.

Only afterwards run adi_rom_Boot().


I've been trying to use "hooks" from EE384 application note, but it seems like the error emerges earlier.


Maybe there is other "easier" way to achieve described above robustness, without the need to manually configure SPI2 for 16 B transfer (and then to do the same with adi_rom_Boot())?



Just a side question:

- The adi_rom_Boot hangs with 0x11e4 code. I've read the "Silicon Anomaly" document for sc584 and the info about ADI_ROM_BOOT_CONFIG::errorReturn.

How can I use the error return value for a closed source BootRom binary? Is it the last instruction address executed in my Secondary Program Loader before the error?


Thanks in advance,