On Mon, 8 Apr 2024 at 20:25, Gautam Bhat <mindentr...@gmail.com> wrote: > > On Thu, Apr 4, 2024 at 2:23 PM Peter Maydell <peter.mayd...@linaro.org> wrote: > > > This will not work (yet) -- CPUs do not get reset as part of the > > whole-system three-phase-reset, so using the exit phase method > > is not sufficient to avoid the reset ordering problem here. > > > > You need to use rom_ptr_for_as() to see if there's a ROM blob > > at the address you're trying to load the PC from, and if there > > is you use ldl_p() to get the PC from the blob; otherwise you > > use ldl_phys(). Searching for "initial_pc" in target/arm/cpu.c > > will find you the code that does this for M-profile. > > Thanks for the tip. I am able to see the program being loaded based on > the dump of rom pointer in gdb. > Now the problem is I am loading a binary file (msp430-elf-objcopy -O > binary simple_test simple_test.bin) > and due to this I will be missing out the loader loading different > sections in the right parts of the memory. > The reset vector which is supposed to be present at 0xFFFE is present > at 0x3FFE in the binary file.
That sounds like a problem with your binary. If the reset vector needs to be at 0xFFFE then it needs to be there, and you should arrange for it to be built correctly. It doesn't matter whether it's an ELF file or a raw binary file, the data has to be in the right place. (Generally when objcopy creates a raw binary from an ELF file it doesn't change the address where the data is, assuming you load the resulting raw binary to the right starting address.) -- PMM
