On 15 November 2010 15:09, Loïc Minier <loic.min...@linaro.org> wrote: > On Mon, Nov 15, 2010, Albert ARIBAUD wrote: >> One last question: >> > qemu: fatal: Trying to execute code outside RAM or ROM at 0x34000000 >> >> Does this mean that qemu does not simulate data or instruction >> aborts? Not that it is required for u-boot, but it *could* be useful >> sometimes. > > I think the only thing it can do is halt :-)
qemu does simulate data/insn aborts caused when the MMU is enabled and you try an access forbidden by the access permissions set up in the page table. That particular error message happens when you try to execute from a physical address which isn't RAM or ROM, so you'll only see it if you have not enabled the MMU or if you get your page tables wrong. There's no particular reason this couldn't be made to take a simulated fault instead, I think -- there's an #ifdef that means qemu for Sparc and MIPS will simulate a fault instead of aborting. (In theory I think the behaviour shouldn't necessarily always be to fault, but if there is a non-RAM non-ROM device at the address to simulate the effect of trying to fetch instructions from your serial device registers, for example :-)) This is an example of a general tendency in qemu-arm for the modelling to be a bit weak for situations which will never be triggered by a correct program/OS but which nonetheless have well defined failure behaviour. Other examples include execution of various opcode values which should UNDEF (may trigger qemu internal error warnings or decode to some other instruction), and execution of VFP or Neon when the CPACR is set to disable access to cp10/11 (should fault but won't). Mostly these things don't cause a problem in practice, which is why they haven't been corrected yet. -- PMM _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot