diff options
Diffstat (limited to 'nuttx/TODO')
| -rw-r--r-- | nuttx/TODO | 2111 |
1 files changed, 0 insertions, 2111 deletions
diff --git a/nuttx/TODO b/nuttx/TODO deleted file mode 100644 index b5958f397..000000000 --- a/nuttx/TODO +++ /dev/null @@ -1,2111 +0,0 @@ -NuttX TODO List (Last updated January 30, 2013) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This file summarizes known NuttX bugs, limitations, inconsistencies with -standards, things that could be improved, and ideas for enhancements. - -nuttx/ - - (11) Task/Scheduler (sched/) - (2) Memory Managment (mm/) - (3) Signals (sched/, arch/) - (2) pthreads (sched/) - (2) C++ Support - (6) Binary loaders (binfmt/) - (16) Network (net/, drivers/net) - (4) USB (drivers/usbdev, drivers/usbhost) - (11) Libraries (libc/, ) - (9) File system/Generic drivers (fs/, drivers/) - (5) Graphics subystem (graphics/) - (1) Pascal add-on (pcode/) - (1) Documentation (Documentation/) - (7) Build system / Toolchains - (5) Linux/Cywgin simulation (arch/sim) - (5) 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/) - (5) ARM/STM32 (arch/arm/src/stm32/) - (3) AVR (arch/avr) - (0) Intel x86 (arch/x86) - (5) 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) - (11) z80/z8/ez80/z180 (arch/z80/) - (9) z16 (arch/z16/) - (1) mc68hc1x (arch/hc) - -apps/ - - (5) Network Utilities (apps/netutils/) - (5) 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: 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. - - The primary advantage of a tickless OS is that is would allow for - reduce power consumptions. That is because timer interrupts will - usually awaken CPUs from reduced power consumption states. - Status: Open. There will probably be no tickless OS implementation unless - someone gets motivated and drives the change. - Priority: Low - - 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 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. 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 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. 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: USER-SPACE WORK QUEUES - Description: There has been some use of work queues that has crept into some - user code. I am thinking of NxWidgets::CNxTimer. That timer - logic was originally implemented (correctly) using POSIX timers, - but was re-implemented using timed work. - - The issue is that NxWidgets::CNxTimer is a user-space application - but the work queues are an OS internal feature. This will be a - problem for KERNEL builds. Hooks and definitions have been added - in include/nuttx/wqueue.h to support a user-space work queue, but - the corresponding logic has not been implemented. - - The work queue logic will need to be moved from sched/ to libc/wqueue/ - Status: Open. No work will probably be done until a functional KERNEL build - that includes NxWisges::CNxTimer is needed. - Priority: Medium Low for now - - 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 vfor() is going to do. - - Any solution to this is either very difficult or impossible with - 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 - _TCB to struct task_group_s. However, I am still not sure - if this should be done or not. - Status: Open - 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: CONTAINER ALLOCATOR - Description: There are several places where the logic requires allocation of - a tiny structure that just contains pointers to other things or - small amounts of data that needs to be bundled together. There - are examples net/net_poll.c and numerous other places. - - I am wondering if it would not be good create a pool of generic - containers (say void *[4]). There re-use these when we need - small containers. The code in sched/task_childstatus.c might - be generalized for this purpose. - Status: Open - Priority: Very low (I am not even sure that this is a good idea yet). - -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 support if 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 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. - - 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 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-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: SOCK_RAW/SOCK_PACKET - Description: Should implement SOCK_RAW, SOCK_PACKET - Status: Open. No changes are planned. - Priority: Low - - 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. - - 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: 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. This is just a thought experiment. No changes are planned. - 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. - -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). - - 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: 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 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 - 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 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 enviornment (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 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 libc/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. - - Title: kconfig-mconf NOT AVAILABLE IN NATIVE WINDOWS BUILD - Description: NuttX is migrating to the use of the kconfig-frontends kconfig-mconf - tool for all configurations. In NuttX 6.24, support for native - Windows builds was added. However, thekconfig- mconf tool does not - build to run natively under Windows. - - Some effort was spent trying to get a clean kconfig-mconf build under - Windows. This is documented in the message thread beginning - here: http://tech.groups.yahoo.com/group/nuttx/message/2900. - The build was successfully completed using: MinGW-GCC, MSYS, - additional Windows libraries, and additional MSYS libraries - (MSYS is a variant of Cygwin so, presumeably, Cygwin could - have been used as well). However, on final testing, it was - found that there are problems with text and numeric entry: - http://tech.groups.yahoo.com/group/nuttx/message/2953. This - was considered a show stopper and the changs were not checked - in. - - Options: (1) Use kconfigs-conf (not kconfig-mconf). confis the text-only - configuration tool, (2) fix kconfig-mconf, (3) write another variant - of the configuration tool for windows, or (4) do all configuration - under Cygwin or MSYS. I am doing (4) now, but this is very - awkward because I have to set the apps path to ../apps (vs - ..\apps) and CONFIG_WINDOWS_NATIVE=n for the 'make menuconfig' - to run error free under windows. Very awkward! - Status: Open, there are some workarounds, but none are good. - Priority: High - -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: 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/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/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 - 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 allocted 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/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 - - Title: 8051 BUILD BROKEN - Description: The last time I tried to build the pjrc-8051 configurtion using - the SDCC 3.2.1 toolchain (for Windows). I got compilation - errors in sched/os_bringup.c. It complained about type - mis-matches. What I gather from Googling, this is a problem - with the --stack-auto option. At any rate, this problem will - need to be fixed if you want to resurrect the 8051 NuttX port. - Status: Open - Priority: Low -- I don't think anyone uses the 8051 port. - -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/z180 (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 - - Title: UNFINISHED Z180 LOGIC NEEDED BY THE P112 BOARD - Description: 1) Need to revist 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: 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 - - 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. As of this writing, the Cygwin - based build has not been re-verified. - Status: Open - Priority: Low -- I don't think anyone uses the Z16 port. - -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) - - Title: RE-DIRECTION OF BUILTIN APPLICATONS - Description: There is a problem with the re-direction of output form built-in - applications in NSH. When output is re-directed, exec_builtin() - spawns a tiny trampoline task that re-directs the output as - requested, starts the built-in task and then exit. - - The problem is that when exec_builtin() starts the trampoline task, - it receives and returns the pid of the trampoline task, and *not* - the pid of the desired builtin application. This bad pid is returned - to NSH and when NSH tries to use that pid in the waitpid() call, it - fails because the trampoline task no longer exists. - - 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(). - - exec_builtin() should not use this internal interface, however, - since it resides in the application space. The suggested solution - is (1) move the exec_builtin() logic into nuttx/sched, (2) make it - a semi-standard interface renamed to task_spawn() and prototyped - in nuttx/include/sched.h, and then (2) use task_reparent to solve - the parental problem in the same way that posix_spawn does. - Status: Open - Priority: Medium - -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. |