[Adeos-main] adeos porting

[Adeos-main] adeos porting

[aaron durbin]

Hi,

I am planning on porting ADEOS over to m68knommu (ColdFire based)
architecture.  I have read the porting guidelines, however they are a little
outdated. Currently I am using the recently released
adeos-linux-2.6.7-i386-r6c6.patch patch for a basis. I was wondering if
there was any more recent documentation on the API so I know exactly what
calls should be performed in entry.S.

The issue I am running into is that the version 2 core of ColdFire does not
have user/kernel stack support in hardware.  Therefore in entry.S needs to
disable interrupts to make the stack switch atomic.  I was wondering if it
would be sufficient to just stall the pipeline for linux at this point and
make sure to unstall as apposed to disabling interrupts.

My plans are to first port over ADEOS then go for RTAI.  The two coupled
together look very promising, and I am hoping they will work as well for
ColdFire as it does for x86.  

Thanks for the help,
Aaron Durbin 

Re: [Adeos-main] adeos porting

[Philippe Gerum]

On Wed, 2004-08-04 at 15:35, aaron durbin wrote:
> Hi,
> 
> I am planning on porting ADEOS over to m68knommu (ColdFire based)
> architecture.  I have read the porting guidelines, however they are a little
> outdated. Currently I am using the recently released
> adeos-linux-2.6.7-i386-r6c6.patch patch for a basis. I was wondering if
> there was any more recent documentation on the API so I know exactly what
> calls should be performed in entry.S.

This one is pretty much in sync with the latest developments:
http://home.gna.org/adeos/doc/api/globals.html

This said, you cannot infer from that what's needed in entry.S. What you
need to do there is basically intercepting the hw IRQ masking/unmasking
and call the corresponding Adeos routines instead
(__adeos_stall/unstall_root), so that interrupts can go through the
pipeline when caught there too, even if the kernel won't receive them.

> 
> The issue I am running into is that the version 2 core of ColdFire does not
> have user/kernel stack support in hardware.  Therefore in entry.S needs to
> disable interrupts to make the stack switch atomic.  I was wondering if it
> would be sufficient to just stall the pipeline for linux at this point and
> make sure to unstall as apposed to disabling interrupts.
> 

Yes. Be careful with the register trashing though; calling the Adeos
pipeline controls might require a bit of tweaking in entry.S so that you
don't end up with a register mess upon return.

> My plans are to first port over ADEOS then go for RTAI.  The two coupled
> together look very promising, and I am hoping they will work as well for
> ColdFire as it does for x86.  
> 

Do you target the 3.0, 3.1 or fusion (poised to become 4.0) branch?

> Thanks for the help,
> Aaron Durbin 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
-- 

Philippe.

RE: [Adeos-main] adeos porting

[aaron durbin]

>Do you target the 3.0, 3.1 or fusion (poised to become 4.0) branch?

Actually I am not totally sure at this point. It was my (mis?)understanding
that newer development on RTAI was using the ADEOS as its base interrupt
dispatcher. Fusion, I believe, is the new-new stuff (experimental), but I
thought the 3.x branches were the newer stable stuff.  Could you give me a
brief description on what they are and what direction they are going? I read
a little up on fusion and xenomai stuff on www.fdn.fr/~brouchou/rtai.   

Thanks again,
Aaron


-----Original Message-----
From: Philippe Gerum [mailto:rpm@xenomai.org]
Sent: Wednesday, August 04, 2004 9:36 AM
To: aaron durbin
Cc: 'adeos-main@gna.org'
Subject: Re: [Adeos-main] adeos porting


On Wed, 2004-08-04 at 15:35, aaron durbin wrote:
> Hi,
> 
> I am planning on porting ADEOS over to m68knommu (ColdFire based)
> architecture.  I have read the porting guidelines, however they are a
little
> outdated. Currently I am using the recently released
> adeos-linux-2.6.7-i386-r6c6.patch patch for a basis. I was wondering if
> there was any more recent documentation on the API so I know exactly what
> calls should be performed in entry.S.

This one is pretty much in sync with the latest developments:
http://home.gna.org/adeos/doc/api/globals.html

This said, you cannot infer from that what's needed in entry.S. What you
need to do there is basically intercepting the hw IRQ masking/unmasking
and call the corresponding Adeos routines instead
(__adeos_stall/unstall_root), so that interrupts can go through the
pipeline when caught there too, even if the kernel won't receive them.

> 
> The issue I am running into is that the version 2 core of ColdFire does
not
> have user/kernel stack support in hardware.  Therefore in entry.S needs to
> disable interrupts to make the stack switch atomic.  I was wondering if it
> would be sufficient to just stall the pipeline for linux at this point and
> make sure to unstall as apposed to disabling interrupts.
> 

Yes. Be careful with the register trashing though; calling the Adeos
pipeline controls might require a bit of tweaking in entry.S so that you
don't end up with a register mess upon return.

> My plans are to first port over ADEOS then go for RTAI.  The two coupled
> together look very promising, and I am hoping they will work as well for
> ColdFire as it does for x86.  
> 

Do you target the 3.0, 3.1 or fusion (poised to become 4.0) branch?

> Thanks for the help,
> Aaron Durbin 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
-- 

Philippe.

RE: [Adeos-main] adeos porting

[Philippe Gerum]

On Wed, 2004-08-04 at 18:03, aaron durbin wrote:
> >Do you target the 3.0, 3.1 or fusion (poised to become 4.0) branch?
> 
> Actually I am not totally sure at this point. It was my (mis?)understanding
> that newer development on RTAI was using the ADEOS as its base interrupt
> dispatcher.

This is right. RTAI/x86 runs over Adeos since 24.1.11.

>  Fusion, I believe, is the new-new stuff (experimental), but I
> thought the 3.x branches were the newer stable stuff.  Could you give me a
> brief description on what they are and what direction they are going? I read
> a little up on fusion and xenomai stuff on www.fdn.fr/~brouchou/rtai.   

3.0 is the stable RTAI branch, for the 2.4 kernel series only, replacing
the legacy 24.1.x . Adeos is available there for x86. It has entered the
maintenance phase six months ago, so don't expect anything but small
bugfixes there. I would not recommend any arch port to start from this
codebase.

3.1 is the testing branch, still supporting the 2.4 series for all
archs, and the 2.6 series for x86 only. The architecture is the same
than 3.0, but it has been extended in several aspects. Adeos is
available there for x86 (the old RTHAL has been discontinued for this
arch), and a preliminary port exists for PPC. Like with 3.0, hard
real-time in user-space is only available for x86 though. Other archs
have no choice but running the apps in kernel space as modules. Changes
to this branch are calming down. It is poised to replace 3.0 as the
stable branch in a few weeks from now, once the remaining 2.6-related
problems have been found. 2.4 is ok already though.

fusion/4.0 is a complete departure from the 3.x architecture, based on
the Xenomai technology that has been initiated back three years ago and
continuously developed since then. It is aimed at rebuilding the RTAI
system over a nanokernel core. It's indeed new to the point that there
is no code recycled from the 24.1.x series. But "experimental" is a
wording chosen to minimize the potential confusion with the current 3.x
branch, not to qualify the state of the code which is maturing
reasonably fast.
In a few words, fusion is for the 2.6 (and above) kernel series, purely
Adeos-based, and specifically designed to have RTAI and the vanilla
(preemptible) kernel cooperate in providing hard real-time support in
user-space. Since 3.x has many (too many) APIs, fusion is also an
attempt to provide a more compact and simple native interface; old 3.x
interfaces will be rewritten in parallel over the new core for
compatibility purpose during the next months.  The fusion architecture
has been defined to be easily portable to other archs, but since it has
not been ported yet beyond x86, I cannot prove it (except that its core
runs glitchlessly over an even-driven simulator). However, there are
proofs for all the rest: just download 0.4 and try it (use the
testsuite/latency test). 
Since the x86 port is in good shape, a PPC port is the next goal.

-- 

Philippe.