https://elinux.org/api.php?action=feedcontributions&user=Panto&feedformat=atomeLinux.org - User contributions [en]2024-03-28T14:27:25ZUser contributionsMediaWiki 1.31.0https://elinux.org/index.php?title=Device_tree_kernel_summit_2017_action_items&diff=454061Device tree kernel summit 2017 action items2017-10-31T11:00:00Z<p>Panto: Device Tree Workshop 2017 Action Items</p>
<hr />
<div>= Device Tree Workshop 2017 Action Items =<br />
<br />
* YAML data schema must enable 3rd party tools, switch from using anchors and labels as in YAML to special properties.<br />
# foo: &foo_label -> foo: { $label: foo_label }<br />
# prop: [ *foo_label, 1 ] -> prop: [ $foo_label, 1 ]<br />
<br />
Assigned: Pantelis<br />
<br />
* YAML tools need to preserve comments (yes/no)<br />
# Hard requirement or not?<br />
# Comments are preserved for ruamel<br />
# Comments are not preserved for yamldt<br />
<br />
Assigned: None<br />
<br />
* Select YAML or JSON for deduplicated machine readable format.<br />
# Example in source YAML format is: foo: [ "string", 10+2, $reference, !int16 8 ] declares a property which is comprised of a sequence of 4 scalars. One string equal to "string", one integer/cell value with the value 12, a reference to a node with the label 'reference' and finally a 16 bit value with a value of 8. <br />
# YAML is easier to read and maps to source file format. Easily distinguish strings, integer values and references. Type information is preserved too. foo: [ "string", 12, $reference, !int16 8 ] Strings are always quoted, integer values are expressions, references are tagged by being unquoted strings starting with $, and if a tag exists it is preserved.<br />
# JSON is easier for machines to parse but does not preserve types. foo: [ "string", 12, "$reference", 8 ] Requires use of the bindings to retrieve type information. Quoted strings maybe either strings or references, values require binding info to know whether they are 32 bit or something elese.<br />
# Alternative JSON encoding with type information using escapes. foo: [ "string", 12 "\aref reference", "\aint8 8" ] Would require disallowing presence of the \a characters in normal strings and encoding tags that can not be deduced in quoted strings. Pro is that it's straight forward, con looks weird for human readers.<br />
<br />
Assigned: Grant, Pantelis<br />
<br />
* YAML schemas<br />
# Grant is using ruamel, validates using json schema format file. Hand written, how it would pick rules from binding files?<br />
# Pantelis is using yamldt, no extra format file, pick up everything from bindings.<br />
# Handle extra constraints. [https://www.ietf.org/archive/id/draft-wright-json-schema-validation-01.txt JSON schema] does not define arbitrary constraints as expressions. They are needed for validation of busses etc. yamldt can eventually generate constraints from a subset of the JSON schema.<br />
<br />
Assigned: Grant, Pantelis<br />
<br />
* Extendable schemas<br />
# Core bindings refer to hardware definitions<br />
# Operating systems/bootloaders may require extensions that are configuration related or specific use related. I.e. Linux specific configuration properties, u-boot spl node tags, etc.<br />
# There can be a systematic method of separating and then combining them for validation/code generation<br />
<br />
Assigned: None<br />
<br />
* Code generation<br />
# Project require generation of code/defines from device tree sources.<br />
# u-boot<br />
# Zephyr<br />
# Xilinx?<br />
# Possible to have a common infrastructure to generate code, based on bindings?<br />
<br />
Assigned: None<br />
<br />
* Device Tree Overlays<br />
# How they should be structured? Differences between how Android does it and how Linux does it.<br />
# Where should they live? Part of the kernel tree or external repo?<br />
# Git submodules use if external repo?<br />
<br />
Assigned: None<br />
<br />
* Device Tree duplication avoidance.<br />
# New marvell parts are using highly duplicated IP. How to support those cases<br />
# Thomas: Use CPP macros -> works now<br />
# David: Could be easier if relative paths would work: <&/foo/bar> -> <&../bar><br />
# David: Node names generated via expression might make things easier. What kind of expressions?<br />
# Pantelis: Possible expression might refer to a property, could tie in with unit-names. foo@10 { reg = <10>; }; -> foo@{reg[0]} { reg = <10>; };<br />
# YAML can use merge keys and templating instead. Not specified yet.<br />
<br />
Assigned: None<br />
<br />
* DT foreign bindings<br />
# Different projects use the same bindings differently<br />
# devicetree.org?<br />
# Could be part of Extendable Schemas<br />
<br />
Assigned: None<br />
<br />
* Sharing generic bindings<br />
# Geert: On certain cases generic bindings apply to devices in the whole domain<br />
# Inheritable bindings. How to define them in schemas?<br />
<br />
Assigned: None<br />
<br />
* Linux kernel device tree overlays specific<br />
# configfs patch not admissible yet, due to the way that the kernel breakage<br />
# Culprit is of_* accessor methods that directly return pointer to device tree properties<br />
# Switch to using a safer API for drivers<br />
# Locking should be revisited or revised completely<br />
# Pantelis: switch drivers to using devm_ managed memory accessor methods<br />
<br />
Assigned: Frank, Pantelis</div>Pantohttps://elinux.org/index.php?title=Device_tree_future&diff=454036Device tree future2017-10-31T09:35:01Z<p>Panto: Added Action Items wiki link</p>
<hr />
<div>[[Category:Device_tree]]<br />
<br />
[[Device_Tree | Top Device Tree page]]<br />
<br />
== Devicetree Validation ==<br />
<br />
See section "Devicetree Verification".<br />
<br />
== Devicetree Verification ==<br />
<br />
[[Device_Tree_presentations_papers_articles#validation | Presentations ]] about verification.<br />
<br />
The verification project made progress around the time of Linux Plumbers 2015,<br />
then stalled out.<br />
<br />
Grant Likely has re-awakened the project at Linux Plumbers 2016:<br />
* [[Media:Grant_likely_plumbers_2016_DT_Schema_Proposal.odp | [PDF]]] "Device Tree Schema Discussion", Linux Plumbers, November 2016, Grant Likely<br />
* [[Device_tree_plumbers_2016_etherpad | local cache of etherpad notes]] (Grant's presentation is the first presentation.)<br />
* Discussion will occur on the [http://elinux.org/Device_Tree#Core_devicetree_binding_.2F_Devicetree_Specification_Mailing_List devicetree-spec email list].<br />
* Development is hosted on github at<br />
** git://github.com/glikely/dtgendoc<br />
** http://github.com/glikely/dtgendoc<br />
<br />
Grant Likely and Pantelis Antoniou have again re-awakened the project at the<br />
[[Device_tree_future#Kernel_Summit_2017.2C_Devicetree_Workshop | Kernel Summit 2017, Devicetree Workshop]]<br />
(and postings to the devicetree mail list shortly before the summit).<br />
<br />
== Devicetree Specification ==<br />
<br />
[http://www.devicetree.org/specifications-pdf Devicetree Specification Release 0.1], located on the<br />
[https://www.devicetree.org/specifications/ Devicetree Specification page]<br />
has superseded the ePAPR for the Linux kernel.<br />
<br />
The Devicetree Specification [[Device_tree_future#Devicetree_Specification | will continue to be updated]].<br />
<br />
<br />
[[Media:Devicetree_specification_linaro_connect_bangkok_2016.pdf|PDF presentation]]<br />
of the plans for the specification organization and the proposed schedule.<br />
<br />
The update process is occurring in the <s>http://webdev.linaro.org/devicetree.org/</s><br />
[http://devicetree.org/ devicetree.org organization].<br />
<br />
Related discussion occurs on the<br />
[[Device_Tree#Core_devicetree_binding_.2F_Devicetree_Specification_Mailing_List | devicetree-spec]]<br />
email list.<br />
<br />
== Linux Plumbers 2015 Device Tree Track ==<br />
<br />
=== presentation material ===<br />
<br />
* [[Media:Plumbers_2016_dt_schedule.pdf | schedule (PDF) - Frank Rowand]]<br />
* [[Media:Plumbers_2015_dt_DT-plumbers-2015.pdf | Dynamic DT and tools (pdf) - Pantelis Antoniou]]<br />
* [[Media:Plumbers_2016_dt_Devicetree_Overlays_at_Juniper.pdf | Device Tree Overlay use at Juniper Networks (PDF) - Guenter Roeck]]<br />
* [[Media:Plumbers_2016_dt_DT_Binding_Documentation.pdf | DT Binding Documentation (PDF) - Matt Porter]]<br />
* [[Media:Plumbers_2016_dt_device_tree_doc.pdf | Device Tree Documentation (PDF) - Frank Rowand]]<br />
* [[Media:Plumbers_2016_dt_device_tree_tools.pdf | Device Tree Tools (PDF) - Frank Rowand]]<br />
<br />
=== etherpad notes ===<br />
<br />
https://etherpad.openstack.org/p/LPC2015_Device_Tree<br />
<br />
[[Device_tree_plumbers_2015_etherpad | local cache of etherpad notes]]<br />
<br />
=== final schedule ===<br />
<br />
<pre><br />
1:30 Intro<br />
Frank Rowand<br />
1:35 Device Tree Overlays<br />
Pantelis Antoniou, Guenter Roeck<br />
2:00 Overlays, some times a good idea sometimes not.<br />
Pantelis Antoniou<br />
2:15 Device Tree Documentation<br />
Matt Porter Frank Rowand<br />
2:30 Chat With The dtc Maintainers, part 1<br />
David Gibson, Jon Loeliger<br />
2:45 ----- Tea Break -----<br />
3:00 Chat With The dtc Maintainers, part 2<br />
David Gibson, Jon Loeliger<br />
3:10 Overlays and tools for sanity.<br />
Pantelis Antoniou<br />
3:25 Device Tree Tools<br />
Frank Rowand<br />
3:40 Device Tree probe order and parallel device probing<br />
Pantelis Antoniou<br />
3:50 Device tree round up<br />
Frank Rowand<br />
</pre><br />
<br />
=== '''draft''' schedule ===<br />
<br />
<pre><br />
<br />
01 -- Device Tree Overlays - Pantelis<br />
Device Tree Overlays are now in the mainline kernel. This session<br />
will cover what they are, how they are used.<br />
<br />
As part of this session I will examine device tree overlays, device<br />
tree changeset, the phandle resolution mechanism, overlay overlap<br />
removal checks and finally device tree variants (or quirks).<br />
<br />
Devicetree overlay use in Juniper products - Guenter<br />
<br />
The Juniper use case will be discussed:<br />
<br />
At Juniper, we use devicetree overlays to manage a variety of cards<br />
which can be inserted and removed at runtime.<br />
<br />
In this session, I will describe the basic system architecture, our<br />
requirements, and why we decided to use devicetree overlays to meet<br />
those requirements. I will also dive into the actual implementation<br />
of our card management framework in the Linux kernel, and explore<br />
some of the limitations of the current devicetree overlay code.<br />
<br />
02 -- was folded into 01<br />
<br />
03 -- Overlays, some times a good idea sometimes not. - Pantelis<br />
This session will cover supported and not supported overlay cases.<br />
<br />
04 -- Device Tree Documentation - Frank<br />
What device tree documentation and tutorials exist and where to find<br />
them. What is needed?<br />
<br />
What new documentation is expected this year?<br />
<br />
Can we bring consistency to the documentation style/syntax?<br />
<br />
05 -- Chat With The dtc Maintainers - Frank<br />
This session is an opportunity to ask questions of the dtc maintainers<br />
or listen to their thoughts on dtc related topics.<br />
<br />
06 -- Overlays and tools for sanity. - Pantelis<br />
Device Tree overlays represent a big change for the device tree in<br />
the kernel. Where as of old the device tree was something static,<br />
now it's something that can change at runtime.<br />
<br />
We could use some new tools to help us when creating them (compile<br />
time) and some kernel tooling to help when applying them (run time).<br />
<br />
07 -- Device Tree Tools - Frank<br />
What tools exist to support device tree development and<br />
debugging? Where are they? What new tools have been proposed or<br />
requested?<br />
<br />
08 -- Device Tree probe order and parallel device probing - Pantelis<br />
The new dynamic device tree capabilities entails marking not only<br />
the location of phandles but the references made to them. We can use<br />
that information to construct a device probe order schedule that can<br />
be used to support parallel device probing which is an obvious win<br />
for kernel boot time.<br />
<br />
If earlier sessions run long, this one may be shortened or deleted.<br />
<br />
09 -- Device tree round up - Frank<br />
Review previous sessions, round up loose ends<br />
<br />
</pre><br />
<br />
=== Material to review '''before''' the conference ===<br />
<br />
The purpose of the Linux Plumbers conference is to '''discuss''' things.<br />
The conference is not a good place to go if you want to look at slides<br />
and listen to canned presentations.<br />
<br />
The discussions will work better if the attendees have prepared in advance,<br />
and have a basic understanding of the technology and issues to be discussed.<br />
The goal of this section is to provide the resources needed to be prepared<br />
to discuss.<br />
<br />
==== Device Tree 101 ====<br />
<br />
If you are new to Device Tree, these resources will start you on the path to a basic understanding.<br />
<br />
* '''An introduction'''<br />
** [https://lwn.net/Articles/572692/ Device trees I: Are we having fun yet?] - Neil Brown, LWN.net November 2013<br />
** [https://lwn.net/Articles/573409/ Device trees II: The harder parts] - Neil Brown, LWN.net November 2013<br />
** "Device Tree for Dummies", ELC 2014 by Thomas Petazzoni<br />
*** [[Media:petazzoni-device-tree-dummies_0.pdf|PDF]]<br />
*** [https://www.youtube.com/watch?v=uzBwHFjJ0vU YouTube video]<br />
* '''More advanced material'''<br />
** "The Device Tree as a Stable ABI: A Fairy Tale?", ELC 2015 by Thomas Petazzoni<br />
*** http://elinux.org/images/0/0a/The_Device_Tree_as_a_Stable_ABI-_A_Fairy_Tale%3F.pdf<br />
** "Device Tree, the Disaster so Far", ELC Europe 2013 by Mark Rutland<br />
*** [[Media:Rutland-presentation_3.pdf]]<br />
*** [https://www.youtube.com/watch?v=xamjHjjyeBI YouTube video]<br />
<br />
==== Overlays ====<br />
<br />
* "Transactional Device Tree & Overlays: Making Reconfigurable Hardware Work", ELC 2015 by Pantelis Antoniou<br />
** [[Media:Dynamic-dt-keynote-v3.pdf|PDF]]<br />
** [http://www.youtube.com/watch?v=3Ag7ZBC_Nts YouTube video]<br />
* Problem statements<br />
** IO boards, eg beaglebone capes<br />
** PPC sub-tree beneath hot-plug PCI<br />
*** http://www.spinics.net/lists/linux-pci/msg40740.html<br />
*** It might be possible to use existing dynamic add and remove functions (CONFIG_OF_DYNAMIC) for this purpose<br />
** Quirks - TODO<br />
*** [http://www.spinics.net/lists/devicetree/msg69490.html [PATCH 0/4] Device Tree Quirks & the Beaglebone]<br />
*** [http://www.spinics.net/lists/devicetree/msg69565.html cpu card plugged into multiple carrier card variants, post manufacturing]<br />
** devices present only during manufacturing<br />
*** [http://www.spinics.net/lists/devicetree/msg82817.html Dealing with optional i2c devices in a devicetree ]<br />
<br />
==== Probe Ordering ====<br />
<br />
* Alexander Holler<br />
** 2014.05.12 [https://lkml.org/lkml/2014/5/12/452 [RFC PATCH 0/9] dt: dependencies (for deterministic driver]<br />
* Tomeu Vizoso<br />
** 2015.05.25[http://thread.gmane.org/gmane.linux.kernel.gpio/8465 [PATCH 00/21] On-demand device registration]<br />
** 2015.06.17 [http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351061.html [PATCH 00/13] Discover and probe dependencies]<br />
** 2015.07.28 [https://lkml.org/lkml/2015/7/28/534 [PATCH v2 0/22] On-demand device probing]<br />
** 2015.08.06 [http://article.gmane.org/gmane.linux.acpi.devel/77867 [PATCH v3 0/18] On-demand device probing]<br />
** 2015.08.06 [https://lkml.org/lkml/2015/8/6/389 [PATCH v3 0/18] On-demand device probing (2nd archive)]<br />
<br />
== Linux Plumbers 2016 Device Tree Track ==<br />
<br />
=== presentation material ===<br />
<br />
* [[Media:Grant_likely_plumbers_2016_DT_Schema_Proposal.odp | [PDF]]] "Device Tree Schema Discussion"- Grant Likely<br />
* [[Media:Dt_hw_config_policy.pdf | [PDF] ]] "Device tree Hardware Description vs Configuration vs Policy"- Frank Rowand<br />
* [[Media:Dt_tools_status.pdf | [PDF] ]] "Device Tree Tools Status" - Frank Rowand<br />
<br />
=== etherpad notes ===<br />
<br />
[[Device_tree_plumbers_2016_etherpad | local cache of etherpad notes]]<br />
<br />
== Kernel Summit 2017, Devicetree Workshop ==<br />
<br />
=== Presentation Materials ===<br />
* [[Media:DTWorkshop2017_Agenda.pdf | [PDF]]] Agenda slides<br />
* [[Media:Dt summit 2017 data flow.JPG | [JPG]]] Devicetree data flow drawing - Frank Rowand<br />
* [[Media:DTWorkshop2017_Zephyr.pdf | [PDF]]] "Devicetree in Zephyr" - Kumar Gala<br />
* [[Media:DTWorkshop2017_DT_Generic_Bindings.pdf | [PDF]]] "DT Generic Bindings" - Geert Uytterhoeven<br />
* [[Media:DTWorkshop2017-duplicate-data.pdf | [PDF]]] "Duplicate Data" - Thomas Petazzoni<br />
* [[Media:DTWorkshop2017_foreign_bindings.pdf | [PDF]]] "Foreign Bindings" - Maxime Ripard<br />
<br />
=== Notes ===<br />
<br />
* [[Device_tree_kernel_summit_2017_etherpad | Local cache of Etherpad notes]]<br />
* [[Device_tree_kernel_summit_2017_notes_julia | Notes from Julia Lawall]]<br />
<br />
=== Audio Recording ===<br />
Grant Likely has audio recordings of the entire workshop, but they are large files and haven't been published yet. Contact Grant if you want a copy of the audio.<br />
<br />
=== Action Items ===<br />
* [[Device_tree_kernel_summit_2017_action_items| Device Tree Workshop Action Items ]]</div>Pantohttps://elinux.org/index.php?title=File:IoT_Made_Easy.pdf&diff=422316File:IoT Made Easy.pdf2016-10-17T07:58:49Z<p>Panto: Linux + Zephyr, how to run IoT on dirt cheap devices</p>
<hr />
<div>Linux + Zephyr, how to run IoT on dirt cheap devices</div>Pantohttps://elinux.org/index.php?title=ELC_2015_Presentations&diff=377336ELC 2015 Presentations2015-03-31T20:53:51Z<p>Panto: DT overlays slideset</p>
<hr />
<div>Presentations from [http://events.linuxfoundation.org/events/embedded-linux-conference/program/schedule ELC 2015].<br />
<br />
== Videos ==<br />
Videos will be listed here when available:<br />
<br />
== Table of Presentations ==<br />
<br />
NOTE: If you add a wikilink to your presentation and attempt to upload it via the link, it may fail. If it does, use the [[Special:Upload]] page to upload your file.<br />
<br />
== Presenters ==<br />
=== Day 1 Presentations ===<br />
{| border="1" cellspacing="0" cellpadding="4"<br />
|- bgcolor="#c0e0e0"<br />
|- bgcolor="#c0e0e0"<br />
| align="center" | '''Session Description'''<br />
| align="center" | '''Presenter(s)''' <br />
| align="center" | '''Presentation'''<br />
| align="center" | '''Transcript Status'''<br />
| align="center" | '''Video'''<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 1, 9:00am<br />
|-<br />
|Driving standards and Open Source to Grow the Internet of Things<br />
|Mark Skarpness, Director of Systems Engineering at Intel<br />
|[[Media:Driving standards and Open Source to Grow the Internet of Things.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 1, 9:30am<br />
|-<br />
|Project Ara<br />
|Paul Eremenko, Head of Project Ara, ATAP at Google & Marti Bolivar, Project Ara Software Lead, Google<br />
|[[Media:Project Ara.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 1, 10:30am<br />
|-<br />
|Android OTA Updates<br />
|Andrew Boie, Intel<br />
|[[Media:Android OTA Updates.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Generalizing Android for Low-Cost 64-Bit ARM-Based Community Boards<br />
|Khasim Syed Mohammed, Linaro<br />
|[[Media:Generalizing Android for Low-Cost 64-Bit ARM-Based Community Boards.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|An Overview of the Kernel DMAEngine Subsystem<br />
|Maxime Ripard, Free Electrons<br />
|[[Media:An Overview of the Kernel DMAEngine Subsystem.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Tuning systemd for Embedded<br />
|Alison Chaiken, Mentor Graphics<br />
|[[Media:Tuning systemd for Embedded.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|The Open Interconnect Consortium (OIC) Security Model and Vision<br />
|Ned Smith, Intel<br />
|[[Media:The Open Interconnect Consortium (OIC) Security Model and Vision.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 1, 11:30am<br />
|-<br />
|Build and Distributing SDK Add-Ons<br />
|Dave Smith, NewCircle<br />
|[[Media:Build and Distributing SDK Add-Ons.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Fuzzing the Media Framework in Android<br />
|Alexandru Blanda, Intel<br />
|[[Media:Fuzzing the Media Framework in Android.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Autonomous Navigation for an OMAP4 Nano-Drone<br />
|Grégoire Gentil, Always Innovating<br />
|[[Media:Autonomous Navigation for an OMAP4 Nano-Drone.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Buildroot: Embedded Linux for Small Devices and Makefile Enthusiasts<br />
|Stephanie Lockwood-Childs, VCT Labs<br />
|[[Media:Buildroot- Embedded Linux for Small Devices and Makefile Enthusiasts.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|LTSI: Latest Status and Kernel Testing<br />
|Tsugikazu Shibata, NEC<br />
|[[Media:LTSI-_Latest_Status_and_Kernel_Testing.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Virtualization for Small Devices<br />
|Jesse Zbikowski and Stephan Okay, Cratus technologies<br />
|[[Media:Virtualization for Small Devices.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 1, 2:00pm<br />
|-<br />
|Solving Global Illiteracy With Android and XPRIZE<br />
|Jono Bacon, XPRIZE<br />
|[[Media:Solving Global Illiteracy With Android and XPRIZE.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Anatomy of a Screenshot<br />
|Rodrigo Chiossi, Intel<br />
|[[Media:Anatomy of a Screenshot.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Using Intel Edison to Fuse Embedded Linux With Existing Drone Flight Controllers<br />
|Mark F. Brown, Intel & Joel Rosenzweig, Intel<br />
|[[Media:Using Intel Edison to Fuse Embedded Linux With Existing Drone Flight Controllers.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Bluetooth 4.2 - New Features for Linux and IoT <br />
|Marcel Holtmann, Intel<br />
|[[Media:Bluetooth 4.2 - New Features for Linux and IoT.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|The Device Tree as a Stable ABI: A Fairy Tale?<br />
|Thomas Petazzoni, Free Electrons<br />
|[[Media:The_Device_Tree_as_a_Stable_ABI-_A_Fairy_Tale?.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|IoTivity and Embedded Linux Support<br />
|Kishen Maloor, Intel<br />
|[[Media:IoTivity and Embedded Linux Support.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 1, 3:00pm<br />
|-<br />
|Android’s New Stream-Based Camera Architecture<br />
|Balwinder Kaur, ON Semiconductor<br />
|[[Media:Android’s New Stream-Based Camera Architecture.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Chaining HALs <br />
|Hunyue Yau, HY Research<br />
|[[Media:Chaining HALs.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Performance Analysis Using the perf Suite<br />
|Mans Rullgard<br />
|[[Media:Performance Analysis Using the perf Suite.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Optimize uClinux for ARM Cortex-M4<br />
|Jim Huang, South Star Xelerator & Jeff Liaw, National Cheng Kung University<br />
|[[Media:Optimize uClinux for ARM Cortex-M4.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|10 Years of Open Source Robotics<br />
|Laurent Pinchart, Ideas on Board<br />
|[[Media:10 Years of Open Source Robotics.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|The OpenDOF Project - An Open Distributed Object Framework For The IoT<br />
|Bryant Eastham, Panasonic<br />
|[[Media:The OpenDOF Project - An Open Distributed Object Framework For The IoT.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 1, 4:20pm<br />
|-<br />
|Implementation of the Global Task Scheduler in big.LITTLE Android Platforms<br />
|Michael E. Anderson, The PTR Group<br />
|[[Media:Implementation of the Global Task Scheduler in big.LITTLE Android Platforms.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Utilizing the Android Open Source Project to Support Controllers for Single-Use Devices. (X-Ray Guns! Pew Pew!)<br />
|Ben Friedberg, SDG Systems<br />
|[[Media:Utilizing the Android Open Source Project to Support Controllers for Single-Use Devices.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Flying Penguins: Embedded Linux Applications for Autonomous UAVs<br />
|Clay McClure<br />
|[[Media:Flying_Penguins-_Embedded_Linux_Applications_for_Autonomous_UAVs.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Introduction to IEEE 1588 Precision Time Protocol (PTP) Using Embedded Linux Systems<br />
|Insop Song, Gainspeed<br />
|[[Media:Introduction to IEEE 1588 Precision Time Protocol (PTP) Using Embedded Linux Systems.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Poky meets Debian: Understanding How to Make an Embedded Linux by Using an Existing Distribution's Source Code<br />
|Yoshitake Kobayashi, Toshiba<br />
|[[Media:Poky meets Debian Understanding How to Make an Embedded Linux by Using an Existing Distribution's Source Code.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Ready-Made Recipes to Add Security and Data<br />
|Dominig ar Foll, Intel<br />
|[[Media:Ready-Made Recipes to Add Security and Data.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 1, 5:20pm<br />
|-<br />
|Memory Management Internals<br />
|Karim Yaghmour, Opersys<br />
|[[Media:Memory Management Internals.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Android Multilib Build Cheat Sheet<br />
|Amit Pundir, Linaro<br />
|[[Media:Android Multilib Build Cheat Sheet.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Teaching More Fish to Fly<br />
|John Hawley, Intel<br />
|[[Media:Teaching More Fish to Fly.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Automated Flashing and Testing for Continuous Integration<br />
|Igor Stoppa, Intel<br />
|[[Media:Automated Flashing and Testing for Continuous Integration.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Tizen: System-Wide Memory Defragmenter Without Killing Any Application <br />
|Pintu Kumar, Samsung<br />
|[[Media:Tizen-_System-Wide_Memory_Defragmenter_Without_Killing_Any_Application.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Getting Started with AllJoyn<br />
|Ivan R. Judson, Microsoft<br />
|[[Media:Getting Started with AllJoyn.pdf|PDF]]<br />
|<br />
|<br />
|<br />
|}<br />
<br />
===Day 2 Presentations===<br />
{| border="1" cellspacing="0" cellpadding="4"<br />
|- bgcolor="#c0e0e0"<br />
|- bgcolor="#c0e0e0"<br />
| align="center" | '''Session Description'''<br />
| align="center" | '''Presenter(s)''' <br />
| align="center" | '''Presentation'''<br />
| align="center" | '''Transcript Status'''<br />
| align="center" | '''Video'''<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 2, 9:00am<br />
|-<br />
|Android Verified Boot <br />
|Andrew Boie, Intel<br />
|[[Media:Android Verified Boot.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Heterogeneous Multi-Core Architecture Support for Dronecode<br />
|Mark Charlebois, Qualcomm Innovation Center (QuIC) <br />
|[[Media:Heterogeneous Multi-Core Architecture Support for Dronecode.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Understanding Embedded Linux Benchmarking Using Kernel Trace Analysis <br />
|Alexis Martin, Inria<br />
|[[Media:Understanding Embedded Linux Benchmarking Using Kernel Trace Analysis.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|A Scalable, Cloud-based Device Reprogramming Architecture <br />
|James Simister, Panasonic<br />
|[[Media:A Scalable, Cloud-based Device Reprogramming Architecture.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Customizing AOSP for my Device <br />
|Rafael Coutinho, Phi Innovations<br />
|[[Media:Customizing AOSP for my Device.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Building Multi-Processor FPGA Subsystems – Allowing Linux to Supervise Embedded Real-Time Processing Systems<br />
|Chris Martin, Altera<br />
|[[Media:Building Multi-Processor FPGA Subsystems.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 2, 10:00am<br />
|-<br />
|Implementing Controls with Bluetooth SMART in Android<br />
|Michael E. Anderson, The PTR Group<br />
|[[Media:Implementing Controls with Bluetooth SMART in Android.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Open Source Drones on Linux<br />
|Lorenz Meier MLC/TLC<br />
|[[Media:Open Source Drones on Linux.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|NAND Support: (New?) Challenges for the MTD/NAND Subsystem <br />
|Boris Brezillon, Free Electrons<br />
|[[Media:NAND Subsystem.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Building IoT systems with openHAB<br />
|Matt Porter, Konsulko<br />
|[[Media:Building IoT systems with openHAB.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 2, 11:20am<br />
|-<br />
|Room For Cooperation: Bionic and musl<br />
|Bernhard Rosenkränzer, Linaro<br />
|[[Media:Room For Cooperation: Bionic and musl.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Aster: A Remote GUI Control Tool for the Android Platform<br />
|Yongqin Liu, Linaro<br />
|[[Media:Aster: A Remote GUI Control Tool for the Android Platform.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Application of Data Fusion to Aerial Robotics<br />
|Paul Riseborough, 3DRobotics<br />
|[[Media:Application of Data Fusion to Aerial Robotics.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Embedded Distributed Systems: A Case of Study<br />
|Victor Rodriguez, Intel<br />
|[[Media:Embedded_Distributed_Systems-_A_Case_of_Study.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Transitioning From uclibc to musl for Embedded Development<br />
|Rich Felker, Openwall<br />
|[[Media:Transitioning From uclibc to musl for Embedded Development.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Security Architecture in the IOT Age<br />
|Stephen Arnold, VCT Labs<br />
|[[Media:Security Architecture in the IOT Age.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 2, 1:40pm<br />
|-<br />
|Dronecode Project and Autopilot With Linux<br />
|Andrew Tridgell, Technical Steering Committee Chair of Dronecode Project<br />
|[[Media:Dronecode Project and Autopilot With Linux.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 2, 2:10pm<br />
|-<br />
|IoT Panel<br />
|Dominig Ar Foll, Intel (Tizen); Greg Burns, AllSeen Alliance; Bryant Eastham, Panasonic; Guy Martin, Samsung; Tim Bird, Sony Mobile (Moderator)<br />
|<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 2, 3:25pm<br />
|-<br />
|Platform-Level UI Customization<br />
|Karim Yaghmour, Opersys<br />
|[[Media:Platform-Level UI Customization.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Upstreaming, Downstreaming, 'Sidestreaming': How Can Android-Based Projects Work Together?<br />
|Bernhard Rosenkränzer, Linaro<br />
|[[Media:Upstreaming, Downstreaming, 'Sidestreaming': How Can Android-Based Projects Work Together?.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|The Syria Airlift Project: Open-Sourcing Humanitarian Airlift <br />
|Mark Jacobsen, U.S. Air Force<br />
|[[Media:The_Syria_Airlift_Project-_Open-Sourcing_Humanitarian_Airlift.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Last One Out, Turn Off The Lights <br />
|Geert Uytterhoeven<br />
|[[Media:Last One Out, Turn Off The Lights.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Generic PHY Framework<br />
|Kishon Vijay Abraham, Texas Instruments<br />
|[[Media:Generic PHY Framework.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Linux for Microcontrollers: From Marginal to Mainstream<br />
|Vitaly Wool, Softprise Consulting OU<br />
|[[Media:Linux_for_Microcontrollers-_From_Marginal_to_Mainstream.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 2, 4:25pm<br />
|-<br />
|Android Customization: From the Kernel to the Apps<br />
|Cédric Cabessa, Genymobile<br />
|[[Media:Android Customization: From the Kernel to the Apps.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Embedded Linux moves into High School Robotics<br />
|Michael E. Anderson, The PTR Group<br />
|[[Media:Embedded Linux moves into High School Robotics.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Freedreno Status Report: Upstream and FOSS Graphics on ARM/SoC Devices <br />
|Rob Clark, Red Hat<br />
|[[Media:Freedreno Status Report: Upstream and FOSS Graphics on ARM/SoC Devices.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Creating Open Hardware Tools <br />
|David Anders, Intel<br />
|[[Media:elc2015-opentools.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Sigrok: Adventures in Integrating a Power-Measurement Device <br />
|Bartosz Golaszewski, BayLibre<br />
|[[Media:Sigrok- Adventures in Integrating a Power-Measurement Device.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Building a General Purpose Android Workstation<br />
|Ron Munitz<br />
|[[Media:Building a General Purpose Android Workstation.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 2, 5:25pm<br />
|-<br />
|Creating Platform Development Tools<br />
|François-Denis Gonthier, Opersys<br />
|[[Media:Creating Platform Development Tools.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|DroneAPI: A Tutorial on Drone Control<br />
|Kevin Hester, 3DRobotics<br />
|[[Media:DroneAPI-_A_Tutorial_on_Drone_Control.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Regulators: Learning To Play With Others<br />
|Mark Brown, Linaro<br />
|[[Media:Regulators: Learning To Play With Others.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Open Lighting Architecture: Blinky Lights!<br />
|Matt Ranostay, Intel<br />
|[[Media:Open_Lighting_Architecture-_Blinky_Lights!.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Real Time Linux Scheduling Performance Comparison<br />
|Vince Bridgers, Altera<br />
|[[Media:Real Time Linux Scheduling Performance Comparison.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 2, 6:40pm<br />
|-<br />
|BoFs: Applying Linux to the Social Infrastructure Systems <br />
|Noriaki Fukuyasu, Linux Foundation<br />
|[[Media:Applying Linux to the Social Infrastructure Systems.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|BoFs: Cryptography and Randomness<br />
|Jesse Zbikowski<br />
|[[Media:Cryptography and Randomness.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|BoFs: Dronecode Project<br />
|Andrew Tridgell & Lorenz Meier<br />
|[[Media:Dronecode Project.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|BoFs: Kernel Wish List<br />
|John Stultz<br />
|[[Media:Kernel Wish List.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|BoFs: MinnowBoard - John Hawley, Intel BoFs: Yocto Project / OpenEmbedded <br />
|Jeff Osier-Mixon<br />
|[[Media:Minnowboard.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|BoFs: Kernel Testing for Upstream with kernelci.org<br />
|Kevin Hilman, Linaro<br />
|[[Media:Intro_Kernel_PM.svg|SVG]]<br />
|<br />
|<br />
|<br />
|}<br />
<br />
===Day 3 Presentations ===<br />
{| border="1" cellspacing="0" cellpadding="4"<br />
|- bgcolor="#c0e0e0"<br />
|- bgcolor="#c0e0e0"<br />
| align="center" | '''Session Description'''<br />
| align="center" | '''Presenter(s)''' <br />
| align="center" | '''Presentation'''<br />
| align="center" | '''Transcript Status'''<br />
| align="center" | '''Video'''<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 3, 9:00am<br />
|-<br />
|Android Based Penetration Testing Framework<br />
|Ron Munitz<br />
|[[Media:Android Based Penetration Testing Framework.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Filesystem Considerations for Embedded Devices<br />
|Tristan Lelong, Adeneo <br />
|[[Media:Filesystem Considerations for Embedded Devices.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Embedded Digital TV Kernel Pipelines via Media Controller API <br />
|Mauro Carvalho Chehab,<br />
|[[Media:Embedded Digital TV Kernel Pipelines via Media Controller API.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Samsung Introduction to Kernel Power Management<br />
|Kevin Hilman, Linaro<br />
|[[Media:Samsung Introduction to Kernel Power Management.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Transactional Device Tree & Overlays: Making Reconfigurable Hardware Work <br />
|Pantelis Antoniou, Konsulko Group<br />
|[[Media:Dynamic-dt-keynote-v3.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Embedded Android Workshop<br />
|Karim Yaghmour, Opersys<br />
|[[Media:Embedded Android Workshop.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 3, 10:00am<br />
|-<br />
|Maintaining Multiple Android Linux Kernels at Intel<br />
|Mark Gross, Intel<br />
|[[Media:Maintaining Multiple Android Linux Kernels at Intel.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Creating Eco-System for R-Car LCB<br />
|Hisao Munakata, Renesas<br />
|[[Media:Creating Eco-System for R-Car LCB.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Maintaining a Large Kernel Subsystem<br />
|Arnd Bergmann<br />
|[[Media:Maintaining a Large Kernel Subsystem.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Status Report for IEEE 802.15.4 and 6LoWPAN in Linux<br />
|Stefan Schmidt, Samsung <br />
|[[Media:Status Report for IEEE 802.15.4 and 6LoWPAN in Linux.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|What's New with Toybox<br />
|Rob Landley<br />
|[[Media:What's New with Toybox.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 3, 11:20am<br />
|-<br />
|Android and Modern Toolchains: gcc 5.0, clang 3.6 and binutils 2.25<br />
|Bernhard Rosenkränzer, Linaro <br />
|[[Media:Android and Modern Toolchains: gcc 5.0, clang 3.6 and binutils 2.25.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Embedded Android Workshop (Cont.)<br />
|Karim Yaghmour, Opersys<br />
|[[Media:Embedded Android Workshop.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Linux in the Connected Car Platform<br />
|Daniel Jackson, Dialexa<br />
|[[Media:Linux in the Connected Car Platform.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Getting Started with Embedded Linux: Using the Yocto Project to Build your Own Custom Embedded Linux Distribution<br />
|Rudolf (Rudi) Streif<br />
|[[Media:Getting Started with Embedded Linux: Using the Yocto Project to Build your Own Custom Embedded Linux Distribution.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Linux Kernel Selftest Framework - Quality Control for New Releases<br />
|Shuah Khan, Samsung <br />
|[[Media:Linux Kernel Selftest Framework - Quality Control for New Releases.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Overcoming Obstacles to Contributing to Linux<br />
|Tim Bird, Sony Mobile<br />
|[[Media:Overcoming Obstacles to Contributing to Linux.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 3, 1:40pm<br />
|-<br />
|Doing big.LITTLE right: little and Big Obstacles<br />
|Vitaly Wool & Vlad Rezki, Softprise Consulting OU<br />
|[[Media:Doing big.LITTLE right: little and Big Obstacles.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Getting Started with Embedded Linux: Using the Yocto Project to Build your Own Custom Embedded Linux Distribution (Cont.)<br />
|Rudolf (Rudi) Streif<br />
|[[Media:Getting Started with Embedded Linux: Using the Yocto Project to Build your Own Custom Embedded Linux Distribution.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Improving the Embedded Linux Development Workflow<br />
|Paul Eggleton, Intel <br />
|[[Media:Improving the Embedded Linux Development Workflow.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Testing Video4Linux Applications and Drivers<br />
|Hans Verkuil<br />
|[[Media:Testing Video4Linux Applications and Drivers.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Embedded Android Workshop (Cont.)<br />
|Karim Yaghmour, Opersys<br />
|[[Media:Embedded Android Workshop.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Shrinking C Code<br />
|Rob Landley<br />
|[[Media:Shrinking C Code.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 3, 2:40pm<br />
|-<br />
|Fixing the y2038 Bug<br />
|Arnd Bergmann, Linaro<br />
|[[Media:Fixing the y2038 Bug.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Enhancing Real-Time Capabilities with the PRU<br />
|Rob Birkett, Texas Instruments<br />
|[[Media:Enhancing Real-Time Capabilities with the PRU.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|Fastboot Tools and Techniques<br />
|John Mehaffey, Mentor Graphics<br />
|[[Media:Fastboot Tools and Techniques.pdf|PDF]]<br />
|<br />
|<br />
|-<br />
|The Ephemeral Smoking Gun: Using ftrace and kgdb to Resolve a pthread 'deadlock'<br />
|Brad Mouring, National Instruments<br />
|[[Media:The_Ephemeral_Smoking_Gun-_Using_ftrace_and_kgdb_to_Resolve_a_pthread_'deadlock'.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 3, 4:00pm<br />
|-<br />
|Embedding Openness in the Connected Car<br />
|Matt Jones, Senior Infotainment Specialist at Jaguar Land Rover<br />
|[[Media:Embedding Openness in the Connected Car.pdf|PDF]]<br />
|<br />
|<br />
|- bgcolor="#a0c0c0"<br />
| colspan="5" | Day 3, 4:30pm<br />
|-<br />
|Community Involvement: Looking Forward and Looking Back<br />
|Deepak Saxena, Noted Linux Kernel Developer<br />
|[[Media:Community Involvement: Looking Forward and Looking Back.pdf|PDF]]<br />
|<br />
|<br />
|}<br />
<br />
== Technical Showcase Posters ==<br />
<br />
{| border="1" cellspacing="0" cellpadding="4"<br />
|- bgcolor="#bc8f96"<br />
| align="center" | '''Poster Title'''<br />
| align="center" | '''Presenter'''<br />
| align="center" | '''Poster'''<br />
|-<br />
| 96Boards HiKey<br />
| Linaro<br />
| [[Media:14_Sargunam.pdf | PDF ]] <br />
|-<br />
| Embedded Linux build system - Buildroot<br />
| Thomas Petazzoni<br />
| [[Media:ELC2015-Buildroot-Poster.pdf | PDF ]]<br />
|-<br />
| FIRST Robotics Competition<br />
| FRC Team 2643 - Dark Matter<br />
| [[Media:05_Phadte.pdf | PDF ]]<br />
|-<br />
| FIRST Robotics Linux-based Controller<br />
| Mike Anderson / The PTR Group, Inc.<br />
| [[Media:11_Anderson.pdf | PDF ]]<br />
|-<br />
| Fluent Bit: Data Collector for Embedded Linux<br />
| Eduardo Silva, Treasure Data<br />
| [[Media:08_Silva.pdf | PDF ]]<br />
|-<br />
| Freedreno - Open Source ARM Graphics<br />
| Rob Clark<br />
| [[Media:07_Clark--edit 150317.pdf | PDF ]]<br />
|-<br />
| OpenDOF Project "One Page" IoT<br />
| Bryant Eastham, Panasonic<br />
| [[Media:09_Eastham.pdf | PDF ]]<br />
|-<br />
| Power measurement with sigrok & ACME<br />
| Bartosz Golaszewski, Patrick Titiano / BayLibre, Ingenios<br />
| [[Media:06_Golaszewski.pdf | PDF ]]<br />
|-<br />
| Scalable, Cloud-Based Device Reprogramming<br />
| James Simister - Panasonic<br />
| [[Media:10_Simister.pdf | PDF ]]<br />
|-<br />
| Sony Mobile phone debug board<br />
| Werner Johansson<br />
| [[Media:04_Johansson.pdf | PDF ]]<br />
|-<br />
| The Syria Airlift Project Open-Sourcing Humanitarian Airlift<br />
| Mark Jacobsen, Jessie Mooberry<br />
| [[Media:15_Jacobsen-Mooberry.pdf | PDF ]]<br />
|-<br />
| Toaster - A web interface to the Yocto Project<br />
| Paul Eggleton, David Reyna, Jeffrey Osier-Mixon - Yocto Project<br />
| [[Media:03_Belen.pdf | PDF ]]<br />
|-<br />
| USRP E310 - Embedded Software Defined Radio<br />
| Philip Balister, Moritz Fischer, Jonathon Pendlum<br />
| [[Media:02_Pendlum.pdf | PDF ]]<br />
|-<br />
| VR Spark - Drone Code Edition<br />
| Roberto Navoni<br />
| [[Media:12_Navoni.pdf | PDF ]]<br />
|}<br />
<br />
[[Category:2015]]<br />
[[Category:ELC]]</div>Pantohttps://elinux.org/index.php?title=File:Dynamic-dt-keynote-v3.pdf&diff=377326File:Dynamic-dt-keynote-v3.pdf2015-03-31T20:49:30Z<p>Panto: </p>
<hr />
<div></div>Pantohttps://elinux.org/index.php?title=File:ELCE2013_-_DT_War.pdf&diff=300224File:ELCE2013 - DT War.pdf2013-11-12T16:32:14Z<p>Panto: Make DT not war.</p>
<hr />
<div>Make DT not war.</div>Pantohttps://elinux.org/index.php?title=BeagleBone_and_the_3.8_Kernel&diff=273572BeagleBone and the 3.8 Kernel2013-07-24T07:13:54Z<p>Panto: : separates not -</p>
<hr />
<div>= Beaglebone and the 3.8 Kernel=<br />
<br />
Pantelis Antoniou <panto@antoniou-consulting.com><br />
<br />
Additional content by<br />
Tom King <ka6sox@gmail.com><br />
Matt Porter <matt.porter@linaro.org><br />
<br />
v1.0<br />
<br />
== Introduction ==<br />
<br />
The Beaglebone Black is the new addition to the Linux ARM development boards coming from Beagleboard.org, and due to the combination of affordable pricing and good hardware expandability has captured the attention of the maker community.<br />
<br />
The Beaglebone Black is clearly a step up over the old version, affectionately now known as Beaglebone White; it is faster, with more memory and onboard eMMC and HDMI.<br />
<br />
What is the most interesting part about the beaglebone family is it's expandability by using “Capes”, small add on boards that can stack, and allow easy access to the peripherals of the am3359 SoC. A plethora of capes have been produced for use for the Beaglebone White and most are compatible with the Black. Things are a bit complicated for capes that use the same pins as the onboard eMMC and the HDMI, to resolve this add-on capes have priority over the onboard peripherals.<br />
<br />
The original beaglebone was shipped with a 3.2 kernel with a lot of patches and custom interfaces from Texas Instruments’s (TI) own kernel trees. Since this was based on a TI supported kernel, hardware compatibility was generally good and the capes worked. They were developed against it after all! <br />
<br />
== The trouble with board files ==<br />
<br />
The old 3.2 Kernel worked pretty well, so why was a move made to 3.8, which causes so much grief to the beaglebone old timers?<br />
<br />
The major problem with the 3.2 kernel is that uses a board-file, namely,<br />
<br />
arch/arm/mach-omap2/board-am335xevm.c<br />
<br />
It's pretty big (at 4K+ lines), and quite difficult to modify. The boardfile also supports, in addition to the beaglebone white, the am335x-evm and all the capes. Every new cape that is to be supported has to modify this file. Additionally you need to create the platform devices that it contains and register them. You have to make sure that you don't break any of the other boards (or capes) supported by the platform file.<br />
<br />
This is a job for professional kernel developers, but even kernel developers have their limits as evidenced by the famous Linus rant that prompted the great cosmic shift to Device Tree:<br />
<br />
[http://article.gmane.org/gmane.linux.ports.arm.omap/55060 Famous Linux rant about ARM churn]<br />
<br />
What has been decreed is simple: ''“No more new ARM board files”'' <br />
<br />
So all new boards must support booting using Device Tree. The board file used in the new kernels is just arch/arm/mach-omap2/board-generic.c and supports booting kernels using omap2, omap3, omap4, omap5 and the am33xx family of the beaglebone.<br />
<br />
This presented a difficult decision for the developers working on the beaglebone black Linux support:<br />
<br />
# Ignore the new mainline dictums, carry on using 3.2 and make the jump to mainline sometime in the future. That would require more developer resources, when the time for mainline porting comes. On top of that most kernel developers don't bother with older vendor kernels, and any bug fix or new functionality has to be painfully back-ported from mainline.<br />
# Bite the bullet, move to 3.8 using DT, and future proof the beaglebone by submitting everything for inclusion to mainline as soon as possible.<br />
<br />
== The trouble with Device Tree==<br />
<br />
What is Device Tree (DT) and why is it causing so many problems for new developers?<br />
<br />
[http://devicetree.org Device Tree Central]<br />
<br />
''"The Device Tree is a data structure for describing hardware. Rather than hard coding every detail of a device into an operating system, many aspect of the hardware can be described in a data structure that is passed to the operating system at boot time."''<br />
(Please take note of the 'boot time' reference, we'll come back to it later).<br />
<br />
The pinmux subsystem and clocksource/clockevent frameworks are two examples of consolidated frameworks that have evolved from the ARM move to DT. Previously, each ARM "machine", such as mach-omap2/*, implemented their SoC-specific pinmux and timer/clock drivers within their machine directory. In converted ARM machines, these drivers now live in the appropriate drivers/* directory and share common code sanely with other similar drivers.<br />
<br />
As it turns out DT isn't that new, it's a couple of decades old and has been used by Open Firmware based systems like Sun workstations and the original PowerPC based Apple Macs.<br />
<br />
For developers the biggest change is that the kernel board file is now gone.<br />
<br />
Simply put, every board has to be described in a DTS (foo.dts) file that is compiled via the DTC compiler to a binary format DTB (flattened device tree format) which gets parsed on boot by the kernel and the devices are created.<br />
<br />
Therein lies the biggest change; there are no more platform device data for the device containing it's configuration. On a board file based platform what you did was:<br />
<br />
In the foo_platform_data.h file:<br />
<br />
<pre><br />
struct foo_platform_data {<br />
u32 bar;<br />
};<br />
</pre><br />
<br />
In the board file:<br />
<br />
<pre><br />
struct foo_platform_data foo_pdata {<br />
.bar = 5,<br />
};<br />
<br />
struct platform_device foo_dev {<br />
.name = "foo",<br />
.id = -1,<br />
.dev.platform_data = &foo_pdata,<br />
};<br />
</pre><br />
<br />
And in the board setup function<br />
<br />
<pre><br />
platform_device_register(&foo_dev);<br />
</pre><br />
<br />
The driver gets access to the platform data in the probe function.<br />
<br />
<pre><br />
static int foo_probe(struct platform_device *pdev)<br />
{<br />
struct foo_platform_data *pdata;<br />
<br />
pdata = pdev->dev.platform_data;<br />
if (pdata == NULL) /* ERROR */<br />
...<br />
<br />
/* access pdata->bar for configuration */<br />
...<br />
}<br />
<br />
static struct platform_driver foo_driver = {<br />
.probe = foo_probe,<br />
....<br />
.driver = {<br />
.name = "foo",<br />
},<br />
...<br />
};<br />
<br />
module_platform_driver(&foo_driver);<br />
</pre><br />
<br />
This method no longer works; in a DT based system what you have to do come up with device driver bindings, which contain the configuration the driver requires.<br />
<br />
You must add a device node in board.dts under the on-chip-peripherals(OCP) device node:<br />
<br />
<pre><br />
foo {<br />
compatible = "corp,foo";<br />
bar = <5>;<br />
};<br />
</pre><br />
<br />
No change in the board file (generic anyway) needs to be made, but the device driver must be updated to support the DT method, with something similar to the following:<br />
<br />
<pre><br />
static struct foo_platform_data *<br />
foo_parse_dt(struct platform_device *pdev)<br />
{<br />
struct device_node *node = pdev->dev.of_node;<br />
struct foo_platform_data *pdata;<br />
<br />
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);<br />
if (pdata == NULL)<br />
return NULL; /* out of memory */<br />
<br />
/* no such property */<br />
if (of_property_read_u32(node, "bar", &pdata->bar) != 0)<br />
return NULL;<br />
<br />
/* pdata->bar is filled in with 5 */<br />
return pdata;<br />
}<br />
<br />
static int foo_probe(struct platform_device *pdev)<br />
{<br />
struct foo_platform_data *pdata;<br />
<br />
if (pdev->dev.of_node != NULL)<br />
pdata = foo_parse_dt(pdev);<br />
else<br />
pdata = pdev->dev.platform_data;<br />
<br />
if (pdata == NULL) /* error */<br />
...<br />
}<br />
<br />
static const struct of_device_id of_foo_match[] = {<br />
{ .compatible = "corp,foo", },<br />
{ },<br />
};<br />
<br />
<br />
static struct platform_driver foo_driver = {<br />
.probe = foo_probe,<br />
....<br />
.driver = {<br />
.name = "foo",<br />
.of_match_table = of_match_ptr(of_foo_match),<br />
},<br />
...<br />
};<br />
<br />
<br />
module_platform_driver(&foo_driver);<br />
</pre><br />
<br />
The driver described above can support both the platform data model and the new DT method. Using a purely DT driver model can result in more flexibility, but we won't deal with it now. Frankly, the biggest change is that now a user (by compiling the DTS) can now configure his platform without having to recompile the kernel, which is a pretty big usability gain. We use this in the new 3.8 releases to boot both versions of the beaglebone using the same kernel, and only changing the DTB we boot with.<br />
<br />
For a developer, the biggest change of using DT, is that it is purely data driven, and that custom platform drivers are frowned upon, opting instead to using generic frameworks, one of which is the pinmux framework.<br />
<br />
In summary, the core of the change to DT is that logic that was previously accomplished in board files is moved into a mixture of generic frameworks, abstracted devices drivers, and data to drive that software. DT imposes structure upon the embedded developer and sometimes there is considerable pushback.<br />
<br />
== Device Tree's data driven model ==<br />
<br />
The data driven model of device tree causes the most pain to the embedded developer steeped in the board file/platform method. Let's examine a concrete example, that deals with the simple subject of a driver/board pinmuxing.<br />
<br />
Pinmuxing refers to the method of modern SoC multiplexing multiple peripheral functions to a rather limited set of physical pins/balls of the SoC package. The am335x is a prime example this, having many pins with up to 8 possible peripheral functions.<br />
<br />
For a peripheral driver to work the correct muxing configuration must be applied to the affected pins; since they are so many, and configuration is complex, a special omap specific driver has been written and has been used on the 3.2 kernel provided by TI.<br />
<br />
Typically in the board setup file, the mux configuration for the peripheral is applied before registering the platform device.<br />
<br />
For example the pin mux for the a gpio configured as a led would be of the form<br />
<br />
<pre><br />
omap_mux_init_signal("gpmc_a2.gpio1_18",<br />
OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT);<br />
</pre><br />
<br />
The omap mux driver also provides a user-space interface for changing the mux settings. The problem with pinmuxing is that it is potentially dangerous if you don't know exactly what kind of hardware is connected to the SoC pins, so in the mainline pinmuxing is performed via the drivers on probe time.<br />
<br />
For the sake of making the example more concrete let's have a gpio also controlling power to the device. The device's driver is only supposed to apply the mux and turn on the power to the device by setting a gpio to high (please bear in mind this is not a real-world example, but explains the issues).<br />
<br />
Let's examine the platform data example with a call back method.<br />
<br />
In the foo_platform_data.h file:<br />
<br />
<pre><br />
struct foo_platform_data {<br />
u32 bar;<br />
void (*get_ready)(struct platform_device *pdev);<br />
};<br />
</pre><br />
<br />
In the board file:<br />
<br />
<pre><br />
/* magic GPIO number of FOO’s power pin */<br />
#define FOO_POWER 11234<br />
<br />
<br />
static void foo_get_ready(struct platform_device *pdev)<br />
{<br />
int ret;<br />
<br />
<br />
omap_mux_init_signal("gpmc_a2.gpio1_18",<br />
OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT);<br />
ret = gpio_request(FOO_POWER, "foo-power");<br />
if (ret >= 0)<br />
gpio_direction_output(FOO_POWER, 1);<br />
}<br />
<br />
struct foo_platform_data foo_pdata {<br />
.bar = 5,<br />
.get_ready = foo_get_ready,<br />
};<br />
</pre><br />
<br />
The rest of the board file has no other changes.<br />
<br />
The driver then can call the get_ready method via the callback function pointer.<br />
<br />
<pre><br />
static int foo_probe(struct platform_device *pdev)<br />
{<br />
struct foo_platform_data *pdata;<br />
<br />
pdata = pdev->dev.platform_data;<br />
if (pdata == NULL) /* ERROR */<br />
...<br />
<br />
/* access pdata->bar for configuration */<br />
...<br />
<br />
/* get foo ready */<br />
(*pdata->get_ready)(pdev);<br />
}<br />
</pre><br />
<br />
Callback functions are impossible in a DT platform. Callbacks break the data only model of DT. What must be done is for the driver to be converted to using the generic gpio and pinmux bindings. On am33xx the generic pinctrl-single driver is used, and to be honest, is not as polished as the old omap mux driver. Nevertheless it is usable and used on many other boards as well, since it is widely supported in the ARM community. Again generic frameworks win over custom solutions.<br />
<br />
The boot.dts file is updated with the pinmux nodes and the gpio bank nodes.<br />
<br />
<pre><br />
/* point to the to the conf_* module registers */<br />
am33xx_pinmux: pinmux@44e10800 {<br />
compatible = "pinctrl-single";<br />
reg = <0x44e10800 0x0238>;<br />
#address-cells = <1>;<br />
#size-cells = <0>;<br />
pinctrl-single,register-width = <32>;<br />
pinctrl-single,function-mask = <0x7f>;<br />
<br />
foo_pins: foo_pins {<br />
pinctrl-single,pins = <<br />
/* need to look into the TRM and find those values */<br />
/* conf_gpmc_a2 module config reg offset and value */<br />
0x0A8 0x1f<br />
>;<br />
};<br />
};<br />
<br />
gpio2: gpio@4804c000 { <br />
compatible = "ti,omap4-gpio";<br />
ti,hwmods = "gpio2";<br />
gpio-controller;<br />
#gpio-cells = <2>;<br />
interrupt-controller; <br />
#interrupt-cells = <1>;<br />
reg = <0x4804c000 0x1000>;<br />
interrupts = <98>;<br />
};<br />
<br />
foo {<br />
compatible = "corp,foo";<br />
bar = <5>;<br />
<br />
# the power control gpio <br />
power-gpio = <&gpio2 18 0x0>;<br />
<br />
# the muxing<br />
pinctrl-names = "default";<br />
pinctrl-0 = <&foo_pins>;<br />
};<br />
</pre><br />
<br />
<br />
The new nodes are the am33xx_pinmux node, and the gpio2 node. Note the added node in am33xx_pinmux that contains the pinmux config for the foo driver. Please note due to the OMAP's numbering of peripherals starting with 1 every numbered peripheral is +1 from what the AM3359 TRM states. There are patches against mainline that fix that, but not on 3.8 yet.<br />
<br />
The foo driver only need minor changes, first the pinctrl consumer interface include header must be included.<br />
<br />
<pre><br />
#include <linux/pinctrl/consumer.h><br />
</pre><br />
<br />
Then on the probe function we need to apply the pinctrl configuration, while on the parse_dt function we need to set the gpio to the given value.<br />
<br />
<pre><br />
static struct foo_platform_data *<br />
foo_parse_dt(struct platform_device *pdev)<br />
{<br />
struct device_node *node = pdev->dev.of_node;<br />
struct foo_platform_data *pdata;<br />
enum of_gpio_flags ofgpioflags;<br />
int ret, gpio;<br />
<br />
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);<br />
if (pdata == NULL)<br />
return NULL; /* out of memory */<br />
<br />
/* no such property */<br />
if (of_property_read_u32(node, "bar", &pdata->bar) != 0)<br />
return NULL;<br />
<br />
/* now get the power gpio and set it to one */<br />
gpio = of_get_named_gpio_flags(pdev->dev.of_node, "power-gpio",<br />
0, &ofgpioflags);<br />
if (!IS_ERR_VALUE(gpio)) {<br />
gpioflags = GPIOF_DIR_OUT;<br />
if (ofgpioflags & OF_GPIO_ACTIVE_LOW)<br />
gpioflags |= GPIOF_INIT_LOW;<br />
else<br />
gpioflags |= GPIOF_INIT_HIGH;<br />
ret = devm_gpio_request_one(&pdev->dev, gpio,<br />
gpioflags, "foo-power");<br />
}<br />
<br />
/* pdata->bar is filled in with 5 */<br />
return pdata;<br />
}<br />
<br />
static int foo_probe(struct platform_device *pdev)<br />
{<br />
struct pinctrl *pinctrl;<br />
<br />
...<br />
/* apply the pinmux configuration */<br />
pinctrl = devm_pinctrl_get_select_default(&pdev->dev);<br />
if (IS_ERR(pinctrl))<br />
dev_warn(pdev->dev, "unable to select pin group\n");<br />
<br />
if (pdev->dev.of_node != NULL)<br />
pdata = foo_parse_dt(pdev);<br />
else<br />
pdata = pdev->dev.platform_data;<br />
<br />
….<br />
}<br />
</pre><br />
<br />
== Cape Manager requirements ==<br />
<br />
Going over the device tree definition we see that the data structure is referred as parsed at boot-time. Beaglebone capes are not static; a different cape set might be connected each time the board boots, and the only way to find out what kind of cape is connected is to read the serial EEPROM present on each cape which contains identification information.<br />
<br />
Beaglebone capes are mostly compatible between White and Black, but due to the presence of the eMMC flash and the HDMI framer, some special attention must be paid for capes that use the same resources.<br />
<br />
The information stored on the EEPROM of each cape are a user readable name, serial number, part number, revision information and others. The only information that the cape manager uses to work are the part-number and the revision.<br />
<br />
A cape-manager should perform the following:<br />
<br />
# Scan the I2C bus for EEPROMs that correspond to the address defined in the beaglebone SRM. Those addresses are 0x54-0x57 on I2C1 bus, hence the 4 capes limitation.<br />
# Read the EEPROM contents and parse them according to the spec. Retrieve the part-number and revision information of that cape.<br />
# Match the PART-NUMBER:REVISION tuple to a configuration that would result in the system state being that as if the cape was directly attached to the base board, and perform any actions that result to it.<br />
<br />
Additionally we need extra facilities that are useful for people developing capes:<br />
<br />
* An override facility so that prototyping capes with no EEPROM can be supported.<br />
* An option to load capes at runtime.<br />
* An option to unload capes at runtime.<br />
* An option to stop a cape from loading even if detected.<br />
* To guard against resource conflicts. A cape that uses the same resources as another loaded earlier should not be permitted to load.<br />
* To be able to forbid cape loading of capes that are not supported by a baseboard revision.<br />
* To be able to load 'virtual' capes that correspond to peripheral that are present on specific baseboard revisions.<br />
* To support the notion of a cape priority, so that in case of a conflict, the cape we define as higher priority gets loaded. This is important to allow plug in capes to take preference over capes that are part of the baseboard; i.e. when an LCD cape is attached it takes preference over the onboard HDMI virtual cape.<br />
* To not require source changes for any driver for a peripheral that resides on cape or onboard , i.e. the drivers should not be modified for use in a cape.<br />
* No kernel source changes must be required for a new cape to be supported.<br />
* To not require modification of the boot-loader, or of the base DTS.<br />
<br />
== Device Tree Overlays ==<br />
<br />
The method used to dynamically load the cape definition to the running kernel is called a Device Tree Overlay. What a device tree overlay does is apply changes to the kernel's internal DT representation and trigger the changes that this action carries. For example adding a new enabled device node should result in a new device being created, while removing a node removes the device and so on.<br />
<br />
The previous foo example, when reworked for usage with DT overlays is as follows:<br />
<br />
The base.dts file has an ocp label of the on-board peripherals for the SoC.<br />
<br />
<pre><br />
/ {<br />
/* On chip peripherals */<br />
ocp: ocp {<br />
/* peripherals that are always instantiated */<br />
peripheral0 { ... };<br />
}<br />
};<br />
</pre><br />
<br />
The overlay when loaded must result in the same device tree as in the previous example; the overlay must be the following:<br />
<br />
<pre><br />
/plugin/; /* allow undefined label references and record them */<br />
/ {<br />
.... /* various properties for loader use; i.e. part id etc. */<br />
fragment@0 {<br />
target = <&am33xx_pinmux>;<br />
__overlay__ {<br />
foo_pins: foo_pins {<br />
pinctrl-single,pins = <<br />
/* look into the TRM for values */<br />
/* conf_gpmc_a2 module reg offset/value */<br />
0x0A8 0x1f<br />
>;<br />
};<br />
};<br />
};<br />
<br />
fragment@1 {<br />
target = <&ocp>;<br />
__overlay__ {<br />
/* bar peripheral */<br />
foo {<br />
compatible = "corp,foo";<br />
bar = <5>;<br />
<br />
# the power control gpio <br />
power-gpio = <&gpio2 18 0x0>;<br />
<br />
# the muxing<br />
pinctrl-names = "default";<br />
pinctrl-0 = <&foo_pins>;<br />
};<br />
};<br />
};<br />
};<br />
</pre><br />
<br />
The overlay consists of two fragments, one targeting the am33xx_pinmux node, the other the ocp node. Note that there are no foo driver changes, not any sort of platform board file hacking. When this overlay is applied the foo device will be created, just as if it was declared in the base.dts.<br />
<br />
More information about the internal of overlays and the resolution mechanism is located in Documentation/devicetree directory of the kernel.<br />
<br />
== Cape Manager and Device Tree Overlays ==<br />
<br />
Device Tree overlays is a general purpose mechanism, which is not tied to any platform. For actual platforms like the beaglebone the mechanism must be supplemented by platform specific logic.<br />
<br />
The platform logic of the beaglebone cape manager deals with the following:<br />
<br />
* Reading the EEPROMs of the capes for retrieval of the part numbers & revision.<br />
* Allowing runtime addition/removal of cape fragments.<br />
* Having options to control cape loading from the kernel command line<br />
* Having options to force loading of capes from the base DTS<br />
* Having mapping options of multiple cape part numbers & revisions to a single cape<br />
* Resource conflict management<br />
* Implement cape priorities so that in case of a conflict the winner can be selected<br />
* Verification of the cape compatibility with a base board<br />
* Various cape information display (i.e. serial# etc).<br />
* Automatic loading of capes based on base board version (i.e. auto loading HDMI/eMMC capes)<br />
<br />
Lets add the beaglebone specific properties to the foo DT overlay and complete the cape.<br />
<br />
<pre><br />
/plugin/; /* allow undefined label references and record them */<br />
/ {<br />
/* compatible with both the original and the beaglebone black */<br />
compatible = "ti,beaglebone", "ti,beaglebone-black";<br />
<br />
/* part-number */<br />
part-number = "BB-FOO-01";<br />
<br />
/* version */<br />
version = "00A0";<br />
<br />
exclusive-use = <br />
"P8.43", /* Header.Pin# */<br />
"gpio2_8"; /* the hardware IP we use */<br />
<br />
/* the fragments are the same as above */<br />
....<br />
};<br />
</pre><br />
<br />
The compatible property lists the platforms that this cape supports. If an attempt is made to load an unsupported cape by this platform the attempt will fail.<br />
<br />
Similarly, the part-number and version properties guard against an attempt of loading a bad cape.<br />
<br />
The exclusive-use property is a pretty simple attempt at implementing resource management. What it does, is allow capes to declare free-form text resources; if another cape tries to load which uses the same resource, it will be prevented of doing so. The convention in the beaglebone cape format is that we reserve the header/pin and the hardware IP block the cape wants to use, in that case pin#43 of the P8 connector, and the gpio2_8 gpio hardware block.<br />
<br />
The name of the cape should be of the ${PART_NUMBER}:${REV}.dts format and the compilation would be (on either the host or the beaglebone):<br />
<br />
<pre><br />
$ dtc -O dtb -o BB-FOO-01-00A0.dtbo -b 0 -@ BB-FOO-01-00A0.dts<br />
</pre><br />
<br />
Note the required -@ option; it is not part of the upstream dtc, so it's a DT overlay specific patch that enables it. The beaglebone kernel has the patch already applied on it’s internal dtc compiler copy, as well as the angstrom image, but you need the following patches for other distro’s dtc packages.<br />
<br />
[https://github.com/beagleboard/meta-beagleboard/blob/96bb2c4ca95cba3b78615c4363c65fcd65cb188a/common-bsp/recipes-kernel/dtc/dtc/0001-dtc-Dynamic-symbols-fixup-support.patch Dynamic Overlays DTC patch]<br />
<br />
Putting the resulting BB-FOO-01-00A0.dtbo file in /lib/firmware we can enable it by<br />
<br />
<pre><br />
# echo BB-FOO-01 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
We can verify if it loaded with:<br />
<br />
<pre><br />
# cat /sys/devices/bone_capemgr*/slots<br />
0: 54:PF--- <br />
1: 55:PF--- <br />
2: 56:PF--- <br />
3: 57:PF--- <br />
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G<br />
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI<br />
6: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-FOO-01<br />
</pre><br />
<br />
Slot #6 is the one we've loaded.<br />
<br />
The cape can be removed by:<br />
<br />
<pre><br />
# echo -6 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
Cape-manager also supports a method of enabling (or disabling) a cape by a kernel command line option.<br />
<br />
<pre><br />
capemgr.extra-override=BB-FOO-01<br />
</pre><br />
<br />
Will automatically load the cape on boot, while<br />
<br />
<pre><br />
capemgr.disable_partno=BB-FOO-01<br />
</pre><br />
<br />
will disable the cape (if it's attempted to load automatically).<br />
<br />
== Porting to the new DT kernel FAQ ==<br />
<br />
'''Q: I have a custom kernel fork, based on a modified board file. Nothing works.'''<br />
<br />
A: The biggest difference of-course is that there's no board file, so there are no platform data. You have to have device drivers with DT bindings. You can get by temporarily by creating a helper DT enabled platform device and allocate/fill the platform data from the probe method and register the platform device. But this is only a temporary fix, and DT bindings should be introduced at some point in the driver.<br />
<br />
'''Q: The new pinmuxing method sucks; why can't I pinmux by the old method at runtime?'''<br />
<br />
A: The old pinmux method was TI specific and although it made it in the mainline, it has no DT bindings and is duplicating functionality of the general pinmux framework. The new method is portable, but it's reliance on raw numbers is a pain. However it does offer safety, since if a device obtains the pin resources there's no way for them to be modified by some outside factor. To help in the transition a full set of peripheral drivers and their<br />
pinmux settings will be introduced shortly.<br />
<br />
Additionally there is a pinmux helper driver that allows runtime switching between different per-state pinmux-settings. For example:<br />
<br />
<pre><br />
bar_pinmux_helper {<br />
compatible = "bone-pinmux-helper";<br />
status = "okay";<br />
pinctrl-names = "input", "output";<br />
pinctrl-0 = <&bar_input_gpio_pins>;<br />
pinctrl-1 = <&bar_output_gpio_pins>;<br />
};<br />
</pre><br />
<br />
This device node creates a pinmux helper device which defines two pinmux states, named input and output. You can switch between them simply by<br />
<br />
<pre><br />
# echo input >/sys/devices/ocp*/bar_pinmux_helper*/state<br />
# echo output >/sys/devices/ocp*/bar_pinmux_helper*/state<br />
</pre><br />
<br />
Note that there is a very slim chance for this driver to be admitted in mainline, but you can use it if it helps you port to the new kernel.<br />
<br />
'''Q: How do I support any kind GPIO/I2C/SPI etc. device. It is completely different.'''<br />
<br />
A: It is. Examples will be provided on how to do most of the standard peripheral configurations. What you get for the change is the ability to create any kind of device without having to recompile the kernel.<br />
<br />
'''Q: My LCD/GPMC/$RANDOM based device doesn't work on the black.'''<br />
<br />
A: The eMMC and HDMI parts of the Black are using the same pins. If you define a cape with the proper resource definitions, the user cape will take precedence. Hardware restrictions might apply (i.e. pin loading issues etc).<br />
<br />
'''Q: Why can't you carry on using the board file method, seems to work just fine.'''<br />
<br />
A: The writing was on the wall; no way we could ever get the beaglebone in the mainline using it. On top of that any new cape that is produced, either by TI/CCO or the community had to patch the board file to make it work. While this is doable when you have a couple of capes, when you expect dozens of capes, most of them produced by community members, having to expect them to hack the board file, is completely out of the question.<br />
<br />
'''Q: The pinmux values are really hard to figure out from the manuals. One has to hunt in the TRM, the datasheet of the specific processor, and the beaglebone SRM to figure them out.'''<br />
<br />
A: There are resources with the muxing options. Please see: [https://github.com/bradfa/beaglebone_pinmux_tables Pinmux Tables]<br />
<br />
'''Q: Too many words! Grog angry! Concrete example!'''<br />
<br />
A: Example of an RS232 cape that uses UART2:<br />
<br />
<pre><br />
/*<br />
* Copyright (C) 2013 Matt Ranostay <mranostay@gmail.com><br />
*<br />
* This program is free software; you can redistribute it and/or modify<br />
* it under the terms of the GNU General Public License version 2 as<br />
* published by the Free Software Foundation.<br />
*/<br />
/dts-v1/;<br />
/plugin/;<br />
<br />
/ {<br />
compatible = "ti,beaglebone", "ti,beaglebone-black";<br />
<br />
/* identification */<br />
part-number = "BB-BONE-RS232";<br />
version = "00A0";<br />
<br />
/* state the resources this cape uses */<br />
exclusive-use =<br />
/* the pin header uses */<br />
"P9.22", /* rs232: uart2_rxd */<br />
"P9.21", /* rs232: uart2_txd */<br />
/* the hardware IP uses */<br />
"uart2";<br />
<br />
fragment@0 {<br />
target = <&am33xx_pinmux>;<br />
__overlay__ {<br />
uart_pins: pinmux_uart_pins {<br />
pinctrl-single,pins = <<br />
0x150 0x21 /* spi0_sclk.uart2_rxd | <br />
* MODE1 | PULL_UP */<br />
0x154 0x01 /* spi0_d0.uart2_txd | MODE1 */<br />
>;<br />
};<br />
};<br />
};<br />
<br />
fragment@1 {<br />
target = <&uart3>; /* remember the +1 peculiarity */<br />
__overlay__ {<br />
status = "okay";<br />
pinctrl-names = "default";<br />
pinctrl-0 = <&uart_pins>;<br />
};<br />
};<br />
};<br />
</pre><br />
<br />
This file is located in the kernel sources at<br />
<br />
<pre><br />
firmware/capes/BB-BONE-RS232-00A0.dts<br />
</pre><br />
<br />
Compile with:<br />
<br />
<pre><br />
$ dtc -O dtb -o BB-BONE-RS232-00A0.dtbo -b 0 -@ BB-BONE-RS232-00A0.dts<br />
</pre><br />
<br />
Copy to /lib/firmware:<br />
<br />
<pre><br />
# cp BB-BONE-RS232-00A0.dtbo /lib/firmware<br />
</pre><br />
<br />
Activate:<br />
<br />
<pre><br />
# echo BB-BONE-RS232 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
'''Q: I still can’t figure it out! Any pointers out there on how to do stuff?'''<br />
<br />
A: A lot of examples in firmware/capes exist<br />
<br />
UART virtual capes: firmware/capes/BB-UART*.dts<br />
I2C virtual capes: firmware/capes/BB-I2C*.dts<br />
SPI virtual capes: firmware/capes/BB-SPI*.dts<br />
<br />
<pre><br />
# echo BB-UART5 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
Configures UART5, a new /dev/ttyOx device will be created (devices are created sequentially) and will be ready to use.<br />
<br />
Similarly<br />
<br />
<pre><br />
# echo BB-I2C1 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
Creates a new I2C bus master. Note that when you have your own I2C devices that you need to access, you can either use the user-space I2C API, or create a device node for your device in the cape. The example capes have commented out examples on how to do that. All those virtual capes can be used as a base for your own experimentation.<br />
<br />
'''Q: I still hate Device Tree!!!'''<br />
<br />
A: Sorry, we cannot help you</div>Pantohttps://elinux.org/index.php?title=BeagleBone_and_the_3.8_Kernel&diff=259598BeagleBone and the 3.8 Kernel2013-05-31T17:13:08Z<p>Panto: Created Beaglebone and the 3.8 Kernel wiki</p>
<hr />
<div>= Beaglebone and the 3.8 Kernel=<br />
<br />
Pantelis Antoniou <panto@antoniou-consulting.com><br />
<br />
Additional content by<br />
Tom King <ka6sox@gmail.com><br />
Matt Porter <matt.porter@linaro.org><br />
<br />
v1.0<br />
<br />
== Introduction ==<br />
<br />
The Beaglebone Black is the new addition to the Linux ARM development boards coming from Beagleboard.org, and due to the combination of affordable pricing and good hardware expandability has captured the attention of the maker community.<br />
<br />
The Beaglebone Black is clearly a step up over the old version, affectionately now known as Beaglebone White; it is faster, with more memory and onboard eMMC and HDMI.<br />
<br />
What is the most interesting part about the beaglebone family is it's expandability by using “Capes”, small add on boards that can stack, and allow easy access to the peripherals of the am3359 SoC. A plethora of capes have been produced for use for the Beaglebone White and most are compatible with the Black. Things are a bit complicated for capes that use the same pins as the onboard eMMC and the HDMI, to resolve this add-on capes have priority over the onboard peripherals.<br />
<br />
The original beaglebone was shipped with a 3.2 kernel with a lot of patches and custom interfaces from Texas Instruments’s (TI) own kernel trees. Since this was based on a TI supported kernel, hardware compatibility was generally good and the capes worked. They were developed against it after all! <br />
<br />
== The trouble with board files ==<br />
<br />
The old 3.2 Kernel worked pretty well, so why was a move made to 3.8, which causes so much grief to the beaglebone old timers?<br />
<br />
The major problem with the 3.2 kernel is that uses a board-file, namely,<br />
<br />
arch/arm/mach-omap2/board-am335xevm.c<br />
<br />
It's pretty big (at 4K+ lines), and quite difficult to modify. The boardfile also supports, in addition to the beaglebone white, the am335x-evm and all the capes. Every new cape that is to be supported has to modify this file. Additionally you need to create the platform devices that it contains and register them. You have to make sure that you don't break any of the other boards (or capes) supported by the platform file.<br />
<br />
This is a job for professional kernel developers, but even kernel developers have their limits as evidenced by the famous Linus rant that prompted the great cosmic shift to Device Tree:<br />
<br />
[http://article.gmane.org/gmane.linux.ports.arm.omap/55060 Famous Linux rant about ARM churn]<br />
<br />
What has been decreed is simple: ''“No more new ARM board files”'' <br />
<br />
So all new boards must support booting using Device Tree. The board file used in the new kernels is just arch/arm/mach-omap2/board-generic.c and supports booting kernels using omap2, omap3, omap4, omap5 and the am33xx family of the beaglebone.<br />
<br />
This presented a difficult decision for the developers working on the beaglebone black Linux support:<br />
<br />
# Ignore the new mainline dictums, carry on using 3.2 and make the jump to mainline sometime in the future. That would require more developer resources, when the time for mainline porting comes. On top of that most kernel developers don't bother with older vendor kernels, and any bug fix or new functionality has to be painfully back-ported from mainline.<br />
# Bite the bullet, move to 3.8 using DT, and future proof the beaglebone by submitting everything for inclusion to mainline as soon as possible.<br />
<br />
== The trouble with Device Tree==<br />
<br />
What is Device Tree (DT) and why is it causing so many problems for new developers?<br />
<br />
[http://devicetree.org Device Tree Central]<br />
<br />
''"The Device Tree is a data structure for describing hardware. Rather than hard coding every detail of a device into an operating system, many aspect of the hardware can be described in a data structure that is passed to the operating system at boot time."''<br />
(Please take note of the 'boot time' reference, we'll come back to it later).<br />
<br />
The pinmux subsystem and clocksource/clockevent frameworks are two examples of consolidated frameworks that have evolved from the ARM move to DT. Previously, each ARM "machine", such as mach-omap2/*, implemented their SoC-specific pinmux and timer/clock drivers within their machine directory. In converted ARM machines, these drivers now live in the appropriate drivers/* directory and share common code sanely with other similar drivers.<br />
<br />
As it turns out DT isn't that new, it's a couple of decades old and has been used by Open Firmware based systems like Sun workstations and the original PowerPC based Apple Macs.<br />
<br />
For developers the biggest change is that the kernel board file is now gone.<br />
<br />
Simply put, every board has to be described in a DTS (foo.dts) file that is compiled via the DTC compiler to a binary format DTB (flattened device tree format) which gets parsed on boot by the kernel and the devices are created.<br />
<br />
Therein lies the biggest change; there are no more platform device data for the device containing it's configuration. On a board file based platform what you did was:<br />
<br />
In the foo_platform_data.h file:<br />
<br />
<pre><br />
struct foo_platform_data {<br />
u32 bar;<br />
};<br />
</pre><br />
<br />
In the board file:<br />
<br />
<pre><br />
struct foo_platform_data foo_pdata {<br />
.bar = 5,<br />
};<br />
<br />
struct platform_device foo_dev {<br />
.name = "foo",<br />
.id = -1,<br />
.dev.platform_data = &foo_pdata,<br />
};<br />
</pre><br />
<br />
And in the board setup function<br />
<br />
<pre><br />
platform_device_register(&foo_dev);<br />
</pre><br />
<br />
The driver gets access to the platform data in the probe function.<br />
<br />
<pre><br />
static int foo_probe(struct platform_device *pdev)<br />
{<br />
struct foo_platform_data *pdata;<br />
<br />
pdata = pdev->dev.platform_data;<br />
if (pdata == NULL) /* ERROR */<br />
...<br />
<br />
/* access pdata->bar for configuration */<br />
...<br />
}<br />
<br />
static struct platform_driver foo_driver = {<br />
.probe = foo_probe,<br />
....<br />
.driver = {<br />
.name = "foo",<br />
},<br />
...<br />
};<br />
<br />
module_platform_driver(&foo_driver);<br />
</pre><br />
<br />
This method no longer works; in a DT based system what you have to do come up with device driver bindings, which contain the configuration the driver requires.<br />
<br />
You must add a device node in board.dts under the on-chip-peripherals(OCP) device node:<br />
<br />
<pre><br />
foo {<br />
compatible = "corp,foo";<br />
bar = <5>;<br />
};<br />
</pre><br />
<br />
No change in the board file (generic anyway) needs to be made, but the device driver must be updated to support the DT method, with something similar to the following:<br />
<br />
<pre><br />
static struct foo_platform_data *<br />
foo_parse_dt(struct platform_device *pdev)<br />
{<br />
struct device_node *node = pdev->dev.of_node;<br />
struct foo_platform_data *pdata;<br />
<br />
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);<br />
if (pdata == NULL)<br />
return NULL; /* out of memory */<br />
<br />
/* no such property */<br />
if (of_property_read_u32(node, "bar", &pdata->bar) != 0)<br />
return NULL;<br />
<br />
/* pdata->bar is filled in with 5 */<br />
return pdata;<br />
}<br />
<br />
static int foo_probe(struct platform_device *pdev)<br />
{<br />
struct foo_platform_data *pdata;<br />
<br />
if (pdev->dev.of_node != NULL)<br />
pdata = foo_parse_dt(pdev);<br />
else<br />
pdata = pdev->dev.platform_data;<br />
<br />
if (pdata == NULL) /* error */<br />
...<br />
}<br />
<br />
static const struct of_device_id of_foo_match[] = {<br />
{ .compatible = "corp,foo", },<br />
{ },<br />
};<br />
<br />
<br />
static struct platform_driver foo_driver = {<br />
.probe = foo_probe,<br />
....<br />
.driver = {<br />
.name = "foo",<br />
.of_match_table = of_match_ptr(of_foo_match),<br />
},<br />
...<br />
};<br />
<br />
<br />
module_platform_driver(&foo_driver);<br />
</pre><br />
<br />
The driver described above can support both the platform data model and the new DT method. Using a purely DT driver model can result in more flexibility, but we won't deal with it now. Frankly, the biggest change is that now a user (by compiling the DTS) can now configure his platform without having to recompile the kernel, which is a pretty big usability gain. We use this in the new 3.8 releases to boot both versions of the beaglebone using the same kernel, and only changing the DTB we boot with.<br />
<br />
For a developer, the biggest change of using DT, is that it is purely data driven, and that custom platform drivers are frowned upon, opting instead to using generic frameworks, one of which is the pinmux framework.<br />
<br />
In summary, the core of the change to DT is that logic that was previously accomplished in board files is moved into a mixture of generic frameworks, abstracted devices drivers, and data to drive that software. DT imposes structure upon the embedded developer and sometimes there is considerable pushback.<br />
<br />
== Device Tree's data driven model ==<br />
<br />
The data driven model of device tree causes the most pain to the embedded developer steeped in the board file/platform method. Let's examine a concrete example, that deals with the simple subject of a driver/board pinmuxing.<br />
<br />
Pinmuxing refers to the method of modern SoC multiplexing multiple peripheral functions to a rather limited set of physical pins/balls of the SoC package. The am335x is a prime example this, having many pins with up to 8 possible peripheral functions.<br />
<br />
For a peripheral driver to work the correct muxing configuration must be applied to the affected pins; since they are so many, and configuration is complex, a special omap specific driver has been written and has been used on the 3.2 kernel provided by TI.<br />
<br />
Typically in the board setup file, the mux configuration for the peripheral is applied before registering the platform device.<br />
<br />
For example the pin mux for the a gpio configured as a led would be of the form<br />
<br />
<pre><br />
omap_mux_init_signal("gpmc_a2.gpio1_18",<br />
OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT);<br />
</pre><br />
<br />
The omap mux driver also provides a user-space interface for changing the mux settings. The problem with pinmuxing is that it is potentially dangerous if you don't know exactly what kind of hardware is connected to the SoC pins, so in the mainline pinmuxing is performed via the drivers on probe time.<br />
<br />
For the sake of making the example more concrete let's have a gpio also controlling power to the device. The device's driver is only supposed to apply the mux and turn on the power to the device by setting a gpio to high (please bear in mind this is not a real-world example, but explains the issues).<br />
<br />
Let's examine the platform data example with a call back method.<br />
<br />
In the foo_platform_data.h file:<br />
<br />
<pre><br />
struct foo_platform_data {<br />
u32 bar;<br />
void (*get_ready)(struct platform_device *pdev);<br />
};<br />
</pre><br />
<br />
In the board file:<br />
<br />
<pre><br />
/* magic GPIO number of FOO’s power pin */<br />
#define FOO_POWER 11234<br />
<br />
<br />
static void foo_get_ready(struct platform_device *pdev)<br />
{<br />
int ret;<br />
<br />
<br />
omap_mux_init_signal("gpmc_a2.gpio1_18",<br />
OMAP_MUX_MODE7 | AM33XX_PIN_OUTPUT);<br />
ret = gpio_request(FOO_POWER, "foo-power");<br />
if (ret >= 0)<br />
gpio_direction_output(FOO_POWER, 1);<br />
}<br />
<br />
struct foo_platform_data foo_pdata {<br />
.bar = 5,<br />
.get_ready = foo_get_ready,<br />
};<br />
</pre><br />
<br />
The rest of the board file has no other changes.<br />
<br />
The driver then can call the get_ready method via the callback function pointer.<br />
<br />
<pre><br />
static int foo_probe(struct platform_device *pdev)<br />
{<br />
struct foo_platform_data *pdata;<br />
<br />
pdata = pdev->dev.platform_data;<br />
if (pdata == NULL) /* ERROR */<br />
...<br />
<br />
/* access pdata->bar for configuration */<br />
...<br />
<br />
/* get foo ready */<br />
(*pdata->get_ready)(pdev);<br />
}<br />
</pre><br />
<br />
Callback functions are impossible in a DT platform. Callbacks break the data only model of DT. What must be done is for the driver to be converted to using the generic gpio and pinmux bindings. On am33xx the generic pinctrl-single driver is used, and to be honest, is not as polished as the old omap mux driver. Nevertheless it is usable and used on many other boards as well, since it is widely supported in the ARM community. Again generic frameworks win over custom solutions.<br />
<br />
The boot.dts file is updated with the pinmux nodes and the gpio bank nodes.<br />
<br />
<pre><br />
/* point to the to the conf_* module registers */<br />
am33xx_pinmux: pinmux@44e10800 {<br />
compatible = "pinctrl-single";<br />
reg = <0x44e10800 0x0238>;<br />
#address-cells = <1>;<br />
#size-cells = <0>;<br />
pinctrl-single,register-width = <32>;<br />
pinctrl-single,function-mask = <0x7f>;<br />
<br />
foo_pins: foo_pins {<br />
pinctrl-single,pins = <<br />
/* need to look into the TRM and find those values */<br />
/* conf_gpmc_a2 module config reg offset and value */<br />
0x0A8 0x1f<br />
>;<br />
};<br />
};<br />
<br />
gpio2: gpio@4804c000 { <br />
compatible = "ti,omap4-gpio";<br />
ti,hwmods = "gpio2";<br />
gpio-controller;<br />
#gpio-cells = <2>;<br />
interrupt-controller; <br />
#interrupt-cells = <1>;<br />
reg = <0x4804c000 0x1000>;<br />
interrupts = <98>;<br />
};<br />
<br />
foo {<br />
compatible = "corp,foo";<br />
bar = <5>;<br />
<br />
# the power control gpio <br />
power-gpio = <&gpio2 18 0x0>;<br />
<br />
# the muxing<br />
pinctrl-names = "default";<br />
pinctrl-0 = <&foo_pins>;<br />
};<br />
</pre><br />
<br />
<br />
The new nodes are the am33xx_pinmux node, and the gpio2 node. Note the added node in am33xx_pinmux that contains the pinmux config for the foo driver. Please note due to the OMAP's numbering of peripherals starting with 1 every numbered peripheral is +1 from what the AM3359 TRM states. There are patches against mainline that fix that, but not on 3.8 yet.<br />
<br />
The foo driver only need minor changes, first the pinctrl consumer interface include header must be included.<br />
<br />
<pre><br />
#include <linux/pinctrl/consumer.h><br />
</pre><br />
<br />
Then on the probe function we need to apply the pinctrl configuration, while on the parse_dt function we need to set the gpio to the given value.<br />
<br />
<pre><br />
static struct foo_platform_data *<br />
foo_parse_dt(struct platform_device *pdev)<br />
{<br />
struct device_node *node = pdev->dev.of_node;<br />
struct foo_platform_data *pdata;<br />
enum of_gpio_flags ofgpioflags;<br />
int ret, gpio;<br />
<br />
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);<br />
if (pdata == NULL)<br />
return NULL; /* out of memory */<br />
<br />
/* no such property */<br />
if (of_property_read_u32(node, "bar", &pdata->bar) != 0)<br />
return NULL;<br />
<br />
/* now get the power gpio and set it to one */<br />
gpio = of_get_named_gpio_flags(pdev->dev.of_node, "power-gpio",<br />
0, &ofgpioflags);<br />
if (!IS_ERR_VALUE(gpio)) {<br />
gpioflags = GPIOF_DIR_OUT;<br />
if (ofgpioflags & OF_GPIO_ACTIVE_LOW)<br />
gpioflags |= GPIOF_INIT_LOW;<br />
else<br />
gpioflags |= GPIOF_INIT_HIGH;<br />
ret = devm_gpio_request_one(&pdev->dev, gpio,<br />
gpioflags, "foo-power");<br />
}<br />
<br />
/* pdata->bar is filled in with 5 */<br />
return pdata;<br />
}<br />
<br />
static int foo_probe(struct platform_device *pdev)<br />
{<br />
struct pinctrl *pinctrl;<br />
<br />
...<br />
/* apply the pinmux configuration */<br />
pinctrl = devm_pinctrl_get_select_default(&pdev->dev);<br />
if (IS_ERR(pinctrl))<br />
dev_warn(pdev->dev, "unable to select pin group\n");<br />
<br />
if (pdev->dev.of_node != NULL)<br />
pdata = foo_parse_dt(pdev);<br />
else<br />
pdata = pdev->dev.platform_data;<br />
<br />
….<br />
}<br />
</pre><br />
<br />
== Cape Manager requirements ==<br />
<br />
Going over the device tree definition we see that the data structure is referred as parsed at boot-time. Beaglebone capes are not static; a different cape set might be connected each time the board boots, and the only way to find out what kind of cape is connected is to read the serial EEPROM present on each cape which contains identification information.<br />
<br />
Beaglebone capes are mostly compatible between White and Black, but due to the presence of the eMMC flash and the HDMI framer, some special attention must be paid for capes that use the same resources.<br />
<br />
The information stored on the EEPROM of each cape are a user readable name, serial number, part number, revision information and others. The only information that the cape manager uses to work are the part-number and the revision.<br />
<br />
A cape-manager should perform the following:<br />
<br />
# Scan the I2C bus for EEPROMs that correspond to the address defined in the beaglebone SRM. Those addresses are 0x54-0x57 on I2C1 bus, hence the 4 capes limitation.<br />
# Read the EEPROM contents and parse them according to the spec. Retrieve the part-number and revision information of that cape.<br />
# Match the PART-NUMBER:REVISION tuple to a configuration that would result in the system state being that as if the cape was directly attached to the base board, and perform any actions that result to it.<br />
<br />
Additionally we need extra facilities that are useful for people developing capes:<br />
<br />
* An override facility so that prototyping capes with no EEPROM can be supported.<br />
* An option to load capes at runtime.<br />
* An option to unload capes at runtime.<br />
* An option to stop a cape from loading even if detected.<br />
* To guard against resource conflicts. A cape that uses the same resources as another loaded earlier should not be permitted to load.<br />
* To be able to forbid cape loading of capes that are not supported by a baseboard revision.<br />
* To be able to load 'virtual' capes that correspond to peripheral that are present on specific baseboard revisions.<br />
* To support the notion of a cape priority, so that in case of a conflict, the cape we define as higher priority gets loaded. This is important to allow plug in capes to take preference over capes that are part of the baseboard; i.e. when an LCD cape is attached it takes preference over the onboard HDMI virtual cape.<br />
* To not require source changes for any driver for a peripheral that resides on cape or onboard , i.e. the drivers should not be modified for use in a cape.<br />
* No kernel source changes must be required for a new cape to be supported.<br />
* To not require modification of the boot-loader, or of the base DTS.<br />
<br />
== Device Tree Overlays ==<br />
<br />
The method used to dynamically load the cape definition to the running kernel is called a Device Tree Overlay. What a device tree overlay does is apply changes to the kernel's internal DT representation and trigger the changes that this action carries. For example adding a new enabled device node should result in a new device being created, while removing a node removes the device and so on.<br />
<br />
The previous foo example, when reworked for usage with DT overlays is as follows:<br />
<br />
The base.dts file has an ocp label of the on-board peripherals for the SoC.<br />
<br />
<pre><br />
/ {<br />
/* On chip peripherals */<br />
ocp: ocp {<br />
/* peripherals that are always instantiated */<br />
peripheral0 { ... };<br />
}<br />
};<br />
</pre><br />
<br />
The overlay when loaded must result in the same device tree as in the previous example; the overlay must be the following:<br />
<br />
<pre><br />
/plugin/; /* allow undefined label references and record them */<br />
/ {<br />
.... /* various properties for loader use; i.e. part id etc. */<br />
fragment@0 {<br />
target = <&am33xx_pinmux>;<br />
__overlay__ {<br />
foo_pins: foo_pins {<br />
pinctrl-single,pins = <<br />
/* look into the TRM for values */<br />
/* conf_gpmc_a2 module reg offset/value */<br />
0x0A8 0x1f<br />
>;<br />
};<br />
};<br />
};<br />
<br />
fragment@1 {<br />
target = <&ocp>;<br />
__overlay__ {<br />
/* bar peripheral */<br />
foo {<br />
compatible = "corp,foo";<br />
bar = <5>;<br />
<br />
# the power control gpio <br />
power-gpio = <&gpio2 18 0x0>;<br />
<br />
# the muxing<br />
pinctrl-names = "default";<br />
pinctrl-0 = <&foo_pins>;<br />
};<br />
};<br />
};<br />
};<br />
</pre><br />
<br />
The overlay consists of two fragments, one targeting the am33xx_pinmux node, the other the ocp node. Note that there are no foo driver changes, not any sort of platform board file hacking. When this overlay is applied the foo device will be created, just as if it was declared in the base.dts.<br />
<br />
More information about the internal of overlays and the resolution mechanism is located in Documentation/devicetree directory of the kernel.<br />
<br />
== Cape Manager and Device Tree Overlays ==<br />
<br />
Device Tree overlays is a general purpose mechanism, which is not tied to any platform. For actual platforms like the beaglebone the mechanism must be supplemented by platform specific logic.<br />
<br />
The platform logic of the beaglebone cape manager deals with the following:<br />
<br />
* Reading the EEPROMs of the capes for retrieval of the part numbers & revision.<br />
* Allowing runtime addition/removal of cape fragments.<br />
* Having options to control cape loading from the kernel command line<br />
* Having options to force loading of capes from the base DTS<br />
* Having mapping options of multiple cape part numbers & revisions to a single cape<br />
* Resource conflict management<br />
* Implement cape priorities so that in case of a conflict the winner can be selected<br />
* Verification of the cape compatibility with a base board<br />
* Various cape information display (i.e. serial# etc).<br />
* Automatic loading of capes based on base board version (i.e. auto loading HDMI/eMMC capes)<br />
<br />
Lets add the beaglebone specific properties to the foo DT overlay and complete the cape.<br />
<br />
<pre><br />
/plugin/; /* allow undefined label references and record them */<br />
/ {<br />
/* compatible with both the original and the beaglebone black */<br />
compatible = "ti,beaglebone", "ti,beaglebone-black";<br />
<br />
/* part-number */<br />
part-number = "BB-FOO-01";<br />
<br />
/* version */<br />
version = "00A0";<br />
<br />
exclusive-use = <br />
"P8.43", /* Header.Pin# */<br />
"gpio2_8"; /* the hardware IP we use */<br />
<br />
/* the fragments are the same as above */<br />
....<br />
};<br />
</pre><br />
<br />
The compatible property lists the platforms that this cape supports. If an attempt is made to load an unsupported cape by this platform the attempt will fail.<br />
<br />
Similarly, the part-number and version properties guard against an attempt of loading a bad cape.<br />
<br />
The exclusive-use property is a pretty simple attempt at implementing resource management. What it does, is allow capes to declare free-form text resources; if another cape tries to load which uses the same resource, it will be prevented of doing so. The convention in the beaglebone cape format is that we reserve the header/pin and the hardware IP block the cape wants to use, in that case pin#43 of the P8 connector, and the gpio2_8 gpio hardware block.<br />
<br />
The name of the cape should be of the ${PART_NUMBER}-${REV}.dts format and the compilation would be (on either the host or the beaglebone):<br />
<br />
<pre><br />
$ dtc -O dtb -o BB-FOO-01-00A0.dtbo -b 0 -@ BB-FOO-01-00A0.dts<br />
</pre><br />
<br />
Note the required -@ option; it is not part of the upstream dtc, so it's a DT overlay specific patch that enables it. The beaglebone kernel has the patch already applied on it’s internal dtc compiler copy, as well as the angstrom image, but you need the following patches for other distro’s dtc packages.<br />
<br />
[https://github.com/beagleboard/meta-beagleboard/blob/96bb2c4ca95cba3b78615c4363c65fcd65cb188a/common-bsp/recipes-kernel/dtc/dtc/0001-dtc-Dynamic-symbols-fixup-support.patch Dynamic Overlays DTC patch]<br />
<br />
Putting the resulting BB-FOO-01-00A0.dtbo file in /lib/firmware we can enable it by<br />
<br />
<pre><br />
# echo BB-FOO-01 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
We can verify if it loaded with:<br />
<br />
<pre><br />
# cat /sys/devices/bone_capemgr*/slots<br />
0: 54:PF--- <br />
1: 55:PF--- <br />
2: 56:PF--- <br />
3: 57:PF--- <br />
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G<br />
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI<br />
6: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-FOO-01<br />
</pre><br />
<br />
Slot #6 is the one we've loaded.<br />
<br />
The cape can be removed by:<br />
<br />
<pre><br />
# echo -6 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
Cape-manager also supports a method of enabling (or disabling) a cape by a kernel command line option.<br />
<br />
<pre><br />
capemgr.extra-override=BB-FOO-01<br />
</pre><br />
<br />
Will automatically load the cape on boot, while<br />
<br />
<pre><br />
capemgr.disable_partno=BB-FOO-01<br />
</pre><br />
<br />
will disable the cape (if it's attempted to load automatically).<br />
<br />
== Porting to the new DT kernel FAQ ==<br />
<br />
'''Q: I have a custom kernel fork, based on a modified board file. Nothing works.'''<br />
<br />
A: The biggest difference of-course is that there's no board file, so there are no platform data. You have to have device drivers with DT bindings. You can get by temporarily by creating a helper DT enabled platform device and allocate/fill the platform data from the probe method and register the platform device. But this is only a temporary fix, and DT bindings should be introduced at some point in the driver.<br />
<br />
'''Q: The new pinmuxing method sucks; why can't I pinmux by the old method at runtime?'''<br />
<br />
A: The old pinmux method was TI specific and although it made it in the mainline, it has no DT bindings and is duplicating functionality of the general pinmux framework. The new method is portable, but it's reliance on raw numbers is a pain. However it does offer safety, since if a device obtains the pin resources there's no way for them to be modified by some outside factor. To help in the transition a full set of peripheral drivers and their<br />
pinmux settings will be introduced shortly.<br />
<br />
Additionally there is a pinmux helper driver that allows runtime switching between different per-state pinmux-settings. For example:<br />
<br />
<pre><br />
bar_pinmux_helper {<br />
compatible = "bone-pinmux-helper";<br />
status = "okay";<br />
pinctrl-names = "input", "output";<br />
pinctrl-0 = <&bar_input_gpio_pins>;<br />
pinctrl-1 = <&bar_output_gpio_pins>;<br />
};<br />
</pre><br />
<br />
This device node creates a pinmux helper device which defines two pinmux states, named input and output. You can switch between them simply by<br />
<br />
<pre><br />
# echo input >/sys/devices/ocp*/bar_pinmux_helper*/state<br />
# echo output >/sys/devices/ocp*/bar_pinmux_helper*/state<br />
</pre><br />
<br />
Note that there is a very slim chance for this driver to be admitted in mainline, but you can use it if it helps you port to the new kernel.<br />
<br />
'''Q: How do I support any kind GPIO/I2C/SPI etc. device. It is completely different.'''<br />
<br />
A: It is. Examples will be provided on how to do most of the standard peripheral configurations. What you get for the change is the ability to create any kind of device without having to recompile the kernel.<br />
<br />
'''Q: My LCD/GPMC/$RANDOM based device doesn't work on the black.'''<br />
<br />
A: The eMMC and HDMI parts of the Black are using the same pins. If you define a cape with the proper resource definitions, the user cape will take precedence. Hardware restrictions might apply (i.e. pin loading issues etc).<br />
<br />
'''Q: Why can't you carry on using the board file method, seems to work just fine.'''<br />
<br />
A: The writing was on the wall; no way we could ever get the beaglebone in the mainline using it. On top of that any new cape that is produced, either by TI/CCO or the community had to patch the board file to make it work. While this is doable when you have a couple of capes, when you expect dozens of capes, most of them produced by community members, having to expect them to hack the board file, is completely out of the question.<br />
<br />
'''Q: The pinmux values are really hard to figure out from the manuals. One has to hunt in the TRM, the datasheet of the specific processor, and the beaglebone SRM to figure them out.'''<br />
<br />
A: There are resources with the muxing options. Please see: [https://github.com/bradfa/beaglebone_pinmux_tables Pinmux Tables]<br />
<br />
'''Q: Too many words! Grog angry! Concrete example!'''<br />
<br />
A: Example of an RS232 cape that uses UART2:<br />
<br />
<pre><br />
/*<br />
* Copyright (C) 2013 Matt Ranostay <mranostay@gmail.com><br />
*<br />
* This program is free software; you can redistribute it and/or modify<br />
* it under the terms of the GNU General Public License version 2 as<br />
* published by the Free Software Foundation.<br />
*/<br />
/dts-v1/;<br />
/plugin/;<br />
<br />
/ {<br />
compatible = "ti,beaglebone", "ti,beaglebone-black";<br />
<br />
/* identification */<br />
part-number = "BB-BONE-RS232";<br />
version = "00A0";<br />
<br />
/* state the resources this cape uses */<br />
exclusive-use =<br />
/* the pin header uses */<br />
"P9.22", /* rs232: uart2_rxd */<br />
"P9.21", /* rs232: uart2_txd */<br />
/* the hardware IP uses */<br />
"uart2";<br />
<br />
fragment@0 {<br />
target = <&am33xx_pinmux>;<br />
__overlay__ {<br />
uart_pins: pinmux_uart_pins {<br />
pinctrl-single,pins = <<br />
0x150 0x21 /* spi0_sclk.uart2_rxd | <br />
* MODE1 | PULL_UP */<br />
0x154 0x01 /* spi0_d0.uart2_txd | MODE1 */<br />
>;<br />
};<br />
};<br />
};<br />
<br />
fragment@1 {<br />
target = <&uart3>; /* remember the +1 peculiarity */<br />
__overlay__ {<br />
status = "okay";<br />
pinctrl-names = "default";<br />
pinctrl-0 = <&uart_pins>;<br />
};<br />
};<br />
};<br />
</pre><br />
<br />
This file is located in the kernel sources at<br />
<br />
<pre><br />
firmware/capes/BB-BONE-RS232-00A0.dts<br />
</pre><br />
<br />
Compile with:<br />
<br />
<pre><br />
$ dtc -O dtb -o BB-BONE-RS232-00A0.dtbo -b 0 -@ BB-BONE-RS232-00A0.dts<br />
</pre><br />
<br />
Copy to /lib/firmware:<br />
<br />
<pre><br />
# cp BB-BONE-RS232-00A0.dtbo /lib/firmware<br />
</pre><br />
<br />
Activate:<br />
<br />
<pre><br />
# echo BB-BONE-RS232 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
'''Q: I still can’t figure it out! Any pointers out there on how to do stuff?'''<br />
<br />
A: A lot of examples in firmware/capes exist<br />
<br />
UART virtual capes: firmware/capes/BB-UART*.dts<br />
I2C virtual capes: firmware/capes/BB-I2C*.dts<br />
SPI virtual capes: firmware/capes/BB-SPI*.dts<br />
<br />
<pre><br />
# echo BB-UART5 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
Configures UART5, a new /dev/ttyOx device will be created (devices are created sequentially) and will be ready to use.<br />
<br />
Similarly<br />
<br />
<pre><br />
# echo BB-I2C1 >/sys/devices/bone_capemgr*/slots<br />
</pre><br />
<br />
Creates a new I2C bus master. Note that when you have your own I2C devices that you need to access, you can either use the user-space I2C API, or create a device node for your device in the cape. The example capes have commented out examples on how to do that. All those virtual capes can be used as a base for your own experimentation.<br />
<br />
'''Q: I still hate Device Tree!!!'''<br />
<br />
A: Sorry, we cannot help you</div>Pantohttps://elinux.org/index.php?title=BeagleBone_Community&diff=259580BeagleBone Community2013-05-31T16:40:53Z<p>Panto: /* Subpages */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
[[Category:Development Boards]]<br />
[[Category: BeagleBoard]]<br />
[[Category: BeagleBone]]<br />
<br />
[[File:BeagleBone_256x249.jpg|320px|thumb|right|BeagleBone]]<br />
[[File:BeagleBone-Black-A5_product_detail_black_sm.jpg|320px|thumb|right|BeagleBone Black]]<br />
<br />
This page collects information about [http://beagleboard.org BeagleBoard.org]'s range of [http://beagleboard.org/bone BeagleBone] boards based on the [http://www.ti.com/am335x TI Sitara AM335x], an application processor SoC containing an [http://en.wikipedia.org/wiki/ARM_Cortex-A8 ARM Cortex-A8] core. The range currently consists of the original '''BeagleBone''' and the upgraded but lower cost '''BeagleBone Black'''.<br />
<br />
Most features are common to the two models. The differences between them are described in each section under a '''BeagleBone Black''' subheading.<br />
<br />
<br><br />
= Events =<br />
* ongoing 2009: [[BeagleBoard/contest|Beagle Sponsored Project Program]] - add a cool project and get a free BeagleBoard to realize it!<br />
<br />
= Description =<br />
The two models of BeagleBone share most features in common through employing only slightly different versions of the same TI Sitara SoC. In addition they both adhere to the same standard for expansion and interfacing through "cape" daughterboards. <br />
<br />
== BeagleBone (original) ==<br />
The '''BeagleBone''' is a low-cost, high-expansion board from the [http://beagleboard.org/ BeagleBoard] product line. It uses the [http://www.ti.com/am335x TI AM3358/9] SoC based on an [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8] processor core using the [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARMv7-A] architecture. It is similar in purpose to earlier BeagleBoards, and can be used either standalone or as a USB or Ethernet-connected expansion for a BeagleBoard or any other system. The BeagleBone is small even by BeagleBoard standards yet still provides much of the performance and capabilities of the larger BeagleBoards.<br />
<br />
BeagleBone ships with a 4GB micro-SD card preloaded with the [http://www.angstrom-distribution.org/ Angstrom] ARM Linux distribution.<br />
<br />
The board uses a [http://www.ti.com/product/tps65217b TI TPS65217B PMIC] to generate stable supply voltages regardless of input power variation. +5V DC power can be supplied to the BeagleBone through a barrel connector or from the mini-USB, both of which are located near the large RJ45 Ethernet connector.<br />
<br />
The mini-USB type-A OTG/device '''client-mode''' socket is multi-functional. In addition to providing an alternative source of power, it gives access to an on-board front-end two-port USB client-side hub. (This is not related to the separate '''host-mode''' USB socket described later). One port of the hub goes directly to the '''USB0''' port of the TI AM3358/9 SoC, while the other port connects to a dual-port [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H] USB-to-serial converter to provide board-to-external-host serial communications and/or JTAG debugging. The BeagleBone's Linux serial console is available through this USB serial connection.<br />
<br />
The SoC's '''USB0''' connection to the front-end hub works in one of two modes, and you can toggle between them at any time: it either presents the SD card as a mountable USB storage device to the host, or it provides an [http://www.linux-usb.org/usbnet/ Ethernet-over-USB] networking interface which yields a simple method of quick-start. The Ethernet-over-USB facility is additional to the BeagleBone's normal 10/100 Ethernet interface, which is directly implemented in the SoC rather than hanging off USB as in some other designs. Full IPv4 and IPv6 networking is provided by the supplied Linux system out of the box.<br />
<br />
In addition to the USB OTG Device or '''client-mode''' facilities already described, BeagleBone also provides one '''host-mode''' USB type-A socket on the other end of the board. This is driven from the '''USB1''' connection on the AM3358/9 SoC, and provides access to USB host peripherals such as mice, keyboards, storage, and wifi or Bluetooth dongles, or a USB hub for further expansion.<br />
<br />
== BeagleBone Black ==<br />
On 23rd April 2013, Beagleboard officially announced '''[http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black]''' at a price approximately half that of the original BeagleBone.<br />
<br />
The new board's most important new features include a AM3359 SoC upgraded to 1GHz, doubling of memory to 512MB, use of faster DDR3 memory in contrast to the DDR2 of the original BeagleBone, and a new HDMI audio/visual output. (The original BeagleBone required an additional cape daughterboard for graphic output).<br />
<br />
= Specifications =<br />
The two boards are very similar in those features provided directly by the SoC. Despite the original BeagleBone being specified as using "AM3358/9", in practice most boards are believed to have shipped with the AM3359 generic part. BeagleBone Black has therefore upgraded only the specific device selected from the AM3359 range, and hence the differences are few. In contrast, the boards have significantly different designs but a high degree of compatibility.<br />
== BeagleBone ==<br />
* Up to 720 MHz superscalar ARM Cortex-A8 AM3358/9<br />
* 256 MB DDR2 RAM<br />
* 10/100 Ethernet RJ45 socket, IPv4 and IPv6 networking<br />
* MicroSD slot and 4GB microSD card supplied<br />
* Preloaded with Angstrom ARM Linux Distribution<br />
* Single USB 2.0 type A host port<br />
* Dual USB hub on USB 2.0 type mini-A OTG device port<br />
* On-board USB-to-serial/JTAG over one shared USB device port<br />
* Storage-over-USB or Ethernet-over-USB on other USB device port<br />
* Extensive I/O: 2 I2C, 5 UART, SPI, CAN, 66 GPIO, 8 PWM, 8 ADC<br />
* +5V DC power from barrel connector or USB device port<br />
* Power consumption of 300-500mA at 5V<br />
* Two 46-pin 3.3-V peripheral headers with multiplexed LCD signals<br />
* Board size: 3.4" × 2.1" (86.4mm x 53.3mm) -- fits in an Altoid tin<br />
<br />
== BeagleBone Black (differences) ==<br />
* 1 GHz superscalar ARM Cortex-A8 AM3359<br />
* 512 MB DDR3 RAM<br />
* On-board 2 GB eMMC flash, preloaded with Angstrom ARM Linux Distribution<br />
* MicroSD slot for additional user data or operating systems (no card supplied)<br />
* USB 2.0 type A host port<br />
* Dedicated single mini-USB 2.0 client port (no additional 2-port hub)<br />
* New micro-HDMI audio/visual output<br />
* USB-to-serial and USB-to-JTAG interfaces removed (available on expansion headers)<br />
* Power expansion header for backlight removed, battery charging moved onto pads<br />
* Lower power consumption of 210-460 mA at 5V<br />
<br />
= Expansion Connectors =<br />
The BeagleBone provides two 46-pin dual-row expansion connectors "'''P9'''" and "'''P8'''" which are also known as "'''Expansion A'''" and "'''Expansion B'''", respectively. The location and pinout of these connectors is illustrated below (click tables to enlarge). All signals on expansion headers are 3.3V except where indicated otherwise.<br />
<br />
=== P9 and P8 - Each 2x23 pins ===<br />
[[File:BeagleBone_P9_256x256.jpg|256px|left|top|border|P9 Header|link=File:BeagleBone_p9_pinout.jpg]]<br />
[[File:BeagleBone_P9_P8_256x256.jpg|256px|top|border|BeagleBone P9 + P8|link=File:BeagleBone_P9_P8_512x512.jpg]]<br />
[[File:BeagleBone_P8_256x256.jpg|256px|top|border|P8 Header|link=File:BeagleBone_p8_pinout.jpg]]<br />
<p><br><br />
In addition to the two large headers above, a small 10-pin dual-row connector provides "'''P6'''" provides a "'''PMIC Expansion'''" that brings out some additional signals from the TPS65217B Power Management IC, using the following pinout:<br />
<br />
=== P6 - 2x5 pins''' ===<br />
[[File:BeagleBone_P6_464x222.jpg|464px|left|middle|border|P6 MPIC Expansion Header]]<br />
<br />
'''NB. P6 is not available on BeagleBone Black'''<br />
<br />
'''IMPORTANT'''<br />
<br />
This diagram of P6 provides an '''UNDERSIDE PINOUT''' view.<br />
<br />
It is therefore ''' ''laterally inverted'' ''' relative to the photograph.<br />
<br />
To obtain the top-side pinout that corresponds to the physical orientation shown in the photograph, swap the two rows of pins so that odd-numbered pins are on the left of even-numbered pins.<br style="clear: both" /><br />
<br />
= Expansion Boards and Accessories =<br />
<br />
== Capes ==<br />
A '''BeagleBone Cape''' is an expansion board which can be plugged into the BeagleBone's two 46-pin dual-row '''Expansion Headers''' and which in turns provides similar headers onto which further capes can be stacked. Up to four capes at a time can be stacked on top of a BeagleBone. An expansion board which can be fitted only at the top of a stack of capes (usually for physical reasons) is a special case of "cape", but this usage is common for display expansion boards such as LCDs (see next section).<br />
<br />
Capes are required to provide a 32Kbyte I2C-addressed EEPROM which holds board information such as board name, serial number and revision, although this is typically omitted on simple prototyping capes. Capes are also expected to provide a 2-position DIP switch to select their address in the stack, although this too is often omitted in prototyping capes.<br />
<br />
The [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] seeks to index all existing capes and cape concepts, including private projects. A [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page] is available to help add capes to the list.<br />
<br />
This section lists only those capes which are available commercially or which are close to a production release, as well as open hardware designs.<br />
<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_DVID CircuitCo BeagleBone DVI-D cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breadboard CircuitCo BeagleBone Breadboard cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breakout CircuitCo BeagleBone Breakout cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_CANBus CircuitCo BeagleBone CANBus cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_RS232 CircuitCo BeagleBone RS232 cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Battery CircuitCo BeagleBone Battery cape]<br />
* [http://www.adafruit.com/products/572 Adafruit Proto Cape kit for BeagleBone]<br />
* [http://www.towertech.it/en/products/hardware/tt3201-can-cape/ TowerTech TT3201 Multi-Channel CAN Cape]<br />
* [https://specialcomp.com/beaglebone/BeagleBone_FPGA.html Special Computing Spartan-3A FPGA cape for BeagleBone] -- in development<br />
* [http://syntheticlifeforms.net/?p=43 Thinking Machines LCD-IO Expansion Cape] -- in development<br />
* [https://github.com/piranha32/FlyingBone Open Source BeagleBone Prototyping Board] -- piranha32 GitHub repository<br />
* [http://www.armkits.com/product/beaglebone-hdmicape.asp Embest BeagleBone HDMI cape]<br />
* [[BeagleBone 6502 RemoteProc cape]] -- in development<br />
<br />
== LCD Displays and Other Expansions ==<br />
LCD displays for the BeagleBone are typically implemented as capes which plug in as the ''' ''top board'' ''' in a stack of capes, for reasons of visibility. Such displays are often larger than the BeagleBone itself, so the normal physical relationship in which a daughterboard is smaller than its host board is inverted. In this arrangement it is the expansion board that provides the physical support for the BeagleBone.<br />
<br />
* [[File:Beaglebone.jpg|320px|thumb|BeadaFrame]][http://www.nxelec.com/products/hmi/beadaframe-beaglebone NAXING Electronics BeadaFrame] with BeagleBone companion board<br />
:Expanded Hardware Features:<br />
:* 7" 800x480 TFT LCD screen<br />
:* PWM Backlight control<br />
:* Resistive touch panel<br />
:* Plastic frame<br />
:* 256MB Nand flash(K9F2G08)<br />
:* RS232 serial ports(UART1 w/ CTS&RTS)<br />
:* Stereo audio out<br />
:* Micro-phone in<br />
:* 6 x USER buttons<br />
:* PWM Beeper<br />
:* RTC with Battery(DS1302)<br />
<br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD3 CircuitCo BeagleBone LCD3 cape and LCD display]<br />
: 3.5" TFT LCD screen, resolution 320x240, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD4 CircuitCo BeagleBone LCD4 cape and LCD display]<br />
: 4" TFT LCD screen, resolution 480x272, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD7 CircuitCo BeagleBone LCD7 cape and LCD display]<br />
: 7" TFT LCD screen, resolution 800x480, 4-wire resistive touchscreen, rear mount for BeagleBone and capes.<br />
* A very low cost LCD implementation for the BeagleBone Black using the PRU-ICSS is [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/28/bbb--connecting-up-an-lcd here]. It requires a graphics library to be written; currently it just displays a couple of lines on the screen.<br />
<br />
== Cases ==<br />
* [http://www.adafruit.com/products/699 Adafruit Bone Box - Enclosure for Beagle Bone]<br />
* [http://www.skpang.co.uk/catalog/acrylic-cover-for-beaglebone-p-1076.html SK Pang Acrylic Cover for BeagleBone]<br />
* [http://specialcomp.com/beagleboard/BB-Bone-assy2_l.jpg Special Computing Bone Acrylic Case]<br />
* [http://www.thingiverse.com/thing:19153 canadaduane's 3D-printable BeagleBone Case design]<br />
* [http://www.thingiverse.com/thing:16195 NinjaBlock's 3D-printable Beaglebone front panel design]<br />
* [http://www.thingiverse.com/thing:20122 builttospec's laser-cut design for BeagleBone Enclosure with DVI Cape]<br />
* [http://www.built-to-spec.com/blog/2012/03/01/beaglebone-case-update-and-new-kits-page/ Built to Spec BeagleBone Case Update], and [http://builttospecstore.storenvy.com/products/225603-beaglebone-enclosure final product]<br />
<br />
= BeagleBone Operating Systems =<br />
BeagleBone's default operating system is [http://www.angstrom-distribution.org/ Angstrom], which ships with the board. This section provides basic information on Angstrom and other operating systems commonly used on BeagleBone. This information may help in making a preliminary choice, but full details should be obtained from the home sites.<br />
<br />
The latest images of the official Angstrom images for BeagleBoard.org products can be found at [http://beagleboard.org/latest-images the beagleboard.org latest images web page]<br />
<br />
=== Angstrom ===<br />
* Home site: http://www.angstrom-distribution.org/<br />
* Mailing lists: [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel angstrom-distro-devel] and [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-users angstrom-distro-users]<br />
* IRC channel: irc://irc.freenode.net/#angstrom<br />
Ångström was started by a small group of people who worked on the OpenEmbedded, OpenZaurus and OpenSimpad projects to unify their effort to make a stable and user-friendly distribution for embedded devices like handhelds, set top boxes and network-attached storage devices.<br />
Ångström can scale down to devices with only 4MB of flash storage.<br />
<br />
The Angstrom community does not provide a forum, [http://www.angstrom-distribution.org/contact intentionally].<br />
<br />
Angstrom uses [http://www.busybox.net/ Busybox] for many key utilities, which has both pros and cons. Advantages include requiring less storage space and a smaller memory footprint for many common utilities, which also improves system startup time and performance. The main disadvantages stem from those utilities not mirroring exactly their full-size counterparts. These differences can be annoying if one is used to standard behavior, and may also break shell scripts that rely on portable functionality.<br />
<br />
Angstrom uses [http://connman.net/ connman] for network connection management, but no documentation is available for this currently. Also, man(1) and man pages are not provided by default, nor debugging utilities like strace(1) and tcpdump(1). Getting started may therefore present difficulties, depending on experience.<br />
<br />
=== Debian ===<br />
* See [[BeagleBoardDebian]]<br />
* Home site: [http://wiki.debian.org/ArmEabiPort http://wiki.debian.org/ArmEabiPort]<br />
* Mailing list: http://lists.debian.org/debian-arm/<br />
* IRC channel: irc://irc.debian.org/debian-arm<br />
The ARM EABI port is the default port of the standard Debian distribution of Linux for the ARM architecture ("armel").<br />
EABI ("Embedded ABI") is actually a family of ABIs, and one of the "subABIs" is the GNU EABI for Linux which is used for this port.<br />
Starting with Debian 7.0 (Wheezy) there is a port targeted at newer (armv7 with fpu) hardware with another ABI ("armhf").<br />
<br />
The [http://www.debian.org/intro/about Debian Project] is strongly committed to software freedom, and has a long pedigree and a good reputation.<br />
<br />
=== Ubuntu ===<br />
* See [[BeagleBoardUbuntu]]<br />
* Home site: https://wiki.ubuntu.com/ARM<br />
* IRC channel: irc://irc.freenode.net/#ubuntu-arm<br />
The vision for Ubuntu is part social and part economic: free software, available free of charge to everybody on the same terms, and funded through a portfolio of services provided by Canonical.<br />
<br />
The first version of Ubuntu was based on the GNOME desktop, but has since added a KDE edition, Kubuntu, and a server edition. All of the editions of Ubuntu share common infrastructure and software. In recent years, special emphasis has been placed on netbooks for lightweight, connected, mobile computing, and on the cloud as a new architecture for data centres.<br />
<br />
=== Fedora ===<br />
* See [[BeagleBoardFedora]].<br />
* Home site: http://fedoraproject.org/wiki/Architectures/ARM<br />
* Mailing list: http://lists.fedoraproject.org/pipermail/arm/<br />
* IRC channel: irc://irc.freenode.net/#fedora-arm<br />
The Fedora Project is sponsored by Red Hat, which invests in its infrastructure and resources to encourage collaboration and incubate innovative new technologies. Some of these technologies may later be integrated into Red Hat products. They are developed in Fedora and produced under a free and open source license from inception, so other free software communities and projects are free to study, adopt, and modify them.<br />
<br />
Red Hat has been a major player since the earliest days of Linux distributions, and has earned a good reputation for solidity which continues in Fedora. The Fedora ARM initiative is very active (see mailing list).<br />
<br />
=== ArchLinux ===<br />
* Home site: http://archlinuxarm.org/platforms/armv7/beaglebone<br />
* Source repository: https://github.com/archlinuxarm/PKGBUILDs<br />
* IRC channel: irc://irc.freenode.net/#archlinux-arm<br />
Arch Linux for BeagleBone is a version of the Arch Linux ARM distribution. This carries forward the Arch Linux philosophy of simplicity and user-centrism, targeting and accommodating ''competent'' Linux users by giving them complete control and responsibility over the system. Instructions are provided to assist in navigating the nuances of installation on the varied ARM platforms; however, the system itself will offer little assistance to the user.<br />
<br />
The entire distribution is on a rolling-release cycle that can be updated daily through small packages instead of huge updates on a defined release schedule. Most packages are unmodified from what the upstream developer originally released.<br />
<br />
=== Gentoo ===<br />
* Home site: http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml<br />
* IRC channel: irc://irc.freenode.net/#gentoo-embedded<br />
Gentoo is a source-based '' '''meta'''-distribution'' of Linux. Instead of distributing a standard system image built with predefined options, Gentoo gives each user the means to create their own customized system that doesn't contain unused bloat and with minimum dependencies. Upgrades are incremental and under user control, so a Gentoo system is normally always up-to-date and wholesale upgrades are avoided.<br />
<br />
Being a source-based system, the downside of Gentoo for low-power ARM systems is very long install times for large applications. Cross-compilation on x86 machines and [http://www.gentoo.org/doc/en/distcc.xml distcc] can overcome this problem, but they add complexity.<br />
<br />
=== Sabayon ===<br />
* Home site: [http://wiki.sabayon.org/index.php?title=Hitchhikers_Guide_to_the_BeagleBone_%28and_ARMv7a%29 wiki.sabayon.org/Hitchhikers Guide to the BeagleBone]<br />
* IRC channel: irc://irc.freenode.net/#sabayon<br />
Sabayon Linux uses the mechanisms of Gentoo to create a pre-configured Linux distribution that can be installed as rapidly as a normal binary distribution, but still retains the benefits of Gentoo's source-based package management. Sabayon on Intel/AMD also provides the Entropy binary package management system, which could in principle greatly ease installation of packages on resource-constrained embedded Linux devices, but this is not yet available for ARM.<br />
<br />
Although it is still early days for Sabayon on ARM (and hence on BeagleBone), there is regular progress reported on [http://lxnay.wordpress.com/2012/ lxnay's blog], and contributions from the community would probably accelerate the work.<br />
<br />
=== Buildroot ===<br />
* Home site: http://www.zoobab.com/beaglebone<br />
* Buildroot project site: http://buildroot.uclibc.org/<br />
Buildroot is a set of Makefiles and patches that makes it easy to generate a complete embedded Linux system. Buildroot can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a bootloader image. Buildroot is useful mainly for people working with small or embedded systems, using various CPU architectures (x86, ARM, MIPS, PowerPC, etc.) : it automates the building process of your embedded system and eases the cross-compilation process.<br />
<br />
The resulting root filesystem is mounted read-only, but other filesystems can be mounted read/write for persistence. Although user accounts can be created, in practice almost everything is done as root. Buildroot uses no package manager. Instead, package selection is managed through '''make menuconfig'''.<br />
<br />
=== Nerves Erlang/OTP ===<br />
* Home site: http://nerves-project.org/<br />
* Source repository: https://github.com/nerves-project/bbone-erlang-buildroot<br />
* Erlang project site: http://www.erlang.org/<br />
Erlang is a programming language used to build massively scalable soft realtime systems with high availability requirements (5-9’s). Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang’s runtime system has built-in support for concurrency, distribution and fault tolerance.<br />
<br />
OTP is a set of Erlang libraries and design principles providing middle-ware to develop these systems. It includes its own distributed database, applications to interface towards other languages, debugging and release handling tools.<br />
<br />
The Nerves project provides an embedded Linux-based environment for running Erlang and an easy-to-use API to access common I/O interfaces, based on '''Buildroot''' (see above). If you are interested in running an Erlang node on a low power ARM-based board such as BeagleBone, this project can get you started.<br />
<br />
= Board recovery =<br />
* See [http://elinux.org/BeagleBoardRecovery#USB_recovery BeagleBoardRecovery] ''--- (*) Check applicability''<br />
<br />
= Software Development =<br />
Software development on the BeagleBone is normally no different to any other Linux platform, and typically varies with language and with the IDE used, if any. This section deals only with development issues that are specific to BeagleBone, or mostly so.<br />
<br />
=== Cloud9 IDE and Bonescript ===<br />
''..... description here .....''<br />
* Source repository: https://github.com/jadonk/bonescript<br />
* Language documentation: http://nodejs.org/<br />
<br />
=== BeagleBone JTAG Debugging ===<br />
''..... description here .....''<br />
<br />
===Using Netbeans to remotely compile and debug C/C++===<br />
<br />
When developing c/c++ on a linux desktop, a toolchain is available for cross-compiling the code for arm. However no such toolchain is readily available for windows. Netbeans can be used to write the code on your desktop, save it in a location accessible to the beagle, and then automatically compile it on the beagle itself using ssh and the built in compiler on the beaglebone's OS.<br />
<br />
Netbeans can also use GDB for remote debugging over ssh.<br />
<br />
Requirements:<br />
<br />
* Set up a samba / smb network share through which code can be shared between both desktop and beagle<br />
* Give netbeans the SSh login details of the beagle<br />
* Give netbeans the path mapping so it can translate between the desktop code folder and beagle code folder<br />
* Setup only takes a few minutes.<br />
<br />
====More info====<br />
<br />
* Download Netbeans (Windows/Linux/OS-X/Solaris): http://www.netbeans.org/<br />
* Example tutorial on setting this up: http://mechomaniac.com/BeagleboardDevelopmentWithNetbeans<br />
<br />
<br />
= Kernel =<br />
<br />
=== Getting the Right Kernel ===<br />
The modern BeagleBone kernels are Maintained by Koen Kooi and are available on the 3.8 branch at https://github.com/beagleboard/kernel/tree/3.8 . This repo contains a set of patches and a script which downloads a mainline kernel and then patches it appropriately. Exact steps for building it are in the README.<br />
<br />
=== Device Tree ===<br />
The 3.5 and newer BeagleBone kernels make use of [[Device_Trees|Device Trees]]. A Device Tree is a text file which describes the layout of a machine, commonly the combination of a system-on-chip (SoC) and a board, so that the kernel can know at what addresses and on which buses hardware is located. The BeagleBone kernels make use of an extension called [[Capemgr|Capemgr]] which allows dynamic loading and unloading of device tree fragments both at compile time and from userspace post-boot.<br />
Learning about the Device Tree is very essential, if you wish to be able to manipulate pins and be able to use them as inputs/outputs. There is a [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 short guide to it here] (part-way down the page). In a nutshell, the device tree can be manipulated by creating a text 'fragment' file that can be converted into a .dtbo file using a program called dtc which is already installed on the BeagleBone Black. The .dtbo file can then be installed and uninstalled as desired. The procedures to install and uninstall are at that link:<br />
<br />
<tt>echo cape-bone-name > $SLOTS</tt> to install, and<br />
<br />
<br />
<tt>echo -<slotnum> > $SLOTS</tt> to uninstall,<br />
but read through the web page and comments section first to see what $SLOT is set to).<br />
<br />
<br />
<br />
= FAQ =<br />
<br />
For BeagleBoard frequently asked questions (FAQ) see [[BeagleBoardFAQ|community FAQ]] and "official" [http://beagleboard.org/support/faq BeagleBoard.org FAQ].<br />
<br />
= Links =<br />
== Home site and Community ==<br />
* [http://beagleboard.org/ beagleboard.org] -- home for BeagleBoard and BeagleBone products<br />
* [http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black] -- manufacturer's page for the second BeagleBone board<br />
* irc://irc.freenode.net/#beagle -- official combined IRC channel<br />
* [http://beagleboard.org/discuss Google Groups forums/mailing list] -- [https://groups.google.com/forum/?fromgroups#!forum/beagleboard English], [http://groups.google.com/group/pandabeagle-jp Japan], [http://groups.google.com/group/beagleboard-brasil Brasil], [https://groups.google.com/group/beagle-board-turkiye Turkey]<br />
* [http://beagleboard.org/project BeagleBoard and BeagleBone projects list]<br />
* [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] and its [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page]<br />
* [http://www.adafruit.com/blog/category/beaglebone/ BeagleBone articles at Adafruit blog] -- products, projects and tutorials<br />
* Use [http://www.google.de/ Google] to search beagleboard.org (including [http://www.beagleboard.org/irclogs/ IRC logs]) using ''site:beagleboard.org <search term>''<br />
* [https://www.linux.com/news/embedded-mobile/mobile-linux/715298-45-beaglebone-black-keeps-eyes-on-raspberry-pi Linux.com report on BeagleBone Black] -- with words from beagleBoard.org's cofounder Jason Kridner<br />
* [https://github.com/selsinork/beaglebone-black-pinmux github.com/selsinork/beaglebone-black-pinmux] -- pinmux data for BeagleBone Black, including extraction scripts<br />
* [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 Element 14 knode blog: Working with the PRU-ICSS] -- detailed tutorial on starting with the PRU on BBB<br />
<br />
== Tutorials and Videos ==<br />
* [http://beagleboard.org/static/bonescript/bone101/index.html ''BeagleBone: BeagleBoard-101 Intro''] -- slides (turn off Javascript for single page)<br />
* [http://www.youtube.com/watch?v=EEnOWR-GXjk ''BeagleBone Intro''], video by Jason Kridner, Texas Instruments<br />
* [http://www.youtube.com/watch?v=Y0uqRVxismQ ''How-To: Get Started with the BeagleBone''], video by Matt Richardson, MakeMagazine<br />
* [http://www.youtube.com/watch?v=z6b4zlh0IrE ''The Beaglebone - Unboxing, Introduction Tutorial and First Example''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=vFv_-ykLppo ''Beaglebone: C/C++ Programming Introduction for ARM Embedded Linux Development using Eclipse''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=SaIpz00lE84 ''Beaglebone: GPIO Programming on ARM Embedded Linux''], video by Derek Molloy, DCU/EE<br />
* [https://gist.github.com/4013192 ''C code for GPIO polling''], sample code by Andrew Montag<br />
* [http://borderhack.com/?p=1062 First steps with the Beaglebone], introductory HOWTO by octavio at borderhack<br />
* [http://learn.adafruit.com/beaglebone Adafruit Learning System - BeagleBone] -- web page<br />
<br />
== Manuals and resources ==<br />
* [http://beagleboard.org/static/beaglebone/a3/Docs/Hardware/BONE_SRM.pdf BeagleBone System Reference Manual (rev. A3_1.0)]<br />
* [http://www.ti.com/am335x Texas Instruments - Sitara AM335x ARM Cortex-A8 Microprocessor overview]<br />
* [http://www.ti.com/product/am3359 Texas Instruments - AM3359 Sitara ARM Cortex-A8 Microprocessor full documentation]<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARM/ARMv7-AR Architecture] -- ARM Cortex-A8 architecture overview<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8 Technical Reference Manual r2p1]<br />
* [http://www.arm.com/support/university/development-platforms/cortex-a8-development-platforms.php ARM Cortex-A Development Platforms] -- ARM page on Beagle boards<br />
* [http://www.ti.com/product/tps65217b TI TPS65217 Power Management IC], [http://www.ti.com/lit/ds/symlink/tps65217.pdf TPS65217 PMIC datasheet]<br />
* [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H Hi-Speed Dual USB UART/FIFO IC overview], [http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf FT2232H datasheet]<br />
* [http://www.linux-usb.org/gadget/index.html Linux-USB Gadget API Framework] and [http://www.linux-usb.org/gadget/h2-otg.html USB OTG], and [http://forums.gentoo.org/viewtopic-t-843255.html kernel config] -- Ethernet-over-USB<br />
* [https://docs.google.com/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub Beaglebone and the 3.8 Kernel] Details about the 3.8 Kernel, its use of DT and the capemanager.<br />
<br />
== Translations ==<br />
* 한국어:[[KR:BeagleBone]]<br />
<br />
== Errata ==<br />
<br />
= Subpages =<br />
http://elinux.org/BeagleBone_Usb_Networking<br />
http://elinux.org/BeagleBone_and_the_3.8_Kernel</div>Pantohttps://elinux.org/index.php?title=BeagleBone_Community&diff=259574BeagleBone Community2013-05-31T16:37:11Z<p>Panto: Added link to beaglebone 3.8 kernel</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
[[Category:Development Boards]]<br />
[[Category: BeagleBoard]]<br />
[[Category: BeagleBone]]<br />
<br />
[[File:BeagleBone_256x249.jpg|320px|thumb|right|BeagleBone]]<br />
[[File:BeagleBone-Black-A5_product_detail_black_sm.jpg|320px|thumb|right|BeagleBone Black]]<br />
<br />
This page collects information about [http://beagleboard.org BeagleBoard.org]'s range of [http://beagleboard.org/bone BeagleBone] boards based on the [http://www.ti.com/am335x TI Sitara AM335x], an application processor SoC containing an [http://en.wikipedia.org/wiki/ARM_Cortex-A8 ARM Cortex-A8] core. The range currently consists of the original '''BeagleBone''' and the upgraded but lower cost '''BeagleBone Black'''.<br />
<br />
Most features are common to the two models. The differences between them are described in each section under a '''BeagleBone Black''' subheading.<br />
<br />
<br><br />
= Events =<br />
* ongoing 2009: [[BeagleBoard/contest|Beagle Sponsored Project Program]] - add a cool project and get a free BeagleBoard to realize it!<br />
<br />
= Description =<br />
The two models of BeagleBone share most features in common through employing only slightly different versions of the same TI Sitara SoC. In addition they both adhere to the same standard for expansion and interfacing through "cape" daughterboards. <br />
<br />
== BeagleBone (original) ==<br />
The '''BeagleBone''' is a low-cost, high-expansion board from the [http://beagleboard.org/ BeagleBoard] product line. It uses the [http://www.ti.com/am335x TI AM3358/9] SoC based on an [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8] processor core using the [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARMv7-A] architecture. It is similar in purpose to earlier BeagleBoards, and can be used either standalone or as a USB or Ethernet-connected expansion for a BeagleBoard or any other system. The BeagleBone is small even by BeagleBoard standards yet still provides much of the performance and capabilities of the larger BeagleBoards.<br />
<br />
BeagleBone ships with a 4GB micro-SD card preloaded with the [http://www.angstrom-distribution.org/ Angstrom] ARM Linux distribution.<br />
<br />
The board uses a [http://www.ti.com/product/tps65217b TI TPS65217B PMIC] to generate stable supply voltages regardless of input power variation. +5V DC power can be supplied to the BeagleBone through a barrel connector or from the mini-USB, both of which are located near the large RJ45 Ethernet connector.<br />
<br />
The mini-USB type-A OTG/device '''client-mode''' socket is multi-functional. In addition to providing an alternative source of power, it gives access to an on-board front-end two-port USB client-side hub. (This is not related to the separate '''host-mode''' USB socket described later). One port of the hub goes directly to the '''USB0''' port of the TI AM3358/9 SoC, while the other port connects to a dual-port [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H] USB-to-serial converter to provide board-to-external-host serial communications and/or JTAG debugging. The BeagleBone's Linux serial console is available through this USB serial connection.<br />
<br />
The SoC's '''USB0''' connection to the front-end hub works in one of two modes, and you can toggle between them at any time: it either presents the SD card as a mountable USB storage device to the host, or it provides an [http://www.linux-usb.org/usbnet/ Ethernet-over-USB] networking interface which yields a simple method of quick-start. The Ethernet-over-USB facility is additional to the BeagleBone's normal 10/100 Ethernet interface, which is directly implemented in the SoC rather than hanging off USB as in some other designs. Full IPv4 and IPv6 networking is provided by the supplied Linux system out of the box.<br />
<br />
In addition to the USB OTG Device or '''client-mode''' facilities already described, BeagleBone also provides one '''host-mode''' USB type-A socket on the other end of the board. This is driven from the '''USB1''' connection on the AM3358/9 SoC, and provides access to USB host peripherals such as mice, keyboards, storage, and wifi or Bluetooth dongles, or a USB hub for further expansion.<br />
<br />
== BeagleBone Black ==<br />
On 23rd April 2013, Beagleboard officially announced '''[http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black]''' at a price approximately half that of the original BeagleBone.<br />
<br />
The new board's most important new features include a AM3359 SoC upgraded to 1GHz, doubling of memory to 512MB, use of faster DDR3 memory in contrast to the DDR2 of the original BeagleBone, and a new HDMI audio/visual output. (The original BeagleBone required an additional cape daughterboard for graphic output).<br />
<br />
= Specifications =<br />
The two boards are very similar in those features provided directly by the SoC. Despite the original BeagleBone being specified as using "AM3358/9", in practice most boards are believed to have shipped with the AM3359 generic part. BeagleBone Black has therefore upgraded only the specific device selected from the AM3359 range, and hence the differences are few. In contrast, the boards have significantly different designs but a high degree of compatibility.<br />
== BeagleBone ==<br />
* Up to 720 MHz superscalar ARM Cortex-A8 AM3358/9<br />
* 256 MB DDR2 RAM<br />
* 10/100 Ethernet RJ45 socket, IPv4 and IPv6 networking<br />
* MicroSD slot and 4GB microSD card supplied<br />
* Preloaded with Angstrom ARM Linux Distribution<br />
* Single USB 2.0 type A host port<br />
* Dual USB hub on USB 2.0 type mini-A OTG device port<br />
* On-board USB-to-serial/JTAG over one shared USB device port<br />
* Storage-over-USB or Ethernet-over-USB on other USB device port<br />
* Extensive I/O: 2 I2C, 5 UART, SPI, CAN, 66 GPIO, 8 PWM, 8 ADC<br />
* +5V DC power from barrel connector or USB device port<br />
* Power consumption of 300-500mA at 5V<br />
* Two 46-pin 3.3-V peripheral headers with multiplexed LCD signals<br />
* Board size: 3.4" × 2.1" (86.4mm x 53.3mm) -- fits in an Altoid tin<br />
<br />
== BeagleBone Black (differences) ==<br />
* 1 GHz superscalar ARM Cortex-A8 AM3359<br />
* 512 MB DDR3 RAM<br />
* On-board 2 GB eMMC flash, preloaded with Angstrom ARM Linux Distribution<br />
* MicroSD slot for additional user data or operating systems (no card supplied)<br />
* USB 2.0 type A host port<br />
* Dedicated single mini-USB 2.0 client port (no additional 2-port hub)<br />
* New micro-HDMI audio/visual output<br />
* USB-to-serial and USB-to-JTAG interfaces removed (available on expansion headers)<br />
* Power expansion header for backlight removed, battery charging moved onto pads<br />
* Lower power consumption of 210-460 mA at 5V<br />
<br />
= Expansion Connectors =<br />
The BeagleBone provides two 46-pin dual-row expansion connectors "'''P9'''" and "'''P8'''" which are also known as "'''Expansion A'''" and "'''Expansion B'''", respectively. The location and pinout of these connectors is illustrated below (click tables to enlarge). All signals on expansion headers are 3.3V except where indicated otherwise.<br />
<br />
=== P9 and P8 - Each 2x23 pins ===<br />
[[File:BeagleBone_P9_256x256.jpg|256px|left|top|border|P9 Header|link=File:BeagleBone_p9_pinout.jpg]]<br />
[[File:BeagleBone_P9_P8_256x256.jpg|256px|top|border|BeagleBone P9 + P8|link=File:BeagleBone_P9_P8_512x512.jpg]]<br />
[[File:BeagleBone_P8_256x256.jpg|256px|top|border|P8 Header|link=File:BeagleBone_p8_pinout.jpg]]<br />
<p><br><br />
In addition to the two large headers above, a small 10-pin dual-row connector provides "'''P6'''" provides a "'''PMIC Expansion'''" that brings out some additional signals from the TPS65217B Power Management IC, using the following pinout:<br />
<br />
=== P6 - 2x5 pins''' ===<br />
[[File:BeagleBone_P6_464x222.jpg|464px|left|middle|border|P6 MPIC Expansion Header]]<br />
<br />
'''NB. P6 is not available on BeagleBone Black'''<br />
<br />
'''IMPORTANT'''<br />
<br />
This diagram of P6 provides an '''UNDERSIDE PINOUT''' view.<br />
<br />
It is therefore ''' ''laterally inverted'' ''' relative to the photograph.<br />
<br />
To obtain the top-side pinout that corresponds to the physical orientation shown in the photograph, swap the two rows of pins so that odd-numbered pins are on the left of even-numbered pins.<br style="clear: both" /><br />
<br />
= Expansion Boards and Accessories =<br />
<br />
== Capes ==<br />
A '''BeagleBone Cape''' is an expansion board which can be plugged into the BeagleBone's two 46-pin dual-row '''Expansion Headers''' and which in turns provides similar headers onto which further capes can be stacked. Up to four capes at a time can be stacked on top of a BeagleBone. An expansion board which can be fitted only at the top of a stack of capes (usually for physical reasons) is a special case of "cape", but this usage is common for display expansion boards such as LCDs (see next section).<br />
<br />
Capes are required to provide a 32Kbyte I2C-addressed EEPROM which holds board information such as board name, serial number and revision, although this is typically omitted on simple prototyping capes. Capes are also expected to provide a 2-position DIP switch to select their address in the stack, although this too is often omitted in prototyping capes.<br />
<br />
The [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] seeks to index all existing capes and cape concepts, including private projects. A [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page] is available to help add capes to the list.<br />
<br />
This section lists only those capes which are available commercially or which are close to a production release, as well as open hardware designs.<br />
<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_DVID CircuitCo BeagleBone DVI-D cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breadboard CircuitCo BeagleBone Breadboard cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breakout CircuitCo BeagleBone Breakout cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_CANBus CircuitCo BeagleBone CANBus cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_RS232 CircuitCo BeagleBone RS232 cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Battery CircuitCo BeagleBone Battery cape]<br />
* [http://www.adafruit.com/products/572 Adafruit Proto Cape kit for BeagleBone]<br />
* [http://www.towertech.it/en/products/hardware/tt3201-can-cape/ TowerTech TT3201 Multi-Channel CAN Cape]<br />
* [https://specialcomp.com/beaglebone/BeagleBone_FPGA.html Special Computing Spartan-3A FPGA cape for BeagleBone] -- in development<br />
* [http://syntheticlifeforms.net/?p=43 Thinking Machines LCD-IO Expansion Cape] -- in development<br />
* [https://github.com/piranha32/FlyingBone Open Source BeagleBone Prototyping Board] -- piranha32 GitHub repository<br />
* [http://www.armkits.com/product/beaglebone-hdmicape.asp Embest BeagleBone HDMI cape]<br />
* [[BeagleBone 6502 RemoteProc cape]] -- in development<br />
<br />
== LCD Displays and Other Expansions ==<br />
LCD displays for the BeagleBone are typically implemented as capes which plug in as the ''' ''top board'' ''' in a stack of capes, for reasons of visibility. Such displays are often larger than the BeagleBone itself, so the normal physical relationship in which a daughterboard is smaller than its host board is inverted. In this arrangement it is the expansion board that provides the physical support for the BeagleBone.<br />
<br />
* [[File:Beaglebone.jpg|320px|thumb|BeadaFrame]][http://www.nxelec.com/products/hmi/beadaframe-beaglebone NAXING Electronics BeadaFrame] with BeagleBone companion board<br />
:Expanded Hardware Features:<br />
:* 7" 800x480 TFT LCD screen<br />
:* PWM Backlight control<br />
:* Resistive touch panel<br />
:* Plastic frame<br />
:* 256MB Nand flash(K9F2G08)<br />
:* RS232 serial ports(UART1 w/ CTS&RTS)<br />
:* Stereo audio out<br />
:* Micro-phone in<br />
:* 6 x USER buttons<br />
:* PWM Beeper<br />
:* RTC with Battery(DS1302)<br />
<br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD3 CircuitCo BeagleBone LCD3 cape and LCD display]<br />
: 3.5" TFT LCD screen, resolution 320x240, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD4 CircuitCo BeagleBone LCD4 cape and LCD display]<br />
: 4" TFT LCD screen, resolution 480x272, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD7 CircuitCo BeagleBone LCD7 cape and LCD display]<br />
: 7" TFT LCD screen, resolution 800x480, 4-wire resistive touchscreen, rear mount for BeagleBone and capes.<br />
* A very low cost LCD implementation for the BeagleBone Black using the PRU-ICSS is [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/28/bbb--connecting-up-an-lcd here]. It requires a graphics library to be written; currently it just displays a couple of lines on the screen.<br />
<br />
== Cases ==<br />
* [http://www.adafruit.com/products/699 Adafruit Bone Box - Enclosure for Beagle Bone]<br />
* [http://www.skpang.co.uk/catalog/acrylic-cover-for-beaglebone-p-1076.html SK Pang Acrylic Cover for BeagleBone]<br />
* [http://specialcomp.com/beagleboard/BB-Bone-assy2_l.jpg Special Computing Bone Acrylic Case]<br />
* [http://www.thingiverse.com/thing:19153 canadaduane's 3D-printable BeagleBone Case design]<br />
* [http://www.thingiverse.com/thing:16195 NinjaBlock's 3D-printable Beaglebone front panel design]<br />
* [http://www.thingiverse.com/thing:20122 builttospec's laser-cut design for BeagleBone Enclosure with DVI Cape]<br />
* [http://www.built-to-spec.com/blog/2012/03/01/beaglebone-case-update-and-new-kits-page/ Built to Spec BeagleBone Case Update], and [http://builttospecstore.storenvy.com/products/225603-beaglebone-enclosure final product]<br />
<br />
= BeagleBone Operating Systems =<br />
BeagleBone's default operating system is [http://www.angstrom-distribution.org/ Angstrom], which ships with the board. This section provides basic information on Angstrom and other operating systems commonly used on BeagleBone. This information may help in making a preliminary choice, but full details should be obtained from the home sites.<br />
<br />
The latest images of the official Angstrom images for BeagleBoard.org products can be found at [http://beagleboard.org/latest-images the beagleboard.org latest images web page]<br />
<br />
=== Angstrom ===<br />
* Home site: http://www.angstrom-distribution.org/<br />
* Mailing lists: [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel angstrom-distro-devel] and [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-users angstrom-distro-users]<br />
* IRC channel: irc://irc.freenode.net/#angstrom<br />
Ångström was started by a small group of people who worked on the OpenEmbedded, OpenZaurus and OpenSimpad projects to unify their effort to make a stable and user-friendly distribution for embedded devices like handhelds, set top boxes and network-attached storage devices.<br />
Ångström can scale down to devices with only 4MB of flash storage.<br />
<br />
The Angstrom community does not provide a forum, [http://www.angstrom-distribution.org/contact intentionally].<br />
<br />
Angstrom uses [http://www.busybox.net/ Busybox] for many key utilities, which has both pros and cons. Advantages include requiring less storage space and a smaller memory footprint for many common utilities, which also improves system startup time and performance. The main disadvantages stem from those utilities not mirroring exactly their full-size counterparts. These differences can be annoying if one is used to standard behavior, and may also break shell scripts that rely on portable functionality.<br />
<br />
Angstrom uses [http://connman.net/ connman] for network connection management, but no documentation is available for this currently. Also, man(1) and man pages are not provided by default, nor debugging utilities like strace(1) and tcpdump(1). Getting started may therefore present difficulties, depending on experience.<br />
<br />
=== Debian ===<br />
* See [[BeagleBoardDebian]]<br />
* Home site: [http://wiki.debian.org/ArmEabiPort http://wiki.debian.org/ArmEabiPort]<br />
* Mailing list: http://lists.debian.org/debian-arm/<br />
* IRC channel: irc://irc.debian.org/debian-arm<br />
The ARM EABI port is the default port of the standard Debian distribution of Linux for the ARM architecture ("armel").<br />
EABI ("Embedded ABI") is actually a family of ABIs, and one of the "subABIs" is the GNU EABI for Linux which is used for this port.<br />
Starting with Debian 7.0 (Wheezy) there is a port targeted at newer (armv7 with fpu) hardware with another ABI ("armhf").<br />
<br />
The [http://www.debian.org/intro/about Debian Project] is strongly committed to software freedom, and has a long pedigree and a good reputation.<br />
<br />
=== Ubuntu ===<br />
* See [[BeagleBoardUbuntu]]<br />
* Home site: https://wiki.ubuntu.com/ARM<br />
* IRC channel: irc://irc.freenode.net/#ubuntu-arm<br />
The vision for Ubuntu is part social and part economic: free software, available free of charge to everybody on the same terms, and funded through a portfolio of services provided by Canonical.<br />
<br />
The first version of Ubuntu was based on the GNOME desktop, but has since added a KDE edition, Kubuntu, and a server edition. All of the editions of Ubuntu share common infrastructure and software. In recent years, special emphasis has been placed on netbooks for lightweight, connected, mobile computing, and on the cloud as a new architecture for data centres.<br />
<br />
=== Fedora ===<br />
* See [[BeagleBoardFedora]].<br />
* Home site: http://fedoraproject.org/wiki/Architectures/ARM<br />
* Mailing list: http://lists.fedoraproject.org/pipermail/arm/<br />
* IRC channel: irc://irc.freenode.net/#fedora-arm<br />
The Fedora Project is sponsored by Red Hat, which invests in its infrastructure and resources to encourage collaboration and incubate innovative new technologies. Some of these technologies may later be integrated into Red Hat products. They are developed in Fedora and produced under a free and open source license from inception, so other free software communities and projects are free to study, adopt, and modify them.<br />
<br />
Red Hat has been a major player since the earliest days of Linux distributions, and has earned a good reputation for solidity which continues in Fedora. The Fedora ARM initiative is very active (see mailing list).<br />
<br />
=== ArchLinux ===<br />
* Home site: http://archlinuxarm.org/platforms/armv7/beaglebone<br />
* Source repository: https://github.com/archlinuxarm/PKGBUILDs<br />
* IRC channel: irc://irc.freenode.net/#archlinux-arm<br />
Arch Linux for BeagleBone is a version of the Arch Linux ARM distribution. This carries forward the Arch Linux philosophy of simplicity and user-centrism, targeting and accommodating ''competent'' Linux users by giving them complete control and responsibility over the system. Instructions are provided to assist in navigating the nuances of installation on the varied ARM platforms; however, the system itself will offer little assistance to the user.<br />
<br />
The entire distribution is on a rolling-release cycle that can be updated daily through small packages instead of huge updates on a defined release schedule. Most packages are unmodified from what the upstream developer originally released.<br />
<br />
=== Gentoo ===<br />
* Home site: http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml<br />
* IRC channel: irc://irc.freenode.net/#gentoo-embedded<br />
Gentoo is a source-based '' '''meta'''-distribution'' of Linux. Instead of distributing a standard system image built with predefined options, Gentoo gives each user the means to create their own customized system that doesn't contain unused bloat and with minimum dependencies. Upgrades are incremental and under user control, so a Gentoo system is normally always up-to-date and wholesale upgrades are avoided.<br />
<br />
Being a source-based system, the downside of Gentoo for low-power ARM systems is very long install times for large applications. Cross-compilation on x86 machines and [http://www.gentoo.org/doc/en/distcc.xml distcc] can overcome this problem, but they add complexity.<br />
<br />
=== Sabayon ===<br />
* Home site: [http://wiki.sabayon.org/index.php?title=Hitchhikers_Guide_to_the_BeagleBone_%28and_ARMv7a%29 wiki.sabayon.org/Hitchhikers Guide to the BeagleBone]<br />
* IRC channel: irc://irc.freenode.net/#sabayon<br />
Sabayon Linux uses the mechanisms of Gentoo to create a pre-configured Linux distribution that can be installed as rapidly as a normal binary distribution, but still retains the benefits of Gentoo's source-based package management. Sabayon on Intel/AMD also provides the Entropy binary package management system, which could in principle greatly ease installation of packages on resource-constrained embedded Linux devices, but this is not yet available for ARM.<br />
<br />
Although it is still early days for Sabayon on ARM (and hence on BeagleBone), there is regular progress reported on [http://lxnay.wordpress.com/2012/ lxnay's blog], and contributions from the community would probably accelerate the work.<br />
<br />
=== Buildroot ===<br />
* Home site: http://www.zoobab.com/beaglebone<br />
* Buildroot project site: http://buildroot.uclibc.org/<br />
Buildroot is a set of Makefiles and patches that makes it easy to generate a complete embedded Linux system. Buildroot can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a bootloader image. Buildroot is useful mainly for people working with small or embedded systems, using various CPU architectures (x86, ARM, MIPS, PowerPC, etc.) : it automates the building process of your embedded system and eases the cross-compilation process.<br />
<br />
The resulting root filesystem is mounted read-only, but other filesystems can be mounted read/write for persistence. Although user accounts can be created, in practice almost everything is done as root. Buildroot uses no package manager. Instead, package selection is managed through '''make menuconfig'''.<br />
<br />
=== Nerves Erlang/OTP ===<br />
* Home site: http://nerves-project.org/<br />
* Source repository: https://github.com/nerves-project/bbone-erlang-buildroot<br />
* Erlang project site: http://www.erlang.org/<br />
Erlang is a programming language used to build massively scalable soft realtime systems with high availability requirements (5-9’s). Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang’s runtime system has built-in support for concurrency, distribution and fault tolerance.<br />
<br />
OTP is a set of Erlang libraries and design principles providing middle-ware to develop these systems. It includes its own distributed database, applications to interface towards other languages, debugging and release handling tools.<br />
<br />
The Nerves project provides an embedded Linux-based environment for running Erlang and an easy-to-use API to access common I/O interfaces, based on '''Buildroot''' (see above). If you are interested in running an Erlang node on a low power ARM-based board such as BeagleBone, this project can get you started.<br />
<br />
= Board recovery =<br />
* See [http://elinux.org/BeagleBoardRecovery#USB_recovery BeagleBoardRecovery] ''--- (*) Check applicability''<br />
<br />
= Software Development =<br />
Software development on the BeagleBone is normally no different to any other Linux platform, and typically varies with language and with the IDE used, if any. This section deals only with development issues that are specific to BeagleBone, or mostly so.<br />
<br />
=== Cloud9 IDE and Bonescript ===<br />
''..... description here .....''<br />
* Source repository: https://github.com/jadonk/bonescript<br />
* Language documentation: http://nodejs.org/<br />
<br />
=== BeagleBone JTAG Debugging ===<br />
''..... description here .....''<br />
<br />
===Using Netbeans to remotely compile and debug C/C++===<br />
<br />
When developing c/c++ on a linux desktop, a toolchain is available for cross-compiling the code for arm. However no such toolchain is readily available for windows. Netbeans can be used to write the code on your desktop, save it in a location accessible to the beagle, and then automatically compile it on the beagle itself using ssh and the built in compiler on the beaglebone's OS.<br />
<br />
Netbeans can also use GDB for remote debugging over ssh.<br />
<br />
Requirements:<br />
<br />
* Set up a samba / smb network share through which code can be shared between both desktop and beagle<br />
* Give netbeans the SSh login details of the beagle<br />
* Give netbeans the path mapping so it can translate between the desktop code folder and beagle code folder<br />
* Setup only takes a few minutes.<br />
<br />
====More info====<br />
<br />
* Download Netbeans (Windows/Linux/OS-X/Solaris): http://www.netbeans.org/<br />
* Example tutorial on setting this up: http://mechomaniac.com/BeagleboardDevelopmentWithNetbeans<br />
<br />
<br />
= Kernel =<br />
<br />
=== Getting the Right Kernel ===<br />
The modern BeagleBone kernels are Maintained by Koen Kooi and are available on the 3.8 branch at https://github.com/beagleboard/kernel/tree/3.8 . This repo contains a set of patches and a script which downloads a mainline kernel and then patches it appropriately. Exact steps for building it are in the README.<br />
<br />
=== Device Tree ===<br />
The 3.5 and newer BeagleBone kernels make use of [[Device_Trees|Device Trees]]. A Device Tree is a text file which describes the layout of a machine, commonly the combination of a system-on-chip (SoC) and a board, so that the kernel can know at what addresses and on which buses hardware is located. The BeagleBone kernels make use of an extension called [[Capemgr|Capemgr]] which allows dynamic loading and unloading of device tree fragments both at compile time and from userspace post-boot.<br />
Learning about the Device Tree is very essential, if you wish to be able to manipulate pins and be able to use them as inputs/outputs. There is a [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 short guide to it here] (part-way down the page). In a nutshell, the device tree can be manipulated by creating a text 'fragment' file that can be converted into a .dtbo file using a program called dtc which is already installed on the BeagleBone Black. The .dtbo file can then be installed and uninstalled as desired. The procedures to install and uninstall are at that link:<br />
<br />
<tt>echo cape-bone-name > $SLOTS</tt> to install, and<br />
<br />
<br />
<tt>echo -<slotnum> > $SLOTS</tt> to uninstall,<br />
but read through the web page and comments section first to see what $SLOT is set to).<br />
<br />
<br />
<br />
= FAQ =<br />
<br />
For BeagleBoard frequently asked questions (FAQ) see [[BeagleBoardFAQ|community FAQ]] and "official" [http://beagleboard.org/support/faq BeagleBoard.org FAQ].<br />
<br />
= Links =<br />
== Home site and Community ==<br />
* [http://beagleboard.org/ beagleboard.org] -- home for BeagleBoard and BeagleBone products<br />
* [http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black] -- manufacturer's page for the second BeagleBone board<br />
* irc://irc.freenode.net/#beagle -- official combined IRC channel<br />
* [http://beagleboard.org/discuss Google Groups forums/mailing list] -- [https://groups.google.com/forum/?fromgroups#!forum/beagleboard English], [http://groups.google.com/group/pandabeagle-jp Japan], [http://groups.google.com/group/beagleboard-brasil Brasil], [https://groups.google.com/group/beagle-board-turkiye Turkey]<br />
* [http://beagleboard.org/project BeagleBoard and BeagleBone projects list]<br />
* [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] and its [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page]<br />
* [http://www.adafruit.com/blog/category/beaglebone/ BeagleBone articles at Adafruit blog] -- products, projects and tutorials<br />
* Use [http://www.google.de/ Google] to search beagleboard.org (including [http://www.beagleboard.org/irclogs/ IRC logs]) using ''site:beagleboard.org <search term>''<br />
* [https://www.linux.com/news/embedded-mobile/mobile-linux/715298-45-beaglebone-black-keeps-eyes-on-raspberry-pi Linux.com report on BeagleBone Black] -- with words from beagleBoard.org's cofounder Jason Kridner<br />
* [https://github.com/selsinork/beaglebone-black-pinmux github.com/selsinork/beaglebone-black-pinmux] -- pinmux data for BeagleBone Black, including extraction scripts<br />
* [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 Element 14 knode blog: Working with the PRU-ICSS] -- detailed tutorial on starting with the PRU on BBB<br />
<br />
== Tutorials and Videos ==<br />
* [http://beagleboard.org/static/bonescript/bone101/index.html ''BeagleBone: BeagleBoard-101 Intro''] -- slides (turn off Javascript for single page)<br />
* [http://www.youtube.com/watch?v=EEnOWR-GXjk ''BeagleBone Intro''], video by Jason Kridner, Texas Instruments<br />
* [http://www.youtube.com/watch?v=Y0uqRVxismQ ''How-To: Get Started with the BeagleBone''], video by Matt Richardson, MakeMagazine<br />
* [http://www.youtube.com/watch?v=z6b4zlh0IrE ''The Beaglebone - Unboxing, Introduction Tutorial and First Example''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=vFv_-ykLppo ''Beaglebone: C/C++ Programming Introduction for ARM Embedded Linux Development using Eclipse''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=SaIpz00lE84 ''Beaglebone: GPIO Programming on ARM Embedded Linux''], video by Derek Molloy, DCU/EE<br />
* [https://gist.github.com/4013192 ''C code for GPIO polling''], sample code by Andrew Montag<br />
* [http://borderhack.com/?p=1062 First steps with the Beaglebone], introductory HOWTO by octavio at borderhack<br />
* [http://learn.adafruit.com/beaglebone Adafruit Learning System - BeagleBone] -- web page<br />
<br />
== Manuals and resources ==<br />
* [http://beagleboard.org/static/beaglebone/a3/Docs/Hardware/BONE_SRM.pdf BeagleBone System Reference Manual (rev. A3_1.0)]<br />
* [http://www.ti.com/am335x Texas Instruments - Sitara AM335x ARM Cortex-A8 Microprocessor overview]<br />
* [http://www.ti.com/product/am3359 Texas Instruments - AM3359 Sitara ARM Cortex-A8 Microprocessor full documentation]<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARM/ARMv7-AR Architecture] -- ARM Cortex-A8 architecture overview<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8 Technical Reference Manual r2p1]<br />
* [http://www.arm.com/support/university/development-platforms/cortex-a8-development-platforms.php ARM Cortex-A Development Platforms] -- ARM page on Beagle boards<br />
* [http://www.ti.com/product/tps65217b TI TPS65217 Power Management IC], [http://www.ti.com/lit/ds/symlink/tps65217.pdf TPS65217 PMIC datasheet]<br />
* [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H Hi-Speed Dual USB UART/FIFO IC overview], [http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf FT2232H datasheet]<br />
* [http://www.linux-usb.org/gadget/index.html Linux-USB Gadget API Framework] and [http://www.linux-usb.org/gadget/h2-otg.html USB OTG], and [http://forums.gentoo.org/viewtopic-t-843255.html kernel config] -- Ethernet-over-USB<br />
* [https://docs.google.com/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub Beaglebone and the 3.8 Kernel] Details about the 3.8 Kernel, its use of DT and the capemanager.<br />
<br />
== Translations ==<br />
* 한국어:[[KR:BeagleBone]]<br />
<br />
== Errata ==<br />
<br />
= Subpages =<br />
http://elinux.org/BeagleBone_Usb_Networking<br />
http://elinux.org/Beaglenone_3.8_Kernel</div>Pantohttps://elinux.org/index.php?title=BeagleBone_Community&diff=259436BeagleBone Community2013-05-31T09:30:10Z<p>Panto: Added "Beaglebone and the 3.8 Kernel"</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
[[Category:Development Boards]]<br />
[[Category: BeagleBoard]]<br />
[[Category: BeagleBone]]<br />
<br />
[[File:BeagleBone_256x249.jpg|320px|thumb|right|BeagleBone]]<br />
[[File:BeagleBone-Black-A5_product_detail_black_sm.jpg|320px|thumb|right|BeagleBone Black]]<br />
<br />
This page collects information about [http://beagleboard.org BeagleBoard.org]'s range of [http://beagleboard.org/bone BeagleBone] boards based on the [http://www.ti.com/am335x TI Sitara AM335x], an application processor SoC containing an [http://en.wikipedia.org/wiki/ARM_Cortex-A8 ARM Cortex-A8] core. The range currently consists of the original '''BeagleBone''' and the upgraded but lower cost '''BeagleBone Black'''.<br />
<br />
Most features are common to the two models. The differences between them are described in each section under a '''BeagleBone Black''' subheading.<br />
<br />
<br><br />
= Events =<br />
* ongoing 2009: [[BeagleBoard/contest|Beagle Sponsored Project Program]] - add a cool project and get a free BeagleBoard to realize it!<br />
<br />
= Description =<br />
The two models of BeagleBone share most features in common through employing only slightly different versions of the same TI Sitara SoC. In addition they both adhere to the same standard for expansion and interfacing through "cape" daughterboards. <br />
<br />
== BeagleBone (original) ==<br />
The '''BeagleBone''' is a low-cost, high-expansion board from the [http://beagleboard.org/ BeagleBoard] product line. It uses the [http://www.ti.com/am335x TI AM3358/9] SoC based on an [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8] processor core using the [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARMv7-A] architecture. It is similar in purpose to earlier BeagleBoards, and can be used either standalone or as a USB or Ethernet-connected expansion for a BeagleBoard or any other system. The BeagleBone is small even by BeagleBoard standards yet still provides much of the performance and capabilities of the larger BeagleBoards.<br />
<br />
BeagleBone ships with a 4GB micro-SD card preloaded with the [http://www.angstrom-distribution.org/ Angstrom] ARM Linux distribution.<br />
<br />
The board uses a [http://www.ti.com/product/tps65217b TI TPS65217B PMIC] to generate stable supply voltages regardless of input power variation. +5V DC power can be supplied to the BeagleBone through a barrel connector or from the mini-USB, both of which are located near the large RJ45 Ethernet connector.<br />
<br />
The mini-USB type-A OTG/device '''client-mode''' socket is multi-functional. In addition to providing an alternative source of power, it gives access to an on-board front-end two-port USB client-side hub. (This is not related to the separate '''host-mode''' USB socket described later). One port of the hub goes directly to the '''USB0''' port of the TI AM3358/9 SoC, while the other port connects to a dual-port [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H] USB-to-serial converter to provide board-to-external-host serial communications and/or JTAG debugging. The BeagleBone's Linux serial console is available through this USB serial connection.<br />
<br />
The SoC's '''USB0''' connection to the front-end hub works in one of two modes, and you can toggle between them at any time: it either presents the SD card as a mountable USB storage device to the host, or it provides an [http://www.linux-usb.org/usbnet/ Ethernet-over-USB] networking interface which yields a simple method of quick-start. The Ethernet-over-USB facility is additional to the BeagleBone's normal 10/100 Ethernet interface, which is directly implemented in the SoC rather than hanging off USB as in some other designs. Full IPv4 and IPv6 networking is provided by the supplied Linux system out of the box.<br />
<br />
In addition to the USB OTG Device or '''client-mode''' facilities already described, BeagleBone also provides one '''host-mode''' USB type-A socket on the other end of the board. This is driven from the '''USB1''' connection on the AM3358/9 SoC, and provides access to USB host peripherals such as mice, keyboards, storage, and wifi or Bluetooth dongles, or a USB hub for further expansion.<br />
<br />
== BeagleBone Black ==<br />
On 23rd April 2013, Beagleboard officially announced '''[http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black]''' at a price approximately half that of the original BeagleBone.<br />
<br />
The new board's most important new features include a AM3359 SoC upgraded to 1GHz, doubling of memory to 512MB, use of faster DDR3 memory in contrast to the DDR2 of the original BeagleBone, and a new HDMI audio/visual output. (The original BeagleBone required an additional cape daughterboard for graphic output).<br />
<br />
= Specifications =<br />
The two boards are very similar in those features provided directly by the SoC. Despite the original BeagleBone being specified as using "AM3358/9", in practice most boards are believed to have shipped with the AM3359 generic part. BeagleBone Black has therefore upgraded only the specific device selected from the AM3359 range, and hence the differences are few. In contrast, the boards have significantly different designs but a high degree of compatibility.<br />
== BeagleBone ==<br />
* Up to 720 MHz superscalar ARM Cortex-A8 AM3358/9<br />
* 256 MB DDR2 RAM<br />
* 10/100 Ethernet RJ45 socket, IPv4 and IPv6 networking<br />
* MicroSD slot and 4GB microSD card supplied<br />
* Preloaded with Angstrom ARM Linux Distribution<br />
* Single USB 2.0 type A host port<br />
* Dual USB hub on USB 2.0 type mini-A OTG device port<br />
* On-board USB-to-serial/JTAG over one shared USB device port<br />
* Storage-over-USB or Ethernet-over-USB on other USB device port<br />
* Extensive I/O: 2 I2C, 5 UART, SPI, CAN, 66 GPIO, 8 PWM, 8 ADC<br />
* +5V DC power from barrel connector or USB device port<br />
* Power consumption of 300-500mA at 5V<br />
* Two 46-pin 3.3-V peripheral headers with multiplexed LCD signals<br />
* Board size: 3.4" × 2.1" (86.4mm x 53.3mm) -- fits in an Altoid tin<br />
<br />
== BeagleBone Black (differences) ==<br />
* 1 GHz superscalar ARM Cortex-A8 AM3359<br />
* 512 MB DDR3 RAM<br />
* On-board 2 GB eMMC flash, preloaded with Angstrom ARM Linux Distribution<br />
* MicroSD slot for additional user data or operating systems (no card supplied)<br />
* USB 2.0 type A host port<br />
* Dedicated single mini-USB 2.0 client port (no additional 2-port hub)<br />
* New micro-HDMI audio/visual output<br />
* USB-to-serial and USB-to-JTAG interfaces removed (available on expansion headers)<br />
* Power expansion header for backlight removed, battery charging moved onto pads<br />
* Lower power consumption of 210-460 mA at 5V<br />
<br />
= Expansion Connectors =<br />
The BeagleBone provides two 46-pin dual-row expansion connectors "'''P9'''" and "'''P8'''" which are also known as "'''Expansion A'''" and "'''Expansion B'''", respectively. The location and pinout of these connectors is illustrated below (click tables to enlarge). All signals on expansion headers are 3.3V except where indicated otherwise.<br />
<br />
=== P9 and P8 - Each 2x23 pins ===<br />
[[File:BeagleBone_P9_256x256.jpg|256px|left|top|border|P9 Header|link=File:BeagleBone_p9_pinout.jpg]]<br />
[[File:BeagleBone_P9_P8_256x256.jpg|256px|top|border|BeagleBone P9 + P8|link=File:BeagleBone_P9_P8_512x512.jpg]]<br />
[[File:BeagleBone_P8_256x256.jpg|256px|top|border|P8 Header|link=File:BeagleBone_p8_pinout.jpg]]<br />
<p><br><br />
In addition to the two large headers above, a small 10-pin dual-row connector provides "'''P6'''" provides a "'''PMIC Expansion'''" that brings out some additional signals from the TPS65217B Power Management IC, using the following pinout:<br />
<br />
=== P6 - 2x5 pins''' ===<br />
[[File:BeagleBone_P6_464x222.jpg|464px|left|middle|border|P6 MPIC Expansion Header]]<br />
<br />
'''NB. P6 is not available on BeagleBone Black'''<br />
<br />
'''IMPORTANT'''<br />
<br />
This diagram of P6 provides an '''UNDERSIDE PINOUT''' view.<br />
<br />
It is therefore ''' ''laterally inverted'' ''' relative to the photograph.<br />
<br />
To obtain the top-side pinout that corresponds to the physical orientation shown in the photograph, swap the two rows of pins so that odd-numbered pins are on the left of even-numbered pins.<br style="clear: both" /><br />
<br />
= Expansion Boards and Accessories =<br />
<br />
== Capes ==<br />
A '''BeagleBone Cape''' is an expansion board which can be plugged into the BeagleBone's two 46-pin dual-row '''Expansion Headers''' and which in turns provides similar headers onto which further capes can be stacked. Up to four capes at a time can be stacked on top of a BeagleBone. An expansion board which can be fitted only at the top of a stack of capes (usually for physical reasons) is a special case of "cape", but this usage is common for display expansion boards such as LCDs (see next section).<br />
<br />
Capes are required to provide a 32Kbyte I2C-addressed EEPROM which holds board information such as board name, serial number and revision, although this is typically omitted on simple prototyping capes. Capes are also expected to provide a 2-position DIP switch to select their address in the stack, although this too is often omitted in prototyping capes.<br />
<br />
The [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] seeks to index all existing capes and cape concepts, including private projects. A [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page] is available to help add capes to the list.<br />
<br />
This section lists only those capes which are available commercially or which are close to a production release, as well as open hardware designs.<br />
<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_DVID CircuitCo BeagleBone DVI-D cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breadboard CircuitCo BeagleBone Breadboard cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breakout CircuitCo BeagleBone Breakout cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_CANBus CircuitCo BeagleBone CANBus cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_RS232 CircuitCo BeagleBone RS232 cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Battery CircuitCo BeagleBone Battery cape]<br />
* [http://www.adafruit.com/products/572 Adafruit Proto Cape kit for BeagleBone]<br />
* [http://www.towertech.it/en/products/hardware/tt3201-can-cape/ TowerTech TT3201 Multi-Channel CAN Cape]<br />
* [https://specialcomp.com/beaglebone/BeagleBone_FPGA.html Special Computing Spartan-3A FPGA cape for BeagleBone] -- in development<br />
* [http://syntheticlifeforms.net/?p=43 Thinking Machines LCD-IO Expansion Cape] -- in development<br />
* [https://github.com/piranha32/FlyingBone Open Source BeagleBone Prototyping Board] -- piranha32 GitHub repository<br />
* [http://www.armkits.com/product/beaglebone-hdmicape.asp Embest BeagleBone HDMI cape]<br />
* [[BeagleBone 6502 RemoteProc cape]] -- in development<br />
<br />
== LCD Displays and Other Expansions ==<br />
LCD displays for the BeagleBone are typically implemented as capes which plug in as the ''' ''top board'' ''' in a stack of capes, for reasons of visibility. Such displays are often larger than the BeagleBone itself, so the normal physical relationship in which a daughterboard is smaller than its host board is inverted. In this arrangement it is the expansion board that provides the physical support for the BeagleBone.<br />
<br />
* [[File:Beaglebone.jpg|320px|thumb|BeadaFrame]][http://www.nxelec.com/products/hmi/beadaframe-beaglebone NAXING Electronics BeadaFrame] with BeagleBone companion board<br />
:Expanded Hardware Features:<br />
:* 7" 800x480 TFT LCD screen<br />
:* PWM Backlight control<br />
:* Resistive touch panel<br />
:* Plastic frame<br />
:* 256MB Nand flash(K9F2G08)<br />
:* RS232 serial ports(UART1 w/ CTS&RTS)<br />
:* Stereo audio out<br />
:* Micro-phone in<br />
:* 6 x USER buttons<br />
:* PWM Beeper<br />
:* RTC with Battery(DS1302)<br />
<br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD3 CircuitCo BeagleBone LCD3 cape and LCD display]<br />
: 3.5" TFT LCD screen, resolution 320x240, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD4 CircuitCo BeagleBone LCD4 cape and LCD display]<br />
: 4" TFT LCD screen, resolution 480x272, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD7 CircuitCo BeagleBone LCD7 cape and LCD display]<br />
: 7" TFT LCD screen, resolution 800x480, 4-wire resistive touchscreen, rear mount for BeagleBone and capes.<br />
* A very low cost LCD implementation for the BeagleBone Black using the PRU-ICSS is [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/28/bbb--connecting-up-an-lcd here]. It requires a graphics library to be written; currently it just displays a couple of lines on the screen.<br />
<br />
== Cases ==<br />
* [http://www.adafruit.com/products/699 Adafruit Bone Box - Enclosure for Beagle Bone]<br />
* [http://www.skpang.co.uk/catalog/acrylic-cover-for-beaglebone-p-1076.html SK Pang Acrylic Cover for BeagleBone]<br />
* [http://specialcomp.com/beagleboard/BB-Bone-assy2_l.jpg Special Computing Bone Acrylic Case]<br />
* [http://www.thingiverse.com/thing:19153 canadaduane's 3D-printable BeagleBone Case design]<br />
* [http://www.thingiverse.com/thing:16195 NinjaBlock's 3D-printable Beaglebone front panel design]<br />
* [http://www.thingiverse.com/thing:20122 builttospec's laser-cut design for BeagleBone Enclosure with DVI Cape]<br />
* [http://www.built-to-spec.com/blog/2012/03/01/beaglebone-case-update-and-new-kits-page/ Built to Spec BeagleBone Case Update], and [http://builttospecstore.storenvy.com/products/225603-beaglebone-enclosure final product]<br />
<br />
= BeagleBone Operating Systems =<br />
BeagleBone's default operating system is [http://www.angstrom-distribution.org/ Angstrom], which ships with the board. This section provides basic information on Angstrom and other operating systems commonly used on BeagleBone. This information may help in making a preliminary choice, but full details should be obtained from the home sites.<br />
<br />
The latest images of the official Angstrom images for BeagleBoard.org products can be found at [http://beagleboard.org/latest-images the beagleboard.org latest images web page]<br />
<br />
=== Angstrom ===<br />
* Home site: http://www.angstrom-distribution.org/<br />
* Mailing lists: [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel angstrom-distro-devel] and [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-users angstrom-distro-users]<br />
* IRC channel: irc://irc.freenode.net/#angstrom<br />
Ångström was started by a small group of people who worked on the OpenEmbedded, OpenZaurus and OpenSimpad projects to unify their effort to make a stable and user-friendly distribution for embedded devices like handhelds, set top boxes and network-attached storage devices.<br />
Ångström can scale down to devices with only 4MB of flash storage.<br />
<br />
The Angstrom community does not provide a forum, [http://www.angstrom-distribution.org/contact intentionally].<br />
<br />
Angstrom uses [http://www.busybox.net/ Busybox] for many key utilities, which has both pros and cons. Advantages include requiring less storage space and a smaller memory footprint for many common utilities, which also improves system startup time and performance. The main disadvantages stem from those utilities not mirroring exactly their full-size counterparts. These differences can be annoying if one is used to standard behavior, and may also break shell scripts that rely on portable functionality.<br />
<br />
Angstrom uses [http://connman.net/ connman] for network connection management, but no documentation is available for this currently. Also, man(1) and man pages are not provided by default, nor debugging utilities like strace(1) and tcpdump(1). Getting started may therefore present difficulties, depending on experience.<br />
<br />
=== Debian ===<br />
* See [[BeagleBoardDebian]]<br />
* Home site: [http://wiki.debian.org/ArmEabiPort http://wiki.debian.org/ArmEabiPort]<br />
* Mailing list: http://lists.debian.org/debian-arm/<br />
* IRC channel: irc://irc.debian.org/debian-arm<br />
The ARM EABI port is the default port of the standard Debian distribution of Linux for the ARM architecture ("armel").<br />
EABI ("Embedded ABI") is actually a family of ABIs, and one of the "subABIs" is the GNU EABI for Linux which is used for this port.<br />
Starting with Debian 7.0 (Wheezy) there is a port targeted at newer (armv7 with fpu) hardware with another ABI ("armhf").<br />
<br />
The [http://www.debian.org/intro/about Debian Project] is strongly committed to software freedom, and has a long pedigree and a good reputation.<br />
<br />
=== Ubuntu ===<br />
* See [[BeagleBoardUbuntu]]<br />
* Home site: https://wiki.ubuntu.com/ARM<br />
* IRC channel: irc://irc.freenode.net/#ubuntu-arm<br />
The vision for Ubuntu is part social and part economic: free software, available free of charge to everybody on the same terms, and funded through a portfolio of services provided by Canonical.<br />
<br />
The first version of Ubuntu was based on the GNOME desktop, but has since added a KDE edition, Kubuntu, and a server edition. All of the editions of Ubuntu share common infrastructure and software. In recent years, special emphasis has been placed on netbooks for lightweight, connected, mobile computing, and on the cloud as a new architecture for data centres.<br />
<br />
=== Fedora ===<br />
* See [[BeagleBoardFedora]].<br />
* Home site: http://fedoraproject.org/wiki/Architectures/ARM<br />
* Mailing list: http://lists.fedoraproject.org/pipermail/arm/<br />
* IRC channel: irc://irc.freenode.net/#fedora-arm<br />
The Fedora Project is sponsored by Red Hat, which invests in its infrastructure and resources to encourage collaboration and incubate innovative new technologies. Some of these technologies may later be integrated into Red Hat products. They are developed in Fedora and produced under a free and open source license from inception, so other free software communities and projects are free to study, adopt, and modify them.<br />
<br />
Red Hat has been a major player since the earliest days of Linux distributions, and has earned a good reputation for solidity which continues in Fedora. The Fedora ARM initiative is very active (see mailing list).<br />
<br />
=== ArchLinux ===<br />
* Home site: http://archlinuxarm.org/platforms/armv7/beaglebone<br />
* Source repository: https://github.com/archlinuxarm/PKGBUILDs<br />
* IRC channel: irc://irc.freenode.net/#archlinux-arm<br />
Arch Linux for BeagleBone is a version of the Arch Linux ARM distribution. This carries forward the Arch Linux philosophy of simplicity and user-centrism, targeting and accommodating ''competent'' Linux users by giving them complete control and responsibility over the system. Instructions are provided to assist in navigating the nuances of installation on the varied ARM platforms; however, the system itself will offer little assistance to the user.<br />
<br />
The entire distribution is on a rolling-release cycle that can be updated daily through small packages instead of huge updates on a defined release schedule. Most packages are unmodified from what the upstream developer originally released.<br />
<br />
=== Gentoo ===<br />
* Home site: http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml<br />
* IRC channel: irc://irc.freenode.net/#gentoo-embedded<br />
Gentoo is a source-based '' '''meta'''-distribution'' of Linux. Instead of distributing a standard system image built with predefined options, Gentoo gives each user the means to create their own customized system that doesn't contain unused bloat and with minimum dependencies. Upgrades are incremental and under user control, so a Gentoo system is normally always up-to-date and wholesale upgrades are avoided.<br />
<br />
Being a source-based system, the downside of Gentoo for low-power ARM systems is very long install times for large applications. Cross-compilation on x86 machines and [http://www.gentoo.org/doc/en/distcc.xml distcc] can overcome this problem, but they add complexity.<br />
<br />
=== Sabayon ===<br />
* Home site: [http://wiki.sabayon.org/index.php?title=Hitchhikers_Guide_to_the_BeagleBone_%28and_ARMv7a%29 wiki.sabayon.org/Hitchhikers Guide to the BeagleBone]<br />
* IRC channel: irc://irc.freenode.net/#sabayon<br />
Sabayon Linux uses the mechanisms of Gentoo to create a pre-configured Linux distribution that can be installed as rapidly as a normal binary distribution, but still retains the benefits of Gentoo's source-based package management. Sabayon on Intel/AMD also provides the Entropy binary package management system, which could in principle greatly ease installation of packages on resource-constrained embedded Linux devices, but this is not yet available for ARM.<br />
<br />
Although it is still early days for Sabayon on ARM (and hence on BeagleBone), there is regular progress reported on [http://lxnay.wordpress.com/2012/ lxnay's blog], and contributions from the community would probably accelerate the work.<br />
<br />
=== Buildroot ===<br />
* Home site: http://www.zoobab.com/beaglebone<br />
* Buildroot project site: http://buildroot.uclibc.org/<br />
Buildroot is a set of Makefiles and patches that makes it easy to generate a complete embedded Linux system. Buildroot can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a bootloader image. Buildroot is useful mainly for people working with small or embedded systems, using various CPU architectures (x86, ARM, MIPS, PowerPC, etc.) : it automates the building process of your embedded system and eases the cross-compilation process.<br />
<br />
The resulting root filesystem is mounted read-only, but other filesystems can be mounted read/write for persistence. Although user accounts can be created, in practice almost everything is done as root. Buildroot uses no package manager. Instead, package selection is managed through '''make menuconfig'''.<br />
<br />
=== Nerves Erlang/OTP ===<br />
* Home site: http://nerves-project.org/<br />
* Source repository: https://github.com/nerves-project/bbone-erlang-buildroot<br />
* Erlang project site: http://www.erlang.org/<br />
Erlang is a programming language used to build massively scalable soft realtime systems with high availability requirements (5-9’s). Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang’s runtime system has built-in support for concurrency, distribution and fault tolerance.<br />
<br />
OTP is a set of Erlang libraries and design principles providing middle-ware to develop these systems. It includes its own distributed database, applications to interface towards other languages, debugging and release handling tools.<br />
<br />
The Nerves project provides an embedded Linux-based environment for running Erlang and an easy-to-use API to access common I/O interfaces, based on '''Buildroot''' (see above). If you are interested in running an Erlang node on a low power ARM-based board such as BeagleBone, this project can get you started.<br />
<br />
= Board recovery =<br />
* See [http://elinux.org/BeagleBoardRecovery#USB_recovery BeagleBoardRecovery] ''--- (*) Check applicability''<br />
<br />
= Software Development =<br />
Software development on the BeagleBone is normally no different to any other Linux platform, and typically varies with language and with the IDE used, if any. This section deals only with development issues that are specific to BeagleBone, or mostly so.<br />
<br />
=== Cloud9 IDE and Bonescript ===<br />
''..... description here .....''<br />
* Source repository: https://github.com/jadonk/bonescript<br />
* Language documentation: http://nodejs.org/<br />
<br />
=== BeagleBone JTAG Debugging ===<br />
''..... description here .....''<br />
<br />
===Using Netbeans to remotely compile and debug C/C++===<br />
<br />
When developing c/c++ on a linux desktop, a toolchain is available for cross-compiling the code for arm. However no such toolchain is readily available for windows. Netbeans can be used to write the code on your desktop, save it in a location accessible to the beagle, and then automatically compile it on the beagle itself using ssh and the built in compiler on the beaglebone's OS.<br />
<br />
Netbeans can also use GDB for remote debugging over ssh.<br />
<br />
Requirements:<br />
<br />
* Set up a samba / smb network share through which code can be shared between both desktop and beagle<br />
* Give netbeans the SSh login details of the beagle<br />
* Give netbeans the path mapping so it can translate between the desktop code folder and beagle code folder<br />
* Setup only takes a few minutes.<br />
<br />
====More info====<br />
<br />
* Download Netbeans (Windows/Linux/OS-X/Solaris): http://www.netbeans.org/<br />
* Example tutorial on setting this up: http://mechomaniac.com/BeagleboardDevelopmentWithNetbeans<br />
<br />
<br />
= Kernel =<br />
<br />
=== Getting the Right Kernel ===<br />
The modern BeagleBone kernels are Maintained by Koen Kooi and are available on the 3.8 branch at https://github.com/beagleboard/kernel/tree/3.8 . This repo contains a set of patches and a script which downloads a mainline kernel and then patches it appropriately. Exact steps for building it are in the README.<br />
<br />
=== Device Tree ===<br />
The 3.5 and newer BeagleBone kernels make use of [[Device_Trees|Device Trees]]. A Device Tree is a text file which describes the layout of a machine, commonly the combination of a system-on-chip (SoC) and a board, so that the kernel can know at what addresses and on which buses hardware is located. The BeagleBone kernels make use of an extension called [[Capemgr|Capemgr]] which allows dynamic loading and unloading of device tree fragments both at compile time and from userspace post-boot.<br />
Learning about the Device Tree is very essential, if you wish to be able to manipulate pins and be able to use them as inputs/outputs. There is a [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 short guide to it here] (part-way down the page). In a nutshell, the device tree can be manipulated by creating a text 'fragment' file that can be converted into a .dtbo file using a program called dtc which is already installed on the BeagleBone Black. The .dtbo file can then be installed and uninstalled as desired. The procedures to install and uninstall are at that link:<br />
<br />
<tt>echo cape-bone-name > $SLOTS</tt> to install, and<br />
<br />
<br />
<tt>echo -<slotnum> > $SLOTS</tt> to uninstall,<br />
but read through the web page and comments section first to see what $SLOT is set to).<br />
<br />
<br />
<br />
= FAQ =<br />
<br />
For BeagleBoard frequently asked questions (FAQ) see [[BeagleBoardFAQ|community FAQ]] and "official" [http://beagleboard.org/support/faq BeagleBoard.org FAQ].<br />
<br />
= Links =<br />
== Home site and Community ==<br />
* [http://beagleboard.org/ beagleboard.org] -- home for BeagleBoard and BeagleBone products<br />
* [http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black] -- manufacturer's page for the second BeagleBone board<br />
* irc://irc.freenode.net/#beagle -- official combined IRC channel<br />
* [http://beagleboard.org/discuss Google Groups forums/mailing list] -- [https://groups.google.com/forum/?fromgroups#!forum/beagleboard English], [http://groups.google.com/group/pandabeagle-jp Japan], [http://groups.google.com/group/beagleboard-brasil Brasil], [https://groups.google.com/group/beagle-board-turkiye Turkey]<br />
* [http://beagleboard.org/project BeagleBoard and BeagleBone projects list]<br />
* [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] and its [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page]<br />
* [http://www.adafruit.com/blog/category/beaglebone/ BeagleBone articles at Adafruit blog] -- products, projects and tutorials<br />
* Use [http://www.google.de/ Google] to search beagleboard.org (including [http://www.beagleboard.org/irclogs/ IRC logs]) using ''site:beagleboard.org <search term>''<br />
* [https://www.linux.com/news/embedded-mobile/mobile-linux/715298-45-beaglebone-black-keeps-eyes-on-raspberry-pi Linux.com report on BeagleBone Black] -- with words from beagleBoard.org's cofounder Jason Kridner<br />
* [https://github.com/selsinork/beaglebone-black-pinmux github.com/selsinork/beaglebone-black-pinmux] -- pinmux data for BeagleBone Black, including extraction scripts<br />
* [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 Element 14 knode blog: Working with the PRU-ICSS] -- detailed tutorial on starting with the PRU on BBB<br />
<br />
== Tutorials and Videos ==<br />
* [http://beagleboard.org/static/bonescript/bone101/index.html ''BeagleBone: BeagleBoard-101 Intro''] -- slides (turn off Javascript for single page)<br />
* [http://www.youtube.com/watch?v=EEnOWR-GXjk ''BeagleBone Intro''], video by Jason Kridner, Texas Instruments<br />
* [http://www.youtube.com/watch?v=Y0uqRVxismQ ''How-To: Get Started with the BeagleBone''], video by Matt Richardson, MakeMagazine<br />
* [http://www.youtube.com/watch?v=z6b4zlh0IrE ''The Beaglebone - Unboxing, Introduction Tutorial and First Example''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=vFv_-ykLppo ''Beaglebone: C/C++ Programming Introduction for ARM Embedded Linux Development using Eclipse''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=SaIpz00lE84 ''Beaglebone: GPIO Programming on ARM Embedded Linux''], video by Derek Molloy, DCU/EE<br />
* [https://gist.github.com/4013192 ''C code for GPIO polling''], sample code by Andrew Montag<br />
* [http://borderhack.com/?p=1062 First steps with the Beaglebone], introductory HOWTO by octavio at borderhack<br />
* [http://learn.adafruit.com/beaglebone Adafruit Learning System - BeagleBone] -- web page<br />
<br />
== Manuals and resources ==<br />
* [http://beagleboard.org/static/beaglebone/a3/Docs/Hardware/BONE_SRM.pdf BeagleBone System Reference Manual (rev. A3_1.0)]<br />
* [http://www.ti.com/am335x Texas Instruments - Sitara AM335x ARM Cortex-A8 Microprocessor overview]<br />
* [http://www.ti.com/product/am3359 Texas Instruments - AM3359 Sitara ARM Cortex-A8 Microprocessor full documentation]<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARM/ARMv7-AR Architecture] -- ARM Cortex-A8 architecture overview<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8 Technical Reference Manual r2p1]<br />
* [http://www.arm.com/support/university/development-platforms/cortex-a8-development-platforms.php ARM Cortex-A Development Platforms] -- ARM page on Beagle boards<br />
* [http://www.ti.com/product/tps65217b TI TPS65217 Power Management IC], [http://www.ti.com/lit/ds/symlink/tps65217.pdf TPS65217 PMIC datasheet]<br />
* [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H Hi-Speed Dual USB UART/FIFO IC overview], [http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf FT2232H datasheet]<br />
* [http://www.linux-usb.org/gadget/index.html Linux-USB Gadget API Framework] and [http://www.linux-usb.org/gadget/h2-otg.html USB OTG], and [http://forums.gentoo.org/viewtopic-t-843255.html kernel config] -- Ethernet-over-USB<br />
* [https://docs.google.com/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub Beaglebone and the 3.8 Kernel] Details about the 3.8 Kernel, its use of DT and the capemanager.<br />
<br />
== Translations ==<br />
* 한국어:[[KR:BeagleBone]]<br />
<br />
== Errata ==<br />
<br />
= Subpages =<br />
http://elinux.org/BeagleBone_Usb_Networking</div>Pantohttps://elinux.org/index.php?title=Beagleboard:BeagleBone_Black_Capes&diff=253496Beagleboard:BeagleBone Black Capes2013-05-17T11:58:31Z<p>Panto: LCD3 + Camera cape</p>
<hr />
<div>* The BeagleBone Black essentially is an original BeagleBone with three virtual capes:<br />
** Memory Cape for on board eMMC<br />
** HDMI Cape for on board video<br />
** Audio Cape for audio through HDMI<br />
<br />
= BeagleBone Black Reserved Signals =<br />
* When adding a Cape to the BeagleBone Black, if the same signals are used for the on board virtual capes, then only one of these devices can be supported at a time.<br />
** MMC signals P8[25:20] and P8[6:3]<br />
** LCD signals P8[46:27]<br />
** AUDIO signals P9[31] and P9[29:28]<br />
<br />
<br />
[[File:Bbb-cape-pinout.jpg]]<br />
<br />
= Supported Capes =<br />
* Each cape is listed with a column to indicate if the cape uses any of the same signals as the virtual cape for each.<br />
* '''Mechanical''' means that the cape has been physcially plugged into a BeagleBone Black and has no clearance issues.<br />
* '''Hardware Support''' means that the cape will electrically work with the BeagleBone Black.<br />
* '''Software Support''' means that the cape is supported in the bootable linux distribution image that ships with the BeagleBone Black.<br />
<br><br />
<br />
{|border="3"<br />
|+<br />
!Board||Mechanical||P9-Battery||LCD P8[46:27]||EMMC P8[25:20] P8[6:3]||AUDIO signals P9[31] and P9[29:28]||Hardware Support||Software Support||Support Planned||Notes<br />
|- style="background:green"<br />
|Breakout Cape||PASS||NC||PASS||PASS||PASS||YES||NONE REQUIRED||APPROVED||<br />
|- style="background:green"<br />
|Breadboard Cape||PASS||NC||PASS||PASS||PASS||YES||NONE REQUIRED||APPROVED||<br />
|- style="background:green"<br />
|Battery Cape||PASS||NC||PASS||PASS||PASS||YES||NONE REQUIRED||APPROVED||<br />
|- style="background:yellow"<br />
|RS-232 Cape||PASS||NC||PASS||PASS||PASS||YES||NO||YES||<br />
|- style="background:yellow"<br />
|RS-485 Cape||PASS||NC||PASS||USED||PASS||YES||NO||YES||<br />
|- style="background:yellow"<br />
|CAN Bus Cape||PASS||NC||PASS||PASS||PASS||YES||NO||YES||<br />
|- style="background:yellow"<br />
|Weather Cape||PASS||NC||PASS||PASS||PASS||YES||NO||YES||<br />
|- style="background:yellow"<br />
|Audio Cape||PASS||NC||PASS||PASS||USED||YES||NO||YES||<br />
|- style="background:yellow"<br />
|LCD3 Cape||PASS||NC||USED||PASS||PASS||YES||YES||YES||Rev A1 uses TPS backlight, so can't work, Rev A2 works but reports of picture being 'fuzzy'<br />
|- style="background:yellow"<br />
|LCD4 Cape||PASS||NC||USED||PASS||PASS||YES||NO||YES||<br />
|- style="background:yellow"<br />
|LCD7 Cape||PASS||NC||USED||PASS||PASS||YES||NO||YES||<br />
|- style="background:yellow"<br />
|3.1MP Camera Cape||PASS||NC||PASS||USED||PASS||YES||YES||YES||Works even more stable than on the white (DRAM timings on white?)<br />
|- style="background:#30FFFF"<br />
|Memory Cape||PASS||NC||USED||USED||PASS||YES||NO||NO||This cape is sold for development purposes only<br />
|- style="background:red"<br />
|HDMI Cape||PASS||NC||USED||USED||USED||YES||NO||NO||<br />
|- style="background:red"<br />
|DVI-D Cape||PASS||NC||USED||PASS||PASS||YES||NO||NO||<br />
|- style="background:red"<br />
|DVI-D w/Audio Cape||PASS||NC||USED||PASS||PASS||YES||NO||NO||<br />
|- style="background:red"<br />
|TiWi-5E Cape||PASS||NC||USED||USED||USED||NO||NO||NO||<br />
|- style="background:red"<br />
|TiWi-BLE Cape||PASS||NC||USED||USED||USED||NO||NO||NO||<br />
|}</div>Pantohttps://elinux.org/index.php?title=BeagleBoard/GSoC/Ideas-2016&diff=244772BeagleBoard/GSoC/Ideas-20162013-04-22T15:15:41Z<p>Panto: Added myself in the mentors list</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
[[Category: BeagleBoard]]<br />
[[Category: GSoC]]<br />
<br />
__TOC__<br />
<br />
=Welcome!=<br />
BeagleBoard.org hopes to be accepted as a mentoring organization in the [[BeagleBoard/GSoC|Google Summer of Code]] for 2013! Below, we've collected project ideas for the 2013 GSoC.<br />
<br />
==Background==<br />
BeagleBoard.org is a volunteer organization that seeks to advance the state of open-source software on [http://en.wikipedia.org/wiki/Open-source_hardware open-source hardware] platforms capable of running high-level languages and operating systems (primarily Linux) in embedded environments. Born from taking mobile phone processors and putting them on low-cost boards to build affordable desktop computers, BeagleBoard.org has evolved to focus on the needs of the "maker" community with greater focus on the I/O needed for controlling motors and reading sensors to build things like robots, 3d printers, flying drones, in-car computer systems and much more. Past BeagleBoard.org GSoC projects included [[BeagleBoard/GSoC/2010_Projects/C6Run|an RPC framework for heterogeneous processor communication]], [[BeagleBoard/GSoC/2010_Projects/USBSniffer|a transparent USB packet sniffer]], [[BeagleBoard/GSoC/2010_Projects/XBMC|ARM optimizations for XBMC]], [[BeagleBoard/GSoC/2010_Projects/FFTW|ARM optimizations for FFTs]], [[BeagleBoard/GSoC/2010_Projects/Pulse_Width_Modulation|make-shift pulse-width-modulation]] and [[BeagleBoard/GSoC/2010_Projects/OpenCV|RPC optimizations for OpenCV]]. BeagleBoard.org has benefited from sponsorship from Texas Instruments, CircuitCo, Digi-Key and others, but avoids any dependence on that sponsorship for sustaining the effort. The project has evolved over the past few years with over 100,000 boards in circulation with developers worldwide and strong roots in the Linaro, Yocto Project, Angstrom Distribution and Linux communities---and support for running most major Linux distributions including Ubuntu, Android, Fedora, Debian, ArchLinux, Gentoo, Buildroot and many more.<br />
<br />
BeagleBoard was inspiration for Raspberry Pi[http://www.linuxuser.co.uk/features/raspberry-pi-interview-eban-upton-reveals-all] and will be more affordable at the time GSoC launches[http://beagleboard.org/unzipped], but is more than a throw-away computer. It is true open hardware, exposing users to the broader world of electronics, demystifying computers and fostering an environment of clones that have changed the industry.<br />
<br />
Students will be expected to demonstrate an understanding of cross-compiling before being accepted, but support for demonstration is available through the IRC channel that typically has approximately 150 online chatters logged on at any time, most with sufficient experience to explain the process.<br />
<br />
'''''<span style="color:red">Every accepted student will be sent a BeagleBone Black before the first week of coding for testing their project.</span>'''''<br />
<br />
Additional hardware will be provided depending on need and value.<br />
<br />
For more information, check out http://beagleboard.org and http://beagleboard.org/brief.<br />
<br />
==Students looking for ideas==<br />
Student proposals can encompass projects inspired from the following list of ideas or can include personal project ideas. Previous Google Summer of Code projects show that the key to success is being passionate about your project, so propose something that is extremely interesting to you, even if it is not on this list. We will be glad to help students develop ideas into projects via [http://webchat.freenode.net/?channels=beagle the BeagleBoard IRC] or [http://groups.google.com/group/beagleboard the BeagleBoard mailing list]. There are many potential project ideas and we will match students to projects based on their interests and help scope the proposals to something that can be completed in the Summer of Code timeframe.<br />
<br />
There are more than 300 existing projects listed at http://beagleboard.org/project. If you are interested in one of the projects listed on the BeagleBoard.org projects page, talk with the project members to see if there are any aspects of their projects that can be used to create a GSoC project. There are also several ideas on the[[ECE497_Project_Ideas|ECE497 class project idea list]]. You can also check out [[BeagleBoard/GSoC/Ideas-2012|last year's idea page]].<br />
<br />
==Mentors wondering where to help==<br />
Please start by registering your ideas for student projects below by following the template provided with the existing ideas. Furthermore, scroll down to the bottom and give everyone a bit of information about your expertise and availability by adding yourself to the table. Jason will make final approvals for mentor assignments based on if we first get accepted as a mentoring organization and best matching mentor skill sets with student project ideas deemed valuable to the community.<br />
<br />
==General requirements==<br />
All projects have the following basic requirements:<br />
# Once accepted, the project must be registered on http://beagleboard.org/project.<br />
# All newly generated materials must be released under an [http://www.opensource.org/licenses open source license].<br />
# Individual students shall retain copyright on their works.<br />
# Source code generated during the project must be released on github.com (to be cloned to github.com/beagleboard on successful completion).<br />
# The registration on http://beagleboard.org/project must include an RSS feed with project announcements and updates at every milestone. Sources for the RSS feed should be blogger.com, wordpress.com, or some other established blog-hosting service with known reliability.<br />
# To help you to break your project down into manageable chunks and also to help the project's mentors to better support your efforts, weekly project status reports should be e-mailed to the project's mentors and the organization administrator (Jason Kridner). Each status report should outline:<br />
## what was accomplished that week, <br />
## any issues that prevented that week's goals from being completed and<br />
## your goals for the next week.<br />
# Students will provide two recorded audio/video presentations uploaded to youtube or vimeo (screencasts are appropriate), one near the beginning of the project summarizing their project goals and another in the wrap-up phase to summarize their accomplishments. Examples can be found on http://beagleboard.org/gsoc.<br />
# Students will demonstrate their ability to cross-compile and utilize version control software by creating a "Hello World" application and generating a pull request to https://github.com/jadonk/gsoc-application/tree/master/ExampleEntryJasonKridner. For assistance, please visit http://beagleboard.org/chat or utilize the beagleboard-gsoc Google Group. The "Hello World" application must print your name and the date out in an ARM Linux environment. Freely available emulators may be used to test your application or you can ask anyone on the chat or mailing list to help you test.<br />
# All projects will produce reusable software components and will not be "what–I-built-over-my-summer-vacation" projects. Including a hardware component is welcome, but the project *deliverable* will be software that may be utilized by a wide audience of the BeagleBoard.org community.<br />
<br />
=Ideas=<br />
There are several areas needing contributions:<br><br />
'''Kernel''': Improving the state of the Linux kernel including improved ARM/OMAP/Sitara platform support, simplifying the development of add-on hardware for embedded systems and exchanging hardware connectivity information with userspace.<br><br />
'''Secondary processor support (RPC/gcc/etc.)''': Enabling usage of DSPs, PRUs, FPGAs, Cortex-M3s, Arduinos, MSP430 launchpads and other attached processing platforms.<br><br />
'''Scripting libraries and web interfaces''': Improving the Bonescript JavaScript library, web-based interface libraries, examples or alternatives in other languages.<br><br />
'''Frameworks for open-hardware projects''': Consolidating support for simplified home manufacturing (CNC, 3D printers, laser cutters, pick-and-place machines, etc.), drones/bots (ROS, IMU, video streaming, etc.) or other common tasks.<br><br />
'''Optimizations to existing userspace applications/libraries''': Optimizations to applications and libraries like XBMC to make them run better on resource constrained environments or to take advantage of more specialized processing elements.<br><br />
<br />
==Upstreaming Beagleboard.org Kernel Patches==<br />
The BeagleBone currently relies on a number of out-of-tree kernel patches in order to boot. These patches are maintained by Koen Kooi (CircuitCo) and come from many sources, including TI employees and various mailing lists. Getting more of these patches upstream would make it easier to boot a BeagleBone and also make use of a BeagleBone easier for users and kernel developers who need to track upstream kernel changes, or who otherwise need to be closer to the bleeding edge of Linux kernel development. The current patch set is [https://github.com/beagleboard/kernel/tree/3.8 maintained at github] and contains scripts to easily patch an upstream kernel. The scripts in this repository are used to build the BeagleBoard.org kernels which ship with the Angstrom SD card images.<br />
<br><br />
<br />
''Goal:'' Push as many patches as possible to [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git Linus's mainline kernel tree] via the appropriate [http://git.kernel.org/cgit/ staging kernels] for the subsystems involved.<br><br />
''Existing Project:'' [http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git The Mainline Linux Kernel], [http://github.com/beagleboard/kernel/tree/3.8 patches needing to be pushed]<br><br />
''Hardware Skills:'' Able to read schematics, understand basic digital logic and monitor logic-level digital signals.<br><br />
''Software Skills:'' Able to write software in C, create patches to the Linux kernel and perform cross-compilation and testing.<br><br />
''Possible mentors:'' Matt Porter, Matt Ranostay, Koen Kooi, Alan Ott<br><br />
<br />
==Library of Arduino-compatible functions for Linux==<br />
For doing basic physical computing tasks, the most popular and understood API is clearly the Arduino API based off of Wiring. This project would utilize the Linux interfaces provided to userspace applications for the hardware functions.<br />
<br />
''Goal:'' Provide an implementation of most major Arduino functions for Linux userspace and verify on BeagleBoard-xM and BeagleBone Black.<br><br />
''Existing Project:'' [https://github.com/prpplague/Energia/tree/userspace Engeria userspace Linux fork]<br><br />
''Hardware Skills:'' Understanding of serial ports and busses and how to use a scope<br><br />
''Software Skills:'' C/C++ and Linux kernel interfaces<br><br />
''Possible mentors:'' Jason Kridner, Dave Anders<br />
<br />
==IIO debugging tools==<br />
Quick background: IIO is the new way of doing sensors but being a newer interface, it lacks tools<br />
for debugging. This project is to produce sometools to debug drivers.<br />
There are several ways this project can happen:<br><br />
1. We can implement userland tools that read IIO data similar to the evtest tool. <br><br />
2. We can implement a event handler for the IIO driver. This way existing tools and code can be used. There was references from another mailing list (probally LKML) talking about this.<br><br />
<br />
''Goal:'' Userspace application similar to evtest that captures debug events and instrumented IIO driver code to produce those events.<br><br />
''Existing Project:'' [http://github.com/beagleboard/kernel/tree/3.8 patched kernel with IIO driver]<br><br />
''Hardware Skills:'' None.<br><br />
''Software Skills:''C coding (1), (2) requires kernel coding<br><br />
''Possible mentors:'' Hunyue Yau<br><br />
<br />
==node-webkit based cross-platform getting-started app==<br />
Newbies often have a difficult time following directions that could be replaced by an application. The steps to download and install an application is something that even newbies can typically manage. This avoid issues like having bad browsers or not having typical development tools like 'ssh'. This is a common problem across all embedded Linux platforms and node-webkit provides a good solution for making it cross-platform.<br />
<br />
''Features'':<br />
* Provide instructions for getting up-and-running with the board based (incorporate the Getting Started Guide)<br />
* Automatically discover boards on the LAN using mDNS and predetermined IP addresses<br />
* Act as a browser to interact with the board, including performing SSH and SCP<br />
* Discover the latest SD card images from multiple distributions<br />
* Bootload the board with a USB-mass-storage-class application<br />
* Program SD cards through the board or a USB adapter<br />
* Program on-board eMMC<br />
<br />
''Goal:'' Provide a downloadable application for Linux, Windows and Mac that enables unexperienced users to get going enough to start learning about using Linux and the embedded I/O.<br><br />
''Existing Project:'' [http://github.com/jadonk/beaglebone-getting-started/tree/node-webkit-app Incomplete node webkit app for the BeagleBone Getting Started guide]<br><br />
''Hardware Skills:'' N/A<br><br />
''Software Skills:'' Able to write software in JavaScript and work with node.js modules<br><br />
''Possible mentors:'' Jason Kridner<br><br />
<br />
==OpenEmbedded support for npm packages for node.js==<br />
Using npm for packages works well for grabbing most recent versions of things, but it doesn't work well to make sure you are getting tested versions built for your platform, it doesn't integrate with the native package manager, it is a huge security hole and it generally is a mess for distributions. OpenEmbedded provides a great vehicle for creating distributions that can professionally support deploying node.js packages rather than relying on a tool that is really only geared for prototyping.<br />
<br />
* Create a bitbake 'npm' class<br />
* Cross-build native code using node-waf, node-gyp and nw-gyp<br />
* Create dependencies using package.json<br />
<br />
''Goal:'' Bitbake 'npm' class and recipes for tools like 'node-serialport', 'express', 'socket.io' and more.<br><br />
''Existing Project:'' http://www.openembedded.org/wiki/BitBake, https://npmjs.org/<br><br />
''Hardware Skills:'' N/A<br><br />
''Software Skills:'' Familiarity with C++, JavaScript and Python. Basic understanding of build systems.<br><br />
''Possible mentors:'' Jason Kridner<br><br />
<br />
==Bonescript web pages with live-running examples and documentation==<br />
The Bonescript JavaScript library enables hardware control from web pages using socket.io for remote procedure calls. This provides an excellent environment for teaching how to wire-up sensors and controls and rapidly prototype user interfaces. Numerous examples exist on the web, but consolidation and testing are required to make them usable by novices.<br />
<br />
''Goal:'' Dozens of web pages with executable script that demonstrate how to connect up sensor and actuator hardware<br><br />
''Existing Projects:'' https://github.com/jadonk/bonescript, [https://github.com/jadonk/beaglebone-getting-started/blob/add-bone101/Docs/demo_bmp085.html BMP085 Bonescript example], [http://elinux.org/Category:ECE497 ECE497 examples]<br><br />
''Hardware Skills:'' Basic knowledge of digital circuits.<br><br />
''Software Skills:'' JavaScript and some familiarity with Linux<br><br />
''Possible mentors:'' Jason Kridner<br><br />
<br />
==Integrate support libraries into Angstrom==<br />
Many BeagleBone and embedded Linux support libraries in various programming languages exist as projects that aren't included in the distro shipped with BeagleBoard and BeagleBone. These need bitbake recipes added to meta-beagleboard such that they can be easily downloaded and incorporated into the shipping distro.<br />
<br />
* Python PyBBIO<br />
* Ruby beaglebone-ruby<br />
* Perl bonelib<br />
<br />
''Goal:'' PyBBIO, beaglebone-ruby and bonelib included in the distro shipping with BeagleBone<br><br />
''Existing Project:'' [https://github.com/alexanderhiam/PyBBIO PyBBIO], [https://github.com/ryanfaerman/beaglebone-ruby beaglebone-ruby], [http://sourceforge.net/p/bonelib/wiki/Home/ bonelib]<br><br />
''Hardware Skills:'' Able to wire up simple hardware, like LEDs<br><br />
''Software Skills:'' Familiarity with Python, Ruby, Perl, embedded Linux and build systems.<br><br />
''Possible mentors:'' Jason Kridner<br><br />
<br />
==SYSFS entries for IIO and PWM==<br />
IIO and PWM provide mechanisms for sampling touch screens, performing general purpose A/D conversions to read sensors, generating voltage levels and driving motors. The Linux kernel SYSFS mechanism provides a simplified mechanism for userspace applications to set parameters and read/write data values.<br />
<br />
''Goal:'' Push patches to Linux mainline providing SYSFS entries for IIO and PWM useful for building a demo robot<br><br />
''Existing project:'' http://github.com/beagleboard/kernel<br><br />
''Hardware skills:'' Able to read schematics, understand basic digital logic and monitor logic-level digital signals<br><br />
''Software skills:'' Able to write software in C, create patches to the Linux kernel and perform cross-compilation<br><br />
''Possible mentors:'' Laine Walker-Avina<br><br />
<br />
==Using BeagleBone PRUs to control CNC and 3D printer stepper motor Drivers==<br />
This project is to write code for the PRU (realtime processors on the AM335x used in the Beagle Bone) so that it can generate multiple step and direction outputs based on a queue of commands in real time. This needs to be done in real time so the acceleration and coordination of multiple stepper motors can be controlled and coordinated. A step/dir signal is commonly used in a lot of stepper motor drivers. While it is possible to generate stepper phase information from the PRU, it is also undesireable from a testing stand point. An example of a reason for doing this is controlling the X/Y directions of the head of a 3D printer so that it can generate precise curves. While similar code has been done, it is not done in a real time fashion so it is difficult to add coordination between motors and/or maintain a known acceleration.<p><br />
<br />
The result of this code should be something interfaceable to a control system like the non realtime portions of the Linux CNC project (formerly the EMC project). But as a demo, this same code should also demonstrate a node.js functionality such as a "G-code" interpreter. This node.js portion can be considered a second project due to the different skill sets required and ideally this project would be split between two GSoC students. One project would be working mostly on PRU assembly with integration into the Linux kernel. The other project would be working mostly on userspace JavaScript in node.js and C++ code for anything needing optimization or low-level kernel access. Mentors would heavily assist on defining the right interfaces between the two programming environments.<br />
<br />
''Goal'': create code to use the AM335x PRUs to generate multiple step and direction outputs for reprap and CNC applications<br><br />
''Existing projects'': [http://github.com/beagleboard/am335x_pru_package Pru Documentation], [https://www.kernel.org/doc/htmldocs/uio-howto.html UIO Driver documentation]<br><br />
''Hardware skills:'' Able to read schematics, understand basic digital logic and monitor logic-level digital signals<br><br />
''Software skills:'' Assembly and C coding. Node.js for g-code interpretation<br><br />
''Possible mentors:'' Tom King, Jason Kridner, Hunyue Yau, Laine Walker-Avina<br><br />
<br />
==PRU upstreaming==<br />
Remove HWMOD dependency requirement for PRU along with adding device tree bindings so it can be upstreamed into Linus's tree.<br />
<br />
''Goal'': Push patches to Linux mainline providing support for the AM335x PRU<br><br />
''Existing project'': https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/<br><br />
''Hardware skills:'' Able to read schematics, understand basic digital logic and monitor logic-level digital signals<br><br />
''Software skills:'' Able to write software in C, understand existing patches with PRU support, create patches to the Linux kernel and perform cross-compilation<br><br />
''Possible mentors:'' Start with Jason Kridner and Matt Porter, but we'll get some others involved<br><br />
<br />
==PRU firmware loader==<br />
Allow "firmware" which are really binary PRU applications to be loaded directly on PRU cores and executed using the request_firmware() functionality of the Linux Kernel. This should also be Cape Manager to load PRU cape specific applications.<br />
<br />
Ideal workflow:<br />
<br />
* Cape detected that uses the PRU<br />
** Setup pinmux <br />
* Find the respective firmware file for PRU core (or both cores) /lib/firmware/cape_A020_pru0.bin<br />
* Load onto PRU and begin execution.<br />
<br />
''Goal'': Push patches to Linux mainline providing support to loading firmware on PRU cores and executing<br><br />
''Existing project'': https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/<br><br />
''Hardware skills:'' Able to read schematics, understand basic digital logic and monitor logic-level digital signals<br><br />
''Software skills:'' Able to write software in C, create patches to the Linux kernel and perform cross-compilation<br><br />
''Possible mentors:'' Matt Ranostay, Matt Porter<br><br />
<br />
==BotSpeak virtual machine for Bonescript and PRU==<br />
Based on Chris Roger's BotSpeak work to provide a virtual machine for typical Arduino functions that can be accessed from LabView, build a virtual machine to enable PRU programming from Bonescript. The virtual machine is a simple interpreter that loops over the command to perform delay, pinMode, attachInterrupt, analogRead, analogWrite, digitalRead and digitalWrite functions. A simple conditional goto is resolved at load-time and a minimal set of variables are available for use. Support will need to be included for simple expressions, but the pre-parser can break them down ahead of time. Introspection in JavaScript should be used to convert a minimal function definition into source to be fed to a parser and passed to the interpreter on the PRU via shared memory.<br />
<br />
''Goal'': Implement a BotSpeak interpreter that off-loads hard real-time tasks from Bonescript onto the PRU and include that in the Bonescript project<br><br />
''Existing projects'': http://github.com/beagleboard/am335x_pru_package, http://github.com/jadonk/bonescript, [https://sites.google.com/site/botspeak/the-language Chris' language definition]<br><br />
''Hardware skills:'' Able to read schematics, understand basic digital logic and monitor logic-level digital signals<br><br />
''Software skills:'' Able to write software in JavaScript and assembly<br><br />
''Possible mentors:'' Chris Rogers, Jason Kridner, Tom King<br><br />
<br />
==Android-based boot host==<br />
Boot your BeagleBone using your Android phone. Combined with the Android Accessory Development Kit code available for BeagleBone and an application to help code/run small applications, this gives you a complete development environment that is easy to distribute to other users.<br />
<br />
On a phone/tablet that supports USB host mode (which sadly not all modern devices do), the phone/tablet would provide the early boot loader and kernel code to the Bone using libusb in host mode. After booting the kernel the Bone could switch to USB host mode (the ADK setup) to e.g. load the filesystem and/or communicate with an App on the phone side.<br />
<br />
Another way that will work on all certified Android devices is to have the boot loader already on the sdcard and to run the boot loader in USB host mode with the Android device is USB device mode. The bootloader would then get only the kernel and filesystem from the Android device.<br />
<br />
Besides using Android to provide a kernel/filesystem to the Bone, one could also use it as an input/display device, relaying touchscreen events to the Bone and displaying the Bone GUI output on the phone/tablet screen.<br />
<br />
''Goal:'' Download a Linux image from the web and boot a BeagleBone using it over USB<br><br />
''Existing Project:'' https://github.com/SpecLad/libusb-android, [https://code.google.com/p/rowboat/wiki/AccessoryDevKit BeagleBone implementation of Android Accessory Development Toolkit]<br><br />
''Hardware Skills:'' Some knowledge of USB<br><br />
''Software Skills:'' Java, C and familiarity with Android<br><br />
''Possible mentors:'' Start with Jason Kridner, but we'll get some others involved<br><br />
<br />
==Android under Angstrom==<br />
Some people want to play Angry Birds or run other Android apps on their BeagleBoard/BeagleBone. Of course, you could use the Rowboat Android project as-is, but then you'd have to give up all of their typical Linux/X11 applications available in Angstrom. This project would use an Android-enabled kernel and a combination of both Angstrom and Android file systems. The input and display methods required for Android would need to be adjusted to run in on a virtual terminal and chroot/chvt would be used to invoke the various user space windows.<br />
<br />
This has essentially been done once as part of [https://www.alwaysinnovating.com/beagleboard/ Always Innovating's Super-Jumbo] demo running Ubuntu, Angstrom, ChromeOS and Android simultaneously. The fundamental challenge is getting it reproducible and integrated into the OpenEmbedded build system for Angstrom and then starting to minimize the wasted file space by sharing libraries. Eventually, even making Android applications run in a window is desired.<br />
<br />
''Goal'': Run Android applications under Angstrom and toggle back-and-forth using CTRL-ALT-Fn key presses.<br><br />
''Existing projects'': http://arowboat.org, http://www.angstrom-distribution.org<br><br />
''Hardware skills:'' Minimal<br><br />
''Software skills:'' Able to write software in C and Java, experience with X11 and Android<br><br />
''Possible mentors:'' Hunyue Yau<br><br />
<br />
==Library of Arduino-compatible functions for StarterWare==<br />
This would be an implementation of Arduino utilizing the BeagleBone Black and the StarterWare O/S independent library for accessing the hardware.<br />
<br />
''Goal:'' Utilize the Energia fork of Arduino to push support for BeagleBone and BeagleBone Black<br><br />
''Existing Project:'' [https://github.com/energia/Energia Energia], [http://processors.wiki.ti.com/index.php/StarterWare StarterWare]<br><br />
''Hardware Skills:'' Yes<br><br />
''Software Skills:'' C/C++<br><br />
''Possible mentors:'' Jason Kridner (others can be referred if there are interested students)<br />
<br />
==Previous ideas==<br />
* [[BeagleBoard/GSoC/Ideas-2012]]<br />
<br />
=Mentors=<br />
{| border="1"<br />
! Name<br />
! IRC nickname<br />
! Native language<br />
! Other languages<br />
! Timezone<br />
! Software help<br />
! Hardware help<br />
! Focus projects<br />
|-<br />
| Jason Kridner<br />
| jkridner<br />
| English<br />
| -<br />
| US Eastern<br />
| JavaScript, C, u-boot<br />
| wiring, timing diagrams, basic debug<br />
| Bonescript development<br />
|-<br />
| Vladimir Pantelic<br />
| av500<br />
| German<br />
| English, Serbian<br />
| CET<br />
| Experienced on most areas of Embedded Linux, Multimedia<br />
| Schematic Review + Design<br />
| Embedded Linux, Linux Multimedia, Android<br />
|-<br />
| Matt Ranostay<br />
| mranostay<br />
| English (U.S. Midwestern Dialect)<br />
| None<br />
| US Pacific Time<br />
| Experienced on most areas of Embedded Linux or Systems<br />
| Schematic Review + Design<br />
| ARM/AM335x Kernel Development<br />
|-<br />
| Philip Balister<br />
| Crofton<br />
| -<br />
| -<br />
| -<br />
| -<br />
| -<br />
| -<br />
|-<br />
| Russ Dill<br />
| Russ<br />
| English<br />
| None<br />
| US Pacific Time<br />
| Experienced on most areas of Embedded Linux or Systems<br />
| Schematic Review + Design<br />
| ARM/AM335x Kernel Development<br />
|-<br />
| Matt Porter<br />
| mdp<br />
| English (U.S. Midwestern Dialect)<br />
| None<br />
| US Eastern<br />
| Embedded Linux Firmware/Kernel and system level design. Designing Linux drivers to make the best use of existing infrastructure.<br />
| Schematic Review + Design<br />
| ARM/AM335x/OMAP/PRU U-Boot and Kernel/Driver Development<br />
|-<br />
| Koen Kooi<br />
| koen<br />
| Dutch<br />
| English<br />
| CET<br />
| Experienced on most areas of Embedded Linux, buildsystems<br />
| -<br />
| -<br />
|-<br />
| Tom King<br />
| ka6sox<br />
| English<br />
| None<br />
| US Pacific Time<br />
| Experienced on most areas of Embedded Linux or Systems<br />
| Schematic Review + Design, Board Layout<br />
| ARM/AM335x Kernel Development<br />
|-<br />
| Jayneil Dalal<br />
| jayneil<br />
| English<br />
| Hindi, Gujarati<br />
| US Central Time<br />
| Basic Embedded Linux, Documentation<br />
| -<br />
| Application based hw/sw projects on the Beaglebone<br />
|-<br />
| Laine Walker-Avina<br />
| Ceriand<br />
| English<br />
| -<br />
| US Pacific<br />
| C, Assembly, Buildroot, Reprap<br />
| USB protocol & logic analyzers, Various JTAG probes, 3d printer<br />
| OpenOCD, bootloaders, Linux kernel, Reprap firmware<br />
|-<br />
| Alan Ott<br />
| alan_o<br />
| American English (Central Florida Dialect)<br />
| American English (Midwestern Dialect)<br />
| US Eastern (EDT)<br />
| Linux Kernel, Firmware<br />
| Breadboard wire-jamming<br />
| 802.15.4 Wireless, USB<br />
|-<br />
| Hunyue Yau<br />
| ds2<br />
| English<br />
| -<br />
| US Pacific<br />
| Android, C, Linux, scripting<br />
| Yes<br />
| -<br />
|-<br />
| Tom Rini<br />
| Tartarus<br />
| English<br />
| -<br />
| US Eastern<br />
| C, u-boot, OpenEmbedded<br />
| -<br />
| U-Boot or OpenEmbedded development<br />
|-<br />
| Luis Gustavo Lira<br />
| lglira<br />
| Spanish<br />
| English<br />
| GMT/UTC -5<br />
| Embedded Linux, C, Android<br />
| Design, Debug, Wiring<br />
| Projects on the BeagleBone<br />
|-<br />
| Derek Molloy<br />
| molloyd<br />
| -<br />
| -<br />
| GMT (London)<br />
| C++, Java, Embedded C/C++<br />
| Digital Circuits, Interfacing to Sensors<br />
| Beaglebone Applications, Linux Multimedia, Embedded Linux<br />
|-<br />
| Steven Frank Barrett<br />
| steveb<br />
| English<br />
| -<br />
| US Mountain<br />
| C<br />
| microcontrollers, BeagleBone<br />
| -<br />
|-<br />
| Frans Meulenbroeks<br />
| eFfeM<br />
| Dutch<br />
| English<br />
| CET<br />
| Linux (including drivers), U-Boot, C, Documentation; Coding Style, QA<br />
| device interfacing (for drivers), review FPGA code<br />
| -<br />
|-<br />
| Andrew Bradford<br />
| bradfa<br />
| English<br />
| -<br />
| E{S,D}T<br />
| C, some u-boot and kernel<br />
| PMICs, SD/eMMC, schematic review<br />
| Cross Linux from Scratch, Debian, 6LoWPAN<br />
|-<br />
| Pantelis Antoniou<br />
| panto<br />
| Greek<br />
| English<br />
| GMT+2<br />
| Linux Kernel, S/W Architecture <br />
| -<br />
| Embedded Linux architecture fixes<br />
|}<br />
[[BeagleBoard/GSoC/Ideas-2012#Mentors|Previous mentors]]</div>Panto