[U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Peter Maydell]

On 15 November 2010 15:09, Loïc Minier <loic.minier at 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