[okl4-developer] S3C2440A and okl4

[Rémy Gottschalk]

Frank Kaiser a écrit :
>> -----Original Message-----
>> From: developer-bounces at okl4.org [mailto:developer-bounces at okl4.org] On Behalf
>> Of Rémy Gottschalk
>> Sent: Monday, August 18, 2008 9:33 PM
>> To: Geoffrey Lee
>> Cc: developer at okl4.org
>> Subject: Re: [okl4-developer] S3C2440A and okl4
>>
>> Geoffrey Lee a écrit :
>>> On Mon, Aug 18, 2008 at 03:07:20PM +0000, Rémy Gottschalk wrote:
>>>> Geoffrey Lee a écrit :
>>>>> On Mon, Aug 18, 2008 at 02:33:49PM +0000, Rémy Gottschalk wrote:
>>>>>> The faulty instruction seems to be  a clzeq within arm_comon_return :
>>>>> Hi Remy
>>>>>
>>>>> I don't think the clz instruction is supported on the arm920t, which
>>>>> might be the cause of the problem.
>>>>>
>>> Hi Remy
>>>
>>>> I am no arm guru but doing some research it appears the same to me.
>>>> Digging a little further i discovered that this portion of code come
>>>> from arch/arm/pistachio/v5/src/traps.spp
>>>>
>>>> I also found that v.2.1 doesn't contain any clz instruction.
>> In fact it contains two clz but none clzeq, see below.
>>
>>>> So for a
>>>> quick test I copied this file from the v 2.1 to the current version
>>>> (2.1.1-patch.9). And well I got a nice amount of test to pass. :)
>>>>
>>> ...
>> Well I found three faulty instructions one clzeq and two clz, all are
>> from arch/arm/pistachio/v5/src/traps.spp I managed to found a workaround
>> for the two clz but non for the clzeq.
>>
>> So I applied my pretty dirty workaround to the v2.1 and not only all
>> tests pass successfully but I got now an oklinux working. :)
>>
>> ...
>>
>> Regards,
>>
>> --
>> Remy Gottschalk - rgottschalk at linagora.com
>> Ingénieur informatique embarquée
>> Groupe LINAGORA - http://www.linagora.com
>> Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29
>>
>> _______________________________________________
>> Developer mailing list
>> Developer at okl4.org
>> https://lists.okl4.org/mailman/listinfo/developer
> ----
> Hello, Folks
> 
> I have to tell you that there are also two CLZ instructions in v2.1 of 'traps.spp': at line 480 and line 494. Since they are in a code section led by an "#ifdef CONFIG_IPC_FASTPATH" directive, I tried to compile my AT91RM9200 platform with the parameter "IPC_FASTPATH=0", but unfortunately this breaks the compilation of 'traps.spp': the constant "L4_ANYTHREAD", which is defined in line 263 after "#ifdef CONFIG_IPC_FASTPATH", is referred in line 1445 which lies after the corresponding #else directive so that it is undefined.
> So I have the situation that my platform runs into an 'undefined instruction' exception with IPC_FASTPATH on, and is not compilable with IPC_FASTPATH off. Any suggestions how to proceed?
> Remy, I think you will face the same problem when you build with "PROJECT=iguana" instead of "PROJECT=l4test".
> 

I managed to get rid off those two CLZ instructions with a pretty dirty 
patch I got my inspiration from the linux kernel :
http://lxr.linux.no/linux+v2.6.26.2/arch/arm/lib/lib1funcs.S#L106
ie :
  106.macro ARM_DIV2_ORDER divisor, order
  107
  108#if __LINUX_ARM_ARCH__ >= 5
  109
  110        clz     \order, \divisor
  111        rsb     \order, \order, #31
  112
  113#else
  114
  115        cmp     \divisor, #(1 << 16)
  116        movhs   \divisor, \divisor, lsr #16
  117        movhs   \order, #16
  118        movlo   \order, #0
  119
  120        cmp     \divisor, #(1 << 8)
  121        movhs   \divisor, \divisor, lsr #8
  122        addhs   \order, \order, #8
  123
  124        cmp     \divisor, #(1 << 4)
  125        movhs   \divisor, \divisor, lsr #4
  126        addhs   \order, \order, #4
  127
  128        cmp     \divisor, #(1 << 2)
  129        addhi   \order, \order, #3
  130        addls   \order, \order, \divisor, lsr #1
  131
  132#endif

And our two culprits are :
clz     tmp3,   tmp3
rsb     tmp3,   tmp3, #31
and :
And our two culprits are
clz     tmp2,   tmp2
rsb     tmp2,   tmp2, #31

Pretty similar no ?

Since I am pretty busy and not really knowledgeable about ARM assembly
I tested to insert a similar macro in v2.1. I can't guaranty this is the 
right thing to do but this compile, all l4test pass and okl4 and wombat 
are now running apparently fine. This need of course some confirmation 
to more skilled foe than myself.

About the clzeq that still keep me from using the latest version I am 
still clueless so I'll personally stay with this version for now.

Regards,

-- 
Remy Gottschalk - rgottschalk at linagora.com
Ingénieur informatique embarquée
Groupe LINAGORA - http://www.linagora.com
Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29