On 16 November 2010 13:54, Albert ARIBAUD <albert.arib...@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... (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 :-)) -- PMM _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
