diff --git a/TODO b/TODO index 1da1af67390..f6185cbf892 100644 --- a/TODO +++ b/TODO @@ -2,9 +2,10 @@ NuttX TODO List (Last updated May 3, 2015) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This file summarizes known NuttX bugs, limitations, inconsistencies with -standards, things that could be improved, and ideas for enhancements. See -also individual README.txt files in the configs/ sub-directories for each -board port. +standards, things that could be improved, and ideas for enhancements. This +TODO list does not include issues associated with individual boar ports. See +altheso individual README.txt files in the configs/ sub-directories for +issues reated to each board port. nuttx/ @@ -16,7 +17,7 @@ nuttx/ (4) C++ Support (6) Binary loaders (binfmt/) (12) Network (net/, drivers/net) - (3) USB (drivers/usbdev, drivers/usbhost) + (4) USB (drivers/usbdev, drivers/usbhost) (12) Libraries (libc/, libm/) (11) File system/Generic drivers (fs/, drivers/) (8) Graphics subsystem (graphics/) @@ -24,26 +25,6 @@ nuttx/ (2) Build system / Toolchains (3) Linux/Cywgin simulation (arch/sim) (5) ARM (arch/arm/) - (1) ARM/C5471 (arch/arm/src/c5471/) - (3) ARM/DM320 (arch/arm/src/dm320/) - (2) ARM/i.MX (arch/arm/src/imx/) - (3) ARM/LPC17xx (arch/arm/src/lpc17xx/) - (7) ARM/LPC214x (arch/arm/src/lpc214x/) - (2) ARM/LPC313x (arch/arm/src/lpc313x/) - (0) ARM/LPC43x (arch/arm/src/lpc43xx/) - (2) ARM/STR71x (arch/arm/src/str71x/) - (2) ARM/LM3S6918 (arch/arm/src/tiva/) - (x) ARM/SAMA5D3/4 ((arch/arm/src/sama5/) - (x) ARM/SAMV7 ((arch/arm/src/samv7/) - (5) ARM/STM32 (arch/arm/src/stm32/) - (3) AVR (arch/avr) - (0) Intel x86 (arch/x86) - (3) MIPS/PIC32 (arch/mips) - (1) Hitachi/Renesas SH-1 (arch/sh/src/sh1) - (4) Renesas M16C/26 (arch/sh/src/m16c) - (11) z80/z8/ez80/z180 (arch/z80/) - (9) z16 (arch/z16/) - (1) mc68hc1x (arch/hc) apps/ @@ -1090,6 +1071,31 @@ o USB (drivers/usbdev, drivers/usbhost) CDC/ACM serial driver might need the line coding data (that data is not used currently, but it might be). + Title: IMPROVED USAGE of STM32 USB RESOURCES + Description: The STM32 platforms use a non-standard, USB host peripheral + that uses "channels" to implement data transfers the current + logic associates each channel with an pipe/endpoint (with two + channels for bi-directional control endpoints). The OTGFS + peripheral has 8 channels and the OTGHS peripheral has 12 + channels. + + This works okay until you add a hub and try connect multiple + devices. A typical device will require 3-4 pipe and, hence, + 4-5 channels. This effectively prevents using a hub with the + STM32 devices. This also applies to the EFM32 which uses the + same IP. + + It should be possible to redesign the STM32 F4 OTGHS/OTGFS and + EFM32 host driver so that channels are dynamically assigned to + pipes as needed for individual transfers. Then you could have + more "apparent" pipes and make better use of channels. + Although there are only 8 or 12 channels, transfers are not + active all of the time on all channels so it ought to be + possible to have an unlimited number of "pipes" but with no + more than 8 or 12 active transfers. + Status: Open + Priority: Medium-Low + o Libraries (libc/) ^^^^^^^^^^^^^^^^^ @@ -1670,705 +1676,6 @@ o ARM (arch/arm/) Status: Open Priority: Low-ish, but a good opportunity for performance improvement. -o ARM/C5471 (arch/arm/src/c5471/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: UART RECONFIGURATION - Description: UART re-configuration is untested and conditionally compiled out. - Status: Open - Priority: Medium. ttyS1 is not configured, but not used; ttyS0 is configured - by the bootloader - -o ARM/DM320 (arch/arm/src/dm320/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: DEBUG ISSUES - Description: config/ntos-dm320: It seems that when a lot of debug statements - are added, the system no longer boots. This is suspected to be - a stack problem: Making the stack bigger or removing arrays on - the stack seems to fix the problem (might also be the - bootloader overwriting memory) - Status: Open - Priority: Medium - - Title: USB DEVICE DRIVER UNTESTED - Description: A USB device controller driver was added but has never been tested. - Status: Open - Priority: Medium - - Title: FRAMEBUFFER DRIVER UNTESTED - Description: A framebuffer "driver" was added, however, it remains untested. - Status: Open - Priority: Medium - - Title: VIDEO ENCODER DRIVER - Description: In order to use the framebuffer "driver" additional video encoder - logic is required to setup composite video output or to interface - with an LCD. - Status: Open - Priority: Medium (high if you need to use the framebuffer driver) - -o ARM/i.MX (arch/arm/src/imx/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: PORT IS INCOMPLETE - Description: The basic port of the i.MX1 architecture was never finished. The port - is incomplete (as of this writing, is still lacks a timer, interrupt - decoding, USB, network) and untested. - Status: Open - Priority: Medium (high if you need i.MX1/L support) - - Title: SPI METHODS ARE NOT THREAD SAFE - Description: SPI methods are not thread safe. Needs a semaphore to protect from re-entrancy. - Status: Open - Priority: Medium -- Will be very high if you do SPI access from multiple threads. - -o ARM/LPC17xx (arch/arm/src/lpc17xx/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: USB DMA INCOMPLETE - Description: USB DMA not fully implemented. Partial logic is in place but it is - fragmentary and bogus. (Leveraged from the lpc214x) - Status: Open - Priority: Low - - Title: SSP DRIVER IMPROVEMENTS - Description: a) At present the SSP driver is polled. Should it be interrupt driven? - Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an - interrupt driven SPI driver. Should be very easy to part that architecture - to the LPC. - b) See other SSP (SPI) driver issues listed under ARM/LPC214x. The LPC17xx - driver is a port of the LPC214x driver and probably has the same issues. - b) Other SSP driver improvements: Add support for multiple devices on the - SSP bus, use DMA data transfers - Status: Open - Priority: Medium - - Title: NOKIA LCD DRIVER NONFUNCTIONAL - Description: An LCD driver for the Olimex LPC1766STK has been developed. However, that - driver is not yet functional on the board: The backlight comes on, but - nothing is visible on the display. - Status: Open - Priority: Medium-Low (unless you need the display on the LPC1766STK!) - -o ARM/LPC214x (arch/arm/src/lpc214x/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: VECTOR INTERRUPTS - Description: Should use Vector Interrupts - Status: Open - Priority: Low - - Title: USB DMA INCOMPLETE - Description: USB DMA not fully implemented. Partial logic is in place but it is - fragmentary and bogus. - Status: Open - Priority: Low - - Title: USB SERIAL DRIVER REPORTS WRONG ERROR - Description: USB Serial Driver reports wrong error when opened before the - USB is connected (reports EBADF instead of ENOTCONN) - Status: Open - Priority: Low - - Title: SPI DRIVER IMPROVEMENTS - Description: At present the SPI driver is polled. Should it be interrupt driven? - Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an - interrupt driven SPI driver. Should be very easy to part that architecture - to the LPC. - Status: Open - Priority: Medium - - Title: SPI METHODS ARE NOT THREAD SAFE - Description: SPI methods are not thread safe. Needs a semaphore to protect from re-entrancy. - Status: Open - Priority: Medium -- Will be very high if you do SPI access from multiple threads. - - Title: SPI DRIVER DELAYS - Description: At present the SPI driver is polled -AND- there is a rather large, arbitrary, - delay in one of the block access routines. The purpose of the delay is to - avoid a race conditions. This begs for a re-design -OR- at a minimum, some - optimization of the delay time. - Status: Open - Priority: Medium - - Title: 2GB SD CARD ISSUES - Desription: I am unable to initialize a 2Gb SanDisk microSD card (in adaptor) on the - the mcu123 board. The card fails to accept CMD0. Doesn't seem like a software - issue, but if anyone else sees the problem, I'd like to know. - Related: Fixes were recently made for the SDIO-based MMC/SD driver to - support 2Gb cards -- the block size was forced to 512 in all cases. The SPI- - based driver may also have this problem (but I don't think this would have - anything to do with CMD0). - Status: Open - Priority: Uncertain - - Title: USB BROKEN? - Description: I tried to bring up the new configuration at configs/mcu123-214x/composite, - and Linux failed to enumerate the device. I don't know if this is - a problem with the lpc214x USB driver (bit rot), or due to recent - changed (e.g., -r4359 is suspicious), or an incompatibility between the - Composite driver and the LPC214x USB driver. It will take more work - to find out which -- like checking if the other USB configurations are - also broken. - Status: Open - Priority: It would be high if the LPC2148 were a current, main stream architecture. - I am not aware of anyone using LPC2148 now so I think the priority has - to be low. - -o ARM/LPC31xx (arch/arm/src/lpc31xx/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: PLATFORM-SPECIFIC LOGIC - Description: arch/arm/src/lpc313x/lpc313x_spi.c contains logic that is specific to the - Embedded Artist's ea3131 board. We need to abstract the assignment of SPI - chip selects and logic SPI functions (like SPIDEV_FLASH). My thoughts are: - - Remove lpc313x_spiselect and lpc313x_spistatus from lpc313x_internal.h - - Remove configs/ea3131/src/up_spi.c - - Add configurations CONFIG_LPC3131x_CSOUT1DEV, CONFIG_LPC3131x_CSOUT2DEV, - and CONFIG_LPC3131x_CSOUT3DEV that maps the lpc313x SPI chip selects to - SPIDEV_* values. - - Change arch/arm/src/lpc313x/lpc313x_spi.c to use those configuration - settings. - Status: Open - Priority: High if you want to use SPI on any board other than the ea3131. - - Title: SPI DRIVER - Description: arch/arm/src/lpc313x/lpc313x_spi.c may or may not be functional. It was - reported to be working, but I was unable to get it working with the - Atmel at45dbxx serial FLASH driver. - Status: Open - Priority: High if you need to use SPI. - -o ARM/LPC43x (arch/arm/src/lpc43xx/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - See comments in configs/lpc4330-xplorer/README.txt - -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: 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/tiva/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - 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 software bug. - Priority: Probably Low - -o ARM/SAMA5D3 ((arch/arm/src/sama5/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Issues related to the SAMA5D3 port are in configs/sama5d3x-ek/README.txt. - Issues related to the SAMA5D4 port are in configs/sama5d4-ek/README.txt. - -o ARM/SAMV7 ((arch/arm/src/samv7/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Issues related to the SAMA5D3 port are in configs/samv71-xult/README.txt. - -o ARM/STM32 (arch/arm/src/stm32/) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: USBSERIAL ISSUES - Description A USB device-side driver is in place but not well tested. At - present, the apps/examples/usbserial test sometimes fails. The situation - that causes the failure is: - - - Host-side of the test started after the target side sends the - first serial message. - - The general failure is as follows: - - - The target message pends in the endpoint packet memory - - When the host-side of the test is stated, it correctly - reads this pending data. - - an EP correct transfer interrupt occurs and the next - pending outgoing message is setup - - But, the host never receives the next message - - If the host-side driver is started before the first target message - is sent, the driver works fine. - Status: Open - Priority: Medium-High - - Title: DMA EXTENSIONS F1/3 - Description: DMA logic needs to be extended. DMA2, Channel 5, will not work - because the DMA2 channels 4 & 5 share the same interrupt. - Status: Open - Priority: Low until someone needs DMA1, Channel 5 (ADC3, UART4_TX, TIM5_CH1, or - TIM8_CH2). - - Title: F4 SDIO MULTI-BLOCK TRANSFER FAILURES - Description: If you use a large I/O buffer to access the file system, then the - MMCSD driver will perform multiple block SD transfers. With DMA - ON, this seems to result in CRC errors detected by the hardware - during the transfer. Workaround: CONFIG_MMCSD_MULTIBLOCK_DISABLE=y. - Status: Open - Priority: Medium - - Title: DMA BOUNDARY CROSSING - Description: I see this statement in the reference manual: "The burst - configuration has to be selected in order to respect the AHB protocol, - where bursts must not cross the 1 KB address boundary because the - minimum address space that can be allocated to a single slave - is 1 KB. This means that the 1 KB address boundary should not be crossed - by a burst block transfer, otherwise an AHB error would be generated, - that is not reported by the DMA registers." - - The implication is that there may be some unenforced alignment - requirements for some DMAs. There is nothing in the DMA driver to - prevent this now. - Status: Open - Priority: Low (I am not even sure if this is a problem yet). - - Title: DMA FROM EXTERNAL, FSMC MEMORY - Description: I have seen a problem on F1 where all SDIO DMAs work exist for - write DMAs from FSMC memory (i.e., from FSMC memory to SDIO). - Read transfers work fine (SDIO to FSMC memory). The failure is - a data underrun error with zero bytes of data transferred. The - workaround for now is to use DMA buffers allocated from internal - SRAM. - Status: Open - Priority: Low - -o AVR (arch/avr) - ^^^^^^^^^^^^^^ - - Title: AMBER WEB SERVER UNTESTED - Description: There is a port for the Amber Web Server ATMega128, however this is - completely untested due to the lack to compatible, functional test - equipment. - Status: Open - Priority: The priority might as well be low since there is nothing I can do about - it anyway. - - Title: STRINGS IN RAM - Description: Many printf-intensive examples (such as the OS test) cannot be executed - on most AVR platforms. The reason is because these tests/examples - generate a lot of string data. The build system currently places all - string data in RAM and the string data can easily overflow the tiny - SRAMs on these parts. A solution would be to put the string data - into the more abundant FLASH memory, but this would require modification - to the printf logic to access the strings from program memory. - Status: Open - Priority: Low. The AVR is probably not the architecture that you want to use - for extensive string operations. - - Title: SPI AND USB DRIVERS UNTESTED - Description: An SPI driver and a USB device driver exist for the AT90USB (as well - as a USB mass storage example). However, this configuration is not - fully debugged as of the NuttX-6.5 release. - Update 7/11: (1) The SPI/SD driver has been verified, however, (2) I - believe that the current teensy/usbmsc configuration uses too - much SRAM for the system to behave sanely. A lower memory footprint - version of the mass storage driver will be required before this can - be debugged - Status: Open - Priority: Medium-High. - - Title: AVR32 PORT IS NOT FULLY TESTED - Description: A complete port for the AVR32 is provided and has been partially - debugged. There may still be some issues with the serial port - driver. - Status: Open - Priority: Medium - -o Intel x86 (arch/x86) - ^^^^^^^^^^^^^^^^^^^^ - -o MIPS/PIC32(arch/mips) - ^^^^^^^^^^^^^^^^^^^^^ - - Title: PIC32 USB DRIVER DOES NOT WORK WITH MASS STORAGE CLASS - UPDATE: ** ONLY USING RAM DISK FOR EXPORTED VOLUME *** - Description: The PIC32 USB driver either crashes or hangs when used with - the mass storage class when trying to write files to the target - storage device. This usually works with debug on, but does not - work with debug OFF (implying some race condition?) - - Here are some details of what I see in debugging: - - 1. The USB MSC device completes processing of a read request - and returns the read request to the driver. - 2. Before the MSC device can even begin the wait for the next - driver, many packets come in at interrupt level. The MSC - device goes to sleep (on pthread_cond_wait) with all of the - read buffers ready (16 in my test case). - 3. The pthread_cond_wait() does not wake up. This implies - a problem with pthread_con_wait(?). But in other cases, - the MSC device does wake up, but then immediately crashes - because its stack is bad. - 4. If I force the pthread_cond_wait to wake up (by using - pthread_cond_timedwait instead), then the thread wakes - up and crashes with a bad stack. - - So far, I have no clue why this is failing. - - UPDATE: This bug was recorded using the PIC32 Ethernet - Starter kit with a RAM disk (that board has no SD card slot). - However, using the USB mass storage device with the - Mikroelektronika using a real SD card, there is no such - problem -- the mass storage device seems quite stable. - - UPDATE: Hmmm.. retesting with the Mikroelektronika board - shows problems again. I think that there are some subtle - timing bugs whose effects can very from innocuous to severe. - Status: Open - Priority: Originally, High BUT reduced to very Low based on the - UPDATED comments. - - Title: PIC32 USB MASS STORAGE DEVICE FAILS TO RE-CONNECT - Description: Found using configuration configs/pic32mx7mmb/nsh. - In this configuration, the NSH 'msconn' command will connect the - mass storage device to the host; the 'msdis' command will - disconnect the device. The first 'msconn' works perfectly. - However, when attempting to re-connect, the second 'msconn' - command does not command properly: Windows reports an - unrecognized device. Apparently, some state is being properly - reset when the mass storage device is disconnected. Shouldn't - be hard to fix. - Status: Open - Priority: Medium - - Title: POSSIBLE INTERRUPT CONTROL ISSUE - Description: There is a kludge in the file arch/mips/src/common/up_idle.c. - Basically, if there is nothing else going on in the IDLE loop, - you have to disable then re-enable interrupts. Logically nothing - changes, but if you don't do this interrupts will be be disabled - in the IDLE loop which is a very bad thing to happen. - - Some odd behavior in the interrupt setup on the IDLE loop is - not really a big concern, but what I do not understand is if - this behavior is occurring on all threads after all context - switches: Are interrupts always disabled until re-enabled? - This requires some further investigation at some point; it - may be nothing but may also be a symptom of some changes - required to the interrupt return logic (perhaps some CP0 - status hazard?) - Status: Open - Priority: Low. Puzzling and needs some investigation, but there there - is no known misbehavior. - -o Hitachi/Renesas SH-1 (arch/sh/src/sh1) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: SH-1 IS UNUSABLE - Description: There are instabilities that make the SH-1 port un-usable. The - nature of these is not understood; the behavior is that certain SH-1 - instructions stop working as advertised. I have seen the following - examples: - - 412b jmp @r1 - Set a return address in PR, i.e., it behaved like - 410b jsr @r1. Normally 412b works correctly, but in the failure - condition, it reliably set the PR. - 69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+. This behavior - does not correspond to any known SH-1 instruction - - This could be a silicon problem, some pipeline issue that is not - handled properly by the gcc 3.4.5 toolchain (which has very limit - SH-1 support to begin with), or perhaps with the CMON debugger. At - any rate, I have exhausted all of the energy that I am willing to put - into this cool old processor for the time being. - - Update: This bug will probably never be addressed now. I just - cleaned house and my old SH-1 was one of the things that went. - - Status: Open - Priority: Low -- because the SH-1, SH7032, is very old and only of historical - interest. - -o Renesas M16C/26 (arch/sh/src/m16c) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: M16C DOES NOT BUILD - Description: The M16C target cannot be built. The GNU m16c-elf-ld link fails with - the following message: - - m32c-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482 - - Where the reference line is: - - /* If the symbol is out of range for a 16-bit address, - we must have allocated a plt entry. */ - BFD_ASSERT (*plt_offset != (bfd_vma) -1); - - No workaround is known at this time. - Status: Open - Priority: High -- this is a show stopper for M16C. - - Title: M16C PORT UNTESTED - Description: Coding of the initial port is complete, but is untested. - Status: Open - Priority: Low - - Title: NO SERIAL CONNECTOR - Description: Serial drivers were developed for the M16C, however, the SKP16C26 - StarterKit has no serial connectors. - Status: Open - Priority: Low - - Title: UNIMPLEMENTED M16C DRIVERS - Description: Should implement SPI, I2C, Virtual EEPROM, FLASH, RTC drivers - Status: Open - Priority: Medium - -o z80/z8/ez80/z180 (arch/z80) - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Title: SDCC INTEGER OVERFLOWS - Description: The SDCC version the same problems with integer overflow during - compilation for certain 8-bit platform. At typical cause is code like - usleep(500*1000) which exceeds the range of a 16-bit integer. - Status: These have probably been fixed but have not yet been verified on these - affected platforms. - Priority: Low for now - - Title: Z80 SIMULATED CONSOLE - Description: The simulated Z80 serial console (configs/z80sim/src/z80_serial.c + - driver/serial.c) does not work. This is because there are - no interrupts in the simulation so there is never any serial - traffic. - Status: Open - Priority: Low -- the simulated console is not critical path and the designs - to solve the problem are complex. - - Title: ZDS-II LIBRARIAN WARNINGS - Description: ZDS-II Librarian complains that the source for the .obj file - is not in the library. - Status: Open - Priority: Low, thought to be cosmetic. I think this is a consequence of - replacing vs. inserting the library. - - Title: ZDS-II COMPILER PROBLEMS - Description: The ZDS-II compiler (version 4.10.1) fails with an internal error - while compiling mm/mm_initialize.c. This has been reported as - incident 81509. - - I have found the following workaround that I use to build for the - time being: - - --- mm/mm_initialize.c.SAVE 2008-02-13 08:06:46.833857700 -0600 - +++ mm/mm_initialize.c 2008-02-13 08:07:26.367608900 -0600 - @@ -94,8 +94,11 @@ - { - int i; - - +#if 0 /* DO NOT CHECK IN */ - CHECK_ALLOCNODE_SIZE; - CHECK_FREENODE_SIZE; - +#endif - - /* Set up global variables */ - - Status: Open - Priority: High - - Title: EZ8 PRIORITY INTERRUPTS - Description: Add support for prioritized ez8 interrupts. Currently logic supports - only nominal interrupt priority. - Status: Open - Priority: Low - - Title: Z8ENCORE ONLY VERIFIED ON SIMULATOR - Description: The z8Encore! port has only been verified on the ZDS-II instruction - set simulator. - Status: Open - Priority: Medium - - Title: XTRS CLEAN - Description: The XTRS target (configs/xtrs) has a clean problem. The clean - rule removes .asm files. This works because there are no .asm - files except in sub-directories that are provided from 'make clean' -- - except for XTRS: It has a .asm file in its src/ directory that - gets removed every time clean is performed. - Status: Open - Priority: High if you happen to be working with XTRS. - - Title: SPI/I2C UNTESTED - Description: A "generic" SPI and I2C drivers have been coded for the eZ80Acclaim! - However, these remains untested since I have no SPI or I2C devices for - the board (yet). - Status: Open - Priority: Med - - Title: SPI METHODS ARE NOT THREAD SAFE - Description: SPI methods are not thread safe. Needs a semaphore to protect from re-entrancy. - Status: Open - Priority: Medium -- Will be very high if you do SPI access from multiple threads. - - Title: I2C UNTESTED - Description: A "generic" I2C driver has been coded for the eZ8Encore! - However, this remains untested since I have no I2C devices for - the board (yet). - Status: Open - Priority: Med - - Title: UNFINISHED Z180 LOGIC NEEDED BY THE P112 BOARD - Description: 1) Need to revisit the start-up logic. Looking at the P112 Bios - (Bios.mcd), I see that quite of bit of register setup is done - there. - 2) Finish ESCC driver logic. - Status: Open - Priority: Low (at least until I get P112 hardware) - -o z16 (arch/z16) -^^^^^^^^^^^^^^^^ - - Title: ZDS-II LIBRARIAN WARNINGS - Description: ZDS-II Librarian complains that the source for the .obj file - is not in the library. - Status: Open - Priority: Low, thought to be cosmetic. I think this is a consequence of - replacing vs. inserting the library. - - Title: SYSTEM DELAYS - Description: The system delays do not appear to be correct with the - apps/examples/ostest/timedmqueue.c test. - Status: Open - Priority: Medium-High - - Title: PROBLEMS WHEN DEBUG DISABLED - Description: At present, the z16f port does not run properly when CONFIG_DEBUG - is disabled: The obvious symptom is that there is no printf() - output. I have isolated with problem to errors in optimization. - With -reduceopt on the command line, I can get the printf output. - However, there are still errors in the compiled code -- specifically - in sched/timer_create.c. - - I have submitted a bug report to ZiLOG for this (support incident - 81400). You can see the status of the bug report (and lots more - technical detail) here: - http://support.zilog.com/support/incident/incident_support.asp?iIncidentId=81400&iSiteId=1&chLanguageCode=ENG - - Summary of ZiLOG analysis: "This is a ZNEO compiler problem. ... [a] workaround - is to replace: - if ( !timerid || (clockid != 0) ) - By: - if ((clockid != 0) || !timerid)" - - Status: Open - Priority: Medium-High - - Title: PASCAL ADD-ON - Description: The pascal add-on does not work with the z16f (that is - configuration z16f2800100zcog/pashello). This appears to be - another ZDS-II error: when executing the instruction - SYSIO 0, WRITESTR a large case statement is executed. This - involves a call into the ZiLOG runtime library to __uwcase(). - __uwcase is passed a pointer to a structure containing jump - information. The cause of the failure appears to be that - the referenced switch data is bad. - This is submitted as ZiLOG support incident 81459. - - Summary of ZiLOG analysis: "This is a ZNEO run time library problem. - One workaround is to replace the line 58 in uwcase.asm - - From: - ADD R9,#4 ; Skip handler - To: - ADD R9,#2 ; Skip handler - - And add uwcase.asm to the project. - - If the customer does not want to modify uwcase.asm then the other - workaround is to add a dummy case and make it same as default: - - case 0x8000: - default: - - This will make sure that uwcase is not called but ulcase is called." - Status: Open. Due to licensing issues, I cannot include the modified - uwcase in the NuttX code base. - Priority: Medium - - Title: USE SPOV - Description: Add support to maintain SPOV in context switching. This - improvement will provide protection against stack overflow - and make a safer system solution. - Status: Open - Priority: Low - - Title: PRIORITIZED INTERRUPTS - Description: Add support for prioritized interrupts. Currently logic supports - only nominal interrupt priority. - Status: Open - Priority: Low - - Title: ZDS-II COMPILER PROBLEMS - Description: The file drivers/mmcsd/mmcsd_sdio.c generates an internal compiler - error like: - - mmcsd\mmcsd_sdio.c - Internal Error(0503) On line 2504 of "MMCSD\MMCSD_SDIO.C" - File , Args(562,46) - - Status: Open. Recommended workaround: remove mmcsd_sdio.c from - drivers/mmcsd/Make.defs. There is no SDIO support for the Z16 anyway - Priority: Low - - Title: NATIVE BUILD PROBLEMS - Description: When last tested (ca.12/12), there were some missing .obj files in - arch/z16/src. A little additional TLC will be needed to get a - reliable Windows native build. - Status: Open - Priority: Low -- I don't think anyone uses the Z16 port with the native build. - - Title: COMPILER BUG - Description: There is a bug in the ZDS II 5.0.1 compiler. It generates incorrect - code when calling through a function pointer if (1) the function - pointer is a field in a structure, and (2) the function pointer has - a variable number of arguments. - - The exact name of the bug is this: Normally, when a function is - called, parameters are passed in registers. When calling a - function with a variable number of arguments, parameters must - instead be passed on the stack. In this failure case3, parameters - are erroneously passed in registers while the receive function - expects the parameters on the stack. This usually results in a - crash. - - Unfortunately, NSH does have this exact kind of function call and - because of this compiler bug, NSH cannot be used with the ZNEO - Status: The bug has been reported to ZiLOG and they have reproduced the - problem. There is, however, no schedule for correction of the bug. - Priority: High if you are using ZNEO - -o mc68hc1x (arch/hc) - ^^^^^^^^^^^^^^^^^^ - - Title: BANKED MODE - Description: There is no script for building in banked mode (more correctly, there - is a script, but logic inside the script has not yet been implemented). - It would be necessary to implement banked mode to able to access more - the 48K of FLASH. - Status: Open. - Priority: Medium/Low - o Network Utilities (apps/netutils/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/configs/c5471evm/README.txt b/configs/c5471evm/README.txt index 17407338292..3f8f9a4bf22 100644 --- a/configs/c5471evm/README.txt +++ b/configs/c5471evm/README.txt @@ -31,6 +31,15 @@ Toolchain 8. Edit setenv.h so that the PATH variable includes the path to the newly built binaries. +Issues +^^^^^^ + + 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 + ARM/C5471-specific Configuration Options ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/configs/mx1ads/README.txt b/configs/mx1ads/README.txt index 6c09df70f1b..e7068c60f89 100644 --- a/configs/mx1ads/README.txt +++ b/configs/mx1ads/README.txt @@ -31,6 +31,22 @@ Toolchain 8. Edit setenv.h so that the PATH variable includes the path to the newly built binaries. +Issues +^^^^^^ + + Title: PORT IS INCOMPLETE + Description: The basic port of the i.MX1 architecture was never finished. The port + is incomplete (as of this writing, is still lacks a timer, interrupt + decoding, USB, network) and untested. + Status: Open + Priority: Medium (high if you need i.MX1/L support) + + Title: SPI METHODS ARE NOT THREAD SAFE + Description: SPI methods are not thread safe. Needs a semaphore to protect from re-entrancy. + Status: Open + Priority: Medium -- Will be very high if you do SPI access from multiple threads. + + ARM/i.MX1-specific Configuration Options ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/configs/ntosd-dm320/README.txt b/configs/ntosd-dm320/README.txt index 86a9bc323e0..b9da6609350 100644 --- a/configs/ntosd-dm320/README.txt +++ b/configs/ntosd-dm320/README.txt @@ -13,6 +13,7 @@ CONTENTS - ARM/DM320-specific Configuration Options - Configurations - Configuration Options + - Issues Dev vs. Production Neuros OSD v1.0 boards ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -395,3 +396,34 @@ Neuros OSD Configuration Options CONFIG_ARCH_NTOSD_DEVBOARD - Selects the old NTOSD development board. The default is the production OSD board which differs in several ways. + +Issues +^^^^^^ + + Title: DEBUG ISSUES + Description: config/ntos-dm320: It seems that when a lot of debug statements + are added, the system no longer boots. This is suspected to be + a stack problem: Making the stack bigger or removing arrays on + the stack seems to fix the problem (might also be the + bootloader overwriting memory) + Status: Open + Priority: Medium + + Title: USB DEVICE DRIVER UNTESTED + Description: A USB device controller driver was added but has never been tested. + Status: Open + Priority: Medium + + Title: FRAMEBUFFER DRIVER UNTESTED + Description: A framebuffer "driver" was added, however, it remains untested. + Status: Open + Priority: Medium + + Title: VIDEO ENCODER DRIVER + Description: In order to use the framebuffer "driver" additional video encoder + logic is required to setup composite video output or to interface + with an LCD. + Status: Open + Priority: Medium (high if you need to use the framebuffer driver) + +