[U-Boot] qemu-arm

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 16/11/2010 15:49, Peter Maydell a ?crit :
> On 16 November 2010 13:54, Albert ARIBAUD<albert.aribaud@free.fr>  wrote:
>>> 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.
>
> Sure, but I imagine that for debugging that sort of thing it doesn't make
> a great deal of difference whether you discover it by getting a cpu
> abort, by having the core just go off into the weeds somewhere or by
> getting a fatal error message from qemu. So that was partly what I
> meant by "in practice" -- yes, it's a deviation from correct behaviour,
> but it's not really any more of an impediment to debugging than
> correctly modelled behaviour would be, once you know what qemu
> is doing wrong...

Understood. What I meant is that "in practice" with a real piece of HW, 
we expect aborts or undefined so much that we actually handle them and 
do a register dump the board's console, so not seeing this dump when 
simulating an abort on the HW would thus somehow 'depart' from 'the 
practice' as I know it. However:

> (Which is not to defend the current qemu behaviour so much as to
> try to explain why this particular bug isn't at the top of my todo list :-))

I do understand why it isn't, and as I said, I can happily live without 
it as long as I know that the simulator differs from the HW in this 
respect -- after all, if I *really* need it, I guess I can delve deep 
into the qemu-arm source code. :)

> -- PMM

Amicalement,
-- 
Albert.