NuttX TODO List (Last updated September 13, 2014) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This file summarizes known NuttX bugs, limitations, inconsistencies with standards, things that could be improved, and ideas for enhancements. See also individual README.txt files in the configs/ sub-directories for each board port. nuttx/ (9) Task/Scheduler (sched/) (2) Memory Managment (mm/) (3) Signals (sched/, arch/) (2) pthreads (sched/) (9) Kernel/Protected Builds (4) C++ Support (6) Binary loaders (binfmt/) (13) Network (net/, drivers/net) (4) USB (drivers/usbdev, drivers/usbhost) (10) Libraries (libc/, ) (13) File system/Generic drivers (fs/, drivers/) (6) Graphics subystem (graphics/) (1) Pascal add-on (pcode/) (1) Documentation (Documentation/) (5) Build system / Toolchains (5) Linux/Cywgin simulation (arch/sim) (4) ARM (arch/arm/) (1) ARM/C5471 (arch/arm/src/c5471/) (3) ARM/DM320 (arch/arm/src/dm320/) (2) ARM/i.MX (arch/arm/src/imx/) (3) ARM/LPC17xx (arch/arm/src/lpc17xx/) (7) ARM/LPC214x (arch/arm/src/lpc214x/) (2) ARM/LPC313x (arch/arm/src/lpc313x/) (0) ARM/LPC43x (arch/arm/src/lpc43xx/) (3) ARM/STR71x (arch/arm/src/str71x/) (3) ARM/LM3S6918 (arch/arm/src/lm/) (x) ARM/SAMA5D3 ((arch/arm/src/sama5/) (5) ARM/STM32 (arch/arm/src/stm32/) (3) AVR (arch/avr) (0) Intel x86 (arch/x86) (3) MIPS/PIC32 (arch/mips) (1) Hitachi/Renesas SH-1 (arch/sh/src/sh1) (4) Renesas M16C/26 (arch/sh/src/m16c) (11) z80/z8/ez80/z180 (arch/z80/) (9) z16 (arch/z16/) (1) mc68hc1x (arch/hc) apps/ (4) Network Utilities (apps/netutils/) (3) 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: Closed. No, this behavior will not be implemented. Priority: Medium, required for good emulation of process/pthread model. Title: pause() NON-COMPLIANCE Description: In the POSIX description of this function is the pause() function will suspend the calling thread until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. The current implementation only waits for any non-blocked signal to be received. It should only wake up if the signal is delivered to a handler. Status: Open. Priority: Medium Low. Title: ON-DEMAND PAGING 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. This has been put on the shelf for some time. Priority: Medium-Low Title: GET_ENVIRON_PTR() Description: get_environ_ptr() (sched/sched_getenvironptr.c) is not implemented. The representation of the environment strings selected for NutX is not compatible with the operation. Some significant re-design would be required to implement this function and that effort is thought to be not worth the result. Status: Open. No change is planned. 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. Title: INCOMPATIBILITES WITH execv() AND execl() Description: Simplified 'execl()' and 'execv()' functions are provided by NuttX. NuttX does not support processes and hence the concept of overlaying a tasks process image with a new process image does not make any sense. In NuttX, these functions are wrapper functions that: 1. Call the non-standard binfmt function 'exec', and then 2. exit(0). As a result, the current implementations of 'execl()' and 'execv()' suffer from some incompatibilities, the most serious of these is that the exec'ed task will not have the same task ID as the vfork'ed function. So the parent function cannot know the ID of the exec'ed task. Status: Open Priority: Medium Low for now Title: ISSUES WITH atexit() AND on_exit() Description: These functions execute with the following bad properties: 1. They run with interrupts disabled, 2. They run in supervisor mode (if applicable), and 3. They do not obey any setup of PIC or address environments. Do they need to? The fix for all of these issues it to have the callbacks run on the caller's thread (as with signal handlers). Status: Open Priority: Medium Low. This is an important change to some less important interfaces. For the average user, these functions are just fine the way they are. Title: execv() AND vfork() Description: There is a problem when vfork() calls execv() (or execl()) to start a new appliction: When the parent thread calls vfork() it receives and gets the pid of the vforked task, and *not* the pid of the desired execv'ed application. The same tasking arrangement is used by the standard function posix_spawn(). However, posix_spawn uses the non-standard, internal NuttX interface task_reparent() to replace the childs parent task with the caller of posix_spawn(). That cannot be done with vfork() because we don't know what vfork() is going to do. Any solution to this is either very difficult or impossible without an MMU. Status: Open Priority: Low (it might as well be low since it isn't going to be fixed). Title: errno IS NOT SHARED AMONG THREADS Description: In NuttX, the errno value is unique for each thread. But for bug-for-bug compatibility, the same errno should be shared by the task and each thread that it creates. It is *very* easy to make this change: Just move the pterrno field from struct tcb_s to struct task_group_s. However, I am still not sure if this should be done or not. Status: Closed. The existing solution is better (although its incompatibilities could show up in porting some code). Priority: Low 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. No changes are planned. Priority: Medium/Low, a good feature to prevent memory leaks but would have negative impact on memory usage and code size. Title: KERNEL MODE PAGE ALLOCATOR Description: The KERNEL mode build for platforms with an MMU really needs a page-oriented allocator and support for sbrk() and brk() Status: Open Priority: Low o Signals (sched/, arch/) ^^^^^^^^^^^^^^^^^^^^^^^ Title: STANDARD SIGNALS Description: 'Standard' signals and signal actions are not supported. (e.g., SIGINT, SIGSEGV, etc). Update: SIG_CHLD is supported if so configured. Status: Open. No changes are planned. 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 Title: SIGNAL NUMBERING Description: In signal.h, the range of valid signals is listed as 0-31. However, in many interfaces, 0 is not a valid signal number. The valid signal number should be 1-32. The signal set operations would need to map bits appropriately. Status: Open Priority: Low. Even if there are only 31 usable signals, that is still a lot. o pthreads (sched/) ^^^^^^^^^^^^^^^^^ Title: CANCELLATION POINTS Description: pthread_cancel(): Should implement cancellation points and pthread_testcancel() Status: Open. No changes are planned. 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. No changes planned. 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 Kernel/Protected Build ^^^^^^^^^^^^^^^^^^^^^^ Title: NSH PARTITIONING. Description: There are issues with several NSH commands in the NuttX kernel and protected build modes (where NuttX is built as a monolithic kernel and user code must trap into the protected kernel via syscalls). The current NSH implementation has several commands that call directly into kernel internal functions for which there is no syscall available. The commands cause link failures in the kernel/protected build mode and must currently be disabled. Here are known problems that must be fixed: COMMAND KERNEL INTERFACE(s) -------- ---------------------------------------------- losetup losetup(), loteardown() mkfatfs mkfatfs mkrd ramdisk_register() dd bchlib_setup(), bchlib_read(), bchlib_write(), bchlib_teardown() ps sched_foreach() ifup netdev_foreach() ifdown netdev_foreach() ifconfig netdev_foreach(), g_netstats ping icmp_ping() Status: Open Priority: Medium/High -- the kernel build configuration is not fully fielded yet. Title: NSH free COMMAND LIMITATION Description: The NSH 'free' command only shows memory usage in the user heap only, not usage in the kernel heap. I am thinking that kernel heap memory usage should be available in /proc/memory. Status: Open Priority: Medium/High Title: TELNETD PARTITIONING. Description: Telnetd is implemented as a driver that resides in the apps/ directory. In the kernel/protected build modes, the driver logic must be moved into the kernel part of the build (nuttx/, although the application level interfaces must stay in apps/). Status: Open Priority: Medium Title: NxCONSOLE PARTITIONING. Description: NxConsole is implemented (correctly) as a driver that resides in the nuttx/ directory. However, the user interfaces must be moved into a NuttX library or into apps/. Currently applications calls to the NxConsole user interfaces are undefined. Status: Open Priority: Medium Title: C++ CONSTRUCTORS HAVE TOO MANY PRIVILEGES (PROTECTED MODE) Description: When a C++ ELF module is loaded, its C++ constructors are called via sched/task_starthook.c logic. This logic runs in protected mode. The is a security hole because the user code runs with kernel- privileges when the constructor executes. Destructors likely have the opposite problem. The probably try to execute some kernel logic in user mode? Obviously this needs to be investigated further. Status: Open Priority: Low (unless you need build a secure C++ system). Title: TOO MANY SYSCALLS Description: There are a few syscalls that operate very often in user space. Since syscalls are (relatively) time consuming this could be a performance issue. Here is some numbers that I collected in an application that was doing mostly printf outout: sem_post - 18% of syscalls sem_wait - 18% of syscalls getpid - 59% of syscalls -------------------------- 95% of syscalls Obviously system performance could be improved greatly by simply optimizing these functions so that they do not need to system calls so frequently. getpid() is (I believe) part of the re-entrant semaphore logic. Something like TLS might be used to retain the thread's ID locally. Linux, for example, has functions call up() and down(). up() increments the semaphore count but does not call into the kernel unless incrementing the count unblocks a task; similarly, down decrements the count and does not call into the kernel unless the count becomes negative the caller must be blocked. Update: "I am thinking that there should be a "magic" global, user-accessible variable that holds the PID of the currently executing thread; basically the PID of the task at the head of the ready-to-run list. This variable would have to be reset each time the head of the ready- to-run list changes. "Then getpid() could be implemented in user space with no system call by simply reading this variable. "This one would be easy: Just a change to include/nuttx/userspace.h, configs/*/kernel/up_userspace.c, libc/, sched/sched_addreadytorun.c, and sched/sched_removereadytorun.c. That would eliminate 59% of the syscalls." Update: This is probably also just a symptom of the OS test that does mostly console output. The requests for the pid() are part of the implementation of the I/O's re-entrant semaphore implementation and would not be an issue in the more general case. Status: Open Priority: Low-Medium. Right now, I do not know if these syscalls are a real performance issue or not. The above statistics were collected from a an atypical application (the OS test), and does an excessive amount of console output. There is probably no issue with more typical embedded applications. Title: SECURITY ISSUES Description: In the current designed, the kernel code calls into the user-space allocators to allocate user-space memory. It is a security risk to call into user-space in kernel-mode because that could be exploited to gain control of the system. That could be fixed by dropping to user mode before trapping into the memory allocators; the memory allocators would then need to trap in order to return (this is already done to return from signal handlers; that logic could be renamed more generally and just used for a generic return trap). Another place where the system calls into the user code in kernel mode is work_usrstart() to start the user work queue. That is another security hole that should be plugged. Status: Open Priority: Low (unless security becomes an issue). Title: MICRO-KERNEL Description: The initial kernel build cut many interfaces at a very high level. The resulting monolithic kernel is then rather large. It would not be a prohibitively large task to reorganize the interfaces so that NuttX is built as a micro-kernel, i.e., with only the core OS services within the kernel and with other OS facilities, such as the file system, message queues, etc., residing in user-space and to interfacing with those core OS facilities through traps. Status: Open Priority: Low. This is a good idea and certainly an architectural improvement. However, there is no strong motivation now do do that partitioning work. Title: ARMVv7-A STACK ISSUE Description: Currently a program running as a process in the kernel build mode cannot run other programs that reside on the file system. Why? Because in order to run those other programs, the new program's address environment must be instantiated in memory to load the .text and .data and to allocate the initial user space components from the new user heap. However, the previous program's stack currently resides in its heap. So when a process tries to run another program, its heap is unmapped and the system crashes. The fix is to add a separate stack in a separate memory region that does not get unmapped when creating new processes. There are hooks in place to do this; I just need to get time to get that done. UPDATE: I don't think it is that simple. Startup logic will need to access the new stack in its correct location to do things like setup task arguments. So I don't think that there is anyway to do that without losing the current stack. I may have to do the Linux solution: Two stacks for each thread: The main user stack, and a tiny kernel mode stack. Status: Open Priority: Pretty high... the kernel build is useless without this capability. 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 a hold 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 aplication logic 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 the application. Title: STATIC CONSTRUCTORS AND MULTITASKING Description: The logic that calls static constructors operates on the main thread of the initial user application task. Any static constructors that cache task/thread specific information such as C streams or file descriptors will not work in other tasks. See also UCLIBC++ AND STATIC CONSTRUCTORS below. Status: Open Priority: Low and probably will not changed. In these case, there will need to be an application specific solution. Title: UCLIBC++ AND STATIC CONSTRUCTORS uClibc++ was designed to work in a Unix environment with processes and with separately linked executables. Each process has its own, separate uClibc++ state. uClibc++ would be instantiated like this in Linux: 1) When the program is built, a tiny start-up function is included at the beginning of the program. Each program has its own, separate list of C++ constructors. 2) When the program is loaded into memory, space is set aside for uClibc's static objects and then this special start-up routine is called. It initializes the C library, calls all of the constructors, and calls atexit() so that the destructors will be called when the process exits. In this way, you get a per-process uClibc++ state since there is per-process storage of uClibc++ global state and per-process initialization of uClibc++ state. Compare this to how NuttX (and most embedded RTOSs) would work: 1) The entire FLASH image is built as one big blob. All of the constructors are lumped together and all called together at one time. This, of course, does not have to be so. We could segregate constructors by some criteria and we could use a task start up routine to call constructors separately. We could even use ELF executables that are separately linked and already have their constructors separately called when the ELF executable starts. But this would not do you very much good in the case of uClibc++ because: 2) NuttX does not support processes, i.e., separate address environments for each task. As a result, the scope of global data is all tasks. Any change to the global state made by one task can effect another task. There can only one uClibc++ state and it will be shared by all tasks. uClibc++ apparently relies on global instances (at least for cin and cout) there is no way to to have any unique state for any "task group". [NuttX does not support processes because in order to have true processes, your hardware must support a memory management unit (MMU) and I am not aware of any mainstream MCU that has an MMU (or, at least an MMU that is capable enough to support processes).] NuttX does not have processes, but it does have "task groups". See http://www.nuttx.org/doku.php?id=wiki:nxinternal:tasksnthreads. A task group is the task plus all of the pthreads created by the task via pthread_create(). Resources like FILE streams are shared within a task group. Task groups are like a poor man's process. This means that if the uClibc++ static classes are initialized by one member of a task group, then cin/cout should work correctly with all threads that are members of task group. The destructors would be called when the final member of the task group exists (if registered via atexit()). So if you use only pthreads, uClibc++ should work very much like it does in Linux. If your NuttX usage model is like one process with many threads then you have Linux compatibility. If you wanted to have uClibc++ work across task groups, then uClibc++ and NuttX would need some extensions. I am thinking along the lines of the following: 1) There is a per-task group storage are withing the RTOS (see include/nuttx/sched.h). If we add some new, nonstandard APIs then uClibc++ could get access to per-task group storage (in the spirit of pthread_getspecific() which gives you access to per-thread storage). 2) Then move all of uClibc++'s global state into per-task group storage and add a uClibc++ initialization function that would: a) allocate per-task group storage, b) call all of the static constructors, and c) register with atexit() to perform clean- up when the task group exits. That would be a fair amount of effort. I don't really know what the scope of such an effort would be. I suspect that it is not large but probably complex. NOTES: 1) See STATIC CONSTRUCTORS AND MULTITASKING 2) To my knowledge, only some uClibc++ ofstream logic is sensitive to this. All other statically initialized classes seem to work OK across different task groups. Status: Open Priority: Low. I have no plan to change this logic now unless there is some strong demand to do so. 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. Update: 13-27-1, tests/mutex crashed with a memory corruption problem the last time that I ran it. 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 Documentation/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-gotoff.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-gotoff.ld} else NXFLATLDSCRIPT=$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.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. Title: TOOLCHAIN COMPATIBILITY PROBLEM Descripton: The older 4.3.3 compiler generates GOTOFF relocations to the constant strings, like: .L3: .word .LC0(GOTOFF) .word .LC1(GOTOFF) .word .LC2(GOTOFF) .word .LC3(GOTOFF) .word .LC4(GOTOFF) Where .LC0, LC1, LC2, LC3, and .LC4 are the labels correponding to strings in the .rodata.str1.1 section. One consequence of this is that .rodata must reside in D-Space since it will addressed relative to the GOT (see the section entitled "Read-Only Data in RAM" at http://nuttx.org/Documentation/NuttXNxFlat.html#limitations). The newer 4.6.3compiler generated PC relative relocations to the strings: .L2: .word .LC0-(.LPIC0+4) .word .LC1-(.LPIC1+4) .word .LC2-(.LPIC2+4) .word .LC3-(.LPIC4+4) .word .LC4-(.LPIC5+4) This is good and bad. This is good because it means that .rodata.str1.1 can now reside in FLASH with .text and can be accessed using PC-relative addressing. That can be accomplished by simply moving the .rodata from the .data section to the .text section in the linker script. (The NXFLAT linker script is located at nuttx/binfmt/libnxflat/gnu-nxflat.ld). This is bad because a lot of stuff may get broken an a lot of test will need to be done. One question that I have is does this apply to all kinds of .rodata? Or just to .rodata.str1.1? Status: Open. Many of the required changes are in place but, unfortunately, not enough go be fully functional. I think all of the I-Space-to-I-Space fixes are in place. However, the generated code also includes PC-relative references to .bss which just cannot be done. Priority: Medium. The workaround for now is to use the older, 4.3.3 OABI compiler. o Network (net/, drivers/net) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Title: 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. Another issue: When sending packets to another subnet, the current logic falls back and uses ETH0 if it cannot find the device for the subnet. That lookup would need to be smarter... perhaps it needs a routing table. Status: Open. Nothing will probably be done until I have a platform with two network interfaces that I need to support. 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. This is really part of the above issue. 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. No work will probably be done until there is a specific requirement for IPv6. 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: 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. This is not a bug but an enhancement idea. 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 notified 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: 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: CLOSED CONNECTIONS IN THE BACKLOG If a connection is backlogged but accept() is not called quickly, then that connection may time out. How should this be handled? Should the connection be removed from the backlog if it is times out or is closed? Or should it remain in the backlog with a status indication so that accept() can fail when it encounteres the invalid connection? Status: Open Priority: Medium. Important on slow applications that will not accept connections promptly. 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. If queuing of stall requests is supported by DCD then this workaround is not required. In this case, (1) the stall is not sent until all write requests preceding the stall request are sent, (2) the stall is sent, and then after the stall is cleared, (3) all write requests queued after the stall are sent. See, for example, the queuing of pending stall requests in the SAM3/4 UDP driver at arch/arm/src/sam34/sam_udp.c. There the logic is do this is implemented with a normal request queue, a pending request queue, a stall flag and a stall pending flag: 1) If the normal request queue is not empty when the STALL request is received, the stall pending flag is set. 2) If addition write requests are received while the stall pending flag is set (or while waiting for the stall to be sent), those write requests go into the pending queue. 3) When the normal request queue empties successful and all of the write transfers complete, the STALL is sent. The stall pending flag is cleared and the stall flag is set. Now the endpoint is really stalled. 4) After the STALL is cleared (via the Clear Feature SETUP), the pending request queue is copied to the normal request queue, the stall flag is cleared, and normal write request processing resumes. 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. Here is an overview of the required changes: New two buffers in driver structure: 1. The existing EP0 setup request buffer (ctrlreq, 8 bytes) 2. A new EP0 data buffer to driver state structure (ep0data, max packetsize) Add a new state: 3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT) General logic flow: 1. When an EP0 SETUP packet is received: - Read the request into EP0 setup request buffer (ctrlreq, 8 bytes) - If this is an OUT request with data length, set the EP0 state to EP0STATE_SETUP_OUT and wait to receive data on EP0. - Otherwise, the SETUP request may be processed now (or, in the case of the F4 driver, at the conclusion of the SETUP phase). 2. When EP0 the EP0 OUT DATA packet is received: - Verify state is EP0STATE_SETUP_OUT - Read the request into the EP0 data buffer (ep0data, max packet size) - Now process the previously buffered SETUP request along with the OUT data. 3. When the setup packet is dispatched to the class driver, the OUT data must be passed as the final parameter in the call. Update 2013-9-2: The new USB device-side driver for the SAMA5D3 correctly supports OUT SETUP data following the same design as per above. Update 2013-11-7: David Sidrane has fixed with issue with the STM32 F1 USB device driver. Still a few more to go before this can be closed out. 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 currently, but it might be). Title: USB HUB SUPPORT Description: Add support for USB hubs Status: Open Priority: Low/Unknown. This is a feature enhancement. o Libraries (libc/) ^^^^^^^^^^^^^^^^^ Title: SIGNED time_t Description: The NuttX time_t is type uint32_t. I think this is consistent with all standards and with normal usage of time_t. However, according to Wikipedia, time_t is usually implemented as a signed 32-bit value. Status: Open Priority: Very low unless there is some compelling issue that I do not know about. 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 libc/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: 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 libc/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: 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 properly (using configuration stm3240g-eval/nsh2). The problem may be an assertion that is occurring before we have a console. Status: Open Priority: Medium Title : USE VFS TO MANAGE NAMED MESSAGE QUEUES AND NAMED SEMAPHORES Description: Currently redundant namespace management logic is use for named message queues and semaphores. Named semaphore management should be consolidated in the VFS. Perhaps in /ipc/mqueue and /ipc/sem. Status: Open Priority: Low. Nothing is broken. This is an enhancement that would improve the OS design and possibly reduce some FLASH usage Title: UNIFIED DESCRIPTOR REPRESENTATION Descripton: There are two separate ranges of descriptors for file and socket descriptors: if a descriptor is in one range then it is recognized as a file descriptor; if it is in another range then it is recognized as a socket descriptor. These separate descriptor ranges can cause problems, for example, they makes dup'ing descriptors with dup2() problematic. The two groups of descriptors are really indices into two separate tables: On an array of file structures and the other an array of socket structures. There really should be one array that is a union of file and socket descriptors. Then socket and file decriptors could lie in the same range. Status: Open Priority: Low Title: DUPLICATE FAT FILE NAMES Description: "The NSH and POSIX API interpretations about sensitivity or insensitivity to upper/lowercase file names seem to be not consistent in our usage - which can result in creating two directories with the same name..." Example using NSH: nsh> echo "Test1" >/tmp/AtEsT.tXt nsh> echo "Test2" >/tmp/aTeSt.TxT nsh> ls /tmp /tmp: AtEsT.tXt aTeSt.TxT nsh> cat /tmp/aTeSt.TxT Test2 nsh> cat /tmp/AtEsT.tXt Test1 Status: Open Priority: Low Title: FAT LONG FILENAME COMPATIBILTY Description: Recently there have been reports that file with long file names created by NuttX don't have long file names when viewed on Windows. The long file name support has been around for a long time and I don't ever having seen this before so I am suspecting that some evil has crept in. 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 operates 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. Title: NXCONSOLE VT100 SUPPORT Description: If the NxConsole will be used with the Emacs-like command line editor (CLE), then it will need to support VT100 cursor control commands. Status: Open Priority: Low, the need has not yet arisen. 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 feature is complete and that we can switch to exclusive use of the tool? Status: Open Priority: Medium-low Title: NATIVE WINDOWS BUILD Description: This effort is underway using MinGW-GCC and GNUWin32 tools for (coreutils+make+grep+sed+uname). Current status: 1. configs/stm32f4discovery/winbuild - builds okay natively 2. configs/ez80f910200kitg - Can be reconfigured to build natively. Requires some manual intervention to get a clean build. See configs/ez80f910200kitg/README.txt. Status: Open Priority: Low Title: WINDOWS DEPENDENCY GENERATION Description: Dependency generation is currently disabled when a Windows native toolchain is used in a POSIX-like environment (like Cygwin). The issue is that the Windows tool generates dependencies use Windows path formatting and this fails with the dependency file (Make.dep) is include). Perhaps 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 appropriate. 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. 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 asynchronous 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. This approach is already implemented for the ARM Cortex-M0, Cortex-M3, Cortex-M4, and Cortex-A5 families. But still needs to be back-ported to the ARM7 and ARM9 (which are nearly identical to the Cortex-A5 in this regard). The change is *very* simple for this architecture, but not implemented. Status: Open. But complete on all ARM platforms except ARM7 and ARM9. Priority: Low. Title: IMPROVED ARM INTERRUPT HANDLING Description: The ARM and Cortex-M3 interrupt handlers restores all registers 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: CORTEX-M3 STACK OVERFLOW Description: There is bit bit logic in 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 excessively high interrupt conditions, many nested interrupts can occur 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. UPDATE: Other ARM architectures have a similer issue. Status: Open Priority: Low. The conditions of continuous interrupts is really the problem. If your design needs continuous interrupts like this, please try the above change and, please, submit a patch with the working fix. Title: STACK ALIGNMENT IN INTERRUPT HANDLERS Description: The EABI standard requires that the stack always have a 32-byte alignment. There is no guarantee at present that the stack will be so aligned in an interrupt handler. Therefore, I would expect some issues if, for example, floating point or perhaps long long operations were performed in an interrupt handler. This issue exists for ARM7, ARM9, Cortex-M0, Cortex-M3, and Cortex-M4 but has been addressed for the Cortex-A5. The fix is really simple can cannot be incorporated without some substantial testing. For ARM, the fix is the following logic arround each call into C code from assembly: mov r4, sp /* Save the SP in a preserved register */ bic sp, sp, #7 /* Force 8-byte alignment */ bl cfunction /* Call the C function */ mov sp, r4 /* Restore the possibly unaligned stack pointer */ This same issue applies to the interrupt stack which is, I think improperly aligned in almost all cases (except Cortex-A5). Status: Open Priority: Low for me because I never do floating point operations in interrupt handlers. 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 setup 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 architecture 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 optimization 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 block size 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/lm/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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/SAMA5D3 ((arch/arm/src/sama5/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Issues related to the SAMA5D3 port are in configs/sama5d3x-ek/README.txt. o ARM/STM32 (arch/arm/src/stm32/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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: DMA EXTENSIONS F1/3 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: 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). Title: DMA FROM EXTERNAL, FSMC MEMORY Description: I have seen a problem on F1 where all SDIO DMAs work exist for write DMAs from FSMC memory (i.e., from FSMC memory to SDIO). Read transfers work fine (SDIO to FSMC memory). The failure is a data underrun error with zero bytes of data transferred. The workaround for now is to use DMA buffers allocated from internal SRAM. Status: Open Priority: Low 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/usbmsc 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 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). However, 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 Mikroelektronika 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/z180 (arch/z80) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Title: SDCC INTEGER OVERFLOWS Description: The SDCC version the same problems with integer overflow during compilation for certain 8-bit platform. At typical cause is code like usleep(500*1000) which exceeds the range of a 16-bit integer. Status: These have probably been fixed but have not yet been verified on thes affected platforms. Priority: Low for now 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 compiling mm/mm_initialize.c. 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 every time 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 Title: UNFINISHED Z180 LOGIC NEEDED BY THE P112 BOARD Description: 1) Need to revisit the start-up logic. Looking at the P112 Bios (Bios.mcd), I see that quite of bit of register setup is done there. 2) Finish ESCC driver logic. Status: Open Priority: Low (at least until I get P112 hardware) 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: 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 submitted 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 , 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 Title: NATIVE BUILD PROBLEMS Description: When last tested (ca.12/12), there were some missing .obj files in arch/z16/src. A little additional TLC will be needed to get a reliable Windows native build. Status: Open Priority: Low -- I don't think anyone uses the Z16 port with the native build. Title: COMPILER BUG Description: There is a bug in the ZDS II 5.0.1 compiler. It generates incorrect code when calling through a function pointer if (1) the function pointer is a field in a structure, and (2) the function pointer has a variable number of arguments. The exact name of the bug is this: Normally, when a function is called, parameters are passed in registers. When calling a function with a variable number of arguments, parameters must instead be passed on the stack. In this failure case3, parameters are erroneously passed in registers while the receive function expects the parameters on the stack. This usually results in a crash. Unfortunately, NSH does have this exact kind of function call and because of this compiler bug, NSH cannot be used with the ZNEO Status: The bug has been reported to ZiLOG and they have reproduced the problem. There is, however, no schedule for correction of the bug. Priority: High if you are using ZNEO 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: 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: Probably closed. The basic ARP issue has been fixed (if CONFIG_NET_ARP_SEND is enable), but this has not been verified with THTTPD. 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: ARP COMMAND Description: Add an ARP command so that we can see and modify 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.