diff --git a/beaglebone-ai-64/ch04.rst b/beaglebone-ai-64/ch04.rst
index 0bf90a6198d8b35b1cb6c4c4ce7eb903ca7e4141..866f1a780d81aa60debd87d385439060de86c407 100644
--- a/beaglebone-ai-64/ch04.rst
+++ b/beaglebone-ai-64/ch04.rst
@@ -27,7 +27,7 @@ BeagleBone AI-64 is manufactured and warranted by partners listed at https://bea
* Mark Yoder, professor at Rose-Hulman Institute of Technology
* Kathy Giori, product engineer at ZEDEDA
-See bbb.io/about
+See `bbb.io/about <bbb.io/about>`_
BeagleBone AI-64 has been designed by Seeed Studio (Seeed Development Limited) under guidance from BeagleBoard.org Foundation.
diff --git a/beagleconnect/ch01.rst b/beagleconnect/ch01.rst
new file mode 100644
index 0000000000000000000000000000000000000000..c3f20dbae330b1e2ab8366c85e3b98edb0a68bc1
--- /dev/null
+++ b/beagleconnect/ch01.rst
@@ -0,0 +1,262 @@
+***************************
+BeagleConnectâ„¢ Introduction
+***************************
+
+
+
+BeagleConnectâ„¢ is a revolutionary technology virtually eliminating low-level
+software development for `IoT <https://en.wikipedia.org/wiki/Internet_of_things>`_
+and `IIoT <https://en.wikipedia.org/wiki/Industrial_internet_of_things>`_
+applications, such as building automation, factory automation, home automation,
+and scientific data acquisition. While numerous IoT and IIoT solutions
+available today provide massive software libraries for microcontrollers
+supporting a limited body of `sensors <https://en.wikipedia.org/wiki/Sensor>`_,
+`actuators <https://en.wikipedia.org/wiki/Actuator>`_ and `indicators <https://en.wikipedia.org/wiki/Indicator_(distance_amplifying_instrument)>`_
+as well as libraries for communicating over various networks, BeagleConnect
+simply eliminates the need for these libraries by shifting the burden into the
+most massive and collaborative software project of all time, the `Linux kernel <https://en.wikipedia.org/wiki/Linux_kernel>`_.
+
+.. image:: media/bcf-c5-boards.jpg
+ :width: 600
+ :align: center
+ :height: 400
+ :alt: BeagleConnect Freedom C5 Boards
+
+These are the tools used to automate things in
+`scientific data collection <https://en.wikipedia.org/wiki/Data_collection_system>`_,
+`data science <https://en.wikipedia.org/wiki/Data_science>`_,
+`mechatronics <https://en.wikipedia.org/wiki/Mechatronics>`_,
+and `IoT <https://en.wikipedia.org/wiki/Internet_of_things>`_.
+
+BeagleConnectâ„¢ technology solves:
+
+* The need to write software to add a large set of diverse devices to your
+ system,
+* The need to maintain the software with security updates,
+* The need to rapidly prototype using off-the-shelf software and hardware
+ without wiring,
+* The need to connect to devices using long-range, low-power wireless, and
+* The need to produce high-volume custom hardware cost-optimized for your
+ requirements.
+
+BeagleConnectâ„¢ Experience
+#########################
+
+BeagleConnectâ„¢ provides a scalable experience for interacting with the physical
+world.
+
+Note: The term BeagleConnectâ„¢ refers to a technology comprising of a family of
+boards, a collection of Linux kernel drivers, microcontroller firmware, a
+communication protocol, and system-level integration to automation software
+tools. More specific terms will be applied in the architecture details. The
+term is also used here to represent the experience introduced to users through
+the initial BeagleConnectâ„¢ Freedom product consisting of a board and case which
+ships programmed and ready to be used.
+
+
+
+For scientists, we are integrating `Jupyter Notebook <https://jupyter.org/>`_
+with the data streams from any of hundreds of sensor options, including
+`vibration <https://www.mikroe.com/click/sensors/force>`_,
+`gas detection <https://www.mikroe.com/click/sensors/gas>`_,
+`biometrics <https://www.mikroe.com/click/sensors/biometrics>`_ and
+`more <https://www.mikroe.com/click/sensors>`_. These data streams can be
+stored in simple `data files <https://en.wikipedia.org/wiki/Comma-separated_values>`
+or processed and visualized.
+
+#TODO: provide images demonstrating Jupyter Notebook visualization
+
+For embedded systems developers, data is easily extracted using the standard IIO
+interface provided by the Linux kernel running on the gateway using any of
+hundreds of programming languages and environments, without writing a line of
+microcontroller firmware. The Linux environment provides opportunities for
+high-level remote management using tools like Balena with applications deployed
+in Docker containers.
+
+#TODO: provide image illustrating remote management
+
+The hardware and software are fully open source, providing for scalability and
+a lack of vendor lock-in.
+
+For DevOps…
+
+For home automaters, integration into WebThings…
+
+#TODO: think a bit more about this section with some feedback from Cathy.
+
+BeagleConnectâ„¢ hardware
+#######################
+
+BeagleConnectâ„¢ Freedom
+**********************
+
+.. image:: media/image1.jpg
+ :width: 600
+ :align: center
+ :height: 400
+ :alt: BeagleConnect-Freedom-C5-HandPhoto
+
+Important: BeagleConnectâ„¢ Freedom enables wirelessly adding new device nodes
+and is targeted to cost initially around US$20 with a roadmap to variants as
+low as US$1.
+
+The initial BeagleConnectâ„¢ Freedom production release will:
+
+* Support at least 100 mikroBUS-based Click boards from Mikroelectronika
+* Work with Bluetooth Low Energy (BLE)-enabled Linux computers at 2.4GHz
+* Work with long-range sub-1GHz IEEE 802.15.4 wireless connections at 500
+ meters with data rates of 1kbps, and
+* Work with a low-cost BeagleBoard.org Linux single-board computer (SBC) as a
+ BeagleConnectâ„¢ gateway device and work with at least 10 other BeagleConnectâ„¢
+ node devices each supporting 2 add-on sensor, actuator or indicator devices.
+
+Future releases will be collaborated with the community, evolve dynamically,
+and contain additional functionality. The goal is to support over 500 add-on
+devices within the first year after the initial release.
+
+BeagleConnectâ„¢ Freedom beta kit
+*******************************
+
+A small number of beta kits have been assembled with BeagleConnectâ„¢ Freedom
+rev C5 boards, which is the version that should be taken to production.
+
+The kit includes:
+
+* 1x `Seeed BeagleBone® Green Gateway <https://wiki.seeedstudio.com/BeagleBone-Green-Gateway/>`_ (board, USB cable)
+* 3x BeagleConnectâ„¢ Freedom (board, attenna, USB cable)
+* 1x `Mikroelectronika Click ID Board <https://www.mikroe.com/unique-id-click>`_
+
+To get started with this kit, see [demo-1].
+
+
+BeagleConnectâ„¢ Mobile Gateway
+#############################
+
+This is a work-in-progress that will be released as the first integrated
+BeagleConnectâ„¢ gateway. It is possible to assemble a gateway with any Linux
+computer, but this computer will ship setup and ready to go.
+
+The gateway is built from:
+
+* BeagleBoard.org PocketBeagle,
+* BeagleConnectâ„¢ Freedom,
+* a cellular modem,
+* a USB WiFi dongle,
+* antennas, and
+* an enclosure.
+
+Architecture
+************
+BeagleConnectâ„¢ Freedom
+**********************
+BeagleConnectâ„¢ Freedom is based on the `TI CC1352 <https://www.ti.com/product/CC1352R>`_
+and is the first available BeagleConnectâ„¢ solution. It implements:
+
+* BeagleConnectâ„¢ gateway device function for Sub-GHz 802.15.4 long-range
+ wireless
+* BeagleConnectâ„¢ node device function for Bluetooth Low-Energe (BLE) and
+ Sub-GHz 802.15.4 long range wireless
+* USB-based serial console and firmware updates
+* 2x `mikroBUS sockets <https://www.mikroe.com/mikrobus>`_ with BeagleConnectâ„¢
+ protocol support
+
+#TODO: provide image of BeagleConnectâ„¢ Freedom in a case with a hand for size perspective
+
+What makes BeagleConnectâ„¢ new and different?
+********************************************
+Important: BeagleConnectâ„¢ solves IoT in a different and better way than any
+previous solution.
+
+The device interface software is already done
+*********************************************
+
+BeagleConnectâ„¢ uses the collaboratively developed Linux kernel to contain the
+intelligence required to speak to these devices (sensors, actuators, and
+indicators), rather than relying on writing code on a microcontroller specific
+to these devices. Some existing solutions rely on large libraries of
+microcontroller code, but the integration of communications, maintenance of the
+library with a limited set of developer resources and other constraints to be
+explained later make those other solutions less suitable for rapid prototyping
+than BeagleConnectâ„¢.
+
+Linux presents these devices abstractly in ways that are self-descriptive. Add
+an accelerometer to the system and you are automatically fed a stream of force
+values in standard units. Add a temperature sensor and you get it back in
+standard units again. Same for sensing magnetism, proximity, color, light,
+frequency, orientation, or multitudes of other inputs. Indicators, such as LEDs
+and displays, are similarly abstracted with a few other kernel subsystems and
+more advanced actuators with and without feedback control are in the process of
+being developed and standardized. In places where proper Linux kernel drivers
+exist, no new specialized code needs to be created for the devices.
+
+Important: *Bottom line*: For hundreds of devices, users won't have to write a
+single line of code to add them their systems. The automation code they do
+write can be extremely simple, done with graphical tools or in any language
+they want. Maintenance of the code is centralized in a small reusable set of
+microcontroller firmware and the Linux kernel, which is highly peer reviewed
+under a `highly-regarded governance model <https://wiki.p2pfoundation.net/Linux_-_Governance>`_.
+
+On-going maintenance
+********************
+
+Because there isn't code specific to any given network-of-devices configuration
+, we can all leverage the same software code base. This means that when someone
+fixes an issue in either BeagleConnectâ„¢ firmware or the Linux kernel, you
+benefit from the fixes. The source for BeagleConnectâ„¢ firmware is also
+submitted to the `Zephyr Project <https://www.zephyrproject.org/>`_ upstream,
+further increasing the user base. Additionally, we will maintain stable
+branches of the software and provide mechanisms for updating firmware on
+BeagleConnectâ„¢ hardware. With a single, relatively small firmware load, the
+potential for bugs is kept low. With large user base, the potential for
+discovering and resolving bugs is high.
+
+Rapid prototyping without wiring
+********************************
+
+BeagleConnectâ„¢ utilizes the `mikroBUS standard <https://elinux.org/Mikrobus>`_.
+The mikroBUS standard interface is flexible enough for almost any typical
+sensor or indicator with hundreds of devices available.
+
+Note: Currently, we have support in the Linux kernel for a bit over 100 Click
+mikroBUS add-on boards from Mikroelektronika and are working with
+Mikroelektronika on a updated version of the specification for these boards to
+self-identify. Further, eventually the vast majority of over 800 currently
+available Click mikroBUS add-on boards will be supported as well as the
+hundreds of compliant boards developed every year.
+
+Long-range, low-power wireless
+******************************
+
+BeagleConnectâ„¢ Freedom wireless hardware is built around a
+`TI CC1352 <http://www.ti.com/product/CC1352R>`_ multiprotocol and multi-band
+Sub-1 GHz and 2.4-GHz wireless microcontroller (MCU). CC1352R includes a 48-MHz
+Arm® Cortex®-M4F processor, 352KB Flash, 256KB ROM, 8KB Cache SRAM, 80KB of
+ultra-low leakage SRAM, and `Over-the-Air <https://en.wikipedia.org/wiki/Over-the-air_programming>`_
+upgrades (OTA).
+
+Full customization possible
+***************************
+
+BeagleConnectâ„¢ utilizes `open source hardware <https://www.oshwa.org/definition/>`_
+and `open source software <https://en.wikipedia.org/wiki/Open-source_software>`_,
+making it possible to optimize hardware and software implementations and
+sourcing to meet end-product requirements. BeagleConnectâ„¢ is meant to enable
+rapid-prototyping and not to necessarily satisfy any particular end-product’s
+requirements, but with full considerations for go-to-market needs.
+
+Each BeagleBoard.org BeagleConnectâ„¢ solution will be:
+
+* Readily available for over 10 years,
+* Built with fully open source software with submissions to mainline Linux and
+ Zephyr repositories to aide in support and porting,
+* Built with fully open source and non-restrictive hardware design including
+ schematic, bill-of-materials, layout, and manufacturing files (with only the
+ BeagleBoard.org logo removed due to licensing restrictions of our brand),
+* Built with parts where at least a compatible part is available from worldwide
+ distributors in any quantity,
+* Built with design and manufacturing partners able to help scale derivative
+ designs,
+* Based on a security model using public/private keypairs that can be replaced
+ to secure your own network, and
+* Fully FCC/CE certified.
+
diff --git a/beagleconnect/ch02.rst b/beagleconnect/ch02.rst
new file mode 100644
index 0000000000000000000000000000000000000000..0c6aa20a8aae3984433d235ba5f3520924e4fb44
--- /dev/null
+++ b/beagleconnect/ch02.rst
@@ -0,0 +1,5 @@
+.. _beagleconnect-Change-History:
+
+**************
+Change History
+**************
diff --git a/beagleconnect/ch03.rst b/beagleconnect/ch03.rst
new file mode 100644
index 0000000000000000000000000000000000000000..6b71fc207ec0a7f348f770858fbc7ca2f9c58969
--- /dev/null
+++ b/beagleconnect/ch03.rst
@@ -0,0 +1,127 @@
+.. _beagleconnect-Usage:
+
+********************
+BeagleConnectâ„¢ Usage
+********************
+
+
+
+This section describes the usage model we are developing. To use the current
+code in development, please refer to the [development] section.
+
+
+BeagleConnectâ„¢ wireless user experience
+#######################################
+
+Enable a Linux host with BeagleConnectâ„¢
+***************************************
+.. image:: media/ProvStep1.jpg
+ :width: 600
+ :align: center
+ :height: 400
+ :alt: ProvStep1
+
+Log into a host system running Linux that is BeagleConnectâ„¢ enabled. Enable a
+Linux host with BeagleConnectâ„¢ by plugging a **BeagleConnectâ„¢ gateway device**
+into it’s USB port. You’ll also want to have a **BeagleConnect™ node device**
+with a sensor, actuator or indicator device connected.
+
+Note: BeagleConnectâ„¢ Freedom can act as either a BeagleConnectâ„¢ gateway device
+or a BeagleConnectâ„¢ node device.
+
+Important: The Linux host will need to run the BeagleConnectâ„¢ management
+software, most of which is incorporated into the Linux kernel. Support will be
+provided for BeagleBoard and BeagleBone boards, x86 hosts, and Raspberry Pi.
+
+TODO: Clean up images
+
+Connect host and device
+***********************
+.. image:: media/ProvStep2.jpg
+ :width: 600
+ :align: center
+ :height: 400
+ :alt: ProvStep2
+Initiate a connection between the host and devices by pressing the discovery
+button(s).
+
+Device data shows up as files
+*****************************
+.. image:: media/ProvStep3.jpg
+ :width: 600
+ :align: center
+ :height: 400
+ :alt: ProvStep3
+New streams of self-describing data show up on the host system using native
+device drivers.
+
+High-level applications, like Node-RED, can directly read/write these
+high-level data streams (including data-type information) to Internet-based
+`MQTT <https://mqtt.org/>`_ brokers, live dashboards, or other logical
+operations without requiring any sensor-specific coding. Business logic can be
+applied using simple if-this-then-that style operations or be made as complex
+as desired using virtually any programming language or environment.
+
+Components
+##########
+BeagleConnectâ„¢ enabled host Linux computer, possibly single-board computer
+(SBC), with BeagleConnectâ„¢ management software and BeagleConnectâ„¢ gateway
+function. BeagleConnectâ„¢ gateway function can be provided by a BeagleConnectâ„¢
+compatible interface or by connecting a BeagleConnectâ„¢ gateway device over USB.
+
+Note: If the Linux host has BLE, the BeagleConnectâ„¢ is optional for short
+distances
+
+BeagleConnectâ„¢ Freedom Board, case, and wireless MCU with Zephyr based firmware
+for acting as either a BeagleConnectâ„¢ gateway device or BeagleConnectâ„¢ node
+device.
+* In BeagleConnectâ„¢ gateway device mode: Provides long-range, low-power
+ wireless communications, Connects with the host via USB and an associated
+ Linux kernel driver, and is powered by the USB connector.
+* In BeagleConnectâ„¢ node device mode: Powered by a battery or USB connector
+ Provides 2 mikroBUS connectors for connecting any of hundreds of `Click Board <https://bbb.io/click>`_
+ mikroBUS add-on devices Provides new Linux host controllers for SPI, I2C,
+ UART, PWM, ADC, and GPIO with interrupts via Greybus
+
+**BeagleConnectâ„¢ gateway device**
+
+Provides a BeagleConnectâ„¢ compatible interface to a host. This could be a
+built-in interface device or one connected over USB. BeagleConnectâ„¢ Freedom can
+provide this function.
+
+**BeagleConnectâ„¢ node device**
+
+Utilizes a BeagleConnectâ„¢ compatible interface and TODO
+
+**BeagleConnectâ„¢ compatible interface**
+
+Immediate plans are to support Bluetooth Low Energy (BLE), 2.4GHz IEEE 802.15.4
+, and Sub-GHz IEEE 802.15.4 wireless interfaces. A built-in BLE interface is
+suitable for this at short range, whereas IEEE 802.15.4 is typically
+significantly better at long ranges. Other wired interfaces, such as CAN and
+RS-485, are being considered for future BeagleConnectâ„¢ gateway device and
+BeagleConnectâ„¢ node device designs.
+
+**Greybus**
+
+TODO
+
+#TODO: Find a place for the following notes:
+
+* The device interfaces get exposed to the host via Greybus BRIDGED_PHY
+ protocol
+* The I2C bus is probed for a an identifier EEPROM and appropriate device
+ drivers are loaded on the host
+* Unsupported Click Boards connected are exposed via userspace drivers on the
+ host for development
+
+What’s different
+################
+
+So, in summary, what is so different with this approach?
+
+* No microcontroller code development is required by users
+* Userspace drivers make rapid prototyping really easy
+* Kernel drivers makes the support code collaborative parts of the Linux kernel
+ , rather than cut-and-paste
+
diff --git a/beagleconnect/ch04.rst b/beagleconnect/ch04.rst
new file mode 100644
index 0000000000000000000000000000000000000000..8edad82f729975733326dfbdef52a08e582450b8
--- /dev/null
+++ b/beagleconnect/ch04.rst
@@ -0,0 +1,246 @@
+.. _beagleconnect-connectivity:
+
+*******************************
+BeagleConnectâ„¢ Freedom & Zephyr
+*******************************
+
+Develop for BeagleConnectâ„¢ Freedom with Zephyr
+##############################################
+
+Developing directly in Zephyr will not be ultimately required for end-users
+who won't touch the firmware running on BeagleConnectâ„¢ Freedom and will instead
+use the BeagleConnectâ„¢ Greybus functionality, but is important for early
+adopters as well as people looking to extend the functionality of the open
+source design. If you are one of those people, this is a good place to get
+started.
+
+Equipment to begin development
+******************************
+
+There are many options, but let's get started with one recommended set for the beta users.
+
+Required
+--------
+
+* beta-kit
+ * Seeed Studio BeagleBone® Green Gateway
+
+ * 3x BeagleConnectâ„¢ Freedom board, antenna, U.FL to SMA cable, SMA antenna and USB Type-A to Type-C cable
+
+ * 1x MikroE ID Click
+
+* microSD card (6GB or larger)
+
+* microSD card programmer
+
+Recommended
+-----------
+
+* `12V power brick <https://smile.amazon.com/TMEZON-Power-Adapter-Supply-2-1mm/dp/B00Q2E5IXW>`_
+
+* `USB to TTL 3.3V UART adapter <https://smile.amazon.com/Converter-Terminated-Galileo-BeagleBone-Minnowboard/dp/B06ZYPLFNB>`_
+
+* Ethernet cable and Internet connection
+
+* 2x USB power adapters
+
+* `BME280-based Weather Click <https://www.mikroe.com/weather-click>`_
+
+* `iAQ-Core-based Air Quality 2 Click <https://www.mikroe.com/air-quality-2-click>`_
+
+Optional
+--------
+
+* x86_64 computer running Ubuntu 20.04.3 LTS
+
+
+Install the latest software image for BeagleBone Green Gateway
+**************************************************************
+
+Download and install the Debian Linux operating system image for the Seeed
+BeagleBone® Green Gateway host.
+
+#. Download the special mikroBUS/Greybus BeagleBoard.org Debian image from
+ `here <https://rcn-ee.net/rootfs/debian-mikrobus-armhf/>`_. Pick the most
+ recent directory and select the file beginning with **bone-** and ending with
+ **.img.xz**. Today that file is
+ **bone-debian-11.2-iot-mikrobus-armhf-2022-03-04-4gb.img.xz**.
+
+#. Load this image to a microSD card using a tool like Etcher.
+
+#. Insert the microSD card into the Green Gateway.
+
+#. Power BeagleBone Green Gateway via the 12V barrel jack.
+
+#TODO: describe how to know it is working
+
+Log into BeagleBone Green Gateway
+*********************************
+
+These instructions assume an x86_64 computer runing Ubuntu 20.04.3 LTS, but any
+computer can be used to connect to your BeagleBone Green Gateway.
+
+#. Log onto the Seeed BeagleBone® Green Gateway using :code:`ssh`.
+ * We need IP address, Username, and Password to connect to the device.
+ * The default IP for the BeagleBone hardware is :code:`192.168.7.2`
+ * The default Username is :code:`debian` & Password is :code:`temppwd`
+ * To connect you can simply type :code:`$ ssh debian@192.168.7.2` and when
+ asked for password just type :code:`temppwd`
+ * Congratulations, You are now connected to the device!
+
+#. Connect to the `WiFi <https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots/31280>`_
+ * Execute :code:`sudo nano /etc/wpa_supplicant/wpa_supplicant-wlan0.conf`
+ and provide the password :code:`temppwd` to edit the configuration file
+ for the WiFi connection.
+ * Now edit the file (shown below) under the :code:`network={...}`
+ section you can set you :code:`ssid` (WiFi name) and :code:`psk` (Wifi
+ Password).
+ .. code-block::
+
+ ctrl_interface=DIR=/run/wpa_supplicant GROUP=netdev
+ update_config=1
+ #country=IN
+ network={
+ ssid="WiFi Name"
+ psk="WiFi Password"
+ }
+ * Now save the file with :code:`CTRL+O` and exit with :code:`CTRL+X`.
+ * Check if the connection is established by executing :code:`$ ping 8.8.8.8`
+ you should see something like shown below.
+ .. code-block:: bash
+
+ debian@BeagleBone:~$ ping 8.8.8.8
+ PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
+ 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=10.5 ms
+ 64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=5.72 ms
+ 64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=6.13 ms
+ 64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=6.11 ms
+ ...
+ * If everything goes well, you are ready to update your system and install
+ new applications for beagleconnect.
+
+Note: If you are facing some issue during boot then you can try debugging the
+boot session with a USB to serial interface cable such as those made by FTDI
+plugged into J10 with the black wire of the FTDI cable toward the Ethernet
+connector. Application like tio/minicom/putty can be used to make the connection
+establishment procedure easy.
+
+TODO: Simplify and elaborate on this section, add boot session debugging walkthrough
+
+Install Zephyr development tools on BeagleBone Green Gateway
+************************************************************
+
+#. Update the system.
+ .. code-block:: bash
+
+ sudo apt update
+
+#. Install all BeagleConnectâ„¢ management software.
+ .. code-block:: bash
+
+ sudo apt install -y \
+ beagleconnect beagleconnect-msp430 \
+ git vim \
+ build-essential \
+ cmake ninja-build gperf \
+ ccache dfu-util device-tree-compiler \
+ make gcc libsdl2-dev \
+ libxml2-dev libxslt-dev libssl-dev libjpeg62-turbo-dev \
+ gcc-arm-none-eabi libnewlib-arm-none-eabi \
+ libtool-bin pkg-config autoconf automake libusb-1.0-0-dev \
+ python3-dev python3-pip python3-setuptools python3-tk python3-wheel
+
+ .. code-block:: bash
+
+ echo "export PATH=$PATH:$HOME/.local/bin" >> $HOME/.bashrc
+
+ .. code-block:: bash
+
+ source $HOME/.bashrc
+
+#. Reboot
+ .. code-block:: bash
+
+ sudo reboot
+
+#. Install BeagleConnectâ„¢ flashing software
+ .. code-block:: bash
+
+ pip3 install -U west
+
+#. Reboot
+ .. code-block:: bash
+
+ sudo reboot
+
+#. Download and setup Zephyr for BeagleConnectâ„¢
+ .. code-block:: bash
+
+ cd
+ west init -m https://github.com/jadonk/zephyr --mr bcf-sdk-3.1.0-rebase bcf-zephyr
+ cd $HOME/bcf-zephyr
+ west update
+ west zephyr-export
+ pip3 install -r zephyr/scripts/requirements-base.txt
+ echo "export CROSS_COMPILE=/usr/bin/arm-none-eabi-" >> $HOME/.bashrc
+ echo "export ZEPHYR_BASE=$HOME/bcf-zephyr/zephyr" >> $HOME/.bashrc
+ echo "export PATH=$HOME/bcf-zephyr/zephyr/scripts:$PATH" >> $HOME/.bashrc
+ echo "export BOARD=beagleconnect_freedom" >> $HOME/.bashrc
+ source $HOME/.bashrc
+
+Build applications for BeagleConnect Freedom on BeagleBone Green Gateway
+************************************************************************
+
+Now you can build various Zephyr applications
+
+#. Change directory to BeagleConnect Freedom zephyr repository.
+ .. code-block:: bash
+
+ cd $HOME/bcf-zephyr
+
+#. Build blinky example
+ .. code-block:: bash
+ west build -d build/blinky zephyr/samples/basic/blinky
+
+
+
+#. TODO
+ .. code-block:: bash
+
+ west build -d build/sensortest zephyr/samples/boards/beagle_bcf/sensortest -- -DOVERLAY_CONFIG=overlay-subghz.conf
+
+#. TODO
+ .. code-block:: bash
+
+ west build -d build/wpanusb modules/lib/wpanusb_bc -- -DOVERLAY_CONFIG=overlay-subghz.conf
+
+#. TODO
+ .. code-block:: bash
+
+ west build -d build/bcfserial modules/lib/wpanusb_bc -- -DOVERLAY_CONFIG=overlay-bcfserial.conf -DDTC_OVERLAY_FILE=bcfserial.overlay
+
+#. TODO
+ .. code-block:: bash
+
+ 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
+*************************************************************************
+
+And then you can flash the BeagleConnect Freedom boards over USB
+
+#. Make sure you are in Zephyr directory
+ .. code-block:: bash
+
+ cd $HOME/bcf-zephyr
+
+#. Flash Blinky
+ .. code-block:: bash
+
+ cc2538-bsl.py build/blinky
+
+Debug applications over the serial terminal
+*******************************************
+
+#TODO
diff --git a/beagleconnect/ch05.rst b/beagleconnect/ch05.rst
new file mode 100644
index 0000000000000000000000000000000000000000..0ecccae0b6a9e86aacc47161bcf23580e40fa782
--- /dev/null
+++ b/beagleconnect/ch05.rst
@@ -0,0 +1,1108 @@
+.. _beagleconnect-overview:
+
+***********************
+BeagleConnectâ„¢ Overview
+***********************
+
+BeagleConnectâ„¢ Greybus Stack
+############################
+
+Work in progress
+****************
+
+To understand a bit more about how the BeagleConnectâ„¢ Greybus stack is being
+built, this section helps describe the development currently in progress and
+the principles of operation.
+
+Background
+**********
+.. image:: media/SoftwareProp.jpg
+ :width: 600
+ :align: center
+ :height: 400
+ :alt: BeagleConnect Software Proposition
+
+BeagleConnectâ„¢ uses Greybus and updated Click Boards with identifiers to
+eliminate the need to add and manually configure devices added onto the Linux
+system.
+
+High-level
+**********
+* For Linux nerds: Think of BeagleConnectâ„¢ as 6LoWPAN over 802.15.4-based
+ Greybus (instead of Unipro as used by Project Ara), where every
+ BeagleConnectâ„¢ board shows up as new SPI, I2C, UART, PWM, ADC, and GPIO
+ controllers that can now be probed to load drivers for the sensors or
+ whatever is connected to them. (Proof of concept of Greybus over TCP/IP:
+ https://www.youtube.com/watch?v=7H50pv-4YXw)
+
+* For MCU folks: Think of BeagleConnectâ„¢ as a Firmata-style firmware load that
+ exposes the interfaces for remote access over a secured wireless network.
+ However, instead of using host software that knows how to speak the Firmata
+ protocol, the Linux kernel speaks the slightly similar Greybus protocol to
+ the MCU and exposes the device generically to users using a Linux kernel
+ driver. Further, the Greybus protocol is spoken over 6LoWPAN on 802.15.4.
+
+Software architecture
+*********************
+
+.. image:: media/bcf_block_diagram.svg
+ :width: 600
+ :align: center
+ :height: 400
+ :alt: BeagleConnect Block Diagram
+
+TODO items
+**********
+
+* Linux kernel driver
+
+* Provisioning
+
+* Firmware for host CC13x
+
+* Firmware for device CC13x
+
+* Click Board drivers and device tree formatted metadata for 100 or so Click
+ Boards
+
+* Click Board plug-ins for node-red for the same 100 or so Click Boards
+
+* BeagleConnectâ„¢ Freedom System Reference Manual and FAQs
+
+
+Associated pre-work
+*******************
+
+* Click Board support for Node-RED can be executed with native connections on
+ PocketBeagle+TechLab and BeagleBone Black with mikroBUS Cape
+
+* Device tree fragments and driver updates can be provided via
+ https://bbb.io/click
+
+* The Kconfig style provisioning can be implemented for those solutions, which
+ will require a reboot. We need to centralize edits to /boot/uEnv.txt to be
+ programmatic. As I think through this, I don't think BeagleConnect is
+ impacted, because the Greybus-style discovery along with Click EEPROMS will
+ eliminate any need to edit /boot/uEnv.txt.
+
+User experience concerns
+************************
+
+* Make sure no reboots are required
+
+* Plugging BeagleConnect into host should trigger host configuration
+
+* Click EEPROMs should trigger loading whatever drivers are needed and
+ provisioning should load any new drivers
+
+* Userspace (spidev, etc.) drivers should unload cleanly when 2nd phase
+ provisioning is completed
+
+BeagleConnectâ„¢ Greybus demo using BeagleConnectâ„¢ Freedom
+********************************************************
+BeagleConnectâ„¢ Freedom runs a subGHz IEEE 802.15.4 network. This BeagleConnectâ„¢
+Greybus demo shows how to interact with GPIO, I2C and mikroBUS add-on boards
+remotely connected over a BeagleConnectâ„¢ Freedom.
+
+This section starts with the steps required to use
+`Linux <https://en.wikipedia.org/wiki/Linux>`_ embedded computer
+(`BeagleBone Green Gateway <https://wiki.seeedstudio.com/BeagleBone-Green-Gateway/>`_)
+and the `Greybus <https://lwn.net/Articles/715955/>`_ protocol, over an
+IEEE 802.15.4 wireless link, to blink an LED on a
+`Zephyr <https://zephyrproject.org/>`_ device.
+
+Introduction
+************
+
+Why??
+-----
+
+
+Good question. Blinking an LED is kind of the
+`Hello, World <https://en.wikipedia.org/wiki/%22Hello,_World!%22_program>`_ of
+the hardware community. In this case, we're less interested in the mechanics
+of switching a GPIO to drive some current through an LED and more interested in
+how that happens with the
+`Internet of Things (IoT) <https://en.wikipedia.org/wiki/Internet_of_things>`_.
+
+There are several existing network and application layers that are driven by
+corporate heavyweights and industry consortiums, but relatively few that are
+community driven and, more specifically, even fewer that have the ability to
+integrate so tightly with the Linux kernel.
+
+The goal here is to provide a community-maintained, developer-friendly, and
+open-source protocol for the Internet of Things using the Greybus Protocol, and
+blinking an LED using Greybus is the simplest proof-of-concept for that. All
+that is required is a reliable transport.
+
+#. Power a BeagleConnect Freedom that has not yet been programmed via a USB
+ power source, not the BeagleBone Green Gateway. You'll hear a click every
+ 1-2 seconds along with seeing 4 of the LEDs turn off and on.
+
+#. In an isolated terminal window, :code:`sudo beagleconnect-start-gateway`
+
+#. :code:`sensortest-rx.py`
+
+Every 1-2 minutes, you should see something like:
+
+.. code-block::
+
+ ('fe80::3111:7a22:4b:1200%lowpan0', 52213, 0, 13) '2l:7.79;'
+ ('fe80::3111:7a22:4b:1200%lowpan0', 52213, 0, 13) '4h:43.75;4t:23.11;'
+
+The value after "2l:" is the amount of light in lux. The value after "4h:" is
+the relative humidity and after "4t:" is the temperature in Celsius.
+
+Flash BeagleConnectâ„¢ Freedom node device with Greybus firmware
+**************************************************************
+
+#TODO: How can we add a step in here to show the network is connected without needing gbridge to be fully functional?
+
+Do this from the BeagleBone® Green Gateway board that was previously used to
+program the BeagleConnectâ„¢ Freedom gateway device:
+
+#. Disconnect the BeagleConnectâ„¢ Freedom **gateway** device
+
+#. Connect a new BeagleConnectâ„¢ Freedom board via USB
+
+#. :code:`sudo systemctl stop lowpan.service`
+
+#. :code:`cc2538-bsl.py /usr/share/beagleconnect/cc1352/greybus_mikrobus_beagleconnect.bin /dev/ttyACM0`
+
+#. After it finishes programming successfully, disconnect the BeagleConnect Freedom node device
+
+#. Power the newly programmed BeagleConnect Freedom node device from an alternate USB power source
+
+#. Reconnect the BeagleConnect Freedom **gateway** device to the BeagleBone Green Gateway
+
+#. :code:`sudo systemctl start lowpan.service`
+
+#. :code:`sudo beagleconnect-start-gateway`
+
+.. code-block:: bash
+
+ debian@beaglebone:~$ sudo beagleconnect-start-gateway
+ [sudo] password for debian:
+ setting up wpanusb gateway for IEEE 802154 CHANNEL 1(906 Mhz)
+ ping6: Warning: source address might be selected on device other than lowpan0.
+ PING 2001:db8::1(2001:db8::1) from ::1 lowpan0: 56 data bytes
+ 64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=185 ms
+ 64 bytes from 2001:db8::1: icmp_seq=3 ttl=64 time=40.9 ms
+ 64 bytes from 2001:db8::1: icmp_seq=4 ttl=64 time=40.9 ms
+ 64 bytes from 2001:db8::1: icmp_seq=5 ttl=64 time=40.6 ms
+
+ --- 2001:db8::1 ping statistics ---
+ 5 packets transmitted, 4 received, 20% packet loss, time 36ms
+ rtt min/avg/max/mdev = 40.593/76.796/184.799/62.356 ms
+ debian@beaglebone:~$ iio_info
+ Library version: 0.19 (git tag: v0.19)
+ Compiled with backends: local xml ip usb serial
+ IIO context created with local backend.
+ Backend version: 0.19 (git tag: v0.19)
+ Backend description string: Linux beaglebone 5.14.18-bone20 #1buster PREEMPT Tue Nov 16 20:47:19 UTC 2021 armv7l
+ IIO context has 1 attributes:
+ local,kernel: 5.14.18-bone20
+ IIO context has 3 devices:
+ iio:device0: TI-am335x-adc.0.auto (buffer capable)
+ 8 channels found:
+ voltage0: (input, index: 0, format: le:u12/16>>0)
+ 1 channel-specific attributes found:
+ attr 0: raw value: 1412
+ voltage1: (input, index: 1, format: le:u12/16>>0)
+ 1 channel-specific attributes found:
+ attr 0: raw value: 2318
+ voltage2: (input, index: 2, format: le:u12/16>>0)
+ 1 channel-specific attributes found:
+ attr 0: raw value: 2631
+ voltage3: (input, index: 3, format: le:u12/16>>0)
+ 1 channel-specific attributes found:
+ attr 0: raw value: 817
+ voltage4: (input, index: 4, format: le:u12/16>>0)
+ 1 channel-specific attributes found:
+ attr 0: raw value: 881
+ voltage5: (input, index: 5, format: le:u12/16>>0)
+ 1 channel-specific attributes found:
+ attr 0: raw value: 0
+ voltage6: (input, index: 6, format: le:u12/16>>0)
+ 1 channel-specific attributes found:
+ attr 0: raw value: 0
+ voltage7: (input, index: 7, format: le:u12/16>>0)
+ 1 channel-specific attributes found:
+ attr 0: raw value: 1180
+ 2 buffer-specific attributes found:
+ attr 0: data_available value: 0
+ attr 1: watermark value: 1
+ iio:device1: hdc2010
+ 3 channels found:
+ humidityrelative: (input)
+ 3 channel-specific attributes found:
+ attr 0: peak_raw value: 52224
+ attr 1: raw value: 52234
+ attr 2: scale value: 1.525878906
+ current: (output)
+ 2 channel-specific attributes found:
+ attr 0: heater_raw value: 0
+ attr 1: heater_raw_available value: 0 1
+ temp: (input)
+ 4 channel-specific attributes found:
+ attr 0: offset value: -15887.515151
+ attr 1: peak_raw value: 25600
+ attr 2: raw value: 25628
+ attr 3: scale value: 2.517700195
+ iio:device2: opt3001
+ 1 channels found:
+ illuminance: (input)
+ 2 channel-specific attributes found:
+ attr 0: input value: 79.040000
+ attr 1: integration_time value: 0.800000
+ 2 device-specific attributes found:
+ attr 0: current_timestamp_clock value: realtime
+
+ attr 1: integration_time_available value: 0.1 0.8
+ debian@beaglebone:~$ dmesg | grep -e mikrobus -e greybus
+ [ 100.491253] greybus 1-2.2: Interface added (greybus)
+ [ 100.491294] greybus 1-2.2: GMP VID=0x00000126, PID=0x00000126
+ [ 100.491306] greybus 1-2.2: DDBL1 Manufacturer=0x00000126, Product=0x00000126
+ [ 100.737637] greybus 1-2.2: excess descriptors in interface manifest
+ [ 102.475168] mikrobus:mikrobus_port_gb_register: mikrobus gb_probe , num cports= 2, manifest_size 192
+ [ 102.475206] mikrobus:mikrobus_port_gb_register: protocol added 3
+ [ 102.475214] mikrobus:mikrobus_port_gb_register: protocol added 2
+ [ 102.475239] mikrobus:mikrobus_port_register: registering port mikrobus-1
+ [ 102.475400] mikrobus_manifest:mikrobus_state_get: mikrobus descriptor not found
+ [ 102.475417] mikrobus_manifest:mikrobus_manifest_attach_device: parsed device 1, driver=opt3001, protocol=3, reg=44
+ [ 102.494516] mikrobus_manifest:mikrobus_manifest_attach_device: parsed device 2, driver=hdc2010, protocol=3, reg=41
+ [ 102.494567] mikrobus_manifest:mikrobus_manifest_parse: (null) manifest parsed with 2 devices
+ [ 102.494592] mikrobus mikrobus-1: registering device : opt3001
+ [ 102.495096] mikrobus mikrobus-1: registering device : hdc2010
+ debian@beaglebone:~$
+
+
+#TODO: update the below for the built-in sensors
+
+#TODO: can we also handle the case where these sensors are included and recommend them? Same firmware?
+
+#TODO: the current demo is for the built-in sensors, not the Click boards mentioned below
+
+Currently only a limited number of add-on boards have been tested to work over Greybus, simple add-on boards without interrupt requirement are the ones that work currently. The example is for Air Quality 2 Click and Weather Click attached to the mikroBUS ports on the device side.
+
+/var/log/gbridge will have the gbridge log, and if the mikroBUS port has been instantiated successfully the kernel log will show the devices probe messages:
+
+#TODO: this log needs to be updated
+
+.. code-block::
+
+ greybus 1-2.2: GMP VID=0x00000126, PID=0x00000126
+ greybus 1-2.2: DDBL1 Manufacturer=0x00000126, Product=0x00000126
+ greybus 1-2.2: excess descriptors in interface manifest
+ mikrobus:mikrobus_port_gb_register: mikrobus gb_probe , num cports= 3, manifest_size 252
+ mikrobus:mikrobus_port_gb_register: protocol added 11
+ mikrobus:mikrobus_port_gb_register: protocol added 3
+ mikrobus:mikrobus_port_gb_register: protocol added 2
+ mikrobus:mikrobus_port_register: registering port mikrobus-0
+ mikrobus_manifest:mikrobus_manifest_attach_device: parsed device 1, driver=bme280, protocol=3, reg=76
+ mikrobus_manifest:mikrobus_manifest_attach_device: parsed device 2, driver=ams-iaq-core, protocol=3, reg=5a
+ mikrobus_manifest:mikrobus_manifest_parse: Greybus Service Sample Application manifest parsed with 2 devices
+ mikrobus mikrobus-0: registering device : bme280
+ mikrobus mikrobus-0: registering device : ams-iaq-core
+
+
+#TODO: bring in the GPIO toggle and I2C explorations for greater understanding
+
+Flashing via a Linux Host
+*************************
+
+
+
+If flashing the Freedom board via the BeagleBone fails here's a trick you can try to flash from a Linux host.
+
+Use :code:`sshfs` to mount the Bone's files on the Linux host. This assumes the
+Bone is plugged in the the USB and appears at :code:`192.168.7.2`:
+
+.. code-block:: bash
+
+ host$ cd
+ host$ sshfs 192.168.7.2:/ bone
+ host$ cd bone; ls
+ bin dev home lib media opt root sbin sys usr
+ boot etc ID.txt lost+found mnt proc run srv tmp var
+ host$ ls /dev/ttyACM*
+ /dev/ttyACM1
+
+
+
+The Bone's files now appear as local files. Notice there is already a
+:code:`/dev/ACM*` appearing. Now plug the Connect into the Linux host's USB
+port and run the command again.
+
+.. code-block:: bash
+
+ host$ ls /dev/ttyACM*
+ /dev/ttyACM0 /dev/ttyACM1
+
+The :code:`/dev/ttyACM` that just appeared is the one associated with the
+Connect. In my case it's :code:`/dev/ttyACM0`. That's what I'll use in this
+example.
+
+Now change directories to where the binaries are and load:
+
+.. code-block:: bash
+
+ host$ cd ~/bone/usr/share/beagleconnect/cc1352;ls
+ greybus_mikrobus_beagleconnect.bin sensortest_beagleconnect.dts
+ greybus_mikrobus_beagleconnect.config wpanusb_beagleconnect.bin
+ greybus_mikrobus_beagleconnect.dts wpanusb_beagleconnect.config
+ sensortest_beagleconnect.bin wpanusb_beagleconnect.dts
+ sensortest_beagleconnect.config
+
+ host$ ~/bone/usr/bin/cc2538-bsl.py sensortest_beagleconnect.bin /dev/ttyACM0
+ 8-bsl.py sensortest_beagleconnect.bin /dev/ttyACM0
+ Opening port /dev/ttyACM0, baud 50000
+ Reading data from sensortest_beagleconnect.bin
+ Cannot auto-detect firmware filetype: Assuming .bin
+ Connecting to target...
+ CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
+ Primary IEEE Address: 00:12:4B:00:22:7A:10:46
+ Performing mass erase
+ Erasing all main bank flash sectors
+ Erase done
+ Writing 360448 bytes starting at address 0x00000000
+ Write 104 bytes at 0x00057F988
+ Write done
+ Verifying by comparing CRC32 calculations.
+ Verified (match: 0x0f6bdf0f)
+
+Now you are ready to continue the instructions above after the cc2528 command.
+
+Trying for different add-on boards
+----------------------------------
+
+See `mikroBUS over Greybus <https://github.com/vaishnav98/greybus-for-zephyr/tree/mikrobus#trying-out-different-add-on-boardsdevices-over-mikrobus>`_
+for trying out the same example for different mikroBUS add-on boards/ on-board devices.
+
+Observe the node device
+***********************
+
+Connect BeagleConnect Freedom node device to an Ubuntu laptop to observe the
+Zephyr console.
+
+
+Console (:code:`tio`)
+*********************
+In order to see diagnostic messages or to run certain commands on the Zephyr
+device we will require a terminal open to the device console. In this case, we
+use `tio <https://tio.github.io/>`_ due how its usage simplifies the
+instructions.
+
+#. Install :code:`tio`
+ :code:`sudo apt install -y tio`
+
+#. Run :code:`tio`
+ :code:`tio /dev/ttyACM0`
+
+ To exit :code:`tio` (later), enter :code:`ctrl+t, q`.
+
+
+The Zephyr Shell
+****************
+
+
+
+After flashing, you should observe the something matching the following output in :code:`tio`.
+
+.. code-block:: bash
+
+ uart:~$ *** Booting Zephyr OS build 9c858c863223 ***
+ [00:00:00.009,735] <inf> greybus_transport_tcpip: CPort 0 mapped to TCP/IP port 4242
+ [00:00:00.010,131] <inf> greybus_transport_tcpip: CPort 1 mapped to TCP/IP port 4243
+ [00:00:00.010,528] <inf> greybus_transport_tcpip: CPort 2 mapped to TCP/IP port 4244
+ [00:00:00.010,742] <inf> greybus_transport_tcpip: Greybus TCP/IP Transport initialized
+ [00:00:00.010,864] <inf> greybus_manifest: Registering CONTROL greybus driver.
+ [00:00:00.011,230] <inf> greybus_manifest: Registering GPIO greybus driver.
+ [00:00:00.011,596] <inf> greybus_manifest: Registering I2C greybus driver.
+ [00:00:00.011,871] <inf> greybus_service: Greybus is active
+ [00:00:00.026,092] <inf> net_config: Initializing network
+ [00:00:00.134,063] <inf> net_config: IPv6 address: 2001:db8::1
+
+
+
+The line beginning with :code:`***` is the Zephyr boot banner.
+
+Lines beginning with a timestamp of the form :code:`[H:m:s.us]` are Zephyr
+kernel messages.
+
+Lines beginning with :code:`uart:~$` indicates that the Zephyr shell is
+prompting you to enter a command.
+
+From the informational messages shown, we observe the following.
+
+* Zephyr is configured with the following
+ `link-local IPv6 address <https://en.wikipedia.org/wiki/Link-local_address#IPv6>`_ :code:`fe80::3177:a11c:4b:1200`
+
+* It is listening for (both) TCP and UDP traffic on port 4242
+
+However, what the log messages do not show (which will come into play later),
+are 2 critical pieces of information:
+
+#. **The RF Channel**: As you may have guessed, IEEE 802.15.4 devices are only
+ able to communicate with each other if they are using the same frequency to
+ transmit and recieve data. This information is part of the Physical Layer.
+
+#. The `PAN identifier <https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2019/10/04/connect_tutorial6-ieee802154addressing-rapc>`_:
+ IEEE 802.15.4 devices are only be able to communicate with one another if
+ they use the same PAN ID. This permits multiple networks (PANs) on the same
+ frequency. This information is part of the Data Link Layer.
+
+If we type :code:`help` in the shell and hit Enter, we're prompted with the
+following:
+
+.. code-block::
+
+ Please press the <Tab> button to see all available commands.
+ You can also use the <Tab> button to prompt or auto-complete all commands or its subcommands.
+ You can try to call commands with <-h> or <--help> parameter for more information.
+ Shell supports following meta-keys:
+
+ Ctrl+a, Ctrl+b, Ctrl+c, Ctrl+d, Ctrl+e, Ctrl+f, Ctrl+k, Ctrl+l, Ctrl+n, Ctrl+p, Ctrl+u, Ctrl+w
+ Alt+b, Alt+f.
+ Please refer to shell documentation for more details.
+
+So after hitting Tab, we see that there are several interesting commands we can
+use for additional information.
+
+.. code-block::
+
+ uart:~$
+ clear help history ieee802154 log net
+ resize sample shell
+
+Zephyr Shell: IEEE 802.15.4 commands
+------------------------------------
+
+Entering :code:`ieee802154 help`, we see
+
+.. code-block::
+
+ uart:~$ ieee802154 help
+ ieee802154 - IEEE 802.15.4 commands
+ Subcommands:
+ ack :<set/1 | unset/0> Set auto-ack flag
+ associate :<pan_id> <PAN coordinator short or long address (EUI-64)>
+ disassociate :Disassociate from network
+ get_chan :Get currently used channel
+ get_ext_addr :Get currently used extended address
+ get_pan_id :Get currently used PAN id
+ get_short_addr :Get currently used short address
+ get_tx_power :Get currently used TX power
+ scan :<passive|active> <channels set n[:m:...]:x|all> <per-channel
+ duration in ms>
+ set_chan :<channel> Set used channel
+ set_ext_addr :<long/extended address (EUI-64)> Set extended address
+ set_pan_id :<pan_id> Set used PAN id
+ set_short_addr :<short address> Set short address
+ set_tx_power :<-18/-7/-4/-2/0/1/2/3/5> Set TX power
+
+
+We get the missing Channel number (frequency) with the command :code:`ieee802154 get_chan`.
+
+.. code-block::
+
+ uart:~$ ieee802154 get_chan
+ Channel 26
+
+We get the missing PAN ID with the command :code:`ieee802154 get_pan_id`.
+
+.. code-block::
+
+ uart:~$ ieee802154 get_pan_id
+ PAN ID 43981 (0xabcd)
+
+Zephyr Shell: Network Commands
+------------------------------
+
+Additionally, we may query the IPv6 information of the Zephyr device.
+
+.. code-block::
+
+ uart:~$ net iface
+
+ Interface 0x20002b20 (IEEE 802.15.4) [1]
+ ========================================
+ Link addr : CD:99:A1:1C:00:4B:12:00
+ MTU : 125
+ IPv6 unicast addresses (max 3):
+ fe80::cf99:a11c:4b:1200 autoconf preferred infinite
+ 2001:db8::1 manual preferred infinite
+ IPv6 multicast addresses (max 4):
+ ff02::1
+ ff02::1:ff4b:1200
+ ff02::1:ff00:1
+ IPv6 prefixes (max 2):
+ <none>
+ IPv6 hop limit : 64
+ IPv6 base reachable time : 30000
+ IPv6 reachable time : 16929
+ IPv6 retransmit timer : 0
+
+
+
+And we see that the static IPv6 address (:code:`2001:db8::1`) from
+:code:`samples/net/sockets/echo_server/prj.conf` is present and configured.
+While the statically configured IPv6 address is useful, it isn't 100% necessary.
+
+Rebuilding from source
+**********************
+
+#TODO: revisit everything below here
+
+Prerequisites
+-------------
+
+* Zephyr environment is set up according to the
+ `Getting Started Guide <https://docs.zephyrproject.org/latest/getting_started/index.html>`_
+
+ * Please use the Zephyr SDK when installing a toolchain above
+
+* `Zephyr SDK <https://docs.zephyrproject.org/latest/getting_started/index.html#install-a-toolchain>`_
+ is installed at ~/zephyr-sdk-0.11.2 (any later version should be fine as well)
+
+* Zephyr board is connected via USB
+
+Cloning the repository
+----------------------
+
+This repository utilizes `git submodules <https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_
+to keep track of all of the projects required to reproduce the on-going work.
+The instructions here only cover checking out the :code:`demo` branch which
+should stay in a tested state. On-going development will be on the
+:code:`master` branch.
+
+Note: The parent directory :code:`~` is simply used as a placeholder for testing.
+Please use whatever parent directory you see fit.
+
+Clone specific tag
+------------------
+
+.. code-block:: bash
+
+ cd ~
+ git clone --recurse-submodules --branch demo https://github.com/jadonk/beagleconnect
+
+Zephyr
+******
+
+Add the Fork
+------------
+
+For the time being, Greybus must remain outside of the main Zephyr repository.
+Currently, it is just in a Zephyr fork, but it should be converted to a
+proper `Module (External Project) <https://docs.zephyrproject.org/latest/guides/modules.html>`_.
+This is for a number of reasons, but mainly there must be:
+
+* specifications for authentication and encryption
+
+* specifications for joining and rejoining wireless networks
+
+* specifications for discovery
+
+Therefore, in order to reproduce this example, please run the following.
+
+.. code-block:: bash
+
+ cd ~/beagleconnect/sw/zephyrproject/zephyr
+ west update
+
+Build and Flash Zephyr
+----------------------
+
+Here, we will build and flash the Zephyr
+`greybus_net sample <https://github.com/cfriedt/zephyr/tree/greybus-sockets/samples/subsys/greybus/net>`_
+to our device.
+
+#. Edit the file :code:`~/.zephyrrc` and place the following text inside of it
+
+.. code-block:: bash
+
+ export ZEPHYR_TOOLCHAIN_VARIANT=zephyr
+ export ZEPHYR_SDK_INSTALL_DIR=~/zephyr-sdk-0.11.2
+
+#. Set up the required Zephyr environment variables via
+
+.. code-block:: bash
+
+ source zephyr-env.sh
+
+#. Build the project
+
+.. code-block:: bash
+
+ BOARD=cc1352r1_launchxl west build samples/subsys/greybus/net --pristine \
+ --build-dir build/greybus_launchpad -- -DCONF_FILE="prj.conf overlay-802154.conf"
+
+#. Ensure that the last part of the build process looks somewhat like this:
+
+.. code-block:: bash
+
+ ...
+ [221/226] Linking C executable zephyr/zephyr_prebuilt.elf
+ Memory region Used Size Region Size %age Used
+ FLASH: 155760 B 360360 B 43.22%
+ FLASH_CCFG: 88 B 88 B 100.00%
+ SRAM: 58496 B 80 KB 71.41%
+ IDT_LIST: 184 B 2 KB 8.98%
+ [226/226] Linking C executable zephyr/zephyr.elf
+
+#. Flash the firmware to your device using
+
+.. code-block:: bash
+
+ BOARD=cc1352r1_launchxl west flash --build-dir build/greybus_launchpad
+
+Linux
+*****
+
+Warning: If you aren't comfortable building and installing a Linux kernel on
+your computer, you should probably just stop here. I'll assume you know the
+basics of building and installing a Linux kernel from here on out.
+
+Clone, patch, and build the kernel
+----------------------------------
+
+For this demo, I used the 5.8.4 stable kernel. Also, I've applied the
+:code:`mikrobus` kernel driver, though it isn't strictly required for greybus.
+
+Note: The parent directory :code:`~` is simply used as a placeholder for testing.
+Please use whatever parent directory you see fit.
+
+TODO: The patches for gb-netlink will eventually be applied here until pushed into mainline.
+
+.. code-block:: bash
+
+ cd ~
+ git clone --branch v5.8.4 --single-branch git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+ cd linux
+ git checkout -b v5.8.4-greybus
+ git am ~/beagleconnect/sw/linux/v2-0001-RFC-mikroBUS-driver-for-add-on-boards.patch
+ git am ~/beagleconnect/sw/linux/0001-mikroBUS-build-fixes.patch
+ cp /boot/config-`uname -r` .config
+ yes "" | make oldconfig
+ ./scripts/kconfig/merge_config.sh .config ~/beagleconnect/sw/linux/mikrobus.config
+ ./scripts/kconfig/merge_config.sh .config ~/beagleconnect/sw/linux/atusb.config
+ make -j`nproc --all`
+ sudo make modules_install
+ sudo make install
+
+Reboot and select your new kernel.
+
+Probe the IEEE 802.15.4 Device Driver
+-------------------------------------
+
+On the Linux machine, make sure the :code:`atusb` driver is loaded. This should
+happen automatically when the adapter is inserted or when the machine is booted
+while the adapter is installed.
+
+.. code-block:: bash
+
+ $ dmesg | grep -i ATUSB
+ [ 6.512154] usb 1-1: ATUSB: AT86RF231 version 2
+ [ 6.512492] usb 1-1: Firmware: major: 0, minor: 3, hardware type: ATUSB (2)
+ [ 6.525357] usbcore: registered new interface driver atusb
+ ...
+
+
+
+We should now be able to see the IEEE 802.15.4 network device by entering :code:`ip a show wpan0`.
+
+.. code-block:: bash
+
+ $ ip a show wpan0
+ 36: wpan0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 123 qdisc fq_codel state UNKNOWN group default qlen 300
+ link/ieee802.15.4 3e:7d:90:4d:8f:00:76:a2 brd ff:ff:ff:ff:ff:ff:ff:ff
+
+
+But wait, that is not an IP address! It's the hardware address of the 802.15.4
+device. So, in order to associate it with an IP address, we need to run a
+couple of other commands (thanks to wpan.cakelab.org).
+
+Set the 802.15.4 Physical and Link-Layer Parameters
+---------------------------------------------------
+
+#. First, get the phy number for the :code:`wpan0` device
+
+.. code-block:: bash
+
+ $ iwpan list
+ wpan_phy phy0
+ supported channels:
+ page 0: 11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
+ current_page: 0
+ current_channel: 26, 2480 MHz
+ cca_mode: (1) Energy above threshold
+ cca_ed_level: -77
+ tx_power: 3
+ capabilities:
+ iftypes: node,monitor
+ channels:
+ page 0:
+ [11] 2405 MHz, [12] 2410 MHz, [13] 2415 MHz,
+ [14] 2420 MHz, [15] 2425 MHz, [16] 2430 MHz,
+ [17] 2435 MHz, [18] 2440 MHz, [19] 2445 MHz,
+ [20] 2450 MHz, [21] 2455 MHz, [22] 2460 MHz,
+ [23] 2465 MHz, [24] 2470 MHz, [25] 2475 MHz,
+ [26] 2480 MHz
+ tx_powers:
+ 3 dBm, 2.8 dBm, 2.3 dBm, 1.8 dBm, 1.3 dBm, 0.7 dBm,
+ 0 dBm, -1 dBm, -2 dBm, -3 dBm, -4 dBm, -5 dBm,
+ -7 dBm, -9 dBm, -12 dBm, -17 dBm,
+ cca_ed_levels:
+ -91 dBm, -89 dBm, -87 dBm, -85 dBm, -83 dBm, -81 dBm,
+ -79 dBm, -77 dBm, -75 dBm, -73 dBm, -71 dBm, -69 dBm,
+ -67 dBm, -65 dBm, -63 dBm, -61 dBm,
+ cca_modes:
+ (1) Energy above threshold
+ (2) Carrier sense only
+ (3, cca_opt: 0) Carrier sense with energy above threshold (logical operator is 'and')
+ (3, cca_opt: 1) Carrier sense with energy above threshold (logical operator is 'or')
+ min_be: 0,1,2,3,4,5,6,7,8
+ max_be: 3,4,5,6,7,8
+ csma_backoffs: 0,1,2,3,4,5
+ frame_retries: 3
+ lbt: false
+
+#. Next, set the Channel for the 802.15.4 device on the Linux machine
+
+.. code-block:: bash
+
+ sudo iwpan phy phy0 set channel 0 26
+
+#. Then, set the PAN identifier for the 802.15.4 device on the Linux machine :code:`sudo iwpan dev wpan0 set pan_id 0xabcd`
+
+#. Associate the :code:`wpan0` device to a new, 6lowpan network interface
+
+.. code-block:: bash
+
+ sudo ip link add link wpan0 name lowpan0 type lowpan
+
+#. Finally, set the links up for both :code:`wpan0` and :code:`lowpan0`
+
+.. code-block:: bash
+
+ sudo ip link set wpan0 up
+ sudo ip link set lowpan0 up
+
+
+
+We should observe something like the following when we run :code:`ip a show lowpan0`.
+
+.. code-block:: bash
+
+ ip a show lowpan0
+ 37: lowpan0@wpan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/6lowpan 9e:0b:a4:e8:00:d3:45:53 brd ff:ff:ff:ff:ff:ff:ff:ff
+ inet6 fe80::9c0b:a4e8:d3:4553/64 scope link
+ valid_lft forever preferred_lft forever
+
+Ping Pong
+*********
+
+Broadcast Ping
+--------------
+
+Now, perform a broadcast ping to see what else is listening on :code:`lowpan0`.
+
+.. code-block::
+
+ $ ping6 -I lowpan0 ff02::1
+ PING ff02::1(ff02::1) from fe80::9c0b:a4e8:d3:4553%lowpan0 lowpan0: 56 data bytes
+ 64 bytes from fe80::9c0b:a4e8:d3:4553%lowpan0: icmp_seq=1 ttl=64 time=0.099 ms
+ 64 bytes from fe80::9c0b:a4e8:d3:4553%lowpan0: icmp_seq=2 ttl=64 time=0.125 ms
+ 64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=2 ttl=64 time=17.3 ms (DUP!)
+ 64 bytes from fe80::9c0b:a4e8:d3:4553%lowpan0: icmp_seq=3 ttl=64 time=0.126 ms
+ 64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=3 ttl=64 time=9.60 ms (DUP!)
+ 64 bytes from fe80::9c0b:a4e8:d3:4553%lowpan0: icmp_seq=4 ttl=64 time=0.131 ms
+ 64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=4 ttl=64 time=14.9 ms (DUP!)
+
+Yay! We have pinged (pung?) the Zephyr device over IEEE 802.15.4 using 6LowPAN!
+
+Ping Zephyr
+-----------
+
+We can ping the Zephyr device directly without a broadcast ping too, of course.
+
+.. code-block::
+
+ $ ping6 -I lowpan0 fe80::cf99:a11c:4b:1200
+ PING fe80::cf99:a11c:4b:1200(fe80::cf99:a11c:4b:1200) from fe80::9c0b:a4e8:d3:4553%lowpan0 lowpan0: 56 data bytes
+ 64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=1 ttl=64 time=16.0 ms
+ 64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=2 ttl=64 time=13.8 ms
+ 64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=3 ttl=64 time=9.77 ms
+ 64 bytes from fe80::cf99:a11c:4b:1200%lowpan0: icmp_seq=5 ttl=64 time=11.5 ms
+
+Ping Linux
+----------
+
+Similarly, we can ping the Linux host from the Zephyr shell.
+
+.. code-block::
+
+ uart:~$ net ping --help
+ ping - Ping a network host.
+ Subcommands:
+ --help :'net ping [-c count] [-i interval ms] <host>' Send ICMPv4 or ICMPv6
+ Echo-Request to a network host.
+ $ net ping -c 5 fe80::9c0b:a4e8:d3:4553
+ PING fe80::9c0b:a4e8:d3:4553
+ 8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=0 ttl=64 rssi=110 time=11 ms
+ 8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=1 ttl=64 rssi=126 time=9 ms
+ 8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=2 ttl=64 rssi=128 time=13 ms
+ 8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=3 ttl=64 rssi=126 time=10 ms
+ 8 bytes from fe80::9c0b:a4e8:d3:4553 to fe80::cf99:a11c:4b:1200: icmp_seq=4 ttl=64 rssi=126 time=7 ms
+
+Assign a Static Address
+-----------------------
+
+So far, we have been using IPv6 Link-Local addressing. However, the Zephyr
+application is configured to use a statically configured IPv6 address as well
+which is, namely :code:`2001:db8::1`.
+
+If we add a similar static IPv6 address to our Linux IEEE 802.15.4 network
+interface, :code:`lowpan0`, then we should expect to be able to reach that as
+well.
+
+In Linux, run the following
+
+.. code-block:: bash
+
+ sudo ip -6 addr add 2001:db8::2/64 dev lowpan0
+
+We can verify that the address has been set by examining the :code:`lowpan0`
+network interface again.
+
+.. code-block:: bash
+
+ $ ip a show lowpan0
+ 37: lowpan0@wpan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/6lowpan 9e:0b:a4:e8:00:d3:45:53 brd ff:ff:ff:ff:ff:ff:ff:ff
+ inet6 2001:db8::2/64 scope global
+ valid_lft forever preferred_lft forever
+ inet6 fe80::9c0b:a4e8:d3:4553/64 scope link
+ valid_lft forever preferred_lft forever
+
+Lastly, ping the statically configured IPv6 address of the Zephyr device.
+
+.. code-block::
+
+ $ ping6 2001:db8::1
+ PING 2001:db8::1(2001:db8::1) 56 data bytes
+ 64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=53.7 ms
+ 64 bytes from 2001:db8::1: icmp_seq=3 ttl=64 time=13.1 ms
+ 64 bytes from 2001:db8::1: icmp_seq=4 ttl=64 time=22.0 ms
+ 64 bytes from 2001:db8::1: icmp_seq=5 ttl=64 time=22.7 ms
+ 64 bytes from 2001:db8::1: icmp_seq=6 ttl=64 time=18.4 ms
+
+Now that we have set up a reliable transport, let's move on to the application
+layer.
+
+
+Greybus
+*******
+
+Hopefully the videos listed earlier provide a sufficient foundation to
+understand what will happen shortly. However, there is still a bit more
+preparation required.
+
+Build and probe Greybus Kernel Modules
+--------------------------------------
+
+Greybus was originally intended to work exclusively on the UniPro physical
+layer. However, we're using RF as our physical layer and TCP/IP as our
+transport. As such, there was need to be able to communicate with the Linux
+Greybus facilities through userspace, and out of that need arose gb-netlink.
+The Netlink Greybus module actually does not care about the physical layer, but
+is happy to usher Greybus messages back and forth between the kernel and
+userspace.
+
+Build and probe the gb-netlink modules (as well as the other Greybus modules)
+with the following:
+
+.. code-block:: bash
+
+ cd ${WORKSPACE}/sw/greybus
+ make -j`nproc --all`
+ sudo make install
+ ../load_gb_modules.sh
+
+Build and Run Gbridge
+---------------------
+
+The gbridge utility was created as a proof of concept to abstract the Greybus
+Netlink datapath among several reliable transports. For the purposes of this
+tutorial, we'll be using it as a TCP/IP bridge.
+
+To run :code:`gbridge`, perform the following:
+
+.. code-block:: bash
+
+ sudo apt install -y libnl-3-dev libnl-genl-3-dev libbluetooth-dev libavahi-client-dev
+ cd gbridge
+ autoreconf -vfi
+ GBNETLINKDIR=${PWD}/../greybus \
+ ./configure --enable-uart --enable-tcpip --disable-gbsim --enable-netlink --disable-bluetooth
+ make -j`nproc --all`
+ sudo make install
+ gbridge
+
+
+Blinky!
+*******
+
+Now that we have set up a reliable TCP transport, and set up the Greybus
+modules in the Linux kernel, and used Gbridge to connect a Greybus node to the
+Linux kernel via TCP/IP, we can now get to the heart of the demonstration!
+
+First, save the following script as :code:`blinky.sh`.
+
+.. code-block:: bash
+
+ #!/bin/bash
+
+ # Blinky Demo for CC1352R SensorTag
+
+ # /dev/gpiochipN that Greybus created
+ CHIP="$(gpiodetect | grep greybus_gpio | head -n 1 | awk '{print $1}')"
+
+ # red, green, blue LED pins
+ RED=6
+ GREEN=7
+ BLUE=21
+
+ # Bash array for pins and values
+ PINS=($RED $GREEN $BLUE)
+ NPINS=${#PINS[@]}
+
+ for ((;;)); do
+ for i in ${!PINS[@]}; do
+ # turn off previous pin
+ if [ $i -eq 0 ]; then
+ PREV=2
+ else
+ PREV=$((i-1))
+ fi
+ gpioset $CHIP ${PINS[$PREV]}=0
+
+ # turn on current pin
+ gpioset $CHIP ${PINS[$i]}=1
+
+ # wait a sec
+ sleep 1
+ done
+ done
+
+
+Second, run the script with root privileges: :code:`sudo bash blinky.sh`
+
+The output of your minicom session should resemble the following.
+
+.. code-block::
+
+ $ *** Booting Zephyr OS build zephyr-v2.3.0-1435-g40c0ed940d71 ***
+ [00:00:00.011,932] <inf> net_config: Initializing network
+ [00:00:00.111,938] <inf> net_config: IPv6 address: fe80::6c42:bc1c:4b:1200
+ [00:00:00.112,121] <dbg> greybus_service.greybus_service_init: Greybus initializing..
+ [00:00:00.112,426] <dbg> greybus_transport_tcpip.gb_transport_backend_init: Greybus TCP/IP Transport initializing..
+ [00:00:00.112,579] <dbg> greybus_transport_tcpip.netsetup: created server socket 0 for cport 0
+ [00:00:00.112,579] <dbg> greybus_transport_tcpip.netsetup: setting socket options for socket 0
+ [00:00:00.112,609] <dbg> greybus_transport_tcpip.netsetup: binding socket 0 (cport 0) to port 4242
+ [00:00:00.112,640] <dbg> greybus_transport_tcpip.netsetup: listening on socket 0 (cport 0)
+ [00:00:00.112,823] <dbg> greybus_transport_tcpip.netsetup: created server socket 1 for cport 1
+ [00:00:00.112,823] <dbg> greybus_transport_tcpip.netsetup: setting socket options for socket 1
+ [00:00:00.112,854] <dbg> greybus_transport_tcpip.netsetup: binding socket 1 (cport 1) to port 4243
+ [00:00:00.112,854] <dbg> greybus_transport_tcpip.netsetup: listening on socket 1 (cport 1)
+ [00:00:00.113,037] <inf> net_config: IPv6 address: fe80::6c42:bc1c:4b:1200
+ [00:00:00.113,250] <dbg> greybus_transport_tcpip.netsetup: created server socket 2 for cport 2
+ [00:00:00.113,250] <dbg> greybus_transport_tcpip.netsetup: setting socket options for socket 2
+ [00:00:00.113,281] <dbg> greybus_transport_tcpip.netsetup: binding socket 2 (cport 2) to port 4244
+ [00:00:00.113,311] <dbg> greybus_transport_tcpip.netsetup: listening on socket 2 (cport 2)
+ [00:00:00.113,494] <dbg> greybus_transport_tcpip.netsetup: created server socket 3 for cport 3
+ [00:00:00.113,494] <dbg> greybus_transport_tcpip.netsetup: setting socket options for socket 3
+ [00:00:00.113,525] <dbg> greybus_transport_tcpip.netsetup: binding socket 3 (cport 3) to port 4245
+ [00:00:00.113,555] <dbg> greybus_transport_tcpip.netsetup: listening on socket 3 (cport 3)
+ [00:00:00.113,861] <inf> greybus_transport_tcpip: Greybus TCP/IP Transport initialized
+ [00:00:00.116,149] <inf> greybus_service: Greybus is active
+ [00:00:00.116,546] <dbg> greybus_transport_tcpip.accept_loop: calling poll
+ [00:45:08.397,399] <dbg> greybus_transport_tcpip.accept_loop: poll returned 1
+ [00:45:08.397,399] <dbg> greybus_transport_tcpip.accept_loop: socket 0 (cport 0) has traffic
+ [00:45:08.397,491] <dbg> greybus_transport_tcpip.accept_loop: accepted connection from [2001:db8::2]:39638 as fd 4
+ [00:45:08.397,491] <dbg> greybus_transport_tcpip.accept_loop: spawning client thread..
+ [00:45:08.397,735] <dbg> greybus_transport_tcpip.accept_loop: calling poll
+ [00:45:08.491,363] <dbg> greybus_transport_tcpip.accept_loop: poll returned 1
+ [00:45:08.491,363] <dbg> greybus_transport_tcpip.accept_loop: socket 3 (cport 3) has traffic
+ [00:45:08.491,455] <dbg> greybus_transport_tcpip.accept_loop: accepted connection from [2001:db8::2]:39890 as fd 5
+ [00:45:08.491,455] <dbg> greybus_transport_tcpip.accept_loop: spawning client thread..
+ [00:45:08.491,699] <dbg> greybus_transport_tcpip.accept_loop: calling poll
+ [00:45:08.620,056] <dbg> greybus_transport_tcpip.accept_loop: poll returned 1
+ [00:45:08.620,086] <dbg> greybus_transport_tcpip.accept_loop: socket 2 (cport 2) has traffic
+ [00:45:08.620,147] <dbg> greybus_transport_tcpip.accept_loop: accepted connection from [2001:db8::2]:42422 as fd 6
+ [00:45:08.620,147] <dbg> greybus_transport_tcpip.accept_loop: spawning client thread..
+ [00:45:08.620,422] <dbg> greybus_transport_tcpip.accept_loop: calling poll
+ [00:45:08.679,504] <dbg> greybus_transport_tcpip.accept_loop: poll returned 1
+ [00:45:08.679,534] <dbg> greybus_transport_tcpip.accept_loop: socket 1 (cport 1) has traffic
+ [00:45:08.679,595] <dbg> greybus_transport_tcpip.accept_loop: accepted connection from [2001:db8::2]:48286 as fd 7
+ [00:45:08.679,595] <dbg> greybus_transport_tcpip.accept_loop: spawning client thread..
+ [00:45:08.679,870] <dbg> greybus_transport_tcpip.accept_loop: calling poll
+ ...
+
+Read I2C Registers
+------------------
+
+The SensorTag comes with an opt3001 ambient light sensor as well as an hdc2080
+temperature & humidity sensor.
+
+First, find which i2c device corresponds to the SensorTag:
+
+.. code-block:: bash
+
+ ls -la /sys/bus/i2c/devices/* | grep "greybus"
+ lrwxrwxrwx 1 root root 0 Aug 15 11:24 /sys/bus/i2c/devices/i2c-8 -> ../../../devices/virtual/gb_nl/gn_nl/greybus1/1-2/1-2.2/1-2.2.2/gbphy2/i2c-8
+
+On my machine, the i2c device node that Greybus creates is :code:`/dev/i2c-8`.
+
+Read the ID registers (at the i2c register address 0x7e) of the opt3001 sensor
+(at i2c bus address 0x44) as shown below:
+
+.. code-block:: bash
+
+ i2cget -y 8 0x44 0x7e w
+ 0x4954
+
+Read the ID registers (at the i2c register address 0xfc) of the hdc2080 sensor
+(at i2c bus address 0x41) as shown below:
+
+.. code-block:: bash
+
+ i2cget -y 8 0x41 0xfc w
+ 0x5449
+
+Conclusion
+**********
+
+The blinking LED can and poking i2c registers can be a somewhat anticlimactic,
+but hopefully it illustrates the potential for Greybus as an IoT application layer
+protocol.
+
+What is nice about this demo, is that we're using Device Tree to describe our
+Greybus Peripheral declaratively, they Greybus Manifest is automatically
+generated, and the Greybus Service is automatically started in Zephyr.
+
+In other words, all that is required to replicate this for other IoT devices is
+simply an appropriate Device Tree overlay file.
+
+The proof-of-concept involving Linux, Zephyr, and IEEE 802.15.4 was actually
+fairly straight forward and was accomplished with mostly already-upstream
+source.
+
+For Greybus in Zephyr, there is still a considerable amount of integration work
+to be done, including * converting the fork to a proper Zephyr module * adding
+security and authentication * automatic detection, joining, and rejoining of
+devices.
+
+Thanks for reading, and we hope you've enjoyed this tutorial.
diff --git a/beagleconnect/index.rst b/beagleconnect/index.rst
new file mode 100644
index 0000000000000000000000000000000000000000..298b65d71d521641683c2eb3bd74318a10060945
--- /dev/null
+++ b/beagleconnect/index.rst
@@ -0,0 +1,55 @@
+.. _beagleconnect-home:
+
+*************
+BeagleConnect
+*************
+
+There are many stories behind BeagleConnectâ„¢, mine is just one of them. It
+begins with my mom teaching me about computers. She told me I could anything I
+wanted with ours, as long as I didn’t open the case. This was the
+late-70s/early-80s, so all she needed to do was put her `floppy disk <https://en.wikipedia.org/wiki/Floppy_disk>`_
+away and there wasn’t risk of me damaging the family photo album or her
+ability to do her work the next day. I listened and learned from her the basics
+of programming, but it wasn’t long before I wanted to take the computer apart.
+
+Initially exploring `Getting Started in Electronics <http://www.forrestmims.org/>`_
+satisfied my itch for quite a while. Eventually, I got a Commodore 64 and began
+connecting voice synthesizer ICs to it. My interest in computers and
+electronics flourished into an electrical engineering degree and a long career
+in the semiconductor industry.
+
+Over this time, I’ve become more and more alarmed with the progress of
+technology. Now, to be clear, I love technology. I love innovation and
+invention. It is just that some things have evolved in a sort of
+tunnel-vision, without bringing everyone along.
+
+But, what about keyboard users? As graphical user interfaces and mice took over
+computers, they rapidly became almost unusable by my mom. She typed well, but
+the dexterity to move a mouse aluded her. To satisfy the need to interact with
+locations on the screen, she adopted using a joystick and her productivity came
+to a crawl. How is it that such assumptions could be made impacting all
+computer users without any thoughtful provisions for what already worked?
+
+
+
+.. image:: media/image1.jpg
+ :width: 598
+ :align: center
+ :height: 400
+ :alt: BeagleConnect
+
+.. toctree::
+ :maxdepth: 1
+
+ ch01.rst
+ ch02.rst
+ ch03.rst
+ ch04.rst
+ ch05.rst
+ ch06.rst
+ ch07.rst
+ ch08.rst
+ ch09.rst
+ ch10.rst
+ ch11.rst
+
diff --git a/beagleconnect/media/ProvStep1.jpg b/beagleconnect/media/ProvStep1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..b29157df5870efe865ab00b4f34509e818d1147e
Binary files /dev/null and b/beagleconnect/media/ProvStep1.jpg differ
diff --git a/beagleconnect/media/ProvStep2.jpg b/beagleconnect/media/ProvStep2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..7769b36da832c857a8115dd91b6a45985fd53ab8
Binary files /dev/null and b/beagleconnect/media/ProvStep2.jpg differ
diff --git a/beagleconnect/media/ProvStep3.jpg b/beagleconnect/media/ProvStep3.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..c316f3b5620b3c21950509cb6485eaef6901d4fa
Binary files /dev/null and b/beagleconnect/media/ProvStep3.jpg differ
diff --git a/beagleconnect/media/SoftwareProp.jpg b/beagleconnect/media/SoftwareProp.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..4314b5912f2780ace67e02b269c1a1bb97fb74f2
Binary files /dev/null and b/beagleconnect/media/SoftwareProp.jpg differ
diff --git a/beagleconnect/media/bcf-c5-boards.jpg b/beagleconnect/media/bcf-c5-boards.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..692696bd2173d3b4de2046a883bdc5f3e42c1da7
Binary files /dev/null and b/beagleconnect/media/bcf-c5-boards.jpg differ
diff --git a/beagleconnect/media/bcf_block_diagram.svg b/beagleconnect/media/bcf_block_diagram.svg
new file mode 100644
index 0000000000000000000000000000000000000000..96cf7a0f2fdcc6e1b3ed229641bb9fc1856a6e8f
--- /dev/null
+++ b/beagleconnect/media/bcf_block_diagram.svg
@@ -0,0 +1,262 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
+ "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.43.0 (0)
+ -->
+<!-- Title: S Pages: 1 -->
+<svg width="570pt" height="767pt"
+ viewBox="0.00 0.00 570.00 767.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 763)">
+<title>S</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-763 566,-763 566,4 -4,4"/>
+<g id="clust1" class="cluster">
+<title>cluster_0</title>
+<polygon fill="none" stroke="black" points="8,-304 8,-751 280,-751 280,-304 8,-304"/>
+<text text-anchor="middle" x="144" y="-735.8" font-family="Times,serif" font-size="14.00">Linux PC</text>
+</g>
+<g id="clust2" class="cluster">
+<title>cluster_1</title>
+<polygon fill="lightgrey" stroke="lightgrey" points="16,-645 16,-720 272,-720 272,-645 16,-645"/>
+<text text-anchor="middle" x="144" y="-704.8" font-family="Times,serif" font-size="14.00">Linux userspace</text>
+</g>
+<g id="clust3" class="cluster">
+<title>cluster_2</title>
+<polygon fill="lightgrey" stroke="lightgrey" points="41,-312 41,-637 272,-637 272,-312 41,-312"/>
+<text text-anchor="middle" x="156.5" y="-621.8" font-family="Times,serif" font-size="14.00">Linux kernel</text>
+</g>
+<g id="clust4" class="cluster">
+<title>cluster_3</title>
+<polygon fill="none" stroke="black" points="288,-213 288,-418 466,-418 466,-213 288,-213"/>
+<text text-anchor="middle" x="377" y="-402.8" font-family="Times,serif" font-size="14.00">BCF gateway</text>
+</g>
+<g id="clust5" class="cluster">
+<title>cluster_4</title>
+<polygon fill="lightgrey" stroke="lightgrey" points="324,-221 324,-296 430,-296 430,-221 324,-221"/>
+<text text-anchor="middle" x="377" y="-280.8" font-family="Times,serif" font-size="14.00">CC1352</text>
+</g>
+<g id="clust6" class="cluster">
+<title>cluster_5</title>
+<polygon fill="lightgrey" stroke="lightgrey" points="296,-312 296,-387 458,-387 458,-312 296,-312"/>
+<text text-anchor="middle" x="377" y="-371.8" font-family="Times,serif" font-size="14.00">MSP430</text>
+</g>
+<g id="clust7" class="cluster">
+<title>cluster_6</title>
+<polygon fill="none" stroke="black" points="227,-8 227,-205 554,-205 554,-8 227,-8"/>
+<text text-anchor="middle" x="390.5" y="-189.8" font-family="Times,serif" font-size="14.00">BCF node</text>
+</g>
+<g id="clust8" class="cluster">
+<title>cluster_7</title>
+<polygon fill="lightgrey" stroke="lightgrey" points="290,-99 290,-174 464,-174 464,-99 290,-99"/>
+<text text-anchor="middle" x="377" y="-158.8" font-family="Times,serif" font-size="14.00">CC1352</text>
+</g>
+<g id="clust9" class="cluster">
+<title>cluster_8</title>
+<polygon fill="lightgrey" stroke="lightgrey" points="235,-16 235,-91 546,-91 546,-16 235,-16"/>
+<text text-anchor="middle" x="390.5" y="-75.8" font-family="Times,serif" font-size="14.00">mikroBUS add-on board</text>
+</g>
+<!-- A -->
+<g id="node1" class="node">
+<title>A</title>
+<g id="a_node1"><a xlink:title="Primary developer entry point">
+<polygon fill="green" stroke="green" points="160,-689 24,-689 24,-653 160,-653 160,-689"/>
+<text text-anchor="middle" x="92" y="-667.3" font-family="Times,serif" font-size="14.00">User Application</text>
+</a>
+</g>
+</g>
+<!-- I -->
+<g id="node3" class="node">
+<title>I</title>
+<g id="a_node3"><a xlink:title="Hundreds of drivers for sensors and acutators">
+<polygon fill="green" stroke="green" points="145,-606 49,-606 49,-570 145,-570 145,-606"/>
+<text text-anchor="middle" x="97" y="-584.3" font-family="Times,serif" font-size="14.00">IIO Drivers</text>
+</a>
+</g>
+</g>
+<!-- A->I -->
+<g id="edge1" class="edge">
+<title>A->I</title>
+<path fill="none" stroke="black" d="M93.06,-652.82C93.72,-642.19 94.57,-628.31 95.32,-616.2"/>
+<polygon fill="black" stroke="black" points="98.82,-616.35 95.94,-606.15 91.83,-615.92 98.82,-616.35"/>
+</g>
+<!-- g -->
+<g id="node2" class="node">
+<title>g</title>
+<g id="a_node2"><a xlink:title="Bridge Greybus to networked devices">
+<polygon fill="green" stroke="green" points="264,-689 178,-689 178,-653 264,-653 264,-689"/>
+<text text-anchor="middle" x="221" y="-667.3" font-family="Times,serif" font-size="14.00">gbridge**</text>
+</a>
+</g>
+</g>
+<!-- 6 -->
+<g id="node9" class="node">
+<title>6</title>
+<g id="a_node9"><a xlink:title="IPv6 for low-power wireless networks">
+<polygon fill="green" stroke="green" points="251,-606 183,-606 183,-570 251,-570 251,-606"/>
+<text text-anchor="middle" x="217" y="-584.3" font-family="Times,serif" font-size="14.00">lowpan</text>
+</a>
+</g>
+</g>
+<!-- g->6 -->
+<g id="edge6" class="edge">
+<title>g->6</title>
+<path fill="none" stroke="black" d="M220.15,-652.82C219.63,-642.19 218.94,-628.31 218.34,-616.2"/>
+<polygon fill="black" stroke="black" points="221.84,-615.97 217.85,-606.15 214.84,-616.31 221.84,-615.97"/>
+</g>
+<!-- m -->
+<g id="node6" class="node">
+<title>m</title>
+<g id="a_node6"><a xlink:title="Board-level abstraction to identify sensor connections">
+<polygon fill="green" stroke="green" points="145.5,-534 48.5,-534 48.5,-498 145.5,-498 145.5,-534"/>
+<text text-anchor="middle" x="97" y="-512.3" font-family="Times,serif" font-size="14.00">mikrobus**</text>
+</a>
+</g>
+</g>
+<!-- I->m -->
+<g id="edge2" class="edge">
+<title>I->m</title>
+<path fill="none" stroke="black" d="M97,-569.7C97,-561.98 97,-552.71 97,-544.11"/>
+<polygon fill="black" stroke="black" points="100.5,-544.1 97,-534.1 93.5,-544.1 100.5,-544.1"/>
+</g>
+<!-- r -->
+<g id="node4" class="node">
+<title>r</title>
+<g id="a_node4"><a xlink:title="Dynamic RPC-like bus interface for I2C, SPI, UART, etc.">
+<polygon fill="green" stroke="green" points="135,-462 61,-462 61,-426 135,-426 135,-462"/>
+<text text-anchor="middle" x="98" y="-440.3" font-family="Times,serif" font-size="14.00">greybus</text>
+</a>
+</g>
+</g>
+<!-- n -->
+<g id="node5" class="node">
+<title>n</title>
+<g id="a_node5"><a xlink:title="Extend Greybus over netlink to userspace">
+<polygon fill="green" stroke="green" points="151,-356 49,-356 49,-320 151,-320 151,-356"/>
+<text text-anchor="middle" x="100" y="-334.3" font-family="Times,serif" font-size="14.00">gb-netlink**</text>
+</a>
+</g>
+</g>
+<!-- r->n -->
+<g id="edge4" class="edge">
+<title>r->n</title>
+<path fill="none" stroke="black" d="M98.33,-425.83C98.64,-409.64 99.11,-385.13 99.48,-366.27"/>
+<polygon fill="black" stroke="black" points="102.98,-366.26 99.67,-356.2 95.98,-366.13 102.98,-366.26"/>
+</g>
+<!-- n->g -->
+<g id="edge5" class="edge">
+<title>n->g</title>
+<path fill="none" stroke="black" d="M87.74,-356.26C53.38,-406.87 -36.47,-556.42 40,-637 49.89,-647.42 155.1,-641.38 169,-645 173.03,-646.05 177.13,-647.42 181.17,-648.98"/>
+<polygon fill="black" stroke="black" points="179.83,-652.21 190.4,-652.89 182.56,-645.77 179.83,-652.21"/>
+</g>
+<!-- m->r -->
+<g id="edge3" class="edge">
+<title>m->r</title>
+<path fill="none" stroke="black" d="M97.25,-497.7C97.36,-489.98 97.49,-480.71 97.61,-472.11"/>
+<polygon fill="black" stroke="black" points="101.11,-472.15 97.76,-462.1 94.11,-472.05 101.11,-472.15"/>
+</g>
+<!-- w -->
+<g id="node7" class="node">
+<title>w</title>
+<g id="a_node7"><a xlink:title="USB-interface to IEEE802.15.4 radio">
+<polygon fill="green" stroke="green" points="262,-462 168,-462 168,-426 262,-426 262,-462"/>
+<text text-anchor="middle" x="215" y="-440.3" font-family="Times,serif" font-size="14.00">wpanusb**</text>
+</a>
+</g>
+</g>
+<!-- b -->
+<g id="node11" class="node">
+<title>b</title>
+<g id="a_node11"><a xlink:title="USB interace to access CC1352 UART that encapulates WPANUSB in HDLC">
+<polygon fill="green" stroke="green" points="450,-356 304,-356 304,-320 450,-320 450,-356"/>
+<text text-anchor="middle" x="377" y="-334.3" font-family="Times,serif" font-size="14.00">usb_uart_bridge**</text>
+</a>
+</g>
+</g>
+<!-- w->b -->
+<g id="edge9" class="edge">
+<title>w->b</title>
+<path fill="none" stroke="black" d="M260.64,-425.92C265.92,-423.47 271.15,-420.82 276,-418 303.24,-402.17 331.22,-379.71 350.81,-362.78"/>
+<polygon fill="black" stroke="black" points="353.18,-365.35 358.4,-356.12 348.57,-360.08 353.18,-365.35"/>
+</g>
+<!-- i -->
+<g id="node8" class="node">
+<title>i</title>
+<g id="a_node8"><a xlink:title="Standards-based radio interface">
+<polygon fill="green" stroke="green" points="264,-534 164,-534 164,-498 264,-498 264,-534"/>
+<text text-anchor="middle" x="214" y="-512.3" font-family="Times,serif" font-size="14.00">ieee802154</text>
+</a>
+</g>
+</g>
+<!-- i->w -->
+<g id="edge8" class="edge">
+<title>i->w</title>
+<path fill="none" stroke="black" d="M214.25,-497.7C214.36,-489.98 214.49,-480.71 214.61,-472.11"/>
+<polygon fill="black" stroke="black" points="218.11,-472.15 214.76,-462.1 211.11,-472.05 218.11,-472.15"/>
+</g>
+<!-- 6->i -->
+<g id="edge7" class="edge">
+<title>6->i</title>
+<path fill="none" stroke="black" d="M216.26,-569.7C215.93,-561.98 215.53,-552.71 215.16,-544.11"/>
+<polygon fill="black" stroke="black" points="218.66,-543.95 214.73,-534.1 211.66,-544.25 218.66,-543.95"/>
+</g>
+<!-- z -->
+<g id="node10" class="node">
+<title>z</title>
+<g id="a_node10"><a xlink:title="Zephyr-based IEEE802.15.4 radio accepting HDLC over UART transactions">
+<polygon fill="green" stroke="green" points="422,-265 332,-265 332,-229 422,-229 422,-265"/>
+<text text-anchor="middle" x="377" y="-243.3" font-family="Times,serif" font-size="14.00">gateway**</text>
+</a>
+</g>
+</g>
+<!-- k -->
+<g id="node12" class="node">
+<title>k</title>
+<g id="a_node12"><a xlink:title="Zephyr-based applies Greybus transactions from IPv6/IEEE802154 to physical I2C, SPI, UART, etc.">
+<polygon fill="green" stroke="green" points="456.5,-143 297.5,-143 297.5,-107 456.5,-107 456.5,-143"/>
+<text text-anchor="middle" x="377" y="-121.3" font-family="Times,serif" font-size="14.00">greybus-mikrobus**</text>
+</a>
+</g>
+</g>
+<!-- z->k -->
+<g id="edge11" class="edge">
+<title>z->k</title>
+<path fill="none" stroke="black" d="M377,-228.81C377,-209.11 377,-176.58 377,-153.39"/>
+<polygon fill="black" stroke="black" points="380.5,-153.16 377,-143.16 373.5,-153.16 380.5,-153.16"/>
+</g>
+<!-- b->z -->
+<g id="edge10" class="edge">
+<title>b->z</title>
+<path fill="none" stroke="black" d="M377,-319.84C377,-307.28 377,-289.98 377,-275.5"/>
+<polygon fill="black" stroke="black" points="380.5,-275.11 377,-265.11 373.5,-275.11 380.5,-275.11"/>
+</g>
+<!-- e -->
+<g id="node13" class="node">
+<title>e</title>
+<g id="a_node13"><a xlink:title="Manifest for mikroBUS driver">
+<polygon fill="green" stroke="green" points="538.5,-60 325.5,-60 325.5,-24 538.5,-24 538.5,-60"/>
+<text text-anchor="middle" x="432" y="-38.3" font-family="Times,serif" font-size="14.00">manifest 1-wire EEPROM**</text>
+</a>
+</g>
+</g>
+<!-- k->e -->
+<g id="edge13" class="edge">
+<title>k->e</title>
+<path fill="none" stroke="black" d="M388.66,-106.82C396.17,-95.76 406.08,-81.18 414.52,-68.75"/>
+<polygon fill="black" stroke="black" points="417.63,-70.39 420.35,-60.15 411.84,-66.46 417.63,-70.39"/>
+</g>
+<!-- s -->
+<g id="node14" class="node">
+<title>s</title>
+<g id="a_node14"><a xlink:title="Over 1,000 different sensor, actuator and indicator options">
+<polygon fill="green" stroke="green" points="307,-60 243,-60 243,-24 307,-24 307,-60"/>
+<text text-anchor="middle" x="275" y="-38.3" font-family="Times,serif" font-size="14.00">sensor</text>
+</a>
+</g>
+</g>
+<!-- k->s -->
+<g id="edge12" class="edge">
+<title>k->s</title>
+<path fill="none" stroke="black" d="M341.11,-106.93C332.83,-102.28 324.32,-96.89 317,-91 308.89,-84.48 301.07,-76.27 294.43,-68.5"/>
+<polygon fill="black" stroke="black" points="296.77,-65.84 287.72,-60.34 291.36,-70.28 296.77,-65.84"/>
+</g>
+</g>
+</svg>
diff --git a/beagleconnect/media/image1.jpg b/beagleconnect/media/image1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..87ef9a9e304f1bcff0818a843bd5de77190ec239
Binary files /dev/null and b/beagleconnect/media/image1.jpg differ
diff --git a/index-tex.rst b/index-tex.rst
index 774f7f1714a270ad0767658ab974b6c58e166fa9..3db99a0d2d617a5864db6f08b934686b0443bd94 100644
--- a/index-tex.rst
+++ b/index-tex.rst
@@ -14,4 +14,5 @@ BeagleBoard Docs
beaglebone-black/index.rst
beaglebone-ai-64/index.rst
pocketbeagle/index.rst
- beaglebone-blue/index.rst
\ No newline at end of file
+ beaglebone-blue/index.rst
+ beagleconnect/index.rst
\ No newline at end of file
diff --git a/index.rst b/index.rst
index a7b488d467cda07c8ba58f8fed2e0b0cdb8dd486..ed0d66df659f21cb24e628c39a8ea593a1387102 100644
--- a/index.rst
+++ b/index.rst
@@ -27,6 +27,7 @@ Sections
beaglebone-ai-64/index.rst
pocketbeagle/index.rst
beaglebone-blue/index.rst
+ beagleconnect/index.rst
Indices and tables
############################