# # $Id$ # This is the list of outstanding problems in this release. + The shell scripts runtest and difftest do not work properly when testing "debug" executables. + AMD 29k port is based on a non-GNU toolset. + The test spfatal is out of date and as a result will NOT execute correctly. The addition of POSIX and consequent ongoing initialization reorganization makes it pointless to fix this until the POSIX support is completely in place. + The m68k family has become quite large and an understanding of the compatibility of the peripherals on the various members of the 683xx family would allow someone to designate some of the drivers submitted for the gen683xx BSPs as useful on other members. + The only supported i960 family member is the CA. No support for the floating point support found in other family members is present. This also implies that RTEMS may "think" of something as generic across the i960 family when in fact it is specific to the CA. To make matters worse, the i960 target board owned by the RTEMS Project is now broken and as a result even the i960CA is a "compile only" port. + Some of the BSPs still define RAM_START and RAM_END in the bsp.h file. It is better to define these in the linkcmds file. It is also nice to use the linkcmds file to place overlays for on-board hardware. + The __read() system call in all of the BSPs using single character input/output needs to be smarter. The following issues need to be addressed: + echoing of characters on input + CR/NL echoing + backspaces + tabs + UNIX port notes: + sometimes a stray SIGALRM is reported as spfatal completes. + There are conflicts between the names of native library routines which MUST be used and those in the POSIX support. This must be addressed. The POSIX API cannot be used with this port as a result of this. + Some of the tests may execute correctly and not produce the exact ordering of lines in the screen file. This appears to be a combination of a number of factors including buffering, processor speed, IO device overhead, and clock interrupt rate. + The clock device drivers should really avoid doing the division by 1000 in the clock tick ISR to convert microseconds into milliseconds. This only applies to clock drivers which generate an ISR each millisecond and only call rtems_clock_tick every so many ISRs.