diff options
Diffstat (limited to 'nuttx/TODO')
| -rw-r--r-- | nuttx/TODO | 1932 |
1 files changed, 1932 insertions, 0 deletions
diff --git a/nuttx/TODO b/nuttx/TODO new file mode 100644 index 000000000..543d15f70 --- /dev/null +++ b/nuttx/TODO @@ -0,0 +1,1932 @@ +NuttX TODO List (Last updated August 12, 2012) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +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/) + (2) pthreads (sched/) + (2) C++ Support + (5) Binary loaders (binfmt/) + (17) Network (net/, drivers/net) + (3) USB (drivers/usbdev, drivers/usbhost) + (11) Libraries (lib/) + (9) File system/Generic drivers (fs/, drivers/) + (5) Graphics subystem (graphics/) + (1) Pascal add-on (pcode/) + (1) Documentation (Documentation/) + (6) Build system / Toolchains + (5) Linux/Cywgin simulation (arch/sim) + (6) 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/) + (0) ARM/LPC43x (arch/arm/src/lpc43xx/) + (3) ARM/STR71x (arch/arm/src/str71x/) + (3) ARM/LM3S6918 (arch/arm/src/lm3s/) + (7) ARM/STM32 (arch/arm/src/stm32/) + (3) AVR (arch/avr) + (0) Intel x86 (arch/x86) + (4) 8051 / MCS51 (arch/8051/) + (3) MIPS/PIC32 (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/) + (4) NuttShell (NSH) (apps/nshlib) + (1) System libraries apps/system (apps/system) + (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: 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. + Update: These are being fixed as they are encountered. There is + no accounting of how many interfaces have this problem. + Status: Open + Priority: Medium, required for standard compliance (but makes the + code bigger) + + Title: TICKLESS OS + Description: On a side note, I have thought about a tick-less timer for the OS + for a long time. Basically we could replace the periodic system + timer interrupt with a one-shot interval timer programmed for the + next interesting event time. That is one way to both reduce the + timer interrupt overhead and also to increase the accuracy of + delays. + + Current timer processing is in sched/sched_processtimer.c: + + 1) Calls clock_timer() which just increments a counter (the system + timer -- basically "up-time"). This is only used when code asks + for the current time. In a tickless OS, some substitute answer + for the question "What time is it?" would need to be developed. + You could use an RTC? Or maybe logic that gets the time until the + next interval expiration and computes the current time. The + solution is not too difficult, but depends on a hardware solution. + + 2) Calls wd_timer() which handles the link list of ordered events: + Each timer event is saved with the delta time to the next event + in the list. So an interval timer would be perfect to implement this. + + 3) sched_process_timeslice(). Then there is round-robin time-slicing. + + Status: Open + Priority: Low + +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. + + Update. From the NuttX forum: + ...there is a good reason why task A should never delete task B. + That is because you will strand memory resources. Another feature + lacking in most flat address space RTOSs is automatic memory + clean-up when a task exits. + + That behavior just comes for free in a process-based OS like Linux: + Each process has its own heap and when you tear down the process + environment, you naturally destroy the heap too. + + But RTOSs have only a single, shared heap. I have spent some time + thinking about how you could clean up memory required by a task + when a task exits. It is not so simple. It is not as simple as + just keeping memory allocated by a thread in a list then freeing + the list of allocations when the task exists. + + It is not that simple because you don't know how the memory is + being used. For example, if task A allocates memory that is used + by task B, then when task A exits, you would not want to free that + memory needed by task B. In a process-based system, you would + have to explicitly map shared memory (with reference counting) in + order to share memory. So the life of shared memory in that + environment is easily managed. + + I have thought that the way that this could be solved in NuttX + would be: (1) add links and reference counts to all memory allocated + by a thread. This would increase the memory allocation overhead! + (2) Keep the list head in the TCB, and (3) extend mmap() and munmap() + to include the shared memory operations (which would only manage + the reference counting and the life of the allocation). + + Then what about pthreads? Memory should not be freed until the last + pthread in the group exists. That could be done with an additional + reference count on the whole allocated memory list (just as streams + and file descriptors are now shared and persist until the last + pthread exits). + + I think that would work but to me is very unattractive and + inconsistent with the NuttX "small footprint" objective. ... + + Other issues: + - Memory free time would go up because you would have to remove + the memory from that list in free(). + - There are special cases inside the RTOS itself. For example, + if task A creates task B, then initial memory allocations for + task B are created by task A. Some special allocators would + be required to keep this memory on the correct list (or on + no list at all). + + 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 + + Title: PTHREAD_PRIO_PROTECT + Description: Extended pthread_mutexattr_setprotocol() suport PTHREAD_PRIO_PROTECT: + "When a thread owns one or more mutexes initialized with the + PTHREAD_PRIO_PROTECT protocol, it shall execute at the higher of its + priority or the highest of the priority ceilings of all the mutexes + owned by this thread and initialized with this attribute, regardless of + whether other threads are blocked on any of these mutexes or not. + + "While a thread is holding a mutex which has been initialized with + the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol attributes, + it shall not be subject to being moved to the tail of the scheduling queue + at its priority in the event that its original priority is changed, + such as by a call to sched_setparam(). Likewise, when a thread unlocks + a mutex that has been initialized with the PTHREAD_PRIO_INHERIT or + PTHREAD_PRIO_PROTECT protocol attributes, it shall not be subject to + being moved to the tail of the scheduling queue at its priority in the + event that its original priority is changed." + Status: Open + Priority: Low -- about zero, probably not that useful. Priority inheritance is + already supported and is a much better solution. And it turns out + that priority protection is just about as complex as priority inheritance. + Exerpted from my post in a Linked-In discussion: + + "I started to implement this HLS/"PCP" semaphore in an RTOS that I + work with (http://www.nuttx.org) and I discovered after doing the + analysis and basic code framework that a complete solution for the + case of a counting semaphore is still quite complex -- essentially + as complex as is priority inheritance. + + "For example, suppose that a thread takes 3 different HLS semaphores + A, B, and C. Suppose that they are prioritized in that order with + A the lowest and C the highest. Suppose the thread takes 5 counts + from A, 3 counts from B, and 2 counts from C. What priority should + it run at? It would have to run at the priority of the highest + priority semaphore C. This means that the RTOS must maintain + internal information of the priority of every semaphore held by + the thread. + + "Now suppose it releases one count on semaphore B. How does the + RTOS know that it still holds 2 counts on B? With some complex + internal data structure. The RTOS would have to maintain internal + information about how many counts from each semaphore are held + by each thread. + + "How does the RTOS know that it should not decrement the priority + from the priority of C? Again, only with internal complexity. It + would have to know the priority of every semaphore held by + every thread. + + "Providing the HLS capability on a simple phread mutex would not + be such quite such a complex job if you allow only one mutex per + thread. However, the more general case seems almost as complex + as priority inheritance. I decided that the implementation does + not have value to me. I only wanted it for its reduced + complexity; in all other ways I believe that it is the inferior + solution. So I discarded a few hours of programming. Not a + big loss from the experience I gained." + +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 + Update: Static constructors are implemented for the STM32 F4 and + this will provide the model for all solutions. Basically, if + CONFIG_HAVE_CXXINITIALIZE=y is defined in the configuration, then + board-specific code must provide the interface up_cxxinitialize(). + up_cxxinitialize() is called from user_start() to initialize + all static class instances. This TODO item probably has to stay + open because this solution is only available on STM32 F4. + 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: SENDTO() 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: 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. + + 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. + +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. See logic conditioned on CONFIG_USBMSC_RACEWAR. + 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). + + Title: EP0 OUT CLASS DATA + Description: There is no mechanism in place to handle EP0 OUT data transfers. + There are two aspects to this problem, neither are easy to fix + (only because of the number of drivers that would be impacted): + + 1. The class drivers only send EP0 write requests and these are + only queued on EP0 IN by this drivers. There is never a read + request queued on EP0 OUT. + 2. But EP0 OUT data could be buffered in a buffer in the driver + data structure. However, there is no method currently + defined in the USB device interface to obtain the EP0 data. + + Updates: (1) The USB device-to-class interface as been extended so + that EP0 OUT data can accompany the SETUP request sent to the + class drivers. (2) The logic in the STM32 F4 OTG FS device driver + has been extended to provide this data. Updates are still needed + to other drivers. + Status: Open + Priority: High for class drivers that need EP0 data. For example, the + CDC/ACM serial driver might need the line coding data (that + data is not used currenly, but it might be). + +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: 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(). + UPDATE: There is growing functionality in lib/termios/ and in the + ioctl methods of several MCU serial drivers (stm32, lpc43, lpc17, + pic32). However, as phrased, this bug cannot yet be closed since + this "growing functionality" does not address all termios.h + functionality and not all serial drivers support termios. + 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. + + Title: DIVIDE BY ZERO + Description: This is bug 3468949 on the SourceForge website (submitted by + Philipp Klaus Krause): + "lib_strtod.c does contain divisions by zero in lines 70 and 96. + AFAIK, unlike for Java, division by zero is not a reliable way to + get infinity in C. AFAIK compilers are allowed e.g. give a compile- + time error, and some, such as sdcc, do. AFAIK, C implementations + are not even required to support infinity. In C99 the macro isinf() + could replace the first use of division by zero. Unfortunately, the + macro INFINITY from math.h probably can't replce the second division + by zero, since it will result in a compile-time diagnostic, if the + implementation does not support infinity." + Status: Open + Priority: + + Title: OLD dtoa NEEDS TO BE UPDATED + Description: This implementation of dtoa in lib/stdio is old and will not + work with some newer compilers. See + http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html + Status: Open + Priority: ?? + + Title: SYSLOG INTEGRATION + Description: There are the beginnings of some system logging capabilities (see + drivers/syslog, fs/fs_syslog.c, and lib/stdio/lib_librawprintf.c and + lib_liblowprintf.c. For NuttX, SYSLOG is a concept and includes, + extends, and replaces the legacy NuttX debug ouput. Some additional + integration is required to formalized this. For example: + + o lib_rawprintf() shjould be renamed syslog(). + o debug.h should be renamed syslog.h + o And what about lib_lowprintf()? llsyslog? + Status: Open + Priority: Low -- more of a roadmap + + Title: FLOATING POINT FORMATS + Description: Only the %f floating point format is supported. Others are accepted + but treated like %f. + Status: Open + Priority: Medium (this might important to someone). + + Title: FLOATING POINT PRECISION + Description: A fieldwidth and precision is required with the %f format. If %f + is used with no format, than floating numbers will be printed with + a precision of 0 (effectively presented as integers). + Status: Open + Priority: Medium (this might important to someone). + +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. + See drivers/can.c + Status: Open + Priority: Low + + Title: REMOVING PIPES AND FIFOS + Description: There is no way to remove a FIFO or PIPE created in the + pseudo 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 pseudo- + 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: 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 + + Title: CONFIG_RAMLOG_CONSOLE DOES NOT WORK + Description: When I enable CONFIG_RAMLOG_CONSOLE, the system does not come up + propertly (using configuration stm3240g-eval/nsh2). The problem + may be an assertion that is occuring before we have a console. + Status: Open + Priority: Medium + +o Graphics subystem (graphics/) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + See also the NxWidgets TODO list file for related issues. + + 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. + + Title: RAW WINDOW AUTORAISE + Description: Auto-raise only applies to NXTK windows. Shouldn't it also apply + to raw windows as well? + Status: Open + Priority: Low + + Title: AUTO-RAISE DISABLED + Description: Auto-raise is currently disabled in NX multi-server mode. The + reason is complex: + - Most touchscreen controls send touch data a high rates + - In multi-server mode, touch events get queued in a message + queue. + - The logic that receives the messages performs the auto-raise. + But it can do stupid things after the first auto-raise as + it opperates on the stale data in the message queue. + I am thinking that auto-raise ought to be removed from NuttX + and moved out into a graphics layer (like NxWM) that knows + more about the appropriate context to do the autoraise. + Status: Open + Priority: Medium low + + Title: IMPROVED NXCONSOLE FONT CACHING + Description: Now each NxConsole instance has its own private font cache + whose size is determined by CONFIG_NXCONSOLE_MXCHARS. If there + are multiple NxConsole instances using the same font, each will + have a separate font cache. This is inefficient and wasteful + of memory: Each NxConsole instance should share a common font + cache. + Status: Open + Priority: Medium. Not important for day-to-day testing but would be + a critical improvement if NxConsole were to be used in a + product. + +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: NUTTX CONFIGURATION TOOL + Description: Need a NuttX configuration tool. The number of configuration + settings has become quite large and difficult to manage manually. + Update: This task is essentially completed. But probably not for + all platforms and all features. When do we know that the the + features is complete and that we can switch to exclusive use of + the tool? + 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 - GRAPHICS/NSH PARTITIONING. + 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. + A similar issue exists in NSH that uses some internal OS + interfaces that would not be available in a kernel build + (such as foreach_task, foreach_mountpoint, etc.). + 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 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. + Another, more standard option would be to use interrupt priority + levels to control interrupts. In that case, (1) The SVC would + be the highest priority interrupt (0), (2) irqsave() would set + the interrupt mask level to just above that, and (2) irqrestore + would restore the interrupt level. This would not be diffult, + but does affect a lot of files! + 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. + + Title: CORTEX-M3 STACK OVERFLOW + Description: There is bit bit logic inf up_fullcontextrestore() that executes on + return from interrupts (and other context switches) that looks like: + + ldr r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */ + msr cpsr, r1 /* Set the CPSR */ + + /* Now recover r0 and r1 */ + + ldr r0, [sp] + ldr r1, [sp, #4] + add sp, sp, #(2*4) + + /* Then return to the address at the stop of the stack, + * destroying the stack frame + */ + + ldr pc, [sp], #4 + + Under conditions of excessivley high interrupt conditions, many + nested interrupts can oocur just after the 'msr cpsr' instruction. + At that time, there are 4 bytes on the stack and, with each + interrupt, the stack pointer may increment and possibly overflow. + + This can happen only under conditions of continuous interrupts. + See this email thread: http://tech.groups.yahoo.com/group/nuttx/message/1261 + On suggested change is: + + ldr r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */ + msr spsr_cxsf, r1 /* Set the CPSR */ + ldmia r0, {r0-r15}^ + + But this has not been proven to be a solution. + Status: Open + Priority: Low. The conditions of continous interrupts is really the problem. + If your design needs continous interrupts like this, please try + the above change and, please, submit a patch with the working fix. + + Title: KERNEL MODE ISSUES - HANDLERS + Description: The is a design flaw in the ARM/Cortex trap handlers. Currently, + they try to process the SYSCALL within the trap handler. That + cannot work. There are two possibilities to fix this. + 1) Just enable interrupts in the trap handler and make sure that + that sufficient protection is in place to handler the nested + interrupts, or + 3) Return from the exception via a trampoline (such as is + currently done for signal handlers). In the trampoline, + the trap would processed in supervisor mode with interrupts + enabled. + Status: Open + Priority: medium-high. + +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 BROKEN? + Description: I tried to bring up the new configuration at configs/mcu123-214x/composite, + and Linux failed to enumerate the device. I don't know if this is + a problem with the lpc214x USB driver (bit rot), or due to recent + changed (e.g., -r4359 is suspicious), or an incompatibility between the + Composite driver and the LPC214x USB driver. It will take more work + to find out which -- like checking if the other USB configurations are + also broken. + Status: Open + Priority: It would be high if the LPC2148 were a current, main stream architecture. + I am not aware of anyone using LPC2148 now so I think the priority has + to be low. + +o ARM/LPC31xx (arch/arm/src/lpc31xx/) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + 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/LPC43x (arch/arm/src/lpc43xx/) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +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). + + Title: UNFINISHED DRIVERS + Description: The following drivers are incomplete: DAC. The following drivers + are untested: DMA on the F4, CAN. + Status: Open + Priority: Medium + + Title: F4 SDIO MULTI-BLOCK TRANSFER FAILURES + Description: If you use a large I/O buffer to access the file system, then the + MMCSD driver will perform multiple block SD transfers. With DMA + ON, this seems to result in CRC errors detected by the hardware + during the transfer. Workaround: CONFIG_MMCSD_MULTIBLOCK_DISABLE=y. + Status: Open + Priority: Medium + + Title: DMA BOUNDARY CROSSING + Description: I see this statement in the reference manual: "The burst + configuration has to be selected in order to respect the AHB protocol, + where bursts must not cross the 1 KB address boundary because the + minimum address space that can be allocated to a single slave + is 1 KB. This means that the 1 KB address boundary should not be crossed + by a burst block transfer, otherwise an AHB error would be generated, + that is not reported by the DMA registers." + + The implication is that there may be some unenforced alignment + requirements for some DMAs. There is nothing in the DMA driver to + prevent this now. + Status: Open + Priority: Low (I am not even sure if this is a problem yet). + + Status: UNFINISHED STM32 F4 OTG FS HOST DRIVER + Description: A quick-n-dirty leverage of the the LPC17xx host driver was put into + the STM32 source to support development of the STM32 F4 OTG FS host + driver. It is non-functional and still waiting for STM32 F4 logic + to be added. Don't use it! + Status: Open + Priority: Low (unless you need a host driver). + +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/PIC32(arch/mips) + ^^^^^^^^^^^^^^^^^^^^^ + + Title: PIC32 USB DRIVER DOES NOT WORK WITH MASS STORAGE CLASS + UPDATE: ** ONLY USING RAM DISK FOR EXPORTED VOLUME *** + Description: The PIC32 USB driver either crashes or hangs when used with + the mass storage class when trying to write files to the target + storage device. This usually works with debug on, but does not + work with debug OFF (implying some race condition?) + + Here are some details of what I see in debugging: + + 1. The USB MSC device completes processing of a read request + and returns the read request to the driver. + 2. Before the MSC device can even begin the wait for the next + driver, many packets come in at interrupt level. The MSC + device goes to sleep (on pthread_cond_wait) with all of the + read buffers ready (16 in my test case). + 3. The pthread_cond_wait() does not wake up. This implies + a problem with pthread_con_wait(?). But in other cases, + the MSC device does wake up, but then immediately crashes + because its stack is bad. + 4. If I force the pthread_cond_wait to wake up (by using + pthread_cond_timedwait instead), then the thread wakes + up and crashes with a bad stack. + + So far, I have no clue why this is failing. + + UPDATE: This bug was recorded using the PIC32 Ethernet + Starter kit with a RAM disk (that board has no SD card slot). + Howevever, using the USB mass storage device with the + Mikroelektronika using a real SD card, there is no such + problem -- the mass storage device seems quite stable. + + UPDATE: Hmmm.. retesting with the Mikroelectronka board + shows problems again. I think that there are some subtle + timing bugs whose effects can very from innocuous to severe. + Status: Open + Priority: Originally, High BUT reduced to very Low based on the + UPDATED comments. + + Title: PIC32 USB MASS STORAGE DEVICE FAILS TO RE-CONNECT + Description: Found using configuration configs/pic32mx7mmb/nsh. + In this configuratin, the NSH 'msconn' command will connect the + mass storage device to the host; the 'msdis' command will + disconnect the device. The first 'msconn' works perfectly. + However, when attempting to re-connect, the second 'msconn' + command does not command properly: Windows reports an + unrecognized device. Apparently, some state is being properly + reset when the mass storage device is disconnected. Shouldn't + be hard to fix. + Status: Open + Priority: Medium + + Title: POSSIBLE INTERRUPT CONTROL ISSUE + Description: There is a kludge in the file arch/mips/src/common/up_idle.c. + Basically, if there is nothing else going on in the IDLE loop, + you have to disable then re-enable interrupts. Logically nothing + changes, but if you don't do this interrupts will be be disabled + in the IDLE loop which is a very bad thing to happen. + + Some odd behavior in the interrupt setup on the IDLE loop is + not really a big concern, but what I do not understand is if + this behavior is occurring on all threads after all context + switches: Are interrupts always disabled until re-enabled? + This requires some further investigation at some point; it + may be nothing but may also be a symptom of some changes + required to the interrupt return logic (perhaps some CP0 + status hazard?) + Status: Open + Priority: Low. Puzzling and needs some investigation, but there there + is no known misbehavior. + +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. + + Update: This bug will probably never be addressed now. I just + cleaned house and my old SH-1 was one of the things that went. + + 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 48K 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: 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 System libraries apps/system (apps/system) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + Title: READLINE IMPLEMENTATION + Description: readline implementation does not use C-buffered I/O, but rather + talks to serial driver directly via read(). It includes VT-100 + specific editting commands. A more generic readline() should be + implemented using termios' tcsetattr() to put the serial driver + into a "raw" mode. + Status: Open + Priority: Low (unless you are using mixed C-buffered I/O with readline and + fgetc, for example). + +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. |