Changeset 620d699 in rtems
- Timestamp:
- Jun 14, 1995, 8:59:07 PM (26 years ago)
- Branches:
- 4.10, 4.11, 4.8, 4.9, 5, master
- Children:
- 68931b5
- Parents:
- 34d877e
- Location:
- c
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
c/ACKNOWLEDGEMENTS
r34d877e r620d699 39 39 support for the IDP board from the newlib/libgloss distribution. 40 40 41 + David Glessner (dwg@glenqcy.glenayre.com) 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. 46 41 47 Finally, the RTEMS project would like to thank those who have contributed 42 48 to the other free software efforts which RTEMS utilizes. The primary RTEMS -
c/PROBLEMS
r34d877e r620d699 5 5 This is the list of outstanding problems in this release. 6 6 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. 13 14 14 2.The only i960 family member tested is the CA. No support for the15 + The only i960 family member tested is the CA. No support for the 15 16 floating point support found in other family members is present. 16 17 This also implies that RTEMS may "think" of something as generic 17 18 across the i960 family when in fact it is specific to the CA. 18 19 19 3.The __read() system call in all of the BSPs using single20 + The __read() system call in all of the BSPs using single 20 21 character input/output needs to be smarter. The following 21 22 issues need to be addressed: … … 26 27 + tabs 27 28 28 4. Solaris 2.3port notes:29 + UNIX port notes: 29 30 30 31 + Some of the tests run correctly when run interactively but … … 34 35 + sometimes a stray SIGALRM is reported as spfatal completes. 35 36 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. 38 39 + CPU code appears to not set the interrupt level correctly 40 when doing a context initialization and sigsetjmp should be used. 41 42 + General cleanup and reorganization to enhance portability. 43 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. 49 50 + Some of the tests may execute correctly and not produce the exact 37 51 ordering of lines in the screen file. This appears to be a combination 38 52 of a number of factors including buffering, processor speed, IO 39 53 device overhead, and clock interrupt rate. 54 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. 60 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. 66 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: 69 70 + as part of some send requests 71 + on a non-successful receive response
Note: See TracChangeset
for help on using the changeset viewer.