diff --git a/boards/beaglebone/ai-64/ch04.rst b/boards/beaglebone/ai-64/ch04.rst
index 2d864d18fe3c2cbdd57258a4d2b7eee781ce505b..9317d7c926f65f308f925480eb80477cf5759a57 100644
--- a/boards/beaglebone/ai-64/ch04.rst
+++ b/boards/beaglebone/ai-64/ch04.rst
@@ -97,9 +97,9 @@ much as possible. There are several significant differences between the three de
- AzureWave AW‑CM256SM
- `-`
-.. note ::
+.. todo::
- TODO: add cape compatibility details
+ add cape compatibility details
.. _beaglebone-ai-64-features-and-specificationd:
diff --git a/boards/beaglebone/ai-64/ch05.rst b/boards/beaglebone/ai-64/ch05.rst
index 4c7046f39d885f73c66b62d38d5415d7dab42e3b..128b61cf18cdf74f820295cf4eed988e635c0ebf 100644
--- a/boards/beaglebone/ai-64/ch05.rst
+++ b/boards/beaglebone/ai-64/ch05.rst
@@ -222,9 +222,9 @@ As mentioned earlier, there are two boot modes:
* **eMMC Boot:** This is the default boot mode and will allow for the fastest boot time and will enable the board to boot out of the box using the pre-flashed OS image without having to purchase an microSD card or an microSD card writer.
* **SD Boot:** This mode will boot from the microSD slot. This mode can be used to override what is on the eMMC device and can be used to program the eMMC when used in the manufacturing process or for field updates.
-.. note ::
+.. todo::
- TODO: This section needs more work and references to greater detail. Other boot modes are possible.
+ This section needs more work and references to greater detail. Other boot modes are possible.
Software to support USB and serial boot modes is not provided by beagleboard.org._Please contact TI for support of this feature.
diff --git a/boards/beaglebone/ai-64/edge_ai_apps/getting_started.rst b/boards/beaglebone/ai-64/edge_ai_apps/getting_started.rst
index 11f016b82b4adf468c752bd4d55347f226c4cd58..89313dcf14d1c7f97c1d8ad35cce5075a4f93853 100644
--- a/boards/beaglebone/ai-64/edge_ai_apps/getting_started.rst
+++ b/boards/beaglebone/ai-64/edge_ai_apps/getting_started.rst
@@ -79,7 +79,9 @@ shown below
:scale: 20
:align: center
- TODO: IMX219 CSI sensor connection with BeagleBone® AI-64 for Edge AI
+.. todo::
+
+ IMX219 CSI sensor connection with BeagleBone® AI-64 for Edge AI
Note that the headers have to be lifted up to connect the cameras
@@ -182,7 +184,9 @@ shown in the image below.
:scale: 25
:align: center
- TODO: BeagleBone® AI-64 wallpaper upon boot
+.. todo::
+
+ BeagleBone® AI-64 wallpaper upon boot
You can also view the boot log by connecting the UART cable to your PC and
use a serial port communications program.
@@ -245,4 +249,6 @@ https://code.visualstudio.com/docs/remote/ssh
:scale: 90
:align: center
- TODO: Microsoft Visual Studio Code for connecting to BeagleBone® AI-64 for Edge AI via SSH
+.. todo::
+
+ Microsoft Visual Studio Code for connecting to BeagleBone® AI-64 for Edge AI via SSH
diff --git a/boards/beaglebone/black/ch07.rst b/boards/beaglebone/black/ch07.rst
index ec1bfd3b394911fad58b8e1ecc8a4bace3e6ee0f..9835fc12d320a6b1755c246d6a38068f430a08ad 100644
--- a/boards/beaglebone/black/ch07.rst
+++ b/boards/beaglebone/black/ch07.rst
@@ -1160,6 +1160,10 @@ Each board has a debug serial interface that can be accessed by using a special
Serial Debug Header
+.. todo::
+
+ Make all figure references actual references
+
Two signals are provided, TX and RX on this connector. The levels on
these signals are 3.3V. In order to access these signals, a FTDI USB to
Serial cable is recommended as shown in *Figure 55* below.
@@ -1177,9 +1181,9 @@ The cable can be purchased from several different places and must be the
3.3V version TTL-232R-3V3. Information on the cable itself can be found
direct from FTDI at: `pdf <https://ftdichip.com/wp-content/uploads/2020/07/DS_USB_RS232_CABLES.pdf>`_
-.. note:
+.. todo::
- #TODO#: move accessory links to a single common document for all boards.
+ move accessory links to a single common document for all boards.
Pin 1 of the cable is the black wire. That must align with the pin 1 on
the board which is designated by the white dot next to the connector on
@@ -1187,6 +1191,10 @@ the board.
Refer to the support WIKI `http://elinux.org/BeagleBoneBlack <http://elinux.org/BeagleBoneBlack>`_ for more sources of this cable and other options that will work.
+.. todo::
+
+ We should include all support information in docs.beagleboard.org now and leave eLinux to others, freeing it as much as possible
+
Table is the pinout of the connector as reflected in the schematic. It is the same as the FTDI cable which can be found at `https://ftdichip.com/wp-content/uploads/2020/07/DS_USB_RS232_CABLES.pdf <https://ftdichip.com/wp-content/uploads/2020/07/DS_USB_RS232_CABLES.pdf>`_ with the exception that only three pins are used on the board. The pin numbers are defined in *Table 14*. The signals are from the perspective of the board.
.. list-table:: J1 Serial Header Pins
diff --git a/boards/beaglebone/blue/accessories.rst b/boards/beaglebone/blue/accessories.rst
index 2d2b903ab81cd4af955a6e5dd5fe174096a80df7..0dfd7543a89702f900f84ce4d6e031e705a527f9 100644
--- a/boards/beaglebone/blue/accessories.rst
+++ b/boards/beaglebone/blue/accessories.rst
@@ -3,9 +3,9 @@
Accessories
###############
-.. note::
+.. todo::
- #TODO#: We are going to work on a unified accessories page for all the boards and it should replace this.
+ We are going to work on a unified accessories page for all the boards and it should replace this.
.. _chassis_and_kits:
diff --git a/boards/beagleplay/demos-and-tutorials/zephyr-cc1352-development.rst b/boards/beagleplay/demos-and-tutorials/zephyr-cc1352-development.rst
index 20d2b150cca34a17834947305e4541d3d8a14354..f65623c50d7c1f57fb93ae55c59192e0e170e9b4 100644
--- a/boards/beagleplay/demos-and-tutorials/zephyr-cc1352-development.rst
+++ b/boards/beagleplay/demos-and-tutorials/zephyr-cc1352-development.rst
@@ -36,9 +36,9 @@ Download and install the Debian Linux operating system image for BeaglePlay.
#. Power BeaglePlay via the USB-C connector.
-.. note::
+.. todo::
- *TODO* describe how to know it is working
+ describe how to know it is working
Log into BeaglePlay
*********************************
@@ -47,9 +47,9 @@ Please either plug in a keyboard, monitor and mouse or :code:`ssh` into the boar
somewhere else for instructions on this. You can also point your web browser to the board to log
into the Visual Studio Code IDE environment.
-.. note::
+.. todo::
- *TODO* A big part of what is missing here is to put your BeaglePlay on the Internet such
+ A big part of what is missing here is to put your BeaglePlay on the Internet such
that we can download things in later steps. That has been initially brushed over.
Flash existing IEEE 802.15.4 radio bridge (WPANUSB) firmware
@@ -357,8 +357,8 @@ Build applications for BeagleConnect Freedom
west build -d build/greybus modules/lib/greybus/samples/subsys/greybus/net -- -DOVERLAY_CONFIG=overlay-802154-subg.conf
-Flash applications to BeagleConnect Freedom from BeagleBone Green Gateway
-=========================================================================
+Flash applications to BeagleConnect Freedom
+===========================================
And then you can flash the BeagleConnect Freedom boards over USB
@@ -375,4 +375,6 @@ And then you can flash the BeagleConnect Freedom boards over USB
Debug applications over the serial terminal
===========================================
-#TODO#
+.. todo::
+
+ Describe how to handle the serial connection
diff --git a/boards/capes/cape-interface-spec.rst b/boards/capes/cape-interface-spec.rst
index 2dc957b7d6dab48fd490722890b9d1d1cbc7d400..58a3d601e521637ec33e2ac44bb0f41846850ef3 100644
--- a/boards/capes/cape-interface-spec.rst
+++ b/boards/capes/cape-interface-spec.rst
@@ -501,7 +501,7 @@ SPI bone bus nodes allow creating compatible overlays for Black, AI and AI-64.
See https://stackoverflow.com/questions/53634892/linux-spidev-why-it-shouldnt-be-directly-in-devicetree for
more background. A custom overlay is required to overload the compatible string to load a non-spidev driver.
-.. note:: #TODO# figure out if BONE-SPI0_0 and BONE-SPI0_1 can be loaded at the same time
+.. todo:: figure out if BONE-SPI0_0 and BONE-SPI0_1 can be loaded at the same time
.. code-block:: c
:linenos:
@@ -666,8 +666,11 @@ CAN bone bus nodes allow creating compatible overlays for Black, AI and AI-64.
ADC
*******
-* TODO: We need a udev rule to make sure the ADC shows up at /dev/bone/adc! There's nothing for sure that IIO devices will show up in the same place.
-* TODO: I think we can also create symlinks for each channel based on which device is there, such that we can do /dev/bone/adc/Px_y
+.. todo:: We need a udev rule to make sure the ADC shows up at /dev/bone/adc! There's nothing for sure that IIO devices will show up in the same place.
+
+.. todo:: I think we can also create symlinks for each channel based on which device is there, such that we can do /dev/bone/adc/Px_y
+
+.. todo:: I believe a multiplexing IIO driver is the future solution
.. table:: ADC pins
@@ -940,7 +943,7 @@ On BeagleBone's without an eQEP on specific pins, consider using the PRU to perf
eCAP
-------
-#TODO: This doesn't include any abstraction yet.
+.. todo:: This doesn't include any abstraction yet.
.. table:: ECAP pins
@@ -1318,9 +1321,7 @@ The overlay situation for PRUs is a bit more complex than with other peripherals
GPIO
----------
-TODO<br>
-For each of the pins with a GPIO, there should be a symlink that comes from the names
-*
+.. todo:: For each of the pins with a GPIO, there should be a symlink that comes from the names
.. _bone-methodology:
@@ -1365,7 +1366,12 @@ TBD
Verification
----------------
-TODO: The steps used to verify all of these configurations is to be documented here. It will serve to document what has been tested, how to reproduce the configurations, and how to verify each major triannual release. All faults will be documented in the issue tracker.
+.. todo::
+
+ The steps used to verify all of these configurations is to be documented
+ here. It will serve to document what has been tested, how to reproduce the
+ configurations, and how to verify each major triannual release. All faults
+ will be documented in the issue tracker.
References
-------------
diff --git a/intro/contribution/index.rst b/intro/contribution/index.rst
index b1ac606d37fe3e3e2c96641cca3e588d863205e8..2c3a9d630350a6cf60e6dcaa5bc4921a98a75c94 100644
--- a/intro/contribution/index.rst
+++ b/intro/contribution/index.rst
@@ -66,15 +66,28 @@ The most obvious way to contribute is using the `git.beagleboard.org Gitlab serv
bugs, suggest enhancements and providing merge requests, also called pull requests, the provide fixes to software, hardware
designs and documentation.
+This documentation has a number of ``todo`` items where help is needed:
+
+.. todolist::
+
Reporting bugs
===============
+.. todo::
+ Describe where and how to report issues on git.beagleboard.org
+
Suggesting enhancements
=======================
+.. todo::
+ Describe how to introduct ideas on forum.beagleboard.org and git.beagleboard.org
+
Submitting merge requests
=========================
+.. todo::
+ Describe how to introduct ideas on forum.beagleboard.org and git.beagleboard.org
+
Style and usage guidelines
**************************
diff --git a/intro/contribution/linux-upstream.rst b/intro/contribution/linux-upstream.rst
index 5768053c6ea815af6eeebfdb2a84a2b88497ead2..106d4bf6d7f842081c5f8e20701afd92d42f0f38 100644
--- a/intro/contribution/linux-upstream.rst
+++ b/intro/contribution/linux-upstream.rst
@@ -145,17 +145,17 @@ Device Drivers in Embedded Systems
I used the term "Drivers" in the above section, but what does it really mean?
-**Why "device" drivers?**
+.. todo::
-TODO
+ **Why "device" drivers?**
-**Why do we need drivers?**
+.. todo::
-TODO
+ **Why do we need drivers?**
-**What do drivers look like?**
+.. todo::
-TODO
+ **What do drivers look like?**
.. _linux-upstream-device-trees: