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
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
|
NuttX TODO List (Last updated April 5, 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.
nuttx/
(11) Task/Scheduler (sched/)
(1) Memory Managment (mm/)
(3) Signals (sched/signal, arch/)
(2) pthreads (sched/pthread)
(0) Message Queues (sched/mqueue)
(4) C++ Support
(6) Binary loaders (binfmt/)
(12) Network (net/, drivers/net)
(4) USB (drivers/usbdev, drivers/usbhost)
(12) Libraries (libc/, libm/)
(11) File system/Generic drivers (fs/, drivers/)
(8) Graphics subystem (graphics/)
(1) Pascal add-on (pcode/)
(1) Documentation (Documentation/)
(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 ((arch/arm/src/sama5/)
(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/
(6) Network Utilities (apps/netutils/)
(2) NuttShell (NSH) (apps/nshlib)
(1) System libraries apps/system (apps/system)
(4) Other Applications & Tests (apps/examples/)
o Task/Scheduler (sched/)
^^^^^^^^^^^^^^^^^^^^^^^
Title: CHILD PTHREAD TERMINATION
Description: When a tasks exits, shouldn't all of its child pthreads also be
terminated?
Status: Closed. No, this behavior will not be implemented.
Priority: Medium, required for good emulation of process/pthread model.
Title: pause() NON-COMPLIANCE
Description: In the POSIX description of this function is the pause() function
will suspend the calling thread until delivery of a signal whose
action is either to execute a signal-catching function or to
terminate the process. The current implementation only waits for
any non-blocked signal to be received. It should only wake up if
the signal is delivered to a handler.
Status: Open.
Priority: Medium Low.
Title: ON-DEMAND PAGING INCOMPLETE
Description: On-demand paging has recently been incorporated into the RTOS.
The design of this feature is described here:
http://www.nuttx.org/NuttXDemandPaging.html.
As of this writing, the basic feature implementation is
complete and much of the logic has been verified. The test
harness for the feature exists only for the NXP LPC3131 (see
configs/ea3131/pgnsh and locked directories). There are
some limitations of this testing so I still cannot say that
the feature is fully functional.
Status: Open. This has been put on the shelf for some time.
Priority: Medium-Low
Title: GET_ENVIRON_PTR()
Description: get_environ_ptr() (sched/sched_getenvironptr.c) is not implemented.
The representation of the environment strings selected for
NutX is not compatible with the operation. Some significant
re-design would be required to implement this function and that
effort is thought to be not worth the result.
Status: Open. No change is planned.
Priority: Low -- There is no plan to implement this.
Title: TIMER_GETOVERRUN()
Description: timer_getoverrun() (sched/timer_getoverrun.c) is not implemented.
Status: Open
Priority: Low -- There is no plan to implement this.
Title: INCOMPATIBILITES WITH execv() AND execl()
Description: Simplified 'execl()' and 'execv()' functions are provided by
NuttX. NuttX does not support processes and hence the concept
of overlaying a tasks process image with a new process image
does not make any sense. In NuttX, these functions are
wrapper functions that:
1. Call the non-standard binfmt function 'exec', and then
2. exit(0).
As a result, the current implementations of 'execl()' and
'execv()' suffer from some incompatibilities, the most
serious of these is that the exec'ed task will not have
the same task ID as the vfork'ed function. So the parent
function cannot know the ID of the exec'ed task.
Status: Open
Priority: Medium Low for now
Title: ISSUES WITH atexit() AND on_exit()
Description: These functions execute with the following bad properties:
1. They run with interrupts disabled,
2. They run in supervisor mode (if applicable), and
3. They do not obey any setup of PIC or address
environments. Do they need to?
The fix for all of these issues it to have the callbacks
run on the caller's thread (as with signal handlers).
Status: Open
Priority: Medium Low. This is an important change to some less
important interfaces. For the average user, these
functions are just fine the way they are.
Title: execv() AND vfork()
Description: There is a problem when vfork() calls execv() (or execl()) to
start a new application: When the parent thread calls vfork()
it receives and gets the pid of the vforked task, and *not*
the pid of the desired execv'ed application.
The same tasking arrangement is used by the standard function
posix_spawn(). However, posix_spawn uses the non-standard, internal
NuttX interface task_reparent() to replace the child's parent task
with the caller of posix_spawn(). That cannot be done with vfork()
because we don't know what vfork() is going to do.
Any solution to this is either very difficult or impossible without
an MMU.
Status: Open
Priority: Low (it might as well be low since it isn't going to be fixed).
Title: errno IS NOT SHARED AMONG THREADS
Description: In NuttX, the errno value is unique for each thread. But for
bug-for-bug compatibility, the same errno should be shared by
the task and each thread that it creates. It is *very* easy
to make this change: Just move the pterrno field from
struct tcb_s to struct task_group_s. However, I am still not
sure if this should be done or not.
Status: Closed. The existing solution is better (although its
incompatibilities could show up in porting some code).
Priority: Low
Title: REMOVE TASK_DELETE
Description: Need to remove or fix task delete. This interface is non-
standard and not safe. Arbitrary deleting tasks can cause
serious problems such as memory leaks. Better to remove it
than to retain it as a latent bug.
Currently used within the OS and also part of the
implementation of pthread_cancel() and task_restart() (which
should also go for the same reasons). It is used in
NxWM::CNxConsole to terminate console tasks and also in
apps/netutils/thttpd to kill CGI tasks that timeout.
Status: Open
Priority: Low and not easily removable.
Title: RELEASE SEMAPHORES HELD BY CANCELED THREADS:
Description: Commit: fecb9040d0e54baf14b729e556a832febfe8229e: "In
case a thread is doing a blocking operation (e.g. read())
on a serial device, while it is being terminated by
pthread_cancel(), then uart_close() gets called, but
the semaphore (dev->recv.sem in the above example) is
still blocked.
"This means that once the serial device is opened next
time, data will arrive on the serial port (and driver
interrupts handled as normal), but the received characters
never arrive in the reader thread.
This patch addresses the problem by re-initializing the
semaphores on the last uart_close() on the device."
Yahoo! Groups message 7726: "I think that the system
should be required to handle pthread_cancel safely in
all cases. In the NuttX model, a task is like a Unix
process and a pthread is like a Unix thread. Cancelling
threads should always be safe (or at least as unsafe) as
under Unix because the model is complete for pthreads...
"So, in my opinion, this is a generic system issue, not
specific to the serial driver. I could also implement
logic to release all semaphores held by a thread when
it exits -- but only if priority inheritance is enabled;
because only in that case does the code have any memory
of which threads actually hold the semaphore.
"The patch I just incorporated is also insufficient. It
works only if the serial driver is shut down when the
thread is cancelled. But what if there are other open
references to the driver? Then the driver will not be
shut down, the semaphores will not be re-initialized, and
the semaphore counts will still be off by one.
"I think that the system needs to automatically release any
semaphores held by a thread being killed asynchronously?
It seems necessary to me."
UPDATE; The logic enabled when priority inheritance is
enabled for this purpose is insufficient. It provides
hooks so that given a semaphore it can traverse all
holders. What is needed would be logic so that given
a task, you can traverse all semaphores held by the task,
releasing each semaphore cound held by the exiting task.
Nothing like this exists now so that solution is not
imminent.
UPDATE: The basic fix to release the semaphore count if
a thread is killed via pthread_cancel() or task_delete()
has been implemented (2014-12-13). See the new file:
sched/semaphore/sem_recover.c However, the general
issue of freeing semaphores when a thread exists still
exists.
Status: Open
Priority: Medium-ish
o Memory Managment (mm/)
^^^^^^^^^^^^^^^^^^^^^^
Title: FREE MEMORY ON TASK EXIT
Description: Add an option to free all memory allocated by a task when the
task exits. This is probably not be worth the overhead for a
deeply embedded system.
There would be complexities with this implementation as well
because often one task allocates memory and then passes the
memory to another: The task that "owns" the memory may not
be the same as the task that allocated the memory.
Update. From the NuttX forum:
...there is a good reason why task A should never delete task B.
That is because you will strand memory resources. Another feature
lacking in most flat address space RTOSs is automatic memory
clean-up when a task exits.
That behavior just comes for free in a process-based OS like Linux:
Each process has its own heap and when you tear down the process
environment, you naturally destroy the heap too.
But RTOSs have only a single, shared heap. I have spent some time
thinking about how you could clean up memory required by a task
when a task exits. It is not so simple. It is not as simple as
just keeping memory allocated by a thread in a list then freeing
the list of allocations when the task exists.
It is not that simple because you don't know how the memory is
being used. For example, if task A allocates memory that is used
by task B, then when task A exits, you would not want to free that
memory needed by task B. In a process-based system, you would
have to explicitly map shared memory (with reference counting) in
order to share memory. So the life of shared memory in that
environment is easily managed.
I have thought that the way that this could be solved in NuttX
would be: (1) add links and reference counts to all memory allocated
by a thread. This would increase the memory allocation overhead!
(2) Keep the list head in the TCB, and (3) extend mmap() and munmap()
to include the shared memory operations (which would only manage
the reference counting and the life of the allocation).
Then what about pthreads? Memory should not be freed until the last
pthread in the group exists. That could be done with an additional
reference count on the whole allocated memory list (just as streams
and file descriptors are now shared and persist until the last
pthread exits).
I think that would work but to me is very unattractive and
inconsistent with the NuttX "small footprint" objective. ...
Other issues:
- Memory free time would go up because you would have to remove
the memory from that list in free().
- There are special cases inside the RTOS itself. For example,
if task A creates task B, then initial memory allocations for
task B are created by task A. Some special allocators would
be required to keep this memory on the correct list (or on
no list at all).
Status: Open. No changes are planned.
Priority: Medium/Low, a good feature to prevent memory leaks but would
have negative impact on memory usage and code size.
o Signals (sched/signal, arch/)
^^^^^^^^^^^^^^^^^^^^^^^
Title: STANDARD SIGNALS
Description: 'Standard' signals and signal actions are not supported.
(e.g., SIGINT, SIGSEGV, etc).
Update: SIGCHLD is supported if so configured.
Status: Open. No changes are planned.
Priority: Low, required by standards but not so critical for an
embedded system.
Title: SIGEV_THREAD
Description: sig_notify() logic does not support SIGEV_THREAD; structure
struct sigevent does not provide required members sigev_notify_function
or sigev_notify_attributes.
Status: Low, there are alternative designs. However, these features
are required by the POSIX standard.
Priority: Low for now
Title: SIGNAL NUMBERING
Description: In signal.h, the range of valid signals is listed as 0-31. However,
in many interfaces, 0 is not a valid signal number. The valid
signal number should be 1-32. The signal set operations would need
to map bits appropriately.
Status: Open
Priority: Low. Even if there are only 31 usable signals, that is still a lot.
o pthreads (sched/pthreads)
^^^^^^^^^^^^^^^^^
Title: CANCELLATION POINTS
Description: pthread_cancel(): Should implement cancellation points and
pthread_testcancel()
Status: Open. No changes are planned.
Priority: Low, probably not that useful
Title: PTHREAD_PRIO_PROTECT
Description: Extended pthread_mutexattr_setprotocol() suport PTHREAD_PRIO_PROTECT:
"When a thread owns one or more mutexes initialized with the
PTHREAD_PRIO_PROTECT protocol, it shall execute at the higher of its
priority or the highest of the priority ceilings of all the mutexes
owned by this thread and initialized with this attribute, regardless of
whether other threads are blocked on any of these mutexes or not.
"While a thread is holding a mutex which has been initialized with
the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol attributes,
it shall not be subject to being moved to the tail of the scheduling queue
at its priority in the event that its original priority is changed,
such as by a call to sched_setparam(). Likewise, when a thread unlocks
a mutex that has been initialized with the PTHREAD_PRIO_INHERIT or
PTHREAD_PRIO_PROTECT protocol attributes, it shall not be subject to
being moved to the tail of the scheduling queue at its priority in the
event that its original priority is changed."
Status: Open. No changes planned.
Priority: Low -- about zero, probably not that useful. Priority inheritance is
already supported and is a much better solution. And it turns out
that priority protection is just about as complex as priority inheritance.
Exerpted from my post in a Linked-In discussion:
"I started to implement this HLS/"PCP" semaphore in an RTOS that I
work with (http://www.nuttx.org) and I discovered after doing the
analysis and basic code framework that a complete solution for the
case of a counting semaphore is still quite complex -- essentially
as complex as is priority inheritance.
"For example, suppose that a thread takes 3 different HLS semaphores
A, B, and C. Suppose that they are prioritized in that order with
A the lowest and C the highest. Suppose the thread takes 5 counts
from A, 3 counts from B, and 2 counts from C. What priority should
it run at? It would have to run at the priority of the highest
priority semaphore C. This means that the RTOS must maintain
internal information of the priority of every semaphore held by
the thread.
"Now suppose it releases one count on semaphore B. How does the
RTOS know that it still holds 2 counts on B? With some complex
internal data structure. The RTOS would have to maintain internal
information about how many counts from each semaphore are held
by each thread.
"How does the RTOS know that it should not decrement the priority
from the priority of C? Again, only with internal complexity. It
would have to know the priority of every semaphore held by
every thread.
"Providing the HLS capability on a simple pthread 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 Message Queues (sched/mqueue)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
o Kernel/Protected Build
^^^^^^^^^^^^^^^^^^^^^^
Title: NSH PARTITIONING.
Description: There are issues with several NSH commands in the NuttX kernel
and protected build modes (where NuttX is built as a monolithic
kernel and user code must trap into the protected kernel via
syscalls). The current NSH implementation has several commands
that call directly into kernel internal functions for which
there is no syscall available. The commands cause link failures
in the kernel/protected build mode and must currently be disabled.
Here are known problems that must be fixed:
COMMAND KERNEL INTERFACE(s)
-------- ----------------------------------------------
losetup losetup(), loteardown()
mkfatfs mkfatfs
mkrd ramdisk_register()
dd bchlib_setup(), bchlib_read(), bchlib_write(),
bchlib_teardown()
ps sched_foreach()
ifup netdev_foreach()
ifdown netdev_foreach()
ifconfig netdev_foreach(), g_netstats
ping icmp_ping()
Status: Open
Priority: Medium/High -- the kernel build configuration is not fully fielded
yet.
Title: NSH free COMMAND LIMITATION
Description: The NSH 'free' command only shows memory usage in the user
heap only, not usage in the kernel heap. I am thinking that
kernel heap memory usage should be available in /proc/memory.
Status: Open
Priority: Medium/High
Title: TELNETD PARTITIONING.
Description: Telnetd is implemented as a driver that resides in the apps/
directory. In the kernel/protected build modes, the driver
logic must be moved into the kernel part of the build (nuttx/,
although the application level interfaces must stay in apps/).
Status: Open
Priority: Medium
Title: NxTERM PARTITIONING.
Description: NxTerm is implemented (correctly) as a driver that resides
in the nuttx/ directory. However, the user interfaces must be
moved into a NuttX library or into apps/. Currently
applications calls to the NxTerm user interfaces are
undefined.
Status: Open
Priority: Medium
Title: C++ CONSTRUCTORS HAVE TOO MANY PRIVILEGES (PROTECTED MODE)
Description: When a C++ ELF module is loaded, its C++ constructors are called
via sched/task_starthook.c logic. This logic runs in protected mode.
The is a security hole because the user code runs with kernel-
privileges when the constructor executes.
Destructors likely have the opposite problem. The probably try to
execute some kernel logic in user mode? Obviously this needs to
be investigated further.
Status: Open
Priority: Low (unless you need build a secure C++ system).
Title: TOO MANY SYSCALLS
Description: There are a few syscalls that operate very often in user space.
Since syscalls are (relatively) time consuming this could be
a performance issue. Here is some numbers that I collected
in an application that was doing mostly printf output:
sem_post - 18% of syscalls
sem_wait - 18% of syscalls
getpid - 59% of syscalls
--------------------------
95% of syscalls
Obviously system performance could be improved greatly by simply
optimizing these functions so that they do not need to system calls
so frequently. getpid() is (I believe) part of the re-entrant
semaphore logic. Something like TLS might be used to retain the
thread's ID locally.
Linux, for example, has functions call up() and down(). up()
increments the semaphore count but does not call into the kernel
unless incrementing the count unblocks a task; similarly, down
decrements the count and does not call into the kernel unless
the count becomes negative the caller must be blocked.
Update:
"I am thinking that there should be a "magic" global, user-accessible
variable that holds the PID of the currently executing thread;
basically the PID of the task at the head of the ready-to-run list.
This variable would have to be reset each time the head of the ready-
to-run list changes.
"Then getpid() could be implemented in user space with no system call
by simply reading this variable.
"This one would be easy: Just a change to include/nuttx/userspace.h,
configs/*/kernel/up_userspace.c, libc/, sched/sched_addreadytorun.c, and
sched/sched_removereadytorun.c. That would eliminate 59% of the syscalls."
Update:
This is probably also just a symptom of the OS test that does mostly
console output. The requests for the pid() are part of the
implementation of the I/O's re-entrant semaphore implementation and
would not be an issue in the more general case.
Status: Open
Priority: Low-Medium. Right now, I do not know if these syscalls are a
real performance issue or not. The above statistics were collected
from a an atypical application (the OS test), and does an excessive
amount of console output. There is probably no issue with more typical
embedded applications.
Title: SECURITY ISSUES
Description: In the current designed, the kernel code calls into the user-space
allocators to allocate user-space memory. It is a security risk to
call into user-space in kernel-mode because that could be exploited
to gain control of the system. That could be fixed by dropping to
user mode before trapping into the memory allocators; the memory
allocators would then need to trap in order to return (this is
already done to return from signal handlers; that logic could be
renamed more generally and just used for a generic return trap).
Another place where the system calls into the user code in kernel
mode is work_usrstart() to start the user work queue. That is
another security hole that should be plugged.
Status: Open
Priority: Low (unless security becomes an issue).
Title: MICRO-KERNEL
Description: The initial kernel build cut many interfaces at a very high level.
The resulting monolithic kernel is then rather large. It would
not be a prohibitively large task to reorganize the interfaces so
that NuttX is built as a micro-kernel, i.e., with only the core
OS services within the kernel and with other OS facilities, such
as the file system, message queues, etc., residing in user-space
and to interfacing with those core OS facilities through traps.
Status: Open
Priority: Low. This is a good idea and certainly an architectural
improvement. However, there is no strong motivation now do
do that partitioning work.
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 a hold 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 application logic 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 the application.
Title: STATIC CONSTRUCTORS AND MULTITASKING
Description: The logic that calls static constructors operates on the main
thread of the initial user application task. Any static
constructors that cache task/thread specific information such
as C streams or file descriptors will not work in other tasks.
See also UCLIBC++ AND STATIC CONSTRUCTORS below.
Status: Open
Priority: Low and probably will not changed. In these case, there will
need to be an application specific solution.
Title: UCLIBC++ AND STATIC CONSTRUCTORS
uClibc++ was designed to work in a Unix environment with
processes and with separately linked executables. Each process
has its own, separate uClibc++ state. uClibc++ would be
instantiated like this in Linux:
1) When the program is built, a tiny start-up function is
included at the beginning of the program. Each program has
its own, separate list of C++ constructors.
2) When the program is loaded into memory, space is set aside
for uClibc's static objects and then this special start-up
routine is called. It initializes the C library, calls all
of the constructors, and calls atexit() so that the destructors
will be called when the process exits.
In this way, you get a per-process uClibc++ state since there
is per-process storage of uClibc++ global state and per-process
initialization of uClibc++ state.
Compare this to how NuttX (and most embedded RTOSs) would work:
1) The entire FLASH image is built as one big blob. All of the
constructors are lumped together and all called together at
one time.
This, of course, does not have to be so. We could segregate
constructors by some criteria and we could use a task start
up routine to call constructors separately. We could even
use ELF executables that are separately linked and already
have their constructors separately called when the ELF
executable starts.
But this would not do you very much good in the case of
uClibc++ because:
2) NuttX does not support processes, i.e., separate address
environments for each task. As a result, the scope of global
data is all tasks. Any change to the global state made by
one task can effect another task. There can only one
uClibc++ state and it will be shared by all tasks. uClibc++
apparently relies on global instances (at least for cin and
cout) there is no way to to have any unique state for any
"task group".
[NuttX does not support processes because in order to have
true processes, your hardware must support a memory management
unit (MMU) and I am not aware of any mainstream MCU that has
an MMU (or, at least an MMU that is capable enough to support
processes).]
NuttX does not have processes, but it does have "task groups".
See http://www.nuttx.org/doku.php?id=wiki:nxinternal:tasksnthreads.
A task group is the task plus all of the pthreads created by
the task via pthread_create(). Resources like FILE streams
are shared within a task group. Task groups are like a poor
man's process.
This means that if the uClibc++ static classes are initialized
by one member of a task group, then cin/cout should work
correctly with all threads that are members of task group. The
destructors would be called when the final member of the task
group exists (if registered via atexit()).
So if you use only pthreads, uClibc++ should work very much like
it does in Linux. If your NuttX usage model is like one process
with many threads then you have Linux compatibility.
If you wanted to have uClibc++ work across task groups, then
uClibc++ and NuttX would need some extensions. I am thinking
along the lines of the following:
1) There is a per-task group storage are within the RTOS (see
include/nuttx/sched.h). If we add some new, non-standard APIs
then uClibc++ could get access to per-task group storage (in
the spirit of pthread_getspecific() which gives you access to
per-thread storage).
2) Then move all of uClibc++'s global state into per-task group
storage and add a uClibc++ initialization function that would:
a) allocate per-task group storage, b) call all of the static
constructors, and c) register with atexit() to perform clean-
up when the task group exits.
That would be a fair amount of effort. I don't really know what
the scope of such an effort would be. I suspect that it is not
large but probably complex.
NOTES:
1) See STATIC CONSTRUCTORS AND MULTITASKING
2) To my knowledge, only some uClibc++ ofstream logic is
sensitive to this. All other statically initialized classes
seem to work OK across different task groups.
Status: Open
Priority: Low. I have no plan to change this logic now unless there is
some strong demand to do so.
o Binary loaders (binfmt/)
^^^^^^^^^^^^^^^^^^^^^^^^
Title: NXFLAT TESTS
Description: Not all of the NXFLAT test under apps/examples/nxflat are working.
Most simply do not compile yet. tests/mutex runs okay but
outputs garbage on completion.
Update: 13-27-1, tests/mutex crashed with a memory corruption
problem the last time that I ran it.
Status: Open
Priority: High
Title: ARM UP_GETPICBASE()
Description: The ARM up_getpicbase() does not seem to work. This means
the some features like wdog's might not work in NXFLAT modules.
Status: Open
Priority: Medium-High
Title: NXFLAT 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 Documentation/NuttXNxFlat.html,
by that would require a compiler change (which we want to avoid).
The simple workaround is to make such functions global in scope.
Status: Open
Priority: Low (probably will not fix)
Title: USE A HASH INSTEAD OF A STRING IN SYMBOL TABLES
Description: In the NXFLAT symbol tables... Using a 32-bit hash value instead
of a string to identify a symbol should result in a smaller footprint.
Status: Open
Priority: Low
Title: WINDOWS-BASED TOOLCHAIN BUILD
Description: Windows build issue. Some of the configurations that use NXFLAT have
the linker script specified like this:
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld -no-check-sections
That will not work for windows-based tools because they require Windows
style paths. The solution is to do something like this:
if ($(WINTOOL)y)
NXFLATLDSCRIPT=${cygpath -w $(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld}
else
NXFLATLDSCRIPT=$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.ld
endif
Then use
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T"$(NXFLATLDSCRIPT)" -no-check-sections
Status: Open
Priority: There are too many references like the above. They will have
to get fixed as needed for Windows native tool builds.
Title: TOOLCHAIN COMPATIBILITY PROBLEM
Descripton: The older 4.3.3 compiler generates GOTOFF relocations to the constant
strings, like:
.L3:
.word .LC0(GOTOFF)
.word .LC1(GOTOFF)
.word .LC2(GOTOFF)
.word .LC3(GOTOFF)
.word .LC4(GOTOFF)
Where .LC0, LC1, LC2, LC3, and .LC4 are the labels correponding to strings in
the .rodata.str1.1 section. One consequence of this is that .rodata must reside
in D-Space since it will addressed relative to the GOT (see the section entitled
"Read-Only Data in RAM" at
http://nuttx.org/Documentation/NuttXNxFlat.html#limitations).
The newer 4.6.3compiler generated PC relative relocations to the strings:
.L2:
.word .LC0-(.LPIC0+4)
.word .LC1-(.LPIC1+4)
.word .LC2-(.LPIC2+4)
.word .LC3-(.LPIC4+4)
.word .LC4-(.LPIC5+4)
This is good and bad. This is good because it means that .rodata.str1.1 can now
reside in FLASH with .text and can be accessed using PC-relative addressing.
That can be accomplished by simply moving the .rodata from the .data section to
the .text section in the linker script. (The NXFLAT linker script is located at
nuttx/binfmt/libnxflat/gnu-nxflat.ld).
This is bad because a lot of stuff may get broken an a lot of test will need to
be done. One question that I have is does this apply to all kinds of .rodata?
Or just to .rodata.str1.1?
Status: Open. Many of the required changes are in place but, unfortunately, not enough
go be fully functional. I think all of the I-Space-to-I-Space fixes are in place.
However, the generated code also includes PC-relative references to .bss which
just cannot be done.
Priority: Medium. The workaround for now is to use the older, 4.3.3 OABI compiler.
o Network (net/, drivers/net)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: LISTENING FOR UDP BROADCASTS
Description: Incoming UDP broadcast should only be accepted if listening on
INADDR_ANY(?)
Status: Open
Priority: Low
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. This is not a bug but an enhancement idea.
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: POLL/SELECT ON TCP/UDP SOCKETS NEEDS READ-AHEAD
Description: poll()/select() only works for availability of buffered TCP/UDP
read data (when read-ahead is enabled). The way writing is
handled in the network layer, all sockets must wait when send and
cannot be notified 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 nonblocking operations only (1) for TCP/IP non-
blocking read operations when read-ahead buffering is
enabled, (2) TCP/IP accept() operations when TCP/IP
connection backlog is enabled, (2) UDP/IP read() operations
when UDP read-ahead is enabled, and (3) non-blocking
operations on Unix domain sockets.
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: 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: CLOSED CONNECTIONS IN THE BACKLOG
If a connection is backlogged but accept() is not called quickly, then
that connection may time out. How should this be handled? Should the
connection be removed from the backlog if it is times out or is closed?
Or should it remain in the backlog with a status indication so that accept()
can fail when it encounteres the invalid connection?
Status: Open
Priority: Medium. Important on slow applications that will not accept
connections promptly.
Title: INTERRUPT LEVEL PROCESSING IN ETHERNET DRIVERS
Description: Too many Ethernet drivers do interrupt-level processing with
the network stack. The network stack supports either interrupt
level processing or normal task level processing (depending on
CONFIG_NET_NOINTS). This is really a very bad use of CPU
resources; All of the network stack processing should be
modified to use a work queue (and, all use of CONFIG_NET_NOINTS=n
should be eliminated). This applies to almost all Ethernet
drivers:
ARCHITECTURE CONFIG_NET_NOINTS? ADDRESS FILTER SUPPORT?
C5471 NO NO
STM32 YES YES
TIVA ----------------------- ------
LM3S NO NO
TM4C YES YES
eZ80 NO NO
LPC17xx YES (could be issues) YES (not tested)
DMxxx NIC NO NO
PIC32 NO NO
RGMP ??? ???
SAM3/4 YES YES
SAMA5D ----------------------- ------
EMACA NO YES (not tested)
EMACB YES YES
GMAC NO YES (not tested)
SAMV7 YES YES
SIM N/A (No interrupts) NO
The general outline of how this might be done is included in
drivers/net/skeleton.c
Status: Open
Priority: Pretty high if you want a well behaved system.
Title: UDP MULTICAST RECEPTION
Description: The logic in udp_input() expects either a single receive socket or
none at all. However, multiple sockets should be capable of
receiving a UDP datagram (multicast reception). This could be
handled easily by something like:
for (conn = NULL; conn = udp_active (pbuf, conn); )
If the callback logic that receives a packet responds with an
outgoing packet, then it will over-write the received buffer,
however. recvfrom() will not do that, however. We would have
to make that the rule: Recipients of a UDP packet must treat
the packet as read-only.
Status: Open
Priority: Low, unless your logic depends on that behavior.
Title: NETWORK WON'T STAY DOWN
Description: If you enable the NSH network monitor (CONFIG_NSH_NETINIT_MONITOR)
then the NSH 'ifdown' command is broken. Doing 'nsh> ifconfig eth0'
will, indeed, bring the network down. However, the network monitor
notices the change in the link status and will bring the network
back up. There needs to be some kind of interlock between
cmd_ifdown() and the network monitor thread to prevent this.
Status: Open
Priority: Low, this is just a nuisance in most cases.
Title: FIFO CLEAN-UP AFTER CLOSING UNIX DOMAIN DATAGRAM SOCKET
Description: FIFOs are used as the IPC underlying all local Unix domain
sockets. In NuttX, FIFOs are implemented as device drivers
(not as a special FIFO files). The FIFO device driver is
instantiated when the Unix domain socket communications begin
and will automatically be released when (1) the driver is
unlinked and (2) all open references to the driver have been
closed. But there is no mechanism in place now to unlink the
FIFO when the Unix domain datagram socket is no longer used.
The primary issue is timing.. the FIFO should persist until
it is no longer needed. Perhaps there should be a delayed
call to unlink() (using a watchdog or the work queue). If
the driver is re-opened, the delayed unlink could be
cancelled? Needs more thought.
NOTE: This is not an issue for Unix domain streams sockets:
The end-of-life of the FIFO is well determined when sockets
are disconnected and support for that case is fully implemented.
Status: Open
Priority: Low for now because I don't have a situation where this is a
problem for me. If you use the same Unix domain paths, then
it is not a issue; in fact it is more efficient if the FIFO
devices persist. But this would be a serious problem if,
for example, you create new Unix domain paths dynamically.
In that case you would effectively have a memory leak and the
number of FIFO instances grow.
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.
If queuing of stall requests is supported by DCD then this workaround
is not required. In this case, (1) the stall is not sent until all
write requests preceding the stall request are sent, (2) the stall is
sent, and then after the stall is cleared, (3) all write requests
queued after the stall are sent.
See, for example, the queuing of pending stall requests in the SAM3/4
UDP driver at arch/arm/src/sam34/sam_udp.c. There the logic is do this
is implemented with a normal request queue, a pending request queue, a
stall flag and a stall pending flag:
1) If the normal request queue is not empty when the STALL request is
received, the stall pending flag is set.
2) If addition write requests are received while the stall pending flag
is set (or while waiting for the stall to be sent), those write requests
go into the pending queue.
3) When the normal request queue empties successful and all of the write
transfers complete, the STALL is sent. The stall pending flag is
cleared and the stall flag is set. Now the endpoint is really stalled.
4) After the STALL is cleared (via the Clear Feature SETUP), the pending
request queue is copied to the normal request queue, the stall flag is
cleared, and normal write request processing resumes.
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.
Here is an overview of the required changes:
New two buffers in driver structure:
1. The existing EP0 setup request buffer (ctrlreq, 8 bytes)
2. A new EP0 data buffer to driver state structure (ep0data,
max packetsize)
Add a new state:
3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT)
General logic flow:
1. When an EP0 SETUP packet is received:
- Read the request into EP0 setup request buffer (ctrlreq,
8 bytes)
- If this is an OUT request with data length, set the EP0
state to EP0STATE_SETUP_OUT and wait to receive data on
EP0.
- Otherwise, the SETUP request may be processed now (or,
in the case of the F4 driver, at the conclusion of the
SETUP phase).
2. When EP0 the EP0 OUT DATA packet is received:
- Verify state is EP0STATE_SETUP_OUT
- Read the request into the EP0 data buffer (ep0data, max
packet size)
- Now process the previously buffered SETUP request along
with the OUT data.
3. When the setup packet is dispatched to the class driver,
the OUT data must be passed as the final parameter in the
call.
Update 2013-9-2: The new USB device-side driver for the SAMA5D3
correctly supports OUT SETUP data following the same design as
per above.
Update 2013-11-7: David Sidrane has fixed with issue with the
STM32 F1 USB device driver. Still a few more to go before this
can be closed out.
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 currently, but it might be).
Title: USB HUB SUPPORT
Description: Add support for USB hubs
Status: Open
Priority: Low/Unknown. This is a feature enhancement.
o Libraries (libc/)
^^^^^^^^^^^^^^^^^
Title: SIGNED time_t
Description: The NuttX time_t is type uint32_t. I think this is consistent
with all standards and with normal usage of time_t. However,
according to Wikipedia, time_t is usually implemented as a
signed 32-bit value.
Status: Open
Priority: Very low unless there is some compelling issue that I do not
know about.
Title: ENVIRON
Description: The definition of environ in stdlib.h is bogus and will not
work as it should. This is because the underlying
representation of the environment is not an arry of pointers.
Status: Open
Priority: Medium
Title: TERMIOS
Description: Need some minimal termios support... at a minimum, enough to
switch between raw and "normal" modes to support behavior like
that needed for readline().
UPDATE: There is growing functionality in libc/termios/ and in the
ioctl methods of several MCU serial drivers (stm32, lpc43, lpc17,
pic32). However, as phrased, this bug cannot yet be closed since
this "growing functionality" does not address all termios.h
functionality and not all serial drivers support termios.
Status: Open
Priority: Low
Title: DAYS OF THE WEEK
Description: strftime() and other timing functions do not handle days of the week.
Status: Open
Priority: Low
Title: RESETTING GETOPT()
Description: There is an issue with the way that getopt() handles errors that
return '?'.
1. Does getopt() reset its global variables after returning '?' so
that it can be re-used? That would be required to support where
the caller terminates parsing before reaching the last parameter.
2. Or is the client expected to continue parsing after getopt()
returns '?' and parse until the final parameter?
The current getopt() implementation only supports #2.
Status: Open
Priority: Low
Title: 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 replace the second division
by zero, since it will result in a compile-time diagnostic, if the
implementation does not support infinity."
Status: Open
Priority:
Title: OLD dtoa NEEDS TO BE UPDATED
Description: This implementation of dtoa in libc/stdio is old and will not
work with some newer compilers. See
http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html
Status: Open
Priority: ??
Title: FLOATING POINT FORMATS
Description: Only the %f floating point format is supported. Others are accepted
but treated like %f.
Status: Open
Priority: Medium (this might important to someone).
Title: FLOATING POINT PRECISION
Description: A fieldwidth and precision is required with the %f format. If %f
is used with no format, than floating numbers will be printed with
a precision of 0 (effectively presented as integers).
Status: Open
Priority: Medium (this might important to someone).
Title: LIBM INACCURACIES
Description: "..if you are writing something like robot control or
inertial navigation system for aircraft, I have found
that using the toolchain libmath is only safe option.
I ported some code for converting quaternions to Euler
angles to NuttX for my project and only got it working
after switching to newlib math library.
"NuttX does not fully implement IEC 60559 floating point
from C99 (sections marked [MX] in OpenGroup specs) so if
your code assumes that some function, say pow(), actually
behaves right for all the twenty or so odd corner cases
that the standards committees have recently specified,
you might get surprises. I'd expect pow(0.0, 1.0) to
return 0.0 (as zero raised to any positive power is
well-defined in mathematics) but I get +Inf.
"NuttX atan2(-0.0, -1.0) returns +M_PI instead of correct
-M_PI. If we expect [MX] functionality, then atan2(Inf, Inf)
should return M_PI/4, instead NuttX gives NaN.
"asin(2.0) does not set domain error or return NaN. In fact
it does not return at all as the loop in it does not
converge, hanging your app.
"There are likely many other issues like these as the Rhombs
OS code has not been tested or used that much. Sorry for not
providing patches, but we found it easier just to switch the
math library."
Ref: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/7805
Status: Open
Priority: Low for casual users but clearly high if you need care about
these incorrect corner case behaviors in the math libraries.
o File system / Generic drivers (fs/, drivers/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt
Title: CHMOD() AND TRUNCATE()
Description: Implement chmod(), truncate().
Status: Open
Priority: Low
Title: CAN POLL SUPPORT
Description: At present, the CAN driver does not support the poll() method.
See drivers/can.c
Status: Open
Priority: Low
Title: REMOVING PIPES AND FIFOS
Description: There is no way to remove a FIFO or PIPE created in the
pseudo filesystem. Once created, they persist indefinitely
and cannot be unlinked. This is actually a more generic
issue: unlink does not work for anything in the pseudo-
filesystem.
Status: Open, but partially resolved: pipe buffer is at least freed
when there are not open references to the pipe/FIFO.
Priority: Medium
Title: ROMFS CHECKSUMS
Description: The ROMFS file system does not verify checksums on either
volume header on on the individual files.
Status: Open
Priority: Low. I have mixed feelings about if NuttX should pay a
performance penalty for better data integrity.
Title: SPI-BASED SD MULTIPLE BLOCK TRANSFERS
Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
yet handle multiple block transfers.
Status: Open
Priority: Medium-Low
Title: SDIO-BASED SD READ-AHEAD/WRITE BUFFERING INCOMPLETE
Description: The drivers/mmcsd/mmcsd_sdio.c driver has hooks in place to
support read-ahead buffering and write buffering, but the logic
is incomplete and untested.
Status: Open
Priority: Low
Title: POLLHUP SUPPORT
Description: All drivers that support the poll method should also report
POLLHUP event when the driver is closed.
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
properly (using configuration stm3240g-eval/nsh2). The problem
may be an assertion that is occurring before we have a console.
Status: Open
Priority: Medium
Title: UNIFIED DESCRIPTOR REPRESENTATION
Descripton: There are two separate ranges of descriptors for file and
socket descriptors: if a descriptor is in one range then it is
recognized as a file descriptor; if it is in another range
then it is recognized as a socket descriptor. These separate
descriptor ranges can cause problems, for example, they makes
dup'ing descriptors with dup2() problematic. The two groups
of descriptors are really indices into two separate tables:
On an array of file structures and the other an array of
socket structures. There really should be one array that
is a union of file and socket descriptors. Then socket and
file descriptors could lie in the same range.
Status: Open
Priority: Low
Title: DUPLICATE FAT FILE NAMES
Description: "The NSH and POSIX API interpretations about sensitivity or
insensitivity to upper/lowercase file names seem to be not
consistent in our usage - which can result in creating two
directories with the same name..."
Example using NSH:
nsh> echo "Test1" >/tmp/AtEsT.tXt
nsh> echo "Test2" >/tmp/aTeSt.TxT
nsh> ls /tmp
/tmp:
AtEsT.tXt
aTeSt.TxT
nsh> cat /tmp/aTeSt.TxT
Test2
nsh> cat /tmp/AtEsT.tXt
Test1
Status: Open
Priority: Low
Title: FAT LONG FILENAME COMPATIBILTY
Description: Recently there have been reports that file with long file
names created by NuttX don't have long file names when viewed
on Windows. The long file name support has been around for a
long time and I don't ever having seen this before so I am
suspecting that some evil has crept in.
Status: Open
Priority: Medium
Title: MISSING FILES IN NSH 'LS' OF A DIRECTORY
Description: I have seen cases where (1) long file names are enabled,
but (2) a short file name is created like:
nsh> echo "This is another thest" >/mnt/sdcard/another.txt
But then on subsequent 'ls' operations, the file does not appear:
nsh> ls -l /mnt/sdcard
I have determined that the problem is because, for some as-
of-yet-unkown reason the short file name is treated as a long
file name. The name then fails the long filename checksum
test and is skipped.
readdir() (and fat_readdir()) is the logic underlying the
failure and the problem appears to be something unique to the
fat_readdir() implementation. Why? Because the file is
visible when you put the SD card on a PC and because this
works fine:
nsh> ls -l /mnt/sdcard/another.txt
The failure does not happen on all short file names. I do
not understand the pattern. But I have not had the opportunity
to dig into this deeply.
Status: Open
Priority: Perhaps not a problem??? I have analyzed this problem and
I am not sure what to do about it. I am suspected that a
fat filesystem was used with a version of NuttX that does
not support long file name entries. Here is the failure
scenario:
1) A file with a long file name is created under Windows.
2) Then the file is deleted. I am not sure if Windows or
NuttX deleted the file, but the resulting directory
content is not compatible with NuttX with long file
name support.
The file deletion left the full sequence of long
file name entries intact but apparently delete only
the following short file name entry. I am thinking
that this might have happened because a version of NuttX
with only short file name support was used to delete
the file.
3) When a new file with a short file name was created, it
re-used the short file name entry that was previously
deleted. This makes the new short file name entry
look like a part of the long file name.
4) When comparing the checksum in the long file name
entry with the checksum of the short file name, the
checksum fails and the entire directlry sequence is
ignored by readder() logic. This the file does not
appear in the 'ls'.
o Graphics subsystem (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 operates 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 NxTERM FONT CACHING
Description: Now each NxTerm instance has its own private font cache
whose size is determined by CONFIG_NXTERM_MXCHARS. If there
are multiple NxTerm instances using the same font, each will
have a separate font cache. This is inefficient and wasteful
of memory: Each NxTerm 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 NxTerm were to be used in a
product.
Title: NxTERM VT100 SUPPORT
Description: If the NxTerm will be used with the Emacs-like command line
editor (CLE), then it will need to support VT100 cursor control
commands.
Status: Open
Priority: Low, the need has not yet arisen.
Title: ANTI-ALIASING
Description: Needed for proper rendering. After some analysis, I believe
this change would only be required in the the trapezoid
rendering logic. Essentially, it would need to blend the
fractional pixels at ends of each run with the underlying
pixel.
Hmmm.. graphics are sometimes erased by just redrawing them
with the background color. Would this approach leave ghost
images around where the erase image was?
Status: Open
Priority: Medium-ish. This would definitely improve graphics rendering
and line drawing.
Title: PER-WINDOW FRAMEBUFFERS
Description: One of the most awkard things to handle in the NX windowing
system is the re-draw callback. This is difficult because it
requires ad hoc, custom logic to be able to do the redrawing
in most cases.
One solution would be to provide a per-window framebuffer.
All rending would be performed into the per-window framebuffer
and the rended bits would be copied the LCD or framebuffer
device memory on demand when the redraw is required.
This would (a) greatly simplify the graphics interface, (b)
greatly improve redraw performance, and (c) enable a more
generic use of the windowing. The downside would be a large
usage of memory to hold all of the framebuffers, one for each
window.
Status: Open
Priority: Low, of mostly strategic value.
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
Title: PDBG
Description: Move the the pascal p-code debugger into the NuttX apps/ tree
where it can be used from the NSH command line.
Status: Open
Priority: Low
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: WINDOWS DEPENDENCY GENERATION
Description: Dependency generation is currently disabled when a Windows native
toolchain is used in a POSIX-like environment (like Cygwin). The
issue is that the Windows tool generates dependencies use Windows
path formatting and this fails with the dependency file (Make.dep)
is include). Perhaps the only issue is that all of the Windows
dependencies needed to be quoted in the Make.dep files.
Status: Open
Priority: Low -- unless some dependency-related build issues is discovered.
Title: 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.
o Linux/Cywgin simulation (arch/sim)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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: SIMULATOR HAS NO INTERRUPTS (NON-PREMPTIBLE)
Description: The current simulator implementation is has no interrupts and, hence,
is non-preemptible. Also, without simulated interrupt, there can
be no high-fidelity simulated device drivers.
Currently, all timing and serial input is simulated in the IDLE loop:
When nothing is going on in the simulation, the IDLE loop runs and
fakes timer and UART events.
Status: Open
Priority: Low, unless there is a need for developing a higher fidelity simulation
I have been thinking about how to implement simulated interrupts in
the simulation. I think a solution would work like this:
http://www.nuttx.org/doku.php?id=wiki:nxinternal:simulator
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 asynchronous 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
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.
This approach is already implemented for the ARM Cortex-M0,
Cortex-M3, Cortex-M4, and Cortex-A5 families. But still needs
to be back-ported to the ARM7 and ARM9 (which are nearly
identical to the Cortex-A5 in this regard). The change is
*very* simple for this architecture, but not implemented.
Status: Open. But complete on all ARM platforms except ARM7 and ARM9.
Priority: Low.
Title: IMPROVED ARM INTERRUPT HANDLING
Description: The ARM and Cortex-M3 interrupt handlers restores all registers
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: CORTEX-M3 STACK OVERFLOW
Description: There is bit bit logic in 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 excessively high interrupt conditions, many
nested interrupts can occur 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: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/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.
UPDATE: Other ARM architectures have a similer issue.
Status: Open
Priority: Low. The conditions of continuous interrupts is really the problem.
If your design needs continuous interrupts like this, please try
the above change and, please, submit a patch with the working fix.
Title: STACK ALIGNMENT IN INTERRUPT HANDLERS
Description: The EABI standard requires that the stack always have a 32-byte
alignment. There is no guarantee at present that the stack will be
so aligned in an interrupt handler. Therefore, I would expect some
issues if, for example, floating point or perhaps long long operations
were performed in an interrupt handler.
This issue exists for ARM7, ARM9, Cortex-M0, Cortex-M3, and
Cortex-M4 but has been addressed for the Cortex-A5. The fix
is really simple can cannot be incorporated without some
substantial testing. For ARM, the fix is the following logic
arround each call into C code from assembly:
mov r4, sp /* Save the SP in a preserved register */
bic sp, sp, #7 /* Force 8-byte alignment */
bl cfunction /* Call the C function */
mov sp, r4 /* Restore the possibly unaligned stack pointer */
This same issue applies to the interrupt stack which is, I think
improperly aligned in almost all cases (except Cortex-A5).
Status: Open
Priority: Low for me because I never do floating point operations in
interrupt handlers.
Title: IMPROVED TASK START-UP AND SYSCALL RETURN
Description: Couldn't up_start_task and up_start_pthread syscalls be
eliminated. Wouldn't this work to get us from kernel-
to user-mode with a system trap:
lda r13, #address
str rn, [r13]
msr spsr_SVC, rm
ld r13,{r15}^
Would also need to set r13_USER and r14_USER. For new SYS_context_switch... couldn't we do he same thing?
Also... System calls use traps to get from user- to kernel-
mode to perform OS services. That is necessary to get from
user- to kernel-mode. But then another trap is used to get
from kernel- back to user-mode. It seems like this second
trap should be unnecessary. We should be able to do the
same kind of logic to do this.
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.
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 <c3>, Args(562,46)
Status: Open. Recommended workaround: remove mmcsd_sdio.c from
drivers/mmcsd/Make.defs. There is no SDIO support for the Z16 anyway
Priority: Low
Title: NATIVE BUILD PROBLEMS
Description: When last tested (ca.12/12), there were some missing .obj files in
arch/z16/src. A little additional TLC will be needed to get a
reliable Windows native build.
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/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 that. 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: Probably closed. The basic ARP issue has been fixed (if
CONFIG_NET_ARP_SEND is enable), but this has not been verified
with THTTPD.
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
Title: DHCPD ACCESSES KERNEL PRIVATE INTERFACE
Description: arp_update() is referenced outside of nuttx/net. It is used in
in the netutils/ DHCPD logic to set entries in the ARP table.
That is violation of the separation of kernel and OS
functionality. As a consequence, dhcpd will not work with the
NuttX kernel built.
This direct OS call needs to be replaced with a network ioctl()
call.
Status: Open
Priority: Medium. Important for full functionality with kernel build.
Title: NETWORK MONITOR NOT GENERALLY AVAILABLE
Description: The NSH network management logic has generally applicability
but is currently useful only because it is embedded in the NSH
module. It should be moved to apps/system or, better,
apps/netutils.
Status: Open
Priority: Low
o NuttShell (NSH) (apps/nshlib)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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: ARP COMMAND
Description: Add an ARP command so that we can see and modify 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 editing commands. A more generic readline() should be
implemented using termios' tcsetattr() to put the serial driver
into a "raw" mode.
Status: Open
Priority: Low (unless you are using mixed C-buffered I/O with readline and
fgetc, for example).
o Other Applications & Tests (apps/examples/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: EXAMPLES/PIPE ON CYGWIN
Description: The redirection test (part of examples/pipe) terminates
incorrectly on the Cywgin-based simulation platform (but works
fine on the Linux-based simulation platform).
Status: Open
Priority: Low
Title: EXAMPLES/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 because 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.
|