[Bug 2111] AVR needs avr-libc to compile RTEMS.

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=2111

Joel Sherrill <joel.sherrill at oarcorp.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joel.sherrill at oarcorp.com

--- Comment #12 from Joel Sherrill <joel.sherrill at oarcorp.com> 2013-04-09 13:13:00 CDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > Found some interesting 'features' of the RTEMS build system.
> > 
> > the (unpatched) RTEMS build system only allows *-*-*rtems* targets.
> > 
> > (patching away the *-*-*rtems*) targets issue, revealed another issue:
> > 
> > cpukit/configure.ac appears to run a POSIX compliance check each time RTEMS is
> > configured, whether posix is enabled (or not).
> > 
> > So, for a long-term avr-libc port, we need to pull out the POSIX compliance
> > check into a cpukit/aclocal/enable-posix-compliance-check.m4
> > and add a
> > --enable-posix-compliance-check option to make POSIX compliance checking
> > optional.
> > 
> > Apparently cpukit/score requires a struct timeval definition, but I'm not clear
> > as to whether we need score to do the classic rtems library (or not).  If we do
> > need score, where should the timeval struct be declared (within rtems, or in
> > avr-libc?)  Do we need score to do the ticker demo?
> > 
> score contains the scheduling and context switch logic which is needed by
> ticker. 

And all RTEMS functionality in the Classic and POSIX API. :)

> However, we replaced struct timeval timestamps with 64-bit integers
> some time ago (although that has been suggested to be reverted), so I think we
> can at the very least conditionalize the code that uses/checks for struct
> timeval, and maybe even eliminate it by moving the timeval dependent code to
> the posix directory. Internally, the score uses Timestamp_Control, which is
> actually either a timespec or a 64-bit integer, so score depends on posix
> timespec when not using 64-bit timestamps.

The implementation of the internal "timestamp" is selected by the architecture.

It is also possible that a new implementation more appropriate for smaller MCUs
could be implemented. That was my thought when providing this as a
configuration
point.

Cynthia mentioned that the avr-libc was completely missing sys/time.h so
the port could add an implementation of that file in score/cpu/avr for
now. If avr-libc is willing to add the .h file with this, then it would
be ok long term.

But the posix subdirectory has a few files which are built even when
--disable-posix is specified:

libposix_a_SOURCES += src/nanosleep.c src/clockgettime.c src/clocksettime.c \
    src/clockgetres.c src/sysconf.c

These need timespec and clockid_t plus sysconf.c needs the _SC_xxx constants
which are in unistd.h in newlib.

FYI it probably also needs to delete every file under the score/cpu/avr/avr/
directory since those are from an old avr-libc.

> I think this problem you found actually stems from the classic API Clock
> Manager (cpukit/rtems/include/rtems/rtems/clock.h) depends on struct timeval.

struct timespec and timeval are assumed to exist. You could disable
everything that depends on them.

Based on http://en.cppreference.com/w/c, I think these are POSIX and
not C99/C11.

This goes back to the requirements of what I have called "uRTEMS" for 
RTEMS on Microcontrollers. This is almost a throwback to version 1.x of
RTEMS where there was only the Classic API as defined by RTEID/ORKID.
No assumptions on C Library in the score and RTEMS -- not even memcpy.

If building a subset of RTEMS with a C99/C11 compiler and C Library
is the requirement, then you can't use anything with those types
in it.

> > I was really amazed that I could compile as much as I did without newlib
> > support!

In twenty years, we haven't broken much since newlib support came in
about 5 years after the project started.

> > So in summary, three issues: target restrictions, posix compliance checking
> > when posix is disabled, and score/timeval.

I think in score/cpu/avr/rtems/score/cpu.h, you should change this to FALSE:

#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE

And see how much farther you get. If you don't have timespec though, these
won't compile:

$ ls *spec*
coretodgetuptimetimespec.c  timespecfromticks.c  timespectoticks.c
timespecaddto.c             timespecisvalid.c    ts64totimespec.c
timespecdividebyinteger.c   timespeclessthan.c
timespecdivide.c            timespecsubtract.c

And don't worry about anything except C.  This is back to answering the
question:

What are the requirements for uRTEMS?

+ C99/C11 Standard Library Dependency only? 
+ Classic API only?
+ no BSP TCP/IP stack?
+ filesystem(s)?
+ stack checker?
+ ...

I know I am on a requirements kick lately but defining them is important for
this. I believe the Classic API should be OK for uRTEMS minus struct time*
based upon the original design parameters.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.