Changeset 620d699 in rtems

06/14/95 20:59:07 (29 years ago)
Joel Sherrill <joel.sherrill@…>
4.10, 4.11, 4.8, 4.9, 5, master

added David Glessner's 68302 work to ACKNOWLEDGEMENTS.
updated PROBLEMS to reflect recently reported things.

2 edited



    r34d877e r620d699  
    3939  support for the IDP board from the newlib/libgloss distribution.
     41+ David Glessner ( of Glenayre Electronics
     42  submitted the support for the Motorola MC68302 CPU.  This included
     43  the "gen68302" BSP which uses the on-chip peripherals on the MC68302
     44  as well as the modifications to the m68k dependent executive code to
     45  support m68k family members based on the mc68000 core.
    4147Finally, the RTEMS project would like to thank those who have contributed
    4248to the other free software efforts which RTEMS utilizes.  The primary RTEMS

    r34d877e r620d699  
    55This is the list of outstanding problems in this release.
    7 1.  The m68000 support is not complete.  Someone with target hardware
    8     needs to complete the missing gaps.  Look for ifdef's based on the
    9     M68K_* macros defined in c/make/cpu/m68k.cfg.  Most of the code
    10     is present but none of it is tested.  An attempt was made to insert
    11     "#warnings" preprocessor directives in the appropriate places.
    12     So these are a good starting spot.
     7+   The m68000 support is not quite complete yet.  The missing piece
     8    inside the executive proper is support for the software interrupt
     9    stack.  Also, the m68k family has become quite large and an
     10    understanding of the compatibility of the peripherals on the various
     11    members of the 683xx family would allow someone to designate some
     12    of the drivers submitted for the gen68302 BSP as useful on other
     13    members.
    14 2.  The only i960 family member tested is the CA.  No support for the
     15+   The only i960 family member tested is the CA.  No support for the
    1516    floating point support found in other family members is present.
    1617    This also implies that RTEMS may "think" of something as generic
    1718    across the i960 family when in fact it is specific to the CA.
    19 3.  The __read() system call in all of the BSPs using single
     20+   The __read() system call in all of the BSPs using single
    2021    character input/output needs to be smarter.  The following
    2122    issues need to be addressed:
    2627       + tabs
    28 4.  Solaris 2.3 port notes:
     29+   UNIX port notes:
    3031       + Some of the tests run correctly when run interactively but
    3435       + sometimes a stray SIGALRM is reported as spfatal completes.
    36 5.  Some of the tests may execute correctly and not produce the exact
     37       + multiple BSPs need to be merged into a single source one.
     39       + CPU code appears to not set the interrupt level correctly
     40         when doing a context initialization and sigsetjmp should be used.
     42       + General cleanup and reorganization to enhance portability.
     44       +  Currently the routines which need to make access to the
     45          native library (not newlib) are spread across a number of
     46          directories.  There should be a "unix_XYZ" wrapper for every
     47          one of these routines so there is only 1 directory which directly
     48          references the "real" native library.
     50+   Some of the tests may execute correctly and not produce the exact
    3751    ordering of lines in the screen file.  This appears to be a combination
    3852    of a number of factors including buffering, processor speed, IO
    3953    device overhead, and clock interrupt rate.
     55+   The compiler configuration files (c/make/gcc-XYZ.cfg) are largely
     56    the same when the different targets have the same CPU.  It would
     57    be desirable to have a gcc-CPU.cfg or gcc-CPU_MODEL.cfg (e.g.
     58    gcc-m68k.cfg or gcc-m68020.cfg) and have the file gcc-TARGET.cfg
     59    include this and possibly override default settings.
     61+   The clock device drivers should really avoid doing the division
     62    by 1000 in the clock tick ISR to convert microseconds into
     63    milliseconds.  This only applies to clock drivers which generate
     64    an ISR each millisecond and only call rtems_clock_tick every
     65    so many ISRs.
     67+   The MP code for the Message Manager copies the message buffer
     68    in and out of the MPCI packet at at least two unecessary times:
     70      + as part of some send requests
     71      + on a non-successful receive response
Note: See TracChangeset for help on using the changeset viewer.