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