[ac7d5ef0] | 1 | # |
---|
| 2 | # $Id$ |
---|
| 3 | # |
---|
| 4 | |
---|
| 5 | This is the list of outstanding problems in this release. |
---|
| 6 | |
---|
[6ae41fd] | 7 | + The POSIX threads and real-time extensions are tested but this is |
---|
| 8 | the first release with them included. They are not enabled by |
---|
| 9 | default. The environment variable RTEMS_HAS_POSIX_API must be |
---|
| 10 | set to "yes" and the C language macro RTEMS_POSIX_API must be defined |
---|
| 11 | before this api is included in the build. |
---|
[07058e7] | 12 | |
---|
[6ae41fd] | 13 | + The shell scripts runtest and difftest do not work properly when |
---|
| 14 | testing "debug" executables. |
---|
| 15 | |
---|
| 16 | + AMD 29k port is based on a non-GNU toolset. |
---|
| 17 | |
---|
[d1c00a18] | 18 | + The test spfatal is out of date and as a result will NOT execute |
---|
| 19 | correctly. The addition of POSIX and consequent ongoing initialization |
---|
| 20 | reorganization makes it pointless to fix this until the POSIX support |
---|
| 21 | is completely in place. |
---|
| 22 | |
---|
[b7acc57f] | 23 | + The m68k family has become quite large and an understanding of the |
---|
| 24 | compatibility of the peripherals on the various members of the 683xx |
---|
| 25 | family would allow someone to designate some of the drivers submitted |
---|
| 26 | for the gen683xx BSPs as useful on other members. |
---|
[620d699] | 27 | |
---|
[b7acc57f] | 28 | + The only supported i960 family member is the CA. No support for the |
---|
[ac7d5ef0] | 29 | floating point support found in other family members is present. |
---|
| 30 | This also implies that RTEMS may "think" of something as generic |
---|
| 31 | across the i960 family when in fact it is specific to the CA. |
---|
[d1c00a18] | 32 | To make matters worse, the i960 target board owned by the RTEMS Project |
---|
| 33 | is now broken and as a result even the i960CA is a "compile only" port. |
---|
[ac7d5ef0] | 34 | |
---|
[7826883] | 35 | + Some of the BSPs still define RAM_START and RAM_END in the bsp.h file. |
---|
| 36 | It is better to define these in the linkcmds file. It is also nice |
---|
| 37 | to use the linkcmds file to place overlays for on-board hardware. |
---|
| 38 | |
---|
[6ae41fd] | 39 | + The __read(), __write(), etc. routines should be renamed __rtems_read(), |
---|
| 40 | etc. to avoid potential naming conflicts. [NOTE: This is already |
---|
| 41 | necessary under some versions of Linux with the unix port.] |
---|
| 42 | |
---|
[620d699] | 43 | + The __read() system call in all of the BSPs using single |
---|
[ac7d5ef0] | 44 | character input/output needs to be smarter. The following |
---|
| 45 | issues need to be addressed: |
---|
| 46 | |
---|
| 47 | + echoing of characters on input |
---|
| 48 | + CR/NL echoing |
---|
| 49 | + backspaces |
---|
| 50 | + tabs |
---|
| 51 | |
---|
[620d699] | 52 | + UNIX port notes: |
---|
[ac7d5ef0] | 53 | |
---|
| 54 | + sometimes a stray SIGALRM is reported as spfatal completes. |
---|
| 55 | |
---|
[07058e7] | 56 | + There are conflicts between the names of native library routines |
---|
| 57 | which MUST be used and those in the POSIX support. This must |
---|
| 58 | be addressed. |
---|
[620d699] | 59 | |
---|
| 60 | + Some of the tests may execute correctly and not produce the exact |
---|
[ac7d5ef0] | 61 | ordering of lines in the screen file. This appears to be a combination |
---|
| 62 | of a number of factors including buffering, processor speed, IO |
---|
| 63 | device overhead, and clock interrupt rate. |
---|
[620d699] | 64 | |
---|
| 65 | + The compiler configuration files (c/make/gcc-XYZ.cfg) are largely |
---|
| 66 | the same when the different targets have the same CPU. It would |
---|
| 67 | be desirable to have a gcc-CPU.cfg or gcc-CPU_MODEL.cfg (e.g. |
---|
| 68 | gcc-m68k.cfg or gcc-m68020.cfg) and have the file gcc-TARGET.cfg |
---|
| 69 | include this and possibly override default settings. |
---|
| 70 | |
---|
| 71 | + The clock device drivers should really avoid doing the division |
---|
| 72 | by 1000 in the clock tick ISR to convert microseconds into |
---|
| 73 | milliseconds. This only applies to clock drivers which generate |
---|
| 74 | an ISR each millisecond and only call rtems_clock_tick every |
---|
| 75 | so many ISRs. |
---|