[U-Boot] qemu-arm (was: [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support)

Albert ARIBAUD albert.aribaud at free.fr
Tue Nov 16 14:54:18 CET 2010


Le 16/11/2010 14:42, Peter Maydell a écrit :

> 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.

Thanks Peter for the clarification. I imagine that "in practice" can 
bear different meanings depending on the practice -- for software like 
u-boot, which is very low-level and can encounter issues such as a RAM 
controller misconfiguration (or plain bad BAR setting, mind) addressing 
outside physically available space, including writing to RO memory or 
fetching bad code, is something we can see in practice, at least in the 
first times of a board's bring up.

I'll have a look and see if I can get a working setup for running u-boot 
on qemu-arm.

> -- PMM

Amicalement,
-- 
Albert.


More information about the U-Boot mailing list