[okl4-developer] ARM versatile platform

[Lukas HANEL]

Hi Matthew,

actualy I have not branched qemu for my custom board. Instead, for the
moment I am just using the already existing versatile platform. I then
build OKL4 either for versatile or my hardware platform. I am using qemu
0.9.1-1 binaries from debian unstable. So I assume your patch is already
integrated.

regards,
Lukas

Matthew Warton wrote:
> 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 <mailto:Developer at okl4.org>
>> https://lists.okl4.org/mailman/listinfo/developer
>