sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
0b43f10d73
nuttx/TODO
patacongo 814d40f5cd PIC32 USB mass storage device works; USB and MSC are now enabled by default in the PIC32MX7 MMB configuration 
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@4801 42af7a65-404d-4744-a932-0658087f49c3
2012-06-03 20:05:44 +00:00

1881 lines
86 KiB
Plaintext
Raw Blame History

NuttX TODO List (Last updated May 15, 2012)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with
standards, things that could be improved, and ideas for enhancements.
nuttx/
(6) Task/Scheduler (sched/)
(1) On-demand paging (sched/)
(1) Memory Managment (mm/)
(2) Signals (sched/, arch/)
(2) pthreads (sched/)
(2) C++ Support
(5) Binary loaders (binfmt/)
(17) Network (net/, drivers/net)
(3) USB (drivers/usbdev, drivers/usbhost)
(8) Libraries (lib/)
(10) 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/)
(3) ARM/STR71x (arch/arm/src/str71x/)
(3) ARM/LM3S6918 (arch/arm/src/lm3s/)
(7) ARM/STM32 (arch/arm/src/stm32/)
(3) AVR (arch/avr)
(0) Intel x86 (arch/x86)
(4) 8051 / MCS51 (arch/8051/)
(2) MIPS/PIC32 (arch/mips)
(1) Hitachi/Renesas SH-1 (arch/sh/src/sh1)
(4) Renesas M16C/26 (arch/sh/src/m16c)
(10) z80/z8/ez80 (arch/z80/)
(8) z16 (arch/z16/)
(1) mc68hc1x (arch/hc)
apps/
(5) Network Utilities (apps/netutils/)
(4) NuttShell (NSH) (apps/nshlib)
(1) System libraries apps/system (apps/system)
(5) Other Applications & Tests (apps/examples/)
o Task/Scheduler (sched/)
^^^^^^^^^^^^^^^^^^^^^^^
Title: CHILD PTHREAD TERMINATION
Description: When a tasks exits, shouldn't all of its child pthreads also be
terminated?
Status: Open
Priority: Medium, required for good emulation of process/pthread model.
Title: 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.
Update: These are being fixed as they are encountered. There is
no accounting of how many interfaces have this problem.
Status: Open
Priority: Medium, required for standard compliance (but makes the
code bigger)
Title: TICKLESS OS
Description: On a side note, I have thought about a tick-less timer for the OS
for a long time. Basically we could replace the periodic system
timer interrupt with a one-shot interval timer programmed for the
next interesting event time. That is one way to both reduce the
timer interrupt overhead and also to increase the accuracy of
delays.
Current timer processing is in sched/sched_processtimer.c:
1) Calls clock_timer() which just increments a counter (the system
timer -- basically "up-time"). This is only used when code asks
for the current time. In a tickless OS, some substitute answer
for the question "What time is it?" would need to be developed.
You could use an RTC? Or maybe logic that gets the time until the
next interval expiration and computes the current time. The
solution is not too difficult, but depends on a hardware solution.
2) Calls wd_timer() which handles the link list of ordered events:
Each timer event is saved with the delta time to the next event
in the list. So an interval timer would be perfect to implement this.
3) sched_process_timeslice(). Then there is round-robin time-slicing.
Status: Open
Priority: Low
o On-demand paging (sched/)
^^^^^^^^^^^^^^^^^^^^^^^^^
Title: ON-DEMAND PAGE INCOMPLETE
Description: On-demand paging has recently been incorporated into the RTOS.
The design of this feature is described here:
http://www.nuttx.org/NuttXDemandPaging.html.
As of this writing, the basic feature implementation is
complete and much of the logic has been verified. The test
harness for the feature exists only for the NXP LPC3131 (see
configs/ea3131/pgnsh and locked directories). There are
some limitations of this testing so I still cannot say that
the feature is fully functional.
Status: Open
Priority: Medium-Low
o Other core OS logic
^^^^^^^^^^^^^^^^^^^
Title: GET_ENVIRON_PTR()
Description: get_environ_ptr() (sched/sched_getenvironptr.c) is not implemented.
The representation of the the environment strings selected for
NutX is not compatible with the operation. Some significant
re-design would be required to implement this funcion and that
effort is thought to be not worth the result.
Status: Open
Priority: Low -- There is no plan to implement this.
Title: TIMER_GETOVERRUN()
Description: timer_getoverrun() (sched/timer_getoverrun.c) is not implemented.
Status: Open
Priority: Low -- There is no plan to implement this.
o Memory Managment (mm/)
^^^^^^^^^^^^^^^^^^^^^^
Title: FREE MEMORY ON TASK EXIT
Description: Add an option to free all memory allocated by a task when the
task exits. This is probably not be worth the overhead for a
deeply embedded system.
There would be complexities with this implementation as well
because often one task allocates memory and then passes the
memory to another: The task that "owns" the memory may not
be the same as the task that allocated the memory.
Update. From the NuttX forum:
...there is a good reason why task A should never delete task B.
That is because you will strand memory resources. Another feature
lacking in most flat address space RTOSs is automatic memory
clean-up when a task exits.
That behavior just comes for free in a process-based OS like Linux:
Each process has its own heap and when you tear down the process
environment, you naturally destroy the heap too.
But RTOSs have only a single, shared heap. I have spent some time
thinking about how you could clean up memory required by a task
when a task exits. It is not so simple. It is not as simple as
just keeping memory allocated by a thread in a list then freeing
the list of allocations when the task exists.
It is not that simple because you don't know how the memory is
being used. For example, if task A allocates memory that is used
by task B, then when task A exits, you would not want to free that
memory needed by task B. In a process-based system, you would
have to explicitly map shared memory (with reference counting) in
order to share memory. So the life of shared memory in that
environment is easily managed.
I have thought that the way that this could be solved in NuttX
would be: (1) add links and reference counts to all memory allocated
by a thread. This would increase the memory allocation overhead!
(2) Keep the list head in the TCB, and (3) extend mmap() and munmap()
to include the shared memory operations (which would only manage
the reference counting and the life of the allocation).
Then what about pthreads? Memory should not be freed until the last
pthread in the group exists. That could be done with an additional
reference count on the whole allocated memory list (just as streams
and file descriptors are now shared and persist until the last
pthread exits).
I think that would work but to me is very unattractive and
inconsistent with the NuttX "small footprint" objective. ...
Other issues:
- Memory free time would go up because you would have to remove
the memory from that list in free().
- There are special cases inside the RTOS itself. For example,
if task A creates task B, then initial memory allocations for
task B are created by task A. Some special allocators would
be required to keep this memory on the correct list (or on
no list at all).
Status: Open
Priority: Medium/Low, a good feature to prevent memory leaks but would
have negative impact on memory usage and code size.
o Signals (sched/, arch/)
^^^^^^^^^^^^^^^^^^^^^^^
Title: STANDARD SIGNALS
Description: 'Standard' signals and signal actions are not supported.
(e.g., SIGINT, SIGCHLD, SIGSEGV, etc).
Status: Open
Priority: Low, required by standards but not so critical for an
embedded system.
Title: SIGEV_THREAD
Description: sig_notify() logic does not support SIGEV_THREAD; structure
struct sigevent does not provide required members sigev_notify_function
or sigev_notify_attributes.
Status: Low, there are alternative designs. However, these features
are required by the POSIX standard.
Priority: Low for now
o pthreads (sched/)
^^^^^^^^^^^^^^^^^
Title: CANCELLATION POINTS
Description: pthread_cancel(): Should implement cancellation points and
pthread_testcancel()
Status: Open
Priority: Low, probably not that useful
Title: PTHREAD_PRIO_PROTECT
Description: Extended pthread_mutexattr_setprotocol() suport PTHREAD_PRIO_PROTECT:
"When a thread owns one or more mutexes initialized with the
PTHREAD_PRIO_PROTECT protocol, it shall execute at the higher of its
priority or the highest of the priority ceilings of all the mutexes
owned by this thread and initialized with this attribute, regardless of
whether other threads are blocked on any of these mutexes or not.
"While a thread is holding a mutex which has been initialized with
the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol attributes,
it shall not be subject to being moved to the tail of the scheduling queue
at its priority in the event that its original priority is changed,
such as by a call to sched_setparam(). Likewise, when a thread unlocks
a mutex that has been initialized with the PTHREAD_PRIO_INHERIT or
PTHREAD_PRIO_PROTECT protocol attributes, it shall not be subject to
being moved to the tail of the scheduling queue at its priority in the
event that its original priority is changed."
Status: Open
Priority: Low -- about zero, probably not that useful. Priority inheritance is
already supported and is a much better solution. And it turns out
that priority protection is just about as complex as priority inheritance.
Exerpted from my post in a Linked-In discussion:
"I started to implement this HLS/"PCP" semaphore in an RTOS that I
work with (http://www.nuttx.org) and I discovered after doing the
analysis and basic code framework that a complete solution for the
case of a counting semaphore is still quite complex -- essentially
as complex as is priority inheritance.
"For example, suppose that a thread takes 3 different HLS semaphores
A, B, and C. Suppose that they are prioritized in that order with
A the lowest and C the highest. Suppose the thread takes 5 counts
from A, 3 counts from B, and 2 counts from C. What priority should
it run at? It would have to run at the priority of the highest
priority semaphore C. This means that the RTOS must maintain
internal information of the priority of every semaphore held by
the thread.
"Now suppose it releases one count on semaphore B. How does the
RTOS know that it still holds 2 counts on B? With some complex
internal data structure. The RTOS would have to maintain internal
information about how many counts from each semaphore are held
by each thread.
"How does the RTOS know that it should not decrement the priority
from the priority of C? Again, only with internal complexity. It
would have to know the priority of every semaphore held by
every thread.
"Providing the HLS capability on a simple phread mutex would not
be such quite such a complex job if you allow only one mutex per
thread. However, the more general case seems almost as complex
as priority inheritance. I decided that the implementation does
not have value to me. I only wanted it for its reduced
complexity; in all other ways I believe that it is the inferior
solution. So I discarded a few hours of programming. Not a
big loss from the experience I gained."
o C++ Support
^^^^^^^^^^^
Title: USE OF SIZE_T IN NEW OPERATOR
Description: The argument of the 'new' operators should take a type of
size_t (see libxx/libxx_new.cxx and libxx/libxx_newa.cxx). But
size_t has an unknown underlying. In the nuttx sys/types.h
header file, size_t is typed as uint32_t (which is determined by
architecture-specific logic). But the C++ compiler may believe
that size_t is of a different type resulting in compilation errors
in the operator. Using the underlying integer type Instead of
size_t seems to resolve the compilation issues.
Status: Kind of open. There is a workaround. Setting CONFIG_CXX_NEWLONG=y
will define the operators with argument of type unsigned long;
Setting CONFIG_CXX_NEWLONG=n will define the operators with argument
of type unsigned int. But this is pretty ugly! A better solution
would be to get ahold of the compilers definition of size_t.
Priority: Low.
Title: STATIC CONSTRUCTORS
Description: Need to call static constructors
Update: Static constructors are implemented for the STM32 F4 and
this will provide the model for all solutions. Basically, if
CONFIG_HAVE_CXXINITIALIZE=y is defined in the configuration, then
board-specific code must provide the interface up_cxxinitialize().
up_cxxinitialize() is called from user_start() to initialize
all static class instances. This TODO item probably has to stay
open because this solution is only available on STM32 F4.
Status: Open
Priority: Low, depends on toolchain. Call to gcc's built-in static
constructor logic will probably have to be performed by
user logic in user_start().
o Binary loaders (binfmt/)
^^^^^^^^^^^^^^^^^^^^^^^^
Title: NXFLAT TESTS
Description: Not all of the NXFLAT test under apps/examples/nxflat are working.
Most simply do not compile yet. tests/mutex runs okay but
outputs garbage on completion.
Status: Open
Priority: High
Title: ARM UP_GETPICBASE()
Description: The ARM up_getpicbase() does not seem to work. This means
the some features like wdog's might not work in NXFLAT modules.
Status: Open
Priority: Medium-High
Title: READ-ONLY DATA IN RAM
Description: At present, all .rodata must be put into RAM. There is a
tentative design change that might allow .rodata to be placed
in FLASH (see Documentation/NuttXNxFlat.html).
Status: Open
Priority: Medium
Title: GOT-RELATIVE FUNCTION POINTERS
Description: If the function pointer to a statically defined function is
taken, then GCC generates a relocation that cannot be handled
by NXFLAT. There is a solution described in Documentataion/NuttXNxFlat.html,
by that would require a compiler change (which we want to avoid).
The simple workaround is to make such functions global in scope.
Status: Open
Priority: Low (probably will not fix)
Title: USE A HASH INSTEAD OF A STRING IN SYMBOL TABLES
Description: In the NXFLAT symbol tables... Using a 32-bit hash value instead
of a string to identify a symbol should result in a smaller footprint.
Status: Open
Priority: Low
Title: WINDOWS-BASED TOOLCHAIN BUILD
Description: Windows build issue. Some of the configurations that use NXFLAT have
the linker script specified like this:
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld -no-check-sections
That will not work for windows-based tools because they require Windows
style paths. The solution is to do something like this:
if ($(WINTOOL)y)
NXFLATLDSCRIPT=${cygpath -w $(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld}
else
NXFLATLDSCRIPT=$(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld
endif
Then use
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T"$(NXFLATLDSCRIPT)" -no-check-sections
Status: Open
Priority: There are too many references like the above. They will have
to get fixed as needed for Windows native tool builds.
o Network (net/, drivers/net)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: SOCK_RAW/SOCK_PACKET
Description: Should implement SOCK_RAW, SOCK_PACKET
Status: Open
Priority: Low
Tile: MULTIPLE NETWORK INTERFACE SUPPORT
Description: uIP polling issues / Multiple network interface support:
(1) Current logic will not support multiple ethernet drivers.
Each driver should poll on TCP connections connect on the
network supported by the driver; UDP polling should respond
with TX data only if the UDP packet is intended for the
the network supported by the driver.
(2) If there were multiple drivers, polling would occur at
double the rate. Fix by using bound IP address in TCP
connection (lipaddr) and verifying that it is in the subnet
served by the driver.
Status: Open
Priority: Medium, The feature is not important, but it is important
for NuttX to resolve the architectural issues.
Title: SENDTO() AND MULTIPLE NETWORK INTERFACE SUPPORT
Description: sendto() and multiple network interface support:
When polled, would have to assure that the destination IP
is on the subnet served by the polling driver.
Status: Open
Priority: Medium, The feature is not important, but it is important
for NuttX to resolve the architectural issues.
Title: IPv6
Description: IPv6 support is incomplete. Adam Dunkels has recently announced
IPv6 support for uIP (currently only as part of Contiki). Those
changes need to be ported to NuttX.
Status: Open
Priority: Medium
Title: LISTENING FOR UDP BROADCASTS
Description: Incoming UDP broadcast should only be accepted if listening on
INADDR_ANY(?)
Status: Open
Priority: Low
Title: READ-AHEAD THROTTLING
Description: Read-ahead buffers capture incoming TCP data when no user
thread is recv-ing the data. Should add some driver call to
support throttling; when there is no listener for new data, the
driver should be throttled. Perhaps the driver should disable
RX interrupts when throttled and re-anable on each poll time.
recvfrom would, of course, have to un-throttle.
Status: Open
Priority: Medium
Title: STANDARDIZE ETHERNET DRIVER STATISTICS
Description: Need to standardize collection of statistics from network
drivers. apps/nshlib ifconfig command should present
statistics.
Status: Open
Priority: Low
Title: CONCURRENT TCP SEND OPERATIONS
Description: At present, there cannot be two concurrent active TCP send
operations in progress using the same socket. This is because
the uIP ACK logic will support only one transfer at a time. The
solution is simple: A mutex will be needed to make sure that each
send that is started is able to be the exclusive sender until all of
the data to be sent has been ACKed.
Status: Open. There is some temporary logic to apps/nshlib that does
this same fix and that temporary logic should be removed when
send() is fixed.
Priority: Medium-Low. This is an important issue for applications that
send on the same TCP socket from multiple threads.
Title: UDP READ-AHEAD?
Description: TCP supports read-ahead buffering to handle the receipt of
TCP/IP packets when there is no read() in place. Should such
capability be useful for UDP? PRO: Would reduce packet loss
and enable support for poll()/select(). CON: UDP is inherently
lossy so why waste memory footprint?
Status: Open
Priority: Medium
Title: NO POLL/SELECT ON UDP SOCKETS
Description: poll()/select() is not implemented for UDP sockets because they do
do not support read-ahead buffering. Therefore, there is never
a case where you can read from a UDP socket without blocking.
Status: Open, depends on UDP read-ahead support
Priority: Medium
Title: POLL/SELECT ON TCP SOCKETS NEEDS READ-AHEAD
Description: poll()/select() only works for availability of buffered TCP
read data (when read-ahead is enabled). The way writing is
handled in uIP, all sockets must wait when send and cannot
be notifiied when they can send without waiting.
Status: Open, probably will not be fixed.
Priority: Medium... this does effect porting of applications that expect
different behavior from poll()/select()
Title: SOCKETS DO NOT ALWAYS SUPPORT O_NONBLOCK
Description: sockets do not support all modes for O_NONBLOCK. Sockets
support only (1) TCP/IP non-blocking read operations when read-ahead
buffering is enabled, and (2) TCP/IP accept() operations when TCP/IP
connection backlog is enabled.
Status: Open
Priority: Low.
Title: UNFINISHED CRYSTALLAN CS89X0 DRIVER
Description: I started coding a CrystalLan CS89x0 driver (drivers/net/cs89x0.c),
but never finished it.
Status: Open
Priority: Low unless you need it.
Title: UNTESTED IGMPv2
Description: Support for client-side IGMPv2 multicast has been added but not yet
tested (because I don't have a proper environment for multicast testing).
There are most likely errors that need to be fixed at least in the
receipt of multicast packets.
In addition, an ethernet driver that needs to work with the IGMP logic
will have to include additional support for multicast MAC address tables.
Status: Open
Priority: Low unless you need it.
Title: INTERFACES TO LEAVE/JOIN IGMP MULTICAST GROUP
Description: The interfaces used to leave/join IGMP multicast groups is non-standard.
RFC3678 (IGMPv3) suggests ioctl() commands to do this (SIOCSIPMSFILTER) but
also status that those APIs are historic. NuttX implements these ioctl
commands, but is non-standard because: (1) It does not support IGMPv3, and
(2) it looks up drivers by their device name (eg., "eth0") vs IP address.
Linux uses setsockopt() to control multicast group membership using the
IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP options. It also looks up drivers
using IP addresses (It would require additional logic in NuttX to look up
drivers by IP address). See http://tldp.org/HOWTO/Multicast-HOWTO-6.html
Status: Open
Priority: Medium. All standards compatibility is important to NuttX. However, most
the mechanism for leaving and joining groups is hidden behind a wrapper
function so that little of this incompatibilities need be exposed.
Title: CONFIGURATIONS WITH TINY MTUS
Description: Many configurations have the MTU (CONFIG_NET_BUFSIZE) set to very small
numbers, less then the minimum MTU size that must be supported -- 576.
This can cause problems in some networks: CONFIG_NET_BUFSIZE should
be set to at least 576 in all defconfig files.
The symptoms of using very small MTU sizes can be very strange. With
Ubuntu 9.x and vsFtpd was that the total packet size did *not match* the
packet size in the IP header. This then caused a TCP checksum failure
and the packet was rejected.
Status: Open
Priority: Low... fix defconfig files as necessary.
Title: UNFINISHED ENC28J60 DRIVER
Description: So far, I have not come up with a usable hardware platform to
verify the ENC28J60 Ethernet driver (drivers/net/enc28j60.c).
So it is untested.
Status: Open
Priority: Low unless you need it.
o USB (drivers/usbdev, drivers/usbhost)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: USB STORAGE DRIVER DELAYS
Description: There is a workaround for a bug in drivers/usbdev/usbdev_storage.c.
that involves delays. This needs to be redesigned to eliminate these
delays. See logic conditioned on CONFIG_USBMSC_RACEWAR.
Status: Open
Priority: Medium
Title: RTL8187 DRIVER IS UNFINISHED
Description: misc/drivers/usbhost_rtl8187.c is a work in progress. There is no RTL8187
driver available yet. That is a work in progress it was abandoned because
it depends on having an 802.11g stack.
Status: Open
Priority: Low (Unless you need RTL8187 support).
Title: EP0 OUT CLASS DATA
Description: There is no mechanism in place to handle EP0 OUT data transfers.
There are two aspects to this problem, neither are easy to fix
(only because of the number of drivers that would be impacted):
1. The class drivers only send EP0 write requests and these are
only queued on EP0 IN by this drivers. There is never a read
request queued on EP0 OUT.
2. But EP0 OUT data could be buffered in a buffer in the driver
data structure. However, there is no method currently
defined in the USB device interface to obtain the EP0 data.
Updates: (1) The USB device-to-class interface as been extended so
that EP0 OUT data can accompany the SETUP request sent to the
class drivers. (2) The logic in the STM32 F4 OTG FS device driver
has been extended to provide this data. Updates are still needed
to other drivers.
Status: Open
Priority: High for class drivers that need EP0 data. For example, the
CDC/ACM serial driver might need the line coding data (that
data is not used currenly, but it might be).
o Libraries (lib/)
^^^^^^^^^^^^^^^^
Title: ENVIRON
Description: The definition of environ in stdlib.h is bogus and will not
work as it should. This is because the underlying
representation of the environment is not an arry of pointers.
Status: Open
Priority: Medium
Title: TERMIOS
Description: Need some minimal termios support... at a minimum, enough to
switch between raw and "normal" modes to support behavior like
that needed for readline().
Status: Open
Priority: Low
Title: DAYS OF THE WEEK
Description: strftime() and other timing functions do not handle days of the week.
Status: Open
Priority: Low
Title: RESETTING GETOPT()
Description: There is an issue with the way that getopt() handles errors that
return '?'.
1. Does getopt() reset its global variables after returning '?' so
that it can be re-used? That would be required to support where
the caller terminates parsing before reaching the last parameter.
2. Or is the client expected to continue parsing after getopt()
returns '?' and parse until the final parameter?
The current getopt() implementation only supports #2.
Status: Open
Priority: Low
Title: FERROR() AND CLEARERR()
Description: Not implemented: ferror() and clearerr()
Status: Open
Priority: Low
Title: CONCURRENT STREAM READ/WRITE
Description: NuttX only supports a single file pointer so reads and writes
must be from the same position. This prohibits implementation
of behavior like that required for fopen() with the "a+" mode.
According to the fopen man page:
"a+ Open for reading and appending (writing at end of file).
The file is created if it does not exist. The initial file
position for reading is at the beginning of the file, but
output is always appended to the end of the file."
At present, the single NuttX file pointer is positioned to the
end of the file for both reading and writing.
Status: Open
Priority: Medium. This kind of operation is probably not very common in
deeply embedded systems but is required by standards.
Title: DIVIDE BY ZERO
Description: This is bug 3468949 on the SourceForge website (submitted by
Philipp Klaus Krause):
"lib_strtod.c does contain divisions by zero in lines 70 and 96.
AFAIK, unlike for Java, division by zero is not a reliable way to
get infinity in C. AFAIK compilers are allowed e.g. give a compile-
time error, and some, such as sdcc, do. AFAIK, C implementations
are not even required to support infinity. In C99 the macro isinf()
could replace the first use of division by zero. Unfortunately, the
macro INFINITY from math.h probably can't replce the second division
by zero, since it will result in a compile-time diagnostic, if the
implementation does not support infinity."
Status: Open
Priority:
Title: OLD dtoa NEEDS TO BE UPDATED
Description: This implementation of dtoa in lib/stdio is old and will not
work with some newer compilers. See
http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html
Status: Open
Priority: ??
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
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: 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
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: DEPENDENCIES IN THE BOARD DIRECTORY
Description: Dependencies do not work correctly under configs/<board>/src
(same as arch/<arch>/src/board).
UPDATE: Added the following to each arch/*/src/Makefile:
PHONY: board/libboard$(LIBEXT)
However, I have not confirmed that this a full-proof fix in
all cases -- still under test (thanks to Mike Smith).
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 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.
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.
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/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).
Title: UNFINISHED DRIVERS
Description: The following drivers are incomplete: DAC. The following drivers
are untested: DMA on the F4, CAN.
Status: Open
Priority: Medium
Title: F4 SDIO MULTI-BLOCK TRANSFER FAILURES
Description: If you use a large I/O buffer to access the file system, then the
MMCSD driver will perform multiple block SD transfers. With DMA
ON, this seems to result in CRC errors detected by the hardware
during the transfer. Workaround: CONFIG_MMCSD_MULTIBLOCK_DISABLE=y.
Status: Open
Priority: Medium
Title: DMA BOUNDARY CROSSING
Description: I see this statement in the reference manual: "The burst
configuration has to be selected in order to respect the AHB protocol,
where bursts must not cross the 1 KB address boundary because the
minimum address space that can be allocated to a single slave
is 1 KB. This means that the 1 KB address boundary should not be crossed
by a burst block transfer, otherwise an AHB error would be generated,
that is not reported by the DMA registers."
The implication is that there may be some unenforced alignment
requirements for some DMAs. There is nothing in the DMA driver to
prevent this now.
Status: Open
Priority: Low (I am not even sure if this is a problem yet).
Status: Unfinished STM32 F4 OTG FS Host Driver
Description: A quick-n-dirty leverage of the the LPC17xx host driver was put into
the STM32 source to support development of the STM32 F4 OTG FS host
driver. It is non-functional and still waiting for STM32 F4 logic
to be added. Don't use it!
Status: Open
Priority: Low (unless you need a host driver).
o AVR (arch/avr)
^^^^^^^^^^^^^^
Title: AMBER WEB SERVER UNTESTED
Description: There is a port for the Amber Web Server ATMega128, however this is
completely untested due to the lack to compatible, functional test
equipment.
Status: Open
Priority: The priority might as well be low since there is nothing I can do about
it anyway.
Title: STRINGS IN RAM
Description: Many printf-intensive examples (such as the OS test) cannot be executed
on most AVR platforms. The reason is because these tests/examples
generate a lot of string data. The build system currently places all
string data in RAM and the string data can easily overflow the tiny
SRAMs on these parts. A solution would be to put the string data
into the more abundant FLASH memory, but this would require modification
to the printf logic to access the strings from program memory.
Status: Open
Priority: Low. The AVR is probably not the architecuture that you want to use
for extensive string operations.
Title: SPI AND USB DRIVERS UNTESTED
Description: An SPI driver and a USB device driver exist for the AT90USB (as well
as a USB mass storage example). However, this configuration is not
fully debugged as of the NuttX-6.5 release.
Update 7/11: (1) The SPI/SD driver has been verified, however, (2) I
believe that the current teensy/usbstorage configuration uses too
much SRAM for the system to behave sanely. A lower memory footprint
version of the mass storage driver will be required before this can
be debugged
Status: Open
Priority: Medium-High.
Title: AVR32 PORT IS NOT FULLY TESTED
Description: A complete port for the AVR32 is provided and has been partially
debugged. There may still be some issues with the serial port
driver.
Status: Open
Priority: Medium
o Intel x86 (arch/x86)
^^^^^^^^^^^^^^^^^^^^
o 8051 / MCS51 (arch/8051/)
^^^^^^^^^^^^^^^^^^^^^^^^^
Title: STACK OVERFLOWS DURING INTERRUPT HANDLING
Description: Current status:
- Basic OS task management seems OK
- Fails when interrupts enabled. The stack pointer is around
0x6e before the failure occurs. It looks like some issue
when the stack pointer moves from the directly to indirectly
addressable region (0x80 boundary).
- Work on the 8052 is temporarily on hold
Status: Open
Priority: Low, 8051 is a tough platform because of the tiny stack.
Title: TIMER 0 AS SYSTEM TIMER
Description: Use timer 0 as system timer. Timer 2 is needed for second UART.
Logic is implemented, but there needs to be a system
configuration to change the ticks-per-second value to match the
timer interrupt rate
Status: Open
Priority: Low
Title: OVERFLOWS DURING BUILD
Description: During build, there are several integer overflows reported:
sched/gmtime_r.c aroud lines 184 and 185
sched/clock_initialize.c at line 107
sched/pthread_create.c at 330
apps/examples/ostest/barrier.c around lines 53 and 74
apps/examples/ostest/sighand.c at 225 and 244
driver/serial.c in usleep calls around 347 and 354
Status: Open. Update: These were reviewed during the hcs12 port. The
hcs12 also has 16-bit integer types (if -mshort is in the CFLAGS).
I believe that the warnings in most of the above have been fixed
but this has not been verified on this platform).
Priority: Medium
Title: DATA INITIALIZATION
Description Global data is not being initialized. Logic like that of SDCCs
crt0*.s needs to be incorporated into the system boot logic
Status: Open
Priority: Low -- only because there as so many other issues with 8051
o MIPS/PIC32(arch/mips)
^^^^^^^^^^^^^^^^^^^^^
Title: PIC32 USB DRIVER DOES NOT WORK WITH MASS STORAGE CLASS
UPDATE: ** ONLY USING RAM DISK FOR EXPORTED VOLUME ***
Description: The PIC32 USB driver either crashes or hangs when used with
the mass storage class when trying to write files to the target
storage device. This usually works with debug on, but does not
work with debug OFF (implying some race condition?)
Here are some details of what I see in debugging:
1. The USB MSC device completes processing of a read request
and returns the read request to the driver.
2. Before the MSC device can even begin the wait for the next
driver, many packets come in at interrupt level. The MSC
device goes to sleep (on pthread_cond_wait) with all of the
read buffers ready (16 in my test case).
3. The pthread_cond_wait() does not wake up. This implies
a problem with pthread_con_wait(?). But in other cases,
the MSC device does wake up, but then immediately crashes
because its stack is bad.
4. If I force the pthread_cond_wait to wake up (by using
pthread_cond_timedwait instead), then the thread wakes
up and crashes with a bad stack.
So far, I have no clue why this is failing.
UPDATE: This bug was recorded using the PIC32 Ethernet
Starter kit with a RAM disk (that board has no SD card slot).
Howevever, using the USB mass storage device with the
Mikroelektronika using a real SD card, there is no such
problem -- the mass storage device is quite stable.
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
o Hitachi/Renesas SH-1 (arch/sh/src/sh1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: SH-1 IS UNUSABLE
Description: There are instabilities that make the SH-1 port un-usable. The
nature of these is not understood; the behavior is that certain SH-1
instructions stop working as advertised. I have seen the following
examples:
412b jmp @r1 - Set a return address in PR, i.e., it behaved like
410b jsr @r1. Normally 412b works correctly, but in the failure
condition, it reliably set the PR.
69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+. This behavior
does not correspond to any known SH-1 instruction
This could be a silicon problem, some pipeline issue that is not
handled properly by the gcc 3.4.5 toolchain (which has very limit
SH-1 support to begin with), or perhaps with the CMON debugger. At
any rate, I have exhausted all of the energy that I am willing to put
into this cool old processor for the time being.
Update: This bug will probably never be addressed now. I just
cleaned house and my old SH-1 was one of the things that went.
Status: Open
Priority: Low -- because the SH-1, SH7032, is very old and only of historical
interest.
o Renesas M16C/26 (arch/sh/src/m16c)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: M16C DOES NOT BUILD
Description: The M16C target cannot be built. The GNU m16c-elf-ld link fails with
the following message:
m32c-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482
Where the reference line is:
/* If the symbol is out of range for a 16-bit address,
we must have allocated a plt entry. */
BFD_ASSERT (*plt_offset != (bfd_vma) -1);
No workaround is known at this time.
Status: Open
Priority: High -- this is a show stopper for M16C.
Title: M16C PORT UNTESTED
Description: Coding of the initial port is complete, but is untested.
Status: Open
Priority: Low
Title: NO SERIAL CONNECTOR
Description: Serial drivers were developed for the M16C, however, the SKP16C26
StarterKit has no serial connectors.
Status: Open
Priority: Low
Title: UNIMPLEMENTED M16C DRIVERS
Description: Should implement SPI, I2C, Virual EEPROM, FLASH, RTC drivers
Status: Open
Priority: Medium
o z80/z8/ez80 (arch/z80)
^^^^^^^^^^^^^^^^^^^^^^^
Title: SDCC INTEGER OVERFLOWS
Description: The SDCC version the same problems with integer overflow during
compilation as described for pjrc-8051. At typical cause is code like
usleep(500*1000) which exceeds the range of a 16-bit integer.
Status: See pjrc-8051. These have probably been fixed but have not yet
been verified on these platforms.
Priority: See pjrc-8051
Title: Z80 SIMULATED CONSOLE
Description: The simulated Z80 serial console (configs/z80sim/src/z80_serial.c +
driver/serial.c) does not work. This is because there are
no interrupts in the simulation so there is never any serial
traffic.
Status: Open
Priority: Low -- the simulated console is not critical path and the designs
to solve the problem are complex.
Title: ZDS-II LIBRARIAN WARNINGS
Description: ZDS-II Librarian complains that the source for the .obj file
is not in the library.
Status: Open
Priority: Low, thought to be cosmetic. I think this is a consequence of
replacing vs. inserting the library.
Title: ZDS-II COMPILER PROBLEMS
Description: The ZDS-II compiler (version 4.10.1) fails with an internal error
while compiler mm/mm_initialize. This has been reported as
incident 81509.
I have found the following workaround that I use to build for the
time being:
--- mm/mm_initialize.c.SAVE 2008-02-13 08:06:46.833857700 -0600
+++ mm/mm_initialize.c 2008-02-13 08:07:26.367608900 -0600
@@ -94,8 +94,11 @@
{
int i;
+#if 0 /* DO NOT CHECK IN */
CHECK_ALLOCNODE_SIZE;
CHECK_FREENODE_SIZE;
+#endif
/* Set up global variables */
Status: Open
Priority: High
Title: EZ8 PRIORITY INTERRUPTS
Description: Add support for prioritized ez8 interrupts. Currently logic supports
only nominal interrupt priority.
Status: Open
Priority: Low
Title: Z8ENCORE ONLY VERIFIED ON SIMULATOR
Description: The z8Encore! port has only been verified on the ZDS-II instruction
set simulator.
Status: Open
Priority: Medium
Title: XTRS CLEAN
Description: The XTRS target (configs/xtrs) has a clean problem. The clean
rule removes .asm files. This works because there are no .asm
files except in sub-directories that are provided from 'make clean' --
except for XTRS: It has a .asm file in its src/ directory that
gets removed everytime clean is performd.
Status: Open
Priority: High if you happen to be working with XTRS.
Title: SPI/I2C UNTESTED
Description: A "generic" SPI and I2C drivers have been coded for the eZ80Acclaim!
However, these remains untested since I have no SPI or I2C devices for
the board (yet).
Status: Open
Priority: Med
Title: SPI METHODS ARE NOT THREAD SAFE
Description: SPI methods are not thread safe. Needs a semaphore to protect from re-entrancy.
Status: Open
Priority: Medium -- Will be very high if you do SPI access from multiple threads.
Title: I2C UNTESTED
Description: A "generic" I2C driver has been coded for the eZ8Encore!
However, this remains untested since I have no I2C devices for
the board (yet).
Status: Open
Priority: Med
o z16 (arch/z16)
^^^^^^^^^^^^^^^^
Title: ZDS-II LIBRARIAN WARNINGS
Description: ZDS-II Librarian complains that the source for the .obj file
is not in the library.
Status: Open
Priority: Low, thought to be cosmetic. I think this is a consequence of
replacing vs. inserting the library.
Title: SERIAL DRIVER HANGS
Description: When the interrupt-driven serial driver is used, the system
hangs. This is because of TX ready (TRDE) interrupts that
get lost while interrupts are disabled. The existing
serial driver appears to be limited to hardware with a
latching, level-sensitive TX ready interrupt.
Status: Open
Priority: Medium. A polled, write-only serial driver is used in the
interim for system testing.
Title: SYSTEM DELAYS
Description: The system delays do not appear to be correct with the
apps/examples/ostest/timedmqueue.c test.
Status: Open
Priority: Medium-High
Title: PROBLEMS WHEN DEBUG DISABLED
Description: At present, the z16f port does not run properly when CONFIG_DEBUG
is disabled: The obvious symptom is that there is no printf()
output. I have isolated with problem to errors in optimization.
With -reduceopt on the command line, I can get the printf output.
However, there are still errors in the compiled code -- specifically
in sched/timer_create.c.
I have submitted a bug report to ZiLOG for this (support incident
81400). You can see the status of the bug report (and lots more
technical detail) here:
http://support.zilog.com/support/incident/incident_support.asp?iIncidentId=81400&iSiteId=1&chLanguageCode=ENG
Summary of ZiLOG analysis: "This is a ZNEO compiler problem. ... [a] workaround
is to replace:
if ( !timerid || (clockid != 0) )
By:
if ((clockid != 0) || !timerid)"
Status: Open
Priority: Medium-High
Title: PASCAL ADD-ON
Description: The pascal add-on does not work with the z16f (that is
configuration z16f2800100zcog/pashello). This appears to be
another ZDS-II error: when executing the instruction
SYSIO 0, WRITESTR a large case statement is executed. This
involves a call into the ZiLOG runtime library to __uwcase().
__uwcase is passed a pointer to a structure containing jump
information. The cause of the failure appears to be that
the referenced switch data is bad.
This is submited as ZiLOG support incident 81459.
Summary of ZiLOG analysis: "This is a ZNEO run time library problem.
One workaround is to replace the line 58 in uwcase.asm
From:
ADD R9,#4 ; Skip handler
To:
ADD R9,#2 ; Skip handler
And add uwcase.asm to the project.
If the customer does not want to modify uwcase.asm then the other
workaround is to add a dummy case and make it same as default:
case 0x8000:
default:
This will make sure that uwcase is not called but ulcase is called."
Status: Open. Due to licensing issues, I cannot include the modified
uwcase in the NuttX code base.
Priority: Medium
Title: USE SPOV
Description: Add support to maintain SPOV in context switching. This
improvement will provide protection against stack overflow
and make a safer system solution.
Status: Open
Priority: Low
Title: PRIORITIZED INTERRUPTS
Description: Add support for prioritized interrupts. Currently logic supports
only nominal interrupt priority.
Status: Open
Priority: Low
Title: ZDS-II COMPILER PROBLEMS
Description: The file drivers/mmcsd/mmcsd_sdio.c generates an internal compiler
error like:
mmcsd\mmcsd_sdio.c
Internal Error(0503) On line 2504 of "MMCSD\MMCSD_SDIO.C"
File <c3>, Args(562,46)
Status: Open. Recommended workaround: remove mmcsd_sdio.c from
drivers/mmcsd/Make.defs. There is no SDIO support for the Z16 anyway
Priority: Low
o mc68hc1x (arch/hc)
^^^^^^^^^^^^^^^^^^
Title: BANKED MODE
Description: There is no script for building in banked mode (more correctly, there
is a script, but logic inside the script has not yet been implemented).
It would be necessary to implement banked mode to able to access more
the 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: WGET UNTESTED
Description: The wget command has been incorporated into NSH, however
it is still untested as of this writing (only because I
have not had the correct network setup for the testing
yet). Since wget depends on the also untest uIP resolv/
logic, it is like non-functional.
Status: Open
Priority: Med-High
Title: IFCONFIG AND MULTIPLE NETWORK INTERFACES
Descripton: The ifconfig command will not behave correctly if an interface
is provided and there are multiple interfaces. It should only
show status for the single interface on the command line; it will
still show status for all interfaces.
Status: Open
Priority: Low (multiple network interfaces not fully supported yet anyway).
Title: RUN NXFLAT PROGRAMS
Description: Add support to NSH to run NXFLAT programs from a ROMFS file system
Status: Open
Priority: Low (enhancement)
Title: ARP COMMAND
Description: Add an ARP command so that we can see the contents of the ARP table.
Status: Open
Priority: Low (enhancement)
o System libraries apps/system (apps/system)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: READLINE IMPLEMENTATION
Description: readline implementation does not use C-buffered I/O, but rather
talks to serial driver directly via read(). It includes VT-100
specific editting commands. A more generic readline() should be
implemented.
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.
Reference in New Issue View Git Blame Copy Permalink