Thank you Peter. I will reach out to someone from Xilinx. Do you have insights on how I could use a Qemu emulated core ( M profile ) with a Virtual Prototype ( System C IP ) ?
Thank you. On Tue, 30 Jan 2024 at 15:59, Peter Maydell <peter.mayd...@linaro.org> wrote: > On Tue, 30 Jan 2024 at 07:48, sanjana gogte <sanj27...@gmail.com> wrote: > > > > I wanted to express my gratitude for your insightful solution concerning > the INVSTATE fault I was encountering. After recompiling my code with the > -mthumb compiler flag, the exception is no longer being raised, which marks > a significant step forward in my project. > > > > However, I've encountered another challenge while working with a > specific version of QEMU (QEMU emulator version 7.1.0, > v2.6.0-55433-g23b643ba16). While the code runs flawlessly on QEMU version > 8.1.50 (v8.1.0-2375-g516fffc993), the earlier version throws a hard fault, > which is critical to my use case. > > > > The use case involves attaching a remote port to the MPS2-AN505, and for > this, I need to utilize Xilinx’s fork of QEMU, which is based on version > 7.1.0 (v2.6.0-55433-g23b643ba16). The error I encounter during emulation is > as follows: > > > > Loaded reset SP 0x0 PC 0x0 from vector table > > Loaded reset SP 0x10080000 PC 0x10000009 from vector table > > Taking exception 3 [Prefetch Abort] on CPU 0 > > ...at fault address 0x10800000 > > ...with CFSR.IBUSERR > > ...taking pending secure exception 3 > > ...loading from element 3 000000c > > ...loaded new PC 0x10000011 of secure vector table at 0x1 > > Taking exception 3 [Prefetch Abort] on CPU 0 > > ...at fault address 0x10800000 > > ...with CFSR.IBUSERR > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > > > Observations: When I trace it using the GDB: > > > > It goes to prefetch abort as soon as I step into reset handler and the > connection gets closed. > > What I do not understand is: > > > > 1) Why is my PC going to address 0x10800000? > > > > > > 2) When I use Qemu version 8.1.50 (v8.1.0-2375-g516fffc993), the PC goes > to the right address and does not throw a prefetch abort. > > This strongly suggests you're running into a QEMU issue > which we've fixed in some QEMU version after 7.1.0. > For bugs in Xilinx's fork of QEMU, you should talk to Xilinx. > > In terms of why your PC is going to 0x10800000, it is > almost certainly executing a lot of NOPs from some point > until it runs off the end of the flash memory. If you > use the gdb 'si' command to single step single instructions > you'll probably find this is less confusing than using > the 's' command, which steps an entire C source line. > > thanks > -- PMM >
