1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
|
NuttX TODO List (Last updated July 12, 2011)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
nuttx/
(5) Task/Scheduler (sched/)
(1) On-demand paging (sched/)
(1) Memory Managment (mm/)
(1) Signals (sched/, arch/)
(1) pthreads (sched/)
(1) C++ Support
(5) Binary loaders (binfmt/)
(16) Network (net/, drivers/net)
(2) USB (drivers/usbdev, drivers/usbhost)
(6) Libraries (lib/)
(13) File system/Generic drivers (fs/, drivers/)
(1) Graphics subystem (graphics/)
(1) Pascal add-on (pcode/)
(1) Documentation (Documentation/)
(5) Build system / Toolchains
(7) Linux/Cywgin simulation (arch/sim)
(4) ARM (arch/arm/)
(1) ARM/C5471 (arch/arm/src/c5471/)
(3) ARM/DM320 (arch/arm/src/dm320/)
(2) ARM/i.MX (arch/arm/src/imx/)
(3) ARM/LPC17xx (arch/arm/src/lpc17xx/)
(7) ARM/LPC214x (arch/arm/src/lpc214x/)
(2) ARM/LPC313x (arch/arm/src/lpc313x/)
(3) ARM/STR71x (arch/arm/src/str71x/)
(4) ARM/LM3S6918 (arch/arm/src/lm3s/)
(4) ARM/STM32 (arch/arm/src/stm32/)
(3) AVR (arch/avr)
(0) Intel x86 (arch/x86)
(4) 8051 / MCS51 (arch/8051/)
(2) Hitachi/Renesas SH-1 (arch/sh/src/sh1)
(4) Renesas M16C/26 (arch/sh/src/m16c)
(8) z80/z8/ez80 (arch/z80/)
(8) z16 (arch/z16/)
(1) mc68hc1x (arch/hc)
apps/
(5) Network Utilities (apps/netutils/)
(5) NuttShell (NSH) (apps/nshlib)
(3) Other Applications & Tests (apps/examples/)
o Task/Scheduler (sched/)
^^^^^^^^^^^^^^^^^^^^^^^
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.
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
Description: Implement sys/mman.h and functions
Status: Open
Priority: Low
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
Description: Several APIs do not set errno. Need to review all APIs.
Status: Open
Priority: Medium, required for standard compliance (but makes the
code bigger)
o On-demand paging (sched/)
^^^^^^^^^^^^^^^^^^^^^^^^^
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
^^^^^^^^^^^^^^^^^^^
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.
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/)
^^^^^^^^^^^^^^^^^^^^^^
Description: Add an option to free all memory allocated by a task when the
task exits. This is probably not be worth the overhead for a
deeply embedded system.
There would be complexities with this implementation as well
because often one task allocates memory and then passes the
memory to another: The task that "owns" the memory may not
be the same as the task that allocated the memory.
Status: Open
Priority: Medium/Low, a good feature to prevent memory leaks but would
have negative impact on memory usage and code size.
o Signals (sched/, arch/)
^^^^^^^^^^^^^^^^^^^^^^^
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.
o pthreads (sched/)
^^^^^^^^^^^^^^^^^
Description: pthread_cancel(): Should implement cancellation points and
pthread_testcancel()
Status: Open
Priority: Low, probably not that useful
o C++ Support
^^^^^^^^^^^
Description: Need to call static constructors
Status: Open
Priority: Low, depends on toolchain. Call to gcc's built-in static
constructor logic will probably have to be performed by
user logic in user_start().
o Binary loaders (binfmt/)
^^^^^^^^^^^^^^^^^^^^^^^^
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
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
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
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)
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
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)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Should implement SOCK_RAW, SOCK_PACKET
Status: Open
Priority: Low
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.
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.
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
Description: Incoming UDP broadcast should only be accepted if listening on
INADDR_ANY(?)
Status: Open
Priority: Low
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
Description: Need to standardize collection of statistics from network
drivers. apps/nshlib ifconfig command should present
statistics.
Status: Open
Priority: Low
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.
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
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
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()
Description: sockets do not support all modes except 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.
Description: I started coding a CrystalLan CS89x0 driver (drivers/net/cs89x0.c),
but never finished it.
Status: Open
Priority: Low unless you need it.
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.
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.
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.
Description: Many configurations have the MTU (CONFIG_NET_BUFSIZE) set to very small
numbers, less then the minimum MTU size that must be supported -- 576.
This can cause problems in some networks: CONFIG_NET_BUFSIZE should
be set to at least 576 in all defconfig files.
The symptoms of using very small MTU sizes can be very strange. With
Ubuntu 9.x and vsFtpd was that the total packet size did *not match* the
packet size in the IP header. This then caused a TCP checksum failure
and the packet was rejected.
Status: Open
Priority: Low... fix defconfig files as necessary.
o USB (drivers/usbdev, drivers/usbhost)
^^^^^^^^^^^^^^^^^^^^
Description: There is a workaround for a bug in drivers/usbdev/usbdev_storage.c.
that involves delays. This needs to be redesigned to eliminate these delays.
Status: Open
Priority: Medium
Description: drivers/usbhost/usbhost_rtl8187.c is a work in progress. There is no RTL8187
driver available yet. That is a work in progress.
Status: Open
Priority: Low (Unless you need RTL8187 support).
o Libraries (lib/)
^^^^^^^^^^^^^^^^
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
Description: fgets implementation does not use C-buffered I/O, but rather
talks to serial driver directly via read(). It includes VT-100
specific editting commands. This gets should be renamed readlin()
and a more generic fgets() should be implemented.
Status: Open
Priority: Low (unless you are using mixed C-buffered I/O with fgets and
fgetc, for example).
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
Description: strftime() and other timing functions do not handle days of the week.
Status: Open
Priority: Low
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
Description: Not implemented: ferror() and clearerr()
Status: Open
Priority: Low
o File system / Generic drivers (fs/, drivers/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt
Description: Implement chmod(), truncate().
Status: Open
Priority: Low
Description: FAT: long file names
Status: Open
Priority: Medium
Description: The CAN driver is untested. Add a test for the CAN driver.
Status: Open
Priority: Medium
Description: At present, the CAN driver does not support the poll() method.
Status: Open
Priority: Low
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
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.
Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
yet handle multiple block transfers.
Status: Open
Priority: Medium-Low
Description: At present, mmap() only works with file descriptors associated
with a ROMFS file system. Generalize this logic so that if
mmap is not supported by the file system or block driver, it
will allocate memory and copy the file into RAM. This would
need some centralized logic so that the memory region would
be shared on later mmap()'s on the same inode. Reference counting
would be required so that the multiply mmap()'ed region persists
until the last munmap().
Status: Open
Priority: Low
Description: Block driver read-ahead buffer and write buffer support is
implemented but not yet tested.
Status: Open
Priority: Low
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
Description: ENC28J60 driver is complete, but untested (I still haven't got
a good ENC28J60 test platform).
Status: Open
Priority: Low
Description: Time stamping is not implemented in the NuttX FA file system.
See the following functions in fs/fat/fs_fat32util.c:
fat_systime2fattime() and fat_fattime2systime()
Status: Open
Priority: Medium
o Graphics subystem (graphics/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Testing of all APIs is not complete. See
http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage
Status: Open
Priority: Medium
o Pascal Add-On (pcode/)
^^^^^^^^^^^^^^^^^^^^^^
Description: Need APIs to verify execution of P-Code from memory buffer.
Status: Open
Priority: Low
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
^^^^^^^^^^^^
Description: Dependencies do not work correctly under configs/<board>/src
(same as arch/<arch>/src/board).
Status: Open
Priority: Medium (maybe higher for z80 target)
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
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
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.
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 libriars should be built into some
libuser.a. The list of user libraries would have to accepted with
some new argument, perhaps -u.
Status: Open
Priority: Low.
o Linux/Cywgin simulation (arch/sim)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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)
Description: Simulator does not build correctly on 64-bit machines. Two
issues:
1) It saves addresses in 32-bit types and these fail when cast
to pointers on a 64-bit host.
2) up_setjmp.S does not build
Status: Open
Priority: Medium and increasing (as 32-bit hosts gradually disappear). NOTE
is it possible to work-around this limitation by building the sim
target for 32-bit operation on a 64-bit platform. Modify the
Make.defs file in the appropriate places so that -m32 is included
in the CFLAGS and -m32 and -melf_386 are included in the LDFLAGS.
See the patch 0001-Quick-hacks-to-build-sim-nsh-ostest-on-x86_64-as-32-.patch
that can be found at http://tech.groups.yahoo.com/group/nuttx/files.
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).
Description: There is an X11-based framebuffer driver that you can use exercise
the NuttX graphics subsystem on the simulator. But I am not much
of an X11 programmer so I did not use X11 autoconfiguration stuff.
As a result, it builds on old X11 installations, but not on current
versions.
Status: Open
Priority: Low (unless you want to test graphics features on the simulation).
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
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.
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/)
^^^^^^^^^^^^^^^
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/cortexm3/* for
examples of how this might be done.
Status: Open
Priority: Low
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
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.
Status: Open
Priority: Low
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.
Status: Open
Priority: Low until I get around to implement security for the ARM platform.
o ARM/C5471 (arch/arm/src/c5471/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
Description: A USB device controller driver was added but has never been tested.
Status: Open
Priority: Medium
Description: A framebuffer "driver" was added, however, it remains untested.
Status: Open
Priority: Medium
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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)
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
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
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Should use Vector Interrupts
Status: Open
Priority: Low
Description: USB DMA not fully implemented. Partial logic is in place but it is
fragmentary and bogus.
Status: Open
Priority: Low
Description: USB Serial Driver reports wrong error when opened before the
USB is connected (reports EBADF instead of ENOTCONN)
Status: Open
Priority: Low
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
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.
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
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
andything to do with CMD0).
Status: Open
Priority: Uncertain
Description: Possible errors in USB device driver reported "I suspect there's a few
issues in the lpc214x USB driver - in particular it doesn't stall both
in/out endpoints for unsupported setup requests and it doesn't call
CLASS_DISCONNCET on a USB reset - I don't have any access to that hardware
so can't pursue it really."
Status: Open
Priority: Medium
o ARM/LPC313x (arch/arm/src/lpc313x/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
Description: Develop a USB driver and integrate with existing USB serial and storage
class drivers.
Status: Open
Priority: Medium
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Still need to implement I2C
Status: Open
Priority: Low
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.
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.
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: NOR Flash driver with FTL layer to support a file system.
Status: Open
Priority: Low
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
Description: FSMC external memory support is untested
Status: Open
Priority: Low
Description: DMA logic needs to be extended. DMA2, Channel 5, will not work
because the DMA2 channels 4 & 5 share the same interrupt.
Status: Open
Priority: Low until someone needs DMA1, Channel 5 (ADC3, UART4_TX, TIM5_CH1, or
TIM8_CH2).
o AVR (arch/avr)
^^^^^^^^^^^^^^
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.
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.
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.
o Intel x86 (arch/x86)
^^^^^^^^^^^^^^^^^^^^
o 8051 / MCS51 (arch/8051/)
^^^^^^^^^^^^^^^^^^^^^^^^^
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.
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
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
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 Hitachi/Renesas SH-1 (arch/sh/src/sh1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: There are instabilities that make the SH-1 port un-usable. The
nature of these is not understood; the behavior is that certain SH-1
instructions stop working as advertised. I have seen the following
examples:
412b jmp @r1 - Set a return address in PR, i.e., it behaved like
410b jsr @r1. Normally 412b works correctly, but in the failure
condition, it reliably set the PR.
69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+. This behavior
does not correspond to any known SH-1 instruction
This could be a silicon problem, some pipeline issue that is not
handled properly by the gcc 3.4.5 toolchain (which has very limit
SH-1 support to begin with), or perhaps with the CMON debugger. At
any rate, I have exhausted all of the energy that I am willing to put
into this cool old processor for the time being.
Status: Open
Priority: Low -- because the SH-1, SH7032, is very old and only of historical
interest.
Description: arch/sh has been restructured to support M16C. Need to verify that
SH-1 still builds.
Status: Open
Priority: Low
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.
o Renesas M16C/26 (arch/sh/src/m16c)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: Coding of the initial port is complete, but is untested.
Status: Open
Priority: Low
Description: Serial drivers were developed for the M16C, however, the SKP16C26
StarterKit has no serial connectors.
Status: Open
Priority: Low
Description: Should implement SPI, I2C, Virual EEPROM, FLASH, RTC drivers
Status: Open
Priority: Medium
o z80/z8/ez80 (arch/z80)
^^^^^^^^^^^^^^^^^^^^^^^
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
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.
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.
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
Description: Add support for prioritized ez8 interrupts. Currently logic supports
only nominal interrupt priority.
Status: Open
Priority: Low
Description: The z8Encore! port has only been verified on the ZDS-II instruction
set simulator.
Status: Open
Priority: Medium
Description: Upgrade to the ZDS-II Z8Encore! 4.11.0 toolchain
Status: Open
Priority: Low
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.
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
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.
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)
^^^^^^^^^^^^^^^^
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.
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.
Description: The system delays do not appear to be correct with the
apps/examples/ostest/timedmqueue.c test.
Status: Open
Priority: Medium-High
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
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
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
Description: Add support for prioritized interrupts. Currently logic supports
only nominal interrupt priority.
Status: Open
Priority: Low
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)
^^^^^^^^^^^^^^^^^^
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/)
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
Description: Port PPP support from http://contiki.cvs.sourceforge.net/contiki/contiki-2.x/backyard/core/net/ppp/
Status: Open
Priority: Low
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
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
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)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Description: When the telnetd front end is received, each TCP packet
received causes a prompt (nsh >) to be presented. The
prompt should only be presented when the user enters a
carriage return.
Status: Open
Priority: Low
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
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).
Description: Add support to NSH to run NXFLAT programs from a ROMFS file system
Status: Open
Priority: Low (enhancement)
Description: Add an ARP command so that we can see the contents of the ARP table.
Status: Open
Priority: Low (enhancement)
o Other Applications & Tests (apps/examples/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
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
Description: examples/sendmail is untested on the target (it has been tested
on the host, but not on the target.
Status: Open
Priority: Med
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.
|