mikroBUS - Vaishnav Ma * Slides: https://linuxplumbersconf.org/event/7/contributions/669/attachments/669/1226/mikroBUS-Addon-Board-Driver.pdf * Brief: https://linuxplumbersconf.org/event/7/contributions/669/ * Demo video: https://www.youtube.com/watch?v=A3NyEjB5O38 * Video Demo on writing add-on board manifests : https://www.youtube.com/watch?v=uq8Bs0wtkQo * Instrunctions to reproduce Vaishnav's work: https://github.com/vaishnav98/manifesto/blob/LPC2020/README.md * More information about mikroBUS on Linux on eLinux wiki: * https://elinux.org/Mikrobus * Latest patch series: * [RFC,v2,0/3] mikroBUS driver for add-on boards * https://lore.kernel.org/patchwork/cover/1290144/ * Live tweets from Drew: https://twitter.com/pdp7/status/1298985616575668226 * Greybus can help improve the ability for the Linux kernel to discover Click add-on boards * Requires that Greybus manifest format be modified to add properties * Open problems: * Device drivers not using the unified device prop API (the current 111 supported boards did not have this issue only a very few 10-20 over the 150 devices with existing device driver support has the trouble) * TODO: * SERDEV devices support * update identifier fetching according to mikroBUS v3 * Rob H: * why are using greybus? * Vaishnav: we are planning to have mikrobus ports on remote microcontroller boards * Drew: also some beagle users are finding it annoying to have to reboot for any DT changes now that the Cape Manager is dead (due to no runtime DT overlay manager), Greybus seemed like a way to maybe solve that * Vaishnav: Also would like to clarify that the over the demo, I have been hotswapping/hotplugging the click boards. we are not trying to provide hotplug support but enable mikrobus as a probeable bus Using the Thread Networking Protocol for IoT Applications with embedded Linux by Michael Magyar * Slides: https://linuxplumbersconf.org/event/7/contributions/795/attachments/677/1238/Using_the_Thread_Networking_Protocol_for_IoT_Applications_with_embedded_Linux.pdf * Brief: https://linuxplumbersconf.org/event/7/contributions/795/ * Demo video: https://www.youtube.com/watch?v=yxEJ7FImF6Q * introduction to Thread, the advantages to using Thread instead of generic Linux IEEE 802.15.4 WPAN, and identify the challenges encountered while bringing up a Thread Border Router using Buildroot. * Chris F: what is the difference between Link-local and Mesh-local? * Michael: thread border routers will be a big improvement to opening it up to wider internet * Stefan: for spinel, all fw sits inside the microcontroller firmware? * Michael: for RCP, it is all moved to the host [slide 16] * Radio Co-Processor Design: minimal controller firmware running on the radio SoC, most of the Thread stack is running on the Host processor - allows for lower cost 802.15.4 SoC's * Host ot Radio controller communicate using Spinel * Thread Border Routers are the infrastructure, the Wi-Fi router of low power wireless networks, bringing Things into a standard IP based world Renode - Michael Gielda * What is Renode? Open source hardware-simulation framework * Website: https://renode.io/ * Brief: https://linuxplumbersconf.org/event/7/contributions/796/ * Slides: https://linuxplumbersconf.org/event/7/contributions/796/attachments/678/1240/Linux_plumbers_conference.pdf * Pre-silicon prototyping and hw/sw co-development * simulates many levels: CPU, SoC, peripherals, sensors, networking * no coding needed to setup a systsem - lots of existing demos exist * supported boareds: https://renode.readthedocs.io/en/latest/introduction/supported-boards.html * for example, you can run a fully simulated HiFive Unleashed RISC-V board on your PC, the actual board is $1,000 and not sold anymore so renode is great alternative * Drew: renode makes it easy to run Linux on RISC-V with a framebuffer https://twitter.com/pdp7/status/1227699717582266370 * Forgot to bring your dev board on a train journey? Renode can help:https://twitter.com/pdp7/status/1233799988242763778 * Renode integrates with GitLab, Wireshark, Robot, Jenkins, GDB, Verilator (Verilog simulator), USB/IP * PlatformIO integration for Zephyr * TensorFlow Lite support * Renode and Linux: RISC-V, ARM and OpenPOWER * Linux platforms: Kendryte K210, LiteX/Vexriscv, HiFive Unleashed PolarFire, and more * VexRiscv is an open RISC-V core that works well for FPGAs and is supported by Renode. It is even multi-core now too. * PolarFire SoC is first mass-produced Liunux-capable RISC-V SoC * Renode was used to simulate the SoC during hardware development * The dev board is coming soon: https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit * But renode can already simulate it * Renode and networking * mult-node capability for IoT testing * networoking simulation like packet loss * enables testing protocols and stacks * integrates with wireshark * enables continuous integration (CI) for IoT hardware and software including deployments * Robot Framework integration makes it easy to test lots of software: Linux, FreeRTOS, Zephyr, Tock, and much more * Tensorflow lite demo running in Zephyr on Litex/VexRiscv SoC * https://github.com/antmicro/litex-vexriscv-tensorflow-lite-demo ieee802154 and rpld updates - Stefan Schmidt * Brief: https://linuxplumbersconf.org/event/7/contributions/668/ * Slides: https://linuxplumbersconf.org/event/7/contributions/668/attachments/643/1176/LPC-2020-linux-wpan.pdf * IEEE 802.15.4 * low data rate and low power * star and p2p topologies * 6LoWPAN * builds upon 802.15.4 to give direct IPv6 addressing of nodes * header compression * Header size solution allows for payload of 75 bytes * Why linux-wpan? * goal is 802.15.4 and 6LoWPAN support in mainline linux * battery powered sensors will likely run RTOS not Linux, but border routers would be Linux * ATUSB dongle is great option for Linux * http://shop.sysmocom.de/products/atusb * new website! https://linux-wpan.org/ * wpanusb - generic usb device driver * extend usb interface spec to be more flexible * kselftest support * hwsim will be hooked into kselftest * linux-wpan future * beacon and MAC command frame * coordinate support in MAC and wpan-tools * scanning * add better support for HardMAC * RTOS interop support * RIOT, Contiki, Zephyr, OpenThread, Mbed OS * see slide 24 for detailed comparision chart of feature support across Linux and RTOS's * rpld ("ripple d") * routing protocol for low power and lossy networks * tree like topology in a mesh, one parent, n childs * rpld has two modes: storing and non-storing Using Linux, Zephyr, & Greybus for IoT - Christopher Friedt * Brief: https://linuxplumbersconf.org/event/7/contributions/814/ * Slides: https://linuxplumbersconf.org/event/7/contributions/814/attachments/672/1239/Using_Linux_Zephyr_and_Greybus_for_IoT_slides.pdf * Chris had an idea to have a dongle to that would expose all these IoT devices as normal Linux devices * Project Ara showed how to do this by making non-discoverable devices discoverable * Originally Chris had idea: Discoball - "discoverable buses for all" * Feedback told Chris to look at Greybus * Greybus uses manifest to describe what exists * Applications Processor: lives inside linux * SVC: supervisory controller * Gbridge: Greybus for IoT talk by Alexandre Baillon at ELCE 2016 * implement SVC in software * communicate with AP (linux kernel) via netlink * Gbridge host controllers: UART, BLE, GB Sim, TCP/IP * Chris has decided to foucs on TCP/IP as all Greybus needs is a reliable transport * Chris introduces the Zephyr RTOS * BSD sockets work out of the box for IoT * it uses Kconfig just like Linux * Chris has gotten lots of support from the zephyr community * Device Tree: it might be a suprise to Linux people how Zephyr uses DT * Porting Greybus to Zephyr * original NuttX implmentation * Zephyr devices are instantiated by a macro * Greybus manifest is different than Device Tree * Define the Greybus devices in DT and then translate that into a manifest * Keep the intelligence on the host, don't implement them on the microcontroller * Vaishnav has done great job of re-using existing Linux drivers * Greybus in Linux: a proposal * Currently with the Gbridge Topology, the SVC lives in userspace and effectively routes messages between AP and other Greybus devices * By using a connected socket (or really any file descriptor), we can move the SVC into the kernel * Gbridge would then stay in userspace as mainly an auth + session broker * Open problems: Greybus * authentication * encryption * comissioning, joining, rejoin * cloud: mgmt of devices at scale * Demo videos * Blink an LED using Linux, Zephyr & Greybus via IEEE 802.15.4 https://www.youtube.com/watch?v=hd60CbiUN1g&feature=youtu.be * Blink and LED using Linux, Zephyr, & Greybus via Bluetooth https://www.youtube.com/watch?v=Y_6y6gpZ2GA&feature=youtu.be * Using Linux, Zephyr, & Greybus for IoT with the CC1352R SensorTag https://www.youtube.com/watch?v=6SNkjiDJ3KY&feature=youtu.be * Current development branch for Greybus in Zephyr https://github.com/cfriedt/zephyr (branch greybus-service-lpc2020) * Zephyr Getting Started Guide / Slack https://docs.zephyrproject.org/latest/getting_started/index.html * BeagleConnect (Hardware Rev C) / Slack https://github.com/jadonk/beagleconnect