From 3d4c7390de72aa8664c063d2bbf863b3a95bf7af Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Thu, 7 Nov 2002 15:46:17 +0000 Subject: 2002-11-07 Joel Sherrill * TOOL_TARGETS: Updated. * PROBLEMS, README, REQUIRES, TESTED, UPDATE_HELP: Removed since they were obsolete. --- c/PROBLEMS | 73 -------------------------------------------------------------- 1 file changed, 73 deletions(-) delete mode 100644 c/PROBLEMS (limited to 'c/PROBLEMS') diff --git a/c/PROBLEMS b/c/PROBLEMS deleted file mode 100644 index 0b22675ac5..0000000000 --- a/c/PROBLEMS +++ /dev/null @@ -1,73 +0,0 @@ -# -# $Id$ -# - -This is the list of outstanding problems in this release. - -+ 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. - -+ Not all of the BSP console drivers have been converted to termios. - Look at the m68k/gen68360, sparc/erc32, and powerpc/psim BSPs for - examples. - -+ 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. - - + Someone suggested writing a mini-system call interface to - include with RTEMS which would eliminate name conflicts. This - would allow the RTEMS POSIX API to be tested in this configuration. - -+ 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 biggest problem is that - some tests depend on polled IO with no unexpected context switches. - These may not be resolvable while maintaining the spirit of the test. - -+ 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. - -+ Cross-check configure --enable-* flags. - + warn/refuse to configure when --enable-libcdir and - --enable-gcc28 are given. - + force --enable-libcdir when --disable-gcc28 is given - -+ make profile does not currently work for a variety of reasons. Few - BSPs include profile versions of the libraries in their bsp_specs - file. There is no mechanism to sample data for gperf to process. - All of this will need to be addressed before "make profile" is truly - useful. - -+ Bare BSP does not compile for all configurations yet. This is - primarily due to libcpu support code assuming that the BSP has - made something available which is not with a bare BSP. -- cgit v1.2.3