[okl4-developer] S3C2440A and okl4

[Frank Kaiser]

> -----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".

Regards
Frank