nuttx-bb/nuttx/TODO

NuttX TODO List (Last updated August 21, 2010)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  (5)  Task/Scheduler (sched/)
  (1)  On-demand paging (sched/)
  (2)  Memory Managment (mm/)
  (1)  Signals (sched/, arch/)
  (1)  pthreads (sched/)
  (1)  C++ Support
  (5)  Binary loaders (binfmt/)
 (17)  Network (net/, drivers/net)
  (5)  Network Utilities (netutils/)
  (1)  USB (drivers/usbdev)
  (5)  Libraries (lib/)
 (12)  File system/Generic drivers (fs/, drivers/)
  (2)  Graphics subystem (graphics/)
  (1)  Pascal add-on (pcode/)
  (1)  Documentation (Documentation/)
  (6)  Build system / Toolchains
  (3)  NuttShell (NSH) (examples/nsh)
  (3)  Other Applications & Tests (examples/)
  (5)  Linux/Cywgin simulation (arch/sim)
  (3)  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/)
  (4)  ARM/LPC17xx (arch/arm/src/lpc17xx/)
  (7)  ARM/LPC214x (arch/arm/src/lpc214x/)
  (3)  ARM/STR71x (arch/arm/src/str71x/)
  (4)  ARM/LM3S6918 (arch/arm/src/lm3s/)
  (5)  ARM/STM32 (arch/arm/src/stm32/)
  (4)  pjrc-8052 / MCS51 (arch/pjrc-8051/)
  (2)  Hitachi/Renesas SH-1 (arch/sh/src/sh1)
  (4)  Renesas M16C/26 (arch/sh/src/m16c)
  (8)  z80/z8/ez80 (arch/z80/)
  (9)  z16 (arch/z16/)
  (1)  mc68hc1x (arch/hc)

o Task/Scheduler (sched/)
  ^^^^^^^^^^^^^^^^^^^^^^^

  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.

  Description: atexit() supports registration of one function called on exit().
               Should task_delete() also cause atexit() function to be called?
  Status:      Open
  Priority:    Low, task_delete() is non-standard and its behavior is
               unspecified.

  Description: Implement sys/mman.h and functions
  Status:      Open
  Priority:    Low

  Description: Implement sys/wait.h and functions.  Consider implementing wait,
               waitpid, waitid.  At present, a parent has no information about
               child tasks.
  Status:      Open
  Priority:    Low

  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/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^

  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 feature is incomplete and untested.
	       It should not be enabled!
  Status:      Open, in work
  Priority:    Medium-Low

o Memory Managment (mm/)
  ^^^^^^^^^^^^^^^^^^^^^^

  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.
  Status:      Open
  Priority:    Medium/Low, a good feature to prevent memory leaks but would
               have negative impact on memory usage and code size.

  Description: Current logic adapts size_t for 16-bit address machines vs.
               32-bit address machines.  But a small memory option should also
               be provided so that the small offset option can be used with
               32-bit machines that have small RAM memories (like the lpc2148)
  Status:      Open
  Priority:    High, a good feature enhancement.

o Signals (sched/, arch/)
  ^^^^^^^^^^^^^^^^^^^^^^^

  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.

o pthreads (sched/)
  ^^^^^^^^^^^^^^^^^

  Description: pthread_cancel():  Should implement cancellation points and
               pthread_testcancel()
  Status:      Open
  Priority:    Low, probably not that useful

o C++ Support
  ^^^^^^^^^^^

  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/)
  ^^^^^^^^^^^^^^^^^^^^^^^^

  Description: Not all of the NXFLAT test under examples/nxflat are working.
               Most simply do not compile yet.  tests/mutex runs okay but
               outputs garbage on completion.
  Status:      Open
  Priority:    High

  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

  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

  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)

  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

o Network (net/, drivers/net)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Description: Should implement SOCK_RAW, SOCK_PACKET
  Status:      Open
  Priority:    Low

  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.

  Description: Sendoto() 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.

  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

  Description: Incoming UDP broadcast should only be accepted if listening on
               INADDR_ANY(?)
  Status:      Open
  Priority:    Low

  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

  Description: Need to standardize collection of statistics from network
               drivers.  examples/nsh ifconfig command should present
               statistics.
  Status:      Open
  Priority:    Low

  Description: Outgoing packets are dropped and overwritten by ARP packets
               if the destination IP has not been mapped to a MAC.  Could
               improve send() performance by explicitly performing ARP before
               sending the packet.
               ---
               Or by enabling arpin() logic.  NOTE: From the uIP forum: "You
               can use the function but it has a bug. You'll need to comment
               this line: uip_len -= sizeof(struct uip_eth_hdr);"
  Status:      Open
  Priority:    Medium

  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 examples/nsh 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.

  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

  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

  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()

  Description: sockets do not support all modes except 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.

  Description: I started coding a CrystalLan CS89x0 driver (drivers/net/cs89x0.c),
               but never finished it.
  Status:      Open
  Priority:    Low unless you need it.

  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.

  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.

  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
               commnands, 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.

o Network Utilities (netutils/)

  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

  Description: Port PPP support from http://contiki.cvs.sourceforge.net/contiki/contiki-2.x/backyard/core/net/ppp/
  Status:      Open
  Priority:    Low

  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
               examples/thttpd has been tested.
  Status:      Open
  Priority:    Medium

  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

  Description: There are some lingering bugs in THTTPD, possibly race conditions.  When debug
               is enabled, it works.  But with debug disabled, there are sometimes
               mysterious hangs or crashes in the CGI.  Of course, this is hard to fix
               when the problem goes away with debug output enabled (and also since
               output from the CGI program is re-directed; you can redefine bdbg to
               be lldbg in include/debug.h to get non-re-directed debug output).
  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

  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 USB (drivers/usbdev)
  ^^^^^^^^^^^^^^^^^^^^

  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

o Libraries (lib/)
  ^^^^^^^^^^^^^^^^

  Description: sscanf() and lib_vsprintf() do not support floating point
               values.
  Status:      Open
  Priority:    Low

  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

  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).

  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

  Description: strftime() and other timing functions do not handle days of the week.
  Status:      Open
  Priority:    Low

o File system / Generic drivers (fs/, drivers/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Description: Implement chmod(), truncate().
  Status:      Open
  Priority:    Low

  Description: FAT: long file names
  Status:      Open
  Priority:    Medium

  Description: The CAN driver is untested.  Add a test for the CAN driver.
  Status:      Open
  Priority:    Medium

  Description: At present, the CAN driver does not support the poll() method.
  Status:      Open
  Priority:    Low

  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

  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.

  Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
               yet handle multiple block transfers.
  Status:      Open
  Priority:    Medium-Low

  Description: At present, mmap() only works with file descriptors associated
               with a ROMFS file system.  Generalize this logic so that if
               mmap is not supported by the file system or block driver, it
               will allocate memory and copy the file into RAM.  This would
               need some centralized logic so that the memory region would
               be shared on later mmap()'s on the same inode.  Reference counting
               would be required so that the multiply mmap()'ed region persists
               until the last munmap().
  Status:      Open
  Priority:    Low

  Description: Block driver read-ahead buffer and write buffer support is
               implemented but not yet tested.
  Status:      Open
  Priority:    Low

  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

  Description: A FLASH translation layer (FTL) has been implemented at
               drivers/mtd/ftl.c but has not yet been tested.  This layer
               will convert a FLASH MTD interface into a block driver that
               can be used with any file system.  Good performance of this
               layer will depend upon functioning write buffer support!
  Status:      Open
  Priority:    Low

  Description: ENC28J60 driver is complete, but untested (I still haven't got
               a good ENC28J60 test platform).
  Status:      Open
  Priority:    Low

o Graphics subystem (graphics/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Description: If CONFIG_NX is enabled, the build fails the first time
               saying that there is "No rule to make target..." for one of the
               auto-generated graphics files.  This is a nuisance, but if you
               simply build again (with the source files already auto-generated)
               the problem does not reoccur.
  Status:      Open
  Priority:    Low, the work-around is simple

  Description: Testing of all APIs is not complete.  See
               http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage
  Status:      Open
  Priority:    Medium

  Description: The examples/nx test using lcd/p14201.c and the configs/lm3s6965-ek
               configuration shows two single pixel-wide anomalies.  One along
               column zero is clearly caused by the NX windowing logic.  It is
               not certain if these are consequences of the 4bpp logic or if these
               are anomalies that have always been in NX, but are only visible
               now at the low resolution of the p14201 LCD (128x96).
  Status:      Open
  Priority:    Low (unless you need the p13201 then it is certainly higher).

o Pascal Add-On (pcode/)
  ^^^^^^^^^^^^^^^^^^^^^^

  Description: Need APIs to verify execution of P-Code from memory buffer.
  Status:      Open
  Priority:    Low

  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/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  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
  ^^^^^^^^^^^^

  Description: Some names under arch are still incorrect.  These should be
               processor architecture names:  pjrc-8051 should be 805x
  Status:      Open
  Priority:    Low

  Description: configs/pjrc-8051 should be configs/pjrc-87c52
  Status:      Open
  Priority:    Low

  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)

  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

  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

  Decription:  Build of NX fails with gcc-4.2.2.  When generating C files using
               arm-elf-gcc -E, the CPP fails when using -isystem.  Works fine with
               older compilers.  My work around for now is to use an older compiler
               for the CPP definition in the configuration Make.defs file, do
               make context, restore the original Make.defs, and then make.
  Status:      Open.  This may not be a real issue.  I have not seen this
               happen lately so it may have nothing to do with GCC.
  Priority:    High if you are using NX and a newer compiler.
               

o NuttShell (NSH) (examples/nsh)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  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

  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

  Description: Add support to NSH to run NXFLAT programs from a ROMFS file system
  Status:      Open
  Priority:    Low

o Other Applications & Tests (examples/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  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

  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

  Description: examples/sendmail is untested on the target (it has been tested
               on the host, but not on the target.
  Status:      Open
  Priority:    Med


o Linux/Cywgin simulation (arch/sim)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  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)

  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.

  Description: I never did get networking to work on the sim target.  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.
  Status:      Open
  Priority:    Low (unless you want to test networking features on the simulation).
  
  Description: There is an X11-based framebuffer driver that you can use exercise
               the NuttX graphics subsystem on the simulator.  But I am not much
               of an X11 programmer so I did not use X11 autoconfiguration stuff.
               As a result, it builds on old X11 installations, but not on current
               versions.
  Status:      Open
  Priority:    Low (unless you want to test graphics features on the simulation).

  Description: Since it 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

o ARM (arch/arm/)
  ^^^^^^^^^^^^^^^

  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/cortexm3/* for
               examples of how this might be done.
                Status:      Open
  Priority:    Low

  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

  Description: The Cortex-M3 user context swich 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.
  Status:      Open
  Priority:    Low

o ARM/C5471 (arch/arm/src/c5471/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  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/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  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

  Description: A USB device controller driver was added but has never been tested.
  Status:      Open
  Priority:    Medium

  Description: A framebuffer "driver" was added, however, it remains untested.
  Status:      Open
  Priority:    Medium

  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/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Description: The basic port of the i.MX1 architecuture is underway.  The port
               is incomplete (as of this writing, is still lacks a timer, interrupt
               decoding, USB, network) and untested.
  Status:      Open (and in work)
  Priority:    Medium (high if you need i.MX1/L support)

  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/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Description: If debug is enabled so that there is a lot of early serial console output,
               The serial console output may be garbled initially.  If this becomes a
               problem during debug, I've found that just putting a delaying at the
               beginning of os_start() (sched/os_start.c) eliminates the garbled output.
  Status:      Open
  Priority:    Low, only effects debug and there is a workaround
  
  Description: Due to some connector/cabling issues using the Nucleus2g, a couple of
               important features have not yet been tested:  The microSD card and
               USB (device).  These features are fully implemented and partially
               tested, but not fully verified.
  Status:      Open
  Priority:    High

  Description: a) USB DMA not fully implemented. Partial logic is in place but it is
                  fragmentary and bogus. (Leveraged from the lpc214x)
               b) Possible errors in USB device driver reported "I suspect there<72>s a few
                  issues in the lpc214x USB driver <20> in particular it doesn<73>t stall both
                  in/out endpoints for unsupported setup requests and it doesn<73>t call
                  CLASS_DISCONNCET on a USB reset <20> I don<6F>t have any access to that hardware
                  so can<61>t pursue it really."
  Status:      Open
  Priority:    Low

  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

o ARM/LPC214x (arch/arm/src/lpc214x/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Description: Should use Vector Interrupts
  Status:      Open
  Priority:    Low

  Description: USB DMA not fully implemented. Partial logic is in place but it is
               fragmentary and bogus.
  Status:      Open
  Priority:    Low

  Description: USB Serial Driver reports wrong error when opened before the
               USB is connected (reports EBADF instead of ENOTCONN)
  Status:      Open
  Priority:    Low

  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

  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.

  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

  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.
  Status:      Open
  Priority:    Uncertain

  Description: Possible errors in USB device driver reported "I suspect there<72>s a few
               issues in the lpc214x USB driver <20> in particular it doesn<73>t stall both
               in/out endpoints for unsupported setup requests and it doesn<73>t call
               CLASS_DISCONNCET on a USB reset <20> I don<6F>t have any access to that hardware
               so can<61>t pursue it really."
  Status:      Open
  Priority:    Medium

o ARM/STR71x (arch/arm/src/str71x/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  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

  Description: Develop a USB driver and integrate with existing USB serial and storage
               class drivers.
  Status:      Open
  Priority:    Medium

  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/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Description: Still need to implement I2C
  Status:      Open
  Priority:    Low

  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.

  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.

  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/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Description: NOR Flash driver and FTL layer to support a file system.
  Status:      Open
  Priority:    Low

  Description  A USB device-side driver is in place but not well tested.  At
               present, the 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
  
  Description: FSMC external memory support is untested
  Status:      Open
  Priority:    Low

  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).

  Desription:  I am unable to access a 2Gb SanDisk microSD card (in adaptor) on the
               the STM3210E-EVAL board.  The card reports that it is a SDV1.x card
               with a 1Kb block size, but the CMD16 to set the block length to
               1024 fails.
  Status:      Open
  Priority:    Uncertain.  I don't this is a bug, I think I just don't understand
               how to work with this type of SD card.

o pjrc-8052 / MCS51 (arch/pjrc-8051/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  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.

  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

  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
               examples/ostest/barrier.c around lines 53 and 74
               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

  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 Hitachi/Renesas SH-1 (arch/sh/src/sh1)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  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.

  Description:  arch/sh has been restructured to support M16C.  Need to verify that
                SH-1 still builds.
  Status:       Open
  Priority:     Low

  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.

o Renesas M16C/26 (arch/sh/src/m16c)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Description: Coding of the initial port is complete, but is untested.
  Status:      Open
  Priority:    Low

  Description: Serial drivers were developed for the M16C, however, the SKP16C26
               StarterKit has no serial connectors.
  Status:      Open
  Priority:    Low

  Description: Should implement SPI, I2C, Virual EEPROM, FLASH, RTC drivers
  Status:      Open
  Priority:    Medium

o z80/z8/ez80 (arch/z80)
 ^^^^^^^^^^^^^^^^^^^^^^^

  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

  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.

  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.

  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

  Description: Add support for prioritized ez8 interrupts.  Currently logic supports
               only nominal interrupt priority.
  Status:      Open
  Priority:    Low

  Description: The z8Encore! port has only been verified on the ZDS-II instruction
               set simulator.
  Status:      Open
  Priority:    Medium

  Description: Upgrade to the ZDS-II Z8Encore! 4.11.0 toolchain
  Status:      Open
  Priority:    Low

  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.

  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

  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.

  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)
^^^^^^^^^^^^^^^^

  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.

  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.

  Description: The system delays do not appear to be correct with the
               examples/ostest/timedmqueue.c test.
  Status:      Open
  Priority:    Medium-High

  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

  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

  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

  Description: Add support for prioritized interrupts.  Currently logic supports
               only nominal interrupt priority.
  Status:      Open
  Priority:    Low

  Description: Upgrade to the ZDS-II ZNEO 4.11.1 toolchain
  Status:      Open
  Priority:    Low

  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)
  ^^^^^^^^^^^^^^^^^^

  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.