From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HiwLf-0008Hq-PZ for qemu-devel@nongnu.org; Tue, 01 May 2007 13:41:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HiwLe-0008HU-98 for qemu-devel@nongnu.org; Tue, 01 May 2007 13:41:10 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HiwLe-0008HI-68 for qemu-devel@nongnu.org; Tue, 01 May 2007 13:41:10 -0400 Received: from nz-out-0506.google.com ([64.233.162.237]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HiwFJ-0003GM-Sm for qemu-devel@nongnu.org; Tue, 01 May 2007 13:34:38 -0400 Received: by nz-out-0506.google.com with SMTP id i11so2476358nzi for ; Tue, 01 May 2007 10:34:37 -0700 (PDT) Message-ID: Date: Tue, 1 May 2007 19:34:36 +0200 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re... In-Reply-To: <1178009881.7759.18.camel@petitemort.i.digital-scurf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1178009881.7759.18.camel@petitemort.i.digital-scurf.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dsilvers@simtec.co.uk, qemu-devel@nongnu.org Hi, On 01/05/07, Daniel Silverstone wrote: > On Mon, 2007-04-30 at 02:24 +0000, Andrzej Zaborowski wrote: > > Account for machine with RAM which is not mapped at 0x0 in arm_boot.c. > > It seems a pity that you did this in a manner which didn't match the > patch I published for the Simtec BAST boards. Now I have a bunch more > merging effort to go through if I'm ever to get this patch merged. (Not > that anyone has said a word to me since I posted it having solved all > the issues that pbrook raised) Your fix was almost identical to what I merged (and what I published in January) so I don't think this is much to pity. Generally when there are two versions of the same code, what is merged is bound to not match at least one of them, however in this case this is really no cause for a lot of rediffing effort. > > In particular you call the variable loader_start which seems somewhat > misleading since essentially what it is is the emulated_sdram_base which > is what I called it. There's no reason for the bootloader to be always at the start of SDRAM. It is at the start of some ROM in most real life cases, but could be anywhere. > > I guess I'll have to do some serious merge work into my working tree and > then post another patch. If you're interested. If not then I'll just > carry on in my own little world and not bother with submitting to trunk, > which seems a serious pity as it simply ends up being more work for all > concerned and it forks the project. Regarding the S3C2410 emulation we have done some of the same work and this is never a nice thing and we'll have to figure a couple of things out. Let me describe what would be optimal for me: At some point we would start working with a single tree (outside mainline). Considering that our S3C2410 implementation seems more complete I would leave this implementation in that tree and base the Simtec BAST machine on this implementation of the CPU. Switching the machine code from using your implementation of the CPU should be easy because both versions seem to have a clean api. I can try to do this. Since you decided to ask for inclusion I assume that your tree is not undergoing any huge changes anymore. However our tree is still heavily evolving, thus I would be in charge of keeping the tree updated with changes from mainline, until the point where we're *both* happy to upstream. I believe the area we're improving at this moment in the S3C2410 code is not overlapping with any of your work so there's no hurry. If anyone else is working on a machine based on S3C2410 they could also do that in that common tree outside mainline. Regarding slowness of the Interrupt Controller, I aimed to be correct with the datasheet and implemented the arbitration algorithm (or something similar to it) but I didn't mean for it to be enabled on normal emulator runs. As you perhaps noticed the arbitration would only have any effect in rare, little significant cases in which the outcome is hazardous to rely on anyway - and even the hardware implementation is probably not 100% correct. Moreover Paul already found places in which my implementation is not even what the datasheet describes, so this has to be changed anyway - however I don't see anything wrong having the code present. Also I don't believe the performance difference noticeable. Regards, Andrzej