@bsvtgc Admittedly, the boot process entry point is a little bit circuitous. Table 5 of Chapter 5 of the Manual shows how the boot vector address depends on the state of the MSEL pins (earlier Manual version v19p05, available elsewhere, has Table 7 called “Target of the reset vector” which explains the MSEL settings).
Unfortunately, the MSEL pins are not accessible, but are hard-wired (presumably floating up) to 11’b which is mentioned as the hardware default condition (and determined empirically).
This causes a jump to the Mask ROM at 0x1 0000.
Section 5.1.1 of the Manual says that the Mask ROM has instructions which further jump to OTP at 0x2 0000.
Now, the “Boot Code” section at the beginning of Chapter 5 of the Datasheet gives us the default OTP program which is a jump to SPI-Flash at 0x2000 0000. Quoting the Datasheet:
As shipped, the OTP memory at the boot location is preprogrammed to jump immediately to the end of the OTP memory, which contains the following code to jump to the beginning of the SPI-Flash at 0x2000 0000:
fence 0,0
li t0, 0x20000000
jr t0fence 0,0 is encoded as 0x0000 000F, and the instruction may be modified by burning additional bits to transform it into a JAL instruction ( opcode 0x6F ) to execute arbitrary code rather than jumping directly to the beginning of the SPI-Flash.
Thus, at power-up, program execution will jump essentially jump to 0x2000_0000, not 0x2001000. Not sure from where you saw the latter.
You can either map/link and load your code to 0x8000 0000, for RAM operation; or to 0x2000 0000, for Flash/ROM operation, and all will be fine.
Erase the Flash/ROM in OpenOCD tcl with:
echo [flash protect 0 0 2 off]
echo [flash erase_sector 0 0 2]
echo [flash protect 0 0 2 on]
NOTE: BE CAREFUL when loading code into ROM! If there’s a bug, exception or otherwise tight infinite loop, reset & halt of the CPU might be difficult. See my earlier post for tips to ‘unbrick’ a system in this case.