[okl4-developer] ARM versatile platform

[Matthew Warton]

Hi Lukas,

I assume that you have branched qemu to support your custom board.   
When initially porting to the OpenMoko neo platform, we ran into a bug  
in qemu related to MMU operations on ARM. I submitted a patch which  
has since been incorporated into qemu's main tree, I wonder if some of  
your failures may be caused by not having this patch?  Before we  
investigate further can you make sure that you have this patch in you  
qemu code.

Thanks,
Matthew Warton

diff -ru qemu-snapshot-2007-10-11_05/target-arm/helper.c qemu-patched/ 
target-arm/helper.c
--- qemu-snapshot-2007-10-11_05/target-arm/helper.c	2007-09-17  
07:08:01.000000000 +1000
+++ qemu-patched/target-arm/helper.c	2007-10-15 11:33:49.000000000 +1000
@@ -703,6 +703,7 @@
          break;
      case 3: /* MMU Domain access control / MPU write buffer  
control.  */
          env->cp15.c3 = val;
+        tlb_flush(env, 1); /* Flush TLB as domain not tracked in TLB */
          break;
      case 4: /* Reserved.  */
          goto bad_reg;
@@ -813,8 +814,6 @@
      case 13: /* Process ID.  */
          switch (op2) {
          case 0:
-            if (!arm_feature(env, ARM_FEATURE_MPU))
-                goto bad_reg;
              /* Unlike real hardware the qemu TLB uses virtual  
addresses,
                 not modified virtual addresses, so this causes a TLB  
flush.
               */

On 30/04/2008, at 10:19 PM, Lukas HANEL wrote:

> Hi,
>
> I am progressing with my OKL4_2.1 port to a platform similar to the  
> ARM
> versatile platform. For software emulation, I use qemu with -M
> versatilepb flag. When running OKL4 with project=l4test, some tests  
> are
> passed, but it hangs in others. I was wondering whether you already  
> have
> some experience with OKL4 on the versatile platform. If so, are you
> experiencing similar problems?
>
> Can you hence tell me, which tests are supposed to pass on a versatile
> platform?
>
> For me to finish l4test, I have to disable the following tests:
>      "CACHE0600",
>      "CACHE0700",
>      "CAPIPC2100",
>    "FUZZ0200",
>    "SCHED0300",
>    "SCHED0500",
> //    TCASE(ipc_schedule_inheritance);
> //    TCASE(mutex_schedule_inheritance);
>
> That said, I have not yet touched the kernel time, clock and interrupt
> controler drivers (empty stubs). Could they be a source of the  
> problem?
>
> In your opinion, will the failure of these tests hinder me to use  
> iguana
> and oklinux?
> To me it seems, those are more like good to have features, e.g. for
> security, but no fundamentals for a running system. Is this right?
>
> Given your support for the arm926ejs core and the versatile  
> emulator, I
> am wondering if you are planning to release OKL4 for a versatile
> platform, soon?
>
> If you already have working parts, can you share them with me, so I  
> can
> focus on the not working parts?
>
> thanks,
> Lukas
>
>
> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20080501/734bc1dd/attachment.htm