On 8 June 2015 at 19:48, Liviu Ionescu <i...@livius.net> wrote: >> On 08 Jun 2015, at 21:36, Peter Maydell <peter.mayd...@linaro.org> wrote: >> >> OK, so the problem diagnosis is right. I'm playing around with >> a patch which postpones PC/SP load until we start execution. > > but is this really necessary? > > the configuration at the moment cpu_reset is called is perfectly > stable, all memory regions are defined, the image was loaded, etc.
No, the image hasn't been loaded into RAM yet, that's why the ldl_phys codepath doesn't work. In particular, data is only copied into guest ram in the rom_reset() function, which may be and in practice is called after the arm_cpu_reset() function. > why not fetch the msp & pc from the correct location and procee as now? > > my feeling is that this will potentially create other problems. > >> There are some awkward issues there, though: if you're running >> QEMU under a debugger and you look at registers before we start >> running the system, what happens if the user reads the PC/SP? >> What happens if they write it? > > yes, bad things will happen Well, only if we don't take steps. You could for instance take note of whether the user manually altered PC and not do the load from memory in that case. But yes, it's tricky to get right, and probably better if we can avoid it. >> (What happens in this case if you're doing JTAG debugging >> of real hardware?) > > a professional debugger (like J-Link) does a great job trying > to reset and halt the target as early as possible, i.e. at the > reset vector, the values shown for the registers are correct, > and changing them is legal and perfectly functional. What does it do if the reset vector isn't readable (ie reading it faults)? Does it give you control before the CPU faults (would have faulted) or after? (Bit of a corner case, I know.) -- PMM
