Completes coding of the PWM module

git-svn-id: https://nuttx.svn.sourceforge.net/svnroot/nuttx/trunk@4200 7fd9a85b-ad96-42d3-883c-3090e2eb8679

1 files changed, 1542 insertions, 0 deletions

diff --git a/nuttx/TODO b/nuttx/TODO
new file mode 100644
index 000000000..34e130dee
--- /dev/null
+++ b/nuttx/TODO
@@ -0,0 +1,1542 @@
+NuttX TODO List (Last updated December 3, 2011)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This file summarizes known NuttX bugs, limitations, inconsistencies with 
+standards, things that could be improved, and ideas for enhancements.
+
+nuttx/
+
+  (5)  Task/Scheduler (sched/)
+  (1)  On-demand paging (sched/)
+  (1)  Memory Managment (mm/)
+  (2)  Signals (sched/, arch/)
+  (1)  pthreads (sched/)
+  (2)  C++ Support
+  (5)  Binary loaders (binfmt/)
+ (16)  Network (net/, drivers/net)
+  (2)  USB (drivers/usbdev, drivers/usbhost)
+  (7)  Libraries (lib/)
+ (10)  File system/Generic drivers (fs/, drivers/)
+  (1)  Graphics subystem (graphics/)
+  (1)  Pascal add-on (pcode/)
+  (1)  Documentation (Documentation/)
+  (7)  Build system / Toolchains
+  (6)  Linux/Cywgin simulation (arch/sim)
+  (4)  ARM (arch/arm/)
+  (1)  ARM/C5471 (arch/arm/src/c5471/)
+  (3)  ARM/DM320 (arch/arm/src/dm320/)
+  (2)  ARM/i.MX (arch/arm/src/imx/)
+  (3)  ARM/LPC17xx (arch/arm/src/lpc17xx/)
+  (7)  ARM/LPC214x (arch/arm/src/lpc214x/)
+  (2)  ARM/LPC313x (arch/arm/src/lpc313x/)
+  (3)  ARM/STR71x (arch/arm/src/str71x/)
+  (3)  ARM/LM3S6918 (arch/arm/src/lm3s/)
+  (4)  ARM/STM32 (arch/arm/src/stm32/)
+  (3)  AVR (arch/avr)
+  (0)  Intel x86 (arch/x86)
+  (4)  8051 / MCS51 (arch/8051/)
+  (1)  MIPS (arch/mips)
+  (1)  Hitachi/Renesas SH-1 (arch/sh/src/sh1)
+  (4)  Renesas M16C/26 (arch/sh/src/m16c)
+ (10)  z80/z8/ez80 (arch/z80/)
+  (8)  z16 (arch/z16/)
+  (1)  mc68hc1x (arch/hc)
+
+apps/
+
+  (5)  Network Utilities (apps/netutils/)
+  (5)  NuttShell (NSH) (apps/nshlib)
+  (5)  Other Applications & Tests (apps/examples/)
+
+o Task/Scheduler (sched/)
+  ^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       CHILD PTHREAD TERMINATION
+  Description: When a tasks exits, shouldn't all of its child pthreads also be
+               terminated?
+  Status:      Open
+  Priority:    Medium, required for good emulation of process/pthread model.
+
+  Title:       MULTIPLE ATEXIT() FUNCTIONS
+  Description: atexit() supports registration of only single function called on
+               exit().  It should support multiple functions registered by atexit()
+               or onexit() and these should be called in reverse order of
+               registration when the task exits.
+  Status:      Open
+  Priority:    Low
+
+  Title:       MMAN.H
+  Description: Implement sys/mman.h and functions
+  Status:      Open
+  Priority:    Low
+
+  Title:       WAIT.H
+  Description: Implement sys/wait.h and functions.  Consider implementing wait,
+               waitpid, waitid.  At present, a parent has no information about
+               child tasks.
+
+               Update: A simple but usable version of waitpid() has been included.
+               This version is not compliant with all specifications and can be
+               enabled with CONFIG_SCHED_WAITPID. 
+  Status:      Open
+  Priority:    Low
+
+  Title:       MISSING ERRNO SETTINGS
+  Description: Several APIs do not set errno.  Need to review all APIs.
+  Status:      Open
+  Priority:    Medium, required for standard compliance (but makes the
+               code bigger)
+
+o On-demand paging (sched/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       ON-DEMAND PAGE INCOMPLETE
+  Description: On-demand paging has recently been incorporated into the RTOS.
+               The design of this feature is described here:
+               http://www.nuttx.org/NuttXDemandPaging.html.
+               As of this writing, the basic feature implementation is
+               complete and much of the logic has been verified.  The test
+               harness for the feature exists only for the NXP LPC3131 (see
+               configs/ea3131/pgnsh and locked directories).  There are
+               some limitations of this testing so I still cannot say that
+               the feature is fully functional.
+  Status:      Open
+  Priority:    Medium-Low
+
+o Other core OS logic
+  ^^^^^^^^^^^^^^^^^^^
+
+  Title:       GET_ENVIRON_PTR()
+  Description: get_environ_ptr() (sched/sched_getenvironptr.c) is not implemented.
+               The representation of the the environment strings selected for
+               NutX is not compatible with the operation.  Some significant
+               re-design would be required to implement this funcion and that
+               effort is thought to be not worth the result.
+  Status:      Open
+  Priority:    Low -- There is no plan to implement this.
+
+  Title:       TIMER_GETOVERRUN()
+  Description: timer_getoverrun() (sched/timer_getoverrun.c) is not implemented.
+  Status:      Open
+  Priority:    Low -- There is no plan to implement this.
+
+o Memory Managment (mm/)
+  ^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       FREE MEMORY ON TASK EXIT
+  Description: Add an option to free all memory allocated by a task when the
+               task exits. This is probably not be worth the overhead for a
+               deeply embedded system.
+               There would be complexities with this implementation as well
+               because often one task allocates memory and then passes the
+               memory to another:  The task that "owns" the memory may not
+               be the same as the task that allocated the memory.
+  Status:      Open
+  Priority:    Medium/Low, a good feature to prevent memory leaks but would
+               have negative impact on memory usage and code size.
+
+o Signals (sched/, arch/)
+  ^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       STANDARD SIGNALS
+  Description: 'Standard' signals and signal actions are not supported.
+               (e.g., SIGINT, SIGCHLD, SIGSEGV, etc).
+  Status:      Open
+  Priority:    Low, required by standards but not so critical for an
+               embedded system.
+
+  Title:       SIGEV_THREAD
+  Description: sig_notify() logic does not support SIGEV_THREAD; structure
+               struct sigevent does not provide required members sigev_notify_function
+               or sigev_notify_attributes.
+  Status:      Low, there are alternative designs.  However, these features
+               are required by the POSIX standard.
+  Priority:    Low for now
+
+o pthreads (sched/)
+  ^^^^^^^^^^^^^^^^^
+
+  Title:       CANCELLATION POINTS
+  Description: pthread_cancel():  Should implement cancellation points and
+               pthread_testcancel()
+  Status:      Open
+  Priority:    Low, probably not that useful
+
+o C++ Support
+  ^^^^^^^^^^^
+
+  Title:       USE OF SIZE_T IN NEW OPERATOR
+  Description: The argument of the 'new' operators should take a type of
+               size_t (see libxx/libxx_new.cxx and libxx/libxx_newa.cxx).  But
+               size_t has an unknown underlying.  In the nuttx sys/types.h
+               header file, size_t is typed as uint32_t (which is determined by
+               architecture-specific logic).  But the C++ compiler may believe
+               that size_t is of a different type resulting in compilation errors
+               in the operator.  Using the underlying integer type Instead of
+               size_t seems to resolve the compilation issues.
+  Status:      Kind of open.  There is a workaround.  Setting CONFIG_CXX_NEWLONG=y
+               will define the operators with argument of type unsigned long;
+               Setting CONFIG_CXX_NEWLONG=n will define the operators with argument
+               of type unsigned int.  But this is pretty ugly!  A better solution
+               would be to get ahold of the compilers definition of size_t.
+  Priority:    Low.
+
+  Title:       STATIC CONSTRUCTORS
+  Description: Need to call static constructors
+  Status:      Open
+  Priority:    Low, depends on toolchain.  Call to gcc's built-in static
+               constructor logic will probably have to be performed by
+               user logic in user_start().
+
+o Binary loaders (binfmt/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       NXFLAT TESTS
+  Description: Not all of the NXFLAT test under apps/examples/nxflat are working.
+               Most simply do not compile yet.  tests/mutex runs okay but
+               outputs garbage on completion.
+  Status:      Open
+  Priority:    High
+
+  Title:       ARM UP_GETPICBASE()
+  Description: The ARM up_getpicbase() does not seem to work.  This means
+               the some features like wdog's might not work in NXFLAT modules.
+  Status:      Open
+  Priority:    Medium-High
+
+  Title:       READ-ONLY DATA IN RAM
+  Description: At present, all .rodata must be put into RAM.  There is a 
+               tentative design change that might allow .rodata to be placed
+               in FLASH (see Documentation/NuttXNxFlat.html).
+  Status:      Open
+  Priority:    Medium
+
+  Title:       GOT-RELATIVE FUNCTION POINTERS
+  Description: If the function pointer to a statically defined function is
+               taken, then GCC generates a relocation that cannot be handled
+               by NXFLAT.  There is a solution described in Documentataion/NuttXNxFlat.html,
+               by that would require a compiler change (which we want to avoid).
+               The simple workaround is to make such functions global in scope.
+  Status:      Open
+  Priority:    Low (probably will not fix)
+
+  Title:       USE A HASH INSTEAD OF A STRING IN SYMBOL TABLES
+  Description: In the NXFLAT symbol tables... Using a 32-bit hash value instead
+               of a string to identify a symbol should result in a smaller footprint.
+  Status:      Open
+  Priority:    Low
+
+  Title:       WINDOWS-BASED TOOLCHAIN BUILD
+  Description: Windows build issue.  Some of the configurations that use NXFLAT have
+               the linker script specified like this:
+
+               NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld -no-check-sections
+
+               That will not work for windows-based tools because they require Windows
+               style paths.  The solution is to do something like this:
+
+               if ($(WINTOOL)y)
+                 NXFLATLDSCRIPT=${cygpath -w $(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld}
+               else
+                 NXFLATLDSCRIPT=$(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld
+               endif
+               
+               Then use
+               
+               NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T"$(NXFLATLDSCRIPT)" -no-check-sections
+
+  Status:      Open
+  Priority:    There are too many references like the above.  They will have
+               to get fixed as needed for Windows native tool builds.
+
+o Network (net/, drivers/net)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       SOCK_RAW/SOCK_PACKET
+  Description: Should implement SOCK_RAW, SOCK_PACKET
+  Status:      Open
+  Priority:    Low
+
+  Tile:        MULTIPLE NETWORK INTERFACE SUPPORT
+  Description: uIP polling issues / Multiple network interface support:
+               (1) Current logic will not support multiple ethernet drivers.
+                  Each driver should poll on TCP connections connect on the
+                  network supported by the driver; UDP polling should respond
+                  with TX data only if the UDP packet is intended for the
+                  the network supported by the driver.
+               (2) If there were multiple drivers, polling would occur at
+                  double the rate.  Fix by using bound IP address in TCP
+                  connection (lipaddr) and verifying that it is in the subnet
+                  served by the driver.
+  Status:      Open
+  Priority:    Medium, The feature is not important, but it is important
+               for NuttX to resolve the architectural issues.
+
+  Title:       SENTDO() AND MULTIPLE NETWORK INTERFACE SUPPORT
+  Description: sendto() and multiple network interface support:
+               When polled, would have to assure that the destination IP
+               is on the subnet served by the polling driver.
+  Status:      Open
+  Priority:    Medium, The feature is not important, but it is important
+               for NuttX to resolve the architectural issues.
+
+  Title:       IPv6
+  Description: IPv6 support is incomplete.  Adam Dunkels has recently announced
+               IPv6 support for uIP (currently only as part of Contiki).  Those
+               changes need to be ported to NuttX.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       LISTENING FOR UDP BROADCASTS
+  Description: Incoming UDP broadcast should only be accepted if listening on
+               INADDR_ANY(?)
+  Status:      Open
+  Priority:    Low
+
+  Title:       READ-AHEAD THROTTLING
+  Description: Read-ahead buffers capture incoming TCP data when no user
+               thread is recv-ing the data.  Should add some driver call to
+               support throttling; when there is no listener for new data, the
+               driver should be throttled.  Perhaps the driver should disable
+               RX interrupts when throttled and re-anable on each poll time.
+               recvfrom would, of course, have to un-throttle.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       STANDARDIZE ETHERNET DRIVER STATISTICS
+  Description: Need to standardize collection of statistics from network
+               drivers.  apps/nshlib ifconfig command should present
+               statistics.
+  Status:      Open
+  Priority:    Low
+
+  Title:       CONCURRENT TCP SEND OPERATIONS
+  Description: At present, there cannot be two concurrent active TCP send
+               operations in progress using the same socket.  This is because
+               the uIP ACK logic will support only one transfer at a time.  The
+               solution is simple: A mutex will be needed to make sure that each 
+               send that is started is able to be the exclusive sender until all of
+               the data to be sent has been ACKed.
+  Status:      Open.  There is some temporary logic to apps/nshlib that does
+               this same fix and that temporary logic should be removed when
+               send() is fixed.
+  Priority:    Medium-Low.  This is an important issue for applications that
+               send on the same TCP socket from multiple threads.
+
+  Title:       UDP READ-AHEAD?
+  Description: TCP supports read-ahead buffering to handle the receipt of
+               TCP/IP packets when there is no read() in place.  Should such
+               capability be useful for UDP?  PRO: Would reduce packet loss
+               and enable support for poll()/select().  CON: UDP is inherently
+               lossy so why waste memory footprint?
+  Status:      Open
+  Priority:    Medium
+
+  Title:       NO POLL/SELECT ON UDP SOCKETS
+  Description: poll()/select() is not implemented for UDP sockets because they do
+               do not support read-ahead buffering.  Therefore, there is never
+               a case where you can read from a UDP socket without blocking.
+  Status:      Open, depends on UDP read-ahead support
+  Priority:    Medium
+
+  Title:       POLL/SELECT ON TCP SOCKETS NEEDS READ-AHEAD
+  Description: poll()/select() only works for availability of buffered TCP
+               read data (when read-ahead is enabled).  The way writing is
+               handled in uIP, all sockets must wait when send and cannot
+               be notifiied when they can send without waiting.
+  Status:      Open, probably will not be fixed.
+  Priority:    Medium... this does effect porting of applications that expect
+               different behavior from poll()/select()
+
+  Title:       SOCKETS DO NOT ALWAYS SUPPORT O_NONBLOCK
+  Description: sockets do not support all modes for O_NONBLOCK. Sockets
+               support only (1) TCP/IP non-blocking read operations when read-ahead
+               buffering is enabled, and (2) TCP/IP accept() operations when TCP/IP
+               connection backlog is enabled.
+  Status:      Open
+  Priority:    Low.
+
+  Title:       UNFINISHED CRYSTALLAN CS89X0 DRIVER
+  Description: I started coding a CrystalLan CS89x0 driver (drivers/net/cs89x0.c),
+               but never finished it.
+  Status:      Open
+  Priority:    Low unless you need it.
+
+  Title:       UNFINISHED ENC28J60 DRIVER
+  Description: So far, I have not come up with a usable hardware platform to
+               verify the ENC28J60 Ethernet driver (drivers/net/enc28j60.c).
+               So it is untested.
+  Status:      Open
+  Priority:    Low unless you need it.
+
+  Title:       UNTESTED IGMPv2
+  Description: Support for client-side IGMPv2 multicast has been added but not yet
+               tested (because I don't have a proper environment for multicast testing).
+               There are most likely errors that need to be fixed at least in the
+               receipt of multicast packets.
+
+               In addition, an ethernet driver that needs to work with the IGMP logic
+               will have to include additional support for multicast MAC address tables.
+  Status:      Open
+  Priority:    Low unless you need it.
+
+  Title:       INTERFACES TO LEAVE/JOIN IGMP MULTICAST GROUP
+  Description: The interfaces used to leave/join IGMP multicast groups is non-standard.
+               RFC3678 (IGMPv3) suggests ioctl() commands to do this (SIOCSIPMSFILTER) but
+               also status that those APIs are historic.  NuttX implements these ioctl
+               commands, but is non-standard because:  (1) It does not support IGMPv3, and
+               (2) it looks up drivers by their device name (eg., "eth0") vs IP address.
+
+               Linux uses setsockopt() to control multicast group membership using the
+               IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP options.  It also looks up drivers
+               using IP addresses (It would require additional logic in NuttX to look up
+               drivers by IP address).  See http://tldp.org/HOWTO/Multicast-HOWTO-6.html
+  Status:      Open
+  Priority:    Medium.  All standards compatibility is important to NuttX.  However, most
+               the mechanism for leaving and joining groups is hidden behind a wrapper
+               function so that little of this incompatibilities need be exposed.
+
+  Title:       CONFIGURATIONS WITH TINY MTUS
+  Description: Many configurations have the MTU (CONFIG_NET_BUFSIZE) set to very small
+               numbers, less then the minimum MTU size that must be supported -- 576.
+               This can cause problems in some networks:  CONFIG_NET_BUFSIZE should
+               be set to at least 576 in all defconfig files.
+
+               The symptoms of using very small MTU sizes can be very strange.  With
+               Ubuntu 9.x and vsFtpd was that the total packet size did *not match* the
+               packet size in the IP header.  This then caused a TCP checksum failure
+               and the packet was rejected.
+  Status:      Open
+  Priority:    Low... fix defconfig files as necessary.
+
+o USB (drivers/usbdev, drivers/usbhost)
+  ^^^^^^^^^^^^^^^^^^^^
+
+  Title:       USB STORAGE DRIVER DELAYS
+  Description: There is a workaround for a bug in drivers/usbdev/usbdev_storage.c.
+               that involves delays.  This needs to be redesigned to eliminate these delays.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       RTL8187 DRIVER IS UNFINISHED
+  Description: misc/drivers/usbhost_rtl8187.c is a work in progress.  There is no RTL8187
+               driver available yet.  That is a work in progress it was abandoned because
+               it depends on having an 802.11g stack.
+  Status:      Open
+  Priority:    Low (Unless you need RTL8187 support).
+
+o Libraries (lib/)
+  ^^^^^^^^^^^^^^^^
+
+  Title:       ENVIRON
+  Description: The definition of environ in stdlib.h is bogus and will not
+               work as it should.  This is because the underlying
+               representation of the environment is not an arry of pointers.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       FGETS IMPLEMENTATION
+  Description: fgets implementation does not use C-buffered I/O, but rather
+               talks to serial driver directly via read().  It includes VT-100
+               specific editting commands.  This gets should be renamed readlin()
+               and a more generic fgets() should be implemented.
+  Status:      Open
+  Priority:    Low (unless you are using mixed C-buffered I/O with fgets and
+               fgetc, for example).
+
+  Title:       TERMIOS
+  Description: Need some minimal termios support... at a minimum, enough to
+               switch between raw and "normal" modes to support behavior like
+               that needed for readline().
+  Status:      Open
+  Priority:    Low
+
+  Title:       DAYS OF THE WEEK
+  Description: strftime() and other timing functions do not handle days of the week.
+  Status:      Open
+  Priority:    Low
+
+  Title:       RESETTING GETOPT()
+  Description: There is an issue with the way that getopt() handles errors that
+               return '?'.
+               
+               1. Does getopt() reset its global variables after returning '?' so
+                  that it can be re-used?  That would be required to support where
+                  the caller terminates parsing before reaching the last parameter.
+               2. Or is the client expected to continue parsing after getopt()
+                  returns '?'  and parse until the final parameter?
+            
+               The current getopt() implementation only supports #2.
+  Status:      Open
+  Priority:    Low
+
+  Title:       FERROR() AND CLEARERR()
+  Description: Not implemented: ferror() and clearerr()
+  Status:      Open
+  Priority:    Low
+
+  Title:       CONCURRENT STREAM READ/WRITE
+  Description: NuttX only supports a single file pointer so reads and writes 
+               must be from the same position.  This prohibits implementation
+               of behavior like that required for fopen() with the "a+" mode.
+               According to the fopen man page:
+               
+               "a+ Open for reading and appending (writing at end of file).
+                The file is created if it does not exist. The initial file
+                position for reading is at the beginning of the file, but
+                output is always appended to the end of the file."
+
+               At present, the single NuttX file pointer is positioned to the
+               end of the file for both reading and writing.
+  Status:      Open
+  Priority:    Medium.  This kind of operation is probably not very common in
+               deeply embedded systems but is required by standards.
+
+o File system / Generic drivers (fs/, drivers/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  NOTE:  The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt
+
+  Title:       CHMOD() AND TRUNCATE()
+  Description: Implement chmod(), truncate().
+  Status:      Open
+  Priority:    Low
+
+  Title:       CAN POLL SUPPORT
+  Description: At present, the CAN driver does not support the poll() method.
+  Status:      Open
+  Priority:    Low
+
+  Title:       REMOVING PIPES AND FIFOS
+  Description: There is no way to remove a FIFO or PIPE created in the
+               psuedo filesystem.  Once created, they persist indefinitely
+               and cannot be unlinked.  This is actually a more generic
+               issue:  unlink does not work for anything in the psuedo-
+               filesystem.
+  Status:      Open, but partially resolved: pipe buffer is at least freed
+               when there are not open references to the pipe/FIFO.
+  Priority:    Medium
+
+  Title:       ROMFS CHECKSUMS
+  Description: The ROMFS file system does not verify checksums on either
+               volume header on on the individual files.
+  Status:      Open
+  Priority:    Low.  I have mixed feelings about if NuttX should pay a
+               performance penalty for better data integrity.
+
+  Title:       SPI-BASED SD MULTIPLE BLOCK TRANSFERS
+  Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
+               yet handle multiple block transfers.
+  Status:      Open
+  Priority:    Medium-Low
+
+  Title:       READ-AHEAD/WRITE BUFFER UNTESTED
+  Description: Block driver read-ahead buffer and write buffer support is
+               implemented but not yet tested.
+  Status:      Open
+  Priority:    Low
+
+  Title:       SDIO-BASED SD READ-AHEAD/WRITE BUFFERING INCOMPLETE
+  Description: The drivers/mmcsd/mmcsd_sdio.c driver has hooks in place to
+               support read-ahead buffering and write buffering, but the logic
+               is incomplete and untested.
+  Status:      Open
+  Priority:    Low
+
+  Title:       ENC29J60 DRIVER UNTESTED
+  Description: ENC28J60 driver is complete, but untested (I still haven't got
+               a good ENC28J60 test platform).
+  Status:      Open
+  Priority:    Low
+
+  Title:       SERIAL DRIVER DOES NOT RETURN WHEN SIGNAL RECEIVED
+  Description: The serial driver (drivers/serial) should return with an
+               error and errno=EINTR when an interrupt is received.  However,
+               the serial driver just continues waiting:
+
+               static void uart_takesem(FAR sem_t *sem)
+               {
+                 while (sem_wait(sem) != 0)
+                   {
+                     ASSERT(*get_errno_ptr() == EINTR);
+                   }
+               }
+  Status:      Open
+  Priority     Medium
+
+  Title:       POLLHUP SUPPORT
+  Description: All drivers that support the poll method should also report
+               POLLHUP event when the driver is closedd.
+  Status:      Open
+  Priority:    Medium-Low
+
+o Graphics subystem (graphics/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       UNTESTED GRAPHICS APIS
+  Description: Testing of all APIs is not complete.  See
+               http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage
+  Status:      Open
+  Priority:    Medium
+
+  Title:       ITALIC FONTS / NEGATIVE FONT OFFSETS
+  Description: Font metric structure (in include/nuttx/nx/nxfont.h) should allow
+               negative X offsets. Negative x-offsets are necessary for certain
+               glyphs (and is very common in italic fonts).
+               For example Eth, icircumflex, idieresis, and oslash should have
+               offset=1 in the 40x49b font (these missing negative offsets are
+               NOTE'ed in the font header files).
+  Status:      Open.  The problem is that the x-offset is an unsigned bitfield
+               in the current structure.
+  Priority:    Low.
+
+o Pascal Add-On (pcode/)
+  ^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       P-CODES IN MEMORY UNTESTED
+  Description: Need APIs to verify execution of P-Code from memory buffer.
+  Status:      Open
+  Priority:    Low
+
+  Title:       SMALLER LOADER AND OBJECT FORMAT
+  Description: Loader and object format may be too large for some small
+               memory systems.  Consider ways to reduce memory footprint.
+  Status:      Open
+  Priority:    Medium
+
+o Documentation (Documentation/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       DOCUMENT APIS USABLE FROM INTERRUPT HANDLERS
+  Description: Need to document which APIs can be used in interrupt
+               handlers (like mq_send and sem_post) and which cannot.
+  Status:      Open
+  Priority:    Low
+
+o Build system
+  ^^^^^^^^^^^^
+
+  Title:       DEPENDENCIES IN THE BOARD DIRECTORY
+  Description: Dependencies do not work correctly under configs/<board>/src
+               (same as arch/<arch>/src/board).
+  Status:      Open
+  Priority:    Medium (maybe higher for z80 target)
+
+  Title:       NUTTX CONFIGURATION TOOL
+  Description: Need a NuttX configuration tool.  The number of configuration
+               settings has become quite large and difficult to manage manually.
+  Status:      Open
+  Priority:    Medium-low
+
+  Title:       NATIVE WINDOWS BUILD
+  Description: At present, NuttX builds only under Linux or Cygwin.
+               Investigate the possibility of a native Windows build using
+               something like the GNUWin32 tools (coreutils+make+grep+sed+uname).
+  Status:      Open
+  Priority:    Low
+
+  Title:       WINDOWS DEPENDENCY GENERATION
+  Description: Dependency generation is currently disabled when a Windows native
+               toolchain is used.  I think that the only issue is that all of the
+               Windows dependencies needed to be quoted in the Make.dep files.
+  Status:      Open
+  Priority:    Low -- unless some dependency-related build issues is discovered.
+
+  Title:       SETENV.H
+  Description: Logic in most setenv.sh files can create the following problem
+               on many platforms:
+
+                 $ . ./setenv.sh
+                 basename: invalid option -- 'b'
+                 Try `basename --help' for more information.
+
+               The problem is that $0 is the current running shell which may include
+               a dash in front:
+
+                 $ echo $0
+                 -bash
+
+               But often is just /bin/bash (and the problem does not occur.  The fix
+               is:
+
+                 -if [ "$(basename $0)" = "setenv.sh" ]; then
+                 +if [ "$_" = "$0" ] ; then
+  Status:      Open
+  Priority:    Low.  Use of setenv.sh is optional and most platforms do not have
+               this problem.  Scripts will be fixed one-at-a-time as is appropropriate.
+
+  Title:       MAKE EXPORT LIMITATIONS
+  Description: The top-level Makefile 'export' target that will bundle up all of the
+               NuttX libraries, header files, and the startup object into an export-able
+               tarball. This target uses the tools/mkexport.sh script.  Issues:
+
+               1. This script assumes the host archiver ar may not be appropriate for
+                  non-GCC toolchains
+               2. For the kernel build, the user libraries should be built into some
+                  libuser.a.  The list of user libraries would have to accepted with
+                  some new argument, perhaps -u.
+  Status:      Open
+  Priority:    Low.
+
+  Title:       KERNEL BUILD MODE ISSUES
+  Description: In the kernel build mode (where NuttX is built as a monlithic
+               kernel and user code must trap into the protected kernel via
+               syscalls), the single user mode cannot be supported.  In this
+               built configuration, only the multiple user mode can be supported
+               with the NX server residing inside of the kernel space.  In
+               this case, most of the user end functions in graphics/nxmu
+               must be moved to lib/nx and those functions must be built into
+               libuser.a to be linked with the user-space code.
+  Status:      Open
+  Priority:    Low -- the kernel build configuration is not fully fielded
+               yet.
+
+o Linux/Cywgin simulation (arch/sim)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       SIMULATED SERIAL DRIVER
+  Description: The simulated serial driver has some odd behavior.  It
+               will stall for a long time on reads when the C stdio buffers are
+               being refilled. This only effects the behavior of things like
+               fgetc().  Workaround: Set CONFIG_STDIO_BUFFER_SIZE=0, suppressing
+               all C buffered I/O.
+  Status:      Open
+  Priority:    Low (because the simulator is only a test/development platform)
+
+  Title:       SIMULATOR BUILD ON 64-BIT MACHINES
+  Description: Simulator does not build correctly on 64-bit machines.  Two
+               issues:
+               1) It saves addresses in 32-bit types and these fail when cast
+                  to pointers on a 64-bit host.
+               2) up_setjmp.S does not build
+  Status:      Open
+  Priority:    Medium and increasing (as 32-bit hosts gradually disappear).  NOTE
+               is it possible to work-around this limitation by building the sim
+               target for 32-bit operation on a 64-bit platform.  Modify the
+               Make.defs file in the appropriate places so that -m32 is included
+               in the CFLAGS and -m32 and -melf_386 are included in the LDFLAGS.
+               See the patch 0001-Quick-hacks-to-build-sim-nsh-ostest-on-x86_64-as-32-.patch
+               that can be found at http://tech.groups.yahoo.com/group/nuttx/files.
+
+  Title:       SIMULATOR NETWORKING SUPPORT
+  Description: I never did get networking to work on the sim Linux target.  On Linux,
+               it tries to use the tap device (/dev/net/tun) to emulate an Ethernet
+               NIC, but I never got it correctly integrated with the NuttX networking.
+               NOTE: On Cygwin, the build uses the Cygwin WPCAP library and is, at
+               least, partially functional (it has never been rigorously tested).
+  Status:      Open
+  Priority:    Low (unless you want to test networking features on the simulation).
+  
+  Title:       ROUND-ROBIN SCHEDULING IN THE SIMULATOR
+  Description: Since the simulation is not pre-emptible, you can't use round-robin
+               scheduling (no time slicing).  Currently, the timer interrupts are
+               "faked" during IDLE loop processing and, as a result, there is no
+               task pre-emption because there are no asynchrous events.  This could
+               probably be fixed if the "timer interrupt" were driver by Linux
+               signals. NOTE:  You would also have to implement irqsave() and
+               irqrestore() to block and (conditionally) unblock the signal.
+  Status:      Open
+  Priority:    Low
+  
+  Title:       NSH ISSUES ON THE SIMULATOR
+  Descripion:  The NSH example has some odd behaviors.  Mult-tasking -- for example,
+               execution of commands in background -- does not work normally.  This
+               is due to the fact that NSH uses the system standard input for the
+               console.  This means that the simulation is actually "frozen" all of
+               the time when NSH is waiting for input and background commands never
+               get the chance to run.
+  Status:      Open
+  Priority:    This will not be fixed.  This is the normal behavior in the current
+               design of the simulator.  "Real" platforms will behave correctly
+               because NSH will "sleep" when it waits for console inpu and other
+               tasks can run freely.
+
+  Title:       DOUBLE COMMAND ECHO
+  Description: In the NSH example, the host HOST echoes each command so after you
+               you enter a command, the command is repeated on the next line.  This
+               is an artifact of the simulator only.
+  Status:      Open
+  Priority:    This will not be fixed.  This is the normal behavior in the current
+               design of the simulator.  "Real" platforms will behave correctly.
+
+o ARM (arch/arm/)
+  ^^^^^^^^^^^^^^^
+
+  Title:       IMPROVED ARM INTERRUPT HANDLING
+  Description: ARM interrupt handling performance could be improved in some
+               ways. One easy way is to use a pointer to the context save
+               area in current_regs instead of using up_copystate so much.
+               see handling of 'current_regs" in arch/arm/src/armv7-m/* for
+               examples of how this might be done.
+  Status:      Open
+  Priority:    Low
+
+  Title:       IMPROVED ARM INTERRUPT HANDLING
+  Description: The ARM and Cortex-M3 interrupt handlers restores all regisers
+               upon return. This could be improved as well:  If there is no
+               context switch, then the static registers need not be restored
+               because they will not be modified by the called C code.
+               (see arch/sh/src/sh1/sh1_vector.S for example)
+  Status:      Open
+  Priority:    Low
+
+  Title:       SVCALLS AND HARDFAULTS
+  Description: The Cortex-M3 user context switch logic uses SVCall instructions.
+               This user context switching time could be improved by eliminating
+               the SVCalls and developing assembly language implementations
+               of the context save and restore logic.
+               Also, because interrupts are always disabled when the SVCall is
+               executed, the SVC goes to the hard fault handler where it must
+               be handled as a special case.  I recall seeing some controls
+               somewhere that will allow to suppress one hard fault.  I don't 
+               recall the control, but something like this should be used before
+               executing the SVCall so that it vectors directly to the SVC
+               handler.
+  Status:      Open
+  Priority:    Low
+
+  Title:       ARM INTERRUPTS AND USER MODE
+  Description: The ARM interrupt handling (arch/arm/src/arm/up_vectors.S) returns
+               using 'ldmia   sp, {r0-r15}^'  My understanding is that this works
+               fine because everything is in kernel-mode.  In an operating model
+               where applications run in user mode and interrupts/traps run in
+               kernel-mode, I think that there is a problem with this.  This would
+               like be a problem, for example, if for a kernel build where NuttX
+               is built as a monolithic, protected kernel and user mode programs
+               trap into the kernel.
+  Status:      Open
+  Priority:    Low until I get around to implementng security or kernel mode for
+               the ARM platform.
+
+o ARM/C5471 (arch/arm/src/c5471/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       UART RECONFIGURATION
+  Description: UART re-configuration is untested and conditionally compiled out.
+  Status:      Open
+  Priority:    Medium.  ttyS1 is not configured, but not used; ttyS0 is configured
+               by the bootloader
+
+o ARM/DM320 (arch/arm/src/dm320/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       DEBUG ISSUES
+  Description: config/ntos-dm320: It seems that when a lot of debug statements
+               are added, the system no longer boots.  This is suspected to be
+               a stack problem: Making the stack bigger or removing arrays on
+               the stack seems to fix the problem (might also be the
+               bootloader overwriting memory)
+  Status:      Open
+  Priority:    Medium
+
+  Title:       USB DEVICE DRIVER UNTESTED
+  Description: A USB device controller driver was added but has never been tested.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       FRAMEBUFFER DRIVER UNTESTED
+  Description: A framebuffer "driver" was added, however, it remains untested.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       VIDEO ENCODER DRIVER
+  Description: In order to use the framebuffer "driver" additional video encoder
+               logic is required to setupt composite video output or to interface
+               with an LCD.
+  Status:      Open
+  Priority:    Medium (high if you need to use the framebuffer driver)
+
+o ARM/i.MX (arch/arm/src/imx/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       PORT IS INCOMPLETE
+  Description: The basic port of the i.MX1 architecuture was never finished.  The port
+               is incomplete (as of this writing, is still lacks a timer, interrupt
+               decoding, USB, network) and untested.
+  Status:      Open
+  Priority:    Medium (high if you need i.MX1/L support)
+
+  Title:       SPI METHODS ARE NOT THREAD SAFE
+  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
+  Status:      Open
+  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.
+
+o ARM/LPC17xx (arch/arm/src/lpc17xx/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       USB DMA INCOMPLETE
+  Description: USB DMA not fully implemented. Partial logic is in place but it is
+               fragmentary and bogus. (Leveraged from the lpc214x)
+  Status:      Open
+  Priority:    Low
+
+  Title:       SSP DRIVER IMPROVEMENTS
+  Description: a) At present the SSP driver is polled.  Should it be interrupt driven?
+                  Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
+                  interrupt driven SPI driver.  Should be very easy to part that architecture
+                  to the LPC.
+               b) See other SSP (SPI) driver issues listed under ARM/LPC214x.  The LPC17xx
+                  driver is a port of the LPC214x driver and probably has the same issues.
+               b) Other SSP driver improvements: Add support for multiple devices on the
+                  SSP bus, use DMA data transfers
+  Status:      Open
+  Priority:    Medium
+
+  Title:       NOKIA LCD DRIVER NONFUNCTIONAL
+  Description: An LCD driver for the Olimex LPC1766STK has been developed.  However, that
+               driver is not yet functional on the board:  The backlight comes on, but
+               nothing is visible on the display.
+  Status:      Open
+  Priority:    Medium-Low (unless you need the display on the LPC1766STK!)
+
+o ARM/LPC214x (arch/arm/src/lpc214x/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       VECTOR INTERRUPTS
+  Description: Should use Vector Interrupts
+  Status:      Open
+  Priority:    Low
+
+  Title:       USB DMA INCOMPLETE
+  Description: USB DMA not fully implemented. Partial logic is in place but it is
+               fragmentary and bogus.
+  Status:      Open
+  Priority:    Low
+
+  Title:       USB SERIAL DRIVER REPORTS WRONG ERROR
+  Description: USB Serial Driver reports wrong error when opened before the
+               USB is connected (reports EBADF instead of ENOTCONN)
+  Status:      Open
+  Priority:    Low
+
+  Title:       SPI DRIVER IMPROVEMENTS
+  Description: At present the SPI driver is polled.  Should it be interrupt driven?
+               Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
+               interrupt driven SPI driver.  Should be very easy to part that architecture
+               to the LPC.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       SPI METHODS ARE NOT THREAD SAFE
+  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
+  Status:      Open
+  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.
+
+  Title:       SPI DRIVER DELAYS
+  Description: At present the SPI driver is polled -AND- there is a rather large, arbitrary,
+               delay in one of the block access routines.  The purpose of the delay is to
+               avoid a race conditions.  This begs for a re-design -OR- at a minimum, some
+               optimiation of the delay time.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       2GB SD CARD ISSUES
+  Desription:  I am unable to initialize a 2Gb SanDisk microSD card (in adaptor) on the
+               the mcu123 board.  The card fails to accept CMD0.  Doesn't seem like a software
+               issue, but if anyone else sees the problem, I'd like to know.
+               Related:  Fixes were recently made for the SDIO-based MMC/SD driver to
+               support 2Gb cards -- the blocksize was forced to 512 in all cases.  The SPI-
+               based driver may also have this problem (but I don't think this would have
+               anything to do with CMD0).
+  Status:      Open
+  Priority:    Uncertain
+
+  Title:       USB DEVICE DRIVER ISSUES?
+  Description: Possible errors in USB device driver reported "I suspect there's a few
+               issues in the lpc214x USB driver - in particular it doesn't stall both
+               in/out endpoints for unsupported setup requests and it doesn't call
+               CLASS_DISCONNCET on a USB reset - I don't have any access to that hardware
+               so can't pursue it really."
+  Status:      Open
+  Priority:    Medium
+
+o ARM/LPC313x (arch/arm/src/lpc313x/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       PLATFORM-SPECIFIC LOGIC
+  Description: arch/arm/src/lpc313x/lpc313x_spi.c contains logic that is specific to the
+               Embedded Artist's ea3131 board.  We need to abstract the assignment of SPI
+               chip selects and logic SPI functions (like SPIDEV_FLASH).  My thoughts are:
+               - Remove lpc313x_spiselect and lpc313x_spistatus from lpc313x_internal.h
+               - Remove configs/ea3131/src/up_spi.c
+               - Add configurations CONFIG_LPC3131x_CSOUT1DEV, CONFIG_LPC3131x_CSOUT2DEV,
+                 and CONFIG_LPC3131x_CSOUT3DEV that maps the lpc313x SPI chip selects to
+                 SPIDEV_* values.
+               - Change arch/arm/src/lpc313x/lpc313x_spi.c to use those configuration
+                 settings.
+  Status:      Open
+  Priority:    High if you want to use SPI on any board other than the ea3131.
+
+  Title:       SPI DRIVER
+  Description: arch/arm/src/lpc313x/lpc313x_spi.c may or may not be functional.  It was
+               reported to be working, but I was unable to get it working with the
+               Atmel at45dbxx serial FLASH driver.
+  Status:      Open
+  Priority:    High if you need to use SPI.
+
+o ARM/STR71x (arch/arm/src/str71x/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       UNVERIFIED MMC SUPPORT
+  Description: Verify SPI driver and integrate with MMC support. This effort is stalled
+               at the moment because the slot on the Olimex board only accepts MMC card;
+               I have no MMC cards, only SD cards which won't fit into the slot.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       NO USB DRIVER
+  Description: Develop a USB driver and integrate with existing USB serial and storage
+               class drivers.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       SPI METHODS ARE NOT THREAD SAFE
+  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
+  Status:      Open
+  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.
+
+o ARM/LM3S6918 (arch/arm/src/lm3s/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       I2C DRIVER
+  Description: Still need to implement I2C
+  Status:      Open
+  Priority:    Low
+
+  Title:       SSI OVERRUNS
+  Description: Should terminate SSI/SPI transfer if an Rx FIFO overrun occurs.
+               Right now, if an Rx FIFO overrun occurs, the SSI driver hangs.
+  Status:      Open
+  Priority:    Medium, If the transfer is properly tuned, then there should not
+               be any Rx FIFO overruns.
+
+  Title:       THTTPD BUGS
+  Description: There are some lingering bugs in THTTPD, possibly race conditions.  This
+               is covered above under Network Utilities, but is duplicated here
+               to point out that the LM3S suffers from this bug.
+  Status:      Open.
+               UPDATE: I have found that increasing the size of the CGI program stack
+               from 1024 to 2048 (on the LM3S) eliminates the problem.  So the most
+               likely cause is probably a stack overflow, not a hard sofware bug.
+  Priority:    Probably Low
+
+o ARM/STM32 (arch/arm/src/stm32/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       NOR FLASH DRIVER
+  Description: NOR Flash driver with FTL layer to support a file system.
+  Status:      Open
+  Priority:    Low
+
+  Title:       USBSERIAL ISSUES
+  Description  A USB device-side driver is in place but not well tested.  At
+               present, the apps/examples/usbserial test sometimes fails.  The situation
+               that causes the failure is:
+
+               - Host-side of the test started after the target side sends the
+                 first serial message.
+
+               The general failure is as follows:
+
+               - The target message pends in the endpoint packet memory
+               - When the host-side of the test is stated, it correctly
+                 reads this pending data.
+               - an EP correct transfer interrupt occurs and the next
+                 pending outgoing message is setup
+               - But, the host never receives the next message
+
+               If the host-side driver is started before the first target message
+               is sent, the driver works fine.
+  Status:      Open
+  Priority:    Medium-High
+  
+  Title:       FSMC EXTERNAL MEMORY UNTESTED
+  Description: FSMC external memory support is untested
+  Status:      Open
+  Priority:    Low
+
+  Title:       DMA EXTENSIONS
+  Description: DMA logic needs to be extended.  DMA2, Channel 5, will not work
+               because the DMA2 channels 4 & 5 share the same interrupt.
+  Status:      Open
+  Priority:    Low until someone needs DMA1, Channel 5 (ADC3, UART4_TX, TIM5_CH1, or
+               TIM8_CH2).
+
+o AVR (arch/avr)
+  ^^^^^^^^^^^^^^
+
+  Title:        AMBER WEB SERVER UNTESTED
+  Description:  There is a port for the Amber Web Server ATMega128, however this is
+                completely untested due to the lack to compatible, functional test
+                equipment.
+  Status:       Open
+  Priority:     The priority might as well be low since there is nothing I can do about
+                it anyway.
+
+  Title:        STRINGS IN RAM
+  Description:  Many printf-intensive examples (such as the OS test) cannot be executed
+                on most AVR platforms.  The reason is because these tests/examples
+                generate a lot of string data.  The build system currently places all
+                string data in RAM and the string data can easily overflow the tiny
+                SRAMs on these parts.  A solution would be to put the string data
+                into the more abundant FLASH memory, but this would require modification
+                to the printf logic to access the strings from program memory.
+  Status:       Open
+  Priority:     Low.  The AVR is probably not the architecuture that you want to use
+                for extensive string operations.
+
+  Title:        SPI AND USB DRIVERS UNTESTED
+  Description:  An SPI driver and a USB device driver exist for the AT90USB (as well
+                as a USB mass storage example).  However, this configuration is not
+                fully debugged as of the NuttX-6.5 release.
+                Update 7/11:  (1) The SPI/SD driver has been verified, however, (2) I
+                believe that the current teensy/usbstorage configuration uses too
+                much SRAM for the system to behave sanely.  A lower memory footprint
+                version of the mass storage driver will be required before this can
+                be debugged
+  Status:       Open
+  Priority:     Medium-High.
+
+  Title:        AVR32 PORT IS NOT FULLY TESTED
+  Description:  A complete port for the AVR32 is provided and has been partially
+                debugged.  There may still be some issues with the serial port
+                driver.
+  Status:       Open
+  Priority:     Medium
+
+o Intel x86 (arch/x86)
+  ^^^^^^^^^^^^^^^^^^^^
+
+o 8051 / MCS51 (arch/8051/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       STACK OVERFLOWS DURING INTERRUPT HANDLING
+  Description: Current status:
+               - Basic OS task management seems OK
+               - Fails when interrupts enabled.  The stack pointer is around
+                 0x6e before the failure occurs.  It looks like some issue
+                 when the stack pointer moves from the directly to indirectly
+                 addressable region (0x80 boundary).
+               - Work on the 8052 is temporarily on hold
+  Status:      Open
+  Priority:    Low, 8051 is a tough platform because of the tiny stack.
+
+  Title:       TIMER 0 AS SYSTEM TIMER
+  Description: Use timer 0 as system timer.  Timer 2 is needed for second UART.
+               Logic is implemented, but there needs to be a system
+               configuration to change the ticks-per-second value to match the
+               timer interrupt rate
+  Status:      Open
+  Priority:    Low
+
+  Title:       OVERFLOWS DURING BUILD
+  Description: During build, there are several integer overflows reported:
+               sched/gmtime_r.c aroud lines 184 and 185
+               sched/clock_initialize.c at line 107
+               sched/pthread_create.c at 330
+               apps/examples/ostest/barrier.c around lines 53 and 74
+               apps/examples/ostest/sighand.c at 225 and 244
+               driver/serial.c in usleep calls around 347 and 354
+  Status:      Open.  Update:  These were reviewed during the hcs12 port.  The
+               hcs12 also has 16-bit integer types (if -mshort is in the CFLAGS).
+               I believe that the warnings in most of the above have been fixed
+               but this has not been verified on this platform).
+  Priority:    Medium
+
+  Title:       DATA INITIALIZATION
+  Description  Global data is not being initialized.  Logic like that of SDCCs
+               crt0*.s needs to be incorporated into the system boot logic
+  Status:      Open
+  Priority:    Low -- only because there as so many other issues with 8051
+
+o MIPS (arch/mips)
+  ^^^^^^^^^^^^^^^^
+
+  Title:       PIC32MX PORT UNVERIFIED
+  Description: A port to the PIC32MX has been completed, but is pending verification.
+  Status:      Open
+  Priority:    High
+
+o Hitachi/Renesas SH-1 (arch/sh/src/sh1)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:        SH-1 IS UNUSABLE
+  Description:  There are instabilities that make the SH-1 port un-usable.  The
+                nature of these is not understood; the behavior is that certain SH-1
+                instructions stop working as advertised.  I have seen the following
+                examples:
+
+                  412b jmp @r1 - Set a return address in PR, i.e., it behaved like
+                       410b jsr @r1.  Normally 412b works correctly, but in the failure
+                       condition, it reliably set the PR.
+                  69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+.  This behavior
+                       does not correspond to any known SH-1 instruction
+
+                This could be a silicon problem, some pipeline issue that is not
+                handled properly by the gcc 3.4.5 toolchain (which has very limit
+                SH-1 support to begin with), or perhaps with the CMON debugger.  At
+                any rate, I have exhausted all of the energy that I am willing to put
+                into this cool old processor for the time being.
+  Status:       Open
+  Priority:     Low -- because the SH-1, SH7032, is very old and only of historical
+                interest.
+
+o Renesas M16C/26 (arch/sh/src/m16c)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:        M16C DOES NOT BUILD
+  Description:  The M16C target cannot be built.  The GNU m16c-elf-ld link fails with 
+                the following message:
+
+                m32c-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482
+
+                Where the reference line is:
+
+                /* If the symbol is out of range for a 16-bit address,
+                   we must have allocated a plt entry.  */
+                BFD_ASSERT (*plt_offset != (bfd_vma) -1);
+
+                No workaround is known at this time.
+  Status:       Open
+  Priority:     High -- this is a show stopper for M16C.
+
+  Title:       M16C PORT UNTESTED
+  Description: Coding of the initial port is complete, but is untested.
+  Status:      Open
+  Priority:    Low
+
+  Title:       NO SERIAL CONNECTOR
+  Description: Serial drivers were developed for the M16C, however, the SKP16C26
+               StarterKit has no serial connectors.
+  Status:      Open
+  Priority:    Low
+
+  Title:       UNIMPLEMENTED M16C DRIVERS
+  Description: Should implement SPI, I2C, Virual EEPROM, FLASH, RTC drivers
+  Status:      Open
+  Priority:    Medium
+
+o z80/z8/ez80 (arch/z80)
+ ^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       SDCC INTEGER OVERFLOWS
+  Description: The SDCC version the same problems with integer overflow during
+               compilation as described for pjrc-8051.  At typical cause is code like
+               usleep(500*1000) which exceeds the range of a 16-bit integer.
+  Status:      See pjrc-8051.  These have probably been fixed but have not yet
+               been verified on these platforms.
+  Priority:    See pjrc-8051
+
+  Title:       Z80 SIMULATED CONSOLE
+  Description: The simulated Z80 serial console (configs/z80sim/src/z80_serial.c +
+               driver/serial.c) does not work.  This is because there are
+               no interrupts in the simulation so there is never any serial
+               traffic.
+  Status:      Open
+  Priority:    Low -- the simulated console is not critical path and the designs
+               to solve the problem are complex.
+
+  Title:       ZDS-II LIBRARIAN WARNINGS
+  Description: ZDS-II Librarian complains that the source for the .obj file
+               is not in the library.
+  Status:      Open
+  Priority:    Low, thought to be cosmetic.  I think this is a consequence of
+               replacing vs. inserting the library.
+
+  Title:       ZDS-II COMPILER PROBLEMS
+  Description: The ZDS-II compiler (version 4.10.1) fails with an internal error
+               while compiler mm/mm_initialize.  This has been reported as
+               incident 81509.
+
+               I have found the following workaround that I use to build for the
+               time being:
+
+               --- mm/mm_initialize.c.SAVE    2008-02-13 08:06:46.833857700 -0600
+               +++ mm/mm_initialize.c    2008-02-13 08:07:26.367608900 -0600
+               @@ -94,8 +94,11 @@
+               {
+                  int i;
+
+               +#if 0 /* DO NOT CHECK IN */
+                  CHECK_ALLOCNODE_SIZE;
+                  CHECK_FREENODE_SIZE;
+               +#endif
+
+               /* Set up global variables */
+
+  Status:      Open
+  Priority:    High
+
+  Title:       EZ8 PRIORITY INTERRUPTS
+  Description: Add support for prioritized ez8 interrupts.  Currently logic supports
+               only nominal interrupt priority.
+  Status:      Open
+  Priority:    Low
+
+  Title:       Z8ENCORE ONLY VERIFIED ON SIMULATOR
+  Description: The z8Encore! port has only been verified on the ZDS-II instruction
+               set simulator.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       XTRS CLEAN
+  Description: The XTRS target (configs/xtrs) has a clean problem. The clean
+               rule removes .asm files.  This works because there are no .asm
+               files except in sub-directories that are provided from 'make clean' --
+               except for XTRS:  It has a .asm file in its src/ directory that
+               gets removed everytime clean is performd.
+  Status:      Open
+  Priority:    High if you happen to be working with XTRS.
+
+  Title:       SPI/I2C UNTESTED
+  Description: A "generic" SPI and I2C drivers have been coded for the eZ80Acclaim!
+               However, these remains untested since I have no SPI or I2C devices for
+               the board (yet).
+  Status:      Open
+  Priority:    Med
+
+  Title:       SPI METHODS ARE NOT THREAD SAFE
+  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
+  Status:      Open
+  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.
+
+  Title:       I2C UNTESTED
+  Description: A "generic" I2C driver has been coded for the eZ8Encore!
+               However, this remains untested since I have no I2C devices for
+               the board (yet).
+  Status:      Open
+  Priority:    Med
+
+o z16 (arch/z16)
+^^^^^^^^^^^^^^^^
+
+  Title:       ZDS-II LIBRARIAN WARNINGS
+  Description: ZDS-II Librarian complains that the source for the .obj file
+               is not in the library.
+  Status:      Open
+  Priority:    Low, thought to be cosmetic.  I think this is a consequence of
+               replacing vs. inserting the library.
+
+  Title:       SERIAL DRIVER HANGS
+  Description: When the interrupt-driven serial driver is used, the system
+               hangs.  This is because of TX ready (TRDE) interrupts that
+               get lost while interrupts are disabled.  The existing
+               serial driver appears to be limited to hardware with a
+               latching, level-sensitive TX ready interrupt.
+  Status:      Open
+  Priority:    Medium. A polled, write-only serial driver is used in the
+               interim for system testing.
+
+  Title:       SYSTEM DELAYS
+  Description: The system delays do not appear to be correct with the
+               apps/examples/ostest/timedmqueue.c test.
+  Status:      Open
+  Priority:    Medium-High
+
+  Title:       PROBLEMS WHEN DEBUG DISABLED
+  Description: At present, the z16f port does not run properly when CONFIG_DEBUG
+               is disabled:  The obvious symptom is that there is no printf()
+               output.  I have isolated with problem to errors in optimization.
+               With -reduceopt on the command line, I can get the printf output.
+               However, there are still errors in the compiled code -- specifically
+               in sched/timer_create.c.
+
+               I have submitted a bug report to ZiLOG for this (support incident
+               81400).  You can see the status of the bug report (and lots more
+               technical detail) here:
+               http://support.zilog.com/support/incident/incident_support.asp?iIncidentId=81400&iSiteId=1&chLanguageCode=ENG
+
+               Summary of ZiLOG analysis: "This is a ZNEO compiler problem. ... [a] workaround
+               is to replace:
+                   if ( !timerid || (clockid != 0) )
+                By:
+                   if ((clockid != 0) || !timerid)"
+
+  Status:      Open
+  Priority:    Medium-High
+
+  Title:       PASCAL ADD-ON
+  Description: The pascal add-on does not work with the z16f (that is
+               configuration z16f2800100zcog/pashello).  This appears to be
+               another ZDS-II error:  when executing the instruction
+               SYSIO 0, WRITESTR a large case statement is executed.  This
+               involves a call into the ZiLOG runtime library to __uwcase().
+               __uwcase is passed a pointer to a structure containing jump
+               information.  The cause of the failure appears to be that
+               the referenced switch data is bad.
+               This is submited as ZiLOG support incident 81459.
+
+               Summary of ZiLOG analysis: "This is a ZNEO run time library problem.
+               One workaround is to replace the line 58 in uwcase.asm
+
+               From:
+                      ADD       R9,#4             ; Skip handler
+               To:
+                      ADD       R9,#2             ; Skip handler
+
+               And add uwcase.asm to the project.
+
+               If the customer does not want to modify uwcase.asm then the other
+               workaround is to add a dummy case and make it same as default:
+
+               case 0x8000:
+               default:
+
+               This will make sure that uwcase is not called but ulcase is called."
+  Status:      Open.  Due to licensing issues, I cannot include the modified
+               uwcase in the NuttX code base.
+  Priority:    Medium
+
+  Title:       USE SPOV
+  Description: Add support to maintain SPOV in context switching.  This
+               improvement will provide protection against stack overflow
+               and make a safer system solution.
+  Status:      Open
+  Priority:    Low
+
+  Title:       PRIORITIZED INTERRUPTS
+  Description: Add support for prioritized interrupts.  Currently logic supports
+               only nominal interrupt priority.
+  Status:      Open
+  Priority:    Low
+
+  Title:       ZDS-II COMPILER PROBLEMS
+  Description: The file drivers/mmcsd/mmcsd_sdio.c generates an internal compiler
+               error like:
+ 
+               mmcsd\mmcsd_sdio.c
+               Internal Error(0503) On line 2504 of "MMCSD\MMCSD_SDIO.C"
+                   File <c3>, Args(562,46)
+
+  Status:     Open.  Recommended workaround: remove mmcsd_sdio.c from
+              drivers/mmcsd/Make.defs.  There is no SDIO support for the Z16 anyway
+  Priority:   Low
+
+o mc68hc1x (arch/hc)
+  ^^^^^^^^^^^^^^^^^^
+
+  Title:       BANKED MODE
+  Description: There is no script for building in banked mode (more correctly, there
+               is a script, but logic inside the script has not yet been implemented).
+               It would be necessary to implement banked mode to able to access more
+               the 48Kb of FLASH.
+  Status:      Open.
+  Priority:    Medium/Low
+
+o Network Utilities (apps/netutils/)
+
+  Title:       UIP RESOLVER
+  Description: One critical part of netutils/ apps is untested: The uIP
+               resolver in netutils/resolv.  The webclient code has been
+               tested on host using gethosbyname(), but still depends on the
+               untested resolve logic.
+  Status:      Open
+  Priority:    Medium, Important but not core NuttX functionality
+
+  Title:       PPP PORT
+  Description: Port PPP support from http://contiki.cvs.sourceforge.net/contiki/contiki-2.x/backyard/core/net/ppp/
+  Status:      Open
+  Priority:    Low
+
+  Title:       UNVERIFIED THTTPD FEATURES
+  Description: Not all THTTPD features/options have been verified.  In particular, there is no
+               test case of a CGI program receiving POST input.  Only the configuration of
+               apps/examples/thttpd has been tested.
+  Status:      Open
+  Priority:    Medium
+
+  Title:       THE ARP ISSUES AGAIN
+  Description: The first GET received by THTTPD is not responded to.  Refreshing the page
+               from the browser solves the problem and THTTPD works fine after thatg.  I 
+               believe that this is the duplicate of another bug: "Outgoing [uIP] packets are dropped
+               and overwritten by ARP packets if the destination IP has not been mapped to a MAC."
+  Status:      Open
+  Priority:    Medium
+
+  Title:       THTTPD WARNINGS
+  Description: If the network is enabled, but THTTPD is not configured, it spews out lots
+               of pointless warnings.  This is kind of annoying and unprofessional; needs to
+               be fixed someday.
+  Status:      Open.  An annoyance, but not a real problem.
+  Priority:    Low
+
+o NuttShell (NSH) (apps/nshlib)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       EACH TCP PACKET CAUSES PROMPT
+  Description: When the telnetd front end is received, each TCP packet
+               received causes a prompt (nsh >) to be presented.  The
+               prompt should only be presented when the user enters a
+               carriage return.
+  Status:      Open
+  Priority:    Low
+
+  Title:       WGET UNTESTED
+  Description: The wget command has been incorporated into NSH, however
+               it is still untested as of this writing (only because I
+               have not had the correct network setup for the testing
+               yet).  Since wget depends on the also untest uIP resolv/
+               logic, it is like non-functional.
+  Status:      Open
+  Priority:    Med-High
+
+  Title:       IFCONFIG AND MULTIPLE NETWORK INTERFACES
+  Descripton:  The ifconfig command will not behave correctly if an interface
+               is provided and there are multiple interfaces.  It should only
+               show status for the single interface on the command line; it will
+               still show status for all interfaces.
+  Status:      Open
+  Priority:    Low (multiple network interfaces not fully supported yet anyway).
+
+  Title:       RUN NXFLAT PROGRAMS
+  Description: Add support to NSH to run NXFLAT programs from a ROMFS file system
+  Status:      Open
+  Priority:    Low (enhancement)
+
+  Title:       ARP COMMAND
+  Description: Add an ARP command so that we can see the contents of the ARP table.
+  Status:      Open
+  Priority:    Low (enhancement)
+
+o Other Applications & Tests (apps/examples/)
+  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Title:       EXAMPLES/PIPE ON CYGWIN
+  Description: The redirection test (part of examples/pipe) terminates
+               incorrectly on the Cywgin-based simulation platform (but works
+               fine on the Linux-based simulation platform).
+  Status:      Open
+  Priority:    Low
+
+  Title:       EXAMPLES/WGET UNTESTED
+  Description: examples/wget is untested on the target (it has been tested
+               on the host, but not in the target using the uIP resolv logic).
+  Status:      Open
+  Priority:    Med
+
+  Title:       EXAMPLES/SENDMAIL UNTESTED
+  Description: examples/sendmail is untested on the target (it has been tested
+               on the host, but not on the target.
+  Status:      Open
+  Priority:    Med
+
+  Title:       EXAMPLES/NX FONT CACHING
+  Description: The font caching logic in examples/nx is incomplete.  Fonts are
+               added to the cache, but never removed.  When the cache is full
+               it stops rendering.  This is not a problem for the examples/nx
+               code because it uses so few fonts, but if the logic were
+               leveraged for more general purposes, it would be a problem.
+               Update: see examples/nxtext for some improved font cache handling.
+  Status:      Open
+  Priority:    Low.  This is not really a problem becauses examples/nx works
+               fine with its bogus font caching.
+
+  Title:       EXAMPLES/NXTEXT ARTIFACTS
+  Description: examples/nxtext.  Artifacts when the pop-up window is opened.
+               There are some artifacts that appear in the upper left hand
+               corner.  These seems to be related to window creation.  At
+               tiny artifact would not be surprising (the initial window
+               should like at (0,0) and be of size (1,1)), but sometimes
+               the artifact is larger.
+  Status:      Open
+  Priority:    Medium.