[Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Peter Wächtler]

Hi Xenomai developers,

for automotive control units the boot time is essential. After power-up the 
first status message has to be sent in about 50ms. This is usually achieved 
by a RTOS with boot times far below.

Is it possible to construct a system with Xenomai that boots the POSIX (or 
whatever) subsystem first and then start Linux. Or is there a dependency that 
the subsystem can't run until Linux is up?

That's the question ;)

        Peter

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Steven Seeger]

Peter,

Please tell us more about your hardware platform. I know this is not  
possible on convention x86 boards with a PC compatible BIOS.

Thanks,
Steven

On Mar 27, 2009, at 10:38 AM, Peter Wächtler wrote:

> Hi Xenomai developers,
>
> for automotive control units the boot time is essential. After power- 
> up the
> first status message has to be sent in about 50ms. This is usually  
> achieved
> by a RTOS with boot times far below.
>
> Is it possible to construct a system with Xenomai that boots the  
> POSIX (or
> whatever) subsystem first and then start Linux. Or is there a  
> dependency that
> the subsystem can't run until Linux is up?
>
> That's the question ;)
>
>        Peter
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Gilles Chanteperdrix]

Peter Wächtler wrote:
> Hi Xenomai developers,
> 
> for automotive control units the boot time is essential. After power-up the 
> first status message has to be sent in about 50ms. This is usually achieved 
> by a RTOS with boot times far below.
> 
> Is it possible to construct a system with Xenomai that boots the POSIX (or 
> whatever) subsystem first and then start Linux. Or is there a dependency that 
> the subsystem can't run until Linux is up?

Xenomai kernel-space support is started somewhere in the middle of the
boot process, so, you can probably start kernel-space applications at
that time. User-space only works when init has been started, which
happens a bit later during the boot process. But you can start Xenomai
applications before all the system services have been started.

If you are using an x86, the bios itself lasts for more than 50 ms. On
other architectures, boots time are lower, but there are still places in
the kernel initialization that may be optimized. I have read articles on
linuxdevices of people having worked on that, but never looked at what
they had actually done.

As a side note, I have a question for the automotive industry people.
Would there be an interest in developing an OSEK skin for Xenomai? I
have been thinking about that for some time, but still have not found
time to start the job. I have read the OSEK spec, and found the
interface pretty simple (though some part of the job has to be done
offline, and annoyingly need to read XML files). The OSEK com spec, on
the other hand, looks rather scary.

-- 
                                                 Gilles.

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Peter Wächtler]

Am Friday 27 March 2009 15:41:46 schrieb Steven Seeger:
> Peter,
>
> Please tell us more about your hardware platform. I know this is not
> possible on convention x86 boards with a PC compatible BIOS.
>

Well the hardware should not matter and the startup code should be finished in 
several milli seconds, of course.
Most probably are ARM. PPC or SH4 platforms used in automotive devices.

In the automation industry the boot time is not that important - therefore a 
lot of PC compatible boards are used.

	Peter

>
> On Mar 27, 2009, at 10:38 AM, Peter Wächtler wrote:
> > Hi Xenomai developers,
> >
> > for automotive control units the boot time is essential. After power-
> > up the
> > first status message has to be sent in about 50ms. This is usually
> > achieved
> > by a RTOS with boot times far below.
> >
> > Is it possible to construct a system with Xenomai that boots the
> > POSIX (or
> > whatever) subsystem first and then start Linux. Or is there a
> > dependency that
> > the subsystem can't run until Linux is up?
> >

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Steven Seeger]

> Well the hardware should not matter and the startup code should be  
> finished in
> several milli seconds, of course.
> Most probably are ARM. PPC or SH4 platforms used in automotive  
> devices.
>
> In the automation industry the boot time is not that important -  
> therefore a
> lot of PC compatible boards are used.

The reason I ask about the hardware is so that I can figure out if you  
are trying to boot a standard PC in that amount time or not. I don't  
know your level of understanding in these matters so that's why I ask  
for more information. I was the MIPS maintainer on RTAI for a couple  
of years, and we had a very wimpy MIPS board and it would boot up and  
start our application in about 2 seconds. Now, with the kernel  
executing in place that time was significantly lower but ROM access  
was very slow and this affected realtime performance. That's why I had  
to go with copying the kernel to RAM. If I recall it would boot up in  
under a second, but that's significantly more time than the 50ms you  
are asking about.

On the other hand that really was a weak chip. 66MHz VR4181. Ugh. We  
mainly wanted it for the low power draw.

Gilles pointed out that you could start a kernel based xenomai  
application fairly early but userspace support takes more time to get  
up. If you really want to get a fast boot time then try to link your  
kernel to execute in place if the hardware supports it.

Steven


Steven

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Peter Wächtler]

Am Friday 27 March 2009 15:53:02 schrieb Gilles Chanteperdrix:
>
> Xenomai kernel-space support is started somewhere in the middle of the
> boot process, so, you can probably start kernel-space applications at
> that time. User-space only works when init has been started, which
> happens a bit later during the boot process. But you can start Xenomai
> applications before all the system services have been started.
>

I think the fundamental question is: does Adeos provide a scheduler? 

And I guess the answer is yes, at least "Life-with-Adeos" doc mentions
primary and secondary execution modes/domains.

In the use case it would be necessary that OSEK subsystem is able to schedule 
between a static number of preconfigured threads WITHOUT the precondition 
that Linux is up and running.

>
> As a side note, I have a question for the automotive industry people.
> Would there be an interest in developing an OSEK skin for Xenomai? I
> have been thinking about that for some time, but still have not found
> time to start the job. I have read the OSEK spec, and found the
> interface pretty simple (though some part of the job has to be done
> offline, and annoyingly need to read XML files). The OSEK com spec, on
> the other hand, looks rather scary.

There are open source OSEK implementations. AFAIK, all far from completeness.

You can start with
http://opensek.sourceforge.net/

or have a look at the list at 
http://en.wikipedia.org/wiki/OSEK

	Peter

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Gilles Chanteperdrix]

Peter Wächtler wrote:
>> As a side note, I have a question for the automotive industry people.
>> Would there be an interest in developing an OSEK skin for Xenomai? I
>> have been thinking about that for some time, but still have not found
>> time to start the job. I have read the OSEK spec, and found the
>> interface pretty simple (though some part of the job has to be done
>> offline, and annoyingly need to read XML files). The OSEK com spec, on
>> the other hand, looks rather scary.
> 
> There are open source OSEK implementations. AFAIK, all far from completeness.
> 
> You can start with
> http://opensek.sourceforge.net/
> 
> or have a look at the list at 
> http://en.wikipedia.org/wiki/OSEK

My question is: would you, people working for the automotive industry,
use it. Do you need this, or is OSEK dead and people are using POSIX.

-- 
                                                 Gilles.

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Gilles Chanteperdrix]

Peter Wächtler wrote:
> Am Friday 27 March 2009 15:53:02 schrieb Gilles Chanteperdrix:
>> Xenomai kernel-space support is started somewhere in the middle of the
>> boot process, so, you can probably start kernel-space applications at
>> that time. User-space only works when init has been started, which
>> happens a bit later during the boot process. But you can start Xenomai
>> applications before all the system services have been started.
>>
> 
> I think the fundamental question is: does Adeos provide a scheduler? 
> 
> And I guess the answer is yes, at least "Life-with-Adeos" doc mentions
> primary and secondary execution modes/domains.
> 
> In the use case it would be necessary that OSEK subsystem is able to schedule 
> between a static number of preconfigured threads WITHOUT the precondition 
> that Linux is up and running.

No, you misunderstood the document, Adeos does not provide a scheduler.
Xenomai dos.

The answer is that some part of the Linux kernel needs to be running
(hardware timer and interrupts subsystem) for Xenomai kernel-space
services to start, and it is started at about the time when it can be
started, and the first process needs to have been started if you want to
start user-space processes.

-- 
                                                 Gilles.

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Philippe Gerum]

On Fri, 2009-03-27 at 16:41 +0100, Peter Wächtler wrote:
> Am Friday 27 March 2009 15:53:02 schrieb Gilles Chanteperdrix:
> >
> > Xenomai kernel-space support is started somewhere in the middle of the
> > boot process, so, you can probably start kernel-space applications at
> > that time. User-space only works when init has been started, which
> > happens a bit later during the boot process. But you can start Xenomai
> > applications before all the system services have been started.
> >
> 
> I think the fundamental question is: does Adeos provide a scheduler? 
> 

No it does not. Not the kind of scheduler you seem to be thinking of
actually; it only "schedules" interrupt and trap events. Not tasks.

> And I guess the answer is yes, at least "Life-with-Adeos" doc mentions
> primary and secondary execution modes/domains.
> 

This is dealt with by the Xenomai nucleus. Adeos provides the simplistic
"domain" abstraction, and Xenomai derives the primary/secondary mode
abstractions on top of those.

> In the use case it would be necessary that OSEK subsystem is able to schedule 
> between a static number of preconfigured threads WITHOUT the precondition 
> that Linux is up and running.
> 

The way to do this would be to port the Xenomai nucleus and portions of
the POSIX skin over bare metal. I did exactly that once over an ARM ISS,
so this is indeed doable to bypass Linux. The point is: this needs a
full-fledge Xenomai port, a bit like the Xenomai event-driven simulator
interfaces to our RTOS core.

> >
> > As a side note, I have a question for the automotive industry people.
> > Would there be an interest in developing an OSEK skin for Xenomai? I
> > have been thinking about that for some time, but still have not found
> > time to start the job. I have read the OSEK spec, and found the
> > interface pretty simple (though some part of the job has to be done
> > offline, and annoyingly need to read XML files). The OSEK com spec, on
> > the other hand, looks rather scary.
> 
> There are open source OSEK implementations. AFAIK, all far from completeness.
> 
> You can start with
> http://opensek.sourceforge.net/
> 
> or have a look at the list at 
> http://en.wikipedia.org/wiki/OSEK
> 
> 	Peter
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Peter Wächtler]

Am Friday 27 March 2009 16:46:12 schrieb Gilles Chanteperdrix:
> Peter Wächtler wrote:
> >> As a side note, I have a question for the automotive industry people.
> >> Would there be an interest in developing an OSEK skin for Xenomai? I
> >> have been thinking about that for some time, but still have not found
> >> time to start the job. I have read the OSEK spec, and found the
> >> interface pretty simple (though some part of the job has to be done
> >> offline, and annoyingly need to read XML files). The OSEK com spec, on
> >> the other hand, looks rather scary.
> >
> > There are open source OSEK implementations. AFAIK, all far from
> > completeness.
> >
> > You can start with
> > http://opensek.sourceforge.net/
> >
> > or have a look at the list at
> > http://en.wikipedia.org/wiki/OSEK
>
> My question is: would you, people working for the automotive industry,
> use it. Do you need this, or is OSEK dead and people are using POSIX.

Can't answer with yes or no.
OSEK is in use today and will be used for several years.
AUTOSAR is a new aproach for providing a framework for easier reuse/relocation 
of functionality.
And POSIX is used whereever Linux or QNX is involved (mediaplayers,navigation 
with file access)

The problem with using a newly open source OSEK implementation is risk and 
trust and level of testing/validation and TOOLS and CAN stack support.

I think it's very late - but this depends on quality of implementation. OSEK 
is for the "smaller" control units. I guess we will have "smaller" ECUs in 
our new cars for the next 10 years.
But on the other hand a manufacturer like Volkswagen has chosen Vector osCAN 
as OSEK implementation. I doubt that they will change that for no good 
reason. Royalties are rather low and the emphasize is TOOLS and CAN support.

	Peter

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Gilles Chanteperdrix]

Peter Wächtler wrote:
> Am Friday 27 March 2009 16:46:12 schrieb Gilles Chanteperdrix:
>> Peter Wächtler wrote:
>>>> As a side note, I have a question for the automotive industry people.
>>>> Would there be an interest in developing an OSEK skin for Xenomai? I
>>>> have been thinking about that for some time, but still have not found
>>>> time to start the job. I have read the OSEK spec, and found the
>>>> interface pretty simple (though some part of the job has to be done
>>>> offline, and annoyingly need to read XML files). The OSEK com spec, on
>>>> the other hand, looks rather scary.
>>> There are open source OSEK implementations. AFAIK, all far from
>>> completeness.
>>>
>>> You can start with
>>> http://opensek.sourceforge.net/
>>>
>>> or have a look at the list at
>>> http://en.wikipedia.org/wiki/OSEK
>> My question is: would you, people working for the automotive industry,
>> use it. Do you need this, or is OSEK dead and people are using POSIX.
> 
> Can't answer with yes or no.
> OSEK is in use today and will be used for several years.
> AUTOSAR is a new aproach for providing a framework for easier reuse/relocation 
> of functionality.
> And POSIX is used whereever Linux or QNX is involved (mediaplayers,navigation 
> with file access)
> 
> The problem with using a newly open source OSEK implementation is risk and 
> trust and level of testing/validation and TOOLS and CAN stack support.
> 
> I think it's very late - but this depends on quality of implementation. OSEK 
> is for the "smaller" control units. I guess we will have "smaller" ECUs in 
> our new cars for the next 10 years.
> But on the other hand a manufacturer like Volkswagen has chosen Vector osCAN 
> as OSEK implementation. I doubt that they will change that for no good 
> reason. Royalties are rather low and the emphasize is TOOLS and CAN support.

Yes, obviously, we do not intend to run Xenomai on these very small
control units, so, it would rather be useful as a tool to test OSEK code
on desktop machines and would have to focus on debugging facilities,
such as errors when choosing tasks and resources priorities. As for CAN
support, Xenomai has CAN support, but it means that implementing OSEK
would only make sense if we implemented an OSEK com binding for CAN.

-- 
                                                 Gilles.

Re: [Xenomai-core] use case: possible to boot Posix subsystem in <50ms and then Linux?

[Philippe Gerum]

On Fri, 2009-03-27 at 17:17 +0100, Peter Wächtler wrote:
> Am Friday 27 March 2009 16:46:12 schrieb Gilles Chanteperdrix:
> > Peter Wächtler wrote:
> > >> As a side note, I have a question for the automotive industry people.
> > >> Would there be an interest in developing an OSEK skin for Xenomai? I
> > >> have been thinking about that for some time, but still have not found
> > >> time to start the job. I have read the OSEK spec, and found the
> > >> interface pretty simple (though some part of the job has to be done
> > >> offline, and annoyingly need to read XML files). The OSEK com spec, on
> > >> the other hand, looks rather scary.
> > >
> > > There are open source OSEK implementations. AFAIK, all far from
> > > completeness.
> > >
> > > You can start with
> > > http://opensek.sourceforge.net/
> > >
> > > or have a look at the list at
> > > http://en.wikipedia.org/wiki/OSEK
> >
> > My question is: would you, people working for the automotive industry,
> > use it. Do you need this, or is OSEK dead and people are using POSIX.
> 
> Can't answer with yes or no.
> OSEK is in use today and will be used for several years.
> AUTOSAR is a new aproach for providing a framework for easier reuse/relocation 
> of functionality.
> And POSIX is used whereever Linux or QNX is involved (mediaplayers,navigation 
> with file access)
> 
> The problem with using a newly open source OSEK implementation is risk and 
> trust and level of testing/validation and TOOLS and CAN stack support.
> 

If I understand correctly what Gilles had in mind, the intended usage
would not be actual embedding, but rather provide a host-based
development environment that is OSEK-aware, on top of which one could
write most of an arch-independant application, use the productivity
tools and rich debug tools available there to work out the issues and
validate it, before moving the code to the actual control units for
finalization, this time on a real, certified OSEK-compliant core.

A bit like having arinc653 on a linux-based system: this won't be
certified before hell freezes, this won't actually be embedded in any
flight control system, but this allows accurate simulation provided the
APEX is properly implemented, and makes the initial stages of the
implementation way easier then banging one's head on the target
directly.

> I think it's very late - but this depends on quality of implementation. OSEK 
> is for the "smaller" control units. I guess we will have "smaller" ECUs in 
> our new cars for the next 10 years.
> But on the other hand a manufacturer like Volkswagen has chosen Vector osCAN 
> as OSEK implementation. I doubt that they will change that for no good 
> reason. Royalties are rather low and the emphasize is TOOLS and CAN support.
> 
> 	Peter
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.