From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 16 Nov 2010 17:02:15 +0100 Subject: [U-Boot] qemu-arm In-Reply-To: References: <4CDA9CF2.1030202@schmid-telecom.ch> <4CDBA515.3050106@free.fr> <20101114212240.5FA7914EA7E@gemini.denx.de> <4CE11314.50807@free.fr> <20101115111321.50761134FEF@gemini.denx.de> <4CE11E66.5060207@free.fr> <20101115115556.GA13479@bee.dooz.org> <20101115120354.866DB134FEF@gemini.denx.de> <20101115140647.GB22583@bee.dooz.org> <4CE143DB.6050907@free.fr> <20101115150923.GG22583@bee.dooz.org> <4CE28D0A.2090909@free.fr> Message-ID: <4CE2AB07.9040209@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 16/11/2010 15:49, Peter Maydell a ?crit : > On 16 November 2010 13:54, Albert ARIBAUD 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.