Re: [Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
On Mon, 2007-04-30 at 02:24 +, 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) 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. 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. Hopefully we can come to some agreement about this which isn't a schism in processes. Regards, Daniel -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
Re: [Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
Hi, On 01/05/07, Daniel Silverstone [EMAIL PROTECTED] wrote: On Mon, 2007-04-30 at 02:24 +, 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
[Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/04/30 02:24:42 Modified files: . : vl.h hw : arm_boot.c integratorcp.c realview.c spitz.c versatilepb.c target-arm : cpu.h Log message: Account for machine with RAM which is not mapped at 0x0 in arm_boot.c. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.229r2=1.230 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_boot.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/spitz.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/cpu.h?cvsroot=qemur1=1.24r2=1.25
[Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/01/16 18:54:31 Modified files: . : vl.h hw : arm_boot.c integratorcp.c realview.c versatilepb.c Log message: ARM ELF loader. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.172r2=1.173 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_boot.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.7r2=1.8 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
Paul the code change that was checked in here causes the zImage files I generate not to work anymore. Please consider the small patch which fixes the problem. The load_elf() function is returning -1. signed-off-by: [EMAIL PROTECTED] Paul Brook wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 07/01/16 18:54:31 Modified files: . : vl.h hw : arm_boot.c integratorcp.c realview.c versatilepb.c Log message: ARM ELF loader. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.172r2=1.173 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/arm_boot.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/integratorcp.c?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemur1=1.7r2=1.8 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Index: qemu/hw/arm_boot.c === --- qemu.orig/hw/arm_boot.c +++ qemu/hw/arm_boot.c @@ -80,7 +80,7 @@ void arm_load_kernel(CPUState *env, int } kernel_size = load_elf(kernel_filename, 0, entry); -if (kernel_size) { +if (kernel_size 0) { /* An ELF image. Jump to the entry point. */ env-regs[15] = entry 0xfffe; env-thumb = entry 1; ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel